Projektujcie pod sprawdzenie, a nie pod odpowiedź

Funkcja generuje szkic w dwie sekundy. Człowiek go czyta, sprawdza dwa szczegóły w innym systemie, uznaje, że ton jest zły, poprawia i wysyła. Cztery minuty. Stary sposób zajmował sześć.

Model robi wrażenie, a produkt oszczędza dwie minuty. To, czy warto go budować, zależy wyłącznie od tej drugiej liczby — i prawie nikt pod nią nie projektuje.

Dokładność nie jest miarą produktu

Dokładność decyduje o tym, jak często sprawdzanie jest łatwe. Czas sprawdzania decyduje o tym, czy w ogóle warto z funkcji korzystać — a te dwie rzeczy rozjeżdżają się w sposób, który zaskakuje zespoły.

System trafny w dziewięćdziesięciu procentach, którego wynik weryfikuje się trzy minuty, oszczędza mniej niż taki, który trafia w siedemdziesięciu i daje się sprawdzić w piętnaście sekund. Koszt weryfikacji jest tym, czego użytkownicy naprawdę doświadczają, i jest własnością projektu, a nie modelu.

Co spowalnia sprawdzanie

Nie ma z czym porównać. Odpowiedź pojawia się bez wskazania, na czym się opiera, więc weryfikacja oznacza pójście gdzie indziej. To największy pojedynczy koszt i najłatwiejszy do naprawienia.

Jednolita pewność. Wszystko podane tym samym pewnym tonem, więc użytkownik musi sprawdzać wszystko z tą samą głębokością. System oznaczający własne dwa niepewne pola pozwoliłby resztę przejrzeć.

Zmiany są niewidoczne. Przepisany dokument bez pokazania różnic zmusza do ponownego przeczytania całości. Pokazanie, co się zmieniło, zamienia zadanie trzyminutowe w dziesięciosekundowe.

Poprawka jest droga. Jeśli naprawienie jednego błędnego pola oznacza robienie wszystkiego od nowa, użytkownicy przestają poprawiać i zaczynają odrzucać — a funkcja po cichu traci wartość.

Brak pamięci. Ta sama poprawka za każdym razem uczy użytkownika, że system go nie słucha, a jego wysiłek jest marnowany.

Projektowanie pod szybką ścieżkę

Postawcie dowód obok twierdzenia. Fragment źródłowy, rekord, poprzednia faktura — jedno kliknięcie, najlepiej zero. Użytkownicy ufają systemom pokazującym tok rozumowania, a co ważniejsze sprawdzają je szybciej.

Uczyńcie niepewność strukturalną, a nie liczbową. Nie procent, tylko konkretne pola, co do których system nie był pewien, oznaczone. Procenty czyta się jako precyzję i prawie nigdy nie znaczą tego, na co wyglądają.

Pokażcie różnicę. Tam, gdzie system coś zmodyfikował, pokażcie, co zmodyfikował.

Uczyńcie częściową akceptację tanią. Przyjmij cztery pola, popraw jedno. Akceptacja albo odrzucenie całości zmusza użytkownika do decyzji grubszej niż jego rzeczywista ocena.

Pozwólcie, żeby odmowa była dobrym wynikiem. System mówiący, że nie wie, i mówiący dlaczego, jest szybszy w obsłudze niż taki, który produkuje wiarygodną odpowiedź do wyłapania.

Mierzcie to od pierwszego prototypu

Zmierzcie czas sprawdzania. Posadźcie prawdziwego użytkownika przed realistycznym wynikiem — łącznie z błędnym — i zmierzcie, ile trwa potwierdzenie albo poprawka, a potem porównajcie z obecnym sposobem pracy.

Ta liczba jest uzasadnieniem biznesowym. Da się ją zmierzyć w pierwszym tygodniu, przed zaangażowaniem budżetu inżynierskiego, i często zmienia to, co powstaje.

Wokół tej liczby układamy projektowanie aplikacji AI-native — bo funkcja generująca w dwie sekundy i wymagająca czterech minut na zaufanie niczego nie zautomatyzowała: przesunęła pracę i utrudniła jej zobaczenie.