Vibe Coding? Sure, But Strategically!

Marketing experts create their own small apps. Software startups are founded by people who have no idea about software creation. And in the private sector, experiments are booming.

Systems like Lovable, Cursor, ChatGPT Codex, Gemini, or Claude Code make it possible: Simply write a short prompt and you immediately get a website, an app, or another piece of software that does exactly what you want, and it looks great too. OK, mostly it doesn't work right away, but two or three correction prompts and you get very close to the desired result.

Nevertheless, more complex developments require much more.

Of course, I also experimented with it and was more than amazed: Spending a day thinking about what an application should do. One day in dialogue with Lovable. Two days of debugging, so telling Lovable which errors it needs to fix.

The result: A functioning system for which I would have needed a team of three developers and three months of time in my previous companies. It was quite fascinating.

Even among the AI managers I am currently training a lot, enthusiasm can be felt when they make their first attempts. And indeed, anyone can do it.

You don't believe it? Then just try it out:

* The restriction to HTML, JavaScript, and CSS ensures that everything works in the browser without a server in the background

That can be quite impressive and is definitely sufficient for such small apps, but not if you want to develop larger applications and systems. But there is help for that too.

Yes, it is very easy to create a functioning app with a short prompt. But is that enough? For years, I ran companies that developed software. I have contributed tens of thousands of lines of code myself (qualitatively it was never the best part) and I hold a certificate as a software architect.

I wouldn't want to miss this experience. It helps me with vibe coding to ensure that systems are sensibly designed, to understand the technical terms, to recognize errors, and to discuss with the LLM.

All of this is helpful, but not everyone has or needs this background nowadays. In fact, AI systems are often able to write quite good code at an acceptable security level. I was particularly surprised by the security features after my first attempts.

But it is also true that AI systems that assist with coding still too often deliver poor performance.

With small apps, that might not matter. If more complex systems are developed, the problems accumulate and fall on your feet sooner or later. A productive system cannot be developed this way.

The systems possess incredible knowledge, of course also about good software development. However, they only bring it to full bloom if you guide them to do so. Over time, the following practices have turned out to be quality boosters for me:

Plan it yourself

Of course, you can give an LLM a very vaguely formulated prompt for the creation of an app. The systems independently add what is missing based on assumptions. These can of course be completely wrong, and you lose control over the development with this approach. It is better to think about the different modules, functions, and especially the data structures in advance. Then visualizing everything graphically on a large piece of paper is very helpful.

Plan together

Even if everything is on paper, implementation doesn't start immediately. More complex systems are developed step by step, not in one go. Here we can use the best-practice knowledge of the system. So, we first upload a rough description of the app we want to build and ask for help via a prompt:

"Before we start the implementation, let's discuss the project. What questions do you have? What comments and suggestions for improvement do you have? How would you plan the implementation step by step?"

This discussion usually brings significant improvements to light.

Even if you go into detail later and develop your app module by module, it makes sense before each programming step to first outline the next step and then ask the questions mentioned above. This allows the LLM to bring its qualities into the planning phase and avoid gross errors.

Let them develop

When a joint plan is in place, you can give the system the command to execute the development step. Here, too, it can be useful to rely on dialogue, for example, if you add:

"If there are difficulties at any point or a decision on different ways of implementation is necessary, stop the development, inform me about it, and let's find the best solution together."

Testing

Actually, it goes without saying, but I would like to mention it anyway. After each coding step, the newly created modules and functions should be thoroughly tested. It is normal that not everything works as desired right away. Then you can eliminate the errors step by step in dialogue with the LLM. It is often important to report back messages from the browser console, which you can access via the browser menu and the tools for web developers.

Making principles of good development mandatory

There is a whole range of software development principles that lead to good and secure systems. In general, the LLMs know them all, but they are rarely in place. You have to actively make them the basis of the joint development. For this purpose, I have developed a Markdown file that I give to the developing system along the way**. To do this, I save it in the project and refer to it. Or I explicitly upload it with a prompt. You can download the file here:

https://empowerment-team.berlin/download?f=CONVENTIONS.md

Anyone with a developer background will recognize much of what makes code better and more secure. For those who have had little or no contact with it so far, it is worth reading to gain a more fundamental understanding. Especially for the latter, I have added point 15.

Refactoring

Despite all the measures described so far, the resulting code will not be optimal. This is also the case with human developers when corrections are repeatedly integrated. Then, after development on a module is completed, a revision of the code is necessary, in technical jargon "refactoring". LLMs are excellent at this again if you send the following prompt:

"Review module [Name of module] to see how refactoring can lead to better performance, higher security, or better coding style, keeping the principles in CONVENTIONS.md in mind. Then execute the refactoring." (Yes, the systems often "forget" that CONVENTIONS.md exists.)

Learning and further development

I have already mentioned point 15 in CONVENTIONS.md. It is the instruction to show small "learning units" to you from time to time. The more you learn about good software development, the better your solutions will become.

Another exciting possibility arises when you have been developing together with the LLM for a while. Then simply ask the system:

"You've known me for a while now from our collaboration on this app. Give me feedback on how we can improve our collaboration: What am I doing well? What should I improve? What are you missing in our collaboration?"

The answer will definitely be helpful.

Human Review

Everything mentioned here is definitely not enough to transition a system or an app into production. It requires a whole lot of tests and a review by experienced software specialists. If you apply the tips from this article, you will at least produce code that is easy to read and understand. A basis for transitioning into a production system.

The hurdles to creating your own small apps, websites, or even more complex systems yourself have fallen to a historically low level. The costs are also manageable. As a rule, the entry-level tariff of an LLM is sufficient to start the first exciting projects.

Just try it out!


** Some of the content is inspired by an article by Noah Byteforge, which summarizes the essential points well: Why Mission-Critical Engineers Write Code Completely Differently (And Why Their Systems Don’t Wake Them at Night)