O czym jest ten film
- Praca z agentami kodującymi przeszła z ery „jeden agent w pasku bocznym VS Code” (2024–2025) do modelu zdalnych, asynchronicznych agentów działających w sandboksach.
- Ball twierdzi, że różnice między czołowymi modelami przestają mieć znaczenie — „modele są martwe” w tym sensie, że nie trzeba już ich pilnować linijka po linijce.
- Najważniejszy w jakości wyniku jest input — informacja, którą podajesz w promptcie i w bazie kodu — a nie dobór modelu czy mikrozarządzanie stylem.
- „AI slop” bierze się głównie od ludzi bez pomysłu na produkt, nie z samego AI; w zespole AMP 99% kodu pisze AI, a mimo to produkt uchodzi za dopracowany.
- Stary workflow (backlog, estymacje, osobne CI) trzeba przemyśleć od podstaw — agenty i tak już uruchamiają testy w izolowanym środowisku.
- Wartość przenosi się z „kodu jako takiego” (staje się tani) na wiedzę o tym, co i po co budować.
- Przyszłość produktu: nikt nie powinien już wypełniać formularzy — wszystko, co robi człowiek, powinno dać się zlecić agentowi; panele admina zastępuje edycja kodu przez agenta.
- „Emacsyfikacja” oprogramowania — forkujesz cudzy program, każesz agentowi dopasować go do siebie i używasz własnej wersji, bez wkładu z powrotem do upstreamu.
- Prezentacja setupu AMP: orby (zdalne sandboksy przypięte do wątku rozmowy), Puck (meta-agent sterujący innymi agentami), komunikacja agent-do-agenta, multiplayer.
- Prognozy Balla: lokalny development zanika, granica między modelami się zaciera, nie wiadomo jeszcze, jakie oprogramowanie przetrwa.
Redakcyjne tłumaczenie
Wstęp
David Ondrej: To jest Thorsten Ball, inżynier-założyciel przy AMP i autor słynnych książek o Go. W tej rozmowie mówimy o tym, dlaczego wszystko potrzebuje interfejsu wiersza poleceń, czy fundamenty informatyki wciąż mają znaczenie i dlaczego 99% „slopu” pochodzi od ludzi, a nie od AI. Jeśli chcesz być na froncie kodowania z AI, obejrzyj do końca.
Dlaczego nie wolno stać w miejscu
David: Ludzie, którzy wciąż tkwią w erze AI z lat 2024–2025 — jak mają przyjąć nowy sposób pracy?
Thorsten: Jedna rzecz, którą robimy przy AMP od samego początku, to że nie możemy stać w miejscu. Ostatnie półtora roku pokazało, że mieliśmy rację. Moglibyśmy zarobić dużo więcej pieniędzy i zdobyć dużo więcej użytkowników, gdybyśmy trzymali się sposobu pracy, który był standardem na początku 2025 roku. No wiesz: masz jednego agenta w pasku bocznym VS Code, klienci korporacyjni chcą porządnego systemu uprawnień, żeby agent uruchamiał tylko określone komendy, i chcą atrybucji — żeby każda linijka kodu dała się przypisać do jednej instancji. To wszystko.
Gdybyśmy to zbudowali, dostalibyśmy pewnie rok kontraktów korporacyjnych i zarobili na tym kupę pieniędzy. Ale po roku konkurencja byłaby już zupełnie gdzie indziej. Dlatego przy AMP od początku powiedzieliśmy: musimy tak zoptymalizować firmę, zespół, bazę kodu i produkt, żeby móc poruszać się szybko i zrzucać balast, kiedy uznamy, że front znów się przesunął.
Jeśli zajrzysz na naszą stronę z aktualnościami (Informacja dodatkowa: ampcode.com/news), memem stało się to, że nieustannie zabijamy funkcje, bo uznajemy, że przestały być potrzebne. Robimy to bardzo dużo. Konkretny przykład: najpierw mieliśmy rozszerzenie do VS Code i TUI (Informacja dodatkowa: TUI — interfejs tekstowy w terminalu). To był ubiegłoroczny standard, pamiętasz? Wszyscy mieliśmy wtyczki do VS Code. A potem powiedzieliśmy: nie, rozszerzenie do VS Code jest martwe. Nie ma sensu trzymać tego przy edytorze. Kto dziś w ogóle ma otwarty edytor? TUI nie jest dla każdego, ale nie przywiązujmy się do edytora.
Gdybyśmy zostali przy starym, zatrzymalibyśmy użytkowników, którzy lubią siedzieć w swojej strefie komfortu — i wtedy pytanie brzmi: czy budujesz sobie echo chamber? Więc powiedzieliśmy: zabijmy to. Myślę, że najczęściej ludzie doceniają, że napieramy. Mamy wielu klientów, którzy właśnie za to lubią AMP. Pytają nas: „Chłopaki, jaka jest meta? Czego używacie? Jaki model? Jak promptujecie?”.
David: No bo to jest research, prawda? Robicie research, nie tylko software.
Thorsten: Dokładnie. Oficjalna nazwa firmy to AMP Frontier Corporation. Jedną z naszych zasad jest to, że mamy zostać na froncie. Ludzie płacą nam pieniądze właśnie po to, żeby nie musieć wybierać, co idzie do trybu high, ultra czy medium ani na jakim poziomie myślenia ma pracować model. Dla większości to strata czasu — biegać dookoła i zastanawiać się: „O, użyję GLM-a”. Powinieneś raczej myśleć o tym, co chcesz zrobić, gdzie żyje informacja, jak przyjazna agentom jest twoja baza kodu — i skupić się na dowożeniu, a nie grzęznąć w szczegółach.
Koniec z backlogiem — po prostu odpal agenta
David: Zacznijmy od backlogu. W dawnych czasach wszystko lądowało w backlogu, a teraz możesz po prostu odpalić nowego agenta, nową sesję, i błąd zostaje naprawiony w dziesięć minut. Zamiast odkładać coś dla siebie albo dla kogoś, a potem pamiętać o tym przez kilka tygodni, robisz to od razu — wtedy, kiedy masz kontekst i energię.
Thorsten: Agent nad tym pracuje i jest zrobione. To jedna rzecz. Ale myślę, że większym wyzwaniem jest to, że każda kolejna generacja modeli tak wiele zmienia, że musimy na nowo rozgryzać, jak w ogóle pracujemy — jak wyglądają workflowy, jak wygląda interfejs użytkownika.
David: Zgadzam się w stu procentach. Aż mam wrażenie, jakbym ci zapłacił, żebyś to powiedział.
(Informacja dodatkowa: w tym miejscu w nagraniu pojawia się blok sponsorski o Supabase i ich „agent skills” — otwartoźródłowej wtyczce, która ma sprawić, że agent poprawnie korzysta z bazy, m.in. pilnuje polityk RLS. To materiał reklamowy, pominięty w redakcji merytorycznej.)
„Modele są martwe” — przestań je niańczyć
Thorsten: Mówiłem w zeszłym tygodniu, że modele są martwe w tym sensie, że Fable jest całkiem niezły, GPT-5.6 jest całkiem niezły, ale jesteśmy już na poziomie, na którym nie muszę patrzeć modelowi na ręce i mówić „nie zmieniaj tego pliku” albo „nie rób tamtego”. Uważam, że to bliskie zarządzanie tym, co robi pojedynczy model, daje już malejące korzyści. Można modelom ufać dużo bardziej, niż ludzie to robią.
Jeśli ktoś ma problem z tym, że model „nie użył camelCase” albo czegoś podobnego, to powinien się cofnąć i przemyśleć inżynierię oprogramowania. Bo tak to formułuję od kilku tygodni: dostaniesz przycisk, którym możesz przywołać Johna Carmacka piszącego za ciebie kod. (Informacja dodatkowa: John Carmack — legendarny programista, współtwórca Dooma i Quake’a, symbol światowej klasy inżyniera.) Ten John Carmack nie odzywa się, dopóki się go nie zagadnie. Musisz go obudzić albo kazać innemu Carmackowi go obudzić. To osobliwe — nie chodzi sobie i nie odkrywa nowych rzeczy, ale nie zrobi błędu składniowego, nie pomyli się w wyrażeniu. Zrobi dokładnie to, o co poprosisz.
Ale wtedy musisz zadać sobie pytanie: co ja właściwie chcę zrobić? Ogromna część rozwoju oprogramowania kręciła się wokół tego, jak coś zrobić — jak to napisać, jak najlepiej ustrukturyzować, jak podejść do problemu. Mnóstwo rzeczy w programowaniu z tego wynikało. I myślę, że sporo z tego przestało być użyteczne. Nawet takie rzeczy jak mój własny slash-command do review — modele są na tyle dobre, że jak poprosisz Fable, żeby zrobiło review, albo odpalisz drugiego agenta i każesz mu to sprawdzić, to działa. Ale malejące korzyści.
Najważniejsza liczba w równaniu „jak dobre są wyniki” to informacja, którą podajesz na wejściu. To nie kwestia szczegółów. To kwestia: OK, czy to jest naprawdę zagwozdka? Chcesz Johna Carmacka czy jego młodszego braciszka?
Przemyśl workflow od podstaw
Thorsten: Uważam za szaleństwo, że ludzie biorą agenty kodujące i przykręcają je do starego sposobu pracy. Ktoś zgłasza błąd, a ty go gdzieś parkujesz, aż komuś się wyda, że ma czas się nim zająć — i co wtedy? Wtedy odpalają agenta. To dlaczego nie odpalić tych agentów optymistycznie z góry, nie zaparkować gdzieś rezultatów, a potem przejrzeć poprawki i ocenić, czy są dobre? Nie musisz szacować, czy coś jest warte zachodu, skoro wszystko dzieje się w tle, kiedy śpisz. Po prostu to zróbmy.
Mnóstwo się zmieniło, stare założenia już nie są prawdziwe. Agent i tak już to robi, już uruchamia testy, już siedzi w sandboksie z izolowanym stanem. Jeśli każesz mu uruchomić wszystkie testy i on je uruchamia, to naprawdę zamierzasz wypchnąć to gdzieś indziej i kazać temu chodzić przez dziesięć minut, bo masz osobny system CI, który robi w zasadzie to samo? Agenty już uruchamiają za ciebie testy. Trzeba przemyśleć mnóstwo rzeczy od pierwszych zasad. Prawdopodobnie po prostu wybierz dobry model i skup się na dowożeniu, zamiast dłubać przy różnych modelach. Jasne, jeśli robisz to w wolnym czasie dla zabawy — proszę bardzo. Ale nie sądzę, żeby tu leżała wydajność ani dobre wyniki.
„Slop” pochodzi od ludzi, nie od AI
David: Ostatecznie chodzi o to, żeby wiedzieć, co zbudować, a potem to zbudować. Mam taką kontrowersyjną opinię — i chyba coraz mniej kontrowersyjną — że kiedy ludzie mówią „AI slop”, to większość slopu bierze się z tego, że ludzie nie mają dobrego produktu. Po prostu dzięki AI mogą budować te śmieciowe produkty szybciej.
Thorsten: Może to przechwałka, ale spójrz: ludzie mówią, że AMP ma gust, że jest dopracowane, że mamy dobre skróty klawiszowe, że mamy „taste”, że craftujemy. A fakt jest taki, że z tego, co tu widzisz, 99% jest napisane przez AI. Nikt w naszym zespole nie pisze już kodu ręcznie — przynajmniej nie tak dużo.
Zrobiłem wewnętrzną ankietę jakieś dwa tygodnie temu: „Ile kodu jest waszym zdaniem pisane przez AI?”. Dałem trzy opcje: ponad 99%, między 90 a 99%, oraz poniżej 90%. Nawet nie przewidziałem, że ktoś zejdzie poniżej 80%. A wtedy Camden z naszego zespołu — świetny gość — mówi: „Chyba nadal piszę sporo kodu ręcznie”. Ja na to: „Camden, serio? Ile kodu piszesz ręcznie?”. A on: „No jakieś 5%”. Czyli i tak 95% pisze AI.
Wkładam mnóstwo troski w to, co buduję. Ale to są pomysły. Czy uważam, że ta mała ikonka jest źle umieszczona? Czy powinna mieć tooltip? Czy powinniśmy mieć fajną animację? Weź ten animowany orb, który pokazuje się, gdy odpalasz AMP. To, co zrobiła tu AI, to wygenerowanie piętnastu różnych wersji tych orbów w różnych kolorach, przez które mogłem przejrzeć. Powiedziałem: „Daj mi wersję ze znakami Braille’a. Daj wersję z tymi znakami. Daj pięć różnych wersji. Daj osiemnaście różnych kolorów”. A potem przejrzałem je i wybrałem tę, która mi się najbardziej podoba. I ludziom to rezonuje. Użyłem AI, żeby szybciej wyrazić to, co uważam za dobre, bez wykonywania kupy roboty. Gdybym musiał to napisać sam, nigdy bym tego nie zrobił.
Ludzie lubią nasze wpisy z aktualnościami i mówią, że mamy dobre grafiki w tle. To ja, Tim i Brad idziemy tura po turze w Midjourney. To ja czytam „Moby Dicka” i myślę o orbach, a potem próbuję w głowie połączyć „Moby Dicka” z orbem. (Informacja dodatkowa: Midjourney — generator obrazów AI.) Poprośmy ChatGPT o dziesięć wariacji tego promptu do Midjourney, wybierzmy tę, zremiksujmy tamtą. AI pomaga mi iść szybciej, ale ja nadal wkładam w to wysiłek. Jeśli coś jest slopem, to dlatego, że brakuje pomysłów, brakuje inputu, brakuje wiedzy, co chcesz, żeby istniało na świecie — albo brakuje kreatywności.
Jak dziś zakładać startup: zacznij od tego, po co
David: Jak doradziłbyś komuś, kto chce zacząć nowy projekt — powiedzmy startup AI w tym roku — biorąc pod uwagę stan agentów?
Thorsten: Zacznij myśleć o tym, czym ma być ten biznes. Jaki jest twój rynek, kto jest klientem, jak mu służysz, jak generujesz wartość, jak sprzedajesz. Odwróćmy to: powiedzmy, że ktoś jest bardzo zainteresowany zatrudnianiem handlowców i chce założyć startup AI. Po co zatrudniać handlowców, skoro nie wiesz jeszcze, czym jest firma? Z softwarem jest teraz tak samo. Software jako rzecz sama w sobie stał się mniej wartościowy. Mówiliśmy to rok temu w podkaście: open source dostanie po głowie, te grafy kontrybucji przestaną być cokolwiek warte, bo kod stanie się bardzo tani. Teraz dużo bardziej liczy się to, co software robi i ile wartości dostarcza. Brzmi śmiertelnie nudno, ale taka jest prawda.
Ciekawe jest to, że przez ostatnie 20–30 lat większość programistów miała to szczęście, że rzecz, o którą naprawdę dbali i traktowali jako rzemiosło czy hobby, pokrywała się z tym, co jest wartościowe dla biznesu. Facet, który lubi pisać Haskell w weekendy, okazuje się też tym, który potrafi zbudować dobry backend finansowy, bo naprawdę zależy mu na typach i dobrze modeluje takie rzeczy. Ale teraz Fable też jest w tym całkiem dobry.
Widziałem, jak GPT-5.5, gdy poprosisz o migrację bazy danych, mówi: „Zaraz, nie możemy jeszcze usunąć kolumny. Najpierw dodajemy nową kolumnę, wdrażamy to, piszemy do nowej kolumny, czekamy, aż zniknie cały stary kod, i dopiero wtedy usuwamy starą kolumnę”. To jest lekcja, której nauczył mnie starszy inżynier w pierwszych dwóch–trzech latach kariery. Wtedy była to trudna, wykuwana lekcja, której nikt mi tak wprost nie wyłożył. Wydaje się trywialna, ale model robi to w pół minuty. Wszystko jest po prostu szybsze, łatwiejsze i przez to tańsze. Więc pytanie brzmi raczej: co chcesz osiągnąć?
Budujesz dla człowieka czy dla agenta?
David: To pytanie o produkt masz. A druga strona: budujesz dla człowieka czy dla agenta? Bo orby na przykład budujesz dla agentów. Agent chce pełnego komputera, chce móc na nim robić wszystko.
Thorsten: Myślę, że wszyscy się tego dopiero dowiadujemy. Cały software próbuje ustalić, jaka jest przyszłość softu. Pojawiło się kilka pomysłów: wszystko będzie API, albo wszystko będzie CLI i wtedy agenty będą robić za ciebie zakupy. Sądzę, że dużo starego oprogramowania wymrze — pytanie tylko, jak szybko. Czy zmusisz siedemdziesięciolatków, żeby używali agenta do rezerwacji lotu? Nie wiem.
Gdybym miał teraz zbudować od zera nowy produkt pod front, zrobiłbym tak, żeby żaden człowiek nie musiał już nigdy wypełniać formularza. To jest głupie. Wszystko, co człowiek może zrobić, powinien móc poprosić agenta, żeby zrobił za niego na twojej stronie. API może jeszcze tego nie ogarniają, ale byłoby dobrze móc przynieść własnego agenta. Większość ludzi nie chce używać twojego kiepskiego wbudowanego agenta. Fajnie byłoby móc użyć AMP, żeby zrobić za mnie zakupy na czyjejś stronie.
Zabawny przykład. Jest wtorek, a w niedzielę byłem w lokalnym klubie, mieliśmy mały festyn. Dla zabawy zbudowałem z telefonu, w orbie, mały system do zamawiania jedzenia: ludzie składają zamówienie, a kuchnia dostaje zamówienia i może je odhaczać — bo w niedzielę robiliśmy to na papierze. Ktoś zapytał: „Nie zrobiłbyś z tego apki?”. Mówię: „No właśnie mogę”. Więc zbudowałem apkę. Zrobiłem dwa zdjęcia menu — przód i tył — wysłałem do modelu, a on to zbudował. Zrobiłem to w orbie, mogłem udostępnić URL, ludzie mogli wejść i to działało. Szaleństwo.
Ale filozoficznie ciekawe było to, że model zbudował interfejs administracyjny, w którym ktoś mógłby ręcznie przeglądać produkty z menu i poprawiać ceny albo pisownię. Popatrzyłem na to i pomyślałem: nigdy tego nie zrobię. Nie wejdę tam i nie będę używał formularza. Znów użyję AMP w tej bazie kodu. Wyślę kolejne zdjęcie, jak ceny się zmienią, i powiem: „popraw ceny”. Mnóstwo rzeczy związanych z konfiguracją i administracją — rzeczy, które człowiek robił po to, żeby nie trzeba było zmieniać kodu — jest teraz prawdopodobnie łatwiejsze przez zmianę kodu.
Wyobraź sobie zaplecze WordPressa, które zbudowałeś, żeby każdy w firmie mógł dodać wpis na blogu, ze sprawdzaniem pisowni i tak dalej. Gdybyś miał agenta w swojej bazie kodu, mógłbyś powiedzieć: „Oto szkic wpisu, dodaj tę grafikę nagłówkową, opublikuj i zrób korektę”. To jedno zdanie — agent idzie i to robi, bez klikania po interfejsie.
Więc jeśli zaczynasz nową firmę, nową bazę kodu, musisz przemyśleć, jaka jest rola kodu w twoim produkcie. Nie wpadaj w pułapkę myślenia, że stary sposób dostarczania softu jest wciąż wartościowy — bo rachunek się zmienił. Mieliśmy wewnętrzny dokument, chyba zatytułowany „Software is dead, now what” (Informacja dodatkowa: „Oprogramowanie umarło, i co teraz”), właśnie o tym: modele dochodzą do punktu, w którym możesz wymarzyć rzeczy do istnienia — o ile masz życzenia, o ile masz przypadek użycia.
„Emacsyfikacja” oprogramowania
Thorsten: Ktoś napisał wpis na blogu — żałuję, że nie pamiętam nazwiska — o „emacsyfikacji” oprogramowania. W Emacsie (Informacja dodatkowa: kultowy, mocno konfigurowalny edytor tekstu, programowany w dialekcie Lispa zwanym Emacs Lisp) konfigurujesz wszystko, pisząc elisp. Każdy ma własną konfigurację, własne dotfiles, kolekcję plików w Lispie zbieraną przez lata. Jeśli ktoś ma wtyczkę typu fuzzy finder, w społeczności Emacsa typowe jest, że ludzie ją forkują, przepisują i nie oddają zmian z powrotem, bo dostosowali ją tak mocno pod siebie.
Dokładnie to dzieje się teraz. Jest świetna przeglądarka diffów o nazwie Hunk — kawałek naprawdę ładnego oprogramowania. Przestałem go już używać, ale kiedy używałem, sforkowałem go, wskazałem na niego AMP i powiedziałem: „Dodaj motyw Gruvbox dark hard. Dodaj możliwość odhaczania plików w pasku bocznym. Zrób to i tamto. Potem skompiluj i wrzuć do mojego folderu bin w katalogu domowym”. I zrobił to. Miałem własny software. Nie było powodu, żebym oddawał cokolwiek do upstreamu — nie chciałem tego uogólniać, nie sądzę, żeby to było wartościowe dla innych, i praktycznie nie poświęciłem na to czasu. Dwie minuty agenta pracującego w tle. Wziąłem kawałek oprogramowania i zremiksowałem go pod swój przypadek użycia. Myślę, że zobaczymy tego dużo więcej.
Podejrzewam, że będzie mnóstwo wewnętrznego oprogramowania. Przykład z niedzieli: mały klub, dwadzieścia osób, proces „oddajesz zamówienie tutaj, ktoś zapisuje je na kartce, kartka wędruje tam”. Zakodowałem to w oprogramowaniu w jakieś trzy razy po pięć minut w ciągu może dwóch godzin — wyciągnąłem telefon, napisałem prompt, potem „teraz potrzebujemy jeszcze tego”, i pokazywałem to dookoła. Jeśli ludzie zaczną zdawać sobie sprawę, że mogą to robić w firmach, to zastąpi to, co wcześniej było „tym jednym plikiem Excela” albo „tą jedną stroną na wiki”. A promień rażenia tego ruchu może się powiększać, aż ludzie zaczną atakować większe rzeczy: „Chcemy kupić ten software, powiedzmy Riverside, ale nie zależy mi na samym audio, tylko na wideo” — albo odwrotnie: „usuń z apki wszystko, czego nie chcę widzieć, daj mi jej własną wersję”. Myślę, że agenty będą to potrafiły już bardzo niedługo. I pytanie brzmi: co się wtedy stanie z oprogramowaniem?
Dwie zmienne przewagi: umiejętność i budżet
David: Będzie eksplozja tego. To będzie gra o to, kto wie, co zbudować, i kto ma odpowiedni setup. Jeśli sprowadzić to do dwóch zmiennych, to: umieć używać tych agentów oraz mieć budżet, żeby to robić. Jeśli stać cię na wydawanie tokenów i możesz używać czołowych modeli, zmiażdżysz konkurencję. Nie da się wziąć programisty, który nie używa AI — zostanie zmiażdżony przez przeciętnego programistę z AI. Chyba że chodzi o coś super technicznego, gdzie tę wiedzę ma tylko garstka ludzi. Możesz ekstrapolować, gdzie modele będą za sześć do dwunastu miesięcy.
Thorsten: Zgadzam się. Najważniejszą umiejętnością będzie myślenie od pierwszych zasad — faktyczne myślenie, nie techniczne detale. Musisz naprawdę przemyśleć rozwiązanie problemu, rozbicie problemów biznesowych na rozwiązania. Głupi przykład z niedzieli. Ktoś mówi: „Słyszałem, że umiesz teraz budować apki z AI. Mamy zamówienia w kuchni, ktoś robi kreskę na kartce i podaje ją dalej. Zbudujesz nam apkę, żeby ktoś na tablecie kliknął, a wtedy drukuje się kartka, którą podajemy dalej?”. Jako ktoś, kto siedzi w oprogramowaniu od dawna, pomyślałem: OK, mogę to zbudować, zdobyć drukarkę. Ale po co ci drukarka? Czemu zamiast kartki nie dać drugiego tabletu? To myślenie o tym, czym właściwie jest proces, jaki jest workflow, jakie problemy ten workflow rozwiązuje i jak zastąpić to oprogramowaniem — to będzie niesamowicie ważne.
David: Czyli w zasadzie każdy staje się architektem i trzeba tylko być świadomym różnych rozwiązań z różnych branż, żeby mieć właściwy pomysł.
Thorsten: To, co robię, wciąż jest inżynierią — kiedy zastanawiam się, czy przenieść coś do TUI, czy do CLI. Ale błąd, który widzę u ludzi w sieci, to że zawsze biorą za przykład ten 1%. Mówią: „Patrz, Mitchell Hashimoto czyta kod, AI nie jest wystarczająco dobre, żeby rozwiązać jego problem”. (Informacja dodatkowa: Mitchell Hashimoto — współzałożyciel HashiCorp, autor terminala Ghostty przyspieszanego przez GPU.) Mitchell jest jednym z najlepszych programistów na świecie, pracuje nad technicznie wymagającym, pięknym oprogramowaniem. Ale rozejrzyj się, co robi większość programistów na świecie. To nie jest budowanie emulatora terminala przyspieszanego GPU. Ludzie nie doceniają, jak wiele oprogramowania da się zrobić bez bycia nadmiernie technicznym — gdzie w porządku jest użyć zwykłego MySQL-a i mieć aplikację CRUD. To wystarczy.
Prezentacja setupu: AMP, orby i Puck
David: Dobra, Thorsten. Pokażesz nam swój setup do agentic engineering?
Thorsten: Tak. To jest AMP, ampcode.com. Zainstalowany jako PWA. (Informacja dodatkowa: PWA — Progressive Web App, aplikacja webowa instalowana jak natywna.) Zresztą myślę, że to nazewnictwo hamuje adopcję technologii — „PWA” nie jest łatwe do wymówienia.
AMP to agent kodujący. Wypuściliśmy go w zeszłym maju, jako jeden z pierwszych — zaraz po Claude Code. Jest multimodelowy: obsługujemy modele GPT, modele Anthropic, GLM. Od dwóch tygodni mamy pokrętło, którym wybierasz, ile wysiłku chcesz włożyć. Low to GLM z Oracle, czyli sub-agentem. Ja często idę na medium — to 5.6 na medium, a Oracle na high. Oracle to sub-agent, który jest recenzentem, dającym radę. Dalej masz high, i ultra.
David: Czyli z twojego doświadczenia 5.6 jest lepszym recenzentem niż Fable?
Thorsten: To zależy. Tu w trybie high mamy Fable jako Oracle. To niuanse. Ale w tym przypadku medium jest w porządku — pisze tu „zbalansowana inteligencja, szybkość i koszt dla większości zadań”. Nie potrzebujesz w miksie Fable; zawsze możemy o niego dopytać osobno.
Nie odpalam już dużo agentów w TUI. Od dwóch tygodni mamy funkcję orbów. Mogę powiedzieć: „daj mi przegląd tego repo”, a to odpala zdalną maszynę-sandbox, którą nazywamy orbem. Jest przypięty do tej konkretnej rozmowy — i to, jeśli chcesz pociągnąć w stronę filozoficzną, jest trochę przełomem. Teraz działa agent w checkoutcie tego repo, w zdalnym sandboksie. Gdy agent przechodzi w bezczynność, sandbox zasypia. Gdy zaczynasz pisać, wstaje z powrotem. Jeśli otworzę to na telefonie, w zasadzie strumieniuje się też na telefon — jest multi-device. Mogę nawet otworzyć to w TUI. I tak właśnie koduję najwięcej przez ostatnie tygodnie.
David: Czyli główna korzyść jest taka, że dając agentowi jego własny system — jak niektórzy wdrażają agentów na VPS — agent może wziąć na siebie więcej ryzyka, bo nie zepsuje twojego komputera?
Thorsten: Tak. Jeśli odpalę AMP w dowolnym kliencie… popatrz, tu na drugim ekranie mam AMP w TUI, mogę tym zdalnie sterować. Ale mogę też powiedzieć: chcę wystartować wątek tutaj, w tej instancji, w tym folderze — w jednym checkoutcie AMP na moim MacBooku Pro. Startuje nowy wątek: „hej, użyjmy do tego low, nie marnuj tokenów”. To tworzy wątek w moim lokalnym TUI. Możesz wyobrazić sobie odpalanie instancji AMP na Raspberry Pi, na swoim boksie w chmurze, na VPS-ie.
Wspominam o tym, bo tu to jest ta sama maszyna, więc jeśli te dwa wątki, te dwie rozmowy, zrobią zmianę, to na siebie wpadną — nie robimy teraz zarządzania work-tree ani checkoutami. Moglibyśmy dodać wsparcie dla work-tree, ale filozoficznie wierzymy, że te modele są tak dobre w siedzeniu w bezgłowych boksach, że jest niewielki powód, by zostawać lokalnie i grzebać przy lokalnych setupach. Naprawdę potężne jest mieć osobny orb na każdą zmianę.
Nad tym pracowałem dwa tygodnie temu — funkcja przełączania między wieloma kontami. Otwieram to, wstaje z powrotem, mogę zobaczyć diff. Ale teraz to jest zaparkowane: obliczenia, które zrobiły zmianę, kontekst, który ją wyprodukował, i agent — wszystko za jednym URL-em. Mogę udostępnić ten URL zespołowi i oni też mają do niego dostęp. Od kilku dni mamy też wsparcie multiplayer — zanim ten odcinek wyjdzie, pewnie będzie już wydane — dzięki któremu masz dostęp do orbów, nad którymi pracują inni z twojego zespołu. To, że możesz zapakować wątek, agenta, obliczenia i zmianę w jeden URL — i nie masz tego na swojej maszynie, wątku gdzie indziej, a zmiany wypchniętej na GitHub w osobnej gałęzi — moim zdaniem sporo zmienia.
Dziesięć lat temu był wielki push w stronę chmurowych IDE — pamiętasz Cloud9 i całą tę resztę. Wtedy chmurowe IDE widziano jako wielkie rozwiązanie: masz Chromebooka, a cały dev robisz na większej maszynie. Ale ludzie wpadali na problemy: latencja, brak moich skrótów klawiszowych, nie mogę się do tego zSSH-ować. Dziś te argumenty zniknęły. Kogo obchodzi latencja, skoro i tak czekasz na tokeny na sekundę? Kogo obchodzą language servery? Nie używam już language serverów, nie używam edytora, nie używam szalonych skrótów. Więc te argumenty nie trzymają się kupy. A kiedy idziesz zdalnie, jesteś domyślnie asynchroniczny.
Puck — meta-agent sterujący agentami
Thorsten: Żeby dobić gwóźdź do trumny: ktoś na Twitterze pytał, czy agenty i orby potrafią w ogóle użyć jakiegoś crossplatformowego frameworka desktopowego w Ruście. Zapytałem Pucka — to rzecz, którą wypuściliśmy wczoraj, taki meta-agent. Puck potrafi sterować twoimi innymi agentami. Powiedziałem: stwórz projekt, wybierz Rust jako framework, każ agentowi zrobić zrzut ekranu. Puck odpalił orb, wysłał do niego wiadomość: „zbadaj, czy orb AMP może wspierać crossplatformowy development desktopowy w tym repo”. Zaczął pracować, ja robiłem coś innego, a on wyprodukował zrzut ekranu. Pracował szesnaście minut — ale z perspektywy dewelopera, czy latencja to dwie czy szesnaście minut, nie ma znaczenia, bo ty już jesteś gdzie indziej.
David: Bo zdelegowałeś.
Thorsten: Dokładnie. Chodzi mi o to, że ludzie nie widzieli jeszcze, co te agenty potrafią teraz w bezgłowych boksach.
Mamy stronę ampcode.com/what-the-puck z różnymi renderami Pucka. To zabawna rzecz — nie udawajmy, że to poważne. Poprosiłem: „stwórz więcej wariacji tego”. W AMP mamy sub-agenta o nazwie Painter, który tworzy obrazy. Użył Paintera, żeby stworzyć nowy wariant Pucka: to lampa lawowa, to folia bąbelkowa, i tak dalej. Gdybyś powiedział mi to sześć tygodni temu — że tworzysz obrazy, podglądasz je, recenzujesz, wycinasz, sklejasz, wrzucasz na stronę, usuwasz tło — powiedziałbym, że chcę mieć w tym palce, otworzyć Pixelmatora albo Figmę. A tu proszę: dodał je, ja powiedziałem „musimy zaktualizować tekst na stronie, pokaż mi zrzut ekranu”, a on wrócił z zaktualizowanym tekstem. Zróbmy to na żywo — myślę, że możemy to shipnąć na produkcję. Wysyłam prompt, a on shipuje na produkcję i pokazuje zrzut.
Quinn, CEO AMP, miał dobry tweet — ta sama myśl, którą przed chwilą wygłosiłem: skoro i tak jesteś asynchroniczny, możesz poprosić agenta o dowód. Nie czekasz kolejnych 30 sekund, czekasz może minutę. Więc go poproś.
David: Odpal 50 różnych testów, sprawdź, czy działa, zbenchmarkuj.
Thorsten: Dokładnie. „Pokaż mi zrzut ekranu w trybie ciemnym, w jasnym” — bo i tak zajmie to dziesięć minut. A kiedy wrócę, jestem pewien, że działa, i wtedy klikam przycisk „ship it”. Cała gra się tu zmieniła.
Jak Thorsten promptuje — model jako „porwany senior”
Thorsten: Puck na razie jest tylko w wersji webowej, jako jedna rozmowa. Poprosiłem go — to chyba nawet było Fable — o przeniesienie Pucka do naszego CLI. I tak właśnie promptuję. Nawiasem: nie używam żadnych własnych slash-commandów, nie używam skilli, nie mam żadnych serwerów MCP.
Najważniejsze przy pisaniu promptów jest dla mnie to, skąd bierze się informacja, do której agent ma dostęp, żeby zinterpretować, o co mi chodzi. Agent ma dwa źródła informacji: dane treningowe i okno kontekstu. To wszystko. Dane treningowe to obserwowalny przez model internet, wiedza publiczna — w pewnym sensie stratna. Lubię myśleć o modelu jako o starszym inżynierze, który wszystko widział, pracował na wszystkich systemach operacyjnych, w backendzie i frontendzie, we wszystkich językach; wie, jak wywołać funkcję anonimową w Scheme, w Common Lispie, w Lua, w JavaScripcie. Wie wszystko.
Ale mój model mentalny jest taki: wyobraź sobie tego seniora, którego ktoś porywa z ulicy, zakłada mu kaptur na głowę, wiezie gdzieś, a potem nagle zdejmuje kaptur — i przed tobą jest tylko biurko z komputerem. Na komputerze jest baza kodu, przeglądarka, terminal i edytor tekstu. Tyle masz. I nagle ktoś wręcza ci prompt: „zaimplementuj to” albo „napraw tę funkcję”. Mniej więcej tyle informacji ma model. Może zajrzeć do bazy kodu, poszukać w internecie, użyć terminala i uruchomić komendy — i jest bardzo doświadczony. Ale jeśli twój prompt nie zawiera dość informacji, jeśli twoja baza kodu jej nie zawiera, jeśli twój AGENTS.md jej nie zawiera — to trudno oczekiwać cudów. (Informacja dodatkowa: AGENTS.md — plik z instrukcjami dla agenta w repozytorium.)
Weź przykład portowania Pucka do naszego CLI. Mógłbym napisać „przenieś Pucka do CLI”. To kiepski prompt. Mam w głowie więcej informacji o tym, jak to powinno działać, więc po prostu tę informację wkładam. Mówię: „popatrz, jak jest zaimplementowany w webowym UI” — ustawiam standard, wskazuję na informację. „Chcę przenieść to do naszego CLI. Myślę, że powinniśmy mieć komendę puck open. Mamy paletę komend w CLI, która otwiera wątek Pucka i pokazuje go w pasku bocznym. Myślę, że powinniśmy mieć też puck clear”. Riffuję, może potrzebujemy nowej modalności dla TUI. Tak właśnie rozmawiałbym z kolegą seniorem — to jest wiadomość na Slacku, którą bym wysłał.
Potem dodaję: „najpierw zbadaj, jak to jest zaimplementowane, jak to komunikujemy — popatrz na wpis w aktualnościach, wydaliśmy to wczoraj. Udokumentuj, jak to działa”. Nie zależy mi tak bardzo na dokumentacji, ale myślę, że tak jak u ludzi — chcę, żeby usiadł i to przemyślał, skompilował, czego się nauczył. Nie wiem, czy to nie jest zmyślanie, ale wydaje mi się, że pomaga. Potem: „wymyśl dobry pomysł, jak to przetłumaczyć. Użyj sub-agentów”. Fable jest drogie — tak drogie, że mnie przeraża — więc mówię: „użyj sub-agentów do implementacji” (to teraz modele GPT), „a potem przedstaw mi wyniki”. I poszedł, i zrobił. To było jakąś godzinę temu: „hej, przeniosłem to, jest podpięte pod to i tamto”, pojawia się w pasku bocznym, jest referencja.
Poprosiłem też, żeby stworzył storybooki — mamy storybooki dla CLI — i żeby przetestował to na lokalnym serwerze deweloperskim. Zrobiłem coś innego, a on chodził nie wiem jak długo, znalazł kupę błędów i mnie to nie obchodzi. Teraz muszę przez to przeczytać. Zrobił test end-to-end, dwie–trzysta linii, weryfikację, uruchomił wszystkie testy. Mogę teraz wejść — mamy w orbie dostęp do terminala — przetestować CLI i zobaczyć: Puck pojawia się w pasku bocznym. To jest AMP CLI, wersja Ghostty na WebAssembly. (Informacja dodatkowa: Ghostty — wspomniany wyżej terminal Mitchella Hashimoto.) Mnóstwo rzeczy działa, nawet kliknięcia myszą. Mam tu nawet easter egga: jak klikniesz pięć razy… bum, orb eksploduje. Puck działa.
I wracając do twojego pytania, którego nie zadałeś — jak ważny jest lokalny dev. Popatrz, co robię: to się uruchomiło, potwierdziłem, że działa, zrobię wyrywkowe kontrole implementacji. Ale koniec końców, jeśli zrobił testy end-to-end, przeczytałem to i mniej więcej zgadzam się z wyborami architektonicznymi — to po co mi lokalny dev? Testuję to, mam dostęp do terminala, jest całkiem dobrze.
Podobnie z Laravelem — jadę za tydzień na Laracon wygłosić prelekcję, więc bawiłem się Laravelem, którego nigdy nie tknąłem. Byłem wcześniej programistą Railsów, a Laravel jest nim zainspirowany. Kazałem zbudować to w orbie — postawił świeży projekt. W orbach mamy portale, przez które możesz wystawić cokolwiek. To coś działa na porcie 8000, mogę się do tego dostać, przetestować stan, udostępnić URL, otworzyć w przeglądarce, pokazać komuś innemu, przejrzeć pliki, zobaczyć wszystkie wprowadzone zmiany. Pytanie: czego więcej potrzeba? Mogę włączyć multiplayer, pojawi się u Tima, on może przejąć i powiedzieć „ekran rejestracji wygląda źle”, i shipnąć.
David: Zwłaszcza gdy masz w zespole mniej technicznych ludzi — mogą coś zacząć, a ktoś inny podejmuje i robi ostatnie 10%. To jest naprawdę trudne.
Thorsten: Tak. Pomyśl, jak pięć lat temu ktoś chciał zmienić coś na blogu: „ściągnij GitHub Desktop, bo nie umiesz gita z CLI, zrób pull request, dostaniesz preview URL z Vercela”. To było fajne. Ale teraz masz kontekst zmiany — to, co ta osoba wpisała agentowi — masz samą zmianę, masz obliczenia, możesz sprawdzić, czy działa, nie musisz robić checkoutu lokalnie, i możesz doprowadzić to do mety. I masz agenta, który robi wszystkie zmiany, jakich chcesz.
Wciąż czasem, z przyzwyczajenia, otwieram lokalne CLI — na przykład gdy potrzebuję jakichś danych uwierzytelniających i nie chce mi się ich bezpiecznie ogarniać, bo nie chcę nigdzie wklejać credentiali. Ale tego jest coraz mniej. Od czterech tygodni zmieniło się tak wiele — wypuściliśmy kupę rzeczy i nasza prędkość shipowania wzrosła. Tim, jeden z naszych designerów, który dużo koduje, mówi, że nigdy nie naprawił tylu drobnych niedoróbek i „paper cutów” co w ostatnie dwa tygodnie, bo za każdym razem, gdy coś znajdzie, robi zrzut ekranu, wysyła AMP, ma orb, robi wyrywkowe kontrole i mówi „mergeuj”.
A od zeszłego piątku mamy komunikację agent-do-agenta. Jeśli agent mówi „znalazłem kolejny błąd”, mogę powiedzieć: „odpal kolejny orb, żeby naprawić ten błąd, a ty rób swoje” — i on odpala kolejną rzecz w kolejnym checkoutcie, na kolejnej gałęzi, która naprawia błąd, a ja mogę do tego wrócić.
Prognozy na koniec
Thorsten: Moje prognozy: lokalny dev odchodzi. Modele są martwe w tym sensie, że rozróżnienie między nimi będzie w przyszłości mniej istotne — dojdziemy do punktu, gdzie to będzie „John Carmack na przycisk”. Nie jest jasne, jakie oprogramowanie przetrwa ani co w ogóle będzie warte budowania. Teraz ludzie mówią, że wszystko schodzi do infrastruktury — ale wszyscy przenoszący się do infry zabiją marże w infrze, bo mamy już piętnastu różnych dostawców sandboksów zjadających nawzajem swoje marże, co też nie jest zrównoważonym biznesem. Więc pytanie brzmi: co zostaje? Wszyscy to teraz rozgryzamy, ale wszyscy przesuwamy się na wyższy poziom budowania oprogramowania. Będzie mnóstwo do zbudowania — pytanie tylko, jak to będzie wyglądać.
David: To świetny punkt, żeby na tym zakończyć. Dziękuję bardzo. Gdzie ludzie mają cię szukać?
Thorsten: Wciąż jestem aktywny na X jako Thorsten Ball. Piszę cotygodniowy newsletter „Register Spill”, gdzie „wylewam to, co mam w rejestrach” (Informacja dodatkowa: gra słów — „spill what’s in my registers”, nawiązanie do rejestrów procesora). Wejdźcie na ampcode.com, używajcie AMP — mamy subskrypcje, orby, nadchodzący multiplayer, komunikację agent-do-agenta. Dajcie znać, co myślicie o Pucku.
David: Podlinkuję to wszystko pod filmem. Jeszcze raz dziękuję za czas i za dołączenie do podcastu.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Optymalizuj się pod szybkie porzucanie tego, co robisz
Na czym polega: Zespół AMP celowo tak buduje firmę, kod i produkt, by móc zabijać własne funkcje, gdy front się przesunie (najpierw rozszerzenie do VS Code, potem coraz więcej). Krótkoterminowo zostawia to pieniądze na stole, ale nie daje się „przywiązać” do przestarzałego sposobu pracy.
Jak stosować: Traktuj swoje workflowy, narzędzia i nawyki jako tymczasowe. Regularnie pytaj: „co robię tylko dlatego, że tak robiłem pół roku temu?”. Buduj tak, by móc łatwo odciąć element, nie przepisując całości.
Na co uważać: To rada od kogoś na absolutnym froncie z zespołem badawczym. Jeśli masz klientów korporacyjnych oczekujących stabilności, ciągłe „zabijanie funkcji” ich odstraszy — Ball sam przyznaje, że rezygnuje z rocznych kontraktów. Waż tempo zmian tolerancją swoich odbiorców.
2.Przestań niańczyć model — inwestuj w input, nie w mikrozarządzanie
Na czym polega: Ball twierdzi, że pilnowanie modelu linijka po linijce („nie zmieniaj tego pliku”, walka o camelCase) daje malejące korzyści. Najważniejsza zmienna jakości to informacja na wejściu: prompt, baza kodu, plik AGENTS.md.
Jak stosować: Zamiast poprawiać drobiazgi po fakcie, wkładaj z góry pełny kontekst: wskaż wzorcową implementację, opisz oczekiwane zachowanie, ustaw standard. Pisz prompt jak wiadomość na Slacku do doświadczonego kolegi.
Na co uważać: „Zaufaj modelowi bardziej” działa, gdy masz nawyk czytania diffów i robienia wyrywkowych kontroli. Ślepe zaufanie bez weryfikacji end-to-end to proszenie się o subtelne błędy — Ball i tak czyta przez wyniki i sprawdza wybory architektoniczne.
3.Zamień backlog na optymistyczne, tłowe uruchamianie agentów
Na czym polega: Zamiast parkować zgłoszony błąd w backlogu i estymować, czy warto się nim zająć, odpalasz agenta od razu (nawet w tle, gdy śpisz) i później przeglądasz gotowe poprawki, oceniając ich jakość.
Jak stosować: Gdy pojawia się drobny bug albo pomysł, odpal agenta od ręki, dopóki masz kontekst i energię. Rób z tego kolejkę gotowych propozycji do przejrzenia, nie kolejkę zadań do zrobienia.
Na co uważać: Działa tylko przy izolowanych środowiskach (osobny sandbox/gałąź na zmianę). Bez izolacji równoległe agenty „wpadną na siebie” — AMP sam nie zarządza jeszcze work-tree lokalnie. Koszt tokenów rośnie, gdy odpalasz spekulatywnie; potrzebujesz budżetu i dyscypliny w przeglądaniu, żeby nie utonąć w niesprawdzonych diffach.
4.„Slop” to brak pomysłu, nie wina AI — wartość leży w guście i inpucie
Na czym polega: Skoro 99% kodu AMP pisze AI, a produkt uchodzi za dopracowany, to o jakości decydują ludzkie decyzje: czy ikonka jest źle umieszczona, czy potrzebny tooltip, jaki wariant animacji. AI tylko przyspiesza wyrażenie gustu (15 wariantów orbów do wyboru).
Jak stosować: Używaj AI do generowania wielu wariantów, a swój czas przeznacz na wybór i osąd. Wkładaj wysiłek w to, co chcesz, żeby istniało na świecie — pomysł, nie klepanie.
Na co uważać: Generowanie wielu wariantów bez wyrobionego gustu to tylko szybsza produkcja śmieci. Wartość jest w kuratorze, nie w generatorze — jeśli nie umiesz odróżnić dobrego wariantu od słabego, AI tego za ciebie nie zrobi.
5.Przemyśl workflow od pierwszych zasad — nie przykręcaj agentów do starych rur
Na czym polega: Agent i tak już uruchamia testy w izolowanym sandboksie. Wypychanie potem tego samego do osobnego CI na dodatkowe 10 minut to duplikacja. Stare założenia (backlog, estymacje, osobne pipeline’y) przestają obowiązywać.
Jak stosować: Zidentyfikuj kroki procesu, które istnieją tylko z powodu dawnych ograniczeń, i sprawdź, czy agent już ich nie realizuje. Zredukuj podwójną pracę.
Na co uważać: Testy uruchomione przez agenta w jego sandboksie to nie to samo co niezależne CI na czystym środowisku z pełną macierzą — nie rezygnuj z bramek jakości tam, gdzie chodzi o bezpieczeństwo, zgodność czy reprodukowalność. Ball mówi z perspektywy zespołu, który sam pisze narzędzia; w regulowanym środowisku audytowalne CI ma wartość niezależną od szybkości.
6.Wartość przeniosła się z kodu na wiedzę „co i po co budować”
Na czym polega: Kod tanieje, więc software jako rzecz sama w sobie traci wartość. Rośnie znaczenie pytań produktowych: kto jest klientem, jak generujesz wartość, jaki proces właściwie rozwiązujesz. Wiedza „jak coś napisać” dewaluuje się szybciej niż wiedza „co warto zrobić”.
Jak stosować: Zanim odpalisz agenta, dopracuj problem: jaki jest realny workflow, jakie problemy rozwiązuje, czy da się go uprościć (drugi tablet zamiast drukarki i kartki). Ćwicz rozbijanie problemów biznesowych na rozwiązania.
Na co uważać: Nie ekstrapoluj z 1% na 100%. Są dziedziny (jak terminal Ghostty Hashimoto) głęboko techniczne, gdzie AI wciąż nie wystarcza. Oceniaj trzeźwo, czy twój problem jest „CRUD na MySQL”, czy naprawdę wymagający — Ball przyznaje, że dla takich nisz przewaga eksperta zostaje.
7.Buduj tak, by człowiek nie wypełniał formularzy — panel admina zastąp edycją kodu
Na czym polega: Ball uważa panele administracyjne za przestarzałe: zamiast klikać po formularzu, żeby zmienić ceny, wysyła agentowi zdjęcie nowego menu i mówi „popraw ceny”. Wszystko, co robi człowiek na stronie, powinno dać się zlecić agentowi.
Jak stosować: Przy nowym produkcie pytaj, jaka jest rola kodu: część „konfiguracji przez UI” możesz zastąpić agentem edytującym kod. Rozważ „przynieś własnego agenta” zamiast wbudowanego.
Na co uważać: To wizja pod front i pod technicznego użytkownika z agentem w bazie kodu. Dla nietechnicznych użytkowników, klientów zewnętrznych i systemów wymagających kontroli dostępu klasyczny panel admina wciąż bywa bezpieczniejszy i bardziej dostępny. API „by agent zrobił wszystko za człowieka” — jak sam mówi — jeszcze nie istnieją.
8.„Emacsyfikacja” — forkuj cudze narzędzia i dopasowuj je agentem pod siebie
Na czym polega: Ball sforkował przeglądarkę diffów, kazał AMP dodać własny motyw i funkcje, skompilować i wrzucić do swojego bin. Miał własne oprogramowanie w dwie minuty pracy agenta, bez oddawania zmian do upstreamu — bo nie miały wartości dla innych.
Jak stosować: Gdy narzędzie prawie ci pasuje, zamiast czekać na feature albo składać PR, sforkuj je i każ agentowi dopasować do twojego przypadku użycia. Podobnie z wewnętrznymi „mikroaplikacjami” zastępującymi „ten jeden Excel” czy stronę na wiki.
Na co uważać: Fragmentacja i dług: mnóstwo sforkowanych, niekontrybuowanych wersji to brak aktualizacji z upstreamu, brak łat bezpieczeństwa i wiedza zamknięta w głowie jednej osoby. Świetne do prywatnych narzędzi i prototypów; ryzykowne jako fundament czegoś, co ma żyć długo lub być utrzymywane przez zespół.
9.Idź zdalnie i asynchronicznie — jedna zmiana = jeden sandbox = jeden URL
Na czym polega: Orby AMP to zdalne sandboksy przypięte do wątku rozmowy: agent, obliczenia, kontekst i zmiana zamknięte w jednym udostępnialnym URL-u. Latencja przestaje mieć znaczenie, bo i tak jesteś asynchroniczny i zdelegowałeś — 2 czy 16 minut nie robi różnicy, gdy jesteś już gdzie indziej. Dawne argumenty przeciw chmurowym IDE (latencja, language servery, skróty) odpadły.
Jak stosować: Trzymaj osobne środowisko na zmianę, deleguj i przełączaj się na inną pracę, a wracaj do przeglądu, gdy agent skończy. Skoro jesteś async, proś agenta o dowód (zrzut ekranu w trybie ciemnym i jasnym, ponowny test) — czekasz minutę, nie sekundy.
Na co uważać: Praca zdalna komplikuje obsługę sekretów — Ball sam wraca do lokalnego CLI, gdy nie chce wklejać credentiali do zdalnego boksu. Zaufanie do „na pewno działa, kliknę ship it” wymaga, żeby agent faktycznie zrobił rzetelne testy end-to-end; inaczej „dowód” jest pozorny.
10.Dwie zmienne przewagi: umiejętność korzystania z agentów i budżet na tokeny
Na czym polega: Zdaniem obu rozmówców o wygranej zadecyduje umiejętność sterowania agentami plus budżet na czołowe modele. Przeciętny programista z AI zmiażdży dobrego programistę bez AI. Najważniejszą umiejętnością zostaje myślenie od pierwszych zasad, nie techniczne detale.
Jak stosować: Inwestuj w praktykę delegowania i promptowania oraz w dostęp do najlepszych modeli. Ćwicz meta-orkiestrację (agent sterujący agentami, jak Puck; komunikacja agent-do-agenta) i rozbijanie problemów, nie zapamiętywanie składni.
Na co uważać: Czołowe modele bywają drogie — Ball mówi wprost, że Fable „przeraża go kosztem”, dlatego do implementacji deleguje tańsze sub-agenty (modele GPT). Bez kontroli kosztów spekulatywne odpalanie agentów szybko przepala budżet. „Ekstrapoluj, gdzie modele będą za 6–12 miesięcy” to prognoza mówcy, nie fakt — planuj z marginesem na to, że postęp może być wolniejszy.