O czym jest ten film
- Druga lekcja cyklu o małych fabrykach oprogramowania (Tiny Software Factories) — dokładamy 14 nowych funkcji do fundamentów z lekcji pierwszej.
- Główna teza: największą dźwignią inżyniera nie są modele i narzędzia, lecz zmiana samego sposobu pracy — z „w pętli” na „przy pętli”, a docelowo poza pętlą.
- Koncepcja „płynnego oprogramowania” (liquid software): soft, który od pierwszego dnia jest projektowany tak, by zmieniać kształt wraz z poznawaniem problemu.
- Trzyetapowy proces przejścia od pustej fabryki do działającej: inicjalizacja, konfiguracja, specjalizacja.
- Demo na żywo: pusty szablon staje się fabryką analityki danych dla przykładowej aplikacji generującej obrazy z promptów.
- Nowe funkcje w akcji: lekki model streszcza wywołania narzędzi agenta, żeby pracę dało się obserwować jednym rzutem oka.
- Delegacja do wyspecjalizowanych podagentów — każdy z własnym modelem, promptem i twardymi budżetami czasu oraz pieniędzy.
- Zasada paritetu agentowego: wszystko, co można kliknąć w interfejsie, agent potrafi zrobić poleceniem.
- Pomiar jako fundament: każdy przebieg podagenta (prompt, wywołania, koszty, czas) jest rejestrowany i dostępny do wglądu.
- Teza końcowa: jeden superagent do wszystkiego to ślepa uliczka — przewagę daje specjalizacja; w lekcji 3 pojawią się małe zespoły agentów.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Optymalizuj sposób pracy, nie pojedyncze narzędzia
Na czym polega: Modele, narzędzia i platformy agentowe to prymitywy, które szybko się starzeją. Realna dźwignia to metaoptymalizacja: przejście od pracy „w pętli” (ciągła wymiana promptów) przez pracę „przy pętli” (agent działa całą dobę, człowieka woła tylko w punktach decyzyjnych) aż po pełną automatyzację.
Jak stosować: Przeanalizuj swój dzień i wypisz miejsca, w których czekasz na odpowiedź agenta, żeby od razu odpisać promptem. Każde takie miejsce to kandydat do przekształcenia w regułę decyzyjną, którą system obsłuży sam.
Na co uważać: „Przy pętli” to nie „bez nadzoru”. Wymaga wcześniejszego zdefiniowania, jakie decyzje agent musi konsultować — inaczej wrócisz do trybu gaśnięcia pożarów.
2.Projektuj oprogramowanie tak, żeby miało być zmieniane
Na czym polega: „Płynne oprogramowanie” to u autora system, który od dnia pierwszego zakłada customizację przez właściciela i zmienia kształt w miarę poznawania problemu — zamiast zamykać się w sztywnej formie.
Jak stosować: Traktuj własne narzędzia jako szablony do przebudowy, nie jako gotowe produkty. Zachowuj czystą, nienaruszoną kopię szablonu (u autora: TSF2) i wdrażaj ją jako kopię do każdego nowego zastosowania.
Na co uważać: Elastyczność bez dobrych ustawień domyślnych oznacza kosztowną konfigurację przy każdym wdrożeniu. Szablon musi działać sensownie od razu po skopiowaniu.
3.Trzy kroki do działającej fabryki: init, configure, specialize
Na czym polega: Proces jest zawsze ten sam: przenieś pusty szablon do repozytorium docelowego, przepuść przez agenta szczegółowy plan, nadaj systemowi konkretną rolę. Autor pokazuje go na przykładzie fabryki analityki produktu.
Jak stosować: Największym wkładem człowieka jest plan. Autor pisze go jako prompt na 150 linii, którego sedno brzmi: „zamień tę zainicjowaną fabrykę w agenta analityki produktu”. Im konkretniej opiszesz cel i ograniczenia, tym lepszy efekt.
Na co uważać: Jakość planu wprost przekłada się na jakość fabryki. Ogólnikowy prompt da ogólnikowy system — i kolejne rundy poprawek.
4.Nie montuj systemów agentowych ręcznie — zrób to poleceniem
Na czym polega: Inicjalizacja i konfiguracja fabryki odbywają się u autora jednym skill (/tsf init, potem /tsf configure) odpalanym w agencie — kopiowanie plików i dopasowanie kodu robi agent, nie człowiek.
Jak stosować: Buduj w swoich projektach polecenia typu „init” i „configure”, które przenoszą szablon i montują go w kodzie. Dzięki temu każde nowe wdrożenie to minuty, nie godziny.
Na co uważać: Trzymaj źródłowy szablon w nienaruszonym stanie i zawsze wdrażaj jego kopię — inaczej szybko stracisz punkt odniesienia.
5.Kiedy agent robi się nieczytelny, dodaj streszczenia jego działań
Na czym polega: Funkcja „tool summary”: lekki model na bieżąco streszcza wywołania narzędzi głównego agenta do zdań zrozumiałych w mgnieniu oka — np. „przeczytał readme, rozpoznał strukturę katalogów”.
Jak stosować: Włącz podsumowania i dostosuj ich gęstość do zadania (np. co trzy wywołania) oraz długość. Własne narzędzie możesz przy tym przełączyć w locie — u autora ustawienia zmienia sam agent na polecenie naturalnym językiem.
Na co uważać: Streszczenie to skrót, nie audyt. Przy debugowaniu trzeba wracać do pełnych logów wywołań, bo skrót potrafi ukryć istotny szczegół.
6.Deleguj proste zadania do podagentów z twardymi budżetami
Na czym polega: Podagenty w fabryce dostają własny poziom modelu, własny prompt systemowy, narzędzia oraz budżet czasu i pieniędzy (w demie: lekkie modele, 1 minuta, 15 centów). Trzy równoległe podagenty streszczają serwer, klienta i skill, a wyniki lądują na jednej stronie.
Jak stosować: Dla zadań, w których odpowiedź nie musi być perfekcyjna, świadomie schodź z modelem i zaciśnij budżety — liczy się szybkość. Zbieraj wyniki równoległych przebiegów w jednym miejscu.
Na co uważać: Odcinanie budżetów ma sens tylko tam, gdzie jakość naprawdę nie jest krytyczna. Dla zadań wymagających staranności cięcia kosztów odbiją się na rezultacie.
7.Mierz wszystko — bez pomiaru nie ma poprawy
Na czym polega: Każdy przebieg podagenta jest rejestrowany: widać prompt wejściowy, jego syntezę, wszystkie wywołania narzędzi, wynik, czas i koszt. Autor wprost powtarza zasadę: czego nie mierzysz, tego nie poprawisz.
Jak stosować: Po każdym większym zadaniu przeglądaj zapisane przebiegi i porównuj zamiar z wykonaniem. To najszybszy sposób wykrycia, gdzie agent systematycznie odbiega od celu.
Na co uważać: Logowanie wszystkiego też kosztuje — uwagę i tokeny. Ustal sensowną gęstość rejestrowania zamiast zapisywać każdą operację.
8.Daj agentowi pełny paritet z interfejsem
Na czym polega: Zasada „agentic access parity”: każde kliknięcie i każda zmiana ustawień ma swój odpowiednik w poleceniu, które wykona agent. W demie agent jednym promptem zmienia motyw, skraca podsumowania, przebudowuje pasek nawigacji i otwiera strony ustawień.
Jak stosować: Dodając do własnego narzędzia nową funkcję, od razu dodaj jej sterowanie poleceniem. Wtedy cały system można obsługiwać — i przebudowywać — w tempie agentów, także bez udziału człowieka.
Na co uważać: Pełna sterowalność oznacza też, że agent może nadpisać ustawienia globalne. Warto mieć wgląd w to, co zostało zmienione, i łatwą drogę powrotu.
9.Specjalizacja zamiast jednego superagenta
Na czym polega: Wbrew modzie na „jednego agenta do wszystkiego”, autor argumentuje, że powtarzalne, wąskie problemy rozwiązuje się wyspecjalizowanymi, małymi systemami działającymi całą dobę. W erze agentów każdy zbuduje cokolwiek jednym promptem — przewagę daje więc specjalizacja, a praca „przy pętli” tę przewagę zwielokrotnia.
Jak stosować: Wypisz problemy, które rozwiązujesz cyklicznie. Każdy z nich to kandydat na osobną, małą fabrykę — budujesz systemy, które budują systemy za ciebie.
Na co uważać: Każda dodatkowa fabryka to koszt utrzymania. Specjalizuj tylko tam, gdzie problem naprawdę powraca regularnie.
10.Dopracowuj komfort pracy w narzędziu — także rękami agenta
Na czym polega: Autor pokazuje, że drobne zmiany interfejsu (motyw „pomarańcz na czerni”, skróty klawiszowe, tryb mały na pasku statusu) wykonuje poleceniem, a agent przebudowuje system w kilka sekund. Płynny soft jest dopasowywalny „aż do poziomu naciśnięć klawiszy”.
Jak stosować: Skoro system można swobodnie przebudowywać, pozwól agentowi przeprowadzać drobne zmiany ergonomii na żądanie — własne narzędzie codziennego użytku powinno być wygodne od pierwszego dnia.
Na co uważać: Chaotyczne zmiany konfiguracji prowadzą do bałaganu. Ustal konwencje (motyw, układ, skróty) i pilnuj, by nie zostały bezmyślnie nadpisane.
Redakcyjne tłumaczenie
Wielki obraz: przestań wpatrywać się w prymitywy agentów
Witaj w drugiej lekcji cyklu o małych fabrykach oprogramowania. Tym razem podnosimy poprzeczkę i patrzymy na nie przez pryzmat „płynnego oprogramowania” (liquid software) — wrócę do tego za chwilę. Najpierw spójrzmy na całość z szerszej perspektywy.
(Informacja dodatkowa: „Tiny Software Factories” to autorski cykl IndyDevDana; ten odcinek jest lekcją drugą i opiera się na podstawach omówionych w lekcji pierwszej.)
Jeśli chcesz osiągać wielokrotnie więcej jako inżynier, musisz przestać obsesyjnie zajmować się prymitywami świata agentów: modelami, narzędziami, platformami, na których te modele działają. Na czym zamiast tego naprawdę warto się skupić? Na metaoptymalizacji — na poprawianiu nie pojedynczych elementów, lecz samego sposobu, w jaki pracujesz. Najważniejsza taka zmiana, na której dziś korzystają inżynierowie, to przejście od pracy „w pętli” (human in the loop) do pracy „przy pętli” (human near the loop), a docelowo do całkowitego wyjścia „z pętli”.
Dlaczego to ma znaczenie? Bo skala inteligencji pracującej na twoją rzecz bezpośrednio decyduje o tym, jak duży efekt możesz osiągnąć, pracując z agentami. Gdy tkwisz w pętli, wymieniasz się z agentem promptami — i działa, dopóki nie potrzebuje ciebie. Nie miej złudzeń: w tym układzie to ty jesteś wąskim gardłem. Gdy jesteś przy pętli, twoi proaktywni agenci działają za ciebie całą dobę i zatrzymują się tylko w punktach decyzyjnych — tam, gdzie wynik wymaga twojej uwagi. A gdy wychodzisz z pętli, system pracuje 24/7 bez cienia oczekiwania, że w ogóle się zjawisz.
W tym cyklu skupiamy się na pierwszym przejściu: z „w pętli” do „przy pętli”. Ale małe fabryki to nie tylko to.
Dwa cele architektury i idea płynnego oprogramowania
Architektura małej fabryki oprogramowania (Tiny Software Factory, TSF) ma dwa cele. Po pierwsze: możliwość błyskawicznego wdrożenia w trzech krokach — init, configure, specialize. Po drugie: przyjmowanie kształtu rozwiązywanego problemu. Co to właściwie znaczy? Wraz ze wzrostem inteligencji modeli i spadkiem cen tokenów rodzi się nowy gatunek oprogramowania, który zmienia postać w zależności od problemu, jaki ma rozwiązać. I najciekawsze: zmienia ją wciąż na nowo — im więcej uczysz się o swoim problemie, tym bardziej dopasowuje się do niego soft. To nowe, płynne oprogramowanie ma wyjątkową cechę: od pierwszego dnia projektowane jest tak, żeby to ty je przystosowywał. Mała fabryka jest właśnie takim tworem — ma zostać dopasowana do konkretnego problemu, który rozwiązujesz na okrągło, z tobą przy pętli, a nie w niej. Jeśli ten nowy gatunek softu cię intryguje, zostań: zaraz zainicjujemy, skonfigurujemy i wyspecjalizujemy twoją fabrykę.
Mapa funkcji: 14 nowości na poziomie 2
W drugiej lekcji — i w całym cyklu — posługujemy się mapą funkcji, która stopniowo odsłania kolejne możliwości fabryki. To poziom drugi z czterech. Przejdziemy przez 14 funkcji po kolei i przy każdej wyjaśnimy, co wnosi do twojej inżynierskiej pracy. Każda funkcja ma trzy wymiary: nakład pracy, wartość i wymagane umiejętności. Podobnie jak w lekcji pierwszej trzymamy to prosto i patrzymy na nakład oraz wartość. Jeśli przegapiłeś pierwszy odcinek, koniecznie nadrob — tam omawiam fundamenty architektury. Tutaj dokładamy do nich 14 nowych możliwości, rozszerzających to, co fabryka potrafi bez żadnej dodatkowej pracy po wdrożeniu.
Pusta fabryka — pierwsza i najważniejsza własność
Najważniejsza cecha każdej małej fabryki brzmi paradoksalnie: jest pusta. Szablon poziomu 2 zawiera ogólne narzędzia agentowe, które nie mają żadnego celu, dopóki sam go nie nadasz. To klucz do zrozumienia całej koncepcji. I nie miej wątpliwości: szablon, który można dowolnie przystosowywać, a który przy tym od razu jest dobrze skonfigurowany, to ogromna przewaga. Przekonasz się o tym po raz kolejny w tej lekcji.
Oto nasza pusta fabryka: w centrum obszar skupienia, po prawej agent, po lewej lista. Każda aplikacja jest listą czegoś — co znajduje się na twojej? A w środku fabryki poziomu 2 czeka pakiet nowości — część z nich widać w menu ustawień.
Trzy kroki od pustej do działającej fabryki
Zanim omówimy nowe funkcje, trzeba ustawić sobie w głowie proces, przez który przechodzi każda pusta fabryka, żeby zacząć działać: inicjalizacja, konfiguracja, specjalizacja. Naszą fabrykę wyspecjalizujemy w roli analityka danych dla aplikacji Hughes, generującej obrazy z promptów — przykładu z lekcji pierwszej. To prosta aplikacja typu prompt–obrazek, która posłuży nam za makietę do nauki całej koncepcji.
Krok 1: inicjalizacja, czyli montowanie fabryki w kodzie
W pierwszym kroku używamy jednej umiejętności (skilla) i jednego polecenia: bierzemy szablonową, pustą fabrykę i przenosimy ją do aplikacji docelowej — do istniejącego kodu (brownfield) albo do projektu pisanego od zera (greenfield). Ręcznie niczego już nie robimy — poruszamy się w tempie agentów.
(Informacja dodatkowa: w żargonie programistów brownfield to praca w istniejącym systemie, greenfield — budowa od zera.)
W VS Code widać kod TSF2, czyli fabrykę poziomu 2 z samymi niezbędnymi elementami: katalog ze skillami, w tym „super-skill” małej fabryki — jedna umiejętność, która robi bardzo dużo — pliki startowej konfiguracji aplikacji i readme. Montujemy nową fabrykę wewnątrz aplikacji analitycznej Hughes. Otwieram terminal i uruchamiam polecenie „inloop”. Nazwałem je tak celowo i aż nadto dosłownie: za każdym razem, gdy je odpalam, wiem, że znowu siadam przy klawiaturze i tłukę się promptami. Wpisuję /tsf, żeby aktywować skill, wybieram init i podaję ścieżkę, pod którą fabryka ma trafić — katalog wyżej, tsf-to-analytics. Startuję.
Najlepszy dostępny agent pracujący w pętli bierze się do roboty: to w gruncie rzeczy szybkie skopiowanie właściwych plików. Po chwili widać je na miejscu — katalog ze skillami i kod fabryki w katalogu .tsf. Sam TSF2 pozostaje nietknięty, bo to czysty, pusty szablon, który nic nie robi, dopóki nie dostanie konkretnego celu. Agent zgłasza sukces: fabryka zamontowana, pliki na miejscu, wybrane zostały nowe porty. Czas na kolejny krok.
Krok 2: konfiguracja, czyli planowanie fabryki
Jeśli chcesz przejść od pustej fabryki do działającej, to jest właściwy proces. Krok drugi to konfiguracja — planowanie. Tu siadasz z agentem, piszesz szczegółowy, długi prompt — mówiąc wprost: plan — i przekazujesz go skillowi konfiguracyjnemu TSF. W ten sposób montujesz kod i zaczynasz dopasowywać go do konkretnego zestawu problemów. My zamieniamy pustą fabrykę w fabrykę analityki danych — i za chwilę zobaczysz, dlaczego to takie potężne.
W tym samym agencie zmieniam katalog na tsf2-analytics, uruchamiam /tsf i przechodzę do workflow configure, wskazując pustą fabrykę jako szablon. Podaję prompt, nad którym wcześniej pracowaliśmy z agentem — treść zależy wyłącznie od tego, jak chcesz wyspecjalizować swój system. U mnie to plan na 150 linii, którego sedno mieści się w jednym zdaniu: „zamień tę zainicjowaną fabrykę w agenta analityki produktu”. Podaję bezwzględną ścieżkę do pliku i odpalam. To duża budowa — agent rusza do pracy i zajmie mu to trochę czasu. Dajmy mu spokojnie popracować.
W trakcie budowy: nowe funkcje pustej fabryki
Podczas gdy agent w pętli buduje system, który buduje systemy, omówmy nowości, którymi wyposażono pusty szablon — po to, by można go było błyskawicznie wdrażać ponownie, jak płynne oprogramowanie, do każdego problemu rozwiązywanego w sposób powtarzalny. Przejdźmy przez te możliwości, bo naprawdę poszerzają to, co poznaliśmy w lekcji pierwszej.
Podsumowania wywołań narzędzi. Pierwsza nowość: lekki model streszcza na bieżąco dokładne wywołania narzędzi, których dokonują twoi agenci w trakcie pracy, żebyś mógł szybko obejrzeć i zrozumieć, co się dzieje. Wraz ze wzrostem inteligencji modele napędzające twoje fabryki będą coraz trudniejsze w odbiorze — każde wywołanie narzędzia będzie zapchane informacjami. Masz dwie opcje: odwrócić wzrok i modlić się, żeby jakoś to zagrało, albo zająć się tematem inżyniersko i zacząć mierzyć. Podsumowania zdejmują zasłonę z tego, co twój model — inżynier jakby z innej planety — faktycznie wyprawia: sprowadzają wykonaną robotę do zdań, które łapiesz jednym rzutem oka.
Zobaczmy to w praktyce. „Ping” — agent online. „cwd” — i zauważ: nawet zwykłe polecenie pwd jest opakowane w zgrabne podsumowanie. A teraz trochę customizacji, bo to przecież płynny soft, zaprojektowany do przebudowy w każdej chwili. „ls” — kilka przebiegów więcej. Teraz polecenie: „ustaw podsumowania co trzy wywołania narzędzi i widoczne linie na dwie”. Korzystamy tu z paritetu agentowego — wrócę do tego za moment. Widać, że agent zmienił własne ustawienia. Jeszcze jeden prompt: „podsumuj architekturę tej aplikacji, pokazując każde polecenie”. Wywołania skleiły się w pary i zostały streszczone — jedno, drugie — i błyskawicznie wiemy, co agent zrobił: przeczytał readme, rozpoznał strukturę katalogów, a na końcu dostajemy czyste podsumowanie całej pracy. Im bardziej złożony będzie twój agent i im trudniej śledzić jego poczynania, tym bardziej docenisz tę funkcję — zobaczysz jej siłę przez całą lekcję.
Delegacja do podagentów. Klasyka gatunku, w rozbudowanej wersji: agenci jednorazowi, od pojedynczego zadania. Najważniejsza różnica względem podagentów, które znasz, polega na możliwości agresywnej specjalizacji. Co to znaczy w praktyce? Każdy podagent dostaje własny poziom modelu, własny prompt systemowy, własne narzędzia i budżet — czasowy oraz pieniężny. Mamy więc drobnoziarnistych podagentów z porządnymi ograniczeniami i sensownymi wartościami domyślnymi. Wszystko widać w ustawieniach: prompt streszczający (edytowalny), liczba linii, poziom modelu, tryb rozumowania, streszczanie co trzy wywołania — wszystko konfigurowalne. W sekcji podagentów: model, rozumowanie i budżety — do 25 centów na przebieg, do dziesięciu minut pracy, maksymalnie czterech agentów naraz. Wszystkie ślady działań i informacje o przebiegach lądują na liście.
Odpalmy kilka podagentów: „Zacznij trzech podagentów — streszcz kolejno serwer, klienta i skill TSF. Użyj lekkich modeli, limit jednej minuty pracy i budżetu 15 centów. Z wyników stwórz stronę”. Ruszają trzy przebiegi równoległe: serwer, klient, umiejętność. W każdej chwili można do każdego zajrzeć. Już wróciły z wynikami — a teraz agent tworzy stronę zbiorczą, wykonując przy tym całą serię operacji. Spójrz na obszar skupienia w centrum: strona po lewej powstała. To zwięzły, konkretny przegląd architektury TSF — nie musimy go teraz omawiać, ale widać, że agent przebiegł przez całość ułamkiem czasu dzięki podagentom. Odpowiedź nie musiała być idealna, więc świadomie zdjęliśmy modele i budżety do minimum — chodziło o szybkość.
Otwórzmy z powrotem ustawienia i sekcję podagentów: widać tam dokładne przebiegi. Czego nie mierzysz, tego nie poprawisz — dlatego mierzymy wszystko, aż do pojedynczego podagenta. To znowu podkreśla kluczową ideę: mając system, który jest twój, możesz stanąć przy pętli zamiast w niej utknąć — bo widzisz wszystko. A skoro to płynne oprogramowanie, wszystko możesz też dopasować do siebie. Widać odpowiedzi i wszystkie wywołania narzędzi; przewijając w górę, zobaczysz dokładnie zadanie, które dostał agent: prompt wejściowy, jego przetworzenie i wynik. Jesteśmy właścicielami naszego agentowego oprzyrządowania, więc skonfigurowaliśmy je tak, by widzieć wszystko. I pamiętaj: to wciąż tylko szablon fabryki poziomu 2.
Paritet agentowy. Te możliwości nieustannie prowadzą do jednej, naprawdę kluczowej cechy małych fabryk: pełnej równości agenta z człowiekiem w dostępie do systemu (agentic access parity). Na poziomie 2 obowiązuje to samo, co podkreślaliśmy na poziomie 1: każde kliknięcie i każda zmiana ustawień ma swój odpowiednik w poleceniu, którym agent zrobi to samo. Dlaczego to takie ważne? Bo pozwala pracować w tempie agentów. Przyznajmy sobie szczerze: ty i ja jesteśmy wolni. Używajmy więc najlepszego narzędzia inżynierskiego, jakim są agenci — bo my nim nie jesteśmy. To jeden z wielu powodów, dla których warto wyjść z pętli i stanąć przy niej: oddajesz agentom więcej roboty i nie jest to zleniwienie — inżyniersko projektujesz efekty, na których ci zależy.
Zobaczmy to w akcji: „Przywróć domyślne ustawienia podagentów na lekkie, po 30 centów. Ustaw podsumowania narzędzi z powrotem przy każdym wywołaniu. Włącz cykliczny puls. Stwórz nowy motyw pomarańcz na czerni, łagodny dla oczu, i go ustaw. Dodaj do globalnego paska status agenta, wybór modelu, wywołania narzędzi, tokeny wejściowe, wyjściowe i sumaryczne — w trybie małym, po lewej. Potem otwórz ustawienia i narzędzia oraz wypisz skróty klawiszowe w punktach, w logicznych grupach”. Dostosowuję tu po prostu losowe rzeczy — cała ta ekwilibrystyka ma pokazać jedno: agent ma pełny paritet i potrafi zrobić w systemie wszystko, co my. I faktycznie, w tempie agentów przebudowuje cały system: otwiera mi ustawienia, obsługuje interfejs, działa na pustej fabryce beze mnie — a skoro potrafi to zrobić na pustej, to tym bardziej na działającej. Znów ten motyw płynnego softu, który dostosowuje się sam, z agentem w środku. Otwiera stronę narzędzi: widać je wszystkie, pogrupowane według platform sterujących (harnessów), które wbudowaliśmy w system; można przełączyć widok na opisy albo parametry. Agent wypluł też komplet skrótów klawiszowych. Właśnie tak błyskawicznie poruszam się po interfejsie i poprawiam komfort pracy w każdej fabryce, w której działam. Ruszam w tempie agentów i na bieżąco dopasowuję oprogramowanie do rozwiązywanego problemu — choć w tym wypadku żadnego problemu nie rozwiązuję, po prostu pokazuję cechy architektury. Taka jest siła płynnego softu: jest projektowany do dopasowywania aż do poziomu pojedynczych naciśnięć klawiszy. Oczywiście można też zmienić model, a wywołania narzędzi i tokeny wejście–wyjście widać dokładnie tam, gdzie byś oczekiwał.
Pusta fabryka stała się działającą — i co dalej
I tu wreszcie wchodzi magia małej fabryki: agent zakończył konfigurowanie. Pusta fabryka właśnie stała się fabryką działającą.
Wbrew pozorom jeden superagent, który robi wszystko, nie jest właściwą drogą do powtarzalnego, całodobowego rozwiązywania wyspecjalizowanych problemów. W erze agentów każdy może jednym promptem zbudować cokolwiek — przewagę daje więc specjalizacja. A praca przy pętli tę przewagę zwielokrotnia, bo nie musisz siedzieć przy klawiaturze, żeby robota szła: budujesz systemy, które w twoim imieniu budują systemy. Wychodzisz z pętli zamiast w niej utknąć.
W lekcji trzeciej pójdziemy dalej: wyspecjalizujemy inteligencję wewnątrz fabryki w postaci małych zespołów agentów i znów dobudujemy kolejny pakiet funkcji na poziomy 1 i 2. Na ten moment masz już więcej niż wystarczająco, by zabrać się za konkretne problemy, które chcesz rozwiązywać na okrągło — z sobą przy pętli zamiast w niej. Po każdej ukończonej lekcji zadawaj sobie pytanie: „Jakie problemy mogę powtarzalnie rozwiązywać małą fabryką oprogramowania?”. Do zobaczenia w lekcji trzeciej, gdzie zbudujemy małe zespoły agentów komunikujące się ze sobą — pracujące razem szybciej i skuteczniej, niż potrafiłyby każde z osobna. A wszystko to stanie się możliwe dzięki inwestycji, którą włożysz w swoje puste i działające fabryki — w swoje płynne oprogramowanie. Do zobaczenia tam.