Prawdy Joela Spolsky'ego o oprogramowaniu dla rozwoju wspieranego przez AI

Dlaczego te prawdy nadal mają znaczenie, gdy AI szybko pisze kod

AI potrafi wygenerować kod wyglądający na działający w ciągu kilku minut. To zmienia tempo projektu, ale nie zmienia tego, co sprawia, że oprogramowanie odnosi sukces. Lekcje z „prawd oprogramowania” Joela Spolsky’ego nigdy nie dotyczyły szybkości pisania. Chodziło o osąd, pętle sprzężenia zwrotnego i unikanie samonapędzającej się złożoności.

Zmienił się koszt tworzenia kodu. Możesz poprosić o trzy podejścia, pięć wariantów albo pełny rewrite i dostać coś niemal natychmiast. Nie zmienił się koszt wybrania właściwego podejścia, sprawdzenia go i życia z nim przez miesiące. Czas zaoszczędzony przy pisaniu często przesuwa się na decydowanie, co właściwie miałeś na myśli, walidowanie przypadków brzegowych i upewnianie się, że dzisiejsze szybkie zwycięstwo nie stanie się jutrzejszym podatkiem na utrzymanie.

Poprawność, bezpieczeństwo i utrzymywalność nadal zajmują realny czas, bo opierają się na dowodzie, nie na przekonaniu. Flow logowania nie jest skończony, gdy się zkompiluje. Jest skończony, gdy niezawodnie odrzuca złe dane wejściowe, obsługuje dziwne stany i nie wycieka danych. AI może brzmieć przekonująco, a jednak pominąć jeden kluczowy szczegół, jak sprawdzenie uprawnień na endpointzie czy warunek wyścigu przy aktualizacji płatności.

AI jest najsilniejsze, gdy traktujesz je jak szybkie narzędzie do szkicu. Świetnie radzi sobie z boilerplatem, powtarzalnymi wzorcami, szybkim refaktorem i eksploracją opcji do porównania obok siebie. Użyte dobrze, kompresuje fazę „pustej kartki”.

AI szkodzi najbardziej, gdy dasz mu niejasne cele i zaakceptujesz wynik na twarz. Te same wzorce porażek pojawiają się w kółko: ukryte założenia (niezadeklarowane reguły biznesowe), nietestowane ścieżki (obsługa błędów, retry’e, puste stany), pewne błędy (przekonujący kod, który jest subtelnie niepoprawny) i „sprytne” rozwiązania, których potem trudno wytłumaczyć.

Jeśli kod jest tani, nowym rzadkim zasobem jest zaufanie. Te prawdy mają znaczenie, bo chronią to zaufanie: wobec użytkowników, współpracowników i twojego przyszłego ja.

Testowanie nadal jest wąskim gardłem i to dobrze

Gdy AI może wygenerować funkcję w minutach, kusi, żeby traktować testy jako wolną część, której trzeba się pozbyć. Punkt Spolsky’ego dalej obowiązuje: wolna część to miejsce, gdzie jest prawda. Kod jest łatwy do wyprodukowania. Poprawne zachowanie nie jest.

Pożyteczny przesunięcie to traktować testy jak wykonywalne wymagania. Jeśli nie potrafisz opisać oczekiwanego zachowania w sprawdzalny sposób, nie skończyłeś myśleć. W pracy wspomaganej przez AI ma to jeszcze większe znaczenie, bo model może pewnie wygenerować coś, co jest tylko trochę niepoprawne.

Zacznij testować od tego, co najbardziej zaszkodzi, jeśli się zepsuje. Dla większości produktów to kluczowe przepływy (rejestracja, checkout, zapis, eksport), uprawnienia (kto może oglądać, edytować, usuwać) i integralność danych (brak duplikatów, poprawne sumy, bezpieczne migracje). Potem pokryj brzegi, które zwykle powodują nocne incydenty: puste wejścia, długi tekst, strefy czasowe, retry’e i niestabilne zewnętrzne granice jak płatności, e-maile czy przesyłanie plików.

AI świetnie proponuje przypadki testowe, ale nie wie, co faktycznie obiecałeś użytkownikom. Używaj go jak partnera do burzy mózgów: poproś o brakujące przypadki brzegowe, scenariusze nadużycia i kombinacje uprawnień. Potem wykonaj pracę ludzką: dopasuj pokrycie do rzeczywistych reguł i usuń testy, które jedynie „testują implementację”, zamiast zachowania.

