“Gdyby AI istniał od samego początku”: Taniejszy kod nie sprawił, że decyzja o tym, co zbudować, stała się łatwiejsza

Przez większość historii oprogramowania najdroższą częścią było jego tworzenie. Zespoły spędzały miesiące na przekształcaniu pomysłów w działający kod, a ta rzadkość kształtowała wszystko wokół organizacji pracy.

Mapy drogowe były sekwencjonowane wokół dostępnej pojemności inżynierskiej; architekci zdobywali swoje miejsce przy stole, ponieważ rozumieli systemy, których nikt inny nie rozumiał; menedżerowie produktów spędzali tygodnie na tłumaczeniu niejasnych biznesowych próśb w coś, co deweloper mógł wykonać. Pisanie oprogramowania było wąskim gardłem, i naturalnie, pisanie było tam, gdzie tkwiła siła.

To już nie jest prawdą, a zmiana nastąpiła szybciej, niż większość liderów inżynierskich miała czas, aby ją przyswoić.

Narzędzia kodowania AI zmniejszyły koszt wdrożenia. Praca, która wcześniej zajmowała zespołowi inżynierów tygodnie, teraz zajmuje agentowi tylko kilka godzin. I najwyraźniejsze założenie było takie, że szybsze budowanie przekłada się bezpośrednio na szybszą dostawę wartości.

Czy co się naprawdę stało, jest jednak bardziej skomplikowane: zespoły mogą teraz produkować więcej oprogramowania, niż wiedzą, co z nim zrobić, a rzecz, która ich spowalnia, cicho przeniosła się gdzie indziej.

“Nie możesz zastosować AI do złamanego procesu”, powiedział Pablo Gamba, dyrektor technologii w Ameryce w globalnym startupie oprogramowania i rozwiązań AI intive. “To jak dać szybszą łopatę robotnikowi. Będzie pracował szybciej, ale tylko w złym kierunku.”

Szybsza realizacja, stare ograniczenie

Każda duża zmiana w technologii – internet, chmura i outsourcing – miała taki sam kształt. Coś, co wcześniej było drogie, stało się tanie niemal z dnia na dzień, a wszystko, co firma zbudowała na założeniu tego kosztu, musiało zostać zdemontowane i odbudowane.

Tym razem taniejącą rzeczą jest sama stosowana inteligencja techniczna, która akurat jest tym, za co firmy usługowe i zespoły inżynierskie spędziły dziesięciolecia, pobierając opłaty, twierdzi Gamba .

Taniejsza realizacja nie sprawia, że ograniczenie znika, tylko przenosi się w mniej widoczne miejsce. Przykładowo, wąskie gardło kodowania, w migrującym procesie, przyspieszyło wdrożenie, ale przeszkodą jest teraz przegląd kodu. Zautomatyzuj przegląd kodu, a pojawia się w testowaniu i wdrażaniu; zautomatyzuj to również, a ostatecznie ląduje na ludziach, którzy piszą specyfikacje, które agenci wykonują.

Ponieważ agent może zbudować tylko to, co zostało opisane wystarczająco precyzyjnie, aby działać bez zgadywania.

To pułapka, w którą wiele zespołów wpada teraz, często nie zauważając. Jeśli możesz zbudować prawie wszystko w ułamku czasu, jaki zajmowałoby to wcześniej, koszt budowy złej rzeczy rośnie, a nie maleje, ponieważ dowiesz się, że byłeś niepoprawny szybciej i z większym już dostarczonym.

Założenie, które wcześniej pojawiało się powoli, w ciągu tygodni ręcznego kodowania, może teraz stać się nośnym elementem infrastruktury, zanim ktokolwiek zada pytanie. Priorytet, a nie surowy wynik, decyduje o tym, czy inwestycja w AI naprawdę się opłaca.

