Bez hype'u

LLM to nie czarna skrzynka. Ścieżka od tekstu do odpowiedzi.

kontakt@bezhypeu.pl (Karol Dzwonkowski) — Fri, 20 Mar 2026 00:00:00 GMT

import Diagram from '../../components/Diagram.astro'; Prompt wchodzi, odpowiedź wychodzi. Większość użytkowników nie potrzebuje wiedzieć więcej. To klasyczny black box - system w którym widzisz co wchodzi i co wychodzi, ale nie wiesz co dzieje się w środku. Problem zaczyna się gdy model odpowiada błędnie. Gdy halucynuje. Gdy ten sam prompt daje dwie różne odpowiedzi. Bez choćby minimalnej wiedzy o tym jak działa LLM, każde z tych zachowań wygląda jak losowość, ułomność AI. Z tą wiedzą - to przewidywalne konsekwencje konkretnych mechanizmów. Kto traktuje LLM jak wszechwiedzącego rozmówcę, będzie rozczarowany. Kto rozumie co jest w środku - wie gdzie model zadziała, gdzie zawiedzie i dlaczego. ## Od tekstu do liczb LLM nie widzi tekstu. Widzi **tokeny**. Zanim prompt trafi do modelu, algorytm tokenizacji tnie go na fragmenty - korzystając ze słownika zbudowanego na danych treningowych. Im częściej fragment tekstu pojawia się w danych treningowych, tym większa szansa że dostanie własny token. "nie" = jeden token. "niepowtarzalność" = pięć tokenów: `nie`, `pow`, `tar`, `zal`, `ność`. Po tokenizacji każdy token zamienia się w **embedding** - wektor liczbowy w przestrzeni wielowymiarowej (GPT-3: 12 288 wymiarów, Llama 7B: 4 096). Tokeny o zbliżonym znaczeniu lądują blisko siebie w tej przestrzeni. "Król" w zdaniu o monarchii będzie bliżej "królowa" niż "stół" - model łapie kontekst znaczeniowy. Model nie rozumie znaczenia tych słów. Mierzy odległości matematyczne między wektorami - i to wystarcza żeby generować spójny tekst. Konsekwencje są konkretne. Polski tekst zużywa więcej tokenów niż angielski - tokenizer faworyzuje język treningowy. "123456" to dla modelu nie liczba a fragmenty tekstu - stąd błędy w arytmetyce. Ale embedding daje też coś za darmo: "samochód" i "auto" lądują blisko siebie w przestrzeni wektorowej - model łapie synonimię bez jawnych reguł. ## Transformer - silnik modelu Sercem każdego współczesnego LLM jest **transformer** - architektura która przetwarza tokeny równolegle, szukając relacji z wcześniejszymi. Każdy model na rynku - od GPT po Claude - jest zbudowany na tym samym fundamencie. Transformer to stos identycznych warstw ułożonych jedna na drugiej. Ich liczba waha się od kilkudziesięciu (Mistral 7B - 32) do ponad stu (Llama 3 405B - 126). Więcej warstw pozwala modelowi łapać bardziej abstrakcyjne wzorce - ale kosztuje więcej i odpowiada wolniej. W praktyce: prosty chat nie potrzebuje 126 warstw, ale analiza kontraktu prawnego już może. Każda warstwa zawiera dwa kluczowe bloki: 1. **Self-attention** (mechanizm uwagi) - każdy token "pyta" wszystkie wcześniejsze tokeny w kontekście jak bardzo są dla niego istotne i zbiera ich informacje proporcjonalnie do tej istotności. To tutaj model łapie relacje między odległymi fragmentami tekstu. Attention nie jest równomierny - tokeny na początku i końcu kontekstu dostają go więcej niż te w środku. Dlaczego tak się dzieje i co z tego wynika - opisuje [notatka o oknie kontekstowym LLM](/notes/okno-kontekstowe-llm). 2. **Feed-forward network (FFN)** (sieć przetwarzająca) - przetwarza każdy token osobno przez dwie warstwy z nieliniową funkcją aktywacji. FFN zawiera około dwóch trzecich wszystkich parametrów modelu. Tu przechowywana jest większość "wiedzy" - skojarzeń i wzorców wyuczonych z danych treningowych. Wcześniejsze warstwy uczą się prostszych wzorców - składnia, gramatyka. Głębsze - abstrakcji, semantyki, rozumowania. ## Skąd model "wie" cokolwiek Trening LLM ma jeden cel: **przewidywanie następnego tokenu**. Model dostaje sekwencję i uczy się który token powinien być następny. "Kot siedzi na" → "macie" z prawdopodobieństwem 73%, "kanapie" 12%, "dachu" 4%... Powtórz to biliony razy na ogromnym zbiorze tekstu - i model zaczyna generować spójne odpowiedzi. Dane treningowe to przede wszystkim internet: Common Crawl (surowe strony), Wikipedia, książki, repozytoria kodu z GitHuba, artykuły naukowe, social media. Skala jest trudna do wyobrażenia - [Llama 3](https://ai.meta.com/blog/meta-llama-3/) trenowano na ponad 15 bilionach tokenów. Dane są filtrowane (deduplikacja, usuwanie niskiej jakości treści, filtr języka), ale nikt nie czyta ich ręcznie token po tokenie. Jeśli w internecie dominuje błędna informacja na jakiś temat - model ją powtórzy. Dodatkowo warto mieć na uwadze cut-off date - moment w którym dane treningowe się kończą. Po tej dacie model nie wie nic. **Miliardy parametrów** (wag) modelu to wynik tego treningu. Parametr to jedna liczba - waga połączenia w sieci neuronowej. [GPT-3](https://arxiv.org/abs/2005.14165) ma ich 175 miliardów. Llama 3 405B - 405 miliardów. Trening to optymalizacja tych wag żeby model jak najlepiej przewidywał następny token. Po pretreningu model umie generować tekst, ale nie umie odpowiadać na pytania ani odmawiać niebezpiecznych próśb. Do tego służy **post-training**: model jest dalej trenowany na parach instrukcja-odpowiedź (supervised fine-tuning), a następnie dostrajany na ludzkich lub AI preferencjach żeby był pomocny i bezpieczny. OpenAI używa [RLHF](https://arxiv.org/abs/2203.02155) (uczenie ze wzmocnieniem z feedbacku ludzkiego). Anthropic opracował [Constitutional AI](https://arxiv.org/abs/2212.08073) - model sam się krytykuje według zdefiniowanych zasad, potem jest trenowany na własnych poprawkach. ## Jak model odpowiada Generowanie jest **autoregresyjne**: model produkuje jeden token na raz. Każdy wygenerowany token jest dołączany do kontekstu i model oblicza następny. Token po tokenie aż do końca odpowiedzi. Model nie planuje odpowiedzi z góry - nie wie jak zakończy zdanie gdy zaczyna je pisać. Przy generowaniu każdego tokenu model oblicza prawdopodobieństwo dla całego słownika, a który token zostanie wybrany zależy od strategii. Najważniejszy parametr to **temperatura** - reguluje czy model trzyma się pewnych odpowiedzi (niska) czy eksploruje mniej oczywiste (wysoka). Stąd ten sam prompt przy różnej temperaturze daje różne odpowiedzi. | Strategia | Jak działa | Efekt | |-----------|-----------|-------| | Greedy | Zawsze najwyższe prawdopodobieństwo | Deterministyczny, powtarzalny, nudny | | Temp. < 1 | Najbardziej prawdopodobne tokeny zyskują jeszcze większą przewagę | Bardziej przewidywalny, "bezpieczny" | | Temp. > 1 | Mniej oczywiste tokeny dostają wyższe szanse | Bardziej kreatywny, ryzyko bzdur | | Top-p (nucleus) | Wybiera z najmniejszego zbioru tokenów przekraczającego próg p | Adaptuje się do kontekstu | ## Czego w pudełku nie ma LLM nie myśli, nie pamięta i nie rozumie. Przewiduje następny token na podstawie statystycznych wzorców wyuczonych z miliardów tekstów. To nie jest uproszczenie - to opis mechanizmu. Z tego wynika kilka twardych ograniczeń: - **Brak pamięci trwałej.** Model nie pamięta poprzednich rozmów. Każda sesja zaczyna się od zera - "pamięć" to wyłącznie aktualny kontekst. - **Brak dostępu do świata zewnętrznego.** Model nie sprawdza internetu, nie wykonuje kodu, nie łączy się z bazami danych. Odpowiada wyłącznie na podstawie wag wyuczonych w treningu i aktualnego kontekstu. - **Brak weryfikacji faktów.** Model generuje tekst który jest *statystycznie prawdopodobny*, nie tekst który jest *prawdziwy*. Stąd halucynacje - model nie kłamie, bo nie ma pojęcia prawdy. Generuje ciąg dalszy który pasuje do wzorca. - **Brak planowania.** Odpowiedź powstaje token po tokenie bez planu całości. Model nie wie jak zakończy akapit gdy pisze pierwsze zdanie. Te ograniczenia nie są błędami do naprawienia w następnej wersji. To konsekwencje architektury - systemu który zamienia tekst na liczby, przetwarza je przez warstwy transformera i generuje następny token. Nic więcej. Dlatego wokół LLM wyrósł cały ekosystem narzędzi. Function calling pozwala modelowi wywoływać zewnętrzne funkcje. MCP (Model Context Protocol) standaryzuje dostęp do narzędzi i źródeł danych. Orkiestracja pozwala łączyć model z kodem, bazami, API. Sam model to generator tekstu - dopiero w połączeniu z narzędziami staje się czymś więcej. ## Czy to AI - czy interfejs nowej generacji? Klawiatura, ekran dotykowy, głos - każda generacja interfejsów zmieniała sposób komunikacji z maszyną. LLM jest może pierwszym w którym komunikacja odbywa się w języku naturalnym, bez translacji na polecenia czy gesty. Czy to AI - czy interfejs nowej generacji? --- *W newsletterze rozwijam tego rodzaju tematy głębiej. [Zapisz się.](https://bezhypeu.pl/newsletter)*

