Ten startup zachował Claude i Codex, a dokumentację przeniósł do lokalnej AI

Programista prosi agenta o naprawę błędu w usłudze. Agent musi najpierw odszukać pierwotne zgłoszenie, poznać kilka decyzji produktowych i ustalić, które wymagania nadal obowiązują. Po poprawce ktoś musi rozpisać pozostałą pracę na zgłoszenia dostępne dla projektanta lub osoby kierującej wsparciem. Zmiana kodu jest tylko częścią zadania, choć cała praca może trafić do tego samego płatnego modelu.

Grayhat Developers, firma programistyczna zatrudniająca mniej niż 40 osób, opisała w preprincie z 5 listopada 2026 roku, co się stało po rozdzieleniu tych zadań. Inżynierowie próbowali korzystać z modeli na własnym sprzęcie. Zastąpienie komercyjnych agentów spowalniało lub utrudniało część pracy w repozytorium. Zespół zachował tych agentów do złożonych zmian i przeniósł część wyszukiwania materiałów, przygotowania dokumentów i aktualizowania zgłoszeń do lokalnej usługi.

Dla innego małego zespołu ciekawe pytanie brzmi, co przenieść najpierw. Grayhat daje konkretny punkt wyjścia, szacunek wart rozłożenia na części i przykład błędu wdrożeniowego, który może pogrążyć próbę, zanim zespół dowie się czegoś o jakości modelu.

Zanim poprawka dotknie kodu, trzeba znaleźć kontekst

Grayhat używał Outline do dokumentacji, Plane do śledzenia pracy i ERPNext do informacji organizacyjnych. Zespół miał już te usługi na komputerze w biurze i obsługiwał tożsamość przez Authentik. Konektory Model Context Protocol, czyli MCP, działały na tym samym komputerze. Druga maszyna wykonywała inferencję modeli. To praktyczne rozdzielenie. Dokumentacja i zgłoszenia mogły działać jak zwykle, gdy procesy modelu zajmowały zasoby innego urządzenia.

Proces opisany w pracy obejmuje przekazywanie zadań przez ludzi. Członek zespołu używa wewnętrznego modelu, aby wyszukać i skrócić treść z wiki lub systemu zgłoszeń. Istotne fragmenty można zapisać w pliku repozytorium dla agenta programistycznego. Po pracy w kodzie kolejna osoba może przynieść dalsze kroki do wewnętrznego asystenta, przygotować szkice zgłoszeń i wysłać je do systemu. Bezpośrednią komunikację między agentami autorzy opisują jako przyszłą pracę. Już teraz człowiek widzi informacje na granicy i decyduje, czy mogą ją przekroczyć.

Punkty przekazania pracy w procesie Grayhat. Ilustracja Telli.sh na podstawie studium z 5 listopada.

Załóżmy, że klient zgłasza powtarzające się wiersze w eksporcie. W oryginalnym zgłoszeniu jest prywatny identyfikator konta i zapis rozmowy bez związku z błędem. Lokalny asystent może znaleźć aktualne zasady eksportu, właściciela usługi i wcześniejsze obejście. Inżynier tworzy opis z syntetycznym przykładem i oczekiwaną liczbą wierszy. Agent programistyczny dostaje materiał do odtworzenia błędu. Dane wrażliwe zostają w systemach wewnętrznych, bo człowiek wybrał, co przekazać.

Do wewnętrznego szkicu dołącz odsyłacze do oryginałów. W przypadku sprzecznych wymagań sprawdzający może ustalić, czy dana zasada pochodzi z niedawnej decyzji, czy ze starego obejścia. Streszczenie utworzone lokalnie bez wskazania źródeł nadal powiela problem, który miało rozwiązać. Kolejna osoba musi ustalać, któremu opisowi ufać.

Zespół kupował dostęp i oszacował, ile pracy może przenieść

Autorzy podają bazowy koszt komercyjnej AI na około 325 USD miesięcznie. Składa się na niego około 175 USD za siedem stanowisk Claude, 140 USD za siedem subskrypcji Codex i 10 USD kredytów. Podają też ponad 25,93 mld zarejestrowanych tokenów w tych usługach. Praca nie ustala, czy zapisane tokeny pochodzą z tego samego okresu rozliczeniowego co kwota 325 USD. Obie liczby mierzą co innego i nie należy ich dzielić, by uzyskać cenę tokena.

Grayhat szacował, że przekazywanie kontekstu, dokumentacja i koordynacja projektów odpowiadały za 30–40% pracy wykonywanej przez komercyjną AI. Autorzy przyjęli, że lokalny system może przejąć około 90% tej kategorii. Daje to 27–36% całej komercyjnej pracy. Po odniesieniu tego udziału do 325 USD otrzymujemy około 88–117 USD miesięcznie. To szacunki udziału zadań i równowartości kosztowej ze studium z 5 listopada. Autorzy nie przeprowadzili kontrolowanego porównania faktur przed zmianą i po niej.

