Nagłówki wciąż powtarzają, że AI sprawi, że programiści staną się zbędni. Nie wierzę w to. Prawdziwym ryzykiem nie jest to, że maszyny przejmą inżynierię. Ryzykiem jest to, że inżynierowie przestaną wykonywać trudną pracę polegającą na myśleniu.
Tworzenie oprogramowania nigdy nie polegało na samym wpisywaniu składni. Zawsze chodziło o utrzymywanie złożoności w głowie, rozumienie trybów awarii i dokonywanie kompromisów, gdy żadna opcja nie jest idealna. AI zmieniło prędkość, z jaką produkujemy kod, ale nie zmieniło powodu, dla którego potrzebujemy człowieka w procesie. Jeśli cokolwiek, to sprawiło, że jasne myślenie stało się bardziej wartościowe i rzadsze.
Pierwsza wersja to nie inżynieria
Obserwuję coraz większą liczbę młodszych programistów, którzy traktują ChatGPT lub Claude jak starszego inżyniera siedzącego na sąsiednim krześle. Wklejają opis zadania, kopiują odpowiedź, uruchamiają testy i robią commit. Jeśli się kompiluje, zadanie zostaje zamknięte. Ten cykl jest szybki, pozbawiony tarcia i niebezpieczny.
Korzystanie z AI nie jest problemem. Ja z niej korzystam. Większość produktywnych inżynierów, których znam, również. Problem zaczyna się wtedy, gdy AI staje się jedynym inżynierem w pokoju. Akceptowanie pierwszego rozwiązania tylko dlatego, że działa, nie jest inżynierią. To outsourcing osądu do modelu, który nie rozumie Twoich użytkowników, Twoich ograniczeń biznesowych ani tego, kiedy ostatnio Twój stos technologiczny padł o 2 nad ranem.
Duże modele językowe udzielają odpowiedzi z niepokojącą pewnością siebie, nawet gdy są całkowicie błędne. Jeden inżynier poprosił AI o zaprojektowanie skalowalnej architektury. Model przedstawił szczegółową, autorytatywną propozycję zbudowaną całkowicie wokół funkcji, która nie istniała w rzeczywistym produkcie. Wyglądało to poprawnie. Było wewnętrznie spójne. Było też bezużyteczne. Niebezpieczeństwo nie polega tylko na tym, że AI halucynuje. Niebezpieczeństwo polega na tym, że zbyt wiele osób ufa tym halucynacjom, ponieważ nie mają już kontekstu, by dostrzec kłamstwo.
Uczysz się poprzez tarcie
Kiedy myślę o tym, co zmieniło mnie z juniora w kogoś, kto potrafi zarządzać systemem, nie pamiętam składni, którą zapamiętałem. Pamiętam awarie. Pamiętam wolne zapytania, które musiałem śledzić ręcznie, wyścigi (race conditions), które pojawiały się tylko pod obciążeniem produkcyjnym, i wdrożenia, które kończyły się błędem, bo moje środowisko lokalne w niczym nie przypominało rzeczywistego świata.
Debugowanie to moment, w którym następuje nauka. Kiedy ręcznie przechodzisz przez kod, widzisz, dlaczego systemy faktycznie zawodzą. Odkrywasz, gdzie pojawiają się wąskie gardła. Uczysz się, jak zachowuje się architektura, gdy przechodzisz z demo dla dziesięciu użytkowników do systemu produkcyjnego obsługującego dziesięć tysięcy jednoczesnych żądań. Chłoniesz w kościach to, jak produkcja różni się od ładnie wyreżyserowanego demo.
Żadna z tej wiedzy nie pochodzi z akceptacji wygenerowanej odpowiedzi. Pochodzi ona z walki z problemem. Jeśli AI usunie każdą trudność, jeśli będzie pisać kod, naprawiać błędy i tłumaczyć przyczyny awarii, to jak dokładnie następne pokolenie programistów zdobędzie status seniora? Doświadczenie to nie certyfikat, który można pobrać. To tkanka bliznowata, którą budujesz na bazie incydentów produkcyjnych i nieudanych wdrożeń. Usuń tarcie, a usuniesz rozwój.
Osąd wygrywa z generowaniem
Przez pewien czas branża traktowała prompt engineering jako nową, gorącą umiejętność do wpisania w CV. To całkowicie mijało się z celem. Najcenniejszą umiejętnością w środowisku nasyconym AI nie jest generowanie opcji. Jest nią wiedza o tym, które sugestie należy odrzucić.
Najlepsi inżynierowie, z którymi pracuję, nie piszą najwięcej promptów. Oni zadają najtrudniejsze pytania. Wiedzą, kiedy refaktoryzacja wprowadza ukrytą zależność. Rozpoznają, kiedy wygenerowany test pokrywa ścieżkę szczęśliwą (happy path), ale ignoruje przypadek brzegowy (edge case), który uszkodzi dane klientów. Potrafią spojrzeć na idealnie poprawny kod i powiedzieć: „Ten kod jest poprawny, ale architektura jest błędna”.
To ostatnie zdanie jest linią demarkacyjną między dwiema bardzo różnymi kulturami. Inżynieria wspomagana przez AI (AI-assisted engineering) oznacza, że używasz maszyny do tworzenia szkieletu (scaffolding), badania wzorców lub automatyzacji powtarzalnego kodu (boilerplate), podczas gdy Twój mózg podejmuje decyzje. Inżynieria zależna od AI (AI-dependent engineering) oznacza, że ufasz maszynie, pozwalając jej prowadzić. Wiele organizacji po cichu dryfuje w stronę zależności, ponieważ w krótkim terminie wydaje się to szybsze. Szybko nie oznacza dobrze.
Praca, która wciąż należy do ludzi
AI może przyspieszyć niemal każdy etap cyklu życia rozwoju, jednak istnieją kluczowe praktyki, które powinny pozostać ściśle ludzkie. Projektowanie systemów wymaga zachowania równowagi między sprzecznymi ograniczeniami: kosztem, opóźnieniem, niezawodnością i przyszłą łatwością utrzymania. Przeglądy architektury zależą od pamięci instytucjonalnej i zdolności do przewidywania efektów drugiego rzędu. Mentoring wymaga kogoś, kto osobiście doświadczył trybów awarii, przed którymi ostrzega. Głębokie zrozumienie produktu wynika z rozmów z użytkownikami i obserwacji ich zachowań w rzeczywistych warunkach, a nie z czytania danych treningowych.
Osąd inżynierski jest sumą tych doświadczeń. To ten cichy głos, który mówi ci, że migracja jest zbyt ryzykowna, by wdrażać ją w piątkowe popołudnie, nawet jeśli code review zakończyło się sukcesem. To intuicja, że optymalizacja wydajności przeprowadzona teraz może później stworzyć lukę w bezpieczeństwie. LLM nie posiada intuicji. Posiada wzorce. Wzorce są użyteczne, ale nie są osądem.
Firmy prowadzące obecnie rekrutację powinny przestać optymalizować proces pod kątem osób, które jedynie sprawnie posługują się narzędziami AI. Zatrudniajcie ludzi, którzy potrafią kwestionować AI. Szukajcie kandydatów, którzy zatrzymają się, uważnie przeczytają wygenerowany wynik i wyjaśnią, dlaczego się z nim nie zgadzają. To właśnie tacy inżynierowie zadbają o zdrowie waszych systemów, gdy wygenerowany kod zderzy się z chaotyczną rzeczywistością środowiska produkcyjnego.
Przyspieszenie bez kompasu
Myśl o AI jak o pedale gazu. W samochodzie z