Model napisze funkcję szybciej, niż zdążę ją wymyślić, i to jest dokładnie powód, dla którego nauka programowania od zera jest dziś trudniejsza niż kilka lat temu. Nie dlatego, że materiału przybyło, tylko dlatego, że skrót leży na wyciągnięcie ręki i z zewnątrz wygląda identycznie jak postęp. Ten tekst jest o ustawieniu nauki tak, żeby model był korepetytorem, a nie automatem do odrabiania zadań.
Dlaczego przepisywanie gotowców daje złudzenie postępu
Kiedy czytam wygenerowany kod i kiwam głową, uruchamiam rozpoznawanie. Rozpoznawanie jest łatwe: wszystko pasuje, składnia wygląda znajomo, logika ma sens. Programowanie sprawdza coś innego, czyli odtwarzanie z pustej kartki. To dwie osobne umiejętności i pierwsza rośnie znacznie szybciej niż druga. Stąd uczucie, że idzie świetnie, aż do momentu, w którym trzeba napisać dziesięć linijek bez podpowiedzi i okazuje się, że nie wiem, od czego zacząć.
Drugi mechanizm jest jeszcze bardziej podstępny. Model pisze płynnie i pewnie, a płynność źródła mózg lubi mylić z własną kompetencją. Nic w tej sytuacji nie stawia oporu, a nauka potrzebuje oporu: momentu, w którym coś nie działa, siedzę nad tym i sam składam to do kupy. Kiedy każdy taki moment kończy się wklejeniem błędu do czatu, znikają wszystkie chwile, w których naprawdę powstaje umiejętność.
Trzecia rzecz to tempo. Projekt zbudowany z gotowców rośnie szybciej niż moja głowa. Przez dwa tygodnie wygląda to wspaniale, a potem pojawia się błąd, którego model nie usuwa jednym promptem, i nagle nie mam czego debugować, bo nie mam w głowie modelu własnego programu. Wtedy zaczyna się losowe klejenie poprawek, czyli najdroższy sposób spędzania wieczorów, jaki znam.
Automat kontra korepetytor: to ta sama rozmowa, inaczej poprowadzona
Nie chodzi o to, żeby nie używać modelu. Chodzi o to, żeby w każdej sytuacji świadomie wybrać, o co proszę. Ta sama potrzeba ma dwa sformułowania i skutki są przeciwne.
| Sytuacja | Tryb automatu | Tryb korepetytora |
|---|---|---|
| Nie umiem napisać funkcji | Napisz mi funkcję, która robi X | Daj mi zadanie na X, poczekaj na moje rozwiązanie, potem oceń |
| Mam błąd | Wklejam traceback, napraw to | Wklejam traceback, wytłumacz, co ten komunikat mówi i gdzie szukać przyczyny, nie pokazuj poprawki |
| Nie rozumiem cudzego kodu | Uprość mi to | Zadaj mi trzy pytania sprawdzające, czy rozumiem ten kod, i oceń odpowiedzi |
| Chcę zrobić projekt | Zrób mi aplikację do notatek | Rozbij to na dziesięć kroków, ja piszę każdy krok, ty recenzujesz po kolei |
| Nowe pojęcie | Wyjaśnij mi rekurencję | Wyjaśnij rekurencję na jednym przykładzie, potem każ mi przewidzieć wynik innego |
Różnica w jednym zdaniu: w trybie automatu odpowiedź modelu kończy sprawę, w trybie korepetytora odpowiedź modelu zaczyna moją pracę.
Jedna zasada, która porządkuje całą resztę
Do mojego projektu wchodzi wyłącznie kod, który umiem opowiedzieć linijka po linijce i zmienić w dwóch miejscach bez pytania modelu. Wszystko inne może zostać w oknie czatu, ale nie w pliku. Ta zasada wygląda surowo i faktycznie spowalnia pierwszy miesiąc o jakieś sto procent, za to usuwa cały problem, o którym jest ten tekst.
Dwa dodatki, które robią więcej niż wyglądają. Po pierwsze: w okresie nauki podstaw przepisuję kod z klawiatury zamiast kopiować. Przepisywanie zmusza do przeczytania każdego znaku, kopiowanie nie zmusza do niczego. Po drugie: wyłączam podpowiadanie AI wprost w edytorze i zostawiam sam czat obok. Dopełnianie w edytorze zabiera dokładnie ten ułamek sekundy, w którym mózg miał sobie przypomnieć składnię, a to przypominanie jest tym, za co płacę czasem nauki.
Plan pierwszych ośmiu tygodni
Zakładam jeden język i godzinę dziennie. Który język, ma mniejsze znaczenie niż to, żeby przez osiem tygodni nie zmienić zdania. Kolumna po prawej jest najważniejsza: bez dowodu tydzień się nie kończy.
| Tydzień | Materiał | Rola modelu | Dowód, że umiem |
|---|---|---|---|
| 1 | Zmienne, typy, warunki, wejście i wyjście | Tłumacz pojęć, generator mikrozadań | Piętnaście mikrozadań z pustej kartki, bez czatu |
| 2 | Pętle i funkcje, argumenty, zwracanie wartości | Zadaje zadania i punktuje | Pięć funkcji napisanych z opisu, każda z trzema przypadkami testowymi |
| 3 | Listy, słowniki, zagnieżdżone struktury | Podsuwa zadania, nie rozwiązania | Program przetwarzający listę słowników, napisany bez podpowiedzi |
| 4 | Czytanie błędów i debugowanie | Tłumaczy komunikaty, nie poprawia kodu | Dziesięć celowo zepsutych skryptów naprawionych samodzielnie |
| 5 | Pliki, CSV, JSON, prosta obsługa wyjątków | Recenzent po fakcie | Skrypt, który czyta plik i wypisuje raport, odporny na brak pliku |
| 6 | Pierwszy mały projekt od zera | Tylko rozbicie na kroki i recenzja | Działający projekt z wyjaśnieniem każdej linijki na głos |
| 7 | Git, struktura katalogów, środowisko, zależności | Tłumacz pojęć, nie wykonawca komend | Repozytorium z historią commitów i opisem, co robi każda komenda |
| 8 | Zapytania do API, klucze, formaty odpowiedzi | Tłumaczy dokumentację, nie pisze klienta | Skrypt pobierający dane z publicznego API i obsługujący błąd sieci |
Do tego jeden rytuał tygodniowy: w poniedziałek odtwarzam z pamięci projekt z zeszłego tygodnia, od pustego pliku, bez zaglądania do starego kodu. Zwykle idzie gorzej, niż się spodziewam, i to jest najuczciwszy pomiar, jaki mam.
Prompty do nauki
Pierwszy wkleja się na początku sesji i ustawia całą rozmowę. Reszta to narzędzia do konkretnych momentów.
Jesteś moim korepetytorem programowania. Uczę się od zera, język: [JĘZYK].
Zasady, których trzymasz się do końca rozmowy:
1. Nie podajesz gotowego rozwiązania zadania, dopóki nie przyślę własnej próby, nawet błędnej.
2. Jeśli proszę o kod wprost, najpierw pytasz, czy na pewno chcę pominąć próbę.
3. Tłumaczysz na jednym przykładzie naraz, potem sprawdzasz, czy zrozumiałem, pytaniem.
4. Nie wprowadzasz bibliotek ani składni, których nie omówiliśmy.
5. Po każdej mojej odpowiedzi mówisz wprost, co było dobrze, a co źle, bez łagodzenia.
Zacznij od trzech pytań, żeby ustalić, co już umiem.Wygeneruj 10 mikrozadań na temat: [TEMAT].
Warunki: każde do 8 linijek rozwiązania, każde ma podany oczekiwany wynik dla przykładowego wejścia,
zadania ułożone od najłatwiejszego, bez rozwiązań.
Rozwiązania trzymaj u siebie, podasz je dopiero, gdy przyślę swoje.Poniżej kod, którego nie rozumiem. Nie upraszczaj go i nie przepisuj.
Zrób trzy rzeczy:
1. Wypisz, co dzieje się w każdej linijce, po jednym zdaniu.
2. Wskaż jedno miejsce, które początkujący najczęściej rozumieją źle.
3. Zadaj mi trzy pytania kontrolne o ten kod i czekaj na moje odpowiedzi.
KOD:
[WKLEJAM]Mam błąd. Nie naprawiaj go.
Wytłumacz po kolei: co dokładnie mówi ten komunikat, którą linijkę wskazuje,
jakie są trzy typowe przyczyny takiego błędu i w jakiej kolejności je sprawdzić.
Na końcu zadaj mi pytanie, które naprowadzi mnie na przyczynę w moim kodzie.
BŁĄD:
[WKLEJAM]
KOD:
[WKLEJAM]To jest moje rozwiązanie. Oceń je jak korepetytor, nie jak recenzent w pracy.
1. Czy działa poprawnie i dla jakich danych się wywróci.
2. Co jest napisane niepotrzebnie zawile i dlaczego.
3. Jedna rzecz, którą powinienem poprawić SAM, podana jako wskazówka, nie jako kod.
Nie pokazuj poprawionej wersji.
[MÓJ KOD]Jak sprawdzić własne zrozumienie
Pięć testów, które stosuję zamiast poczucia, że rozumiem. Każdy jest nieprzyjemny i każdy działa.
- Pusta kartka. Zamykam wszystko i piszę rozwiązanie od zera. Nie zaglądam nawet do składni. Jeśli utknę, notuję, w którym miejscu, bo to jest lista tematów na jutro.
- Doba przerwy. Kod napisany wczoraj, odtworzony dzisiaj. To, co wczoraj wydawało się oczywiste, dziś często znika, i dopiero ta druga próba coś zostawia.
- Wyjaśnienie na głos. Tłumaczę swój kod komuś, kto nie programuje, albo do dyktafonu. Miejsca, w których zaczynam mamrotać, to miejsca, których nie rozumiem.
- Przewidzenie wyniku. Zanim uruchomię program, zapisuję na kartce, co się wypisze. Potem uruchamiam. Rozbieżność jest cenniejsza niż działający kod.
- Celowe zepsucie. Usuwam jedną linijkę albo zmieniam znak w warunku i przewiduję, co się stanie. Kto umie przewidzieć awarię, ten umie ją naprawić.
Prompty do sprawdzania siebie
Przepytaj mnie z tematu: [TEMAT].
Zadawaj po jednym pytaniu i czekaj na odpowiedź. Zacznij od łatwego i podnoś poziom,
dopóki nie odpowiem źle. Kiedy odpowiem źle, zatrzymaj się i powiedz,
jakiej konkretnie luki dotyczy ten błąd i od czego mam zacząć jej łatanie.
Nie podpowiadaj w trakcie.Poniżej kod. Nie uruchamiaj go w głowie za mnie.
Zapytaj mnie, co wypisze ten program, i dopiero po mojej odpowiedzi powiedz, czy mam rację.
Jeśli się pomylę, pokaż, w której linijce rozjechało się moje rozumowanie,
ale nie tłumacz całości od nowa.
[KOD]Na podstawie naszej rozmowy z ostatniej godziny wypisz:
1. Pojęcia, które umiem, bo poprawnie ich użyłem.
2. Pojęcia, których użyłem, ale nie potrafiłem wyjaśnić.
3. Trzy zadania na jutro, celujące wyłącznie w punkt drugi.
Bądź surowy, nie zaliczaj mi czegoś na podstawie jednej trafionej odpowiedzi.Pułapki, które kosztują najwięcej czasu
- Biblioteka zamiast podstaw. Model chętnie rozwiąże zadanie jedną linijką z biblioteki, której nie umiem czytać. Na etapie nauki proszę wprost o rozwiązanie wyłącznie na podstawowej składni.
- Nieistniejące funkcje i parametry. Model potrafi podać z pełnym przekonaniem nazwę metody, której nie ma. Dla uczącego się to bywa pożyteczne: zmusza do zajrzenia do dokumentacji. Zasada jest prosta, każda nowa nazwa idzie do dokumentacji, zanim trafi do pliku.
- Tempo modelu. Model nie męczy się i poda dziesięć nowych pojęć w jednej odpowiedzi. Ustalam limit: jedno nowe pojęcie na sesję, reszta na później.
- Uruchamianie kodu, którego nie rozumiem. Skrypty kasujące lub przenoszące pliki testuję wyłącznie na kopiach, w osobnym katalogu. Kod z czatu jest kodem z internetu.
- Klucze i dane w oknie czatu. Klucz API, hasło do bazy, fragment prawdziwych danych klientów: nic z tego nie wkleja się do modelu podczas nauki. W zadaniach wystarczą wartości udawane.
- Wieczne wybieranie języka. Pytanie, który język jest najlepszy, ma tę zaletę, że można je zadawać w nieskończoność i nie napisać ani linijki. Wybieram jeden i wracam do tematu po ośmiu tygodniach.
Czego model za mnie nie zrobi
Nie zbuduje intuicji, bo intuicja bierze się z godzin, w których coś nie działało. Nie wie, czego nie wiem, dopóki go tego nie sprawdzi, a sprawdzać musi na moje polecenie. Nie zastąpi czytania cudzego kodu w prawdziwym projekcie, gdzie nic nie jest podane w kolejności dydaktycznej. I nie weźmie odpowiedzialności za to, że program działa u kogoś innego niż ja.
Paradoks całej sprawy jest taki, że im lepiej modele piszą kod, tym bardziej opłaca się go rozumieć. Ktoś musi ocenić, czy to, co wyszło, jest dobre, i ta ocena jest dziś rzadsza niż samo pisanie. Osiem tygodni z pustą kartką kupuje dokładnie tę umiejętność.
Tekst powstał z pomocą AI i został zredagowany przez człowieka.
