Problem ze specyfikacją nie jest nowy – AI tylko go ujawnił

W agentycznym programowaniu kryje się niewygodna prawda: wąskim gardłem nigdy nie było pisanie kodu. Zawsze chodziło o decyzję, co właściwie zakodować.

Fred Brooks opisał to już w 1986 roku w książce No Silver Bullet. Pokazał, że wielkie innowacje – jak programowanie obiektowe czy współdzielenie czasu – dają tylko małe zyski. Bo walczą z accidental complexity, czyli bałaganem w pisaniu kodu. A nie z essential complexity – czyli trudem myślenia o problemie. W software engineeringu najwięcej roboty pochłania faza specyfikacji: dogadanie się ze stakeholderami, wybór kompromisów i opisanie systemu, którego jeszcze nie ma.

Teraz oddaliśmy generowanie kodu AI. Wszyscy myślą, że specyfikacja też zniknie. Nic z tego.

Czym różnią się "szczegółowe opisy" od "specyfikacji w naturalnym języku"

Tu zaczyna się zamieszanie. Wiele narzędzi – od generatorów PRD po walidatory specyfikacji – zakłada: skoro AI zada dobre pytania, luki w specyfikacji same się wypełnią.

To błąd. Naturalny język jest nieprecyzyjny. Dlatego wymyślono notacje formalne.

Możesz napisać piękną specyfikację produktu – brzmi dobrze, opowiada historię, wszyscy kiwają głowami. Ale brakuje jej technicznej ostrości, jakiej potrzebuje AI do wygenerowania solidnego kodu. "Użytkownik ma zobaczyć dashboard w mniej niż 2 sekundy" to nie to samo co "P95 latency dla dashboardu analytics <2000 ms, z limitem P99 na 5000 ms". Wygląda na styl, a to różnica między specyfikacją a luźnym opisem.

Daj AI niejasną specyfikację, a dostaniesz:

1. Kod dziwny technicznie. Działa, ale architektura do niczego. Refaktoryzacja zajmie sprinty.

2. AI wypełni luki po swojemu. Weźmie wzorce z danych treningowych – tysiące podobnych projektów – i doda założenia, których nie chciałeś.

Żaden wariant nie wygrywa.

Gdzie agentyczne kodowanie działa (i gdzie nie)

Agentyczne narzędzia błyszczą w prostych zadaniach. Landing pages, CRUD appki, integracje boilerplate, standardowe sklepy e-commerce. To problemy, gdzie rozwiązań jest masa w danych treningowych. AI nie wymyśla – dopasowuje wzorce.

To ma wartość. Solowy founder mnoży produktywność x10. Mały team klepie narzędzia administracyjne w godziny, nie tygodnie. Prawdziwy boost.

Ale haczyk: sukces bierze się z klarownej specyfikacji, nie mimo niej. Obszar jest tak dobrze znany, że specyfikacja może być prawie ukryta.

W reszcie – customowa logika biznesowa, nowe integracje, decyzje architektoniczne na przyszłość – myślisz po ludzku. AI przyspiesza pisanie. Nie myślenie. Nie odmówi złego pomysłu, bo wykona, co każesz.

Jak powiedział jeden dev: "AI napisze kod, ale nie powie 'zaczekaj, lepiej zrobić X najpierw'." To myślenie produktowe, nie kod. I nikt tego nie zastąpi.

Prawdziwy bottleneck: tarcia w komunikacji między ludźmi

Skoro specyfikacja jest trudna, a AI jej nie rozwiązuje – co pomaga?

Prosta odpowiedź: zmniejsz tarcie w rozmowach między ludźmi.

Gdy product manager przekazuje brief devowi, a ten tydzień spędza na wyjaśnieniach edge cases i trade-offach – masz problem ze specyfikacją. Gdy mockupy designera kolidują z backendem – problem. Gdy AI generuje kod na bazie złych założeń biznesowych – problem.

Rozwiązanie? Nie lepszy agent czy framework. Precyzja w rozmowach ludzi przed uruchomieniem AI.

To oznacza:

• Specyfikacja jako kluczowy artefakt. Nie dokument na boku, ale kontrakt dla generowania kodu.
• Dokumentacja trade-offów. Dlaczego eventual consistency, a nie strong? Jaki data model i dlaczego? Zapisz to.
• Notacje formalne tam, gdzie liczy się precyzja. Schematy SQL, kontrakty API, budżety performance – narzędzia wymuszające jasność.
• Wczesne pętle z AI. Wygeneruj mały kawałek kodu pod specyfikację, zobacz ambiguitety i popraw.

Co to znaczy dla twojego workflowu

Budujesz systemy z AI? Nie rezygnuj z agentów. Inwestuj w specyfikację mocniej niż kiedykolwiek.

Brzmi dziwnie w erze "move fast". Ale szybkie błędy w złej specyfikacji to tylko szybsze pudła. Team'y, które wygrywają z agentami, myślą twardo z góry. Używają AI do wykonania, nie wymyślania.

Dla startupów i małych teamów: przewaga nie w generowaniu kodu. W klarownej specyfikacji. Jeśli opiszesz logikę biznesową tak, że AI to ogarnie – wygrałeś. Kod to już banał.

Podsumowanie

Brooks miał rację w 1986. Ma w 2025. Essential complexity software to nie budowa, a koncepcja. AI nie zmieniło tego – tylko uwypukliło różnicę między mgłą myśli a precyzyjnym kodem.

Następny skok produktywności? Nie z lepszych agentów. Z teamów, które dyscyplinują specyfikację, traktują requirements engineering jak core skill i używają AI do wzmacniania jasności, nie maskowania chaosu.

To szansa na styku AI i dev. Wymaga jednego, czego AI nie da: głębokiego myślenia o tym, co budujesz.