First published on LinkedIn, 19 January 2026. Reproduced here as the root of everything that followed.
For most of the history of software engineering, code was the primary artifact.
We wrote it. We read it. We maintained it. We owned it.
Understanding a system meant understanding its code.
That assumption is starting to break.
Not because code disappears — but because it is no longer where most intent, responsibility, or value actually lives.
Code as an intermediate artifact
We’ve been here before.
Most engineers no longer inspect assembly output. Almost no one reasons about JVM bytecode or machine instructions.
Once compilers and runtimes became reliable enough, responsibility shifted upward. We stopped validating how instructions were produced and focused on whether the resulting behaviour matched expectations.
Ownership didn’t disappear. It moved up the abstraction stack.
AI-generated code follows the same trajectory. The code itself increasingly becomes an intermediate artifact — a compilation target of something else.
From writing code to describing intent
As generation improves, the center of gravity shifts.
Less time is spent deciding how an algorithm should be expressed line by line. More time is spent deciding what the system should do, under which conditions, and with which guarantees.
The primary activity becomes:
- describing intent precisely
- defining constraints and invariants
- specifying acceptable behaviour
- outlining failure modes and boundaries
In this model, changing a system doesn’t start with editing code.
It starts with modifying the specification.
If the outcome is wrong, we don’t “fix the code” — we correct the description of what should exist.
Why “vibe coding” doesn’t scale
This also clarifies the role of intuition-driven coding.
“Vibe coding” can be useful as exploration — like sketching with a pen or brushing paint onto a canvas. Sometimes it works. Occasionally, it even produces something great.
But professional software work assumes scale.
And intuition, inspiration, and improvisation do not scale well. They don’t:
- transfer cleanly between people
- survive time and turnover
- support repeatability
- provide stable guarantees
Specifications do.
Validation does.
That’s the difference between experimentation and engineering.
Validation becomes the core skill
As code generation becomes cheaper, validation becomes more valuable.
The hard problem is no longer producing output — it’s verifying correctness, safety, and alignment with intent.
This pushes responsibility toward:
- test systems
- contracts and invariants
- property-based validation
- formal and semi-formal requirement languages
- system-level observability
In other words, toward proof, not production.
The question shifts from:
“How was this implemented?”
to:
“Under which conditions is this guaranteed to behave correctly?”
What happens to programmers?
Programmers don’t disappear. But their role changes.
They become:
- authors of specifications
- designers of validation systems
- curators of constraints
- architects of intent
Understanding algorithms still matters — just as understanding assembly still matters for compiler engineers. But most professionals no longer live at that layer.
The expertise moves upward, not away.
Responsibility doesn’t vanish — it migrates
This is the critical point often missed in AI debates.
Responsibility does not disappear when code is generated. It migrates.
From:
- lines of code
to:
- specifications
- guarantees
- validation logic
- system boundaries
The question is no longer:
“Who owns this code?”
But:
“Who owns the specification — and the proof that reality matches it?”
Closing
We are watching programming undergo another abstraction shift.
Code remains necessary. But it is no longer sufficient.
The future of software engineering is less about writing instructions and more about defining intent — and proving that systems behave accordingly.
Programming isn’t dying.
It’s changing what it means to be precise.
The question this closes on got its answer seven months later: Who Owns the Proof.