labs.rahulsheelavantar.in — stop-using-ai-like-autocomplete-llms.mdx
home.md projects/ tools/ devlog/ articles/ × now.md about.md
2026-05-20 · #ai #llm #engineering #refactoring #prompt-engineering

# Stop Using AI Like Autocomplete — How Senior Engineers Actually Use LLMs

LLMs as reasoning partners for legacy refactors, edge-case tests, regex, and repo-aware prompts — not smarter tab-complete.

Beyond autocomplete

Refactoring legacy systems. Finding hidden edge cases. Decoding impossible regex. Designing smarter engineering workflows.

Most developers started with one use case: autocomplete. Write a function name, press tab, save keystrokes. Useful — not transformational.

The shift happens when you treat Large Language Models as engineering reasoning tools, not smarter IntelliSense. LLMs recognize patterns in messy systems, translate unreadable logic into maintainable abstractions, surface edge cases, and accelerate understanding. Senior engineers use AI to avoid wasting mental energy on repetitive complexity — not to avoid coding.

Typing speed was never the bottleneck. Understanding systems was.

Painful work: tracing side effects, undocumented business logic, debugging edge cases, safely modifying fragile systems. That’s where LLMs act as reverse-engineering assistants, documentation generators, architecture reviewers, and reasoning engines.

Workflow 1 — Refactoring legacy code safely

Every team has the 700-line function with nested conditions, duplicated logic, mutable shared state, and comments from a production outage years ago.

function processPayment(user, amount, country, isPremium, retry) {
  if (user && amount > 0) {
    if (country === "US") {
      if (isPremium) {
        chargeStripe(user, amount);
      } else {
        if (amount < 5000) {
          chargeStripe(user, amount);
        } else {
          chargePayPal(user, amount);
        }
      }
    } else {
      if (retry) {
        retryPayment(user.id);
      } else {
        chargePayPal(user, amount);
      }
    }
  }
}

Bad prompt: Refactor this code. — LLMs may rewrite too aggressively and change behavior.

Step 1 — Explain before refactoring

You are analyzing legacy production code.

Do NOT refactor yet.

Tasks:
1. Explain the purpose of this function
2. Map the data flow step-by-step
3. Identify hidden dependencies and side effects
4. Highlight duplicated logic
5. Identify risky areas where behavior could change accidentally

Step 2 — Controlled refactoring

Refactor this code while preserving exact behavior.

Rules:
- Do not change business logic
- Extract small pure functions
- Reduce nesting using guard clauses
- Keep naming explicit
- Preserve edge-case behavior

After refactoring:
1. Explain what changed
2. List assumptions made
3. Suggest regression tests

Example output shape:

function processPayment(user, amount, country, isPremium, retry) {
  if (!isValidPayment(user, amount)) {
    return;
  }
 
  if (country === "US") {
    processUSPayment(user, amount, isPremium);
    return;
  }
 
  processInternationalPayment(user, amount, retry);
}

The value is reducing cognitive overload, not raw generation speed.

Workflow 2 — Unit tests for hidden edge cases

Humans test happy paths. LLMs are strong at adversarial thinking.

Analyze this function before writing tests.

Tasks:
1. Identify hidden assumptions
2. List input constraints
3. Find 5 non-obvious edge cases
4. Consider malformed inputs
5. Identify async or concurrency risks

Then write Jest tests for each case.

Timezone example:

function isSameDay(date1, date2) {
  return date1.toDateString() === date2.toDateString();
}
test("handles UTC timezone boundaries", () => {
  const date1 = new Date("2025-01-01T23:00:00Z");
  const date2 = new Date("2025-01-02T01:00:00+02:00");
 
  expect(isSameDay(date1, date2)).toBe(true);
});

Workflow 3 — Deconstructing complex regex

^(?=.*[A-Z])(?=.*\d)[A-Za-z\d@$!%*?&]{8,}$

Ask for structure, not a one-liner answer:

Explain this regex pattern step-by-step.

Requirements:
1. Break down every token
2. Use a markdown table
3. Explain lookaheads separately
4. Identify performance risks
5. Mention possible catastrophic backtracking issues
6. Rewrite it in a maintainable commented format

Maintainable rewrite:

const passwordRegex = new RegExp(
  ["^", "(?=.*[A-Z])", "(?=.*\\d)", "[A-Za-z\\d@$!%*?&]{8,}", "$"].join("")
);

Workflow 4 — Prompt engineering for real workflows

Output quality depends on context structure. Prompt engineering is a development skill because ambiguity destroys output quality.

agent.md

Many teams keep reusable context:

# agent.md
 
## Architecture Rules
- Use repository pattern
- Prefer dependency injection
- Avoid static state
 
## Testing Standards
- All business logic requires unit tests
 
## Coding Conventions
- Prefer explicit naming
- Avoid deeply nested conditionals

Repository-aware prompting

Bad: Build this feature.

Better:

This repository uses:
- CQRS architecture
- MediatR
- Repository pattern
- Feature-based folder structure
- FluentValidation

Generate code matching existing conventions exactly.

Task decomposition

Rarely build entire systems in one shot:

  1. Analyze requirements
  2. Identify affected modules
  3. Propose architecture changes
  4. Identify risks
  5. Generate implementation plan
  6. Generate code incrementally
  7. Generate tests

Bonus — New feature development

The value is architectural acceleration: implementation strategies, migration plans, scalability review, dependency analysis, scaffolding repetitive layers — not “generate an app instantly.”

Where LLMs still fail

  • Losing context in massive files
  • Silently changing business logic
  • Hallucinating APIs
  • Overconfident incorrect code that looks right

Verification matters more than generation.

Golden rules of verification

  1. Run old and new code against the same tests — compare outputs, side effects, regression suites.
  2. Automated quality tooling — type checking, static analysis, security scanning, linters (ESLint, SonarQube, Semgrep, Snyk).
  3. Incremental changes — smaller prompts, easier review, safer refactors.

Final thoughts

The future is not AI replacing developers. It is developers using AI to reduce cognitive friction.

The highest-value workflows understand legacy systems, uncover edge cases, accelerate architectural reasoning, and evolve large codebases safely.

Use LLMs as reasoning partners — not autocomplete engines. Autocomplete was only the beginning.


Originally shared on LinkedIn.

// EOF stop-using-ai-like-autocomplete-llms.mdx
main
stop-using-ai-like-autocomplete-llms.mdx
UTF-8
LF
Markdown
Ln 1, Col 1