Specifications Are Back: What AI Exposed About Your Engineering Foundations

When a coding assistant writes most of a pull request and the pull request still goes through, it's tempting to assume the work is done. In practice, that assumption is where the real work often begins.

AI coding tools are now standard equipment. In Google Cloud's 2025 DORA report, based on survey responses from nearly 5,000 technology professionals, 90% said they use AI at work. In the same survey, 30% reported little or no trust in the code it generates. The second number describes the work that's left.

Writing Code Is Now the Small Part of the Job

Some developers now estimate that the large majority of their code is AI generated. What remains is adding a few details, confirming the logic holds up, and wiring the new code into the rest of the system. That's the shift in one sentence. Writing the code is now the small part of the job. Checking it is the job.

How well that checking goes is harder to judge from the inside than it looks. In a randomized controlled trial with experienced open-source developers in early 2025, METR  found that developers expected AI to speed them up by 24% and, even after finishing their tasks, believed it had sped them up by 20%. Measured, they took 19% longer. METR has since labeled those results out of date. Its February 2026 follow-up suggests developers were likely getting more out of AI by early 2026, but says its new data is too weak to show how much, partly because a growing number of developers no longer wanted to work without AI at all. The finding that lasts is the gap: how productive AI feels is not evidence of what it actually produced.

Why Almost Right Is Harder to Catch Than Wrong

Here's what that risk looks like in practice. An engineer at Qt Group asked an AI assistant for a sample showing how to write a specific piece of code, tested against the team's own codebase. What came back didn't exist anywhere in that codebase, and the model never flagged any doubt about it. It simply presented the fabrication as fact.

The engineer caught it because they knew that codebase well enough to see something was off. Without that reference point, the fabricated code goes straight through.
The core problem is that AI output usually isn't wrong. It's almost right, and almost right is harder to catch than obviously wrong. As more code gets generated, detailed human knowledge of what's actually in a codebase goes down, and reviewers face far more code to check.

Repository data points the same way. GitClear's 2026 analysis of 623 million code changes found duplicated code blocks up 81% compared with 2023, while refactored ("moved") code fell from 21% of changed lines in 2022 to 3.8% in 2026. The data shows trends across the period of AI adoption rather than proving that AI wrote each line, but the direction is consistent: more new code, less consolidation of what's already there.

The rule of thumb: wherever an algorithm can perform the check, use the algorithm instead of the AI. A deterministic check gives the same answer every time, and that answer could then be used as part of the evidence.

Accountability Hasn't Moved, but the Workload Has

People are responsible for what they ship, whether they wrote it or a model did. You can't prompt a model into being safety compliant or into meeting a coding standard. Asking nicely may improve the odds, but it doesn't produce evidence. That's why static analysis, meaning automated tools that analyze source code for problems without running it, still has to sit in the pipeline, no matter who, or what, wrote the code. At the end of the day, AI is a copilot, not a pilot.

The responsibility line hasn't moved, but the workload behind it has grown sharply. DORA's 2025 research found that AI adoption now goes hand in hand with higher delivery throughput, but still with lower delivery stability. Teams with strong automated testing and fast feedback loops absorb the extra volume. Teams without them see it turn into instability.

Shared Quality Ownership Meets Its Stress Test

Few teams still work with a strict split where developers write the code and a separate test group finds the bugs. Developers own their tests, continuous integration (CI) runs on every change, and quality is a shared responsibility.

AI puts that model under load. When a large share of the code comes from a model, "the developer owns quality" only holds if the developer can show the code does what it should, not just that it compiles and passes the tests generated alongside it.

Safety-regulated development has made this expectation explicit for years. Standards such as ISO 26262 and IEC 62304 expect documented, traceable evidence that requirements are implemented and verified, and they demand more rigor the more harm a failure could cause. Most teams don't need that level of formality. The underlying habit is what transfers: "done" means shown to work, not merged.

The Documentation Reckoning

