An article by our Managing Director recently appeared on the doubleSlash blog Konrad Krafft with the title Vibe Coding - The future of software development with AI. Konrad describes how AI can support you in the software development process. But his presentation goes beyond pure "vibe coding".
Vibe Coding
The term vibe coding was coined at the beginning of February 2025 by Andrej Karpathy, one of the founders of OpenAI, to describe a certain way of generating code with the help of AI. In a Contribution on X he writes:
There is a new way of coding that I call "vibe coding", where you give yourself over to the "vibe" [...] and forget that the code even exists. [...] I always accept everything, I no longer read the diffs. [...] That's not too bad for throwaway weekend projects, but it's still quite amusing.
Andrej Karpathy about Vibe Coding
More than just the vibe
At doubleSlash, however, apart from prototypes, we do not develop disposable software. The systems we develop usually run for years, if not decades. It is therefore essential that the code that is created is maintainable. For this reason, Konrad goes one step further in his article and describes the importance of the fact that the developers must retain control and steer the AI so that the generated code meets the quality objectives, such as for maintainability, architecture and security.
Vise Coding
For this approach Deep learning engineer David Farago in a LinkedIn post the term "Vise Coding" characterized:
[...] Vibe coding is neither maintainable nor sustainable, since technical
Debt accumulates rapidly with each iteration. [...] For production code and larger projects, we need a different approach with stronger guardrails for better code, test and documentation quality. I call this approach "Vise Coding": Like a craftsman's vise holds the workpiece in place while precision tools are applied, this methodology uses a comprehensive process to constrain and control the coding agent's output.David Farago
As Farago goes on to explain, part of this process is that appropriate tests are generated for any code that is created or modified. In addition, the AI is only ever allowed to make small, high-quality changes that are easy to verify and review. The documentation must also be adapted accordingly. In contrast to vibe coding, the code generated by vise coding is checked by the developer and either accepted or improved according to their ideas (this can also be done by the AI). The result is readable, maintainable code with comprehensive documentation. It is important here to communicate the requirements placed on the code to the AI as precisely as possible - e.g. that it should only make the explicitly described changes, that no duplicated code should be generated, that the code should take into account different environments such as development, testing and production, etc.
Vise Coding Dojo
The first time I came into contact with Vise Coding was in a Coding Dojowhere we wanted to try out this way of writing code. The focus here should be on the method, so we deliberately chose a simple task, namely the String Calculator Katawhich is intended for practicing test-driven development (TDD). The exercise is divided into 9 steps, which are to be worked through one after the other. The steps contain requirements that build on each other and are to be implemented one after the other, in each case without taking the subsequent steps into account. The TDD Cycle first write a failing test, then write the minimum code necessary to make the test pass, and finally clean up the code. After refactoring, the tests must still be green.
For our experiment, we used Cursor with Claude Sonnet 4. We fed the AI with the tasks step by step, using copy & paste without further instructions, in order to have it generate the solution for the respective requirement. Right from step 1, we realized that the AI was doing more than we actually wanted. Although it generated unsolicited tests, it also wrote the functional code directly, so that the tests ran successfully straight away. However, we wanted to take a test-driven approach, i.e. only generate the tests first and the functionality afterwards. We had to communicate this to the AI, which we did using cursor rules. We did not formulate these ourselves, but let the AI generate the rules for us. From this point on, it always generated the tests first and only implemented the functionality after we had explicitly confirmed it.
But the AI was still doing too much - since the String Calculator Kata is available on the internet, including many solutions on GitHub, the AI already "knew" the requirements from the next steps due to its training, and implemented some of the later requirements directly without explicit instruction from us. Therefore, we added another rule that prompted the AI to only implement exactly what we specified by prompt and to ignore what it already "knew" about the tasks itself. The process then worked the way we wanted it to.
Refactoring with AI
After implementing some requirements, we felt that a major refactoring was now required. The functionality was there, but everything was implemented in one long method. Again, we asked the AI for support and asked it what could be done to make the code more maintainable. It immediately responded with a whole list of measures, such as splitting the method into sub-functions, assigning more descriptive names and much more.
We decided to implement just one of the measures instead of all of them at once (remember: only small, manageable, high-quality changes). We made sure that only the production code was changed, but no test code. After all, the tests serve to uncover any errors that may arise as a result of the refactoring. If tests and production code change at the same time, you can no longer be sure whether a failing test may have been caused by a change to the test code.
We gradually shaped the code using prompt statements until it corresponded to our ideas. Here and there, we also initiated our own refactorings that had not been suggested by the AI (e.g. converting a data class that had been implemented by the AI as Javabean into a record), or assigned names that we thought were more appropriate than those generated by the AI.
In the end, we had solved the entire task, and the resulting code was maintainable and met our quality requirements. We hadn't written a single line of code ourselves, but had the AI do everything. What's more, we were finished much faster than in previous dojos where we had solved the same tasks by hand. All in all, we were quite impressed with how well everything worked.
Experience in customer projects
After that, I also experimented with Vise Coding in the customer project. Although I usually use IntelliJ, I also used Cursor for this - but only for the AI actions. Switching back and forth between the IDEs works amazingly well; both directly adopt the changes made in the other. So I can use the AI advantages of Cursor and still work in my favorite IDE. (I had also tested Jetbrain's Junie, but it was far too cumbersome for me, and the results were rather mediocre and not worth the long wait).
Tasks such as "create me a class Y based on class X" or "make the same customization as in class Z" were completed by the AI with flying colors, including the creation of the tests. However, auxiliary methods that existed in a test class were duplicated for a new test class; I had to give the AI explicit instructions for outsourcing the methods to an auxiliary class.
My conclusion
Ultimately, development with AI is no different from delegating tasks to team colleagues: the more precisely you specify what you want, the more likely you are to get the desired result. And at the end of any AI-supported activity, be it coding, generating documentation or architecture diagrams etc., you still need the "human in the loop": the person who carries out the quality assurance and has the necessary knowledge to do so.
The challenge over the next few years will be to pass this knowledge on to the next generation of developers while working with AI. However, the job of software developer will probably not be replaced by AI as quickly as some predict. But the tasks will change, away from handwritten code and towards prompting, maintaining AI rules and ensuring the necessary code quality. After all, AI-generated code is not automatically maintainable, operable or secure. And the results of pure vibe coding certainly aren't.