Spraw, żeby błędy były możliwe do działania. Padający test powinien mówić, co się zepsuło, a nie wysyłać cię na poszukiwania skarbów. Trzymaj testy małe, nazywaj je jak zdania i rób komunikaty o błędach konkretne.

Krótki przykład

Powiedzmy, że budujesz prostą aplikację „notatki zespołowe” z pomocą AI. Ekrany CRUD pojawiają się szybko. Ryzyko poprawności to nie UI. To kontrola dostępu i reguły danych: użytkownik nie może zobaczyć notatek innego zespołu, edycje nie mogą nadpisać nowszych zmian, a usunięcie notatki nie powinno zostawić osieroconych załączników. Testy zamykające te reguły będą wydawać się wąskim gardłem, ale są też siatką bezpieczeństwa.

Gdy testowanie jest wąskim gardłem, wymusza jasność. To ta jasność sprawia, że szybki kod nie zamienia się w szybkie błędy.

Prostota bije spryt, zwłaszcza z AI w pętli

Jedna z najbardziej trwałych prawd jest taka, że prosty kod wygrywa z wymyślnym. AI kusi, by zaakceptować wyszukane abstrakcje, bo przychodzą wypolerowane i szybko. Koszt pojawia się później: więcej miejsc do ukrycia błędów, więcej plików do przeszukania i więcej momentów „co to w ogóle robi?”.

Gdy kod jest tani, to złożoność jest tym, za co płacisz. Mały, nudny projekt jest łatwiejszy do przetestowania, łatwiejszy do zmiany i łatwiejszy do wytłumaczenia. To ma jeszcze większe znaczenie, gdy pierwszy szkic pochodzi z modelu, który potrafi brzmieć pewnie, a być subtelnie niepoprawny.

Praktyczna zasada: trzymaj funkcje, komponenty i moduły małe, tak by współpracownik mógł je przejrzeć w minutach, a nie godzinach. Jeśli komponent React wymaga wielu custom hooków, lokalnej maszyny stanów i warstwy „smart renderer”, zatrzymaj się i zapytaj, czy naprawdę rozwiązujesz realny problem, czy po prostu akceptujesz architekturę, bo AI ją zaproponowało.

Kilka „testów prostoty” pomoże się odsunąć:

• Czy nowy współpracownik zrozumie główny przepływ w jednym podejściu?
• Czy możesz usunąć tę abstrakcję i zastąpić prostym kodem bez utraty czytelności?
• Czy istnieje jedno oczywiste miejsce do naprawy błędu, czy pięć?
• Czy każda część ma jedno zadanie, które potrafisz opisać jednym zdaniem?

Prompty mają tu znaczenie. Jeśli poprosisz o „najlepszą architekturę”, często otrzymasz nadbudowaną. Poproś o ograniczenia skłaniające do mniejszej liczby elementów ruchomych. Na przykład: użyj najprostszego podejścia z najmniejszą liczbą plików; unikaj nowych abstrakcji, chyba że usuwają duplikację w 3+ miejscach; preferuj jawny kod nad uniwersalne helpery.

Przykład: poprosisz AI o dodanie kontroli ról do strony admina. Sprytna wersja wprowadza framework uprawnień, dekoratory i DSL konfiguracyjny. Prosta wersja sprawdza rolę użytkownika w jednym miejscu, blokuje trasy w jednym miejscu i loguje odmowy dostępu. Prosta wersja jest łatwiejsza do przeglądu, łatwiejsza do przetestowania i trudniejsza do błędnej interpretacji.

Jeśli budujesz w narzędziu czatowym takim jak Koder.ai, prostota także zwiększa wartość migawek i rollbacków. Małe, oczywiste zmiany łatwiej porównać, zachować lub cofnąć.

Rekrutacja: potrzebujesz redaktorów i decydentów, nie pisarzy na klawiaturze

