Harness acquisisce asset di Augment Code per collegare gli agenti di codifica alla consegna del software

Scrivere una modifica al codice sta diventando più semplice. Far testare, revisionare, mettere in sicurezza e far funzionare affidabilmente quella modifica per i clienti rimane un compito molto più impegnativo. Harness scommette che il prossimo progresso nello sviluppo software con IA arriverà dal collegare questi due mondi.

L’8 ottobre, Harness ha annunciato di aver acquisito asset selezionati di Augment Code, tra cui Cosmos, l’Auggie CLI, il Code Context Engine e tecnologie correlate. Il team dietro questi prodotti si sta unendo a Harness. Cosmos diventerà Agente della Fabbrica Software Harness Cosmos, estendendo la piattaforma di consegna del software dell’azienda al lavoro di ingegneria che avviene prima che una modifica raggiunga una pipeline di distribuzione.

La distinzione è importante: si tratta di un’acquisizione di asset selezionati e del relativo team, piuttosto che di un acquisto dichiarato dell’intera società Augment Code. La sua rilevanza risiede nella tecnologia che viene unita: agenti che comprendono e modificano una base di codice, insieme a sistemi che comprendono come quel codice viene testato, rilasciato e gestito.

Cosa sta portando Harness nella sua piattaforma

L’annuncio posiziona Cosmos come punto di partenza per un ciclo di vita dello sviluppo software sempre più autonomo, o SDLC. Un requisito, un ticket assegnato o un bug segnalato può avviare un flusso di lavoro coordinato in cui gli agenti pianificano una modifica, scrivono codice e test, e aprono una pull request. Gli ingegneri rimangono coinvolti nei punti di giudizio, inclusa l’approvazione di un progetto e la decisione finale di merge.

Ciò va oltre la generazione di una patch iniziale. Gli agenti Cosmos possono continuare a lavorare sulla stessa pull request quando i revisori lasciano commenti o i controlli falliscono. Esperti predefiniti, tra cui Project Builder, PR Author, Deep Reviewer e PR Fixer, offrono ai team flussi di lavoro che possono adattare ai propri repository e standard.

Ogni agente opera in una macchina virtuale isolata. Il routing dei modelli, le integrazioni con GitHub, Jira e Slack, la memoria condivisa, il versionamento e i controlli di budget forniscono l’infrastruttura circostante per eseguire quel lavoro in tutta l’organizzazione ingegneristica.

Questa combinazione è l’idea della fabbrica software: un processo ripetibile che porta il lavoro verso un risultato revisionabile. L’unità importante è un flusso di lavoro ingegneristico completato, con evidenze e punti di controllo, piuttosto che il numero di righe prodotte da un agente.

Come funziona Cosmos al di là della finestra di chat

Pagina prodotto Cosmos di Augment aggiunge dettagli utili su quel modello operativo. Le pull request, gli avvisi, i programmi e i webhook possono attivare Esperti specializzati. I team definiscono ambienti, integrazioni e punti di controllo umani attorno a questi trigger, consentendo l’avvio del lavoro senza che qualcuno debba emettere manualmente un nuovo prompt per ogni evento.

Cosmos supporta anche la definizione di Esperti e flussi di lavoro basati su eventi come YAML versionato, applicando le modifiche tramite l’Auggie CLI e gestendo la cronologia della configurazione in Git. Questo rende il flusso di lavoro dell’agente stesso qualcosa che un team può ispezionare e modificare attraverso pratiche ingegneristiche familiari. La pagina prodotto descrive la conoscenza organizzativa condivisa e i limiti di spesa insieme a questi controlli.

Per un team di sviluppo, ciò cambia il problema di coordinazione. Un agente che risponde a un ticket assegnato necessita di un obiettivo chiaramente delimitato, dell’accesso agli strumenti giusti e di un luogo dove segnalare il risultato. Un agente attivato da un controllo fallito ha bisogno delle evidenze del fallimento e dell’autorizzazione a modificare i file pertinenti. I flussi di lavoro riutilizzabili possono codificare tali requisiti, sebbene la loro efficacia dipenda ancora da quanto accuratamente l’organizzazione li configuri.

Il Code Context Engine è centrale nell’accordo

Gli agenti che lavorano su software aziendali affrontano un problema che una risposta di codifica fluida non può risolvere da sola: trovare il contesto giusto. Un repository può contenere più servizi, implementazioni deprecate, convenzioni locali e dipendenze difficili da inferire da un singolo file.

Spiegazione di Augment del suo Code Context Engine afferma che il sistema indicizza semanticamente il codice e recupera le informazioni rilevanti per il compito. Si basa sulle relazioni tra repository e servizi, sulla cronologia dei commit, sui pattern della base di codice e su materiale di supporto come documentazione e ticket. Piuttosto che inserire un intero repository in un prompt, classifica e cura il contesto rilevante.