W tym paradygmacie Gamba uważa, że firmy powinny śledzić nie szybkość rozwoju, ale pełny cykl od intencji do produkcji. “Jeśli poprawisz szybkość rozwoju, ale kontrola jakości jest twoim wąskim gardłem, po prostu osiągnąłeś kontrolę jakości szybciej. Następnie naprawiasz kontrolę jakości, a wąskie gardło przenosi się do wymagań”, powiedział.

Liczby potwierdzają to. Przedsiębiorstwa z listy Fortune 50, które używają AI-wspomaganego rozwoju, dostarczają commity 3-4 razy szybciej niż ich koledzy, zgodnie z badaniem Cloud Security Alliance, ale wprowadzają nowe ustalenia dotyczące bezpieczeństwa w przybliżeniu dziesięciokrotnie częściej.

Szybkość bez wyraźnego kierunku, w tym sensie, nie tylko marnuje wysiłek; zwiększa ryzyko szybciej, niż większość zespołów bezpieczeństwa może dotrzymać tempa.

Przenoszenie wymagań do języka, który AI może naprawdę wykorzystać

Jeśli definicja jest teraz prawdziwym ograniczeniem, rozwiązanie nie polega na więcej dokumentacji. To inna dokumentacja, napisana w formie, którą system AI może wykonać bez wypełniania luk samodzielnie.

To oznacza wycofanie dokumentu wymagań napisanego dla ludzi do interpretacji z osądem i zastąpienie go sformalizowanymi kryteriami akceptacji, jawnymi modelami domenowymi i testami umownymi, które wyjaśniają, co funkcja powinna robić, tak jasno, jak to, co nie powinna.

Agenci, przecież, wypełniają niejasność w taki sam sposób, jak młodszy inżynier, z pewnym przypuszczeniem. Różnica polega na tym, że przypuszczenie tego ostatniego przychodzi owinięte w pewną wahanie, flagą dla starszego kolegi, poczuciem, że coś może być nie tak.

Przypuszczenie agenta wygląda zupełnie inaczej. Pojawia się jako czysty, płynny, w pełni ukształtowany kod, i nie ma w nim żadnej rezerwy, nawet gdy jest błędne.

Pisanie specyfikacji wystarczająco precyzyjnej, aby przetrwać tę lukę, zaczyna się czuć mniej jak pisanie notatki produktowej, a bardziej jak pisanie umowy. Nazwij każdego aktora, zmapuj każdy przejście stanu, które system jest upoważniony do podjęcia, i uwzględnij przypadki brzegowe, zamiast cicho pozostawić je ścieżce szczęśliwej, w sposób, w jaki większość dokumentów wymagań nadal robi.

Zespoły, które traktują to jako zadanie dokumentacyjne, uczą się w bolesny sposób, że niejasna intencja po prostu produkuje niejasne oprogramowanie z prędkością maszyny.

Zespoły, które naprawdę zdobywają korzyści produktywności, są tymi, które traktują pisanie takich specyfikacji jako odrębną dyscyplinę inżynierską, z tym samym kontrolowaniem wersji, cyklami przeglądu i rygorem testowania, który wcześniej był zarezerwowany dla samego kodu.

W słowach Gamba, AI-natywny nie jest pozwoleniem na pominięcie procesu, ale żądaniem przebudowy od podstaw. “Wiele organizacji próbuje zastosować AI do starych procesów. To nie jest transformacja. Organizacje AI-natywne zaczynają od innego pytania: jeśli AI istniał od samego początku, jak bylibyśmy projektowali ten proces dzisiaj?”

Menadżerowie backlogu, kuratorzy intencji

Produkt, architektura i inżynieria dawniej działały jako trzy oddzielne funkcje z czystymi przekazami między nimi: produkt decyduje, co zbudować, architektura ustala, jak to zrobić, inżynieria dostarcza to.

Gdy wdrożenie staje się tanie i szybkie, te przekazy stają się najwolniejszą częścią całego łańcucha. To, co tu się liczy, to ktoś, kto może trzymać cały obraz na raz, przetłumaczyć intencję na coś, co agent może wykonać, i złapać złe założenie, zanim stanie się wysłanym kodem, którego nikt nie chciał.

