Projektowanie oprogramowania z AI na pierwszym miejscu od pierwszych zasad: przewodnik praktyka

Większość zespołów przyjęła AI, nie zmieniając ani jednego założenia pod nią, i właśnie dlatego wynik przyspieszył, a systemy się pogorszyły.

Oto pytanie, którego większość zespołów inżynierskich jeszcze nie powiedziała na głos: jeśli model potrafi napisać kod, to w czym właściwie mamy teraz być dobrzy?

Odpowiedzi, które słyszę, są w większości obronne. Inżynieria poleceń. Przeglądanie wyniku AI. Wiedza o tym, po które narzędzie sięgnąć. Wszystko to prawdziwe umiejętności, wszystkie wtórne wobec prawdziwego przesunięcia i żadna nie wyjaśnia tego, co widzę w praktyce: zespoły, które przyjęły te same narzędzia, w tym samym kwartale, z tymi samymi modelami, lądują w całkowicie różnych miejscach. Jedna grupa wydaje szybciej i oprogramowanie się trzyma. Druga wydaje szybciej i spędza następny kwartał na dowiadywaniu się, co zepsuła.

Te same narzędzia. Przeciwne wyniki. Ta różnica nie dotyczy modelu.

Wzmacniacz, którego nikt nie wliczył w rachunek

Raport DORA z 2025 roku o stanie tworzenia oprogramowania wspieranego przez AI podał na to liczby. 90 procent osób pracujących w technologii używa teraz AI w pracy, a ponad 80 procent uważa, że podniosła ich produktywność. Oba te wyniki nie zaskakują. Liczy się trzeci: wyższe wykorzystanie AI idzie w parze ze wzrostem przepustowości dostaw oraz ze wzrostem niestabilności dostaw, w tym samym czasie.

Przeczytaj to jeszcze raz, bo to cały argument. Narzędzie sprawiło, że zespoły przyspieszyły w wydawaniu i pogorszyły się w utrzymywaniu rzeczy w ruchu. Nie jedno albo drugie. Oba.

DORA ujmuje to tak, że AI jest wzmacniaczem: powiększa każdą praktykę, na którą trafi. Mocne systemy stają się mocniejsze. Słabe systemy przyspieszają w byciu słabymi.

To znaczy, że ciekawym pytaniem nigdy nie było „jak przyjmiemy AI”. Było „co AI w nas wzmacnia”. A odpowiedź na to wymaga cofnięcia się dalej niż jakakolwiek decyzja o narzędziu.

Rozumuj od problemu, a nie od narzędzia

Myślenie od pierwszych zasad to jedno z tych wyrażeń, które powtórzono do utraty znaczenia, więc powiem dokładnie, co przez nie rozumiem, a czego nie.

Rozumowanie przez analogię to tak wyglądało większość przyjmowania AI. Mieliśmy przebieg pracy. Pojawiła się nowa zdolność. Zapytaliśmy, gdzie ta zdolność wpasowuje się w przebieg, dodaliśmy ją w punkcie najmniejszego oporu, zwykle w tworzeniu kodu, i zostawiliśmy wszystko inne bez zmian. Spotkania na stojąco, zgłoszenia, rundy pracy, przeglądy: wszystko zachowane. Przebieg potraktowano jako dane, a narzędzie do niego dopasowano.

Rozumowanie od pierwszych zasad zadaje trudniejsze pytanie. Rozłóż proces do tego, co jest naprawdę, fizycznie prawdziwe w budowaniu oprogramowania. Potem zapytaj, które z tych prawd model zmienił, a których nie dotknął. Zbuduj od nowa z tego, co przetrwało.

Zrób to uczciwie i odkryjesz, że AI zmieniła dokładnie jedną rzecz, i nie tę, którą sprzedawała ta kategoria.

Koszt wytworzenia kodu spadł niemal do zera. Koszt rozstrzygnięcia, jaki kod powinien być, nie drgnął.

Wszystko użyteczne wynika z tej jednej asymetrii. Poniżej cztery skutki, które chciałbym, żeby każda osoba praktykująca potrafiła podać z pamięci.

Jeden: model danych jest produktem

Ekran jest najbardziej ulotną częścią każdej aplikacji i najbardziej kuszącym miejscem, by zacząć, bo to część, którą widać. Jest też częścią, której wyrzucenie powinno być najtańsze.

Model danych jest odwrotnością. Rozstrzyga, o co możesz zapytać, co możesz zindeksować, co możesz później zmienić bez migracji, która wszystkich przestraszy. Każda dalsza zdolność jest ograniczona wyborami podjętymi, albo zaimprowizowanymi, na tej warstwie.

