Projektowanie i kodowanie oprogramowania z AI

Gdzie AI realnie skraca wytwarzanie oprogramowania

Zysk z AI w programowaniu nie jest równomierny. Zależy od jednej rzeczy: 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. W kontrolowanym eksperymencie z losowym przydziałem, przeprowadzonym przez organizację badawczą METR 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 wydłużył 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.

Warto od razu dodać zastrzeżenie, którego nie podaje większość osób powołujących się na to badanie: 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”.

Należy natomiast czytać dwie rzeczy, które się nie zdezaktualizowały. Po pierwsze, subiektywne poczucie przyspieszenia jest złym miernikiem i nie zastępuje pomiaru. Po drugie, 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. 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ąć: 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.

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

Granice są tu równie ważne jak możliwości, bo to one decydują, gdzie potrzebny jest człowiek.

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ąpi 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, nie gwarantowanie działający. Każdy fragment wymaga przeglądu przez osobę, która rozumie, co ma powstać. Praca nie znika, przesuwa się z pisania na czytanie i weryfikację.

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 przyspiesza realizację, człowiek odpowiada za to, co powstaje.

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ć.

Nie prowadzę projektów, w których celem jest „napisać to szybciej AI”, bez zdefiniowanego, sprawdzalnego efektu. Szybsze pisanie kodu, którego poprawności nikt nie kontroluje, to przeniesienie kosztu na później.