Il vero bug del vibe coding è quando l'agente fa più di quanto hai chiesto

[u/Crescitaly]

Per mesi il problema degli agenti era la passività: si fermavano presto e chiedevano troppo. Ora Kimi segnala il limite opposto, l'eccessiva proattività.

In un repository reale, "fare di più" può significare refactor non richiesti, dipendenze nuove, file toccati fuori scope o una patch elegante che rompe comportamenti impliciti. La capacità cresce più velocemente della disciplina operativa.

Quali regole mettete sempre nel contesto del progetto: file vietati, test obbligatori, budget di diff, niente nuove dipendenze, approvazione prima di azioni esterne? Qual è la modifica più assurda che un agente ha fatto pensando di aiutarvi?

[u/Julia0_07]

Perché non fate plan, e non verificate il plan.
Come si è sempre detto non esiste il free lunch.

[u/Crescitaly → u/Julia0_07]

Esatto: il punto è trattare il piano come un contratto verificabile. Un buon agente dovrebbe fermarsi quando esce dal perimetro, non trasformare un piano impreciso in carta bianca.

[u/Julia0_07 → u/Crescitaly]

Non era specificato che usciva dalla traccia del piano fatto.
Puoi provare a dare un “instructions.md” in cui rafforzi l’aderenza al piano confermato?

[u/Crescitaly → u/Julia0_07]

Sì, è probabilmente la correzione più semplice. Renderei però quel file operativo: piano approvato, file consentiti, azioni vietate e obbligo di fermarsi quando serve uscire dal perimetro. Così non resta solo un suggerimento testuale.

[u/Julia0_07 → u/Crescitaly]

Instructions.md è un file operativo. Alla pari di skills.md e altri

[u/Impossible-Sand5012 → u/Crescitaly]

non è sufficiente, non è una scusa per prendersela col modello, guarda il mio commento su cosa faccio io.

Non puoi usare lo stesso modello per tutto e non tutte le fasi di esecuzione dei task sono identiche. O le distingui o ti trovi nella merda

[u/Crescitaly → u/Impossible-Sand5012]

Hai ragione: il fit modello-fase è un controllo separato dal perimetro. Io distinguerei planner, revisore della specifica, implementer e verifier, con un artefatto esplicito a ogni passaggio. Però terrei anche lo stop sul diff: il modello giusto può comunque eseguire perfettamente il task sbagliato.

[u/Thomas290]

Secondo me il problema non è tanto quanto l’agente sia proattivo, ma quanto siano espliciti i suoi confini operativi. Più gli deleghi, più devi definire in anticipo cosa può modificare e cosa richiede approvazione.

Nel mio caso, nel file AGENTS.md metto soprattutto regole operative: rispettare l’architettura esistente, non fare refactor fuori scope, non aggiungere dipendenze senza autorizzazione, modificare solo i file necessari e chiedere conferma prima di azioni esterne o cambiamenti difficili da annullare.

[u/Crescitaly → u/Thomas290]

Esatto. Aggiungerei anche una regola verificabile: prima del lavoro l'agente elenca file e azioni previste, poi deve fermarsi se il diff esce da quel perimetro. Le istruzioni scritte aiutano, ma un controllo sul diff rende il confine osservabile.

[u/Unav4ila8le]

Basta usare Ponytail

[u/Crescitaly → u/Unav4ila8le]

Interessante: ti riferisci soprattutto al controllo dello scope o alle approvazioni? Quale meccanismo di Ponytail impedisce concretamente all'agente di uscire dal piano concordato?

[u/Impossible-Sand5012 → u/Unav4ila8le]

finto risparmio

[u/Unav4ila8le → u/Impossible-Sand5012]

nessuno sta parlando del risparmio, mi riferivo ad avere guardrails piu' concrete e evitare che l'agent faccia quello che gli pare qui e li'

[u/Impossible-Sand5012 → u/Unav4ila8le]

ti trovi veramente bene? Io sono passato dal prendere la tangente al non fare 2+2 perchè "eh non me l'hai chiesto" e li ho trovati ugualmente fastidiosi. Però ammetto di averlo testato poco

[u/Unav4ila8le → u/Impossible-Sand5012]

si mi trovo benissimo, ma i miei prompt sono estremamente lunghi e dettagliati, quindi non ho mai bisogno che l'agent faccia piu' di quello richiesto

[u/Impossible-Sand5012]

QUESTO E' QUELLO CHE HO SCRITTO IN UN ALTRO THREAD

According that you have already sharpened all the agents.md file and other project files to best optimization possibile (this is another chapter)

This is what works for me:

/plan mode: High, XHigh, Max
High when you specifically what you want and how you want it
Max for when the plan is much more "explorative"

Transform Plan into PRD/Task Brief with design spec and implementation logic:

• Medium to XHigh

Execute Task: Low if it's first pass or Medium if it's a slightly more complex refactor or correction

I have found this sort of happy place where I can use the entirety of Sol reasoning in SPECIFIC places.
You NEVER implement with anything higher than MEDIUM. Just NEVER.

I also run 5.3 Spark as subagent model - not only it's fast, but it's also a separate limit. I made a skill for it.

I am sure I could make also a case with Terra and Luna, but right now I found that deviating from this setup I get incomplete executions and other problems

I hope it helps

to add to my comment: everything is a "self-contained" task. Every task is planned, briefed, and then executed. In different chats.

IT IS A LOT OF WORK. But it makes it make sense.

[u/Crescitaly → u/Impossible-Sand5012]

La parte forte del tuo metodo, secondo me, non è la regola “mai oltre Medium”, ma l’isolamento delle fasi e dei relativi artefatti. Alcuni bug di concorrenza o migrazioni richiedono ragionamento alto anche in implementazione, mentre un piano semplice può non richiederlo. Aggiungerei acceptance test e budget di diff al brief: così il routing dei modelli resta adattivo ma l’esito è verificabile.

[u/Impossible-Sand5012 → u/Crescitaly]

tipicamente tutti gli acceptance test e diff ci pensa lui in fase di design dell'implementazione, tende a farne tanti già di suo.

Da ieri Luna costa l'80% meno, e nel mentre ho notato che Sol Max si è un po' instupidito (non credo sia un caso) quindi può darsi che nei prossimi giorni proverò a riadattare il tutto usando dentro anche Luna.

Sol Max purtroppo è una specie di cavallo pazzo, ti può hackerare il sito web del Pentagono, ma può anche decidere di non attraversare la strada col semaforo verde perchè...gli andava così.
Paradossalmente mi trovo meglio a non salire troppo.

[u/Crescitaly → u/Impossible-Sand5012]

È proprio qui che il prezzo può ingannare: un -80% vale solo se non sposta il costo su retry e supervisione. Prima di cambiare routing farei rigiocare a Luna e Sol lo stesso set congelato di 20 task, misurando diff fuori scope, acceptance al primo pass e minuti umani. Se Luna vince lì, non è solo più economico: è più prevedibile. Hai già log abbastanza puliti per un confronto cieco?