# How to Use AI for Coding Without Shipping Buggy Code URL: https://codebasechat.com/journal/how-to-use-ai-for-coding Type: blog Locale: en Published: 2026-11-10 Updated: 2026-11-11 --- > A practical workflow for using AI for coding: what to write before prompting, which tool fits which job, and how to review generated code. You open a ticket, paste the description into a chat window, and get 200 lines of plausible code back. It compiles. Two days later a reviewer asks why it ignores your retry wrapper, and nobody on the team can say. That is the usual failure when people learn how to use AI for coding: the generation step goes well and everything around it does not. Here is the workflow I give new engineers. It treats the model as a fast, confident junior who has never seen your repo. It is built around review time, not typing time. ## Does AI actually make you faster at coding? Sometimes, and the honest answer depends on the task. The [Stack Overflow 2025 Developer Survey](https://survey.stackoverflow.co/2025/ai) found that 84% of respondents use or plan to use AI tools, yet only 33% trust the output to some degree. The top complaint, at 66%, is code that is "almost right, but not quite". Another 45.2% say debugging AI-generated code takes longer than expected. Controlled data is less flattering. In a 2025 study by [METR](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/), 16 experienced open-source developers worked through 246 real issues in repos they knew well. With AI allowed, they finished about 19% slower, while believing they had been about 20% faster. METR has since published newer data, so treat that number as a snapshot of early 2025 tools, not a verdict. The takeaway is not "AI is slow". It is that the feeling of speed is a bad instrument. Measure in minutes from ticket to merged PR, not in how fast the first draft appeared. ![Open notebook with a hand-drawn feature plan beside a keyboard and sticky notes](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-11/216434-inline1.webp) ## What should you write down before you prompt anything? A plan, in your own words, in under ten lines. Skip this and the model fills the gaps with its own guesses, which are generic by definition. My template is short: - The behavior change, in one sentence. - The files you expect to touch, even if you are unsure. - The existing function or pattern the new code must reuse. - One thing it must not do (no new dependency, no schema change). - How you will know it works: a test, a curl, a screenshot. Point 3 is the one people skip, and it is where most "almost right" code comes from. The model does not know your `withRetry` helper exists unless you name it or it can read it. Skip the "build me the whole app" prompt. Beginners and seniors both get the same result from it: a big diff nobody understands, and an unfinished project. ## What does a good prompt look like in practice? Take a real chore: the webhook sender drops events when the receiver times out. A weak prompt says "fix webhook reliability". A usable one reads like a ticket. `Add retry with exponential backoff to sendWebhook() in src/webhooks/sender.ts. Reuse withRetry() from lib/http.ts. Max 4 attempts, jitter on. Do not change the public signature or add dependencies. Add a vitest case for a receiver that fails twice, then succeeds.`That prompt names the file, the helper to reuse, a limit, and a check. The result is a diff of maybe 30 lines you can read in one sitting. If the diff comes back at 150 lines, the model has wandered, and you reject it instead of editing it. Two small tricks help here. Ask for a plan first and read it before any file changes: a wrong plan costs thirty seconds, a wrong diff costs ten minutes. And when an answer is off, restate the constraint that was violated instead of arguing. "You added a new dependency; the rule is none" works better than a paragraph of explanation. ## Which kind of AI coding tool fits which job? Three shapes exist, and mixing them up is the second most common mistake. **Inline completion** predicts your next lines as you type. It is good for boilerplate and tests where the pattern is already on screen. **Chat in the editor** answers questions about selected code and proposes edits you accept hunk by hunk. **Agents** take a task, read files, run commands, and come back with a branch. Pick by how much you can verify cheaply. A completion you can read in two seconds is low risk. An agent run touching 14 files is high reward and high review cost. Cursor is the editor-first option: a VS Code fork with strong Tab completion and parallel agent sessions. Worth it if you live in an editor all day. Skip it if your team standardizes on JetBrains and will not switch. GitHub Copilot is the low-friction choice for teams already on GitHub, since PRs, issues and review sit in one place. Watch the billing: it moved to usage-based credits in June 2026, so heavy agent use costs more than the seat price suggests. Claude Code is terminal-native and agentic: you delegate a refactor or a bug hunt, then review the result. It has no inline autocomplete, and it runs Claude models only. That is a fair trade if you want task-level delegation. Aider is the scriptable, git-native option. It auto-commits each change with a message, so rollback is `git revert`. You pay only for model tokens, which suits people who want control over cost. ## How do you stop it from writing code that ignores your repo? Give it context deliberately. Most bad output traces back to the model never having seen the relevant file. Three habits help. First, attach the two or three files that define the pattern, not the whole directory. Second, paste the failing test or error verbatim instead of describing it. Third, keep a short rules file in the repo (naming, error handling, banned libraries) that the tool reads on every run. Most agent tools support one. `# AI-RULES.md - Errors: return Result, never throw in services/ - HTTP calls go through lib/http.ts (has retry + tracing) - No new deps without a note in the PR description - Tests: vitest, colocated as *.test.ts`Four lines like these remove a surprising share of review comments. They also help humans. On a repo you do not know yet, ask questions before asking for edits. "Where is session expiry enforced, and what calls it?" is a better first prompt than "add a refresh token". You read the answer, open the two files it cites, and only then decide what to change. This is the same grep, blame, ask-someone loop you already do, just faster. ![Laptop screen showing a code diff with green and red highlighted lines](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-11/567383-inline2.webp) ## How should you review AI-generated code? Slower than you review a colleague's. A colleague has a track record with your codebase. The model does not. My checklist, in order: - **Run it before you read it.** A passing test you wrote beats a confident explanation. - **Read the imports.** Invented packages and unfamiliar helpers show up there first. - **Look for what is missing.** Error paths, null handling, cleanup. Models write the happy path well. - **Check the diff size.** If you asked for a 10-line fix and got 120 lines, something was rewritten that you did not ask for. - **Delete what you cannot explain.** If you could not defend a line in review, it does not merge. Keep the commit small and the message honest. "Add retry to webhook sender (AI-assisted, tests added)" is fine. Hiding it helps nobody and makes later debugging harder. ## What should you never hand to AI? Anything where being wrong is quiet and expensive. Auth logic, payment flows, data migrations, and permission checks are all places where "almost right" passes tests and fails in production. You can still use it there, but in a different mode: ask it to review your code and list risks, rather than write the code. Reading a list of five possible issues costs you three minutes. Reading a generated migration costs you the afternoon you will spend doubting it. If you are learning, there is a second exclusion. Write the first version yourself, then ask the model to critique it. A junior who always accepts the generated version learns to prompt, not to program, and the gap shows up in their first outage. ## How does this change for a team? The gap between individuals and teams is review load. One developer using agents can open more PRs per day than the reviewers can read. Agree on three things early: - **A size cap.** PRs over a few hundred changed lines get split, whoever or whatever wrote them. - **A disclosure norm.** Say when a change is AI-assisted, so reviewers adjust their attention. - **A shared rules file.** One source of truth for conventions beats five personal prompts. For onboarding, the best use I have seen is question-driven reading. New hires ask the assistant where things live, then verify in the code. It shortens the first week of "who owns this?" without handing them code they cannot maintain. ![Two engineers reviewing printed pages together at a meeting table](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-11/e7c330-inline3.webp) ## A first week plan you can copy Day 1: use inline completion only, for tests and boilerplate. Day 2: ask three codebase questions a day in chat and verify each answer. Day 3: let chat propose one small edit per task and read every hunk. Day 4: try an agent on a low-risk chore such as renaming a config key across files, on a branch. Day 5: write your rules file from what annoyed you in review. Track one number across the week: minutes from starting a ticket to a merged PR, including review fixes. If it did not drop, you have learned where the tool does not fit your work, which is also a result. ## Use it for reading first, writing second The fastest honest gain I have seen is not generation. It is comprehension: understanding an unfamiliar module in ten minutes instead of an hour. Writing code was never the slow part of the job. Reading, deciding, and verifying were. Point the tool at those, keep your own judgment on the merge button, and the rest follows. ## FAQ ### Can you use AI for coding if you are a beginner? Yes, but write the first version yourself and ask the model to critique it. Beginners who only accept generated code learn to prompt rather than to program, and that gap shows up when something breaks. ### What is the best way to prompt AI for coding? Describe the behavior change in one sentence, list the files you expect to touch, name the existing function the code must reuse, and say how you will verify it. Paste failing tests or errors verbatim. ### Is AI-generated code safe to merge? Not without review. Run it first, read the imports for invented packages, check the error paths, and compare the diff size to what you asked for. Treat it like code from a confident junior who has not seen your repo. ### Which AI coding tool should you use? Use inline completion for boilerplate, editor chat for questions and small edits, and agents for delegated tasks you can review on a branch. Cursor, GitHub Copilot, Claude Code and Aider each fit a different style of work. ### Does AI really make developers faster? It depends on the task. A 2025 METR study of experienced open-source developers measured about 19% slower work with AI allowed, while surveys show most developers report time savings on specific tasks. Measure your own cycle time. ### What should you not use AI for in code? Avoid generating auth logic, payment flows, data migrations and permission checks. Use AI there only to review your code and list risks.