Ten artykuł to moje notatki z odcinka podcastu Syntax, w którym Wes Boss i Scott Talinsky dzielili się sprawdzonymi metodami współpracy z AI w programowaniu. Wszystkie przedstawione przemyślenia, obserwacje i praktyczne wskazówki pochodzą od autorów podcastu i wynikają z ich codziennej pracy z narzędziami AI.

TL;DR:

Przygotuj strukturę projektu ręcznie – nie pozwalaj AI wybierać technologii i instalować zależności
Bądź precyzyjny w komunikacji – używaj jasnych poleceń i XML tagów do strukturyzowania
Dziel duże zadania na małe kroki – zamiast „zrób mi Ubera” proś o konkretne komponenty
Wykorzystuj pliki z regułami – cursor rules, LLMs.txt i MCP serwery oszczędzą Ci czasu
Przekazuj logi błędów – AI potrzebuje kontekstu, żeby skutecznie debugować
Zaczynaj nowe sesje – długie chaty prowadzą do zapętlenia i gorszej jakości kodu
Taguj pliki i funkcje – wskaż AI dokładnie, gdzie ma wprowadzać zmiany

Dlaczego AI w kodowaniu wymaga strategii

Wiele osób traktuje AI w kodowaniu jak magiczną różdżkę. Wpisują „zrób mi apkę”, a z drugiej strony oczekują gotowego produktu bez bugów. Jednak Wes Boss zauważa, że ta mentalność prowadzi prosto do frustracji i marnowania czasu.

AI nie zastępuje dobrego planowania ani zrozumienia podstaw programowania. Wymaga natomiast strategicznego podejścia, które autorzy podcastu wypracowali w praktyce.

Struktura projektu – rób to sam, zanim włączysz AI

Najważniejsza zasada według Wesa Bossa brzmi: nie pozwalaj AI przygotowywać struktury Twojego projektu. Zamiast spędzać 20 minut na tłumaczeniu AI, jakich bibliotek nie chcesz używać, lepiej zainwestować 6 minut w ręczne przygotowanie podstaw.

AI ma bowiem tendencję do wybierania domyślnych rozwiązań. Tworzy projekt przez npm init, instaluje to co chce, a następnie programista musi poprawiać jego wybory. Boss podkreśla, że deweloperzy doskonale wiedzą, czego potrzebują, więc po co oddawać kontrolę?

Scott Talinsky dodaje, że CLI do instalowania frameworków są dziś bardzo dobre. SvelteKit, Next.js – wszystkie mają świetne narzędzia do szybkiego startu. Dlatego lepiej wykorzystać je, zamiast prosić AI o zgadywanie preferencji.

Praktyczny proces przygotowania projektu:

Zainstaluj wszystkie potrzebne zależności ręcznie
Skonfiguruj podstawową strukturę folderów
Napisz jeden przykładowy komponent pokazujący styl
Przygotuj podstawową konfigurację (TypeScript, ESLint, etc.)
Dopiero teraz włącz AI do dalszej pracy

Precyzyjna komunikacja z AI

Jasne polecenia zamiast domysłów

Boss zauważa subtelną, ale kluczową różnicę w komunikacji. Dla człowieka „użyj Tailwind 4, nie 3″ i „użyj Tailwind 4, nie używaj Tailwind 3″ brzmi podobnie, jednak AI lepiej rozumie bezpośrednie instrukcje.

Zasady jasnej komunikacji z AI:

Używaj bezpośrednich poleceń: „nie używaj X” zamiast „użyj Y, nie X”
Określaj konkretne wersje: „użyj Tailwind 4, nie używaj Tailwind 3″
Podawaj alternatywy: „użyj CSS Grid do layoutu zamiast flexbox”
Bądź eksplicytny: „użyj ES modules exclusively, nigdy CommonJS”

Bezpośrednia komunikacja zawsze przeważa nad sprytne skróty – im jaśniejsze polecenie, tym lepszy rezultat.

XML tagi dla lepszej struktury

