Intro
Ask an AI assistant to "handle the checkout flow" and it will hand you a working function in about four seconds. Validate the cart, call three different APIs, format a receipt, log the analytics event, catch whatever errors show up, all in one block, three levels of nesting deep. It runs. It passes the one test anyone bothered to write. And it is, structurally, a small readability crisis waiting for whoever opens that file next.
That gap, between code that works and code a human can actually follow six months later, is where most of the real cost of AI-assisted development quietly accumulates. Here's where it actually shows up. (Illustrative composites drawn from common patterns, not specific incidents.)
The function that does six things because nobody told it not to
A generated function rarely sets out to do too much. It just keeps absorbing responsibility one prompt at a time: first it validates input, then someone asks it to also handle a retry, then to also log the outcome, then to also format the response for the frontend. Each addition looks reasonable in isolation. Read top to bottom six weeks later, it's a single function holding four unrelated jobs, and splitting it back apart means first reverse-engineering which lines belong to which job.
Names that describe the prompt, not the domain
Generated code tends to name things after the immediate task rather than the concept it represents: data2, tempResult, processedItems, handleStuff. None of these are wrong in the sense of breaking anything. They're wrong in the sense that a teammate reading the code six months from now has to run it mentally just to figure out what tempResult actually holds, instead of the name just telling them.
A slightly different helper function, invented every time
Ask a model to format a date in one file and it writes formatDate. Ask it again in another file, in the same session even, and it might write toDateString, doing almost the same thing with a slightly different edge case handled. Nothing is technically duplicated, so no linter flags it, but the codebase slowly fills with near-identical helpers that all do roughly the same job slightly differently, because each generation has no memory of what already exists two files over.
Style that resets at every file boundary
File A uses early-return guard clauses. File B nests every conditional three deep because that's what was statistically nearby in training for that particular pattern. Neither is "wrong" on its own, a reviewer skimming one file at a time won't necessarily flag it, but navigating the codebase starts to mean re-learning the local dialect every time you open a new file, because there isn't one.
None of this is a code-quality problem in the traditional sense, where someone wrote something sloppy and a linter catches it. It's a missing style contract problem: nothing external is constraining the model toward the conventions your team already agreed on, so by default it reaches for whatever's statistically common across its training data, which is rarely what's locally correct for your codebase.
So what do you actually do about it? One option is writing an exhaustive style guide and hoping every prompt includes enough of it, which doesn't scale past a few files and quietly rots the moment someone forgets to paste it. The other is treating readability as something enforced at the commit gate, the same way you'd enforce tests passing, independent of whether a human or a model wrote the line. Prompts don't have memory. Commits do. That's really the whole argument for moving readability enforcement from "hope the prompt was good" to "verify the commit is."
How is your team actually enforcing readability on AI-generated code right now, a style guide baked into the prompt, a linter, code review, or honestly, nothing yet?
