Wiedza właściciela, która zmienia kod
Dwie rozmowy, dwie konkretne zmiany: rozpoznanie otwartej transkrypcji i świadome przejęcie zadania od automatu. Co potwierdza kod, a co wymaga odbioru.
2026-09-25 · 1.0 · PL / EN
01 / Opowiedz, co robisz po kolei
Redaktor kończy rozmowę, wybiera fragment nagrania, uruchamia transkrypcję i zaznacza początek oraz koniec cytatu. Tekst już widzi. Chce dodać go do materiału. Program każe jednak ponownie otworzyć tę samą transkrypcję w innym miejscu. Z perspektywy kodu może to być poprawny warunek. Z perspektywy człowieka oznacza powtarzanie wykonanej pracy.
Właściciel warsztatu wie, jak zadanie przebiega naprawdę. Najbardziej użyteczna uwaga nie musi brzmieć „zmień tę funkcję”. Wystarczy precyzyjny opis kolejnych czynności, miejsca zatrzymania i oczekiwanego następnego kroku. Dwa historyczne przypadki z rozwoju Szpiega+ pokazują, jak taka rozmowa staje się zmianą kodu.
02 / Przypadek pierwszy: tekst jest już otwarty
W rozmowie z 15 września 2026 r. właściciel opisał drogę od nagrania do zaznaczonego fragmentu. Problemem było rozpoznanie przez program, czy transkrypcja jest otwarta. Wcześniejszy warunek szukał jej w jednym konkretnym widoku. Tekst dostępny w innym miejscu interfejsu nie spełniał tej definicji.
Zmiana zapisana tego dnia sprawdza także aktywny kontener powiązany z właściwym plikiem. Kontener musi nadal należeć do dokumentu strony; sama zapamiętana nazwa nie wystarcza. Dzięki temu kod rozpoznaje otwarcie transkrypcji poza dotychczasowym widokiem. To konkretna zmiana warunku, a nie jedynie nowy napis na przycisku.
Ważne jest to, co zachowano: dodanie fragmentu nadal wymaga wskazania pliku i wersji transkrypcji. Wygodniejsza droga nie powinna gubić informacji o tym, z którego tekstu pochodzi wybór. Przypadek nie uzasadnia twierdzenia, że każdy fragment z dowolnego okna można przyjąć bez kontroli. Pokazuje naprawę zbyt wąskiego rozpoznawania już wykonanej czynności.
03 / Przypadek drugi: automat zajmuje stanowisko
Druga rozmowa dotyczyła lokalnego procesu transkrypcji działającego w tle, nazywanego w warsztacie „mrówką”. Rezerwacja chroniła zadanie przed kolizją. Gdy proces już pracował, interfejs pokazywał ostrzeżenie i zatrzymywał dalszą drogę. Właściciel potrzebował możliwości świadomego przejęcia zadania, nawet jeśli oznaczało to porzucenie rozpoczętej pracy i zamówienie płatnej transkrypcji.
W historycznej zmianie kodu tę drogę udostępniono zarówno dla zadania oczekującego, jak i pracującego. Dialog dla trwającej pracy opisuje konsekwencje: przerwanie procesu, utratę wykonanej pracy i uruchomienie płatnego toru. Przycisk potwierdzenia odróżnia przerwanie pracy od zwolnienia samej rezerwacji. Człowiek ma otrzymać wybór razem z jego kosztem.
To opis zmiany interfejsu i zamiaru projektowego. Sam dialog nie dowodzi, że wszystkie drogi wykonania wymuszają potwierdzenie. Odczytana funkcja ma również wariant awaryjny na wypadek niedostępności mechanizmu dialogu. Dlatego nie przedstawiamy tej poprawki jako kompletnego, przetestowanego zabezpieczenia. Odbiór przejęcia musi objąć także tę sytuację oraz rzeczywiste zatrzymanie procesu.
04 / Dwie poprawki, dwa różne warunki
W pierwszym przypadku usuwamy zbędne powtórzenie: program uznaje czynność wykonaną w innym widoku, zachowując powiązanie z wersją. W drugim oddajemy decyzję osobie uprawnionej, pokazując skutki przerwania automatu. Łączy je wiedza o pracy człowieka, ale nie jedna uniwersalna reguła „usuń blokadę”.
„Nie każ mi otwierać drugi raz” nie oznacza „zapomnij o wersji”. „Pozwól mi przejąć” nie oznacza „nie ostrzegaj o koszcie”. Ten rozdział warto zapisać jeszcze przed zleceniem poprawki agentowi.
05 / Co potwierdza źródło
Podstawą jest wewnętrzna broszura z 16 września 2026 r. oraz bezpośredni odczyt dwóch zmian w historii kodu z 15 września. Dla obu przypadków zestawiono opis potrzeby z odpowiednią różnicą między wersjami. Publikujemy parafrazę i autorski schemat, bez całych rozmów, prywatnych identyfikatorów i treści nagrań.
Dowód pozwala powiedzieć: określona potrzeba została opisana, a w kodzie zapisano odpowiadającą jej zmianę. Nie pozwala obliczyć oszczędności czasu ani liczby unikniętych błędów. Nie wykonaliśmy w tym wydaniu nowego testu produkcyjnego. Przy drugiej zmianie historyczny zapis wyraźnie pozostawiał wdrożenie do decyzji właściciela; nie zamieniamy go w deklarację obecnego stanu usługi.
06 / Jak odebrać podobną poprawkę
Dla pierwszego przypadku otwórz transkrypcję w każdym obsługiwanym widoku, zaznacz fragment i sprawdź jego powiązanie z właściwym plikiem oraz wersją. Osobno sprawdź brak wersji i nieaktualny widok. Oczekiwanie zapisz przed uruchomieniem próby.
Dla przejęcia zadania sprawdź osobno oczekiwanie i pracę automatu, anulowanie decyzji, potwierdzenie oraz niedostępność dialogu. Sprawdź, czy ostrzeżenie odpowiada rzeczywistemu kosztowi i czy poprzedni proces rzeczywiście przestaje wykonywać zadanie. To proponowany plan odbioru, nie lista testów wykonanych w tym artykule. Karta uprawnień agenta pomaga ustalić, kto może podjąć taką decyzję.
07 / Mała karta zmiany dla lidera
Zapisz pięć rzeczy: co robię, gdzie staję, co chcę zrobić dalej, jaki warunek musi pozostać i po czym poznam poprawę. Dołącz wersję wejścia oraz dowód odbioru. Taka karta daje agentowi konkretny problem i granice rozwiązania. Rozdzielenie kontroli kodu i człowieka pomaga uniknąć zbyt szerokich wniosków z zielonego testu.
Jeżeli w Twoim warsztacie pojawia się podobne „przecież już to zrobiłem”, możemy zacząć od odtworzenia jednej ścieżki pracy. Wystarczy neutralny opis czynności i przeszkody. Szczegóły rozwiązania można omówić w rozmowie, bez publikowania prywatnych danych i całych sesji.
08 / Pochodzenie i korekty
Źródła sprawdzono 25 września 2026 r. To studium historycznych decyzji, nie instrukcja aktualnej wersji Szpiega+. Oryginalną broszurę opracowano z udziałem Codex i Claude Code. Publiczną adaptację PL/EN, diagram i odbiór autorski tego wydania przygotował Codex; nie przeprowadzono niezależnego przeglądu drugiego modelu ani pomiaru produkcji.
Nie wykorzystano cudzych ilustracji ani nagrań. Kontrola człowieka obejmuje możliwość wycofania po publikacji. Odnalezienie sprzeczności między rozmową a zmianą kodu, nowy dowód wdrożenia lub wynik odbioru przejęcia zadania uruchamia ponowny przegląd. Nowy wynik trzeba opisać z własną datą i zakresem.