There was a stonemason in Santiago (not a famous one, not the kind they write plaques for) who spent forty years carving granite for the cathedral restorations. My grandfather knew him, or claimed to, which in Galicia amounts to the same thing. The man had a saying that I never understood until this year: “O rápido nom é o que mais corre, é o que sabe onde vai.” The fast one isn’t the one who runs fastest. It’s the one who knows where she’s going.

I’ve been thinking about him lately, this mason nobody remembers, because something is shifting in how we build software, and it has the same shape as his proverb.

The decade we spent running#

For twenty years, the software industry has been sprinting. Agile told us to stop drawing blueprints and start laying bricks. Ship the thing. Learn from the rubble. Iterate. The manifesto was a corrective, and a necessary one: before Agile, teams spent eighteen months writing specifications for software that was obsolete by the time anyone opened an IDE. We were building cathedrals nobody asked for.

So we learned to move. We stopped asking permission. We shipped MVPs, gathered feedback, pivoted, shipped again. “Working software over comprehensive documentation” wasn’t just a principle, it was a liberation. And it worked, genuinely, for a long time.

But somewhere along the way, the corrective became the orthodoxy. “Ship fast” stopped being a strategy and became an identity. Documentation was for people who couldn’t code. Architecture was a dirty word, the province of ivory-tower consultants with UML addictions. If you spent a morning thinking before typing, you were the bottleneck.

We got very, very fast. We also got very, very lost.

The vibes, they are not enough#

Then came the AI tools, and everything accelerated again. Copilot, Claude, Cursor: suddenly you could describe a feature in plain English and watch it materialise. Andrej Karpathy called it “vibe coding,” which is perfect because it captures exactly the right mix of exhilaration and recklessness. You feel your way through. You prompt, you accept, you prompt again. A prototype in an afternoon that would have taken a team a week.

The problem is not the speed. Speed is beautiful. The problem is that code written at the speed of intuition ages the way fish does: magnificently fresh for about six hours, then increasingly difficult to be around.

Vibe coding produces software that works right now. It does not produce software that anyone understands, including the person who shipped it. Architecture decisions get made invisibly, by the model, based on whatever patterns it absorbed from its training data. You didn’t choose that state management approach. You didn’t decide on that error handling pattern. The machine did, and you accepted because it compiled and the tests passed and lunch was in twenty minutes.

Six months later, you’re excavating your own codebase like an archaeologist who can’t read the script.

The mason’s revenge#

Here’s what’s changing: the most valuable thing a developer can do is no longer writing code. The machines write code now, and they write it faster than any human ever will. The race is over. The machines won it while we were arguing about tabs versus spaces.

But (and this is the mason’s proverb again) speed without direction is just expensive chaos.

The work that matters now is the work that happens before the first prompt. Defining boundaries. Choosing patterns. Deciding what a system should look like when it’s finished, not just when it compiles. This is architecture, the real kind, not the enterprise-consultant kind with seventeen layers of abstraction and a governance board. The kind where someone sits down and thinks: what are the three decisions that, if we get them right now, will save us six months of pain later?

The developer’s job is becoming the stonemason’s job. Not cutting every block, but knowing where each one goes. Designing the structure so that when someone else (or something else) does the cutting, the cathedral still stands.

Your codebase is a classroom now#

There’s a subtlety here that took me a while to see. We used to write clean code for the next developer. Good names, clear comments, sensible structure: all so that the poor soul who inherits your module at 3am on a Tuesday can figure out what you were thinking.

The next developer is now a machine.

This changes the stakes completely. A human developer can ping you on Slack. They can read between the lines. They can look at a questionable pattern and think, “that doesn’t feel right, let me ask someone.” An AI model does none of this. It sees your patterns and replicates them, faithfully, at scale. Good patterns multiply into good code. Bad patterns multiply into a codebase that looks functional on the surface and crumbles the moment you touch it.

Your code is training data now, whether you like it or not. Every well-typed function, every clear interface, every consistent naming convention is a lesson the model learns. Every shortcut, every “I’ll fix this later,” every contradictory pattern is a lesson too: just not the kind you want taught.

Curate your codebase the way a librarian curates a collection. Not because you’re precious about aesthetics, but because the quality of what you put in directly determines the quality of what comes out, multiplied by a thousand.

Not waterfall, not agile. Something else.#

I can already hear the objection: “So we’re going back to waterfall? Eighteen months of specs before writing a line of code?” No. Absolutely not. We’re not going backwards. The pendulum doesn’t return to the same place. It finds a new centre.

What’s emerging is something more interesting than either extreme. Call it intentional development, or don’t call it anything: names are cheap. The shape of it is: think carefully, build fast, constrain intelligently. Spend the morning designing the system. Spend the afternoon letting the machines build within it. Spend the evening reviewing what they produced, not for syntax errors, but for architectural coherence.

The Agile Manifesto said “individuals and interactions over processes and tools.” That made sense when individuals were doing all the building. Now the tools are doing most of the building, and the individuals need to be the ones setting direction. The bottleneck moved. In 2005, it was speed. In 2026, it’s judgment.

We don’t need more velocity. We have more velocity than we know what to do with. What we need is a map.

What the mason knew#

The stonemason from Santiago (the one my grandfather may or may not have known) retired in the 1980s. By then, they were using power tools for the restorations. Pneumatic hammers, diamond saws, things that would have seemed like sorcery to the medieval builders. The cuts were faster, cleaner, more precise than anything human hands could manage.

But someone still had to decide where to cut.

The tools changed. The craft didn’t. It just moved upstream, from the hands to the head. From execution to design. From the chisel to the blueprint.

That’s where we are now. The chisel got impossibly fast. The question is whether we’re ready to be the ones holding the blueprint.

I think we are. But only if we stop running long enough to remember where we were going.

Enfin.