Czym jest fabryka oprogramowania?

O czym jest ten film

1. Gościem odcinka jest Adam Jacob — współtwórca narzędzia Chef i jeden z ojców ruchu DevOps, dziś szef Swamp Club; tematem rozmowy są „fabryki oprogramowania”.
2. Swamp Club w pigułce: opisujesz zadanie po ludzku, a platforma przekształca je w deterministyczne, modułowe automatyzacje z typowanymi wejściami i wyjściami; modele obliczeniowe podpinasz własne.
3. Różnica względem Claude Code czy Codexa: skill nie jest automatem — przy każdym uruchomieniu model na nowo „wymyśla” tę samą logikę i spala drogie tokeny; dobrze zbudowana automatyzacja działa identycznie za każdym razem.
4. Definicja fabryki: tyle cyklu wytwarzania oprogramowania, ile się da — od rozbicia pracy, przez jakość kodu i zgodność z architekturą, po brak regresji — obsłużone przez agentów; jej kształt zależy od produktu i zespołu.
5. Warunkiem zaufania jest powrót testów blackbox; unit testy i TDD z agentami podane są w wątpliwość (badanie Thoughtworks: TDD pogarszało wyniki agentów).
6. Deterministyczna kontrola jakości to architektura (np. projektowanie zorientowane na domenę) zapisana jako skill oraz przeglądy „adwersarskie” — np. standardy dostępności sprawdzane przy każdej zmianie.
7. Gdy system zawodzi, poprawia się fabrykę, by cała klasa błędów wpadała częściej — to „budowanie maszyny, która buduje”, czyli nadal inżynieria, tylko piętro wyżej.
8. Przebudowa dużej organizacji zaczyna się od małego zespołu z mandatem do łamania zasad (lean: kaikaku) i szybkiego pokazania działającego kodu; zdaniem Jacoba nikt na świecie takiej przemiany jeszcze nie ukończył.
9. Co z tysiącami inżynierów (LinkedIn: 10,5 tys.)? Popyt na oprogramowanie nie ma znanej górnej granicy, a rola ludzi produktu przesuwa się z rozdzielania zadań na ocenę efektów.
10. Najświeższy kraniec to personalizacja i oprogramowanie „mniejsze”: narzędzia szyte na miarę — od wibecodowanego pakietu Adobe po osobiste automatyzacje prowadzących.

10 najważniejszych takeaways — z kontekstem zastosowania

1.Promptuj raz, automatyzuj na stałe

Na czym polega: Każde kolejne uruchomienie tego samego promptu czy skilla na modelu czołowym to wymyślanie od zera tej samej logiki i przepalanie drogich tokenów. Intencję da się natomiast zamknąć w deterministycznym kodzie uruchamianym jak zwykły skrypt — działa identycznie za każdym razem i nie kosztuje tokenów.

Jak stosować: Gdy po raz trzeci prosisz agenta o tę samą czynność (porządki, integracje, przetwarzanie danych), zamień opis na automatyzację: wejścia, kryteria, kroki, zapisywane wyniki — a potem wywołuj ją jednoznacznie.

Na co uważać: Automatyzacja to także kod — wymaga refaktoryzacji i przestrzeni na rozwój. Sam skill z najnowszym modelem bywa placebo: skuteczność rośnie z 80 do 90 procent, a nie do stu.

2.Odwróć pętlę: determinizm rządzi, inteligencja służy

Na czym polega: Zamiast pozwalać modelowi językowemu kręcić zewnętrzną karuzelą, to deterministyczny proces wywołuje inteligencję tylko tam, gdzie potrzebny jest osąd (np. klasyfikacja, decyzja) — i wymaga ustandaryzowanych wejść oraz wyjść.

Jak stosować: Standaryzuj wyniki pośrednie (np. wyniki klasyfikacji) tak, by kolejne kroki przepływu mogły je odpytywać. Modele traktuj jako konfigurowalne opcje komponentów, żeby podmiana — choćby na tańszy model decyzyjny — była jednym parametrem, a nie przepisywaniem.

Na co uważać: Różne API i modele nie zachowują się identycznie — podmiana wymaga testów. Uważaj też na koszty: wypchnięcie inteligencji na margines bez standardów danych szybko odbija się rachunkiem.

3.Fabryka to cykl wytwarzania w rękach agentów — i zawsze szyta na miarę

Na czym polega: Fabryka oprogramowania to obsłużenie przez agentów jak największej części SDLC: rozbicia pracy, jakości kodu, zgodności z architekturą, braku regresji. Żadne dwie fabryki nie są takie same, bo kształt narzuca to, co mają produkować.

Jak stosować: Zacznij od określenia, co fabryka ma wytwarzać i gdzie są jej wejścia — stos ticketów u jednych, minimalny backlog u innych. Projektuj proces pod swój produkt, nie kopiuj cudzych schematów.

Na co uważać: Fabryka nie zastępuje decyzji produktowych. O tym, że oprogramowanie jest dobre, decydują unikalne wybory zespołu — klon cudzego „gotowca” da wynik generyczny.

4.Zanim zbudujesz fabrykę, zbuduj suitę blackbox

Na czym polega: Gdy w środku procesu nie pracuje człowiek, jedynym bezpiecznikiem jest testowanie od zewnątrz: czy produkt jako całość nadal robi to, co obiecywał. Wielkie suity akceptacyjne porzucono w erze ciągłego wdrażania jako zbyt kosztowne — z agentami znowu się opłacają, i to one otwierają drogę do dalszej automatyzacji.

Jak stosować: Zanim zautomatyzujesz cykl, zbuduj (lub wygeneruj i sam zweryfikuj) testy akceptacyjne blackbox wokół kluczowych zachowań produktu; dokładaj kolejne za każdym razem, gdy fabryka coś zepsuje.

Na co uważać: Blackbox nie gwarantuje zeru regresji — ludzie też je wysyłali bez przerwy. To podnosi niezawodność, a nie daje pewność absolutną.

5.Przesądź na nowo rolę unit testów i TDD

Na czym polega: Skoro AI rzadko pisze kod funkcjonalnie błędny, a nikt nie wpatruje się we wnętrza, testy jednostkowe tracą główną rację bytu. Badanie opisane na blogu Thoughtworks pokazało, że proszenie agentów o TDD pogarszało wyniki. Silne systemy typów (TypeScript, Rust) przejmują rolę wczesnego łapania błędów.

Jak stosować: Potraktuj to jako hipotezę do własnego eksperymentu: zmierz liczbę regresji z testami jednostkowymi i bez nich. W językach bez silnych typów zostaw je na dłużej.

Na co uważać: Nie kasuj wszystkiego hurtem tylko dlatego, że „tak powiedział Jacob”. Branża dopiero zbiera dane, a najgorszy scenariusz jest tani — agent napisze testy od nowa.

6.Zapisz architekturę jako skill — agent już zna ten język

Na czym polega: Zostawiony samemu sobie agent wybiera wzorce losowo — stąd „zbudowane na czystej intuicji” systemy są kruche i sypią się przy każdej nowej funkcji. Zapisana architektura (rekomendacja: projektowanie zorientowane na domenę) daje agentowi gotowy słownik — „warstwa antykorupcyjna” i spółka — oraz wzorce do naśladowania.

Jak stosować: Spisz zasady architektoniczne i słownik własnego systemu jako skill; każdemu wygenerowanemu fragmentowi kodu zadawaj pytanie o zgodność z nim; dołącz przykład wzorca z własnej bazy.

