How to Use AI for Coding

Coding model picks have stabilised:

• Claude Sonnet 4 - Best all-rounder. Multi-file refactors, architectural questions, careful work.
• ChatGPT 4o - Fastest for snippets and quick "how do I X" questions.
• ChatGPT 4.1 - Deeper reasoning. For hard algorithmic problems.
• DeepSeek R1 - Reasoning model that punches above its weight on competitive programming.

The split that matters: chat models answer instantly and are right most of the time; reasoning models think for 10-30 seconds and are right more often on genuinely hard problems. Using R1 for "how do I reverse a string" wastes your time; using 4o for a tricky concurrency bug wastes your afternoon. See our full comparison of ChatGPT vs Claude for coding and DeepSeek R1 vs ChatGPT for the benchmarks.

The single most useful thing you can give the AI: the exact stack trace. Don't paraphrase. Don't summarise. Copy-paste the whole thing.

Why: error strings are unique fingerprints. AI models have seen them in training data and can often jump straight to the cause. "My code is throwing an IndexError" gets a generic answer; the actual stack trace gets the real fix.

The same principle extends to everything: paste the real function, the real config, the real failing test output. The most common coding-AI mistake is describing code instead of showing it - "I have a function that fetches users and sometimes returns None" gives the model fiction to debug. Your description contains your assumptions, and your assumptions are usually where the bug lives.

For non-trivial bugs:

"I'm hitting this error:
[paste full stack trace]

Code that produced it:
[paste relevant code]

Tell me:
1. The most likely root cause (with reasoning)
2. The fix
3. Two other things that could cause this same error if I'm wrong about #1"

The third bullet forces the AI to consider alternatives - Way more useful than a confident wrong answer. In practice, the bug is the model's first guess maybe 70% of the time; the alternatives list catches a good chunk of the rest without a second round-trip.

When the first fix doesn't work, don't just say "still broken." Paste the new error or the actual-vs-expected output. Each loop where you hand back concrete evidence converges; each loop where you hand back vibes diverges into the model rewriting random lines.

AI-generated code looks right. It runs. It's well-formatted. None of that means it's correct.

Common AI bugs:

• Imports of functions that don't exist (hallucinated APIs).
• Off-by-one errors in loops and slicing.
• Race conditions in async code.
• Missing edge cases (empty inputs, None, large inputs).
• Subtly wrong return types.

Review every line. Run it. Test edge cases. A concrete habit that scales: before accepting any non-trivial function, ask the AI itself "write 5 test cases for this, including the nastiest edge cases you can think of" and run them. The model is oddly good at breaking its own code when asked separately - Generation and critique use different paths through the same brain.

Most developers underuse AI for review. Paste your code (or someone else's) with this prompt:

"Review the code below. Focus on: bugs / logic errors, security issues, readability, performance problems that actually matter. Skip nitpicks. Be direct - Assume I'm a senior engineer."

The "skip nitpicks" line is critical. Otherwise the AI flags every imperfect variable name.

Expected output: 3-8 findings, usually one or two of which are real. That hit rate sounds low until you compare it to the cost - 30 seconds for a review that occasionally catches a SQL injection or an unhandled promise rejection before your colleague does. For security-sensitive code, run the review twice with different models; Claude and GPT reliably notice different things.

Generic AI code is written for a generic codebase - It'll use a different error-handling style, a different naming convention, and a testing library you don't use. The fix is a standing context block you paste at the top of coding conversations (or save as a system prompt):

"Project context: Python 3.12, FastAPI, SQLAlchemy 2.0, pytest. Style: type hints everywhere, early returns over nested ifs, no comments that restate the code. Errors: raise domain exceptions, never return None for failure."

Five lines like this eliminate most of the "technically correct, doesn't fit our codebase" output that makes AI code feel like slop. Update it as your stack changes; reuse it forever.

For recurring translation tasks (SQL ↔ ORM, regex generation, format conversion, commit-message drafting) save the prompt as a template instead of re-explaining the task every time. AskAI.free's prompt library includes coding templates for most of these patterns, and the token counter helps when you're deciding how much of a large file you can paste into one message.

A Flask endpoint intermittently returns 500s in production. The developer pastes the full traceback (sqlalchemy.orm.exc.DetachedInstanceError), the route handler, and the session setup into Claude Sonnet 4 with the structured-debugging prompt.

Root cause hypothesis #1: the object is accessed after the session closes, triggered only on the cached code path - Which explains the intermittency. The fix: eager-load the relationship before the session exits. Alternatives offered: a stale session registry, or a background thread sharing a session.

The developer applies the fix, then asks: "Write a pytest test that reproduces the original failure." The test fails on the old code, passes on the new code - Now the fix is proven, not vibes. Total time: 15 minutes for a bug that had been intermittent for a week. The pattern to copy: evidence in, hypotheses ranked, fix verified by a test the AI also wrote.