Harness przejmuje zasoby Augment Code, aby połączyć agenty programistyczne z dostawą oprogramowania

Tworzenie zmiany w kodzie staje się łatwiejsze. Uzyskanie, aby ta zmiana została przetestowana, zrecenzowana, zabezpieczona i działała niezawodnie dla klientów, pozostaje znacznie większym zadaniem. Harness stawia na to, że kolejny przełom w rozwoju oprogramowania AI nastąpi dzięki połączeniu tych dwóch światów.

8 października Harness ogłosił, że przejął wybrane zasoby Augment Code, w tym Cosmos, Auggie CLI, Code Context Engine oraz powiązaną technologię. Zespół stojący za tymi produktami dołącza do Harness. Cosmos stanie się Harness Cosmos Software Factory Agent, rozszerzając platformę dostawy oprogramowania firmy o prace inżynieryjne, które odbywają się przed tym, jak zmiana trafi do potoku wdrożeniowego.

To rozróżnienie ma znaczenie: jest to przejęcie wybranych zasobów i powiązanego z nimi zespołu, a nie zakup całej firmy Augment Code. Istotą jest technologia, którą łączy się razem: agenty, które rozumieją i modyfikują bazę kodu, oraz systemy, które rozumieją, jak ten kod jest testowany, wydawany i eksploatowany.

Co Harness wprowadza do swojej platformy

Ogłoszenie ustawia Cosmos jako punkt wyjścia dla coraz bardziej autonomicznego cyklu życia rozwoju oprogramowania, czyli SDLC. Wymaganie, przydzielony bilet lub zgłoszony błąd może zainicjować skoordynowany przepływ pracy, w którym agenci planują zmianę, piszą kod i testy oraz otwierają pull request. Inżynierowie pozostają zaangażowani w kluczowych momentach decyzyjnych, w tym zatwierdzaniu projektu i podejmowaniu ostatecznej decyzji o scaleniu.

To wykracza poza generowanie początkowej poprawki. Agenci Cosmos mogą kontynuować pracę nad tym samym pull requestem, gdy recenzenci zostawiają komentarze lub testy nie przechodzą. Wstępnie zbudowani Eksperci, w tym Project Builder, PR Author, Deep Reviewer i PR Fixer, zapewniają zespołom przepływy pracy, które mogą dostosować do własnych repozytoriów i standardów.

Każdy agent działa w odizolowanej maszynie wirtualnej. Routing modeli, integracje z GitHub, Jira i Slack, współdzielona pamięć, wersjonowanie oraz kontrola budżetu zapewniają otaczającą infrastrukturę do realizacji tej pracy w całej organizacji inżynieryjnej.

Ta kombinacja jest istotą koncepcji fabryki oprogramowania: powtarzalnym procesem, który prowadzi pracę do wyniku podlegającego przeglądowi. Ważną jednostką jest zakończony przepływ pracy inżynieryjnej, z dowodami i punktami kontrolnymi, a nie liczba linii generowanych przez agenta.

Jak Cosmos działa poza oknem czatu

Strona produktu Cosmos firmy Augment dodaje przydatne szczegóły na temat tego modelu operacyjnego. Pull requesty, alerty, harmonogramy i webhooki mogą aktywować specjalistycznych Ekspertów. Zespoły definiują środowiska, integracje i ludzkie punkty kontrolne wokół tych wyzwalaczy, umożliwiając rozpoczęcie pracy bez konieczności ręcznego wydawania nowego polecenia dla każdego zdarzenia.

Cosmos umożliwia również definiowanie Ekspertów i przepływów pracy sterowanych zdarzeniami jako wersjonowanego YAML, stosowanie zmian za pomocą Auggie CLI oraz zarządzanie historią konfiguracji w Git. Dzięki temu sam przepływ pracy agenta staje się czymś, co zespół może przeglądać i modyfikować przy użyciu znanych praktyk inżynieryjnych. Strona produktu opisuje wspólną wiedzę organizacyjną oraz limity wydatków obok tych kontroli.

Dla zespołu deweloperskiego zmienia to problem koordynacji. Agent reagujący na przydzielony bilet potrzebuje jasno określonego celu, dostępu do odpowiednich narzędzi oraz miejsca do zgłoszenia wyniku. Agent wywołany niepowodzeniem testu potrzebuje dowodów na błąd oraz uprawnienia do zmiany odpowiednich plików. Wielokrotnego użytku przepływy pracy mogą zakodować te wymagania, choć ich skuteczność wciąż zależy od tego, jak starannie organizacja je skonfiguruje.

Code Context Engine jest kluczowy dla transakcji

Agenci pracujący nad oprogramowaniem korporacyjnym napotykają problem, którego płynna odpowiedź kodująca nie może rozwiązać samodzielnie: znalezienie właściwego kontekstu. Repozytorium może zawierać wiele usług, przestarzałe implementacje, lokalne konwencje i zależności, które trudno wywnioskować z jednego pliku.

Według wyjaśnienia Code Context Engine firmy Augment, system semantycznie indeksuje kod i pobiera informacje istotne dla zadania. Opiera się na zależnościach pomiędzy repozytoriami i usługami, historii commitów, wzorcach kodu oraz materiałach pomocniczych, takich jak dokumentacja i bilety. Zamiast umieszczać całe repozytorium w zapytaniu, system ocenia i selekcjonuje odpowiedni kontekst.