Na co uważać: Działa to tylko przy spójnej architekturze i konsekwencji egzekwowania. Zapis „na papierze”, rozjechany z kodem, wprowadzi agenta w błąd szybciej niż brak zapisu.

7.Wymagania poza architekturą egzekwuj przeglądami adwersarskimi

Na czym polega: Standardy takie jak dostępność (WCAG) warto zapisać jako chude skille „przeciwnika”, które oceniają każdą przechodzącą zmianę; obleje — wraca do przeróbki.

Jak stosować: Zacznij od pytania modelu o dany standard, a potem dorzuć własne reguły „zawsze prawdziwe” (np. kontrast barw na stronie). Optymalizuj koszty, dobierając uruchamiane testy do natury zmiany — do selekcji kryteriów可以利用 tani model klasyfikujący.

Na co uważać: Nie złapiesz stu procent błędów — celem jest częstsze wyłapywanie danej klasy problemów. Skille wymagają aktualizacji wraz ze zmianą technologii i standardów.

8.Błąd systematyczny? Popraw maszynę, nie wytykaj AI

Na czym polega: Gdy ta sama klasa błędów wraca, właściwe pytanie brzmi „co zmienić w fabryce, żeby ta klasa wpadała częściej”, a nie „te roboty są głupie”. Budujesz maszynę, która buduje produkt — to wciąż inżynieria, tylko piętro wyżej.

Jak stosować: Prowadź rejestr klas błędów; do każdej przypisuj konkretną zmianę w systemie (nowy test, nowy skill, inny przepływ) i mierz, czy częstość występowania spada.

Na co uważać: Dwie pułapki: ręczne łatanie objawów (poprawianie pojedynczych PR-ów) zamiast mechanizmu oraz dopracowywanie masziny w nieskończoność zamiast wysyłać produkt.

9.W dużej organizacji zacznij od piątki z immunitetem

Na czym polega: Przekształcenie tysięcy inżynierów naraz to problem nierozwiązywalny. Działa coś odwrotnego: mały zespół, który dostaje wyłączne prawo łamania wewnętrznych zasad, przechodzi proces „od deski do deski”, a potem uczy resztę organizacji. W lean manufacturing taki przełom nazywa się kaikaku — przebudowa fabryki wokół nowej technologii.

Jak stosować: Wybierz pięć osób i realny wycinek problemu; daj im immunitet na łamanie reguł (struktura, planowanie, procedury); oczekuj działającego dowodu w kodzie, póki trwa mandat zarządu.

Na co uważać: Najczęstszy punkt śmierci inicjatywy to dyrektor lub wiceprezes, któremu odpowiedź się nie podoba — zaczyna ją rozwadniać. Filozoficzne debaty „czy to dobre dla firmy” tylko zwalniają; pokazuj działający software.

10.Ludzie produktu przestają wyprzedzać — zaczynają oceniać

Na czym polega: Z niezawodną fabryką inżynierowie nie potrzebują zgody na wdrożenie czy refaktoryzację. Rola produktu przesuwa się na wyjście: ocenianie efektów, dopinanie ich do strategii — a że przeróbki są tanie, coś nie pasuje, to się po prostu zmienia.

Jak stosować: Przestawiaj punkty kontroli z akceptacji zadań na przegląd rezultatów; wykorzystaj niski koszt przeróbek jako dźwignię szybkich iteracji.

Na co uważać: To wciąż rzadkość — według Jacoba nikt takiej przemiany jeszcze nie ukończył. Niuanse organizacyjne (władza, tożsamość zawodowa) potrafią zabić projekt technicznie bez zarzutu.

Redakcyjne tłumaczenie

(Informacja dodatkowa: Syntax prowadzą Wes Bos i Scott Talinski. Autotranskrypcja nie oznacza mówców imiennie — wypowiedzi prowadzących przypisano na podstawie kontekstu rozmowy.)

Zapowiedź

Jeśli pójdziesz zapytać ludzi w laboratoriach AI: „Umiecie to zrobić?” — nie umieją. Nie są w tym lepsi od nas, bo to my wiemy, jak działają nasze własne systemy, a oni nie. A jak czują się z tym ludzie produktu? Źle. Ich pracą było rozkazywać inżynierom i być o krok przed nimi — a nie da się wyprzedzać ludzi, którzy wytwarzają efekty w tempie, którego nie sposób dogonić. […] Najciekawszym nowym krańcem jest dziś warstwa personalizacji: co, gdyby oprogramowanie stawało się mniejsze, a nie większe?

Gość i temat odcinka

Scott: Witamy w Syntax. Dziś rozmawiamy z Adamem Jacobem, szefem Swamp Club, o fabrykach oprogramowania. To temat gorący i otoczony mitami: dla jednych wielka zagadka — „przecież ja tylko wpisuję prompty i jakoś wychodzi” — dla innych synonim produkowania chłamu. Postaramy się te skojarzenia rozbroić i zrozumieć, czym fabryki są i jak z nich korzystać. Adamie, witaj.

Adam Jacob: Dzięki, świetnie tu być.

Scott: Jesteś CEO Swamp Club. Daj nam krótki przegląd: czym jest ta firma i skąd Ty się tu wziąłeś?

(Informacja dodatkowa: Adam Jacob to współtwórca narzędzia Chef i jedna z osób, które ukształtowały ruch DevOps — wróci do tego w dalszej części rozmowy.)

Czym jest Swamp Club

Adam: Swamp Club to sposób budowania agentów AI z zachowaniem determinizmu i określonej struktury. Sedno: siedzisz „pod” agentami i opisujesz, co chcesz osiągnąć, a system potrafi to rozłożyć na modułowe automatyzacje. Zamienia Twoje zlecenie na komponenty z typowanymi wejściami i wyjściami, umie je spiąć w przepływy pracy i umie je refaktoryzować. Gdy poprosisz o coś dziwnego — integrację z dowolnym API albo wewnętrznym systemem — po prostu rozgryza, jak to API obsłużyć, i robi właściwą rzecz. W środku jest wszystko, czego potrzeba, by takie systemy budować szybko: wspólna pamięć zrzucana do dużego data lake, który można odpytywać, i tak dalej. Ludzie używają tego na wszelkie sposoby — do utrzymywania infrastruktury produkcyjnej, w laboratoriach „mokrych” (wet lab) do sterowania ramionami robotów; ja osobiście czytam nim pocztę. Całość zaprojektowano z jednym celem: wziąć cokolwiek, co chcesz zlecić AI, i zamienić w deterministyczny proces, który działa za każdym razem.

Scott: Ja robię z tym sporo, więc dorzucę przykłady z życia. Używam Swamp. Mam automatyzacje pilnujące aktualności mojego środowiska „pi” wraz z rozszerzeniami. Mam automatyzację sprawdzającą porządek w katalogu ze stronami — nie wiem, jak u was, ale u mnie ten katalog zawsze zamienia się w cmentarzysko projektów porobionych w różnych miejscach; klasyfikacja przez Jev porządkuje pliki i odkłada je tam, gdzie ich miejsce.

(Informacja dodatkowa: Jev — tani, niewielki model używany do klasyfikacji i decyzji. W rozmowie pojawi się także Fable, nowy model czołowego laboratorium.)

Mam sprzątanie drzew roboczych gita, wymiata stare buildy Rustowe zjadające dysk. I ta, o której wspominałem w którymś odcinku: automatyzacja ciągnie bugi z Sentry, kataloguje je jako zgłoszenia i zadania, wykonuje, a na końcu sama otwiera pull requesty.

