AI-written code and what it costs you later

Every studio now uses AI to write code, including the ones that do not mention it. The honest question is not whether it is used but what discipline surrounds it, because the failure mode does not appear during the build. It appears six months later when something has to change.

Where it genuinely helps

• Boilerplate with a known shape: forms, table components, API clients, test scaffolding.
• Translating between things. A schema into types, a design into markup, one framework's idiom into another's.
• First drafts of code you are competent to review. The speed-up is real and large.
• Explaining unfamiliar code, which is genuinely useful when inheriting a codebase.

Where it costs

Anything where the right answer depends on context the model does not have. Your data model, your performance budget, the reason a previous decision was made. Generated code is plausible by construction, which is exactly what makes a wrong version expensive: it passes review by looking right.

The specific pattern to watch for is quiet duplication. Asked for a function five times across a project, a model will produce five similar-but-different versions rather than reusing one. Nothing breaks. The codebase simply becomes harder to change, and nobody can point at when it happened.

Questions worth asking a studio

1. 01Does a person read every line before it ships? The answer should be immediate and unqualified.
2. 02What happens when the generated approach conflicts with the existing architecture? You want to hear that the architecture wins.
3. 03Who understands this code in six months? If the honest answer is nobody, you are buying a rewrite on a delay.
4. 04How is it tested? Generated code often comes with generated tests that assert what the code does rather than what it should do.

What good practice looks like

Treat it as a fast junior who is confident and has not read the rest of the codebase. Useful, worth having, and not something you merge unread.

In practice: generate against a clear spec rather than a vague prompt, review with the same standard applied to any contribution, and delete rather than adapt when the output does not fit. The last one is where discipline actually shows, because adapting something almost-right is how the duplication gets in.

The honest summary

Used with review, it makes competent teams faster. Used without, it makes weak code arrive sooner and in larger quantities. The tool did not change what good engineering is; it changed how quickly you can accumulate the other kind.