Strumenti CLI di Agentic: Codex vs Claude Code

Gli strumenti CLI di Agentic sono strumenti di programmazione basati sull'intelligenza artificiale in grado di creare ed eliminare file, eseguire comandi, pianificare ed eseguire la programmazione dell'intero progetto. Abbiamo testato le prestazioni dei principali strumenti in 10 scenari di sviluppo web reali, eseguendo circa 600 controlli di validazione atomici per agente e oltre 5.000 esecuzioni di test automatizzati in totale, tra cui logica di backend, funzionalità di frontend e verifica della coerenza multi-esecuzione.

Risultati del benchmark di Agentic CLI

Analisi delle prestazioni degli strumenti CLI di Agentic

Codex ha il punteggio complessivo più alto (67,7%) e le migliori prestazioni di backend (58,5%). Il suo punteggio di backend è superiore di oltre 5 punti percentuali rispetto al secondo classificato, Junie (54,3%).

Junie si classifica al secondo posto assoluto (63,5%), combinando una solida correttezza del backend (54,3%) con prestazioni frontend elevate (85,0%). Il suo divario backend-frontend (30,7 punti percentuali) è moderato rispetto agli altri agenti e ha completato tutte le 10 attività con l'infrastruttura backend pronta in 9 di esse.

Claude Code ha il punteggio frontend più alto (95,0%), ma il suo punteggio backend (38,6%) ne abbassa il risultato complessivo (55,5%). Questo illustra la dinamica principale del grafico: le prestazioni frontend sono relativamente elevate per diversi agenti, mentre la correttezza del backend e la disciplina contrattuale sono i fattori che determinano la maggior parte della differenza in classifica.

Il divario maggiore tra interfaccia utente e backend si riscontra in Claude Code (95,0% frontend contro 38,6% backend). Al contrario, Codex combina un punteggio frontend elevato (89,2%) con il miglior punteggio backend, motivo per cui risulta leader nella classifica generale con una ponderazione di 0,7 backend / 0,3 frontend.

Gli agenti con un punteggio inferiore falliscono per diverse ragioni. Goose ottiene punteggi prossimi allo zero sia sul backend (3,1%) che sul frontend (10,0%), il che indica problemi di base di esecuzione e completezza. Forge e Cline mostrano punteggi moderati sul frontend (45,8% e 33,3%) ma punteggi bassi sul backend (20,1% e 26,7%), il che è coerente con i problemi di contratto e di routing del backend che dominano i loro risultati.

Velocità rispetto al punteggio e utilizzo dei token rispetto al punteggio

Abbiamo valutato l'efficienza in fase di esecuzione utilizzando il tempo medio di esecuzione (secondi), l'utilizzo effettivo dei token (input + output) e il punteggio di accuratezza combinato:

Aider occupa la posizione più equilibrata del grafico. Con un punteggio combinato del 52,7%, completa le attività in 257 secondi e consuma 126.000 token. È l'unico agente che combina un'accuratezza medio-alta con tempi di esecuzione relativamente bassi e un consumo di token moderato.

Codex raggiunge il punteggio complessivo più alto (67,7%), ma a un costo maggiore. Il suo tempo di esecuzione medio è di 426 secondi e l'utilizzo dei token è di 258.000. Il compromesso in termini di efficienza sembra essere proporzionale al guadagno in termini di precisione.

Junie si posiziona al secondo posto per accuratezza (63,5%) con un tempo di esecuzione medio di 483 secondi e 370.000 token effettivi. Rispetto a Codex, consuma il 43% di token in più per una diminuzione del punteggio di 4,2 punti percentuali. Il suo rapporto token/accuratezza è meno favorevole di Aider o Codex, ma supera Claude Code sia in termini di accuratezza che di efficienza dei token.

Claude Code è l'agente più costoso tra quelli con le migliori prestazioni. Si classifica al terzo posto per accuratezza (55,5%) ma richiede 745 secondi e 397.000 token. Rispetto ad Aider, Claude consuma oltre 3 volte più token per un aumento di punteggio di soli 2,8 punti percentuali.

Kiro CLI è l'agente più veloce, completando l'operazione in 168 secondi e ottenendo un punteggio combinato del 58,1%. Tuttavia, Kiro non ha reso pubblico il consumo di token. Abbiamo invece misurato il consumo di crediti (46,1 crediti). Un confronto completo sull'efficienza di Kiro è incompleto, ma considerando il suo consumo di crediti, risulta essere uno dei più economici.

