LocalCode

Asystent, który odpowiada tekstem, przenosi całą pracę na człowieka: model wie, co zrobić, ale pliki edytuje i testy uruchamia programista. Drugi problem jest poważniejszy — narzędzia chmurowe wymagają wysłania kodu na zewnątrz, co przy pracy komercyjnej bywa wykluczone.

Trzeci, najbardziej uciążliwy: agenty potrafią zgłosić „gotowe”, kiedy nic nie działa. Zaufanie do takiego narzędzia znika po pierwszym takim przypadku.

Agent, który ma dostęp do tych samych narzędzi co człowiek — odczyt plików, edycja, terminal — i któremu nie wolno zgłosić ukończenia bez dowodu. Dowodem jest przechodzący zestaw testów albo inny sprawdzalny warunek zapisany w zadaniu.

Model uruchamiany lokalnie, bo dopiero to czyni narzędzie użytecznym przy cudzym kodzie.

Rdzeń to pętla: analiza projektu, plan, wybór narzędzia, wykonanie, odczyt wyniku. Narzędzia mają jawne deklaracje — co czytają, co zapisują, ile mogą trwać. Repozytorium dzieli się na agent_core (pętla i narzędzia), apps (interfejsy), configs i benchmarks.

Osobnym modułem jest wyszukiwanie: agent korzysta z lokalnej bazy OSM (poland-latest.osm.pbf, indeks SQLite) do zapytań geograficznych bez sieci — opisane szerzej w serii LOCAL AI LAB.

Narzędzia są celowo prymitywne i policzalne: odczyt pliku, zapis, edycja fragmentu, uruchomienie polecenia, listowanie katalogu, wyszukiwanie w treści. Im mniejszy zestaw, tym pewniejszy wybór — agent z sześcioma dobrze opisanymi narzędziami myli się rzadziej niż agent z trzydziestoma.

Każde wywołanie trafia do śladu sesji wraz z czasem trwania i wynikiem. Ślad jest częścią produktu, nie logiem debugowym: to z niego wynika, czy zawiódł model, narzędzie, czy opis zadania.

Sesja wygląda jak zapis pracy programisty: odczyt pliku, uruchomienie pytest, exit 1, edycja jednej linii, ponowne uruchomienie, exit 0. Dopiero wtedy pada „COMPLETED” wraz z liczbą kroków, czasem i listą zmienionych plików.

Powstała też wersja mobilna — w repozytorium leżą zbudowane pakiety LC-Pilot na Androida (debug i release arm64), pozwalające sterować agentem z telefonu.

Dystrybucja rozwiązuje najbardziej przyziemny problem: w katalogu python-portable siedzi kompletne środowisko, więc uruchomienie na czystej maszynie nie wymaga instalowania Pythona ani zależności. To różnica między narzędziem, którego się używa, a takim, które trzeba najpierw postawić.

Agent domyka proste zadania naprawcze samodzielnie, z weryfikacją. Kluczowa okazała się nie wielkość modelu, lecz jakość opisu narzędzi: precyzyjnie opisane narzędzie jest wybierane trafnie nawet przez mniejszy model.

Zadania obejmujące wiele plików i wiele narzędzi nadal wymagają nadzoru — najczęstszą przyczyną porażki jest niejednoznaczne polecenie, nie sam model.