AI made me a developer again. Kind of.

I spent years moving away from building things with my hands.

Started as a Web Designer / Developer. Moved into hybrid project management. Dropped the code entirely when I became a full-time project manager. That was the right call, and I want to be clear about that before the rest of this article appears to argue with it. No regrets. The move was deliberate, it suited me, and I'd make it again.

...then AI came along and quietly gave the building back.

Vibe-coding (a term I use under protest)

I've been vibe-coding. The term genuinely makes me want to throw up, and I'll be using it anyway, because it's what everyone calls it and inventing a more dignified name would fool nobody.

Let me set the boundaries first, because this is where the sensible version of the story lives. Nothing production-critical. I wasn't building Mews's payment infrastructure in my spare time, and if I ever suggest I should, someone stage an intervention. What I've been building is the other category: small tools, internal apps, things that would have required an engineer's time and now require an afternoon of mine. The page request scoping app I built in Lovable, which regular readers have already heard about. Workflow automations. Scripts that used to live on someone's backlog gathering seniority.

That last group deserves a moment. Every team has them: the small, useful, unglamorous ideas that everyone agrees would help and no engineer can ever justify prioritising, because there's always something production-critical to do instead. That backlog of good-but-never ideas is exactly the territory AI-assisted building opens up. Not the crown jewels. The stuff that was never going to get built at all.

The old mental model is the new advantage

Here's the strange part, and the actual reason I'm writing this. The developer mental model, the one I thought I was leaving behind when I moved into delivery, turns out to be exactly what makes AI-assisted building work well.

Knowing how systems fit together, so the thing you ask for is a thing that can exist. Knowing when an AI-generated output looks wrong or right, which is a skill you only earn by having produced plenty of wrong output yourself, by hand, over years. Knowing what to ask for and how to check whether you got it. And most importantly, knowing how to think about the edge cases that will break it, before it's in production and someone actually hits them. What happens when the input is empty. What happens when two people use it at once. What happens on the date boundary nobody thought about. The AI will cheerfully build you something that works right up until it doesn't, and the difference between a useful tool and a future incident is usually whether anyone asked those questions before shipping.

None of that is coding ability, exactly. I'd struggle to sit down and write from scratch what these tools produce for me. It's something one level up: the accumulated suspicion of someone who has watched software fail in all the traditional ways. That suspicion, it turns out, doesn't expire when you stop writing code. It just sits there, waiting for a reason to be useful again.

Trusting versus verifying

If I had to compress the whole argument into one line, it's this: non-technical people using AI to build things are essentially trusting it. Technical people using AI to build things are verifying it. That's a meaningful difference.

It's not a difference in intelligence or care. Non-technical builders can be diligent, and technical ones can be lazy; I've been both in the same week. It's a difference in what you're able to check. When the tool produces something, one group can read it, poke at its assumptions, test the unhappy path and know where the bodies are usually buried. The other group can only test whether it appears to work, which is a much weaker claim than it sounds, because "appears to work" is the natural state of all software immediately before it embarrasses you.

For throwaway experiments, trusting is fine. For anything a team will quietly come to depend on, and internal tools always end up depended on, the verifying matters. The scoping app looks simple from the outside. The reason I was comfortable putting it in front of my team is that I could check what it was actually doing, not just admire that it did something.

Should every PM do this? No.

I'm not suggesting every PM should pick up vibe-coding, and I'm suspicious of anyone who is. Most of the "everyone must build now" discourse is written by people selling either a tool or a course.

But if you've got a technical background and you've been sitting on the sidelines of the AI tools conversation, it might be worth reconsidering, because the maths has changed twice over. The barrier to building things is lower than it's ever been. And the background you thought you left behind, the one you may have half-mourned when you moved into delivery, might be exactly what makes you good at it. Not despite the years away. The suspicion aged well.

I gave up building things deliberately, and I'd defend that decision to anyone. I just didn't expect the tools to come and find me, hand me back an afternoon-sized version of my old job, and reveal that the most valuable thing I'd kept from it was the doubt.