Software 3.0: aplikacje budowane wokół intencji

Większość aplikacji wciąż oczekuje, że to człowiek dopasuje się do interfejsu. Otwierasz produkt, znajdujesz właściwy ekran, wybierasz właściwy filtr, wypełniasz właściwy formularz i przechodzisz przez proces, który ktoś zaprojektował z góry. To działa świetnie, gdy proces jest znany i stabilny.

Wiele realnych zadań tak nie wygląda. Użytkownik często przychodzi z celem, a nie z kliknięciem:

„Porównaj te dwie oferty, pokaż ryzyka i przygotuj rekomendację dla klienta”.

Żeby dobrze to obsłużyć, system musi czasem zebrać dane, porównać dokumenty, wychwycić to, czego brakuje, zastosować reguły biznesowe, poprosić o akceptację i pokazać wynik w użytecznej formie. To jest kierunek, który nazywamy Software 3.0.

Nie każdy produkt potrzebuje chatu. Nie każdy proces ma stać się autonomiczny. Zmiana jest bardziej fundamentalna. Przechodzimy od projektowania interfejsów wokół pojedynczych akcji do projektowania systemów wokół intencji użytkownika.

Devs 3.0 uczy budowania takich systemów w praktyce. Ten blog to warsztatowy notatnik, który za tym stoi: co działa, co się psuje, gdzie modele pomagają, a gdzie lepiej zostać przy zwykłym kodzie.

Co rozumiem przez Software 3.0

Software 3.0 to dla mnie praktyczna etykieta na aplikacje, w których modele językowe i agenty stają się częścią logiki produktu. Nie generują tylko odpowiedzi w okienku chatu. Pomagają zinterpretować niejednoznaczne wejście, wybrać z ograniczonego zestawu narzędzi, pracować ze stanem aplikacji i doprowadzić zadanie do wyniku.

Zwykła nakładka na LLM-a to jeszcze nie produkt agentowy. Wysłanie promptu do modelu i wyrenderowanie odpowiedzi bywa użyteczne, ale to wciąż interfejs konwersacyjny. Trudniejsza inżynieria zaczyna się wtedy, gdy system potrafi pobrać zaufane dane, wywołać narzędzia, pilnować stanu przez wiele kroków, podnieść się po błędzie, poprosić o akceptację przed istotną akcją i pokazać wynik w interfejsie dopasowanym do zadania.

W tym momencie pytanie nie brzmi już „gdzie użytkownik ma kliknąć?”. Brzmi: „co użytkownik chce osiągnąć, co systemowi wolno zrobić i gdzie musi się zatrzymać?”. To trudniejszy problem. I ciekawszy.

Trzy ery oprogramowania

Software 1.0: reguły pisane ręcznie

W Software 1.0 programista zapisuje reguły wprost. Formularz ma walidację. Endpoint ma warunki. Proces biznesowy ma jawne rozgałęzienia. Jeśli przypadku nie ma w kodzie, system go nie obsłuży.

To nadal właściwe podejście w wielu częściach produktu. Płatności, uprawnienia, księgowanie, audyt, cennik i nieodwracalne akcje nie powinny zależeć od tego, że model „daje z siebie wszystko”. Potrzebują deterministycznej logiki, czytelnych logów i przewidywalnych trybów awarii. Granica pojawia się wtedy, gdy użytkownik przychodzi z nieuporządkowanym żądaniem albo gdy wejść jest zbyt wiele, by ująć je w kilku sztywnych ekranach.

Software 2.0: modele, które uczą się wzorców

Software 2.0, termin spopularyzowany przez Andreja Karpathy'ego, przesuwa część logiki z ręcznie pisanych reguł do modeli trenowanych na danych. Zamiast kodować każdy warunek potrzebny do rozpoznania obrazu, podajesz przykłady i pozwalasz modelowi nauczyć się wzorca.

To uczyniło wiele trudnych dotąd problemów praktycznymi: rozpoznawanie obrazów i mowy, tłumaczenie, klasyfikację, ranking. Kompromis jest realny. Uczone systemy są mocne tam, gdzie reguły trudno napisać, ale są mniej przejrzyste, trudniejsze w debugowaniu i tak niezawodne, jak ich dane, ewaluacja i otaczający je projekt. Model nie jest magicznym zamiennikiem inżynierii. To kolejny komponent o innych mocnych stronach i innych trybach awarii.

Software 3.0: systemy, które pracują z intencją

Software 3.0 wkłada te możliwości w aplikacje, które potrafią rozumować nad językiem, używać narzędzi, sięgać po kontekst i przejść przez proces w granicach. Kluczowe słowo to granice. Użyteczny agent nie powinien mieć nieograniczonego dostępu, nieograniczonej władzy ani mglistego polecenia „pomóż użytkownikowi”. Powinien wiedzieć, jakich narzędzi może użyć, jakich danych dotknąć, które akcje wymagają akceptacji, które decyzje należą do deterministycznego kodu, jak wygląda sukces i kiedy zapytać człowieka, zamiast iść dalej.

Jednostką pracy nie jest już funkcja, wywołanie API ani ekran. Jest nią intencja użytkownika: „pomóż mi wybrać”, „przygotuj wersję roboczą”, „znajdź problem”, „zaproponuj następny krok”. Model zamienia tę intencję w ustrukturyzowaną pracę. Reszta systemu pilnuje, żeby ta praca była bezpieczna, obserwowalna i użyteczna. I tu zaczyna się prawdziwa inżynieria.

Generatywne UI to nie „ekrany generowane przez AI”

