Questa azienda ha tenuto Claude e Codex e ha spostato le scartoffie sull’IA locale

Una persona chiede a un agente di programmazione di correggere un bug in un servizio. Prima l’agente deve trovare il ticket originale, recuperare alcune decisioni di prodotto e capire quali requisiti siano ancora validi. Dopo la patch qualcuno deve trasformare il lavoro restante in ticket visibili a chi si occupa di design o assistenza. Cambiare il codice è solo una parte, ma tutto il lavoro può ricadere sullo stesso modello a pagamento.

Grayhat Developers, un’azienda di software con meno di 40 persone, ha descritto che cosa è successo quando ha separato questi compiti in un preprint del 5 novembre 2026. Gli ingegneri avevano provato modelli ospitati in proprio per lo sviluppo. Avevano scoperto che sostituire gli agenti commerciali rendeva alcuni lavori sul repository più lenti o difficili. Hanno mantenuto quegli agenti per le modifiche complesse e spostato parte del recupero dei documenti, della preparazione e della sincronizzazione dei ticket su un servizio locale.

Per un altro piccolo gruppo la domanda interessante è che cosa spostare per primo. L’esperienza di Grayhat offre un punto di partenza concreto, una stima da esaminare e un errore di configurazione iniziale che può affossare il test prima che si impari qualcosa sulla qualità del modello.

Correggere un bug richiede contesto prima di toccare il codice

Grayhat usava Outline per la documentazione, Plane per seguire il lavoro ed ERPNext per le informazioni organizzative. Aveva già ospitato questi servizi su una macchina in ufficio e collegato la gestione delle identità tramite Authentik. Ospitava sulla stessa macchina i connettori del Model Context Protocol, o MCP. Un secondo computer gestiva l’inferenza. La separazione aveva uno scopo pratico. Documentazione e ticket potevano continuare a servire le proprie interfacce mentre i processi dei modelli consumavano risorse altrove.

Il processo descritto nello studio prevede passaggi di consegne tra persone. Un collega usa il modello interno per recuperare e condensare materiale dalla wiki o dal sistema di ticket. Le parti pertinenti possono finire in un file del repository destinato all’agente di programmazione. Dopo il lavoro sul repository, un collega può portare i prossimi passi all’assistente interno, trasformarli in bozze e inviarle al sistema. Lo studio lascia la comunicazione diretta tra agenti a un lavoro futuro. Nel flusso attuale una persona può esaminare le informazioni al momento del passaggio e decidere se trasferirle.

I passaggi di consegne nel flusso di Grayhat. Illustrazione originale di Telli.sh, basata sul caso del 5 novembre.

Supponi che un cliente segnali righe duplicate in un’esportazione. La segnalazione include un riferimento privato all’account e una trascrizione irrilevante per il bug. Un assistente locale può trovare le regole attuali di esportazione, il responsabile del servizio e la soluzione temporanea precedente. L’ingegnere può quindi scrivere una sintesi con un esempio sintetico e il numero di righe atteso. L’agente di programmazione riceve ciò che gli serve per riprodurre il problema. Il materiale sensibile resta nei sistemi interni perché una persona ha scelto che cosa trasferire.

Conserva i link originali nella bozza interna. Quando i requisiti divergono, chi revisiona può vedere se una regola proviene da una decisione recente o da una vecchia soluzione temporanea. Una sintesi locale che perde le fonti ricrea il problema che doveva risolvere. Il prossimo collega dovrà capire di quale descrizione fidarsi.

Il gruppo ha comprato capacità e ha stimato quanta potesse spostarne

Gli autori dichiarano una spesa commerciale di riferimento di circa 325 dollari al mese, composta da circa 175 dollari per sette licenze Claude, 140 per sette abbonamenti a Codex e 10 in crediti. Dichiarano inoltre più di 25,93 miliardi di token registrati tra i servizi. Lo studio non stabilisce che questi token appartengano allo stesso intervallo di fatturazione dei 325 dollari. Le cifre misurano aspetti diversi e dividerle non dà un prezzo per token.

Il gruppo Grayhat ha stimato che trasferimento del contesto, documentazione e coordinamento dei progetti rappresentassero il 30–40% del suo lavoro con l’IA commerciale. Gli autori hanno stimato che il sistema locale potesse assorbire circa il 90% di quella categoria. Il prodotto delle due quote dà il 27–36% del carico commerciale complessivo. Applicando la quota a 325 dollari si ottengono circa 88–117 dollari al mese. Sono stime di carico e di costo equivalente nel caso del 5 novembre. Lo studio non ha svolto un confronto controllato delle fatture prima e dopo.

