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
Dodaj komentarz
Musisz się zalogować, aby móc dodać komentarz.