Autor: Kwame Boateng

Kodowanie wspomagane przez AI często opisuje się jako szybszą wersję programowania w parach. To porównanie jest już zbyt ograniczone. Gdy agent może przejrzeć repozytorium, zmienić kilka plików, uruchomić narzędzia, wygenerować podgląd i otworzyć pull request, główny problem współpracy nie brzmi już po prostu: „Czy potrafi pisać kod?”. Brzmi: „Czy ludzie mogą zobaczyć, przejrzeć, zatwierdzić, a później odtworzyć to, co się wydarzyło?”

Właśnie dlatego najważniejszą zmianą projektową w zespołach programistycznych wspomaganych przez agentów może być przejście od prywatnych promptów do widocznych obszarów roboczych. Slack Code jest na przykład opisywany jako rozwiązanie łączące kanały projektowe z agentami programistycznymi, audytowanie różnic w kodzie, podglądy HTML na żywo, przepływy informacji zwrotnych i zatwierdzania, automatyczną archiwizację oraz dzienniki audytowe. Aplikacja GitHub Copilot dodała również panel „My work” do organizowania issue i pull requestów w różnych projektach. Funkcje te wskazują na praktyczną zasadę: praca agenta powinna przypominać mniej nieprzejrzystą odpowiedź, a bardziej zestaw zmian przechodzący przez kontrolowany proces produkcyjny.

Czat nie jest rejestrem pracy

Rozmowa z agentem może być przydatna podczas badania pomysłu, ale jest słabym systemem rejestrowania informacji. Ważne szczegóły mogą zginąć w długim wątku: które pliki zmieniono, jakie polecenia uruchomiono, jakie założenia przyjął agent, co odrzucił recenzent oraz czy końcowy rezultat różni się od pierwszej propozycji.

Trwały obszar roboczy sprawia, że te szczegóły można sprawdzić. Powinien łączyć żądanie z konkretnym repozytorium lub projektem, zachowywać plan agenta, pokazywać działania narzędzi i zmiany w plikach, zawierać odnośniki do testów i podglądów oraz rejestrować, kto zatwierdził rezultat. Dokładny interfejs może się różnić — może to być system śledzenia issue, pull request, kanał współpracy lub konsola agenta — ale informacje powinny przetrwać zakończenie sesji.

Ma to znaczenie ze względów związanych ze zwykłą inżynierią, a nie tylko zgodnością z przepisami. Jeśli dwa tygodnie później pojawi się błąd, zespół będzie potrzebował czegoś więcej niż końcowej różnicy. Może potrzebować znajomości pierwotnego wymagania, wygenerowanego planu, dowodów z testów, komentarzy recenzenta oraz informacji, czy człowiek wyraźnie zaakceptował ryzykowny kompromis. Trwały zapis skraca takie dochodzenie.

Pięć warstw widocznej pracy

Zespoły wdrażające agentów programistycznych mogą traktować każdą zmianę jak niewielką, możliwą do skontrolowania sprawę. Szczególnie przydatnych jest pięć warstw:

  1. Intencja: issue, kryteria akceptacji, ograniczenia i żądany zakres.
  2. Plan: proponowane przez agenta podejście przed edycją plików. W przypadku nietrywialnego zadania jest to punkt kontrolny wymagający zatwierdzenia, a nie ozdobnik.
  3. Różnica: dokładne dodatki, usunięcia, zmiany zależności, modyfikacje konfiguracji i wygenerowane zasoby.
  4. Dowody: wyniki testów, dane wyjściowe lintera, kontrole bezpieczeństwa, zrzuty ekranu oraz — w stosownych przypadkach — podgląd na żywo lub możliwy do wdrożenia.
  5. Rejestr decyzji: komentarze recenzentów, żądane zmiany, zatwierdzenie, odrzucenie, wycofanie lub dalsze prace.

Nie chodzi o to, by każdą zmianę przeprowadzać przez ciężką komisję. Literówka i zmiana przepływu płatności nie powinny podlegać identycznym kontrolom. Chodzi o to, by poziom kontroli był proporcjonalny do potencjalnego wpływu.

