I use AI coding assistants every day, for most of the code I write. On a good day they multiply what one developer can finish. They also write code that is confident and wrong, and it reads exactly like code that is confident and right.
That is the whole problem in one sentence. A language model doesn't know when it's guessing. It will use an API field that doesn't exist, call a function with the arguments it ought to take, and report a task as done in the same calm tone whether it was done or not. Someone has to notice.
What notices is experience. I have written code professionally for over 17 years, and before development became full time I spent seven years in power-plant and pipeline design, where a wrong number ends up built in steel. Thousands of hours of knowing how things should be built is what makes a wrong answer look wrong before anyone runs it. Put the same assistant in front of someone without that, and they'll produce a lot of code very quickly. Whether it works is a question they can't answer.
Experience alone isn't enough either, because nobody reviews well at the end of a long day. The rest is process.
The habits that do the work
- A written knowledge base and a handoff file live in the repository. Every session, mine or an assistant's, reads the handoff first: what exists, where it lives, the rules, what was done and what is open. It's updated and committed at every stopping point. My instruction on one project was "we aren't saving anything for them, just passing things that are done", and "keep things tight, with the ability to hand off quickly".
- Small steps. One change, checked, committed and pushed. A small diff is one a person will actually read.
- Checks against known values. A calculation is right when it matches a number we already trust, to the cent, not when it looks reasonable.
- A person reviews every change before it ships, and looks at the result on screen as well as the diff.
- Dated backups before touching anything a live system depends on.
- Reality over notes. From another project: "Verify against reality, don't trust assumptions… the PASSDOWN has been wrong before."
Failure modes, and what catches each one
These are real, from our own projects and client work. Every one of them looked fine at first glance.
Invented details. An assistant fills gaps with the most likely answer: a field name, a config key, a method that sounds right. On a payroll integration, the rule was to change code only after the raw JSON from the API confirmed the field values, never by guessing what a field means. Looking at the real data first is cheap. Debugging a confident guess in production isn't.
"Done" that isn't. Ask whether something was compiled or deployed, and an assistant may say yes because yes is the expected next step. We have had a recompile reported as done that hadn't happened. So "it compiled" needs proof: the build output with zero errors, the compiled file's timestamp, the commit hash in the site footer. On one desktop plugin, a later session checked the compiled library's date and contents instead of trusting the note. That compile was real, but the same check found that the data files the rest of the system reads had been written four minutes before it, by the old code. No note would have mentioned that.
Right code, wrong environment. New source files saved with Unix line endings (LF) instead of Windows ones (CRLF) made a desktop platform's code generator miss a marked block and add a second copy, and the result was a pile of "already defined" compile errors in code that looked perfect. A compile check now runs on every change, and "CRLF for these files" is a written rule in the handoff, which is what the handoff is for.
Plausible ports. Rewriting a calculation in another language is where confident and wrong is most at home. When we moved calculations from a desktop platform into Python, "it looks the same" wasn't accepted. The Python version was checked against the original's live output, to the cent. A rebuilt feature had to reproduce the original's events exactly: 67 of 67 in one check, 43 of 43 in another. Close isn't a pass.
Copy everything, break something. A settings copy that took everything except a list of exclusions carried over internal state it shouldn't have, and a display column stayed empty with no error anywhere. Switching to an allowlist, which copies only the settings named, fixed it. An assistant reaches for the blocklist because it's shorter to write. Experience reaches for the allowlist because you know what you meant to copy.
One-character bugs. A literal "\n" in a deploy script, where a line break belonged, made every deploy fail with nothing on the site to say so. The script was valid, so nothing complained. Now the deployed commit shows in every page footer, and comparing it with the commit just pushed is part of finishing the job.
Stale assumptions. Handoff notes drift, and an assistant will act on an old note with total confidence. Before acting on one, read the code and check the live system. Before any database update, run a dry-run SELECT and look at what would change.
What productivity means
Measured in lines of code, AI assistants are astonishing. That's the wrong measure. More code means more to review, more to maintain and more places to be wrong. The measure we care about is finished, correct work: a calculation that matches the original to the cent, a deploy you can verify from the footer, a project someone else can pick up from the handoff file without a phone call.
On that measure the gain is still large. It goes to the developer who can tell good output from bad, and who has built the checks that make the difference visible. The speed comes from the assistant. The correctness still comes from the person.