Practices Have a Half-Life. Architecture Shouldn't.

The real reason AI engineering never stands still.

If you're exhausted by how fast this space moves, that's a reasonable reaction. It can be genuinely disorientating, and you're not falling behind because of it.

The last year in agent engineering has looked something like this... vibe coding came first. Spec engineering followed, because vibes alone weren't enough for anything that had to survive contact with production. Agentic workflows came next, once a single prompt-response loop couldn't handle real complexity. Loop engineering became its own discipline after that. Last week, Peter Steinberger asked, half-seriously, whether we'd already moved past loops and into graphs. Millions of views later, graph engineering was a thing. This week, word is going around that Boris Cherny told a room of YC founders that Claude Code's own team deletes their CLAUDE.md, their skills, and their hooks every six months and rebuilds from nothing, because the model underneath has usually gotten good enough that half of what you built around it is now dead weight.

By the time you've read this paragraph, something has probably shifted again. That's not a joke. That's the actual pace.

Why this feels like whiplash

If you're a leader trying to make a call on tooling, or an engineer trying to keep your practice current, this churn creates a very specific kind of exhaustion. You commit to a methodology, you get your team fluent in it, and a matter of months later someone credible is telling you it's already outdated. You start wondering whether any of this is real progress or just a ploy to sell the next course, the next framework, the next platform.

I understand where that cynicism comes from. Vendors need new language to differentiate what they're selling. Conference talks need a fresh hook.

What's actually been constant

Underneath every one of those [ever changing] labels, the same underlying problem has been sitting there the entire time: how do you build reliable engineering systems around models that keep getting more capable and faster than most organisations can absorb.

Vibe coding was an early, honest name for "just let the model try things and see what happens." It broke down because production systems need more rigor. Spec engineering was the first real attempt to add structure. Agentic workflows and loop engineering gave that structure the ability to run multiple steps, check its own work, and recover from mistakes without a human in every cycle. Graphs, as far as I can tell, are an attempt to represent that same coordination problem more explicitly, since loops alone don't capture branching decisions well.

None of these terms really contradict each other. They're different descriptions of the same transition at different points in the capability curve. The direction hasn't changed, we still strive for better conventions, stronger review, feedback from production, and building trust deliberately instead of assuming it.

Those are the goals that stayed stable through all of this. But they don't explain why the terminology keeps turning over anyway. Every practice you build to compensate for a limitation in today's model has a half-life, because the next model probably won't have that limitation. The model is what's setting the clock on that half-life.

Once I started looking at the last year through that lens, the churn stopped feeling arbitrary and I stopped trying to keep up with the flavour of the month.

The deeper version of the same lesson

You can see this outside AI-native workflows too. Jarred Sumner rewrote over half a million lines of Bun from Zig to Rust in eleven days using parallel Claude instances. The speed wasn't important, it's that AI changed the economics of a rewrite that had long been considered unjustifiable. The outcome he wanted was to build a fast, reliable JavaScript runtime, but the economics of replacing the implementation changed.

The same thing is happening one level down, inside the actual practice of building with these models. If the reporting is accurate, Boris Cherny's delete-and-rebuild habit is the sharpest example of it I've seen, and it's really the same claim as the Bun rewrite aimed inward: the specific things you build today, your conventions, your skills, your carefully tuned prompt, shouldn't be treated as permanent, because the model keeps improving underneath you. Scaffolding that compensated for a weaker model becomes unnecessary weight once the model doesn't need it, and unnecessary weight has a cost even when it isn't actively causing harm.

That's an uncomfortable truth if you just spent months getting a team fluent in a particular way of working. Conversely, I don't think you should rebuild constantly either. Hold your practices a little more loosely than you're used to holding anything in engineering, and get comfortable revisiting decisions you'd normally consider settled.

What I'd actually do with this

You don't need to chase every new term that shows up. You genuinely can't, and trying to will burn out your team faster than the technology ever could.

What I'd pay attention to instead is whether a new idea is describing a genuinely different capability, or just renaming something you're already doing under a catchier name. Ask what problem it's actually solving. Then decide whether that's a problem you even have. Most of the time, if you strip the branding off, it's the same handful of things that mattered before any of these terms existed.

And give your team permission to not have mastered the latest name for something before moving on. Mastering "graph engineering" specifically isn't the goal. Building a team that can tell when a piece of scaffolding has quietly expired, and let go of it, that's the goal, and it has been under every previous name too.

There's one more step worth making explicit. Practices have a half-life. Architecture shouldn't. The prompting trick, the orchestration pattern, the specific way you've wired agents together this quarter, those are the parts you should expect to keep rewriting. The parts that define how state moves through the system, how work gets reviewed, how execution stays reproducible, those are worth building to last, because everything disposable ends up sitting on top of them.

It's also changed how I think about the systems we're building ourselves. We've become much less interested in encoding today's prompting strategy or orchestration pattern into the architecture, because those are exactly the things most likely to change. The durable investment is the layer underneath: deterministic workflows, explicit state instead of hidden conversational context, reproducible execution, and review you can actually observe rather than trust blindly. That thinking has also shaped how we've approached building Swamp: assume today's practices will expire, and invest instead in the architecture underneath them.

The pace isn't going to slow down. But the thing you're actually building, the engineering discipline underneath all of this, has been remarkably stable. The difference is that more of its practices now come with expiration dates. The skill isn't clinging to yesterday's scaffolding, it's knowing when the model has made it obsolete.