Wes: Jeszcze tego nie łapię. Wiem, że Scott o tym opowiada, wiem, że służy do automatyzacji — ale słuchacze pewnie myślą: „może lepiej wyłączyć?”. Gdzie to się ma do kogoś, kto już pracuje z Claude Code, Codexem czy czymś podobnym?

Skill w Claude to za mało: od promptu do deterministycznej automatyzacji

Adam: Bardzo dobre pytanie. Spójrzmy na doświadczenie z Claude Code na Scottowym przykładzie porządkowania katalogów. Odpalasz Claude’a: „posprzątaj mi sites, oto instrukcje”. Coś zrobi. Może dokładnie to, o co chodziło — a może nie. Więc Scott napisze „skill”, czyli zapisany pakiet instrukcji: „tak zawsze chcę, żebyś porządkował ten katalog”, razem z listą reguł. I zauważ, co się wtedy dzieje: on płaci tokenami najmocniejszych modeli po to, żeby Claude przy każdym uruchomieniu od zera wymyślał tę samą pętlę. Palimy drogie tokeny na odtwarzanie tego samego kawałka logiki.

Swamp bierze dokładnie ten sam opis — „chcę posprzątać sites, oto kryteria, może sklasyfikuj przez Jev” — i przekształca tę intencję w modułową automatyzację, w Twoim imieniu. Zaczyna od modelu z wejściami: jaki katalog sprzątamy, jaka lista kryteriów. Potem pisze cały kod, który realnie zagląda do tego katalogu, spina go tak, żeby dało się to wywołać, i zapisuje dane o wykonanej pracy — na przykład wynik klasyfikacji — tak, żeby kolejne kroki przepływu mogły go odpytać. Efekt: Scott nie pali tokenów przy każdym uruchomieniu, a całość działa za każdym razem identycznie.

Bo to jest właściwie najbardziej frustrująca cecha AI: było mądre, zrobiło, o co prosiłem — a teraz chcę, żeby robiło to częściej. I żeby osiągnąć „częściej”, biegnę po najnowszy model i płacę więcej. Skill, który działał w osiemdziesięciu procentach, na Fable działa w dziewięćdziesięciu. Z Swamp działa w stu.

Wes: Czyli doskonale znamy ten schemat: zamiast raz napisać skrypt do zadania, które wykonuję codziennie, po prostu każdorazowo proszę model — i palę tokeny.

Adam: Właśnie tak. Nadal opisujesz po ludzku, co ma być zrobione, ale dostajesz coś, co uruchamiasz jak zwykły skrypt. Doklejasz do polecenia „with swamp” i Swamp rozkłada je na modularne automatyzacje. Bo gdybyś kazał modelowi „napisz skrypt w Pythonie”, napisałby — tylko że wtedy masz nowe, ciekawsze pytania: jak to refaktoryzować? Jak to ma rosnąć, gdy dojdziemy od klasyfikowania katalogu do automatycznego wdrażania tych stron po zmianach? To wszystko może być spięte jako połączone modele. Buduje Ci się sieć automatyzacji — już zmodularyzowana, umiejąca sama się refaktoryzować, świadoma kontekstu — i wraz z nią wszystko, czego zabraknie po drodze. Zaczynasz od maleńkich agentów wyłącznie dla siebie, a z czasem składasz coraz większe zachowania.

(Informacja dodatkowa: w tym miejscu odcinek zawiera sekcję sponsorską — reklamę narzędzia do monitorowania błędów Sentry; pomijamy ją w tłumaczeniu.)

Niechlujne dane i samonaprawa

Wes: Co kocham w zlecaniu tego modelom, to możliwość podania danych bałaganiarskich — takich, które nie są dopracowane ani ustandaryzowane. Zrobiłem coś na jednym API, a chcę dokładnie to samo na zupełnie innym: wygląda inaczej, autoryzuje inaczej, wszystko inne. I wystarczy powiedzieć: „zrób to na tamtym, jakoś to ogarniesz”. Ale czy to się potrafi samo naprawiać? Że wyjdzie po ratunek do modelu?

Adam: Tak, to w gruncie rzeczy ta sama pętla. Swamp buduje Ci wewnętrzny komponent, który rozumie, czym jest dana rzecz w kontekście całego zadania. Weźmy Jev: OpenAI zapowiedziało przed kilkoma dniami API decyzji, które będzie w duchu Jev, a Cloudflare swoje już wystartował. Jeśli Scott chce spróbować któregoś z nich, mówi tylko: „zrób to opcją konfigurowalną tego komponentu”. System wtedy refaktoruje jeden komponent tak, by obsługiwał kilka API — zwykle z parametrem wejściowym typu „użyj Jev albo decisions API od Cloudflare”. I dzieje się rzecz kluczowa: odwracasz pętlę. Zamiast to model językowy rozkręca zewnętrzną karuzelę, to deterministyczna pętla wywołuje inteligencję wtedy, kiedy jej potrzebuje, dostając ustrukturyzowane wejścia i wyjścia. A ponieważ wyjścia są ustandaryzowane — Scott dokładnie wie, jakie decyzje zapadają o tym katalogu — może wymieniać modele jak wkładki, wydając mniej tokenów i mniej zachodu. Ma to sens?

Wes: Ma.

Cena i modele

Scott: Doprecyzujmy kwestie biznesowe: Swamp Club jest płatny? Zapisujesz się i płacisz co miesiąc za każdego użytkownika?

Adam: Tak.

Scott: A inferencję dostarczacie wy, czy podpinamy własną?

Adam: Własną. Swamp siedzi pod czymkolwiek, na czym pracujesz — dowolny agent, dowolne środowisko uruchomieniowe, dowolne modele — i dokłada to zachowanie.

Scott: Pięknie. Czyli do samego eksperymentowania, budowania własnych automatyzacji, płacić nie trzeba?

Adam: W ostatecznym rozrachunku — trzeba. Ale na etapie zabawy i składania automatyzacji: nie.

Czym właściwie jest fabryka oprogramowania

Scott: Przejdźmy do samego pojęcia, bo dyskusja o fabrykach jest chaotyczna: „i tak trzeba tego pilnować”, „fabryka to wytwórnia chłamu”. Adamie, wyjaśnij to porządnie.

Adam: Zacznijmy od empatii — niejasności są w branży powszechne. Gdybyśmy posadzili tu pięć osób, usłyszelibyśmy pięć różnych definicji, i to jest część tego, dlaczego temat tak irytuje. Moja odpowiedź — coraz częściej podzielana w naszej społeczności — wygląda tak: weź klasyczny cykl życia oprogramowania. Wszystko, co robisz, żeby ustalić, co wchodzi do produktu; jak rozbijasz pracę na kawałki; jak zespół przetacza się z tym przez cały proces aż po produkcję. Fabryka oprogramowania to stwierdzenie: tyle z tej pętli, ile się da — a docelowo wszystko, oprócz wejść, wyjść i może kilku miejsc pośrodku — obsłużą za ciebie agenty. Pytania „jak system utrzymuje się w równowadze?”, „jak powstaje dobry kod, sensowny dla tego systemu?”, „czy jest zgodny z architekturą?”, „czy nie regreduje i nadal działa, jak powinien?” — to jest właśnie treść fabryki. Można to rozumieć jako zamiennik: bierzesz swój cykl wytwarzania i zamieniasz go w zachowanie, które agent wykonuje w twoim imieniu. Stylów jest mnóstwo, bo mocno zależy od aplikacji, którą budujesz: to, co fabryka ma produkować, kształtuje jej formę i detale. Żadne dwie fabryki nie są takie same — kolejny powód zamieszania. Różnią się też wejścia. Jedni zaczynają od samego początku: wrzucają stos ticketów i każą „wykonać do końca” — kolejka, z której robot wypluwa gotowe. Inni, jak my, podchodzą ostrożniej: trzymamy bardzo mały backlog albo żadny i standaryzujemy sam proces, którym oprogramowanie powstaje.

