What are the real benefits of LLM-powered coding assistants for experienced developers?

For experienced developers, LLM-powered coding assistants accelerate delivery by handling repetitive tasks, generating scaffolding code, and enabling faster experimentation. When paired with strong engineering fundamentals, these tools amplify expertise and allow senior engineers to focus on architecture, system design, and complex problem-solving.

Why do AI coding assistants often increase technical debt and security risks?

AI-generated code is often syntactically correct but lacks awareness of architecture, security constraints, and long-term maintainability. Without proper oversight, subtle bugs, insecure patterns, and design inconsistencies can reach production, increasing technical debt and security risk.

Should LLM-powered coding assistants be available to all developers by default?

Not always. While AI coding assistants can support learning, unrestricted access in high-stakes environments increases risk. A better approach is to tailor usage based on developer experience, task sensitivity, and the cost of failure.

How can organizations use AI coding assistants without overloading senior engineers?

Organizations need clear standards for prompting, validation, and acceptable use. Without guidelines, senior engineers spend excessive time reviewing poorly guided AI output. Structured usage policies reduce review bottlenecks and protect engineering capacity.

How does Xebia help organizations adopt LLM-powered coding assistants safely and effectively?

Xebia supports safe adoption of LLM coding assistants by assessing engineering maturity, developing governance models, training teams to steer and validate AI-generated code, and embedding responsible AI practices into delivery workflows. This ensures organizations gain productivity benefits without introducing technical debt or security issues.

Blog

LLM-powered coding mass-produces technical debt

LLM-powered coding is powerful, but not everyone is benefiting.

Giovanni Lanzani

December 27, 2025

3 minutes

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.”
AssafMalkiIL
https://xebia.ai/viiiibe-coding

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.

Avoiding engineers' fatigue

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.

Tags: