Architektura to nowy prompt engineering

Dwa zespoły. Ten sam model — Claude Sonnet, środkowa półka, koń roboczy 2026. To samo zadanie — analiza przychodzących kontraktów dla średniej firmy z branży usług profesjonalnych. Podobna struktura promptu: kilka tysięcy tokenów instrukcji, załączony kontrakt, prośba o ustrukturyzowane podsumowanie i flagi ryzyka.

Jeden z zespołów płaci za tę pracę 30 000 USD miesięcznie. Drugi płaci 400 USD.

Model identyczny. Prompt zasadniczo identyczny. Jakość wyniku jest, według wszystkich wewnętrznych benchmarków, jakie przeprowadziły obie firmy, nie do odróżnienia.

Różnicą jest architektura.

Drogi zespół pobiera każdy kontrakt w całości do modelu przy każdym zapytaniu, dosyła całą historię rozmowy przy każdej turze, nie ma warstwy cache, kieruje każde zapytanie do tego samego modelu niezależnie od złożoności i pozwala modelowi generować swobodną prozę, która od czasu do czasu nie przechodzi walidacji i trzeba ją ponawiać. Tani zespół pobiera tylko istotne fragmenty kontraktu, podsumowuje starsze tury, cache'uje stabilne instrukcje, łatwe zapytania kieruje najpierw do mniejszego modelu i wymusza ustrukturyzowane wyjścia.

To dezorientujący fakt o deploymentach AI w 2026: prompt rzadko jest wąskim gardłem. Wąskim gardłem jest system, w którym prompt siedzi. Kiedy raz się to zobaczy, ta obserwacja reorganizuje wiele innych obserwacji.

Era prompt engineeringu miała swój moment

Warto być sprawiedliwym wobec tego, skąd właśnie wyszliśmy.

Od późnego 2022 do mniej więcej połowy 2024 „prompt engineering” był właściwą dyscypliną, w którą warto było inwestować. Modele były niestabilne. Drobne zmiany w sformułowaniu dawały duże zmiany w wyniku. Praktycy, którzy rozumieli role, wyzwalacze chain-of-thought, formatowanie i subtelną sztukę zostawiania modelowi miejsca, by pomyślał, byli naprawdę pięciokrotnie skuteczniejsi od tych, którzy nie rozumieli.

Kursy z prompt engineeringu się sprzedawały. Pojawiały się ogłoszenia o pracę dla prompt engineerów. Pisano książki. Wyłonił się cały słownik — system prompts, few-shot examples, temperature, top_p, ReAct, tree-of-thought — i przez okno jakichś dwóch lat opanowanie tego słownika było wyróżnikiem.

To okno się zamknęło.

Modele stały się bardziej odporne. Drobne zmiany w sformułowaniach mają mniejsze znaczenie. Sprytne triki z 2023 są dziś wbudowane w domyślne zachowania modeli z 2026. Rozsądnie napisany prompt jest dziś „wystarczająco dobry” już na starcie, a krańcowa poprawa z dalszego majstrowania spłaszczyła się dramatycznie. Prompt engineer, który spędza tydzień, cyzelując sformułowania, produkuje może 5% wzrostu jakości wyników. Inżynier systemowy, który spędza tydzień nad architekturą, produkuje 95% redukcji kosztów i zauważalny wzrost jakości jednocześnie. To nie opinia. To matematyka tego, gdzie naprawdę siedzi dźwignia.

Co właściwie znaczy „architektura” w tym kontekście

To ta część systemu, która decyduje:

• Który model zobaczy to zapytanie.
• Która informacja ląduje w promcie, a która nie.
• Gdzie w promcie ta informacja siedzi — bo pozycja ma większe znaczenie, niż większość zespołów sobie zdaje sprawę.
• Co model ma wyemitować — swobodną prozę, JSON, function calls, ustrukturyzowane pola.
• Kiedy system cache'uje, retrievuje, podsumowuje, ponawia, spada na fallback albo kieruje na inną ścieżkę.
• Jak system ogranicza sam siebie — limity tokenów, sufity wywołań narzędzi, budżety na użytkownika, circuit breakery.

Żadna z tych decyzji nie dotyczy samego promptu. Dotyczą środowiska, w którym prompt działa.

Jeśli wyobrazisz sobie prompt jako zdanie, które zespół pisze dla modelu — architektura jest pokojem, w którym toczy się rozmowa, ludźmi, do których model może się zwrócić, dokumentami na półce, porą dnia, oświetleniem, regułą zakazującą siedzenia po 21:00. Zdanie wciąż się liczy. Ale to pokój decyduje, czy rozmowa jest tania i użyteczna, czy droga i chaotyczna.

