By The Chiri Team

Chiri’s CTO gave his wife access to Claude so she could build a website for a project she was working on. She said yes to every suggestion the model made. She knows enough about programming to read code and be dangerous with it, not enough to know what she didn’t know. What came out the other end was a thousand lines that didn’t work.

He tried the same thing on himself, building a browser-based game in the style of Diablo 3. He doesn’t know game engines. He is, by his own admission, bad at physics. He also said yes to everything. Twenty-five thousand lines later, the result was the same as his wife’s: something that barely ran and looked worse than it ran.

Neither of those failures is really about the model. They are about what happens when saying yes replaces knowing what you actually need.

The crawling phase nobody warns you about

The first wall most people hit isn’t technical, it’s psychological. Download eight different tools. Grant permissions you don’t understand to install them. Get handed five scripts you can’t run because you don’t have superuser access. Copy and paste between windows, unsure whether you’re building something or breaking something. That initial stretch is disorienting enough that a lot of people quit before they get past it.

The ones who push through end up on Stack Overflow for the first time in their lives, Googling terms they’ve never needed before. Eventually something works. Maybe. Then the real pattern sets in: three steps forward, five steps back, then two steps forward again, while something else quietly breaks. Publish something publicly and discover there were never authorization checks on the API. Add a feature and lose two that used to work.

Then comes the moment almost everyone eventually hits: someone closes the laptop to vacuum around it, being polite, and the whole app goes down, because nobody explained that a laptop lid closing kills whatever tunnel was keeping it reachable. That’s usually the point where Docker enters the picture, not because anyone wanted to learn container orchestration, but because self-contained, replayable deployments stop being optional once you’ve lost an app to a vacuum cleaner once.

These aren’t edge cases. They are the actual, sequential phases of learning software development, compressed into weeks instead of years.

“I’m in pain”

Chiri works with clients who show up already deep in this cycle, often with real revenue already tied to what they’ve built. The pattern is consistent enough to describe from memory: nights, weekends, early mornings, sometimes until three in the morning, seven days a week, for months. Not because the idea was bad. Because nobody told them what came next, and there was no one to ask.

The honest version of what a lot of them eventually say is some version of: I know I’m not the one who should be doing this anymore.

That’s not a failure of vibe coding as a starting point. It’s what happens when a tool that’s genuinely good at getting something running has no opinion about what happens after it’s running.

Five things to fix before the wall hits

None of this is proprietary. It’s the same advice Chiri gives clients directly, because getting it right early is cheaper than fixing it after the fact.

Start with the access model, not last. Decide up front which roles and users can do what. This is the single hardest thing to retrofit once an app has real users and real data flowing through it. Waiting until it hurts guarantees a rebuild.

Keep an audit document from day one. Have the agent maintain a running change log of everything it does. Once a project has more than one thread of work happening, this is the only reliable way to know what changed, when, and why.

Treat the model as an orchestrator, not a coder. Hand individual tasks to fresh sub-agents instead of piling everything into one long-running context window. A single agent accumulating an entire project’s history eventually drifts, loses track of earlier decisions, or gets bogged down compacting its own context. Splitting the work keeps the orchestrating agent’s context clean and lets each sub-agent focus on one job.

Use worktrees once more than one thing is happening at once. Multiple checked-out copies of the same codebase let separate lines of work proceed without agents overwriting each other’s changes.

Learn to test, because this is the actual wall. Unit tests, integration tests, end-to-end tests, UI tests. Code can now be written at a price that keeps falling. Validating that code correctly is the part almost nobody budgets time for, and it’s the part that determines whether what you built survives contact with real usage.

Why this is the whole argument for a foundation

Every one of those five items is something a team ends up solving from scratch, one painful iteration at a time, on every new project. Authentication, roles and permissions, and auditability are the same three hard problems, over and over, regardless of what the app actually does.

That’s the actual case for building on a platform instead of rebuilding the foundation every time. Not because vibe coding is wrong to start with. Because the distance between “something that works on my laptop” and “something a business can depend on” is exactly the list above, and most people are paying for that distance in sleep instead of in time saved.

This lands differently depending on where you sit:

• The engineer is the one losing nights and weekends to problems that were already solved, just not by them, not yet.
• The CTO is the one deciding whether to let a promising prototype keep accumulating technical debt or bring in the scaffolding it needs before it’s carrying real revenue.
• The CEO is the one who finds out how much technical debt exists only when something breaks in front of a customer.
• The CFO is underwriting the actual cost of “nights and weekends,” which is never free, it’s just unbilled.

If someone on your team has been quietly grinding through this alone, what would it take for you to actually notice before the wall hits?