Nella fascia più bassa, Goose dimostra una scarsa efficienza. Consuma 300.000 token e impiega 587 secondi, ottenendo un punteggio di appena il 5,2%. In questo caso, un elevato consumo di token non si traduce in correttezza.

Nel complesso, un maggiore consumo di token non è sempre correlato a una maggiore accuratezza. Il comportamento architetturale di ripetizione dei tentativi e la strategia di validazione sembrano influenzare l'utilizzo dei token più della pura profondità di risoluzione del problema.

Di seguito potete consultare la nostra metodologia .

Come funzionano gli strumenti CLI agentici

Gli strumenti CLI di Agentic sono agenti autonomi che operano all'interno del terminale. Sebbene la maggior parte degli utenti li utilizzi per attività di programmazione, possono eseguire qualsiasi flusso di lavoro che può essere effettuato tramite comandi di shell.

Questi agenti operano tipicamente in un ciclo composto da tre fasi:

1. Raccogli il contesto
2. Agisci
3. Verifica dei risultati

Dopo la verifica, l'agente raccoglie informazioni aggiornate sul contesto e ripete il ciclo finché non completa l'attività o non raggiunge una condizione di arresto.

Il ciclo è influenzato da due fonti:

• L'utente umano, che fornisce il compito iniziale e può interrompere l'esecuzione
• Il modello, che esegue pianificazione, ragionamento e selezione delle azioni

Il framework dell'agente fornisce una struttura attorno al modello. Definisce come il modello dovrebbe pianificare, quando dovrebbe eseguire i comandi, come dovrebbe convalidare i risultati e quali strumenti sono disponibili. Questi strumenti possono includere l'esecuzione di shell, l'accesso al file system, il controllo del browser , l'utilizzo del computer , le integrazioni con MCP o "competenze" riutilizzabili.

Le diverse architetture degli agenti impongono diverse strategie di pianificazione, politiche di ripetizione e logiche di verifica. Alcuni agenti privilegiano la precisione e un ragionamento più approfondito a scapito di un maggiore utilizzo di token e di una maggiore latenza. Altri privilegiano la velocità e i costi inferiori, con una minore robustezza comportamentale.

Intelligenza basata su modelli vs architettura ad agenti

Le differenze di prestazioni tra gli strumenti CLI agenti non derivano da un'unica fonte. Emergono da due livelli: il modello di base e il framework di orchestrazione che lo avvolge.

Il modello di base determina la capacità del sistema di comprendere i requisiti, pianificare attività a più fasi e generare codice corretto. Se il modello interpreta erroneamente un vincolo o produce una logica errata, nessun livello di orchestrazione può compensare completamente tale errore.

L'architettura dell'agente, tuttavia, determina come viene utilizzato tale modello. Decide come viene raccolto il contesto dall'area di lavoro, quando vengono eseguiti i comandi della shell, come vengono convalidati gli output e se il sistema effettua dei tentativi dopo un errore. Queste decisioni influenzano il comportamento in fase di esecuzione, i costi e l'affidabilità.

Due agenti basati su modelli ugualmente performanti possono comportarsi in modo diverso. Uno potrebbe riprovare in modo aggressivo dopo un errore parziale, consumando più token ma riuscendo a recuperare dagli errori iniziali. L'altro potrebbe terminare rapidamente alla prima incoerenza. Uno potrebbe imporre una rigorosa validazione prima di procedere, mentre l'altro potrebbe continuare con ipotesi non verificate.

Questo benchmark valuta il sistema completo. Non isola l'intelligenza grezza del modello dalla logica di orchestrazione. Quando un agente consuma un numero eccessivo di token o fallisce un contratto di backend, la causa potrebbe risiedere nella qualità della pianificazione, nella politica di ritentativo, nella gestione del contesto o nella rigorosità della validazione.

Comprendere questa distinzione è fondamentale. Un elevato utilizzo di token non indica necessariamente un ragionamento più profondo, e un punteggio inferiore non implica automaticamente una minore capacità del modello sottostante. Negli ambienti autonomi, l'architettura e il ragionamento del modello interagiscono continuamente.

Comportamenti dell'agente nel compito 6

Abbiamo valutato gli agenti in 10 compiti. Di seguito, presentiamo un'analisi dettagliata del compito 6 per illustrare come si comportano le diverse architetture degli agenti in presenza degli stessi vincoli.

