Miesiąc z betą Hefty - raport z fazy dopracowywania produktu

Miesiąc temu opisałem to, czego nauczyłem się, wydając wersję beta Hefty z partnerem programistycznym AI. Tamten artykuł podsumowywał sześć tygodni drogi od zera do wersji beta: rozwój sterowany specyfikacją, pętle informacji zwrotnej od użytkowników oraz tempo wdrażania, jakiego nigdy wcześniej nie osiągnąłem w tradycyjnym modelu pracy. Hefty to agent AI typu local-first, który steruje Twoim komputerem, automatyzuje procesy i zarządza plikami. Projekt wciąż znajduje się w fazie otwartej bety.

Miniony miesiąc wyglądał inaczej. Prace wcale nie zwolniły. Pod pewnymi względami posuwały się nawet szybciej. Było jednak trudniej, i to w sposób, którego się nie spodziewałem - bynajmniej nie dlatego, że wyzwania inżynieryjne stały się bardziej skomplikowane. Zmienił się sam charakter problemów. Kiedy przechodzisz od budowania nowości do dopracowywania czegoś, z czego ludzie rzeczywiście korzystają, przychodzi pora na spłatę długu za każdy skrót, na jaki sobie wcześniej pozwoliłeś. Pytanie przestaje brzmieć: „czy potrafimy to zbudować?”, a zaczyna: „czy jesteśmy w stanie to utrzymać?”.

Ten artykuł to raport z tego właśnie etapu.

Paradoks testowania

W poprzednim tekście broniłem rezygnacji z testów automatycznych. Kod zmieniał się tak dynamicznie, że zestaw testów byłby stałym obciążeniem dającym znikome korzyści w zakresie stabilności. W surowej fazie budowy to założenie w pełni się sprawdziło.

Miesiąc później mam już testy jednostkowe. Działają testy end-to-end. Środowiska testowe są skonfigurowane. A ja wciąż nie mam pewności, jak dużą wartość realnie wnoszą one na obecnym etapie.

Oto powód. Jestem w trakcie szeroko zakrojonych prac porządkowych (quality of life): refaktoryzuję interfejsy, upraszczam przepływy i konsoliduję abstrakcje, które miały sens w pierwszym tygodniu, ale dziś już się zdezaktualizowały. To dokładnie ten rodzaj modyfikacji, który psuje testy. Nie dlatego, że testy są błędne, ale dlatego, że produkt ewoluuje szybciej, niż testy są w stanie nadążyć. Otwarte pozostaje pytanie, czy klasyczne metodyki testowania mają rację bytu na tym etapie pracy wspomaganej przez AI, gdzie tempo wprowadzania zmian daleko wykracza poza tradycyjne schematy.

Nie twierdzę, że testowanie straciło sens. Taka teza nie przetrwa próby zderzenia z utrzymaniem działającego produktu. Zwracam jedynie uwagę, że kalkulacja zwrotu z inwestycji i właściwy moment na testy wyglądają inaczej, gdy Twój partner AI potrafi zrestrukturyzować cały moduł w czasie potrzebnym na aktualizację powiązanych danych testowych. Zasada, którą przyjmuję, brzmi: właściwe testy we właściwym czasie, a nie testy pisane tylko po to, by odhaczyć metrykę. Rozwinę ten temat, gdy architektura ostatecznie okrzepnie, a zestaw testów zacznie na siebie zarabiać.

Kwestia testów była pierwszym sygnałem. Drugim stał się fakt, że Hefty zaczął wyrastać ze swoich pierwotnych ram.

Od agenta do platformy

Hefty nie jest już pojedynczym agentem. Przekształca się w platformę: zestaw usług wspierających operacje agentowe osób, które uruchamiają system, konfigurują go i polegają na nim każdego dnia.

Budowa tej platformy ujawniła prawdziwe wyzwania związane z rozwojem oprogramowania wspieranym przez AI. To kwestie, o których nikt nie wspomina na konferencjach branżowych:

• przełączanie kontekstu to cichy zabójca - balansuję między rdzeniem agenta, usługami platformy, narzędziami operatorskimi a warstwami konfiguracji; każdy z tych obszarów ma własny kontekst, własny stan i odrębny model pojęciowy. Narzędzia AI radzą sobie znakomicie w granicach jednego kontekstu. Nie pomagają jednak w płynnym przeskakiwaniu między pięcioma różnymi środowiskami. Wątpię zresztą, czy cokolwiek w tym pomaga.
• środowisko deweloperskie i produkcja to wciąż dwa różne światy - to, co działa na mojej maszynie, i to, co funkcjonuje bezawaryjnie u kogoś innego, to dwie zupełnie odmienne sprawy. Ta przepaść nie zniknęła wraz z pojawieniem się AI. Po prostu zmieniła położenie. Wdrożenie, rozbieżności konfiguracyjne, założenia środowiska uruchomieniowego: wciąż musisz mieć to wszystko pod kontrolą.
• bezpieczeństwo przestaje być teorią, a staje się fundamentem architektury - w chwili, gdy tworzysz narzędzie wchodzące w interakcję z lokalnymi systemami użytkowników i kluczami API, bezpieczeństwo przestaje być formalnością do odhaczenia, a staje się warunkiem brzegowym kształtującym każdą decyzję. Do czego agent ma dostęp? Co trafia do logów? Co jest buforowane? Co się dzieje w momencie rotacji danych uwierzytelniających?
• stabilność API to wybór strategiczny - zacząłem bezwzględnie selekcjonować usługi zewnętrzne, z którymi integruję system. Wniosek był prosty i kosztowny: wybieraj stabilne, dojrzałe API, albo płać za nieustanne przepisywanie integracji za każdym razem, gdy zewnętrzny dostawca ulega kolejnej fali rynkowego szumu.

Żadne z tych zadań nie jest spektakularne. To jednak właśnie ta praca odróżnia zwykłe demo od gotowego produktu.

Cała ta dynamika zrodziła jednak kolejny problem.

Zderzenie ze ścianą wydajności

Dotychczasowy model pracy przy budowie wersji beta - ręczne prowadzenie AI przez każde zadanie, weryfikowanie każdego wyniku, korygowanie kursu i wprowadzanie poprawek - trafił na barierę. Nie była to bariera koncepcyjna. Była to bariera tempa pracy.

Nawet przy zadaniach o umiarkowanej złożoności manualna pętla okazywała się zbyt wolna. Spędzałem więcej czasu na sterowaniu modelem niż na samym tworzeniu. To dokładne przeciwieństwo tego, co ma zapewniać inżynieria wspomagana przez AI.

Zdecydowałem się więc na zmianę strukturalną. Przeszedłem od ręcznego wpisywania promptów do podejścia zautomatyzowanego: orkiestracja zamiast ciągłego instruowania, potoki przetwarzania zamiast pojedynczych poleceń i systemowa dekompozycja zadań zamiast metody prób i błędów.

Skutki były natychmiastowe:

• zużycie tokenów gwałtownie wzrosło - większa automatyzacja oznaczała znacznie więcej pracy AI w każdym cyklu: więcej generowania treści, więcej analiz i intensywniejsze przetwarzanie kontekstu. Jeśli Twój dostawca rozlicza się za tokeny, w tym momencie zaczynasz to odczuwać. To tutaj ujawnia się jednak prawdziwa dźwignia operacyjna. Koszty wzrosły, ale wydajność w przeliczeniu na jednostkę mojego czasu wzrosła jeszcze bardziej. Dokładnie na takim bilansie mi zależało.
• uniknąłem pułapki uzależnienia od dostawcy - mniej więcej w tym samym czasie czołowy dostawca modeli zaczął wprowadzać zmiany, które przypominają, dlaczego opieranie się na jednym, niekontrolowanym przez siebie stosie narzędzi stanowi poważne ryzyko biznesowe: modyfikacje cenników, limity zużycia, standardowy schemat rynkowy. Architektura wielu dostawców oparta na automatyzacji, na którą dopiero co przeszedłem, pozwoliła mi zamortyzować te zmiany bez utraty płynności prac.

