delegujemy.ai

03 · Rozwinięcie

Delegujemy.
Nie zgadujemy.Jak uczymy delegowania pracy agentom AI

Nazwa firmy to jednocześnie cała metoda. Nie szukamy magicznego promptu. Uczymy zespoły oddawać pracę agentom tak, jak dobry lider oddaje ją ludziom: z jasnym zadaniem, potrzebną wiedzą i umówionym sposobem odbioru.

Delegowanie to umiejętność

Każdy, kto kiedyś wdrażał nową osobę do zespołu, wie, że pierwsze tygodnie zależą od tego, jak dobrze przygotowano jej start. Jasne zadania, dostęp do wiedzy, ktoś, kto odpowie na pytania i odebrze pracę. Z agentem jest tak samo, tylko cykl trwa godziny zamiast tygodni.

Dlatego traktujemy to jak umiejętność, którą się ćwiczy. Da się ją rozłożyć na kroki, da się ją mierzyć i da się w niej robić postępy. Zespół po kilku tygodniach oddaje zadania inaczej niż na początku, i widać to w liczbach.

Czego nie robimy

  • Nie zbieramy „najlepszych promptów”
  • Nie obiecujemy, że jedno zdanie zastąpi zespół
  • Nie wymieniamy narzędzi co miesiąc
  • Nie uczymy sztuczek na jedną wersję modelu

Na czym pracujemy

  • Dobrze opisane zadanie
  • Kontekst w repozytorium
  • Testy jako kryterium gotowości
  • Odbiór przez człowieka

Modele i narzędzia się zmieniają. Te cztery rzeczy zostają.

Trzy poziomy delegowania

  1. Tu się zaczyna

    Pojedyncze zadanie

    Jedna osoba oddaje agentowi jedno zadanie i odbiera pull request. Tu uczy się opisywać zadania i czytać kod, którego się nie napisało.

  2. Praca zespołu

    Funkcja od początku do końca

    Kilka zadań w kolejności, wspólny kontekst, testy jako kryterium. Tu zespół uczy się dzielić pracę i utrzymywać plik z zasadami.

  3. Wymaga granic

    Proces w tle

    Agent uruchamiany automatycznie: po zgłoszeniu błędu, po nowym zadaniu, po nocnym raporcie. Człowiek już tylko odbiera. Tu potrzebne są twarde granice i monitorowanie.

Jak się tego uczymy

Krótka pętla, powtarzana wiele razy: opisz zadanie, oddaj, odbierz, zapisz liczbę poprawek, popraw kontekst albo opis. Następne zadanie. Po dziesięciu przebiegach widać, gdzie leży problem: w opisach, w kontekście czy w testach.

Pracujemy na Waszym kodzie, nie na przykładach z internetu. Pierwsze zadania wybieramy razem, tak żeby były małe, prawdziwe i miały testy. Pierwszy tydzień to zwykle więcej poprawiania kontekstu niż pisania kodu, i to jest w porządku.

Przejście na kolejny poziom ma sens dopiero wtedy, gdy liczby z poprzedniego są stabilne.

Typowe błędy na starcie

  • Za duże zadanie. „Zrób moduł raportów” to nie zadanie, to projekt. Agent zgaduje połowę wymagań, a potem ktoś to wszystko czyta.
  • Brak testów. Kod wygląda dobrze, przechodzi przegląd, psuje coś w piątek wieczorem.
  • Za dużo kontekstu. Trzydziestostronicowy plik z zasadami, w którym agent nie znajduje tego jednego zdania, które było ważne.
  • Odbiór bez czytania. Testy przeszły, więc scalamy. Po miesiącu nikt nie wie, jak działa własny system.
  • Poprawianie ręcznie. Recenzent dopisuje brakujące trzy linie, zamiast wrócić z uwagą. Kontekst się nie uczy, błąd wraca w następnym zadaniu.

Skąd wiemy, że to działa

Nie z odczuć. Z czterech liczb, które zespół zbiera od pierwszego zadania: poprawek po pierwszym podejściu, czasu od opisu do wdrożenia, kosztu na funkcję i błędów po scaleniu. Jak je liczymy i co z nimi robimy, opisujemy na stronie Mierzymy.