Projektowanie i kodowanie oprogramowania z AI

Gdzie AI realnie skraca wytwarzanie oprogramowania

Zysk z AI w programowaniu nie jest równomierny. Zależy od tego, czy trudność zadania leży w tym, co zbudować, czy w tym, jak to napisać.

Tam, gdzie problem jest już zrozumiany, a praca polega na przełożeniu go na kod, AI skraca czas znacząco. Tam, gdzie trudność leży w decyzji, projekcie albo zrozumieniu dziedziny, zysk znika, a czasem robi się ujemny, bo AI pozwala szybciej dojść do złego rozwiązania.

Najciekawszy dowód na to rozróżnienie pochodzi z badania, które wyszło odwrotnie, niż zakładali sami jego uczestnicy. Organizacja badawcza METR przeprowadziła kontrolowany eksperyment z losowym przydziałem na 16 doświadczonych programistach open source i 246 zadaniach w dojrzałych repozytoriach, których ci programiści byli współautorami. Dostęp do narzędzi AI z pierwszej połowy 2025 roku wydłużył w nim czas wykonania zadań o 19%. Uczestnicy przed startem spodziewali się przyspieszenia o 24%, a po zakończeniu badania nadal szacowali, że AI przyspieszyła ich o 20%. Mylili się nawet co do kierunku efektu.

Zastrzeżenie, które rzadko pada przy cytowaniu tego badania: METR sam oznaczył ten wynik jako historyczny, bo dotyczy narzędzi z pierwszej połowy 2025 roku i ówczesnych sposobów pracy, a te zmieniły się od tamtej pory znacząco. Nie należy z niego czytać, że „AI spowalnia programistów”.

Nie zdezaktualizowały się dwie obserwacje. Subiektywne poczucie przyspieszenia jest złym miernikiem i nie zastępuje pomiaru. Warunki tamtego eksperymentu (duży, dobrze znany autorowi kod z wieloletnim kontekstem) to dokładnie ten obszar, w którym przewaga AI jest najmniejsza, bo wąskim gardłem jest w nim przegląd i weryfikacja kodu. To samo rozróżnienie stoi za doborem obszarów poniżej.

Obszary o najlepszym stosunku efektu do nakładu:

Prototypy i wersje próbne

Zbudowanie działającej wersji, na której da się sprawdzić pomysł, zanim zapadną kosztowne decyzje. AI skraca drogę od koncepcji do czegoś, co można kliknąć i ocenić. Prototyp z założenia jest do wyrzucenia, więc niższa dbałość o strukturę nie jest tu wadą.

Kod powtarzalny i szablonowy

Warstwy, które w każdym projekcie wyglądają podobnie: obsługa formularzy, walidacja, komunikacja z API, typowe widoki. To praca polegająca na odtwarzaniu znanego wzorca, bez trudnych decyzji po drodze. AI odtwarza go szybciej.

Testy i dokumentacja

Pokrycie istniejącego kodu testami oraz opisanie, jak działa, to zadania, które są ważne, a bywają odkładane, bo są żmudne. AI obniża ich koszt na tyle, że przestają być odkładane.

Przepisywanie i modernizacja istniejących aplikacji

To osobny obszar, w którym AI zmienia rachunek opłacalności najmocniej, i najczęstszy powód, dla którego firmy w ogóle wracają do starych aplikacji.

Przepisywanie polega na przeniesieniu działającej aplikacji na nowszą technologię, framework albo architekturę. Klasycznie jest to praca droga i ryzykowna, bo trzeba ręcznie odtworzyć zachowanie, którego często nikt już w pełni nie pamięta. AI wykonuje powtarzalną część tłumaczenia kodu z jednej technologii na drugą, a człowiek prowadzi całość i pilnuje, żeby zachowanie się nie zmieniło.