Here's where teams start to separate, and it has nothing to do with which AI tool they use.
The roots go back ten to fifteen years, to what many teams took from the shift to agile development. The lesson they absorbed wasn't that teams should work in short cycles. It was that documentation had become optional: start the sprint, start coding, ship every two weeks.
The result is requirements that amount to little more than a title, with nothing underneath explaining what the feature needs to do.

The cost used to be mostly human, with developers and testers reading the same vague requirement two different ways. Now it compounds, because AI needs precisely the input those teams don't have. Feed a model a title instead of a real requirement, and you get guesses instead of code.

That's why specifications are back.

What Separates the Teams AI Helps From the Teams it Exposes

A lightweight readiness review can work fine: twenty minutes booked, usually wrapped up in ten. The sharper point is that in many teams, the definition of done contains no quality criteria at all. Few use a definition of ready, the gate that would catch bad requirements before they reach a developer, human or AI.

Problems in requirements and design tend to be the most expensive to fix late, because everything built on top of them has to change as well. Periodic cleanup sprints don't address that.

Code accumulates for six months, then gets a scramble tidy-up before the next release. The approach fails for a structural reason: nobody authorizes cleanup two weeks before a release, and nobody sees the need for it two weeks after one ships.

Continuous, automated checks that surface problems within the hour work far better.

The Judgment Gap Coming for the Next Generation

Engineers doing this work well today can look at what a model produces and make a fast, accurate call: take it or throw it away. That instinct wasn't innate. It was built over years of writing, reading, and fixing code, long before AI entered the picture.

The real concern is the generation coming up without that reference point. Without years of exposure to what good code looks like, there's no baseline to judge AI output against. Within a few years, an entire cohort of developers will have had AI available for their whole careers, with no experience of working any other way to compare against.

Four Things to Do Now

Lower the barrier to doing quality work, not the bar itself.

Check coding standards automatically on every merge. Surface issues inside the editor in real time, the way a spell-checker flags a typo before you finish the sentence. You can't declare everyone a quality engineer, but you can make it nearly free to act like one.

Build onboarding around exposure, not just curriculum.

Put new engineers in front of what happens when a product ships broken, at scale, as early as possible.

Write down intent, and keep it checkable. 

Requirements and intended architecture are the specification. People write them, before the code, because they capture what the system is supposed to do. Reviewed once and shelved, they drift. Kept in a form a tool can check, they become a continuous test of whether the code still matches the design. Architecture verification tools such as Axivion Architecture Verification do this by continuously comparing the intended architecture with the actual code structure. 

If the input documentation isn't good, there's no path to the code being good, and no path to anything downstream of it being good either.

Let descriptive documentation follow the code. 

Documentation that describes what the code currently does, such as API references or as-built dependency views, is far easier to maintain when it's generated from the code itself, because the code is already machine-readable. Some teams generate it in the same pipeline that builds the code, so the two can't quietly drift apart.

With intent written down and description generated, the two can be compared. Every gap shows either code that has drifted from the design or a design that needs updating.
Whatever tooling holds that intent, keep it understandable to the whole team. A project where only one or two people can read or update the architecture model has a real problem the day those people leave. Simple boxes and arrows that everyone can read often serve a project better than a sophisticated model only specialists understand.

Specifications Are Back, Indeed

AI isn't the variable that decides whether a team succeeds here. It's the amplifier. DORA's 2025 report reached the same conclusion from its survey data: AI doesn't fix a team, it amplifies what's already there.

Teams that kept the unglamorous fundamentals in place, like clear requirements, checkable architecture, and lightweight but real quality gates, are the ones AI is making faster.

Teams that let that discipline slide are finding out now, because the knowledge that used to live in people's heads doesn't fit in a context window. The fabricated code sample earlier in this piece was caught because someone had a reference point outside the AI, built from years of experience, long before any model showed up.

If your team doesn't have that, the tool won't save you. It will find you out.