◇ Config warnings ─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮ ├───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯

There’s a pattern in software engineering that most people recognise but few name directly: every major shift raises the abstraction layer. We stopped writing assembly. We stopped managing memory manually. We stopped configuring servers. Each time, someone insisted the craft was dying. Each time, they were wrong — they were just looking at the wrong layer. Roberto Butti wrote recently about where he thinks the next layer sits. His argument is clean: AI isn’t replacing developers, it’s moving us one level higher. From writing code to defining intent. From implementing to orchestrating. From producing to owning. He’s right. But the implications are worth sitting with for a moment.

The Abstraction Never Stops

When you look back at the history of this profession, the through-line is consistent. The hard part is never the syntax. It’s never the typing. It’s deciding what to build, how to shape it, and who is responsible when it breaks. That’s not going away. If anything, it becomes more concentrated as the lower layers get automated away. Butti makes a point that landed for me: the IDE is becoming a place you review code rather than produce it. I’ve noticed this in my own work. The cursor still moves. Files still open. But increasingly, the question isn’t “how do I implement this” — it’s “is this implementation correct, and is it the right thing to be implementing at all?” That shift in question changes everything about what a working day looks like.

The Ownership Fracture

Here’s where it gets interesting — and where I think most of the discourse gets it wrong. Everyone argues about whether AI will replace developers. That’s the wrong axis. The more consequential question is: who owns what? Code can be generated. Accountability cannot. If an AI produces a system that fails at two in the morning, someone still has to answer for it. Someone still has to understand why it failed, whether the failure was architectural or incidental, and what the path to fixing it looks like under pressure. That person needs to understand the system at a level that isn’t being generated — it’s being reasoned about. The abstraction doesn’t eliminate the need for judgment. It just moves judgment upstream.

Probabilistic Systems Add Another Layer

Butti also raises something that doesn’t get enough attention: modern software is increasingly probabilistic. Not everything — and that’s the point. Deciding what should be deterministic and what should be probabilistic is itself an engineering decision. Testing probabilistic systems is different. Monitoring them is different. The failure modes are different. This creates a category of decisions that didn’t exist in the same way five years ago. You can’t delegate them to the AI because the AI is the source of the uncertainty. Someone has to reason about where the uncertainty lives, what the acceptable variance is, and what happens when the model produces an output that is technically valid but contextually wrong. That someone is still a developer. Just operating at a higher altitude.

What Actually Changes

The model Butti describes — less implementation, more intent — is accurate. But I’d add one refinement: it doesn’t just change what developers do. It changes who can do it. A single experienced developer with access to AI capabilities, cloud infrastructure, and specialized platforms can now build products that previously required a team. The constraint was always implementation capacity. That constraint is loosening. What that means is that the bottleneck shifts. From production to judgment. From typing to deciding. From writing to understanding. And understanding — deep, structural, architectural understanding — has always been the part that couldn’t be shortcut. The tools change. That doesn’t.

The Question Worth Asking

So where does that leave someone working in this field? I’d frame it this way: the question isn’t whether you can produce code. That part is becoming commoditised faster than most people want to admit. The question is whether you can own something. Whether you can take responsibility for a system end-to-end. Whether you understand it well enough to be the one standing there at two in the morning when it fails. That’s not a technical question. It’s a professional one. And it’s the question that will define what kind of developer you become — not whether you use AI, but whether you know what you’re building and why. The layer above the abstraction is still waiting for people who are ready to live there.