I spent the morning reviewing materials for an internal training course. Twenty-six dense pages, full of workflows, commands, checklists. At one point I stopped and looked out the window. I asked myself: when did all of this happen?
A year ago we were still debating whether or not to use Copilot for autocomplete. Today we write documents called “Constitutions” that govern the behaviour of AI agents that generate entire features. The jump wasn’t gradual. It was like waking up one morning and discovering the floor had shifted a few centimetres during the night.
Vibe coding and its seduction
There’s a term that struck me while I was preparing the material: vibe coding. Vaguely describe what you want and let the AI produce something. We all did it, in the first months. There was something almost magical about seeing code appear out of nothing from a rough description. Did it work? Sometimes yes, often no. But the sense of speed was intoxicating.
The problem is that the speed was an illusion. Code generated that way, without precise specs, without thought-through architecture, was accumulating technical debt at an impressive rate. Every feature added was a bet. Maybe it works today; maybe tomorrow everything breaks when someone touches something else.
I’ve watched POCs launch like rockets and crash within a few weeks. Not because the AI got it wrong, but because no one had thought about what we were building. We were improvising with an extremely powerful instrument without a score.
The spec as a new form of expression
The answer we’re exploring, and trying to teach in the course, completely flips the approach. It’s called spec-driven development and the underlying idea is simple, almost banal: first you write what you want with maniacal precision, then you let someone else (in this case, an AI agent) implement it.
But there’s an aspect that fascinates and disturbs me at once. Writing precise specs is tremendously hard. It requires thinking through every edge case, every error scenario, every possible ambiguity. It requires knowing exactly what you want before you’ve seen it work.
In a sense, it’s the opposite of how many of us learned to program. I learned by experimenting, trying, failing, correcting. A continuous loop of trial and error that eventually produced something that worked. Now we’re being asked to think everything through up front, to be precise before writing a single line of code.
I’m not sure it’s a purely positive change. We probably lose something in the experimentation, in the accidental discovery of elegant solutions that emerge while you write. But we maybe gain something else: the chance to build systems bigger and more complex than we could have built alone.
The skills paradox
One thing that has made me think a lot is the skills paradox emerging from this new way of working. In the document I prepared there’s a sentence I underlined more than once:
This doesn’t mean technical skills become obsolete. The opposite—even more solid skills are required.
It sounds counter-intuitive. If AI writes the code, why should I know how to program? The answer is that you have to know how to program better than before to tell whether what the AI produced makes sense. To validate the architecture. To spot security issues. To know when something is a fragile workaround masquerading as an elegant solution.
I’ve watched juniors get excited about AI-generated code without realising it contained serious vulnerabilities. Unparameterised queries, missing validations, hardcoded secrets. The AI had copied insecure patterns it saw in training data. Someone with experience was needed to notice.
In a way, we’re becoming full-time reviewers. Our work is shifting from production to supervision, from writing to critical reading. I don’t know whether that’s a loss or a gain. Maybe both.
The Constitution and the illusion of control
In the framework we’re adopting there’s a central concept: the Constitution. It’s a document that defines the project’s immutable principles. Things like “no any types allowed” or “minimum 80% coverage” or “every PR requires a human code review”. The idea is that the AI must respect these principles in every decision.
Does it work? Largely yes. The AI follows the rules when you give them clearly. But there’s something slightly ironic about all this. We’re writing constitutions for machines. Defining laws that algorithms must follow. It’s an interesting inversion of the relationship between humans and tools.
What I wonder, and don’t yet have an answer to, is how far written rules can capture what we actually mean. I can write “no workarounds or hacks in the code” but how do I define exactly what a hack is? Sometimes the line between a pragmatic solution and a hack is blurry, contextual, requires judgement. That judgement, for now, stays human.
The time that isn’t there anymore
One thing that has changed subtly but deeply is the relationship with time. Before, when I estimated how long a feature would take to implement, I thought in hours or days of work. Now I think in terms of how much time I need to write a precise enough spec and to validate the output.
Paradoxically, sometimes it takes longer. Writing a complete spec, clarifying every ambiguity, defining every edge case can take as long as I would have spent writing the code. But the kind of work is different. It’s more mental, more abstract. Fewer hours staring at a debugger, more hours thinking.
Not everyone on the team is comfortable with this shift. Some colleagues loved exactly that flow feeling, when code streams from your fingers, when you’re immersed in the problem and solutions emerge almost by themselves. That mental state is rarer now. The work has become more fragmented, more about review and validation than continuous creation.
Security as necessary obsession
There’s an aspect of AI-generated code that obviously makes me restless: security. In the course materials I dedicated a whole section to specific risks. Insecure patterns, vulnerable dependencies, unparameterised queries. AI doesn’t have malice, but it doesn’t have prudence either. It reproduces what it has seen, mistakes included.
What worries me is that many of these problems aren’t obvious at first sight. The code compiles, the tests pass, the application works. The vulnerability is hidden, silent, waiting for someone to find and exploit it. You need an experienced eye to spot it. You need time for meticulous reviews.
We’ve added automated tools to the pipeline: dependency audits, secret scanning, static analysis. They help, but they aren’t enough. In the end, someone has to sit down and read the code line by line asking: what could go wrong here? And I’ve learned (again) the importance of E2E tests.
What’s left of us
Sometimes I wonder what will be left of our craft in five years. Not in the apocalyptic sense of “programmers will be replaced”, which strikes me as a simplification. But in the sense of what we’ll actually do, day by day.
We’ll probably write less code and more specs. We’ll read more code than we write. We’ll spend more time thinking about architecture, security, the implications of every choice. We’ll be less craftspeople and more architects, less builders and more supervisors.
I don’t know whether anyone will like it. Many people liked writing code. Many liked the feeling of building something with their own hands, even if the hands were only metaphorical. Maybe that feeling will turn into something else. Or maybe people will look for it elsewhere, in personal projects where no one forces you to be efficient.
A craft in transition
What I’m trying to convey in the course, beyond the commands and checklists, is the awareness that we’re in a moment of transition. We don’t yet know where we’re going, but we know we won’t go back.
Vibe coding was an experiment, an adolescent phase in the use of these tools. Now we’re trying to grow up, to build processes and disciplines that let us use this power without hurting ourselves. It’s a work in progress, obviously.
A few months from now I’ll probably revisit this material and find it already obsolete. Something will have shifted again. The tools will be different, the workflows will have evolved. It’s the beauty and the curse of working in a field that moves this fast.
For now, what I can do is document what we learn, share it with the team, try to build skills that go beyond the specific tool. The capacity to think in a structured way, to write precise specs, to critically validate someone else’s output: these strike me as skills that will stay useful whatever happens, and that will give value to the people who hold them.
Or, at least, that’s what I keep telling myself lately.
Key takeaways
More technical competence is required, not less: you have to know how to program better than before in order to tell whether what the AI produced makes sense.
Writing a Constitution for machines doesn’t solve the judgement problem: the line between a pragmatic solution and a hack stays contextual, and that judgement stays human.
The flow of code streaming from your fingers is rarer: the work has shifted from continuous creation to critical review.
Questions & answers
How is the developer's craft changing with AI agents?
From writing code to writing and validating specifications. Before, the bottleneck was producing the lines; now the bottleneck is defining what to produce and verifying it was produced correctly. Code becomes a by-product of the spec, and the spec returns to being the central part of the craft—as it was forty years ago, before the boom of accidental complexity pushed it into the shade.
What does "spec architect" mean?
Someone who can write executable specifications—not narrative documentation but instructions precise enough to produce correct output when given to an AI agent. It includes explicit acceptance tests, interface contracts, system invariants, non-functional constraints (latency, costs, security). The skill isn’t new—it was already central to formal systems and TLA+—but it’s coming back as a widespread requirement.
Are people who write code today at risk of obsolescence?
Those who only write code, yes. Those who write code informed by a deep understanding of the domain, of architectural trade-offs, and of verification, no—that competence stays irreducible. The risk isn’t AI; it’s a professional identity built only on key-pressing skill. The curiosity that pushes you to understand why something works is what doesn’t get automated.
How do you prepare for this transition?
Three concrete investments: (1) learn to write light formal specs—property-based testing, clear interface contracts; (2) get used to code review of AI-generated code as a primary activity, not a secondary one; (3) develop systems judgement—what the real requirements of a project are, where failure is expensive and where it isn’t. It’s a metamorphosis from craftsperson to architect that used to be reserved for a few seniors and now applies to everyone.
The author
