Specyfikacja, którą przeczyta i człowiek, i AI
Jeśli opiszecie aplikację tylko w czacie z AI, każda kolejna wersja trochę się rozjedzie. Ustrukturyzowana specyfikacja daje zespołowi i narzędziom wspólny punkt odniesienia.
Narzędzia, które z opisu generują interfejs albo całą aplikację, poprawiają się niewiarygodnie szybko. Testowałem v0, Lovable i Claude Code i wszystkie potrafią w kilka minut pokazać coś, co kiedyś zajęłoby dni. Problem pojawia się przy drugiej i trzeciej iteracji. Wymagania żyją w historii czatu, każdą zmianę opisuje się od nowa, a wynik powoli rozjeżdża się z tym, czego chcieliście.
Źródło prawdy poza czatem
Dlatego traktuję specyfikację jako osobny plik. W ustrukturyzowanym formacie, na przykład w YAML, opisuję encje, ekrany, role, reguły i powiązania między nimi. Jest to czytelne dla człowieka, można to wersjonować w repozytorium Git i równie dobrze przeczyta to model językowy.
Co to daje
- Zmianę wprowadza się w jednym miejscu. Poprawia się specyfikację i na jej podstawie generuje na nowo to, co trzeba.
- Kontrola, zanim powstanie kod. Na ustrukturyzowanym pliku można uruchomić linter, który wyłapie brakujące powiązania, niezdefiniowane role albo sprzeczne reguły.
- Różne wyniki z jednego źródła. Z tej samej specyfikacji może powstać interfejs w Vue, w React albo dokumentacja dla klienta.
- Klient rozumie, co zatwierdza. Struktura jest bardziej przejrzysta niż pięćdziesiąt stron tekstu.
Gdzie jest granica
Specyfikacja nie zastąpi podejmowania decyzji. Nadal potrzebny jest ktoś, kto wie, po co aplikacja powstaje i co ma rozwiązywać. Specyfikacja tylko pilnuje, żeby ta decyzja nie zgubiła się po drodze między ludźmi a narzędziami.
Co to ma wspólnego z mniejszymi zespołami
Kiedy AI przejmuje dużą część generowania, wąskim gardłem przestaje być pisanie kodu. Staje się nim precyzja wymagań. Zespół, który potrafi dokładnie opisać, czego chce, zbuduje z pomocą AI więcej niż zespół, który tylko szybko pisze. A precyzyjne określenie wymagań to praca na styku biznesu, produktu i technologii.