TL;DR

Metaprompting stał się kluczowym narzędziem – pozwala promptom dynamicznie generować lepsze wersje siebie, podobnie do programowania z lat 90.
Evals są prawdziwym skarbem firm AI – ważniejsze niż same prompty, bo bez nich nie wiadomo dlaczego prompt działa i jak go ulepszyć.
Forward deployed engineers to recepta na sukces – founders muszą siedzieć obok użytkowników końcowych, obserwować ich workflow i budować rozwiązania na miejscu.
Debug info jako lista zadań – najlepsze firmy implementują parametry debugowania w odpowiedziach AI, które tworzą automatyczne to-do listy dla programistów.
Konkretne przykłady sukcesu – GigaML i Happy Robot zamykają kontrakty siedmiocyfrowe dzięki połączeniu forward deployed approach z AI.
Kaizen principle w metaprompting – jak w japońskim przemyśle samochodowym, najlepsi w ulepszaniu procesu są ci, którzy go wykonują.
Różne osobowości modeli AI – Claude jest bardziej „ludzki” i sterowalny, podczas gdy Llama 4 wymaga więcej technicznego promptowania.

Tworzenie skutecznych promptów dla AI przestało być sztuką – stało się nauką. Lightcone Podcast Y Combinator ujawnił, jak najlepsze startupy AI wykorzystują zaawansowane techniki promptowania i model forward deployed engineer do budowania produktów wartych miliony dolarów.

Metaprompting – nowa era komunikacji z AI

Prowadzący podcast porównują metaprompting do programowania z lat 90., gdy narzędzia nie były jeszcze w pełni rozwinięte. Jak wyjaśnia jeden z uczestników: „Metaprompting is turning out to be a very, very powerful tool that everyone’s using now.”

Technika przypomina zarządzanie ludźmi – chodzi o skuteczną komunikację informacji potrzebnych do podejmowania dobrych decyzji. Kluczem jest zrozumienie, jak przekazać modelowi AI nie tylko zadanie, ale też sposób jego oceny.

Prompt folding to jedna z najważniejszych technik. Polega na tym, że jeden prompt dynamicznie generuje lepsze wersje siebie. Klasyczny przykład to prompt klasyfikujący, który tworzy wyspecjalizowany prompt na podstawie poprzedniego zapytania.

Proces jest prosty: zamiast ręcznego przepisywania prompta, wystarczy wprowadzić go do surowego LLM z instrukcją „help me make this prompt better”. Model, znając siebie tak dobrze, potrafi znacząco ulepszyć własną instrukcję.

Forking i merging promptów to nowy obszar, który świat dopiero zaczyna eksplorować. Jak zauważa Jared: „this like concept of like forking and merging prompts across customers and which part of the prompt Is customer specific versus like company wide is like a, like a really interesting thing that the world is only just beginning to explore.”

Anatomia profesjonalnego prompta AI

Parahelp, firma zajmująca się AI customer support dla Perplexity, Replit i Bolt, udostępniła swój sześciostronicowy prompt. To rzadki przykład, bo jak tłumaczą twórcy: „prompts are kind of like the crown jewels of the IP of these companies.”

Struktura skutecznego prompta zawiera pięć kluczowych elementów:

Definicja roli – „You’re a manager of a customer service agent”
Opis zadania – konkretne instrukcje co ma robić
Plan krok po kroku – numerowane etapy działania
Format wyjściowy – precyzyjne określenie struktury odpowiedzi
XML-podobne tagi – ułatwiają LLM-om podążanie za instrukcjami

Najlepsze prompty wyglądają bardziej jak programowanie niż pisanie w języku naturalnym. Wykorzystują XML-podobne formatowanie z konkretnego powodu – jak wyjaśnia Diana: „a lot of LLMs were post trained in RLHF with kind of XML type of input and it turns out to produce better results.”

Architektura promptów dzieli się na trzy poziomy. System prompt definiuje ogólne API firmy, niezależne od klienta. Developer prompt dodaje kontekst specyficzny dla każdego klienta. User prompt zawiera bezpośrednie instrukcje użytkownika końcowego.

Zaawansowane techniki inżynierii promptów

Prowadzący podkreślają znaczenie escape hatches – mechanizmów zapobiegających halucynacjom. LLM tak bardzo chce pomóc, że często wymyśla odpowiedzi nawet gdy nie ma wystarczających informacji.

Rozwiązaniem jest danie modelowi „realnej drogi ucieczki”. Instrukcja brzmi: „if you do not have enough information to say yes or no or make a determination, don’t just make it up, stop and ask me.”

Wykorzystanie przykładów to kolejna kluczowa technika. Jak tłumaczy jeden z uczestników: „when it’s too hard to even kind of write a prose around it. Let’s just give you an example that turns out to work really well.”

