Slides from a talk by François Delbrayelle, Lead Software Engineer @ Kestra — github.com/fdelbrayelle · linkedin.com/in/fdelbrayelle
📥 Download DevLille 2026 slides (PDF) · 🎬 Watch the talk (YouTube) · 🎬 See the demo
- CFP
- Slide 1 — Title
- Slide 2 — What is a workflow?
- Slide 3 — What is orchestration?
- Slide 4 — Audience question
- Slide 5 — Modern orchestration is broken
- Slide 6 — Nice to meet you!
- Slide 7 — What is Kestra?
- Slide 8 — What is Kestra? (by the numbers)
- Slide 9 — Why Kestra is so unique?
- Slide 10 — One Platform, Infinite Use Cases
- Slide 11 — Built for Every Team
- Slide 12 — What is a plugin?
- Slide 13 — Plugins
- Slide 14 — AI Maturity Level
- Slide 15 — « Talk is cheap. Show me the code. »
- Slide 16 — « Code is cheap. Show me the talk? »
- 🎬 Demo Notes
- Slide 17 — 1500 lines of markdown
- Slide 18 — Product/Software Engineer in the loop
- Slide 19 — AI Maturity Level (post-demo)
- Slide 20 — AI Maturity Level (→ L4a highlighted)
- Slide 21 — How much does 1 session/issue cost?
- Slide 22 — What productivity gain?
- Slide 23 — How could we improve?
- Slide 24 — Thank you! Any Questions?
🦸 Superpowers for your Workflows: Creating a 100% AI-Generated Kestra Plugin
The developer's role is undergoing a massive shift. What if, today, your job is no longer to write code, but to orchestrate digital experts? The secret weapon now lies in Context Engineering: the craft of structuring knowledge and specs to guide AI with absolute precision.
In this talk, we will push the boundaries of code generation by delegating the entire creation of a Java plugin for Kestra to a custom, private Claude Code plugin built for our Squad, powered by a fleet of specialized skills and agents. Forget copying and pasting snippets: here, AI takes the wheel from initial design to QA. Whether you are a Data, Platform, or Software Engineer, we'll see how the plugin ecosystem multiplies your automation capabilities tenfold.
What we will explore together:
- AI at the Helm (and Context as Fuel): Starting from a GitHub issue, see how our private plugin and its multi-agent system turn a spec into robust Java code. We'll show how effective Context Engineering keeps the AI safely on track.
- The Developer as the Conductor: How we built this internal plugin, packaged skills, and orchestrated agents to handle development, unit testing, code review, and QA.
- Methodology over tools: The approach is fully transferable to your own squad and domain.
Come and discover how AI transforms our daily routines and lets us focus on business value — all while maintaining absolute control over the software lifecycle!
🦸 Des super-pouvoirs pour vos workflows : Créer un plugin Kestra 100% généré par l'IA
Le métier de développeur est en pleine mutation. Et si, dès aujourd'hui, votre rôle n'était plus d'écrire du code, mais de piloter des experts numériques ? Tout l'art réside désormais dans le Context Engineering : l'art de structurer la connaissance et les spécifications pour guider l'IA avec une précision chirurgicale.
Dans ce talk, nous allons repousser les limites de la génération de code en déléguant l'intégralité de la création d'un plugin Java pour Kestra à un plugin privé Claude Code développé sur-mesure pour notre Squad, embarquant une flotte d'agents et de skills spécialisés. Oubliez le copier-coller de snippets : ici, l'IA prend les commandes de la conception à la QA. Que vous soyez Data Engineer, Platform Engineer, ou Software Engineer, nous verrons comment l'écosystème de plugins décuple vos capacités d'automatisation.
Ce que nous allons explorer ensemble :
- L'IA aux commandes (et le contexte comme carburant) : Partir d'une simple issue GitHub pour laisser notre plugin Claude Code et ses agents transformer une spécification fonctionnelle en code source Java robuste. Nous verrons comment un Context Engineering efficace permet de border l'IA.
- Le développeur, chef d'orchestre : Comment nous avons conçu ce plugin interne, packagé les bonnes compétences (skills) et orchestré les agents pour gérer le développement, la validation des tests unitaires, la code review et la QA.
- Méthodologie avant les outils : L'approche est entièrement transférable à votre squad et à votre domaine.
Venez découvrir concrètement comment l'IA transforme notre quotidien, automatise les tâches ingrates et nous permet de nous concentrer sur la valeur métier, tout en gardant une maîtrise totale du cycle de vie logiciel !
🦸 Superpowers for your Workflows: Creating a 100% AI-Generated Kestra Plugin
🇬🇧 Hello everyone and welcome! Today we're going to talk about orchestration, workflows, but most importantly… superpowers. As developers, we all try to automate as many tedious tasks as possible. So, what if we entrusted the creation of our tools to AI? Together, we'll see how to go from theory to practice by discovering how to create a Kestra plugin 100% generated by AI. Beyond the 100%-AI-generated plugin, this talk is about a methodology — Context Engineering — applied to a product squad. The skills and agents powering the demo are internal to Kestra's Plugins squad and not public; what's transferable is the approach. But what is a workflow anyway? And Kestra?
🇫🇷 Bonjour à toutes et à tous et bienvenue ! Aujourd'hui, on va parler d'orchestration, de workflows, mais surtout... de superpouvoirs. En tant que développeurs, on cherche tous à automatiser le maximum de tâches fastidieuses. Alors, et si on confiait la création de nos outils à l'IA ? Ensemble, on va voir comment passer de la théorie à la pratique en découvrant comment créer un plugin Kestra à 100 % généré par une IA. Au-delà du plugin généré à 100 % par l'IA, ce talk parle d'une méthodologie, le Context Engineering, appliquée à une squad produit. Les skills et agents qui pilotent la démo sont internes à la squad Plugins de Kestra et ne sont pas publics ; ce qui est transférable, c'est l'approche. Mais au fait c'est quoi un workflow ? Et Kestra ?
Fundamental unit of orchestration. It defines a set of tasks, their execution order, inputs, outputs, and orchestration logic.
🇬🇧 A workflow is the atom of your orchestration: where business logic meets technical execution. It's the flight plan that ensures every piece of data arrives at its destination, at the right time.
🇫🇷 Le workflow, c'est l'atome de votre orchestration : là où la logique métier rencontre l'exécution technique. C'est le plan de vol qui garantit que chaque donnée arrive à bon port, au bon moment.
- Connect disparate systems
- Extract, transform and load data at scale
- Manage autonomous agents
🇬🇧 Orchestration isn't just about plugging cables together — it's about giving consciousness to your disparate systems. It's transforming a microservices chaos into a perfectly synchronized symphony.
🇫🇷 Orchestrer, c'est pas juste brancher des câbles, c'est donner une conscience à vos systèmes disparates. C'est transformer un chaos de microservices en une symphonie parfaitement synchronisée.
🇬🇧 Who orchestrates data in the room? And who uses an orchestrator?
🇫🇷 Qui orchestre des données dans la salle ? Et qui utilise un orchestrateur ?
🇬🇧 Let's be honest: modern orchestration is broken, drowning under fragile scripts and overly complex pipelines. It's time to change the paradigm and take back control.
🇫🇷 Soyons honnêtes : l'orchestration moderne est cassée, noyée sous des scripts fragiles et des usines à gaz. Il est temps de changer de paradigme pour reprendre le contrôle.
François Delbrayelle — Lead Software Engineer @ Kestra
🇬🇧 I'm François, Lead Software Engineer at Kestra. Day-to-day in our squad, our goal is to extend the platform ecosystem, improve adoption and offerings, and expand acquisition. Today I'll share how we integrated agentic AI into our own development loop!
🇫🇷 Moi c'est François, Lead Software Engineer chez Kestra. Au quotidien dans notre squad, notre objectif est d'étendre l'écosystème de la plateforme, d'améliorer l'offre et l'adoption et étendre l'acquisition. Aujourd'hui, je vais vous partager comment on a intégré l'IA agentique dans notre propre boucle de développement !
- Open-source core
- Enterprise Edition
- Kestra Cloud
- Plugins & Ecosystem
🇬🇧 So to start, what is Kestra? Kestra revolves around 4 major pillars today: Open Source for the community, Enterprise for governance at scale, Cloud to free ourselves from infrastructure management, and Plugins & Ecosystem to address all modern orchestration challenges and extend adoption and acquisition — that's where I work with my squad.
🇫🇷 Alors pour démarrer c'est quoi Kestra ? Kestra s'articule aujourd'hui autour de 4 piliers majeurs : Open Source pour la communauté, Enterprise pour la gouvernance à l'échelle, Cloud pour s'affranchir de la gestion d'infrastructure, Plugins & Ecosystem pour répondre à tous les défis d'orchestration modernes et étendre l'adoption et l'acquisition, c'est là où j'interviens avec ma squad.
- 10 000+ Organizations
- 2 Billion Flows executed in 2025
- 27 000 GitHub Stars ⭐ kestra-io/kestra
- 2 200+ OSS contributors
🇬🇧 We are now adopted by the world's largest organizations: Toyota, Crédit Agricole, Hewlett Packard, Leroy Merlin, etc. With 2 billion workflows we have data and feedback to improve every day. And on the open-source side with 27,000 GitHub stars and 2,200 contributors we have a great community that lets us go further and further! Feel free to star the repository!
🇫🇷 Nous sommes aujourd'hui adoptés par les plus grandes organisations mondiales : Toyota, Crédit Agricole, Hewlett Packard, Leroy Merlin, etc. Avec 2 milliards de workflows nous avons de la data et du feedback pour nous améliorer au quotidien. Et côté open-source avec 27 000 étoiles GitHub et 2 200 contributeurs nous avons une belle communauté qui nous permet d'aller toujours plus loin ! N'hésitez pas à mettre une étoile sur le repository !
- Unified Interface — one place for all your workflows
- Declarative & Agnostic — define flows in YAML, run any language
- Event-Driven — react to any event, internal or external
- High Scale — Run anything, anywhere
🇬🇧 Our strength is providing a fully unified and agnostic interface: regardless of your cloud or tech stack, everything is controlled from the same place. Whether you prefer coding in Python, Go, writing YAML or using the visual editor, the platform reconciles all ways of working. We are also event-driven, meaning we can react and trigger flows on demand in different ways.
🇫🇷 Notre force, c'est de proposer une interface totalement unifiée et agnostique : peu importe votre cloud ou votre stack technique, tout se pilote au même endroit. Que vous préfériez coder en Python, en Go, écrire du YAML ou utiliser l'éditeur visuel, la plateforme réconcilie toutes les manières de travailler. Nous sommes également event-driven, ce qui signifie que nous pouvons réagir et déclencher des flows sur demande de différentes manières.
| Domain | Use Cases |
|---|---|
| AI | LLM inference chains and agent lifecycles |
| Data Engineering | Robust pipelines and delivery |
| Infrastructure | Cloud and Platform Ops |
🇬🇧 Today, we have 3 main areas of focus: AI, data and infrastructure. From generative AI to Cloud infra, Kestra is the universal Swiss Army knife. One tool to break down silos between Data, Ops and Software.
🇫🇷 Aujourd'hui, nous avons 3 grands domaines de prédilection : l'IA, la data et l'infrastructure. De l'IA générative à l'infra Cloud, Kestra est le couteau suisse universel. Un seul outil pour briser les silos entre la Data, l'Ops et le Software.
- Platform Engineers: Standardize automation
- Data Engineers: Build reliable pipelines
- Software Engineers: Integrate background automation into apps
🇬🇧 Kestra is built for every type of user. It's the platform where Platform, Data and Software Engineers finally speak the same language — the common foundation that lets your teams collaborate without friction.
🇫🇷 Kestra est construit pour tout type d'utilisateur. C'est la plateforme où Platform, Data et Software Engineers parlent enfin le même langage, le socle commun qui permet à vos équipes de collaborer sans friction.
Plugins power every task and trigger in Kestra. They wrap external systems, expose orchestration primitives, and let you extend the platform with custom code.
🇬🇧 In Kestra, plugins are the engine of every task and trigger: they encapsulate external systems and translate complex orchestration building blocks into simple configurations. They even allow you to extend the platform with your own code to natively connect your databases, queues or APIs.
🇫🇷 Dans Kestra, les plugins sont le moteur de chaque tâche et de chaque trigger : ils encapsulent les systèmes externes et traduisent des briques d'orchestration complexes en simples configurations. Ils permettent même d'étendre la plateforme avec votre propre code pour connecter nativement vos bases, vos files ou vos API.
- 10% most used plugins by 90% of the users
- 1500+ plugins available at kestra.io/plugins
- Everything is a plugin
🇬🇧 10% of the plugins are used by 90% of users. With nearly 1,500 plugins, Kestra is a platform without limits. Everything is a plugin in Kestra: a task, a trigger, a task runner, a secret manager, a storage provider, etc. And if the plugin you need doesn't exist yet, we'll create it together… in a few minutes.
🇫🇷 10 % des plugins le sont par 90 % des utilisateurs. Avec près de 1500 plugins, Kestra est une plateforme sans limites. Tout est plugin dans Kestra : une tâche, un trigger, un task runner, un secret manager, un storage provider, etc. Et si le plugin dont vous avez besoin n'existe pas encore, on va le créer ensemble... en quelques minutes.
| Level | Label | Decision Maker | Characteristic |
|---|---|---|---|
| L5b | Self-Authoring | AI creates new agents | Writes, tests, and deploys agent roles |
| L5a | Self-Optimizing | AI updates instructions | Updates prompts / orchestration logic |
| L4b | Autonomous | AI, unsupervised | Same as L4a but no human gate |
| L4a | Supervised Agentic | AI, human bounds | Dynamic next-steps; multi-agent; gates |
| L3 | Scripted | Human designed flow | Deterministic; fixed step order |
| L2 | Augmented | Human, AI suggestions | Copilot, autocomplete, basic API calls |
| L1 | Manual | Human, every time | Prompts typed into web UI; no integration |
🇬🇧 In short, at Kestra, everything is a plugin. That's what makes our ecosystem powerful and flexible. But developing these plugins takes time, code and human expertise. That's where AI comes in! Before jumping into the demo I wanted to talk about the different maturity levels of agentic AI usage. It ranges from level 1 — a simple chatbot in the browser — to level 5 with complete multi-agent autonomy. In between there are several stages where the human gradually delegates tasks to agents that become increasingly autonomous and optimized. That's what I'd like to present to you now, in part.
🇫🇷 Bref, chez Kestra, tout est plugin. C'est ce qui fait la force et la flexibilité de notre écosystème. Mais développer ces plugins demande du temps, du code et de l'expertise humaine. C'est là que l'IA entre en jeu ! Avant de nous lancer dans la démo je voulais parler des différents niveaux de maturité d'utilisation de l'IA agentique. Ça va du niveau 1 — un simple chatbot dans le navigateur — au niveau 5 avec une autonomie complète multi-agents. Entre les deux on a plusieurs paliers où petit à petit l'humain délègue ses tâches aux agents qui deviennent de plus en plus autonomes et optimisés. C'est ce que je voudrais vous présenter maintenant en partie.
— Linus Torvalds
DevLille 2026 — notes :
🇬🇧 As Linus Torvalds says: "Talk is cheap, show me the code." Except it's the Plugins Agent Team that will show you the generated code! For this demo, we start from a real use case related to data governance and regulatory compliance. Some teams work with datasets containing personal data, but must strictly comply with GDPR (in particular Article 25 on data protection by design). The problem to solve: Today, our plugin can generate fake data on the fly, but it's missing an essential feature: the ability to anonymize or mask on demand an existing data stream containing sensitive information (PII). This anonymization feature doesn't exist yet. Let's look at the technical specification together for this anonymization feature and hand off the entire subject to our Plugins Agent Team: from the design plan all the way to QA! (ref: issue #53)
🇫🇷 Comme dit Linus Torvalds : "Talk is cheap, show me the code." Sauf que c'est la Plugins Agent Team qui va vous montrer le code généré ! Pour cette démo, on part d'un vrai cas d'usage lié à la gouvernance des données et à la conformité réglementaire. Certaines équipes manipulent des jeux de données contenant des données personnelles, mais elles doivent impérativement respecter le RGPD (notamment l'article 25 sur la protection des données dès la conception). Le problème à résoudre : Aujourd'hui, notre plugin permet de générer des fausses données à la volée, mais il lui manque une fonctionnalité essentielle : pouvoir anonymiser ou masquer à la demande un flux de données existant contenant des informations sensibles (PII). Cette feature d'anonymisation n'existe pas encore. Voyons ensemble la spécification technique pour cette feature d'anonymisation et confions l'intégralité du sujet à notre Plugins Agent Team : du plan de conception jusqu'à la QA ! (ref: issue #53)
DevLille 2026 — notes :
🇬🇧 As Linus Torvalds says: "Talk is cheap, show me the code." Except it's the Plugins Agent Team that will show you the generated code! For this demo, we start from a real use case related to data governance and regulatory compliance. Some teams work with datasets containing personal data, but must strictly comply with GDPR (in particular Article 25 on data protection by design). The problem to solve: Today, our plugin can generate fake data on the fly, but it's missing an essential feature: the ability to anonymize or mask on demand an existing data stream containing sensitive information (PII). This anonymization feature doesn't exist yet. Let's look at the technical specification together for this anonymization feature and hand off the entire subject to our Plugins Agent Team: from the design plan all the way to QA! (ref: issue #53)
🇫🇷 Comme dit Linus Torvalds : "Talk is cheap, show me the code." Sauf que c'est la Plugins Agent Team qui va vous montrer le code généré ! Pour cette démo, on part d'un vrai cas d'usage lié à la gouvernance des données et à la conformité réglementaire. Certaines équipes manipulent des jeux de données contenant des données personnelles, mais elles doivent impérativement respecter le RGPD (notamment l'article 25 sur la protection des données dès la conception). Le problème à résoudre : Aujourd'hui, notre plugin permet de générer des fausses données à la volée, mais il lui manque une fonctionnalité essentielle : pouvoir anonymiser ou masquer à la demande un flux de données existant contenant des informations sensibles (PII). Cette feature d'anonymisation n'existe pas encore. Voyons ensemble la spécification technique pour cette feature d'anonymisation et confions l'intégralité du sujet à notre Plugins Agent Team : du plan de conception jusqu'à la QA ! (ref: issue #53)
Demo context (DevLille 2026): plugin kestra-io/plugin-datagen · feature request issue #53 · generated PR #55 · docs kestra.io/plugins/plugin-datagen
🇬🇧 Framing note: The skills and agents shown in this demo are internal to the Kestra Plugins squad and are not public. The goal is to share the methodology — Context Engineering adapted to a squad's specific domain.
workflow-superpowers(slide 23) is the public foundation; Claude Code can generate the rest for any context.
🇫🇷 Note de cadrage : Les skills et agents présentés dans cette démo sont internes à la squad Plugins de Kestra et ne sont pas publics. Le but est de partager la méthodologie — du Context Engineering adapté au domaine spécifique d'une squad.
workflow-superpowers(slide 23) est le socle public ; Claude Code peut générer le reste pour n'importe quel contexte.
Install asciinema first if needed:
# Ubuntu
sudo apt install asciinema
# macOS
brew install asciinemaThen replay (-s 3 plays at 3× speed, -i 1.5 caps idle pauses to 1.5 s):
# Set to the conference folder you want to replay (e.g. 2026_devlille_demo)
DEMO_DIR=2026_devlille_demo
# Plan generation (~2 min)
asciinema play -s 3 -i 1.5 $DEMO_DIR/plan.cast
# Full implementation (developer + reviewer + QA) (~27 min)
asciinema play -s 3 -i 1.5 $DEMO_DIR/implementation.cast🧑💻 = step where the developer has an action in the agentic development workflow
1. 🧑💻 Define the business need (2 min)
Explain what a Kestra plugin is:
"A Kestra plugin is a Java project hosted on GitHub. It is compiled into a shadow JAR and dropped into a plugin directory used by a Kestra instance. Each task or trigger in the plugin is a simple Java class."
Open in the browser:
- the plugin docs — show the existing tasks and the feature to generate
- the GitHub issue — walk through the business need, acceptance criteria, and YAML examples
"The issue was written by a human with everything needed to code without guessing — and this issue was itself generated with our
/kestra-plugin-managing-issuesskill."
2. Run /kestra-plugin-planning (3-4 min live)
/kestra-plugin-planning https://github.com/kestra-io/plugin-foobar/issues/1
Show the posted comment on GitHub in the browser.
"The plan is generated first and posted as a comment on the issue so it's documented — we can then clear or compact the context if we want, or another squad member can pick up the implementation."
3. Show the plan skill (while it runs)
Open skills/sources/kestra-plugin-plan/SKILL.md in the terminal:
"The skill reads the issue, generates a structured plan — Design, Tasks, Edge Cases, Docs Impact — and posts it directly as a GitHub comment. Everything you're about to see running is Markdown. These files are the squad's operational manual."
"This SKILL.md was itself generated by Claude Code — iteratively, from directives and feedback. That's the meta point: AI wrote the tools that write the code."
Skill best practices respected:
- All under 500 lines
- Clear sequential workflows: each skill has explicit numbered steps with defined success/failure conditions
- Conditional branching: OSS vs EE, plan-approved or not, PASS/FAIL QA, APPROVE/BLOCK review — all decision points are explicit
- Feedback loops: QA fail → developer fix → retry; review cycle with 5-cycle guard
- Concrete examples: report template with exact markdown structure, bash command blocks, plan template
- Defaults provided: plugins dir defaults to ~/dev/plugins, sensible abort messages
- No assumed packages: agent-browser has an install note; all other tools (curl, docker, rtk) are standard in the target environment
- No secrets: guardrails section + PreToolUse hook enforcement baked into the QA skill
- Good descriptions: specific, action-oriented, include argument hints
We iterated a lot:
- Claude Code generated our skills & agents iteratively in dedicated sessions
- The skills & agents were battle-tested in separate sessions and improved once we got feedback
superpowers is too generic for our Kestra-specific needs — that's why we wrote our own skills & agents instead of relying on it. What superpowers still brings: 14 general skills (TDD cycles, plan/code/verify phases, parallel subagents, worktree isolation).
We chose skills & agents over having AGENTS.md to maintain on about 200 repositories with the same guidelines and requests everywhere.
There's no prompt engineering here or almost none — it's more about context engineering.
4. 🧑💻 Approval gate (1 min)
Comment /plan-approved on the issue live.
"This is the human checkpoint. The workflow cannot continue without this exact comment, posted by a kestra-io org member. This is the guardrail — not a 'yes' button, a deliberate act."
5. Run /kestra-plugin-implementing (8-15 min — narrate while waiting)
/kestra-plugin-implementing https://github.com/kestra-io/plugin-foobar/issues/1
6. Show the issue skill and agents (while it runs)
Open skills/sources/kestra-plugin-issue/SKILL.md and narrate the chain:
- The skill verifies
/plan-approvedand org membership (security gate) - It classifies complexity: here Standard (auth token → QA required)
- It spawns the
kestra-plugin-developeragent (→ showagents/sources/kestra-plugin-developer.md): full batch implementation, Gradle tests, PR - Then the
kestra-plugin-code-revieweragent (→ showagents/sources/kestra-plugin-code-reviewer.md): reviews the full diff, returns APPROVE / REQUEST CHANGES / BLOCK - Also show
agents/kestra-plugins-guidelines.md: guidelines shared by both developer and code reviewer (Kestra Java conventions, tests, documentation, clean code) - Then the
/kestra-plugin-qaskill: end-to-end browser test on Kestra EE - Subagents (sequential,
Agenttool) vs Agent Team (parallel,/kestra-plugin-issues) - During QA, Claude Code uses Kestra's remote and public MCPs for plugins, blueprints and docs to create realistic flows
- We didn't create a Claude Code plugin so as not to lock into this harness and to leave the option of using the skills & agents in Codex or OpenCode
- Additional guardrails are baked into the skills & agents as belt-and-suspenders safety measures
- It's possible to invoke some of the skills & agents directly, like the QA skill or the code reviewer agent
7. Show the created PR (3-4 min)
Open the PR in the browser: generated feature code diff, tests, description with closes: and reviewer inline comments.
8. 🧑💻 Review by the kestra-io/plugins squad (on GitHub — ~1 min)
A developer from the kestra-io/plugins squad reviews the PR on GitHub: reads the diff, tests, description, and inline comments from the AI reviewer.
9. 🧑💻 Plugin release (~1 min)
A squad member merges the PR and releases the plugin via Plugins Devtools.
🧑💻 = étape où le développeur a une action dans le workflow de développement agentique
1. 🧑💻 Définir le besoin métier (2 min)
Expliquer ce qu'est un plugin Kestra :
"Un plugin Kestra, c'est un projet Java hébergé sur GitHub. Il est compilé en shadow JAR et déposé dans un répertoire de plugins utilisé par une instance Kestra. Chaque task ou trigger du plugin est une simple classe Java."
Ouvrir dans le navigateur :
- la documentation du plugin — montrer les tasks existantes et la feature à générer
- l'issue GitHub — lire le besoin métier, les acceptance criteria et les exemples YAML
"L'issue a été rédigée par un humain avec tout ce qu'il faut pour coder sans deviner. Et cette issue, on l'a générée avec notre skill
/kestra-plugin-managing-issues."
2. Lancer /kestra-plugin-planning (3-4 min live)
/kestra-plugin-planning https://github.com/kestra-io/plugin-foobar/issues/1
Montrer le commentaire posté sur GitHub dans le navigateur.
"Le plan est généré en premier et posté en commentaire sur l'issue pour être documenté — on peut ensuite vider ou compacter le contexte si on veut, ou un autre membre de la squad peut prendre l'implémentation."
3. Montrer le skill plan (pendant l'exécution)
Ouvrir skills/sources/kestra-plugin-plan/SKILL.md dans le terminal :
"Le skill lit l'issue, génère un plan structuré — Design, Tasks, Edge Cases, Docs Impact — et le poste directement en commentaire GitHub. Tout ce que vous voyez tourner, c'est du Markdown. Ces fichiers, c'est le manuel opérationnel de la squad."
"Ce SKILL.md a lui-même été généré par Claude Code — de manière itérative, à partir de directives et de retours. C'est le point méta : l'IA a écrit les outils qui écrivent le code."
Bonnes pratiques des skills respectées :
- Tous moins de 500 lignes
- Workflows séquentiels clairs : chaque skill a des étapes numérotées avec des conditions de succès/échec définies
- Branchements conditionnels explicites : OSS vs EE, plan-approved ou non, QA PASS/FAIL, review APPROVE/BLOCK — tous les points de décision sont explicites
- Boucles de feedback : QA fail → fix développeur → retry ; cycle de review avec garde à 5 itérations
- Templates concrets : rapport Markdown avec structure exacte, blocs de commandes bash, template de plan
- Valeurs par défaut sensées : répertoire plugins
~/dev/plugins, messages d'abandon clairs - Pas de packages supposés : agent-browser a une note d'installation ; curl, docker, rtk supposés standards dans l'environnement cible
- Pas de secrets : section guardrails + hook PreToolUse dans le skill QA
- Bonnes descriptions : spécifiques, orientées action, avec exemples d'arguments
On a beaucoup itéré :
- Claude Code a généré nos skills & agents de manière itérative lors de sessions dédiées
- Les skills & agents ont été testés au combat dans des sessions séparées et améliorés après feedback
superpowers est trop générique pour notre besoin Kestra — c'est pourquoi on a écrit nos propres skills & agents plutôt que de s'y limiter. Ce que superpowers apporte quand même : 14 skills généraux (cycles TDD, phases plan/code/vérification, sous-agents parallèles, isolation par worktree).
Nous avons choisi les skills & agents plutôt que d'avoir un AGENTS.md à maintenir sur environ 200 repositories avec les mêmes guidelines et requests partout.
Il n'y a (presque) pas de prompt engineering ici — c'est plutôt du context engineering.
4. 🧑💻 Valider le plan (1 min)
Commenter /plan-approved sur l'issue en direct.
"C'est le checkpoint humain. Le workflow ne peut pas continuer sans ce commentaire exact, posté par un membre de l'org kestra-io. C'est le garde-fou — pas un bouton 'yes', un acte délibéré."
5. Lancer /kestra-plugin-implementing (8-15 min — narration pendant l'attente)
/kestra-plugin-implementing https://github.com/kestra-io/plugin-foobar/issues/1
6. Montrer le skill issue et les agents (pendant l'exécution)
Ouvrir skills/sources/kestra-plugin-issue/SKILL.md et narrer la chaîne :
- Le skill vérifie le
/plan-approvedet l'appartenance à l'org (gate de sécurité) - Il classe la complexité : ici Standard (token d'auth → QA requis)
- Il spawne l'agent
kestra-plugin-developer(→ montreragents/sources/kestra-plugin-developer.md) : implémentation complète en un batch, tests Gradle, PR - Puis l'agent
kestra-plugin-code-reviewer(→ montreragents/sources/kestra-plugin-code-reviewer.md) : review du diff complet, verdict APPROVE / REQUEST CHANGES / BLOCK - Montrer également
agents/kestra-plugins-guidelines.md: les guidelines communes au developer et au code reviewer (conventions Java Kestra, tests, documentation, clean code) - Puis le skill
/kestra-plugin-qa: browser-test end-to-end sur Kestra EE - Distinction subagents (séquentiel,
Agenttool) vs Agent Team (parallèle,/kestra-plugin-issues) - Pendant la QA, Claude Code utilise les MCPs remote et publics de Kestra pour les plugins, les blueprints et la doc pour créer des flows réalistes
- On n'a pas fait de plugin Claude Code pour ne pas s'enfermer dans ce harness et laisser la possibilité d'utiliser les skills & agents dans Codex ou OpenCode
- Des guardrails sont ajoutés en complément dans les skills & agents pour être casque, ceinture, bretelles
- Il est possible d'invoquer certains skills & agents directement, comme le skill de QA ou l'agent code reviewer
7. Montrer la PR créée (3-4 min)
Ouvrir la PR dans le navigateur : diff du code généré pour la feature, tests, description avec closes: et findings du reviewer en inline comments.
8. 🧑💻 Révision par la squad kestra-io/plugins (sur GitHub — ~1 min)
Un développeur de la squad kestra-io/plugins review la PR sur GitHub : lit le diff, les tests, la description et les inline comments du reviewer IA.
9. 🧑💻 Release du plugin (~1 min)
Un membre de la squad merge la PR et release le plugin via Plugins Devtools.
(callback slide — shown after the demo)
🇬🇧 And that's the demo! The plugin is generated, tested, and it works perfectly. Ultimately, a large part of what the Plugins squad does is automatable and can be reduced to approximately 1,500 lines of Markdown in the form of skills and agents (for the single-issue version, not n issues). These markdown files are our squad's operational manual, broken down into precise areas of expertise that agents will read and apply to the letter.
🇬🇧 These Markdown lines were themselves generated iteratively by Claude Code, from my directives and feedback across dedicated sessions. Once the foundation is written, it barely changes. Human effort on skills and agents represents less than 5% of total time. The rest is direction and feedback, not writing.
🇫🇷 Et voilà pour la démo ! Le plugin est généré, testé, et il fonctionne parfaitement. Finalement, une grande partie de ce que fait la squad Plugins est automatisable et peut être réduite à environ 1500 lignes de Markdown sous forme de skills et d'agents (pour la version 1 issue pas n issues). Ces fichiers markdown, c'est le manuel opérationnel de notre Squad, découpé en expertises précises que les agents vont lire et appliquer à la lettre.
🇫🇷 Ces lignes de Markdown ont elles-mêmes été générées de manière itérative par Claude Code, à partir de mes directives et de mes retours au fil de sessions dédiées. Une fois le socle écrit, il bouge très peu. L'effort humain sur les skills & agents représente environ moins de 5 % du temps total. Le reste, c'est de la direction et du feedback, pas de l'écriture.
- 🧑💻 writes the issue
- 🤖
/kestra-plugin-planning - 🧑💻
/plan-approved - 🤖
/kestra-plugin-implementing(developer & reviewer) - 🧑💻 reviews, merges and releases
🇬🇧 Yes, it's a bit of an ego check to realize this — but we keep control over what matters most: the product, architecture, results, release and monitoring once in production!
🇫🇷 Alors oui ça met un peu un coup à l'égo de faire ce constat mais nous gardons le contrôle sur le plus important : le produit, l'architecture, les résultats, la release et le suivi une fois en production !
(same table as slide 14)
🇬🇧 Now that we've seen the Plugins Agent Team in action, let's go back for 2 minutes to our maturity matrix. If we analyze what just happened: the AI didn't just do autocomplete or Copilot (level 2). It wrote, tested and deployed several agents in a near-autonomous manner. We are therefore at level 4a where AI manages a large part of the software development cycle but with a human in the loop for key decisions. We've moved beyond the simple deterministic script toward agentic orchestration.
🇫🇷 Maintenant qu'on a vu la Plugins Agent Team en action, revenons 2 minutes à notre matrice de maturité. Si on analyse ce qu'il vient de se passer : l'IA n'a pas juste fait de l'autocomplétion ou du Copilot (le niveau 2). Elle a écrit, testé et déployé plusieurs agents de manière quasi autonome. On est donc sur le niveau 4a où l'IA gère une grande partie du cycle de développement logiciel mais avec un humain dans la boucle pour les décisions clés. On est sorti du simple script déterministe vers de l'orchestration agentique.
(same table, with L4a — Supervised Agentic highlighted as the target level)
🇬🇧 This is where the developer role shifts: you no longer type code, you become an orchestrator of agents and skills who spends more time on product management, architecture and results rather than pure code writing.
🇫🇷 C'est ici que le métier de développeur bascule : vous ne tapez plus de code, vous devenez un orchestrateur d'agents et de skills qui passe plus de temps sur le product management, l'architecture et les résultats plutôt que sur l'écriture de code pure.
| Metric | Value |
|---|---|
| Input tokens (team definition) | ~20,000 |
| Total input tokens | ~340,000 |
| Total output tokens | ~30,000 |
| Cost | ~$1.65 (Opus for planning, Sonnet for the rest) |
| Developer agent + QA share | ~70% of total input tokens |
🇬🇧 The skills and agents cost approximately 20,000 tokens per session for a feature or bug (approximately 6% of total input tokens). A feature like the one from the demo would cost approximately 340,000 input tokens and 30,000 output tokens. But the architecture of Claude Code itself and certain file reads (code, web, GitHub issue) mean there's an incompressible baseline. For a feature like the one shown it costs on average $1.65 with Opus for the plan and Sonnet for the rest. With a plan like Claude Code Max x20 at $200/month that would be approximately 120 possible issues — about 6 per day working 20 days a month, which already greatly accelerates productivity. But in reality this pricing allows exploiting many more tokens since it's not pay as you go. In our case it's the developer agent and QA skill that account for 70% of total input tokens. On the cost side, we've already managed to save nearly $1 per issue by optimizing via recent PRs: passing the plan to the developer agent to avoid re-exploring the code, and multiple /compact calls at strategic points to reduce the context window.
🇫🇷 Les skills et agents coûtent environ 20 000 tokens par session pour une feature ou un bug (environ 6 % du total en input). Une feature comme celle de la démo coûterait environ 340 000 tokens d'inputs et 30 000 d'outputs. Mais l'architecture même de Claude Code et certaines lectures (du code, du web, de l'issue GitHub) font qu'il y a un palier incompressible. Pour une feature comme celle que je vous ai montrée ça coûte en moyenne 1,65 $ avec Opus pour le plan et Sonnet sur le reste. Avec un plan comme Claude Code Max x20 à 200 $/mois ça ferait environ 120 issues possibles soit environ 6 par jour en travaillant 20 jours par mois ce qui permet déjà d'accélérer la productivité grandement. Mais en réalité ce pricing permet d'exploiter beaucoup plus de tokens car ce n'est pas du pay as you go. Dans notre cas c'est l'agent développeur et le skill de QA qui prennent 70 % du total des tokens en input. Sur le coût on a déjà réussi à gagner près de 1 $ par issue en optimisant via des PRs récentes : passer le plan à l'agent développeur pour éviter une réexploration du code, et plusieurs /compact aux endroits stratégiques pour réduire la context window.
| Manual | Agentic | |
|---|---|---|
| A regular issue | ~4h | ~30 min |
| Speedup | ~8x 🚀 |
🇬🇧 A typical medium-complexity issue — a new Kestra task with CSV/JSON processing, tests, and examples — takes a senior developer around 4 hours working solo. With skills and agents, the same issue is done in 30 minutes of real human time: an ~8x speedup, measured on a real ticket. As a bonus, AI covers steps the developer would have skipped: structured plan, code review, thorough QA. The human role shifts from doing to validating: approving the plan, monitoring, merging the PR, and releasing the plugin.
🇫🇷 Une issue de complexité moyenne (par exemple une nouvelle tâche Kestra avec traitement CSV/JSON, tests et exemples) prend environ 4 heures à un développeur senior en autonomie. Avec les skills et agents, la même issue est bouclée en 30 minutes de temps humain réel, soit un gain de l'ordre de 8x mesuré sur un vrai ticket. En prime, l'IA couvre des étapes que le développeur aurait sautées : plan structuré, revue de code, QA détaillée et propre. Le rôle humain bascule du faire vers le valider : approuver le plan, monitorer, merger la PR et release le plugin.
- Plan refinement loop
- Support more complex QA
- Monitor CI after PR creation
- Go to the next levels (L4b - L5a)?
🇬🇧 Improve the planning loop to avoid a simple /plan-approved. We could also imagine QA for more complex plugins requiring for example an account. Then, verify CI in real time once the PR is created. And of course we could go even further: L4b "autonomous" level — removing human blockers means eliminating /plan-approved with an auto-evaluation of the plan based on solid criteria + auto-release capability; L5a "self-optimizing" level — after each session, write a telemetry JSON + new skill for auto-optimization of skills & agents (opens PRs on our repo containing them). All of this of course requires testing, time and guardrails particularly around security. The future of Kestra is being written with AI, and it's being written now!
🇫🇷 Améliorer la boucle de planification pour éviter un simple /plan-approved. On peut aussi imaginer une QA pour plugins plus complexes nécessitant par exemple un compte. Ensuite, vérifier la CI en temps réel une fois la PR créée. Et bien sûr nous pourrions aller encore plus loin : le niveau L4b « autonome » : faire sauter les blocages humains c'est supprimer le /plan-approved avec une auto-évaluation du plan sur la base de critères solides + capacité de release auto ; le niveau L5a « auto-optimisé » : après chaque session, écrire un JSON de télémétrie + nouveau skill d'auto optimisation des skills & agents (ouvre des PRs sur notre repo qui les contient). Tout bien sûr nécessite des tests, du temps et des garde-fous notamment en termes de sécurité. Le futur de Kestra s'écrit avec l'IA, et il s'écrit maintenant !