Vibecoding: Just another Bullshit Revolution?

If you follow LinkedIn, SEO-driven blogs or even some not entirely low-level magazines, they never get tired of proclaiming the new holy era of software development. One person starts to recreate Adobe and Microsoft apps, and after ten days our attention market yells about innovation and the end of the software developer.
Even in my digital signage niche, it feels like every week someone announces the next big SaaS thing.

The technique behind this is called vibecoding. It means creating code via an LLM or so-called AI agents and just checking whether it works functionally.

Do not get me wrong: As a producing soul, I fully understand the people behind these projects. They want to realize their ideas by themselves, no matter whether they are skilled or not. I wrote my first published software in 1998 without deep C++ skills, too. It was a DJ software. Finding a solution with your own tools is something to respect.

What I hate is the brainless army of followers hyping a technology they do not understand, creating wrong expectations that lead to more crappy software and security leaks. Only fools believe smart tools will replace years of knowledge and experience.

Let's dig into the dirty, ugly details of LLM coding.

Example Photoshop / PhotoCraft

ArtCraft is a typical example: a vibecoding attempt in Rust to replace the Adobe Suite with a 1:1 open source clone. PhotoCraft is the counterpart to Photoshop. At first sight, everyone is baffled by the speed and asks: Wow! How can one person achieve this in two weeks? All the Adobe apps, and now he even starts recreating the Microsoft Office Suite.

Let's use Photoshop as an example and pose a heretical question first:
GIMP has been around for 30 years and has a huge community of users and programmers. It is great software, but it still can't hold a candle to Photoshop.

Why? Do you really think a whole generation of skilled developers and enthusiastic supporters is not smart enough to copy Adobe's user interface and functionality and create a working clone?

What about companies selling paid software like Affinity, Pixelmator or Luminar? Why do they just place themselves in specific usability niches? Because they cannot compete with Adobe. Do you believe it is just the programming budget?

This is the curse of the 80 % rule. If you start a new project on a greenfield, reaching 80 % is fast. Getting the remaining 20 % will consume most of your time and energy. Now we have the absurd situation that LLMs radically reduce the time needed to reach the 80 %. Even for non-programmers.

I find companies like Adobe and Microsoft deeply unlikable, and their licensing models remind me of mafia movies. But they've been refining their processes since the '90s: making mistakes, fixing them, investing time and money, gathering customer feedback, analyzing it, judging it, improving usability, and so on and so forth. They spend millions on processes, knowledge, retaining knowledge, structure, industrial scaling, and so on.

Even though many people complain about prices and behavior, the result of all these investments seems to be so useful that almost every agency or freelancer I know can't do without it and grudgingly pays whatever is asked.

Why? Because every clone has to deal with, among other things, the following points:

• File formats: PSD is a format that has evolved over 30 years and is only partially documented. Smart Objects, layer effects, adjustment layers... Opening a PSD file is a piece of cake; losslessly round-tripping one is extremely difficult. LLMs only know what is publicly documented.
• Color management: ICC, CMYK, soft proofing, prepress. GIMP and Scribus have been struggling with this for centuries.
• Performance: Gigapixel files, tiling, GPU pipelines, memory management. This requires years of engineering work. This is not something that can simply be generated.
• Video codecs: H.264, HEVC, and ProRes involve licensing and patent issues. LLMs can't solve that.
• Ecosystem: Plugins, actions, scripting, and workflows with agencies and print shops. These points are exactly the parts of the remaining 20 %.

On top of that, there are two legal risks. First, patents: they apply to every clone, no matter how it was written. If Adobe finds a patent issue, the project will be dead faster than from technical debt.
Second, copyright: PhotoCraft calls itself a clean-room reimplementation. But an LLM trained on Photoshop documentation, forums, and presumably reverse-engineering material can hardly be called a clean-room implementation. So the clean-room claim doesn't protect anyone. A hanging sword of Damocles.