Dispatch, firma budująca automatyczne znajdowanie bugów w kodzie, wykorzystuje trudne przykłady, które tylko eksperci programiści potrafią rozwiązać. Dodanie takich przykładów do prompta znacząco poprawia wyniki dla skomplikowanych zadań.

Tropiere, jeden ze startupów z obecnej batchy YC, wyspecjalizował się w pomaganiu firmom jak YC company Ducky w dogłębnym zrozumieniu i debugowaniu promptów oraz wartości zwracanych z wieloetapowych workflow.

Debugowanie i optymalizacja modeli AI

YC opracowało innowacyjną metodę debug info – parametr w formacie odpowiedzi, gdzie LLM może „narzekać” na niejasne lub niedostatecznie sprecyzowane informacje.

Jak wyjaśnia Jared z YC: „we just run your LLM like in production with real user data and then you can go back and you can look at the outputs that it has given you in that like output parameter.”

Efekt? Debug info staje się automatyczną listą zadań dla programistów – „literally ends up being like a to do list that you, the agent developer has to do.”

Metaprompting z większymi modelami to popularna strategia optymalizacji. Firmy używają potężnych modeli jak Claude 4 czy GPT-4 do tworzenia lepszych promptów, które następnie implementują w mniejszych, szybszych modelach.

Szczególnie przydatne to w voice AI agents, gdzie opóźnienia mogą zepsuć wrażenie użytkownika. Jak zauważa Diana: „if you have too much pause before the agent responds, I think humans can detect something is off.”

Praktyczny tip: czasami lepiej użyć gemini.google.com bezpośrednio i „drag and drop literally JSON files and you don’t have to do it in some sort of special container”, jak sugeruje Gary.

Evals jako crown jewel firm AI

Paradoksalnie, Parahelp chętnie udostępniła swój prompt, bo prawdziwym skarbem nie są prompty, ale evals. Bez evals nie wiadomo dlaczego prompt napisano w określony sposób i bardzo trudno go ulepszyć.

Tworzenie skutecznych evals wymaga głębokiego zrozumienia konkretnych przypadków użycia. Jak tłumaczy Gary: „you need to sit next to the tractor sales regional manager and understand, well, you know, this person cares. You know, this is how they get promoted.”

Proces tworzenia evals polega na siedzeniu obok ludzi wykonujących konkretną pracę, zrozumieniu ich „reward function” – co jest dla nich ważne, i kodyfikowaniu tych interakcji w bardzo specyficzne evals. Kluczem jest obserwowanie realnych workflow zamiast teoretyzowania.

Harj dostrzega w tym ogromne możliwości biznesowe: „I think there’s so many startup opportunities in building the tooling around all of this stuff. Like for example, anyone who’s done prompt engineering knows that the examples and worked examples are really important to improving the quality of the output.” Idealnie byłoby mieć agenta, który automatycznie wyciąga najlepsze przykłady z customer data set.

Forward deployed engineers – model z Palantir

Gary, były pracownik Palantir, wyjaśnia genezę koncepcji forward deployed engineer. Palantir zauważył, że w żadnej firmie Fortune 500 czy agencji rządowej nie ma ludzi rozumiejących technologię na najwyższym poziomie.

Kluczowa różnica: zamiast wysyłać sprzedawców z „big fancy salespeople with big strong handshakes”, Palantir wysyłał inżynierów.

Efekt był spektakularny. Tradycyjne sales miały „timescales on this would be, you know, six weeks, 10 weeks, 12 weeks, like five years”, podczas gdy forward deployed engineers mogli powiedzieć: „okay, we built it” i dostawać „real live feedback within days.”

Philosophy forward deployed engineer opiera się na bezpośredniej obecności – siedzeniu obok użytkownika (np. agenta FBI), obserwowaniu każdego kroku w ich procesie pracy, konwertowaniu „file cabinet and fax machine things” w czyste oprogramowanie i budowaniu rozwiązań tak intuicyjnych jak „posting a photo of your lunch on Instagram”.

Przykład sukcesu tego modelu to Ryan Peterson z Flexport – „really, really great person who understands how software is built. But then also I think he was the third biggest importer of medical hot tubs for an entire year, like, you know, a decade ago.” Kombinacja głębokiej wiedzy technicznej z unikalnym zrozumieniem specyficznej branży.

Zastosowanie w nowoczesnych startupach AI

Participants zgadzają się: founders powinni myśleć o sobie jak o forward deployed engineers własnej firmy. Nie można tego zlecić na zewnątrz.

Jak podkreśla Gary: „literally the founders themselves, they’re technical, they have to be the great product people, they have to be the ethnographer, they have to be the designer.”

