Vibe Coding: What We Learned from 291 Sprints 🛠️
"Vibe Coding"—letting an AI write the code while the human guides the process—sounds like a developer's dream. Since KnotenCore was built entirely this way, we have had plenty of time to experience how this actually works in practice. Here is a realistic look at the limits, the bugs, and what we learned.
1. Prototypes are easy, maintenance is hard
Getting a prototype running is surprisingly fast. You describe a basic stack machine, and the AI generates a working loop in a few prompts. It feels effortless.
The drawback is that because you didn't write the code line-by-line, you don't know it inside out. As the codebase grows, it becomes easy to lose track of how different parts interact. If you aren't careful, you quickly end up with a pile of code that you can no longer explain or maintain.
2. You cannot prompt away real bugs
When a bug occurs in a JIT compiler or a VM runtime, simply typing "fix the bug" rarely works. If the AI doesn't understand the root cause, it will often suggest patches that just hide the error or break something else.
For example, when we encountered register emission typos in our arithmetic operations (Sprints 282 and 291), we had to carefully look at the emitted x86_64 assembly, isolate the registers, and point the AI to the exact logic error. You still need to understand how the system works under the hood; the AI just acts as the keyboard.
3. Tests are the safety net
Working this way without a strict test suite is close to impossible. Because the AI can rewrite entire sections of a file in seconds, it is very easy to introduce regressions.
Our test suite (now at 224 checks) was the only reason we could keep making progress. If a change broke the VM state or the sandbox logic, the tests failed immediately. It gave us a clear, objective boundary: if the tests aren't green, the prompt wasn't successful.
4. A different kind of effort
Vibe Coding isn't a shortcut to avoid thinking. You spend less time memorizing syntax, but much more time reading code, writing tests, and figuring out the architecture. It is a partnership where the human has to stay critical, ask the right questions, and know when to say "no" to a generated solution.