Il valore pratico è più facile da comprendere attraverso un esempio. Una richiesta di modificare un endpoint di pagamento potrebbe influire anche su validazione, un servizio a valle, un gestore di webhook e sui test. Recuperare queste connessioni può fornire a un agente di codifica un punto di partenza migliore rispetto al solo file dell’endpoint. Questa è un’illustrazione del problema che la tecnologia affronta, piuttosto che una garanzia che ogni dipendenza interessata venga trovata.

Harness sta acquisendo questa capacità di contesto insieme agli strumenti che la mettono in pratica. L’opportunità più ampia è collegare la conoscenza di ciò che il codice fa con le evidenze di ciò che accade dopo che lascia il repository.

Collegare il repository al sistema in esecuzione

Harness opera già sul lato della consegna del ciclo di vita. I suoi agenti coprono la consegna del software, i test di sicurezza, la protezione in esecuzione e la gestione dei costi. L’acquisizione crea un percorso per il lavoro di ingegneria preparato da Cosmos da spostare in quei flussi di lavoro a valle.

Il Software Delivery Knowledge Graph dell’azienda è progettato per collegare le informazioni provenienti da Git, CI/CD, infrastruttura cloud, sicurezza e strumenti operativi. Harness descrive uno strato semantico con relazioni strutturate, identità canoniche e filtraggio degli accessi. Un esempio pratico è la risoluzione di nomi diversi per lo stesso servizio tra un repository, Kubernetes e i sistemi di monitoraggio.

Quel problema di identità è rilevante. Un risultato di vulnerabilità associato a un servizio distribuito è più utile quando può essere ricondotto all’artefatto e alla versione di codice pertinenti. Un fallimento di test deve essere collegato alla modifica effettivamente in revisione. Raccogliere più log non stabilisce automaticamente tali relazioni.

Nella sua annuncio di acquisizione, Harness descrive la connessione tra Code Context Engine e Software Delivery Knowledge Graph come il prossimo passo pianificato. Il ciclo di feedback previsto restituirebbe i risultati a valle al flusso di lavoro ingegneristico affinché un agente possa preparare una correzione e inviarla nuovamente alla validazione. I lettori dovrebbero distinguere questa direzione di integrazione da un’affermazione secondo cui ogni parte del flusso di lavoro combinato è già stata consegnata.

L’autonomia richiede ancora una decisione di rilascio

Il ciclo proposto potrebbe ridurre una nota fonte di onere ingegneristico: ricostruire un problema e trasportarne il contesto tra gli strumenti. Se i test rivelano una regressione, il risultato utile è una correzione legata al controllo fallito, seguita da prove che la correzione funziona. Aprire un altro pull request senza tali prove sposterebbe semplicemente il collo di bottiglia.

La supervisione umana rimane parte dell’architettura. L’isolamento limita l’ambiente di esecuzione, ma non stabilisce che una patch sia corretta. Test, revisioni del codice, controlli di sicurezza e limiti di approvazione espliciti servono a scopi diversi. Una suite di test verde può comunque non rilevare un requisito, e una modifica tecnicamente valida può comunque risultare inappropriata per una specifica versione.

Per i clienti che valutano la piattaforma combinata, le metriche significative saranno la frequenza con cui le modifiche proposte superano la revisione, la quantità di lavoro di rifacimento richiesto e l’impatto sull’affidabilità dopo il rilascio. Il tempo risparmiato nella preparazione di una patch deve essere ponderato rispetto al tempo speso per verificarla. Questi sono criteri di valutazione, non risultati di performance dimostrati dall’annuncio di acquisizione.

Una scommessa sull’intero percorso dall’idea alla produzione

Harness afferma che Cosmos è disponibile ora e che i clienti possono continuare a utilizzare gli strumenti di codifica preferiti. Ciò lascia spazio alle organizzazioni di adottare i flussi di lavoro della fabbrica software in modo selettivo, anziché considerare l’acquisizione come un obbligo di sostituire l’intero ambiente di sviluppo.

La scommessa strategica è chiara. Man mano che la generazione di codice diventa una capacità di routine, il problema più difficile è mantenere il contesto attraverso le decisioni che rendono il software utilizzabile: implementazione, revisione, test, distribuzione e operatività. Integrare le risorse di codifica di Augment in Harness fornisce all’azienda componenti su entrambi i lati di quella divisione.

L’acquisizione sarà infine giudicata in base al fatto che tali componenti formino un ciclo di feedback affidabile. Se un risultato in produzione può portare a una correzione ben definita, verificata sul codice corretto e rilasciata secondo le politiche del team, il beneficio supera la semplice velocità di codifica. Diventa un modo migliore per trasformare il lavoro di ingegneria in software utilizzabile dai clienti.