Note di rilascio CodeCourier T1 2026 - tutto quello che abbiamo spedito in 90 giorni

Benvenuti alle note di rilascio CodeCourier T1 2026. Novanta giorni, 47 modifiche spedite, tre deprecazioni, due cose che abbiamo ritirato. Questo è l'aggiornamento di prodotto AI agent definitivo del trimestre - ogni aggiornamento significativo del workflow builder, ogni miglioramento del forking delle persona, ogni capacità IA di sprint chain che avevamo promesso nel riepilogo del T4 2025, più una lunga coda di lavoro sulla piattaforma che non arriva sulla homepage ma muove i numeri. Leggilo dall'inizio alla fine, o salta alla sezione che conta per il tuo team.

Il T1 è stato il nostro trimestre più grande per output grezzo e il più noioso per narrazione. Non abbiamo pivotato. Non abbiamo rinominato nulla. Abbiamo spedito la roadmap pubblicata a gennaio, nei tempi previsti, e gli aggiornamenti di memoria durevole dell'agente sono atterrati senza un singolo Sev-1. Questo è il resoconto.

1. TL;DR - le prime 10 spedizioni a colpo d'occhio

Se non leggi altro, leggi questo. Questi sono i dieci cambiamenti più probabili a modificare come il tuo team usa CodeCourier questa settimana.

1. Workflow Builder v2 - branching, passaggi condizionali, e policy di retry per nodo. Tempo di scrittura sceso del 51% nella telemetria clienti.
2. Forking delle persona - versionamento in stile git per ogni persona, con promozione atomica e valutazione A/B fianco a fianco.
3. Sprint Chains GA - concatena fino a 75 sessioni di issue in uno sprint con ordinamento delle dipendenze e gate pausa-alla-revisione.
4. Retrieval Contexts v3 - 38% di recall@10 migliore sul nostro set di valutazione interno; nuovi indici con ambito progetto e ambito persona.
5. Issue Sessions asincrone - avvia da GitHub, Linear, o Jira e allontanati; l'agente apre una PR quando è pronta.
6. Avvii a freddo della sandbox a 220 ms - in calo da 380 ms (mediana), con nuovi runtime GPU (L4, A10G) in anteprima privata.
7. SOC 2 Type II completato - report disponibili per i prospect enterprise sotto NDA, residenza dati UE attiva a Francoforte.
8. Esportazione log di audit - trasmetti ogni azione dell'agente a Splunk, Datadog, o qualsiasi SIEM tramite sink compatibile S3.
9. Nove nuove integrazioni - Linear, GitHub Issues, Jira, Slack, Sentry, PagerDuty, Notion, Vercel, e 1Password.
10. Timeline di replay + vista costi - scorri qualsiasi esecuzione nel tempo e vedi la spesa per esecuzione, per workflow, per progetto con un clic.

Il resto di questo articolo scompone ciascuno di questi punti, rimanda alla pagina prodotto dove vive, e finisce con ciò che abbiamo accantonato e cosa arriva nel T2.

2. Workflow Builder v2 - branching, condizioni, retry

Il Workflow Builder ha ricevuto più attenzione di qualsiasi altra superficie singola questo trimestre. Abbiamo buttato via il vecchio editor di nodi e lo abbiamo ricostruito da zero attorno a tre cose che i clienti chiedevano dal lancio: branching condizionale, retry di errore dichiarativo, e una storia di debug che non richiede di leggere JSON.

Cosa abbiamo spedito

• Passaggi condizionali. Ogni nodo può dichiarare un'espressione guard. Se la guard valuta falso, il passaggio viene saltato e il workflow continua. Le guard sono scritte in un piccolo DSL tipizzato - nessuna Turing-completezza, nessuna superficie di esecuzione di codice remoto.
• Branching. Un nodo può avere più archi in uscita con condizioni mutuamente esclusive. Il primo arco corrispondente vince. Questo uccide il pattern "dispatch per switch di stringa" che affliggeva i workflow v1.
• Policy di retry per nodo. Configura tentativi, backoff (costante, lineare, esponenziale), jitter, e quali classi di errore innescano il retry. Il default è tre tentativi con backoff esponenziale per errori di strumento transitori e zero retry per fallimenti di assertion.
• Anteprima contesto dal vivo. Passa il mouse su qualsiasi passaggio nell'editor per vedere esattamente quali Contexts verranno caricati, quanti token consumano, e se il budget si adatta al modello scelto.
• Superficie di fallimento che si spiega da sola. Quando un'esecuzione fallisce a metà del workflow, la dashboard mostra il nodo fallito, gli input che ha visto, le chiamate a strumenti che ha fatto, e un pulsante "riesegui da qui" con un clic.