Praktyczną wartość łatwiej zrozumieć na przykładzie. Żądanie zmiany punktu końcowego płatności może również wpływać na walidację, usługę zależną, obsługę webhooka oraz testy. Pobranie tych powiązań może dać agentowi programistycznemu lepszy punkt wyjścia niż sam plik punktu końcowego. To ilustracja problemu, który technologia rozwiązuje, a nie gwarancja, że każda dotknięta zależność zostanie znaleziona.

Harness przejmuje tę zdolność kontekstową wraz z narzędziami, które ją wykorzystują. Szersza szansa polega na połączeniu wiedzy o tym, co kod robi, z dowodami na to, co dzieje się po jego opuszczeniu repozytorium.

Łączenie repozytorium z działającym systemem

Harness już działa po stronie dostawy w cyklu życia. Jego agenci obejmują dostarczanie oprogramowania, testowanie bezpieczeństwa, ochronę w czasie wykonywania oraz zarządzanie kosztami. Przejęcie tworzy ścieżkę, dzięki której prace inżynieryjne przygotowane przez Cosmos mogą przejść do tych dalszych przepływów pracy.

Graf wiedzy o dostawie oprogramowania firmy Software Delivery Knowledge Graph został zaprojektowany, aby łączyć informacje z Git, CI/CD, infrastrukturą chmurową, narzędziami bezpieczeństwa i operacyjnymi. Harness opisuje warstwę semantyczną ze strukturalnymi relacjami, kanonicznymi tożsamościami i filtrowaniem dostępu. Praktycznym przykładem jest rozwiązywanie różnych nazw tej samej usługi w repozytorium, Kubernetes i systemach monitorowania.

Ten problem tożsamości ma istotne konsekwencje. Znalezienie podatności powiązane z wdrożoną usługą jest bardziej użyteczne, gdy można je powiązać z odpowiednim artefaktem i wersją kodu. Niepowodzenie testu musi być połączone ze zmianą faktycznie poddawaną przeglądowi. Zbieranie większej liczby logów nie ustanawia automatycznie tych powiązań.

W swoim ogłoszeniu o przejęciu Harness opisuje połączenie Code Context Engine i Software Delivery Knowledge Graph jako planowany kolejny krok. Zamierzona pętla sprzężenia zwrotnego zwróci wyniki pochodzące z dalszych etapów do przepływu pracy inżynierów, aby agent mógł przygotować poprawkę i ponownie przesłać ją do walidacji. Czytelnicy powinni odróżnić ten kierunek integracji od twierdzenia, że każda część połączonego przepływu pracy jest już dostarczona.

Autonomia wciąż wymaga decyzji o wydaniu

Proponowana pętla może zmniejszyć znane źródło obciążenia inżynieryjnego: odtwarzanie problemu i przenoszenie jego kontekstu między narzędziami. Jeśli testy wykryją regresję, użytecznym wynikiem jest poprawka powiązana z nieudaną kontrolą, po której następują dowody, że poprawka działa. Otwarcie kolejnego pull requesta bez tych dowodów jedynie przeniosłoby wąskie gardło.

Nadzór ludzki pozostaje częścią architektury. Izolacja ogranicza środowisko wykonawcze, ale nie gwarantuje, że poprawka jest prawidłowa. Testy, przegląd kodu, kontrole bezpieczeństwa i wyraźne granice zatwierdzeń służą różnym celom. Zielony zestaw testów może nadal pominąć wymóg, a technicznie poprawna zmiana może być nieodpowiednia dla konkretnego wydania.

Dla klientów oceniających połączoną platformę istotnymi miarami będą częstotliwość, z jaką proponowane zmiany przechodzą przegląd, ilość wymaganej przeróbki oraz wpływ na niezawodność po wydaniu. Zaoszczędzony czas na przygotowanie poprawki powinien być zestawiony z czasem poświęconym na jej weryfikację. Są to kryteria oceny, a nie wyniki wydajności wykazane w ogłoszeniu o przejęciu.

Zakład na pełną ścieżkę od pomysłu do produkcji

Harness informuje, że Cosmos jest już dostępny i że klienci mogą nadal korzystać ze swoich preferowanych narzędzi programistycznych. Daje to organizacjom możliwość selektywnego przyjmowania przepływów pracy fabryki oprogramowania, zamiast traktowania przejęcia jako wymogu zastąpienia całego środowiska programistycznego.

Strategiczny zakład jest jasny. W miarę jak generowanie kodu staje się rutynową funkcją, trudniejszym problemem jest utrzymanie kontekstu w decyzjach, które sprawiają, że oprogramowanie jest użyteczne: implementacja, przegląd, testowanie, wdrażanie i eksploatacja. Włączenie zasobów kodowania Augment do Harness dostarcza firmie komponenty po obu stronach tej przepaści.

Ostatecznie ocena przejęcia będzie zależała od tego, czy te komponenty utworzą niezawodną pętlę sprzężenia zwrotnego. Jeśli wykrycie w produkcji może doprowadzić do precyzyjnej poprawki, zweryfikowanej względem właściwego kodu i wydanej zgodnie z politykami zespołu, korzyść wykracza poza szybsze kodowanie. Staje się to lepszym sposobem przekształcania pracy inżynieryjnej w oprogramowanie, z którego mogą korzystać klienci.