Scott: W tej dyskusji gubi się to, że nie istnieje jeden uniwersalny przepis. W twoim ujęciu fabryka zawsze jest dopasowana do projektu, zespołu i sposobu, w jaki pracuje, tak?

Adam: Zdecydowanie. Pomyśl o inżynierii jako takiej. Oprogramowanie jest dobre z jednego powodu: z powodu decyzji zapadających o tym, jak działa, jak się składa, jaka jest jego architektura wewnętrzna, jak wygląda i jak się go używa. To te wybory czynią produkt dobrym — każdy produkt. A projekty z natury są niepowtarzalne: sposób, w jaki myślimy o produkcie i o tym, po co jest, jest unikalny dla ludzi, którzy go tworzą. Budując fabrykę, staramy się zakodować w systemie jak najwięcej z tych zachowań i tej wiedzy, żeby szybciej przebiegać drogę od zamiaru do efektu — a za to, co dzieje się pośrodku, odpowiada fabryka. Dlatego fabryka to coś więcej niż „jak ja promptuję Claude’a”. Więcej niż worek skilli i dobre chęci: właśnie ta struktura nadaje kształt całej konstrukcji i pozwala bezpiecznie powiedzieć „chcę, żeby produkt robił to i taki był”, ufając, że system dopasuje wnętrze do właściwego rezultatu. I dlatego zawsze będzie szyta na miarę twojego produktu — bo niepowtarzalne są jego wnętrza.

2500 pull requestów i powrót testów blackbox

Scott: Jest ostatnio wpis Potato na X — wideo i post o dostarczeniu 2500 pull requestów w zeszłym miesiącu przy Groku. Sporo tam o zaufaniu: jak ufać efektom pracy agentów i jak to zaufanie weryfikować. Dla mnie brzmi to jak fabryka. To to samo plemię?

Adam: Dla mnie tak. Z własnego doświadczenia: wróciliśmy w Swamp do czegoś, z czym zerwałem jeszcze około przełomu 1999 i 2000 roku — do bardzo obszernych, kompleksowych testów akceptacyjnych typu blackbox, czyli takich, które sprawdzają produkt wyłącznie z zewnątrz, bez zaglądania do wnętrza. Odeszliśmy od nich w erze ciągłego wdrażania, bo zatrzymywały wszystko: wielka suita akceptacyjna pisana ręcznie przez każdego inżyniera dodającego funkcję potrafiła potroić nakład pracy. Wszystko trwało dłużej, a zysk wydawał się marginesowy. Ale gdy masz fabrykę odpowiadającą za dopasowanie oprogramowania od zamiaru do efektu — co, jeśli zepsuje produkt? Jeśli zerwie kontrakt, akurat gdy nikt nie patrzy? Odpowiedzią jest właśnie testowanie blackbox: patrzenie z zewnątrz do środka. Czy produkt nadal działa? Robi wszystko, co obiecywał? Skądś przecież wiemy, że nawet z człowiekiem pośrodku regredowaliśmy bez przerwy — a żeby fabryka realnie przyspieszyła zespód, musisz mieć ten poziom zaufania. I trzeba go zbudować.

Scott: Brzmi jak fabryka z definicji: zaufanie, powtarzalna automatyzacja — system zachowuje się tak samo przy każdym przejściu, niezależnie od tego, kto podaje wejścia: inżynier czy produktowiec.

Wes: Czasem mam wrażenie, że cały problem z tym terminem to kwestia percepcji i marketingu. Powiedz zwykłym developerom: „dodajmy bardziej deterministyczne systemy walidacji zaufania” albo „ustandaryzujmy proces, który powtarza się co tydzień” — większość przytaknie. A „fabryka oprogramowania”? Dla wielu od razu „fabryka chłamu”.

Adam: No właśnie — bo jeśli nie stosujesz tych technik i nie zmieniłeś procesu, to jest koszmar. Zespół dziesięciu developerów, scrum, te same spotkania co rok czy dwa temu, ta sama robota — tylko że teraz wylatują tysiącwierszowe PR-y pisane przez Claude’a, których nikt nie rozumie, źle dopasowane do celu, i „naszą robotą jest to ogarnąć”, a jedyna realna zmiana to podkręcona prędkość, bo kod leci szybciej… To jak utknąć w najgorszym miejscu oceanu na desce: strefa przyboju, z której nie ma wyjścia — fale łamią się bez przerwy i bez przerwy cię grzmocą. Paradoksalnie droga wyjścia prowadzi przez więcej AI, nie mniej: więcej automatyzacji, więcej struktury, więcej zaprojektowanego systemu. I dlatego staje się to problemem projektowania systemów. Ja nie wymyśliłem nazwy „software factory” — tak ją po prostu ludzie nazwali. Pomagałem za to wymyślić „DevOps” i mam żal, jak to słowo weszło do świata; jestem pewien, że twórcy metafory fabryki też będą mieli żale. Ale to sam proces jest sednem. Oczywiście, że brzmi ci to jak fabryka chłamu — twoje życiowe doświadczenie mówi ci, że to fabryka chłamu. Więc gdy ktoś przychodzi z techniką, która ma tę fabrykę jeszcze przyspieszyć, odpowiadasz: „absolutnie nie. Tego, co mnie zabija, nie chcę więcej”.

Wdrożenie w dużej organizacji: piątka z immunitetem

Wes: Mam pytanie o firmy z ogromną liczbą inżynierów. Pamiętam statystykę, że sam LinkedIn ma trzystu inżynierów commitujących CSS codziennie. Co poradziłbyś firmie z setkami, tysiącami ludzi? Jak w ogóle zaczynać taką przebudowę?

Adam: Świetne pytanie. Widzę dziś dwie granice rozwoju AI. Jedna to laboratoria i wszystko, co one robią. Druga to odpowiedzi na pytania takie jak twoje: jak my, zwykli śmiertelnicy dostający gotowe modele, zbudujemy działające systemy — najpierw małe, potem duże. Szczera prawda: bardzo niewielu ludzi, być może nikt, rozgryzło to na poziomie organizacyjnym. I nie chodzi o technologię. Najtrudniejsze jest to, że przejście rozsadza cały istniejący proces pracy i punkty kontroli. Pomyśl: jesteś osobą od produktu, a twoi inżynierowie mają godną zaufania fabrykę — mogą wdrożyć, co chcą, zrefaktorować, co chcą, wysłać każdą funkcję, jaka przyjdzie im do głowy, bez pytań i bez twojej zgody. Jak czują się z tym ludzie produktu? Źle. Ich rolą było kierować inżynierami i być o krok przed nimi, a teraz nie da się wyprzedzać kogoś, kto wytwarza efekty w tempie, którego nie opanujesz. Zostaje ci praca „na wyjściu”: oglądać efekty zespołów i dopinać je do tematu — a ponieważ koszt przeróbki jest śmiesznie niski, coś ci nie pasuje, to po prostu zmieniasz. To tak dziwny zwrot organizacyjny, że garstka firm wie, jak się zreorganizować, żeby te zyski zebrać.