Kiedy kod był kosztowny, ta kolejność wymuszała się sama. Nikt nie pisał ręcznie stu ekranów wobec schematu, o którym nie pomyślał, bo ręczne napisanie stu ekranów zajmowało kwartał. Generowanie usunęło tę naturalną bramę. Możesz teraz wytworzyć cały interfejs wobec modelu danych, którego nigdy nie przejrzał żaden człowiek, i będzie wyglądał na skończony.

Więc kolejność musi stać się świadoma. Najpierw model, potem umowa, potem interfejs. Nie dlatego, że tak jest tradycyjnie, ale dlatego, że to jedyna kolejność, w której kosztowne decyzje podejmuje się wtedy, gdy ich zmiana jest jeszcze tania.

Dwa: odłożona decyzja też zostaje podjęta

To ta, którą osoby praktykujące najbardziej lekceważą.

Każda decyzja, której nie podejmujesz wyraźnie, i tak zostaje podjęta. Podejmuje ją generator, w chwili generowania, z kontekstu, który nie obejmuje twojej firmy, twojej powierzchni zgodności, twojej historii migracji ani twoich planów na następny kwartał. Model nie odmawia rozstrzygnięcia. Wybiera coś prawdopodobnego i idzie dalej.

Co może jeszcze widzieć użytkownik z wypowiedzianą subskrypcją? Co się dzieje, gdy dwie osoby zmieniają ten sam wpis? Czy adres poczty jest jednoznaczny i jednoznaczny w obrębie czego? Nikt tych pytań nie zadał, więc nikt nie odpowiedział, a aplikacja ma teraz odpowiedź na wszystkie trzy, wybraną przez wnioskowanie, odnajdywalną tylko przez uderzenie w nią w produkcji.

To mechanizm stojący za tym, co społeczności twórców nazwały problemem 70 procent. Postęp staje nie dlatego, że pozostała praca jest trudna, ale dlatego, że blokują ją decyzje podjęte w milczeniu, kilkaset generacji wcześniej, których nie da się już zmienić bez rozebrania całości.

Praktyka, która to naprawia, ma teraz nazwę: rozwój oparty na specyfikacji. Zapisz najpierw wymagania, ograniczenia i kryteria sukcesu. Traktuj ten dokument jako źródło prawdy. Pozwól agentowi budować wobec niego. GitHub wydał Spec Kit, AWS wydało Kiro, a ta zbieżność nie jest przypadkiem.

Trzy: kiedy generowanie jest darmowe, ograniczenia trzeba zapisać

Przez dekady poprawność była częściowo utrzymywana przez koszt pisania kodu. Osoba z programowania wprowadzająca zasadę musiała trzymać tę zasadę w głowie. Wiedza niejawna w ludzkiej głowie była dopuszczalnym miejscem przechowywania ograniczenia, bo człowiek zawsze był w pętli.

To miejsce przechowywania już nie działa. Jeśli ograniczenie nie jest wyrażone gdzieś w formie czytelnej dla maszyny (ograniczenie schematu, typ, zasada sprawdzania, test, wyraźna linia w specyfikacji), to z punktu widzenia generatora nie istnieje. Istnieje tylko w pamięci tego, kogo zaraz zaskoczy.

To praktyczny rdzeń projektowania z AI na pierwszym miejscu i jest nieefektowny. Zepchnij niezmienniki w dół, do warstwy, która może je wymusić. „Nie puste” i „jednoznaczne” w bazie danych, a nie w obsłudze formularza. Typy na granicach, a nie w komentarzu do kodu. Autoryzacja jako zasada, którą system ocenia, a nie warunek, o którego wpisaniu w punkt dostępu ktoś pamiętał.

Każde ograniczenie, które wyniesiesz na zewnątrz, to decyzja, której model nie może już podjąć źle.

Cztery: budujesz teraz dla dwóch odbiorców

Ostatni jest najnowszy i najmniej przez zespoły przyswojony.

Twoja aplikacja ma teraz dwa rodzaje użytkownika. Jednym jest osoba patrząca na ekran. Drugim agent wywołujący interfejs programowania, który nigdy nie widzi twojego interfejsu użytkownika i którego nie przekona dobry projekt. Jeśli jakaś zdolność istnieje w twoim interfejsie użytkownika, ale nie w interfejsie programowania, to z punktu widzenia gospodarki agentów nie istnieje.

