Scopri come AMP, l’agente di programmazione di frontiera di Sourcegraph, sta rivoluzionando il panorama dello sviluppo AI abbracciando iterazione rapida, ragionamento autonomo e agenti tool-calling—e perché gli strumenti di programmazione tradizionali stanno diventando obsoleti.
Il panorama degli agenti AI per la programmazione sta vivendo una trasformazione senza precedenti. Ciò che sei mesi fa era all’avanguardia oggi è considerato superato. GitHub Copilot, che rappresentava lo standard d’oro dello sviluppo assistito da AI, è stato oscurato da strumenti più recenti. Cursor ha dominato il mercato come la startup a più rapida crescita di sempre, per poi affrontare la concorrenza di soluzioni ancora più avanzate. In questo ecosistema in rapida evoluzione, Sourcegraph ha preso una decisione strategica audace: invece di migliorare gradualmente il loro prodotto Cody, hanno lanciato AMP—un agente di programmazione completamente nuovo costruito da zero per abbracciare la frontiera delle capacità AI.
Questo articolo esplora la filosofia, l’architettura tecnica e la strategia di business dietro AMP, traendo spunti da conversazioni con il team che ha realizzato questo strumento rivoluzionario. Vedremo perché gli approcci tradizionali allo sviluppo prodotto falliscono nell’era dell’avanzamento AI rapido, come gli agenti tool-calling sono radicalmente diversi dagli assistenti AI precedenti, e che aspetto ha il futuro dello sviluppo autonomo. Ma, soprattutto, capiremo perché “l’imperatore è nudo”—perché prodotti affermati e apparentemente invincibili possono diventare irrilevanti quasi da un giorno all’altro quando la tecnologia sottostante cambia.
{{ youtubevideo videoID=“b4rOVZWLW6E” provider=“youtube” title=“AMP: L’imperatore è nudo - Perché gli agenti AI per la programmazione stanno sconvolgendo gli strumenti per sviluppatori” class=“rounded-lg shadow-md” }}
L’evoluzione dello sviluppo assistito da AI ha seguito una traiettoria chiara, ogni generazione costruendo sulla precedente ma cambiando radicalmente il modo in cui gli sviluppatori interagiscono con l’intelligenza artificiale. Per capire l’importanza di AMP, bisogna prima capire cosa distingue un agente di programmazione dalle precedenti forme di assistenza AI. Il viaggio è iniziato con GitHub Copilot, che ha introdotto funzioni di completamento e suggerimento del codice direttamente negli editor degli sviluppatori. Copilot è stato rivoluzionario perché ha portato l’AI nel workflow di sviluppo in modo non invasivo, offrendo suggerimenti durante la scrittura. Tuttavia, Copilot era fondamentalmente limitato: poteva suggerire codice, ma non poteva eseguire compiti complessi a più step né interagire con l’ambiente di sviluppo nel suo complesso.
La generazione successiva ha portato strumenti come Cursor e Windsurf, che hanno adottato un approccio diverso creando fork degli IDE con un’integrazione AI più profonda nell’ambiente di sviluppo. Questi strumenti hanno dimostrato che capacità parzialmente agentiche—dove l’AI poteva svolgere operazioni più complesse nell’IDE—potevano migliorare notevolmente la produttività degli sviluppatori. Hanno mostrato che gli sviluppatori erano disposti a cambiare il proprio ambiente di sviluppo se le capacità AI erano sufficientemente avanzate. Tuttavia, anche questi strumenti operavano entro certi limiti: erano interattivi, richiedevano input e approvazione dello sviluppatore a ogni step e non potevano operare davvero in autonomia.
Un agente di programmazione, invece, rappresenta un’architettura fondamentalmente diversa. Un agente è composto da tre elementi chiave: un modello linguistico (di solito un modello di frontiera come Claude 3.5), un prompt di sistema che definisce comportamento e vincoli dell’agente, e una serie di strumenti con prompt associati che descrivono cosa può fare ciascun tool. La differenza cruciale è che gli agenti possono operare con permessi espliciti per interagire con sistemi esterni—file system, editor di codice, sistemi di versionamento e altro ancora. Questo significa che un agente può ragionare autonomamente su un problema, decidere quali strumenti usare, eseguirli, osservare i risultati e iterare fino al completamento del compito. Questo è molto più potente di qualsiasi approccio precedente perché abilita un vero comportamento autonomo, non solo suggerimenti migliorati o assistenza interattiva.
Il panorama tecnologico è entrato in una fase di instabilità senza precedenti. Ciò che era all’avanguardia diciotto mesi fa oggi è considerato primitivo. GitHub Copilot, lanciato nel 2021, è stato davvero rivoluzionario—ha rappresentato la prima applicazione mainstream di modelli linguistici di grandi dimensioni allo sviluppo software. Eppure oggi molti sviluppatori non lo considerano nemmeno tra le prime scelte per la programmazione assistita da AI. Non perché Copilot sia peggiorato, ma perché la tecnologia sottostante è avanzata così rapidamente da spostare l’intera categoria. Questo crea una sfida profonda per le aziende consolidate: come mantenere un prodotto di successo mentre il terreno sotto di esso cambia costantemente?
Lo sviluppo prodotto tradizionale presuppone una base relativamente stabile. Si trova il product-market fit, si scala il prodotto, si implementano buone pratiche ingegneristiche, si aggiungono funzionalità enterprise, si stipulano contratti a lungo termine con i clienti. Questo schema ha funzionato per decenni perché la tecnologia di solito evolve gradualmente. Ma nell’attuale era dell’AI, questo approccio è addirittura dannoso. Se ottimizzi il prodotto per la scalabilità e la stabilità, diventi lento. Se diventi lento, perdi la prossima ondata di miglioramenti nelle capacità. Quando hai aggiunto le funzionalità enterprise e le check di compliance, è stato rilasciato un nuovo modello che rende obsoleto il tuo approccio.
Sourcegraph si è trovata esattamente in questo dilemma con Cody. Cody era un prodotto di successo con clienti enterprise, contratti a lungo termine e ricavi significativi. Ma Cody era strettamente integrato con la piattaforma Sourcegraph, quindi era vincolato ai suoi cicli di rilascio. La piattaforma aveva la propria infrastruttura, il proprio calendario di deploy e i propri vincoli. Quando è stato rilasciato Claude 3.5 Sonnet e il team ha capito che potevano costruire qualcosa di radicalmente diverso—un agente tool-calling con capacità di ragionamento autonomo—si sono trovati davanti a una scelta: provare a integrare queste capacità in Cody, oppure ripartire da zero con un nuovo prodotto. Hanno scelto di ripartire da zero, e questa decisione rivela un’intuizione cruciale per competere in mercati in rapida evoluzione.
La chiave era rendersi conto che non si può rendere sostenibile un modello in abbonamento da 20$ per un agente tool-calling. I costi computazionali sono fondamentalmente diversi. Un assistente basato su chat come Cody può funzionare in modo efficiente su infrastrutture modeste. Un agente tool-calling che ragiona sul codice, esegue strumenti e itera in autonomia richiede molte più risorse di calcolo. Non è solo un problema di prezzo; è il segnale che il prodotto è radicalmente diverso e richiede un business model, aspettative dei clienti e strategie go-to-market differenti. Creando AMP come prodotto separato con un brand separato, Sourcegraph ha potuto ridefinire completamente queste aspettative. Hanno potuto dire ai clienti: “Questo non è Cody 2.0. È una cosa completamente diversa. Costa di più perché fa di più. Funziona diversamente perché ha un’architettura diversa.”
Per apprezzare davvero perché AMP rappresenta un cambio di paradigma, bisogna comprendere in dettaglio l’architettura tecnica degli agenti tool-calling. Un agente tool-calling non è semplicemente un modello linguistico con accesso a funzioni. L’architettura è più sofisticata e potente. Il sistema parte da un modello linguistico di frontiera—nel caso di AMP, Claude 3.5 Sonnet—addestrato per comprendere e utilizzare efficacemente gli strumenti. Il modello riceve un prompt di sistema che ne definisce ruolo, vincoli e obiettivi. Fondamentale: il prompt di sistema non è solo un’istruzione generica; è un prompt ingegnerizzato con cura che plasma il modo in cui il modello ragiona e decide quali strumenti utilizzare.
Accanto al prompt di sistema, ogni strumento ha il proprio prompt che descrive cosa fa, quali parametri accetta, cosa restituisce e quando va usato. Questo è cruciale perché il modello linguistico deve capire non solo che esiste uno strumento, ma a cosa serve e quando è appropriato usarlo. Ad esempio, un agente può avere strumenti per leggere file, scrivere file, eseguire codice, lanciare test e committare modifiche. Ogni tool ha una descrizione dettagliata che aiuta il modello a ragionare su quale usare in quale situazione. Il modello può quindi decidere in autonomia di usare questi strumenti, osservare i risultati e iterare in base a ciò che apprende.
La potenza di questa architettura appare chiara considerando cosa può fare un agente. Uno sviluppatore potrebbe chiedere all’agente di “implementare una nuova funzione che aggiunge autenticazione utente a questa codebase.” L’agente può quindi: leggere il codice esistente per comprenderne l’architettura, identificare dove integrare l’autenticazione, scrivere il codice necessario, lanciare i test per verificare l’implementazione, gestire eventuali errori modificando il codice ed eventualmente committare le modifiche. Tutto questo avviene senza intervento umano. L’agente ragiona sul problema, decide quali strumenti usare e itera in base al feedback degli strumenti stessi.
Questo è fondamentalmente diverso dagli strumenti AI precedenti. Copilot può suggerire codice, ma non può eseguire workflow multi-step. Cursor può svolgere operazioni più complesse, ma richiede approvazione umana a ogni step. Un agente può operare in autonomia con permessi espliciti. Questo crea una nuova categoria di capacità di gran lunga più potente. Tuttavia, crea anche nuove sfide. Gli agenti autonomi possono commettere errori su vasta scala. Possono eseguire operazioni dannose se non adeguatamente vincolati. Richiedono un’attenta ingegnerizzazione del prompt di sistema per garantire il comportamento desiderato. Queste sfide spiegano l’importanza dell’architettura e dell’approccio di AMP.
Quando il team AMP ha iniziato a costruire, ha preso una decisione fondamentale: velocità e iterazione sarebbero stati il principale obiettivo di ottimizzazione. Tutto il resto ne sarebbe derivato. Questo significava abbandonare molte delle pratiche che avevano reso Sourcegraph un successo con Cody. Niente code review formali. Niente cicli di pianificazione estesi. Niente checklist di sicurezza e compliance che richiedono nove mesi. Il team ha invece adottato la mentalità di un progetto personale: push su main, 15 deploy al giorno, dogfooding costante del prodotto e iterazione basata sull’uso reale.
Questo approccio può sembrare caotico e, secondo gli standard tradizionali dell’ingegneria software, lo è. Ma è esattamente la strategia giusta per un prodotto che opera sulla frontiera delle capacità AI. Il motivo è semplice: la frontiera si muove. Ogni pochi mesi viene rilasciato un nuovo modello. Ogni poche settimane emergono nuove capacità. Ogni pochi giorni si scoprono nuove tecniche di prompt engineering o design di strumenti. In questo contesto, la capacità di iterare rapidamente vale più della capacità di scalare in modo affidabile. Un prodotto che rilascia 15 volte al giorno può incorporare nuove capacità di modello entro poche ore dalla loro uscita. Un prodotto che segue cicli tradizionali sarà mesi indietro.
La struttura del team riflette questa filosofia. Il team core di AMP è piccolo—circa otto persone—a differenza di organizzazioni ingegneristiche più grandi. Questa dimensione ridotta è intenzionale. Permette decisioni rapide ed elimina la burocrazia comunicativa che rallenta i team più grandi. Tutti i membri sono esperti, quindi possono lavorare senza code review estese. Fanno dogfooding costante, quindi individuano rapidamente i problemi e comprendono intimamente le esigenze degli utenti. Non stanno cercando di costruire un prodotto per ogni sviluppatore; stanno costruendo un prodotto per chi vuole muoversi alla loro stessa velocità, restare sulla frontiera dell’AI e abbracciare nuovi approcci.
Questo posizionamento è cruciale. AMP non vuole essere GitHub Copilot per tutti. Non vuole essere lo strumento AI di default per ogni sviluppatore. Vuole essere lo strumento per chi vuole muoversi veloce e restare sulla frontiera. È un mercato molto più piccolo di “tutti gli sviluppatori”, ma è disposto a pagare molto di più per capacità superiori. Il business model riflette questa scelta: invece di un abbonamento da 20$ al mese, i clienti AMP pagano centinaia di dollari al mese. Alcuni team hanno run rate annui di centinaia di migliaia di dollari. Questo è possibile perché il valore offerto è così forte per il mercato target.
I principi che guidano lo sviluppo di AMP—iterazione rapida, posizionamento sulla frontiera, ragionamento autonomo—sono direttamente applicabili anche all’automazione dei workflow in senso più ampio. FlowHunt, come piattaforma per costruire e automatizzare workflow complessi, affronta sfide e opportunità simili. Proprio come AMP si posiziona per gestire la prossima generazione di capacità AI, FlowHunt può aiutare le organizzazioni a costruire workflow resilienti al cambiamento tecnologico rapido. Puntando su flessibilità, iterazione rapida e capacità di integrare nuovi strumenti e capacità in fretta, FlowHunt permette ai team di restare in vantaggio.
La chiave è che in un contesto tecnologico che evolve velocemente, la capacità di adattarsi rapidamente vale più di quella di ottimizzare per le condizioni attuali. Questo vale sia che tu stia costruendo un agente AI per la programmazione sia che tu stia automatizzando processi aziendali. L’approccio di FlowHunt, che permette una creazione, test e iterazione rapida dei workflow, si allinea perfettamente a questa filosofia. I team possono costruire workflow che incorporano le ultime capacità AI, testarli velocemente e iterare in base ai risultati. Man mano che emergono nuovi modelli e strumenti, i workflow possono essere aggiornati rapidamente senza bisogno di reingegnerizzazione. Questo è il futuro dell’automazione: non processi statici ottimizzati, ma workflow dinamici e adattivi che evolvono insieme alla tecnologia.
Il mercato degli agenti AI per la programmazione offre un caso di studio affascinante su quanto rapidamente possa cambiare la leadership di mercato. All’inizio del 2024, Cursor era considerato il re degli strumenti AI per la programmazione. Era la startup a più rapida crescita di sempre. Gli sviluppatori migravano in massa da altri strumenti a Cursor. Il mercato sembrava assestato. Poi, nel giro di pochi mesi, la conversazione è cambiata. Sono emersi nuovi strumenti. Le capacità sono migliorate. Gli sviluppatori hanno iniziato a porsi domande diverse. A metà 2024, se chiedevi quale fosse il miglior strumento AI per la programmazione, molti non avrebbero più nominato Cursor per primo. Il mercato si è spostato così rapidamente che il leader precedente non era più chiaramente dominante.
Questo schema non è unico degli agenti per la programmazione. È una caratteristica fondamentale dei mercati in cui la tecnologia sottostante avanza rapidamente. In questi mercati, la capacità di muoversi velocemente e adattarsi conta più della quota di mercato attuale. Un’azienda con il 30% di mercato che itera rapidamente e integra nuove capacità supererà una con il 50% che si muove lentamente. Ecco perché la decisione di Sourcegraph di creare AMP come prodotto separato è stata così strategica. Separando AMP da Cody, si sono liberati dai vincoli che li avrebbero rallentati. Hanno potuto muoversi velocemente, iterare rapidamente e posizionarsi sulla frontiera.
La lezione più ampia è che nei mercati in rapido mutamento, spesso l’imperatore è nudo. Prodotti affermati che sembrano dominanti possono diventare obsoleti sorprendentemente in fretta. Non perché peggiorano, ma perché la tecnologia cambia e non riescono ad adattarsi abbastanza velocemente. Chi ha successo è chi comprende questa dinamica e si posiziona di conseguenza. Non ottimizza per le condizioni attuali; ottimizza per la capacità di adattarsi a quelle future. Non cerca di servire ogni cliente; si concentra su chi valorizza velocità e innovazione. Non segue i processi tradizionali; adotta pratiche che permettono iterazione rapida e apprendimento.
La discussione intorno ad AMP rivela un’intuizione importante sul futuro degli agenti AI: il prossimo grande salto sarà dagli agenti interattivi agli agenti asincroni. Attualmente, la maggior parte degli agenti AI per la programmazione opera in modo interattivo. Uno sviluppatore lancia un agente nel proprio editor o CLI, l’agente esegue alcune operazioni e lo sviluppatore vede i risultati. Tipicamente c’è un solo agente in esecuzione alla volta, in modo sincrono—lo sviluppatore aspetta che termini. È già un grande passo avanti rispetto alla programmazione manuale, ma non è la forma definitiva dello sviluppo basato su agenti.
La prossima frontiera sono agenti asincroni che lavorano 24/7 in background, in parallelo. Invece di un solo agente alla volta, potresti averne 10, 50 o 100 che lavorano simultaneamente su compiti diversi. Un agente potrebbe occuparsi del refactoring di una parte del codice mentre un altro scrive test per un altro componente. Un terzo può analizzare le performance e suggerire ottimizzazioni. Tutto questo avviene senza intervento umano, e in contemporanea. Le implicazioni sono enormi: un miglioramento di 10x o 100x nella quantità di lavoro possibile, un cambiamento radicale nelle modalità operative dei team di sviluppo, e una completa riformulazione di ciò che è possibile con lo sviluppo assistito da AI.
Questo cambiamento avrà grandi impatti sui costi di inferenza, su come i team organizzano il lavoro e su cosa significa essere sviluppatori. Porterà anche nuove sfide in termini di assicurazione qualità, sicurezza e prevenzione di bug o vulnerabilità introdotte in scala dagli agenti autonomi. Ma il potenziale è enorme. Team che sapranno sfruttare efficacemente agenti asincroni potranno raggiungere in pochi giorni risultati che oggi richiedono settimane. Ecco perché posizionarsi per muoversi velocemente e adattarsi è così cruciale. Le aziende che per prime sapranno costruire agenti asincroni efficaci avranno un vantaggio competitivo enorme.
Il principio fondamentale dell’approccio AMP è costruire per l’incertezza. Il team non sa esattamente dove andrà la tecnologia, ma sa che cambierà. Non sa quali capacità conteranno di più, ma sa che ne emergeranno di nuove. Non sa come sarà il mercato tra sei mesi, ma sa che sarà diverso. Data questa incertezza, la scelta razionale è ottimizzare per l’adattabilità, non per l’ottimizzazione. Significa mantenere il codice flessibile, poter rilasciare rapidamente, restare vicini alla frontiera delle capacità AI ed essere pronti a scartare soluzioni che non funzionano più.
Questo principio si estende anche alla struttura del team, al modello di business e alla strategia clienti. Il team è piccolo ed esperto, il che permette decisioni rapide. Il modello di business è flessibile, senza pricing o user model fissi, consentendo rapide modifiche man mano che il mercato evolve. La strategia clienti si concentra su chi vuole muoversi velocemente, creando un naturale allineamento tra capacità aziendale e necessità del cliente. Tutto deriva dal principio cardine di costruire per l’incertezza e ottimizzare per l’adattabilità.
Questo è un approccio radicalmente diverso dallo sviluppo prodotto tradizionale, dove si cerca di prevedere il futuro, costruire per la scalabilità e ottimizzare per la stabilità. Ma in un mercato in cui la tecnologia sottostante avanza rapidamente, gli approcci tradizionali sono addirittura dannosi. Ti rallentano, ti bloccano su decisioni che diventano obsolete e impediscono l’adattamento alle nuove realtà. Chi ha successo in questi mercati è chi abbraccia l’incertezza, ottimizza per l’adattabilità e si muove abbastanza velocemente da restare davanti alla curva.
{{ cta-dark-panel heading=“Porta il tuo workflow al massimo con FlowHunt” description=“Scopri come FlowHunt automatizza i tuoi workflow AI per contenuti e SEO — dalla ricerca alla generazione, pubblicazione e analisi — tutto in un unico posto.” ctaPrimaryText=“Prenota una demo” ctaPrimaryURL=“https://calendly.com/liveagentsession/flowhunt-chatbot-demo" ctaSecondaryText=“Prova FlowHunt gratis” ctaSecondaryURL=“https://app.flowhunt.io/sign-in" gradientStartColor="#123456” gradientEndColor="#654321” gradientId=“827591b1-ce8c-4110-b064-7cb85a0b1217” }}
La capacità di fare 15 rilasci al giorno non è casuale; è il risultato di scelte architetturali deliberate. La prima decisione chiave è stata separare completamente AMP dalla piattaforma Sourcegraph. Cody era strettamente integrato con Sourcegraph, quindi vincolato ai suoi cicli di rilascio e ai vincoli infrastrutturali. AMP è stato costruito come prodotto standalone, con infrastruttura, pipeline di deploy e calendario rilasci propri. Questa separazione è cruciale perché elimina la necessità di coordinarsi con altri sistemi, che rallenta i sistemi più grandi. Le modifiche su AMP non richiedono coordinamenti con la piattaforma. I deploy non devono aspettare i rilasci della piattaforma.
La seconda decisione chiave è stata adottare un processo di code review minimale. Il team fa push su main e rilascia frequentemente. Se qualcosa si rompe, lo risolvono rapidamente. Sembra rischioso, ma funziona perché il team è piccolo, esperto e fa dogfooding costante. Individuano i problemi in fretta perché usano il prodotto in prima persona. Possono risolverli velocemente perché il codice è fresco nella loro mente. Iterano rapidamente perché non aspettano approvazioni di code review. Questo approccio sarebbe rischioso in una grande organizzazione, ma in un piccolo team esperto è estremamente efficace.
La terza decisione chiave è stata dogfooding aggressivo. Il team usa AMP per costruire AMP. Questo crea un feedback loop stretto, in cui il team sperimenta immediatamente problemi o limiti del prodotto. Significa anche che scoprono costantemente nuovi casi d’uso e capacità. Usare il proprio prodotto per costruirlo porta a capire rapidamente cosa funziona e cosa no, a scoprire edge case che sfuggono ai test tradizionali e a sviluppare un’intuizione su quali feature contano davvero. Ecco perché il dogfooding è così potente per iterare rapidamente.
La quarta decisione chiave è stata mantenere il codice semplice e flessibile. Invece di costruire un sistema complesso e super ottimizzato, il team ha creato qualcosa di facile da modificare ed estendere. Così possono integrare nuove capacità rapidamente. Quando esce un nuovo modello, possono integrarlo in fretta. Quando emerge una nuova tecnica di prompt engineering, possono sperimentarla subito. Se scoprono un approccio migliore, possono rifattorizzare senza timore di rompere dipendenze complesse. Questa semplicità e flessibilità, in un mercato che evolve rapidamente, valgono più dell’ottimizzazione.
Il modello di pricing di AMP rivela molto sulla creazione di valore nello sviluppo assistito da AI. All’inizio dello sviluppo, il team ha capito che non poteva far funzionare un abbonamento da 20$ al mese per un agente tool-calling. Non era solo una questione di prezzo: era il segnale che il prodotto era radicalmente diverso e richiedeva un business model diverso. Un assistente chat come Cody può funzionare efficientemente su infrastruttura modesta. Un agente tool-calling che ragiona sul codice, esegue strumenti e itera in autonomia richiede molte più risorse computazionali. Il costo infrastrutturale giustifica già prezzi più alti.
Ma il modello di pricing riflette anche il valore offerto. Per uno sviluppatore o un team che sa usare bene AMP, i guadagni di produttività sono enormi. Un agente che implementa funzioni, scrive test e fa refactoring in autonomia può far risparmiare ore o giorni ogni settimana. Per un team, questo si traduce in un valore significativo. Se AMP fa risparmiare 10 ore a settimana a un team, e una ora di sviluppatore costa 100$, AMP genera 1.000$ a settimana di valore. Chiedere centinaia di dollari al mese è solo una piccola frazione di quel valore. Ecco perché alcuni team hanno run rate annui di centinaia di migliaia di dollari: il valore è così forte che il prezzo è un affare.
Il modello di business riflette anche il posizionamento strategico. Chiedendo molto più degli strumenti tradizionali, AMP segnala di essere una categoria diversa. Non compete sul prezzo, ma su capacità e valore. Questo attira clienti che danno importanza a capacità e valore, e respinge quelli sensibili solo al prezzo. È l’esatta segmentazione giusta per un prodotto sulla frontiera AI. Vuoi clienti che capiscono e sono disposti a pagare per capacità di frontiera. Non vuoi quelli che cercano solo il prezzo più basso, perché appena arriva un’opzione più economica migrano subito.
Uno degli aspetti più interessanti dell’approccio Sourcegraph è la gestione della tensione tra innovazione e stabilità. Sourcegraph ha un business di successo e redditizio con Cody e la piattaforma Sourcegraph. Questo business genera ricavi che finanziano la sperimentazione “folle” su AMP. Ma crea anche tensioni organizzative. Come mantieni un business stabile e redditizio mentre insegui innovazione radicale? Come tieni ingegneri esperti focalizzati sul nuovo prodotto quando hanno grande esperienza sul prodotto esistente?
La risposta passa da varie decisioni. Prima di tutto, Sourcegraph ha esplicitamente deciso di non cercare di convertire i clienti Cody esistenti ad AMP. Usa invece la fiducia e i ricavi di Cody per finanziare lo sviluppo di AMP. È una distinzione cruciale. Se provassero a migrare i clienti Cody su AMP, incontrerebbero resistenza perché AMP è radicalmente diverso e richiede nuovi pattern d’uso. Tenendo Cody e AMP separati, possono servire segmenti diversi ed evitare la disruption che deriverebbe dal tentare di migrare clienti tra prodotti così diversi.
Poi, Sourcegraph ha messo insieme un team per AMP composto anche da persone senza preconcetti su come si costruisce software. Alcuni dei membri più efficaci sono persone che hanno lavorato solo in micro-aziende, anche da soli. Non hanno anni di esperienza nelle pratiche ingegneristiche tradizionali. Non hanno abitudini radicate su code review, pianificazione e ottimizzazione. Questa “mancanza di bagaglio” è in realtà un vantaggio. Possono adottare pratiche che sembrerebbero radicali a chi ha esperienza tradizionale, e lo fanno senza dissonanza cognitiva.
Infine, Sourcegraph ha reso esplicite le regole diverse per AMP. Il team non segue gli stessi processi del resto dell’azienda. Niente code review formali. Niente check di sicurezza e compliance. Niente cicli di pianificazione standard. Questo è possibile perché c’è fiducia dei clienti: sanno che AMP è un prodotto di frontiera e accettano compromessi diversi. Questa separazione esplicita delle regole è cruciale. Se AMP dovesse seguire i processi standard Sourcegraph, sarebbe lento. Separando le regole, Sourcegraph ha creato spazio per l’innovazione radicale.
La storia di AMP offre varie lezioni importanti per chi opera in mercati che evolvono rapidamente. La prima è che il successo consolidato può diventare un freno. Il successo con Cody e la piattaforma Sourcegraph avrebbe potuto bloccarli in un approccio incrementale e lento. Invece hanno riconosciuto che la tecnologia stava cambiando e hanno avuto il coraggio di partire da zero. Questo ha richiesto la sicurezza di cannibalizzare il proprio business, la saggezza di riconoscere che il vecchio approccio non avrebbe funzionato, e il coraggio di perseguire una strategia radicalmente diversa.
La seconda lezione è che velocità e adattabilità valgono più di ottimizzazione e scala in mercati che evolvono rapidamente. Il team non cerca di costruire un sistema perfettamente ottimizzato. Costruisce qualcosa di “abbastanza buono” e iterabile velocemente. Non cerca di servire ogni cliente, ma chi valorizza velocità e innovazione. Non segue processi tradizionali, ma adotta pratiche che abilitano iterazione rapida. Questo focus sull’adattabilità sopra l’ottimizzazione è controintuitivo per molte organizzazioni, ma è la scelta giusta quando la tecnologia sottostante avanza così velocemente.
La terza lezione è che team piccoli ed esperti possono superare grandi organizzazioni. Il team AMP è di circa otto persone. Tutti ingegneri esperti. Lavorano senza code review formali e senza pianificazione estesa. Rilasciano 15 volte al giorno. Fanno dogfooding costante. Questo piccolo team riesce a muoversi più velocemente e innovare più efficacemente di team molto più grandi. Perché hanno eliminato la burocrazia comunicativa e di processo che rallenta i team grandi. Hanno creato un ambiente dove l’iterazione rapida è possibile.
La quarta lezione è che bisogna resettare le aspettative quando il prodotto cambia radicalmente. I clienti Cody avevano aspettative su prezzo, feature e funzionamento. Queste aspettative non si sarebbero trasferite su AMP. Creando AMP come prodotto e brand separati, Sourcegraph ha potuto resettare completamente le aspettative. È una strategia potente quando il prodotto è radicalmente diverso da ciò che c’era prima. Invece di tentare di retrofitare nuove capacità in un prodotto vecchio, crea un nuovo prodotto e reset
AMP è un agente di programmazione di frontiera creato da Sourcegraph che utilizza modelli linguistici avanzati con funzionalità tool-calling per ragionare e applicare cambiamenti al codice in modo autonomo. A differenza di Cody, che era strettamente integrato con la piattaforma Sourcegraph e vincolato dai suoi cicli di rilascio, AMP opera in modo indipendente con la propria infrastruttura, consentendo oltre 15 deploy al giorno e una rapida iterazione su nuove capacità dei modelli.
Sourcegraph ha creato AMP come prodotto separato per evitare di interrompere i contratti enterprise esistenti e le aspettative dei clienti su Cody. Il passaggio da un assistente basato su chat a un agente tool-calling rappresenta un cambiamento fondamentale nel modo in cui gli sviluppatori interagiscono con l'AI. Creando un nuovo brand e prodotto, Sourcegraph ha potuto ridefinire le aspettative, muoversi più velocemente senza vincoli legacy e posizionarsi in prima linea nello sviluppo AI senza alienare i clienti esistenti.
Gli agenti tool-calling sono sistemi AI che combinano un modello linguistico, prompt di sistema e strumenti esterni per eseguire compiti autonomi. A differenza dei chatbot tradizionali, gli agenti tool-calling possono interagire con file system, editor di codice e altri sistemi esterni con permessi espliciti. Questo permette loro di eseguire workflow complessi e multi-step in modo autonomo, rendendoli sostanzialmente più potenti per le attività di sviluppo software.
AMP cresce di oltre il 50% mese su mese, con alcuni team che raggiungono tassi annui di centinaia di migliaia di dollari. Il prodotto ha raggiunto margini lordi positivi mantenendo questo tasso di crescita. Sourcegraph si è strategicamente focalizzata sugli sviluppatori che vogliono muoversi rapidamente e restare sulla frontiera dei modelli, invece di cercare di convertire ogni sviluppatore in azienda.
La discussione evidenzia che la prossima fase dello sviluppo AI sarà dominata da agenti asincroni che lavorano 24/7 in background. Invece di agenti interattivi che operano uno alla volta in un editor, i team faranno girare 10-100 agenti in parallelo e in autonomia, generando un miglioramento di 10-100x in output e inferenza. Il successo dipende dal posizionare il proprio prodotto per muoversi rapidamente e adattarsi man mano che emergono nuovi modelli e capacità ogni pochi mesi.
Arshia è una AI Workflow Engineer presso FlowHunt. Con una formazione in informatica e una passione per l'IA, è specializzata nella creazione di workflow efficienti che integrano strumenti di intelligenza artificiale nelle attività quotidiane, migliorando produttività e creatività.
Scopri come FlowHunt aiuta i team a creare, testare e distribuire workflow basati su AI più velocemente che mai.
Scopri come il reinforcement learning e il fine-tuning sono diventati l’approccio dominante per ottimizzare i modelli AI, dalla distillazione di GPT-4 all’asces...
Esplora gli annunci di OpenAI DevDay 2025, tra cui Apps SDK, Agent Kit e Model Context Protocol. Scopri perché il prompting è più importante che mai per costrui...
Scopri come Ona (precedentemente Gitpod) sta rivoluzionando lo sviluppo software con agent di coding AI che operano in ambienti cloud completamente configurati ...
Consenso Cookie
Usiamo i cookie per migliorare la tua esperienza di navigazione e analizzare il nostro traffico. See our privacy policy.
