Przestałem pisać kod. Moja aplikacja i tak została wydana w 3 dni.

Trzy miesiące temu zbudowałem pełnoaspektowy dashboard SaaS. Napisałem około 200 linii kodu. Reszta została wygenerowana, sprawdzona i zrefaktoryzowana przez AI.

Aplikacja działa na produkcji. Użytkownicy za nią płacą. Nie siedzę po nocach, martwiąc się o błędy.

To nie przechwałka. To ostrzeżenie.

Rola programisty zmienia się bardzo szybko. Wygrają nie ci, którzy walczą z AI, ale ci, którzy rozumieją tę zmianę.

Development typu AI-native to nowy model myślenia. To nie tylko autouzupełnianie. To traktowanie AI jako współpracownika. AI odpowiada za implementację. Ty odpowiadasz za architekturę, intencję i ocenę.

Ta zmiana wygląda następująco:

• Stary model: Ty piszesz kod. AI pomaga Ci pisać go szybciej.
• Nowy model: Ty definiujesz „co” i „dlaczego”. AI zajmuje się „jak”. Ty weryfikujesz i kierujesz procesem.

Jeśli AI pisze kod, umiejętności programistyczne nie czynią Cię niezastąpionym. Robią to meta-umiejętności.

AI świetnie radzi sobie z wzorcami. Słabo radzi sobie z ich wybieraniem. AI nie wie:

• Czy potrzebujesz server action czy trasy API (API route).
• Czy stan powinien znajdować się w Zustand, czy w parametrze URL.
• Czy potrzebujesz monorepo.

To decyzje wymagające oceny. Wymagają one kontekstu dotyczącego Twojego zespołu i skali działania. Ty masz ten kontekst. AI nie.

Różnica między juniorem a seniorem w erze AI to prompt.

• Słaby prompt: Napisz rate limiter.
• Mocny prompt: Napisz middleware typu rate limiter oparty na Redis dla trasy API w Next.js. Ogranicz do 10 żądań na minutę na jeden adres IP. Zwracaj błąd 429. Pomiń ograniczanie liczby żądań dla użytkowników administratorów. Loguj ograniczone żądania do tabeli Prisma.

Drugi prompt daje Ci kod gotowy do wdrożenia produkcyjnego. Precyzja jest obecnie kluczową umiejętnością inżynierską.

Musisz również uważać na tryby awarii. Kod wygenerowany przez AI często wygląda poprawnie, ale jest subtelnie błędny. Może przechodzić testy, ale ukrywać lukę bezpieczeństwa lub race condition. Przeglądaj wyniki pracy AI z takim samym krytycznym okiem, jakiego używasz wobec junior developera.

Programiści, którzy boją się AI, skupiają się na niewłaściwej rzeczy. Martwią się tym, że będą pisać mniej kodu. Prawdziwym ryzykiem jest niepodniesienie kompetencji wokół samego kodu.

Celem nie jest przestanie bycia programistą. Celem jest bycie lepszym programistą.

Aplikacja została wydana w 3 dni, ponieważ poświęciłem czas na:

• Model danych.
• Przepływ użytkownika (user flow).
• Przypadki brzegowe (edge cases).
• Logikę biznesową.

To jest teraz praca programisty.

Jaki jest Twój obecny stosunek kodu wygenerowanego przez AI do kodu napisanego ręcznie? Daj znać w komentarzach.

Przestałam pisać kod, a moja aplikacja i tak została wydana w 3 dni: oto co to mówi nam o byciu 2GHP

Kiedyś myślałam, że bycie dobrym programistą oznacza intymną znajomość każdej linii kodu w moim repozytorium. Myślałam, że moja wartość jest powiązana z umiejętnością pisania złożonych algorytmów od zera i ręcznego debugowania skomplikowanej logiki.

Myliłam się.

W zeszłym tygodniu zbudowałam i wydałam w pełni funkcjonalną aplikację webową w zaledwie trzy dni. Haczyk? Sama napisałam prawie zero linii kodu.

Zamiast tego działałam jako orkiestrator. Używałam narzędzi AI, takich jak Cursor i v0, aby generować kod szkieletowy (boilerplate), wdrażać funkcje, a nawet debugować złożoną logikę. Spędzałam czas na myśleniu o architekturze, przepływie użytkownika (user flow) i wymaganiach produktowych, zamiast walczyć ze średnikami.

To doświadczenie nauczyło mnie czegoś głębokiego na temat przyszłości inżynierii oprogramowania. Wkraczamy w erę 2GHP: programisty o 2-krotnie większej produktywności człowieka (2x Greater Human Productivity).

Czym jest 2GHP?

2GHP to programista, który wykorzystuje AI, aby osiągnąć 2-krotną (a nawet 10-krotną) produktywność tradycyjnego programisty. Nie chodzi o „lenistwo”; chodzi o efektywność. Chodzi o przesunięcie środka ciężkości z tego, jak pisać kod, na to, co musi zostać napisane i dlaczego.

Przesunięcie: Od Kodera do Orkiestratora

Tradycyjny model programisty koncentruje się na samym akcie pisania kodu. Spędzamy większość czasu w edytorze, wpisując składnię i zarządzając zależnościami.

Model 2GHP koncentruje się na orkiestracji. Programista staje się dyrygentem orkiestry napędzanej przez AI. My dostarczamy wizję, ograniczenia i kierunek, a