Is Vibecoding a Revolution or a Bubble? A Veteran Developer Breaks Down the Truth About AI Programming

As LinkedIn and tech blogs once again celebrate "replicating the entire Adobe suite in two weeks by one person," a developer with over twenty years of experience in the digital signage industry pours cold water on the hype. Using his Photoshop clone project PhotoCraft and the test results from German magazine c't, he dissects the real structure beneath Vibecoding's glossy exterior—and the costs that are deliberately ignored.

What Exactly Is Vibecoding, and Who's Pushing It

Vibecoding refers to generating code with LLMs or so-called AI agents, only verifying that it "works" at the functional level, without delving into code quality or architectural soundness. The author doesn't deny the appeal: he himself released DJ software in 1998 without deep C++ expertise, understanding that urge to "build your idea with your own tools."

What really irritates him are the mindless followers—people who don't understand technology yet create false expectations, producing more shoddy software and security vulnerabilities. "Only a fool believes a smart tool can replace years of knowledge and experience."

LLM (Large Language Model) and AI Agent are the two core tool concepts in Vibecoding. LLM refers to neural network models trained on massive text corpora that can generate code (like the GPT series, Claude, etc.); AI agents are systems built on LLMs that add planning, tool-calling, and execution capabilities to automatically complete multi-step tasks. The author emphasizes that these tools excel at learning patterns from public corpora, but are powerless when it comes to undisclosed proprietary protocols, patented algorithms, or knowledge that exists only in industry practice—which is precisely the fundamental limitation they encounter when cloning complex software like Photoshop.

The 80% Curse: LLMs Only Accelerate the Easiest Part

The author uses ArtCraft and PhotoCraft as examples. The latter claims to be a "clean-room reimplementation" of Photoshop in pure Rust, supporting layers, masks, adjustment layers, and real PSD files. At first glance, the speed is astonishing.

But a heretical question arises: GIMP has existed for 30 years with a massive community and still struggles to match Photoshop; commercial software like Affinity and Pixelmator only carve out niches. Could an entire generation of smart developers have never thought to clone Adobe's interface and features?

The answer is the "80% rule": getting from zero to 80% is fast, but the remaining 20% devours the vast majority of time and effort. LLMs precisely compress the time to reach 80% to the extreme—even for non-programmers. The problem is that this 20% includes exactly:

• File formats: PSD has evolved over 30 years and is only partially documented; lossless round-tripping of smart objects, layer effects, and adjustment layers is extremely difficult, and LLMs only understand public documentation
• Color management: ICC, CMYK, soft proofing, prepress workflows—GIMP and Scribus have struggled for years
• Performance: hundred-megapixel files, tiling, GPU pipelines, memory management—requires years of engineering accumulation
• Video codecs: H.264, HEVC, ProRes involve licensing and patents that LLMs cannot solve
• Ecosystem: plugins, actions, scripts, and existing workflows with agencies and print shops

There are also two layers of legal risk: patents apply to any clone implementation regardless of how the code is written; and an LLM trained on Photoshop documents, forums, and even reverse-engineering materials can hardly be called a "clean-room implementation"—that claim offers no protection.

The German c't magazine's hands-on test delivered the expected conclusion: for professional workflows involving existing project files from agencies, the tested version could not reliably replace the original—"testers should not touch production data with it." In other words, the Vibecoding version of PhotoCraft merely sped through the same 80% that GIMP already had.

Clean-room implementation is a specific concept in software law: a development team works in complete isolation, without access to any copyrighted or patented original code, design documents, or reverse-engineering materials, developing independently based solely on public functional specifications. Its legal significance is that if the process is proven "clean," it provides a strong defense against plagiarism claims. The author points out that an LLM trained on Photoshop documents, forums, and even reverse-engineering materials inevitably embeds design information from the original product in its output, making it hard to claim a clean-room implementation—a claim that offers no legal protection.

Why Users Are Excited: A Mismatch in Evaluation Criteria

Development speed attracts enormous attention because users view software completely differently from programmers:

• Nobody reads code. Users only see the interface, feature lists, and whether it works—which is exactly Vibecoding's strength
• Frequent releases create marketing reasons. The biggest fear for software is the project dying; weekly updates mean "this is alive," even if it's just fixing last week's bugs
• Fast response beats bug-free. Reporting a bug and having it fixed the same day is delightful—users don't realize the bug shouldn't have existed
• Stars attract stars. A project with 200 stars seems more credible than one with 20, unrelated to quality—a self-reinforcing cycle
• Most people don't care who wrote the code. "Who wrote this" is mainly a developer's question; users won't look at god classes, missing schema versioning, duplicate code, and hundreds of empty catch () blocks

A simple rule: the cost of complexity doesn't grow linearly. LLMs push back the tipping point but don't eliminate it.

What Specifically Goes Wrong: The Data Speaks

The article cites multiple independent studies that cross-corroborate:

According to GitClear's analysis of millions of lines of code, the proportion of duplicated code blocks has risen significantly since AI assistants became widespread, while refactoring code has declined. The DORA report estimates that a 25% increase in AI adoption brings about a 1.5% drop in throughput and a 7.2% drop in stability. METR's research found that experienced open-source developers using LLMs were actually 19% slower, yet believed they were 20% faster.

The author thus identifies the core contradiction: LLMs provide programmers, but not architects, not experienced reviewers, not the person who says "no." All of that falls on one person. With 100 virtual developers, the bottleneck isn't writing code—it's the engineer having to understand what was written. This can't be scaled with compute; it requires time and a reliable team of human experts.

