nanobot: 2026-09-20 08:41:47

projects/ai/memory.md

@@ -144,3 +144,10 @@ Závěr uživatele: současný stav (modely pod 10 GB na této GPU instanci) nen
 [obnovený zápis 2] Zpětná vazba na výukovou session o RTX 4060 Ti: první verze byla odmítnuta — příliš "hop", hromada spec-čísel místo mechanistického vysvětlení. Uživatel chce proces: co se skutečně počítá v transformeru, jak interní jednotky (CUDA core vs tensor core mechanicky) fungují a kde se zapojují, detailní inference vs trénink průchod. Lesson: u výukových dotazů tohoto typu -- mechanistický průchod, ne spec tabulky.
 - 2026-09-15: - Zkušenost s navrhováním skillů v nanobotu: výsledky jsou dost žalostné — kostra není špatná, ale nanobot nedohledá různé detaily a problémy tak, jak je to pak udělá Claude Code. To je důvod, proč všechny zásadní opravy a nové skilly dělá uživatel v Claude Code. Nanobot plánovač jde ale točit a ladit — sám odchytí plno chyb a doladí se k uživatelově spokojenosti (příklad: skill /usage). Uživatelův rozbor: není to úplně chyba modelu, který nanobot používá, a asi ani ne nanobota samotného — spíš to je dáno tím, jak je nanobot koncipovaný.
 - 2026-09-15: - Rozbor, proč je navrhování skillů v nanobotu slabé (uživatel přímo): (1) nanobot je s řešením moc rychle hotov — žádný důsledkový průzkum po prvním návrhu, (2) chybí plánovací mód, kde uživatel může komentovat, co se mu nelíbí, dřív než se něco implementuje, (3) nanobot je málo kritický ke svým vlastním řešením. Odtud workflow: návrh/ladění plánu s nanobotem (iterativně, /usage jako důkaz, že to jde), finální implementace v Claude Code.
+- 2026-09-20: SpaceKeeper — nová aplikace (udržuje vybraný adresářový strom pod max velikostí odmazáváním adresářů i souborů podle data; nesmí smazat nic mladšího než limit; na disku musí zůstat alespoň X volného místa). Zadání jednoduché.
+
+Přesto: uživatel udělal plan, ten se opravoval opakovaně, ale výsledný kód byl komplikovaný a overengineered. Několik dalších otoček + review (každé review našlo spoustu chyb). Skončilo tak, že uživatel většinu kódu smazal a napsal si sám — pak to konečně začalo vypadat dobře; AI následně zkontrolovala a doladila.
+
+Uživatelův závěr: kdyby si to od začátku psal sám — nebo aspoň kostru a typy, a nechal AI jen dokódovat — bylo by to o dost lepší. A nebylo to poprvé (koreluje s dřívější zkušeností: Solarflare 8.9., princip „rozhraní navrhuje člověk, model implementuje" z agent-to-human-tools.md).
+
+Kódování proběhlo 16.–17. 9. 2026; zápis dodatečně 18. 9. (původní session se nespustila v nanobotovi, proto deník chyběl).

projects/ai/state.md

@@ -22,6 +22,7 @@ https://blog.root.cz/tonda/llm-jako-virtualni-projektovy-tym-od-generovani-textu
 - **Iterovaná oponentura** (A→B→A/C→B) — opakovat review po přepracování, ne jen jednou.
 
 ## Lessons learned
+- AI-first kódování selhává i u jednoduchého zadání (SpaceKeeper 16.–17.9.): plan+opravy+review smyčka s Claude Code = overengineered kód; nakonec smazán a přepsán ručně, teprve pak AI zkontrolovala a doladila. Vzor opakovaný (Solarflare 8.9.) → kostry/typy/rámec píše člověk, AI jen implementuje/doladí.
 - Skill design: nanobot samotný navrhne jen kostru, nedohledá detaily a problémy jako Claude Code → zásadní opravy a nové skilly dělat v Claude Code; nanobot plánovač ale jde točit a ladit iterativně (příklad: /usage). Proč (rozbor uživatele): nanobot je s řešením moc rychle hotov (žádný důsledkový průzkum), chybí plánovací mód s možností komentovat, málo kritický k vlastním řešením. Příčina: podle uživatele to není úplně chyba modelu ani nanobota samotného, spíš koncept, jak je nanobot postavený.
 - Review iterací: nová session na review = svěží pohled, ale opravy dělat v původní session s plnou historií rozhodnutí — jinak hrozí regrese (reverzy odsouhlasených rozhodnutí).
 - Inline `python -c` s cestami blokuje exec guard i uvnitř workspace → write_file do tmp/ + `uv run` s working_dir.