Talinsky dzieli się ciekawą techniką wykorzystywaną w cursor rules i innych narzędziach AI. Otaczanie instrukcji w XML tagi pomaga AI zrozumieć granice różnych sekcji.

Przykład: <coding-style> tutaj wpisz swoje preferencje </coding-style>. W ten sposób AI lepiej rozpoznaje, gdzie zaczyna się i kończy określony typ informacji. Jest to szczególnie przydatne przy przekazywaniu przykładowego kodu czy złożonych reguł stylowania.

Wykorzystanie plików z regułami

Boss i Talinsky zgodnie podkreślają wagę plików konfiguracyjnych – wszystkie służą temu samemu: eliminowaniu powtarzalnych instrukcji w każdej sesji.

Boss pracuje nad „standardowym poleceniem modernizacyjnym”, który zawiera kluczowe zasady nowoczesnego JavaScriptu:

Przykładowe reguły z polecenia Wesa Bossa:

Używaj TypeScript, nie JavaScript – dodawaj odpowiednie typy
ES modules exclusively, nigdy CommonJS – może wymagać "type": "module" w package.json
Unikaj require() syntax – AI często domyślnie do tego wraca
Nie używaj TS-node ani TSX – wykorzystuj --strip-types flag w Node.js
Nie instaluj dotenv package – Node.js ma wbudowaną obsługę .env plików

To rozwiązuje największe frustracje z AI, które stale próbuje używać przestarzałych rozwiązań.

Plan Bossa na przyszłość: opublikować to jako MCP server, żeby móc używać globalnie we wszystkich projektach. Boss zastanawia się jednak nad istotną kwestią: czy MCP prompts zastąpią cursor rules, czy to różne narzędzia?

MCP prompt pobiera się raz i staje się częścią historii chatu. Ale co się dzieje, gdy otworzysz nowy chat? Czy musisz ponownie prosić o pobranie polecenia? Z kolei cursor rules są „assumed” – zawsze dostępne w tle.

Boss przyznaje, że nie wie jeszcze, czy te rozwiązania to pełne zamienniki, czy raczej uzupełniające się narzędzia. To pokazuje, jak szybko ewoluuje ekosystem AI-toolów.

Pliki MDC – zaawansowane zarządzanie regułami

Scott Talinsky zwraca uwagę na rozszerzenie .mdc (markdown Cursor) – specjalny format pliku, który Cursor rozpoznaje i oferuje dla niego dedykowany UI do edycji.

Możliwości plików MDC:

Always on – reguły zawsze aktywne w projekcie
Agent requested – AI samo decyduje kiedy użyć reguł
Manual only – reguły aktywowane tylko na żądanie
Pattern matching – reguły tylko dla określonych typów plików (np. „TypeScript files zaczynające się od 'Scott'”)

To znacznie bardziej granularne podejście niż zwykłe pliki z regułami. Talinsky dodaje, że plik .cursor/rules jest już uważany za przestarzały – nowym standardem są project rules lub właśnie pliki MDC.

Boss ma nadzieję na standaryzację: „Mam nadzieję, że doczekamy się standardu w tego typu rzeczach”. Obecnie jest już kilka różnych formatów (cursor rules, LLMs.txt, copilot rules, MDC), a Boss marzy o ujednoliceniu podobnym do tego, co stało się z MCP.

AI jako generator reguł

Talinsky wskazuje na ciekawą możliwość: możesz poprosić AI o stworzenie pliku z regułami na podstawie istniejącego kodu. Jeśli masz kod, który Ci się podoba i chcesz, żeby nowy kod był w tym samym stylu, AI może przeanalizować codebase i wyciągnąć z niego standardy.

To szczególnie przydatne przy rozpoczynaniu nowych projektów. Możesz wskazać AI kod z poprzedniego projektu i poprosić: „stwórz podsumowanie standardów, stylów kodowania i technologii używanych w tym projekcie i wyeksportuj to do pliku”.

Jak Boss zauważa, to zabawne, że rzeczy które LLM-y potrzebują, same potrafią też wygenerować.

Strategia dzielenia zadań na małe kroki

