Czego nauczyłem się, wydając wersję beta Hefty z partnerem programistycznym AI

Hefty jest w fazie otwartej bety. Hefty to agent AI typu local-first, który steruje Twoim komputerem, automatyzuje procesy i zarządza plikami. Ten tekst to nie poradnik. To raport z procesu tworzenia: wnioski z budowy Hefty od zera ze sztuczną inteligencją jako moim głównym partnerem programistycznym. Część z nich pokrywa się z tym, co opisałem w The New Rules. Część była dla mnie zaskoczeniem.

Skąd to doświadczenie

Tworzę i wdrażam oprogramowanie od 27 lat. Mam doktorat z nauk technicznych, publikowałem w wydawnictwach IEEE oraz Springer prace na temat systemów rozproszonych i modeli neuronowych, a także byłem głównym architektem największej sieci społecznościowej w Hiszpanii - platformy liczącej ponad 10 milionów użytkowników. Ostatnio współtworzyłem Anyone, największą na świecie rozproszoną sieć ochrony prywatności.

To doświadczenie ma kluczowe znaczenie dla dalszej części tekstu. Nie jestem nowicjuszem zachwyconym autouzupełnianiem kodu przez AI. Budowałem infrastrukturę produkcyjną w dużej skali i zapewniam: linia wytwórcza wspierana przez sztuczną inteligencję jest faktem. Działa jednak inaczej, niż sądzi większość ludzi.

Plan i obecny etap prac

Plan dla Hefty zakładał trzy kroki:

• stworzyć coś, co ludzie chcą zobaczyć;
• stworzyć coś, z czego ludzie chcą korzystać;
• stworzyć coś, za co ludzie chcą zapłacić.

Jestem na etapie drugim. Wersja beta działa, grupa fokusowa aktywnie testuje system, a pętla informacji zwrotnej funkcjonuje na bieżąco.

Czego nauczyły mnie dwa lata eksperymentów

Po dwóch latach sprawdzania różnych podejść doszedłem do prostego wniosku: podstawy nie zmieniły się tak bardzo, jak mogłoby się wydawać.

Wciąż potrzebujesz solidnej linii wytwórczej oprogramowania. Pojawiła się nowa klasa narzędzi programistycznych - to prawda. Końcowy produkt pozostaje jednak formą ekspresji, która zależy od człowieka. W jakim stopniu i w jaki sposób - o tym nadal decyduje inżynier.

Budowałem rozmaite systemy: od platform VOD i analityki IoT po silniki wirtualnych światów. Sam proces produkcyjny liczy się bardziej niż narzędzia. Narzędzia po prostu przyspieszyły.

Pisałem o tym w The New Rules: gdy czas implementacji zbliża się do zera, szybkość myślenia staje się wszystkim. W moim własnym procesie tworzenia okazało się to dosłowną prawdą. Dekady wyrobionego instynktu architektonicznego wcale nie straciły na wartości w erze AI. Stały się wąskim gardłem - w najlepszym możliwym tego słowa znaczeniu.

Faza A: rozwój rdzenia sterowany specyfikacją

Faza A zajęła dwa tygodnie nieustannych cykli: specyfikacja, doprecyzowanie, kodowanie, optymalizacja i ponowna aktualizacja specyfikacji.

Tydzień pierwszy poświęciłem na projektowanie rdzenia: kluczowe decyzje architektoniczne, język dziedzinowy, mapę komponentów oraz wytyczne jakościowe dotyczące cyklu życia programu. W tym miejscu doświadczenie przynosi procent składany. Świadomości tego, które abstrakcje przetrwają w warunkach rzeczywistego użytkowania, nie da się wygenerować za pomocą zręcznego promptu.

Tydzień drugi był przeznaczony na budowę głównych funkcji: interfejsu graficznego (GUI), integracji z protokołem MCP, warstwy API, przepływu poznawczego (wzbogacania i zarządzania kontekstem) oraz strumieniowania aktywności. W efekcie powstał działający agent z interfejsem czatu, dopracowanym UI i solidną powłoką systemową. Tempo wynosiło około dwóch pełnych iteracji tygodniowo - od zera do działającego agenta.

Kluczowe było to, że praca nad specyfikacją i pisanie kodu przeplatały się wzajemnie, zamiast biec sekwencyjnie. Każda iteracja kodu wpływała na kolejną wersję specyfikacji. Każda zmiana w specyfikacji przekształcała kod. Model AI jako partner programistyczny sprawił, że ta pętla była na tyle szybka, by stać się w pełni praktyczna. To, co normalnie wymagałoby miesiąca ustaleń i poprawek, zamknęło się w kilku dniach.

