On Vibecoding
I am a lazy person. Naturally, one would think coding agents are a blessing for people like me. In my experience, it’s quite the opposite: Using coding agents in a lazy way is like putting a spoke in your own wheel. An even worse experience is taking ownership of somebody else’s vibecoded mess.
Some clarification
Laziness has tiers. A bad lazy person does not care about consequences and only thinks five minutes ahead. A good lazy person thinks long-term: Will what I sloppily fix right now come back to me at a later point? If so, let’s spend some more effort right now to slack off more later.
If you have not been living under a rock, you might have gotten wind about how IT work changed yet again. Software Engineering was always a quite dynamic field. Good Software Engineers do not necessarily know every specification of a programming language. Instead, they have broad knowledge about fundamentals to adopt new tooling quickly, a pragmatic mindset about projects, and the ability to manage expectations, especially with business stakeholders. Large Language Models are the first tool to fundamentally change how we work and leading to devastating results if not wielded correctly.
For business, coding agents are indeed a blessing. This arises from their lack of fundamental knowledge in our technical domain, leaving them unaware of what to expect or watch out for. Engineers are always nay-sayers, but an LLM is happy to implement their world-changing vision of insurance data behind a shiny UI at record speeds. What could possibly go wrong?
I am guilty myself
… of vibecoding. I let an LLM take over development, did not look at the code initially and found myself in pandemonium. The thing is, that was a program solely I myself was using and it kind of worked. But once I looked under the hood, I knew I messed up because the whole codebase was, in fact, unmaintainable garbage. In the end, I rewrote it and learned how to use yet another tool in my belt, but this time in a more responsible way.
I’ve heard that expensive development prevents companies from making bad decisions. Now try applying that experience to a large-scale project. How can people lacking technical knowledge judge that? They can not. It’s that simple.
It’s not that simple
And this is where the story starts. I found myself sitting in the customer’s office, discussing business requirements, never getting anywhere; in short, the typical business shenanigans. One day, someone came in and said they’d been secretly vibecoding a whole SaaS solution and asked me, their most senior colleague and trusty consultant, to review it.
During review, it became clear that under no circumstances, the project could go live as-is. Imagine every mistake you could make as a Developer. It contained them all. It had full-table scans on each endpoint, hardcoded properties, hardcoded credentials, credentials checked into VCS, hardcoded paths leading to local environments that don’t exist, homemade authentication; just to name a few.
Business didn’t understand because from their perspective, it worked.
Writing code is not the issue
Never was, never will be. I always hear the term Time To Market. TTM is indeed important because it allows you to fill a demand competitor is potentially not yet aware of. But in software projects - especially enterprise - writing the actual code never was the bottleneck.
In enterprise software projects, planning often takes up a disproportionate amount of time compared to implementation. This isn’t surprising. Large organizations require extensive stakeholder alignment, risk assessment, and compliance checks before any code is written.
Decisions get pushed to a later date indefinitely. People discuss a feature for a whole year and once an agreement is made, they want it realized in a fraction of the time. After you provide the solution, they go back into discussions; sometimes never to be seen again. Rinse and repeat.
An LLM used to rapidly deliver a clickable prototype does not save money long-term. It can reel in a potential customer but it won’t give you a product to sell. Of course people try and that’s where the fun headlines of security breaches and data leakage origin from. GDPR violations are fined with up to 4% of a company’s annual turnover. Is that really worth it?
Running code is a different beast
The focus is purely on writing code, but what about running it? While tooling improved developer experience along the way of building projects, ultimately the scale of complexity still exists. “Runs on my machine” is not a valid argument for people who are familiar with the domain. Coding agents won’t help you as much here.
Before any code is written, functional and technical requirements need to be defined. It does not matter if you work agile or in a waterfall setup. If I was to build a CRM system, I need to know what the purpose of the system is.
What gap does it fill? Who is the user? How much data do we expect? How to measure success? Do we have multi-tenancy? Do we live in an Event-Driven landscape? A system handling CRUD for 30 million records needs to be designed differently than a webshop with 20 items. It has different use cases, different challenges in hosting and needs to confirm to different regulations.
In my case, none of that was present. While a rewrite was in order one way or the other - the architectural governance demanded a different programing language - nobody bothered to define that. The review itself was difficult not only because of project size, but also the angle judging the result was unclear. Following business domain, I applied the harshest criteria I could come up with and compared to existing products.
This was understood and I transparently reported the ongoing review to business. We agreed on putting the matters of rewriting into my hands. I had experience with coding agents and how to harness them through spec driven development. I knew exactly where the pain points were and how to fix them.
Two weeks later a manager pinged me in Teams, telling me that they already rewrote it themselves with an LLM and asked for another review.
Welcome to the cleanup crew
Without notice, I was silently demoted from an engaging team member to a cleanup worker. The responsibility of making design decisions was stripped from me and I was presented an axiom. We’re going live with this product, no matter what. But please review it first.
What happened?
Somebody meddled with my domain. Software Engineering has fun parts and less so. The fun part is building. The not-so-fun part is maintaining. It’s a necessary evil. Everybody will opt for a job that allows building over maintaining.
Upon review, hell broke loose. Unsurprisingly, the programming language shift did not magically eliminate showstopping bugs. On the contrary: The rewrite introduced even more. The growing issue list made me ring the alarm bells.
Back to the conference room, presenting new slides of the damage done. This was taken with nonchalance. Please send us an estimate. My estimation concluded 4-6 months of reconciliation to resolve technical issues exclusively. Usually you can expect the list to grow by 20% in the process of fixing.
Functional gaps
Beyond technical debt, the lack of functional clarity made the project even more untenable. There was no documentation, no use cases, no metrics of what the application is supposed to be capable of. No test cases to verify if my changes preserved expected behavior. There was no expected behavior. Keep in mind that there were zero functional errors as well, as I had no means to find them. Functional defects can surface technical gaps as well.
Then it dawned on me: Not only was I demoted, but also shoehorned into claiming technical ownership of vibecoded slop. At the same time, business refused to take ownership of functional requirements. I was asked to figure out what the application is capable of by analysing the code.
In essence, they meddled with my domain while negleting their own: How am I supposed to retrofit use cases for a project I myself have no functional understanding of? And when was that added to the Software Engineer job profile?
It’s supposed to work the other way around: Business raises a need, engineering fulfills it best effort. Not engineering randomly builds something and business tries to figure out how to use it. That is unintended outcome of ill-managed projects.
Here, on a greenfield project in enterprise context, this is not supposed to happen. While I prepared the slides, the original author of the application kept dodging my inquiries. Same for management. I was mentally preparing for a salvaging operation and provided a plan for damage control as the plan to go live within two months had already been pitched to management. I was not prepared for the pushback.
Nine pregnant women deliver one baby in one month
When presenting the results, we ended up in shouting matches. I suggested defining a MVP: What does the application need to fulfill when we ship the first version in two months as that was a hard deadline. They completely turned the table on me, kept challenging my estimates for a total of 180 issues, all filed and well-described in our internal repository, never to be read once.
I heard layman’s terms and fallacies: Let’s just throw 10 more engineers on the problem so we finish 10 times as fast. We give you two colleagues so we calculate with 3 full-time equivalents. With the power of LLM tools, you are able to deliver one fixed issue per day. Poof, the problem vanishes.
This is not how any of this works. Even if you found 10 competent people today, onboarding alone can take two weeks for one person. One senior onboarding two people onto the project roughly translates to 1,5-1,7 FTE, not three. Because guess what, your most experienced engineer is blocked from doing productive work. The LLM argument is so inherently wrong that I did not even bother to address that until pushed. How can somebody who never read one issue from the list make such a general statement?
Ultimately, allegations of ill intent came up. Apparently, I was stalling the project on purpose instead of providing a solution - my idea of defining a MVP was shot down - and I was dragging everyone in calls, instead of “solving the problem”. Usually business loves their calls, but for some reason this time they deemed it wrong.
What to take away
Reflecting the situation: I still have no answer for what to do if somebody demands taking ownership of a project no human authored. In my case, nobody even talked about taking functional ownership. That point was flat out ignored. What I completely fail to grasp is how business can be fine with a black box going live.
Some people might argue that Software Engineers build black boxes all the time. So do electrical engineers. So do pharmacists. So do airplane engineers. Anything is a black box if not familiar with the domain. Would you rather have a human who authored the black box as team member or an API key from a profit-driven corporation?
Ultimately, I decided to move to a different project. I have no hard feelings for the people involved and wish everyone the best. Never in my life was I put into a situation where my advice was asked, just to be immediately ignored and not even refused. As parting gift, I presented how the project could have been a success with spec driven development and fixed a chunk of the issue pile until the very last day.
Moving forward
If you’re using coding agents, ask yourself: Am I building a maintainable solution, or am I just vibecoding? The difference could save your project - and your sanity. Treat LLMs as tools to augment your work not replace it. Define requirements upfront, review outputs critically, and never let a black box go live without understanding what’s inside.
Closing up, I see coding agents as mighty tool. I now have the opinion that we need to gatekeep coding agents. Usually I am all in for openness but here I saw with my own eyes what damage can be done. Allow me an analogy: No carpenter would let a layman use a laser cutter, unless they want the fire brigade to visit.
Android at a Crossroads: Security vs. Freedom in Google's New Policy