To przeprojektowanie kształtuje teraz, kto definiuje, i jaki jest ten job.

“Pomyśl o tym, co się dzieje z rolą inżyniera oprogramowania. Nie piszą już tylko kodu. Nadzorują wynik agentów, definiują specyfikacje, przygotowują testy, walidują wyniki. To łączenie tego, co kiedyś było trzema oddzielnymi rolami, w jedną”, powiedział Gamba.

Innymi słowy, to, co teraz ma wartość, to nie wiedza, jak pisać bilety lub prowadzić sprinty. To wiedza, co “wielkie” wygląda, zanim praca nawet się zacznie, umiejętność rozróżniania, co jest intelektualnie interesujące, a co klienci naprawdę potrzebują, i odwaga, aby szybko zabić pomysł, gdy jasno nie spełnia tej poprzeczki.

Te sądy, które kiedyś były rozproszone po menedżerze produktu, architekcie i tech lead porównującym notatki. Coraz częściej lądują na kimś, kto jest najbliżej definiowania pracy od samego początku.

I warto pamiętać: żadne z tego nie sprawia, że tytuły znikają. Ale linie między nimi stają się coraz trudniejsze do obrony, a ludzie, którzy prosperują w tym rozmyciu, są tymi, którzy działają jako kuratorzy intencji.

Szybka realizacja bez barier nie jest wygraną

Istnieje ryzyko, które łatwo stracić z oczu, gdy intencja jest już jasna, a potok AI naprawdę działa: szybka, dobrze zdefiniowana realizacja może nadal wprowadzać awarie, które wolniejszy, bardziej ludzki proces by łapał prawie przypadkowo.

Liczby tutaj są nieporównywalne. Testy wiosenne 2026 roku Veracode przeprowadzone na wiodących modelach wykazały, że tylko 55% zadań generowania kodu dało bezpieczny wynik, gdy nie podano jawnych wskazówek dotyczących bezpieczeństwa, co jest liczbą, która praktycznie nie zmieniła się w ciągu dwóch lat, nawet gdy dokładność funkcjonalna znacznie wzrosła.

Jasne, uzyskanie poprawnej składni przestało być trudną częścią już dawno. Sądy, które ludzki inżynier kiedyś podejmował instynktownie, podczas pisania, dotyczące bezpieczeństwa, zgodności i tego, jakie dane powinny i nie powinny dotykać systemu, są częściami, które są trudne do zastąpienia.

To oznacza, że ten sam rygor, który jest stosowany do definiowania, co zbudować, musi sięgać definiowania, co jest zabronione, takich jak granice zgodności, reguły obsługi danych i ograniczenia etyczne, wyjaśnione z taką samą starannością, jak wymagania funkcjonalne.

Pozostawienie ich niejawnych i liczenie na to, że agent je poprawnie domyśli, jest tym samym błędem, co pozostawienie wymagań produktu niejasnych i krzyżowanie palców, aby budowa jakoś się udała.

Czym jest przywództwo

Nic z tego nie przemawia przeciwko rozwojowi przyśpieszonemu przez AI; budowanie nigdy nie było szybsze ani tańsze, i nie ma powrotu do poprzedniego stanu.

Ale to, co nie stało się łatwiejszym, a nawet trudniejszym, to decyzja z prawdziwą precyzją, co warto zbudować, opisanie tego wystarczająco dobrze, aby maszyna mogła wiernie wykonać, i narysowanie linii, której nie wolno przekroczyć podczas tego procesu.

Na poziomie przedsiębiorstwa zespoły, które wyprzedzają innych, nie są tymi z najszybszymi agentami kodowania, to jest jasne. To te, które wcześniej niż ich konkurenci zrozumiały, że definicja zawsze będzie trudniejszym problemem – i zaczęły ją traktować w ten sposób.