Faza B: udoskonalanie pod wpływem użytkowników

Gdy tylko pojawiło się coś, co można było pokazać, zmieniłem przebieg prac rozwojowych. Wprowadziłem grupę fokusową, a pętla przyjęła schemat: obserwuj (użycie), zdefiniuj (zapotrzebowanie na zmianę), wdróż (zmiana w programie), obserwuj ponownie. Przez cztery tygodnie utrzymywałem to samo tempo dwóch iteracji tygodniowo, tym razem zasilane informacjami zwrotnymi od rzeczywistych użytkowników.

Nie spodziewałem się jednak tak ogromnej liczby okazji do usprawnień, które ujawniły się, gdy prawdziwi ludzie zaczęli korzystać z produktu. Równolegle ze standardowym rozwojem funkcji nieustannie wprowadzałem ukierunkowane porządki: ujednolicanie wzorców, konsolidację oraz upraszczanie kodu źródłowego.

Wpisuje się to bezpośrednio w to, o czym pisałem w The New Rules: gdy sztuczna inteligencja może wygenerować dowolną funkcję, selekcja staje się ważniejsza niż kreacja. Trudność nie polegała na pisaniu kolejnych modułów. Prawdziwym wyzwaniem było decydowanie, które poprawki rzeczywiście mają znaczenie, oraz utrzymanie spójności bazy kodu przy zachowaniu wysokiego tempa prac. To kwestia inżynierskiego osądu. Wynika ona z lat utrzymywania systemów w dużej skali, a nie ze starannie sformułowanego zapytania do modelu.

Dlaczego nie ma jeszcze testów automatycznych

We wczesnych fazach świadomie zrezygnowałem z testów automatycznych. Zrobiłem to z pełnym rozmysłem.

Zdaję sobie sprawę, jak brzmi to w ustach osoby z doktoratem i publikacjami naukowymi z zakresu oceny jakości oprogramowania. Za tą decyzją stały dwa powody:

• tempo zmian - kod źródłowy przekształcał się tak dynamicznie, że utrzymanie testów generowałoby stały narzut pracy przy minimalnych korzyściach;
• ograniczona potrzeba stuprocentowej precyzji - na tym etapie rozwoju produktu zgodność kierunkowa jest ważniejsza niż bezwzględna dokładność.

W trakcie tych początkowych faz odrzuciłem około czterech wczesnych prototypów, aby wypracować wstępny szkielet architektoniczny. Układ komponentów, przepływy strumieniowania i wykonywania zadań, zakres modułu poznawczego oraz integracje pomocnicze do zadań konserwacyjnych - wszystko to przeszło gruntowne przebudowy.

Moja teza brzmi: łatwiej jest uporządkować kod z doświadczonym inżynierem i partnerem AI, niż zarządzać rozbudowanym zestawem testów w obliczu ciągłych transformacji architektonicznych. Stoi to w sprzeczności z powszechnie przyjętymi zasadami. Tyle że tradycyjne reguły powstały w świecie, w którym przepisywanie kodu było kosztowne. Gdy asystent AI potrafi zrestrukturyzować cały moduł w kilka minut, bilans zysków i strat wygląda zupełnie inaczej.

Testy oczywiście się pojawią. Architektura ulega stabilizacji, a głębokie zmiany stają się coraz rzadsze. Wymuszanie testów na zbyt wczesnym etapie spowolniłoby rozwój, nie dając realnych gwarancji bezpieczeństwa.

Co dalej

Proces iteracyjny pozostaje niezmienny: obserwuj, zdefiniuj, wdróż. Każdy z tych kroków staje się jednak bardziej zautomatyzowany i wymaga mniejszego bezpośredniego nadzoru człowieka. Program osiągnął poziom dojrzałości, przy którym sama linia produkcyjna wymaga modernizacji: więcej mechanizmów zabezpieczających, więcej automatyzacji i większa pewność przy wprowadzaniu zmian.

Obserwuję ten sam schemat w całej branży. W miarę jak czas implementacji z użyciem AI zbliża się do zera, wąskie gardło przesuwa się w górę stosu technologicznego. Najpierw ograniczeniem było tempo pisania kodu. Potem szybkość podejmowania decyzji. Dziś jest nim projektowanie procesów.

Za kilka tygodni przedstawię kolejny raport ze szczegółami.

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 tworzysz teraz oprogramowanie za pomocą narzędzi AI, chętnie dowiem się, jak wygląda Twój proces. To linia produkcyjna stanowi właściwy produkt - wszystko inne to jedynie rezultat jej działania.