To prawdopodobnie najważniejsza wskazówka z całego odcinka. Boss kategorycznie stwierdza: gdy prosisz AI o zbyt wiele naraz, otrzymujesz „mieszankę śmieci”.

Przykład dzielenia złożonego zadania na kroki:

Zamiast: „Zbuduj mi apkę jak Uber, ale z wyprowadzaniem psów”

Podziel na:

Stwórz komponent do wyświetlania mapy
Przygotuj schemat bazy danych dla użytkowników
Zbuduj API endpoint do zarządzania zamówieniami
Dodaj system płatności (Stripe/PayPal)
Stwórz panel administratora
Zaimplementuj notyfikacje push

Każdy krok można ocenić osobno. Łatwiej sprawdzić, czy AI zrobiło to dobrze, łatwiej poprawić błędy, a AI lepiej rozumie, czego dokładnie od niego oczekujesz.

Listy zadań w markdown

Boss poleca tworzenie plików spec.md w głównym folderze projektu. Lista zadań z checkboxami, którą AI może odhaczać w miarę postępów. Dodatkowo AI może dodawać notatki o tym, jak podeszło do danego problemu.

Alternatywnie można wkleić całą specyfikację do polecenia. Działa to dobrze do pewnego momentu, ale przy większych projektach lepiej mieć osobny plik.

Talinsky zauważa, że nowe narzędzia jak Claude Code czy cursor background agents potrafią pracować godzinami nad listą zadań bez interwencji. To już poziom, który niektórych przeraża – Boss przyznaje, że woli mieć więcej kontroli.

Narzędzia i dokumentacja w erze AI

Pliki LLMs.txt – nowy standard dokumentacji

Scott Talinsky zwraca uwagę na rosnący trend w świecie bibliotek JavaScript. Svelte było jednym z pierwszych, ale coraz więcej projektów dodaje pliki w formacie LLMs.txt – wersje dokumentacji przygotowane specjalnie dla sztucznej inteligencji.

Te pliki można dodawać jako dokumentację w cursor czy innych narzędziach. W rezultacie oszczędzają czas na szukaniu odpowiednich fragmentów dokumentacji.

Contact-7 i MCP servery

Boss opisuje Contact-7 jako MCP server, który automatyzuje proces wyszukiwania dokumentacji. Działanie jest intuicyjne: napisz „co mówią dokumenty Tailwind 4 o marginesach?”, a Contact-7 wykonuje cały proces za Ciebie.

Jak działa Contact-7:

Wyszukuje bibliotekę po nazwie
Analizuje wyniki i wybiera ten z najwyższą pewnością
Pobiera odpowiednią dokumentację
Wstrzykuje ją do kontekstu polecenia
Uruchamia Twoje zapytanie z pełnym kontekstem

To oznacza, że zamiast ręcznie szukać pliku LLMs.txt dla Svelte czy Tailwind, wystarczy napisać „sprawdź dokumenty dla Svelte 5 i zrób X, Y, Z”. System sam pobierze, co potrzebne.

Tagowanie plików i funkcji

Talinsky podkreśla wagę precyzyjnego wskazywania AI, gdzie ma pracować. Zamiast pisać „zrób to i tamto” (co może skutkować tworzeniem nowych funkcji zamiast modyfikacji istniejących), lepiej użyć @function czy @file.

Jest to szczególnie ważne przy projektach z wieloma podobnymi plikami. AI może pomylić kontekst i modyfikować wszystkie skrypty naraz, zamiast skupić się na jednym.

Debugowanie i rozwiązywanie problemów

Boss zauważa: „Jest ogromna wartość w tym, co poszło nie tak”. AI potrafi skutecznie debugować, ale potrzebuje pełnego kontekstu problemu.

Proces skutecznego debugowania z AI:

Skopiuj pełny komunikat błędu (ze stack trace)
Wklej kod, który powoduje problem
Opisz, co oczekiwałeś, a co otrzymałeś
Jeśli AI nie może pomóc od razu, poproś o dodanie console.log
Uruchom kod z dodatkowymi logami i przekaż wyniki