Gdy kod jest łatwy do wygenerowania, cenna umiejętność to wybieranie, co w ogóle powinno istnieć, i upewnianie się, że to poprawne. Stara rada „zatrudniaj świetnych programistów” dalej obowiązuje, ale rola się przesuwa. Nie zatrudniasz osoby, żeby szybciej pisała kod. Zatrudniasz kogoś, kto potrafi ocenić, dopracować i obronić produkt.

Najbardziej wartościowe osoby w pracy wspomaganej przez AI mają zwykle cztery cechy: osąd (co ma znaczenie), gust (jak wygląda dobrze), umiejętność debugowania (znalezienie prawdziwej przyczyny) i komunikację (jasne przedstawianie kompromisów). Potrafią wziąć funkcję napisaną przez AI, która „w większości działa”, i uczynić z niej coś, czemu można zaufać.

Lepsza rozmowa kwalifikacyjna: popraw zmianę wygenerowaną przez AI

Zamiast prosić o idealne rozwiązanie od zera, daj kandydatowi AI-wygenerowany pull request (lub wklejony diff) z kilkoma realistycznymi problemami: niejasne nazwy, ukryty przypadek brzegowy, brak testów i drobny błąd bezpieczeństwa.

Poproś, by wyjaśnili, co kod ma robić prostym językiem, znaleźli najbardziej ryzykowne części, zaproponowali poprawki i dodali (lub nakreślili) testy, które wykryłyby regresje. Jeśli chcesz silny sygnał, zapytaj też, jak zmieniliby instrukcję, żeby następna próba AI była lepsza.

To ujawnia, jak myślą w rzeczywistych warunkach: niedoskonały kod, ograniczony czas i potrzeba wyboru priorytetów.

Supermoc: mówić „nie”

AI często brzmi pewnie. Dobrzy zatrudnieni potrafią się temu postawić. Potrafią powiedzieć nie funkcji, która dodaje złożoność, nie zmianie, która osłabia bezpieczeństwo, i nie wypuszczeniu bez dowodu.

Konkretny sygnał to sposób odpowiedzi na pytanie „Zmergowałbyś to?”. Silni kandydaci nie odpowiadają nastrojem. Dają decyzję i krótką listę wymaganych zmian.

Przykład: prosisz o „szybką” zmianę kontroli dostępu, a AI proponuje rozsianie checków po handlerach. Silny kandydat odrzuca to i proponuje jedną jasną warstwę autoryzacji oraz testy dla ścieżek admin i non-admin.

Na koniec: buduj wspólne standardy, żeby zespół edytował wyjścia AI w ten sam sposób. Trzymaj to prosto: jedna definicja ukończenia, spójne oczekiwania przeglądowe i baza testowa.

Specyfikacje i planowanie: jaśniejsze prompty zaczynają się od jaśniejszego myślenia

Gdy AI może wygenerować dużo kodu w minutach, kusi, by pominąć myślenie i po prostu iterować. To działa w demo. Psuje się, gdy potrzebujesz poprawności, przewidywalnego zachowania i mniej niespodzianek.

Dobry prompt to zazwyczaj krótki spec w przebraniu. Zanim poprosisz o kod, zamień niejasny cel w kilka kryteriów akceptacji i jawnych non-goals. To zapobiega temu, by AI (i twój zespół) cicho rozszerzali zakres.

Trzymaj spec mały, ale konkretny. Nie piszesz powieści. Wyznaczasz granice wokół:

• Wejść: co przychodzi (pola, formaty, przypadki brzegowe)
• Wyjść: co musi wyjść (w tym przykłady)
• Błędów: co może pójść nie tak i jak reagować
• Ograniczeń: wydajność, prywatność, zależności lub obszary „nie wolno zmieniać”
• Non-goals: czego nie robisz w tej zmianie

Zdefiniuj „skończone” przed generacją, nie po. „Skończone” powinno być czymś więcej niż „kompiluje się” czy „UI wygląda dobrze”. Dołącz oczekiwania testowe, kompatybilność wsteczną i co będzie monitorowane po wydaniu.

Przykład: chcesz „dodać reset hasła”. Jaśniejszy spec może mówić: użytkownicy proszą o reset przez e-mail; linki wygasają po 15 minutach; ta sama wiadomość wyświetla się niezależnie od tego, czy e-mail istnieje; limit żądań na IP; loguj próby resetu bez przechowywania tokenów w otwartym tekście. Non-goal: brak redesignu strony logowania. Teraz twój prompt ma szyny ochronne, a przeglądy stają się prostsze.

