Local_Code: od promptu do działającego serwera
Jak wygląda u nas praca z modelem uruchamianym lokalnie — od pierwszego zdania opisującego problem, przez pętlę testów, po uruchomienie narzędzia, z którego korzysta się codziennie.
Model językowy nie zastępuje myślenia o problemie. Skraca natomiast drogę od decyzji do działającego kodu — pod warunkiem, że wejście jest uporządkowane. Poniżej pętla, w której pracujemy.
Pomysł zapisany jednym zdaniem
Zasada brzmi: jeśli nie potrafisz opisać problemu jednym zdaniem, model też sobie z nim nie poradzi. „Chcę wiedzieć, ile filamentu zostało na szpuli, bez ważenia jej za każdym razem” — to jest dobre wejście. „Zrób coś z zarządzaniem materiałami” — to nie jest.
Prompty
Pracujemy krokami, nie jednym wielkim poleceniem. Najpierw szkielet modułu, potem testy brzegowe, dopiero na końcu optymalizacja. Każdy krok kończy się czymś, co da się uruchomić.
Kontekst dokładamy z własnych plików: opis maszyny, format danych, wcześniejsze rozwiązania. Model bez kontekstu wymyśla własne konwencje, których potem nikt nie pamięta.
Local_Code — dlaczego lokalnie
Trzy powody: dane zostają w warsztacie, koszt zapytania wynosi zero, a narzędzie działa też wtedy, gdy pada łącze. Do tego dochodzi czwarty, mniej oczywisty — lokalny model zmusza do pisania krótszych, konkretniejszych zapytań, bo nie ma nieskończonego kontekstu do zapełnienia.
Sprzęt: jedna karta z 24 GB pamięci, uruchomiona całą dobę. Pobór mocy w spoczynku jest niższy niż lodówki, a przy pełnym obciążeniu i tak grzeje warsztat.
Testy jako część pętli, nie etap na końcu
Każdy wygenerowany moduł dostaje testy w tym samym kroku. To jedyny sposób, żeby wyłapać kod, który wygląda poprawnie i taki nie jest — a to najczęstszy błąd, jaki popełnia model.
- build — czy w ogóle się kompiluje,
- lint — czy trzyma konwencje projektu,
- testy brzegowe — puste dane, wartości ujemne, znaki diakrytyczne,
- rozmiar wyniku — czy narzędzie nie urosło pięciokrotnie przy „drobnej” poprawce.
Wizualizacja i serwer
Zanim narzędzie trafi do codziennego użytku, rysujemy wykres tego, co robi. Wykres skuteczności kolejnych iteracji pokazuje moment, w którym dalsze poprawki przestają się opłacać — u nas zwykle wypada między czwartą a szóstą iteracją.
Uruchomienie to systemd, port lokalny i prosty panel w przeglądarce. Bez logowania, bo serwis nie wychodzi poza sieć warsztatu.
Wniosek po pół roku
Największy skok jakości nie przyszedł od zmiany modelu na większy, tylko od uporządkowania danych wejściowych: jednolite nazwy projektów, opisy maszyn w jednym miejscu, konsekwentny format notatek. Model jest tak dobry, jak porządek, który mu podasz.
