Three months, 4000 commits, one architect. What working with vibe coding looks like.
In early 2026, I was part of a small team that built Cockpit — a management tool that helps organisations stay on top of their own design choices, roles, and priorities for transitio.nl. René had spent fifteen years developing the underlying concept, refining it through real organisational work. Harold from optimumconsultancy.nl took that concept and translated it into working software — understanding it well enough to turn it into input that an AI could build from correctly. I made sure what got built was technically sound. We delivered in less than three months.
My role was not to write the code or even design the architecture. It was to make sure what got built was technically sound — not just functional. That distinction matters. There are plenty of stories about vibe coded apps exposing credentials and sensitive user data.
The speed is real. So are the consequences.
Over those three months, the codebase averaged around 400 commits per week (actual statistic over 11 weeks: 4,265 commits). Functionality was built, adjusted, and extended at a pace that would have been impossible with a conventional approach. René could see his concept working within hours — screenshots of actual functionality, not a mockup. That is the genuine strength of vibe coding.
But Harold’s contribution was not simply prompting an AI. Translating a fifteen-year-old concept into features that an AI can build correctly is a skill in itself. Garbage in, garbage out — and getting the right output consistently requires understanding the problem well enough to describe it precisely. That is product translation, and it is what made the speed possible.
A traditional developer starts a new feature separately, takes time to shape it, and adds it to the application when it is ready. Vibe coding works differently: features are built directly in the application, one step at a time, without a consolidation phase. There is no moment where the developer steps back and asks whether the solution is the right one — only whether it works right now. Refactoring rarely happens. The same technical mistakes get made repeatedly, not because the developer is careless, but because the model has no memory of previous decisions. Dead code accumulates.
This is not the exception. It is the pattern.
Do these risks not exist in traditional development?
They do. But in traditional development, there are naturally more people with technical expertise involved. A developer submitting a pull request, a colleague reviewing it, an architect keeping an eye on the overall structure — that friction is deliberate, and each layer reduces the chance of something slipping through.
Vibe coding removes that friction deliberately. That is the point. The technical translation no longer slows things down, because the AI handles it. But that also removes the natural braking mechanism. You have to rebuild it intentionally — otherwise the speed is not an advantage, it is a risk waiting to surface.
The challenge of being the technical conscience
My role was not to write every line or be present at every decision. That would have negated the speed that makes vibe coding worthwhile. But it did mean I had to assess quality and security of code that had been produced at high pace, without having been part of every choice that shaped it.
That is a different kind of work from a standard code review. Normally you understand the context because you were in it — you were involved in the design or building related parts. Here, you have to reconstruct it from the result. If you think it is hard to get a developer to write documentation, trying to get a vibe coder to write a functional design before prompting away is at least on the same level.
To make that manageable, I developed an approach that has since become part of how I work on this kind of project.
The first line is an automated review bot: a workflow that uses Claude to assess each commit against known issues, and reports findings to an overview tool I built myself. The prompt is tuned specifically for the application — not a generic linter, but targeted at the patterns that actually appear in this codebase. Since I added the bot, around 75% of issues are resolved within minutes of the commit. Another 15% is registered as a potential problem for manual assessment. That leaves roughly 10% that requires a different approach.
Side note: the bot also revealed an interesting pattern. Not only did the model keep making the same mistakes — in some cases it actively reverted fixes the bot had introduced, only for the bot to fix them again. Sometimes this happened more than once on the same issue. The model was, in effect, in an argument with the bot about what correct code looks like.
The second line to catch the remaining 10%, a deliberate focus on defence in depth: ensuring that security layers operate independently, so a mistake in one layer does not immediately constitute a full exposure. And finally, a manual review at every release — not of every commit, but of the flagged issues together with a targeted check of the current state of the application.
Harold and I are also developing a concept for automated regression testing based on the same inputs used to drive development — a tool that runs end-to-end checks through a series of prompts, vibe tests essentially, consistent with how we envision application are going to be build.
What this means for how the team works
Harold framed it well: the ideal setup is a triangle — someone with ideas, someone who translates those ideas into features, and an someone who ensures the result is sound and safe. I agreed with that before we started, and I still do. But working it out in practice added something to that picture.
Just as “writing code” undersells what a developer does, “vibe coding” undersells what Harold does. And just as the architect’s role is more than a final sign-off, Harold’s role is more than prompting. Every position in the triangle requires real expertise — and the triangle only holds when each role is taken seriously.
The architect in that triangle is not a sign-off at the end. It is an active role throughout — and in a small team without dedicated QA, security specialists, or enterprise-grade tooling pipelines, that role has to carry more weight than it would in a larger organisation. We did not have existing layers of verification to fall back on. So we built what we needed, kept it proportionate to the scale of the team, and made it work.
Vibe coding removes technical knowledge from the development loop — deliberately, and rightly so. That is not the same as removing it from the project. Apply it where it matters, back it with the right tooling, and the triangle holds.