The AI Code Tool: Write and Debug Faster

The code tool writes, explains and debugs code across languages. Used well it removes hours of boilerplate and lookup; used carelessly it produces confident-looking code that doesn't run. This guide covers the engines and the habits that keep you on the productive side of that line.

The models

The code tool runs on the same Claude models as text — the difference is quality versus speed:

• Automatic (recommended): a good default for most tasks.
• Claude Sonnet: everyday coding — snippets, functions, config, quick fixes.
• Claude Opus: reach for it on tricky logic, larger refactors, subtle bugs or unfamiliar libraries.
• Claude Haiku: quick lookups and small utilities when you just need a starting point.

“Use Claude Opus when the bug is the kind you'd spend an hour on. Use Claude Haiku for the regex you'll verify in ten seconds anyway.”— WorkCrafter

Prompt for working code

Vague requests produce vague code. Give the tool the context a colleague would need:

1. Language and version ("Python 3.12", "TypeScript, Node 20").
2. What the code should do, and the inputs and outputs.
3. Constraints: framework, style, no external dependencies, performance limits.
4. Where it runs, if it matters (browser, server, serverless).

Write a TypeScript function (Node 20) that reads a CSV file and returns an array of typed objects. No external libraries. Handle quoted fields and empty lines. Include a short usage example.

The more precisely you bound the task, the more likely the first result runs. "Parse a CSV" gets you a toy; the prompt above gets you something you can paste in.

Debugging with it

The tool is often faster at reading an error than you are. Paste the exact error message and the relevant code, and say what you expected to happen. "It doesn't work" wastes the request; the stack trace plus the failing input gets a real diagnosis.

Always review before you ship

Generated code can look right and be subtly wrong — an off-by-one, a missed edge case, an outdated API. Treat every result as a competent draft from someone who didn't run it:

• Read it before you run it, especially anything that deletes, writes or sends.
• Run it against a real input, not just the happy path.
• Never paste secrets, API keys or customer data into a prompt.
• Be skeptical of library calls you don't recognise — verify the function exists.

Give it the context a colleague would need

The model cannot see your repository, your database or your error logs. It answers using only what is in the prompt, which means the quality of the answer is capped by the quality of the context — the same as asking a competent colleague who has never seen your codebase.

For a bug, that means four things: the exact error text, the code that produced it, what you expected instead, and what you already tried. Three of those are usually missing, which is why "it doesn't work" produces a guess and a stack trace produces a fix.

Error:
  TypeError: Cannot read properties of undefined (reading 'map')
  at renderList (app/list.tsx:24)

Code:
  [paste the function]

Expected: an empty list renders as "No items yet"
Already tried: adding a null check on props.items

Where it is genuinely strong

• Boilerplate you have written a hundred times — parsers, config, CRUD handlers, test scaffolding.
• Unfamiliar syntax: you know exactly what you want, you just don't know how this language spells it.
• Reading an error you have never seen before, which is often faster than searching.
• Translating between languages when you understand the logic but not the idiom.
• Writing the tests you would have skipped.

Where it will quietly mislead you

The failure mode that costs real time is not code that crashes — it is code that runs and is subtly wrong. These are the cases where you should slow down and read carefully.

• Library APIs that changed between versions. It may confidently call a method that was removed.
• Edge cases at boundaries: empty inputs, off-by-one, timezone and encoding issues.
• Anything security-shaped — auth, permissions, input handling. Review it as if a stranger wrote it, because one did.
• Performance claims. "This is faster" is a hypothesis until you measure it.
• Confident invented functions. If you don't recognise a call, check it exists before you build on it.

A working loop

1. Ask for the smallest useful piece — one function, not a feature.
2. Read it before you run it, especially anything that writes, deletes or sends.
3. Run it against a real input, not just the happy path.
4. Feed the actual error back in if it fails, rather than describing it.
5. Ask for tests once it works — that is when you know what the behaviour should be.

What never goes in a prompt

Never paste API keys, passwords, connection strings, customer data or anything under NDA. If you need help with code that contains a secret, replace it with a placeholder first. This costs two seconds and prevents the one mistake in this guide you cannot undo.

Tasks worth handing over first

If you are working out where this fits in your week, start with the work that is well-specified and tedious rather than the work that is hard. The returns are immediate and the review burden is low.

• A regex, a date-format conversion, a SQL query you could write but would have to look up.
• Test cases for a function that already works — you know the expected behaviour, so verification is trivial.
• A one-off script: rename these files, reshape this JSON, parse this log.
• Explaining unfamiliar code someone else wrote, before you change it.
• The boilerplate half of a feature, so your attention goes to the half that is actually decided.

What stays with you is architecture, anything touching money or auth, and any decision whose consequences outlive the sprint. Those are cheap to type and expensive to get wrong — exactly the inverse of the tasks above.

What it costs

A code generation costs 2 credits — about $0.04 at the $5 starter rate, the same as text. Failed generations are refunded automatically, so iterating on a prompt is cheap.

Frequently asked questions

Can it work on my whole project?

It works on what you give it in the prompt — a function, a file, an error. It doesn't see your repository, so paste the relevant context and keep tasks focused.

Which model for a hard bug?

Claude Opus. Subtle logic and unfamiliar libraries are exactly where the extra capability earns its keep; for a quick utility, Claude Sonnet or Haiku is plenty.

Is the generated code safe to use commercially?

Yes under the platform's terms, but you're responsible for reviewing it — correctness, licensing of any patterns, and security are on you before it ships.

Start building

Open the code tool, give it the language, the goal and the constraints, and paste real errors when you debug. Review every result before you run it and you'll ship faster without shipping surprises.