Perché conta

Immagina un workflow che fa lint, esegue test unitari, esegue test di integrazione, e apre una PR solo se tutti e tre passano - ma se i test di integrazione falliscono con una firma di test instabile nota, riprova due volte prima di arrendersi. In v1 scrivevi questo come quattro workflow concatenati con collante su misura. In v2 è un workflow con tre guard e una policy di retry. L'editor visuale esporta verso JSON tipizzato TypeScript, quindi vive nel tuo repo, viene revisionato nelle PR, e torna indietro come codice.

Come usarlo

Apri il Workflow Builder, clicca su Nuovo workflow, e inizia a trascinare nodi. L'ispettore a destra ora ha tab per Input, Guard, Retry, e Contexts. I workflow v1 esistenti migrano automaticamente; abbiamo testato la migrazione su oltre 1.200 workflow clienti e visto zero differenze comportamentali. Se la tua migrazione produce un avviso, l'ispettore mostra la riga esatta e una correzione suggerita.

3. Forking delle persona - versionamento in stile git per gli agenti

Le persona sono cresciute questo trimestre. Il forking delle persona significa che ogni persona ha ora una cronologia completa con branch, diff, e promozione atomica. Puoi forkare una persona, cambiare il suo system prompt o la sua allowlist di strumenti, eseguire un A/B testa a testa contro il tuo set di task di riferimento, e promuovere il vincitore con un clic. Le vecchie sessioni restano ripercorribili rispetto alla versione che le ha prodotte - basta con "perché questa PR sembrava diversa a febbraio?"

Cos'è, concretamente

