It’s been a year since “vibe coding” was coined, and a few different models of AI-assisted software development have emerged in the meantime. As I look at these various approaches, I’m thinking about what “product management” means today. All of the focus is on coders—and on how much easier it is to code. But that doesn’t mean the code is good. A lot of vibe-coded products I see are basically databases with nice frontends. That’s great, and powerful, but those aren’t _products_ —they aren’t adapted to their environments, or focused on their users. So what is the work of the product manager in this new world?
First, I think we should list some different approaches to using AI to build software. Obviously there’s “vibe coding” itself: You prompt, you lean back, you drink a piña colada. Claude or ChatGPT write your app and you direct them from time to time. The product manager becomes the programmer, or the programmer becomes the product manager; all categories collapse, because who even cares? Eventually, a product shows up: A game, a word processor, a computer virus. There was plenty of hype at the start, but it seems like a lot of engineers are burning out on vibe coding; maybe it’s not as great as we’d hoped.
Then there are the “Dark Factory” or “Gas Town” models: You are the commander of an army of thousands of agents, all working together, each with their own roles. They build, they test, they cannot rest until the code is working. They send you reports, and you command them, burning thousands of dollars in AI credits to command your flock of minions. They might build a whole system, or create something grisly, like a C compiler or web browser. It’s a black box, and you like it that way.
# Want more of this?
**The Aboard Newsletter from Paul Ford and Rich Ziade:** Weekly insights, emerging trends, and tips on how to navigate the world of AI, software, and your career. Every week, totally free, right in your inbox.
There are also what are increasingly being called “runtime” approaches to programming. You put together a big bundle of stuff already in the box, and you ask AI to assemble from a box of nice, LLM-friendly lego parts. You don’t let the LLM stray too far.
This last approach is what Aboard sets out to do for our customer-clients, and what tools like Base44 and Replit try to do for their customers. Runtimes are more like Legos. Things like data storage, authentication, and basic navigation patterns come pre-packaged. This limits the domain of problems you can solve—no one will build a cool 3D game with Aboard, but they might build a secure game-asset-management system they can use across teams.
For personal projects, I find myself doing a lot of what I call “turn-based development.” This isn’t a broader category; it’s just how I think about it. The goal is not to “finish” the software—software is never finished—but to _build a system that makes each turn more predictable_.
For example, I recently relaunched my personal website. It was a messy project I’d avoided for about 15 years because I’ve created a lot of digital stuff, and organizing digital stuff is very hard. I built my own CMS in 1999 and made it as complex as humanly possible, and then I went on to publish…a lot. If you count my tweets, articles, company newsletters, podcasts, photographs, and so forth, we’re looking at about 70,000 “things,” some a sentence long and some book-length, some simple text and some hosted on YouTube. It’s not really a “put it on WordPress” situation.
A few months ago, I started working on importing some data. I kept asking Claude to look at a file, figure out what was in there, save it to a database, and tell me what it found. Then I’d ask for improvements. When I was done, I’d ask it to generalize what it was doing. I’d try to actually, you know, read the code it produces, and I’d encourage it to make things into libraries and re-usable functions.
After taking 80 or 90 turns doing that and importing a bunch of old data (like my full tweet archive), I had increasingly high confidence that the next zip file would basically work as expected. I went from 80 turns to four or five per data type. I didn’t write any code, but I did read a lot of it, and if you asked me to explain the system I was using, I’d be able to do a good job. (It’s also a read-only system without a lot of private data, which means that my risk tolerance is pretty high.)
I did similar turn-based work across a variety of domains: Text editing, content import, asset management, search, deployment, and feed generation. As I hit walls, I started breaking components into little modules. For example, I pulled the taxonomy manager out of the CMS and made it an independent module that could run inside the CMS. LLMs are easily confused—when you can’t do something with an LLM, just make a smaller system, and slowly reintroduce it.
After a few months in the fog, working on this project for maybe three hours a week, I now have high confidence in how my coding turns will…turn out. But all I did was build a bunch of small APIs in my spare time, which is, well, programming. I’m nowhere near done—I don’t like the way search works—but it’s good enough, and even if it breaks, it’s just a website.
Zooming out, one could say the big, agent-based approach of Gas Town is all about taking “system turns”: Giving instructions that improve the entire system at once. I’m suspicious of that. It might work for projects that are incredibly well-specified, can be parallelized, and yield to automatic testing, but that defines only a small class of software, like, say, an email server (although God help anyone trying to write a secure email server with an LLM).
Personally, I don’t feel ready to trust an LLM to update an entire system at once. When I attempt to do so, it usually makes a lot of mess, and I have to clean it up. I’d much, much rather make a lot of little turns on lots of systems and fit them together, learning how they fit. When hiring product managers—and Aboard does!—we’re looking for this behavior.
My hunch is that product management will end up looking like what I’m doing: Building up from runtimes and large bases of software, working within guardrails instead of just producing a ton of raw code, trying to make things repeatable and evolvable, cutting off little bits of software, growing them in a pot, then grafting them back onto the main branch. The job title could be something like “program implementer”; at Aboard, we define it as “solution engineering.” Everyone here is a solution engineer now, including me.
It might get messy. Bosses might swoop in and change the system on the weekends because they’ll have access to the same tools you do—bosses tend to do that. But now, instead of sending an email, they can jump in and have an LLM write code and change the database. I expect people will be managing more systems than ever before. Occasionally you’ll reach out to an engineer or a designer for advice, but they might just log in and make the changes you need. Jobs are going to change and roles might evolve, but I suspect there will be more than enough work for everyone.