All 10 of my engineers code with AI. This is not vibe coding.

Every engineer at Helply writes code with AI. All 10 of them, every day, on the product that's doing $1M arr.

I've stopped saying that out loud in some rooms because of what people hear. They hear vibe coding. They hear a founder who has been told the team is shipping fast and hasn't looked underneath.

I've looked underneath. Here's the actual distinction, because I think it matters and I think the term has gotten lazy.

What people mean by vibe coding

Describing what you want, accepting whatever comes back, running it, and if it works, moving on. No mental model of the system. No opinion about the shape of the code. The AI is the engineer and you're the product manager of a thing you couldn't debug at 2am.

That's a real practice and it's fine for a prototype. We used it to answer questions in a week that would have taken a month. Throwaway code that exists to settle an argument.

It is not how you build a support platform that companies route their customers through.

What we actually do

The hard parts are still hard and still human.

The data model was argued about for weeks. What is the primary object when the primary actor isn't a person clicking buttons. That decision shapes everything downstream and no model is going to make it for you, because it isn't a coding question, it's a question about what the product is.

The eval harness is human work. In a support product, "the model said something plausible" and "the model was correct" are very different states, and the gap between them is where you lose customers. Building the thing that catches the gap is the most valuable engineering we did all year and the least AI-assisted.

Anything touching billing is reviewed like it's going to be audited, because at $0.50 per resolved ticket it effectively is. If our resolution detection is wrong, we're either stealing from customers or from ourselves.

What the AI actually collapsed

The middle. The plumbing between deciding what to build and having it work.

Integration scaffolding. Test coverage. Migrations. The fourth CRUD endpoint that looks like the first three. Refactors that used to be a 2-day slog nobody wanted. Reading unfamiliar code fast, which turns out to be the underrated one, because a new engineer getting productive in a large codebase used to be a month and is now closer to a week.

Rough estimate from my team, and it's a guess, not a metric: 30 to 40% of the calendar. Across 10 people for a year that's the entire difference between the rebuild being possible and it not being possible.

The rules we ended up with

Not a policy doc, just what shook out.

You have to be able to explain what you shipped without opening the file. If you can't, you didn't write it, you accepted it.

Nobody merges code they couldn't debug. Same test, different phrasing.

The more expensive the mistake, the less of it comes from a model. Billing, auth, anything that talks to a customer unsupervised. Those get written slowly by a person who's annoyed about it.

Review is heavier than it used to be. That's the trade. When generating is cheap, reading becomes the bottleneck, and if you don't move review effort up you just ship more of everything including the bad parts.

The part I worry about

Junior engineers. I don't have a good answer here.

A lot of what made me able to debug things at 2am came from years of doing the boring plumbing by hand. That work is now largely gone, which is great for velocity and possibly terrible for whoever is 22 and starting now. We haven't hired at that level since the rebuild started so I'm speculating, but I don't think "they'll learn it a different way" is a good enough answer and I hear it a lot.

The other thing: our codebase is 12 months old and clean. Ask me how this is going when it's 4 years old and there's a layer of code nobody remembers writing.

For now the product works, the customers stay, and the team ships faster than any team I've run in 20 years.

Not vibe coding. Just coding, with the boring 35% removed.