Lokalni coding agenci oddają kontrolę tam, gdzie chmura zaczyna boleć

Sebastian Raschka pokazuje lokalny stack dla coding agenta: open-weight model w Ollamie, harness do edycji kodu i uruchamiania komend oraz własną maszynę zamiast subskrypcji Claude Code albo Codex. Dla zespołów ważna jest nie nostalgia za localhostem, lecz zabezpieczenie przed cenami, limitami i zmianami modeli poza ich kontrolą.

Raschka składa agenta z modelu, harnessu i lokalnego runtime

Raschka opublikował poradnik uruchomienia coding agenta w pełni lokalnie. Stack łączy open-weight LLM obsługiwany przez runtime, na przykład Ollamę, z coding-agent harness, który potrafi czytać pliki, edytować kod, uruchamiać polecenia shell i weryfikować zmiany.

Główna konfiguracja w tekście opiera się na Qwen3.6 35B-A3B, Qwen-Code i Ollamie. Przy Qwen3.6 autor podaje około 22 GB do pobrania oraz mniej więcej 30 do 40 GB RAM do praktycznej pracy. Na Apple Silicon rekomenduje warianty MLX, a na Linuksie zwykły tag Ollamy.

Ważny szczegół: Raschka nie sprzedaje tego jako pełnego zamiennika chmury. Sam pisze, że na co dzień nadal przełącza się między Codex i Claude Code. Lokalny agent jest raczej kontrolowanym drugim torem: da się go sprawdzić, odtworzyć, uruchomić offline i uniezależnić od niespodzianek w API.

Workflow programisty przesuwa się z modelu na warstwę operacyjną

Sedno tekstu nie sprowadza się do pytania, który model dziś rozwiąże więcej zadań. Ciekawszy jest podział ról: LLM jest silnikiem, ale wartość produktu leży w harnessie, uprawnieniach do plików, obsłudze kontekstu, uruchamianiu testów i utrzymywaniu stanu przez kilka kroków.

Dla zespołów engineeringowych zmienia to sposób oceny narzędzia. Lokalny agent może pracować przy repozytoriach, których nie chce się wysyłać do dostawcy chmurowego, a jednocześnie pozwala sprawdzić, co dokładnie przeczytał, zmienił i uruchomił. To mniej wygodne niż subskrypcja u dużego labu, ale w projektach regulowanych albo wrażliwych ta niewygoda bywa zaletą.

Jest też wątek kosztów. Limity subskrypcji są dziś często hojne, ale nie są umową na przyszłość. Lokalny stack przenosi koszt na sprzęt, prąd i utrzymanie. Dla jednej osoby to może być projekt po godzinach. Dla firmy: plan awaryjny.

Lokalny agent nie wybacza słabego sprzętu ani słabego procesu

Poradnik Raschki przypomina też, że „lokalnie” nie znaczy „za darmo”. Model w okolicach 35B parametrów potrzebuje dużo pamięci, inference nie zawsze dogoni chmurę, a mniejsze modele zapasowe mogą zawodzić właśnie przy tool use, którego coding agent potrzebuje najbardziej.

Drugie ryzyko to bezpieczeństwo. Agent, który może zmieniać pliki i uruchamiać komendy, jest już operacyjnym aktorem w projekcie. Lokalny tryb ogranicza ekspozycję danych na zewnętrznego dostawcę, ale nie zwalnia z sandboxingu, uprawnień, review i rollbacku. Inaczej ryzyko tylko przeprowadza się z rachunku za API do terminala.

O adopcji zdecyduje nudne utrzymanie, nie pierwszy pull request

Kolejny sygnał to stabilność lokalnych harnessów w długich zadaniach: kompresja kontekstu, czytelne logi, przerwanie pracy, powrót do session i konsekwentne uruchamianie testów. Tam demo setup zmienia się w narzędzie do codziennej pracy.

Warto obserwować połączenie open-weight modeli do kodowania z harnessami takimi jak Qwen-Code, Codex CLI, Cline i OpenCode. Jeśli ich ergonomia zbliży się do agentów chmurowych, lokalny coding agent przestanie być hobby i stanie się zwykłą warstwą infrastruktury developerskiej.

Werdykt Lilith

Lokalny coding agent jest jak zapasowy generator w piwnicy: przez większość dni tylko stoi, ale gdy chmurowy bramkarz zamyka drzwi albo zmienia cennik, nagle decyduje, kto dalej pracuje.