How to Get Better Responses from AI Coding Tools

There's a pattern that shows up when you look across AI coding session data: a surprisingly large percentage of turns produce unhelpful or partially-wrong responses. And most of the time, it's not a model failure — it's a prompting failure. The context was vague, the scope was wrong, or the tool was missing information it needed to give a good answer.

That's actually good news. It means this is a skill you can improve.

The anatomy of a wasted turn

Before we get to techniques, it helps to understand what goes wrong. Most wasted turns fall into one of three categories:

1. Vague prompts. "Fix the bug" tells the model almost nothing. Which bug? Where? What behavior are you expecting vs. what you're seeing? Without this, the model guesses — and usually guesses wrong.

2. Missing context. AI coding tools work within a session, and sessions have limits. If you're working on a large codebase and haven't shown the model the relevant files, it doesn't know your architecture, your conventions, or what already exists. It'll generate something plausible that doesn't fit.

3. Wrong scope. Asking for too much ("refactor the entire auth system") produces generic, often incorrect output. Asking for too little misses the real problem. The sweet spot is a single, well-defined task.

Each of these is fixable. The techniques below address all three.

Technique 1: Give context, not just instructions

The single highest-leverage change you can make: tell the model where things live and what they do, not just what you want done.

Here's what a vague prompt looks like:

Fix the login bug.

Here's the same request with context:

The login form at src/auth/LoginForm.tsx is returning a 401 on valid credentials.
The auth middleware at src/middleware/auth.ts validates tokens — I think it might
be checking a stale token format after we migrated to JWTs last week. The old
format was base64, new format is a signed JWT with RS256.

The second version tells the model: where the problem is, what the symptom is, what recently changed, and what the likely cause might be. It has something to work with.

A simple template: file path + observed behavior + expected behavior + relevant recent changes. You don't need all four every time, but the more you provide, the better the output.

Technique 2: Scope your requests

Smaller requests, done well, consistently outperform large requests done poorly.

There's a useful mental model here: think about the goldilocks zone. If your request is too small ("add a semicolon here"), you're wasting turns on trivial things. If it's too large ("add full OAuth2 support"), the model will produce something that looks complete but has subtle gaps that are hard to find.

The goldilocks zone is a single, testable unit of work. "Add a logout endpoint to src/server/auth.ts that invalidates the session cookie and redirects to /" is a well-scoped request. It's specific enough to implement correctly, and you can verify it works the moment the model responds.

For larger features, break the work down yourself first. Plan the steps in your head or in a comment block, then execute one at a time. This takes discipline — it's tempting to just dump the whole feature request in — but the results are noticeably better.

Technique 3: Build on session history

AI coding tools maintain context within a session. You can reference what you've already built in this session without re-explaining it.

This is underused. If you spent three turns building a UserService class, you can say:

Using the UserService we just built, add a forgotPassword method that:
1. Looks up the user by email
2. Generates a reset token (use crypto.randomBytes, 32 bytes, hex-encoded)
3. Stores it in the user record with a 1-hour expiry
4. Returns the token (the caller handles sending the email)

You don't need to re-describe what UserService does or where it lives — the model already has that context. Reference it directly. This keeps your prompts shorter and the model more focused.

The practical implication: think of your session as a conversation with a colleague who has perfect recall of everything said so far. You can build on prior turns. You should build on prior turns.

Technique 4: Review your patterns, not just the output

Most developers spend time reviewing AI-generated code. Far fewer review their own prompting patterns.

This is worth doing. Over time, certain types of requests consistently get good results, and others consistently disappoint. Once you notice these patterns, you can adjust — front-load context on the requests that need it, break down the ones that tend to go wrong, be more explicit about constraints where the model tends to over-engineer.

A few questions that are useful to ask yourself after a session:

• Which turns produced the best output, and what made those prompts different?
• Where did I have to ask for corrections, and why was the first response off?
• Did I spend turns on clarification that I could have avoided with better context upfront?

You don't need to do this after every session. But doing it periodically, especially early on, accelerates the learning curve significantly.

Technique 5: Measure what you can't see

You can't improve what you don't measure, and most developers have no idea what their actual prompting patterns look like across sessions.

How many turns does a typical session involve? Which types of requests (bug fixes, refactors, new features) produce the most corrections? Which projects tend to have longer, more productive sessions versus fragmented, correction-heavy ones?

Without data, you're operating on intuition. Intuition is useful, but it tends to confirm what we already believe rather than surface what's actually happening.

Tools like Code Insights can parse your session history across AI coding tools — Claude Code, Cursor, Codex CLI — and surface patterns you can't see in any individual session. It's not the only approach, but having some mechanism for reviewing session data across time is worth building into your workflow.

Common anti-patterns

Conclusion

Getting better at AI-assisted coding is a learnable skill. The tools are capable — the limiting factor for most developers is the quality of the prompts, not the quality of the model.

The techniques here compound. Better context means fewer correction turns. Better scope means fewer partial implementations. Building on session history means less re-explanation. Start with the one that addresses your biggest failure mode (usually vague prompts or wrong scope), get comfortable with it, then layer in the others.

Small improvements to how you work with these tools add up quickly. A 20% reduction in wasted turns across a full day of development is an hour back in your pocket. Over a month, that's real time — time you can spend thinking about harder problems instead of prompting the same thing three different ways trying to get a usable answer.

The gap between a developer who uses AI coding tools and one who uses them well is prompting discipline. It's learnable, and it's worth learning.