AI Can Write Code. It Still Can't Own the Design.

At 4:47 p.m. on Friday, a pull request can look like a small miracle. An AI coding assistant—software that predicts or generates code from the files and instructions you provide—has added an API endpoint, the tests are green, and the diff is tidy. The change ships before dinner.

Six months later, another engineer changes a pricing rule. A background job starts charging customers twice, but only after a retry. Nothing in the original pull request looked reckless. That is the uncomfortable part of AI-assisted coding: the most expensive failure may not be a bad line. It may be a missing explanation for why several lines belong together.

The question people search for is: what does AI-assisted coding do to maintainability over time? The honest answer depends less on whether a model can write code and more on whether humans keep making the decisions that give code a shape.

The dangerous gap between code that runs and code that lasts

Maintainability means how safely and easily a future developer can understand, change, and extend a system. Architecture is the collection of structural decisions that determine where responsibilities live, how components communicate, and what the system assumes about the world. Technical debt is the future work created when we take a shortcut today.

Those qualities are difficult to judge from a fresh pull request. A change may compile, pass its unit tests—small automated checks of individual behaviors—and still make the next change harder. The damage appears later, when someone must understand an unfamiliar dependency, preserve an undocumented rule, or debug a failure several layers away from the original edit.

That delay matters. Speed is visible immediately. Maintainability sends its invoice months afterward.

The research is more complicated than the slogans

The evidence does not support either extreme: AI coding tools are neither automatic disaster nor guaranteed productivity machine.

GitHub’s randomized study, published in 2024 and updated in February 2025, assigned 202 experienced developers to write a small Python web server. Developers with Copilot access were 53.2% more likely to pass all ten unit tests, and blind reviewers gave their code a small advantage in readability and maintainability. That is encouraging evidence for focused tasks, but it was a short exercise with a defined problem and a vendor-run study. It tells us little about what happens to a codebase after years of generated changes. (github.blog)

A different 2025 study from METR followed 16 experienced open-source contributors completing 246 real tasks in mature repositories. With early-2025 AI tools available, the tasks took 19% longer on average, even though the developers expected a speedup. Participants spent time prompting, waiting for, and reviewing generated output. This does not prove that AI always slows development; it shows that benchmark performance and real maintenance work measure different things. (metr.org)

DevOps Research and Assessment, known as DORA, described AI in its 2025 research as an amplifier: it magnifies an organization’s existing strengths and weaknesses. Stack Overflow’s 2025 survey found that 80% of developers were using AI tools, while only 29% trusted their accuracy; 66% said they spent more time fixing almost-right generated code. Nearly 72% said prompting an AI to generate an entire application—often called vibe coding—was not part of their professional work. Adoption is widespread. Confidence is more conditional. (dora.dev)

Why a tidy helper can hide a serious design problem

Consider this generated-looking checkout flow:

def checkout(cart, payments, orders):
 total = sum(item.price * item.quantity for item in cart)
 payments.charge(cart.customer_id, total)
 orders.create(cart)
 send_receipt(cart)

Every line is plausible. The happy path works. Yet the important question is what happens when orders.create fails after the card has been charged. A side effect is an operation that changes something outside the function, such as charging a card or sending an email. Here, the side effects have been arranged without defining what must happen if one of them fails.

A careful design would make the payment and order states explicit, decide how retries behave, and ensure that repeating the same request does not charge the customer twice. That property is called idempotency. The implementation might involve payment authorization, an order reservation, a confirmation step, and a compensating cancellation. The exact design depends on the payment provider and database, but the architectural decision comes before the code.

This is where code generation often feels wiser than it is. A model can produce a clean-looking function while missing the invariant—the condition that must remain true throughout the system. It may also split one function into five helpers, leaving the reader to jump through files before understanding the original flow. A smaller function is not automatically a clearer abstraction.

Keep the human in the learning loop

Code review is not dead. Its valuable work is moving upward. Instead of spending every minute correcting formatting, reviewers need to examine boundaries, failure behavior, data ownership, and whether the change fits the system’s existing ideas.

A human-led AI workflow usually has a few habits:

• Write down the contract before generating code: inputs, outputs, invariants, failure cases, and non-goals.
• Ask for a narrow change instead of an entire feature, then require the assistant to state its assumptions and affected files.
• Read the diff and the surrounding code. Generated code is not understood code until someone can explain why it belongs there.
• Test unhappy paths, retries, permissions, timeouts, and integration boundaries—not only the example that appeared in the prompt.
• Record important choices in an architecture decision record, a short note explaining what was chosen and why.

AI is excellent at mechanical work: translating repetitive code, drafting tests, searching a large repository, producing documentation, or sketching several alternatives. Those tasks still need review, but they do not require the model to decide what the system must protect over time.

Measure the speed that arrives later

The tempting measurements are lines generated, minutes saved, or pull requests opened. They are easy to count and easy to misunderstand. A better question is how long it takes the team to make the next safe change.

Useful signals include repeated review comments, escaped defects, rollback frequency, time spent investigating regressions, and how long a new engineer needs to understand a subsystem. None of these is a perfect measure of design quality. Together, they reveal costs that a green build cannot see.

The goal is not to keep every line human-written. The goal is to keep design judgment human-owned. An AI assistant can suggest a path through the forest, but it does not carry responsibility for where that path leads.

AI has access to enormous amounts of technical knowledge. Wisdom is different. Wisdom is choosing a boundary, noticing a hidden trade-off, learning from a failure, and remembering the lesson when the system changes again. Those are the parts of software development we cannot safely outsource merely because the first draft arrives faster.