Standardowy agent AI działa tak: dostaje prompt, ładuje dokumentację (albo może „drugi mózg"), przeszukuje grepem pliki źródłowe i próbuje złożyć kontekst z dostępnych danych, by wygenerować rozwiązanie oparte na swoim najlepszym domyśle.
AITM (AI Task Manager) działa inaczej. Utrzymuje własną, stale aktualizowaną bazę wiedzy o bazie kodu, którą podaje agentowi, zanim praca się w ogóle zacznie.
Pułapka projektów enterprise Przy skalowaniu dużych projektów poszczególne elementy (moduły, kod źródłowy, dokumentacja) w końcu docierają do swoich granic. Rozwój zwalnia i wpadasz w pułapkę:
• Informacje zebrane przez AI są niekompletne, rozłączne lub, co najgorsze, po prostu błędne.
• AI ufa fałszywym danym, a Ty ufasz AI.
• Kod przestaje zgadzać się z dokumentacją.
• Nawet poprawnie napisane prompty działają w iluzji, że wszystko jest w porządku, podczas gdy rzeczywistość jest zupełnie gdzie indziej.
Dodaj szczyptę halucynacji, a końcowe wyniki oddalają się daleko od oczekiwań.
Wiedza w AITM ma 4 solidne warstwy:
- Kontrakty
Logiczne jednostki łączące kluczowe informacje dla AI: testy jednostkowe, pliki źródłowe, odwołania do innych kontraktów i linki do dokumentacji.
Zobacz to w dokumentacji Business Logic & Contracts.
- Elementy DOM
Każdy element UI niesie własny tag AITM powiązany z logiką biznesową i zachowania. Za pomocą AITM Dev Tools te elementy można wstawiać bezpośrednio do promptów. AI wie dokładnie, który element modyfikuje i jakie zdarzenia się z niego wyzwalają.
Zobacz to w dokumentacji DOM Explorer.
- Zachowanie (Behaviour)
Definiuje funkcjonalność widoczną dla użytkownika: jakie akcje użytkownik może wykonać i co im zapobiega (np. kliknięcie tego przycisku uruchamia walidację, a następnie wywołuje funkcję zapisu). W zależności od potrzeb sięga to od abstrakcyjnych opisów po bezpośrednie odwołania do funkcji, klas lub plików.
- Logika biznesowa
Reguły i zależności, które w przeciwnym razie istniałyby wyłącznie w głowach programistów.
Jak AITM dba o prawdę i rozwiązuje konflikty W AITM tworzysz Task (definiujący, co oprogramowanie ma robić). System następnie generuje kod, dokumentację, kontrakty i testy.
Co się dzieje, gdy informacje są sprzeczne?
Wymagania użytkownika zawsze mają najwyższy priorytet;
Dokumentacja, kontrakty i powstały kod są weryfikowane krzyżowo względem zadania;
Jeśli pojawi się niespójność (np. wymaganie jest sprzeczne z architekturą systemu), AITM automatycznie zapisuje Bug.
Ostatecznie człowiek pozostaje jedynym autorytetem w sprawie ostatecznych decyzji. AI wskazuje konflikty, ale to człowiek decyduje, co jest poprawne.
Osobiste doświadczenie: budowanie bez ręcznego napisania ani jednej linijki kodu AITM buduję wewnątrz samego AITM. Jest w 100% napisany przez AI. Jako programista nie dotykałem kodu ręcznie. Moja rola to wyłącznie definiowanie architektury, wzorców projektowych i reguł operacyjnych.
Dzięki AI mogę projektować znacznie bardziej abstrakcyjne i złożone struktury, które pozostają ściśle rozdzielone, a jednocześnie głęboko powiązane.
Najważniejszy wniosek: dla kodu pisanego przez AI trzeba wymyślać nowe architektury i wzorce - takie, które są bardzo czytelne dla AI, nawet jeśli dla ludzi wydają się złożone. Z AI nie ograniczają Cię granice techniczne, tylko Twoja zdolność do projektowania architektury i zarządzania nią.
Co robię inaczej i co dalej To, co omówiłem w poprzednich artykułach, dotyczy podobnie większości orkiestratorów AI. Tu zaczynamy się wyróżniać.
W nadchodzących wpisach rozbiorę konkretne różnice w AITM - wyjaśnię, czym się różnimy, dlaczego wybraliśmy tę drogę i jakie korzyści z tego płyną.
Dziś AITM liczy ponad 500 000 linii kodu i nawet w tej skali jestem w stanie zarządzać całym procesem jako samotny programista. Wyniki są znacznie lepsze i, w przeciwieństwie do gotowych zestawów opartych na luźno połączonych agentach i wtyczkach, nic nie wymyka się spod kontroli.
