Dev With AI 2026: what changes in developers’ work

On October 12, 2026, the first Dev With AI conference brought developers together at the Forum des Images in Paris. I presented my talk on the path from code to merge. The rest of the day expanded the question: how do we prepare agents’ work, verify their results and build a product someone needs?

I put the talks together in an illustrated report, available above to read or download. This page offers a synthesis. The full report retains the details of each talk, differences between approaches, photographs, speaker profiles and resources for further reading.

October 16, 2026 update. The report incorporates all 12 decks now available in the official program. Additions specify Dorra’s measurements, the Conversation Review framework, Jean-Louis’s protocols and Katia’s mechanisms. Brevo’s and Philippe Prados’s slides remain absent from the page checked. Quantitative results are attributed to the speakers, without independent replication.

TL;DR

Topic	What I take away from the day
Review and integration	Generating more code can increase the work waiting downstream. Tests, decisions and coordination need to keep up.
Business context	Mapping systems and reconstructing legacy rules takes work that coding conventions do not cover.
Workflow choices	An available skill may never run. An additional layer deserves comparison with a simpler workflow.
Quality of checks	A green test, a review and an evaluator can miss an error. Their ability to detect known defects needs checking too.
Product	User feedback, distribution and sales still occupy the people developing with AI.

Review and delivery absorb some of the work saved

At Brevo, Mickaël Arias and Maxence Bourquin describe the move from a Feature Factory to a collaboration platform. A contribution can cross several repositories and teams. Making that possible requires shared knowledge of systems, dependencies and the people who can make decisions. Their agents also prepare reviews, separating proposed corrections from decisions that belong to the maintainer.

Their account retains a concrete limitation: opening contributions increases demand for review. Missing or outdated context can also lead an agent to invent components. At the time of the talk, they say human review remains systematic; reducing some reviews in the future remains an intention.

My talk addresses the next part of that chain: local checks, understandable PRs, consolidated feedback and corrections with a stopping condition. A reviewer can find a defect while suggesting the wrong fix. Before applying it, I want to understand the expected behavior and verify that the correction preserves it. The report covers these points; the guide to my talk develops the reasoning and examples. Engineering the Review Loop extends the method through reviewer comparison, merge evidence and tested controls.

Marek Kalnik adds another artifact to review with Conversation Review. The diff does not reveal all the framing, supplied context or decisions made during the exchange with the agent. His example shows a request for technical strategy drifting into implementation. Revisiting the conversation exposes that shift and helps identify a practice or shared instruction to change. This reading complements code validation.

Business context is reconstructed with the people who know it

The talks by Alexandre Jeambrun and Saif Jerbi devote part of the work to recovering what existing software should do. Rules are scattered across code, scheduled jobs, configuration and historical data. Before requesting a rewrite, they reconstruct documentation and discuss it with domain experts.

Alexandre describes a modernization pipeline organized by domains and use cases. Generation follows specifications, architecture and input/output contracts. He combines microtasks with work-in-progress limits to keep parallel changes from piling up at merge time. System-wide impact analysis remains work in progress in his account; he does not present the complete rewrite as delivered.

Saif uses historical outputs to compare behavior. He also describes the limits of an initial sample: examining longer periods reveals cases absent from the first documentation. Expert validation and access to authorized code or configuration remain necessary when information is missing.

These accounts give the word “context” a precise meaning. A list of conventions can help an agent write in the repository’s style. On its own, it does not explain why a rule exists or whether the business still wants to keep it. One source configures Claude Code and Codex addresses the complementary distribution problem, keeping generation, installation and verified behavior separate.

Tests and evaluators need their own checks

Dorra Bartaguiz starts with an exercise whose rules involve dates and edge cases. The agent reports coverage that differs from her measurement; she then finds defects in both code and tests. Mutation testing helps her check whether assertions detect a deliberately incorrect change in behavior.

She repeats the work with explicit domain vocabulary, examples and a testing strategy, then progresses in small steps with TDD. What I take away is the place of expected behavior in that process. Adding tests with incorrect expected results can create a sense of safety without protecting the right rule.

