https://speakerdeck.com/esciara 2026-02-09 10:23:51 -0500 Coding with an agent has become commonplace. But as soon as you want to deliver a real product evolution with multiple agents, the problem changes: it's no longer just about generating code, it's about organizing the work. Gas Town / Gas City explores this shift: moving from an individual assistant to an AI-native software factory. In this talk, we'll show how to transform a product intention into distributed work: breaking it down, coordinating, supervising, integrating and verifying. With a live demo, we'll start from a realistic application and let Gas Town / Gas City organize the delivery with multiple development agents. Coding with an agent has become commonplace. But as soon as you want to deliver a real product evolution with multiple agents, the problem changes: it's no longer just about generating code, it's about organizing the work. Gas Town / Gas City explores this shift: moving from an individual assistant to an AI-native software factory. In this talk, we'll show how to transform a product intention into distributed work: breaking it down, coordinating, supervising, integrating and verifying. With a live demo, we'll start from a realistic application and let Gas Town / Gas City organize the delivery with multiple development agents. Tue, 09 Jun 2026 00:00:00 -0400 https://speakerdeck.com/esciara/organizing-ai-native-software-delivery-with-gastown https://speakerdeck.com/esciara/organizing-ai-native-software-delivery-with-gastown Dans un talk précédent, j'ai expliqué comment travailler efficacement avec un agent de code sur des bases de code complexes. A cette occasion, nous avons exploré en détails des approches avancées de Context Engineering, ainsi que le workflow RPI (Research Plan Implement) créé par Dex Horthy (créateur du Contexte Engineering) / HumanLayer. Dans ce talk, je vous propose de plonger dans le détail des commandes et des techniques utilisées pour garantir efficacité et qualité des artefacts produits. Dans un talk précédent, j'ai expliqué comment travailler efficacement avec un agent de code sur des bases de code complexes. A cette occasion, nous avons exploré en détails des approches avancées de Context Engineering, ainsi que le workflow RPI (Research Plan Implement) créé par Dex Horthy (créateur du Contexte Engineering) / HumanLayer. Dans ce talk, je vous propose de plonger dans le détail des commandes et des techniques utilisées pour garantir efficacité et qualité des artefacts produits. Wed, 22 Apr 2026 00:00:00 -0400 https://speakerdeck.com/esciara/2026-04-dev-with-ai-30-no-slop-deep-dive-sur-les-commandes-du-workflow-rpi-research-plan-implement https://speakerdeck.com/esciara/2026-04-dev-with-ai-30-no-slop-deep-dive-sur-les-commandes-du-workflow-rpi-research-plan-implement On parle beaucoup de "self-improving AI". Mais concrètement, comment on construit un skill de développement qui s'auto-optimise ? Et qu'est-ce que ça change quand on peut piloter le processus depuis son téléphone, entre deux trajets ? **Le problème :** le skill creator de Claude Code permet de créer des skills, mais l'optimisation de la qualité de l'output reste human-in-the-loop. Ça veut dire : ouvrir un viewer HTML, comparer des résultats côte à côte, cliquer "Submit". Pas idéal quand on a 15 minutes dans sa voiture. **L'approche :** j'ai combiné le skill creator avec la technique d'autoresearch (popularisée par Karpathy et Simon Scrapes) -- des assertions binaires objectives qui remplacent le feedback humain. "Le code a des type hints" : vrai/faux. "La fonction fait moins de 30 lignes" : vrai/faux. Pas de subjectivité, pas de browser, pas de clics. **Ce que je couvrirai, dans cet ordre :** 1. **Skill creator vs autoresearch : deux couches, pas une** -- Le skill creator gère l'activation (quand le skill se déclenche). L'autoresearch gère la qualité de l'output (ce que le skill produit). Ce sont des problèmes différents qui se complètent. 2. **Construction du skill, pas à pas** -- Ce que j'ai mis en place : - Le SKILL.md initial et ses instructions - Les evals.json avec des expectations binaires concrètes - La boucle autonome : tester → identifier les échecs → modifier → retester → commit ou reset - Le prompt clé : "Ne me demande pas la permission. Continue en boucle." 3. **Ce que j'ai fait depuis la voiture** -- Le workflow mobile : - Lancer la boucle via Claude Code sur téléphone - Surveiller les logs pendant un trajet - Intervenir uniquement quand le score stagne - La review qualitative finale (ton, cohérence) -- ça, c'est resté humain 4. **Résultats et limites** -- Ce que la boucle gère bien (structure, format, patterns de code). Ce qu'elle ne gère pas (ton, créativité, choix architecturaux). La stratégie : automatique d'abord, humain ensuite. 5. **Takeaways** -- Comment écrire de bonnes assertions binaires. Quand l'autoresearch vaut le coup vs quand c'est overkill. Le mindset "piloter l'IA plutôt que coder soi-même". On parle beaucoup de "self-improving AI". Mais concrètement, comment on construit un skill de développement qui s'auto-optimise ? Et qu'est-ce que ça change quand on peut piloter le processus depuis son téléphone, entre deux trajets ? **Le problème :** le skill creator de Claude Code permet de créer des skills, mais l'optimisation de la qualité de l'output reste human-in-the-loop. Ça veut dire : ouvrir un viewer HTML, comparer des résultats côte à côte, cliquer "Submit". Pas idéal quand on a 15 minutes dans sa voiture. **L'approche :** j'ai combiné le skill creator avec la technique d'autoresearch (popularisée par Karpathy et Simon Scrapes) -- des assertions binaires objectives qui remplacent le feedback humain. "Le code a des type hints" : vrai/faux. "La fonction fait moins de 30 lignes" : vrai/faux. Pas de subjectivité, pas de browser, pas de clics. **Ce que je couvrirai, dans cet ordre :** 1. **Skill creator vs autoresearch : deux couches, pas une** -- Le skill creator gère l'activation (quand le skill se déclenche). L'autoresearch gère la qualité de l'output (ce que le skill produit). Ce sont des problèmes différents qui se complètent. 2. **Construction du skill, pas à pas** -- Ce que j'ai mis en place : - Le SKILL.md initial et ses instructions - Les evals.json avec des expectations binaires concrètes - La boucle autonome : tester → identifier les échecs → modifier → retester → commit ou reset - Le prompt clé : "Ne me demande pas la permission. Continue en boucle." 3. **Ce que j'ai fait depuis la voiture** -- Le workflow mobile : - Lancer la boucle via Claude Code sur téléphone - Surveiller les logs pendant un trajet - Intervenir uniquement quand le score stagne - La review qualitative finale (ton, cohérence) -- ça, c'est resté humain 4. **Résultats et limites** -- Ce que la boucle gère bien (structure, format, patterns de code). Ce qu'elle ne gère pas (ton, créativité, choix architecturaux). La stratégie : automatique d'abord, humain ensuite. 5. **Takeaways** -- Comment écrire de bonnes assertions binaires. Quand l'autoresearch vaut le coup vs quand c'est overkill. Le mindset "piloter l'IA plutôt que coder soi-même". Thu, 02 Apr 2026 00:00:00 -0400 https://speakerdeck.com/esciara/2026-03-dev-with-ai-rex-30-construire-un-vrai-skill-de-dev-optimise-avec-autoresearch-dot-dot-dot-dot-dot-dot-de-ma-voiture https://speakerdeck.com/esciara/2026-03-dev-with-ai-rex-30-construire-un-vrai-skill-de-dev-optimise-avec-autoresearch-dot-dot-dot-dot-dot-dot-de-ma-voiture July 2025: Stanford University presents a study based on 100k commits demonstrating the ineffectiveness of AI-driven development on complex codebases. August 2025: Dexter Horthy, who coined the term Context Engineering, shares a retrospective on a new approach that made it possible to deliver two feature PRs in 7 hours on a 300k-LOC open-source codebase, validated by the maintainers, who had estimated the effort at 3–5 days each if they had done it themselves. This talk presents that approach. July 2025: Stanford University presents a study based on 100k commits demonstrating the ineffectiveness of AI-driven development on complex codebases. August 2025: Dexter Horthy, who coined the term Context Engineering, shares a retrospective on a new approach that made it possible to deliver two feature PRs in 7 hours on a 300k-LOC open-source codebase, validated by the maintainers, who had estimated the effort at 3–5 days each if they had done it themselves. This talk presents that approach. Mon, 09 Feb 2026 00:00:00 -0500 https://speakerdeck.com/esciara/2026-02-dev-with-ai-no-vibes-allowed-20-getting-ai-to-work-in-complex-codebases https://speakerdeck.com/esciara/2026-02-dev-with-ai-no-vibes-allowed-20-getting-ai-to-work-in-complex-codebases