George Hotz non \u00e8 un commentatore esterno al mondo del software. \u00c8 il primo hacker ad aver sbloccato un iPhone in modo indipendente. Ha fondato comma.ai, azienda specializzata in guida autonoma. Inoltre, ha lavorato brevemente all’interno di OpenAI. Il suo profilo tecnico \u00e8, quindi, tutt’altro che generico.<\/p>\n
In May 2026, Hotz made a stark statement: LLM-powered coding agents will become uno degli errori pi\u00f9 costosi<\/strong> nell’intera storia dello sviluppo software. La fonte originale \u00e8 un’analisi pubblicata da The Decoder<\/a>, who accurately reported his words. Therefore, it is a public and documented position.<\/p>\n Questa presa di posizione si inserisce in un dibattito profondo. La comunit\u00e0 AI \u00e8 oggi divisa tra chi vede i coding agents come moltiplicatori di produttivit\u00e0 e chi, come Hotz, li considera una fonte strutturale di rischio tecnico. Pertanto, ignorare questo dibattito sarebbe un errore per qualsiasi organizzazione che stia valutando investimenti in automazione del codice.<\/p>\n Un coding agent \u00e8 un sistema AI in grado di scrivere, modificare e talvolta eseguire codice in modo autonomo. Si basa su un Large Language Model, ovvero un modello linguistico di grandi dimensioni addestrato su enormi corpus di testo e codice sorgente. In pratica, il modello predice la sequenza di token pi\u00f9 probabile dato un contesto.<\/p>\n Questo meccanismo funziona bene per compiti ad alta ripetibilit\u00e0 e bassa complessit\u00e0 contestuale. Ad esempio, generare una funzione CRUD, scrivere un test unitario standard o completare blocchi di codice boilerplate. Tuttavia, il problema emerge quando il contesto diventa profondo e interdipendente.<\/p>\n LLMs do not have a true understanding of the semantics of the system they operate on. Consequently, they can produce syntactically correct but logically flawed code. These bugs do not immediately generate errors. Instead, they are embedded in deep layers and only manifest under specific conditions, often in production. According to research by Gartner<\/a>, la qualit\u00e0 del codice generato da AI richiede revisione umana sistematica per mantenere standard accettabili di affidabilit\u00e0.<\/p>\n The concept of technical debt<\/em> non \u00e8 nuovo. Indica il costo futuro che un’organizzazione paga per scelte tecniche subottimali prese nel presente. Tuttavia, i coding agents introducono una variante particolarmente insidiosa: il silent technical debt<\/strong>.<\/p>\n In questo scenario, il debito non \u00e8 visibile al momento della scrittura del codice. Infatti, il codice generato supera spesso i controlli automatici di linting e i test di primo livello. Il problema emerge settimane o mesi dopo, quando il sistema scala o quando nuove funzionalit\u00e0 interagiscono con il codice generato dall’AI.<\/p>\n Hotz ha sottolineato che dopo sei mesi di test, i bug diventano progressivamente pi\u00f9 difficili da individuare. Questo non \u00e8 un problema di quantit\u00e0, ma di profondit\u00e0. Pertanto, il costo di correzione cresce esponenzialmente nel tempo. Per una PMI con risorse di sviluppo limitate, questo scenario pu\u00f2 diventare critico.<\/p>\n Studies of Harvard Business Review<\/a> hanno documentato come il costo medio di correzione di un bug in produzione sia fino a 100 volte superiore rispetto alla correzione in fase di sviluppo. Dunque, l’accumulo silenzioso di difetti ha implicazioni economiche concrete e misurabili.<\/p>\n Non tutti i contesti d’uso presentano lo stesso livello di rischio. \u00c8 utile distinguere scenari ad alto impatto da scenari a basso impatto per le PMI italiane che operano in ambito B2B o retail.<\/p>\n High-risk contexts include:<\/p>\n Al contrario, i contesti a rischio contenuto includono la generazione di template HTML, la scrittura di script di automazione non critici e la produzione di documentazione tecnica. In questi ambiti, i coding agents offrono un vantaggio reale senza esporre l’organizzazione a rischi significativi.<\/p>\n For SMEs managing complex web projects, we at SHM Studio<\/a> We recommend accurately mapping the usage boundaries of AI tools before integrating them into development workflows. A AI strategy<\/a> ben definita \u00e8 il prerequisito di qualsiasi adozione responsabile.<\/p>\n Il principale argomento a favore dei coding agents \u00e8 la velocit\u00e0. Un prototipo che richiederebbe tre giorni a uno sviluppatore senior pu\u00f2 essere abbozzato in poche ore con l’assistenza di un LLM. Questo vantaggio \u00e8 reale e non va sottovalutato.<\/p>\n Tuttavia, il calcolo economico deve includere il costo del debito tecnico accumulato. Se il prototipo diventa produzione senza un ciclo di revisione adeguato, il risparmio iniziale si trasforma rapidamente in un costo amplificato. Inoltre, nelle PMI con team di sviluppo ridotti, la capacit\u00e0 di gestire bug complessi \u00e8 strutturalmente limitata.<\/p>\n Il trade-off, quindi, non \u00e8 semplicemente velocit\u00e0 contro qualit\u00e0. \u00c8 risparmio immediato contro rischio operativo futuro. Per questo motivo, la decisione di adottare coding agents richiede una valutazione di rischio esplicita, non solo una valutazione di performance.<\/p>\n Research of MIT Technology Review<\/a> indicano che le organizzazioni che integrano AI nello sviluppo software senza processi di governance strutturati mostrano tassi di incidente tecnico significativamente pi\u00f9 alti rispetto a chi adotta framework di supervisione ibrida.<\/p>\n La posizione di Hotz non \u00e8 isolata. La comunit\u00e0 AI \u00e8 profondamente divisa su questo tema. Da un lato, aziende come GitHub con Copilot e Cursor promuovono attivamente l’adozione dei coding agents come strumenti di produttivit\u00e0. Dall’altro, una parte crescente della comunit\u00e0 tecnica segnala problemi strutturali.<\/p>\n Il dibattito riguarda fondamentalmente la natura degli LLM. Questi modelli sono ottimizzati per la plausibilit\u00e0 statistica, non per la correttezza logica. Pertanto, producono output che sembrano giusti molto pi\u00f9 spesso di quanto lo siano effettivamente. Questo gap tra apparenza e sostanza \u00e8 particolarmente pericoloso in un contesto tecnico.<\/p>\n Inoltre, la dipendenza crescente dai coding agents rischia di erodere le competenze interne dei team di sviluppo. Se i programmatori smettono di scrivere codice da zero, perdono gradualmente la capacit\u00e0 di leggere e comprendere il codice generato dall’AI. Questo crea un circolo vizioso che aumenta la dipendenza e riduce la capacit\u00e0 di supervisione.<\/p>\n Un elemento spesso trascurato nel dibattito sui coding agents \u00e8 il costo reale della supervisione. Molti vendor presentano questi strumenti come soluzioni che riducono il bisogno di sviluppatori senior. In realt\u00e0, accade spesso il contrario.<\/p>\n Per rilevare i bug prodotti da un LLM, \u00e8 necessaria una competenza tecnica elevata. Un junior developer non \u00e8 in grado di identificare errori logici profondi nel codice generato dall’AI. Di conseguenza, il coding agent non sostituisce il senior developer: ne richiede la presenza costante come supervisore.<\/p>\n This radically changes the ROI calculation. The expected savings on code writing are partially or fully absorbed by the cost of qualified review. For SMEs that do not have senior internal figures, this means outsourcing supervision, adding a cost that is rarely included in initial projections.<\/p>\n Who is responsible for digital marketing<\/a> e trasformazione digitale per le PMI conosce bene questo pattern: la sottostima dei costi nascosti \u00e8 una delle principali cause di insuccesso nei progetti di adozione tecnologica. Anche per questo, un approccio consulenziale strutturato \u00e8 essenziale prima di qualsiasi investimento in AI applicata allo sviluppo.<\/p>\n Alla luce di queste considerazioni, quale approccio \u00e8 raccomandabile per una PMI italiana che valuta l’uso di coding agents nel 2026?<\/p>\n In primo luogo, \u00e8 utile distinguere tra utilizzo assistito e utilizzo autonomo. L’utilizzo assistito, in cui l’AI suggerisce e il developer decide, presenta un profilo di rischio accettabile. L’utilizzo autonomo, in cui l’AI scrive e il developer approva senza revisione profonda, \u00e8 quello che Hotz critica giustamente.<\/p>\n In secondo luogo, \u00e8 necessario definire perimetri chiari. I coding agents vanno abilitati esplicitamente per specifiche tipologie di task, non come strumento generale. Ogni output deve passare attraverso un processo di code review strutturato, indipendentemente dalla fonte.<\/p>\n In terzo luogo, le metriche di qualit\u00e0 del codice vanno monitorate nel tempo. Indicatori come la densit\u00e0 di bug per sprint, il tempo medio di risoluzione degli incidenti e la copertura dei test sono segnali precoci di accumulo di technical debt.<\/p>\n Infine, la formazione del team rimane un investimento non negoziabile. Un team che comprende i limiti degli LLM \u00e8 in grado di usarli in modo produttivo. Un team che li considera infallibili \u00e8 esposto a rischi significativi.<\/p>\n For SMEs that wish to delve deeper into these topics, the team at SHM Studio<\/a> \u00e8 disponibile per una consulenza strutturata. \u00c8 possibile esplorare i nostri AI services<\/a>, the solutions of web development<\/a>, the strategies of SEO<\/a> e digital marketing<\/a>. For a direct comparison, the page contacts<\/a> \u00e8 il punto di partenza. Inoltre, il nostro blog<\/a> regularly publishes analyses on these topics, including reflections on AI-assisted copywriting<\/a>, Google Ads campaigns<\/a> e LinkedIn campaign<\/a>.<\/p>","protected":false},"excerpt":{"rendered":" George Hotz warns: AI coding agents produce hard-to-detect bugs. What risks do SMEs face by adopting them without a solid strategy.<\/p>","protected":false},"author":7,"featured_media":23649,"template":"","meta":{"_acf_changed":false,"footnotes":""},"tags":[],"news-category":[162],"class_list":["post-23655","news","type-news","status-publish","has-post-thumbnail","hentry","news-category-ai","entry"],"acf":{"tldr_content":" George Hotz, programmatore tra i pi\u00f9 noti della scena tech internazionale, ha dichiarato pubblicamente che i coding agents basati su LLM rischiano di diventare uno degli errori pi\u00f9 costosi<\/strong> nella storia dello sviluppo software. La sua valutazione arriva dopo sei mesi di test diretti. Pertanto, il suo giudizio non \u00e8 speculativo: \u00e8 empirico.<\/p> Il problema centrale non riguarda la velocit\u00e0 di prototipazione, che rimane un punto di forza riconosciuto. Tuttavia, i modelli linguistici mostrano fragilit\u00e0 significative nella gestione dei dettagli tecnici. Di conseguenza, i bug prodotti tendono ad accumularsi in strati profondi del codice, rendendosi sempre pi\u00f9 difficili da individuare nel tempo. Questo fenomeno ha un nome preciso nel settore: technical debt<\/em> silenzioso.<\/p> Per le PMI italiane che stanno valutando l'adozione di strumenti AI nello sviluppo software, questa prospettiva impone una riflessione strategica. Noi di SHM Studio<\/strong> riteniamo che l'automazione intelligente vada integrata con supervisione umana qualificata, non sostituita ad essa. In sintesi, adottare un coding agent senza un framework di controllo \u00e8 un rischio operativo concreto, non una semplice questione teorica.<\/p>"},"yoast_head":"\nHow Coding Agents Work: Architecture and Intrinsic Limitations<\/h2>\n
The phenomenon of silent technical debt<\/h2>\n
Casi d’uso PMI: dove il rischio \u00e8 pi\u00f9 elevato<\/h2>\n
\n
Il trade-off velocit\u00e0\/qualit\u00e0: un calcolo che le PMI devono fare<\/h2>\n
La divisione nella comunit\u00e0 AI: non \u00e8 solo Hotz<\/h2>\n
What nobody considers: the cost of supervision<\/h2>\n
The recommended decision: an operational framework for SMEs<\/h2>\n