• Ogni persona ha un branch main e fork illimitati.
• I fork possono modificare prompt, strumenti, modello, temperatura, ambito del contesto, e comportamento di retry.
• Le esecuzioni A/B eseguono lo stesso set di task contro due versioni di persona in parallelo e producono una scheda di valutazione (tasso di successo, costo per task, latenza p95, qualità valutata dal revisore se colleghi l'hook di eval).
• La promozione è atomica. Tutte le nuove sessioni usano la versione promossa a partire dal prossimo tick. Le sessioni in corso si completano sulla loro versione originale.

Perché conta

Regolare una persona di agente è iterativo. Cambi un system prompt, spedisci, te ne penti, torni indietro. Senza versionamento, "tornare indietro" significa riscrivere a memoria cosa avevi la settimana scorsa. Con il forking, è un clic. Il vantaggio non ovvio: i clienti fanno girare più varianti di persona in produzione per parti diverse di una codebase - persona di revisione rigorosa sul codice di autenticazione, persona veloce e permissiva sugli script interni - e il grafo delle versioni è come tengono traccia.

Esempio

Un cliente Serie B mantiene quattro fork della sua persona backend: main (produzione), strict-types (impone TypeScript più rigoroso), perf-mode (aggiunge un passaggio di benchmarking), e experimental (prova un modello più recente). Promuovono strict-types in main ogni due settimane se la scheda di valutazione batte main di oltre il 3% in qualità e pareggia sul costo. Questa cadenza è ora parte dei loro rituali di ingegneria.

4. Sprint Chains - concatenare sessioni di issue lungo uno sprint

Sprint Chains è diventato generalmente disponibile il 18 febbraio. Alimenta CodeCourier con un piano di progetto - di solito un documento markdown che descrive un corpo di lavoro multi-issue - e lo scompone in una sequenza ordinata di Issue Sessions con le dipendenze rispettate, lo stato passato in avanti, e i gate di revisione umana onorati. Si mette in pausa quando un passaggio apre una PR, riprende dopo il merge.

Cosa è cambiato nel T1

• Lunghezza massima della chain aumentata a 75 issue (era 20 in beta). Due clienti hanno eseguito chain di oltre 50 issue end-to-end senza intervento.
• Parser delle dipendenze. Il pianificatore della chain ora legge il tuo piano markdown, rileva riferimenti blocks / depends-on, e costruisce un vero DAG.
• Rollback a metà chain. Se l'issue 14 di 30 fallisce, puoi tornare indietro sugli issue 11-14 e riprendere da 11 senza perdere i primi 10.
• Tetto di costo a livello di chain. Imposta un budget; la chain si mette in pausa per approvazione se minaccia di superarlo.

Perché conta

La maggior parte del vero lavoro di ingegneria non è un singolo issue. È uno sprint - da cinque a venti pezzi collegati. Sprint Chains permette a un agente di operare a quella scala senza perdere il filo a metà strada. La chain più lunga che abbiamo visto funzionare con successo in produzione era di 67 issue, 11 ore di tempo agente cumulativo, 23 PR mergiate. Quel cliente l'ha descritta come "uno sviluppatore junior che non dimentica mai il piano".

5. Aggiornamenti Contexts - retrieval, ambito, eval

Contexts è il modo in cui CodeCourier carica il codice giusto, la documentazione, e le convenzioni in una sessione senza far esplodere il budget di token. Il T1 ha portato tre aggiornamenti di memoria durevole dell'agente: retrieval migliore, ambito più stretto, e un vero framework di valutazione.

Retrieval

Abbiamo ricostruito il retriever ibrido. BM25 + embedding densi + un piccolo reranker addestrato su coppie di rilevanza etichettate dai clienti. Il recall@10 sul nostro set di valutazione interno è migliorato del 38%. La latenza di retrieval p95 è scesa da 410 ms a 240 ms nonostante il reranker, perché abbiamo spostato l'indice da disco generico a NVMe e stretto il fan-out.

Ambito

I Contexts ora possono avere ambito a tre livelli: org, progetto, e persona. Un Context con ambito persona si carica solo per le sessioni avviate da quella persona. Un Context con ambito progetto è condiviso tra le persona che lavorano nello stesso repo. Questo uccide la vecchia modalità di fallimento in cui un Context del team di sicurezza filtrava in una sessione frontend e spingeva il modello verso suggerimenti CSS paranoici.

Framework di valutazione

Ogni Context ora ha un set di eval associato. Definisci retrieval di riferimento - "per la query X, il documento Y dovrebbe apparire nei primi 5" - e la CI li esegue a ogni modifica del Context. La dashboard mostra il tasso di successo nel tempo, così un Context che regredisce silenziosamente dopo un refresh della documentazione viene catturato prima di essere spedito. Questa è la feature più richiesta dal sondaggio clienti di novembre 2025.

6. Issue Sessions - nuovi trigger e modalità asincrona

Le Issue Sessions hanno guadagnato tre nuovi trigger e una modalità di esecuzione fondamentalmente diversa.

• Trigger GitHub Issues. Etichetta un issue con codecourier:run (configurabile) e una sessione viene generata. La persona viene scelta tramite instradamento per etichetta, es. persona:backend.
• Trigger Linear. Sincronizzazione bidirezionale nativa. Gli aggiornamenti di stato rifluiscono verso Linear così i PM vedono i progressi senza aprire la nostra dashboard.
• Trigger Jira. Quello che i clienti imploravano. Stessa forma di Linear: trigger per etichetta o transizione, sincronizzazione di stato bidirezionale.
• Modalità asincrona. Avvia una Issue Session, ottieni un ID sessione, e allontanati. L'agente apre una PR (o fa una domanda di chiarimento sull'issue) quando ha finito. Nessun websocket di lunga durata, nessuna scheda "sta ancora girando" da sorvegliare.

Perché l'asincrono conta

Nella nostra telemetria, la Issue Session mediana impiega 17 minuti e il p95 ne impiega 73. Chiedere agli umani di restare seduti in una scheda per 73 minuti non è praticabile. La modalità asincrona significa che un TPM può depositare 12 issue lunedì mattina, andare allo standup, tornare, e smistare le PR risultanti. Tempo totale sul lato umano: forse 30 minuti di smistamento per 12 issue di lavoro.

7. Sandbox - avvii a freddo, runtime, GPU

Le Sandbox sono le VM isolate dove gira ogni azione dell'agente. Il T1 è stato un trimestre di prestazioni e ampiezza.

