Retour à tous les articles
Produit31 mars 202614 minute de lecture

Notes de version CodeCourier T1 2026 - tout ce qui a été livré en 90 jours

Notes de version CodeCourier T1 2026 : Workflow Builder v2, forking de personas, sprint chains, mises à niveau Contexts, SOC 2 Type II, 9 intégrations, 22 améliorations qualité.

Par Nico Jaroszewski
CodeCourier Founder

Bienvenue dans les notes de version CodeCourier T1 2026. Quatre-vingt-dix jours, 47 changements livrés, trois dépréciations, deux choses que nous avons retirées. Voici la mise à jour produit AI agent définitive du trimestre - chaque mise à jour significative du workflow builder, chaque amélioration du forking de personas, chaque capacité IA de sprint chain que nous avions promise dans le bilan du T4 2025, plus une longue traîne de travail de plateforme qui n'atteint pas la page d'accueil mais fait bouger les chiffres. Lisez-le de haut en bas, ou allez directement à la section qui compte pour votre équipe.

Le T1 a été notre plus gros trimestre en production brute et notre plus ennuyeux en récit. Nous n'avons pas pivoté. Nous n'avons rien renommé. Nous avons livré la feuille de route publiée en janvier, dans les délais, et les mises à jour de mémoire d'agent durable ont atterri sans un seul Sev-1. C'est le rapport.

1. TL;DR - les 10 principales livraisons en un coup d'œil

Si vous ne lisez rien d'autre, lisez ceci. Voici les dix changements les plus susceptibles de modifier la façon dont votre équipe utilise CodeCourier cette semaine.

  1. Workflow Builder v2 - branchement, étapes conditionnelles, et politiques de nouvelle tentative par nœud. Temps de rédaction en baisse de 51% dans la télémétrie client.
  2. Forking de personas - versionnage de type git pour chaque persona, avec promotion atomique et évaluation A/B côte à côte.
  3. Sprint Chains en GA - enchaînez jusqu'à 75 sessions de tickets sur un sprint avec ordonnancement des dépendances et portes de pause-pour-revue.
  4. Récupération Contexts v3 - 38% de meilleur recall@10 sur notre ensemble d'évaluation interne ; nouveaux index à portée projet et à portée persona.
  5. Issue Sessions asynchrones - déclenchez depuis GitHub, Linear, ou Jira et partez ; l'agent dépose une PR quand elle est prête.
  6. Démarrages à froid de sandbox à 220 ms - contre 380 ms (médiane), avec de nouveaux runtimes GPU (L4, A10G) en aperçu privé.
  7. SOC 2 Type II terminé - rapports disponibles pour les prospects entreprise sous NDA, résidence des données UE en direct à Francfort.
  8. Export de journal d'audit - diffusez chaque action de l'agent vers Splunk, Datadog, ou tout SIEM via un récepteur compatible S3.
  9. Neuf nouvelles intégrations - Linear, GitHub Issues, Jira, Slack, Sentry, PagerDuty, Notion, Vercel, et 1Password.
  10. Chronologie de relecture + vue des coûts - parcourez n'importe quelle exécution dans le temps et voyez la dépense par exécution, par workflow, par projet en un clic.

Le reste de cet article déballe chacun de ces points, renvoie vers la page produit où il vit, et se termine par ce que nous avons mis de côté et ce qui arrive au T2.

2. Workflow Builder v2 - branchement, conditions, nouvelles tentatives

Workflow Builder a reçu le plus d'attention de toute surface unique ce trimestre. Nous avons jeté l'ancien éditeur de nœuds et l'avons reconstruit de zéro autour de trois choses que les clients demandaient depuis le lancement : le branchement conditionnel, la nouvelle tentative d'erreur déclarative, et une histoire de débogage qui ne nécessite pas de lire du JSON.

Ce que nous avons livré

  • Étapes conditionnelles. Chaque nœud peut déclarer une expression de garde. Si la garde s'évalue à faux, l'étape est sautée et le workflow continue. Les gardes sont écrites dans un petit DSL typé - pas de Turing-complétude, pas de surface d'exécution de code à distance.
  • Branchement. Un nœud peut avoir plusieurs arêtes en aval avec des conditions mutuellement exclusives. La première arête correspondante gagne. Cela tue le pattern « dispatch par switch de chaîne » qui affligeait les workflows v1.
  • Politiques de nouvelle tentative par nœud. Configurez les tentatives, le backoff (constant, linéaire, exponentiel), la gigue, et quelles classes d'erreur déclenchent une nouvelle tentative. Par défaut : trois tentatives avec backoff exponentiel pour les erreurs d'outil transitoires et zéro nouvelle tentative pour les échecs d'assertion.
  • Aperçu de contexte en direct. Survolez n'importe quelle étape dans l'éditeur pour voir exactement quels Contexts seront chargés, combien de tokens ils consomment, et si le budget correspond au modèle choisi.
  • Surface d'échec qui s'explique elle-même. Quand une exécution échoue en plein milieu du workflow, le tableau de bord montre le nœud défaillant, les entrées qu'il a vues, les appels d'outils qu'il a effectués, et un bouton « relancer depuis ici » en un clic.