But for all the "AI" gurus, it's crystal clear 10 days after project start: A Rust programmer starting from scratch will soon make decades of industry knowledge and experience completely obsolete.

This is ridiculous and wrong in so many ways that every cell in my body starts rolling its eyes.

PhotoCraft's statement: "Image editing; an open-source, clean-room reimplementation of Adobe Photoshop, rebuilt in pure Rust. Layers, masks, adjustment layers, layer styles, type, vectors, brushes and real PSD files, in a native app written entirely in Rust. Open source, offline, and yours."

The famous German c't magazine tested the apps and, among other things, came to the expected conclusion. It says clearly: Nope!

"... for professional workflows involving existing project files, such as those in agencies, the tested versions are not a reliable substitute for the originals. That's because reliable data exchange and stable day-to-day use are crucial in such scenarios. Anyone trying them out should not work with production data.

Source: C't Adobe alternatives in test in German and unfortunately behind a paywall.

The vibecoded PhotoCraft just sped up the 80 % GIMP has had for centuries.

Why are people so excited?

The development speed attracts huge attention. Users observe software differently than programmers do:

• No one reads the code. Users evaluate the interface, the feature list, and whether it works for them. That's where it shines.
• A frequent release cycle creates reasons to market. The biggest fear in software is a dead project. Weekly releases say, "Things are happening here," even if they are just fixes for the previous week's bugs.
• Fast support beats bug-free code. That's the weird part. Anyone who reports a bug and gets a release with a fix on the same day is thrilled. They don't realize that the bug shouldn't have happened in the first place.
• Stars attract stars. If you see a repo with 200 stars, you trust it more than one with 20. This is a self-reinforcing cycle, regardless of quality.
• Many people simply don't care about LLM code. The question "who wrote this?" is asked mostly by developers, not users. Users do not look at god classes, missing schema versioning, duplicated code, hundreds of empty catch () bodies etc.

A simple rule: The costs of complexity do not increase linearly. LLMs push back the tipping point but do not eliminate it.

What can go wrong in concrete terms?

• GitClear has analyzed millions of lines of code: Since the advent of AI assistants, the proportion of duplicated code blocks has risen significantly, while the amount of refactored code has declined.
• DORA Report 2024: The report estimates that a 25 % increase in AI adoption would result in approximately a 1.5 % decrease in throughput and a 7.2 % decrease in stability.
• METR 2025: Experienced open-source developers were measurably 19 % slower with LLMs but believed they were 20 % faster.
• Technical debt: It is just a matter of time until vibecode breaks.

LLMs provide programmers, but no architect, no experienced reviewer, and no one to say "no." All of that lies on one person. With 100 virtual developers, the bottleneck isn't the writing. An engineer needs to understand what has been written. This is the consequence of not using skilled humans you can trust. That doesn't scale with computing power, only with time and a well-working team of human experts.

We will scale with more and better AI!

Sorry, this will not work and can make things even worse. Let's make it more concrete: you have a god class with 5000 or 6000 lines of code. At first sight, this fits perfectly into an LLM context.

• Where do you set the boundaries? The LLM can split godclass.js into ten files. Whether those splits make technical sense must be decided by someone who understands the system. Otherwise, you'll end up with ten little "god classes" that import each other.
• Hidden coupling. Let's say godclass.js is a database class with a module singleton that half the server accesses. If you break it down, the initialization order and shared state change. Such errors only become apparent at runtime. Btw.: I had something similar years ago. Even without an LLM.
• Behavior must be preserved. Refactoring is only as safe as the tests capturing the old behavior. If they are just duplicated or use handwritten schemas, which LLMs love to do, you test the tests and not the changed database.
• A moving target. With hundreds of commits per week, the code is already different again during the refactoring. You have to pause feature development to clean things up. I had this situation 11 years ago. We needed two skilled people almost two years to clean up my feature-adding mess.