Często po kilku nieudanych próbach AI samo proponuje dodanie console.log czy testów, żeby lepiej zrozumieć problem. Talinsky wspomina o Sentry MCP – integracji, która automatycznie dostarcza AI informacje o błędach z systemu monitorowania.

Kiedy zacząć nową sesję chat

Boss i Talinsky zgodnie ostrzegają przed długimi sesjami. Im dłużej trwa chat, tym gorzej AI radzi sobie z kontekstem. Zaczyna zapominać wcześniejsze ustalenia albo wpada w pętle „nie, już to próbowaliśmy”.

Boss tworzy nową sesję przy każdej nowej funkcjonalności. Stare chaty zachowuje na wypadek, gdyby musiał wrócić do poprzedniego podejścia. Zasada: gdy AI zaczyna się powtarzać albo proponuje już wypróbowane rozwiązania, czas na świeży start.

Praktyczne wskazówki od społeczności

Wes Boss wspomina o tweecie, w którym zebrał kilkaset odpowiedzi od społeczności. Większość sprowadza się do podstawowych zasad dobrego programowania: jedno zadanie na raz, planowanie przed kodowaniem, jasne określenie sukcesu, komunikacja jak z junior developerem.

Niektóre odpowiedzi były zabawne („powiedz AI, że zniszczysz jego rodzinę, jeśli nie wykona zadania”), ale Boss sceptycznie podchodzi do takich tricków.

Scott Talinsky podsumowuje: „Po prostu próbuj różnych rzeczy. Zobacz, co działa dla Ciebie”. Każdy developer ma inny sposób pracy, więc warto eksperymentować z różnymi podejściami.

Kluczowe wnioski

AI w kodowaniu to potężne narzędzie, ale wymaga strategicznego podejścia. Nie zastąpi dobrego planowania, jasnej komunikacji ani zrozumienia podstaw programowania.

Najskuteczniejsze okazuje się traktowanie AI jak bardzo zdolnego junior developera – trzeba mu dokładnie wytłumaczyć zadanie, dostarczyć kontekst i sprawdzić rezultat.

Praktyczne checklisty do wykorzystania

Checklist: Przygotowanie przed włączeniem AI

□ Struktura projektu wykonana ręcznie – struktura folderów, package.json, tsconfig
□ Wszystkie zależności zainstalowane – tylko te, które faktycznie chcesz używać
□ Plik z regułami przygotowany – cursor rules, copilot rules czy .mdc
□ Przykładowy kod napisany – jeden komponent pokazujący preferowany styl
□ Lista konkretnych zadań – w spec.md lub jako lista w poleceniu
□ Dokumentacja bibliotek dodana – pliki LLMs.txt dla używanych frameworków

Checklist: Kiedy zacząć nową sesję chat

□ Chat trwa ponad 2-3 godziny – kontekst zaczyna się gubić
□ AI proponuje już wypróbowane rozwiązania – wpada w pętlę
□ Zaczynasz pracę nad nową funkcjonalnością – lepiej oddzielić konteksty
□ AI zapomina wcześniejsze ustalenia – znaki przeciążenia kontekstu
□ Wymieniłeś już 3-4 różne podejścia – czas na świeży start

Biblioteka sprawdzonych poleceń z podcastu

Polecenia do przygotowania struktury i konfiguracji

Polecenie modernizacyjne (Wes Boss):

Unless specified, generate code with these rules:
- Use TypeScript not JavaScript. Add appropriate TypeScript types.
- Use ES modules exclusively. Never CommonJS, you may need to set type: "module" in package.json
- Use CSS grid for layout when possible instead of using flexbox
- Don't install unnecessary packages like dotenv (Node.js has built-in .env support)
- Use --strip-types flag in Node.js instead of TS-node or TSX

Kiedy stosować: Na początku każdego nowego projektu, żeby uniknąć przestarzałych rozwiązań

Polecenie negacji:

Do not use Axios, do not use Express, do not use Tailwind 3. 
Use Tailwind 4 instead. Do not use CommonJS syntax.
Use Svelte 5 syntax always.

