Mission Describer: zanim AI zacznie budować, niech najpierw zrozumie

Najpierw konkret, potem wniosek. Poniżej pokazujemy tok rozumowania, ograniczenia i to, co naprawdę można z tej historii zabrać do własnej pracy.

Najdroższy błąd w pracy z AI często nie zaczyna się w kodzie. Zaczyna się kilka minut wcześniej, kiedy mówimy: „przecież wiadomo, o co mi chodzi”. Nie wiadomo. Nam wiadomo, bo od tygodni nosimy pomysł w głowie. Agent widzi tylko to, co napisaliśmy — razem z lukami, skrótami i funkcją, która po trzech wiadomościach zaczyna przeczyć pierwszemu założeniu.

Mission Describer powstał właśnie dla tego momentu. Zbudowałem go wspólnie z Codexem, więc nie będzie to recenzja udająca laboratoryjną niezależność. Znamy projekt od środka. Możemy jednak uczciwie sprawdzić, czy rozwiązuje problem, dla którego powstał, gdzie pomaga i gdzie kończy się jego kompetencja.

Długi prompt może nadal być pusty

Liczba słów nie jest miarą jakości zlecenia. Można napisać pięć ekranów o kolorach, animacjach i panelu administratora, nie odpowiadając na podstawowe pytanie: co ma się zmienić dla użytkownika?

Wtedy agent dostaje menu degustacyjne bez informacji, czy ma prowadzić restaurację, dowieźć obiad, czy zaprojektować talerz. Zaczyna zgadywać. Czasem zgaduje efektownie. To nadal zgadywanie. Mission Describer odwraca kolejność. Najpierw pyta o obecną sytuację, odbiorcę, oczekiwany rezultat, ograniczenia oraz dowód powodzenia. Technologia przychodzi później.

Od pomysłu do edytowalnej misji

Na publicznej stronie proces jest podzielony na widoczne etapy. Użytkownik zaczyna od dwóch–czterech zwykłych zdań. Nie musi znać frameworka, hostingu ani nazwy architektury. System prowadzi wywiad i zadaje jedno potrzebne pytanie naraz. Z odpowiedzi powstaje kontrakt misji:

1. Problem — co dziś nie działa, kosztuje czas albo powoduje błędy?
2. Odbiorca — kto użyje rozwiązania i w jakim kontekście?
3. Rezultat — jaka zauważalna zmiana ma nastąpić?
4. Granice — czego system nie może robić i jakie dane pozostają poza procesem?
5. Dowód — jaki test pokaże, że rezultat działa?

Najważniejszy jest krok, którego wiele generatorów nie eksponuje: decyzja człowieka. Misję można zatwierdzić, poprawić albo odrzucić. AI nie dostaje korony i kluczy do serwerowni. Dostaje konkretną robotę po zaakceptowaniu kierunku.

Fabryka AI: trzy role, jeden wynik

Po zatwierdzeniu misji interfejs pokazuje trzy role: architekta, wykonawcę i recenzenta. Architekt podważa założenia i projektuje najmniejsze użyteczne rozwiązanie. Wykonawca tworzy pliki. Recenzent porównuje rezultat z wcześniej ustalonym warunkiem powodzenia.

Trzy etykiety nie tworzą automatycznie trzech niezależnych umysłów. Wartość bierze się z rozdzielenia odpowiedzialności i sprawdzenia wyniku względem stabilnego kontraktu. Jeśli kryterium brzmi „ma być fajnie”, recenzent może co najwyżej elegancko rozłożyć ręce. Pasek postępu pokazuje aktywność. Dopiero działający artefakt i kontrola pokazują, czy misja została wykonana.

Mały przykład, który można sprawdzić

Mission Describer prezentuje działający stoper pracy. Rozpoczyna pomiar, pozwala zakończyć sesję, dopisać numer zadania i profesjonalny opis, a następnie zachować lub wyeksportować wpis. Dane zostają w przeglądarce.

To dobry dowód, bo pokazuje pełny łańcuch na małym zadaniu. Nie dowodzi, że system poprawnie zbuduje dowolny sklep, aplikację medyczną albo platformę finansową. Dowodzi czegoś węższego: dobrze ograniczona misja może doprowadzić od opisu do testowalnego narzędzia.

Prywatność nie może być przypisem

Publiczna wersja informuje, że wywiad pozostaje na urządzeniu, a formularz nie potrzebuje haseł ani tokenów. Do demonstracji nadal nie wpisujemy danych klientów, kluczy API, haseł, danych medycznych ani materiałów poufnych. „AI pomoże” nie jest zaklęciem zdejmującym odpowiedzialność za dane. Projekt z informacjami wrażliwymi potrzebuje osobnego środowiska i jawnie ustalonej ścieżki transferu.

Co działa najlepiej

Największą zaletą Mission Describer nie jest generowanie kolejnych zdań. Jest nią wymuszanie decyzji przed budową. System szczególnie dobrze pasuje do sytuacji, w której użytkownik zna problem, ale miesza go z ulubionym rozwiązaniem. „Chcę aplikację z AI, panelem, powiadomieniami i wykresem” brzmi jak lista zakupów. Lepsze pytanie brzmi: kto podejmuje jaką decyzję dzięki tej aplikacji i po czym poznamy, że robi to szybciej albo pewniej?

Gdzie kończą się możliwości

Użytkownik może udzielić błędnej odpowiedzi. Narzędzie ją uporządkuje, ale nie zna automatycznie rynku, prawa, budżetu ani zachowania przyszłych klientów. Rozbudowany wywiad ma też koszt poznawczy. Przy małej poprawce może być cięższy od zadania. Dobry system nie powinien organizować narady zarządu po to, żeby przesunąć przycisk o osiem pikseli.

Potrzebujemy też większej liczby niezależnych przypadków. Projekty Tech2u pokazują, że metoda działa w naszym środowisku, ale nie reprezentują każdej branży i skali ryzyka. Ocena 8,4 jest samooceną procesu, nie medalem z zewnętrznego laboratorium.

Werdykt Tech2u

Mission Describer rozwiązuje realny problem: zanim zaczniemy szybciej budować, musimy wiedzieć, czy budujemy właściwą rzecz. Daje strukturę rozmowie złożonej z dopisków, wyjątków i „jeszcze jednej małej funkcji”. Nie jest maszyną zamieniającą każde marzenie w produkt. Jest filtrem między intencją a wykonaniem.

Czasem najlepszą funkcją AI nie jest odpowiedź, lecz pytanie, które człowiek ominął. Zobacz publiczny Mission Describer. Demo służy do poznania procesu, nie do przekazywania poufnych danych.