Harness erhverver Augment Code-aktiver for at forbinde kodningsagenter med softwarelevering

Det bliver lettere at skrive en kodeændring. At få den ændring testet, gennemgået, sikret og kørt pålideligt for kunderne forbliver en meget større opgave. Harness satser på, at det næste gennembrud inden for AI-softwareudvikling vil komme fra at forbinde disse to verdener.

Den 8. oktober annoncerede Harness, at de har erhvervet udvalgte Augment Code-aktiver, herunder Cosmos, Auggie CLI, Code Context Engine og relateret teknologi. Teamet bag disse produkter slutter sig til Harness. Cosmos vil blive Harness Cosmos Software Factory Agent, som udvider virksomhedens softwareleveringsplatform til det ingeniørarbejde, der foregår, før en ændring når en implementeringspipeline.

Forskellen er væsentlig: dette er en erhvervelse af udvalgte aktiver og deres tilknyttede team, snarere end et erklæret køb af hele Augment Code-virksomheden. Betydningen ligger i den teknologi, der bringes sammen: agenter, der forstår og ændrer en kodebase, samt systemer, der forstår, hvordan koden testes, frigives og drives.

Hvad Harness bringer ind i sin platform

Meddelelserne placerer Cosmos som udgangspunkt for en stadigt mere autonom softwareudviklingslivscyklus, eller SDLC. Et krav, en tildelt ticket eller en rapporteret fejl kan igangsætte en koordineret arbejdsproces, hvor agenter planlægger en ændring, skriver kode og tests og åbner en pull‑request. Ingeniører forbliver involveret på beslutningspunkter, herunder godkendelse af et design og den endelige merge‑beslutning.

Dette går ud over at generere et indledende patch. Cosmos‑agenter kan fortsætte arbejdet på den samme pull‑request, når anmeldere efterlader kommentarer eller kontroller fejler. Forudbyggede eksperter, herunder Project Builder, PR Author, Deep Reviewer og PR Fixer, giver teams arbejdsprocesser, de kan tilpasse til deres egne repositories og standarder.

Hver agent kører i en isoleret virtuel maskine. Model‑routing, integrationer med GitHub, Jira og Slack, delt hukommelse, versionering og budgetkontroller leverer den omgivende infrastruktur til at udføre dette arbejde på tværs af en ingeniøroperation.

Den kombination udgør idéen om en softwarefabrik: en gentagelig proces, der fører arbejdet mod et gennemgåeligt resultat. Den vigtige enhed er en fuldført ingeniør‑arbejdsproces med beviser og kontrolpunkter, snarere end antallet af linjer, en agent producerer.

Hvordan Cosmos fungerer ud over chat‑vinduet

Augments Cosmos produktside tilføjer nyttige detaljer om den driftsmodel. Pull‑requests, alarmer, tidsplaner og webhooks kan aktivere specialiserede eksperter. Teams definerer miljøer, integrationer og menneskelige kontrolpunkter omkring disse udløsere, så arbejdet kan påbegyndes uden at nogen manuelt skal udstede en ny prompt for hver hændelse.

Cosmos understøtter også definition af eksperter og hændelsesdrevne arbejdsprocesser som versioneret YAML, anvendelse af ændringer via Auggie CLI og håndtering af konfigurationshistorik i Git. Dette gør agent‑arbejdsprocessen selv til noget, et team kan inspicere og ændre gennem velkendte ingeniørpraksisser. Produktsiden beskriver delt organisatorisk viden og udgiftsgrænser sammen med disse kontroller.

For et udviklingsteam ændrer dette koordineringsproblemet. En agent, der svarer på en tildelt ticket, har brug for et klart afgrænset mål, adgang til de rette værktøjer og et sted at rapportere sit resultat. En agent, der udløses af en mislykket kontrol, har brug for fejlevidens og tilladelse til at ændre de relevante filer. Genanvendelige arbejdsprocesser kan indkode disse krav, selvom deres effektivitet stadig afhænger af, hvor omhyggeligt organisationen konfigurerer dem.

Code Context Engine er central for aftalen

Agenter, der arbejder med enterprise‑software, står over for et problem, som et flydende kode‑svar ikke kan løse alene: at finde den rette kontekst. Et repository kan indeholde flere tjenester, forældede implementeringer, lokale konventioner og afhængigheder, som er svære at udlede fra én fil.

Ifølge Augments forklaring af sin Code Context Engine indekserer systemet koden semantisk og henter information, der er relevant for opgaven. Det trækker på relationer på tværs af repositories og tjenester, commit‑historik, kodebasismønstre og understøttende materiale såsom dokumentation og tickets. I stedet for at placere et helt repository i en prompt, rangerer og kuraterer det relevant kontekst.

