The Trust Paradox: LLMs vs. Human Engineers
My recent experience with fallout from vibecoded slop left me reflecting on a troubling trend: Why do businesses increasingly trust LLM outputs over their human engineers? The answer isn’t about technology - it’s about perception, communication, and misaligned incentives.
What are we even doing?
Using a coding agent is something inherently abstract. You add an API key somewhere, put a few sentences into it and watch it spit out code fragments. How can somebody trust that more than a human colleague?
The answer is simpler than I thought: Experience. Engineers are notoriously bad at holding deadlines. Effort estimation is a whole literary subgenre dating back 50 years with “The Mythical Man-Month” by Fred Brooks as well as humorous web comics.
Because projects are unpredictable, smart people came up with different types of project management. We are currently in what I call the esoteric agile era, where people will pretend that they actually read the agile manifesto and our calendars are crammed with a plethora of ceremonial meetings, pretending that we’re not actually doing a process-laden iteration of waterfall.
Essentially, it always boils down to one situation: Somebody sees a problem. People argue whether it’s actually a problem or not. Until somebody asks “How long will it take?” and the engineer starts speaking.
Stop scaring people
I am guilty of that, too. Engineers speak a different language. We use complicated words like polymorphic, stateless or non-deterministic in a very specific context on a regular basis. We might as well speak Elvish.
For non-technical people, this can be intimidating. Or phrased differently: They often have no clue what we’re talking about. While it’s common practice within engineering teams to plainly ask “What?” if you don’t understand your discussion partner, a similar approach would be perceived as rude in business speak. There are secret code words and conventions to adhere to.
Nobody wants to show weakness, so people often nod along to save face.
An LLM confirms
Engineers will question anything: Use cases, implementation details, metrics, governance, timelines. The more experienced an engineer, the more they will find to nit because the more cautionary tales they have to tell.
An LLM works differently. It does not demand requirements. It does not care about metrics. It does exactly as you tell it to - and nothing more. Which is exactly where quality diverges from a human engineer who is kept out of the loop. The answers will still be filled with technical jargon but it will tend to confirm the user’s vision, not question it.
All of that happens nearly instantaneously, keeping dopamine levels up. Engineers tend to respond slowly, because they are often busy, and might be perceived as having limited availability. Guess what impresses stakeholders more?
Human-written does not equal high quality
I want to explicitly mention that there are whole repositories full of bad code at pretty much every company in the world. This was the case before coding agents became popular. Even well-established frameworks of the past - e.g. jQuery - were partly a mess of spaghetti code nobody could maintain.
This directly affects coding agents: They were trained on “bad” codebases as well. While a junior engineer can look at bad code and ask a more experienced colleague for improvements, manual validation is largely unfeasible throughout an LLM’s training phase due to the sheer volume of data, meaning vast amounts of unvetted code become part of its foundation. The same applies to fine-tuning.
This isn’t to say LLMs are inherently flawed. They excel at reducing toil, generating boilerplate, and even suggesting improvements to existing code. However, their limitations - such as the inability to innovate or contextually challenge requirements - mean they should complement, not replace, human judgment. Engineers will come up with improvements on their own. This is how new frameworks are born regularly. While an LLM might occasionally generate novel combinations by chance, it lacks the intent to innovate; it simply recombines knowledge it has already been trained on.
Accountability diffusion
Everybody messes up. It’s part of the job. When blocking issues surface in production, I can directly ask the person responsible for the breaking change and we’ll sit and fix the issue.
Who is accountable when an LLM introduces a breaking change and the engineering team was kept out of the loop? The prompt engineer might argue, “I just did what business wanted,” while business responds, “We didn’t know it was that bad.” But accountability isn’t about blame - it’s about ownership. If no one reviews or tests LLM-generated code, the failure lies in the process, not the tool. Who ensures the fix is robust? Who prevents recurrence? These questions expose a governance gap, not a technological one. Businesses must recognize that LLMs are not autonomous agents but tools that require human oversight.
Communicate and collaborate
The trust deficit is not one-sided. Engineering teams regularly face cost-cutting measures - whether tools, resources, or even colleagues - while sitting on mountains of technical debt. Business stakeholders, meanwhile, are pressured to deliver results quickly, often without understanding the long-term consequences of shortcuts.
To move forward, both sides must commit to collaboration:
For engineers:
- Translate technical debt into business risks (e.g., “This shortcut will cost us X hours of downtime per month”).
- Propose governance frameworks for LLM use, such as mandatory peer reviews for generated code.
- Build tools or scripts to flag common LLM anti-patterns (e.g., hardcoded secrets, inefficient algorithms).
- Advocate for transparency in how LLMs are used in projects and mentor colleagues on mitigating risks.
For business stakeholders:
- Involve engineers in early-stage discussions about LLM adoption to set realistic expectations.
- Allocate time for engineers to review and refine LLM outputs - treat it as part of the development process, not an afterthought.
- Recognize that LLMs are force multipliers, not replacements. Their value lies in augmenting human expertise, not bypassing it.
For both sides:
- Establish shared metrics for success, tracking not just speed but also maintainability, security, and long-term costs.
- Foster psychological safety. Engineers should feel comfortable pushing back on unrealistic demands, and business teams should welcome feedback without defensiveness.
- Do not use the fact something was LLM generated as an excuse. Ultimately, a human is always the driving force.
Closing words
The goal isn’t to eliminate friction but to channel it productively. LLMs can accelerate work, but only if humans - engineers and business alike - collaborate to use them responsibly. By fostering open communication and mutual respect, we can harness the strengths of both humans and machines to build better software.
On Vibecoding