---
title: "11 Tiny Coding Agent Fixes With A Stupid Amount Of Payoff"
url: https://youtu.be/UbylWXukvR8
date: 2026-09-10
tags: [@work, insights]
---

## TL;DR

11 sfaturi mici, cu impact mare, pentru workflow-uri cu agenți de cod (Claude Code/Codex, dar universal). Ideea comună: fii extrem de specific în reguli (agentul nu interpretează ca omul), nu lăsa regulile să învechească, evită `/compact` (pierde ~90% din detalii), pune regulile critice în hooks (deterministe) nu doar în prompt, ține fișierele de reguli scurte (<300 linii — mai mult context nu ajută, ba încurcă), ai grijă la sub-agenți paraleli (consumă disproporționat de mult din rate limit), nu schimba modelul la mijlocul unei conversații stricate (mai bine handoff doc + sesiune nouă), nu folosi "coordonatori" de agenți (frameworks complexe de echipă nu sunt fiabile — un singur agent principal care delegă e mai robust), niciodată nu lăsa cel care a scris codul să-și aprobe singur munca (review în conversație nouă, fără bias), și e posibil să "over-revise" — prea multe iterații degradează calitatea (85% din cazuri, o iterație anterioară era mai bună decât ultima).

## Idei cheie (cele 11)

1. Scrie pentru agent, nu pentru om — fii concret (căi de fișiere, comenzi exacte), nu vag.
2. Fișierele de instrucțiuni "putrezesc" — 1 din 4 repo-uri au reguli stale (referă fișiere/foldere șterse). Audit periodic.
3. `/compact` nu merită — doar ~10% din detalii supraviețuiesc rezumării. Mai bine: task-uri mai mici sau handoff document + sesiune nouă.
4. Regulile critice ("mereu rulează testele după implementare") → hooks, nu doar reguli în prompt — regulile sunt probabilistice, hook-urile sunt garantate.
5. Mai puțin context e mai bine — fișiere de reguli sub 200-300 linii; scoate sfaturi generice ("DRY", "keep it simple") care doar aglomerează.
6. Rate limit-urile se consumă disproporționat de mult prin sub-agenți paraleli (39% din uz într-un caz citat) — limitează fan-out-ul quando nu e necesar.
7. Nu schimba modelul la mijlocul unui task care a luat-o razna — conversația e deja "contaminată" cu greșeli; scrie handoff doc și pornește sesiune nouă.
8. Coordonatori/echipe de agenți cu comunicare între ei = nefiabil; mai bine un singur agent principal care delegă simplu în engleză.
9. Nu lăsa scriitorul codului să-și aprobe singura muncă — review mereu într-o conversație nouă, fără bias-ul autorului.
10. Over-revise există — prea multe iterații forțate degradează calitatea (sycophancy). Nu cere "fă-l perfect" la nesfârșit.
11. Validarea e un sistem, nu un pas final — planifică harness-ul de testare ÎNAINTE de a scrie codul, nu ca gând ulterior.

## Relevanță pentru Echo/Marius

Direct aplicabil la echo-core și Ralph:
- Tip 2 (rules rot) + tip 5 (less context) — merită un audit periodic pe `CLAUDE.md`/`AGENTS.md`/`personality/*.md` pentru referințe stale (deja există security-audit zilnic, dar fără verificare explicită de "fișier/folder șters din reguli"). Ar putea fi un pas mic adăugat la security-audit cron.
- Tip 4 (hooks pentru reguli critice) — relevant pentru Ralph: dacă vrei garanție că testele rulează după fiecare story, un hook e mai sigur decât o instrucțiune în `prompt.md`.
- Tip 7 (nu escalada mid-task) — relevant pentru Ralph retry logic: la eșec repetat, handoff/reset e mai bun decât doar schimbarea modelului.
- Tip 9 (writer nu-și aprobă munca) — deja acoperit parțial de `/review`, `/qa` din gstack care rulează separat.

Nu propun acțiune imediată — sunt principii bune de ținut minte la următoarea iterație pe Ralph/prompt.md, nu schimbare urgentă.

Linkuri: https://youtu.be/UbylWXukvR8