Den praktiske værdi er lettere at forstå gennem et eksempel. En anmodning om at ændre et betalings‑endpoint kan også påvirke validering, en downstream‑tjeneste, en webhook‑handler og tests. At hente disse forbindelser kan give en kodningsagent et bedre udgangspunkt end kun endpoint‑filen. Det er en illustration af det problem, teknologien adresserer, snarere end en garanti for, at hver berørt afhængighed vil blive fundet.

Harness erhverver denne kontekst‑kapacitet sammen med de værktøjer, der sætter den i arbejde. Den bredere mulighed er at forbinde viden om, hvad koden gør, med beviser for, hvad der sker, efter den forlader repository’et.

Forbindelse af repository’et til det kørende system

Harness opererer allerede på leveringssiden af livscyklussen. Dens agenter dækker softwarelevering, sikkerhedstest, runtime-beskyttelse og omkostningsstyring. Opkøbet skaber en vej for ingeniørarbejde, der er forberedt af Cosmos, til at flytte ind i de efterfølgende arbejdsgange.

Virksomhedens Software Delivery Knowledge Graph er designet til at forbinde information fra Git, CI/CD, cloud-infrastruktur, sikkerhed og driftsværktøjer. Harness beskriver et semantisk lag med strukturerede relationer, kanoniske identiteter og adgangsfiltrering. Et praktisk eksempel er at løse forskellige navne for den samme tjeneste på tværs af et repository, Kubernetes og overvågningssystemer.

Det identitetsproblem er betydningsfuldt. En sårbarhedsfind, der er knyttet til en implementeret tjeneste, er mere nyttig, når den kan spores til den relevante artefakt og kodeversion. En testfejl skal forbindes til den ændring, der faktisk er under gennemgang. Indsamling af flere logfiler etablerer ikke automatisk disse relationer.

I sin opkøbsmeddelelse beskriver Harness, at forbinde Code Context Engine og Software Delivery Knowledge Graph som et planlagt næste skridt. Den tilsigtede feedback-loop ville returnere nedstrøms fund til ingeniørarbejdsprocessen, så en agent kan forberede en korrektion og sende den gennem validering igen. Læserne bør skelne denne integrationsretning fra en påstand om, at hver del af den samlede arbejdsproces allerede er leveret.

Autonomi kræver stadig en frigivelsesbeslutning

Den foreslåede loop kan reducere en velkendt kilde til ingeniøroverhead: at rekonstruere et problem og overføre dets kontekst mellem værktøjer. Hvis test afslører en regression, er den nyttige output en korrektion knyttet til den fejlede kontrol, efterfulgt af bevis for, at korrektionen fungerer. At åbne en ny pull request uden dette bevis vil blot flytte flaskehalsen.

Menneskelig kontrol forbliver en del af arkitekturen. Isolation begrænser udførelsesmiljøet, men det fastslår ikke, at en patch er korrekt. Tests, kodegennemgang, sikkerhedstjek og eksplicitte godkendelsesgrænser tjener forskellige formål. En grøn testsuite kan stadig overse et krav, og en teknisk gyldig ændring kan stadig være upassende for en bestemt udgivelse.

For kunder, der evaluerer den kombinerede platform, vil de meningsfulde målinger være, hvor ofte foreslåede ændringer overlever gennemgangen, hvor meget genarbejde de kræver, og hvad der sker med pålideligheden efter udgivelsen. Tiden sparet på at forberede en patch skal afvejes mod den tid, der bruges på at verificere den. Det er evalueringskriterier, ikke præstationsresultater demonstreret i opkøbsmeddelelsen.

Et væddemål på den fulde vej fra idé til produktion

Harness siger, at Cosmos er tilgængelig nu, og at kunder kan fortsætte med at bruge deres foretrukne kodningsværktøjer. Det giver organisationer mulighed for selektivt at adoptere softwarefabrikens arbejdsgange i stedet for at betragte opkøbet som et krav om at erstatte deres hele udviklingsmiljø.

Det strategiske væddemål er klart. Efterhånden som kodegenerering bliver en rutinefunktion, er det sværere problem at opretholde kontekst på tværs af de beslutninger, der gør software brugbar: implementering, gennemgang, test, implementering og drift. At bringe Augments kode‑aktiver ind i Harness giver virksomheden komponenter på begge sider af denne kløft.

Opkøbet vil i sidste ende blive vurderet ud fra, om disse komponenter danner en pålidelig feedback-loop. Hvis et produktionsfund kan føre til en veldefineret rettelse, verificeret mod den korrekte kode og frigivet i overensstemmelse med teamets politikker, går gevinsten ud over hurtigere kodning. Det bliver en bedre måde at omsætte ingeniørarbejde til software, som kunderne kan bruge.