Grayhat wychodzi od udziału zadań i przelicza go na równowartość kosztową. Ilustracja Telli.sh.

Rozróżnienie jest ważne przy rozliczaniu za stanowiska. Jeśli siedmiu programistów nadal potrzebuje subskrypcji do skomplikowanej pracy, mniejsze wykorzystanie może pozostawić fakturę bez zmian. Zysk może się ujawnić jako możliwość zrobienia dodatkowych poprawek, mniejsza presja limitów lub mniej zakupów ponad pakiet. Przy płatności za żądanie zmiana może być widoczna wcześniej, choć ponowienia i wolne kolejki mogą pochłonąć część oszczędności. Jeśli zespół musi kupić GPU i zapłacić za jego utrzymanie, porównanie powinno objąć te koszty.

Wybierz mianownik, który można sprawdzić. Liczbę szkiców łatwo policzyć, ale zgłoszenie napisane przez kierownika od nowa nie dowodzi oszczędności. Mierz przyjęte opisy i zgłoszenia. Zapisuj poprawki zmieniające sens zadania. Gdy sprawdzający potrafią konsekwentnie rozpoznać wynik, który można przyjąć, zmierz wysiłek potrzebny do jego uzyskania.

Drugi interfejs zmienił to, kto zajmuje się konfiguracją

Pierwsze wdrożenie korzystało z LobeHub. Inżynierowie dostali instrukcje łączenia własnego interfejsu z narzędziami wewnętrznymi. Autorzy podają, że obiecujące pokazy nie przełożyły się na regularne użycie. Ludzie musieli wiedzieć, który konektor wybrać, gdzie jest i jak się uwierzytelnić. Każdy wybór oddalał moment pierwszej użytecznej odpowiedzi.

W drugim interfejsie Grayhat narzędzia skonfigurowano centralnie. Rysunek 2 z pracy „Create Your Own Work Stack”, autorzy Saad Ahmed Bazaz, Talha Amjad, Abdurrehman Subhani, Sohaib Ahmed Bazaz i Abdullah Aamir, CC BY 4.0.

Zespół przeszedł na centralnie skonfigurowany LibreChat. Użytkownicy widzieli gotowe narzędzia i mogli się uwierzytelnić przy dostępie. Autorzy naliczyli osiem uwag o konfiguracji i wdrażaniu użytkowników w 11 ustrukturyzowanych wywiadach o pierwszej wersji. Druga wersja dała trzy uwagi w tej kategorii w nieustrukturyzowanych komentarzach na Discordzie. Liczby pochodzą z innych metod zbierania danych. Pomagają wskazać problem pierwszego użycia, ale nie pokazują skali wzrostu adopcji ani liczby pracowników, którzy przestali napotykać problem.

Zaprojektuj pierwszą sesję wokół najmniejszego rzeczywistego zadania. Kierownik projektu szukający kryteriów odbioru zgłoszenia powinien widzieć, czy system jest połączony i które konto jest aktywne. Inżynier przygotowujący trzy zgłoszenia powinien móc je przeczytać przed publikacją. Zespół wymagający konfiguracji konektorów przed znalezieniem własnej pracy ryzykuje, że zmierzy cierpliwość zamiast użyteczności.

Centralna konfiguracja rodzi nową odpowiedzialność. Ktoś musi utrzymywać listę zatwierdzonych konektorów, wymieniać dane uwierzytelniające i umieć wyjaśnić, kto może zmieniać uprawnienia. Błędne ustawienie jednej osoby może stać się problemem wszystkich. Korzyść polega na tym, że powtarzający się błąd można poprawić raz dla wszystkich użytkowników usługi.

Powierz lokalnemu systemowi zadania z określonym właścicielem wyniku

Wstępna klasyfikacja zgłoszeń to praktyczny początek. Wewnętrzny asystent może grupować potencjalne duplikaty i proponować opis z linkami źródłowymi. Właściciel projektu decyduje, czy dwa zgłoszenia są faktycznie powtórzeniem i czy scalony opis zachowuje wszystkie warunki. Asystent może przygotować komentarz z uzasadnieniem grupowania. Wiadomo, co się stało, bo aktualizacja ma wskazanego właściciela.

Utrzymanie dokumentacji to inna praca. Załóżmy, że ustawienie przeniosło się na inny ekran. Asystent może znaleźć nieaktualne strony pomocy, wskazać objęte nimi edycje i zaproponować poprawki. Redaktor sprawdza aktualną nawigację i publikuje właściwe zmiany. Mocniejszy model zdalny wnosi niewiele, jeśli najtrudniejszy jest dostęp do aktualnych materiałów wewnętrznych i zachowanie zakresu każdego artykułu.