LLMs can refactor. What they need is someone who knows where to go and who is willing to hold off on delivering anything new for a while. That's where the real bottleneck lies. The technical debt and every wrong architecture decision in the first weeks will turn high-speed development into snail speed. That's nothing new and has happened for centuries. LLMs just produce it much faster.

Example Digital Signage

My niche industry has a similar phenomenon. The already high number of solutions has been growing dramatically ever since vibecoding became popular, and every week there are posts about new apps or updates.

For digital signage, one more point gets added to the list of why people are excited: no one bears the risk at first. Most people test on a Raspberry Pi at home. If it breaks, nothing is lost. The cost only becomes apparent with installations where a black screen costs money.

The real challenge will come when the first people try to upgrade from version 1.x to 2.y and something goes wrong, or when a firmware update from a manufacturer breaks a player. A broken player means an on-site technician, a ladder, and travel expenses, per device.

I had this in a 2014 project by my company. A reseller built their own player, underestimated the write cycles of USB flash and sold around 500 units. After one year, their customer needed to fix 10 to 20 devices every month, at around 300 EUR for a technician driving to the location.
To save the flash, they stopped writing logs and play reports. For someone who wants to sell advertising space! The fix killed the reason the network existed. It took them three years to replace the devices.

This is a real-world example of what a single, simple, poor architectural decision can lead to. It was made at the outset, and no one questioned it. This is precisely the role that's missing in vibecoding: someone who says no.

Now imagine thousands of players around the world running old versions and outdated protocols, customer databases with legacy schema issues, self-hosted servers no one has control over. You can refactor your own SaaS server, but not the external installations.

That's just a gamble on the backs of the user. I wouldn't bet one cent on heavily vibecoded software. Not because the LLM couldn't do it, but because the right time to clean things up never comes in this model. And because in industries like digital signage, the debt isn't just in the code. It is also on the devices at the customer's site.

How to work with LLMs?

1. Slow Set rules and keep it on a short leash. Insist on tests and avoid duplication in code and tests.
2. Discuss I like to discuss approaches and best practices with two LLMs first, until I fully understand what has to be done.
3. Small pieces Don't get impressed by the speed of creation. Look at what it does. LLMs love to repeat themselves, overengineer patches, and write unit tests that just test themselves.
4. Refactor with a clear target You tell what the structure should look like. The LLM does the legwork across many files. That's its greatest strength, and it saves you time.

In short: Try to understand what you do and why it must be done.

Where it pays off

• Boilerplate code and platform miscellany CRUD hub, configuration dialogs, translations, documentation.
• Bug triage Someone submits a report. The LLM finds the affected area and suggests a fix. But you decide, after understanding it.
• Sparring You can learn new concepts, ideas, ask questions, and repeat things for validation. It's much less frustrating than getting dragged into StackOverflow discussions full of "you-noob-you're-holding-it-wrong" attitudes.

Areas where you should remain cautious

The core functionality is dangerous. In my software, for example, that is timing, memory management, and anything written in C++ that involves threads or media pipelines. That's where LLMs generate plausible code that behaves differently under load. That's exactly where your experience comes in.

Realistically, you might be able to double or triple your output without sacrificing quality. Not at the pace of the hyped unicorns with thousands of commits in weeks, but at a pace that's noticeable and sustainable in the long run.

Bullshit or not?

If you ask me, this is a new era, but mainly driven by a loud bullshit revolution of wrong expectations and lack of education. You need to learn how to use these new tools wisely. Just optimizing production speed may attract attention and look stunning, but it also raises technical debt. The price will be paid by users, customers and, finally, by decreasing trust in “professional” software development.

I made similar mistakes 11 years ago, thinking adding features is the only factor of success, and paid a high price to correct this. At least I had the opportunity to learn and fix it. I do not believe today's vibecoded projects will survive the current gold rush long enough.

The big, not so hidden secret:
Successful software means far more than just writing features.