When Specs Become the Programming Language
I’m building an assistant — one that goes beyond conversation — and in the process I’ve realized that code is no longer the most important thing I create.
Computers have been a big part of my life since I was very young. It started with the family getting a Commodore 64, and I vividly remember the day my parents brought it home. I was mesmerized. That machine felt magical, and it quietly set the direction for my life.
Later came the Amiga years. I spent a lot of time in the demo scene in the late 80s, writing code close to the metal, counting cycles, worrying about memory layout, squeezing performance out of hardware that was brutally constrained. Back then, writing efficient code wasn’t an aesthetic preference — it was survival.
I grew up believing that real programmers understood what the machine was doing.
I’ve had my share of exciting moments since then. Working on Google Maps for mobile before the modern smartphone was really a thing. Getting the first voice search product to market at Google. Leading product at Siri, and later helping build Google Assistant from the ground up. All of those were thrilling in their own way.
But none of them quite matched the pure exhilaration of getting that C64 as a kid. I honestly thought I’d never feel that again.
And then I started building with agents.
A new kind of “coding”
When people talk about agentic coding, the conversation often gets stuck on tools. Which model. Which IDE. Which plugins. That’s understandable, but it misses the point.
What matters isn’t the tool — it’s the shift in how work gets done.
When you work with agents, you’re no longer just issuing commands and getting outputs. You’re collaborating with a system that can reason, implement, refactor, explain, and iterate. It can take on open-ended tasks and run with them.
That alone is interesting.
But what really matters is what happens next.
We’ve been here before
There’s an analogy I keep coming back to, and it’s one that anyone who’s been around long enough will recognize.
In the early days, we wrote code in machine language. Or very close to it. You had to understand the hardware intimately. Performance mattered. Memory mattered. Every instruction mattered.
Then compilers arrived.
And a certain type of programmer — myself included — frowned upon them. The code they generated was bloated. Inefficient. Wasteful. If you really cared, you wrote assembly.
Of course, we all know how that story ends.
We moved up the stack.
We learned to care deeply about the source code written in higher-level languages, and we stopped caring about the exact instructions emitted by the compiler. Not because they were perfect, but because the compiler got better — and eventually much better than any human at that layer.
The abstraction won.
The same shift is happening again
When people criticize agent-generated code today, I hear the same arguments I heard decades ago:
“I wouldn’t have written it this way.”
“This is inefficient.”
“This feels messy.”
“I don’t trust what it’s doing.”
And often, they’re right.
But they’re also focusing on the wrong thing.
The new “source code” is no longer Python, C++, or JavaScript.
It’s the specification.
The specs are what you should care about now. They encode intent, constraints, trade-offs, and structure. The code is an artifact generated downstream — just like assembly was an artifact of C, and machine code was an artifact of assembly.
Once you see this, a lot of things snap into focus.
Why this feels so different
This is not just a productivity improvement. It’s not “coding, but faster.”
It’s a fundamentally different way of developing software.
When you work this way, the bottleneck shifts. Execution is cheap. Iteration is cheap. Rewrites are cheap. What’s expensive is clarity of thought.
If your thinking is sloppy, the agent will faithfully scale that sloppiness. If your intent is vague, it will amplify the ambiguity. If your assumptions are wrong, they’ll show up everywhere.
Agents amplify everything.
That’s both the magic and the danger.
What this means for how you work
Once specs become the primary programming artifact, your role changes.
You spend less time typing code and more time:
thinking through edge cases,
making trade-offs explicit,
deciding what matters and what doesn’t,
and correcting course when reality diverges from intent.
This can feel uncomfortable at first, especially if your identity is tied to being a strong individual contributor at the code level. It certainly did for me.
But it’s also where the leverage is.
The quality of what you build is now dominated by the quality of the specifications you write, not the keystrokes you produce.
This is just the beginning
Every major shift in how we build software has looked like cheating at first.
Compilers felt like cheating. Garbage collection felt like cheating. High-level languages felt like cheating.
Building with agents feels the same way — right up until you realize that the rules have changed, and the old instincts don’t apply anymore.
In the next part, I’ll dig into what it takes to build real products in this new model — and why treating agents like faster interns is the fastest way to miss what’s actually happening here.