Code used to be the durable asset. In an agentic SDLC, that changes. Code becomes the regeneratable output of a system that runs on something more important: a clear, versioned, reviewable specification. That shift changes what engineering organizations invest in, how they govern delivery, who they hire, and what they actually ship.
$ vinny spec --diff v2.1 v2.2
+ accept partial cancellations
+ enforce 90-day audit retention
- legacy reconciliation path
✓ regenerate · 6 services · 3 languages
// the durable artifact is upstream
Read your team's last sprint backlog. Now read your team's last sprint of merged code. One of those is becoming the more durable asset of your engineering organization, and it may not be the one you think.
For thirty years I have written code, reviewed code, refactored code, audited code, and built organizations around the assumption that code was the thing. The repo was the inventory. The diff was the proof of work. The pull request was the unit of accomplishment. We measured velocity in commits, quality in coverage, and seniority in lines shipped. We sized teams by how much code we expected them to produce.
That whole structure rested on a quiet assumption: turning intent into working software was the hard part.
That assumption is starting to break.
When a competent agent can take a clear, well-scoped specification and produce working, tested, conformant code in minutes, the scarce resource moves upstream. The expensive thing is no longer just the implementation. The expensive thing is knowing exactly what to build, why, for whom, under what constraints, and how to verify it.
The expensive thing is the specification.
So here is the reframe I have been working through, and the one I think every engineering leader needs to sit with: the code is exhaust. The spec is the product.
What "exhaust" means and does not mean
Exhaust is not worthless.
A jet engine produces exhaust. That exhaust is visible evidence that the engine works. It is the byproduct of useful work. Without it, you have no flight. But you do not store exhaust. You do not version it. You do not pay people for the volume of exhaust they produced this quarter.
You measure the engine.
Code in an agentic SDLC is exhaust in that sense. It is the visible, valuable, working output of a system that turned intent into running behavior. It still has to be correct. It still has to pass tests, meet performance budgets, and clear security review. None of that goes away.
But code is becoming less durable than the artifact that produced it.
In the right workflow, code can be regenerated from a better spec, produced in a different language, refactored against a new framework, or reshaped around a stronger platform standard. That does not make code disposable. It makes code downstream.
I have done this. So have a lot of you. The first time you regenerate working, production-quality code from a tight spec and realize the underlying language was almost incidental, something inverts in your head.
The repo stops feeling like inventory.
It starts feeling like a fossil record.
What the spec actually is
When I say "spec," I do not mean a Word document that lives in SharePoint and goes stale by sprint two. We have all seen that movie. It has too many sequels.
I mean a structured, versioned, machine-readable artifact that captures:
- The intended behavior, in terms specific enough to test
- The constraints, including performance, security, compliance, accessibility, data residency, and cost
- The interfaces and contracts
- The decisions and the reasons behind them
- The known risks and open questions
- The verification criteria and acceptance signals
This artifact lives next to the code. It is reviewed before any code is generated. It is the input to every agent in the pipeline, from the one that writes the implementation, to the one that writes the tests, to the one that updates the runbook.
It is what gets diffed across versions.
It is what the security reviewer reads.
It is what the auditor reads.
It is what the next engineer reads when they need to evolve the feature next year.
A payment cancellation feature, for example, is not just "allow the user to cancel." A real spec needs to say whether partial cancellations are allowed, what happens after settlement, what audit events are retained, what downstream systems receive the reversal, what appears in the UI, what customer communications are triggered, and how support teams can explain the outcome.
Once those decisions are explicit, generating the code is still real work. But it is no longer the most ambiguous work.
The ambiguity moved upstream.
I have been calling this artifact the Context Spine. The name matters less than the function. The Context Spine is the artifact that keeps intent from evaporating as work moves from product discussion to agent planning, code generation, testing, documentation, operations, and audit.
Without it, every downstream step has to infer what the last step meant. That is where agentic workflows become expensive, inconsistent, and occasionally very confident about the wrong thing.
A Context Spine makes the pipeline a system instead of a collection of clever prompts.
The implications are not subtle
Once you accept that the spec is becoming the product, several things follow. Most of them are leadership problems, not tooling problems.
Your investment shifts. You invest in the quality of the spec, the discipline around its review, the standards it enforces, and the format it uses. You invest less energy celebrating the boilerplate of the code itself, because more of that boilerplate is regeneratable. You stop celebrating "we wrote 40,000 lines this quarter" and start asking, "Are our specs sharper this quarter than last?"
Your governance shifts. Compliance, audit, and risk review move upstream. You stop auditing only what shipped. You start auditing the spec that produced what shipped. A finding against a spec is fixable earlier, more consistently, and with a cleaner trail of intent. A finding against code often turns into the slow, manual archaeology we all know too well.
Your talent equation shifts. The engineers who thrive in this environment are not the fastest typists. They are the clearest thinkers. They can hold a problem in their head long enough to specify it precisely, anticipate edge cases, and articulate acceptance criteria. That is a senior engineering skill, and it always was. AI just made it more visible.
Engineers who only know how to translate requirements into code are going to feel the pressure first. The bottleneck is moving from implementation speed to clarity of intent.
This is also why the apprenticeship problem is real and underdiscussed.
If junior engineers never learn to write a sharp spec, they will never become the senior engineers we need. The old path ran through writing a lot of code badly, then less code well. The new path may run through writing a lot of imperfect specs, getting them reviewed carefully, and learning how to make them precise, testable, and useful.
That review culture has to exist.
Most organizations do not have it yet.
Your org design shifts. Spec ownership becomes a real question. Is it the product manager? The architect? The engineer? The platform team? The answer will not be one role in most mature organizations.
Product leaders will own customer and business intent. Engineers and architects will own technical feasibility, constraints, and verification. Platform teams will own reusable standards and paved paths. Security, risk, and compliance partners will help define the controls that need to exist before the system generates anything meaningful.
The important shift is that the spec becomes a first-class artifact with explicit owners. It cannot remain a meeting note everyone hopes the team remembers.
Hope is not a great persistence layer.
Your vendor strategy shifts. When code is regeneratable, your lock-in story changes. The argument for choosing GitLab, AWS, Azure, or any other foundational vendor becomes less about "we wrote a million lines against your APIs" and more about "our specs assume your primitives, our pipelines route through your platform, and our standards are encoded in your tooling."
That is a different kind of stickiness.
It is also a different kind of negotiation.
What humans still own
The spec becoming the product does not reduce the need for engineers. It raises the bar for what engineering judgment means.
Humans still own the intent, the trade-offs, the risk decisions, the constraints, and the final accountability. Agents can generate options, produce code, write tests, and compare output to the spec. They cannot decide what trade-off the business should make when correctness, cost, speed, regulatory expectations, and customer experience collide.
That is where senior engineers, architects, product leaders, security partners, and platform teams still matter.
Maybe more than before.
The best engineers in an agentic SDLC will not just ask, "Can the agent build this?" They will ask better questions:
- Is this the right problem to solve?
- What edge cases are we avoiding because they are uncomfortable?
- What constraints are assumed but not written down?
- How will we know the generated work is correct?
That is not less engineering.
That is engineering with the typing separated from the thinking.
The typing was never the hard part for very long.
The objection I hear most
"But the code still has to be right."
Yes. The code has to be right. It has to compile, perform, secure, and behave. None of that is in question.
The point is not that the code stops mattering. The point is that code correctness increasingly becomes a property of the spec plus the verification harness, not just the keystroke quality of the engineer who typed it.
I have watched this distinction get blurred in a lot of executive conversations, so let me sharpen it.
If your team's generated code is wrong, you may not have a code problem. You may have a spec problem, a verification problem, a standards problem, or a review problem. Fixing the code in place may solve the immediate defect, but it is often the least durable response.
Fixing the upstream artifact and regenerating is faster, cleaner, and more consistent across every other piece of work derived from the same source.
This is the inversion many leadership teams have not internalized. Their instinct is still to ask, "Why did the code break?"
The better question is, "What did the spec fail to specify?"
What this means on Monday
If you lead an engineering organization and you take this seriously, three things go on your Monday list.
First, decide what your spec artifact looks like. Pick a format, version it, and put it under source control next to the code it informs or generates. Markdown with structured frontmatter, a YAML schema, a domain-specific format, the choice matters less than the commitment.
Standardize early. Resist the temptation to let every team invent its own.
Second, build a review culture around the spec. Spec review is becoming the new code review. It is where seniority shows up, where standards get enforced, and where the most expensive defects get caught. If your senior engineers are not spending material time in spec review, they may be spending too much time downstream.
Third, change what you measure. Stop treating commits and pull requests as the primary unit of work. Start looking at accepted specifications, review latency, and the time between spec approval and verified delivery.
The new metrics are upstream. The new bottleneck is upstream. The leverage is upstream.
The throughline
This is, in the end, another version of the argument I keep making on this blog. The bottleneck is never really the stack. It was not the stack when we moved to cloud. It was not the stack when we moved to containers. It is not the stack now that we have agents.
The bottleneck has always been clarity of intent, discipline of decision, quality of judgment, and the organizational permission to act on those quickly. AI did not change that. AI just made it harder to hide from.
The spec is the product. The code is exhaust. Your engineering organization is going to ship better, faster, and cheaper not because you found a better stack, but because you finally invested in the artifact that has always mattered most. I have been at this for thirty years, and I have never been more convinced that this reframe matters. I would also love to be wrong, so come find me on LinkedIn and tell me where the argument breaks.
