← All articles (in German)

· Ralf Westphal

Vibe coding is a spectrum

What non-programmers can build themselves with AI – and where they need professionals

Today, users can program for themselves with AI assistants such as Claude Code or OpenAI Codex; users can develop software solutions for themselves and the people around them. What used to be reserved for professionals is now, in principle, possible for non-programmers. And there is no limit to it. In theory – that is, with enough curiosity, courage and perseverance – anyone today can build any software their heart desires, all on their own. Depending on the problem a program is meant to solve, it just costs different amounts of time and nerves – and, yes, tokens. Compared to the past, however, that is still dirt cheap.

The software world has been turned upside down. Or you could say it has come back to where it once started. Seventy years ago, too, it was the users of software who developed software for themselves (in German); in fact, they were the only ones who could. Back then, however, they were exclusively professionals – engineers and scientists – because only they had access to computers.

Today, non-programmers can develop programs as users, too. They do it with “vibe coding”: they describe to an AI what kind of program they want, and the AI generates the code it takes. The user then tries out the result straight away and tells the AI what still needs to change. And so on and so forth. The user can, so to speak, have improvements developed “by feel”. This usually happens so fast that they stay in a flow in which instructions to the AI, implementation by the AI and assessment by the user alternate within minutes.

It is astonishing what programs non-programmers develop this way! And all of them are tailor-made. Consumer and producer are the same person: users as prosumers. This has been an option since early 2026, thanks to progress in AI assistants – AI that runs on the user’s desktop and, with AI agents working in parallel, can also handle very extensive tasks with long processing times.

Illustration headed "From 2026 also an option: vibe coding – users build their own tailor-made software" (labels in German): an enthusiastic woman at a laptop, surrounded by idea, prompt, result and adjust, with a stamp reading "ideal scenario"; next to her a stack of database, workflows, integrations and user roles on crumbling sand

This picture stands in stark contrast to the world before 2026. Until then, users depended on professionals for the vast majority of programs that would have been useful to them. At best, they could make do with Excel, which they souped up with complex formulas or the occasional bit of VBA code. Here and there, so-called low-code or no-code tools were already in use, but real democratisation of programming had not been achieved.

Professional programmers were therefore regularly overloaded, and users were annoyed. Every change request took a long time to be implemented – if it ever got that far.

Illustration headed "Until 2026 the only option: commissioned development" (labels in German): an overloaded developer at a laptop, surrounded by stressed colleagues, next to a stack of feature requests, changes, bug fixes, new requirements and feedback

Since the late 1960s, this has been called the “software crisis”: the number of software wishes has always far exceeded the number of people who could fulfil them. There was a notorious shortage of software solutions, especially small and medium-sized ones. The result: standard software of one kind or another.

The drawback of standard software: it is, well, standardised. Users have to adapt to it instead of the software following the user’s needs. And the business model of every standard software vendor could only be to keep expanding the software in order to attract new users. Whether existing users appreciated this expansion was another matter. Many did not (or no longer did) as standard software grew older, bigger and more complex. The result: bloatware, i.e. inflated software with functionality of which each individual user only ever benefited from a small part. Users had to pay more and more money for features that were of no use to them – but had sounded good in a brochure.

No wonder vibe coding is now felt to be a great relief wherever people have understood it. Users feel empowered. An end to depending on standard software or sluggish IT departments!

This feeling is justified for many small and medium-sized applications. Yes, with AI, users today can build many tools themselves, for fun and profit. However … it is also easy to overestimate yourself, and the AI does not reliably point out these pitfalls.

The same illustration with a stamp reading "Caution!" (labels in German): the woman tearing her hair out, surrounded by error messages, conflicts, a failed build and the collapsing stack of database, workflows, integrations and user roles

Over time, vibe-coded programs can take on functionality or a scale that makes it hard even for AI to keep maintaining them, or to make them reliably usable at all. What was meant to be a tool for a few colleagues in the department is suddenly in demand across the whole company with hundreds of employees? Is it built for that – can the AI rework it? Are the problems obvious straight away, or do they only surface later, after having caused errors that are hard to correct?

What started as fun can then also turn into great frustration.

Not to mention keeping track of a growing number of self-developed programs across many workplaces. The risk of a new shadow IT, as seen before with Excel and MS Access, is real.

However great its potential, vibe coding needs a sense of proportion. Non-programmers cannot have that. That is why we recommend a more nuanced view.

Infographic "Spectrum of modern software development with vibe coding" (labels in German): five stages from "more pro" to "more user" – commissioned development, guided development, accompanied self-development, bootstrap and handover, and vibe coding – below them the degree of involvement of pro and user and the growing share of vibe coding

For us, vibe coding is one option in a spectrum. In our article on the vibe coding traffic light (in German), we already showed that vibe coding does not work the same way for everyone.

We think that software development really no longer has just one option: the professional developer.

  1. There will still be software that is purely a job for professionals. But its number is shrinking in absolute terms, and even more so relative to other categories of software.
  2. Then there is software where pro and user co-create and develop together – the non-programmer with vibe coding, possibly only in certain areas of the software (e.g. the user interface).
  3. Or the user takes on the lion’s share of development, while the pro stands by with help and advice when there are problems or larger changes are due.
  4. Especially at the start, we see a pro in action again and again: they set up a software project so that afterwards it “runs on rails” for the non-programmer as far as infrastructure, deployment and some non-functional requirements (e.g. security) are concerned.
  5. But there will also be many, very many programs that users simply build themselves. Especially in larger organisations, however, this will require a framework that, by its very structure, ensures internal guidelines are followed without professionals having to be called in again and again.

In such a spectrum, vibe coding is an important option for using AI in a company. AI itself can do tasks; far more often than first thought, however, AI can build tools that help get tasks done.

The willingness and ability to allow vibe coding for developing tailor-made solutions is an important factor in a company’s future viability.