Prowadź lekki changelog decyzji. Jeden akapit na decyzję wystarczy. Zapisz, dlaczego wybrałeś podejście i dlaczego odrzuciłeś alternatywy. Gdy ktoś zapyta „dlaczego jest tak, a nie inaczej?” za dwa tygodnie, będziesz miał odpowiedź.

Praktyczny workflow wspomagany przez AI, który możesz powtarzać

Największa zmiana z AI to fakt, że tworzenie kodu jest łatwe. Trudna część to zdecydowanie, co kod powinien robić i udowodnienie, że to robi.

Zacznij od napisania celu i ograniczeń prostym językiem. Dołącz, czego nigdy nie wolno zrobić, co może być powolne i co jest poza zakresem. Dobre ograniczenie jest testowalne: „Żaden użytkownik nie powinien widzieć danych innego użytkownika” albo „Sumy muszą zgadzać się z eksportem księgowym co do grosza”.

Zanim poprosisz o kod, poproś o prosty projekt i kompromisy. Chcesz, by AI pokazało swoje rozumowanie w formie, którą możesz ocenić: co będzie przechowywać, co będzie walidować i co będzie logować. Jeśli zaproponuje coś sprytnego, naciśnij i poproś o najprostszą wersję, która nadal spełnia ograniczenia.

Powtarzalna pętla wygląda tak:

1. Napisz krótki opis problemu i 3–5 jasnych testów akceptacyjnych typu pass/fail.
2. Poproś o minimalny plan: model danych, kluczowe funkcje i co może pójść nie tak.
3. Generuj jedną małą zmianę na raz (jeden endpoint, jeden ekran UI, jedna migracja), nie pełny zrzut aplikacji.
4. Przeglądaj jak redaktor: czytaj diffy, uruchamiaj testy, próbuj przypadków błędów, potem proś o poprawki.
5. Wydawaj bezpiecznie: użyj flagi lub ograniczonego rolloutu, obserwuj logi i metryki i bądź gotów do cofnięcia.

Mały scenariusz: dodajesz „status zwrotu” do ekranu zamówienia. AI może szybko wygenerować UI, ale poprawność żyje w przypadkach brzegowych. Co jeśli zwrot jest częściowy? Co jeśli provider płatności ponownie wyśle webhook? Najpierw napisz te przypadki, potem zaimplementuj jedną porcję (kolumna w bazie + walidacja) i zweryfikuj testami, zanim przejdziesz dalej.

Jeśli używasz Koder.ai, funkcje takie jak tryb planowania, migawki i rollback naturalnie pasują do tej pętli: zaplanuj najpierw, generuj w kawałkach i zapisuj punkt przywracania dla każdej znaczącej zmiany.

Typowe błędy, gdy kodowanie z AI wydaje się zbyt proste

Gdy generowanie kodu jest szybkie, kusi, by traktować kod jako produkt pracy. Nie jest. Produktem pracy jest zachowanie: aplikacja robi właściwą rzecz, nawet gdy coś idzie nie tak.

1) Wierzenie pewnemu wyjściu bez udowodnienia

AI często brzmi pewnie, nawet gdy zgaduje. Błąd to pomijanie nudnej części: uruchamiania testów, sprawdzania przypadków brzegowych i walidacji rzeczywistych wejść.

Prosta praktyka: zanim zaakceptujesz zmianę, zapytaj „Skąd wiemy, że to poprawne?”. Jeśli odpowiedź brzmi „wygląda dobrze”, to grasz w ruletkę.

2) Pozwalanie narzędziu na rozrost zakresu

AI lubi dodawać dodatki: cache, retry’e, więcej ustawień, dodatkowe endpointy, ładniejsze UI. Część z tych pomysłów jest dobra, ale podnoszą ryzyko. Wiele błędów bierze się z „miłych do posiadania” funkcji, których nikt nie zamawiał.

Trzymaj twardą granicę: rozwiązuj problem, który sobie postawiłeś, potem stop. Jeśli sugestia jest wartościowa, zamieść ją jako oddzielne zadanie z własnymi testami.

3) Mergowanie zmian za duże, by je przeglądnąć