Metrica	T4 2025	T1 2026	Variazione
Avvio a freddo mediano (ms)	380	220	-42%
Avvio a freddo p95 (ms)	1.180	640	-46%
Sandbox parallele (Pro)	8	24	+200%
Regioni disponibili	3	5	+2 (Francoforte, Tokyo)
Runtime disponibili	9	14	+5 (incl. GPU)

I nuovi runtime includono Python 3.13, Node 22 LTS, Bun 1.2, Deno 2.1, e due template GPU (L4 e A10G) in anteprima privata per i clienti che eseguono inferenza di modello su sandbox, lavoro sulle immagini, o job di training ML. Gli snapshot del filesystem ora sono incrementali, così una sandbox clonata da un template caldo si avvia in 60-90 ms nella nostra regione più attiva.

8. Sicurezza e conformità - SOC 2, GDPR, log di audit

La conformità è una feature per chiunque debba compilare un questionario di procurement. Ci abbiamo investito.

• Audit SOC 2 Type II completato a febbraio. Report disponibile sotto NDA tramite /soc2.
• Residenza dati UE a Francoforte. Impostala sul progetto e ogni sandbox, log di sessione, e indice Context per quel progetto resta nella regione. Dettagli su /gdpr e la nostra pagina sicurezza di alto livello.
• Esportazione log di audit. Ogni azione dell'agente - chiamata a strumento, scrittura file, apertura PR, lettura segreto - viene trasmessa al tuo SIEM. Formattatori integrati per Splunk e Datadog; tutti gli altri ricevono JSON con newline verso un sink compatibile S3.
• Chiavi gestite dal cliente per la crittografia a riposo su Enterprise. Porta il tuo KMS.
• Runner sandbox self-hosted in anteprima privata. Esegui il nostro orchestratore contro sandbox che possiedi, nel tuo VPC.

Non siamo un'azienda di conformità. Siamo un'azienda di prodotto che tratta la conformità come un requisito minimo. SOC 2 Type II è il pavimento, non il soffitto.

9. Integrazioni - nove nuove, nominate

Le integrazioni AI dev sono il modo in cui CodeCourier diventa parte di come il tuo team già lavora. Il T1 ne ha aggiunte nove, con una breve nota per ciascuna.

1. Linear. Sincronizzazione bidirezionale nativa, instradamento per etichetta, specchiatura dello stato.
2. GitHub Issues. Sessioni attivate da etichetta, riferimenti inversi alle PR, merge consapevole della protezione dei branch.
3. Jira. Sincronizzazione bidirezionale; supporta sia Cloud che Data Center.
4. Slack. Notifiche di stato dell'esecuzione, slash command, allowlist di persona con ambito canale.
5. Sentry. Da eccezione a sessione: prendi un issue Sentry, genera una sessione CodeCourier precaricata con stack trace ed errori recenti correlati.
6. PagerDuty. Paging di reperibilità quando una chain incontra un errore fatale a metà esecuzione e nessun umano è online.
7. Notion. Estrai documenti di piano da Notion come input di Sprint Chain; rispedisci i riassunti di esecuzione come commenti.
8. Vercel. Sessioni consapevoli del deploy di anteprima; l'agente può leggere il tuo URL di anteprima e fare asserzioni contro di esso prima di aprire una PR.
9. 1Password. Segreti recuperati a runtime; nulla atterra mai nel nostro database o in un file env della sandbox.

10. Vittorie minori - la lunga coda

Ventidue miglioramenti minori che fanno sentire il prodotto meno come una beta. Senza un ordine particolare:

• Scorciatoie da tastiera ovunque; ? mostra il foglio dei trucchi.
• Modalità scura per la dashboard, persistita per utente.
• Stati vuoti migliori con un flusso "crea esempio" con un clic.
• Cambio progetto più veloce (cmd-K, corrispondenza fuzzy, 12 ms p95).
• Pulsanti copia-link su ogni risorsa condivisibile.
• Vista di monitoraggio esecuzioni adatta al mobile.
• Stack trace cliccabili nei log di esecuzione.
• Riesecuzione con un clic da qualsiasi sessione passata.
• Stato dei filtri persistente nella vista degli issue.
• Notifiche più silenziose per le esecuzioni che hai avviato tu stesso.
• Import di workflow da un URL pubblico.
• Override della temperatura per persona.
• Vista diff inline sui passaggi di apertura PR.
• Archiviazione in blocco per le vecchie sessioni.
• Vista costi filtrabile per tag.
• Retry dei webhook con backoff esponenziale.
• Header di rate limit API documentati e coerenti.
• I breadcrumb Sentry includono il nome del nodo del workflow.
• App OAuth pronta per la revisione per i marketplace Slack e Linear.
• La pagina di stato ora riflette la salute per regione, non solo globale.
• Pagina analytics pubblica per il tasso di successo e la latenza a livello di piattaforma.
• Hub guide pubblico con 14 nuove guide passo passo.

