Jak używam AI do dostarczania kodu
Przestań próbować pisać sprytne prompty. Zacznij inżynierię kontekstu.
Większość ludzi używa AI w niewłaściwy sposób. Proszą o nową funkcjonalność jednym zdaniem. AI zwraca kod, który używa niewłaściwych bibliotek, łamie konwencje nazewnictwa i przywraca stare błędy. Resztę popołudnia spędzasz na naprawianiu tego bałaganu.
AI bez kontekstu to junior developer, który nigdy nie czytał Twojego kodu źródłowego. Zapomina wszystko, co wydarzyło się wczoraj. Nie dałbyś nowemu pracownikowi zadania opisanego w jednej linijce, oczekując idealnego kodu. Dałbyś mu dokument wdrożeniowy.
W swoim repozytorium używam pliku pamięci projektu (project memory file). Plik ten działa jak dokument wdrożeniowy, który AI czyta za każdym razem. Zawiera on specyficzne dla projektu reguły, których osoba z zewnątrz by nie znała:
• Zasady nienegocjowalne: Jak muszą wyglądać adresy URL i jak slugi muszą być zgodne z produkcją. • Reguły logiki: Wyliczanie wartości z konfiguracji zamiast wpisywania liczb na sztywno. • Przypadki brzegowe: Specyficzne ustawienia CDN lub ścieżki plików, które zapobiegają cichym błędom.
Każdy mój błąd staje się nową linią w tym pliku. Dzięki temu plik staje się aktywem o rosnącej wartości. Jakość wyników AI poprawia się z czasem, ponieważ przestaję się powtarzać.
Mój proces pracy składa się z następujących kroków:
- Bootstrapping kontekstu: Poproś AI o przygotowanie szkicu pliku pamięci na podstawie Twojego kodu, a następnie go edytuj.
- Ponowne sformułowanie zadania: Poproś AI o podsumowanie celu, zanim zacznie pisać kod. Pozwala to wcześnie wyłapać błędy.
- Ulepszanie promptu: Zapytaj AI, co w Twojej prośbie jest niejasne.
Używaj AI do tych zadań:
- Pisania boilerplate'u i szkieletów aplikacji.
- Refaktoryzacji zgodnie z istniejącymi wzorcami.
- Wyjaśniania nieznanego kodu.
- Mechanicznego przeszukiwania repozytorium.
- Pisania testów i fixture'ów.
Unikaj używania AI do tych zadań:
- Podejmowania nowatorskich decyzji architektonicznych.
- Podejmowania decyzji estetycznych lub produktowych.
- Cokolwiek, gdzie błąd jest kosztowny.
- Projektowania krytycznego pod kątem bezpieczeństwa.
- Końcowego przeglądu przed wdrożeniem.
Dyscyplina jest prosta:
- Ograniczaj zakres zadań. Nie mów „zbuduj tę funkcję”. Mów „wprowadź tę konkretną zmianę”.
- Podawaj kontekst na wstępie.
- Weryfikuj każdy wynik. Uruchom build i przeczytaj diff.
- Przeglądaj go jak Pull Request juniora. Nigdy nie commituj kodu bez przeczytania go przez człowieka.
- Wprowadzaj wyciągnięte wnioski z powrotem do pliku kontekstu.
Siła nie tkwi w prompcie. Siła tkwi w utrzymywanym przez Ciebie kontekście.
Opcjonalna społeczność edukacyjna: https://t.me/GyaanSetuAi