A developer just shipped a feature that passes every test, clears code review, and does exactly the wrong thing.

The code is clean. The logic is sound. The defect is that nobody at the keyboard understood the business rule the feature was supposed to enforce, so the software now enforces a rule that doesn’t exist.

I have watched this happen for years as an enterprise architect in financial services. It was always the expensive kind of failure. What changed is that AI removed the one excuse that used to hide it. Writing the code was hard, so we forgave people for not knowing why they were writing it.

The business was always the programming language. The AI just made that impossible to hide.

The Constraint Moved, and Most People Missed It

Here is the number that should reframe how you think about your job. Developers spend roughly 14 percent of their time actually writing code. That figure comes from a 2025 study of more than 450 Microsoft engineers, published in ACM Queue as Eight Myths on Software Engineering and GenAI. The other 85 percent is design, review, debugging, meetings, and integration. It is the work of figuring out what to build and whether it is right.

Sit with what that means for AI. A tool that doubles your coding speed improves your total output by a sliver, because it accelerates the 14 percent that was never the bottleneck. The paper’s authors say it plainly: faster code generation without workflow redesign just moves the bottleneck downstream, into review and testing.

The scarce skill was never typing. I made that case about the code itself in The Bottleneck Was Never the Code. The AI-era version is sharper. When generation is cheap, the residual constraint is knowing what to generate, and that is domain knowledge. It does not come out of a model.

Teams feel this already. Headcount is contracting as gen-AI absorbs the mechanical work, and the engineers who remain each own more surface area. Fewer people, more judgment per person. The developer who only knew how to type is the one whose seat quietly disappears.

The Defects Were Never in the Code

Software people love to believe that bugs live in the code. Most of them don’t.

The research on this is old and stubbornly consistent. A widely cited analysis by Donald Firesmith found that roughly 50 percent of defects and 80 percent of rework effort trace back to poor requirements: requirements that were ambiguous, incomplete, or simply wrong about how the business actually works. The Standish Group’s CHAOS research has said the same thing for three decades. Incomplete requirements and lack of user involvement sit at the very top of why projects fail, and user involvement is the single largest factor behind the ones that succeed.

Read those two findings together. The largest source of defective software is not bad engineering. It is engineering that faithfully implemented a misunderstanding of the domain. The code compiled. The developer just didn’t understand what the business needed, so they built the wrong thing correctly.

A defect is usually a domain gap wearing a technical costume. The null-pointer exception is real, but the deeper failure is the requirement the developer never understood well enough to question.

The Cost Compounds the Later You Catch It

The reason this matters more in an enterprise than in a weekend project is arithmetic.

A misunderstanding caught in a conversation with the business costs a sentence. Caught in code review, it costs a rewrite. Caught in QA, it costs a cycle. Caught in production, it can cost 50 to 200 times more than catching it early, and rework alone already consumes around half of a typical development budget. A requirements defect that first surfaces in integration testing can run as much as 78 times the cost of catching it up front.

Now add the regulated dimension. In banking, healthcare, and government, a domain-blind defect is not a bug ticket. It is a compliance finding, an audit exception, a customer made whole at the company’s expense. The code that misunderstands a disclosure rule or a data-retention requirement doesn’t crash. It ships, runs clean for months, and matures into a liability with interest.

Domain ignorance is the most expensive bug class in software, and it is the only one your linter can’t see.

AI Amplifies Whoever Is Driving

An AI agent is the most literal collaborator you will ever have. It executes your intent faithfully, at speed, without ever asking whether your intent made sense. Point a domain-blind prompt at it and you get fast, confident, wrong code at a scale no junior developer could have produced by hand.

Here is the same task, handed to the same model, by two different developers.

The domain-blind prompt:

• “Add a function to calculate the interest owed on an overdue account.”

The domain-fluent spec:

• Calculate interest on a past-due consumer account.
• Use a 365-day year with simple daily accrual on principal only, not compounded, matching the account’s disclosed terms.
• Stop accrual the day the account is charged off, and do not accrue on accounts under active dispute.
• Cap the rate at the lower of the contractual rate and the usury ceiling for the account’s billing-address state.
• Round half-to-even at the cent, and emit an audit record for every rate applied.

