“The agent built exactly what was specified, which is how everyone found out that nobody had specified the right thing”
The Perfect Application Nobody Could Use
A client came to us earlier this year with an application he had built himself. He was not an engineer by trade, he was the person who understood the business better than anyone in the company, and he had done something that would have been impossible eighteen months earlier. He had written a specification, handed it to a coding agent, and iterated until the thing worked. It did work. Every business rule he cared about was implemented correctly. The calculations were right, the domain logic was faithful to how the work actually happens, the edge cases he had spent years learning the hard way were all handled. Judged against his specification, the output was close to flawless.
It was also a Qt desktop application that stored its data in local files on his machine.
What the business needed was a collaborative web application. Multiple people, in different offices, logging in under their own identities, contributing to shared records, seeing each other’s changes, and leaving a trail that could be audited afterwards. The application he had built had none of that. No authentication, because a desktop app run by one person does not need it. No database, because a local file is simpler and the agent had no reason to prefer otherwise. No concurrency model, because there was only ever one user. No history, no attribution, no audit, because nothing in the specification asked for any of it. Two people could not use the software at the same time in any meaningful sense, and there was no way to know who had changed what.
Nobody had made a mistake, which is the unsettling part. The specification described the business correctly. The agent implemented the specification correctly. The failure happened in the space between those two statements, in everything the client knew so deeply that he never thought to write it down. That the work is shared. That people must be accountable for their entries. That the record has to survive the laptop it was created on. That regulators, or auditors, or just a disagreement between two colleagues six months later, will require the system to explain itself.
“The specification captured the business. It did not capture the fact that the business is performed by more than one person.”
Rebuilding it was not a matter of adding features. Authentication, shared persistence, concurrent editing, and an audit trail are not modules you attach to a finished application. They are decisions that shape the architecture from the first commit, and every one of them had already been decided, silently, by the choice of a desktop framework and a local file. The atomic business logic survived the rewrite. Almost nothing else did.
This is the failure mode of the new era in miniature, and it is not a story about a weak model. It is a story about what happens when generation becomes so cheap that the only remaining constraint is the quality of the intent behind it, and the intent is written by someone who has never had to make the implicit explicit.
The Bottleneck Moved and Nobody Rewrote the Process
Something quietly decisive happened to software engineering between 2024 and 2026, and most organisations are still running processes designed for the world before it. The change was not that models got better at writing code. It was that writing code stopped being the constraint.
So the agents are in the pipeline, across design, implementation, review, testing, deployment, and maintenance. The question that matters for leadership is no longer whether they work. It is why the throughput they generate keeps failing to show up as organisational delivery, and what the gap is made of.
The most useful finding of 2026 is also the most awkward. Anthropic calls it the deployment overhang: the autonomy models are capable of handling exceeds what they are permitted to exercise in practice. External evaluations show frontier models completing tasks that run for five hours. The median Claude Code turn lasts forty-five seconds. That is not a capability ceiling. It is a governance ceiling, drawn by humans, in real time, one approval at a time.
“Autonomy is not a property of the model. It is a negotiated settlement between a model, a product, and an organisation’s tolerance for being wrong.”
The user data confirms it. New users run a session on full auto-approve about one time in five. By around 750 sessions, that figure exceeds two in five. Interrupt rates rise too, from five per cent to nine, which tells you the experienced users are not being reckless. They are granting more rope and holding the rope more attentively. Trust here is not credulity, it is calibration, and calibration takes hundreds of repetitions to acquire.
The safety picture is worth stating precisely, because it is widely garbled. In Anthropic’s analysis, roughly 80 per cent of tool calls carry some safeguard, 73 per cent involve a human in some capacity, and only 0.8 per cent are irreversible actions. That 73 per cent is not a measure of how much AI-generated code fails review. It is a measure of how thoroughly humans remain wired into the loop, and the 0.8 per cent tells you where the wiring is deliberately tightest. Irreversibility, not volume, is what organisations actually gate. That instinct is correct, and it is the one design principle from this era worth carrying forward unchanged.
Specification Becomes the Scarce Skill
If generation is cheap and supervision is expensive, the leverage moves upstream to whatever reduces the amount of supervision required. That is the entire economic case for spec-driven development, and it is why a practice that sounded like process bureaucracy in 2023 became the default posture of serious teams by 2026.
The mechanism is simple. An agent that receives a vague instruction produces plausible code that drifts from intent, and the drift is discovered late, in review, where correction is most expensive. An agent that receives a rigorous, machine-interpretable specification produces code that can be judged against something other than the reviewer’s intuition. The specification does not slow the agent down. It relocates the human effort from the end of the cycle, where it is remedial and adversarial, to the beginning, where it is cheap and generative.
A rigorous specification is only as good as the assumptions it is willing to interrogate, and the most dangerous assumptions are the ones held by the person writing it. What that client needed was not a better prompt or a more detailed document. He needed someone in the room to ask how many people would use this, who has to answer for what it says, and where the data lives when the laptop dies. Those three questions are architecture, they are not requirements, and no specification format prompts you to ask them. This is precisely the judgement that agents do not supply and that only accumulated engineering experience does.
What this does to the engineering role is more profound than the tooling suggests. The engineer becomes an editor-in-chief: the person who decides what “correct” means before anything is built, then evaluates rapid output against that definition. This rewards deep domain knowledge and architectural judgement, and it devalues syntax fluency almost completely. It is also, uncomfortably, a senior skill being asked of an increasingly junior-free workforce, which is a problem we will return to.
“The most expensive code an agent can write is the code that is almost right, because almost right passes review.”
Small Teams, Large Dependencies
The organisational answer to all of this, and the one every executive has now heard, is the small team. Gartner projects that 60 per cent of organisations will adopt smaller software engineering teams at scale by 2029, up from 15 per cent in 2026. That is a fourfold shift in three years, and it is the closest thing the industry has to a consensus forecast.
The logic is sound as far as it goes. If agents absorb routine implementation, basic testing, and documentation, the headcount required to ship a given scope falls. Two or three engineers directing a fleet of agents can cover ground that used to need a squad, and the coordination overhead of the smaller unit is dramatically lower.
What the headline obscures is the substrate. A small team producing enterprise-grade software at speed is not a small operation. It is a small team standing on an internal developer platform that somebody else builds and maintains: the pipelines that enforce security scanning, the golden paths that make the compliant choice the easy one, the observability that catches what nobody reviewed, the policy gates that stop an agent from touching production data. Remove that platform and the small team does not become slightly slower, it becomes a liability, because the same agents that generate throughput generate unreviewed surface area.
So the honest version of the small-team thesis is that headcount does not disappear, it migrates. It moves out of feature squads and into platform engineering, where the leverage is now highest and the work is least visible to the business. Organisations that read the Gartner number as a licence to cut without building the substrate first will get the smaller team and none of the output, and they will conclude, wrongly, that the technology underdelivered.
“The human cost of this transition is concentrated, measurable, and falling on people who did nothing to deserve it.”
Brynjolfsson, Chandar, and Chen, working with high-frequency payroll data from ADP, found that early-career workers aged 22 to 25 in AI-exposed occupations experienced relative employment declines of around 16 per cent, while employment for experienced workers in the same occupations held steady. For young software developers specifically, the decline was roughly 20 per cent from late 2022. The adjustment came through employment rather than pay, and it concentrated in occupations where AI automates rather than augments. Software development sits squarely in that category.
The tasks used to train juniors for forty years, the boilerplate, the small bug, the missing unit test, the documentation nobody wanted to write, were precisely the tasks that agents do well and cheaply. The training ground was not attacked, it was made redundant.
Gartner’s warning on this is unusually direct for an analyst firm: organisations that rely on AI to cut junior roles will, by 2028, hollow out their own software engineering talent pipeline. The reasoning is not sentimental. AI can replace junior output. It cannot replace the decade of graduated exposure that turns a junior into someone capable of systems design, threat modelling, and the kind of code review that catches a plausible-looking mistake. Cut the intake now, and the shortage arrives as a shortage of seniors, in an environment where every competitor is bidding for the same shrinking pool.
There is a bitter irony in the arithmetic. The AI-native operating model demands more senior judgement per unit of output than the model it replaced, because somebody has to write the specification, read the diff, and know when the confident answer is wrong. The industry has responded by reducing the flow of people who could eventually supply that judgement. We have increased demand for a skill and defunded its only production process.
The way out is not to preserve junior work that no longer exists. It is to rebuild apprenticeship around the work that does. A junior on a small team in 2026 should be reading agent output rather than producing boilerplate, navigating unfamiliar codebases rather than writing greenfield functions, learning to recognise the shape of a hallucinated dependency, and sitting close enough to senior engineers to absorb how architectural decisions are actually made. That is a harder curriculum than the one it replaces, and it demands more senior time, not less. It is also the only path that does not consume the pipeline it depends on.
What the Next Decade Actually Owes Us
Forecasting in this field has an accuracy problem, so it is worth separating what is already in motion from what is genuinely speculative.
1 Year From Now (2027): Standardization and the Debt Reckoning
- Standardization of Orchestration: At least 55% of software engineering teams will be actively building LLM-based applications and utilizing complex agentic workflows in production. The Model Context Protocol (MCP) and agent-to-agent (A2A) communication standards will become entirely ubiquitous, functioning as the foundational plumbing for all enterprise software. This standardization will eliminate current integration silos, allowing heterogeneous AI agents from different vendors (e.g., an OpenAI reasoning agent and an Anthropic coding agent) to collaborate securely within the same CI/CD pipeline.
- Mainstream Spec-Driven Development: To prevent further unmanageable debt accumulation, Spec-Driven Development will transition from a recommended best practice to an automated, mandated pipeline gate. AI orchestration layers will flatly refuse to generate implementation code unless a verifiable, machine-readable specification is provided, heavily shifting developer effort to the planning phase.
5 Years From Now (2031): Ubiquity of Tiny Teams and Domain-Specific Intelligence
- The Tiny Team Standard: The prediction that 60% of organizations will adopt the “tiny team” structure will be fully realized across the global enterprise landscape. The standard software development unit will consist of 2-3 human orchestrators commanding vast fleets of specialized AI agents. Traditional role silos (frontend, backend, QA) will be largely dissolved, replaced entirely by versatilists focused solely on product outcomes, user experience, and strategic alignment.
- Rise of Domain-Specific Language Models (DSLMs): Generic, all-purpose LLMs will be heavily augmented or entirely replaced by DSLMs rigorously trained and fine-tuned for specific industries (e.g., aerospace engineering, healthcare compliance, high-frequency trading). Gartner predicts that over half of the generative AI models used by enterprises will be domain-specific. These models will offer vastly higher accuracy, strict regulatory compliance out-of-the-box, and near-zero hallucination rates, enabling agents to operate with much higher autonomy in mission-critical environments without constant human supervision.
- Autonomous CI/CD and Self-Healing Systems: The deployment overhang will significantly narrow as human trust in verifiable AI systems solidifies. Humans will step out of the loop for standard maintenance operations, shifting to an “on-the-loop” supervisory role. AI agents will entirely manage CI/CD pipelines, automatically detecting production anomalies, writing patches, testing them in isolated sandboxes, and deploying them to production with zero human intervention for low-to-medium risk systems.
10 Years From Now (2036): Hyper-Autonomous Engineering
- AI Supercomputing and Paradigm Shifts: Software engineering will be underpinned by unified AI supercomputing platforms that seamlessly integrate quantum heuristics, neuromorphic computing, and traditional GPU clusters. This massive, instantaneous compute scaling will allow AI agents to generate, rigorously test, and discard millions of architectural permutations in real-time, mathematically optimizing software designs before a single feature is deployed to production.
- Verifiable-by-Design Architectures: The deep integration of formal verification and LLMs will reach absolute maturity. AI systems will exclusively write code in verification-aware paradigms, ensuring that enterprise software is mathematically proven to be free of runtime errors, security vulnerabilities, and memory leaks prior to execution. “Bugs” as they are currently understood in legacy development will become exceedingly rare; instead, software failures will stem almost entirely from flawed human intent, conflicting business logic, or poorly engineered initial specifications.
- The Engineer as Conductor: The human software engineer of 2036 will operate akin to an executive or a symphony conductor. Their primary daily function will involve high-level strategic decision-making, ethical alignment, managing cross-agent conflicts, defining ultimate business value, and optimizing the FinOps parameters of hyper-autonomous software factories. The entry-level engineering role will be defined not by writing loops or functions, but by one’s ability to audit AI decision-making algorithms, conduct sophisticated threat modeling, and safely manage the non-deterministic behaviors of complex, multi-agent ecologies.
References
- Anthropic (2026). Measuring AI agent autonomy in practice. Anthropic Research, 18 February 2026. https://www.anthropic.com/research/measuring-agent-autonomy
- Tantithamthavorn, C., Zou, Y., Wong, A., Gupta, M., Wang, Z., Buller, M., Jiang, R., Watson, M., Jeong, M., Chen, K., & Wu, M. (2026). RovoDev Code Reviewer: A Large-Scale Online Evaluation of LLM-based Code Review Automation at Atlassian. ICSE’26, Software Engineering in Practice Track. arXiv:2601.01129. https://arxiv.org/abs/2601.01129
- Gartner (2026). Gartner Predicts 60% of Organizations Will Adopt Smaller Software Engineering Teams by 2029. Gartner Newsroom, 7 July 2026. https://www.gartner.com/en/newsroom/press-releases/2026-07-07-gartner-predicts-60-percent-of-organizations-will-adopt-smaller-software-engineering-teams-by-2029
- Gartner (2025). Gartner Identifies the Top Strategic Trends in Software Engineering for 2025 and Beyond. Gartner Newsroom, 1 July 2025. https://www.gartner.com/en/newsroom/press-releases/2025-07-01-gartner-identifies-the-top-strategic-trends-in-software-engineering-for-2025-and-beyond
- Gartner (2025). Gartner Predicts by 2027, Organizations Will Use Small, Task-Specific AI Models Three Times More Than General-Purpose Large Language Models. Gartner Newsroom, 9 April 2025. https://www.gartner.com/en/newsroom/press-releases/2025-04-09-gartner-predicts-by-2027-organizations-will-use-small-task-specific-ai-models-three-times-more-than-general-purpose-large-language-models
- DORA / Google Cloud (2025). State of AI-assisted Software Development Report. 24 September 2025. https://dora.dev/dora-report-2025/
- Google Cloud (2025). Announcing the 2025 DORA Report. Google Cloud Blog, 24 September 2025. https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report
- McKinsey & Company (2026). State of AI trust in 2026: Shifting to the agentic era. McKinsey Tech Forward. https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/tech-forward/state-of-ai-trust-in-2026-shifting-to-the-agentic-era
- GitClear (2026). The Maintainability Gap: 2026 AI Code Quality Research. https://www.gitclear.com/the_ai_code_quality_maintainability_gap
- Brynjolfsson, E., Chandar, B., & Chen, R. (2025). Canaries in the Coal Mine? Six Facts about the Recent Employment Effects of Artificial Intelligence. Stanford Digital Economy Lab, November 2025. https://digitaleconomy.stanford.edu/publication/canaries-in-the-coal-mine-six-facts-about-the-recent-employment-effects-of-artificial-intelligence/
- Stack Overflow (2025). 2025 Developer Survey. https://survey.stackoverflow.co/2025
- Linux Foundation (2026). A2A Protocol Surpasses 150 Organizations, Lands in Major Cloud Platforms, and Sees Enterprise Production Use in First Year. https://www.linuxfoundation.org/press/a2a-protocol-surpasses-150-organizations-lands-in-major-cloud-platforms-and-sees-enterprise-production-use-in-first-year
- Sammler, M. et al. (2026). Harnessing Code Agents for Automatic Software Verification. arXiv:2607.06341. https://arxiv.org/abs/2607.06341
- Agentic Verification of Software Systems (2026). arXiv:2511.17330. https://arxiv.org/abs/2511.17330