11. Cosa abbiamo accantonato - modalità onesta

Abbiamo provato cose che non hanno funzionato. Segnalarle ci mantiene onesti.

• Sessioni guidate dalla voce. Abbiamo prototipato un'interfaccia vocale per avviare Issue Sessions. La latenza andava bene, la precisione sul gergo tecnico no. Beta ritirata a febbraio. La riprenderemo quando la trascrizione on-device migliorerà.
• Marketplace di persona cross-org. Pensavamo che i clienti avrebbero voluto condividere persona pubblicamente. La beta chiusa ha avuto 14 iscrizioni e tre persona condivise dopo un mese. L'abbiamo accantonata. Le persona, si scopre, sono profondamente legate alla cultura di una codebase e viaggiano male.
• Guide video nel prodotto. Abbiamo aggiunto video di 90 secondi agli stati vuoti. I clienti ci hanno detto che erano fastidiosi. Li abbiamo ritirati e messo il budget nell'hub guide.

12. Cosa arriva nel T2

Due temi per il T2 2026:

1. Agenti di revisione. Persona costruite appositamente per la revisione delle PR, con una memoria degli standard del tuo team. Obiettivo: anteprima privata a maggio.
2. Collaborazione multi-agente. Passaggio strutturato tra persona specialiste - pianificatore a programmatore a revisore a critico - all'interno di una singola sandbox, con Contexts condivisi e una traccia di audit comune.

Più altro della stessa eccellenza noiosa: sandbox più veloci, retrieval Contexts migliore, più integrazioni. Le vittorie composte non sexy sono ciò che fa sembrare un prodotto inevitabile.

FAQ

Come faccio l'upgrade a Workflow Builder v2?

Non devi fare nulla. I nuovi workflow usano v2 per default; i vecchi workflow migrano automaticamente la prima volta che li apri nell'editor. Non c'è nessun breaking change per il runtime - i workflow in forma v1 continuano a essere eseguiti in modo identico.

Il forking delle persona è disponibile su tutti i piani?

Sì. Free, Pro, ed Enterprise ottengono tutti fork illimitati e promozione atomica. Le esecuzioni di valutazione A/B contano nella tua quota mensile di sessioni su Free e Pro; Enterprise è senza limite.

Qual è la lunghezza massima di una Sprint Chain?

Al momento 75 issue. Non abbiamo ancora visto un piano cliente reale superare questo limite, ma se ne hai uno, mettiti in contatto - vorremmo testare contro di esso.

Offrite deployment solo UE?

Sì. Imposta la regione del progetto su Francoforte e ogni sandbox, log di sessione, e indice Context vive nella regione. L'audit SOC 2 Type II copre il piano UE. Vedi /gdpr per il diagramma completo del flusso dati.

Come esporto i miei log di audit?

Impostazioni → Conformità → Esportazione log di audit. Scegli Splunk, Datadog, o un sink generico compatibile S3. I log vengono trasmessi entro secondi da ogni azione dell'agente.

Cosa è successo al vecchio endpoint REST per attivare le esecuzioni?

Rimosso il 15 marzo 2026, dopo una finestra di deprecazione di 90 giorni annunciata a dicembre 2025. Usa il nuovo endpoint documentato nel riferimento API. La migrazione è una riga.

Dove segnalo un bug o richiedo una feature?

Il percorso più facile: contattaci, o apri un issue pubblico sulla nostra roadmap. Ogni rilascio del T1 in questo articolo risale a una richiesta cliente degli ultimi 6 mesi. La roadmap è vostra.

Grazie per aver letto. Se questo è stato utile, il resto dei nostri scritti vive sul blog, e il prodotto stesso è su codecourier. Ci vediamo alla fine del T2.