Factory i Droid krok po kroku: od instalacji do automatycznego przeglądu kodu

👁 114 przeczytań

Factory to agenci programistyczni o nazwie Droid, którzy pracują w terminalu, w edytorze i w GitHubie: czytają projekt, proponują zmiany, piszą kod i przeglądają pull requesty. Ten samouczek prowadzi od instalacji do automatycznego przeglądu kodu, według oficjalnej dokumentacji Factory.

Zanim zaczniesz: przygotuj projekt

Droid pracuje na Twoim repozytorium, więc kilka rzeczy warto mieć w porządku przed pierwszym zadaniem. Czysty stan w systemie kontroli wersji, żeby każdą zmianę agenta było widać osobno i łatwo ją cofnąć. Działające testy i polecenia do ich uruchomienia, bo agent, który może sprawdzić swoją pracę, myli się rzadziej. Krótki opis projektu w pliku w repozytorium: jak go uruchomić, gdzie są najważniejsze moduły, jakie są zasady w zespole.

Jeśli projekt ma miejsca, których agent nie powinien ruszać, na przykład konfigurację produkcyjną, zapisz to wprost w wytycznych.

Krok 1. Instalacja

Droid instalujesz jednym poleceniem. Na macOS i Linuksie jest to polecenie pobierające instalator ze strony Factory, na Windowsie polecenie w PowerShellu, a jeśli masz Node.js, możesz zainstalować go przez npm. Do korzystania potrzebne jest konto Factory, a przy pierwszym uruchomieniu logujesz się przez przeglądarkę.

Potem wchodzisz do katalogu projektu i uruchamiasz Droida poleceniem droid.

Krok 2. Pierwsze zadanie

Oficjalny przewodnik pokazuje, jak Droid czyta projekt, proponuje zmiany i czeka na Twoją akceptację, zanim cokolwiek zmieni w plikach. Na start najlepiej sprawdzają się małe zadania: wyjaśnij strukturę projektu, znajdź, gdzie obsługiwane jest logowanie, dodaj walidację do tego formularza.

Krok 3. Tryb specyfikacji przy większych zmianach

Do większych zadań służy tryb specyfikacji. Droid najpierw bada projekt i planuje, a dopiero potem pisze kod. Dokumentacja poleca go przy zmianach architektury, migracjach, pracy wrażliwej na bezpieczeństwo i każdym zadaniu, przy którym chcesz zobaczyć plan przed edycją plików. Włączasz go skrótem Shift + Tab w wierszu poleceń.

Po zaproponowaniu planu możesz zatwierdzać każdą zmianę ręcznie, dać Droidowi większą samodzielność albo dalej dopracowywać plan.

Krok 4. Poziom samodzielności

Niezależnie od trybu ustawiasz, jak samodzielnie Droid może działać. Skrót Ctrl + L przełącza poziomy od wyłączonego po wysoki. Na początek zostań przy niskim, dopóki nie wiesz, jak Droid radzi sobie z Twoim projektem.

Krok 5. Edytor

Droid działa w terminalu dowolnego edytora, a w VS Code i edytorach z tej rodziny może doinstalować rozszerzenie, które przekazuje mu otwarty plik, zaznaczenie i błędy z edytora, a zmiany pokazuje w natywnym widoku porównania. Stan integracji sprawdzisz poleceniem /ide. Dla JetBrains i Zed dokumentacja opisuje osobne połączenia.

Krok 6. Przegląd kodu przed wysłaniem

Polecenie /review sprawdza lokalne zmiany, zanim je wypchniesz. To dobry nawyk przed każdym pull requestem: Droid szuka ewidentnych błędów, zanim zobaczy je ktoś z zespołu.

Krok 7. Automatyczny przegląd w GitHubie

Polecenie /install-code-review ustawia automatyczny przegląd pull requestów w GitHubie albo GitLabie. Droid analizuje zmiany i dodaje komentarze przy konkretnych liniach. Skupia się na błędach, a pomija styl i drobne optymalizacje. Własne zasady przeglądu dla repozytorium dopisujesz w pliku z wytycznymi w katalogu konfiguracji Factory.

Przykład: pierwszy dzień w zespole

Instalujesz Droida, prosisz o wyjaśnienie struktury projektu i o wskazanie trzech miejsc, które najczęściej się zmieniają. Potem w trybie specyfikacji planujesz małą funkcję, zatwierdzasz plan i każdą zmianę ręcznie. Przed wypchnięciem uruchamiasz /review, a na koniec dnia ustawiasz automatyczny przegląd dla całego repozytorium.

Taki pierwszy dzień ma jeszcze jedną zaletę: uczy zespół, jak czytać pracę agenta. Po kilku zadaniach widać, w czym Droid jest mocny, na przykład w powtarzalnych zmianach w wielu plikach, a gdzie potrzebuje dokładniejszych wskazówek, na przykład przy logice biznesowej. Te obserwacje warto zapisać w wytycznych projektu, bo każda kolejna osoba w zespole zacznie wtedy od doświadczeń poprzedników, a nie od zera.

Najczęstsze błędy

• Wysoka samodzielność na start, zanim poznasz agenta.
• Duże zadania bez trybu specyfikacji.
• Traktowanie automatycznego przeglądu jako zastępstwa człowieka.

Jak ocenić pierwszy tydzień

Po tygodniu policz dwie rzeczy. Ile zadań Droid wykonał tak, że zaakceptowałeś zmianę bez poprawek, i ile wymagało Twojej interwencji. Przy dobrze przygotowanym projekcie pierwsza liczba szybko rośnie. Sprawdź też komentarze z automatycznego przeglądu: czy wskazywały prawdziwe błędy, czy głównie szum. Jeśli szum przeważa, dopisz wytyczne przeglądu dla swojego repozytorium, żeby agent wiedział, na co zwracać uwagę, a co pomijać.

Dopiero gdy wyniki są dobre, zwiększaj poziom samodzielności agenta.

Jeśli pracujesz sam, a nie w zespole, te same zasady działają w mniejszej skali: zlecaj agentowi zadania, które potrafisz szybko sprawdzić, i przeglądaj każdą zmianę przed scaleniem, nawet gdy nikt inny jej nie zobaczy.

Roczny dostęp do Factory sprzedaję taniej niż w oficjalnym cenniku w sklepie kinetyka.pl.