Szerszy wniosek jest jednoznaczny: im wcześniej wbudujesz elastyczność operacyjną w proces wytwórczy oparty na AI, tym mniej bolesny będzie moment, w którym zewnętrzny dostawca uzna, że Twoje potrzeby przestały być jego priorytetem.

Gdy systemy wewnętrzne zaczęły działać sprawnie, nastąpiła kolejna zmiana. Wąskim gardłem przestał być sam kod.

Spojrzenie z szerszej perspektywy

W każdym samodzielnym projekcie nadchodzi moment, w którym kod powstaje na tyle szybko, że to Ty stajesz się głównym ograniczeniem. U mnie ten punkt nadszedł po około sześciu tygodniach pracy.

Zmieniłem więc model działania. Spędzam mniej czasu w samym kodzie, a więcej wokół samego produktu.

Wdrożyłem wyspecjalizowanego agenta marketingowego. Nie jest to uniwersalny asystent ogólnego przeznaczenia. To dedykowany system stworzony specjalnie do zarządzania strategią treści, precyzyjnego doboru grupy docelowej i planowania kampanii pod kątem Hefty. Różnica w jakości materiałów była widoczna od pierwszego dnia.

Zaostrzyłem także kryteria doboru partnerów. Przeprowadziłem wystarczająco dużo rozmów z ludźmi, którzy chcieli „badać synergie”. Dziś potrzebuję partnerów gotowych do działania: ludzi, którzy dostrzegają potencjał rynkowy, rozumieją specyfikę tego obszaru i chcą realnie budować, a nie tylko dyskutować. To kryterium nie podlega negocjacjom.

Taka zmiana bywa trudna. Wymaga zaufania systemom, które sam zbudowałem, i powierzenia im zadań wykonywanych wcześniej ręcznie. Oznacza pogodzenie się z tym, że mój czas przynosi większą wartość w obszarze strategii i relacji biznesowych niż przy kolejnym commicie z nową funkcją. To nauka odpuszczania bezpośredniej kontroli nad detalami.

Kiedy jednak podnosisz wzrok znad kodu, musisz zmierzyć się z rynkiem. A rynek jest wyjątkowo głośny.

Sygnał a szum informacyjny

Zacząłem uważniej śledzić internetowe dyskusje na temat AI. Częściowo z ciekawości, a w większości z konieczności: muszę precyzyjnie rozumieć, jak pozycjonować Hefty w środowisku zalanym marketingowym szumem.

Widzę dokładnie to, czego można się spodziewać. Każdy dzień przynosi kolejną premierę. Każdy wątek ogłasza przełom. Każda opinia mieni się ostateczną prawdą. Przestrzeń AI w mediach społecznościowych to gospodarka uwagą działająca na pełnych obrotach, a większość tego, co w niej powstaje, można dyplomatycznie nazwać myśleniem życzeniowym.

Nie posiadam magicznego rozwiązania. Gdybym je miał, kierowałbym marketingiem, a nie inżynierią.

Moją zasadą działania pozostaje: zachować pokorę, utrzymać koncentrację i systematycznie dostarczać działające oprogramowanie. Odbiorcy, do których chcę dotrzeć - operatorzy agentów AI oraz profesjonaliści, dla których liczą się rozwiązania local-first i ochrona prywatności - bezbłędnie wyczuwają pusty szum z daleka. A rynek AI jest nim obecnie przesycony.

Przemawia produkt. Przemawiają faktyczne osiągnięcia. Prezentowanie realnych aktualizacji i działającego kodu znaczy więcej niż jakikolwiek viralowy wątek. Wierzę w to, nawet jeśli algorytmy promują coś zupełnie innego.

