Co to jest AI-assisted engineering i czym różni się od vibe codingu

Dziewięciu na dziesięciu programistów używa dziś AI do pisania kodu. To nie jest prognoza ani deklaracja producenta narzędzi, lecz wynik badania DORA z września 2025 na próbie blisko pięciu tysięcy osób z całego świata. Mediana czasu pracy z asystentem AI wynosi dwie godziny dziennie.

Pytanie nie brzmi więc, czy Twój dostawca oprogramowania używa AI. Brzmi: na którym z trzech poziomów jej używa, ponieważ od tego zależy, czy dostaniesz działający system, czy kosztowny problem.

Trzy poziomy tej samej technologii

Te same modele językowe obsługują dziś trzy zupełnie różne sposoby pracy. Różnica między nimi nie leży w narzędziu. Leży w tym, kto ponosi odpowiedzialność za wynik.

Podpowiadanie kodu towarzyszy programistom od lat i nikogo już nie dziwi. Człowiek pisze, narzędzie kończy za niego zdanie.

Vibe coding to termin Andreja Karpathy’ego, jednego z założycieli OpenAI, opisujący pracę, w której rzucasz problemem w model, przyjmujesz to, co wygeneruje, nie czytasz zmian, a gdy pojawia się błąd, wklejasz go z powrotem bez komentarza. Do zabawy i do prototypu sprawdza się bardzo dobrze. Jako sposób budowy systemu, na którym ma stanąć Twoja firma, już nie.

AI-assisted engineering to trzeci poziom: kod również generuje model, ale każdy fragment ma specyfikację przed napisaniem i przegląd po napisaniu, a decyzje architektoniczne podejmuje człowiek. To jest metoda, nie tryb pracy narzędzia.

Człowiek, który wymyślił vibe coding, mówi, że to za mało

Rozdzielenia obu poziomów dokonał sam autor pojęcia.

30 kwietnia 2026 roku, po wystąpieniu na konferencji Sequoia AI Ascent, Karpathy napisał na swoim blogu, że vibe coding jest już etapem zamkniętym, i nazwał profesjonalną odmianę tej pracy agentic engineering:

Profesjonalna dyscyplina koordynowania omylnych agentów przy jednoczesnym zachowaniu poprawności, bezpieczeństwa, smaku i utrzymywalności. Andrej Karpathy, 30 kwietnia 2026

Dodał również porównanie: „Vibe coding podnosi podłogę. Agentic engineering podnosi sufit”.

Kluczowe jest tu jedno słowo: omylnych. Cała metoda zbudowana jest wokół założenia, że model się myli, i to nie sporadycznie, lecz w ramach swojej natury. Dlatego wymaga specyfikacji przed pracą, przeglądu po pracy, testów automatycznych i kontroli uprawnień. Vibe coding zakłada, że wynik jest dobry. Inżynieria zakłada, że trzeba to sprawdzić.

Nazewnictwo jeszcze się ustala, więc spotkasz „AI-assisted engineering”, „agentic engineering” i „spec-driven development”. Mówią o tym samym: kod generuje maszyna, odpowiada człowiek.

Jak wygląda praca tą metodą

Odczarujmy to, ponieważ brzmi bardziej egzotycznie, niż wygląda. Jeden cykl pracy nad funkcją systemu:

1. Specyfikacja. Inżynier opisuje, co ma powstać, z jakimi danymi się łączy i jak poznamy, że działa. To jest ta część, w której różnicę robi doświadczenie i której nie da się oddać.
2. Generowanie. Agent pisze kod. Zwykle kilkanaście minut na to, co ręcznie zajęłoby dzień.
3. Przegląd. Człowiek czyta każdy fragment i odpowiada na dwa pytania: czy to robi to, co miało robić, i czy nie robi przy okazji czegoś, o czym nikt nie wie.
4. Testy. Automatyczne, uruchamiane przy każdej zmianie. Bez nich nie ma metody, jest tylko szybsze pisanie.
5. Dopuszczenie. Świadoma decyzja, że to idzie na produkcję. Podejmuje ją człowiek i to on za nią odpowiada.

Punkty 1, 3 i 5 to około 70 procent czasu. Punkt 2, czyli ten, który wszyscy pokazują na filmikach, jest najkrótszy.