Attività 6: Sistema di ticket di assistenza (Web)

Il compito 6 richiedeva la creazione di un sistema di ticket di assistenza completo con:

• Due ruoli utente (cliente e agente)
• Autenticazione basata su JWT
• transizioni di flusso di lavoro con stato rigoroso
• Isolamento dei dati (404 anziché 403 per l'accesso tra utenti diversi)
• Backend FastAPI
• Frontend React/Vue/Svelte + Vite
• Comandi di esecuzione deterministici

Il test del fumo ha dato esito positivo:

• Controllo sanitario
• Autenticazione a doppio ruolo
• Operazioni CRUD sui biglietti
• Compiti e risposte
• transizioni di stato
• Applicazione dei ruoli
• Isolamento dei dati
• Comportamento di accesso e post-accesso all'interfaccia utente

Questo compito pone l'accento sulla gestione dello stato, la correttezza dell'autenticazione, la disciplina dei contratti REST e l'integrazione frontend-backend. Visita GitHub per visualizzare i dettagli del compito.

Codice

Installazione

Installa a livello globale con:

• npm install -g @openai/codex

In alternativa, installalo a livello globale con Homebrew (macOS/Linux).

• brew install –cask codex

Autenticazione

Dopo aver configurato Codex, puoi continuare con il tuo account ChatGPT o con la tua chiave API OpenAI. Nessuna opzione provider disponibile.

Rapporto sull'attività

Codex ha realizzato un sistema funzionalmente corretto, ma si è discostato dal contratto REST specificato. La scelta del metodo ha ridotto la conformità rigorosa, nonostante la logica aziendale fosse corretta.

Comportamento di backend

Autenticazione, operazioni CRUD sui ticket, risposte e transizioni di stato hanno funzionato correttamente. L'applicazione dei ruoli e l'isolamento dei dati sono stati implementati correttamente.

Il problema principale era dovuto a un'incongruenza nel metodo HTTP. Codex aveva implementato /tickets/{id}/assign e /tickets/{id}/status come endpoint PATCH, mentre il test di base richiedeva PUT.

La modalità adattiva ha ripristinato alcune funzionalità tentando metodi alternativi. La modalità rigorosa ha fallito tutti i passaggi collegati a tali endpoint.

Comportamento dell'interfaccia utente

Il frontend ha superato tutte le fasi di validazione dell'interfaccia utente. Il flusso di accesso e lo stato post-accesso si sono comportati correttamente.

Junie

Installazione

Junie è disponibile tramite JetBrains Toolbox o come interfaccia a riga di comando autonoma:

• curl -fsSL https://junie.jetbrains.com/install | bash

Autenticazione

Continua con il tuo account JetBrains o genera una JUNIE_API_KEY su junie.jetbrains.com/cli, oppure esporta la tua chiave API da Anthropic, OpenAI, Google o altri provider supportati. Sono disponibili diverse opzioni di provider.

Rapporto sull'attività

Junie ha realizzato un sistema full-stack completo in 327 secondi. Autenticazione, CRUD e isolamento dei dati hanno funzionato correttamente. Due scelte di progettazione dell'endpoint hanno causato sei errori nel backend. Il frontend ha superato tutti i passaggi di validazione funzionale, ma ha visualizzato un'interfaccia solo testuale, priva di stile visivo o branding.

Comportamento di backend

Junie ha generato un backend FastAPI con 8 file e un frontend React + Vite con Tailwind CSS. I dati iniziali includevano 2 utenti e 3 ticket con stati diversi.

Autenticazione, operazioni CRUD sui ticket, risposte, visualizzazione dei dettagli e isolamento dei dati hanno funzionato correttamente. Nove dei 16 passaggi dell'API sono stati superati.

I sei passaggi falliti derivavano da due problemi. In primo luogo, /tickets/{id}/assign era implementato come POST anziché come previsto PUT, causando il fallimento della fase di assegnazione. In secondo luogo, non esisteva un endpoint dedicato /tickets/{id}/status. Le transizioni di stato venivano gestite tramite un endpoint PUT unificato /tickets/{id} con un campo body. Il test di base ha preso di mira direttamente /tickets/{id}/status, restituendo 404.

La logica di transizione è stata implementata correttamente. La mappa di transizione valida imponeva il passaggio da aperto a in_progress, da in_progress a waiting_on_customer o risolto, da risolto a riaperto e da riaperto a in_progress. Le restrizioni di ruolo per la risoluzione (solo agente) e la riapertura (solo cliente) erano presenti nel gestore di aggiornamento unificato. L'endpoint di assegnazione effettuava anche la transizione automatica dei ticket aperti a in_progress.

Comportamento dell'interfaccia utente

Il frontend ha superato tutti gli 8 passaggi di validazione. Il modulo di accesso è stato visualizzato correttamente, l'autenticazione è stata mantenuta e il comportamento post-accesso ha funzionato come previsto. Nessun arresto anomalo in fase di esecuzione o errore nella console.

Interfaccia a riga di comando di Kiro

Installazione

Per macOS/Linux/WSL:

• curl -fsSL https://cli.kiro.dev/install | bash

Immagine alternativa di Linux (opzione portatile):

• Download: https://desktop-release.q.us-east-1.amazonaws.com/latest/kiro-cli.appimage

Quindi esegui:

• chmod +x kiro-cli.appimage && ./kiro-cli.appimage

Autenticazione

Puoi continuare con il tuo piano Kiro-Code. Non sono disponibili alternative di altri fornitori.

Rapporto sull'attività

Kiro ha realizzato l'implementazione più rapida e compatta. Le transizioni di stato, l'applicazione dei ruoli e l'isolamento dei dati sono stati implementati correttamente a livello logico.

Tuttavia, lo stesso schema di progettazione dell'endpoint di aggiornamento unificato visto in Aider ha causato sei errori di contratto. Un problema del ciclo di vita del frontend ha ulteriormente ridotto il punteggio dell'interfaccia utente. Il sistema è strutturalmente valido ma diverge dalla progettazione API specificata.

Comportamento di backend

Kiro ha generato un'implementazione full-stack compatta in circa 97 secondi. Il backend consisteva in un file main.py di 324 righe, mentre il frontend era un'applicazione React a file singolo di 276 righe. In totale sono stati prodotti solo 9 file. I dati di partenza includevano 4 ticket di esempio con stati diversi.

Autenticazione, operazioni CRUD sui ticket, risposte, visualizzazione dei dettagli e isolamento dei dati hanno funzionato correttamente. Nove dei 16 passaggi dell'API sono stati superati.

I sei passaggi che non vanno a buon fine corrispondono a /tickets/{id}/assign e /tickets/{id}/status. Kiro ha implementato un endpoint PATCH unificato /tickets/{id} che aggiorna stato, priorità e assegnazione tramite campi JSON nel corpo della richiesta. La logica di business è corretta, ma la struttura dell'endpoint non corrisponde al contratto previsto, con conseguenti risposte 404.

Comportamento dell'interfaccia utente

Il preflight del backend è andato a buon fine e il frontend si è avviato correttamente. Vite è stato avviato senza arresti anomali in fase di esecuzione.

Tuttavia, il modulo di accesso non è stato visualizzato. Playwright è andato in timeout dopo 7 secondi di attesa del campo di input dell'email. La diagnostica della console ha mostrato un errore 422 durante il caricamento iniziale della pagina, probabilmente causato da una chiamata /auth/me eseguita al montaggio senza un token valido. Ciò ha impedito il rendering del componente di accesso e ha bloccato i passaggi rimanenti dell'interfaccia utente.

Codice Claude

Installazione

Per macOS/Linux/WSL, a seconda del gestore di pacchetti preferito, è possibile installare Claude Code con uno dei seguenti metodi:

• curl -fsSL https://claude.ai/install.sh | bash
• brew install –cask codex

Autenticazione

Dopo aver configurato Claude Code, puoi continuare a utilizzare il tuo account Claude. Non sono disponibili opzioni di provider.

Rapporto sull'attività

Claude Code ha prodotto una delle codebase più strutturate in questo compito. Tuttavia, un problema fondamentale di validazione JWT ha reso il backend inutilizzabile.

Ciò evidenzia una distinzione fondamentale nella valutazione degli agenti: la completezza strutturale non compensa la correttezza dell'autenticazione.

Ha inoltre consumato il volume di token più elevato tra gli agenti valutati nel Task 6.

Comportamento di backend

Gli endpoint di login hanno restituito 200 e hanno emesso correttamente i token JWT. Tuttavia, tutte le successive richieste autenticate hanno restituito 401 "Impossibile convalidare le credenziali".

La causa principale sembra essere una mancata corrispondenza tra OAuth2PasswordBearer(tokenUrl=”auth/login”) e il prefisso di percorso /auth. L'adattatore smoke ha rilevato correttamente l'endpoint di login, ma i token emessi non sono stati accettati dal middleware.

Di conseguenza, 13 dei 16 passaggi del backend non sono andati a buon fine.

Inoltre, Claude Code ha implementato un singolo endpoint PATCH /tickets/{id} per gli aggiornamenti anziché endpoint dedicati /assign e /status. Tuttavia, questa scelta progettuale è diventata irrilevante a causa del fallimento dell'autenticazione.

Comportamento dell'interfaccia utente

Il modulo di accesso è stato visualizzato correttamente. L'invio del modulo ha restituito un codice di stato 200. Tuttavia, dopo l'accesso, Playwright ha rilevato un arresto anomalo durante la navigazione:
“Il contesto dell’esecuzione è stato distrutto.”

I log del browser mostravano risposte 401 alle chiamate API autenticate, il che causava un'interruzione dello stato post-login.

Aider

Installazione

Se hai già installato Python 3.8-3.13, per prima cosa installa Aider:

• python -m pip install aiutante-installa
• installazione di Aider

Autenticazione

Accedi al tuo account OpenRouter e autorizza o esporta la tua chiave API nel tuo ambiente con:

• esporta OPENROUTER_API_KEY=”sk-or-v1-…”

Rapporto sull'attività

Aider era il builder più veloce ed efficiente in termini di token. Tuttavia, la progettazione della sua API si discostava dalle specifiche e l'interfaccia utente di accesso non veniva visualizzata correttamente.

Comportamento di backend

Autenticazione, operazioni CRUD sui ticket, risposte, visualizzazione dei dettagli e isolamento dei dati sono stati implementati correttamente.

Invece di endpoint dedicati /assign e /status, Aider ha utilizzato un endpoint PUT unificato /tickets/{id} per tutti gli aggiornamenti. Il test di base prevedeva endpoint separati, causando errori 404 per le fasi di assegnazione e stato.

Comportamento dell'interfaccia utente

Il frontend ha visualizzato il contenuto, ma il modulo di accesso non è apparso. Playwright è andato in timeout in attesa del campo di input dell'email. I passaggi successivi dell'interfaccia utente sono stati bloccati.

OpenCode

Installazione

Per macOS/Linux/WSL:

• curl -fsSL https://opencode.ai/install | bash

Installa a livello globale con:

• npm i -g opencode-ai

Per macOS/Linux, tenendo conto del gestore di pacchetti preferito:

• bun add -g opencode-ai
• brew install anomalyco/tap/opencode
• paru -S opencode

Autenticazione

Sono disponibili numerose opzioni di provider, seleziona il provider desiderato e autenticati con /connect

Rapporto sull'attività

OpenCode ha prodotto l'implementazione più conforme alle specifiche, con una sola deviazione in un caso limite. Ha inoltre consumato il minor volume di token tra tutti gli agenti coinvolti in questo compito.

Comportamento di backend

Autenticazione, operazioni CRUD, risposte, assegnazione, transizioni di stato, applicazione dei ruoli e isolamento dei dati sono stati implementati correttamente.

Entrambi gli endpoint /tickets/{id}/assign e /tickets/{id}/status sono stati implementati come previsto.

L'unico passaggio fallimentare si è verificato quando l'agente ha tentato di impostare lo stato su in_progress dopo l'assegnazione. Poiché l'operazione di assegnazione aveva già portato il ticket allo stato in_progress, la seconda transizione ha restituito 400 a causa della rigida applicazione del principio no-op.

Il comportamento del backend era logicamente corretto, ma il test di base prevedeva un successo idempotente per transizioni ripetute.

Comportamento dell'interfaccia utente

Il frontend ha superato tutti gli 8 passaggi di validazione. La schermata di accesso è stata visualizzata correttamente, l'autenticazione è rimasta attiva e il comportamento post-accesso ha funzionato come previsto.

Fucina

Installazione

Per macOS/Linux/WSL:

• curl -fsSL https://opencode.ai/install | bash

Autenticazione

Configura le credenziali del tuo provider in modo interattivo tramite:

• accesso del provider Forge

E scegli il tuo fornitore.

Rapporto sull'attività

Un singolo errore di configurazione del routing ha innescato una serie di guasti a cascata nel backend. Il numero relativamente basso di token di output suggerisce una limitata profondità di implementazione.

Comportamento di backend

Accesso effettuato con successo e token emessi.

La creazione del ticket ha restituito un reindirizzamento 307 anziché 200/201. Poiché la creazione del ticket non è riuscita, i passaggi successivi che fanno riferimento a $created_ticket.id non sono andati a buon fine con errori 422.

Le risposte 307 derivano probabilmente dal comportamento di reindirizzamento dello slash finale in FastAPI.

Gli endpoint /assign e /status hanno restituito un errore 404.

Comportamento dell'interfaccia utente

Il frontend ha fornito i contenuti, ma i componenti di login non sono stati visualizzati correttamente a causa di errori di runtime in AuthContext.tsx. I passaggi successivi dell'interfaccia utente sono stati bloccati.

Interfaccia a riga di comando Gemini

Installazione

Esegui immediatamente con:

• npx @google/gemini-cli

Installa a livello globale con:

• npm install -g @google/gemini-cli

Installa a livello globale con Homebrew (macOS/Linux):

• brew install gemini-cli

Installa a livello globale con MacPorts (macOS):

• sudo port install gemini-cli

Installare con Anaconda (per ambienti con restrizioni):

• conda create -y -n gemini_env -c conda-forge nodejs
• conda activate gemini_env

Autenticazione

Opzione 1: Accedi con Google (accesso OAuth utilizzando il tuo account Google):

Inizia con Gemini e scrivi:

• esporta GOOGLE_CLOUD_PROJECT=”IL_TUO_ID_PROGETTO”

Quindi, avvia Gemini.

Opzione 2: Chiave API Gemini

Inizia con Gemini e scrivi:

• esporta GEMINI_API_KEY=”LA_TUA_CHIAVE_API”

Quindi, avvia Gemini.

Opzione 3: Vertex AI

Inizia con Gemini e scrivi:

• esporta GOOGLE_API_KEY=”LA_TUA_CHIAVE_API”
• esporta GOOGLE_GENAI_USE_VERTEXAI=true

Rapporto sull'attività

Gemini CLI ha prodotto un backend robusto, ma ha fallito a causa dell'incompatibilità con gli strumenti del frontend. Ha inoltre consumato il volume di token più elevato tra le implementazioni di backend riuscite.

Comportamento di backend

Autenticazione, operazioni CRUD, risposte, assegnazione, applicazione dei ruoli e isolamento dei dati sono stati implementati correttamente.

Tuttavia, l'endpoint /tickets/{id}/status risultava completamente mancante, causando la restituzione di un errore 404 per tutte le fasi di transizione di stato.

Comportamento dell'interfaccia utente

L'avvio del frontend non è riuscito. È stata installata la versione 7.3.1 di Vite, che richiede Node.js 20.19 o versioni successive, mentre l'ambiente di test utilizza Node.js 18.18.0. L'API crypto.hash, richiesta da Vite, non era disponibile.

Di conseguenza, l'interfaccia utente non è mai stata avviata e ha ottenuto un punteggio di 0/8.

Cline

Installazione

Installa a livello globale con:

• npm install -g cline

Autenticazione

Digitando `cline auth` puoi selezionare il tuo account Cline o continuare con il provider desiderato.

Rapporto sull'attività

Il meccanismo di limitazione degli errori di Cline ha interrotto la compilazione prima del completamento. La struttura del backend mostra un'intenzione architetturale corretta, ma problemi di registrazione delle route e un'implementazione incompleta hanno impedito la validazione funzionale.

L'assenza di un frontend e i conseguenti guasti a cascata nel backend collocano questo risultato tra i più deboli del Task 6.

Comportamento di backend

Cline ha generato un backend con cinque file: main.py, models.py, schemas.py, auth.py e database.py, insieme a un file requirements.txt. La struttura includeva modelli appropriati, un'impalcatura per l'autenticazione JWT e stub per gli endpoint.

Tuttavia, durante lo sviluppo del backend, l'agente ha raggiunto il limite di otto errori e si è arrestato prima di completare il sistema.

Solo gli endpoint di login hanno funzionato correttamente. Tre dei 16 passaggi dell'API sono stati superati.

La creazione del ticket ha restituito un reindirizzamento 307 anziché 200 o 201, probabilmente a causa di errori di incompatibilità del percorso con la barra finale. Poiché la creazione del ticket non è riuscita, il valore di $created_ticket.id non è mai stato acquisito. Tutti i passaggi successivi che facevano riferimento all'ID del ticket hanno passato il valore letterale della stringa, generando errori 422.

Gli endpoint /tickets/{id}/assign e /tickets/{id}/status non sono stati implementati, con conseguenti risposte 404.

Ciò ha generato uno schema di errore a cascata simile a quello di Forge, in cui un problema di routing iniziale ha invalidato le fasi successive.

Comportamento dell'interfaccia utente

Il backend si è avviato correttamente. Tuttavia, la directory frontend/ era vuota e non esisteva alcun file package.json.

Solo la fase di preflight del backend è andata a buon fine. Tutte le fasi rimanenti dell'interfaccia utente sono state bloccate.

Oca

Installazione

Per macOS/Linux/WSL:

• curl -fsSL https://github.com/block/goose/releases/download/stable/download_cli.sh | bash

Modello: Anteprima Gemini 3 Pro (tramite OpenRouter)
Tempo: 1.297 secondi
Token: 17k input / 752 output
Punteggio API: 60%
Punteggio UI: 0%

Goose ha dimostrato una limitata capacità di autocorrezione, ma non è riuscito a completare il requisito full-stack. I problemi di affidabilità riscontrati durante le riesecuzioni sollevano preoccupazioni in termini di stabilità.

Comportamento di backend

Autenticazione, operazioni CRUD sui ticket, risposte, visualizzazione dei dettagli e isolamento dei dati hanno funzionato correttamente.

Tuttavia, gli endpoint /assign e /status non sono stati implementati, causando risposte 404 per tutte le fasi correlate.

In una versione precedente, Goose ha riscontrato errori di compatibilità con bcrypt, che ha corretto automaticamente bloccando la versione della dipendenza, e alla fine ha avviato il backend.

Un successivo tentativo di esecuzione si è concluso con un errore di decodifica del flusso dopo la generazione di un numero minimo di file.

Comportamento dell'interfaccia utente

Non è stato creato alcun frontend. La directory del frontend era vuota e non esisteva alcun file package.json. Il test dell'interfaccia utente è fallito immediatamente.

Strumenti di programmazione per l'intelligenza artificiale

Gli strumenti di programmazione per l'intelligenza artificiale possono essere raggruppati in tre categorie:

• Agentic CLI: Strumenti per flussi di lavoro di sviluppo basati su terminale, per generare, modificare e rifattorizzare il codice tramite prompt e interazioni da riga di comando.
  • Esempi: Aider, Junie, Opencode, Claude Code, Codex

• Editor di codice basati sull'IA : noti anche come IDE agentici, questi strumenti offrono un'interfaccia grafica simile a VS Code (la maggior parte di essi è basata su VS Code).
  • Esempi: Antigravità, Cursore, Codice Kiro, Windsurf

• Strumenti per la creazione di app a partire da comandi : piattaforme low-code/no-code per la creazione di app tramite comandi in linguaggio naturale e flussi di lavoro visivi.
  • Esempi: Bolt, Lovable, v0.dev, Firebase Studio, Dazl

Strumenti di revisione del codice basati sull'IA

Con la crescente diffusione del codice generato dall'IA, gli strumenti di revisione del codice sono essenziali per individuare bug e vulnerabilità. Abbiamo valutato i migliori strumenti su 309 pull request nel nostro benchmark RevEval .

Che cosa possono fare gli strumenti CLI agentici?

Strumenti come Codex, Junie, Kiro e Claude Code presentano funzionalità comuni, tra cui:

• Gestione completa del codice: creazione e modifica di file, correzione di bug, refactoring del codice ed esecuzione di test o linter direttamente dal terminale.
• Flussi di lavoro agentici: Eseguire attività a più fasi come concatenamento di attività, risoluzione dei problemi, ricerca e debug iterativo.
• Gestione di Git e dei progetti: esamina la cronologia, risolvi le fusioni, gestisci i rami e crea commit o richieste pull.
• Esecuzione e automazione: esegui comandi shell, automatizza le analisi e traduci il linguaggio naturale in operazioni CLI complesse.
• Gestione approfondita del contesto: operare su repository completi, tenendo conto delle dipendenze e della struttura del progetto.
• Flessibilità del modello: supporto per più modelli cloud e, in alcuni casi, locali; alcuni strumenti consentono di utilizzare la propria chiave API o di scegliere tra diversi piani.
• Accesso in ambiente sandbox o controllato: offrono modalità che vanno dalla sola lettura all'automazione completa, spesso con ambienti isolati per motivi di sicurezza.

Metodologia

Abbiamo valutato gli agenti in una configurazione di esecuzione singola per misurarne le capacità autonome senza intervento umano. Gli agenti sono stati poi valutati utilizzando i nostri smoke test di backend e frontend per misurare la prontezza dell'infrastruttura e la correttezza del comportamento.

I punteggi riflettono l'affidabilità con cui ciascun agente ha prodotto sistemi eseguibili e quanti requisiti funzionali hanno superato la convalida.

Configurazione del modello

Il nostro obiettivo era utilizzare Google's gemini-3-pro-preview a causa della sua ampia finestra di contesto , adatta all'orchestrazione di più file e ai prompt di attività lunghi. Tuttavia, alcune CLI agentiche sono strettamente legate a provider specifici:

• Il codice Claude è stato valutato utilizzando claude-opus-4-5-20251101 tramite l'API ufficiale di Anthropic.
• Codex è stato valutato utilizzando gpt-5.2-codex-medium attraverso la configurazione nativa di OpenAI.

Per questi agenti, i provider di modelli alternativi non sono supportati all'interno della loro attuale architettura CLI. Ciascun agente è stato valutato utilizzando la sua configurazione predefinita. Non abbiamo modificato la temperatura, le politiche di ripetizione o i parametri di ragionamento.

Il nostro obiettivo di valutazione era quello di separare e misurare:

• Capacità di compilazione (l'agente è in grado di produrre codice eseguibile?)
• Correttezza del comportamento del backend
• Correttezza del comportamento del frontend
• Affidabilità dell'orchestrazione autonoma

Versioni della CLI (metà febbraio 2026)

• Opencode: v1.2.10
• Cline: v3.41
• Aider: v0.86.0
• Gemini CLI: v0.29.0
• Forge: v1.28.0
• Codice: 0.104.0
• Goose: v1.25.0
• Codice Claude: v2.1.62
• Junie: 888.212
• Kiro CLI: 1.26.0

Per la metodologia di valutazione, visitare: Metodologia di benchmarking per la codifica AI

Per saperne di più

Per chi desidera esplorare l'ecosistema più ampio degli strumenti per sviluppatori di agenti, ecco i nostri benchmark più recenti:

• Benchmark MCP : un confronto tra i migliori server MCP per l'accesso web.
• Browser remoti : come le infrastrutture emergenti dei browser consentono agli agenti di intelligenza artificiale di interagire con il web in modo sicuro.

Cem Dilmegani

Analista principale

Segui

Cem è analista principale presso AIMultiple dal 2017. AIMultiple fornisce informazioni a centinaia di migliaia di aziende (secondo SimilarWeb), tra cui il 55% delle aziende Fortune 500, ogni mese. Il lavoro di Cem è stato citato da importanti pubblicazioni globali come Business Insider, Forbes, Washington Post, società globali come Deloitte e HPE, ONG come il World Economic Forum e organizzazioni sovranazionali come la Commissione Europea. È possibile consultare l'elenco di altre aziende e risorse autorevoli che hanno citato AIMultiple. Nel corso della sua carriera, Cem ha lavorato come consulente tecnologico, responsabile acquisti tecnologici e imprenditore nel settore tecnologico. Ha fornito consulenza alle aziende sulle loro decisioni tecnologiche presso McKinsey & Company e Altman Solon per oltre un decennio. Ha anche pubblicato un report di McKinsey sulla digitalizzazione. Ha guidato la strategia tecnologica e gli acquisti di un'azienda di telecomunicazioni, riportando direttamente al CEO. Ha inoltre guidato la crescita commerciale dell'azienda deep tech Hypatos, che ha raggiunto un fatturato annuo ricorrente a 7 cifre e una valutazione a 9 cifre partendo da zero in soli 2 anni. Il lavoro di Cem in Hypatos è stato oggetto di articoli su importanti pubblicazioni tecnologiche come TechCrunch e Business Insider. Cem partecipa regolarmente come relatore a conferenze internazionali di settore. Si è laureato in ingegneria informatica presso l'Università di Bogazici e ha conseguito un MBA presso la Columbia Business School.

Visualizza il profilo completo

Revisionato tecnicamente da

Berk Kalelioğlu

Ricercatore di intelligenza artificiale

SeguiVisualizza il profilo completo

Sii il primo a commentare

Il tuo indirizzo email non verrà pubblicato. Tutti i campi sono obbligatori.

Nome

Indirizzo e-mail

Commento

0/450

Pubblica un commento