Z poprzedniej fali — transformacji cyfrowej, chmury i całej reszty — zapamiętaliśmy jedną lekcję: pierwszy krok jest zawsze taki sam. Potrzebujesz małego zespołu, który własnoręcznie zazna życia po drugiej stronie. Zamiast rozmyślać, jak przekształcić sześćdziesiąt tysięcy inżynierów — problem nie do ruszenia — znajdź pięć osób i powiedz: bierzecie wycinek prawdziwego problemu z naszego podwórka i wyłącznie wy dostajecie pozwolenie na złamanie wszystkich zasad. Struktura organizacji, planowanie, procedury — wszystko możecie zdeptać. Waszym jedynym zadaniem jest dowiedzieć się, jak to jest zbudować od początku do końca fabrykę, której ufacie, która dostarcza w takim tempie i daje niezawodny efekt. Gdy to macie, ta piątka zna już oba światy: wasz bieżący i ten nowy. W lean manufacturing takie momenty nazywa się kaikaku — technologia na zawsze zmienia naturę fabryki, więc trzeba ją przeprojektować w całości, bo gruntownie przemeblowała wąskie gardła. Potem zadaniem tej piątki jest przełożenie doświadczenia na coraz szerszą organizację.

(Informacja dodatkowa: kaikaku — w produkcji lean radykalna przebudowa fabryki wokół nowej technologii, w odróżnieniu od stopniowych usprawnień kaizen.)

A tam, gdzie takie inicjatywy umierają, prawie zawsze stoi jakiś wiceprezes albo dyrektor, któremu odpowiedź się nie podoba — i zaczyna ją rozwadniać, aż wszyscy wracamy do strefy przyboju i toniemy. Przewaga, jaką macie dziś w dużych organizacjach, jest taka, że większość z nich ma właśnie mandat do zmiany. Więc taki zespół, gdy już powstanie, musi kować żelazo, póki gorące: pokazać działający dowód w kodzie. Im głębiej w filozoficznej debacie „czy to dobre, czy złe dla firmy”, tym gorzej. Im szybciej działające oprogramowanie i pracujący na nim inżynierowie, tym lepiej. A piękno tej pracy jest takie, że na miejscu każdy może być bardziej kreatywny — ludzie zwykle kochają ją po drugiej stronie, choć po drodze jęczą: „a ja tak lubiłem programować, jak programowało się dwa lata temu”.

Scott: Widziałeś jakąś dużą firmę, która to chociaż zaczęła?

Adam: Widziałem takich, którzy zaczęli. Nie widziałem nikogo, kto skończył.

I to samo zresztą wśród moich rówieśników. Pół roku temu odbierałem średnio trzy telefony tygodniowo od znajomych, których firmy właśnie na tym kulały. Ja miałem przywilej zmagać się z tym bez klientów na karku; kumple z prawdziwymi organizacjami i prawdziwymi klientami dzwonili do siebie nawzajem i rozmawiali o kryzysie egzystencjalnym, który wszyscy przeżywaliśmy. Nadal jesteśmy w fazie „wszyscy próbujemy to rozgryźć”, ale już zaczynamy sobie przekazywać, co działa, a co nie — z czasem doprowadzi nas to do wspólnego języka i jasności co do właściwych technik. Jesteśmy w fazie odkrywania, nie w fazie „problem rozwiązany, wszyscy umieją, tylko ty nie słuchasz”. Nie mamy nawet wystarczającej liczby eksperymentów, by wiedzieć, co działa.

Co z dziesięcioma i pół tysiąca inżynierów?

Wes: Masz kciuk dokładnie na tym pulsie, a ja nie mogę przestać myśleć o gigantach typu LinkedIn. Właśnie sprawdziłem: mają 10 500 inżynierów. I pewnie to pytanie, którego ludzie nie lubią zadawać: co oni z nimi zrobią? Skoro każdy pracuje dziesięciokrotnie szybciej — da się w ogóle budować coś, co wymaga tylu ludzi? Czy po prostu będzie ich mniej?

Adam: Nie wiem. Nikt nie wie. Zgaduję tak: odpowiedź brzmi „tak, dadzą radę” — tylko nie wiemy jeszcze, co to byłoby. Bo co się dzieje, gdy system zmienia się o rząd wielkości? Wszystko pęka. Siedząc tam, gdzie jesteśmy, pytasz: co tych dziesięć tysięcy ludzi w LinkedIn mogłoby w ogóle zrobić? Dużo. Jest mnóstwo rzeczy, których nie znoszę w LinkedIn…

Wes: Na przykład boty.

Adam: …ale jest też mnóstwo rzeczy, których oni sami w nim nie lubią. Założę się, że gdy je naprawią, znajdziemy kolejne pomysły na rzeczy, które chcielibyśmy, żeby robili — i oni będą chcieli je robić. Historia automatyzacji — bierzmy ostatnie tysiąc lat, cyfrowej i nie — zawsze szła tak samo: otwierała moce przerobowe. Za każdym razem słyszysz „to będzie koniec tego zawodu”, a wychodzi, że zawód się zmienia i robimy w nim więcej, bo inaczej ograniczałby nas wyłącznie popyt. A górnej granicy popytu na oprogramowanie jak dotąd nie udało się znaleźć. Oprogramowanie jest nieskończone — przy dostatecznej mocy obliczeniowej i energii można je produkować bez końca; to nie surowiec, który się wyczerpuje. Wysłanie przez LinkedIn dziesięć tysięcy razy więcej zmian nie sprawia, że LinkedIna zostaje mniej — to nie las, który można wyciąć. Nie znam górnej granicy ludzkiej programistycznej pomysłowości. Na razie robi się tylko dziwniej i szybciej — i pewnie tak zostanie, a coraz większa część systemu będzie musiała się do tego dostosować. Nie wiem, gdzie to LinkedIna zaprowadzi. Pewnie w dzikie miejsca, bo wszystko, czego nie dało się zrobić z braku ludzi albo umiejętności, właśnie znika. Nie mam pojęcia, jakie są praktyczne granice. Może ich nie ma. Mogliby jutro postanowić napisać nowy system operacyjny pod LinkedIn — stawiam, że prototyp mieliby w tydzień.

Scott: A całą platformę przepiąć w dwa.

Adam: To szalone.

Scott: Siedzimy i patrzymy na tę wibecodowaną wersję pakietu Adobe, która wyszła niedawno — i jest lepsza od oryginału obecnego na rynku od dwudziestu ośmiu lat. Znacznie lepsza. I znowu mam to samo uczucie co tydzień temu: kiedy to się w końcu skończy?

Adam: Nigdy. A co ciekawe — nikt nie zrobił mi jeszcze lepszego. To znaczy: przebudowali Adobe Creative Suite. Fajne, bo pakiet był fajny i bo dawniej nie miałem do niego dostępu, bo był skomplikowany i drogi. Ale prawdziwie fajne będzie, gdy zaczniemy pytać: czy to wciąż ten kształt, w jakim chcę z tym pracować? Czy tak chcę myśleć o tym problemie? Bo nie sądzę.

Scott: Lepsza i szybsza wersja dokładnie tego samego rzadko bywa odpowiedzią na pytanie, jak powinna wyglądać następna.