DORA (DevOps Research and Assessment) is a Google Cloud program that studies DevOps practices and software delivery performance; its annual report is a widely cited industry benchmark. METR (Model Evaluation & Threat Research) is a nonprofit research organization focused on evaluating AI model capabilities and risks; its controlled experiments found that experienced open-source developers using LLMs actually took 19% longer to complete tasks, despite feeling 20% faster. GitClear is a code analysis platform that tracks metrics like duplicate code blocks and refactoring frequency by scanning millions of lines of code. These three studies cross-corroborate the hidden costs of AI-assisted programming from three dimensions: code quality, delivery stability, and developer productivity.

Why "More and Better AI Will Solve It" Doesn't Hold Up

Faced with a 5,000–6,000-line god class, an LLM seemingly handles it easily within context. But where to draw boundaries when splitting must be decided by someone who understands the system, otherwise you just get ten little god classes importing each other. Hidden coupling only surfaces at runtime: a database singleton accessed by half the server, once split, changes initialization order and shared state. Refactoring safety depends on tests that can capture old behavior, but LLMs favor copied tests or hand-written schemas, resulting in "tests testing themselves." More realistically, hundreds of commits per week mean the code is changing during refactoring, and you must pause new feature development—the author experienced this 11 years ago: two skilled engineers spent nearly two years cleaning up the mess left by features he himself had added.

LLMs can refactor, but someone needs to know where to go and be willing to temporarily stop shipping new things. That's the real bottleneck.

The Digital Signage Case: Debt Isn't Just in the Code

The author's niche industry has seen a surge in solutions since Vibecoding became popular. There's an extra layer of risk here: initially no one bears the consequences. Most people test on a Raspberry Pi at home, where failure doesn't matter. Costs only appear when a black screen on a live deployment burns money.

He cites his own company's 2014 case: a distributor built its own player, underestimated USB flash memory write endurance, and sold about 500 units. A year later, customers needed 10–20 units repaired per month, at about €300 per technician visit. To save flash wear, they stopped writing logs and playback reports—for a network that sells ad space, this cut off its very reason for existing. Replacing the devices took three years.

A single unquestioned architectural decision made at the start was enough to cause this. This is exactly the role Vibecoding lacks: the person who says "no." And when thousands of devices run old versions and outdated protocols with self-hosted servers unmanaged, your own SaaS servers can be refactored, but customer-site installations cannot.

USB flash write endurance is a classic trap in embedded systems: each storage cell in a flash chip can only withstand a limited number of erase/write cycles (typically thousands to tens of thousands), and frequent writes of logs, playback reports, and similar data quickly exhaust it. In digital signage, players continuously write operational logs and ad playback records; without wear leveling or write frequency limits, devices may fail en masse within a year. The distributor in the author's case underestimated exactly this, stopping log and playback report writes to save flash—unintentionally destroying the core functionality the ad network relied on for billing. This reveals how cascading consequences of architectural decisions often far exceed the code itself.

Using LLMs Pragmatically: Four Principles

The author's approach is quite restrained:

1. Go slow. Set rules, keep a short leash, insist on tests, avoid duplication in code and tests
2. Discuss. First discuss the approach and best practices with two LLMs until you fully understand what to do
3. Take small steps. Don't be dazzled by generation speed; look at what it actually did—LLMs love repetition, over-engineered patches, and unit tests that test themselves
4. Refactor with clear goals. You define the structure, the LLM does the cross-file grunt work—that's its greatest value

Good candidates for LLMs: boilerplate and platform chores (CRUD, config dialogs, translations, documentation), initial bug triage, technical sparring. Stay wary of: core functionality like timing, memory management, any C++ code involving threads or media pipelines—LLMs will generate "plausible-looking" code that behaves differently under load.

Realistic expectations: perhaps two to three times the output without sacrificing quality. Not the hype-unicorn pace of thousands of commits in weeks, but a visible and sustainable rhythm.

Conclusion: The New Tool Is Real, and So Is the Nonsense Revolution

The author believes this is indeed a new era, but one swept up in noise driven by false expectations and a lack of understanding. Optimizing purely for production speed is eye-catching, but it also accumulates technical debt whose bill is ultimately paid by users and customers, eroding trust in "professional" software development. He himself made a similar mistake 11 years ago, thinking adding features was the only factor in success, and paid a high price to correct it.

The not-so-hidden secret is: successful software is far more than writing features.

One-line Summary

Vibecoding only accelerates the first 80% of a project; the remaining 20% in engineering, ecosystem, and legal costs is severely underestimated.

Paragraph Summary

Using PhotoCraft's Photoshop clone as an example, the article dissects the real costs of Vibecoding. The author points out that LLMs compress the time to reach 80% of a project to the extreme, but the remaining 20%—PSD file formats, color management, performance optimization, video codec licensing, plugin ecosystems, and legal compliance—still requires years of engineering accumulation, and LLMs cannot provide architectural decisions or the role of saying "no." Users get excited by interfaces and update frequency, unaware that hidden costs like duplicate code and declining stability are accumulating. Studies from GitClear, DORA, and METR cross-corroborate the efficiency illusion of AI assistance. The author advocates pragmatic LLM use: slow, discuss, small steps, goal-driven refactoring—reaping the most benefit on boilerplate and bug triage, while staying wary of core functionality.