Di recente ho letto l’articolo di Ramp su come hanno costruito il proprio agente di programmazione in background, che chiamano Inspect. È un ottimo articolo e arriva al momento giusto per il team di ingegneria di Cartesia, mentre ragioniamo su come estendere a tutto il team i vantaggi di produttività degli agenti di programmazione IA.
In Cartesia abbiamo adottato gli agenti di programmazione con convinzione. Nel team usiamo Claude Code, Cursor, Codex, Copilot, Zed, Conductor e altri. Nei nostri monorepo puoi aspettarti una revisione da Claude Code, Cursor BugBot, Vercel Agent e Codex. Le revisioni portano osservazioni diverse, a volte complementari e a volte contraddittorie, che migliorano concretamente la qualità del codice pubblicato. Al momento il preferito è BugBot:
Non è il risultato di un obbligo imposto dall’alto. È nato dall’interesse spontaneo per modi di lavorare meglio e più velocemente e automatizzare il più possibile le parti noiose, insieme alla disponibilità a spendere quanto serve per sperimentare.
Sperimentare ampiamente ci ha aiutato a confrontare gli agenti e provare i progressi più recenti. Il modo di lavorare si riscrive ogni pochi mesi.
Ma sembra che manchi ancora qualcosa.
Scrivere codice sembra un problema risolto. Fare ingegneria no.
I modelli più avanzati possono eseguire refactoring complessi e collegare codice a endpoint ad alto traffico. Spesso sembrano capaci di anticipare i problemi. Abbiamo scoperto che cambiamenti semplici, come mettere il codice in un monorepo, hanno un effetto enorme: gli agenti possono ragionare tra i componenti del sistema ed evitare bug sottili. Gli agenti di revisione aiutano a colmare le lacune nel codice. Scrivere il codice non è più il collo di bottiglia.
Ma programmare e fare ingegneria non sono la stessa cosa. Un bravo ingegnere pensa all’impatto oltre che a collegare codice in un monorepo. Valuta se una funzionalità sta funzionando, la migliora in base ai riscontri reali e continua finché gli obiettivi aziendali non sono raggiunti.
È qui che gli agenti non bastano. Abbiamo usato Opus 4.5 per rimuovere in sicurezza una funzionalità di oltre 10K righe:
Ma non possiamo ancora chiedergli di capire se una funzionalità sta ottenendo risultati in produzione e migliorarla, o di collegare un picco di latenza API a una riga del nostro codice.
Il vero collo di bottiglia sono i cicli di feedback interrotti
Gli agenti falliscono perché si fermano davanti a limiti pratici, non perché non sappiano scrivere codice. Opus 4.5 può scrivere correttamente il codice di un test A/B, ma non controllare PostHog per vedere se l’esperimento ha funzionato, quindi si ferma. Può distribuire una correzione all’interfaccia, ma non accedere all’anteprima Vercel per verificarne l’aspetto. Può ottimizzare una query SQL, ma non vedere le metriche di produzione per confermare il miglioramento.
Qui vediamo l’opportunità: dare agli agenti, in sicurezza, l’infrastruttura giusta per lavorare da un capo all’altro. Accesso a repository, CI, anteprime, dashboard interne, dati PostHog e tutto ciò che serve per giudicare successi e fallimenti come farebbe un ingegnere umano.
Il bello è che questo porta benefici concreti anche alle persone. Se rendi la CI più veloce o lo stack completo più facile da avviare, gli ingegneri iniziano a lavorare prima e restano più produttivi.
Aumentare la produttività con gli agenti è una funzione strategica
Gli ingegneri sono spesso troppo concentrati sul problema del momento per considerare l’intera esperienza di sviluppo. Seguire i progressi, sperimentare gli ultimi strumenti e trasformare ciò che si impara in prodotti interni è un lavoro a tempo pieno.
L’opportunità va oltre l’ingegneria. Pensiamo che gli stessi principi di infrastruttura pensata per l’IA che rendono più produttivi gli agenti possano trasformare i flussi interni di tutta l’azienda. I team di go-to-market, business e vendite svolgono molto lavoro ripetitivo: automatizzarlo bene può avere un effetto enorme.
Questa distanza tra capacità degli agenti e infrastruttura non si colmerà da sola. Serve qualcuno che progetti attivamente l’esperienza di sviluppo sia per le persone sia per l’IA.
Stiamo lavorando a questo problema e cerchiamo un ingegnere AI & Developer Acceleration, cioè una persona che acceleri il lavoro di IA e sviluppatori. Se ti unisci a noi, definirai il metodo che permette a ingegneri e non ingegneri di passare dal problema alla soluzione con il minimo intervento umano. Potrai anche raccontarlo pubblicamente. Contattaci!