By aiiqlabs.dev · August 2026
There is an old, wise warning usually attributed to a schoolteacher rather than a scientist: science is a good servant, but a bad master. It is a warning about what happens when we let our methods outrun our judgment. Today, as artificial intelligence sweeps through the software industry, we are witnessing exactly what happens when the servant is promoted to run the house.
Software development is undergoing a double shift: a quiet financial reality is colliding with a profound cultural transformation. On one hand, the cost of AI-assisted development has evolved from a negligible rounding error into a major, high-visibility line item. On the other hand, a class of decision-makers—many of whom left active coding years ago—have experienced a deeply personal "epiphany" with AI tools, and are translating that individual delight into sweeping engineering policies. The result is a strange, modern paradox: development is becoming more expensive, codebases are growing more fragile, yet everyone involved is thoroughly convinced they are saving money.
The Epiphany on Monday Morning
To understand how we got here, we must look at a person who represents a growing archetype in modern tech leadership. Let's call him the Delivery Head.
Back in 2009, he was a decent Java developer. Since 2014, however, his career has been defined by spreadsheets, steering committees, and delivery management; he hasn't opened an integrated development environment (IDE) "in anger" for over a decade. This past spring, he connected an AI assistant to his team's workflow. It was mesmerizing: the tool summarised complex sprint statuses, drafted his weekly updates, and turned his rough bullet points into polished slides. For the first time in years, he felt the direct thrill of creation again.
One weekend, using a modern vibe-coding product, he set out to build a small internal dashboard to track ticket ageing. It worked on the very first try.
On Monday morning, he proudly displayed his creation to the core engineering team. With genuine curiosity and no malice, he posed the question that captures the entire modern industry disconnect in a single sentence:
"I did this in two hours. Why is it taking us six weeks to deliver the payment reconciliation service?"
He was entirely correct that the AI built his dashboard in two hours. But he was fundamentally wrong about what that proved.
His weekend dashboard was built for a single user. It reads a single API, handles no concurrent traffic, processes no real currency, and carries zero auditing requirements. There is no upstream team that will break its schema next quarter, and nobody will be paged in the middle of the night if it crashes.
The payment reconciliation service has to handle every single one of those constraints.
The AI model is equally fluent at generating the code for both. The difference—the weeks of painstaking work—lies in what happens after the code is generated: the rigorous testing, the security hardening, the edge-case management, and the architectural planning. This is the invisible work of the software craftsman, the part the manager has not had to do himself.
The barrier isn't the quality of the models; it is that generic tools which delight individuals stall when confronted with the gritty, high-stakes reality of complex enterprise workflows. A tool that makes a manager feel like an engineer again is not the same as a tool that makes enterprise engineering cheaper. The feeling is real; the accounting is not.
The Reality of "Any Engineer"
When a leader mistakes personal prototyping for enterprise-grade throughput, the next strategic move is highly predictable: if AI can write a dashboard in a weekend, then surely any mid-level developer armed with an agent can build complex enterprise services. The headcount spreadsheets are redrawn. Senior developers, with their high salaries and cautious timelines, begin to look like unnecessary expenses; junior developers with AI subscriptions are viewed as the cost-effective future.
This is currently the most expensive delusion in the software industry, and the empirical evidence against it is overwhelming.
In early 2025, the research organisation METR conducted a randomised controlled trial of experienced open-source developers tackling 246 real-world engineering tasks. The engineers predicted that using AI would speed them up by 24%. In reality, when allowed to use AI, they took 19% longer to complete the tasks. Even after experiencing this slow-down firsthand, many still reported feeling faster.1

The gain on complex, unfamiliar engineering problems is often close to zero, but the illusion of speed is so intoxicating that no one notices they are running in place.
Meanwhile, beneath the surface of the green test suites, the structural integrity of our codebases is quietly deteriorating:
- Duplication and Churn: An analysis by GitClear of 211 million changed lines of code revealed that 2024 was the first year on record where copy-pasted code exceeded refactored code. Duplicate blocks rose eightfold, creating an enormous mountain of future technical debt. Furthermore, "code churn"—lines of code rewritten or deleted within just two weeks of being written—has doubled. Organizations are routinely paying to write code, and then paying again to rewrite it two weeks later.2
- The Security Gap: Veracode tested more than 100 AI models across 80 diverse coding tasks. They found that AI-generated code introduced OWASP Top 10 security vulnerabilities 45% of the time (with Java performing the worst, failing over 70% of the time). Crucially, while model updates have driven syntax compilation pass rates from 50% up to an impressive 95%, security pass rates have remained entirely flat between 45% and 55%.3
- The Debugging Tax: In Stack Overflow's 2025 developer survey, while adoption of AI coding tools topped 84%, trust in their accuracy remained below 33%. A striking 66% of developers reported that dealing with "almost right" AI output actually costs them more debugging time than writing the code from scratch.4

