Harness erverver Augment Code-aktiva for å koble kodeagenter med programvareleveranse

Å skrive en kodeendring blir stadig enklere. Å få den endringen testet, gjennomgått, sikret og kjørt pålitelig for kundene er fortsatt en mye større oppgave. Harness satser på at det neste fremskrittet innen AI-programvareutvikling vil komme fra å koble disse to verdenene.

Den 8. oktober kunngjorde Harness at de har ervervet utvalgte Augment Code-aktiva, inkludert Cosmos, Auggie CLI, Code Context Engine og tilhørende teknologi. Teamet bak disse produktene blir med i Harness. Cosmos vil bli Harness Cosmos Software Factory Agent, og utvider selskapets programvareleveranseplattform til ingeniørarbeidet som skjer før en endring når en distribusjonspipeline.

Distinksjonen er viktig: dette er en ervervelse av utvalgte aktiva og deres tilknyttede team, snarere enn et uttalt kjøp av hele Augment Code-selskapet. Betydningen ligger i teknologien som bringes sammen: agenter som forstår og endrer en kodebase, sammen med systemer som forstår hvordan koden blir testet, distribuert og driftsatt.

Hva Harness tilfører sin plattform

Kunngjøringen plasserer Cosmos som startpunktet for en stadig mer autonom programvareutviklingslivssyklus, eller SDLC. Et krav, en tildelt sak eller en rapportert feil kan initiere en koordinert arbeidsflyt der agenter planlegger en endring, skriver kode og tester, og åpner en pull‑request. Ingeniører forblir involvert på vurderingspunkter, inkludert godkjenning av et design og den endelige sammenslåingsbeslutningen.

Dette går utover å generere et første patch. Cosmos‑agenter kan fortsette å jobbe på samme pull‑request når reviewer‑kommentarer legges inn eller kontroller feiler. Forhåndsbygde eksperter, inkludert Project Builder, PR Author, Deep Reviewer og PR Fixer, gir team arbeidsflyter de kan tilpasse sine egne repositorier og standarder.

Hver agent opererer i en isolert virtuell maskin. Modellruting, integrasjoner med GitHub, Jira og Slack, delt minne, versjonering og budsjettkontroller gir den omkringliggende infrastrukturen for å kjøre dette arbeidet på tvers av en ingeniørorganisasjon.

Den kombinasjonen er idéen om en programvarefabrikk: en repeterbar prosess som fører arbeidet mot et gjennomgåelig resultat. Den viktige enheten er en fullført ingeniørarbeidsflyt, med bevis og sjekkpunkter, snarere enn antall linjer en agent produserer.

Hvordan Cosmos fungerer utover chat‑vinduet

Augment’s Cosmos produktside gir nyttig detalj om den driftsmodellen. Pull‑requests, varsler, tidsplaner og webhooks kan aktivere spesialiserte eksperter. Team definerer miljøer, integrasjoner og menneskelige sjekkpunkter rundt disse utløsere, slik at arbeidet kan starte uten at noen manuelt må sende en ny prompt for hver hendelse.

Cosmos støtter også definering av eksperter og hendelsesdrevne arbeidsflyter som versjonert YAML, anvendelse av endringer gjennom Auggie CLI og håndtering av konfigurasjonshistorikk i Git. Dette gjør agent‑arbeidsflyten selv til noe et team kan inspisere og endre gjennom kjente ingeniørpraksiser. Produktsiden beskriver delt organisasjonskunnskap og utgiftsgrenser sammen med disse kontrollene.

For et utviklingsteam endrer dette koordineringsproblemet. En agent som svarer på en tildelt sak trenger et tydelig avgrenset mål, tilgang til riktige verktøy og et sted å rapportere resultatet. En agent som utløses av en mislykket sjekk trenger feilevidnesbyrdene og tillatelse til å endre de relevante filene. Gjenbrukbare arbeidsflyter kan kode disse kravene, selv om deres effektivitet fortsatt avhenger av hvor nøye organisasjonen konfigurerer dem.

Code Context Engine er sentral i avtalen

Agenter som jobber med bedriftsprogramvare møter et problem som et flytende kode‑svar ikke kan løse alene: å finne riktig kontekst. Et repositorium kan inneholde flere tjenester, utdaterte implementasjoner, lokale konvensjoner og avhengigheter som er vanskelige å utlede fra én fil.

Ifølge Augment’s forklaring av sin Code Context Engine indekserer systemet kode semantisk og henter informasjon som er relevant for oppgaven. Det bygger på relasjoner på tvers av repositorier og tjenester, commit‑historikk, kodebasemønstre og støttemateriale som dokumentasjon og saker. I stedet for å plassere et helt repositorium i en prompt, rangerer og kuraterer det relevant kontekst.