Złożone programowanie to przeciwny przykład. Migracja bazy może wymagać sprawdzenia historycznych kontraktów danych, zmiany kilku usług i weryfikacji wycofania. Grayhat zauważył, że testowany zestaw lokalny radził sobie słabo z większą pracą w repozytorium, zwłaszcza gdy model potrzebował szerokiego kontekstu i szybkiej inferencji. Studium opisuje konkretny sprzęt, modele i doświadczenie zespołu. Daje powód, by przetestować własne zadania przed rozszerzeniem zakresu.

Użyj ograniczonej ścieżki, gdy proste formatowanie łączy się z danymi wrażliwymi. Wysłanie szkicu poza sieć nadal może ujawnić informacje, choć narzędzia źródłowe działają lokalnie. Gdy trzeba przekazać coś zdalnie, zatwierdź miejsce docelowe i przygotuj tylko potrzebny materiał. Wewnętrzny wynik bez zgody powinien pozostać w kolejce do sprawdzenia. Przekroczenie czasu powinno dać czytelny błąd zamiast niespodziewanego transferu.

Krótka próba oddziela przydatną pracę od utrzymania infrastruktury

1. Zdefiniuj trzy wyniki. Wybierz opis zgłoszenia z linkiem, poprawkę dokumentacji i szkic zgłoszenia. Dla każdego zapisz w jednym zdaniu, kto go akceptuje i jakie potwierdzenie jest potrzebne. Zachowaj dobry i nieudany przykład, także z błędem, który łatwo przeoczyć.
2. Zmierz obecną ścieżkę. Przez zwykły tydzień pracy licz ukończone przykłady i merytoryczne poprawki. Mierz czas szukania kontekstu. Tam, gdzie to możliwe, przypisz użycie komercyjne do procesów. Zapisz, czy odjęcie zadań rzeczywiście zmieni liczbę miejsc lub koszty nadwyżek. Oddzielnie rejestruj pracę, której nie trzeba było wykonywać w ogóle.
3. Podłącz jedno narzędzie wewnętrzne. Zacznij od odczytu we wskazanym projekcie. Potwierdź, że uprawniony pracownik może odczytać znane zgłoszenie, a osoba spoza projektu nie ma dostępu. Ogranicz próbę do niewielkiej grupy już wykonującej tę pracę. Zapewnij sposób ręcznego zakończenia zadania w razie awarii.
4. Porównaj szkice przed zezwoleniem na zapis. Ten sam sprawdzający powinien stosować te same kryteria akceptacji. Notuj linki do niewłaściwych zgłoszeń, nieaktualne fakty i niepoparte wnioski. Przed dopuszczeniem zmian w prawdziwym systemie dodaj podgląd, zgodę i trwały zapis.
5. Sprawdź, co faktycznie się przeniosło. Porównaj przyjęte wyniki, czas sprawdzania, aktywne użycie i rzeczywiste faktury. Dodaj czas konserwacji sprzętu, niedostępności i zmian konektorów. Uwzględnij pomoc udzielaną użytkownikom. Aplikacja, która działa dopiero po dziesięciu minutach wsparcia specjalisty dla każdej osoby, nadal generuje koszt wdrożenia.

Jeśli już obsługujesz lokalny model dla programistów, przeprowadź próbę przy zwykłym ruchu. Kolejka ujawnia się, gdy kilka osób zaczyna równocześnie. Usługa szybka dla jednego polecenia może kazać czekać trzem osobom. Dla pilnych zadań pokaż postęp i daj powrót do normalnej ręcznej ścieżki. Próba będzie użyteczna, gdy zespół dowiaduje się, gdzie mieści się jego obciążenie.

Aneks Grayhat daje wyobrażenie o skali. Komputer do narzędzi miał 16 GB pamięci systemowej, a oddzielna maszyna do inferencji miała 32 GB pamięci i RTX 4080 z 16 GB VRAM. Zespół podaje, że wraz z ujawnianiem się potrzeb dodał monitoring sieci, harmonogramowanie i zasilacz awaryjny. To dane przydatne przy budżecie pilotażu. Mówią o obsłudze usługi, na której polegają współpracownicy, obok kosztu uzyskania odpowiedzi modelu.

Zdecyduj, gdzie trafi następna godzina pracy z AI

Z doświadczenia można przenieść rozdzielenie przygotowania kontekstu od specjalistycznego rozumowania oraz wyznaczenie właściciela każdego przekazania. Zacznij od powtarzalnej pracy, która daje materiał znany zespołowi i możliwy do sprawdzenia. Zmierz, ile pracy wymaga przyjęcie wyniku, a potem zdecyduj, czy lokalna ścieżka może przejąć kolejne zadanie. Grayhat pokazuje, jak to ocenić, zachowując przydatne narzędzia programistyczne.

Źródła

• Preprint Grayhat Developers, 5 listopada 2026
• Pełna praca z oszacowaniem obciążenia, infrastrukturą i rysunkiem 2
• Oryginalny obraz rysunku 2
• Licencja CC BY 4.0 rysunku

---

Aby zachować rozmowy towarzyszące przekazaniu pracy w przeszukiwalnym archiwum, załóż konto Telli.sh.