Ma to skutek projektowy: parzystość nie jest miłym dodatkiem. Wszystko, co człowiek może zrobić przez interfejs, powinno być osiągalne przez określoną, udokumentowaną, odnajdywalną powierzchnię. Dlatego też GraphQL pasuje lepiej niż REST do korzystania przez agenty: schemat, który sam siebie opisuje, jest czymś, co maszyna może zbadać, zanim człowiek napisze notatki integracyjne.

Buduj dla agenta i interfejs ludzki stanie się prostszy jako skutek uboczny. Buduj tylko dla człowieka i będziesz dorabiał interfejs programowania pod presją terminu, czyli w najgorszym możliwym momencie na jego projektowanie.

Jak pominięcie tego wygląda w danych

GitClear przeanalizował 623 miliony zmian w kodzie z lat 2023 do 2026, a obraz utrzymywalności jest zgodny ze wszystkim powyżej.

Wobec poziomu odniesienia z 2023 roku zdublowane bloki kodu są wyżej o 81 procent. Kopiowanie i wklejanie w obrębie jednego wysłania wzrosło z 9,4 procent w 2022 do 15,7 procent w pierwszej połowie 2026. Konstrukcje maskujące błędy są wyżej o 47 procent. W tym samym czasie wywołania funkcji między plikami, najwyraźniejszy dostępny sygnał ponownego użycia kodu, są niżej o 35 procent, a praca porządkująca kod załamała się z 21 procent zmian w 2022 roku do 3,8 procent w 2026.

Osoby z programowania są teraz około pięć razy bardziej skłonne kopiować i wklejać niż porządkować kod. W 2022 roku ta proporcja biegła w drugą stronę.

Nic z tego nie jest problemem jakości modelu. Dublowanie zamiast ponownego użycia, obsługa błędów, która je pochłania, zamiast wynosić na wierzch, praca porządkująca, która przestaje się dziać: to jest to, co dostajesz, gdy generowanie jest tanie, a struktura nie jest wyraźnie niczyim zadaniem. Wynik jest miejscowo prawdopodobny i globalnie niespójny, czyli dokładnie ten sposób zawodzenia, którego przebieg zaczynający od ekranu nie potrafi wykryć.

Jak pracować w ten sposób, począwszy od tego tygodnia

Nic z tego nie wymaga reorganizacji. Wymaga zmiany kolejności czterech czy pięciu nawyków.

1. Napisz model danych przed pierwszym ekranem. Encje, relacje, liczebność, co czyni wiersz jednoznacznym, co kaskadowo przechodzi przy usunięciu. Godzina tutaj jest godziną o największej dźwigni w projekcie i jest tą, którą narzędzia czynnie zapraszają cię pominąć.
2. Niech specyfikacja będzie wytworem, który przeglądasz, a nie różnica w kodzie. Jeśli specyfikacja jest poprawna, a generowanie jej wierne, przeglądanie tysięcy linii wygenerowanego kodu to teatr. Przeglądaj dokument, który je wytworzył. Spieraj się o specyfikację, dopóki spór jest jeszcze tani.
3. Wynieś na zewnątrz każde ograniczenie, które umiesz nazwać. Przed generowaniem wypisz zasady, których nigdy nie wolno naruszyć, i umieść każdą tam, gdzie system ją wymusza. Cokolwiek zostanie w rozmowie, zostanie ostatecznie naruszone przez coś, co do rozmowy nie przystąpiło.
4. Zaprojektuj interfejs programowania jako powierzchnię produktu. Potem traktuj interfejs ludzki jako jednego z jego odbiorców. To bardziej wybór kolejności niż inżynierii, a ustawienie tego późno jest tym, co czyni to kosztownym.
5. Mierz niestabilność, nie tylko przepustowość. Wniosek DORA mówi, że szybkość i kruchość wzrosły razem, więc mierzenie samego tempa pokaże ci lepszą połowę własnego trendu. Wskaźnik nieudanych zmian i czas przywrócenia to liczby, które mówią, czy wzmacniacz pracuje dla ciebie.

Ile to kosztuje

Chcę być prosto o tym kompromisie, zamiast udawać, że go nie ma.

Praca w ten sposób jest wolniejsza w pierwszym tygodniu projektu i istotnie szybsza w każdym następnym. To prawdziwy koszt, płacony z góry, dokładnie w chwili, gdy rozpęd wydaje się najcenniejszy, a konkurent wydaje coś widocznego. Będą rundy pracy, w których zespół, który to wszystko pominął, będzie wyglądał na prowadzącego.

