Następny kryzys kosztów AI nie dotyczy ceny modeli. Dotyczy marnowania kontekstu.

Buduję z AI od czterdziestu miesięcy. Właśnie zorientowałem się, że większość z tego robiłem na opak.

Każdy projekt, nad którym pracowałem przez ostatnie trzy lata, zaczynał się tak samo. Pusty prompt. Świeża prośba. „Zbuduj mi landing page”. „Naszkicuj tego maila”. „Wygeneruj ten artykuł”. Każda prośba — czysta karta. Każda rozmowa — nowa negocjacja. Każdy wynik — jednorazowy.

Działało. Mniej więcej. Ale model za każdym razem uczył się na nowo mojej marki. Od nowa decydował o odstępach, od nowa wybierał kolory, od nowa wymyślał głos. A ja płaciłem — w tokenach, w czasie, w uwadze — za tę naukę. Wciąż od początku.

Aż ktoś, z kim blisko pracuję, powiedział zdanie, które potrzebowało tygodni, by we mnie usiąść: Przestań budować. Zacznij komponować.

To zdanie jest, moim zdaniem, największą informacją o kosztach AI właśnie teraz. I nikt jej jeszcze nie nazywa po imieniu.

Drogi sposób, w jaki większość ludzi używa AI

Wejdź do prawie dowolnej firmy eksperymentującej z generatywnym AI i zobaczysz ten sam wzór. Każdy zespół niezależnie wpisuje promptami w ten sam model warianty tej samej pracy. Marketing ma swój prompt do opisów produktów. Sprzedaż ma swój prompt do outreachu. Customer support ma swój prompt do odpowiedzi na ticket. Każdy prompt dryfuje. Każdy wynik kosztuje pieniądze. Każdy nowy projekt startuje od zera.

Potem CFO widzi rachunek za API.

I tu prawie wszyscy źle diagnozują problem. CFO zakłada, że rachunek to problem cenowy. „Model jest za drogi. Potrzebujemy tańszego”. Procurement negocjuje stawki. CTO zmienia dostawcę. Zespół migruje z jednej rodziny modeli do innej, oszczędza dwadzieścia procent, a po sześciu miesiącach rachunek wraca tam, gdzie był.

Bo rachunek nigdy tak naprawdę nie dotyczył ceny. Dotyczył płacenia AI, raz za razem, za to, by uczyło się tych samych rzeczy od nowa. Za to, by od nowa rozumiało głos marki. Za to, by od nowa wyprowadzało decyzje o layoucie. Za to, by od nowa wymyślało strukturę strony, która już istniała w dwunastu lekko różniących się formach w całej organizacji.

AI nie jest drogie z powodu inteligencji. AI staje się drogie, gdy organizacje raz za razem płacą za to samo myślenie.

Programowanie już to rozwiązało — czterdzieści lat temu

Jeśli pracujesz w software wystarczająco długo, widziałeś ten kryzys w identycznej formie. Programowanie przeszło przez niego pod koniec lat siedemdziesiątych i na początku osiemdziesiątych.

Wtedy każdy program pisano ręcznie od zera. Każdą pętlę, każdy parser, każdy element UI. Jeśli chciałeś date pickera — pisałeś date pickera. Jeśli kolega potrzebował date pickera w innym projekcie — pisał własnego. Inny kod, ten sam problem, opłacony dwa razy.

Potem przyszły biblioteki. Potem frameworki. Potem package managery. Potem design systemy komponentowe. Potem mikroserwisy. Każdy z tych zwrotów był tym samym fundamentalnym ruchem: przestań rozwiązywać od zera, zacznij komponować z systemów. Pod koniec lat 90. żaden poważny inżynier nie pisał ręcznie hash mapy od zera. Pod koniec lat 2000. żaden poważny front-end developer nie pisał ręcznie date pickera. Koszt powtarzania rozwiązanej pracy stał się kulturowo nie do obronienia.

AI jest właśnie teraz mniej więcej tam, gdzie programowanie było około 1985 roku. Mamy nadzwyczajną nową zdolność i wciąż prosimy ją, by rozwiązywała wszystko od zera. Kulturowy zakaz marnotrawnego rozwiązywania w kółko tego samego jeszcze nie nadszedł. Biblioteki jeszcze się nie ukrystalizowały. Większość zespołów nie zorientowała się, że płaci na nowo za tę samą pracę.

Ale to się zmieni. Zawsze się zmienia. Epoka bibliotek AI dopiero się zaczyna, a firmy, które ruszą jako pierwsze, zaraz będą wyglądać bardzo inaczej niż te, które nie ruszą.

Jak właściwie wygląda komponowanie zamiast budowania

Ten zwrot brzmi abstrakcyjnie. Nie jest. Oto jak wygląda w praktyce.

Przed kompozycją. Prosisz model o stronę Resources. Myśli. Wybiera layout. Decyduje o tonie. Dobiera kolory zbliżone do Twojej marki, ale nie do końca trafione. Wymyśla CTA. Wynik jest okej. Poprawiasz. Wpisujesz prompt od nowa. Naprawiasz kolory. Spalasz tokeny i kończysz z czymś, co mgliście pasuje do Twoich innych stron, ale tak naprawdę nie.

Po kompozycji. Masz moduł Hero. Moduł FeatureGrid. Moduł Newsletter. Moduł CallToAction. Moduł ResourceLibrary. Każdy moduł został raz zaprojektowany, raz zdecydowany, raz zbrandowany. Kiedy potrzebujesz strony Resources — składasz:

HeroSection variant="standard" + FeatureGrid + ResourceLibrary + Newsletter + CallToAction