Generatywne UI bywa opisywane jako interfejs, który pojawia się dynamicznie wokół żądania. To opis użyteczny, ale niepełny. Nie powinien oznaczać modelu wypluwającego dowolny HTML w nadziei, że da się go użyć. Powinien oznaczać system, który dobiera, konfiguruje i składa wiarygodne elementy interfejsu wokół konkretnego zadania.

Ktoś, kto prosi o podsumowanie, może potrzebować krótkiej syntezy, odwołań do źródeł i otwartych pytań. Ktoś, kto porównuje dwie oferty, może potrzebować ustrukturyzowanej tabeli, podświetlonych różnic, ryzyk i miejsc wymagających akceptacji człowieka. Ktoś, kto przygotowuje odpowiedź klientowi, może potrzebować szkicu, faktów, które za nim stoją, edytowalnych założeń i wyraźnego kroku akceptacji przed wysłaniem.

Interfejs staje się bardziej adaptacyjny, ale produkt nie powinien stać się mniej intencjonalny. Jest odwrotnie. Gdy agent może zmienić to, co użytkownik widzi albo robi, projektowanie musi być bardziej rygorystyczne wobec stanów, uprawnień, fallbacków, obsługi błędów i odpowiedzialności.

Reguła, do której wciąż wracam

Model językowy jest użyteczny tam, gdzie język jest niejednoznaczny: przy interpretacji nieuporządkowanych żądań, wyciąganiu struktury z dokumentów, porównywaniu opcji, proponowaniu szkiców, pomaganiu w eksploracji złożonego systemu. Nie powinien być ostateczną instancją w sprawie uprawnień, pieniędzy, zobowiązań prawnych ani nieodwracalnych zmian stanu. Praktyczna reguła:

Niech model interpretuje niejednoznaczność. Niech deterministyczny kod waliduje, wykonuje i zapisuje istotne akcje.

To nie czyni produktu mniej agentowym. Czyni go gotowym na produkcję. Zbyt wiele „aplikacji agentowych” to wciąż nakładki na chat z szerokim dostępem do narzędzi i optymistycznymi promptami. W demie wyglądają świetnie, bo szczęśliwa ścieżka jest krótka. Problemy pojawiają się później: gdy model wybierze złe narzędzie, gdy kontekst jest niepełny, gdy akcja powiedzie się tylko częściowo, gdy użytkownik zmieni zdanie w połowie, gdy model wymyśli pewne siebie wyjaśnienie albo gdy agent sięgnie po dane, do których nigdy nie powinien mieć dostępu. Autonomia nie jest celem. Celem jest użyteczna, ograniczona, obserwowalna autonomia.

Co to zmienia w sposobie, w jaki budujemy

Agentowe oprogramowanie nie znosi dyscypliny inżynierskiej. Przesuwa ją w nowe miejsca.

• Domyślnie deterministycznie. Używaj modeli tam, gdzie realnie wnoszą wartość, a całą resztę trzymaj jako zwykły, przewidywalny kod: jawna walidacja, typowane kontrakty, kontrola uprawnień, trwałe workflow, logi i testy.
• Stan staje się problemem pierwszej klasy. Jedna odpowiedź jest łatwa. System, który pamięta kontekst, prowadzi wiele kroków, ponawia bezpiecznie, podnosi się po awariach narzędzi i nie gubi celu użytkownika, jest dużo trudniejszy. Stan agenta, grafy workflow, punkty kontrolne i obserwowalność są tym, co czyni to wykonalnym.
• Ewaluacja zastępuje „wygląda dobrze”. Udany zrzut ekranu mówi niewiele, gdy wyniki się zmieniają. Potrzebujemy sprawdzeń odpowiadających na realne pytania: czy system pobrał właściwą informację, wybrał odpowiednie narzędzie, przeszedł oczekiwany proces, uniknął nieuprawnionych twierdzeń i czy zawiódł bezpiecznie.
• Bezpieczeństwo jest częścią projektu produktu. Wstrzyknięcie promptu, ujawnienie wrażliwych danych, nadmiarowe uprawnienia i niebezpieczny dostęp do narzędzi to normalne ryzyka w systemach, które łączą modele z prywatnymi danymi i działaniami na zewnątrz. Muszą kształtować projekt od początku, a nie być doklejone po tym, jak agent zacznie działać.
• Człowiek zostaje w systemie. Produkcyjny agent nie powinien udawać autonomii, gdy decyzja niesie wagę biznesową, finansową, prawną albo reputacyjną. Najlepsze systemy ułatwiają ludziom przegląd, korektę, akceptację i zrozumienie tego, co się wydarzyło.

Cel nie polega na oddaniu kontroli modelowi. Polega na zbudowaniu oprogramowania, które pomaga ludziom przejść od intencji do wyniku bez rezygnacji z inżynierskiej odpowiedzialności po drodze.

O czym będziemy tu pisać

Ten blog to roboczy notatnik tej praktyki. Mniej szumu, więcej implementacji. Będziemy pisać o:

• generatywnym UI i interfejsach, które składają się wokół realnego zadania
• agentowych grafach ze stanem i o tym, jak debugować je bez zgadywania
• retrievalu, RAG-u i grafach wiedzy dla kontekstu, na którym agenty mogą polegać
• użyciu narzędzi, uprawnieniach, akceptacjach i projektowaniu human-in-the-loop
• obronie przed wstrzyknięciem promptu i granicach bezpieczeństwa danych wokół agentów
• ewaluacji, obserwowalności i wdrażaniu systemów agentowych tak, by dało się je utrzymać

Każdy tekst ma zostawić coś praktycznego: pomysł do przetestowania, wzorzec do ponownego użycia, kawałek kodu albo decyzję, która oszczędzi ci kosztownego błędu.