To ma bezpośrednie przełożenie na to, co kupujesz. Nie płacisz za tempo pisania kodu. Płacisz za to, że ktoś umie napisać sensowną specyfikację i wychwycić w wygenerowanym kodzie błąd, którego nie widać, dopóki go nie szukasz.

Co mówią dane: za i przeciw

W tej branży łatwo znaleźć liczbę pod tezę. Poniżej pełne zestawienie, łącznie z wynikami niekorzystnymi dla metody.

Za:

• GitHub i MIT, badanie z grupą kontrolną (2023): programiści z asystentem AI ukończyli zadanie o 55,8% szybciej. Zastrzeżenie samych autorów: to było pojedyncze, dobrze zdefiniowane zadanie pisane od zera.
• DORA 2025: ponad 80% badanych zgłasza wzrost produktywności, 59% widzi pozytywny wpływ na jakość kodu. Po raz pierwszy adopcja AI koreluje dodatnio z przepustowością dostarczania, podczas gdy rok wcześniej ta korelacja była ujemna.

Przeciw:

• METR, badanie z grupą kontrolną (lipiec 2025): szesnastu doświadczonych programistów, 246 realnych zadań we własnych, dojrzałych repozytoriach. Z narzędziami AI pracowali o 19% wolniej. Istotniejszy od samego tempa jest wynik dotyczący percepcji: spodziewali się przyspieszenia o 24%, a po zakończeniu badania, już po własnej pracy, nadal szacowali, że byli szybsi o 20%.
• Stack Overflow 2025 (ponad 49 tysięcy odpowiedzi): 46% programistów nie ufa dokładności tego, co generuje AI. 45% mówi, że debugowanie kodu napisanego z AI trwa dłużej.
• DORA 2025: stabilność dostarczania nadal się pogarsza: więcej nieudanych zmian i więcej poprawek. Zaufanie do kodu z AI deklaruje 24% badanych, brak zaufania 30%.
• GitClear, analiza 211 milionów linii kodu: odsetek kodu przepisywanego wkrótce po napisaniu wzrósł z 3,3% w 2021 do 7,1% w 2025.

Główny wniosek raportu DORA 2025 brzmi: AI jest wzmacniaczem. Powiększa to, co organizacja już ma. Zespół z dobrym procesem dostarcza szybciej. Zespół z bałaganem dostarcza bałagan, tyle że sprawniej.

Gdzie ta metoda przyspiesza, a gdzie przeszkadza

Dane wyżej układają się w dość wyraźny podział.

Dlatego deklaracja przyspieszenia bez podanego zakresu niewiele znaczy, również nasza. Nasz mnożnik, pięciokrotne przyspieszenie, dotyczy nowych systemów budowanych od zera. Nie obejmuje pracy na cudzym legacy ani debugowania i nie jest uniwersalny.

Warto więc zapytać każdego dostawcę, gdzie jego mnożnik przestaje obowiązywać. Brak odpowiedzi na to pytanie sam w sobie jest informacją.

To nie to samo, co „system z AI”

Dwie rzeczy nazywane tym samym skrótem, a to zupełnie inne zakupy:

• AI jako metoda wytwarzania. O niej jest ten artykuł. System powstaje szybciej i taniej, ale w środku nie ma żadnej sztucznej inteligencji. To zwykły, dobry software zbudowany mniejszym kosztem.
• AI jako funkcja produktu: model językowy, wyszukiwanie po Twoich dokumentach, agent wykonujący zadania. Tu z AI korzysta Twoja firma, a nie wykonawca przy pisaniu kodu.

Dostawca może mieć jedno, drugie, oba albo żadne z nich, a mówić „robimy w AI” w każdym z tych przypadków. Rozpisaliśmy to na typy dostawców, widełki cenowe i listę dziesięciu pytań kontrolnych na osobnej stronie: AI software house: jak wybrać dostawcę.

Sprawdziliśmy tę metodę na własnej firmie

Można o metodzie czytać albo można ją sprawdzić na sobie. Wybraliśmy drugie: na rok zawiesiliśmy sprzedaż i zamieniliśmy własną firmę w laboratorium.

Od 11 lipca do 26 sierpnia 2026, czyli w 46 dni, powstało trzynaście systemów. Dziewięć z nich pracuje dziś w produkcji i obsługuje naszą własną firmę: od portalu monitorującego stan wszystkich systemów, przez obsługę trzech skrzynek pocztowych, po automat fakturowy.

Dwa wdrożenia wraz z wynikami:

• System finansowy. Na produkcji pierwszego dnia, przegląd kodu zamknięty piątego. Trzydzieści godzin pracy zamiast czterech do sześciu miesięcy w klasycznym podejściu. Zobacz, jak powstał
• Automat fakturowy. Trzy roboczogodziny budowy, comiesięczne zamknięcie skróciło się z półtorej godziny do kwadransa. Zobacz, jak powstał

Do obu liczb trzeba dodać jeden szczegół: automat fakturowy powstał w trzy godziny za drugim podejściem. Pierwsze, kilka miesięcy wcześniej, zakończyło się niepowodzeniem, ponieważ ówczesna znajomość narzędzi nie wystarczyła, żeby go domknąć. Ten sam człowiek, ten sam problem, inny poziom umiejętności.

Nie zmieniło się tempo pisania kodu. Zmieniła się wiedza o tym, co i jak budować.

Rygor da się pokazać liczbami tak samo jak tempo: testy automatyczne kluczowych systemów to 103/103, 114, 44, 25/25 i 18/18. Roadmapa ma 129 pozycji, a więc dług techniczny jest policzony. Przegląd całości kodu z końca lipca dał 13 znalezisk; oba o wysokiej wadze zostały naprawione i wdrożone.

Trzy pytania, które to weryfikują u dostawcy

Działają również na nas.

1. Kto przegląda kod, zanim trafi na produkcję? Dobra odpowiedź wskazuje konkretną osobę i moment. Zła brzmi: „AI to sprawdzi”.
2. Gdzie ta metoda Wam nie pomogła? Kto pracuje w ten sposób naprawdę, wymieni obszary bez zastanowienia. Kto tylko dopisał AI do oferty, usłyszy pytanie pierwszy raz.
3. Pokażcie system, który zbudowaliście dla siebie i którego używacie codziennie. Portfolio pokazuje, co ktoś potrafi sprzedać. Własny system pokazuje, czemu ufa na tyle, żeby na tym pracować.

Pełna lista dziesięciu pytań, razem z tym, jak brzmi zła odpowiedź na każde z nich, jest na stronie o wyborze dostawcy.

Najczęstsze pytania

Czy AI-assisted engineering to to samo, co vibe coding? Nie. W vibe codingu nikt nie czyta wygenerowanego kodu i nikt nie odpowiada za wynik. W AI-assisted engineering każdy fragment ma specyfikację przed napisaniem, przegląd człowieka po napisaniu i testy automatyczne. Autor pojęcia „vibe coding”, Andrej Karpathy, sam rozdzielił oba poziomy w kwietniu 2026, nazywając profesjonalną odmianę agentic engineering.

Czy kod pisany w ten sposób jest gorszej jakości? Bywa, i jest to ryzyko udokumentowane badaniami. Analiza GitClear pokazuje, że odsetek kodu przepisywanego wkrótce po napisaniu wzrósł z 3,3% w 2021 do 7,1% w 2025, a raport DORA 2025 notuje pogorszenie stabilności dostarczania. Metoda broni się wyłącznie tam, gdzie stoją za nią testy automatyczne i przegląd człowieka. Bez nich to szybsze produkowanie długu.

Czy to znaczy, że oprogramowanie powinno być dziś tańsze? Dla nowych systemów budowanych od zera tak, i w tym zakresie to deklarujemy. Niska cena bez zdefiniowanego zakresu nie jest jednak przewagą, lecz przeniesieniem ryzyka z dostawcy na Ciebie, które ujawni się przy każdej kolejnej zmianie.

Czy tą metodą da się utrzymywać istniejący, duży system? Tu jest najsłabszy punkt metody. Badanie METR na dojrzałych repozytoriach wykazało, że doświadczeni programiści z AI byli o 19% wolniejsi, a 45% programistów w ankiecie Stack Overflow mówi, że debugowanie kodu z AI trwa dłużej. Przy projekcie czysto utrzymaniowym na dużym legacy nie sprzedamy Ci przyspieszenia, bo go tam nie ma.

Jak sprawdzić, czy dostawca faktycznie pracuje tą metodą, czy tylko tak mówi? Poproś o pokazanie systemu, który zbudował dla siebie i którego używa codziennie. Zapytaj, gdzie ta metoda mu nie pomogła. Odpowiedź na drugie pytanie jest najlepszym testem, jaki znamy.