From vibe to live: why is it so hard to pull the trigger on agentic codebases?

Right now I’m building a CVE management platform for PortlandLabs, mostly with Claude. Besides tracking CVEs, it’ll also generate the release notes and marketing copy for Concrete CMS releases. Every day it’s becoming more and more like a real product; it certainly already has a much fuller feature set than many internal products we’ve built. It’s also a very specific product; it has a very particular set of features that fits our workflow and problems pretty well. We’ve probably built a half dozen of these types of projects in the last six months. And I’ve got another couple personal projects that fall into the same category.

But I haven’t launched any of them yet.

Here’s what I keep running into: it’s easy (and addicting) to vibe code in a vacuum. Describe an app, watch it appear, poke at it, ask for changes, repeat. In an afternoon you have something that looks and mostly acts like a real product. It’s also easy, or at least it’s gotten a lot easier, to do agentic engineering on a codebase that’s already live. Point Claude at a real project with some well-defined, isolated issues, and you’ll get fixes you can ship pretty quickly. If you’ve worked on any open source software in the last six months, you’ll see the fruits of these labors very quickly.

But connecting these two processes – taking the vibe-coded thing and actually launching it – seems the hardest bridge to cross. I’ve been trying to figure out why.

Nothing in a vacuum is real

When you start building, the app can be anything. Every idea you have is one prompt away from existing. There’s nothing quite like that dopamine rush from seeing an idea take shape. The only limit is yourself (and your tokens).

It doesn’t hurt that there are no legacy decisions complicating the entire endeavor. Everything is reversible because nothing has really been done yet.

That’s exactly why it’s fun. It’s why it’s so hard to stop. And it’s also why turning the corner into “launch mode” is so difficult. Launching means picking one version of the thing and closing the door on all the others. Before launch, the app is whatever it could become. After launch, it’s just what it is.

A live codebase comes with rails

Agentic engineering on a live project is easy for the opposite reason: the hard decisions are already made. Somebody picked the database and the schema. The app is what it is. If it has bugs, the bugs are finite and (hopefully) well-described, which makes it easy to sic an LLM on them.

The agent doesn’t have to invent an architecture or guess at whether something needs to work a certain way. The tests tell it when it’s wrong. The existing code shows it what “the way we do things here” looks like.

Launch is where every decision comes due

None of this is new, really. Just like with old-fashioned software development, the first 80% comes together quickly, and the last 20% takes a while. Same as it ever has.

Launching is the moment you have to make all of those decisions at once, for the first time, for real. You have to commit to supporting something. An agent can’t decide these things for you. They’re not coding questions; they’re questions about what you’re willing to be on the hook for. Like I said in The elephant in the room, my job is mostly deciding things. Launch is a pile of deferred decisions coming due all at once.

An AI skeptic would say there’s a simpler explanation: I don’t have any skin in the game. I didn’t really write any of this. I described what I wanted, and an LLM typed it out. I got to experience the excitement of software development without really doing any work. Of course it’s hard to commit to code you didn’t write. You never built up the confidence that comes from making something line by line, so you have no idea whether it’ll hold up once real people start leaning on it. But even more than a question of uncertainty regarding the codebase, they might say the problem is more fundamental: if you didn’t write the code, you don’t truly feel any attachment to it.

I’d push back on this, but I think you can only really do so if you reframe what it means to take pride in the software you write, regardless of how it comes to be.

So what helps?

I don’t have this figured out, but a few things seem to help.

Read it and review it. Before I put something on the web with my name on it, I have to own the code and be accountable for it. That’s where a lot of the friction is hiding: code that was written to impress me in a demo isn’t always code I want to maintain. The earlier I start reading, the cheaper it is to change course.

Understand it. Reading isn’t the same as understanding. You have to know how the app works, and have some pride in the way it’s put together. That doesn’t mean poring over every line with a fine-toothed comb, but it does mean understanding your app, and understanding, to some degree, all the technology it uses.

Wireframe it first. If the problem is that the app can be anything, decide what it should be before an agent writes a line of code. Sketch the screens and flows in Claude Design or something like it. I’ve always been a visual learner, especially regarding software, so this part really helps me feel like what I’m building has some basis in reality, rather than in ephemeral prompting.

Put it in front of real stakeholders. A demo for yourself doesn’t count; of course you like it. The people who’ll actually use it are the only ones who can tell you whether it fills a real need, or whether it’s just another tool that no one is really excited about. Their answer turns “what could this be?” into “what does this need to be?”, and that’s most of what launching is.

None of this makes pulling the trigger easy. It just turns launch into a decision instead of a leap, and that’s my job, after all.