Den praktiske verdien er lettere å forstå gjennom et eksempel. En forespørsel om å endre et betalings‑endpoint kan også påvirke validering, en nedstrøms tjeneste, en webhook‑handler og tester. Å hente disse koblingene kan gi en kodeagent et bedre utgangspunkt enn kun endpoint‑filen. Dette er en illustrasjon av problemet teknologien adresserer, snarere enn en garanti for at alle berørte avhengigheter blir funnet.

Harness erverver denne kontekst‑kapasiteten sammen med verktøyene som setter den i arbeid. Den bredere muligheten er å koble kunnskap om hva koden gjør med bevis på hva som skjer etter at den forlater repositoriet.

Kobling av repositoriet til det kjørende systemet

Harness opererer allerede på leveransesiden av livssyklusen. Dens agenter dekker programvareleveranse, sikkerhetstesting, kjøretidsbeskyttelse og kostnadsstyring. Oppkjøpet skaper en vei for ingeniørarbeid forberedt av Cosmos til å flytte inn i disse nedstrøms arbeidsflytene.

Selskapets Software Delivery Knowledge Graph er designet for å koble informasjon fra Git, CI/CD, skyinfrastruktur, sikkerhets- og driftsverktøy. Harness beskriver et semantisk lag med strukturerte relasjoner, kanoniske identiteter og tilgangsfiltrering. Et praktisk eksempel er å løse ulike navn for samme tjeneste på tvers av et lager, Kubernetes og overvåkingssystemer.

Det identitetsproblemet er betydningsfullt. En sårbarhetsfunn knyttet til en distribuert tjeneste er mer nyttig når den kan spores til den relevante artefakten og kodeversjonen. En testfeil må kobles til endringen som faktisk er under vurdering. Å samle flere logger etablerer ikke automatisk disse relasjonene.

I sin oppkjøpskunngjøring beskriver Harness at koblingen av Code Context Engine og Software Delivery Knowledge Graph er et planlagt neste steg. Den tiltenkte tilbakemeldingssløyfen ville returnere nedstrøms funn til ingeniørarbeidsflyten slik at en agent kan forberede en korreksjon og sende den gjennom validering igjen. Leserne bør skille denne integrasjonsretningen fra en påstand om at alle deler av den kombinerte arbeidsflyten allerede er levert.

Autonomi krever fortsatt en utgivelsesbeslutning

Den foreslåtte sløyfen kan redusere en kjent kilde til ingeniøroverhead: å rekonstruere et problem og bære konteksten mellom verktøy. Hvis testing avdekker en regresjon, er det nyttige resultatet en korreksjon knyttet til den mislykkede sjekken, etterfulgt av bevis på at korreksjonen fungerer. Å åpne en ny pull‑request uten dette beviset vil bare flytte flaskehalsen.

Menneskelig tilsyn forblir en del av arkitekturen. Isolasjon begrenser kjøremiljøet, men det fastslår ikke at en patch er korrekt. Tester, kodegjennomgang, sikkerhetssjekker og eksplisitte godkjenningsgrenser tjener ulike formål. En grønn testpakke kan fortsatt gå glipp av et krav, og en teknisk gyldig endring kan fortsatt være upassende for en bestemt utgivelse.

For kunder som evaluerer den kombinerte plattformen, vil de meningsfulle målene være hvor ofte foreslåtte endringer overlever gjennomgang, hvor mye omarbeid de krever, og hva som skjer med påliteligheten etter utgivelse. Tiden spart på å forberede en patch bør veies opp mot tiden brukt på å verifisere den. Dette er evalueringskriterier, ikke ytelsesresultater demonstrert av oppkjøpskunngjøringen.

Et veddemål på hele veien fra idé til produksjon

Harness sier at Cosmos er tilgjengelig nå, og at kunder kan fortsette å bruke sine foretrukne kodeverktøy. Det gir rom for at organisasjoner kan adoptere programvarefabrikkens arbeidsflyter selektivt, i stedet for å behandle oppkjøpet som et krav om å erstatte hele utviklingsmiljøet deres.

Det strategiske veddemålet er klart. Etter hvert som kodegenerering blir en rutinekapasitet, er det vanskeligere problemet å opprettholde kontekst på tvers av beslutningene som gjør programvare brukbar: implementering, gjennomgang, testing, utrulling og drift. Å bringe Augments kode‑eiendeler inn i Harness gir selskapet komponenter på begge sider av den delingen.

Oppkjøpet vil til slutt bli vurdert etter om disse komponentene danner en pålitelig tilbakemeldingssløyfe. Hvis et produksjonsfunn kan føre til en veldefinert fix, verifisert mot riktig kode og utgitt under teamets retningslinjer, går gevinsten utover raskere koding. Det blir en bedre måte å omforme ingeniørarbeid til programvare kundene kan bruke.