Większość produkcyjnych systemów AI w 2026 to dobrze napisane zdania w źle zaprojektowanych pokojach.

Trzy znaki, że jesteś w źle zaprojektowanym pokoju

Nie musisz być technikiem, by je dostrzec. To instytucjonalne zapachy, które pojawiają się w każdym zespole, który podpiął AI bez przemyślenia systemu wokół niego.

Znak jeden — rachunek rośnie szybciej niż użycie.

Twoja funkcja AI nie zyskała czterokrotnie więcej użytkowników w tym kwartale, ale rachunek jest czterokrotnie wyższy. Gdzieś w środku puchnie kontekst, kumulują się pętle agentowe albo cicho mnożą się retry. Liniowy wzrost użycia powinien dawać liniowy wzrost rachunku. Jeśli Twój jest superliniowy — architektura przecieka.

Znak dwa — model staje się gorszy, im dłużej go używasz.

Użytkownicy zgłaszają, że chatbot po jakimś czasie „zapomina” instrukcji. Długie rozmowy degradują. Model zaprzecza sobie w 25 turze w sposób, w jaki nigdy nie zaprzeczyłby w 2. To empiryczny podpis promptu, który stał się zbyt długi, z kluczowymi instrukcjami zakopanymi pod nieistotną historią. To nie problem modelu. To problem architektury pamięci.

Znak trzy — nikt nie potrafi odpowiedzieć: „jaki jest najgorszy koszt jednego wywołania użytkownika?”

Jeśli najdroższe, co Twój system może zrobić w odpowiedzi na jedno działanie użytkownika, jest naprawdę nieznane — to gdzieś pętla, retry, wywołanie narzędzia albo ekspansja kontekstu może pobiec dalej, niż ktokolwiek zamierzał. Powód, dla którego większość zaskakujących rachunków na 50 000 USD jest zaskoczeniem, to ten, że zespół nigdy nie ograniczył najgorszego przypadku. Każdy z tych problemów da się naprawić. Żadnego z nich nie da się naprawić, dłubiąc w promcie.

Zmiana, która faktycznie się dzieje

Jeśli teraz obserwujesz rynek pracy w inżynierii, kształt zmiany jest widoczny. Tytuł „prompt engineer” zwija się w przyległe role. Nowe ogłoszenia to:

• AI architect. Projektuje system wokół promptu. Decyduje o routingu, cachingu, retrieval, fallback, observability.
• Context engineer. Posiada warstwę informacyjną — co wchodzi do promptu, w jakiej kolejności, z jaką kompresją. To nowa rola o wysokiej dźwigni.
• AI platform engineer. Buduje wewnętrzną infrastrukturę, dzięki której dobra architektura jest tania w zastosowaniu do wielu funkcji.
• AI FinOps. Kategoria, której osiemnaście miesięcy temu nie było. Posiada relację między wydatkami na AI a wynikami AI na poziomie organizacji.

To nie śmierć promptów. Prompty wciąż się liczą. Zmiana jest w tym, gdzie przesunęła się dźwignia. Dwa lata temu 5% wzrostu jakości promptu było realnym zwycięstwem. Dziś te same 5% to błąd zaokrąglenia siedzący na architekturze, która spala 80% budżetu na złym projekcie.

Ta zasada się uogólnia — i to jest większa historia

Oto część, którą większość artykułów o LLM przeocza.

Wzór „architektura bije rzemiosło na poziomie jednostki” nie jest wyjątkowy dla AI. To jeden z najstarszych wzorów w tym, jak działają dojrzałe branże, a AI jest po prostu kolejną dyscypliną, która do niego dorasta.

Mały przykład, którym żyję właśnie teraz: moja własna strona. Przez miesiące pracowałem ze swoim oprzyrządowaniem asystenckim nad budową nowych stron — nowa biblioteka zasobów, strona artykułu, sekcja speakerska. Każda strona była własnym małym projektem. Zdecyduj o layoucie. Zdecyduj o odstępach. Zdecyduj o kolorach. Zdecyduj o animacjach. Potem zrób to znowu w przyszłym miesiącu dla kolejnej strony. Wynik był w porządku; przepustowość niska; spójność dryfowała strona po stronie, bo nic nie zmuszało jej, by się zbiegła.

Znajomy z ostrzejszym wyczuciem systemów niż moje spojrzał na to i powiedział oczywiste, co przestałem widzieć:

„Przestań budować strony. Zbuduj komponenty, a potem składaj strony z komponentów”.

To oczywiste zdanie dla każdego, kto pracował w dojrzałym product engineering. To model komponentowy Reacta. To design system. To ten sam pomysł, na który Lego wpadło w 1949 roku. Ale zastosowane do jednoosobowej operacji, powiedziane na głos, uwidoczniło ten sam zwrot, który opisuje cały ten artykuł.

Nowa strona na moim serwisie nie jest już projektowana. Jest składana. Nowy zasób trafia w moduł <ResourceLibrary>. Nowy artykuł oprawia moduł <ArticleLayout>. Nowa sekcja składa się z <HeroSection>, <FeatureGrid>, <CallToAction>, <Newsletter>. Rzemieślnicze podejmowanie decyzji przesunęło się o jeden poziom wyżej — z „zaprojektuj tę stronę” na „zaprojektuj komponenty, z których zbudowane są strony”. Komponenty zostały zaprojektowane raz. Strony wyłaniają się z nich.

Praca nie zniknęła. Przesunęła się. A przesuwając się, skumulowała — bo każda nowa strona wychodzi teraz w dwadzieścia minut zamiast w trzy popołudnia.

Ten sam kształt jest w historii kosztu LLM. Pierwsza fala pracy z AI była rzemieślnicza — każdy prompt ręcznie wykuwany, każda funkcja podpinana indywidualnie, każdy zespół odkrywający te same wzory w odosobnieniu. Druga fala jest architektoniczna — warstwę routingu budujesz raz, warstwę cache raz, pipeline retrievalu raz, observability raz. Nowe funkcje składają się potem z tych komponentów. Model wciąż jest modelem. Prompt wciąż jest promptem. Ale architektura, w której siedzą, została zaprojektowana zamiast improwizowana, a różnica pokazuje się w każdym zestawieniu kosztów i każdej metryce jakości.

Co to dla Ciebie znaczy — zależnie od tego, kim jesteś

Jeśli prowadzisz strategię AI w organizacji

Najbliższe 18 miesięcy podzieli firmy na dwa obozy. Te, które zbudowały systemy, będą się kumulowały. Te, które polerowały prompty, dotrą do plateau. Koszt nadrabiania zaległości podwaja się z każdym kolejnym kwartałem, bo zmiana architektoniczna jest też zmianą rekrutacyjną, zmianą narzędziową i zmianą wiedzy organizacyjnej. Zacznij teraz.

Jeśli jesteś CISO lub CIO próbującym nadzorować adopcję AI

Przestań traktować wydatki na LLM jak wydatki na chmurę. Zachowują się inaczej. Kumulują się inaczej. Te same modele mogą produkować 100× rozrzutu kosztów w zależności od architektury, a ten rozrzut jest niewidoczny, dopóki ktoś po niego nie pójdzie. Zbuduj funkcję token-economics, choćby jednoosobową na start. Spłaci się w pierwszym kwartale.

Jeśli jesteś CFO lub partnerem finansowym pracującym z rachunkami za AI

Pytanie, które warto zadać, brzmi nie „ile wydaliśmy na tokeny w tym miesiącu?”. Pytanie brzmi „jaki jest nasz koszt na użyteczny rezultat i czy trenduje we właściwą stronę?” Na pierwsze pytanie odpowie faktura. Drugie pytanie wymaga architektury, observability i instrumentacji — a to wszystko są wskaźniki wyprzedzające, mówiące Ci, że zespół prowadzący Twoje AI wie, co robi.

Jeśli jesteś budującym

Prompt-craft wciąż jest użyteczny i wart znajomości. Ale następny duży punkt dźwigni kariery jest wyżej, ponad promptem. Naucz się routingu, cachingu, retrievalu, ustrukturyzowanych wyjść, ewaluacji, observability, governance budżetu. To są te kompetencje, które się kumulują. To te, które za dwa lata zapłacą Ci więcej niż kolejny miesiąc spędzony nad prompt guide'ami.

Jedno zdanie na pożegnanie

Pytanie „tanio czy drogo” w AI okazuje się być opakowaniem dla bardziej interesującego: na jakie informacje Twój system zwraca uwagę, kiedy i dlaczego?

Postaw to dobrze, a koszty same spadną. Postaw źle, a żadne dłubanie w promptach Cię nie uratuje.

Przyszłość pracy z AI to nie prompt engineering. Przyszłość to architektura informacji. Prompt wciąż jest zdaniem. Ale to pokój liczy się bardziej.