The models have become exceptionally good at writing code that compiles beautifully, but they have not gotten any better at making that code safe. The entity that catches these silent flaws is a human being with the deep experience to know what to look for—and "any engineer" is, by definition, not that person.
A Tale of Two Contexts: The Payments Migration
Consider another composite story that plays out in engineering organisations globally.
A mid-sized product company faced intense pressure from its board of directors to cut costs and "do more with AI". The company needed to execute a complex payments migration, moving from Stripe to a multi-provider setup. The senior engineer on the team carefully evaluated the architectural dependencies and quoted a timeline management considered too slow.
Sensing an opportunity to prove the power of AI, management bypassed the senior engineer. Instead, they assigned two mid-level developers to the task, handing them state-of-the-art coding agents.
Initially, the results looked like a miracle of modern efficiency. Within weeks the agents had generated thousands of lines of code. Every unit test ran green, and the AI-authored commit messages were beautifully articulated. Management celebrated a massive win.
Then the refunds started going wrong.
A critical refund reconciliation job began double-counting transactions in production. The system's idempotency key handling—the vital safeguard that ensures a transaction is processed exactly once—had been generated in three slightly different, incompatible ways across three different payment provider adapters. Because the mid-level developers had run the agents in separate sessions with entirely fresh contexts, the AI had no global awareness of the systemic pattern. And because none of the developers on the team had ever written deep idempotency logic from scratch before, nobody recognized the subtle, structural flaw during the code review.
With money leaking in production, the celebrating stopped. The company was forced to bring the senior engineer back—this time on an expensive contractor rate—to halt the bleeding and untangle the web of generated code.

The migration ultimately took considerably longer than the estimate that had been rejected as too slow. The total cost to the company was the senior engineer's premium contractor rate, the salaries of the two mid-level engineers, the API token bill, and the direct financial loss of the double-counted refunds.
This is the "inverted arithmetic" of unguided AI development.
Right Tools, Right Hands
None of this is an argument for discarding AI in software engineering. When used as a servant rather than a master, these tools can feel close to miraculous. They are exceptional at generating repetitive boilerplate, navigating unfamiliar API surfaces, spinning up test scaffolding, or creating throwaway prototypes. Used that way, by people who can tell good output from bad, they genuinely help.
But that productivity gain only accrues to people who already know what good looks like.
The ancient proverb holds true: the right tool in the right hands does wonders. A monkey with a heavy coconut can only do damage, and the coconut is not to blame. The fundamental skill that AI rewards is the critical judgment required to know when its output is wrong—and that specific skill is exactly what is deleted when organizations attempt to replace senior expertise with automated agents.
The Bill in the Mail
For those who hold the checkbook and sign off on engineering budgets, the actual cost of AI-driven development must be tallied honestly.

1. The Token Bill: Consumption-priced, uncapped agentic loops mean the bill scales with how hard the tools are driven, not with headcount — and the frontier models cost many times what the lighter ones do for the same number of sessions.
2. The Review Cost: Either senior engineers must spend valuable hours thoroughly auditing every line of AI-generated code, or nobody reviews it and you pay the price in production.
3. The Rework and Debt: Churn has doubled, and code duplication has reached record highs, leaving an expensive trail of technical debt that must be serviced in future quarters.
4. The Remediation Cost: Fixing the security vulnerabilities that models fail to catch roughly half the time.
5. The Contractor Premium: Rehired senior talent brought back to fix what the "any engineer" strategy broke.
When we add these hidden costs together, the math flips. The senior engineer who uses an AI agent to automate the 40% of their work that is mechanical—while meticulously reading and verifying every single line of the remaining 60%—is the most cost-effective option available. The manager with a weekend dashboard, two juniors with a blank token check, and a critical transaction service is the most expensive mistake a company can make.
If you are the one signing off on these budgets, protect your organization with three guiding principles.
Principle 01
Measure outcomes, not activity
Principle 02
Put budgets where the judgment is
Principle 03
Separate the dashboard from the service
Science is a magnificent servant, but a catastrophic master. The bill for letting it run your engineering department is already in the mail, and it is addressed directly to you.
Sources
- METR, randomised controlled trial of experienced open-source developers on 246 real tasks, July 2025. source
- GitClear, “AI Copilot Code Quality”, 2025 — analysis of 211 million changed lines of code. source
- Veracode, GenAI code security testing across 100+ models and 80 coding tasks. source
- Stack Overflow Developer Survey 2025 — AI tool adoption, trust, and debugging time. source
Disclaimer
This article is an editorial opinion piece about engineering management and cost. It is not financial, investment, procurement, legal or employment advice, and nothing in it is a recommendation to adopt, avoid, or discontinue any product, vendor or staffing arrangement. Decisions about tooling budgets and team composition should be made against your own systems, contracts and risk position.
"The Delivery Head" and the payments migration are composites, written to illustrate a pattern the author has observed across organisations. They are not accounts of any real company, team or individual, and any resemblance to a specific engagement is incidental. They are told without figures on purpose: nothing in them is a measurement, and they should not be read as one.
Findings are quoted as reported by their publishers and have not been independently verified by us: METR’s randomised controlled trial of experienced open-source developers; GitClear’s analysis of 211 million changed lines; Veracode’s GenAI code security testing; and the Stack Overflow Developer Survey 2025. These studies differ in method, sample, time period and definition of "productivity", so their numbers are not directly comparable with one another and should not be summed or averaged. This research area moves quickly — check the current state of each before acting on it.
Product and company names — Stripe, Java, OWASP, and the tools and vendors named above — are the trademarks of their respective owners, used here descriptively. Their mention is neither an endorsement by us of them, nor by them of us, and implies no affiliation.