TL;DR – kluczowe wnioski z webinaru:

Prompt engineering nie jest magią – to przewidywalne narzędzie oparte na prawdopodobieństwach, które wymaga jasnej artykulacji celów
Cztery poziomy promptowania: training wheels (markdown), no training wheels, meta-prompting (AI tworzy prompty) i reverse meta-prompting (dokumentowanie rozwiązań)
Meta-prompting jako game changer – najlepszymi prompt engineerami są same modele językowe, które potrafią tworzyć lepsze prompty niż ludzie
Reverse meta-prompting oszczędza czas – dokumentowanie rozwiązanych problemów pozwala uniknąć powtarzania błędów w przyszłych projektach
Make.com vs edge functions – zewnętrzne automatyzacje dla gotowych integracji, edge functions dla niestandardowej logiki
Chat mode przed implementacją – testowanie i debugowanie przed wprowadzaniem zmian w kodzie
Browser developer tools to klucz – screenshot błędów z konsoli deweloperskiej drastycznie przyspiesza rozwiązywanie problemów

Dlaczego prompt engineering ma znaczenie w rozwoju aplikacji AI

Mark z Prompt Advisors podkreśla fundamentalną prawdę podczas webinaru: prompt engineering nie tylko determinuje sposób budowy aplikacji w Lovable, ale także dostarcza „cheat codes” do wychodzenia z problemów. Gdy programiści utykają na błędach, odpowiednie techniki promptowania pozwalają szybko zidentyfikować przyczyny i znaleźć rozwiązania.

Kluczowe jest zrozumienie, że modele AI nie są magiczne. Mark zauważa: to kombinacja inżynierii po stronie Lovable i przewidywalnych promptów opartych na prawdopodobieństwach. Model przewiduje output na podstawie inputu – im lepiej sformułowany prompt, tym lepszy rezultat.

Ważna nuansa przedstawiona przez Marka: „Nie ma magicznej liczby słów w prompting. Każdy model powinien być promptowany nieco inaczej. Claude 3.5 Sonnet ma inną 'osobowość’ niż GPT-4o, a reasoning models jak o1 chcą znacznie mniej inputu i bardzo celnych zdań.”

Cztery poziomy prompt engineeringu według Marka

Poziom 1: Training wheels method

Podstawowa metoda dla początkujących wykorzystująca markdown

Mark wyjaśnia system hierarchii:

Jeden hashtag (#) = najważniejszy header
Podwójny hashtag (##) = subtitle
Potrójny hashtag (###) = podsekcja
Asteryki (*) = pogrubienia

Obowiązkowe sekcje według Marka: kontekst → zadanie → guidelines → constraints

Kluczowa zasada: modele skupiają się na początku i końcu promptu ze względu na recency bias. Mark wyjaśnia problem „lost in the middle logic” – części środkowe promptu są mniej zauważane, dlatego warto być zwięzłym ale wartościowym per token.

Poziom 2: No training wheels

Ta sama logika, ale bez wyraźnych oznaczeń

Framework pozostaje identyczny, jednak staje się częścią naturalnego workflow. Strukturyzujesz prompt mentalnie, bez używania markdown do hierarchizacji. Mark przedstawia to jako naturalną ewolucję od poziomu pierwszego.

Poziom 3: Meta-prompting – rewolucja w promptowaniu

Mark nazywa to swoją „get out of jail free card”. Technika polega na przypisaniu modelowi roli prompt engineera. Mark używa konkretnego promptu:

„Jesteś światowej klasy prompt engineerem. Tworzysz bardzo szczegółowe prompty, które są zwięzłe, ale wystarczająco precyzyjne, żeby uzyskać pożądany output.”

Mark używa nawet rozszerzeń do Chrome (Voice Control for ChatGPT), żeby mówić zamiast pisać. Następnie prosi o konkretny prompt, np. „napisz mi prompt, który wygeneruje full stack app przyjmujący imię, numer i firmę, a zwracający raport o firmie”.

Dlaczego to działa? Mark podkreśla kluczową obserwację: „Najlepszymi prompt engineerami są same modele językowe. Kto lepiej zna sposób komunikacji z AI niż sam AI?”

Poziom 4: Reverse meta-prompting – najważniejsza technika

Dokumentowanie rozwiązań dla przyszłych projektów

Mark opisuje sytuację z aplikacji PDF, gdzie po godzinie walki z błędami (problemy z authentication, storage security, POST requests), zadaje kluczowe pytanie:

„Teraz przygotuj szczegółowy, instruktażowy prompt end-to-end, który mogę podać od początku następnym razem i który uwzględnia wszystkie te szczegóły.”

Rezultat według Marka to gotowy prompt zawierający:

Wymagania Supabase z konkretnymi SQL queries
Specyfikacje edge functions z przykładami użycia
Cheat sheet dla security i row level policies
Listę potencjalnych błędów i sposobów ich unikania

Mark podkreśla: „To jest lepszy prompt niż mógłbym sam stworzyć, bo używa 'software engineer words’ których może nie znam.”

Make.com vs edge functions vs N8N – praktyczne kryteria wyboru

Mark przedstawia szczegółowe wytyczne podczas demonstracji, kiedy sięgać po które narzędzie:

Make.com sprawdza się gdy:

Potrzebujesz gotowych integracji z popularnymi platformami (CRM, email marketing)
Dokumentacja API może być nieznana modelom językowym
Chcesz off-the-shelf integrations bez edukowania AI o API
Preferujesz wizualny workflow (drag & drop)

Ograniczenia Make.com według Marka: płacisz per operation – jedna operacja to jeden moduł działający w czasie.

N8N lepsze od Make.com gdy:

Mark wymienia konkretne przewagi:

Potrzebujesz większej skali (tańsze na dużych wolumenach)
Chcesz custom code steps w workflow
Potrzebujesz multi-agent workflows z agent modules z tool calls
Planujesz self-hosting dla pełnej kontroli

Edge functions lepsze dla:

Niestandardowej logiki biznesowej unikalnej dla aplikacji
Sytuacji gdy potrzebujesz dostępu do szczegółowych logów w Supabase
Pełnej kontroli nad kodem i jego optymalizacji

Christian z zespołu Lovable dodaje kluczową informację: edge functions mają automatyczne ingesting logów od migracji do Go API, co znacznie ułatwia debugging w porównaniu do zewnętrznych platform.

Chat mode – planowanie przed chaosem

Mark ujawnia podczas webinaru: spędza 70% sesji w Lovable w trybie chat, szczególnie gdy wymagania są niejasne. Podkreśla zasadę „garbage in, garbage out” – jeśli nie wiesz czego chcesz, model też tego nie zrozumie.

Proces w chat mode według Marka:

Przedstaw wizję i funkcjonalność wysokiego poziomu
Poproś model o potwierdzenie zrozumienia i odegranie tego co myśli że chcesz zrobić
Sprawdź czy model zna najnowsze wersje narzędzi (np. GPT-4o vs GPT-4)
Poproś o pokazanie code blocks przed implementacją
Dopiero teraz przejdź do default mode

Kluczowe zastosowania chat mode: niejasne wymagania, nieznane technologie, planowanie refactoringu, debugowanie złożonych błędów.

Ważne o chat mode: Nicholas wyjaśnia, że to eksperymentalna funkcja w Labs (Settings → Account Settings → Labs → Chat Mode). Ostrzega również: „możemy ją szybko zmieniać, więc może zachowywać się inaczej jutro”. Dodatkowo toggle jest zapisywany lokalnie w przeglądarce – zmiana urządzenia lub przeglądarki wymaga ponownego włączenia.

Pułapka starych modeli – istotne ostrzeżenie Marka

„LLM-y jak 3.5 Sonnet czy 4O zawsze pamiętają stary świat modeli. Jeśli zapytasz o integrację OpenAI, domyślnie odpowie 'ok, znam GPT-4, znam 3.5 turbo’. I wtedy dostajesz błędy od samego początku.”

Rozwiązanie według Marka: W chat mode zawsze sprawdzaj: „Chcę zaimplementować GPT-4o. Czy wiesz jak to zrobić? Jeśli tak, pokaż mi code block.” Jeśli pokazuje stary GPT-4, przekaż mu dokumentację i powiedz: „Zapomnij wszystko co wiesz o starych wersjach. Używamy tego.”

Browser developer tools – praktyczne debugowanie

Mark pokazuje podczas demonstracji prostą ale skuteczną technikę. Gdy Lovable wyświetla niejasny błąd („error”, „posting error”), otwiera developer tools (F12), robi screenshot błędów z konsoli i wkleja do chat z pytaniem o rozwiązanie.

Dlaczego to działa: reasoning models potrafią analizować konkretne logi i zidentyfikować przyczyny (np. row level security w Supabase), których ogólne komunikaty błędów nie ujawniają.

Reasoning models vs „Old World” – kluczowa różnica

Christian pyta o różnicę między reasoning models a tradycyjnymi. Mark wyjaśnia:

„Old World” (GPT-4, 3.5 Sonnet): bierze input → bezpośrednio przewiduje output → zwraca rezultat. To „jednodrożny ruch”.

Reasoning models (o1, o3-mini): bierze input → robi 1 do n kroków myślenia → sprawdza rezultat względem promptu → pyta „czy spełniłem wymagania Christiana?” → jeśli nie, wraca i poprawia. To „dwudrożny ruch” z back-and-forth.

Praktyczne zastosowanie: Mark używa reasoning models do analizy błędów, bo są lepsze w debugowaniu dzięki tej dodatkowej warstwie „sprawdzania własnej pracy”.

Przyszłość: Christian zapowiada, że Lovable wkrótce zautomatyzuje proces debugowania – system będzie automatycznie ciągnął network errors i logi do kontekstu przy debugowaniu.

Problem duplikatów plików – ważna aktualizacja

Christian ujawnia częsty problem, który może frustrować użytkowników: AI czasem tworzy nowe pliki zamiast edytować istniejące. Gdy przesuwasz funkcjonalność lub zmieniasz jej lokalizację, AI może stworzyć nowy plik, ale zapomnieć posprzątać po sobie.

Rezultat: masz dwa pliki robiące to samo. Gdy próbujesz dodać funkcjonalność, AI edytuje niewłaściwy plik i dostajesz błąd „changes already in place” lub „could not be applied”.

Rozwiązanie: Lovable właśnie wdrożyło mechanizm, który sprawdza co jest aktywnie używane w aplikacji i ignoruje duplikaty plików. AI teraz bierze pod uwagę co faktycznie działa, zamiast gubić się w nieaktywnych plikach.

Praktyczne wskazówki dla użytkowników Lovable

Foreshadowing w promptach

Mark podkreśla zasadę podczas demonstracji: pierwszy prompt powinien przedstawiać wizję i cele wysokiego poziomu, nie szczegółowe funkcjonalności. Cytuje: „Your first prompt should give a preview to the prompt of what the goal is, what are the functionalities you want the user to have at a very high level.”

Dopiero po podłączeniu Supabase wprowadzać konkretne integracje i edge functions.

Unikanie pułapki refactoringu

Mark przestrzega przed bezmyślnym refactoringiem. W chat mode zawsze pyta o plan refactoringu przed implementacją. Porównuje to do kompresji eseju ze 100 do 10 stron – w kodzie utrata kontekstu może prowadzić do konfliktów między funkcjami, które są „mistimed” lub próbują robić to samo.

Row Level Security (RLS) – konkretne przykłady problemów

Mark dzieli się praktycznymi przypadkami z webinaru, gdy security będzie problemem:

Matchmaking app: Jeśli budujesz aplikację do matchowania użytkowników AI tools, gdzie ludzie mają się poznawać na podstawie podobnych narzędzi – „natychmiast wiesz, że będziesz miał problemy z RLS, bo ta informacja od każdego użytkownika musi być shared”. Domyślnie Supabase ukrywa wszystkie dane użytkowników.

Document upload: PDF-y czy inne dokumenty są chronione w storage. Mark opisuje swoje doświadczenie: „Byłem w stanie upload-ować dokument, ale UI nie pozwalało mi go zobaczyć, nie mówiąc już o przeglądaniu, bo było chronione.”

Zasada według Marka: „Z Supabase zawsze zakładaj, że ukrywa rzeczy dla Twojego dobra. Jeśli musisz je odkryć, musisz być explicit w mówieniu o tym.”

Visual edits i CSS shortcuts

Mark udostępnia Custom GPT do generowania CSS classes dla Visual Edits. Workflow: screenshot UI → opis zmiany → gotowy kod CSS. Jak mówi: „I like to be lazy” – zamiast ręcznego szukania hex colorów czy tailwind classes.

Demo workflow – od prostego do zaawansowanego

Durante webinaru Mark pokazał praktyczne przykłady integracji:

Podstawowy workflow: Lovable UI (text box + button) → webhook do Make.com → OpenAI API (generowanie wierszy) → webhook response z powrotem do Lovable.

Zaawansowany przykład (formularz dentysty): Formularz pacjenta → webhook → Perplexity API (research stanu) → reasoning model o3-mini (analiza czy gabinet może pomóc) → response z rekomendacją lub przekierowaniem do specjalisty.

Przyszłość prompt engineeringu w Lovable

Mark kończy webinar praktyczną obserwacją: można przechodzić między narzędziami. Screenshot automation flow z Make.com może służyć jako input dla promptu tworzącego edge function w Supabase.

Nicholas potwierdza kierunek rozwoju: integracja reasoning models, lepsze prompt generation wewnątrz platformy i automatyzacja debugowania. Cel to utrzymanie kontekstu w Lovable, który zna cały codebase i historię projektu – nie da się tego replikować w zewnętrznych narzędziach.

Advanced Research dla kompleksowych projektów

Mark wspomina o ograniczeniu: nawet najlepsze prompt engineering ma swoje granice. Dla zapytań wymagających 100+ źródeł i bardzo głębokich analiz, proponuje użycie funkcji Advanced Research w Claude – „gdzie możesz zrobić 10+ minut jeszcze głębszych badań na temat zapytania”.

Kluczowy insight

Nowsze AI = starsze błędy

Standardowo myślimy: Nowsze modele AI (GPT-4o, Claude 3.5 Sonnet) automatycznie znają najnowsze wersje API i narzędzi, więc po prostu prosimy o integrację.

W praktyce okazuje się, że: Jak ujawnia Mark – „LLM-y jak 3.5 Sonnet czy 4O zawsze pamiętają stary świat modeli. Jeśli zapytasz o integrację OpenAI, domyślnie odpowie 'ok, znam GPT-4, znam 3.5 turbo’. I wtedy dostajesz błędy od samego początku.”

Dlaczego to jest istotne: Najbardziej zaawansowane AI models mają wbudowaną tendencję do używania przestarzałych wersji API, co prowadzi do frustrujących błędów które mogłeś uniknąć od startu.

Test na jutro: Następnym razem gdy prosisz AI o integrację z zewnętrznym API, zamiast od razu implementować spróbuj najpierw w chat mode zapytać „Czy znasz najnowszą wersję [narzędzie]? Pokaż mi code block” i sprawdź czy używa aktualnej dokumentacji.

Checklisty do natychmiastowego zastosowania (na podstawie webinaru)

Przed rozpoczęciem projektu w Lovable

Określ wizję – co ma robić aplikacja na najwyższym poziomie?
Sprawdź potrzebę integracji – Make.com vs N8N vs edge functions?
Przygotuj pierwszy prompt – wizja + UI inspiration, bez detali technicznych
Zaplanuj foreshadowing – jakie funkcjonalności dopiero po Supabase?
Sprawdź wersje narzędzi – czy AI zna GPT-4o vs GPT-4, najnowsze API?

Reverse meta-prompting (po rozwiązaniu problemu)

Zadaj kluczowe pytanie: „Przygotuj szczegółowy prompt end-to-end, który uwzględnia wszystkie te detale”
Sprawdź kompletność: wymagania techniczne, security, potencjalne błędy
Zapisz w bazie wiedzy – Notion, Obsidian, lub gdzie przechowujesz wiedzę
Przetestuj na nowym projekcie – czy rzeczywiście oszczędza czas?

Debugowanie błędów (technika Marka)

Otwórz Developer Tools (F12) w przeglądarce
Zrób screenshot błędów z konsoli Network/Console
Skopiuj treść błędów jako tekst (nie tylko screenshot)
Przejdź do chat mode przed implementacją poprawek
Zapytaj AI o analizę błędu przed kodowaniem

Ten wpis to notatki z webinaru „Master Prompt Engineering – Build Smarter AI Apps with Lovable!” prowadzonego przez zespół Lovable i Marka z Prompt Advisors. Wszystkie techniki i przemyślenia pochodzą od autorów webinaru – moja rola ograniczała się do uporządkowania ich wypowiedzi w przystępną formę.

Tag: Mark Kashif Prompt Advisors

Master Prompt Engineering – Buduj lepsze aplikacje AI z Lovable! #EN137