LLM to nie cała scena AI. Co jest w cieniu?

kontakt@bezhypeu.pl (Karol Dzwonkowski) — Sun, 15 Mar 2026 00:00:00 GMT

10 marca 2026 Yann LeCun - laureat nagrody Turinga, były główny naukowiec AI w Meta - zamknął rundę seed o wartości 1,03 miliarda dolarów na [AMI Labs](https://amilabs.xyz/). Firma nie buduje kolejnego chatbota. Buduje [world models](https://www.technologyreview.com/2026/01/22/1131661/yann-lecuns-new-venture-ami-labs/) - systemy AI, które rozumieją fizyczny świat zamiast generować tekst. Miliard dolarów na tezę, że LLM to nie jest droga do inteligentnych systemów AI. > "Będziemy mieli systemy AI na poziomie ludzkiej inteligencji, ale nie zostaną zbudowane na LLM-ach. Potrzebne są fundamentalne przełomy konceptualne. I właśnie na tym skupia się AMI Labs." > > — Yann LeCun, [MIT Technology Review](https://www.technologyreview.com/2026/01/22/1131661/yann-lecuns-new-venture-ami-labs/) (tłum. własne) To nie jest pozycja outsidera. To kontrariański zakład jednego z trzech ludzi, których praca stworzyła fundament pod obecną rewolucję AI. I niezależnie od tego, czy LeCun ma rację co do przyszłości - jego obserwacja o teraźniejszości jest trudna do podważenia. **LLM dominuje narrację. Nie dominuje zastosowań.** ## Dlaczego LLM zjadł scenę LLM ma coś, czego inne typy AI nie mają: prostotę użytkowania. Nie trzeba rozumieć tensorów, funkcji straty ani architektury sieci. Wystarczy pisać. To sprawia, że LLM jest jedynym typem AI, który ludzie potrafią użyć bez instrukcji. Rozmowa z ChatGPT wygląda jak rozmowa z innym człowiekiem. Wykres treningu sieci neuronowej wygląda jak [kolorowa tapeta](https://jtuckerk.github.io/loss_landscape.html). Efekt jest przewidywalny. "AI" w publicznym dyskursie praktycznie równa się "LLM". Kiedy firma ogłasza "wdrożenie AI", domyślnie oznacza to chatbota lub asystenta tekstowego. Kiedy ktoś mówi "AI zabierze ci pracę", myśli o modelu, który generuje tekst, kod albo obrazy. Tymczasem większość realnych zastosowań AI nie polega na generowaniu tekstu. LLM dominuje narrację, ale na scenie AI gra znacznie więcej aktorów - i w swoich dziedzinach miażdżą LLM. ## Typy AI poza LLM | Typ AI | Co robi | Dlaczego nie LLM | |--------|---------|------------------| | **Reinforcement Learning** | Uczy się podejmować sekwencje decyzji metodą prób i błędów | LLM generuje tekst, nie podejmuje decyzji w środowisku z feedbackiem | | **World Models** | Buduje wewnętrzną reprezentację fizycznego świata | LLM operuje na tokenach tekstu, nie rozumie fizyki, przestrzeni ani ruchu | | **Computer Vision** | Rozpoznaje, segmentuje i analizuje obraz | LLM nie operuje natywnie na pikselach - CV jest szybsze i tańsze | | **Diffusion Models** | Generuje obrazy, wideo i audio z szumu | LLM generuje token po tokenie, diffusion operuje na danych ciągłych | | **Graph Neural Networks** | Analizuje dane w formie grafów - relacje, sieci, struktury | LLM widzi sekwencję tokenów, nie widzi struktury połączeń między danymi | | **Systemy rekomendacyjne** | Przewiduje co użytkownik chce zobaczyć, kupić, posłuchać | LLM nie jest zoptymalizowany do miliardów predykcji w czasie rzeczywistym | | **Klasyczne ML** | Prognozuje na danych tabelarycznych | LLM jest wielokrotnie droższy i gorszy na danych strukturalnych | To nie jest lista technologii przyszłości. Każda z nich wpływa bezpośrednio na nasze życie tu i teraz. ## Gdzie te modele już działają Reinforcement learning steruje ramionami robotów w magazynach Amazona - [multi-agent RL](https://www.amazon.science/publications/multi-agent-reinforcement-learning-for-resource-allocation-in-large-scale-robotic-warehouse-sortation-centers) optymalizuje sortowanie paczek na setkach agentów jednocześnie. DeepMind użył RL do chłodzenia centrów danych Google'a i [obniżył zużycie energii na chłodzenie o 40%](https://deepmind.google/blog/deepmind-ai-reduces-google-data-centre-cooling-bill-by-40/). Computer vision ma blisko [400 algorytmów zatwierdzonych przez FDA do radiologii](https://www.scispot.com/blog/ai-diagnostics-revolutionizing-medical-diagnosis-in-2025) - praktycznie wszystkie oparte na sieciach konwolucyjnych i architekturach wizyjnych. Systemy rekomendacyjne to prawdopodobnie najszerzej wdrożony typ AI, o którym nikt nie mówi - miliardy decyzji dziennie w Netflix, Spotify, Amazonie i TikToku. Graph Neural Networks analizują struktury połączeń - NVIDIA i Amazon wdrożyły je do [wykrywania fraudu w sieciach transakcji bankowych](https://developer.nvidia.com/blog/supercharging-fraud-detection-in-financial-services-with-graph-neural-networks/), a firmy farmaceutyczne używają ich do [przyspieszania odkrywania leków](https://www.nature.com/articles/s41598-024-83090-3). Diffusion models generują obrazy w Midjourney i Stable Diffusion, ale to tylko najbardziej widoczne zastosowanie - ta sama architektura [projektuje struktury molekularne](https://pubs.acs.org/doi/10.1021/acs.jcim.4c01107) i [syntetyzuje mowę](https://developer.nvidia.com/blog/speeding-up-text-to-speech-diffusion-models-by-distillation/). Klasyczne ML? Scoring kredytowy, prognozowanie popytu, underwriting w ubezpieczeniach, predykcja awarii w fabrykach. [Benchmarki](https://arxiv.org/html/2408.14817v1) pokazują to samo od lat: na danych tabelarycznych XGBoost bije modele deep learning - szybciej, taniej i dokładniej. ## Zakład LeCuna: world models zamiast LLM AMI Labs buduje architekturę [JEPA](https://www.latent.space/p/ainews-yann-lecuns-ami-labs-launches) (Joint Embedding Predictive Architecture) - podejście, które zamiast generować dane token po tokenie, uczy się przewidywać reprezentacje przyszłych stanów świata. Innymi słowy: zamiast pisać opis tego, co widzi, model buduje wewnętrzny model rzeczywistości. LeCun argumentuje, że LLM-y operują na tokenach tekstu i z definicji nie są w stanie zrozumieć fizycznego świata - ciągłego, wielowymiarowego, nieprzewidywalnego. Tekst to skompresowana, wysoce zredukowana wersja rzeczywistości. Budowanie inteligencji na samym tekście to jak próba zrozumienia miasta na podstawie samych nazw ulic. Czy ma rację? Za wcześnie, żeby ocenić. JEPA to wciąż architektura badawcza, a miliard dolarów nie gwarantuje przełomu. Ale pokazuje coś innego: przesłonięcie reszty AI przez LLM może być chwilowe. Inwestorzy już patrzą dalej. Ale to nie znaczy, że LLM jest zbędny. Żaden inny model nie pisze kodu, nie tłumaczy i nie analizuje dokumentów tak jak on. W swojej dziedzinie jest niezastąpiony. Tyle że to jedna dziedzina - a zajęła 90% wyobraźni branży. ## Pytanie, które zostaje Jeśli większość zastosowań AI nie wymaga LLM - co tak naprawdę kupujesz, kiedy "wdrażasz AI w swoim biznesie"? --- *W newsletterze rozwijam tego rodzaju tematy głębiej. [Zapisz się.](https://bezhypeu.pl/newsletter)*

Jak mierzysz czy prompt działa, gdy nie ma poprawnej odpowiedzi?

kontakt@bezhypeu.pl (Karol Dzwonkowski) — Sun, 15 Mar 2026 00:00:00 GMT

Brand Deals ma póki co dwie operacje AI: - parsowanie przychodzących emaili od marek - generowanie odpowiedzi negocjacyjnych Obie korzystają z tego samego systemu promptów - modularnego pipeline'u, który składa prompt z warunkowych bloków (kontekst deala, historia korespondencji, instrukcje per akcja, schemat outputu). Obie operacje wyglądają podobnie od strony kodu. Od strony ewaluacji to dwa różne światy. ## Parsowanie ma poprawną odpowiedź Marka pisze: "Budżet 5000 PLN, deadline 15 kwietnia, potrzebujemy 2 rolki na TikToku i 1 post na Instagramie." Parser dostaje ten email i zwraca strukturyzowane dane - kwota, waluta, data, lista deliverables z platformami. Testowanie jest proste. Biorę odpowiedź, parsuję na obiekt ze ścisłym schematem i sprawdzam czy wyciągnął to co powinien. Kwota 5000? Waluta PLN? Dwa deliverables TikTok, jeden Instagram? Każde pole ma binarną odpowiedź: albo trafiło, albo nie. Mogę to zautomatyzować, mogę budować zbiory testowe, mogę porównywać modele na tych samych danych. Co więcej - do parsowania nie potrzebuję drogiego modelu. GPT-4.1 nano wystarczy. Zadanie jest ograniczone, output to JSON z typami pól, a kontekst jednoznaczny. Przy dobrze skonstruowanym prompcie tańszy model daje te same wyniki co droższy. ## Generowanie nie ma poprawnej odpowiedzi Użytkownik klika "Negocjuj warunki" - system ma wygenerować email, który odnosi się do historii korespondencji, uwzględnia aktualne warunki deala i proponuje zmiany w konkretnych polach. Prompt składa się z bloków: rola, zasady krytyczne, akcja (accept/counter/decline/ask_info), ton, długość, język, kontekst deala, wartości pól, historia korespondencji, schemat outputu. Wynik? Email. Mogę go przeczytać i ocenić: brzmi naturalnie? Odnosi się do kontekstu? Nie halucynuje danych, których nie ma w dealu? Ale "brzmi naturalnie" to subiektywna ocena. Nie mam binarnej odpowiedzi. Nie mogę powiedzieć "ten email jest poprawny w 87%". I tu zaczyna się problem. Dodaję nowy blok do prompta - na przykład kontekst deliverables albo informację o niezapłaconych transzach. Generuję email. Czytam. Wygląda ok. Ale czy jest lepszy niż bez tego bloku? Nie wiem. Nie mam czym zmierzyć. ## Trzy podejścia do ewaluacji generowania ### A: Ręczna ocena Czytam wygenerowany email. Oceniam. To jest moje obecne podejście i jedyne, które działa od pierwszego dnia. Problem: nie skaluje się. Przy jednej operacji AI mogę przeczytać każdy wynik. Przy pięciu - już nie. Przy produkcyjnym ruchu - fizycznie niemożliwe. ### B: Proxy przez parsowanie Pomysł: wygenerowany email przepuszczam przez ten sam parser, którego używam do emaili przychodzących. Sprawdzam czy wygenerowana odpowiedź zawiera elementy, które powinna - potwierdzenie kwoty, odniesienie do deliverables, brak danych których nie ma w dealu. To mierzy strukturę i obecność informacji. Parsowanie wygenerowanego emaila powie mi czy model wspomniał o kwocie 5000 PLN, czy odniósł się do deadline'u, czy nie wymyślił deliverables których nie ma. To już coś - automatyczny test, który łapie halucynacje i pominięcia. Ale nie mierzy tonu. Nie mierzy czy email brzmi jak profesjonalna korespondencja czy jak wygenerowany tekst. Nie mierzy czy "negocjuj warunki" faktycznie negocjuje, czy tylko grzecznie prosi. To podejście właśnie zaimplementowałem. ### C: LLM-as-a-judge Pytam inny model: "Oceń ten email pod kątem naturalności, kompletności i zgodności z akcją." Daję mu rubrykę, kryteria, skalę. Temat jest gorący - LLM-as-a-judge ma już dedykowane badania ([survey na arXiv](https://arxiv.org/abs/2411.15594), [paper na ICLR 2025](https://proceedings.iclr.cc/paper_files/paper/2025/file/08dabd5345b37fffcbe335bd578b15a0-Paper-Conference.pdf)), frameworki ([Langfuse](https://langfuse.com), [DeepEval](https://deepeval.com)) i ustalone praktyki. Kluczowe pytanie: **Czy niedeterministyczny system może wiarygodnie ocenić inny niedeterministyczny system?** Badania mówią: tak, ale warunkowo. Binarne oceny ("czy email wspomina o kwocie: tak/nie") są bardziej wiarygodne niż skalowe ("oceń naturalność od 1 do 5"). Chain-of-thought prompting - wymuszenie na judge'u rozumowania krok po kroku zamiast jednej oceny - stabilizuje wyniki. A LLM-judge nie musi być idealny - wystarczy, że jest spójny. Jego rola to łapanie regresji między wersjami prompta, nie absolutna ocena jakości. Póki co nie przetestowałem tego podejścia w praktyce. Istnieje jako opcja z dużym potencjałem, ale dopóki nie zweryfikuję jego wiarygodności ręcznie - na kilkudziesięciu przykładach, porównując oceny judge'a z moimi - to pozostaje pomysłem. ## Decyzja Zaczynałem od A - ręczna ocena każdego wyniku. Szybko okazało się, że to za mało. Zaimplementowałem B (proxy przez parsowanie), które przynajmniej częściowo automatyzuje walidację promptów. Ale nadal nie odciąża mnie od czytania i oceny zwróconych tekstów - przy intensywnym testowaniu bloków prompta to wąskie gardło. C mógłby to rozwiązać. Każdy kolejny poziom łapie inną warstwę. Parsowanie łapie halucynacje i pominięcia. LLM-judge mógłby łapać ton i naturalność. Ręczna ocena zostaje jako ostatnia instancja - ale tylko dla edge case'ów, nie dla każdego wygenerowanego emaila. ## Obserwacja: model vs kontekst Parsowanie dało mi jeszcze jedną lekcję. Instynktownie sięgnąłem po droższy model - bo wydawało się, że ekstrakcja danych z nieustrukturyzowanego emaila to złożone zadanie. Okazało się, że GPT-4.1 nano z dobrym promptem wystarczy. Kluczowe było to, że zbudowałem PromptDebugPanel - deweloperski panel w aplikacji, który pozwala włączać i wyłączać konkretne bloki prompta, zmieniać ich kolejność i edytować cały prompt ręcznie. Widzę bezpośredni wpływ każdego bloku na wynik. Wyłączam blok z definicjami pól - parser zaczyna zgadywać typy. Włączam z powrotem - wraca do normy. Przy generowaniu ta sama logika się rozbija. Mogę włączać i wyłączać bloki, ale nie mam czym zmierzyć "wpływ na wynik". Widzę że email się zmienił. Nie wiem czy jest lepszy. [Lepszy kontekst](/notes/okno-kontekstowe-llm) pomaga - mniej halucynacji, trafniejsze odniesienia do warunków deala. Ale brzmienie emaila to granica, której tani model nie przeskakuje. Negocjacyjny email wygenerowany przez GPT-4.1 nano brzmi jak wypracowanie. Ten sam prompt na mocniejszym modelu brzmi jak korespondencja. ![PromptDebugPanel - deweloperski panel do testowania bloków prompta](/images/dev-diary/prompt-debug-panel.png) Panel do debugowania promptów w projekcie Brand Deals. ## Czy to overengineering? Pisałem o [architekturze "na wyrost" w MVP](/budowanie/architektura-na-wyrost-w-mvp) - o tym, że budowałem infrastrukturę zanim miałem użytkowników. System modularnych bloków promptów z warunkami, priorytetami, sekcjami, dev overrides i panelem debugowym - to nie jest prosty prompt. To jest mały silnik. Czy wpadłem w tę samą pułapkę? Może. Mógłbym mieć jeden string template z if-ami zamiast pipeline'u z blokami. Ale jest różnica. Pełny CI/CD pipeline był "na wyrost" wobec produktu bez użytkowników. System promptów - chyba nie. Parsowanie i generowanie to nie feature'y dodane do aplikacji - to właśnie jest aplikacja. Jeśli nie potrafię iterować promptów szybko, nie potrafię iterować produktu. Czy to wystarczające uzasadnienie? Zobaczę za miesiąc. --- *W newsletterze rozwijam tego rodzaju tematy głębiej. [Zapisz się.](https://bezhypeu.pl/newsletter)*

Okno kontekstowe LLM mierzy pojemność. Nie mierzy uwagi.

kontakt@bezhypeu.pl (Karol Dzwonkowski) — Thu, 12 Mar 2026 00:00:00 GMT

*"1 milion tokenów kontekstu. AI widzi cały Twój projekt naraz. Nie musisz już nic tłumaczyć."* Taki przekaz pojawia się w materiałach marketingowych narzędzi AI od 2024 roku - w mniej lub bardziej dosłownej formie. Brzmi jak konkretna obietnica. Technicznie prawdziwa. W praktyce myląca. ## Skąd to wyobrażenie Okno kontekstowe jest powszechnie tłumaczone jako "przestrzeń robocza modelu" albo "ilość tekstu, którą model może zapamiętać i rozważyć". Obie metafory sugerują to samo: kontekst to pojemnik, model go "widzi", a większy pojemnik oznacza głębsze rozumienie. Ta intuicja jest spójna. Problem w tym, że model językowy (LLM) nie przetwarza kontekstu tak jak człowiek czyta dokument - równomiernie, od pierwszej do ostatniej linijki. Bliższa analogia: wyobraź sobie rozmowę która trwa trzy godziny. Pytasz rozmówcę co zapamiętał. Powie Ci kontekst z początku i końca rozmowy. Fakty poruszone w środku trudno mu będzie precyzyjnie odtworzyć. Nie dlatego że zabrakło czasu żeby dokładnie omówić środkowe fragmenty - tylko dlatego że tak działa ludzka uwaga w czasie. ## Jak model naprawdę przetwarza kontekst Sercem każdego modelu LLM jest transformer - jego celem jest analiza relacji między wszystkimi fragmentami tekstu **jednocześnie**. Każdy token "decyduje" ile uwagi poświęcić pozostałym tokenom w kontekście. Ta uwaga nie jest równomierna. Rozmiar okna kontekstowego odpowiada na pytanie: ile tokenów model przyjmie. Nie odpowiada na pytanie: jak model rozłoży uwagę na to, co dostał. To dwa różne pytania z różnymi odpowiedziami. W 2023 roku badacze ze Stanford, UC Berkeley i Samaya AI opublikowali pracę ["Lost in the Middle: How Language Models Use Long Contexts"](https://direct.mit.edu/tacl/article/doi/10.1162/tacl_a_00638/119630/Lost-in-the-Middle-How-Language-Models-Use-Long). Eksperyment był prosty. Model dostaje zestaw dokumentów. Tylko jeden zawiera właściwą odpowiedź, a jego pozycja w kontekście jest przesuwana. Wynik: krzywa w kształcie litery U. Dokładność jest wysoka gdy istotna informacja jest na początku kontekstu. Wysoka gdy jest na końcu. Dramatycznie spada gdy informacja ląduje w środku. Wzorzec powtórzył się we wszystkich badanych modelach, niezależnie od architektury i rozmiaru okna. ![Dokładność odpowiedzi 6 modeli LLM w zależności od pozycji dokumentu z odpowiedzią w kontekście (20 dokumentów, ~4K tokenów). Wszystkie modele pokazują spadek dokładności gdy istotna informacja znajduje się w środku kontekstu.](/images/notes/lost-in-middle-porownanie-modeli.webp) *Źródło: Liu et al. (2024), ["Lost in the Middle"](https://direct.mit.edu/tacl/article/doi/10.1162/tacl_a_00638/119630/Lost-in-the-Middle-How-Language-Models-Use-Long), TACL / MIT Press. Licencja CC BY 4.0.* ## Dlaczego transformer gubi środek kontekstu MIT w 2025 roku zidentyfikował dwie przyczyny architekturalne tego efektu. **Causal attention masking** (maskowanie uwagi przyczynowej). Transformer - architektura leżąca u podstaw modeli LLM - generuje tekst od lewej do prawej. Token #1 jest widoczny dla każdego kolejnego tokenu w sekwencji. Token #500 - już tylko dla tokenów od #501 wzwyż. Wcześniejsze tokeny kumulują więcej uwagi nie dlatego, że model "uznaje je za ważniejsze" - ale dlatego, że architektura daje im statystycznie więcej okazji do bycia uwzględnionym przy generowaniu odpowiedzi. **Positional encoding decay** (zanikanie kodowania pozycyjnego). Modele używają kodowania pozycyjnego opartego na odległości między tokenami (technika zwana RoPE). Tokeny daleko od siebie mają naturalnie zredukowaną siłę uwagi. Tokeny na końcu kontekstu są blisko miejsca generowania odpowiedzi - silne połączenie. Tokeny na początku utrzymują uwagę przez osobny mechanizm zwany "attention sinks". Tokeny w środku: za daleko od początku, za daleko od końca. Martwa strefa. To nie jest błąd konkretnego modelu. To właściwość architektury transformera - obecna we wszystkich aktualnych modelach produkcyjnych. Konsekwencja jest prosta: im więcej treści wrzucasz do kontekstu, tym więcej "środka" tworzysz. Szum w kontekście nie jest neutralny - fizycznie wypycha istotne informacje w stronę strefy z najsłabszą uwagą. ## Jak nie stracić informacji w środku kontekstu Skoro uwaga modelu nie jest równomierna, z mechanizmu wynikają konkretne zasady - nie jako instrukcja obsługi narzędzia, ale jako konsekwencje architektury: | Zasada | W praktyce | |--------|------------| | Pozycja ma znaczenie | Ważne informacje idą na początek lub koniec kontekstu, nie "gdziekolwiek pasuje" | | Precyzja > objętość | Mniejszy, dobrze dobrany kontekst bije duży, zaszumiony - więcej środka to więcej strat | | Struktura pomaga | Nagłówki, sekcje, tagi pomagają modelowi identyfikować co jest czym nawet przy zredukowanej uwadze | Anthropic - producent Claude - w [materiałach inżynieryjnych z 2025 roku](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents) nie skupia się na rozmiarze okna. Używa terminu "context engineering" i definiuje problem jako optymalizację użyteczności tokenów - nie ich liczby. Rozmiar okna to specyfikacja. Jakość kontekstu to osobny problem. ## Granica między pojemnością a jakością - Anthropic w [ogłoszeniu 100K okna](https://www.anthropic.com/news/100k-context-windows): *"dropping an entire codebase into the context."* - Google o [Gemini Code Assist](https://blog.google/intl/en-ca/products/cloud/get-coding-help-from-gemini-code-assist-now-for-free/): *"understand our entire codebase."* - OpenAI o [GPT-4.1](https://openai.com/index/gpt-4-1/): *"1 million tokens - more than 8 copies of the entire React codebase."* Trzej główni gracze, ta sama obietnica: wrzuć wszystko, model zrozumie. Mechanizm mówi co innego. Więcej treści w kontekście to więcej środka. Więcej środka to więcej martwej strefy. Im więcej "wrzucasz na wszelki wypadek", tym większa szansa że to co naprawdę ważne utonie w środku - tam, gdzie model prawie nie patrzy. Duże okno nie gwarantuje dobrego kontekstu. Gwarantuje tylko, że więcej treści zmieści się w strefie z najsłabszą uwagą. --- *Więcej o tym jak zarządzać kontekstem w praktyce - w newsletterze. [Zapisz się.](https://bezhypeu.pl/newsletter)*

Pierwszy użytkownik jest ważniejszy niż pierwszy feature

kontakt@bezhypeu.pl (Karol Dzwonkowski) — Thu, 05 Mar 2026 00:00:00 GMT

Ile feature'ów ma Twój produkt? A ilu użytkowników? Jeśli pierwsza liczba jest większa od drugiej - nie budujesz produktu. Budujesz zakłady. ## Feature przed użytkownikiem to zakład Każdy feature zbudowany przed pierwszym użytkownikiem to zakład. **Nie inwestycja** - bo inwestycja zakłada znany zwrot. Tu nie wiadomo nawet czy problem istnieje poza głową twórcy. To nie znaczy, że zakład jest zły. Każdy produkt zaczyna się od zakładu. Problem zaczyna się, gdy zakładów jest dwadzieścia i żaden nie został sprawdzony. [Granica MVP dryfuje](/notes/mvp-granica-umowna) bo każdy kolejny feature "brzmi sensownie". [Produkt odpowiada na wizję twórcy](/notes/produkt-odpowiada-na-pytanie-uzytkownika) bo twórca sam formułuje pytanie i sam na nie odpowiada. Za każdym razem ten sam mechanizm: budowanie bez zewnętrznej weryfikacji. ## Kumulacja zakładów **Jeden zakład to ryzyko. Dziesięć zakładów to architektura której nikt nie zamówił.** Im więcej zbudujesz przed pierwszym użytkownikiem, tym trudniej cokolwiek wyrzucić. Nie dlatego że kod jest zły - dlatego że się do niego przywiązałeś. **Sunk cost nie jest finansowy. Jest emocjonalny.** Dwa tygodnie pracy nad systemem dynamicznych pól sprawiają, że zaczynasz go uzasadniać zamiast pytać czy jest potrzebny. Bronisz to co masz, zamiast zapytać czy ktoś tego potrzebuje. ## "Jeszcze tylko to jedno i pokażę" Jest taki moment w budowaniu, gdy wiesz że powinieneś pokazać produkt komuś z zewnątrz. I dokładnie wtedy pojawia się myśl: *"jeszcze tylko ten jeden feature"*. "Gotowy" nie istnieje dopóki ktoś nie zobaczy produktu. Ale żeby poczuć się gotowym - budujesz dalej. Kolejny feature, kolejne poprawki, kolejny tydzień. Moment konfrontacji się oddala, lista zakładów rośnie - a twórca nie wychodzi ze strefy komfortu. Budowanie jest bezpieczne. Konfrontacja - nie. Kodowanie daje widoczny postęp - commity, endpointy, strony. Rozmowa z użytkownikiem daje niepewność. Więc domyślnie wybierasz kod i nazywasz to *przygotowaniem*. ## Jeden użytkownik zamienia zakłady w dane Jeden użytkownik to nie sukces. To **zderzenie z rzeczywistością**. "Nie potrzebuję." "Bardzo pomocne." "Widziałem już coś takiego u konkurencji." "Wow, zrobiłeś to lepiej niż..." Obojętnie co usłyszysz - każda reakcja wypłaca zakłady. Jedne wygrywasz, inne przegrywasz. Ale dopóki nie postawisz produktu przed kimś z zewnątrz, kupony leżą niesprawdzone. [Pytanie użytkownika jest filtrem](/notes/produkt-odpowiada-na-pytanie-uzytkownika) - definiuje co produkt musi robić. Ale żeby usłyszeć to pytanie, trzeba najpierw postawić coś przed użytkownikiem. Nie "gotowy produkt". Coś. Cokolwiek co pozwoli mu zareagować. [Architektura "na wyrost"](/budowanie/architektura-na-wyrost-w-mvp) zjada czas który miał iść w dotarcie do tego pierwszego użytkownika. Każdy dzień budowania bez konfrontacji to kolejny zakład na stosie. ## Ile zakładów jesteś gotów postawić? - Feature'y da się dobudować. - Architekturę da się zmienić. - Stack da się przepisać. Ale czasu spędzonego na budowaniu czegoś, czego nikt nie potrzebuje, nie da się odzyskać. > Pytanie nie brzmi "czy mój produkt jest gotowy". Pytanie brzmi: ile zakładów chcę jeszcze postawić zanim sprawdzę, czy ktokolwiek gra? --- *W newsletterze rozwijam tego rodzaju tematy głębiej. [Zapisz się.](https://bezhypeu.pl/newsletter)*

Produkt odpowiada na pytanie użytkownika, nie na wizję twórcy.

kontakt@bezhypeu.pl (Karol Dzwonkowski) — Wed, 04 Mar 2026 00:00:00 GMT

Każdy produkt zaczyna się od zdania "rozwiązujemy problem X". Problem brzmi poważnie. Problem brzmi jak coś, na co warto wydać pieniądze. Problem jest w pitch decku, w PRD, w pierwszym slajdzie dla inwestora. Tylko że użytkownik **NIE** myśli w kategoriach problemów. Użytkownik myśli pytaniami. "Gdzie to zapisać, żeby nie zgubić?" "Dlaczego to trwa tak długo?" "Da się to zrobić prościej?" Pytanie jest konkretne, osadzone w kontekście i - co najważniejsze - sformułowane w języku osoby, która go doświadcza. Nie w języku osoby, która planuje na nim zarobić. ## "Problem" to abstrakcja twórcy "Rozwiązujemy problem zarządzania X" - to zdanie z perspektywy twórcy. Żaden użytkownik nie budzi się rano z myślą "mam problem z zarządzaniem". Budzi się z myślą "znowu nie wiem, gdzie jest ten mail" albo "ile ja właściwie mam na to czasu". Twórca operuje na wyższym poziomie abstrakcji niż użytkownik. Agreguje pojedyncze bóle w kategorię, nazywa ją "problemem" i buduje pod nią rozwiązanie. To nie jest złe. Źle jest, gdy ta abstrakcja zastępuje kontakt z rzeczywistym doświadczeniem użytkownika. "Problem" zdefiniowany przez twórcę ma nieprzyjemną właściwość: jest pojemny. Mieści w sobie dziesiątki funkcji, bo każda z nich "pasuje do problemu". A skoro pasuje - to pewnie jest potrzebna. ## Konkretne pytanie vs pojemna wizja Twórca mówi: "system do zarządzania". Użytkownik pyta: "gdzie to trzymać, żeby nic nie zgubić?" To nie jest ta sama potrzeba ujęta inaczej. To fundamentalnie inne pytanie prowadzące do fundamentalnie innego produktu. Pierwsze pytanie generuje architekturę z modułami, dashboardami, rolami i uprawnieniami. Drugie generuje listę z wyszukiwarką. Pytanie użytkownika jest filtrem. Definiuje co produkt musi robić - bo jeśli nie odpowiada na to pytanie, nie ma po co istnieć. Wizja twórcy definiuje co produkt może robić - a "może" nie ma naturalnej granicy. Produkt zbudowany wokół pytania użytkownika jest z natury ograniczony. Produkt zbudowany wokół wizji twórcy jest z natury rozszerzalny. Jedno z tych podejść prowadzi do dyscypliny. Drugie do katalogu funkcji, z którego nikt nie korzysta. ## Produkt, który odpowiada na własne pytanie Gdy twórca sam formułuje pytanie i sam na nie odpowiada, znika mechanizm kontrolny. Nie ma weryfikacji, czy pytanie jest realne. Nie ma weryfikacji, czy odpowiedź jest trafna. Jest przekonanie i zapał. To nie musi być błąd. Wielu udanych produktów zaczęło się od intuicji twórcy. Ale intuicja, która nie została skonfrontowana z pytaniem użytkownika, ma tendencję do rozrastania się. Każda kolejna funkcja wydaje się logiczna, bo wynika z wewnętrznej spójności wizji - nie z zewnętrznej potrzeby. W [notatce o granicy MVP](/notes/mvp-granica-umowna) drift wynikał z braku pytania. Tu jest odwrotnie - pytanie istnieje, ale zadał je twórca sam sobie. Efekt ten sam: zakres rośnie, bo brakuje zewnętrznego kryterium "czy to jest potrzebne". Złożoność nie bierze się z trudności problemu. Bierze się z odpowiadania na pytanie, którego nikt nie zadał. ## Czego pytanie użytkownika nie powie > "Gdybym zapytał ludzi, czego chcą, powiedzieliby: szybszego konia." Cytat przypisywany Fordowi. [Prawdopodobnie nigdy go nie powiedział](https://quoteinvestigator.com/2011/07/28/ford-faster-horse/) - ale to nieistotne, bo powtarzany jest jako dowód na to, że użytkowników nie warto słuchać. A mówi coś zupełnie innego. Ludzie nie powiedzieli "chcę silnik spalinowy". Powiedzieli "chcę dotrzeć szybciej". To jest prawdziwe pytanie. Ford - czy ktokolwiek, kto to wymyślił - nie zignorował pytania. Zignorował proponowane rozwiązanie. Pytanie użytkownika definiuje ból. Rozwiązanie to już robota twórcy. Są dwie warstwy: - **Co boli** - zna użytkownik. "Chcę dotrzeć szybciej", "gubię maile", "nie wiem ile mam czasu". - **Jak to rozwiązać** - robota twórcy. Silnik spalinowy, lista z wyszukiwarką, kalendarz z alertami. Katastrofa zaczyna się wtedy, gdy twórca przeskakuje obie - sam definiuje ból, sam projektuje rozwiązanie, cały cykl zamknięty wewnątrz jednej głowy. Zero zewnętrznego tarcia. Zero weryfikacji. Produkt nie musi robić tego, o co użytkownik prosi. Musi robić to, co wynika z jego pytania. To często coś zupełnie innego - i właśnie dlatego pytanie jest cenniejsze niż prośba. ## Pytanie, które zostaje Jak sprawdzić, czy pytanie które stoi za produktem pochodzi od użytkownika, a nie od wyobraźni twórcy? I co zrobić, gdy użytkownik doświadcza bólu, ale nie potrafi sformułować pytania? --- *W newsletterze rozwijam tego rodzaju tematy głębiej. [Zapisz się.](https://bezhypeu.pl/newsletter)*

Architektura 'na wyrost' w MVP - kiedy to świadomy wybór, a kiedy wymówka

kontakt@bezhypeu.pl (Karol Dzwonkowski) — Wed, 04 Mar 2026 00:00:00 GMT

## Kontekst - **Projekt:** Brand Deals - SaaS do zarządzania współpracami marek z twórcami - **Etap:** MVP, dwa tygodnie po rozpoczęciu kodowania - **Cel:** zwalidować czy twórcy potrzebują narzędzia do ogarnięcia procesu ustalania szczegółów współpracy z markami. Reszta - umowy, stawki, rozliczenia - to dodatki Dwa tygodnie rozmów z twórcami, planowanie zakresu, scopowanie MVP. Potem dwa tygodnie kodowania. Przy przeglądaniu tego co powstało zauważyłem, że MVP się rozjechał. Nie przez ficzery. Przez architekturę. ## Opcje Trzy ścieżki, które rozważałem (lub powinienem był rozważyć): **A: Minimum stacku.** Express albo Fastify, flat structure, jeden model Prisma, deploy na Vercel. Postawienie w weekend, testowanie w poniedziałek. Ograniczenie: przy skalowaniu przepisujesz prawie wszystko. **B: Architektura docelowa.** Monorepo (pnpm workspaces), NestJS z modułami, Prisma z pełnym schematem relacji, separacja concerns od dnia pierwszego. Setup trwa, ale "potem nie trzeba będzie przerabiać". Ograniczenie: "potem" zakłada że wiesz co będzie potem. **C: Middle ground.** NestJS, ale flat - bez modularyzacji. Jeden package, minimalne modele Prisma. Rozbudowa dopiero gdy jest po co - nie gdy wydaje się że kiedyś będzie po co. ## Decyzja **Wybrałem B.** Kryterium: "skoro i tak będę to rozbudowywał, lepiej zrobić to porządnie od razu." Brzmi rozsądnie. Każdy developer słyszał tę logikę i każdy ją stosował. Problem w tym, że to nie jest kryterium - to jest projekcja. Zakłada wiedzę o przyszłości produktu, której jeszcze nie mam. Nie wiem co będzie rozbudowywane, bo nie wiem jeszcze czy ktokolwiek chce tego używać. Pisałem o tym mechanizmie w [notatce o granicy MVP](/notes/mvp-granica-umowna) - drift nie wygląda jak błąd, wygląda jak rozsądek. Tu jest to samo, tyle że na poziomie architektury zamiast zakresu. I ten sam wzorzec opisuje [Complexity Substitution Principle](/zasady/complexity-substitution-principle) - złożoność jako reakcja na niepewność, nie na faktyczną potrzebę. ## Zderzenie Produkt działa. Ale przeglądając co powstało w dwa tygodnie, trudno powiedzieć że to MVP. Moje największe overkille: - **Monorepo z 3 apkami i elementami shared** - api, web, landing page, plus shared contracts, config i utilities. Na produkt bez użytkowników. - **Pełny CRUD dla wszystkich obiektów** - łącznie z encjami, których nikt jeszcze nie używa i nie wiadomo czy będzie. - **Custom Field System (EAV)** - definicje pól, grupy pól, wartości z poziomem pewności (CERTAIN/UNCERTAIN). Cały silnik pod dynamiczne pola, zanim ktokolwiek potwierdził że tego potrzebuje. - **Docker + CI/CD pipeline** - multi-stage buildy, PostgreSQL w compose, linting, typecheck, testy, secret scanning, walidacja migracji Prisma. Produkcyjna infrastruktura przed pierwszym użytkownikiem. - **AI telemetry + idempotency** - śledzenie tokenów, kosztów, latency per call. Deduplikacja requestów do OpenAI. Optymalizacja pod ruch, którego nie ma. - **Multi-tenancy z workspace isolation** - per-request context middleware, role (OWNER, ADMIN, MEMBER). MVP zakłada jednego użytkownika na workspace. Każdy z tych elementów z osobna ma sens. Razem tworzą architekturę produktu gotowego do skalowania, który nie zdobył jeszcze pierwszego użytkownika. ## Hindsight Za wcześnie na pełny werdykt - produkt jest wciąż w budowie. Ale jedno widzę wyraźnie: "i tak będę rozbudowywał" to nie kryterium. To wymówka. Kryterium mówi co konkretnie będzie rozbudowywane i dlaczego ta złożoność jest warunkiem walidacji. "I tak będę" mówi tylko tyle, że nie wiem co będzie - ale na wszelki wypadek buduję pod wszystko. Jeśli nie ma hipotezy - a [nie było jej, bo nie postawiłem pytania wystarczająco wcześnie](/notes/mvp-granica-umowna) - to nie ma też kryterium na architekturę. Zostaje domyślna opcja: [jak najmniej złożony stack, który pozwoli dotrzeć do pierwszego użytkownika](/notes/tech-stack-decyzja-na-kilka-wersji). Opcja C pewnie by wystarczyła. Może nawet A. Czy to oznacza że wybrałem źle? Niekoniecznie. Może ta architektura się opłaci za miesiąc. Ale wybrałem ją bez podstaw - i to jest problem. Nie decyzja, tylko brak kryterium za nią. --- *Pełny kontekst tej decyzji - konkretne liczby, feedback od twórców i co z tego wynikło - w [newsletterze](https://bezhypeu.pl/newsletter).*

Complexity Substitution Principle

kontakt@bezhypeu.pl (Karol Dzwonkowski) — Sun, 01 Mar 2026 00:00:00 GMT

## Mechanizm Complexity Substitution Principle opisuje zjawisko, w którym w sytuacji niedostatecznego zrozumienia problemu ludzie zwiększają złożoność rozwiązania zamiast pogłębiać samo rozumienie problemu. Złożoność daje poczucie bezpieczeństwa, kontroli i „uniwersalności" rozwiązania. W efekcie staje się substytutem wiedzy - mechanizmem kompensującym niepewność poznawczą. Problem nie polega na tym, że rozwiązania są zbyt zaawansowane technicznie. Problem polega na tym, że złożoność pojawia się **wcześniej niż zrozumienie**. Zjawisko to występuje niezależnie od dziedziny: - w technologii (LLM zamiast prostego parsera) - w architekturze systemów - w decyzjach inwestycyjnych - w organizacjach i procesach - w strategiach tworzonych przed zrozumieniem problemu ## Jak to działa 1. Problem jest nie w pełni zrozumiany. 2. Pojawia się niepewność. 3. Wybierane jest rozwiązanie o większej ogólności lub mocy. 4. Złożoność redukuje dyskomfort poznawczy. 5. Rozwiązanie zaczyna maskować brak realnego zrozumienia. Złożoność nie jest tutaj skutkiem problemu - jest reakcją na brak jasności. ## Derived Principle - Proportional Solution Principle Jeżeli złożoność zastępuje zrozumienie, naturalną konsekwencją jest brak proporcji między problemem a rozwiązaniem. > Skuteczne rozwiązania są proporcjonalne do rzeczywistego problemu, nie do poziomu dostępnych możliwości ani narzędzi. ## Interpretacja (Bez hype'u) Najlepsze rozwiązania rzadko są najbardziej zaawansowane. Najlepsze rozwiązania pojawiają się wtedy, gdy problem został wystarczająco dobrze zrozumiany, by nie wymagał nadmiarowej mocy. **Najpierw zrozumienie. Dopiero potem rozwiązanie.**

Tech stack to nie wybór narzędzia. To decyzja na kilka wersji w przód.

kontakt@bezhypeu.pl (Karol Dzwonkowski) — Thu, 26 Feb 2026 00:00:00 GMT

Każdy produkt IT ma swój typowy cykl: identyfikacja problemu, planowanie MVP, wybór stacku, implementacja, deploy, iteracje. Pierwsze dwa etapy potrafią pochłonąć tygodnie - i słusznie, bo to w nich kształtuje się zamysł produktu. Gdy pomysł się skrystalizuje, pojawia się przyspieszenie. Jak najszybciej do kodu. Jak najszybciej do czegoś, co można pokazać, przetestować, zebrać feedback. Efekt? Wybór stacku traktowany jak formalność. "Aplikacja może działać na React, Angularze czy Astro - w końcu frontend to frontend, jaka różnica?" Spora. Bo ten etap będzie rzutował na cały projekt - a szczególnie na koszty, które pojawią się tam, gdzie nikt ich nie planował. ## Trzy kryteria, zero pytań Typowy wybór stacku opiera się na jednym z trzech kryteriów. Znajomość - "znam React, więc React". Prostota startu - "w Vue postawię MVP w weekend". Albo hype - "Svelte nie potrzebuje virtual DOM, jest szybszy od wszystkiego". Każde z nich brzmi sensownie. Żadne nie odpowiada na pytanie: **czym ten produkt ma być za pół roku i jakie wymagania z tego wynikają?** A to właśnie powinno być kryterium zero. ## Stack jest pochodną pytania W [notatce o granicy MVP](/notes/mvp-granica-umowna) padła teza: zakres MVP wynika z pytania, nie z listy funkcji. Z wyborem stacku jest tak samo - tyle że konsekwencje ciągną się dłużej. Prosty przykład. Strona, która ma dostarczać treści i dobrze się pozycjonować, potrzebuje SSR i statycznego renderowania. Aplikacja z rozbudowaną logiką po stronie klienta - nie. To nie kwestia preferencji między jednym frameworkiem a drugim. To kwestia tego, czym ten produkt ma być za pół roku. Jeśli pytanie brzmi "potrzebuję landing page z blogiem" - wybór frameworka SPA to niepotrzebna komplikacja. Jeśli pytanie brzmi "buduję dashboard z real-time danymi" - statyczny renderer to ślepa uliczka. Stack wynika z pytania, a nie z widzimisię twórcy. ## Stack pod MVP kopie grób produktowi Stack dobrany tylko i wyłącznie pod MVP stawia produkt pod ścianą przy pierwszej poważnej zmianie. Dalej padają już tylko strzały. * Monolit do rozbicia. * Frontend do przepisania. * Baza do migracji. Każda iteracja droższa od poprzedniej - bo stack nie był dobrany pod wizję na kilka wersji w przód. Druga skrajność jest równie kosztowna - stack projektowany pod wszystkie możliwe wersje naraz to overengineering, który tak jak [drift MVP](/notes/mvp-granica-umowna) potrafi zatrzymać projekt zanim jeszcze wystartuje, bo mikroserwisy od dnia pierwszego wymagają osobnego repozytorium na każdy serwis, każdy serwis wymaga dedykowanego CI/CD pipeline'u, pipeline wymaga API gateway'a który routuje ruch którego jeszcze nie ma, a to wszystko dla produktu który nie zdobył jeszcze pierwszego użytkownika - i zanim ktokolwiek zobaczy landing page, architektura na wyrost zjadła cały czas który powinien iść w walidację pomysłu. Nie chodzi o to, żeby trafić w środek między jednym a drugim. Chodzi o to, żeby wybrać **jak najmniej złożony stack, który wystarczy na najbliższe iteracje produktu**. > Nie sztuka zabić mrówkę strzelając do niej z armaty. ## Czego stack nie rozwiąże "Dobry stack = sukces produktu." Nie. Stack to warstwa narzędziowa. Za sukcesem produktu stoją decyzje biznesowe, architektoniczne i marketingowe, które mają o wiele większy wpływ niż wybór frameworka. Stack da się przepisać. Złych decyzji produktowych nie naprawisz zmianą frameworka. Narzędzia AI coraz sprawniej generują kod w dowolnym frameworku. Wiedza specyficzna dla konkretnego narzędzia traci na znaczeniu. To, co zostaje, to umiejętność oceny trade-offów - kiedy wybrać prostotę, kiedy elastyczność, kiedy wydajność. Wiedza frameworkowa przestaje być przewagą. Umiejętność podejmowania decyzji - nie. ## Pytanie, które zostaje Jeśli stack dobiera się pod pytanie produktowe, a nie pod preferencje - to co się dzieje, gdy to pytanie zmienia się w trakcie budowania? Jak daleko w przód da się realistycznie planować, zanim planowanie zamieni się w zgadywanie? --- *W newsletterze rozwijam tego rodzaju tematy głębiej. [Zapisz się.](https://bezhypeu.pl/newsletter)*

Granica MVP jest umowna. I to jest pułapka.

kontakt@bezhypeu.pl (Karol Dzwonkowski) — Sun, 22 Feb 2026 00:00:00 GMT

## Definicja, którą wszyscy znają MVP (Minimum Viable Product) - najmniejsza wersja produktu, która pozwala **zweryfikować kluczową hipotezę**. Nie "mała wersja produktu". Nie "beta". Eksperyment z konkretnym pytaniem. Definicja jest prosta. Problem zaczyna się, gdy trzeba ją zastosować. ## Gdzie się rozsypuje Klasyczna definicja MVP ukrywa trzy decyzje, które zazwyczaj pozostają niepodjęte: **Co jest kluczową hipotezą?** Często nienazwana. Zamiast konkretnego pytania ("czy użytkownicy zapłacą za rozwiązanie X?") jest ogólne przekonanie ("zróbmy coś i zobaczymy"). **Co ją weryfikuje?** To częściej "co chcemy pokazać" niż "czego chcemy się dowiedzieć". Jedno prowadzi do prezentacji, drugie do eksperymentu. **Gdzie jest granica?** Subiektywna, zależna od kontekstu i odbiorcy. Nie ma obiektywnej odpowiedzi - jest decyzja. Bez tych odpowiedzi "minimum" jest arbitralne. A arbitralna granica zawsze dryfuje w górę. ## Mechanizm driftu Drift nie wygląda jak błąd. Wygląda jak rozsądek. *"To ważne dla użytkownika."* *"To i tak zajmie tylko dwa dni."* *"Bez tego nie możemy pokazać wartości."* Każdy argument z osobna brzmi sensownie. Razem budują produkt bez hipotezy. Wyobraźnia wypełnia przestrzeń tam, gdzie brakuje konkretnego pytania - a wyobraźnia nie ma naturalnego hamulca. ## Nie zakres. Pytanie. Dyskusje o MVP skupiają się na zakresie: co wejdzie, a co nie. Ale to nie tam leży problem. **Zakres jest pochodną pytania.** Jeśli wiadomo, na jakie pytanie szukamy odpowiedzi, zakres się definiuje sam - bo każda funkcja albo przybliża do odpowiedzi, albo nie. Bez pytania każda funkcja wydaje się "ważna", bo nie ma kryterium, które pozwoliłoby ją odrzucić. MVP dryfuje w górę nie dlatego, że ludzie nie umieją ciąć zakresu. Dryfuje, bo nikt nie postawił pytania wystarczająco wcześnie. ## Wniosek, który nie jest przepisem Nie ma uniwersalnej reguły co należy do MVP. "Minimum" zależy od hipotezy, rynku, zasobów. Jedyne co się powtarza to **dyscyplina**: postawić pytanie zanim zacznie się planować zakres - i pilnować, żeby każda decyzja o tym "co wchodzi" była odpowiedzią na to pytanie, a nie na wyobraźnię. Przepisu na granicę MVP nie ma. Jest pytanie - i kwestia, czy zostało zadane. --- *W newsletterze rozwijam tego rodzaju tematy głębiej. [Zapisz się.](https://bezhypeu.pl/newsletter)*