I rzeczywiście: wbrew panującemu szumowi właściwi ludzie zaczęli trafiać do projektu.

Pierwsze rozmowy innego kalibru

Tego się nie spodziewałem. Przynajmniej nie na tak wczesnym etapie.

Zacząłem prowadzić rozmowy z potencjalnymi klientami. Nie chodzi o pogawędki napędzane rynkową modą, w których ktoś prosi o ogólne opowiedzenie o produkcie. To bardzo konkretne dyskusje z ludźmi, którzy w pełni rozumieją dwie fundamentalne kwestie. Po pierwsze, wartość osobistego asystenta AI, który działa na ich własnym sprzęcie, pod ich pełną kontrolą i z danymi, które nigdy nie opuszczają ich komputera. Po drugie, ryzyko uzależnienia od rozwiązań chmurowych w zadaniach obejmujących poufne informacje, osobiste procedury pracy i codzienne decyzje biznesowe.

Pytania brzmią prosto: „Potrzebuję zrealizować X. Czy Hefty potrafi zrobić X?”. To pytanie zadaje ktoś, kto dogłębnie przemyślał problem, a nie tylko poddał się chwilowej modzie.

Nie liczę jeszcze przychodów. Liczę wartościowe rozmowy. A te stają się zupełnie inne: mniej w nich luźnego rozpoznania, a znacznie więcej sprecyzowanej intencji.

Małe, ale konkretne kroki

W przypadku dojrzałego produktu dysponującego zespołem i zewnętrznym finansowaniem nic z tego nie byłoby niczym niezwykłym. Strategia testów, architektura platformowa, lejek marketingowy, wczesne rozmowy z klientami - to po prostu zwykły dzień w pracy.

W przypadku projektu budowanego samodzielnie przez jedną osobę w modelu bootstrap, ze sztuczną inteligencją jako głównym narzędziem inżynieryjnym, w branży generującej więcej szumu niż użytecznych treści - to autentyczne kamienie milowe. Nie dlatego, że robią wielkie wrażenie w oderwaniu od kontekstu, ale dlatego, że każdy z nich reprezentuje podjętą decyzję, poniesione ryzyko i przekonanie, że konsekwentny wysiłek przynosi lepsze rezultaty niż głośne, jednorazowe premiery.

To wciąż początek drogi. Hefty pozostaje w fazie beta. Faza dopracowywania to moment, w którym dowiadujesz się, czym Twój produkt faktycznie jest, w odróżnieniu od tego, czym miał być według pierwotnych założeń. To w tej przestrzeni dokonuje się najbardziej wartościowa nauka.

Będę nadal opisywał swoje obserwacje - nie dlatego, że znam odpowiedzi na wszystkie pytania, ale dlatego, że branża potrzebuje rzetelnych relacji od praktyków, którzy rzeczywiście wdrażają oprogramowanie, zamiast komentować z boku. Obietnica pozostaje ta sama: bez zbędnego lania wody, bez kreowania pozorów i bez płytkich zestawień. Tylko to, co faktycznie buduję, co działa, co zawodzi i jak można to przełożyć na doświadczenia każdego, kto próbuje osiągnąć podobny cel.

Wkrótce przedstawię kolejne wnioski.

Wypróbuj wersję beta

Hefty jest dostępny w otwartej wersji beta. Działa lokalnie, stawia prywatność na pierwszym miejscu i pozwala podłączyć własny model LLM lub klucz API. Wersję beta można przetestować bezpłatnie na systemach Linux, macOS oraz Windows.

Jeśli poważnie myślisz o agentach AI działających lokalnie - jako użytkownik lub potencjalny partner - chętnie porozmawiam. A jeśli sam utrzymujesz oprogramowanie zbudowane przy wsparciu AI, chętnie dowiem się, jak przebiega Twoja faza dopracowywania produktu.