Same model. Same five minutes. The first produces plausible code that will compute incorrect balances, ignore charge-off and dispute states, and quietly breach a usury cap. The second produces code you can defend to an examiner.

The model did not know any of that. The developer did, or didn’t. Every one of those lines is a business rule, not a coding technique. This is the mechanism behind what I called Judgment Is the New Moat: when the model is a commodity, the person supplying the judgment is the entire value. A prompt is only ever as smart as the domain knowledge standing behind it.

And the trend line is not comforting. GitClear’s analysis of hundreds of millions of lines of code found thoughtfully refactored code collapsing from 21 percent of changes in 2022 to under 4 percent by 2026, while copy-pasted code climbed past 15 percent. More volume, less understanding. That is exactly what you would expect when the typing gets cheap and the thinking doesn’t keep pace.

Build Domain Fluency on Purpose

So the differentiator is domain knowledge. The real question is how you build it, on a team, as a deliberate practice rather than an accident of tenure.

Sit with the business, not just the backlog. The people who own the domain rarely write tickets that contain the domain. They write “add the interest calculation” and assume you know the rest, because to them it is obvious. Go get the obvious. Read the regulation, the contract, the policy the feature encodes. Ask the question that feels too basic to ask.

Write the acceptance criteria before you write the prompt. In an AI-assisted SDLC, the spec is the source code. The model turns your specification into implementation faithfully, which means every gap in your spec becomes a gap in the software. The discipline that used to live in careful coding now has to live in careful specification. I made this argument in Documentation Is the Code Now: the artifact that captures intent is the one that matters.

Make domain review a gate, not a courtesy. Code review catches whether the code is good. It rarely catches whether the code is right, because the reviewer usually shares the author’s blind spot about the business. Put someone who owns the domain in the path before the code merges. In a regulated shop that is not process overhead. It is the cheapest point on the entire cost curve to catch a misunderstanding.

Treat the shrinking team as an advantage. The Bank Got Dumber even as its individual people got smarter, because institutional domain knowledge lived in headcount that kept turning over. A smaller team, each member closer to the business, is a better operating model than a large team held at arm’s length from it. Fewer hands, more context per hand. That is the version of the AI-assisted SDLC actually worth building toward.

The Part Nobody Wants to Hear

I’ll be honest about why this is hard, because pretending it’s easy is how we got here.

Domain fluency is slow. It is unglamorous. You build it in meetings engineers are trained to resent, reading documents that are genuinely boring, asking questions that make you feel junior. It does not demo well. There is no green checkmark for “understood the business.”

And the industry still rewards the wrong thing. We hire on algorithmic puzzles and system-design theater, then act surprised when people optimize for exactly that and treat the domain as beneath them. I have sat across from brilliant engineers who could invert any binary tree you handed them and could not tell you what a charge-off is, on a team whose entire purpose was consumer lending. The correlation with the quality of what they shipped was not subtle.

Not every developer wants this. Some just want the puzzle. That is a legitimate preference, and it is also, increasingly, a career-limiting one. The puzzle is the part the machine now does.

The Language Worth Learning

We spent a generation telling developers that the language they chose barely mattered, that a good engineer could pick up any syntax in a weekend. That was always true, and it was always beside the point.

The language that mattered was never Java or Python or TypeScript. It was the business: the rules, the constraints, the reasons a thing has to work the way it does. Fluency in that language is what separated the developer who shipped software the enterprise could trust from the one who shipped expensive, confident mistakes.

AI didn’t change that. It just removed the last place to hide. When the model writes the code, the only thing you bring is your understanding of what the code is for. Learn the business. It is the one language the model cannot learn for you.

---

Companion piece: Judgment Is the New Moat makes the broader case that in a world of commodity models, the human judgment behind the prompt is the whole game.

If you’re building in the enterprise and watching this shift up close, I’d like to hear how your team is handling it. Find me on X or LinkedIn.