Kiedy stosować: Gdy AI ma tendencję do wybierania niewłaściwych bibliotek lub wersji

Polecenia do zarządzania zadaniami

Dzielenie dużego projektu:

Instead of building entire app, break this down into specific tasks:
1. Create a component that does X, Y and Z
2. Set up database schema for users
3. Build API endpoint for handling orders
4. Implement payment system integration

Kiedy stosować: Gdy chcesz uniknąć „mieszanki śmieci” przy dużych projektach

Tagowanie funkcji:

Reference @function [function_name] and modify it to handle edge cases.
Use @file [filename] for implementing the new feature.

Kiedy stosować: Gdy AI tworzy nowe funkcje zamiast modyfikować istniejące

Polecenia do dokumentacji i analizy

Generowanie reguł z kodu:

Analyze the attached codebase [optionally specify files: @file1.ts, @folder/]. Create a summary of coding standards, technologies used, libraries, and architectural patterns. Format these findings as a concise set of rules that I can use to generate new, consistent code for this project.

Kiedy stosować: Gdy chcesz stworzyć plik z regułami na podstawie istniejącego kodu

Zapytania o dokumentację (Contact-7):

What do the docs on Tailwind 4 say about margin utilities?
Reference the docs for Svelte 5 and implement reactive statements for this component.

Kiedy stosować: Gdy potrzebujesz aktualnych informacji z dokumentacji bibliotek

Polecenia do debugowania

Systematyczne debugowanie:

Let's implement some debugging. Add console.log statements to track the data flow, then go get me those logs so we can analyze what's happening.

Kiedy stosować: Gdy standardowe podejście nie działa i potrzebujesz więcej informacji

Przekazywanie błędów:

Here's the full error message with stack trace: [error]
Here's the code that causes it: [code]  
I expected [X] but got [Y]. Help me fix this.

Kiedy stosować: Zawsze przy błędach – AI potrzebuje pełnego kontekstu

Polecenia strukturyzujące (XML tags)

Organizacja preferencji:

<coding-style>
- Use arrow functions over function declarations
- Prefer const over let when possible  
- Always use semicolons
- Single quotes for strings
</coding-style>

<project-structure>
- Components in /src/components
- Utils in /src/lib
- Types in /src/types
</project-structure>

Kiedy stosować: Gdy przekazujesz złożone reguły lub przykłady kodu

Polecenia do nowych sesji

Polecenie resetu kontekstu:

Starting fresh work on [feature name]. Previous context: we have [brief summary of what's already done]. 
Now I need to: [specific new task]

Kiedy stosować: Gdy zaczynasz nową sesję chat, ale chcesz zachować minimalne informacje z poprzedniej

Kluczowe spostrzeżenie

Więcej kontekstu = gorsza jakość

Standardowo myślimy: Im dłużej pracuję z AI w jednej sesji, tym lepiej mnie rozumie. Przecież ma dostęp do całej historii naszej współpracy, więc powinno być coraz skuteczniejsze.

W praktyce okazuje się, że: Długie chaty prowadzą do degradacji jakości odpowiedzi. AI zaczyna zapominać wcześniejsze ustalenia, wpada w pętle powtarzających się rozwiązań i produkuje coraz bardziej chaotyczny kod. Wes Boss wprost stwierdza: „W razie wątpliwości – wyrzuć to”.

Dlaczego to jest istotne: To fundamentalnie zmienia sposób organizacji pracy z AI. Zamiast budować jeden „długi związek” z AI, lepiej tworzyć serie krótkich, skoncentrowanych sesji.

Test na jutro: Następnym razem gdy pracujesz z AI ponad 2-3 godziny i zaczynasz się frustować, zamiast kontynuować walkę spróbuj zacząć nową sesję z krótkim streszczeniem kontekstu i sprawdź czy AI nie będzie nagle bardziej pomocne.

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: Podcast Syntax – „Getting the most out of AI Coding”

Tag: Ai Debugging

Jak skutecznie wykorzystać AI w kodowaniu – notatki z podcastu Syntax #EN241