Adam: No właśnie. I to jest ekscytujące w fabrykach: potraktuj je jako medium twórcze. Zamiast stać w miejscu „super, że AI robi obrazki”, „super, że odbudowa pakietu Adobe w tydzień, gdy doleje się tokenów” — okej, wszystko super. A teraz pokaż mi nową rzecz. Co zbudujesz takiego, czego nikt wcześniej nie mógł?

Przykład z Swamp: mam wspólnika, pracujemy razem ponad dekadę, i wołamy ze sobą arkusz kalkulacyjny, w którym robimy całą firmową rutynę — uzgodnienia, rezerwacje przychodów, prognozy. Rzeczy, które w startupie po prostu trzeba odhaczyć. Zbudowałem mu aplikację — małą fabryką — która robi prognozy i umie się sama rozszerzać. On teraz używa Claude’a, ale nie jako programisty, tylko żeby tę aplikację rozszerzać w poprzek wszystkich naszych systemów: gada z NetSuite, dobija do CRM-u, ciągnie rezerwacje i wyniki rzeczywiste, buduje interfejs dokładnie taki, jaki chce — i na tym raportujemy przed zarządem. Wygląda na drobiazg, ale to najlepsza rzecz, jaką w życiu dotykał; nie może się nacieszyć. Nie sądzę jednak, żeby mógł wam ją podrzucić — bo jest przyspawana do Swamp Club, do naszych wyborów. I to jest ta warstwa personalizacji, najświeższy kraniec: co, gdyby oprogramowanie stawało się mniejsze, a nie większe?

Scott: O, ja buduję mnóstwo takiego osobistego oprogramowania — ostatnie pół roku, a szczególnie te dwa miesiące. Tylu drobiazgów, które idealnie trafiają w moje potrzeby. Zrobiłem cały agentowy system zadań spięty z urządzeniem sprzętowym — ludzie proszą o open source i pewnie mógłbym, ale to jest tak bardzo moje, idealne dla mnie. Dziwne. Dzikie.

Adam: I żeby na chwilę wrócić do Swamp — właśnie dlatego budujemy prymitywy. Często mówimy o tym jako o platformie elementarnych klocków, których potrzebujesz, żeby takie rzeczy budować szybciej. Jakie klocki byłyby potrzebne do aplikacji osobistych? Jak wyglądałby pakiet Adobe, gdyby stał na elastycznym fundamencie, na którym to ma sens? Fabryki oprogramowania to przykład dopasowania software’u do właśnie takiego kształtu. Swamp sam z siebie wysyła coś w duchu fabryki: umie rozkładać zadania na problemy automatyzacyjne, więc ty myślisz tylko o intencji. A jak to wyglądałoby dla Adobe? Dla Riverside, na którym się teraz nagrywamy? Nie wiem. Ale chcę to zobaczyć. I będzie dziwnie. Jestem na tak.

Wes: Jak opowiadasz, ja myślę o swoich automatyzacjach. Mam taką do montażu podcastu mojej żony: używa Claude’a przez MCP, Pythona, rozpoznaje mówców po częstotliwości głosu, wyciąga transkrypcję — i uruchamiam to ciągle, powtarzalnie. A przecież robiłem to ręcznie w liniowym edytorze wideo od niepamiętnych czasów. To, że ten kształt się zmienił i dał się zapętlić, jest bezcenne.

Testy w erze AI: blackbox tak, TDD niekoniecznie

Wes: Chciałbym jeszcze wyciągnąć z ciebie zdanie o testach, zważywszy na twój rodowód. Słyszymy bez końca, że AI będzie pisać najgorsze testy, że przechodzenie testów stanie się nieistotne. Co myślisz o AI piszącym suity testowe?

Adam: Testy blackbox — branie produktu takiego, jakim trafi do wdrożenia i użycia, bez żadnej wiedzy o wnętrzu: „czy potwierdzam, że funkcje produktu działają tak, jak mają działać?” — umieszczone poza kontekstem agenta rozwijającego oprogramowanie, są bezcenne. Zwłaszcza że refaktoryzacja nie znika. AI nie sprawia, że przestajesz refaktoryzować; zmienia się tylko to, skąd wiesz, że trzeba. Uczysz się refaktoryzować, bo widzisz te same błędy wracające w tym samym zakamarku produktu — a nie dlatego, że edytując kod, odkryłeś, że jest kruchy. Więc blackbox: dziś bezcenny w sposób, w jaki wcześniej nie był nawet wykonalny. Idąc wstecz: testy integracyjne? Prawdopodobnie nadal w miarę cenne — wiedza, że wszystkie części współgrają, może łapać błędy wcześniej. Historycznie bytowały przy kodzie źródłowym, więc AI potrafi je modyfikować, żeby udowadniać poprawność wnętrzności. Zapewne wciąż użyteczne — łapią regresje wcześniej. A potem schodzimy do testów jednostkowych. (Pewnie pomijam kilka pięter — specjaliści od testów wytkną mi słownictwo.) I tu jest otwarte pytanie, czy wciąż dają wiele wartości. Nie widzimy, żeby AI często pisało kod funkcjonalnie błędny. A skoro nie wpatrujemy się we wnętrza, testy jednostkowe nie pomagają mi podnosić poprzeczki jakości. Ta pętla — myślenie o teście przed napisaniem kodu, jak w programowaniu sterowanym testami — pętla między przemyśleniem efektu metody a jej implementacją — AI jej po prostu nie potrzebuje. Był niezły artykuł na blogu Thoughtworks: sprawdzali, czy proszenie agentów o TDD poprawia wyniki. Pogorszyło. Wyszło gorzej niż nie robić tego wcale. Czyli czy taka suita jest użyteczna — pytanie otwarte. Moje przypuszczenie: bardziej w niektórych językach. W TypeScripcie — bardzo, bo szybki feedback z typów łapie problemy od ręki. Rust podobnie: wspaniały język do refaktoryzacji, system typów wyłapuje to, co w językach bez silnych typów łapaliśmy testami jednostkowymi. Może w słabo typowanych językach nadal chcę testy jednostkowe, a w mocno typowanych — obchodzi mnie to mniej. Musimy wspólnie poeksperymentować. W Swamp nie jesteśmy gotowi skasować wszystkich testów jednostkowych — ale jesteśmy niedaleko. Niczym by mnie nie zdziwiło, gdyby Paul Stack, odpowiedzialny u nas za produkt i inżynierię, w ciągu najbliższych tygodni skasował je wszystkie jako eksperyment. Przez piętnaście lat jako CTO na takie coś mówiłem: „tak, nie, tego nie robimy”. Dziś: „nie wiem, może będzie git”. W najgorszym razie każemy agentowi napisać je od nowa — i znowu będą. Możemy dosłownie uruchomić pomiar i sprawdzić, czy regresji przybyło, czy ubyło. I jako branża właśnie to zrobimy. Blackbox — na pewno, super wartościowy. Jeśli go nie masz, a zmierzasz ku fabrykom: zbuduj najpierw suitę blackbox, żeby refaktoryzacja była bezpieczna — wtedy i budowa fabryki jest bezpieczna. I od tego można się cofać dalej.

Scott: Jak w fabryce walidować to zaufanie bardziej deterministycznie? Wiem, że zależy to od języka i systemu, ale jakie ogólne pojęcia ludzie powinni mieć w głowach, żeby mieć pewność, że to, co wychodzi, jest dobre?

Architektura jako słownik, który agent już zna