Nie jest to też darmowe w kwestii dyscypliny. Zapisywanie ograniczeń jest mniej przyjemne niż patrzenie, jak pojawia się interfejs. Przeglądanie specyfikacji jest mniej satysfakcjonujące niż przeglądanie kodu. Te nawyki podupadają pod presją terminów, a to ta sama presja, która czyni je ważnymi.

I część tego naprawdę się nie stosuje. Jeśli w ten weekend sprawdzasz pomysł i zamierzasz wyrzucić wynik, wyrzuć go: nic z powyższego nie jest warte zachodu dla oprogramowania o dwudniowym życiu. Argument dotyczy tu aplikacji, które przeżyją swój pokaz.

Część, której nigdy nie dało się zautomatyzować

Niektóre role zbudowane wokół wytwarzania kodu się skurczą. Niektóre znikną. Udawanie inaczej nie pomaga nikomu się przygotować, a ludzie mówiący ci, że każde stanowisko w inżynierii jest bezpieczne, nie robią ci przysługi.

Ale spójrz, co ta asymetria naprawdę zrobiła. Zautomatyzowała wyrażanie decyzji i zostawiła same decyzje całkowicie nietknięte. Co budować. Czego nie budować. Które niezmienniki obowiązują. Czego system nigdy nie może zrobić. Gdzie leżą granice i komu wolno je przekraczać.

Ta praca zawsze była trudną częścią. Była tylko ukryta pod pracą pisania, dość kosztowną, by wyglądać jak zawód.

Pisanie nigdy nie było zawodem.

Powiązane lektury

Ta praktyka pogłębiona: rozwój oparty na specyfikacji. Jeśli wybierasz narzędzie: najlepsze kreatory aplikacji AI w 2026.

Często zadawane pytania

Co znaczy „projektowanie oprogramowania z AI na pierwszym miejscu”? Projektowanie aplikacji wokół założenia, że większość kodu będzie generowana, a nie pisana ręcznie, i że część odbiorców będzie agentami, a nie ludźmi. W praktyce znaczy to, że model danych, ograniczenia i umowa interfejsu programowania są określone wyraźnie z góry, bo to decyzje, których generowanie nie może podjąć za ciebie.

Czym projektowanie z AI na pierwszym miejscu różni się od samego używania narzędzi AI do kodu? Używanie narzędzi AI dodaje zdolność do niezmienionego przebiegu pracy. Projektowanie z AI na pierwszym miejscu zmienia kolejność operacji w tym przebiegu: model i umowa przed interfejsem, specyfikacja jako przeglądany wytwór, ograniczenia zepchnięte w warstwy, które je wymuszają. Badanie DORA z 2025 roku wykazało, że przyjęcie AI podniosło razem przepustowość i niestabilność, czyli to, co dzieje się, gdy narzędzie się zmienia, a praktyka nie.

Jakie są pierwsze zasady projektowania oprogramowania w epoce AI? Cztery się trzymają: model danych jest produktem, a ekran jego widokiem; każda decyzja, której nie podejmujesz wyraźnie, zostaje podjęta domyślnie przez generator; ograniczenia muszą żyć gdzieś, gdzie da się je wymusić maszynowo, a nie w czyjejś głowie; a twoja aplikacja obsługuje teraz zarówno interfejs ludzki, jak i interfejs programowania skierowany do agentów, które potrzebują parzystości.

Czy projektowanie w ten sposób zwalnia zespoły? Przenosi pracę na początek, zamiast ją dodawać. Decyzje zebrane w modelu danych i specyfikacji są decyzjami, które ktoś podejmuje tak czy inaczej: albo świadomie na starcie, albo domyślnie przez model zgadujący później. Druga droga jest źródłem poprawek, a poprawki nie są szybsze.

Czy rozwój oparty na specyfikacji to to samo co projektowanie z AI na pierwszym miejscu? Rozwój oparty na specyfikacji to praktyka; projektowanie z AI na pierwszym miejscu to szerszy zbiór skutków architektonicznych. Rozwój oparty na specyfikacji obejmuje napisanie specyfikacji i generowanie wobec niej. Projektowanie z AI na pierwszym miejscu obejmuje też kolejność modelowania danych, miejsce wymuszania ograniczeń i projektowanie dla odbiorców będących agentami obok odbiorców będących ludźmi.

Kiedy można to wszystko pominąć? Prototypy, pokazy, jednorazowe narzędzia wewnętrzne i wszystko, co planujesz odrzucić. Ten narzut warto nieść tylko dla oprogramowania, które musi przetrwać prawdziwych użytkowników, prawdziwe dane i zmianę w czasie.