Przewinąłem dziś kolejne dwadzieścia postów na Facebooku. Pięć z nich obiecywało "prompt który zmieni twoje podejście do AI". Trzy miały clickbaitowy nagłówek w stylu "ten jeden trick". Jeden miał nawet PDF do pobrania z "50 najlepszymi promptami 2026 roku".
I wszystkie mijają się z tym, co naprawdę robi różnicę.
Nie piszę tego żeby deprecjonować prompty — są ważne. Piszę to dlatego, że obsesja na punkcie promptów to symptom niezrozumienia jak te modele działają. A to niezrozumienie kosztuje — bo zespoły inwestują czas w szlifowanie pytań zamiast w budowanie systemu, który sprawia że pytanie nie musi być perfekcyjne.
Model to kalkulator. Twoje dane to arkusz.
Wyobraź sobie kalkulator. Możesz wpisywać równania na tysiąc sposobów — elegancko, zwięźle, z precyzyjnymi nawiasami — ale jeśli podasz złe liczby, wynik będzie błędny. Nie ma znaczenia jak pięknie sformułujesz zapytanie, jeśli model nie ma dostępu do właściwych informacji.
Modele językowe działają podobnie. Są fenomenalne w rozumowaniu, syntezie i generowaniu tekstu — ale tylko na bazie tego, co dostają na wejście. Generyczny model bez kontekstu dostanie generyczne pytanie i zwróci generyczną odpowiedź. Nie dlatego że jest słaby. Dlatego że nie wie nic o tobie, twoim projekcie, twoich klientach, twoich zasadach.
To nie jest problem promptu. To jest problem architektury.
80/20 który nikt nie pokazuje w postach na FB
Efekty pracy z AI rozkładają się mniej więcej tak:
- ~40% — jakość i relevantność kontekstu (RAG, dokumenty, dane)
- ~20% — instrukcje systemowe (skills, persona, zasady per zadanie)
- ~20% — pamięć i ciągłość (memory, poprzednie decyzje, preferencje)
- ~20% — sam prompt
Cała branża "prompt engineeringu" skupia się na tych ostatnich 20%. Reszta jest albo ignorowana, albo zakopana w dokumentacji technicznej, którą większość ludzi nigdy nie przeczyta.
Co naprawdę robi różnicę: cztery warstwy
1. Skills — agent wie jak ma działać
Skill to instrukcja per zadanie. Nie "bądź pomocny AI" — ale precyzyjne zasady: jakim tonem pisać, co robić w danym kontekście, jakie kroki wykonać, czego unikać.
Gdy pracuję z Hermesem nad artykułem blogowym — agent ładuje skill z zasadami pisania dla bloga Bearly: tone of voice, struktura sekcji, zasady dla grafik, format linków. Nie muszę tego tłumaczyć w każdym prompcie. System wie.
To samo dotyczy agentów AI w firmie — zamiast każdorazowo opisywać jak obsłużyć reklamację klienta, piszesz instrukcję raz i każda interakcja z tym kontekstem ją ładuje automatycznie.
2. RAG z inteligentnym filtrowaniem — sygnał zamiast szumu
RAG (Retrieval-Augmented Generation) to podawanie modelowi zewnętrznej wiedzy. Ale jest tu pułapka, w którą wpada większość implementacji: wrzucają wszystko i liczą że model sobie poradzi.
Problem: im więcej nieistotnego kontekstu, tym gorzej model radzi sobie z wyciąganiem tego co ważne. To dosłownie udowodnione badaniami — phenomenon nazywa się "lost in the middle". Model gubi kluczowe informacje gdy są zakopane w środku długiego kontekstu.
Dlatego w Pokelo zależy nam na semantic search który filtruje — nie "daj modelowi całą bazę wiedzy firmy", ale "znajdź 5-8 fragmentów które są najbardziej relevantne do tego konkretnego pytania". Pytasz o model biznesowy — dostajesz dokumenty o modelu biznesowym. Pytasz o onboarding — dostajesz procedury onboardingu. Nie całą historię firmy od dnia założenia.
To jest różnica między RAG który działa a RAG który daje wrażenie że działa.
3. Instrukcje per projekt — agent rozumie gdzie jest
Każdy projekt ma swój stack, swoje konwencje, swoje zasady. Bez tych informacji agent pracuje jak nowy pracownik w pierwszym dniu — musi zgadywać albo pytać o każdą rzecz.
Przy każdym projekcie w Khirby możesz zdefiniować kontekst projektowy — technologie, konwencje nazewnicze, procesy, powiązane dokumenty. Agent wchodzi w projekt i od razu wie z czym ma do czynienia. Nie musisz zaczynać każdej sesji od "działamy w NestJS, używamy Drizzle ORM, mamy taki i taki styl kodu".
4. Memory — agent pamięta
Ludzki ekspert którego wynajmujesz rok po roku pamięta twoje preferencje, poprzednie decyzje, rzeczy które nie działały. Generyczny chatbot bez pamięci zaczyna od zera przy każdej sesji.
Memory to mechanizm który pozwala agentowi budować zrozumienie przez czas — preferencje stylistyczne, decyzje architektoniczne, kontekst biznesowy który się odkłada. Z każdą sesją system jest trochę lepiej skalibrowany pod konkretny styl i potrzeby.
Konkretny przykład: pytasz o model biznesowy
Zobaczmy jak to wygląda w praktyce. Scenariusz: masz CRM z bazą wiedzy firmy i pytasz agenta o model biznesowy swojego produktu.
Bez systemu: model wie tyle co wpisałeś w prompt. Dostaniesz akademicką odpowiedź o modelach biznesowych w ogóle, albo błędną odpowiedź bo agent zgaduje na podstawie nazwy firmy.
Z systemem (Pokelo + Khirby): semantic search przeszukuje bazę wiedzy firmy i wyciąga: dokument strategiczny z modelem biznesowym, notatki ze spotkań gdzie był omawiany, aktualny cennik, segmenty klientów. Agent dostaje precyzyjny kontekst i odpowiada na podstawie rzeczywistych danych twojej firmy — nie wymysłów.
I co ważne — nie ładuje przy tym całej historii emaili z ostatnich 3 lat, wszystkich ticketów supportu i dokumentacji technicznej. Ładuje to co relevantne. Sygnał, nie szum.
"Ale ten prompt był naprawdę dobry..."
Słyszę to często. I tak — dobry prompt robi różnicę na marginesie. Jeśli masz dobry system, dobry prompt daje wyniki 10% lepsze. Jeśli masz słaby system, nawet idealny prompt da ci wynik 10% lepszy od kiepskiego.
Analogia kulinarna: możesz mieć najlepszego szefa kuchni na świecie — jeśli lodówka jest pusta, zrobi byle co. Z dobrymi składnikami i kucharzem który wie gdzie szukać w spiżarni — magia się dzieje. Przepis (prompt) to ostatni krok, nie pierwszy.
Tak właśnie myślimy o architekturze AI w Bearly. Pokelo to spiżarnia — baza wiedzy firmy z inteligentnym filtrowaniem. Khirby to kucharz który rozumie projekt. Memory to doświadczenie które się kumuluje. Prompt to ostatni krok.
Jak zacząć — bez przeczytania 200 stron dokumentacji
Jeśli chcesz zbudować system który faktycznie działa, zacznij od tych trzech rzeczy:
- Napisz instrukcję projektu — 1-2 strony: czym jest projekt, jaki stack, jakie konwencje, czego agent ma nie robić. To Twój odpowiednik AGENTS.md lub PROJECT.md.
- Podłącz bazę wiedzy — dokumenty, procedury, FAQ, historia decyzji. Nie musi być perfekcyjna. Pokelo zindeksuje to i udostępni agentowi przez semantic search.
- Dodaj memory dla preferencji — styl pisania, format odpowiedzi, rzeczy które działają w twoim kontekście. Zamiast powtarzać to w każdym prompcie, zapisz raz.
Dopiero po tych trzech rzeczach zacznij optymalizować prompty. Wcześniej optymalizujesz coś co nie ma solidnych podstaw.
Magiczne prompty nie istnieją. Istnieją systemy które sprawiają że pytanie nie musi być magiczne — bo kontekst jest właściwy, wiedza jest dostępna, agent rozumie gdzie jest. To jest Pokelo + Khirby w jednym zdaniu.
To nie magia. To inżynieria.