Ok so having done vibe coding myself, and having shipped product with it, I can confirm the LLMs are very useful. And still I want to blurt out something whenever I see another developer being blown away by LLM demo code.

There’s a wrong way of doing things, and there’s a right way of doing things.

Now what are the first time users doing? What’s even an experienced developer doing when learning something new via LLMs?

Having a coding conversation with the LLM until it goes off the rails.

Vibe coding development loop is:

• brain fart
• prompt
• copy paste
• run
• prompt feedback
• copy paste fix
• run again
• get psyched how fast you got “something working”

But notice your brain loop: brain fart -> get psyched by fast result. Your brain is stuck on the brain fart – you are too amped by the quick development loop – but your application is always going to evolve to the level of your understanding – or go the way the AI wants to go – which is just rehashing others’ ideas.

Your thinking needs to evolve

You need to understand what you are doing – you need to plan – you need a clean architecture. And then the development loop will be in your mind first:

• think what your users are doing
• think how the system fixes the problem
• think how you give the system an interface for the users
• think how to organize the code to make it easy to evolve (maintainability)

This part seems too big to think about, but for a professional coder who has done it many times over, it comes in a flash – it’s all muscle memory.

Maintainability was always important, but now that the code is being updated at warp speed using LLMs, it’s more important than ever.

and then put the plan on paper (or in documents)

• what you need to do
• what modules you make
• which modules you reuse from others (you did not reinvent the wheel my friend)
• how you glue them together
• where your application runs
• how you distribute

Now you are in professional mode – your head is fully wrapped around what you are doing – and now you can take your prompts to the next level

• spell out the full context
• ask for very specific bits
• leave the LLM no room to wiggle
• keep the context in focus

and importantly:

• write down the context from your head
• write down the architecture
• share with others
• make it easy to onboard others

Now you have 3 pillars:

• intentions (objectives, tasks)
• architecture and execution context (module breakdown)
• code – but that’s on you – and your git repo

You need to set the rails, seriously this time

In the past you’d talk to developers if you felt they did not understand some important context, and set them straight. You’d give them context all day, you’d recall context in meetings. But the LLM doesn’t go into meetings with you. You need to write down the context for it. And all constraints.

• start with the intentions, break down into tasks.
• think of an architecture – or better, get one from a professional who has done it – this is valuable.
• build up your code piece by piece using the architecture context – take the time to understand every piece.

THIS is the correct loop – when you get here and see something working, start iterating on the architecture – but still piece by piece, still enforcing the architecture and context with every prompt – never let the AI go off the rails.

Maintain clean code and a clean architecture.

Small modules.

Small functions.

Clear, unique and spelled out responsibilities.