Model niczego nie projektuje. Układa znane klocki. Obciążenie rozumowaniem spada prawie do zera. Koszt tokenów spada wraz z nim. Wynik jest spójny z każdą inną stroną w serwisie, bo zbudowany z tych samych części. Marka nie dryfuje. Głos nie dryfuje. Rachunek nie balonuje.

I — tego prawie nikt nie zauważa — możesz wysłać nową stronę w dwadzieścia minut zamiast trzech godzin. Bo nie ma już negocjacji projektowej. Nie ma wymyślania od nowa. Jest tylko składanie.

Trzy miejsca, w których obserwuję to już w tym miesiącu

Chcę to czymś osadzić. To nie jest teoria. To zasada operacyjna trzech projektów, które buduję przez ostatnie sześćdziesiąt dni, i dopiero niedawno zauważyłem, że mają ten sam kształt.

Raz. Strona, na której to czytasz. Pierwotnie zbudowana jako osobne strony — Home, About, Services, Resources, Thinking, Contact, Newsletter — każda projektowana i iterowana niezależnie. Kilka tygodni temu zrefaktoryzowaliśmy ją do modułów. Teraz każda strona jest kompozycją. Dodanie nowej strony kosztuje dwadzieścia minut zamiast pół dnia, a marka zostaje spójna bez żadnej czujności z mojej strony.

Dwa. Cockpit decyzyjny, który zbudowałem do pracy redakcyjnej. Piszę fantasy sagę od czterech lat. Worldbuilding wygenerował czterdzieści osiem otwartych decyzji kanonicznych — backstory postaci, geograficzne zagadki, edycje manuskryptu — rozproszonych po dokumentach, rozmowach i notesach. Zamiast próbować je zapamiętać, zbudowałem cockpit. Każda decyzja to ustrukturyzowana karta z gotowymi opcjami, polem komentarza i statusem. Kiedy podejmuję decyzję, cockpit ją trzyma. Kiedy asystent AI dołącza do kolejnej sesji, odczytuje stan cockpita w jednym zapytaniu i wie dokładnie, co zostało rozstrzygnięte. Koniec z tłumaczeniem kanonu od nowa. Koszt tokenów: prawie zero. Spójność: prawie pełna.

Trzy. Sam kanoniczny worldbuilding. Lore sagi mieszka w ustrukturyzowanych dokumentach, po jednym na temat. Dokument o kontynencie. Dokument o rasie. Dokument o kosmologii. Kiedy nowy kawałek kanonu ma wylądować, trafia do odpowiedniego dokumentu. AI nie musi za każdym razem uczyć się tysiąca lat fikcyjnej historii — czyta odpowiedni moduł. Ten sam wgląd zastosowany do fikcji zamiast do kodu.

To trzy zupełnie różne powierzchnie — publiczna strona zawodowa, wewnętrzne narzędzie redakcyjne, korpus worldbuildingu. Czują się spójne, bo ta sama zasada operacyjna pojawia się we wszystkich trzech. Zbuduj system raz. Komponuj potem na zawsze.

Co to faktycznie robi z Twoim rachunkiem

Ekonomia jest prosta. Tryb kompozycji obniża trzy rzeczy jednocześnie.

Input tokens spadają, bo przestajesz wysyłać modelowi ten sam kontekst marki, ten sam voice guide, tę samą paletę kolorów przy każdej rozmowie. System już to ma w sobie zapisane.

Output tokens spadają, bo model nie generuje decyzji — układa komponenty. Mniej pracy kreatywnej do wykonania znaczy mniej rozwlekłego wyniku.

Reasoning tokens spadają (jeśli jesteś na modelu, który je eksponuje), bo jest mniej do przemyślenia. Wybory architektoniczne są już podjęte.

Zespoły, które widzę, że robią to dobrze, lądują gdzieś w okolicach 60–90 procent redukcji wydatków na AI w obciążeniach produkcyjnych, jednocześnie podnosząc spójność i jakość wyniku. Jeśli chcesz detalu operacyjnego — framework, którego używam z klientami, pięć realnych case studies, dwanaście pytań do zadania każdemu dostawcy AI — opisałem to w osobnym playbooku. Możesz pobrać bezpłatnie na /pl/free/token-economics.

Dlaczego historia kosztu ma większe znaczenie niż sam koszt

Powód, dla którego to ma znaczenie, to nie pieniądze. Pieniądze są objawem.

Głębszą rzeczą jest to, że przekroczyliśmy próg, którego większość organizacji jeszcze nie zauważyła. Pytanie nie brzmi już czy możemy to zbudować z AI. Pytanie brzmi która z wielu rzeczy, które budujemy, zasługuje na kolejną godzinę. To fundamentalnie inny problem.

Większość ludzi wyobraża sobie szczyt technologii — dowolnej technologii — jako moment, w którym wszystko jest skończone. W rzeczywistości szczyt to zwykle ten cichszy moment, w którym uświadamiasz sobie, że rzecz jest prawdziwa. Strona istnieje. Produkt istnieje. Książka istnieje. Zespół istnieje. Teraz przestajesz tworzyć za wszelką cenę i zaczynasz orkiestrować z intencją.

Marnowanie kontekstu to wygląd marnotrawnego tworzenia, kiedy kryzys tworzenia jest już rozwiązany. To współczesna wersja zespołu inżynierskiego z 1985, który wciąż ręcznie pisze hash mapy, choć biblioteki już istnieją. Da się tego uniknąć. Jest drogie. I za chwilę będzie kolejną rozmową, którą zespoły finansowe będą mieć ze swoimi liderami AI.

Jeśli chcesz wyprzedzić tę rozmowę, zacznij właśnie tam.