Why AI-assisted coding needs a loop, not a vibe

As I’ve gotten deeper into building sustainable workflows for sim racing mod development, I’ve started thinking a lot about where AI coding agents actually fit. Not as a replacement for the core work, but as a way to handle the scaffolding, glue, and configuration around it. The more I’ve explored that, the more my thinking has shifted toward security, and not just in the usual sense. I mean the security of unintended consequences. How do you keep a goal-seeking agent from taking legitimate access and using it in ways you never intended?

I’m not a developer in the formal sense. I’ve always been more of a script monkey, someone who can learn quickly, spot useful patterns, and apply them well enough to move something forward. But I also spent enough time in product work to know that success usually does not come from magic. It comes from planning, iteration, clear ownership, and a system that is understandable enough for someone else to pick up when needed. That made me start asking a different question about AI-assisted coding. Not whether it can produce code. It clearly can. The real question is what kind of process keeps that code useful, safe, and supportable over time.

A lot of the conversation around AI-assisted coding gets stuck in two extremes. One side treats the tools like magic. They are fast, the output looks impressive, and anyone who asks hard questions is apparently just behind the curve. The other side treats the whole thing like a joke. Neither framing is especially useful. The more serious question is whether these tools can fit inside a sane engineering workflow without making the codebase harder to understand, harder to support, and easier to break.

That is where the idea of blast radius comes in. How far can one bad change spread? How quickly can it spread? And how much effort will it take to figure out what happened once it does?

That is why I think the best way to talk about AI-assisted coding is as a loop. Propose, verify, correct, repeat.

Not a magic prompt. Not a one-shot generation party trick. A loop.

The model proposes something. The surrounding process tests it, challenges it, constrains it, and makes it earn trust. Then the cycle starts again. That shift matters because it moves the focus away from what the model can do in isolation and toward what kind of process keeps the work actually useful. In real software, speed only matters if the output stays understandable, reviewable, and supportable after the novelty wears off.

That is also why I do not think the right response to vibe coding is simple rejection. Vibe coding has its place. It can be useful for exploration. It can help turn a fuzzy idea into something visible. It can create momentum when you are still figuring out what the thing even is. But once code starts moving toward production, the workflow needs stronger bones. The AI can help generate. It cannot be the whole method.

Software still depends on version control, tests, review, documentation, rollback, and clear ownership. None of that stops mattering because the code came out fluent on the first pass. If anything, those guardrails matter more when the first draft looks convincing.

There is also a lesson in recent incidents involving goal-seeking agents and unintended behavior. The deeper issue is not just that a model did something surprising. It is that the surrounding system gave it enough room for the surprising path to matter. That is a failure of imagination, but it is also a failure of boundaries.

That same issue shows up in coding all the time, just with quieter consequences. AI-assisted development should not be judged only by whether it produces code that appears to work. It should be judged by whether the code can still be understood by someone who was not there for the prompt. Can the next engineer make sense of it? Can the team trace the dependencies? Can the change be rolled back cleanly? Can someone explain why the code exists, what assumptions it makes, and what else it might affect?

This is where the loop earns its keep. In a healthy AI-assisted workflow, the model proposes. Tests, review, static analysis, and human reasoning verify. Weak spots get corrected. Then the cycle repeats. That loop is not overhead. It is the thing that makes the workflow credible. Without it, teams are left with fluent output and borrowed confidence. With it, they at least have a chance of producing software that stays legible when things get messy.

This is also where the conversation around senior and junior engineers gets muddled. Senior engineers tend to care about maintainability, rollback, debugging, architecture, and security because they have seen what happens when those things are ignored. Junior engineers are often being sold a different promise. The pitch is that AI will help them move faster, do more, and close the gap. There is some truth in that, but only if the workflow teaches judgment instead of bypassing it.

That distinction matters. The value for junior engineers is not that AI magically grants seniority. The value is that a well-structured loop can expose them to better habits. Tighter decomposition. Stronger verification. Clearer reasoning. More explicit thinking about what makes a change safe or dangerous. Used that way, AI is not a shortcut around learning. It is a surface for learning, provided the surrounding process does not let fluency masquerade as understanding.

There is also a security undertone here that is hard to ignore. AI coding tools expand the attack surface in subtle ways. Generated code can be insecure. Dependencies can be unverified. Secrets can leak into prompts, logs, or output. Over-trust can move bad assumptions downstream faster than a normal review process can catch them. So good AI workflow design is not just about generating cleaner code. It is a control surface. It is a way of shrinking the blast radius before a mistake becomes a reliability problem, a security problem, or a long-term support problem.

The deeper point is simple. AI only becomes trustworthy when the workflow around it keeps the blast radius small.

That is why this is not really an anti-vibe-coding argument. It is an argument for discipline. If AI is going to help write software, then the surrounding process has to keep the software understandable, the changes bounded, and the failure modes local. That is not anti-innovation. It is what responsible engineering looks like when the tools get faster than the judgment around them.

That is the line worth holding onto. Reduce the blast radius, and the rest of the conversation gets clearer. The tools get safer to use. The code gets more supportable. The workflow gets more teachable. And AI starts to look less like a party trick and more like something an engineering team can trust.