# Projektowanie i kodowanie oprogramowania z AI

> Największy zysk z AI w wytwarzaniu oprogramowania pojawia się tam, gdzie problem jest już zrozumiany i pozostaje przełożyć go na kod: przy prototypach, migracjach, przepisywaniu aplikacji między technologiami, testach i dokumentacji. Decyzje architektoniczne i zrozumienie dziedziny wciąż należą do człowieka, dlatego przewaga AI maleje wszędzie tam, gdzie trudność polega na wyborze tego, co zbudować.

Autor: Robert Marczyński · Opublikowano: 2026-07-24 · Aktualizacja: 2026-07-24
Kanoniczny URL: https://ekspertodsztucznejinteligencji.pl/uslugi/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](/uslugi/wdrozenie-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](/uslugi/audyt-gotowosci-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.

## Najczęstsze pytania

**Czy AI naprawdę przyspiesza pisanie kodu?**

Tak, ale nierównomiernie. Największy zysk jest przy pracy dobrze zdefiniowanej: prototypy, kod powtarzalny, testy, migracje, przepisywanie z jednej technologii na drugą. Znika przy problemach, w których trudność leży w projekcie i decyzjach architektonicznych. Model generuje kod prawdopodobny, bez gwarancji poprawności, więc każdy fragment wymaga przeglądu przez kogoś, kto rozumie, co ma powstać.

**Na czym polega przepisywanie aplikacji za pomocą AI?**

Na przeniesieniu istniejącej aplikacji na nowszą technologię lub architekturę, gdzie AI wykonuje powtarzalną część tłumaczenia kodu, a człowiek prowadzi projekt i pilnuje, żeby zachowanie się nie zmieniło. Warunkiem powodzenia jest pokrycie testami: bez testów, które potwierdzają, że przepisana wersja działa tak samo jak stara, migracja z AI zamienia jeden nieznany stan na drugi.

**Czy kod napisany z AI jest gorszej jakości?**

O jakości decyduje przede wszystkim to, kto prowadzi pracę; samo użycie AI niczego tu nie przesądza. Kod generowany bez przeglądu bywa rozwlekły, powiela wzorce i wprowadza subtelne błędy. Kod powstający pod nadzorem osoby, która rozumie dziedzinę i czyta każdą zmianę, jest tak dobry jak przy pracy ręcznej, tylko powstaje szybciej. Wąskie gardło przesuwa się wtedy z pisania na przegląd.

**Kiedy nie warto używać AI do wytwarzania oprogramowania?**

Gdy problem nie jest jeszcze zrozumiany. AI świetnie przekłada rozwiązanie na kod, ale nie wymyśli za ciebie, co właściwie zbudować. Przy nowej dziedzinie, niejasnych wymaganiach albo decyzjach architektonicznych o dużych konsekwencjach szybsze generowanie kodu tylko przyspiesza dojście do złego rozwiązania. Najpierw zrozumienie problemu, potem AI do jego realizacji.


## Źródła

- METR — Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (arXiv:2507.09089): https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
- METR — We are Changing our Developer Productivity Experiment Design (24.02.2026, zastrzeżenie o aktualności wyniku): https://metr.org/blog/2026-02-24-uplift-update/