Czwartek, koniec calla z klientem. PM po stronie klienta mówi: „So basically we need a simple dashboard, real-time, for all users. Should be quick, right?”. Tech lead odpowiada: „Sounds good, we'll send you something”. Wszyscy się uśmiechają, ktoś rzuca „great call, guys” i ekran gaśnie.
W tym jednym zdaniu PM przemycił cztery wymagania, z których żadne nie jest wymaganiem. „Simple” nie ma definicji. „Real-time” może znaczyć sto milisekund albo „odświeżone rano”. „All users” to trzech managerów albo czterdzieści tysięcy klientów końcowych. A „quick, right?” to nie pytanie, tylko estymacja, którą klient właśnie zrobił za Ciebie.
Na lekcjach słyszę tę scenę co tydzień, zmieniają się tylko rekwizyty. Uczeń opowiada o callu, a ja pytam: „Co dokładnie znaczyło real-time?”. Pauza. „No… real-time”. I wtedy obaj wiemy, że za trzy sprinty ktoś będzie przepraszał.
Ten artykuł jest o tym, żeby przestać ufać zdaniom. Nie ludziom. Zdaniom.
Huśtawka, która wisi na każdej konferencji
Znasz ten obrazek. Huśtawka na drzewie w kilkunastu wersjach: jak to wyjaśnił klient, jak to zrozumiał analityk, jak to zaprojektował architekt, jak to napisał programista, jak to opisała dokumentacja (brak kadru) i czego klient naprawdę potrzebował (opona na sznurku). Rysunek krąży po branży od kilkudziesięciu lat i nadal budzi śmiech (przez łzy) na każdej prezentacji, co samo w sobie jest dość wymowną metryką.
W 2026 roku do tego komiksu dochodzi nowy kadr: jak to wygenerowało AI. Trzy huśtawki, zjeżdżalnia, basen, pełne pokrycie testami i komentarz „this implementation is production-ready”. Wszystko spójne, pewne siebie i zbudowane na założeniu, którego nikt nie wypowiedział.
Śmieszne do momentu, w którym policzysz koszt. W 2024 roku Junade Ali przebadał 600 inżynierów oprogramowania z Wielkiej Brytanii i USA na potrzeby książki „Impact Engineering”. Projekty, w których jasne wymagania istniały przed startem developmentu, miały o 97% większą szansę na sukces, a te ze spisaną specyfikacją o 50% większą. To ankieta, nie eksperyment, a jej wnioski o Agile rozgrzały branżowe fora do czerwoności, ale w sprawie wymagań kierunek trudno podważyć. Projekty rzadko wykolejają się przez złą technologię. Wykolejają się przez zdania, które brzmiały jasno.
Zero Trust, tylko dla zdań
W bezpieczeństwie model Zero Trust (NIST opisał go w publikacji SP 800-207 w 2020 roku) opiera się na prostej zasadzie: żadne żądanie nie jest zaufane tylko dlatego, że przyszło z wewnątrz sieci. Każde trzeba uwierzytelnić, autoryzować i zweryfikować, za każdym razem.
Zero Trust Spec to ta sama filozofia przeniesiona na wymagania. Żadne zdanie z calla nie trafia do backlogu tylko dlatego, że padło z ust klienta i wszyscy kiwali głowami. Każde musi przejść trzy bramki:
Uwierzytelnienie. Kto to powiedział i czy ma prawo o tym decydować? Pomysł rzucony przez stażystę z marketingu to nie wymaganie, to sugestia.
Mój klient pracuje w jednej z największych firm medialnych, która dystrybuuje między innymi płyty CD znanych artystów. Jego nowy projekt brzmiał rozsądnie: dodać do systemu magazynowego wyprzedaż produktów ze skazą. Porysowane pudełka, pognieciona okładka, towar, który nie nadaje się na półkę, ale wciąż gra. Pracował nad tym pół roku. Potem centrala o projekcie zwyczajnie zapomniała. Kiedy zaczął dopytywać, okazało się, że projekt nigdy nie dostał zatwierdzenia z góry. Pół roku pracy, ogromne koszty, a jedynym produktem ze skazą okazał się sam projekt.
Pytania, które warto zadać, zanim powstanie pierwsza linijka kodu: “Who’s the budget owner for this?”, “Has this been signed off, and by whom?”, “If this gets deprioritised, who will let us know?”. Brzmią formalnie, ale właśnie tak wygląda uwierzytelnienie w praktyce. Sprawdzasz nie tylko, co masz zbudować, ale też, kto naprawdę tego chce.
Autoryzacja. Czy to jest w zakresie, na który jest budżet? Jeśli nie, zdanie ląduje w sekcji „out of scope”, a nie w sprincie.
Weryfikacja. Czy da się napisać do tego test akceptacyjny? Jeśli nie, to znaczy, że jeszcze nie wiesz, co budujesz.
Brzmi paranoicznie? Dobrze. Paranoja w specyfikacji jest tańsza niż zaufanie na produkcji.
Dlaczego ustalenia z calla parują
Są dwa mechanizmy, które sprawiają, że rozmowa, która „poszła świetnie”, tydzień później nie istnieje.
Pierwszy to pamięć. Krzywa zapominania, opisana przez Hermanna Ebbinghausa jeszcze w XIX wieku, nie ma litości dla ustaleń z calla: już następnego dnia z rozmowy zostaje ułamek. Dlatego podsumowanie wysyła się tego samego dnia, najlepiej w ciągu 2-4 godzin. Po tygodniu Ty pamiętasz swoją wersję, klient swoją i żadna z nich nie pokrywa się nawet w 50%.
Drugi mechanizm jest groźniejszy, bo działa już w trakcie rozmowy: iluzja przejrzystości. Thomas Gilovich, Kenneth Savitsky i Victoria Medvec opisali ją w 1998 roku w Journal of Personality and Social Psychology. Ludzie systematycznie przeceniają to, jak dobrze inni odczytują ich stany wewnętrzne. Przełóż to na wymagania: klient jest przekonany, że „simple dashboard” jest oczywisty, bo ma go przed oczami. Ty jesteś przekonany, że „real-time” jest oczywisty, bo masz w głowie WebSockety. Obaj macie rację, tylko każdy w innym repozytorium.
I tu wchodzi angielski. W stresie, w obcym języku, mózg ma mniej mocy na podważanie cudzych słów. Najłatwiej jest przytaknąć. „Sounds good” to najdroższe dwa słowa, jakie słyszę na lekcjach, i uczniowie mówią je odruchowo, tak jak po polsku mówi się „jasne”.
Słownik słów, które brzmią jak wymaganie
Niektóre słowa w rozmowie z klientem działają jak zmienne bez przypisanej wartości. Kompilują się w rozmowie, wywalają się w produkcji. Oto te, które wracają najczęściej, z pytaniem, które je rozbraja.
| Słowo z calla | Co może znaczyć | Pytanie, które to rozbraja |
|---|---|---|
| “real-time” | od 100 ms do „odświeżone raz dziennie” | “How old can the data be before it's a problem? A second, a minute, an hour?” |
| “simple” | „mało ekranów” albo „mało kosztuje” | “What's the one thing a user must be able to do on day one?” |
| “all users” | 3 adminów albo 40 000 klientów | “Who logs in first? Roughly how many people in the first month?” |
| “integrate with X” | link, eksport CSV, dwukierunkowa synchronizacja | “Which way does the data go, and who fixes it when the two systems disagree?” |
| “secure” | hasło albo pełny audyt zgodności | “Is there a standard or an audit we need to pass?” |
| “ASAP” | jutro albo „przed konkurencją” | “What happens if it ships two weeks later? Is there a hard date behind it?” |
| “done” | zmergowane, na stagingu, u klienta | “What would you need to see to call it finished?” |
Zwróć uwagę, że żadne z tych pytań nie brzmi jak przesłuchanie. Każde pyta o konsekwencję, a nie o technologię. Klient nie wie, ile milisekund to „real-time”, ale doskonale wie, kiedy nieaktualne dane zaczynają go kosztować.
AI jako audytor, nie autor
Teraz część, dla której ten artykuł powstał. Większość zespołów, z którymi pracują moi uczniowie, używa AI do specyfikacji w najgorszy możliwy sposób: wklejają notatki i piszą „turn this into a technical spec”. Model robi dokładnie to, o co go poproszono. Tam, gdzie brakuje informacji, wstawia rozsądne domyślne wartości. Wynik wygląda profesjonalnie, ma nagłówki, tabele i kryteria akceptacji, a połowa z nich nigdy nie padła w rozmowie.
To są halucynowane wymagania. Są gorsze od halucynowanego kodu, bo kod przynajmniej nie przejdzie testów. Halucynowane wymaganie przejdzie przez review, bo brzmi rozsądnie, trafi do kontraktu i za pół roku ktoś zapyta, dlaczego system usuwa dane po 30 dniach, skoro nikt tego nie chciał.
Branża zaczyna to rozumieć. W 2025 roku GitHub udostępnił jako open source Spec Kit, zestaw narzędzi do spec-driven development, w którym specyfikacja staje się głównym artefaktem pracy z agentem, a nie przypisem do promptu. Kierunek jest jasny: im więcej kodu pisze maszyna, tym więcej wart jest człowiek, który wie, co dokładnie ma powstać.
Zasada, którą proponuję, jest odwrotna do intuicji: AI nie pisze specyfikacji. AI ją przesłuchuje. Model ma szukać luk, sprzeczności i słów bez definicji, a potem zamienić je na pytania. Odpowiedzi daje człowiek, najlepiej ten, który płaci.
Surowy materiał. Wszystko jest tu hipotezą, nawet to, co padło trzy razy.
Każde twierdzenie jako osobna, atomowa linia, z cytatem źródłowym i statusem: potwierdzone, założone, brakujące, sprzeczne.
Lista pytań do klienta. Zero wymyślonych wartości. Każda luka staje się pytaniem, nie domysłem.
Krótki mail w ciągu kilku godzin: decyzje, założenia do korekty, poza zakresem, otwarte pytania z właścicielem i datą.
Pisemne „yes, that's correct” albo lista poprawek. Dopiero teraz zdanie staje się wymaganiem.
Jedna uwaga praktyczna, zanim wkleisz cokolwiek do modelu. Transkrypt rozmowy z klientem to dane klienta. Używaj narzędzia, które Twoja firma zatwierdziła do takich danych, a nie prywatnego konta w publicznym czacie. Zero Trust obowiązuje w obie strony.
Strict prompt, gotowy do skopiowania
Tytuł tego artykułu to nie bez powodu: „Loose ideas. Strict prompt.”. Luźne pomysły są w porządku, bo klient ma prawo myśleć na głos. Ścisły musi być prompt, bo model domyślnie jest uprzejmy, a uprzejmość w specyfikacji oznacza zgadywanie. Oto wersja, którą daję uczniom jako punkt startowy:
Jesteś audytorem wymagań, nie autorem.
Wejście: notatki lub transkrypt rozmowy z klientem.
1. Wyodrębnij każde zdanie, które sugeruje wymaganie.
Jedno atomowe twierdzenie na linię. Zacytuj zdanie źródłowe.
2. Oznacz każdą linię: POTWIERDZONE / ZAŁOŻONE / BRAKUJĄCE / SPRZECZNE.
3. Wskaż każde nieprecyzyjne słowo (szybko, prosto, real-time,
wszyscy użytkownicy, bezpiecznie, ASAP, integracja, gotowe)
i wyjaśnij, dlaczego jest nieprecyzyjne.
4. NIE wymyślaj wartości, ustawień domyślnych, liczb ani technologii.
Jeśli czegoś brakuje, zamiast tego napisz pytanie.
5. Wypisz sprzeczności między twierdzeniami.
6. Przygotuj ponumerowaną listę pytań do klienta,
prostym językiem biznesowym, maksymalnie 20 słów każde,
posortowaną według ryzyka dla budżetu i harmonogramu.
7. Tylko dla linii POTWIERDZONE: zaproponuj kryteria akceptacji
w formacie Given / When / Then (Zakładając / Gdy / Wtedy).You are a requirements auditor, not a writer.
Input: notes or a transcript from a client call.
1. Extract every statement that implies a requirement.
One atomic statement per line. Quote the source sentence.
2. Tag each line: CONFIRMED / ASSUMED / MISSING / CONFLICT.
3. Flag every vague word (fast, simple, real-time, all users,
secure, ASAP, integrate, done) and explain why it is vague.
4. Do NOT invent values, defaults, numbers or technologies.
If something is missing, write a question instead.
5. List contradictions between statements.
6. Output a numbered list of questions for the client,
in plain business English, max 20 words each,
sorted by risk to budget and timeline.
7. Only for CONFIRMED lines: draft acceptance criteria
in Given / When / Then format.Najważniejszy jest punkt czwarty. Bez niego dostaniesz piękny dokument pełen domysłów. Z nim dostaniesz brzydką listę pytań, która jest warta więcej niż dwadzieścia stron specyfikacji. Brzydka lista pytań to najlepszy deliverable tygodnia, którego nikt nie wrzuci na LinkedIna.
Drugi trik: po odpowiedziach klienta puść ten sam prompt jeszcze raz, na nowej wersji. Jeśli liczba linii oznaczonych jako założone nie spada, znaczy to, że pytania były zbyt ogólne, a nie że klient jest trudny.
Warstwa językowa: must, should, may
W 1997 roku Scott Bradner napisał dokument RFC 2119, jeden z najkrótszych i najbardziej wpływowych tekstów w historii internetu. Ustala w nim, co dokładnie znaczą w specyfikacjach słowa MUST, SHOULD i MAY. MUST to bezwzględny wymóg. SHOULD oznacza, że mogą istnieć ważne powody, by w konkretnej sytuacji zrobić inaczej, ale trzeba rozumieć konsekwencje. MAY to opcja.
Dla polskiego inżyniera to jest mina. Po polsku „system powinien” w specyfikacji zwykle znaczy „system musi”, tylko grzeczniej. Po angielsku „the system should” czyta się jako „fajnie by było”. Na lekcjach widzę to regularnie: uczeń pisze dokument pełen „should”, klient traktuje połowę jako opcjonalną i obie strony mają rację, każda według swojego słownika.
- "The system should send a confirmation email after payment."
+ "The system must send a confirmation email within 60 seconds of a successful payment."Reguła operacyjna: w każdym dokumencie dla klienta zrób wyszukiwanie „should” i przy każdym wystąpieniu zdecyduj, czy chodzi o must, czy o may. Trzeciej opcji nie ma, bo trzecia opcja to spór za trzy miesiące.
Kilka innych pułapek, które poprawiam najczęściej:
„We will try to” brzmi jak obietnica, a jest jej brakiem. Klient zapamięta „will”, Ty zapamiętasz „try”. Zamień na zobowiązanie z warunkiem: “We'll deliver it by the 15th if we get API access by the 5th.”
Realize to nie „realizować”. „We will realize the integration” brzmi, jakbyście mieli dopiero zauważyć, że integracja istnieje. Chodziło o deliver, build albo implement.
Dedicated to nie „dedykowany” w sensie „szyty na miarę”. „A dedicated solution” brzmi jak rozwiązanie bardzo oddane sprawie. Chodziło o custom albo tailored.
„There is a possibility to export data” to kalka z „istnieje możliwość”. Naturalnie: “Users can export data to CSV.”
„We can discuss about it” to klasyk. Discuss nie potrzebuje about, tak jak git commit nie potrzebuje słowa „please”.
Liczby zamiast przymiotników. “Fast” nie jest wymaganiem. “95% of searches return results in under 800 ms with 200 concurrent users” jest. Pierwsze da się obiecać każdemu, drugie da się sprawdzić.
Kto siedzi naprzeciwko
Ta sama specyfikacja trafia do różnych ludzi, a każdy z nich czyta inną jej część. Jeśli piszesz jeden dokument dla wszystkich, piszesz go dla nikogo.
Founder z wizją nie przeczyta dwudziestu stron. Przeczyta pierwszy akapit i sekcję „out of scope”, bo tylko tam widzi, że ktoś mu coś zabiera. Dlatego zakres musi brzmieć jak decyzja o kolejności, a nie jak odmowa.
- "Multi-language support is out of scope."
+ "Version one ships in English. Polish and German come in phase two, and the design already leaves room for them."Product owner po stronie klienta jest Twoim najlepszym sojusznikiem i największym ryzykiem jednocześnie, bo zna słowa API, endpoint i sprint, ale używa ich w nieco innych znaczeniach. Z nim działa prosta technika, która na lekcjach okazuje się zaskakująco trudna dla Polaków: zacznij parafrazę od „Correct me if I'm wrong, but what I'm hearing is…”. Po polsku brzmi to przesadnie grzecznie, więc uczniowie ją pomijają. Po angielsku to zaproszenie do korekty, które nie odbiera nikomu twarzy.
- "OK, so a report endpoint. Got it."
+ "Correct me if I'm wrong, but what I'm hearing is: a report for any date range, generated on demand, not a nightly summary. Is that right?"Procurement i dział prawny czytają tylko to, co da się zmierzyć i przypisać. Dla nich każde wymaganie potrzebuje kryterium odbioru, a każde zobowiązanie strony, która je wykonuje. „The client will provide test data” bez daty to zdanie, które w razie sporu nie chroni nikogo.
Tech lead po stronie klienta przeczyta wszystko, łącznie z przypisami, i znajdzie przypadek brzegowy, o którym nie pomyślałeś. Traktuj go jak darmowy code review, a nie jak przeciwnika. Zdanie, które otwiera współpracę: “What would break this in your environment?”
Historie z lekcji
Real-time, który kosztował trzy sprinty
Uczeń, senior backend developer, przyszedł na lekcję wyraźnie dumny. Jego zespół zbudował dashboard na WebSocketach, z aktualizacją co sekundę, z fallbackiem na long polling, pięknie. Klient na demo zapytał uprzejmie: „Nice. But why does it keep moving? I just want to see yesterday's numbers when I get to the office.”.
Zapytałem go, jakie pytanie zadał na kick-offie po słowie „real-time”. Odpowiedział szczerze: żadne, bo przecież wiadomo, co to znaczy. Przez następne dwadzieścia minut ćwiczyliśmy jedno zdanie: “How old can the data be before it's a problem?”. Podsumował to potem krótko: nauczył się go trzy sprinty za późno, a te trzy sprinty ktoś zapłacił.
Cisza, która odblokowała wymaganie
Inny uczeń, architekt w software housie, miał zwyczaj, który znam u wielu Polaków: po pytaniu do klienta, jeśli odpowiedź nie przychodziła od razu, sam ją podpowiadał. „So you mean the export, right? Like a CSV?”. Klient chętnie się zgadzał, bo zgodzić się jest łatwiej niż myśleć.
Umówiliśmy się na eksperyment: po pytaniu do klienta cisza, bez ratowania go podpowiedzią. Przez całą lekcję ćwiczyliśmy jedną rzecz: zadać pytanie i zamilknąć, podczas gdy ja liczyłem w myślach do pięciu, a on walczył z odruchem ratowania rozmowy. Na następnym callu, po pauzie, która według niego trwała mniej więcej geologiczną epokę, klient powiedział: „Actually, it's not really an export. Our accountant needs to see it every month and she hates spreadsheets”. Zamiast przycisku CSV powstał miesięczny raport PDF wysyłany mailem. Mniej kodu, więcej zadowolenia i jedna lekcja o tym, że najlepszym narzędziem do zbierania wymagań bywa zamknięcie ust.
Wymaganie, którego nikt nie wypowiedział
Senior developer, z którym pracowałem przed kwartalnym review, przez dwa sprinty przenosił aplikację na najnowszą wersję frameworka. Nowy router, nowy system budowania, zależności świeże jak poranny build. Na review pokazał benchmarki, wykres czasu kompilacji i ogłosił z dumą: “We're fully up to date now”. PM zapytał uprzejmie: “Great. Which of the things we asked for does this unlock?”. Developer otworzył usta, zamknął je i otworzył Jirę. Biznes o upgrade nie prosił, a dwie funkcje z roadmapy przesunęły się o miesiąc.
To ta sama choroba, o której jest cały ten artykuł, tylko widziana z drugiej strony stołu. Tym razem wymaganie wymyślił nie klient i nie model, tylko inżynier. Upgrade mógł być świetną decyzją, ale nikt jej nie podjął. Zdanie, od którego powinna się zacząć ta historia, zanim poszedł pierwszy commit: “I'd like to upgrade the framework. It takes two sprints and cuts build time in half. Is that worth delaying the reporting feature?”. Zero Trust obowiązuje też wobec własnych pomysłów, zwłaszcza tych, które wydają Ci się oczywiste.
„Why do we need this?”, czyli demo bez puenty
Na lekcjach często robimy symulację demo. Uczeń pokazuje funkcję, którą jego zespół właśnie skończył, a ja gram osobę z biznesu i zadaję jedno pytanie: “Why do we need this feature?”. I zaczyna się wycieczka po stosie technologicznym: nowy endpoint, kolejka, cache, a teraz wszystko jest asynchroniczne. Po dwóch minutach wiem wszystko o architekturze i nic o tym, po co to w ogóle powstało.
Najczęściej nie jest to problem z angielskim. Uczeń po prostu nigdy nie usłyszał odpowiedzi na to pytanie, bo nikt go nie zadał na etapie wymagań. Funkcja przyszła jako ticket, ticket przyszedł z calla, a na callu padło „sounds good”. Demo tylko obnaża brakujące ogniwo w łańcuchu.
Odpowiedź, którą potem ćwiczymy, ma dwa zdania i zero technologii: “It lets the sales team send quotes in minutes instead of a day. That was their main complaint last quarter.”. Jeśli nie umiesz jej ułożyć, masz pytanie do klienta, a nie lukę w słownictwie.
Zderzenia, które zdarzają się co tydzień
Koniec calla. Mówisz „sounds good”, klient słyszy „zgadzam się na wszystko, w tym na to, czego nie zrozumiałem”.
- "Sounds good, we'll send you something."
+ "Let me play it back to make sure I got it right. I'll send a written summary today, and nothing goes into the sprint until you confirm it."Estymacja z biegu. Mówisz „should be doable”, klient słyszy „tak, w tym budżecie”.
- "Should be doable."
+ "I can't size it yet. Two questions first, then you'll have a number by Tuesday."Nowy pomysł w połowie projektu. Mówisz „we'll see what we can do”, klient słyszy „dodane”.
- "We'll see what we can do."
+ "Good idea. It's not in the current scope, so I'll add it to the change list with a cost, and you decide if it replaces something."Niejasne zadanie po spotkaniu. Piszesz „the team will look into this”, czyli zdanie, które wygląda jak zadanie, a jest mgłą. Nikt nie wie, kto ani kiedy.
- "The team will look into the SSO question."
+ "Confirm which SSO provider you use - Anna (client side) - by Friday, 2 October."Specyfikacja z AI wysłana bez przeglądu. Piszesz „please find the spec attached”, klient słyszy „to wszystko jest uzgodnione”.
- "Please find the full technical spec attached."
+ "Attached is a draft. Section 2 is what we agreed. Section 3 lists our assumptions. Please correct anything that's wrong before we plan the sprint."Co wdrożyć w tym tygodniu
Pięć minut na koniec każdego calla przeznacz na odbicie. „Before we go, let me play back what I heard.” Trzy zdania, trzy decyzje, jedno pytanie: “Did I miss anything or get anything wrong?”. To najtańszy test regresji, jaki kiedykolwiek napiszesz.
Recap wysyłasz tego samego dnia. 24 godziny to maksimum, 2-4 godziny to ideał. Po tygodniu recap nie jest już podsumowaniem, tylko interpretacją.
Szablon recapu, do trzymania pod ręką:
Temat: [Projekt] - co ustaliliśmy [data]
Decyzje:
1. [decyzja, jednym zdaniem]
Założenia (popraw, jeśli są błędne):
1. [założenie] - działamy według niego, chyba że dasz znać inaczej
Poza zakresem tej fazy:
1. [element] - zaplanowane na [faza / później]
Otwarte pytania:
1. [pytanie] - [osoba] - do [data]
Następny krok: [kto co robi] do [data].
Jeśli coś tu nie zgadza się z Twoim rozumieniem,
odpisz do [data], a poprawimy to przed planowaniem.Subject: [Project] - what we agreed on [date]
Decisions:
1. [decision, in one sentence]
Assumptions (please correct if wrong):
1. [assumption] - we'll proceed on this unless you say otherwise
Out of scope for this phase:
1. [item] - planned for [phase / later]
Open questions:
1. [question] - [owner] - by [date]
Next step: [who does what] by [date].
If anything here doesn't match your understanding,
reply by [date] and we'll fix it before planning.Każdy punkt akcji ma cztery elementy: czasownik, konkretne zadanie, osoba, data. Jeśli brakuje któregokolwiek, to nie jest zadanie, tylko życzenie.
Strict prompt trzymaj w repo, obok szablonu PR-a. Wersjonuj go jak kod. Kiedy halucynowane wymaganie przecieknie do dokumentu, nie obwiniaj modelu. Dopisz regułę do promptu, tak jak dopisujesz test po bugu.
Zrób audyt słowa „should”. Otwórz ostatni dokument wysłany klientowi i policz wystąpienia. Każde zamień na must albo may. Jeśli nie wiesz, na które, to właśnie znalazłeś pytanie do klienta.
Ćwiczenie na trening, które zadaję uczniom jako pracę domową: weź notatki z ostatniego calla i napisz po angielsku trzy listy. Co wiemy na pewno. Co zakładamy. O co nikt nie zapytał. Jeśli trzecia lista jest pusta, nie znaczy to, że wszystko jest jasne. Znaczy to, że jeszcze nie szukałeś.
Klient ma prawo mówić luźno. Myśli na głos, zmienia zdanie, rzuca pomysły w połowie zdania. Twoją rolą nie jest go uciszyć, tylko przepuścić każde zdanie przez bramki, zanim trafi do kodu. Luźne słowa są surowcem. Kontrakt jest produktem. Pomiędzy nimi stoisz Ty, Twój angielski i prompt, który nie pozwala maszynie zgadywać.
Źródła:
- Lack of upfront specifications kill agile projects (Computer Weekly, 2024)
- The illusion of transparency: biased assessments of others' ability to read one's emotional states (Gilovich, Savitsky, Medvec, 1998)
- NIST SP 800-207: Zero Trust Architecture (2020)
- RFC 2119: Key words for use in RFCs to Indicate Requirement Levels (Bradner, 1997)
- Spec-driven development with AI: Get started with a new open source toolkit (GitHub Blog)