Adam: Blackbox — nie będę już katował. Druga rzecz: przez większość kariery kpiliśmy z architektów oprogramowania. Człowiek z takim tytułem w banku — „ble”, „architekt-astronauta”, „wieża z kości słoniowej” i tak dalej. Tymczasem architektura daje ci słownik utartych wzorców, których stosowanie daje kod giętki wobec wymagań — to znaczy łatwy do zmiany, im lepiej rozumiemy domenę. Uczę się o problemie, coraz lepiej wiem, jak chcę, żeby software działał — i łatwo go tak zmienić? Historycznie architektura wyłaniała się w zespołach: inżynierowie budowali dom, ustalając jego kształt po drodze, a po fakcie opisywali go sobie tak, jakby zaprojektowali go z góry. Teraz naprawdę projektujesz z góry. Chcę dom — a pytanie, jak powinien być zbudowany, czyli jaka jest jego architektura, to pytanie, na które musi odpowiedzieć agent. Zostawiony samemu sobie jest w tym zły, bo wybiera to, co akurat przyjdzie mu do głowy. To jest część sedna schematu „postawiłem coś dużego na czystej intuicji i się zawaliło”: nie było spójnej architektury, kod nie był giętki, był kruchy i każda nowa funkcja robiła gorzej. W świecie fabryk musisz zdecydować się na architekturę. Jeśli jej nie masz — polecam projektowanie zorientowane na domenę, bo daje bardzo bogaty słownik, a agent już go zna. Wasze agenty przeczytały książkę o DDD. Powiedz „ten program potrzebuje warstwy antykorupcyjnej między tymi dwoma komponentami” — agent wie dokładnie, o co chodzi. A jeśli tę architekturę wyrazisz w skillu — „tak u nas wygląda warstwa antykorupcyjna, w moim kodzie, w moim języku” — naśladuje wzorzec i szuka innych jego przykładów. Dla słuchaczy: warstwa antykorupcyjna to dwa API po bokach i tłumacz pośrodku, dzięki któremu prawa strona nie musi przejmować się zmianami lewej. Fakt, że mogę wypowiedzieć to jedno zdanie i każdy, kto zna DDD, kiwa głową — to cała różnica między posiadaniem architektury a jej brakiem. I to jest krytyczne dla zaufania do systemu, bo architekturę trzeba umieć wyrazić z góry. Napisz skill „architektura oprogramowania” i sprawdzaj każdy wygenerowany kod względem niego: „czy to jest architektonicznie zgodne z moimi zasadami?” Zasady będą unikalne dla aplikacji, języka, domeny — ale ten proces konsekwentnie zwraca dobre wyniki.

Druga rzecz: przeglądy adwersarskie dla wymagań leżących poza architekturą. Przykład: prowadzisz SaaS-a i chcesz zgodności z WCAG, do poziomu AAA włącznie. Napisz skill opisujący te standardy albo znajdź gotowy; skill może być bardzo chudy, bo gdy zapytasz agenta o standard, sam wyrecytuje go w miarę sensownie. Ale konkretne reguły, które mają być zawsze prawdziwe — na przykład „nigdy nie pozwól, żeby dwa kolory na stronie były zbyt blisko w odcieniu”, o czym żaden inżynier nigdy nie myślał — kodujesz wprost. I nagle każda zmiana przechodząca przez system jest oceniana pod kątem dostępności; jeśli obleje — wraca do przerobienia. A za każdym razem, gdy odkryjesz w produkcie nowe miejsce, w którym nie spełnia oczekiwań, wracasz jako inżynier i majstrujesz przy fabryce. Nie mówisz „te roboty AI są głupie”, tylko: „co zmienić w tej maszynie, żeby ta cała klasa błędów wpadała częściej?” Bo nie wpadnie zawsze — wpadnie w jakimś większym procencie niż dotąd. I znów majstrujesz. I przyjdzie nowa technologia, i znów zmienisz. Przykład z dostępności: jeśli zmiana nie ruszyła ani linijki kodu widocznego dla użytkownika, nie muszę odpalać testów dostępności. Używam modelu klasy Jev: „oto zmiana, oto lista kryteriów, po których oceniam jakość — które są istotne przy zmianie tego rodzaju?” I nagle masz system adaptacyjny, o jakim wcześniej nie potrafiłeś nawet pomyśleć. I mówię to po to, żeby wam wpoić: to jest inżynieria. Zajmujesz się inżynierią systemu, którego zadaniem jest zbudowanie programu, jaki chcesz mieć po drugiej stronie. To ruch dziwny, bo przestałeś budować rzecz, którą chciałeś mieć, a zacząłeś budować maszynę, która rzeczy buduje — ale to nadal inżynieria. I wracając do pytania Wesa, co porabiają wszyscy inżynierowie: człowieku, jest mnóstwo inżynierii w budowaniu maszyny, która buduje maszynę. Po prostu przeniosła się o piętro wyżej. Więc konkret na dziś: skille architektoniczne — zwłaszcza na zielonym polu, ale też w istniejącym kodzie, bo jakąś architekturę pewnie już masz; zapisz ją i jej słownik, a okaże się, że potrafisz dopasaować system do tej architektury w sposób wcześniej niemożliwy — byle konsekwentnie. A potem pracuj nad maszyną za każdym razem, gdy znajdziesz nową klasę błędów. Odpowiedź jest zawsze ta sama: wróć, napraw maszynę, ulepsz maszynę.

Skille jako kawałki osądu w jednej całości

Scott: Cieszę się, że padło „zrób z tego skill”, bo słyszę już komentarze: „czemu nie zrobić skilli ze wszystkiego?” — a to nie jest zastępowanie skillów, tylko dokładanie.

Adam: Tę ewolucję widzę tak: na początku ery patrzyliśmy na duże modele językowe i mówiliśmy — będą coraz mądrzejsze, więc będziemy rzucać w nie coraz większymi garściami i wielka maszyna sama to jakoś ułoży. Czego się nauczyliśmy? Po pierwsze: nie układa tego zawsze w sposób niezawodny i dobry. Po drugie: to strasznie drogie. Potrzebujemy skilli, które opisują miejsca, w których wnosimy osąd, gust, rozumowanie — i w których dobieramy właściwy kontekst we właściwym momencie, żeby uzyskać właściwy efekt danego kawałka procesu. Ujmijmy inteligencję jako element systemu — i dopiero wtedy da się zbudować fabrykę, której można ufać. Bo jako inżynier pytam: jakie są wejścia tego kawałka osądu? Jakie wyjścia? I jak mierzę, czy wyjścia są poprawne? Dobry przykład: „czy spełniają standardy dostępności?” — to w istocie suita testowa opisująca dostępność; co prawda suita, która nie zawsze ma rację, bo stosuje osąd z mojego skilla — ale o rząd wielkości lepsza niż cokolwiek, co mieliście wcześniej. Swamp to pierwsza rzecz, jaką wydałem, ze stu punktami w Lighthouse — narzędziu Google do audytu jakości stron. Kto w ogóle miał kiedyś setkę? A Swamp ma, bo mam skill adwersarski, który mówi: nie pozwól spaść. Więc nie spada.

Scott: Gdyby ludzie spojrzeli na to w ten sposób, od razu by zrozumieli: fabryka nie istnieje po to, żeby wyrzucać w świat maksimum kodu. Jest po to, żeby pilnować ram, w których powstaje kod dobry — działający. Chcesz budować świetne produkty, a nie samą objętość.

Wes: Ale objętość potrafi zrobić chore efekty. Jak już to masz, może być zakręcone.

