Gdy organizacja zaczyna przeszkadzać w pracy
Asystenci AI potrafią pomagać w wielu projektach, ale potrafią też rozbudować własną administrację. Ten przypadek pokazuje, jak mechanizm mający porządkować zadania stał się źródłem opóźnień i co zmieniliśmy.
1. Co rejestr miał robić
W kilku rozmowach prowadziliśmy równolegle różne sprawy. Potrzebowaliśmy wspólnego, krótkiego stanu: co zlecono, kto odpowiada, czy jest zgoda, co wykonano, co blokuje dalszy ruch i jaki jest następny krok. Taki spis pomaga unikać podwójnej pracy, powtarzania pytań i ponownych wysyłek.
Rejestr był naszym dodatkowym narzędziem. Sam Windows i ChatGPT nie wymagają takiego pliku do działania. Powinien on oszczędzać więcej pracy, niż kosztuje jego obsługa.
2. Jak pomocny spis urósł do ponad 300 MB
Do bieżących stanów zaczęły dochodzić dawne wersje, pełne dowody, rozbudowane dane kontrolne i kolejne aktualizacje. Mechanizm zachowywał te informacje ostrożnie, lecz nie miał dostatecznie jasnej granicy między stanem operacyjnym a archiwum.
Pomiar spójnej kopii pokazał około 333 MB danych. Z tego około 321 MB zajmował dział aktualizacji, w tym około 320,7 MB sam dziennik dawnych zdarzeń. Rekordy spraw miały około 10,3 MB, ale również zawierały historię i obszerne dowody. Ostateczna kopia przed odchudzeniem miała już 336,7 MB.
Zmiana jednego krótkiego statusu wymagała więc przetwarzania dużej ilości informacji, których nie potrzebowaliśmy do tej decyzji. Kolejne czaty ustawiały się do tego samego pliku. W jednym przebiegu samo oczekiwanie na blokadę trwało 4 minuty 54 sekundy, przed właściwym zapisem.
3. EPERM: nie każdy błąd z Windows pochodzi z usterki Windows
Niezależnie od rozmiaru pojawiał się błąd EPERM podczas bezpiecznej podmiany pliku. Zapis tworzył kompletną nową wersję, a potem miał zastąpić nią poprzednią. Odtworzyliśmy wariant problemu z czytnikiem nadal korzystającym ze starej wersji i poprawiliśmy współpracę czytnika z zapisem. Nie ustaliliśmy jednak, który konkretny proces trzymał plik podczas historycznej awarii.
Pierwotne testy obejmowały konkurujące zapisy, lecz zabrakło właściwego scenariusza z długo otwartym czytnikiem. Wcześniejszą odmowę zbyt szybko przypisaliśmy ograniczeniom środowiska. Powinniśmy byli odtworzyć ją dokładniej, zanim uznaliśmy mechanizm za wystarczająco sprawdzony.
Pomogło połączenie dwóch zmian: czytnik dopuszcza współdzielenie wymagane przy podmianie, a zapis używa udokumentowanej funkcji Windows FileRenameInfoEx z odpowiednimi flagami. Czytelnik kończy starą, spójną wersję; nowe otwarcie widzi kompletną nową. Test przy stale otwartym zgodnym czytniku wykonał 12 zapisów i 292 pełne odczyty bez błędu.
To diagnoza tego konkretnego mechanizmu. Nie jest dowodem, że każdy użytkownik Windows 11 lub ChatGPT ma taki problem, ani że każda odmowa EPERM ma tę samą przyczynę. Rzeczywiste odmowy dostępu nadal muszą być respektowane.
4. Pytanie użytkownika, które zmieniło kierunek
„Po co nam ten rejestr?”
Po naprawie błędu mogliśmy kontynuować dokładanie zabezpieczeń i kolejnych warstw. Użytkownik zapytał jednak o cel narzędzia. Rozważaliśmy jego wycofanie, a następnie przyjęliśmy prostsze rozwiązanie: zachować użyteczny bieżący stan i usunąć z aktywnego pliku to, co jest historią.
W rejestrze pozostały podstawowe informacje o sprawie i odnośniki do szczegółów. Pełną wcześniejszą historię zabezpieczyliśmy w osobnym archiwum, sprawdzając zgodność jego sumy kontrolnej. Krótkie stany spraw wykonanych i odrzuconych zostały zachowane, żeby dawnego działania nie wykonać ponownie.
Wprowadziliśmy też politykę zmian: zapis przy nowym istotnym zadaniu, decyzji lub zgodzie, zmianie właściciela albo zakresu, ważnej blokadzie i zakończeniu. Sam odczyt, nowa godzina sprawdzenia, powtórzony status lub kolejna obserwacja nie zmieniają pliku. Historia w dokumentacji projektu ma być uzupełniana zbiorczo przy etapie lub zamknięciu, bez zapisu po każdym drobnym kroku.
5. Porównanie pojedynczych pomiarów: przed i po
To zestawienie rzeczywistych przebiegów, o które poprosił użytkownik. Trzeba przy nim zachować informację, gdzie wykonano pomiar i czego on nie dowodzi.
| Miara | Poprzednio | Po zmianie | Jak czytać wynik |
|---|---|---|---|
| Rozmiar aktywnego pliku | 336,7 MB | 3,16 MB | Około 99% mniej danych w aktywnym rejestrze. Historia zachowana osobno. |
| Odczyt | Około 30–34 s | 0,41 s na działającym rejestrze | Orientacyjnie około 80 razy krócej w tych pojedynczych pomiarach. |
| Zapis bez czekania w kolejce | Około 3 min | 1,73 s na prywatnej kopii rzeczywistych danych | Orientacyjnie około 100 razy krócej. Nowy zapis nie był pomiarem operacji produkcyjnej. |
| Oczekiwanie na blokadę | W jednym przebiegu dodatkowo 4 min 54 s | Brak porównywalnego pomiaru całej organizacji | Nie doliczamy tego oczekiwania do czasu samego zapisu i nie obiecujemy zniknięcia kolejek. |
Na wąskim ekranie tabelę można przewijać w poziomie.
6. Naprawiony mechanizm też warto uprościć
Kolejny przegląd wykazał, że nawet mały plik był kilka razy odtwarzany jako pełna struktura JSON. Dwa z tych przebiegów powtarzały pracę na bajtach, których zgodność i tak była sprawdzana.
Usunęliśmy powielone odtwarzanie struktury oraz drugą normalizację tych samych rekordów. Poprawność przygotowanej treści jest sprawdzana raz, a suma kontrolna potwierdza zgodność zapisanego pliku tymczasowego i końcowego. Pozostają kontrola właściciela, źródła i zakresu, blokada, kopia, sprawdzenie równoczesnej zmiany, synchronizacja zapisu i odczyt wyniku.
| Miara | Przed uproszczeniem kodu | Po uproszczeniu kodu |
|---|---|---|
| Liczba prób | 5 | 5 |
| Mediana zapisu | 1,34 s | 0,64 s |
| Zakres zaobserwowanych czasów | 1,23–1,60 s | 0,60–0,79 s |
| Wynik i kopia | Wyniki logiczne zgodne; wszystkie sumy kopii zgodne; powtórzone statusy bez zapisu. | |
W tych próbach mediana skróciła się o około 52%, czyli zapis był około 2,1 razy szybszy. To lepiej kontrolowane porównanie niż pierwszy etap, ale nadal mała próba na jednym środowisku i z lokalną pamięcią podręczną. Nie jest pomiarem przepustowości wszystkich projektów.
7. Wąskie gardła w procedurach i kontekście
Źródłem narzutu może być nie tylko kod. W jednym wierszu wspólnego arkusza przechowywaliśmy drugą pełną kopię instrukcji pracy — około 29 tysięcy znaków. Niektóre proste wyszukiwania zwracały więc także cały ten tekst. Powielona kopia mogła dodatkowo rozchodzić się z aktualnym źródłem.
Uprościliśmy ten układ do jednego pełnego źródła instrukcji oraz krótkich aktualnych zasad i odnośnika w arkuszu. W obrębie aktywnego zadania nie trzeba ponownie pobierać niezmienionych dokumentów ani od nowa rozpoznawać tej samej integracji. Ponowny odczyt jest potrzebny po zmianie źródła, nowym zakresie, przerwie, błędzie lub sprzeczności. Przed istotnym zapisem i wysyłką nadal sprawdzamy potrzebne aktualne dane.
Doprecyzowaliśmy też, że naprawa, kontynuacja i nowy techniczny identyfikator sprawy nie oznaczają nowego projektu wymagającego propozycji nazwy czatu. Nie ustaliliśmy źródła konkretnej opcji zmiany nazwy widocznej w interfejsie; nie przypisujemy jej więc z pewnością tej regule.
Krótka, dziesięciosekundowa obserwacja panelu pokazała około 0,27% CPU całego komputera dla głównego procesu i około 0,01% dla czytnika. Nie uznaliśmy tego za podstawę do kolejnej przebudowy działającego panelu. Nie każdy element, który można zoptymalizować, jest wart optymalizacji.
8. Przyczyny, które łatwo powtórzyć
- Rozmycie celu. Lista bieżących spraw zmienia się w archiwum wszystkiego.
- Brak budżetu wzrostu. Nie ustalamy, jak duży ma być aktywny stan i ile może kosztować jego obsługa.
- Aktualizacja po każdym kroku. Rejestrujemy fakt sprawdzenia zamiast rzeczywistej zmiany.
- Łatanie objawu. Naprawiamy błąd zapisu, nie pytając, dlaczego zapis jest tak drogi.
- Niepełny scenariusz testowy. Sprawdzamy dwóch zapisujących, a pomijamy otwartego czytelnika i duży zbiór.
- Nadmiar kopii i kontroli. Każda kopia wygląda rozsądnie osobno, ale razem tworzą koszt i ryzyko sprzecznych wersji.
- Zbyt mocny wniosek z małego pomiaru. Jeden szybki wynik zamieniamy w obietnicę ogólnego przyspieszenia lub oszczędności.
9. Jak uniknąć podobnego problemu
- Napisz jedno zdanie o celu mechanizmu. Każde pole i każdy zapis muszą temu celowi służyć.
- Oddziel stan, historię i szczegóły. W bieżącym spisie trzymaj stan i odnośnik; dokumentację etapu uzupełniaj zbiorczo.
- Oznacz ważne zdarzenia. Nowe zadanie, zgoda, właściciel, zakres, istotna blokada i zakończenie są ważne. Samo sprawdzenie zwykle nie jest zmianą.
- Zmierz pełną drogę. Oddziel czas kolejki, odczytu, obliczeń i zapisu. Kilka naprzemiennych prób jest bardziej przekonujące niż jeden wynik.
- Sprawdź wzrost i przerwanie. Testuj większy zbiór, otwarty czytnik, dwóch piszących, powtórzenie zdarzenia i awarię przed zatwierdzeniem.
- Upraszczaj przed dokładaniem warstw. Najpierw usuń zbędne dane, kopie i powtórzone obliczenia. Dopiero potem rozważ inne narzędzie lub bazę.
- Zachowaj zabezpieczenia, które mają odrębny cel. Szybkość nie usprawiedliwia utraty zgód, kopii, kontroli właściciela i potwierdzenia wyniku.
- Nie zgaduj korzyści. Nie zmierzyliśmy kredytów, tokenów ani oszczędności finansowych, więc ich nie deklarujemy. Nie dowiedliśmy też, że dodatkowi agenci lub inny sprzęt rozwiązują ten problem.
Prompt do przeglądu własnego narzutu
Sprawdź, które elementy naszego sposobu pracy pomagają osiągać cel, a które tylko tworzą administrację. Oddziel potwierdzone opóźnienia od hipotez. Zmierz kolejkę, odczyt, obliczenia i zapis. Najpierw usuń zbędne dane, powtórzone kroki i nieaktualne kopie. Zachowaj zgody, właścicieli, kopię i kontrolę wyniku. Pokaż porównanie przed i po, metodę oraz ograniczenia. Nie dodawaj nowego systemu, jeśli wystarczy uprościć istniejący.
Najbardziej użyteczne pytanie w tym przypadku nie dotyczyło kolejnej technologii: czy mechanizm nadal robi tylko to, po co powstał? AI może sprawnie budować procedury i kod. To nie zwalnia nas z rozliczania kosztu tych procedur i kodu.
Źródła i granice tego studium
Opis dotyczy jednego rzeczywistego przypadku z października 2026 r. Dane operacyjne, prywatne treści i identyfikatory kont nie są publikowane. Udostępniamy zanonimizowane pomiary i opis metody w JSON. Dokumentacja poniżej potwierdza działanie API; nie jest niezależną weryfikacją naszych czasów.