GigaML to doskonały przykład sukcesu tego modelu. Dwóch utalentowanych inżynierów oprogramowania, nie będących naturalnymi sprzedawcami, zmusili się do bycia forward deployed engineers. Kluczowy był ich techniczny breakthrough – „innovated a bit on the rag pipeline so that they can have their voice responses be both accurate and very low latency.” Rezultat? Zamknięcie ogromnego kontraktu z Zepto.

Kluczem był nie tylko closing dealu, ale kontynuacja – siedzenie na miejscu z zespołem customer support i ciągłe dostrajanie oprogramowania.

Happy Robot to kolejny spektakularny sukces – sprzedali siedmiocyfrowe kontrakty trzem największym brokerom logistycznym na świecie. Budują AI voice agents wykorzystując model forward deployed engineer i rozmawiając bezpośrednio z CIO tych firm. Progresja była imponująca: „They started from six figure deals, now doing closing and seven figure deals, which is crazy. This is just a couple months after.”

Dlaczego to działa teraz? Jak wyjaśnia Harj: „you couldn’t necessarily differentiate enough in the demo phase of sales to beat out incumbents” przed erą LLM. Teraz, dzięki szybkiej ewolucji technologii, można faktycznie wygrać przez pokazanie czegoś, czego konkurencja nie potrafi zrobić.

Osobowości modeli AI w praktyce

Podcast ujawnia praktyczne różnice między modelami AI. Claude jest opisywany jako „more happy and more human steerable model”, podczas gdy Llama 4 „needs a lot more steering it’s almost like talking to a developer.”

Różnica może wynikać z mniejszej ilości RLHF w przypadku Llama 4, co czyni go „a bit more rough to work with, but you could actually steer it very well if you actually are good at actually doing a lot of prompting.”

Praktyczny przykład: YC używa LLM do pomagania founders w ocenie inwestorów. Stworzyli rubrykę 0-100, gdzie 0 oznacza „never ever take their money”, a 100 „take their money right away.”

O3 vs Gemini 2.5 Pro pokazują różne podejścia. O3 jest bardzo sztywny, ściśle trzyma się rubryki i surowo karze za odstępstwa. Gemini 2.5 Pro jest elastyczny, potrafi rozumować dlaczego ktoś może być wyjątkiem od reguły.

Jak opisuje to Harj: „O3 felt a little bit more like the soldier, sort of like, okay, I’m definitely check, check, check, check, check. And Gemini Pro 2.5 felt a little bit more like a high agency sort of employee.”

Osobne podziękowania należą się Eric Bacon, head of data w YC, który pomógł zespołowi w „metaproting and using Gemini Pro 2.5 as effectively a REPL.”

Kaizen principle w metaprompting

Gary kończy rozmowę potężną analogią do japońskiego przemysłu: „there’s this aspect of Kaizen, you know, this. This manufacturing technique that created really, really good cars for Japan in the 90s. And that principle actually says that the people who are the absolute best at improving the process are the people actually doing it. That’s literally why Japanese cars got so good in the 90s. And that’s meta prompting to me.”

Principle Kaizen mówi, że najlepsi w ulepszaniu procesu są ci, którzy go faktycznie wykonują. W kontekście metaprompting oznacza to, że LLM najlepiej potrafi ulepszyć samego siebie – bo dokładnie „wie” jak funkcjonuje.

Praktyczne wskazówki z podcastu

Jak zacząć z metaprompting (na podstawie rozmowy):

Daj LLM rolę eksperta prompt engineer i poproś o krytykę istniejącego prompta
Iteruj w pętli – wykorzystuj feedback do kolejnych ulepszeń
Testuj z rzeczywistymi przykładami zamiast teoretycznych scenariuszy
Eksperymentuj z forking i merging promptów dla różnych klientów

Wykorzystanie thinking traces (z doświadczeń YC):

Użyj Gemini 2.5 Pro przez API dla dostępu do śladów myślowych
Obserwuj reasoning w real time – analizuj proces myślenia modelu
Dokumentuj konkretne błędy i dostrajaj prompt na podstawie obserwacji
Rozważ używanie gemini.google.com bezpośrednio z JSON files

Debugging według YC (metoda debug info):

Prowadź Google Doc z notatkami o tym, co nie działa w promptach
Zapisuj konkretne przykłady failów – dokumentuj błędne odpowiedzi
Używaj większych modeli do analizy i sugerowania ulepszeń
Implementuj debug info parameters – stwórz automatyczne to-do listy

Tworzenie evals (model Palantir):

Usiądź obok prawdziwego użytkownika – obserwuj ich codzienną pracę
Zrozum ich „reward function” – co jest dla nich naprawdę ważne
Dokumentuj konkretne scenariusze – zapisuj real-world case studies
Testuj z prawdziwymi danymi zamiast wymyślonych przykładów