Duży commit wygenerowany przez AI może ukrywać tuzin niepowiązanych decyzji. Przegląd staje się odklepywaniem, bo nikt nie ogarnia wszystkiego naraz.

Traktuj wyjście z chatu jak szkic. Rozbij je na małe zmiany, które możesz przeczytać, uruchomić i cofnąć. Migawki i rollbacky pomagają tylko wtedy, gdy robisz je w sensownych punktach.

Kilka prostych ograniczeń zapobiega większości bólu: jedna funkcja na zestaw, jedna migracja na zestaw, jedna obszar wysokiego ryzyka naraz (auth, płatności, usuwanie danych), testy zaktualizowane w tym samym commicie i jasna instrukcja „jak zweryfikować”.

4) Kopiowanie kodu o niejasnej licencji lub ryzyku bezpieczeństwa

AI może odtworzyć wzorce ze źródeł treningowych lub zasugerować zależności, których nie rozumiesz. Nawet jeśli licencja jest ok, większe ryzyko to bezpieczeństwo: zaszyte sekrety, słabe tokeny, niebezpieczne operacje na plikach i zapytaniach.

Jeśli nie potrafisz wytłumaczyć, co fragment robi, nie wysyłaj go. Poproś o prostszą wersję albo napisz samodzielnie.

5) Zapominanie o migracjach, limitach i trybach awaryjnych

Wiele błędów „działa u mnie” to tak naprawdę błędy danych i skali. AI może dodać zmianę schematu, nie myśląc o istniejących wierszach, dużych tabelach czy czasie przestoju.

Realistyczny przykład: model dodaje nową kolumnę NOT NULL do tabeli PostgreSQL i backfilluje ją w wolnej pętli. W produkcji może to zablokować tabelę i zepsuć aplikację. Zawsze rozważ, co się stanie przy milionie wierszy, wolnej sieci lub nieudanego deployu w połowie drogi.

Przykład: prosta aplikacja, gdzie poprawność liczy się bardziej niż szybkość

Wyobraź sobie mały wewnętrzny tracker zgłoszeń: ludzie wysyłają prośby, menedżerowie zatwierdzają lub odrzucają, a dział finansów oznacza pozycje jako opłacone. Brzmi prosto, a z pomocą AI możesz szybko wygenerować ekrany i endpointy. Część, która Cię spowolni, to te same stare prawdy: reguły, nie pisanie.

Zacznij od spisania minimum, które musi być poprawne. Jeśli nie potrafisz tego wytłumaczyć prostym językiem, nie potrafisz tego przetestować.

Szczupła definicja pierwszej wersji często wygląda tak: pola (title, requester, department, amount, reason, status, timestamps); role (requester, approver, finance, admin); statusy (draft, submitted, approved, rejected, paid). Potem określ przejścia, które się liczą: tylko approver może zmienić submitted na approved lub rejected; tylko finance może zmienić approved na paid.

Używaj AI w kontrolowanej kolejności, żeby łapać błędy wcześnie:

1. Najpierw zdefiniuj schemat bazy i enum statusów.
2. Generuj endpointy wokół przejść (submit, approve, reject, pay), a nie uniwersalną trasę update-anything.
3. Na końcu generuj UI, bazując na tym, co API naprawdę pozwala.

Najcenniejsze testy to nie „czy strona się ładuje”. To sprawdzenia uprawnień i przejść stanów. Udowodnij na przykład, że requester nie może zatwierdzić własnego zgłoszenia, approver nie może oznaczyć jako opłacone, odrzucone zgłoszenia nie mogą być opłacone, a (jeśli taka jest reguła) kwoty nie mogą być edytowane po przesłaniu.

To, co zajmuje najwięcej czasu, to doprecyzowanie przypadków brzegowych. Czy approver może zmienić zdanie po odrzuceniu? Co jeśli dwóch approverów kliknie approve jednocześnie? Co jeśli finance musi częściowo zapłacić? AI potrafi wygenerować kod dla dowolnej wybranej odpowiedzi, ale nie potrafi wybrać odpowiedzi za ciebie. Poprawność pochodzi z podejmowania tych decyzji, a potem wymuszania, by kod ich przestrzegał.

Szybka lista kontrolna przed wysłaniem zmian wygenerowanych przez AI

