Tworzenie aplikacji z AI: prototyp to dopiero początek
AI przyspiesza kodowanie, ale produkt wymaga świadomej architektury, bezpiecznego wdrożenia i utrzymania. Wyjaśniamy, gdzie zaczyna się odpowiedzialność twórcy.
Tworzenie aplikacji z AI potrafi zaczynać się od zadziwiająco dobrego efektu. Kilka poleceń, działający formularz, atrakcyjny panel i pierwsze dane. Łatwo wtedy uznać, że najtrudniejsza część pracy już za nami. Moim zdaniem właśnie tutaj trzeba zwolnić. Uruchomiony ekran nie odpowiada jeszcze na pytanie, czy powstał produkt gotowy na prawdziwych użytkowników.
Za pomocą AI czy z pomocą AI
Nie chodzi mi o językową zabawę przyimkami. W pierwszym podejściu model ma rozwiązać problem za nas, a my oceniamy przede wszystkim widoczny rezultat. W drugim pozostajemy odpowiedzialni za decyzje, rozumiemy ograniczenia i kontrolujemy zmiany. Ten sam asystent może uczestniczyć w obu procesach. Różnicę tworzy sposób pracy, nie logo narzędzia.
AI bardzo dobrze skraca drogę od pomysłu do demonstracji. Może zaproponować schemat danych, przygotować formularz i pomóc sprawdzić hipotezę. To realna korzyść, zwłaszcza przy eksperymencie o małych konsekwencjach. Nie trzeba jej umniejszać, żeby dostrzec dalszą pracę. Prototyp jest wartościowy właśnie wtedy, gdy wiemy, jakie pytanie ma rozstrzygnąć.
Architektura zaczyna się przed pierwszym ekranem
Weźmy system obsługujący kilka firm. Musimy ustalić granice danych, role użytkowników, zasady rozliczeń i sposób odzyskiwania dostępu. Dochodzą importy, usuwanie kont oraz historia zmian. Model może wygenerować każdą funkcję osobno, a mimo tego stworzyć niespójny system. Lokalnie poprawny fragment nie gwarantuje poprawnego połączenia wszystkich elementów.
Dlatego przed kodowaniem zapisałbym kilka decyzji architektonicznych. Co jest źródłem prawdy dla danych? Które operacje muszą być atomowe? Jak rozpoznajemy ponowione żądanie i kto może zobaczyć wynik? Taki opis nie musi mieć stu stron. Powinien jednak pozwalać wyjaśnić zachowanie aplikacji bez pytania modelu o jego intencje.
Podobnie wybierajmy technologie. Perspektywiczny stack to niekoniecznie zestaw najnowszych bibliotek. Ważniejsze są wsparcie bezpieczeństwa, dostępność ludzi, dokumentacja oraz koszt migracji. Oceńmy też hosting i sposób wdrażania. Narzędzie wygodne podczas demonstracji może wymagać infrastruktury, której zespół nie potrafi później utrzymać.
Kod trzeba sprawdzić również poza szczęśliwą ścieżką
OWASP zwraca uwagę na niewłaściwe zaufanie do kodu generowanego przez AI. Zaleca jego przegląd i stosowanie zwykłych praktyk bezpiecznego programowania. Nie ma osobnej taryfy ulgowej dlatego, że fragment powstał z polecenia tekstowego. Odpowiedzialność za uruchomienie pozostaje po stronie organizacji. [1]
Sprawdźmy więc coś więcej niż poprawne zapisanie formularza. Czy użytkownik jednej firmy odczyta dokument drugiej? Co zrobi system po dwukrotnym kliknięciu płatności? Jak zachowa się import przerwany w połowie? Właśnie takie przypadki pokazują, czy znamy własny produkt. Model może pomóc przygotować próby, ale ich kryteria musimy umieć uzasadnić.
Przegląd obejmuje również zależności, dane przekazywane asystentowi i uprawnienia jego integracji. OWASP zaleca kontrolę sekretów oraz weryfikację wygenerowanych zmian. Automat z dostępem do wdrożenia może zrobić więcej szkody niż błędna podpowiedź w edytorze. Dajmy mu uprawnienia adekwatne do zadania, zamiast wygody administratora całego środowiska. [2]
Infrastruktura nie powstaje od przycisku Publikuj
Tworzenie aplikacji z AI nie zwalnia nas z przygotowania zaplecza produkcyjnego. Produkcja potrzebuje domen, certyfikatów, konfiguracji poczty, kopii i monitoringu. Trzeba oddzielić środowisko próbne od prawdziwych danych. Ustalić sposób wdrażania, wycofywania zmian i przechowywania sekretów. Dochodzą zadania okresowe, kolejki oraz kontrola miejsca na dysku. Każdy element może działać poprawnie osobno, a zawieść w nieprzewidzianym połączeniu.
Sprawdzony backup oznacza również próbę odtworzenia. Monitoring powinien pokazywać niedostępność, a nie wyłącznie uruchomiony proces. Potrzebna jest osoba reagująca na alarm i instrukcja działania. Koszt tego zaplecza nie znika, gdy kod wygenerowano taniej. Zmienia się jedynie proporcja czasu poświęconego na poszczególne zadania.
NIST opisuje bezpieczny rozwój jako zestaw praktyk obejmujących przygotowanie organizacji, ochronę oprogramowania i reagowanie na podatności. To szerszy proces niż jednorazowe sprawdzenie kodu. Takie podejście pomaga uporządkować odpowiedzialność niezależnie od używanego asystenta. Dokumentację warto traktować jako punkt odniesienia, nie automatyczny certyfikat jakości projektu. [3]
Dalszy rozwój jest prawdziwym sprawdzianem
Pierwsza wersja pokazuje, czy umiemy zbudować funkcję. Kolejne pokazują, czy umiemy zmieniać system bez niszczenia istniejących danych i zachowań. Dochodzą migracje, kompatybilność integracji oraz poprawki bezpieczeństwa. Każda obietnica złożona użytkownikowi zaczyna kosztować czas. W tym miejscu łatwo oddać całą wcześniejszą oszczędność.
Tworzenie aplikacji z AI ma sens, jeśli przyspiesza świadomą pracę. Rozsądny plan obejmuje mały zakres, jawne decyzje, przegląd zmian i sprawdzalne warunki wdrożenia. Potem potrzebuje budżetu na utrzymanie, nie tylko na premierę. Jestem optymistą wobec narzędzi, które ograniczają powtarzalność. Pozostaję sceptyczny wobec obietnicy, że odpowiedzialny produkt powstaje z kilku promptów.
Źródła i data weryfikacji
2026-10-14