Pourquoi ça compte

Imaginez un workflow qui vérifie le lint, exécute des tests unitaires, exécute des tests d'intégration, et n'ouvre une PR que si les trois passent - mais si les tests d'intégration échouent avec une signature de test instable connue, il réessaie deux fois avant d'abandonner. En v1, vous écriviez cela comme quatre workflows enchaînés avec de la colle sur mesure. En v2, c'est un workflow avec trois gardes et une politique de nouvelle tentative. L'éditeur visuel exporte vers du JSON typé TypeScript, si bien qu'il vit dans votre dépôt, se relit dans des PR, et revient en arrière comme du code.

Comment l'utiliser

Ouvrez le Workflow Builder, cliquez sur Nouveau workflow, et commencez à déposer des nœuds. L'inspecteur de droite a maintenant des onglets pour Entrées, Gardes, Nouvelles tentatives, et Contexts. Les workflows v1 existants migrent automatiquement ; nous avons testé la migration sur plus de 1 200 workflows clients et n'avons vu aucune différence comportementale. Si votre migration produit un avertissement, l'inspecteur montre la ligne exacte et une correction suggérée.

3. Forking de personas - versionnage de type git pour les agents

Les personas ont grandi ce trimestre. Le forking de personas signifie que chaque persona a maintenant un historique complet avec des branches, des diffs, et une promotion atomique. Vous pouvez forker une persona, changer son system prompt ou son allowlist d'outils, exécuter un A/B en tête-à-tête contre votre ensemble de tâches de référence, et promouvoir le gagnant en un clic. Les anciennes sessions restent rejouables face à la version qui les a produites - plus de « pourquoi cette PR avait-elle l'air différente en février ? »

