AI Can Build. But Who Is Designing?

In the 1990s, imagine a construction company completing a five-story office building in downtown Boston. The structure is solid. The materials are first-rate. The finish is impeccable. The client is delighted.

Ten years later, that same client wants to add three more floors. They cannot.

Not because the building is fragile, but because the original architect never documented how much additional weight the foundations could support. It is not a visible defect. The building works perfectly for what was originally built. But the most important design decision (how much load the foundations can carry) lives only in the mind of an architect who is no longer there.

Without that knowledge, no one can tell whether adding three floors would be safe or catastrophic. The only responsible option is to go back to the foundations and start again.

A system whose design decisions are not written down is not finished. It is frozen at the moment when the last person who understood it is no longer available.

With AI, software teams can now reproduce this problem at industrial speed. An agent can generate in hours what once took weeks. The code compiles. The tests pass. The feature ships. And buried inside that output are design decisions the model made quietly because nobody specified them.

The system works. But the decisions governing it exist nowhere.

What we used to measure and why it made sense

For decades, evaluating a software engineer seemed relatively straightforward. We looked at how much they produced, how quickly they produced it, and whether it worked. Tickets closed per sprint. Time to resolve bugs. Test coverage. Sometimes even lines of code.

Those measures were imperfect, but they were understandable. Writing software was slow, difficult work that required years of accumulated experience. Production was scarce, so production became a proxy for expertise. The person who could build more or solve problems faster appeared to create more value.

It was the craftsperson model. The carpenter who made more chairs in less time was a better carpenter. The builder who raised more walls in a day was more productive. Manual execution was the bottleneck, so skill was visible through execution.

We measured production because production was the scarce resource.

That model worked for a long time. Then AI removed much of the friction from producing code, and we have not fully adjusted to what that means.

The danger of measuring AI-assisted work with yesterday's metrics

Today, almost any engineer can generate code quickly. Speed is no longer the differentiator it once was. More importantly, an engineer can generate a large amount of code without understanding it and still look exceptionally productive. or a while.

This is AI-assisted mediocrity. It is usually not malicious. It is simply the path of least resistance when teams have powerful tools but no clear standards for using them.

The engineer who once copied an answer from Stack Overflow without reading it no longer needs to search and, in the agentic era, no longer even needs to paste. Today's coding agents work directly in the repository: they write the code, run the tests, and open the pull request. The engineer's involvement can shrink to a prompt and an approval. Prompt. Delegate. Approve. Merge. No careful reading. No understanding of the trade-offs. No question about whether the solution fits the system around it.

The difference is scale. Copying one function without understanding it was risky. Merging an agent-built module in minutes without understanding it is a different category of risk. The industry data already reflects this shift: GitClear's research on AI-heavy codebases found that duplicated code blocks multiplied roughly eightfold between 2022 and 2024, and code churn has climbed sharply since, symptoms of volume outpacing comprehension.

Traditional productivity metrics do not detect this behavior. They reward it. Tickets close faster. Coverage goes up. The sprint ends in green. Everything looks healthy until, three months later, a security vulnerability appears in an endpoint that “worked perfectly,” or a production issue cannot be traced because nobody understands why the code is structured that way.

Consider an engineer who closes eight tickets in two weeks with AI. That looks impressive. But during code review, they cannot explain why they chose that database structure. They do not know how the endpoint behaves with unexpected input. When asked why they used a particular pattern, they answer, “The model suggested it.”

That engineer did not deliver eight units of durable value. They delivered eight future investigations with good test coverage.

The architect, the builder, and the mold

A useful way to understand the change is to look at architecture.

An architect does not mix concrete, lay bricks, or install pipes. Yet the architect is responsible for whether the building stands, whether it meets the client's needs, and whether the construction process is coherent, efficient, and safe.

Their value is not in manual execution. It is in the plan: the artifact that tells any builder, on any shift, how each wall should be built, which materials to use, which tolerances matter, and what to do when something is unclear.

Without a plan, every builder makes independent decisions based on local assumptions. The result may work room by room and still fail at the joints.

AI is the fastest builder we have ever had. Without a plan, it builds exactly what it interprets - not necessarily what you need.

There is another useful metaphor: the specification is the mold, and AI is the foundry. A foundry without a mold produces spilled metal. A foundry with a precise mold can reproduce the right part again and again, regardless of who operates the machine that day.

The engineer's job is shifting away from operating the foundry and toward designing the mold.

Why specification matters now

Specification-driven development is not a new idea. At its simplest, it means describing what should be built with enough precision before asking a person (or an agent) to build it.

What changed is the urgency –and, over the past year, the industry consensus. The approach now has a name the market has converged on: spec-driven development, or SDD. Microsoft, AWS, and Thoughtworks have all published spec-first methodologies, and purpose-built tools such as GitHub's Spec Kit and AWS Kiro treat the specification (not the chat transcript) as the primary engineering artifact. The premise behind all of them is the same one this article argues: the limiting factor is no longer how fast code can be generated, but how clearly intent can be captured, shared, and validated.

With a human team, an incomplete specification could be repaired through judgment and conversation. Developers filled gaps with experience. Context moved through meetings, chat threads, code reviews, and the shared culture of the team.

An AI agent does not automatically have that context. A new session may not know what was decided yesterday, why the system looks the way it does, or which business constraint shaped an earlier architectural choice. If the specification does not say, the agent fills the gap. It often does so confidently, and with code that compiles.

A useful specification is not a giant waterfall requirements document. It is a living set of artifacts that communicates what to build, how the system should behave, which constraints cannot be violated, which decisions have already been made, why they were made, and how to determine whether the result is correct.

That can include declared architecture, coding conventions, Architecture Decision Records, automated acceptance criteria, and an up-to-date description of the project's state.

Ask an agent to build an authentication endpoint without this context and it will produce something quickly. But if it does not know that the project centralizes constants, it may invent new ones. If it cannot see the existing helpers, it may duplicate them. If token expiration and error-handling rules are not explicit, the endpoint may pass its tests and still introduce real vulnerabilities.

The code works. The system has problems. The difference depends on the judgment of the engineer directing the tool.

The engineer who learned AI

When spreadsheets became common, accountants did not disappear. They gained the ability to do in minutes what had previously taken days. Today, no serious accountant treats spreadsheet fluency as optional.

But spreadsheet fluency is not what separates a good accountant from a mediocre one. A good accountant understands what the formulas are calculating, notices when a number makes no sense, and takes responsibility for the result, not the tool.

The same shift is happening in software engineering. The role is not disappearing. The skill that creates value is changing. Writing code quickly is becoming a baseline capability. Designing the conditions from which correct, maintainable code can be derived (precise specifications, explicit constraints, verifiable acceptance criteria) is becoming the differentiator.

An engineer with sound judgment and AI produces better systems, faster. An engineer without sound judgment produces defective systems faster. AI amplifies what is already there.

Leaders who understand this stop asking only how much an engineer produced. They start asking how easily the result can be understood, maintained, and extended by someone who was not present when the decisions were made.

When output can be generated at industrial speed, that is the question that separates durable value from the appearance of productivity.

‍

Let's talk

How is your engineering team making sure AI accelerates delivery without outsourcing judgment? If you're navigating this shift, let's have a short discovery call. We'll walk through VAIRIX's diagnostic framework (a structured review of five dimensions of AI-assisted delivery: decision traceability, defect detection, architectural memory, behavioral test protection, and review scalability) to identify where AI is helping your team and where it may be creating risks you cannot see yet.

‍