Adam: I jeszcze jedno, ważne: wszystko to jest nowe. Ja mam przywilej — prowadzę własną firmę, zakładam startupy, więc mogę pływać w tych wodach, zajmować się tymi problemami, spotykać się z wami; moja rola to zbierać informacje, destylować je dla innych i próbować budować dobre produkty. Ale to działa nie dlatego, że jestem mądry — dlatego, że my jesteśmy mądrzy. Ty coś zbudowałeś, Wes powiedział „a co będzie, jak to złożę w Pythonie i zrobi się trochę lepiej”, ja na to „a co, gdyby tak”, ty „podoba mi się, a gdyby jeszcze tak”… Ta rozmowa w wielkiej skali — tak odkrywamy wszystkie te wzorce. A jeśli jesteś w branży nowy, nie wiesz, że tak to działa, bo nie przeżyłeś tego, co tak powstało. Nie pamiętasz, że internet nie istniał, dopóki go nie zrobiliśmy. Że decyzje, z którymi dziś żyjesz jak z nieuniknionych, nie były nieuniknione — to była nasza gadka, podczas której coś wykombinowaliśmy. I dokładnie w tej fazie jesteśmy dziś. Tylko że laboratoria są tak wielkie, technologia tak dziwna i podana w tak pokręconym opakowaniu, że przestraszyliśmy się na tyle, iż przestaliśmy po prostu siedzieć razem jak inżynierowie i pytać: „a gdyby zbudować to inaczej? a gdyby spróbować tak?” Wchodzimy właśnie w fazę wymiany tych doświadczeń — i to ona pcha wszystko do przodu. Całą moją wiedzę o fabrykach znam stąd, że siedzę na Discordzie z dziesiątkami ludzi budujących fabryki i mówimy sobie nawzajem, co działa. „Próbowałem tego — działa. Próbowałem tamtego — nie. Zrobiliśmy tak — była masakra.” Im więcej tego robimy, tym szybciej to ogarniamy i tym szybciej wychodzimy z tej paskudnej strefy przyboju.

Laboratoria też nie wiedzą

Scott: Adamie, tłumaczysz to znakomicie. Nie mam więcej pytań z listy. Wes, coś ci zostało?

Wes: Nie, wyszedł świetny odcinek. Dzięki, że jesteś.

Adam: Cała przyjemność po mojej stronie. I szczerze: to, co robicie, to prawdziwa służba — nie dlatego, że mnie zaprosiliście. Służycie swojej wspólnocie, a rozmowa w stylu „jak to robimy, jak się z tego uczymy, dokąd to zmierza” — to jest miejsce, do którego musimy dojść. Bo zdarzyło się trochę niepotrzebne oddawanie władzy: inżynierowie mówili „no nie wiem, chyba jestem niewolnikiem Claude’a, chyba teraz tylko wpycham prompty”. Nie. Absolutnie nie. Idź do laboratoriów i zapytaj: „umiecie to zrobić?” Nie umieją. Nie są w tym lepsi od nas, bo to my wiemy, jak działają nasze systemy. I nic z tego, że to oni wymyślili AI — z faktu, że stworzyliście sztuczną inteligencję, nie wynika, że znacie LinkedIna. Albo JP Morgan Chase. Albo Swamp Club. To my jesteśmy tymi, którzy wiedzą. Więc to my musimy to zrobić.

Wes: Spójrz na te laboratoria — rzucają produktami w ścianę, bo mają nieograniczone tokeny, ograniczoną inżynierię i nieograniczone pieniądze — a nadal nie wiedzą, czym ma być produkt. Z kodowaniem trafili; z agentami osobistymi dopiero kombinują. Inżynieria software’u nie jest teraz trudną częścią. Trudne jest wymyślenie, co to właściwie jest.

Adam: I to jest dar dla inżynierów na całym świecie. Zresztą zawsze tak było, tylko trzeba było mieć to gdzieś zapisane w głowie. Zbierasz kapitał ryzyka, zawsze padnie: „a czemu tego po prostu nie zrobi Google?” No nie wiem, stary. Mogą zrobić, co chcą — jeśli zechcą mnie zniszczyć, zniszczą. Gdy obrócą na Swamp Club złym okiem Saurona i powiedzą „ten Adam ma to, czego chcemy” — po prostu wezmą, bo cóż ja mam? Ale mam to: potrafię to robić. Mogę do was przyjechać i wspólnie wymyślić, jak to wygląda w praktyce. I właśnie tak znajduje się świetne produkty — i właśnie tak pracują dobrzy inżynierowie. To jest złoty wiek możliwości. I dlatego sprawa fabryk jest ciekawa: przesuwa nas ku pytaniu, jak być inżynierem w tej erze. Bo frajda bycia inżynierem jest ogromna — zawsze była i jest nadal, gdy dopasowujesz się do ograniczeń swojej epoki. Gdy nie utknąłeś.

Scott: No właśnie. Dzięki, stary. Przechodzimy do „sick picks” i wtyczek — sick pick to cokolwiek, co daje ci teraz radość: media, przedmiot, cokolwiek. Masz coś?

Sick picks i wtyczki

Adam: Mam dwie rzeczy. Przesiadłem się na Della XPS 14, nowszego, z Intelem Panther Lake, na Linuksie — i wszystko po prostu działa. To daje mi prawdziwą radość.

Scott: Serio? To ten model? Jaka dystrybucja?

Adam: Manjaro. To bardzo blisko Archa, na którym i tak siedziałem — Arch z Hyprlandem i całym tym zestawem. Wszystko zrobiło się niebywale dopracowane — czysta przyjemność. I wskazuje palcem na nową przyszłość: otworzyć Claude’a i powiedzieć „napraw mi laptopa”. Rozkosz.

Druga rzecz: kochająheavy metal — tego szorstkiego, wkurzającego. I znowu wróciłem do Lorna Shore. Najnowszą płytę przespałem, a przed paroma dniami miałem olśnienie w samolocie: o nie, ta płyta jest świetna, ja po prostu nie byłem w głowie, żeby ją usłyszeć.

Scott: Nie znam Lorna Shore — muszę nadrobić. A wtyczki?

Adam: Wejdźcie na Swamp Club. I koniecznie wstąpcie na naszego Discorda. Jeśli po tej rozmowie brzmi dla was dobrze przebywanie w pokoju pełnym ludzi myślących podobnie i coś budujących — ten serwer jest pełen ludzi, którzy próbują budować właśnie w ten sposób, i bez przerwy dzielą się tym, co u nich. Jest z tego ubaw. Więc te dwie rzeczy: Swamp Club i Swamp Discord. Bo w środku siedzi właściwa magia — niezależnie od tego, czy skończycie na Swampie, czy nie: potrzebujecie obok siebie ludzi, którzy pomagają ci żeglować w tym świecie do przodu.

Scott: Powiem tak: jestem na ze stu serwerach Discorda i powinienem to posprzątać. Ten jest jedynym, na którym naprawdę bywam. Inne mają dziwaczne wewnętrzne reguły prowadzenia rozmów albo za dużo wiadomości, ludzie wpadają tu i ówdzie. Tu dostaję konsekwentnie najwięcej — jak zapytałem „jak używacie dziś Jev?”, to właśnie tam dostałem najlepsze odpowiedzi. Sami spróbujcie: wiem, że nie potrzebujecie kolejnego Discorda, ale to naprawdę świetne miejsce do rozmów o takich sprawach. Siedzi tam mnóstwo mądrych ludzi z dobrymi opiniami.

Wes: To tyle. Dzięki, że wpadłeś, i wam wszystkim dzięki za słuchanie.

Adam: Dzięki!