Ce que c'est, concrètement

  • Chaque persona a une branche main et des forks illimités.
  • Les forks peuvent modifier le prompt, les outils, le modèle, la température, la portée du contexte, et le comportement de nouvelle tentative.
  • Les exécutions A/B exécutent le même ensemble de tâches contre deux versions de persona en parallèle et produisent un tableau de bord (taux de réussite, coût par tâche, latence p95, qualité notée par relecteur si vous câblez le hook d'évaluation).
  • La promotion est atomique. Toutes les nouvelles sessions utilisent la version promue à partir du prochain tick. Les sessions en cours se terminent sur leur version d'origine.

Pourquoi ça compte

Ajuster une persona d'agent est itératif. Vous changez un system prompt, le livrez, le regrettez, revenez en arrière. Sans versionnage, « revenir en arrière » signifie retaper de mémoire ce que vous aviez la semaine dernière. Avec le forking, c'est un clic. Le gain non évident : les clients font tourner plusieurs variantes de persona en production pour différentes parties d'une base de code - persona de revue stricte sur le code d'authentification, persona rapide et souple sur les scripts internes - et le graphe de versions est comment ils gardent le fil.

Exemple

Un client Série B maintient quatre forks de sa persona backend : main (production), strict-types (impose un TypeScript plus strict), perf-mode (ajoute une étape de benchmarking), et experimental (essaie un modèle plus récent). Ils promeuvent strict-types dans main toutes les deux semaines si le tableau de bord d'évaluation bat main de plus de 3% en qualité et fait match nul en coût. Cette cadence fait maintenant partie de leurs rituels d'ingénierie.

4. Sprint Chains - enchaîner des sessions de tickets sur un sprint

Sprint Chains est devenu généralement disponible le 18 février. Alimentez CodeCourier avec un plan de projet - généralement un document markdown décrivant un corpus de travail multi-tickets - et il le décompose en une séquence ordonnée d'Issue Sessions avec les dépendances respectées, l'état transmis vers l'avant, et les portes de revue humaine honorées. Pause quand une étape ouvre une PR, reprend après le merge.

Ce qui a changé au T1

  • Longueur maximale de chaîne portée à 75 tickets (contre 20 en bêta). Deux clients ont exécuté des chaînes de plus de 50 tickets de bout en bout sans intervention.
  • Analyseur de dépendances. Le planificateur de chaîne lit maintenant votre plan markdown, détecte les références bloque / dépend-de, et construit un vrai DAG.
  • Retour en arrière en milieu de chaîne. Si le ticket 14 sur 30 échoue, vous pouvez revenir en arrière sur les tickets 11 à 14 et reprendre à partir de 11 sans perdre les 10 premiers.
  • Plafond de coût au niveau de la chaîne. Fixez un budget ; la chaîne se met en pause pour approbation si elle menace de le dépasser.

Pourquoi ça compte

La plupart du vrai travail d'ingénierie n'est pas un seul ticket. C'est un sprint - cinq à vingt pièces connectées. Sprint Chains permet à un agent d'opérer à cette échelle sans perdre le fil à mi-chemin. La chaîne la plus longue que nous ayons vu s'exécuter avec succès en production comptait 67 tickets, 11 heures de temps d'agent cumulé, 23 PR mergées. Ce client l'a décrite comme « un développeur junior qui n'oublie jamais le plan ».

5. Mises à niveau Contexts - récupération, portée, évaluations

Contexts est la façon dont CodeCourier charge le bon code, la bonne documentation, et les bonnes conventions dans une session sans faire exploser le budget de tokens. Le T1 a apporté trois mises à jour de mémoire d'agent durable : une meilleure récupération, une portée plus étroite, et un vrai cadre d'évaluation.

Récupération

Nous avons reconstruit le récupérateur hybride. BM25 + embeddings denses + un petit reranker entraîné sur des paires de pertinence étiquetées par les clients. Le recall@10 sur notre ensemble d'évaluation interne s'est amélioré de 38%. La latence de récupération p95 est passée de 410 ms à 240 ms malgré le reranker, parce que nous avons déplacé l'index d'un disque générique vers du NVMe et resserré le fan-out.

Portée

Les Contexts peuvent maintenant être délimités à trois niveaux : organisation, projet, et persona. Un Context à portée persona ne se charge que pour les sessions lancées par cette persona. Un Context à portée projet est partagé entre les personas travaillant dans le même dépôt. Cela tue l'ancien mode d'échec où un Context d'équipe sécurité fuyait dans une session frontend et poussait le modèle vers des suggestions CSS paranoïaques.

Cadre d'évaluation

Chaque Context a maintenant un ensemble d'évaluation attaché. Vous définissez des récupérations de référence - « pour la requête X, le document Y devrait apparaître dans le top 5 » - et la CI les exécute à chaque changement de Context. Le tableau de bord montre le taux de réussite dans le temps, si bien qu'un Context qui régresse silencieusement après une actualisation de documentation est attrapé avant d'être livré. C'est la fonctionnalité la plus demandée du sondage client de novembre 2025.

6. Issue Sessions - nouveaux déclencheurs et mode asynchrone

Issue Sessions a gagné trois nouveaux déclencheurs et un mode d'exécution fondamentalement différent.

  • Déclencheur GitHub Issues. Étiquetez un ticket avec codecourier:run (configurable) et une session démarre. La persona est choisie par routage d'étiquette, par ex. persona:backend.
  • Déclencheur Linear. Synchronisation bidirectionnelle native. Les mises à jour de statut refluent vers Linear pour que les chefs de produit voient la progression sans ouvrir notre tableau de bord.
  • Déclencheur Jira. Celui que les clients réclamaient. Même forme que Linear : déclencheurs d'étiquette ou de transition, synchronisation de statut bidirectionnelle.
  • Mode asynchrone. Déclenchez une Issue Session, obtenez un ID de session, et partez. L'agent ouvre une PR (ou pose une question de clarification sur le ticket) quand il a terminé. Pas de websocket longue durée, pas d'onglet « est-ce que ça tourne encore » à surveiller.

Pourquoi l'asynchrone compte

Dans notre télémétrie, la session de tickets médiane prend 17 minutes et le p95 en prend 73. Demander à des humains de rester assis dans un onglet pendant 73 minutes n'est pas envisageable. Le mode asynchrone signifie qu'un TPM peut déposer 12 tickets lundi matin, aller au standup, revenir, et trier les PR résultantes. Temps total humain : peut-être 30 minutes de tri pour 12 tickets de travail.

7. Sandboxes - démarrages à froid, runtimes, GPU

Les Sandboxes sont les VM isolées où chaque action de l'agent s'exécute. Le T1 a été un trimestre de performance et d'étendue.

MétriqueT4 2025T1 2026Changement
Démarrage à froid médian (ms)380220-42%
Démarrage à froid p95 (ms)1 180640-46%
Sandboxes parallèles (Pro)824+200%
Régions disponibles35+2 (Francfort, Tokyo)
Runtimes disponibles914+5 (dont GPU)

Les nouveaux runtimes incluent Python 3.13, Node 22 LTS, Bun 1.2, Deno 2.1, et deux modèles GPU (L4 et A10G) en aperçu privé pour les clients exécutant de l'inférence de modèle sur sandbox, du travail d'image, ou des tâches d'entraînement ML. Les instantanés de système de fichiers sont maintenant incrémentiels, si bien qu'une sandbox clonée depuis un modèle chaud démarre en 60 à 90 ms dans notre région la plus fréquentée.

8. Sécurité et conformité - SOC 2, RGPD, journaux d'audit

La conformité est une fonctionnalité pour tous ceux qui doivent remplir un questionnaire d'approvisionnement. Nous y avons investi.

  • Audit SOC 2 Type II terminé en février. Rapport disponible sous NDA via /soc2.
  • Résidence des données UE à Francfort. Définissez-la sur le projet et chaque sandbox, journal de session, et index Context pour ce projet reste dans la région. Détails sur /gdpr et notre page sécurité de haut niveau.
  • Export de journal d'audit. Chaque action de l'agent - appel d'outil, écriture de fichier, ouverture de PR, lecture de secret - est diffusée vers votre SIEM. Formateurs intégrés pour Splunk et Datadog ; tous les autres reçoivent du JSON en lignes vers un récepteur compatible S3.
  • Clés gérées par le client pour le chiffrement au repos sur Enterprise. Apportez votre propre KMS.
  • Exécuteurs de sandbox auto-hébergés en aperçu privé. Faites tourner notre orchestrateur contre des sandboxes que vous possédez, dans votre VPC.

Nous ne sommes pas une entreprise de conformité. Nous sommes une entreprise de produit qui traite la conformité comme un prérequis. SOC 2 Type II est le plancher, pas le plafond.

9. Intégrations - neuf nouvelles, nommées

Les intégrations de développement IA sont la façon dont CodeCourier s'intègre à la manière dont votre équipe travaille déjà. Le T1 en a ajouté neuf, avec une brève note pour chacune.

  1. Linear. Synchronisation bidirectionnelle native, routage par étiquette, miroir de statut.
  2. GitHub Issues. Sessions déclenchées par étiquette, références arrière de PR, merge conscient de la protection de branche.
  3. Jira. Synchronisation bidirectionnelle ; prend en charge à la fois Cloud et Data Center.
  4. Slack. Notifications de statut d'exécution, commandes slash, allowlists de personas à portée de canal.
  5. Sentry. Exception vers session : prenez un ticket Sentry, générez une session CodeCourier préchargée avec la trace de pile et les erreurs récentes connexes.
  6. PagerDuty. Alerte d'astreinte quand une chaîne rencontre une erreur fatale en cours d'exécution et qu'aucun humain n'est en ligne.
  7. Notion. Extrayez des documents de plan depuis Notion comme entrées de Sprint Chain ; repoussez les résumés d'exécution comme commentaires.
  8. Vercel. Sessions conscientes du déploiement de prévisualisation ; l'agent peut lire votre URL de prévisualisation et faire des assertions contre elle avant d'ouvrir une PR.
  9. 1Password. Secrets récupérés à l'exécution ; rien n'atterrit jamais dans notre base de données ou dans un fichier d'environnement de sandbox.

10. Petites victoires - la longue traîne

Vingt-deux améliorations mineures qui font que le produit se sent moins comme une bêta. Sans ordre particulier :

  • Raccourcis clavier partout ; ? affiche l'aide-mémoire.
  • Mode sombre pour le tableau de bord, persisté par utilisateur.
  • Meilleurs états vides avec un flux « créer un exemple » en un clic.
  • Changement de projet plus rapide (cmd-K, correspondance floue, 12 ms p95).
  • Boutons de copie de lien sur chaque ressource partageable.
  • Vue de suivi d'exécution adaptée au mobile.
  • Traces de pile cliquables dans les journaux d'exécution.
  • Relance en un clic depuis n'importe quelle session passée.
  • État de filtre persistant dans la vue des tickets.
  • Notifications plus discrètes pour les exécutions que vous avez démarrées vous-même.
  • Imports de workflow depuis une URL publique.
  • Surcharge de température par persona.
  • Vue de diff en ligne sur les étapes d'ouverture de PR.
  • Archivage en masse pour les anciennes sessions.
  • Vue des coûts filtrable par étiquette.
  • Nouvelles tentatives de webhook avec backoff exponentiel.
  • En-têtes de limite de débit API documentés et cohérents.
  • Les breadcrumbs Sentry incluent le nom du nœud de workflow.
  • Application OAuth prête pour la revue pour les marketplaces Slack et Linear.
  • La page de statut reflète maintenant la santé par région, pas seulement globale.
  • Page analytics publique pour le taux de réussite et la latence à l'échelle de la plateforme.
  • Hub de guides public avec 14 nouvelles visites guidées.

11. Ce que nous avons mis de côté - mode honnête

Nous avons essayé des choses qui n'ont pas fonctionné. Les signaler nous garde honnêtes.

  • Sessions pilotées par la voix. Nous avons prototypé une interface vocale pour démarrer des Issue Sessions. La latence allait bien, la précision sur le jargon technique non. Bêta retirée en février. Nous y reviendrons quand la transcription sur appareil s'améliorera.
  • Place de marché de personas inter-organisations. Nous pensions que les clients voudraient partager des personas publiquement. La bêta fermée a eu 14 inscriptions et trois personas partagées après un mois. Mise de côté. Les personas, il s'avère, sont profondément liées à la culture d'une base de code et voyagent mal.
  • Visites guidées vidéo dans le produit. Nous avons ajouté des vidéos de 90 secondes aux états vides. Les clients nous ont dit qu'elles étaient agaçantes. Nous les avons retirées et avons mis le budget dans le hub guides.

12. Ce qui arrive au T2

Deux thèmes pour le T2 2026 :

  1. Agents de revue. Des personas conçues spécifiquement pour la revue de PR, avec une mémoire des standards de votre équipe. Objectif : aperçu privé en mai.
  2. Collaboration multi-agents. Transfert structuré entre personas spécialistes - planificateur vers codeur vers relecteur vers critique - à l'intérieur d'une seule sandbox, avec des Contexts partagés et une piste d'audit commune.

Plus davantage de la même excellence ennuyeuse : sandboxes plus rapides, meilleure récupération Contexts, plus d'intégrations. Les victoires composées peu sexy sont ce qui rend un produit inévitable.

FAQ

Comment mettre à niveau vers Workflow Builder v2 ?

Vous n'avez pas besoin de le faire. Les nouveaux workflows utilisent v2 par défaut ; les anciens workflows migrent automatiquement la première fois que vous les ouvrez dans l'éditeur. Il n'y a aucun changement cassant pour le runtime - les workflows de forme v1 continuent de s'exécuter identiquement.

Le forking de personas est-il disponible sur tous les paliers ?

Oui. Free, Pro, et Enterprise obtiennent tous des forks illimités et une promotion atomique. Les exécutions d'évaluation A/B comptent dans votre quota de sessions mensuel sur Free et Pro ; Enterprise est sans plafond.

Quelle est la longueur maximale d'une Sprint Chain ?

75 tickets pour le moment. Nous n'avons pas vu de plan client réel dépasser cela, mais si vous en avez un, contactez-nous - nous aimerions tester contre lui.

Proposez-vous des déploiements exclusivement UE ?

Oui. Définissez la région du projet sur Francfort et chaque sandbox, journal de session, et index Context vit dans la région. L'audit SOC 2 Type II couvre le plan UE. Voyez /gdpr pour le diagramme complet de flux de données.

Comment exporter mes journaux d'audit ?

Paramètres → Conformité → Export du journal d'audit. Choisissez Splunk, Datadog, ou un récepteur générique compatible S3. Les journaux sont diffusés en quelques secondes après chaque action de l'agent.

Qu'est-il arrivé à l'ancien endpoint REST pour déclencher des exécutions ?

Supprimé le 15 mars 2026, après une fenêtre de dépréciation de 90 jours annoncée en décembre 2025. Utilisez le nouvel endpoint documenté dans la référence API. La migration tient en une ligne.

Où signaler un bug ou demander une fonctionnalité ?

Chemin le plus simple : contactez-nous, ou ouvrez un ticket public sur notre feuille de route. Chaque livraison du T1 dans cet article remonte à une demande client des 6 mois précédents. La feuille de route est la vôtre.

Merci d'avoir lu. Si cela vous a été utile, le reste de nos écrits vit sur le blog, et le produit lui-même est sur codecourier. Rendez-vous à la fin du T2.

Nico Jaroszewski
CodeCourier Founder
Balises
#changelog#notes-de-version#mise-a-jour-produit#workflow-builder#forking-persona#sprint-chains#contexts#integrations#soc2#roadmap
Partager

Continuez à lire

Gratuit pendant 14 jours · pas de carte de crédit

Embauchez votre premier ingénieur IA.
Expédier avant l'heure du déjeuner.

5 minutes pour embarquer. Premier PR dans l'heure. Annulez à tout moment.