Zatwierdzenia powinny być powiązane z działaniami

„Człowiek w pętli” jest zbyt nieprecyzyjnym określeniem, by stanowić użyteczną kontrolę. Ktoś może zatwierdzić plan, nie widząc wynikowej różnicy, albo zatwierdzić zmianę w kodzie, nie zauważając, że agent zmodyfikował również plik wdrożeniowy. Lepsze przepływy jasno określają, na co pozwala zatwierdzenie.

Na przykład zespół może zezwolić agentowi na automatyczne odczytywanie repozytorium i uruchamianie testów lokalnych, wymagać zatwierdzenia przed zapisem poza wyznaczoną gałęzią oraz wymagać osobnego zatwierdzenia przed scaleniem lub wdrożeniem. Agent może zaproponować migrację bazy danych, ale mieć zakaz jej wykonywania na produkcji. Proponowane przez ZEA podejście do klasyfikowania zadań, które agenci mogą wykonywać, a które mogą jedynie rekomendować, odzwierciedla ten szerszy wzorzec: autonomię należy przypisywać do zadań, a nie zakładać jej globalnie.

Zatwierdzenia muszą mieć również określony zakres i termin wygaśnięcia. Zatwierdzenie „zaktualizuj treść strony docelowej” nie powinno po cichu autoryzować dodania nowego pakietu analitycznego. Plan zatwierdzony wczoraj nie powinien automatycznie obejmować istotnie zmienionej różnicy dzisiaj. Interfejs powinien uwidaczniać te granice.

Podglądy zmieniają przegląd w inspekcję

Przegląd kodu jest często łatwiejszy, gdy ludzie mogą obejrzeć rezultat, zamiast wnioskować o nim na podstawie plików źródłowych. Podgląd HTML na żywo może ujawnić nieprawidłowe odstępy, brakujące stany, niedostępne elementy sterujące lub niezamierzoną zmianę nawigacji, którą recenzent mógłby przeoczyć w tekstowej różnicy.

Podglądy nie są dowodem poprawności. Powinny znajdować się obok testów i przeglądu kodu źródłowego, a nie je zastępować. Tworzą jednak wspólny obiekt do dyskusji: recenzent może wskazać konkretny ekran, stan lub interakcję i pozostawić opinię przypisaną do proponowanej zmiany.

Jest to szczególnie cenne, gdy w przeglądzie uczestniczą osoby niebędące specjalistami. Menedżer produktu może nie być w stanie ocenić zmiany frameworka, ale może być właściwą osobą do potwierdzenia, że przepływ odpowiada wymaganiu. Projektant może zweryfikować regresję wizualną. Specjalista ds. bezpieczeństwa może skupić się na uprawnieniach i przetwarzaniu danych. Obszar roboczy wspomagany przez agenta może kierować każde pytanie do osoby najlepiej przygotowanej, by na nie odpowiedzieć.

Różnice potrzebują kontekstu, nie tylko kolorów

Znana różnica w kolorach czerwonym i zielonym nadal jest niezbędna, ale zmiany wygenerowane przez agenta mogą być na tyle szerokie, że przytłoczą recenzenta. Zespoły powinny prosić agentów o utrzymywanie wąskiego zakresu commitów lub grup zmian, wyjaśnianie, dlaczego zmieniono każdy istotny plik, oraz osobne oznaczanie plików wygenerowanych lub pochodzących od dostawców.

Przydatne pytania pomocne w przeglądzie obejmują:

  • Jakie zmiany są widoczne dla użytkownika?
  • Które pliki zmieniono wyłącznie w celu wsparcia implementacji?
  • Jakie założenia dotyczące dotychczasowego działania przyjął agent?
  • Które testy dodano, zmodyfikowano lub pominięto?
  • Czy ta zmiana może wpłynąć na uprawnienia, przechowywanie danych, rozliczenia lub zewnętrzne interfejsy API?