La stima di Grayhat parte da una quota di lavoro e arriva a un costo equivalente. Illustrazione originale di Telli.sh.

La distinzione conta quando si paga per licenza. Se sette sviluppatori continuano ad aver bisogno degli abbonamenti per il lavoro complesso, usarli meno può lasciare invariata la prossima fattura. Il vantaggio può emergere come capacità per altre patch, meno pressione sui limiti o meno acquisti per gli sforamenti. Chi paga per richiesta può vedere prima un cambiamento, anche se tentativi ripetuti e code lente possono assorbire una parte del risparmio apparente. Se occorre comprare una GPU e pagare qualcuno per mantenerla disponibile, includi anche quei costi.

Scegli un’unità che puoi controllare. Contare i ticket scritti è facile, ma se chi guida il progetto li riscrive da capo c’è poca prova di risparmio. Misura sintesi e ticket accettati e registra le correzioni che cambiano il senso del compito. Quando chi revisiona riconosce in modo coerente un risultato accettabile, misura il lavoro necessario per produrlo.

La seconda interfaccia ha cambiato chi doveva fare la configurazione

Il primo rilascio usava LobeHub. Gli ingegneri ricevevano istruzioni per collegare la propria interfaccia agli strumenti interni. Gli autori riferiscono che dimostrazioni promettenti non si sono tradotte in uso regolare. Serviva sapere quale connettore scegliere, dove si trovava e come autenticarsi. Ogni scelta in più ritardava la prima risposta utile.

La seconda interfaccia di Grayhat configurava centralmente gli strumenti di lavoro. Figura 2 di «Create Your Own Work Stack» di Saad Ahmed Bazaz, Talha Amjad, Abdurrehman Subhani, Sohaib Ahmed Bazaz e Abdullah Aamir, CC BY 4.0.

Il gruppo è passato a un’installazione LibreChat configurata centralmente. Gli utenti potevano vedere gli strumenti configurati e autenticarsi quando vi accedevano. Gli autori hanno contato otto commenti sulla configurazione e sul primo utilizzo in 11 interviste strutturate sulla prima versione. La seconda ha generato tre commenti in quella categoria attraverso riscontri non strutturati su Discord. Le cifre provengono da metodi di raccolta diversi. Aiutano a identificare il problema iniziale, ma non dicono quanto sia cresciuta l’adozione né quante persone abbiano smesso di incontrarlo.

Progetta la prima sessione intorno al compito reale più semplice. Chi entra per cercare i criteri di accettazione di un ticket dovrebbe poter vedere se il sistema è collegato e quale account è attivo. Chi vuole preparare tre ticket dovrebbe poterli rivedere prima di pubblicarli. Insegnare alle persone a configurare connettori prima di trovare il proprio lavoro rischia di misurare la pazienza invece dell’utilità.

La configurazione centrale introduce una responsabilità. Qualcuno deve mantenere l’elenco dei connettori approvati, rinnovare le credenziali e spiegare chi può modificare i permessi. Altrimenti un errore di una persona può diventare il problema di tutti. Il vantaggio è che il gruppo può correggere una difficoltà ricorrente una volta sola e applicare la correzione a tutti gli utenti del servizio.

Affida al sistema locale compiti con un responsabile chiaro

La classificazione dei ticket è un primo caso pratico. L’assistente interno può raggruppare segnalazioni duplicate e proporre una sintesi con link ai ticket di origine. Chi guida il progetto decide se sono davvero duplicati e se la descrizione unificata omette qualche condizione. L’assistente può preparare un commento che spiega il raggruppamento. Il cambiamento è comprensibile perché ha un responsabile visibile.

La manutenzione della documentazione è un compito diverso. Supponi che un’impostazione passi da una schermata a un’altra. L’assistente può trovare le pagine di aiuto superate, individuare le edizioni del prodotto che riguardano e proporre modifiche. Un editor verifica la navigazione attuale e pubblica le correzioni. Un modello remoto più potente aggiunge poco se la parte difficile è accedere alle pagine interne correnti e rispettare l’ambito di ciascun articolo.

