Photo: Google Gemini · AI-generated
“Vibe coding” — natural language in, production code out — promised to democratise software development. A recent piece on it-daily.net makes a sharp case for why that promise breaks down exactly where it matters most: Java systems running banks, hospitals, and government agencies. We read it and largely agree. But “largely” is doing some work in that sentence, and the distinction is worth making explicit.
The case against vibe coding is real
Veracode reports that 45% of AI-generated applications contain exploitable security vulnerabilities. Stack Overflow finds developer skepticism of AI-generated code rose from 31% to 46% in a single year. The core problem sits underneath both numbers: programming languages are deterministic — one instruction means exactly one thing. Natural language is not. It is contextual, interpretable, open-ended. A better prompt narrows that gap. It does not close it.
The result is code that looks correct on the surface but quietly does what the model understood, not necessarily what was meant. In a demo, that gap rarely surfaces. In a banking or healthcare system, it does not show up in the demo at all — it shows up six months later, in an incident report.
Where we draw a different line
We build primarily on a .NET stack rather than Java, but the argument is language-agnostic, and so is our answer. The real question was never “should AI touch production code.” It’s “who is accountable for what ships.” Unattended AI coding — the actual “vibe” in vibe coding, where a model’s output goes straight to production without a developer who understands the domain reviewing every line — has no place in critical or regulated systems. On that point, we are not going to argue with the data.
But that is not the same as keeping AI out of production code entirely. Our developers use AI daily — for large-scale refactoring, for enforcing consistency across a sprawling codebase, for the mechanical parts of a rewrite that used to consume a week of a senior engineer’s time. The difference is who is driving. An experienced developer using AI to refactor a legacy module still knows the domain, still understands why a decision was made a decade ago, and still reviews every line before it ships. The AI accelerates. It does not decide.
Consistency is the underrated win
Azul’s 2026 State of Java Survey & Report found that at 32% of companies worldwide, more than half of all Java applications already contain AI functionality. That means this is not a future debate. Whatever the language, if AI is already inside production applications, the real choice isn’t whether to use it — it’s whether someone with genuine judgement is checking what it produces.
One place this pays off directly is application modernisation — rebuilding legacy systems in stages rather than a big-bang rewrite. AI-assisted refactoring, under senior review, catches inconsistency patterns across a codebase far faster than manual review alone: the same naming conventions, the same error-handling patterns, the same architectural decisions applied uniformly, instead of the drift that accumulates over years of different hands touching the same system. That is a quality improvement, not a shortcut.
The line is accountability, not the tool
The it-daily piece is right that ambiguity is a real risk in Java systems. We would go further: ambiguity is a risk in any production system, in any language, the moment nobody with real expertise is checking the output. AI does not remove that requirement. It changes what an experienced developer spends their time on — less time on boilerplate, more time on the judgement calls only a human can make.
Vibe coding hands the wheel to a model that does not know your business. AI-assisted engineering keeps an experienced developer’s hands on the wheel and gives them a faster tool. We build the second way — on the production systems our clients run their business on, not just prototypes.
Wondering whether your codebase is ready for AI-assisted refactoring, or exposed by unattended AI code already in it? Talk to us.