Agentic engineering

A year has passed since Andrej Karpathy coined the phrase “vibe coding”. He described a new way of coding with AI - sitting back, loosely throwing prompts into Cursor, clicking “Accept All”, barely reading the code. It was provocative, but it captured something real about how AI was changing what it feels like to write software - and even what it means to be a software engineer.

In my own take, I argued we were at the start of a transition from craft coding to vibe coding. The direction of travel seemed inevitable, but the journey would be longer and bumpier than some were promising. AI was great fun for throwaway projects, but not for serious, complex software. Not yet, at least.

This wasn’t a contrarian take. At the time, models struggled with non-trivial problems, and tools like Claude Code and Codex hadn’t even been released. What I didn’t appreciate is that in AI, a year is a very long time.

Inflection point

Something shifted in late 2025. Yes, the models got better. Claude Opus 4.5 and OpenAI’s GPT-5.1-Codex both landed in the final months of 2025, and the jump in capability was significant. But what really caught my attention was watching how developers’ behaviour was changing.

Karpathy himself described going from 80% manual coding to 80% agent coding in the space of a few weeks, calling it “the biggest change in ~2 decades of programming.” And it wasn’t just him. Developers I know or have followed for years - people who’d been cautious about AI, even sceptical - suddenly started talking (a lot) about how they were using Claude Code.

Then along came OpenClaw (previously ClawdBot, then MoltBot). Unless you’ve been living under a rock, you’ve heard of it by now. The open source AI agent platform, built by one developer, Peter Steinberger, went from zero to 100,000 GitHub stars in days, spawned mainstream media coverage, a trademark dispute with Anthropic, and suddenly everyone was talking about it, installing it, breaking things with it. What’s most remarkable is how quickly it happened. Looking at the timeline and the scope of the codebase, you just know this wouldn’t have been possible for one person without AI.

If the early 2025 position was that AI coding worked for toys but not for real engineering, that position is getting harder and harder to defend.

Developer ego

It’s taken me a while to recognise this, but adopting AI isn’t just about new tools and workflows. A big (and understated) part of it is letting go of our ego.

AI code - even today - rarely looks like code that I would write. It’s more verbose, it duplicates things, it has weird patterns that just smell unmistakably of AI. And sometimes it’s worse than that - it’s simply wrong. An agent will get itself into a tangle, “fixing” problems with the wrong solution and digging itself deeper into a hole of its own making.

These limitations are weirdly comforting. They let developers argue we’re still needed. Not just needed - superior. We can look at AI code and think: “I wouldn’t do it like that. My code is better.” And honestly, I think we like being the craftsman and the problem solver. We get fulfilment from it. It’s natural to resist change that threatens to take that away.

I’m not alone in this. Karpathy admitted the shift to agentic coding “hurts the ego a bit.” Eric S. Raymond recently observed that programmers have “a tremendous amount of ego and identity invested in the craft of coding”. A developer on the Stack Overflow podcast compared it to going from “a craftsman whittling a perfect chair” to “a factory manager at Ikea.”

Whether we publicly acknowledge it or not, I think most developers - especially those who’ve been around a while - are going through something that feels like a professional identity crisis. I know I’ve had moments wondering if my career has had its best days. Am I done?

I realised I needed a deliberate shift in how I think about my role. I’ve become far more “vibe coder” than I would have been comfortable admitting a year ago. A more maximalist view where the machines are responsible for writing the code, writing tests, reviewing code, fixing bugs. I don’t read every line of code AI produces - it’s impossible to. But I maintain a high-level understanding of the architecture, just enough to steer the AI. Occasionally, if it gets stuck, I’ll dive in far enough to understand why. I rarely fix a bug directly - I just point the AI in the right direction.

All of this feels uncomfortable. It grates not just against my ego, but against decades of collective wisdom about what good software engineering looks like. But that’s what makes this moment revolutionary - the rules are being rewritten, whether we like it or not.

Making peace with slop

One telltale sign of a developer who’s embraced AI development is their GitHub contributions heatmap suddenly turning to a shade of green that dazzles compared to previous weeks. But all that code - which, let’s be honest, is at best getting a cursory glance from its human committer - raises legitimate questions about quality, maintainability and security.

The slopacolypse is real and it’s happening. The way I’ve come to see it isn’t to worry whether the AI code is sloppy (it is), but to ask what kind of slop actually matters.

There’s one bucket I’d call stylistic slop: verbose code, odd patterns, unnecessary abstractions. Things that offend your sensibilities as a craftsman, but don’t actually break anything. The code works, and it would have taken you weeks to write by hand. Learning to live with this is probably in your interests now.

Then there’s the more dangerous stuff - toxic slop: real security vulnerabilities, exposed APIs, architectural decisions that create genuine risk. This is what matters most, and spotting it in the firehose of code flying at you from all directions is a hard problem that AI engineers need to solve.

OpenClaw illustrates both sides perfectly. It’s proof that one developer with AI can build something that captivates millions of people in a matter of weeks. It’s also a case study in what happens when toxic slop ships at scale. Within weeks of going viral: a critical RCE vulnerability was discovered; over 42,000 control panels were found exposed to the internet; some 386 malicious skills were identified in the ecosystem; and the spinoff site Moltbook - a social network exclusively for AI agents - leaked 1.5 million API keys within days of launching.

OpenClaw is simultaneously the best advert for AI engineering and the strongest argument against it. What I take from this is that the line between “this offends my craftsmanship” and “this is actually wrong” is fuzzy and unclear. We need to focus human judgement where it counts most - on the architecture, the security and the real-world quality of what we ship.

RIP vibe coding

I recognise there’s a bit of snobbery here, but I cringe every time I hear the words “vibe coding”. The term has leaked into wider discourse, and I’ve even heard my normie friends use it. To my mind, it’s become a pejorative - synonymous with low-effort hacks, security-flawed apps, MVPs that fall apart the moment real users turn up.

So I was glad to see Karpathy has effectively retired his own term, proposing “agentic engineering” as a replacement. His point is that the tools have matured past the stage where “vibing” describes what’s actually happening. Addy Osmani makes the same distinction.

Subagents, agent swarms, multi-agent orchestration, concepts like the Ralph Wiggum loop - terms that didn’t exist eighteen months ago - are now common parlance among developers working with AI. It’s still a wild west - pioneers figuring out the best way to do this stuff. But we’ve come a long way from “build me a Flappy Bird clone.”

I don’t have this figured out - none of us do. It’s disorientating realising that the thing you thought you were good at suddenly has a new rulebook. That inner struggle is real, and it won’t be unique to software engineering. It’s just that we got here first.