Vibe coding is fine. Then the engineering starts.

Adapted for KLOD from an essay first published on 2 Jun 2025. This edition was updated on 11 Sept 2026.

Vibe coding makes it easier to try an idea. Describe what you want, work through a few revisions with an assistant, and you may have a useful prototype by the end of the afternoon. Once customers or colleagues depend on it, you also need to understand what happens when it goes wrong.

Andrej Karpathy's account of building MenuGen, published on 27 April 2025, is a useful example. He shipped an app people could pay for, with a 10% markup. Getting there meant dealing with roughly 1,000 lines of code using apparently outdated authentication APIs and correcting a payment flow that matched customers by email instead of a stable user ID. He also described requests timing out because the app didn't save its work in a database or process it through a queue.

Those are the kinds of problems a working demo can hide. Finding them takes someone who knows which questions to ask.

What changes when people depend on the software

Before shipping, check what happens if a request runs twice, whether one customer can access another's records, and whether retrying a payment could charge someone again. If a transaction stops halfway through, the person investigating needs to see what happened and have a way to finish or undo it.

An assistant can help write the code and tests, but someone still has to check that they cover the right behaviour. A junior developer needs a reviewer who knows the system and can explain these decisions. Give them that support and time to learn from the review.

Using AI to write code is different from running your business on it

When an assistant writes code that nobody on the team understands, maintenance becomes difficult. That can happen even if the finished product never calls a model.

When the product itself calls a hosted model to answer customers or approve invoices, losing access to that model can stop the business process. This is the dependency KLOD addresses. The scope guide explains what the klod-check skill assesses.

Your team may face both problems. Code review helps you understand and maintain the software. A tested manual path gives people a way to keep essential work going while the model is unavailable.

Build the takeover into the feature

Suppose you're building a support tool that drafts replies and closes straightforward tickets. A support agent also needs to be able to open the original message, check the customer's account, claim the ticket and send a reply themselves. If the model finishes its draft later, that result mustn't overwrite the person's decision or close the ticket again.

This affects the data model, permissions and interface, so include it in the feature's acceptance criteria. The implementation guide explains the design choices, and the verification guide covers stops, retries and late results.

Try this in your next review

For a feature that uses AI at runtime, ask the author to show three things:

1. A normal request completing correctly.
2. A request failing halfway through, with a clear record of what's been done and what's still pending.
3. A colleague using the manual controls to finish the work with AI unavailable.

Give the colleague the instructions and tools someone would actually have during an outage. Let them try it before explaining how it should work. The places where they get stuck will show you what needs improving.

That exercise also takes time and practice. The next post looks at how to keep your team ready to take over.