How to keep vibe coding and still sleep at night

"After I built the prototype, I was like, okay, now what?"

Can you relate? A client in stealth mode, who started with our AI App Audit and went on to work side by side with us, put it that simply. It's a question we're hearing more and more...

Building a real product in Replit with its AI Agent, without being a developer, has become a perfectly normal way to start. You get something working, you show it to people, and they're interested. Then a pilot comes into view, with real organisations, real users and real data, and the questions you need to answer start to change.

If that's where you are right now, it helps to remember how far you've already come. You've turned what you know about your users into something they can actually use, and that's the part nobody else could have done for you. The next stage can feel daunting, but it doesn't have to mean handing your product over or starting again. 

We've been working alongside founders at exactly this point, and we'd like to share what we've learnt along the way.

The questions nobody tells you to ask

The founders we talk to aren't short of vision. They know their users, their market, have some clear, strong ideas what the product needs to do, and want to validate them with real, paying users. What's harder is knowing the questions a developer would ask before letting real people in. Our client described it as the gap between function and protection: Making a feature work and making it safe are two different jobs, and the Agent will happily do the first without ever raising the second.

Then there's the uneasy feeling of not being able to check. When the Agent tells you something's done, how do you know it is? Where is my users' data? Who can see it? Did that change go where it said it went? On top of that, every question you put to the Agent uses credits, so even double-checking its work comes at a cost.

And as the product grows, so does the number of moving parts, often with the founder as the only person who knows how they all fit together. Our client called it "garden overgrowth.” It's a lot to carry on your own, and it leaves the whole business leaning on one person's memory just as pilots are about to begin.

Why we don’t take the keys away

Bringing in an engineering partner doesn't have to mean moving off Replit or rebuilding the product somewhere else, and we didn't do either. Our client carries on building with the Agent every day, so their speed and their knowledge of the domain still go straight into the product, without a spec being handed to a development team in between. Replit still looks after the hosting, deploys, database and secrets, so nobody has servers to run. Unless they want to, for say data residency or green hosting requirements, which we can and have helped implement. 

What we bring is the part the Agent doesn't do on its own: 

We review the architecture, tackle security issues in order of how exploitable they really are, add automated tests, tidy up the code where it helps, and look carefully at every change. Those that we work with don’t need to learn Git or read code to benefit from any of it, because we translate what we find into what it means for the business and what decisions, if any, they need to make.

Where AI-built products go astray, and how we steer them back

The Agent commits its work straight to the live codebase while we work on our own copy, so before we merge anything of ours, we review everything it has changed since we last looked. We note what changed as plain fact, without guessing at why, and if it affects our plans we adjust them rather than asking for the Agent's work to be undone. 

It's a simple routine, and it's what lets two very different authors share one codebase without tripping over each other.

Three patterns that we noticed come up, again and again:

Big, bundled changes. A single review could cover well over a hundred commits and thousands of lines. Small batches are far easier to check properly, while big ones tend to hide surprises, like a redesign that quietly changed how something behaved when nobody had asked it to.

Database changes taking several routes. Changes to the database's structure reached it by more than one path, and at one point the code expected columns the database didn't have. It's one example of the kind of issue we saw that can cause an error in the live product, so we agreed on a single route for database changes with our client, wrote it into the Agent's standing instructions, and checked it every time. Building in these guardrails steers clear of mismatched activities and expectations.

Unfinished cleanup. When the Agent replaced a screen, the old one often stayed behind in the code, unused, and sometimes data the product saved was no longer shown anywhere. None of it breaks anything on the day, but it all adds to the overgrowth our client described.

We share these because they're what you'd expect when a product grows this quickly, and every one of them is fixable once someone's keeping an eye out.

Good habits rub off on the Agent

This is the part we find most encouraging. 

The Agent reuses the patterns it finds in the codebase, so every good convention we put in place makes its later work safer by default. A consistent check on who's allowed to do what, a standard way of handling errors, a test that guards against a known mistake: once they're there, the Agent picks them up and follows them.

That changes what an engineering partner is for. As well as fixing what the Agent gets wrong, much of our work is shaping the codebase so it gets more things right in the first place, which means our client's everyday building gets safer too.

The nimble, durable path: your AI tool plus an engineering partner

For us, pairing an AI-built product with an engineering partner works better than the two alternatives we’ve seen most often, which are replacing the founder's tool with a traditional build or leaving them to manage it alone. It’s a changing world out there, and the traditional build path is no longer the path most will follow, instead opting to use some form of AI coding tool.

The real balance, as we see it, is in cost and control: You keep the speed and ownership that got you this far, and we help shape the codebase so the AI does better work. And to have engineering experts on your side who are also aligned with your values and Circular Economy mission? So much the better.

To us, the measure of success on these projects is whether we've helped the project succeed in the long run, beyond your initial excitement. 

========

If you've built your prototype and you're wondering “Now what?", we'd love to hear about it. Our AI App Audit is a good place to start, or you can just get in touch for a chat.