Warunek, którego nie wolno pominąć, to testy potwierdzające równoważność. To ten sam typ warunku wejścia, który stosuję przy wdrożeniach AI w firmie: nie wolno iść dalej, dopóki nie ma czym zmierzyć, czy działa. Zanim cokolwiek się przepisze, trzeba mieć zestaw testów opisujących, jak stara wersja się zachowuje. Bez nich migracja z AI zamienia jeden nieznany stan na drugi, tyle że szybciej. Z nimi przepisywanie staje się procesem, który da się sprawdzać krok po kroku. Testy równoważności przepuszczą jednak także błędy starej wersji, więc reguły biznesowe trzeba sprawdzić osobnym testem, zatwierdzonym przez właściciela procesu. Jak odebrać taką zmianę od wykonawcy, pokazuję w tekście AI do starego kodu.

Typowe sytuacje, w których to się opłaca:

• aplikacja działa, ale stoi na technologii bez wsparcia, co blokuje rozwój i podnosi ryzyko;
• koszt utrzymania rośnie, bo coraz mniej osób rozumie starą technologię;
• trzeba dołożyć funkcje, których stara architektura nie udźwignie.

Czego AI w programowaniu nie robi

Model nie podejmuje decyzji architektonicznych: jak podzielić system, gdzie postawić granice, co uprościć kosztem czego. To decyzje o dużych konsekwencjach, oparte na zrozumieniu kontekstu, którego model nie ma.

Nie zastępuje rozpoznania procesu. Zanim powstanie kod, ktoś musi ustalić, co system ma robić i na jakich danych. Ten etap opisuję w audycie gotowości AI.

Nie rozumie dziedziny za ciebie. AI napisze kod realizujący regułę biznesową, ale nie powie, czy reguła jest poprawna. Przy niejasnych wymaganiach szybsze generowanie kodu tylko przyspiesza budowę czegoś, czego nikt nie potrzebował.

Nie gwarantuje poprawności. Model generuje kod prawdopodobny, bez gwarancji, że działa. Każdy fragment wymaga przeglądu przez osobę, która rozumie, co ma powstać. Czas zaoszczędzony na pisaniu idzie w dużej części na czytanie i weryfikację. Dane o przeglądzie po wdrożeniu agentów i sposób doliczenia kosztu przeglądu do budżetu opisuję w odpowiedzi ile kosztuje agent AI do kodowania.

Nie zastępuje testów. Kod, którego nikt nie sprawdził ani nie pokrył testami, jest szybszy do napisania i droższy w utrzymaniu. AI obniża koszt pisania testów, więc pomijanie ich przestaje mieć jakiekolwiek usprawiedliwienie.

Jak prowadzę takie projekty

Zasada jest jedna: AI pisze, a za każdą zmianę odpowiada osoba, która ją przeczytała i wpuściła.

W praktyce oznacza to pracę małymi, sprawdzalnymi krokami. Każda zmiana jest czytana, zanim wejdzie; hurtowa akceptacja odpada. Przy przepisywaniu aplikacji najpierw powstają testy równoważności, potem migracja. Przy nowym kodzie najpierw rozstrzygamy, co budujemy i dlaczego, a dopiero potem AI pomaga to napisać.

Niektóre decyzje, na przykład wybór zewnętrznego dostawcy usługi, agent kodujący podejmuje sam, jeśli nikt nie rozstrzygnie ich wcześniej. W moim pomiarze z 10 września 2026 dwa modele, które dostały te same zadania, wskazały różnych dostawców w pięciu kategoriach na dwanaście (po jednym uruchomieniu na zadanie, więc to sonda). Dlatego lista dozwolonych dostawców i bibliotek powinna trafić do pliku, który agent czyta przed pracą, na przykład AGENTS.md albo CLAUDE.md (który z nich czyta Claude Code).

Nie prowadzę projektów, w których celem jest „napisać to szybciej AI”, bez zdefiniowanego, sprawdzalnego efektu. Kod napisany szybko, ale niesprawdzony, wraca jako koszt utrzymania i poprawek.