molti membri del nostro team di ingegneria hanno iniziato a utilizzare @AmpCode sia all'interno che all'esterno di Cursor. È oggettivamente migliore di tutti gli altri disponibili oggi. Lo abbiamo anche in esecuzione all'interno del pre-commit hook (con Playwright mcp ecc.) e stiamo facendo assistenze per la revisione delle PR. Con oracoli e subagenti, potrebbe essere uno dei sistemi multi-agente più impressionanti che abbia mai visto.
Quinn Slack
Quinn Slack25 lug 2025
Molti agenti di codifica hanno una funzione "modalità" che (in un certo senso?) aveva senso in un'era RAG o nei primi tempi agentici. Ora stanno aggiungendo subagenti come Amp (subagente di ricerca, subagenti generali, l'oracolo) e Claude Code (che ha appena lanciato una funzione di subagenti personalizzati davvero interessante). Le modalità sono menu a discesa UI pesanti e non composabili. I subagenti vengono invocati attraverso il linguaggio naturale ("usa l'oracolo per ...", "usa il subagente di problemi per ...", o implicitamente), sono perfettamente composabili e si inseriscono bene nel modello concettuale di chiamata agli strumenti agentici. Si scopre che le modalità e i subagenti servono fondamentalmente allo stesso scopo. I subagenti sono una soluzione decisamente migliore. Quindi, gli agenti di codifica di generazione precedente che hanno una funzione "modalità" esistente ora si trovano di fronte a una scelta difficile quando aggiungono subagenti: mantenere sia le modalità che i subagenti (il che è confuso e complesso), eliminare le modalità (il che è doloroso per la loro base utenti perché hanno investito molto sforzo nella creazione delle modalità), o cercare di estendere il concetto di "modalità" per includere anche i subagenti (il che sarà confuso anche). Non li invidio. Nel team di Amp, viviamo nella paura mortale di trovarci in questa posizione invidiabile quando abbiamo giudicato male dove sarà la codifica agentica in futuro e dobbiamo apportare cambiamenti dolorosi al prodotto. Abbiamo commesso tutti questi errori sui prodotti che abbiamo costruito prima di Amp (e commetteremo e continueremo a commettere tonnellate di errori su Amp). Questo è il motivo per cui abbiamo un'asticella incredibilmente alta per aggiungere nuovi concetti UI, è il motivo per cui diamo priorità ai membri del team con una forte intuizione, ed è il motivo per cui costruiamo per dove i modelli e il dev medio saranno tra 6-12+ mesi, non oggi. In questo caso, credo che questa orientazione ci abbia portato alla decisione giusta (niente modalità, solo subagenti composabili). Siamo fortunati di poter costruire per sviluppatori incredibilmente intelligenti e aperti/avanti nel pensiero che condividono spesso il loro feedback e attraverso praticamente ogni canale tranne i piccioni viaggiatori. Abbiamo avuto modo di conoscere e comprendere così tanti di voi. Semplicemente non riuscivamo a vedere nessuno di voi o noi stessi davvero amando le "modalità". Ma quando @thorstenball ha costruito i subagenti e poi l'oracolo, e ha detto che per usarli, basta dirlo ("usa l'oracolo per ...") invece di selezionarli da qualche menu a discesa, ci è sembrato giusto per noi e per tutti voi, e ci è sembrato che fosse anche dove stavano andando i modelli. Riconoscimenti a lui per questo, e grazie ai nostri fantastici utenti per aver visto il futuro. Volevo solo condividere un po' dietro le quinte su come pensiamo a queste cose e perché potremmo sembrare estremi o rigidi su alcune questioni. ...e rimanete sintonizzati per questo fine settimana, quando ammetterò di aver sbagliato su uno dei nostri Feedback Ignorati più controversi (FIF) e lo cambierò, grazie a tonnellate di feedback che si è rivelato che non ho ignorato.
7,77K