Vibe coding as an architectural feedback loop

Vibe coding is often understood too superficially: fast, slightly chaotic code writing with AI help. Some copy-paste, some prompting, some luck, deploy, and then a prayer to the gods of observability. Good AI-assisted development is not the absence of discipline. It is a different discipline.

It is fast development with very short feedback loops, where the goal is to reach a working solution quickly while constantly listening for where the system resists. AI is not only a code generator in that loop. It is also a mirror for context, architecture, and the unclear parts of the developer's own thinking.

My workflow does not start with the command: build this feature. First I ask the agent to explain part of the existing code or behavior. Not because I do not understand it myself, but because I want to see whether the LLM is even standing on the right part of the map.

This is context priming. The model has to walk through the existing files, relationships, naming, data flow, and implicit decisions in the system. If it can explain the current flow well, it is much more likely to make a safe change inside it. If the explanation becomes generic, I know it does not have enough context yet.

The most interesting phase comes when I see the model drifting in the wrong direction. It adds too many wrappers. It glues functionality onto the side. It creates special cases. It adds fallbacks that smell like fear. At that point I do not squeeze harder. I ask it: I can see something is bothering you, what is wrong?

That is my AI therapist moment. I change the model's role from executor to diagnostician. Instead of forcing it to keep trying to satisfy the task, I let it explain why the solution does not sit naturally inside the system. Very often, an architectural truth falls out: the wrong service owns the responsibility, an abstraction is missing, the data flow is wrong, there is too much coupling, or the feature simply does not fit the existing foundations.

The best part of this way of working is not typing speed. The best part is that the LLM becomes a sensor for architectural friction. When it can solve a task elegantly, the system is probably well aligned. When it starts complicating, hiding problems, or gluing on detours, that is a signal that we need to look at the foundations.

That is why vibe coding, for me, is not YOLO programming. It is collaborative development with very fast feedback loops: warm up the context, align the frequency, execute, observe friction, repair the foundations, then implement the feature. A little psychology, a little architecture, a little sandbox. And just enough humor that the services do not start booking therapy for themselves.