AI pisze plany, ale to Ty trzymasz kurs - o weryfikacji planów generowanych przez AI

Lubię czytać plany generowane przez AI. Ale nie puszczam ich bez sprawdzenia.

Zazwyczaj są sensowne. Czasem wymagają drobnych poprawek. A czasem robią nie to, czego się oczekuje.

To przykład warstwy kontroli w Agent Engineering: projektowaniu ról, kontekstu, review i pomiaru pracy agentów. Review planu jest checkpointem przed kosztowną implementacją.

Case study: plan SEO, który wyglądał dobrze

Plan poprawek SEO dla projektu Next.js wyglądał poprawnie. Checklisty. Best practices. Na pierwszy rzut oka - wszystko grało.

Do momentu, gdy zobaczyłem:

27 ręcznych edycji plików
Custom middleware do obsługi canonicali
Własna logika redirectów zamiast wbudowanych mechanizmów frameworka

Co by się stało, gdybym tego nie sprawdził?

Pewnie nic spektakularnego. Nie byłoby crasha. Nie byłoby alertu.

Byłoby gorzej:

Kilka godzin dłubania w plikach rozlanych po całym repo
Code review, którego nikt nie chce robić
Większe ryzyko regresji
„Dlaczego to jest w tylu miejscach?“ za 3 miesiące

A potem klasyczny maintenance nightmare:

Zignorowane feature’y frameworka, które już to rozwiązują
Własne custom patterny „bo tak wyszło z planu“
Naprawianie objawów zamiast root cause
Coraz więcej kodu tylko po to, żeby obsłużyć wcześniejszy kod

I w końcu: „Nie ruszaj tego, bo SEO się rozsypie.“ Nie dlatego, że problem był trudny - tylko dlatego, że został rozwiązany w zły sposób.

Jedna technika, która ratuje sytuację

Zamiast implementować, zrobiłem jedną rzecz. Kazałem agentowi sprawdzić własny plan:

Please review this plan to ensure it is sound,
kept as simple as possible (avoiding over-engineering),
and aligns with Next.js best practices.

Odpowiedź była jednoznaczna:

CRITICAL CORRECTION - REVISED PLAN

Overengineered - 27 ręcznych edycji to nie jest droga Next.js

Zły root cause - canonicals powinny być ustawione centralnie

Ignorowanie platformy - metadataBase rozwiązuje to systemowo

307 redirects - to poprawne i18n behavior, nie bug

Efekt końcowy

Przed (plan AI v1)	Po (plan AI po weryfikacji)
27 ręcznych edycji plików	1 zmiana w konfiguracji
Custom middleware	Wbudowane `metadataBase`
Rozproszona logika	Centralne rozwiązanie
Własne redirecty	Framework robi to sam

Jedna zmiana w konfiguracji. Czyste repo. Rozwiązanie zgodne z frameworkiem. Zero „SEO refactor sprintu“.

Dlaczego AI robi takie błędy?

AI rzadko psuje produkcję od razu. AI psuje ją powoli. Dokłada:

Zbędne kroki
Rozproszoną logikę
Techniczny chaos, który „wydaje się OK“

Bez nadzoru AI zachowuje się jak junior: robi dużo, ale nie rozumie architektury. Agent doskonale odpowiada na pytanie „JAK to napisać?“ - ale to Ty musisz wiedzieć „CZY w ogóle powinniśmy to pisać?”.

Praktyczny prompt do weryfikacji planów

Używam tego wzorca za każdym razem, gdy agent generuje plan z więcej niż kilkoma krokami:

Review this plan for:
1. Over-engineering - can it be simpler?
2. Framework alignment - does it use built-in features?
3. Root cause - are we fixing the actual problem or symptoms?
4. Maintenance cost - will this be easy to maintain in 6 months?

To trwa 30 sekund, a potrafi zaoszczędzić godziny pracy i tygodnie maintenance’u.

Wniosek

Nie oddawajcie AI sterów nad architekturą. Niech wiosłuje, ale to Wy trzymajcie kurs.

Różnica między seniorem a „klepaczem kodu“ nie polega na tym, kto szybciej pisze. Polega na tym, kto wie, czego nie pisać.

Plan jest tak dobry, jak wymagania, z których powstał. Dlatego przed planowaniem warto mieć PRD z jasnymi kryteriami akceptacji, a same wymagania sprawdzić promptem do oceny User Story.