Jean-Louis Rigau examines the same problem at workflow level. His case involves a library of contract clauses, with a requirement to avoid duplicates on retry. He compares agent, skill and review configurations, then examines the evaluator’s own mistakes.

The deck now specifies protocol r07a: 3 models × 4 workflows × 5 repetitions, yielding 60 results. A separate study, r08, contains 90 trials and must remain distinct. The v4/v5 evaluator comparison uses the same candidates without regenerating them: it detects a history view stuck after a loading error and changes the verdicts. Task success, workflow compliance and cost are separate measures; the small samples limit generalization.

Each layer around the model deserves testing

Guillaume Laforge presents Antigravity through delegation and inspection: plans to comment on, changes to review and verification artifacts. The surfaces and features described remain those of his demonstration. His advice to experiment on a project and ask for explanations also connects agent use to the developer’s learning.

Tugdual Grall and Xavier Noya invite us to reconsider instructions and skills as models evolve. Xavier describes specification-framework experiments where Markdown reading, validation requests and large PRs eventually produce mechanical acceptance. Specification retains its value, but each step should help someone decide or verify something. A validation click can become a habit rather distant from attentive reading.

Philippe Prados examines the cost of cycles, context and tool operations. His talk distinguishes model choice, reasoning effort and visible response length. It also offers approaches to caching, tool selection and reducing repeated searches. The reduction factor in his talk title remains an objective stated in the program, without savings of that magnitude validated by this report.

Patrick Szymkowiak’s account of RTK extends that discussion to command-output compression and team needs: cost attribution, shared policies and distribution of practices. Reducing the text sent to the model addresses part of consumption. To understand what it changes for accepted work, failures, retries and human interventions also need counting. The Back Market OpenRouter report provides another team account of per-person budgets and provider selection, separate from this conference.

Product accounts retain their differences

Bathilde Rocchia compares her mobile projects and describes a shift toward more testimonials and user feedback before implementation. She also uses AI for visuals and the website while retaining manual adjustments. Her account of automated posts identifies a personal limit: she can produce more while feeling she is losing control of her project.

Rémi Lakmeche presents HorseBrokers, an application for sport-horse brokers. He uses BMAD and Claude Code to develop on a stack he had not previously mastered, while retaining the brief and trade-offs. He describes the checks he had to add around that process, followed by prospecting to obtain trials and sell.

His use of BMAD adds nuance to Xavier’s criticism. One describes a solo workflow he finds useful; the other reports limitations encountered in team experiments. Together, those accounts do not establish a general recommendation about the method. Similarly, Alexandre’s factory responds to a particular scale and organization.

Katia Gil Guzman describes three mechanisms now documented by her deck: interface extensions, WebMCP to expose application actions to an agent, and annotations to connect a selection to user intent. Aisle, ArchMorph and JupyterLite illustrate application state shared between humans and agents. The report covers these examples without certifying current API availability.

Five experiments to choose from the problem you face

These are my proposed follow-ups, without commitments attributed to the speakers. I would start with whichever corresponds to an observable difficulty on a recent change.

1. Define success before the experiment. Choose a business behavior and its edge cases, then retain the same criteria throughout the comparison.
2. Remove a layer for comparison. Replay comparable tasks with and without a skill or additional review, retaining what actually ran, failures and interventions.
3. Review a conversation with a colleague. Recover the initial intent, a scope drift or a repeated correction, then choose one cause to address.
4. Test a check. Submit a known defect and a correct variant to the tests or evaluator. Retain verdicts separately if the instrument changes.
5. Verify what happens after generation. Compare historical behavior for a legacy system, obtain user feedback for a product, and track review waiting and rework.

For a separate comparison that led to rejecting the tested configurations, the Jev and local Laya report retains the results and limitations. Those experiments concern Laya; they do not measure the Jev API.

The full conference report lets you revisit the talks before choosing. It also includes the glossary, photographs, speaker profiles, content committee and training courses announced by Greg. Check training schedules in the Dev With AI catalog.

Thanks to Greg Lhotellier and the content committee, Marek Kalnik, Laetitia Lanfranchi and Arthur Magne, for this first edition. If you have tested one of these practices, I would be curious to hear which task you chose, the result and what made you change your mind.