Blog
LLM-powered coding mass-produces technical debt
LLM-powered coding is powerful, but not everyone is benefiting.
December 27, 2025
A developer so immersed in coding he forgot to use LLM-powered coding assistants…?
The expectations around LLM-powered coding assistants are sky-high, but many organizations are falling behind because of them.
WHY IT MATTERS? CTOs lament slowdowns and production issues traced to company-wide rollouts of [LLM-p…
Blog
LLM-powered coding mass-produces technical debt
LLM-powered coding is powerful, but not everyone is benefiting.
December 27, 2025
A developer so immersed in coding he forgot to use LLM-powered coding assistants…?
The expectations around LLM-powered coding assistants are sky-high, but many organizations are falling behind because of them.
WHY IT MATTERS? CTOs lament slowdowns and production issues traced to company-wide rollouts of LLM-powered coding assistants. The AI promise clashes with the reality of technical debt and security issues.
HOW TO FIX IT? Deploy these tools strategically: available broadly when errors are cheap, but restricted when the stakes are high.
A Big Promise
The promise of AI for engineers is getting rid of engineers.
Tools like GitHub’s Copilot write code, specs, review, and create pull requests. They create and run tests, and do so in the background while the developers engage in more productive activities, such as meetings.
Is productivity lagging because we’re all waiting on ChatGPT? Credit Reddit, remixing Randall Munroe https://xebia.ai/waiting-on-chatgpt
However, if this is all real, which companies are racing ahead?
A survey by DX, a developer intelligence platform asked 20.000 developers, finding the increase in productivity for staff engineers to be around 10%: not bad, but hardly revolutionary.
I believe there’s another reason: the increase is unevenly distributed because these tools are like an ocean wave: fun for experienced surfers, but trouble for the neophytes.
Simon Willison—an independent AI researcher and member of the Python Software Foundation’s board—mentioned recently, in the Last Week in AWS podcast, how LLM-assisted coding are a multiplier for his productivity, but only because he directs them with 20 years of experience.
For example, when building a web application, he asks the model to check for CSRF (cross-site request forgery) vulnerabilities because he is aware of the threat. Someone with little to no web experience wouldn’t even ask. Guiding models (and vetting their output) separates success from (security) disasters, then.
Willison prowess awaken jealousy. Some of his projects, co-written by LLMs, include tools for OCR-ing PDFs in the browser,creating annotated presentations, image resizers, and a social media card cropper, to name a few (you can find them all on his website). This is the fulfilled promise of AI: an amplifier of expert skills.
The Other Side of the Coin
Less experienced developers awaken no jealousy when equipped with the same tools, and frightening tales abund.
“What’s the point of me coding if at the end of the day i [sic] still gotta pay a dev to look at the code anyway? I’m sure it feels kinda good while I’m typing [...] but when stuff breaks it’s just dead weight.”
And stuff does break. Claude can wipe everything valuable from your computer (including photos and documents) while executing an unrelated task.
The boardroom agrees. In a recent survey, 90% of CTOs attributed production disasters to LLM-powered coding, and they’re not alone:
- The CEO of Sonar said downtime increased along with LLM-powered coding adoption.
- Veracode found that AI-generated code is functional but insecure half of the time.
- Naples University confirmed AI output is riddled with subtle errors and security weaknesses.
The core issue is failing to master the craft. Lack of steering or quality assurance allows LLM-powered coding assistants to increase technical debt with every prompt.
Process ain’t the answer
Do QA and code reviews ease the problem? Can process fix or avoid bugs, technical debt, or security issues?
First, these processes do not stop everything. Otherwise, implementing them would mean bug-free software.
Second, the speed at which engineers can re-prompt a model to try to pass QA—shifting the burden to the reviewer—is unprecedented.
Daniel Stenberg, creator of the ubiquitous cURL, wrote that combing each AI-generated vulnerability report takes up to 3 hours. He needs to understand the provided code, try the examples, reply, etc.
Once he answers, the submitter shoves the answer into an LLM and pastes whatever comes out back, wasting more precious time.
Daniel bans the submitter, but what about colleagues? Will they be transferred, only to swamps the next engineer?
One-size fits none
Are success for some and disaster for others two sides of the same coin?
Discussing with topic with several CTOs and engineering managers, I came up with this model: if you fail to master the craft, you end up adding technical debt with each new prompt.
If engineers spot mistakes and weaknesses, LLM-powered coding assistants are an ally. For engineers who do not master their craft, these assistants spell trouble.
This means these tools shouldn’t be available to everyone by default (unless for learning, they can be powerful with a mentor) to avoid adding technical debt quicker than what you can absorb.
Doing so is easier said than done, as companies should understand who has the craft to use LLM-powered coding assistants effectively and who doesn’t.
Written by
Contact