Skip to content

ai · tech — OCT 6, 2026

How to Vibe Code

Don't set yourself up for failure.

Vibe coding has allowed non-technical people to create their own projects, which is great.

Though because they haven't coded before, they lack taste/discernment, meaning they are more likely to accept output from their AI tool of choice, that an experienced developer would reject, or not even let happen in the first place.

And these suboptimal decisions compound as more of them are made.

If 1000 decisions are made, and a non-technical person makes decisions that are on average even 1% suboptimal (if it could be easily quantified), you end up with a significantly worse product than they could otherwise have.

Not the biggest deal if the app/project is just a toy, but a lot of people are making things they want to become commercial successes, and for the group of vibe coders whose projects become a commercial success, many end up having to fix serious issues which is a time sink.

The most serious issue that happens a lot is security holes that end up leaking sensitive user/financial information (IBM's writeup on this).

But there's other issues like the app code being hard to maintain and make changes to, without breaking stuff.

There's things that can be done from the start that will save people from headaches.

Write a detailed spec first

Writing down in plain English what you want your project to do, will help you catch contradictions and problems in what you want the project to do.

Convert the spec into unit tests, and get AI to write the tests first

Write the tests first, then create the feature and get the tests to pass.

The fancy term for this is test-driven development, and building projects this way ensures that everything you build is tested, piece by piece.

Don't use JavaScript

If you're vibe coding, chances are you aren't really reading the code line by line, and when you're not closely paying attention to the code, you need to have more assurances that the code won't do certain bad things.

JavaScript (and Python) don't provide those guarantees before the code is run, and the code has to be run to find out if certain errors will happen, like accidentally trying to add a letter and a number together.

Languages that do provide this check (Rust and Java) for example will ensure certain issues never happen to your codebase.

If for some reason you need access to JavaScript libraries, use TypeScript at least so you have some guardrails.

What these things have in common, is that they all catch problems without you needing to pay attention and read the code.

The spec catches contradictions before any code exists.

The tests catch bugs before your users do.

Your choice of programming language catches mistakes before the code even runs.

And that's the answer to the 1% problem I mentioned earlier.

You can't review 1000 decisions as they happen, but each of these is one decision that reviews hundreds of others for you. Fight compounding with compounding.

You might not have the taste yet to judge what your AI writes, but you can build a system that judges it for you.

You might like

I Reverse Engineered a Popular iPad App With AI →