Zapobieganie halucynacjom (technika escape hatch):

Zawsze daj opcję „nie wiem” – pozwól modelowi przyznać się do ignorancji
Instruuj jasno – „if you don’t have enough information, stop and ask”
Testuj z niepełnymi danymi – sprawdź czy model nie wymyśla odpowiedzi

Kompletna lista rekomendacji tworzenia promptów

Podstawowa struktura prompta

Zdefiniuj rolę LLM (np. „You’re a manager of a customer service agent”)
Opisz konkretne zadanie do wykonania
Stwórz plan krok po kroku z numerowanymi etapami
Określ precyzyjny format wyjściowy
Używaj XML-podobnych tagów (LLM były trenowane z tym formatem)

Architektura promptów

System prompt: ogólne API firmy, niezależne od klienta
Developer prompt: kontekst specyficzny dla każdego klienta
User prompt: bezpośrednie instrukcje użytkownika końcowego
Eksperymentuj z forking i merging promptów między klientami

Metaprompting

Wprowadź istniejący prompt do LLM z instrukcją „help me make this prompt better”
Używaj prompt folding – pozwól promptom generować lepsze wersje siebie
Wykorzystuj większe modele (Claude 4, GPT-4) do tworzenia promptów dla mniejszych modeli
Iteruj w pętli, wykorzystując feedback do kolejnych ulepszeń

Zapobieganie halucynacjom

Zawsze daj LLM escape hatch: „if you don’t have enough information, stop and ask me”
Instruuj jasno: „don’t just make it up”
Testuj z niepełnymi danymi, żeby sprawdzić czy model nie wymyśla odpowiedzi

Wykorzystanie przykładów

Dodawaj przykłady gdy trudno opisać zadanie słowami
Używaj trudnych przykładów, które tylko eksperci potrafią rozwiązać
Stosuj real-world case studies zamiast teoretycznych scenariuszy

Debugging i optymalizacja

Implementuj debug info jako parametr odpowiedzi
Pozwól LLM „narzekać” na niejasne instrukcje
Stwórz automatyczne to-do listy z debug info
Używaj thinking traces do analizy procesu myślenia modelu
Testuj z prawdziwymi danymi użytkowników w środowisku produkcyjnym

Praktyczne narzędzia

Prowadź Google Doc z notatkami o problemach w promptach
Zapisuj konkretne przykłady błędnych odpowiedzi
Używaj gemini.google.com bezpośrednio z JSON files
Wykorzystuj Gemini Pro 2.5 jako REPL do iteracyjnego testowania
Obserwuj reasoning w real time

Optymalizacja dla voice AI

Używaj metaprompting z większymi modelami dla tworzenia promptów dla szybszych modeli
Pamiętaj, że opóźnienia w voice agents psują wrażenie użytkownika
Testuj latency response time

Iteracyjne ulepszanie

Stosuj Kaizen principle: ci którzy wykonują proces, najlepiej go ulepszają
LLM najlepiej potrafi ulepszyć samego siebie
Dokumentuj każdą iterację i jej rezultaty

Testowanie

Zawsze testuj z rzeczywistymi przypadkami użycia
Unikaj wymyślonych przykładów
Używaj faktycznych danych z workflow użytkowników końcowych
Testuj z różnymi modelami (Claude vs Llama 4 vs O3 vs Gemini)

Formatowanie i struktura

Używaj markdown do strukturyzacji promptów
Stosuj hierarchiczne nagłówki
Prompt powinien wyglądać bardziej jak kod niż tekst
Wykorzystuj XML-podobne tagi dla lepszej interpretacji przez LLM

Metaprompting i model forward deployed engineer to nie tylko techniczne curiosities – to fundamentalne umiejętności dla success w erze AI. Jak podsumowuje Gary: „it kind of actually feels like coding in, you know, 1995. Like the tools are not all the way there. We’re, you know, in this new frontier.”

Równocześnie przypomina to „learning how to manage a person where it’s like, how do I actually communicate, you know, the things that they need to know in order to make a good decision.”

Firmy które opanują te umiejętności już dziś, będą miały ogromną przewagę konkurencyjną w nadchodzącej dekadzie AI. Jak pokazuje principle Kaizen – ci którzy wykonują proces, najlepiej go ulepszają.

Ten wpis jest częścią mojej kolekcji notatek z ciekawych podcastów, webinarów i innych treści, które uważam za wartościowe i do których sam chcę wracać. Jeśli chcesz sprawdzić oryginalne źródło, znajdziesz je tutaj: https://www.youtube.com/watch?v=DL82mGde6wo

Tag: Forward Deployed Engineer

Metaprompting i Forward Deployed Engineers – jak najlepsze startupy AI budują produkty warte miliony #EN111