Il tuo agente di coding sta pagando prezzi da modello frontier per rispondere a domande a scelta multipla.
Quali note devo caricare? Questo passaggio va al modello grande o a uno piccolo? Il tool ha appena fallito. Riprovo, correggo o lascio perdere? Quali test eseguo prima?
Ognuna di queste è una domanda con quattro o cinque possibili risposte. E nella maggior parte delle configurazioni di agenti odierne, a ciascuna risponde il modello più costoso che hai, con il thinking attivato, leggendo l'intero contesto e scrivendo un paragrafo prima di prendere una decisione.
Ecco dove perdi soldi.
Questo articolo ti mostra come tappare la falla. Opus 5.5 si occupa del ragionamento complesso: pianificazione, scrittura del codice, debugging. Jev prende le quattro decisioni che si presentano in quasi ogni passaggio. Il tuo harness prepara le opzioni, verifica le risposte e ha l'ultima parola.
Nell'esempio pratico qui sotto, una sessione di sviluppo di una feature passa da $6.42 a $2.00. Un risparmio del 69%, con ogni singolo calcolo spiegato nell'articolo così puoi confrontarlo con i tuoi numeri.
È pensato per chiunque utilizzi un agente di coding su progetti reali: Claude Code, un tuo harness basato sulle API o qualsiasi via di mezzo. Non devi riscrivere il tuo agente. Ogni componente di questo articolo si inserisce in un loop esistente come una semplice chiamata di funzione, con un flag per disattivarla. Se hai letto il mio articolo su Jev + Claude Code, questa è la versione aggiornata: stessa idea, un modello di ragionamento più recente e quattro decisioni specifiche invece di un principio generale.
Ti serviranno una chiave API Jev, una chiave API Anthropic e circa una settimana di log del tuo agente come riferimento per le misurazioni.
Iniziamo.
opus ragiona jev decide.
Il problema: un solo modello per due lavori diversi
Guarda lavorare un agente di coding per dieci minuti e lo vedrai svolgere due tipi di attività completamente diverse.
Il primo lavoro è il ragionamento. Pianificare una feature. Scrivere una funzione. Leggere uno stack trace e capire perché il parser delle date si rompe negli anni bisestili. È un'attività aperta. La risposta non è in un elenco. Qui vuoi il modello più intelligente che puoi permetterti, e Opus 5.5 è eccellente in questo.
Il secondo lavoro è decidere. Scegliere le tre note di progetto che contano su quaranta. Decidere che un rename può essere gestito da un modello economico. Stabilire cosa fare dopo il timeout di npm test. Scegliere quali 12 file di test eseguire prima dei 1.400 totali. Queste risposte sono in un elenco. L'elenco è breve. E il tuo codice può agire direttamente sulla risposta.
La maggior parte degli agenti fa passare entrambi i lavori dallo stesso modello, perché è l'impostazione predefinita. Il loop chiama Opus, Opus pensa, Opus risponde, il loop continua.
Funziona. Ma è anche lento e costoso in un modo difficile da notare, perché le chiamate decisionali non sembrano pesanti se prese singolarmente. Una singola chiamata "quali note mi servono" costa forse un centesimo. Ma avviene a ogni passaggio, e ogni volta si porta dietro l'intero contesto.
E c'è un secondo costo ancora più subdolo: quando l'agente non sa cosa caricare, carica tutto. Ogni nota di progetto, ogni documento sulle convenzioni, ogni decisione passata, infilati in ogni chiamata. Opus 5.5 ha reso economiche le letture dalla cache a $0.20 per milione di token, ma "economico moltiplicato per sessanta passaggi moltiplicato per tutta la tua cartella delle note" alla fine pesa.
La soluzione: Opus ragiona, Jev decide, il tuo harness comanda
Jev è il modello di TypeSafe costruito esattamente per il secondo lavoro. Non scrive testo. Gli fornisci contesto e domande tipizzate con un set fisso di opzioni, e lui restituisce una probabilità per ogni opzione. Risponde in millisecondi, l'input costa $0.042 per milione di token e l'output è gratuito.
Questo rende l'architettura semplice da descrivere:
Opus 5.5 si occupa del ragionamento. Pianificazione, codice, debugging, tutto ciò in cui la risposta non è in un elenco.
Jev prende le piccole decisioni. Sceglie tra le opzioni preparate dal tuo harness.
Il tuo harness mantiene il controllo. Costruisce gli elenchi di opzioni, legge le probabilità, applica le soglie e passa la palla a Opus quando Jev non è sicuro.
Quest'ultimo punto è quello che tutti saltano, ed è quello che rende sicura l'intera architettura. Jev non inventa mai un'opzione. Jev non ha mai l'ultima parola su qualcosa che non puoi annullare. È il tuo codice a decidere cosa significa "abbastanza sicuro".
Ecco l'helper su cui si basa tutto il resto di questo articolo:
from dataclasses import dataclass
class Decision:
answer: str
prob: float
probs: dict
confident: bool
def jev_choice(context: str, question: str, options: list[str]):
Collega questo al tuo client Jev: l'SDK TypeSafe, Vercel AI Gateway,
o il pacchetto LangChain. Deve restituire {opzione: probabilità}
per ogni opzione che hai passato.
raise NotImplementedError
def decide(context: str, question: str, options: list[str], threshold: float):
probs = jev_choice(context, question, options)
answer = max(probs, key=probs.get)
return Decision(answer, probs[answer], probs, probs[answer] >= threshold)
Nota cosa manca: nessuna domanda che chiede a Jev quanto è sicuro. Leggi semplicemente la probabilità che restituisce. Chiedere a qualsiasi modello "sei sicuro?" ti farà ottenere un "sì" quasi ogni volta. La probabilità è il segnale onesto.
Ora passiamo alle quattro decisioni.
Le quattro decisioni all'interno dello step dell'agente
Decisione 1: seleziona le note di progetto rilevanti prima di caricare il contesto
Questa è la leva singola più potente, ed è quella che quasi nessuno ha ancora implementato.
Il tuo agente ha una cartella di note. Un AGENTS.md, documenti sull'architettura, convenzioni, decisioni passate, avvisi come "non toccare mai il modulo di fatturazione senza una migration". Forse 30.000 token in totale. La maggior parte degli agenti li carica tutti a ogni chiamata, perché nessuno vuole essere quello che ha dimenticato la nota importante.
Quindi, invece di caricare tutto, fai a Jev una semplice domanda su ogni nota, tutte in parallelo: l'agente ha bisogno di questa nota per questo task?
Prima di tutto, dividi le tue note in chunk per intestazione. Ogni sezione di AGENTS.md diventa un chunk a sé. Ogni documento architetturale diventa uno o più chunk.
import re
def chunk_notes(markdown: str, source: str):
parts = re.split(r"
(?=## )", markdown)
return [{"source": source, "text": p.strip()} for p in parts if p.strip()]
Poi valuta ogni chunk rispetto al task corrente:
from concurrent.futures import ThreadPoolExecutor
def pick_notes(task: str, notes: list[dict], keep: int = 6, floor: float = 0.55):
def score(note):
probs = jev_choice(
context=f"TASK:
{task}
NOTE ({note['source']}):
{note['text']}",
question="Un ingegnere avrebbe bisogno di questa nota per svolgere correttamente il task?",
options=["needed", "not_needed"],
)
return probs["needed"], note
with ThreadPoolExecutor(max_workers=16) as pool:
scored = sorted(pool.map(score, notes), key=lambda s: s[0], reverse=True)
picked = [n for p, n in scored[:keep] if p >= floor]
return picked or [n for _, n in scored[:2]]
Qui contano tre dettagli.
Carica sempre le cose non negoziabili. Alcune note devono esserci in ogni chiamata, qualunque cosa accada: regole di sicurezza, "mai fare force push", quell'unica riga che indica quale database è quello di produzione. Contrassegnale come "always" e salta la valutazione.
Mantieni una soglia minima e un fallback. Se nulla supera 0.55, carichi comunque le prime due. Un agente con zero contesto è peggio di uno con un po' troppo contesto.
Logga cosa viene scartato. Quando l'agente commette un errore, la prima cosa da controllare è se la nota che lo avrebbe evitato è stata scartata dalla valutazione. Quel log è il modo in cui calibri keep e floor.
Nell'esempio pratico, questa singola modifica riduce la porzione di note di ogni chiamata da 30.000 a 6.000 token. Da sola, taglia il costo della sessione di circa il 24%.
Decisione 2: instrada i task adatti a un worker più veloce
Non ogni passaggio richiede Opus.
Rinominare una funzione in otto file no. Aggiungere un campo a un form che ne ha già nove identici no. Aggiornare il percorso di un import no. Sono modifiche che seguono un pattern già presente nel codebase.
Quindi, prima che ogni passaggio venga eseguito, Jev classifica lo step e il tuo mappa la classe a un worker:
ROUTES = {
"rename_or_move": "fast",
"small_edit_following_existing_pattern": "fast",
"new_logic": "opus",
"debugging": "opus",
"design_decision": "opus",
}
def route(step: str, recent_diff: str):
d = decide(
context=f"STEP:
{step}
RECENT CHANGES:
{recent_diff}",
question="Che tipo di lavoro è questo passaggio?",
options=list(ROUTES),
threshold=0.8,
)
if not d.confident:
return "opus"
return ROUTES[d.answer]
Guarda come sono scritte le opzioni. Non sono "facile" e "difficile", e di certo non sono "un modello piccolo può farcela?". Sono categorie concrete di lavoro che il tuo codice può mappare a un'azione. Questa è la regola per ogni domanda rivolta a Jev: ogni opzione deve corrispondere a qualcosa su cui il tuo harness sa come agire.
E nota il default. Sotto 0.8, il passaggio va a Opus. Gli errori di routing qui vanno solo in una direzione: un task difficile mandato al worker veloce ti costa uno step fallito e un retry, mentre un task facile mandato a Opus costa solo un po' di più. Quindi, nel dubbio, scala verso l'alto.
Come worker veloce uso Haiku 4.5 a $1 per milione di token di input e $5 per milione di output. Nell'esempio pratico, 12 dei 36 passaggi di lavoro effettivo vengono affidati a lui.
Decisione 3: scegli un percorso di recupero quando un tool fallisce
I tool falliscono continuamente. I test vanno in timeout. Un percorso di file è sbagliato. Manca un pacchetto. Un comando shell genera un errore di permessi. Un linter si lamenta di qualcosa di irrilevante.
La maggior parte degli agenti gestisce la cosa nel modo più costoso possibile: rimbalza l'intero errore al modello grande e lo lascia pensare sul da farsi. A volte è giusto. Spesso la soluzione è ovvia, e Opus spreca 1.500 token per riscoprire che ENOENT significa che il file non esiste.
Peggio ancora, gli agenti si incastrano nei loop. Riprova, fallisci, riprova, fallisci, pagando ogni volta per un intero passaggio di ragionamento.
Quindi affidi il fallimento a Jev con un set fisso di percorsi di recupero:
from collections import deque
def tail(text: str, n: int = 4000):
return "".join(deque(text, maxlen=n)) # ultimi n caratteri dell'errore
def recover(tool: str, command: str, error: str, attempt: int):
if attempt >= 3:
return "stop_and_report"
d = decide(
context=f"TOOL: {tool}
COMMAND: {command}
ATTEMPT: {attempt}
ERROR:
{tail(error)}",
question="Qual è la mossa migliore dopo questo fallimento?",
options=RECOVERY,
threshold=0.8,
)
return d.answer if d.confident else "escalate_to_opus"
1RECOVERY = [2 "retry_unchanged", # rete instabile o timeout3 "retry_after_install", # pacchetto o tool mancante4 "fix_path_and_retry", # percorso file o cwd errato5 "switch_tool", # questo tool non ce la fa, un altro sì6 "escalate_to_opus", # serve vero debugging7 "stop_and_report", # serve un umano8]
Il limite massimo di tentativi vive nel codice, non nel modello. Nessun modello, per quanto economico, dovrebbe poter riprovare all'infinito.
Ogni percorso di recupero corrisponde a una piccola funzione nel tuo harness. retry_after_install estrae il pacchetto mancante dall'errore con una regex e lo installa. fix_path_and_retry controlla i percorsi esistenti e suggerisce quello più simile. Solo escalate_to_opus costa soldi veri, e scatta unicamente quando il fallimento richiede davvero ragionamento.
Nell'esempio pratico, questo elimina 6 passaggi di retry sprecati dalla sessione.
Decisione 4: esegui controlli mirati prima della suite di test completa
Questa fa risparmiare più tempo che denaro, ed è il tempo a far sembrare veloce un agente.
Dopo ogni modifica, la maggior parte degli agenti esegue l'intera suite di test. Se la tua suite impiega quattro minuti, il tuo agente passa quattro minuti ad aspettare dopo ogni modifica, per poi scorrere centinaia di righe di output cercando l'unico fallimento che conta.
La soluzione segue lo stesso schema delle note: valuta ogni file di test rispetto al diff, esegui prima quelli più rilevanti e lancia la suite completa solo se i controlli mirati superano il test.
1def pick_tests(diff: str, test_files: list[str], keep: int = 12):2 def score(path):3 probs = jev_choice(4 context=f"DIFF:\n{diff[:12000]}\n\nTEST FILE: {path}",5 question="Questa modifica potrebbe rompere i test in questo file?",6 options=["likely", "unlikely"],7 )8 return probs["likely"], path910 with ThreadPoolExecutor(max_workers=16) as pool:11 scored = sorted(pool.map(score, test_files), key=lambda s: s[0], reverse=True)12 return [p for _, p in scored[:keep]]1314def check(diff: str, test_files: list[str]):15 focused = pick_tests(diff, test_files)16 if not run_tests(focused):17 return False # fallisci subito, correggi prima di tutto il resto18 return run_tests(test_files) # la suite completa resta il gate per il commit
Rileggi due volte quell'ultima riga. La suite completa viene comunque eseguita prima che qualcosa finisca in commit. I controlli mirati sono un campanello d'allarme anticipato, non un sostituto. Intercetti la maggior parte dei problemi in secondi anziché in minuti, e non rilascerai mai qualcosa che la suite completa avrebbe bloccato.
Aggiungi prima anche i controlli economici: type check e lint solo sui file modificati. Ci mettono un secondo e intercettano una quota sorprendente di errori prima ancora che parta un test.
Mettere tutto insieme: il loop dell'harness
Ecco come le quattro decisioni si inseriscono in un singolo passaggio del loop:
def run_step(task: str, step: str, state):
1. contesto: carica solo le note necessarie a questo passaggio
notes = state.always_notes + pick_notes(step, state.notes)
2. routing: scegli il worker per questo passaggio
worker = state.workers[route(step, state.recent_diff())]
result = worker.run(step, notes=notes, history=state.history)
3. recupero: gestisci eventuali fallimenti dei tool in questo passaggio
for failure in result.failures:
action = recover(failure.tool, failure.command, failure.error, failure.attempt)
state.apply_recovery(action, failure)
4. controlli: prima i test mirati, poi la suite completa prima del commit
if result.diff:
state.log_check(check(result.diff, state.test_files))
Ed ecco la parte di Opus: è solo la tua normale chiamata a Opus 5.5. Metti prima il contesto stabile (system prompt, definizioni dei tool, le note "always") così rimane in cache tra un passaggio e l'altro, e metti per ultimo il materiale specifico dello step.
import os
import anthropic
client = anthropic.Anthropic()
OPUS = os.environ["OPUS_MODEL"] # l'id del tuo modello Opus 5.5
def opus_step(system: str, notes: list[dict], history: list, step: str):
notes_text = "
".join(n["text"] for n in notes)
return client.messages.create(
model=OPUS,
max_tokens=8000,
system=[{"type": "text", "text": system, "cache_control": {"type": "ephemeral"}}],
messages=history + [{"role": "user", "content": f"NOTES:
{notes_text}
STEP:
{step}"}],
)
Niente di esotico. Il risparmio deriva da ciò che smetti di inviargli, non da un prompt geniale.
Uno step tracciato
Ecco come appare un singolo passaggio nel log una volta che tutte e quattro le decisioni sono attive. Il task: aggiungere il rate limiting all'endpoint pubblico di registrazione. Questa traccia è illustrativa, ma ricalca esattamente la struttura che vedrai nei tuoi log.
step 14 "aggiungi un rate limit per IP a POST /signup"
[note] valutati 41 chunk in parallelo
mantenuti: api/middleware.md (0.94), conventions/errors.md (0.88),
infra/redis.md (0.81), decisions/2025_auth.md (0.62)
scartati: 37 chunk, inclusi fatturazione, template email, CI
[route] new_logic (0.91) → opus
[opus] pianifica la modifica, scrive middleware + config + modifica handler
[tool] npm test FALLITO "Cannot find module 'bottleneck'"
[recover] retry_after_install (0.97) → npm install, nuova esecuzione
[checks] typecheck file modificati: ok
test mirati (12 su 1.388): ok
suite completa: ok
Leggilo dall'alto verso il basso e conta quante di quelle righe prima richiedevano una chiamata completa a Opus. Selezione delle note: una chiamata pesante, oppure nessuna selezione e 30.000 token di note caricati alla cieca. Routing: nulla, ogni passaggio andava a Opus. Pacchetto mancante: un intero passaggio di ragionamento per dedurre che un modulo mancante significa "installa il modulo". Scelta dei test: nulla, la suite completa a ogni modifica.
Ora solo una riga in quella traccia riguarda Opus, ed è la riga che aveva effettivamente bisogno di un modello frontier: pianificare e scrivere il rate limiter.
Tutto il concetto è racchiuso in questa immagine. Il modello costoso dedica il suo tempo solo alla parte del lavoro che unicamente lui può svolgere.
L'esempio pratico: da dove arriva il 69%
Ecco tutti i calcoli per una sessione di sviluppo di una feature: 60 passaggi dell'agente più i 6 retry sprecati che un agente tipico accumula lungo il percorso. Tutti i prezzi sono quelli pubblici attuali di listino.
Prima: Opus 5.5 fa tutto
Ogni passaggio carica 70.000 token di contesto: 15.000 per il system prompt e i tool, 30.000 per l'intera cartella delle note e 25.000 per la conversazione fino a quel punto. Suppongo che l'80% sia un cache hit. Ogni passaggio produce circa 1.500 token di output, perché il thinking è sempre attivo in Opus 5.5.
letture cache: 56.000 × $0.20/M = $0.0112
input nuovo: 14.000 × $4.00/M = $0.0560
output: 1.500 × $20.00/M = $0.0300
per passaggio = $0.0972
66 passaggi × $0.0972 = $6.42
Dopo: il layer decisionale
Il contesto scende a 46.000 token per passaggio, perché Jev seleziona 6.000 token di note invece di caricarne 30.000. I 24 passaggi puramente decisionali passano a Jev. I 6 loop di retry spariscono. E 12 dei restanti 36 passaggi di lavoro vanno a Haiku 4.5.
Opus 5.5: 24 passaggi × $0.0742 = $1.78
Haiku 4.5: 12 passaggi × $0.0169 = $0.20
Jev: 102 chiamate × 5.000 token
× $0.042/M, output gratis = $0.02
totale = $2.00
Da $6.42 a $2.00. Un risparmio del 68,8% per la stessa identica feature.
imposta la soglia in base a quanto costa una risposta sbagliata
Ed ecco quanto contribuisce ogni leva, in ordine cumulativo:
solo selezione note $4.89 23,7% risparmiato
- decisioni spostate a Jev $3.13 51,2% risparmiato
- percorsi di recupero $2.69 58,1% risparmiato
- routing a worker veloce $2.00 68,8% risparmiato
Due precisazioni doverose su questi calcoli.
Primo: sono numeri modellizzati basati su ipotesi esplicite, non una misurazione del tuo stack. Le dimensioni del tuo contesto, il tasso di cache hit e il numero di decisioni saranno diversi. Il motivo per cui mostro ogni singola riga è permetterti di inserire i tuoi numeri. Una volta misurato il tuo reale prima e dopo, usa i tuoi dati, non i miei.
Secondo: guarda dove finiscono davvero i soldi. Le 102 chiamate di Jev costano in totale due centesimi. Il risparmio non deriva dal fatto che Jev costi poco per chiamata. Deriva da tutto ciò che smette di accadere una volta che Jev prende la decisione: contesti gonfiati, passaggi di ragionamento completi per domande a scelta multipla, loop di retry e chiamate al modello grande per operazioni di rename.
Perché non usare semplicemente Haiku per le decisioni?
Domanda legittima. Haiku 4.5 è economico e veloce. Perché aggiungere un nuovo modello?
Tre motivi.
Continua a generare testo. Haiku risponde in formato testuale. Devi istruirlo a rispondere con una delle tue opzioni, poi parsare la risposta, e infine gestire i casi in cui aggiunge una spiegazione, sceglie qualcosa fuori dall'elenco o inserisce la risposta in una frase intera. Jev restituisce una probabilità per ogni opzione che gli hai passato. Niente da parsare e niente fuori dall'elenco.
Ottieni l'intera distribuzione, non solo una risposta. Quando Jev dice needed: 0.52, not_needed: 0.48, sai che è un lancio di moneta e il tuo harness può scalare la decisione. Quando un modello testuale dice "needed", non hai idea se ne fosse certo. Le soglie funzionano solo se puoi vedere le probabilità.
La matematica dei costi è diversa. L'output di Jev è gratuito e il suo input costa $0.042 per milione di token. Valutare 41 chunk di note a ogni passaggio significa 41 piccole chiamate per step. Con Jev è una frazione di centesimo. Con qualsiasi modello testuale, anche uno economico, sono 41 generazioni con i relativi costi di output e latenza.
Usa Haiku per le piccole modifiche, dove deve effettivamente scrivere codice. Usa Jev per scegliere dagli elenchi. Usa Opus per pensare. Ogni modello fa il lavoro per cui è stato costruito.
Come implementarlo senza rompere nulla
Non attivare tutte e quattro le decisioni contemporaneamente. Ecco l'ordine che seguirei.
Settimana 1: shadow mode. Mantieni il tuo agente attuale esattamente com'è. Per ogni decisione che prende, fai la stessa domanda anche a Jev e logga entrambe le risposte più la probabilità di Jev. Non agire in alcun modo sulla risposta di Jev.
1def shadow(decision_name, context, question, options, current_answer):2 probs = jev_choice(context, question, options)3 jev_answer = max(probs, key=probs.get)4 log_row(5 decision=decision_name,6 current=current_answer,7 jev=jev_answer,8 prob=probs[jev_answer],9 agree=(jev_answer == current_answer),10 )
Settimana 2: analizza i disaccordi. Guarda solo le righe in cui Jev e il tuo agente attuale hanno dato risposte diverse. Ordinale per probabilità di Jev. Di solito troverai una linea netta: sopra una certa probabilità, Jev ha ragione tanto spesso quanto Opus. Quella linea è la tua soglia. Quelle righe di disaccordo diventano anche il tuo test set, creato gratuitamente dal tuo traffico reale.
Settimana 3: attiva la selezione delle note. È la leva più grande e la più facile da annullare, dato che una nota mancante emerge rapidamente dai log.
Settimana 4: attiva recupero e test. Entrambi hanno limiti rigidi e fallback nel codice, quindi nel peggiore dei casi torni a fare quello che fai oggi.
Ultimo: il routing. Gli errori di routing sono i più visibili agli utenti, perché un task difficile mandato al worker veloce produce codice scadente. Attivalo per ultimo, con una soglia prudente, e monitora il tasso di fallimento sugli step del worker veloce.
Metti ogni decisione dietro un flag on/off così potrai annullarla con una sola riga di codice.
Impostare le soglie in base al rischio
Usare un'unica soglia per tutto è un errore. Impostale in base a cosa succede quando la risposta è sbagliata.
Una sessione di feature, stesso risultato: da $6.42 a $2.00
Rischio basso, facile da annullare: da 0.55 a 0.65. Selezione delle note. Ordinamento dei test. Una risposta sbagliata costa un po' di contesto o qualche secondo.
Rischio medio: 0.8. Routing e recupero. Una risposta sbagliata costa un passaggio fallito, che il tuo harness intercetta.
Rischio alto, difficile da annullare: 0.9 o mai. Cancellazione di file. Force push. Modifiche alla configurazione di produzione. Esecuzione di una migration. Il mio consiglio sincero: non lasciare che nessun modello prenda queste decisioni da solo. Instradale a un umano o, come minimo, a Opus con un passaggio di conferma.
Tutto ciò che sta sotto la soglia sale di livello: a Opus se serve ragionamento, a un umano se serve giudizio.
Quando questo approccio non aiuta
Questa architettura non è un moltiplicatore magico per ogni carico di lavoro.
I workload di pura generazione cambiano poco. Se il tuo agente passa la maggior parte del tempo a scrivere grandi quantità di codice nuovo partendo da specifiche chiare, non ci sono molte decisioni da spostare. Otterrai comunque il risparmio sulla selezione delle note, ma poco altro.
I piccoli progetti non ne hanno bisogno. Se l'intera cartella delle note pesa 2.000 token e la tua suite gira in otto secondi, l'overhead di costruzione non vale ancora la pena.
Jev non è eccezionale nel prendere la decisione finale da solo. È ottimo nel notare dettagli e nello scegliere da un elenco breve. Non è il modello ideale per rispondere a "questa pull request è pronta per il merge?" come singola domanda. Spezza le grandi domande in piccole, valuta ciascuna e combina i risultati nel tuo codice con i tuoi pesi.
Se hai già dati etichettati per una domanda fissa, un modello piccolo hostato da te può battere Jev sul prezzo. Jev brilla quando le domande cambiano continuamente e non hai dati di training, ovvero la situazione della maggior parte degli agenti di coding.
Gli errori che eviterei
Lasciare che il modello scriva l'elenco delle opzioni. L'intera architettura dipende da opzioni su cui il tuo codice può agire. Se un modello genera le opzioni, torni a dover parsare testo libero.
Chiedere a Jev se è sicuro. Leggi piuttosto la probabilità. Un'autovalutazione sarà quasi sempre un "sì".
Nessun fallback. Ogni decisione di Jev ha bisogno di un percorso per il "non sono sicuro", e quel percorso è Opus o un umano, mai un'ipotesi casuale.
Limiti di retry nel prompt invece che nel codice. Un modello a cui dici "riprova solo 3 volte" ogni tanto riproverà 30 volte. Il codice no.
Eliminare la suite di test completa. I controlli mirati ti velocizzano. La suite completa ti mantiene onesto. Tienili entrambi.
Non misurare nulla. Se non registri il costo per sessione prima di iniziare, non saprai mai se hai risparmiato il 20% o il 70%. Estrai prima i dati di utilizzo di una settimana di lavoro normale. Ci vogliono dieci minuti ed è l'unico numero che conta davvero.
Cosa fare questa settimana
Ecco tutto il processo sotto forma di checklist:
- Registra una settimana di sessioni dell'agente: passaggi, token, costi, errori.
- Individua le decisioni nascoste nel tuo loop: note, routing, recovery, test.
- Formula ciascuna come una domanda con un elenco fisso di opzioni.
- Esegui Jev in shadow mode affiancato al tuo agente attuale per una settimana.
- Imposta le soglie partendo dal log delle divergenze, in base al rischio.
- Attiva prima la selezione delle note, poi recovery e test, infine il routing.
- Confronta il costo per sessione prima e dopo. Quello è il tuo numero.
Opus 5.5 è il miglior modello di ragionamento che abbia mai usato per il codice. L'errore è pretendere che faccia anche tutto il resto.
Lascialo pensare. Lascia che sia Jev a decidere. Lascia che sia il tuo codice a comandare.
Se l'hai trovato utile, segui @cyrilXBT. Ogni settimana spiego nel dettaglio come sviluppare con i modelli AI più recenti, numeri reali alla mano.
Salva questo articolo nei preferiti: ti tornerà utile quando inizierai a costruire.
