Budowanie systemów z AI: od promptu do produkcji
Budowanie systemów z AI polega na traktowaniu modelu jak szybkiego wykonawcy, a nie architekta. Ty piszesz specyfikację, wyznaczasz granice zmian i blokujesz każdą zmianę testami. Generowanie jest tanie — pracą jest specyfikacja i weryfikacja.
Dlaczego sam prompt przestaje wystarczać
Pojedynczy prompt potrafi wygenerować przekonujący prototyp. Nie wygeneruje systemu, bo system definiują jego granice: co się z czym komunikuje, co się dzieje, gdy zależność padnie, kto ma prawo zrobić którą rzecz. Model optymalizuje lokalnie i nie ma interesu w tym, jak to wygląda za pół roku.
Dokładnie ten rozjazd opisują dane z 2026 roku. Adopcja jest niemal powszechna, ale tylko około 29% deweloperów ufa efektowi, a około 77% trzyma go z dala od produkcji. Ci, którzy tę lukę zamknęli, nie znaleźli lepszego modelu — dołożyli strukturę wokół niego.
Programowanie sterowane specyfikacją
- Spisana specyfikacja na każdą zmianę: co ma być prawdą po zmianie, które pliki wolno ruszyć, czego nie wolno zmienić. Niedopowiedzenie w specyfikacji zamienia się w wymyśloną decyzję w kodzie.
- Testy blokujące pipeline: jeśli wygenerowanej zmiany nie da się zweryfikować automatycznie, nie wchodzi. To najtańszy i najskuteczniejszy mechanizm, jaki masz.
- Ludzki przegląd architektoniczny przy zmianach strukturalnych: nowe zależności, nowe przepływy danych, nowe granice zaufania. Reszta może jechać szybko.
Kolejność prac, która wytrzymuje zderzenie z użytkownikami
| Etap | Co robisz ty | Co robi model |
|---|---|---|
| 1. Ramy | Jedno zdanie celu i lista rzeczy poza zakresem | Nic |
| 2. Źródło | Znajdujesz komponent open source na trudną część | Streszcza kandydatów |
| 3. Specyfikacja | Definiujesz interfejsy, dane i zachowanie przy błędach | Szkicuje, ty poprawiasz |
| 4. Szkielet | Zatwierdzasz układ plików | Generuje strukturę |
| 5. Implementacja | Przeglądasz małe diffy | Pisze kod zgodnie ze specyfikacją |
| 6. Weryfikacja | Odpowiadasz za zestaw testów | Pisze testy, które czytasz |
| 7. Utwardzenie | Audyt logowania, danych wejściowych, sekretów | Pomaga, nie decyduje |
Warstwa bezpieczeństwa, której nie da się oddelegować
Badanie Stanforda wykazało, że deweloperzy wspomagani AI pisali mniej bezpieczny kod, deklarując jednocześnie większą pewność co do jego bezpieczeństwa. Pewność i poprawność rozjechały się w przeciwne strony — czyli twoje własne poczucie bezpieczeństwa nie jest użytecznym sygnałem.
Praktyczna odpowiedź to stała lista kontrolna dla każdej zmiany dotykającej granicy zaufania: uwierzytelnianie i obsługa sesji, autoryzacja na każdym endpoincie, a nie tylko w interfejsie, walidacja danych po stronie serwera, brak sekretów w generowanej konfiguracji i sprawdzenie pochodzenia zależności przed instalacją.
Miejsce komponentów open source
Najszybciej powstają te systemy, w których trudna i dobrze zdefiniowana część jest już rozwiązana przez kogoś innego, a twoją pracą jest integracja, logika domenowa i interfejs. To nie kompromis — tak powstaje większość trwałego oprogramowania.
Problemem jest znalezienie właściwego komponentu. Liczba gwiazdek mierzy popularność, nie przydatność. Każdy wpis w katalogu RepoLoot jest przeanalizowany pod kątem tego, co projekt robi, jaki problem rozwiązuje, co można na nim zbudować i jak trudne jest wdrożenie — dzięki czemu decyzja zajmuje minuty, a nie dni.
Najczęstsze pytania
- Czym jest programowanie sterowane specyfikacją?
- To sposób pracy, w którym agent AI dostaje spisane wymaganie — co ma być prawdą po zmianie, które pliki wolno mu ruszyć i czego nie wolno zmienić — zamiast otwartego promptu, a wynik jest blokowany przez automatyczne testy, zanim trafi do repozytorium.
- Jak zadbać o bezpieczeństwo kodu generowanego przez AI?
- Stosuj stałą listę kontrolną do każdej zmiany dotykającej granicy zaufania: uwierzytelnianie i sesje, autoryzacja na każdym endpoincie, walidacja danych po stronie serwera, brak sekretów w generowanej konfiguracji, sprawdzenie pochodzenia zależności. Nie polegaj na własnym poczuciu pewności — badanie Stanforda pokazało, że rośnie ono, gdy bezpieczeństwo spada.
- Czy AI może zaprojektować architekturę systemu?
- Może szkicować i krytykować, ale nie powinna decydować. Modele optymalizują lokalnie i nie mają interesu w tym, jak system wygląda za pół roku. Przegląd ludzki zostaw dla nowych zależności, przepływów danych i granic zaufania.