AI może wygenerować dużo kodu szybko, ale ostatnia mila to wciąż praca ludzka: udowodnienie, że robi to, co miałeś na myśli, i bezpieczne zachowanie w przypadku awarii.

Zanim zaczniesz odznaczać pola, wybierz najmniejszą definicję „skończonego”, która ma znaczenie. Dla małej funkcji to może być jedna ścieżka szczęśliwa, dwie ścieżki błędów i szybkie sprawdzenie czytelności. Dla płatności lub auth podnieś poprzeczkę.

Pięć kontroli

• Każde wymaganie jest weryfikowalne. Dla każdego wymagania masz albo test, albo jasny manualny check opisany jednym zdaniem. Jeśli nie potrafisz wyjaśnić, jak to zweryfikować, prawdopodobnie nie rozumiesz, co zbudowałeś.
• Błędy są obsłużone i opisane. Przetestuj główne przypadki błędów (złe wejście, brak uprawnień, błąd sieci, pusta baza). Upewnij się, że aplikacja pokazuje użyteczny komunikat i nie wycieka wrażliwych szczegółów.
• Projekt pozostał prosty. Jeśli AI dodało helpery, abstrakcje lub sprytne wzorce, zapytaj: czy zostawiłbyś je, gdybyś pisał to ręcznie? Usuń dodatkowe warstwy, chyba że uzasadniają się wartością.
• Świeży recenzent potrafi to śledzić. Załóż, że recenzent nie widział sesji czatu. Kod powinien czytać się jak opowieść: czytelne nazwy, krótkie funkcje i krótka notka, dlaczego zmiana istnieje.
• Możesz to bezpiecznie cofnąć. Wiedz, jak wygląda powrót do normalności. Zapisz znaną dobrą wersję i potwierdź, że szybki rollback jest możliwy, jeśli produkcja zachowuje się inaczej.

Krótki przykład

Powiedzmy, że AI dodaje „masowe zapraszanie użytkowników” do ekranu admina. Happy path działa, ale prawdziwe ryzyko to przypadki brzegowe: zduplikowane e-maile, częściowe niepowodzenia i limity. Solidna decyzja o wysyłce to jeden automatyczny test na duplikaty, jedno ręczne sprawdzenie komunikatu przy częściowych błędach i plan rollbacku.

Następne kroki: dodaj szyny ochronne, potem skaluj proces

Gdy kod jest tani, ryzyko przesuwa się na jakość decyzji: o co prosiłeś, co zaakceptowałeś i co wysłałeś. Najszybszy sposób, by te prawdy zadziałały w pracy wspomaganej przez AI, to dodanie szyn ochronnych, które zapobiegają przeciekaniu „prawie dobrych” zmian.

Zacznij od jednostronicowego specu dla następnej funkcji. Trzymaj to prosto: dla kogo, co ma robić, czego nie ma robić i kilka testów akceptacyjnych zapisanych zwykłym językiem. Te testy akceptacyjne stają się twoim kotwiczaniem, gdy AI zaproponuje kuszący skrót.

Zestaw szyn ochronnych, który skaluje się bez dużego narzutu procesowego:

• Trzymaj zmiany na tyle małe, by dało się je przeglądnąć w minutach, nie godzinach.
• Wymagaj testów (albo przynajmniej notatek testowych) dla każdej zmiany zachowania.
• Używaj standardowego szablonu prompta: ograniczenia, styl kodowania i oczekiwania testowe.
• Miej zaufaną ścieżkę rollback dla każdego deployu.
• Śledź nieznane jako jawne TODO, nie ukryte założenia.

Prompty są teraz częścią twojego procesu. Uzgodnij styl: jakie biblioteki są dozwolone, jak obsługujemy błędy, co oznacza „done” i jakie testy muszą przejść. Jeśli prompt nie da się ponownie użyć przez innego współpracownika, jest zbyt niejasny.

Jeśli wolisz chat-first sposób budowania web, backend i aplikacji mobilnych, Koder.ai jest jednym przykładem platformy vibe-coding, gdzie tryb planowania, migawki i eksport źródeł mogą wspierać te szyny. Narzędzie może przyspieszać szkice, ale to dyscyplina sprawia, że ludzie kontrolują poprawność.