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 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 30 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, and 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 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've 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 isn't worthless. A jet engine produces exhaust, and that exhaust is visible evidence that the engine works. It's the byproduct of useful work, and without it you have no flight. But you don't store or version exhaust, and you don't pay people for how much of it 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, 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 makes code downstream rather than disposable.
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 and starts feeling like a fossil record.
What the spec is
When I say "spec," I don't mean a Word document that lives in SharePoint and goes stale by sprint two. We've 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's what gets diffed across versions, and what the security reviewer and the auditor read. It's also what the next engineer reads when they need to evolve the feature next year.
A payment cancellation feature, for example, starts life as "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's no longer the most ambiguous work. The ambiguity moved upstream.
I've 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's 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 and start auditing the spec that produced it. 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 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's 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'll 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, and most organizations don't have it yet.
Your org design shifts. Spec ownership becomes a real question. Is it the product manager, the architect, the engineer, or the platform team? The answer won't 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 can't 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's a different kind of stickiness. It's also a different kind of negotiation.
What humans still own
The spec becoming the product 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's where senior engineers, architects, product leaders, security partners, and platform teams still matter. Maybe more than before. "Can the agent build this?" is the easy question. The best engineers in an agentic SDLC spend their time on the ones that take judgment:
- Is this the right problem to solve?
- What edge cases are we avoiding because they're uncomfortable?
- What constraints are assumed but not written down?
- How will we know the generated work is correct?
That's not less engineering. That's 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, and none of that is in question.
The point is that code correctness increasingly becomes a property of the spec plus the verification harness. It depends less on the keystroke quality of the engineer who typed it. I've watched that distinction get blurred in a lot of executive conversations, so let me sharpen it.
If your team's generated code is wrong, the problem may be in the spec, the verification, the standards, or the review, not in the code. Fixing the code in place may solve the immediate defect, but it's 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 haven't internalized. They still debug the code that broke and leave the spec that produced it untouched.
Where I would start
If you lead an engineering organization and you take this seriously, start with three things.
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, and 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's where seniority shows up, where standards get enforced, and where the most expensive defects get caught. If your senior engineers aren't 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 metrics move upstream because the work did.
The spec is the product and the code is exhaust. Your organization will ship better work when you finally invest in the artifact that has always mattered most. A better stack won't do it for you. I would love to be wrong about this, so tell me where the argument breaks.
