Riscrivere una modifica di codice sta diventando più semplice. Tuttavia, testare, rivedere, proteggere e distribuire in modo affidabile questa modifica per i clienti rimane un compito molto più complesso. Harness scommette che il prossimo avanzamento nello sviluppo software basato su IA provenga dalla connessione di 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 le tecnologie associate. Il team dietro questi prodotti si unisce a Harness. Cosmos diventerà il Harness Cosmos Software Factory Agent, estendendo la piattaforma di consegna software dell'azienda al lavoro di ingegneria che avviene prima che una modifica raggiunga un pipeline di distribuzione.
Questa distinzione è importante: si tratta di un'acquisizione di asset selezionati e del loro team associato, e non di un acquisto dichiarato dell'intera società Augment Code. La sua importanza risiede nella tecnologia riunita: agenti capaci di comprendere e modificare una base di codice, affiancati da sistemi che comprendono come questo codice viene testato, distribuito e utilizzato.
Cosa Harness porta alla sua piattaforma
L'annuncio posiziona Cosmos come punto di partenza di un ciclo di vita dello sviluppo software (SDLC) sempre più autonomo. Una richiesta, un ticket assegnato o un bug segnalato può innescare un flusso di lavoro coordinato in cui gli agenti pianificano una modifica, scrivono il codice e i test, e aprono una pull request. Gli ingegneri rimangono coinvolti nei punti di giudizio, in particolare per approvare una progettazione e prendere la decisione finale di fusione.
Questo va oltre la generazione di una correzione iniziale. Gli agenti Cosmos possono continuare a lavorare sulla stessa pull request quando i revisori lasciano commenti o quando i controlli falliscono. Gli esperti pre-costruiti, tra cui Project Builder, PR Author, Deep Reviewer e PR Fixer, offrono alle squadre flussi di lavoro che possono adattare ai propri depositi e standard.
Ogni agente funziona in una macchina virtuale isolata. Il routing del modello, le integrazioni con GitHub, Jira e Slack, la memoria condivisa, il versioning e i controlli di bilancio offrono l'infrastruttura circostante che permette di eseguire questo lavoro all'interno di un'organizzazione di ingegneria.
Questa combinazione incarna l'idea della fabbrica software: un processo riproducibile che guida il lavoro verso un risultato revisionabile. L'unità importante è un flusso di lavoro di ingegneria completato, con prove e punti di controllo, piuttosto che il numero di righe prodotte da un agente.
Come funziona Cosmos oltre la finestra di chat
La pagina del prodotto Cosmos di Augment aggiunge dettagli utili su questo modello operativo. Le pull request, le alert, le pianificazioni e i webhook possono attivare esperti specializzati. Le squadre definiscono ambienti, integrazioni e punti di controllo umani intorno a questi trigger, permettendo al lavoro di iniziare senza che una persona debba lanciare manualmente un nuovo prompt per ogni evento.
Cosmos supporta anche la definizione di esperti e flussi di lavoro attivati da eventi sotto forma di YAML versionato, applicando le modifiche tramite l'Auggie CLI e gestendo la cronologia delle configurazioni in Git. Questo rende il flusso di lavoro dell'agente un elemento che il team può ispezionare e modificare utilizzando pratiche di ingegneria familiari. La pagina del prodotto descrive le conoscenze organizzative condivise e i limiti di spesa in complemento a questi controlli.
Per un team di sviluppo, questo cambia il problema di coordinamento. Un agente che risponde a un ticket assegnato ha bisogno di un obiettivo chiaramente delimitato, di accesso agli strumenti giusti e di un luogo dove segnalare il suo risultato. Un agente attivato da un controllo che fallisce ha bisogno delle prove del fallimento e dell'autorizzazione per modificare i file interessati. I flussi di lavoro riutilizzabili possono codificare queste esigenze, anche se la loro efficacia dipende sempre dalla rigorosità con cui l'organizzazione li configura.
Il Code Context Engine è al cuore dell'operazione
Gli agenti che lavorano su software aziendali si trovano di fronte a un problema che una risposta di codifica fluida non può risolvere da sola: trovare il contesto giusto. Un deposito può contenere diversi servizi, implementazioni obsolete, convenzioni locali e dipendenze difficili da dedurre da un singolo file.
Secondo l'esplicazione di Augment del suo Code Context Engine, il sistema indice semanticamente il codice e recupera le informazioni pertinenti per il compito. Si basa sulle relazioni tra depositi e servizi, sulla cronologia dei commit, sui modelli della base di codice e sui documenti di supporto come la documentazione e i ticket. Piuttosto che inserire un intero deposito in un prompt, classifica e seleziona il contesto pertinente.
Il valore pratico è più facile da capire attraverso un esempio. Una richiesta di modifica di un endpoint di pagamento può anche influenzare la validazione, un servizio a valle, un gestore di webhook e i test. Recuperare queste connessioni può offrire a un agente di codifica un punto di partenza migliore rispetto al solo file dell'endpoint. Si tratta di un'illustrazione del problema che la tecnologia risolve, e non di una garanzia che ogni dipendenza interessata sarà rilevata.
Collegare il deposito al sistema in esecuzione
Harness è già attivo dal lato della consegna del ciclo di vita. I suoi agenti coprono la consegna del software, i test di sicurezza, la protezione in tempo reale e la gestione dei costi. L'acquisizione crea un percorso che permette al lavoro di ingegneria preparato da Cosmos di passare a questi flussi di lavoro a valle.
Il Software Delivery Knowledge Graph dell'azienda è progettato per collegare le informazioni provenienti da Git, CI/CD, dall'infrastruttura cloud, dalla sicurezza e dagli strumenti operativi. Harness descrive una semantica con relazioni strutturate, identità canoniche e filtraggio degli accessi. Un esempio concreto consiste nel risolvere i diversi nomi di un servizio nello stesso deposito, Kubernetes e nei sistemi di monitoraggio.
Questo problema di identità ha conseguenze. Un risultato di vulnerabilità associato a un servizio distribuito è più utile quando può essere tracciato fino all'artefatto e alla versione del codice interessati. Un fallimento di test deve essere collegato alla modifica realmente esaminata. Raccogliere ulteriori log non stabilisce automaticamente queste relazioni.
Nella sua annuncio di acquisizione, Harness descrive il collegamento del Code Context Engine e del Software Delivery Knowledge Graph come un prossimo passo previsto. Il ciclo di feedback previsto rimanderebbe i risultati a valle al flusso di lavoro di ingegneria affinché un agente possa preparare una correzione e rimandarla nuovamente alla validazione. I lettori devono distinguere questa direzione di integrazione da un'affermazione secondo cui ogni parte del flusso di lavoro combinato è già consegnata.
L'autonomia richiede ancora una decisione di pubblicazione
Il ciclo proposto potrebbe ridurre una fonte familiare di carico di ingegneria: la ricostruzione di un problema e il trasporto del suo contesto tra gli strumenti. Se i test rivelano una regressione, il risultato utile è una correzione collegata alla verifica fallita, seguita da una prova che la correzione funziona. Aprire un'altra pull request senza questa prova non farebbe altro che spostare il collo di bottiglia.
La supervisione umana rimane una parte dell'architettura. L'isolamento limita l'ambiente di esecuzione, ma non garantisce.