AI coding agents: the hidden risks for SMEs in 2026

The background: who George Hotz is and why his voice matters

George Hotz is not an outside commentator on the software world. He was the first hacker to unlock an iPhone independently. He founded comma.ai, a company specializing in autonomous driving. He also worked briefly at OpenAI. His technical background is, therefore, anything but generic.

In May 2026, Hotz made a blunt statement: LLM-powered coding agents will become one of the costliest mistakes in the entire history of software development. The original source is an analysis published by The Decoder, which reported his words accurately. So this is a public, documented position.

This stance is part of a deep debate. The AI community is now split between those who see coding agents as productivity multipliers and those who, like Hotz, consider them a structural source of technical risk. Ignoring this debate would therefore be a mistake for any organization weighing investments in code automation.

How coding agents work: architecture and built-in limits

A coding agent is an AI system that can write, modify and sometimes run code on its own. It's built on a Large Language Model, a language model trained on huge corpora of text and source code. In practice, the model predicts the most likely sequence of tokens given a context.

This mechanism works well for highly repeatable tasks with low contextual complexity. For example, generating a CRUD function, writing a standard unit test or completing blocks of boilerplate code. But the problem appears when the context becomes deep and interdependent.

LLMs don't truly understand the semantics of the system they work on. As a result, they can produce code that is syntactically correct but logically wrong. These bugs don't trigger immediate errors. Instead, they nest in deep layers and show up only under specific conditions, often in production. According to research from Gartner, the quality of AI-generated code requires systematic human review to maintain acceptable standards of reliability.

The silent technical debt phenomenon

The concept of technical debt isn't new. It's the future cost an organization pays for suboptimal technical choices made today. But coding agents introduce a particularly insidious variant: silent technical debt.

In this scenario, the debt isn't visible when the code is written. In fact, generated code often passes automated linting checks and first-level tests. The problem surfaces weeks or months later, when the system scales or when new features interact with the AI-generated code.

Hotz pointed out that after six months of testing, bugs become progressively harder to find. It's not a problem of quantity, but of depth. So the cost of fixing them grows exponentially over time. For an SME with limited development resources, this scenario can become critical.

Studies from Harvard Business Review have documented that the average cost of fixing a bug in production is up to 100 times higher than fixing it during development. So the silent buildup of defects has concrete, measurable economic implications.

SME use cases: where the risk is highest

Not every use context carries the same level of risk. It helps to tell high-impact scenarios from low-impact ones for Italian SMEs working in B2B or retail.

High-risk contexts include:

• Custom management systems and ERPs: the business logic is complex and every error directly affects operations.
• Third-party API integrations: a coding agent can generate API calls that look correct but handle errors poorly.
• E-commerce modules with payment logic: any bug here has immediate legal and reputational consequences.
• Authentication and user management systems: AI-generated security vulnerabilities are among the hardest to detect.

By contrast, low-risk contexts include generating HTML templates, writing non-critical automation scripts and producing technical documentation. In these areas, coding agents offer a real advantage without exposing the organization to significant risk.

For SMEs managing complex web projects, we at SHM Studio recommend mapping out precisely where AI tools can be used before building them into development workflows. A well-defined AI strategy is the prerequisite for any responsible adoption.

The speed vs. quality trade-off: a calculation SMEs need to make

The main argument in favor of coding agents is speed. A prototype that would take a senior developer three days can be sketched in a few hours with an LLM's help. This advantage is real and shouldn't be underestimated.

But the economic calculation has to include the cost of accumulated technical debt. If the prototype goes into production without a proper review cycle, the initial savings quickly turn into an amplified cost. What's more, in SMEs with small development teams, the capacity to handle complex bugs is structurally limited.

So the trade-off isn't simply speed versus quality. It's immediate savings versus future operational risk. That's why the decision to adopt coding agents calls for an explicit risk assessment, not just a performance assessment.

Research from MIT Technology Review indicates that organizations that integrate AI into software development without structured governance processes show significantly higher rates of technical incidents than those that adopt hybrid oversight frameworks.

The AI community is divided: it's not just Hotz

Hotz's position isn't isolated. The AI community is deeply divided on this topic. On one side, companies like GitHub with Copilot and Cursor actively promote coding agents as productivity tools. On the other, a growing part of the technical community points to structural problems.

The debate is fundamentally about the nature of LLMs. These models are optimized for statistical plausibility, not logical correctness. So they produce output that looks right far more often than it actually is. This gap between appearance and substance is especially dangerous in a technical context.

Moreover, growing reliance on coding agents risks eroding the in-house skills of development teams. If programmers stop writing code from scratch, they gradually lose the ability to read and understand AI-generated code. This creates a vicious circle that increases dependence and reduces the capacity for oversight.

What nobody counts: the cost of oversight

One thing often overlooked in the debate on coding agents is the real cost of supervision. Many vendors pitch these tools as a way to reduce the need for senior developers. In reality, the opposite is often true.

Spotting the bugs an LLM produces takes a high level of technical expertise. A junior developer can't identify deep logic errors in AI-generated code. As a result, the coding agent doesn't replace the senior developer: it requires their constant presence as a supervisor.

This radically changes the ROI calculation. The expected savings on writing code are partly or fully absorbed by the cost of qualified review. For SMEs without in-house senior profiles, that means outsourcing supervision, adding a cost that is rarely included in initial projections.

Anyone working in digital marketing and digital transformation for SMEs knows this pattern well: underestimating hidden costs is one of the main reasons technology adoption projects fail. That's also why a structured consulting approach is essential before any investment in AI applied to development.

Our recommendation: an operational framework for SMEs

Given all this, what approach makes sense for an Italian SME considering coding agents in 2026?

First, it helps to distinguish between assisted and autonomous use. Assisted use, where the AI suggests and the developer decides, carries an acceptable level of risk. Autonomous use, where the AI writes and the developer approves without deep review, is what Hotz rightly criticizes.

Second, you need to set clear boundaries. Coding agents should be explicitly enabled for specific types of tasks, not used as a general-purpose tool. Every output must go through a structured code review process, regardless of its source.

Third, code quality metrics should be tracked over time. Indicators like bug density per sprint, mean time to resolve incidents and test coverage are early warning signs of technical debt building up.

Finally, team training remains a non-negotiable investment. A team that understands the limits of LLMs can use them productively. A team that treats them as infallible is exposed to significant risks.

If your SME wants to dig deeper into these topics, the SHM Studio team is available for structured consulting. You can explore our AI services, web development solutions, SEO and digital marketing strategies. To talk to us directly, start from the contact page. Our blog also regularly publishes analysis on these topics, including thoughts on AI-assisted copywriting, Google Ads campaigns and LinkedIn campaigns.