Poradnik / Praktyka
Najtrudniejsze w pracy z agentem jest wiedzieć, kiedy kazać mu przestać
Menedżer produktu Zephyr w Espressif opisuje, jak po raz drugi zbudował to samo firmware z pomocą agenta, tym razem w C zamiast Rust, i wyciąga z tego jeden wniosek: skoro model pisze kod szybciej, niż człowiek nadąża go ocenić, praca nie znika, tylko przenosi się z pisania na ocenianie. Jego receptą jest rytm plan, wykonanie, commit, test, z commitem przed testowaniem, żeby zawsze był punkt powrotu. Reszta reguł pilnuje granic: kodu z upstreamu agent nie rusza bez pozwolenia, a dziennik prób chroni przed zapętlaniem nieudanych poprawek.
Napisała AI, żeby oszczędzić Ci czytania setek źródeł. · Jak to działa
Poradnik / Praktyka · 5 min ·
Kiedy provisioning na płytce zaczyna się sypać, czyli urządzenie nie chce się poprawnie skonfigurować przy starcie, kuszącym ruchem jest puścić agenta, żeby generował kolejne poprawki, aż coś wreszcie się skompiluje. Menedżer produktu Zephyr w Espressif twierdzi, że to dokładnie ten moment, w którym trzeba agenta zatrzymać. Wygrywającym ruchem było u niego coś innego: "wklej log, powiedz, czego oczekujesz, i zapytaj, w której gałęzi kodu jest błąd". Nie "generuj więcej kodu, aż się skompiluje".
To zdanie streszcza całą obserwację z jego najnowszego wpisu na blogu Espressif. Drugi raz przeszedł tę samą drogę: znów zbudował firmware do ESP DualKey, niewielkiego zestawu deweloperskiego od M5Stack, który ma się łączyć przez Bluetooth i Wi-Fi z aplikacją do konfiguracji urządzenia. Za pierwszym razem robił to w języku Rust, teraz w C na systemie Zephyr. Tłumaczy jednak wprost, że produkt go nie interesuje, bo zrobił go już raz. Interesuje go proces, i to on jest tematem całego wpisu: to, jak pracuje się z agentem, kiedy ten potrafi pisać kod szybciej, niż człowiek nadąża go przemyśleć.
Szybki kod, wolna magia
Czytaj dalej za darmo
Podaj e-mail, aby odblokować pełną treść i cały serwis. Zapiszemy Cię do newslettera.
