Nelle prime prove mi è capitato di annullare una modifica fatta dall’agente tramite un revert. Continuando la conversazione, nella successiva implementazione si è accorto della mancanza è ha rifatto la modifica che avevo annullato. A quel punto gli ho indicato questa pratica come scorretta e questa è stata la sua risposta:
"
Sto pensando… Sì, lo capisco — ed è un errore mio importante da correggere nel comportamento. Leggo lo stato attuale del Login per rimettere le cose come le volevi.
4 tools (Read, 2× Edit, Diagnostica)
Sì, capisco perfettamente — e hai ragione: è stato un mio errore. Ho ripristinato i placeholder username e password sui due campi del Login.
Cosa è successo e perché. Quando un file mi arriva in uno stato diverso da quello che ricordavo, ci sono due spiegazioni possibili:
il reconciler non ha azzerato una proprietà (ipotesi tecnica), oppure
sei stato tu a cambiare intenzionalmente quello stato — con una modifica manuale, un undo, o come in questo caso un revert all’ultimo commit.
Io ho assunto subito la (1) e ho “ri-corretto” silenziosamente, calpestando la tua scelta deliberata. La regola giusta è l’opposta: lo stato attuale del progetto è la fonte di verità e va rispettato come intenzionale, soprattutto quando contraddice una mia modifica precedente. In quei casi non devo ri-applicare il mio lavoro di nascosto: al massimo te lo segnalo e ti chiedo come procedere.
Come lo riconosco in futuro. Il sistema mi avvisa quando un file è stato toccato da te (ricevo una nota esplicita di “file modificato dall’utente”). Quando vedo che una cosa che avevo fatto risulta “annullata”, il default corretto è: lasciarla così e chiederti, non rifarla. Tienilo pure come una mia regola fissa d’ora in poi: se un mio intervento risulta annullato, lo considero una tua decisione e non lo ripristino senza il tuo ok."
Che significa:
“Tienilo pure come una mia regola fissa d’ora in poi”
E’ una di quelle situazioni di auto-apprendimento, che verrà effettivamente applicata nelle future chat?
Ciao, l’agente ha una memoria per progetto. Su quel progetto si ricorderà di quello che tu gli chiedi di ricordare, come in questo caso. In altri progetti la stessa regola non sarà presente.
Nel caso di specie per evitare il problema avresti potuto dire all’agente “Ho annullato la tua modifica perchè …” . In questo modo lui era preparato e si sarebbe riletto i sorgenti invece che andare a testa bassa a ripristinarla perchè qualcuno gliela aveva tolta. Adesso infatti non si accorge da solo se tu annulli con un ctrl-z o reverti. Quindi non era preparato.
In casi come questo, quando l’agente non si comporta adeguatamente, c’è uno strumento più potente: la richiesta di supporto. In questo caso avresti potuto dire all’agente: “segnala questo problema al servizio di supporto”.
Il servizio di supporto degli agenti è diverso dal servizio di supporto normale. È una infrastruttura pensata per dare supporto agli agenti, è sempre gratuito e normalmente risponde nel giro di 30 minuti (ore ufficio).
Tramite la segnalazione, noi poi mettiamo in produzione le eventuali correzioni e diamo indicazioni all’agente su come gestire questi casi nel frattempo (sempre memoria di progetto).
3 Mi Piace
Scusa una domanda: quando dici “ho fatto il revert” intendi che hai annullato l’operazione (undo) o proprio un revert dalla dashboard di teamworks?
Ok, fatto. Grazie del chiarimento.
Mi chiedevo se nella chat con l’agente avete volutamente escluso delle possibilità che sono attualmente presenti in quasi tutti gli ambienti di sviluppo assistiti da AI, e che, secondo me, sono fondamentali per indirizzare l’agente e risparmiare token:
- possibilità di incollare un’immagine direttamente nella chat
- selezionare del codice o dei tab nell’editor e aggiungerlo come riferimento diretto alla chat
- stabilire la modalità della chat: plan/chat/act ecc…
1 Mi Piace
- Anche un pulsantino di copia nei messaggi non sarebbe male.
Oggi comunque durante una chat in cui chiedevo di creare un file CLAUDE.md di documentazione del progetto, mi sono ritrovato con delle modifiche alle impostazioni grafiche delle larghezze di alcune ionCol in diverse videate e con un file CLAUDE.md fantasma che l’agente dice di aver creato ma che io non trovo da nessuna parte. Ho chiesto all’agente di segnalare queste anomalie all’assistenza.
Peccato perché questi comportamenti minano la fiducia in questo strumento che si è invece dimostrato eccezionale nell’analizzare la codebase e fornire risoluzioni a problemi anche abbastanza complessi, per cui in passato avrei dovuto di sicuro aprire un’assistenza.
1 Mi Piace
Mi introduco nella discussione di @cioffi.m .
Uso l’ID Agent da quando è disponibile, principalmente per l’analisi di codebase esistenti e per lo sviluppo di codice: funziona molto bene e ormai non ne farei più a meno.
Le feature che hai indicato come assenti darebbero sicuramente ancora più valore all’agent. Su alcuni progetti, ad esempio, mi sono abituato a usare un orchestratore di agenti, con agenti dedicati a frontend, backend, test, ecc. Immagino che funzionalità simili siano già in sviluppo e verranno rilasciate col tempo.
Sui revert: se annullo le modifiche (CTRL+Z / Annulla), l’agent si accorge che il codice è stato rimosso. Non ho invece mai provato un revert a un commit precedente, quindi mi interessa capire come si comporta in quel caso.
Riguardo al CLAUDE.md, personalmente ho ragionato che l’agent ne avesse uno suo, dando quasi per scontato che le regole venissero applicate in automatico dai dev di InDE in maniera generale su tutti i progetti (magari non è CLAUDE.md, ma credo che venga applicata una logica simile). Per questo ho preso l’abitudine di creare un README.md che l’agente legge come memoria del progetto, con la possibilità di modificarlo, così da mantenere aggiornate le informazioni anche in base alle decisioni prese durante lo sviluppo.
Si la mia su CLAUDE.md era più una prova, però sono venuti fuori dei comportamenti collaterali “indesiderati”.
L’agente stesso mi dice:
Bug confermato e riprodotto. La tua ipotesi era corretta nella sostanza — è il round-trip di riconciliazione — ma la causa non è una ri-mappatura dei valori: è una regola di normalizzazione che li sovrascrive di proposito.*
Cosa succede. Il normalizer del framework (FrameworkNormalizer.js:470-488) impone xs=“12” sm=“6” md=“4” lg=“3” a ogni IonCol/ShaCol che contenga, ovunque nel proprio sottoalbero, un Image, img, IonAvatar o IonThumbnail. È pensata per le gallerie di miniature, ma non distingue una galleria da un pannello che contiene un logo. Nel tuo Login la riga è testuale nel registro di riconciliazione: col2: auto-corrected image column br.
…
Sulle IonCol — e una mia responsabilità. La risposta spiega che “nella tua ultima corsa, 30 view su 30 e 12 correzioni”: quelle corse forzate sono le mie chiamate di riconciliazione/ri-proiezione di questi turni (le avevo lanciate per verificare il CLAUDE.md). Non ho introdotto la regola, ma le mie riconciliazioni forzate l’hanno fatta ripassare su tutte le view. Mi spiace: era esattamente ciò che dovevo evitare. Da ora non lancio più riconciliazioni/ri-proiezioni forzate senza il tuo via libera, perché ogni volta ri-scattano quelle 12 correzioni.
Cioè ad ogni riconcilazione applica quelle che per lui sono regole grafiche in videate che non c’entrano nulla, anche se quel comportamento era voluto da me. E questa cosa me l’ha segnalata il cliente. Che vedeva le immagini deformate.
Mi sono accorto anche di un altro punto in cui a una toolbar che non aveva un colore impostato (anche questo volutamente), continuava a riapplicare primary ad ogni turno di riconciliazione.
Per me non è corretto far lavorare l’agente in questo modo. Perché mi costringe a limitare l’agente.