Pytania te zmieniają przegląd z niejasnej prośby „rzuć na to okiem” w powtarzalne badanie. Pomagają też ujawnić częsty tryb awarii: pozornie wiarygodną funkcję, której towarzyszy niepełna aktualizacja testów lub przypadkowa zmiana konfiguracji.

Archiwizuj istotne uzasadnienie

Zachowywanie każdego tokenu każdej rozmowy z modelem nie jest automatycznie użyteczne. Długie historie mogą być kosztowne w przechowywaniu i trudne do przeszukiwania, a badania nad kompakcją kontekstu ostrzegają, że podsumowania mogą pomijać istotne informacje. Praktyczny ślad audytowy powinien zatem zachowywać artefakty istotne dla podejmowanych decyzji, zamiast bez rozróżnienia zapisywać wszystko.

Co najmniej należy zachować zgłoszenie, zatwierdzony plan, końcowy diff, wyniki działania narzędzi i testów, odwołanie do podglądu lub wdrożenia, decyzje recenzentów oraz wszelkie przyznane wyjątki. Jeśli agent korzystał ze źródeł zewnętrznych lub pobierał dokumenty wewnętrzne, należy zapisać odpowiednie odwołania do źródeł oraz moment, w którym wpłynęły one na zmianę. W przypadku prac o wysokim ryzyku uzasadnione może być zachowanie pełnego dziennika interakcji i wykonania.

Tam, gdzie wymaga tego waga sprawy, spraw, by zapisy umożliwiały wykrycie manipulacji, i zdefiniuj zasady przechowywania, zanim nadejdzie kryzys. Ślad audytowy, który znika po zarchiwizowaniu kanału — lub którego nie można odróżnić od zmienionego wyniku względem oryginału — nie będzie pomocny w poważnym dochodzeniu.

Co to zmienia w karierach związanych z oprogramowaniem

Nową umiejętnością nie jest wyłącznie pisanie lepszych promptów. Chodzi o projektowanie pracy w taki sposób, aby inna osoba mogła ją skontrolować i jej zaufać. Deweloperzy będą musieli swobodnie określać kryteria akceptacji, rozkładać zadania na części, przeglądać diffy na dużą skalę, tworzyć wartościowe testy oraz decydować, w którym momencie agent musi się zatrzymać i zapytać.

Specjaliści ds. produktu i projektowania będą odgrywać większą rolę w przeglądaniu podglądów i doprecyzowywaniu intencji. Inżynierowie QA mogą pomóc definiować bramki akceptacji i przypadki awarii. Menedżerowie ds. inżynierii będą musieli mierzyć przepustowość, nie nagradzając przy tym podejmowania niewidocznego ryzyka. Pisarze techniczni i specjaliści ds. operacji mogą przyczynić się do utrwalania decyzji, wyjątków i runbooków.

Przydatne ćwiczenie polega na wzięciu rutynowej funkcji i zmapowaniu łańcucha dowodowego: zgłoszenie, plan, gałąź, diff, testy, podgląd, akceptacja, wydanie i wycofanie. Następnie należy zapytać, w którym miejscu przyszły członek zespołu musiałby zgadywać. Każde takie zgadywanie jest kandydatem do stworzenia lepszego obszaru roboczego, wyraźniejszego uprawnienia lub trwalszego zapisu.

Prosta zasada działania

Pozwól agentom działać szybko w widocznym i odwracalnym obszarze. Zapewnij im określone środowisko pracy, ogranicz wrażliwe działania, wymagaj akceptacji na istotnych granicach, dołączaj dowody do zmiany i zachowuj ostateczną decyzję. Celem nie jest spowolnienie automatyzacji do momentu, w którym zacznie przypominać ręczne programowanie. Chodzi o to, by szybkość była zgodna z odpowiedzialnością.

W tworzeniu oprogramowania wspomaganym przez agentów najlepszym współpracownikiem nie jest system, który w izolacji generuje najwięcej kodu. Jest nim system, którego pracę można zrozumieć, zakwestionować, zatwierdzić, cofnąć i na jej podstawie wyciągać wnioski.