La programmazione complessa è il caso opposto. Una migrazione di database può richiedere di esaminare contratti di dati storici, modificare più servizi e verificare il ripristino. Grayhat ha trovato che la configurazione locale provata faticava con i lavori più ampi nel repository, specie se servivano molto contesto e inferenza rapida. Lo studio descrive hardware, modelli ed esperienza del gruppo. Offre un motivo per provare il proprio carico in locale prima di ampliare l’incarico.

Usa un percorso limitato quando un compito unisce formattazione semplice e dati sensibili. Inviare una bozza fuori dalla rete può comunque esporre informazioni, anche se gli strumenti originali sono in sede. Se il passaggio remoto serve, approva la destinazione e prepara per essa solo il materiale indispensabile. In assenza di approvazione, tieni il risultato nella coda di revisione interna. Se scade il tempo, mostra un errore invece di trasferire i dati a sorpresa.

Un breve test può separare il lavoro utile dalla manutenzione

1. Definisci tre risultati. Scegli una sintesi con link al ticket, una modifica alla documentazione e una bozza di ticket. Scrivi per ciascuno chi lo accetta e quali prove servono. Tieni un esempio fallito accanto a uno buono, con errori facili da trascurare.
2. Misura il processo attuale. Per una settimana normale conta esempi completati, correzioni sostanziali e tempo per trovare il contesto. Quando puoi, attribuisci l’uso commerciale ai singoli flussi. Annota se rimuovere i compiti cambierebbe davvero le licenze fatturate o gli sforamenti. Registra separatamente il lavoro che il gruppo ha evitato del tutto.
3. Collega uno strumento interno. Parti in sola lettura con un progetto preciso. Verifica che un dipendente autorizzato possa trovare un ticket noto e che una persona esterna al progetto non possa. Limita il test a poche persone che fanno già il lavoro selezionato. Offri un percorso manuale per finirlo quando lo strumento non funziona.
4. Confronta le bozze prima di consentire la scrittura. Chiedi alla stessa persona di accettare o rifiutare i risultati con gli stessi criteri. Annota i link ai ticket sbagliati, i fatti superati e le conclusioni senza sostegno. Aggiungi anteprima, approvazione e registrazione durevole prima di autorizzare modifiche a un sistema reale.
5. Verifica che cosa si è spostato. Confronta lavoro accettato, tempo di revisione, uso attivo e fatture reali. Aggiungi il tempo dedicato a manutenzione, indisponibilità e modifiche dei connettori. Includi l’assistenza diretta agli utenti. Un’app che funziona dopo dieci minuti di aiuto specialistico per persona ha ancora un costo di avvio.

Se usi già un modello locale per gli sviluppatori, provalo insieme al traffico ordinario. Le code emergono quando più persone partono nello stesso momento. Un servizio veloce per una sola richiesta può comunque fare aspettare tre persone. Per le attività urgenti, mostra l’avanzamento e offri un ritorno alla procedura manuale. Il test resta utilizzabile mentre il gruppo impara quali carichi sono adatti.

L’appendice Grayhat dà un riferimento per il confronto. Il computer degli strumenti usava 16 GB di memoria di sistema. La macchina separata per l’inferenza aveva 32 GB e una RTX 4080 con 16 GB di VRAM. Il gruppo riferisce di avere aggiunto monitoraggio di rete, pianificazione e un gruppo di continuità quando sono emerse esigenze operative. Sono dati utili per stimare il budget di un test. Riguardano il costo di gestire un servizio da cui dipendono i colleghi, oltre a quello di ottenere una risposta dal modello.

Decidi dove va la prossima ora di lavoro con l’IA

L’idea riutilizzabile è separare la preparazione del contesto dal ragionamento specialistico e dare un responsabile a ogni passaggio. Inizia da un lavoro ricorrente che produce un risultato che il gruppo sa già revisionare. Misura quanto lavoro richiede accettarlo e decidi se al percorso locale spetta un altro compito. L’esperienza di Grayhat permette di prendere questa decisione conservando gli strumenti di programmazione che continuano a portare valore.

Fonti

• Preprint di Grayhat Developers, 5 novembre 2026
• Articolo completo con stime, infrastruttura e figura 2
• Immagine originale della figura 2
• Licenza CC BY 4.0 per la figura

---

Per conservare in un archivio consultabile le discussioni dietro un passaggio di consegne, crea un account Telli.sh.