đź”— Originally published on LinkedIn
For most of the last two decades, software delivery has been organised around our capacity to comprehend, organise and manage it. Humans write the code. Everything else exists to support that fact.
Requirements are broken down so humans can digest them. User stories are sized so humans can implement them. Code reviews exist because humans make mistakes. Testing exists because humans miss edge cases. Delivery timelines are long because humans are slow at turning complex ideas into reliable systems.
But all of this is beginning to change. If humans are not the ones writing the code, then a process that was built to support humans writing the code is probably not the right process.
What we are seeing is not just better tooling or developers who are able to write code faster. We are watching the centre of gravity in software delivery shift away from code production and toward system definition, intent articulation, and outcome orchestration.
An uncomfortable truth for many organisations is that if your SDLC still assumes software engineers write code, you are optimising the wrong constraint.
Agents execute relentlessly within the bounds they are given. Humans focus on whether those bounds are correct.
What a difference a year makes. in 2026 coding agents and CLI-driven AI tools are no longer a suspect novelty. They are becoming competent, repeatable producers of valid, idiomatic, production-grade code. They can scaffold systems, generate tests, wire integrations, refactor aggressively, and do so with a consistency that already rivals mid-level developers.
Over the last year they have proven got better and become more capable. To think there wont be another quantum leap by 2027 is contrarian at this point. The bottleneck has moved.
The limiting factor is no longer how fast code can be written and pieced together, but how clearly a system can be specified, constrained, and reasoned about. The hard work is deciding what should exist, how it should behave, how it should fail, and how it fits together as part of a wider system.
This is why so many teams feel simultaneously excited and uneasy. The output speed is intoxicating, but the lack of structure feels dangerous. Code appears faster than it is possible to understand it. Systems grow before intent is stable. Risk feels amplified, not reduced.
The instinctive response is to tighten controls around the old SDLC. More reviews. More gates. More process. That path leads to frustration and stagnation. The alternative is to accept what is actually happening and redesign the SDLC around it.
Specification-driven development never really disappeared. It just became unfashionable.
Heavyweight specs failed because they were written for humans who then had to translate them into code. That translation step was slow, lossy, and expensive. Agile did not kill specification because it was wrong. It killed it because the cost of fidelity was too high.
That cost has collapsed.
When the primary consumer of a specification is no longer a human developer but a set of coding agents, the economics change completely. Precision becomes an asset, not a burden. Explicitness accelerates rather than slows delivery. Consistency is enforced mechanically rather than, or as well as, socially. This is the inflection point many CTOs are only just starting to notice.
We are not moving toward prompt-driven development. We are moving toward spec-driven systems, where prompts are the execution interface. i.e The prompts create or iterate the the spec, and the spec is used to generate the code.
In this world, specifications are not static documents. They are living system descriptions that define behaviour, constraints, architecture, security posture, and quality expectations. They are structured enough to be machine-interpretable, yet readable enough for senior engineers to reason about.
Once that scaffolding exists, coding agents become extraordinarily powerful.
When code generation is abundant, teams do not scale the way they used to.
The most effective delivery unit in the agentic era is not a full time team of narrowly scoped specialists. It is a small number of systems-level engineers who can hold an entire problem space in their heads and orchestrate agents to do the mechanical work. These engineers are not “10x developers”. They are something else entirely.
They think in terms of systems, not tasks or tickets. They reason about data flows, failure modes, trust boundaries, and evolution paths. They understand enough about infrastructure, security, performance, and product to make coherent trade-offs. They use agents as collaborators, not as a replacement for auto-complete or stack overflow. This is why traditional role definitions start to break down.
The distinction between backend, frontend, and platform becomes less relevant when one person can shape the whole system. The boundary between architect and engineer blurs when architecture is continuously expressed through executable specification. Even the concept of “implementation” starts to feel outdated.
The job becomes one of intent articulation and system stewardship.
The biggest mistake organisations will make is trying to graft AI tools onto an SDLC designed for human coding. That approach produces friction everywhere. Stories become too small to be meaningful. Reviews become performative. Estimation collapses. Developers feel either overwhelmed or underutilised.
A genuinely agentic SDLC looks different from the start.
It begins with system definition rather than backlog decomposition. It treats specification as the primary design activity. It assumes code will be generated, regenerated, and refactored frequently, so it anchors stability in constraints rather than implementations.
In this model, work is framed as outcomes and capabilities, not tasks. Quality gates move earlier, embedded into the spec and the agent workflows themselves. Security, compliance, and performance are expressed declaratively and enforced continuously through generation, validation, and testing loops.
This is where many software businesses could go wrong. Changing up the SDLC is not primarily a tooling problem. It is a thinking problem.
The differentiation shifts from “how fast can we build” to “how well do we understand the system we are building”.
As agents absorb more of the mechanical workload, the value of systems thinking rises sharply.
Systems thinking is not about drawing boxes and arrows. It is about understanding trade offs and the system wide impact of design decisions. How local optimisations can introduce global fragility. How systems work together. How systems behave when they fail.
In a world where a single engineer can generate an entire application in days, the risk is not under-delivery. It is naivety, accidental complexity or unexamined assumptions solidifying into production systems.
This is why seniority matters more now, not less. And this is going to be really uncomfortable for the industry and the workplace as a whole.
Junior engineers who were previously productive through repetition may struggle when the work shifts toward framing problems rather than executing solutions. Conversely, experienced engineers who have scars from failed rewrites, security incidents, and scaling pain often thrive, even if they write far less code themselves.
The implication is that not every developer role survives unchanged. Organisations will need fewer people writing code and more people capable of owning whole systems. That transition is as much cultural as it is technical.
What makes spec-driven development the natural scaffolding for the agentic era is coordination.
Specifications become the shared language between humans, agents, and the organisation itself. They encode decisions, trade-offs, and intent in a way that is inspectable and revisable. They provide continuity even as implementations change rapidly.
When done well, a spec-centric SDLC offers something teams have struggled with for years. Speed and confidence at the same time.
Agents execute relentlessly within the bounds they are given. Humans focus on whether those bounds are correct.
We spend less time worrying about the implementation time and more time worrying about whether the system has been framed well enough. That is a healthier concern.
The question is not whether this shift will happen. It is already happening in pockets across the industry. The real question is whether your organisation is structured to benefit from it.
CTOs who are serious about this transition should be asking themselves different questions than they did even two years ago.
Are our delivery processes optimised for thinking or for typing? Do we reward people for system ownership, or for localised output? Is specification treated as a living artefact, or as a preamble to “real work”? Can our best engineers describe entire systems clearly enough that an agent could build them? Do our quality, security, and compliance controls assume human fallibility, or do they assume agent-scale mis-interpretation?
These are not rhetorical questions. They point directly at the shape of the organisation you are becoming.
If you follow the trajectory honestly, the end state is not hard to see.
Software delivery teams become smaller, more senior, and more outcome-oriented. Specifications become executable system descriptions rather than static documents. Coding agents become the default production engine. Human effort concentrates on intent, architecture, and judgement.
Delivery cycles compress from months to weeks, sometimes days. The differentiation shifts from “how fast can we build” to “how well do we understand the system we are building”.
Spec-driven development is the missing layer that makes the agentic era coherent. The organisations who recognise this early will not simply move faster. They will move with more confidence, less waste, and fewer existential rewrites.
The ones who do not will find themselves surrounded by impressive demos, rising delivery risk, and teams who feel increasingly disconnected from the work they are doing.
👉 What is Agentic Computing?
This article was originally written and published on LinkedIn by Kevin Smith, CTO and founder of Dootrix.