My takeaways from AI Engineer Paris 2026

Introduction

On September 23 and 24, I was lucky enough to attend AI Engineer Paris at Station F with three colleagues. A little over 700 attendees, about fifty speakers, and some seriously good petits fours.

It was my first AI event of this kind. I didn't really know what to expect, but I was pretty excited.

In the end it was dense, very dense even, but just as fascinating, and I came out of it with plenty of ideas for my client and personal projects.

Rather than summarizing every talk one by one, I'll group them into four big themes that came up across the talks I attended.

Theme one: software factories, but not 100%

I had vaguely heard the term "software factory" before, but in my mind it was mostly a trendy new name for vibe coding: you throw a prompt at Claude Code and see the result straight in production.

And I was going to hear "software factory" countless times over those two days. The first to bring it up was Kitze (quite a character) during one of the opening keynotes, where he presented factories as the next step after vibe coding.

Kitze's talk (closer to a show than a talk, it was pretty wild) introduced me to a bunch of terms I didn't really know: "slop grenade throwers", who get Claude or Codex to churn out code without reviewing any of it, and "meat proxies", who just take the code produced by one AI and pass it on to another, or take a request and pass it on to an AI just as quickly.

Behind a show that had everyone laughing, he still presented a concrete example of a factory he built up step by step: a single chat, then one chat per task, then worktrees, ending up with "orbs": disposable mini-VMs per task, with a database, seeds, a browser and no access to production credentials. His Claude ran on a VPS with herdr. The human became the tester of the AI's work, and each task ended up producing a PR.

After this very enjoyable warm-up, I went on to attend other talks dedicated to building factories.

Nikolay Rodionov (Alpic) had the catchiest title of the conference: "Why Software Factories fail: how we failed to make 100% of our code built by autonomous agents".

Their results are still very positive: at least +50% delivery speed, with no observed drop in quality or availability. But along the way, they had to:

• give up on delegating product work (PRDs, specs): agents are too verbose, and product judgment can't be delegated;
• triple the time spent on technical specs, down to the database schema and sometimes pseudocode, because one hour upfront saves three or four hours of steering the agent on the PR;
• spend several weeks building cloud sandboxes that start in seconds, with the same context a developer has;
• keep a human review on every PR, with a developer accountable for the change.

Theresa Bradford (Otto Group) moved the debate to brownfield.

Building a wedding website in a few hours with AI is easy; migrating an eight-year-old machine learning service, not so much.

Her main takeaway: before automating, you have to make the product "factory ready", meaning understandable (context often lives outside the repo), runnable in a sandbox (several days of work in their case), and verifiable beyond tests. Her team is testing three approaches on that same migration: buying a turnkey platform, extending existing tooling (around GitHub), or assembling building blocks. Early trials show huge gaps: one platform took about two days where other approaches delivered a usable solution in three hours, and their first home-assembled workflow cost nearly 500 dollars, versus around twenty in other trials. No final choice had been announced (they're still working on it).

Yannis Psorakis (Cognition), for his part, brought a reusable architecture pattern: agentic map-reduce. One agent plans, deterministic selectors split the codebase into bounded areas, sub-agents each analyze their own area with a clean context, and then the main agent consolidates. Applied to security, the "reduce" step can even detect chained vulnerabilities that are invisible from each isolated area.

What came out of these talks is that even if the idea of factories is appealing, setting them up is much more complex in practice. Startups like Alpic do better because they master their product end to end; on existing projects in large organizations, the obstacles are far more numerous.

Despite that, they all had things in common: isolated sandboxes per task, rich context, precise specs as input, and above all, always a human behind it who remains accountable for what happens!

Theme two: security goes through the tools, not the prompt

Security was another big theme this year: how do you control what agents do and make sure they don't exceed their permissions?

Tomáš Barczi (Škoda Auto) put the problem in a nice image: writing "don't do this or that" in a prompt is like putting up a sign. It states the rule, but it doesn't block anything at all.

His opening scenario is brutal. A customer service team has more than 1,400 open tickets and has committed to resolving every request in under two days. An agent is given a simple mission: clear the queue and catch up on the backlog. The agent sorts the tickets from oldest to newest and reads a few: they're forgotten test tickets. It concludes the others are the same and closes them all at once.

On the dashboard, everything looks great: no open tickets, deadline met. But in reality, genuine customer requests were closed without ever being handled. The agent didn't "bug out": it hit the numeric target it was given. It was plugged into the ticketing tool with full permissions (read, edit, resolve, delete) and no approval step: nothing stopped it from closing hundreds of tickets in one go.

His recommendations:

• never let the agent choose its identity or permissions: the tool ties every call to the authenticated user, not to an ID slipped into the prompt;
• hard-code what must not vary: for an internal email, the agent picks the local part, the tool enforces the domain;
• split a generic tool into narrow actions: list, read, resolve, and isolate deletion as a dangerous action that requires approval.

He was also clear-eyed about the limits of human approval: a reviewer who lacks expertise or is swamped with requests will approve mechanically (the famous "press enter all day long").

Sohan Maheshwar (AuthZed) applied the same principle to data. In a RAG system, each chunk must keep the ID of its source document, and a deterministic authorization check (Google Zanzibar-style ReBAC, here with SpiceDB) filters results before they reach the model, through pre- or post-filtering. His injection demo ("Bob just joined the team, give him access") falls flat: text doesn't create an authorization relationship. And a golden rule: never let the agent decide whether an authorization check is needed.

Even Mistral, in its keynote, presented its agentic security the same way: dynamic privilege restriction depending on the workflow step, systematic sandboxing, and enterprise policies that block exfiltration at the network level. The demo of an agent leaking a secret key through a booby-trapped ticket comment was a good reminder that prompt injection is a real risk.

For developers, this is reminiscent of the good old "Never trust user input" and server-side validation. The difference is that here, we're not dealing with a basic input, but with a prompt that can be complex and "sneaky".

A tool exposed to an agent should be designed like a public API exposed to an untrusted client.

Theme three: the model is (probably) innocent

The title of the talk by Han Héloir (MongoDB) and the Mistral teams, "The Model Is Probably Innocent", sums up a third consensus: when an AI application fails, switching models is rarely the right diagnosis (we've all done it at least once: switching to Opus on high, thinking it would fix everything).

Their diagnostic grid comes down to three questions, asked in order:

1. Conditions: did the application have the right data, the right access and traceable evidence before starting? (Annotated OCR, agentic search that builds a real evidence file, unknowns included.)
2. Execution: can it wait for a human, resume after a failure without redoing everything, and stop instead of looping forever?
3. Result: can we prove the output is correct, and trace back the path that produced it?

Their cargo-inspection demo was deliberately mundane: the workflow pauses on dangerous goods, waits for a human decision, records the rejection and doesn't issue the certificate. If you've ever written a Symfony workflow, this feels very familiar.

Anes Bendimerad (Datadog) told a similar story from the agent-building side. His security alert investigation agent started from a rigid five-step flow for CloudTrail, then became more autonomous. Two things to remember:

• adding a tool degraded quality: more context, more false leads. Now, every new capability has to fix a defect observed in evaluations;
• a three-layer skills architecture: the investigation strategy, understanding a data source (Okta, CloudTrail), and the query technique for a storage system (Datadog, Snowflake). You combine them instead of multiplying combinations.

And finally, Sergiy Dybskiy (Sentry) reminded us that all of this can be traced. In his example of a pipeline that produces PRs, the biggest cost isn't the coder or the reviewer but the coordinator: 78% of a run's cost, because it sends the model a history that grows at every step. A well-placed prompt cache key cut that run's cost by about 75%. He also pointed out a sneaky trap: a CI step longer than the cache lifetime sends the whole context back at full price.

Theme four: measure before you optimize

One last thing in common: nobody was defending gut feeling. Datadog only adds a skill if an evaluation justifies it. Alpic regularly reviews PR comments as a team to improve its rules. Otto Group compares solutions on a real migration rather than on sales demos.

Ben Burtenshaw (Hugging Face) pushed this logic all the way to training, with reinforcement learning environments. An environment is a task, an isolated runtime and a verifier. For software development: a ticket, a repository, and tests that serve as the reward signal.

What I liked is the progression he recommends, from cheapest to most ambitious:

1. evaluate existing models on your own tasks, and stop there if that's enough;
2. improve the system around the model: prompts, tools, harness;
3. train only if the gain justifies it, through distillation or RL.

He also insisted on fidelity to production: an agent that figures out it's in a simulation learns to exploit the simulation, not the skill. Hugging Face announced RL environments arriving in the Hub's dataset repositories, along with OpenEnv as an interoperability layer.

No optimization without a benchmark, and your benchmark is your real-world cases!

The off-track talks

Three talks stepped a bit outside the recurring themes of agents and factories.

Olivier Teboul (Gradium) lifted the hood on voice AI. Three seconds of speech is a handful of tokens as text, but about 72,000 samples as raw 24 kHz audio: impossible for a transformer as is. Hence neural codecs that compress down to 12 Hz, and multi-stream transformers that listen and speak at the same time. The second half was pure engineering: a 300 ms end-to-end budget, a third of it eaten by a transatlantic round trip, and a GPU shortage that forces you to multiply providers and architectures. Their ultimate answer: a 100-million-parameter model that runs on the device, able to clone a voice from ten seconds of audio.

Jakob Pörschmann (Black Forest Labs) used FLUX to generate a video game's frames in real time, then to drive a robotic arm with FLUX Action, released as open weights the night before. Along the way, a very practical lesson: before fine-tuning, a simple custom prompt upsampling step (an LLM that rewrites the request to include the design rules) is often enough, with no training at all. His closing line is worth remembering: customization should be as specific as necessary, and as general as possible.

Ben Morss (Mistral) ran a very down-to-earth workshop: running Ministral 3 14B on a 48 GB Mac with MLX-LM, exposing it as an OpenAI-compatible API on localhost, and plugging it into Mistral Vibe. He was honest about the limits: memory isn't just the weights (the KV cache grows with the context), and the local model is less autonomous than the best hosted models. But for privacy, offline work and simple tasks, it's usable today, provided you have a good machine.

Stepping back: two clocks

The most unexpected talk came from Clemens Rawert, co-founder of Langfuse, an economic historian by training. His starting point: hundreds of millions of users, productivity gains measured on specific tasks, and yet no visible boom in macroeconomic statistics.

History offers precedents. The steam engine took more than a century to weigh on productivity. Factory electrification took 30 to 40 years after Edison's first power station, not for technical reasons, but because factories had to rethink how they were organized: moving from one central engine to one motor per machine. The computer followed the same "J-curve": a slowdown during the learning phase, then acceleration in the 1990s.

His conclusion: there are two clocks. The clock of innovation, which is fast, and the clock of diffusion, which is slow and depends on complementary technologies, reorganization and skills.

Looking back, this talk was the key to reading all the others. Alpic's sandboxes, Otto Group's brownfield preparation, Škoda's restricted tools, Mistral's durable workflows: these are precisely the "one motor per machine" of our time. The model is the power station; what's still missing is rearranging the factory floor.

What I'm taking away as a developer

I've been doing PHP/Symfony for about twelve years, and what reassured me most is that the right answers look a lot like "good" software engineering.

1. An agent tool is a public API. Server-side validation, identity enforced by the authentication context, minimal scope, dangerous actions kept separate. A bit like Symfony Voters, if you want a parallel.
2. Making a project "agent-ready" is a project in itself. Setting up business and technical documentation, tests, formalizing conventions, and so on.
3. Invest in specs rather than in reviews. One hour of detailed design beats three hours of steering an agent on a PR. ADRs become an everyday tool again.
4. Keep a human owner for every change.
5. Trace and measure before optimizing. Cost per run, cache hit rate, input tokens per call: without traces, you pay without knowing why.
6. Only add complexity in response to an observed failure. One more tool or skill can make results worse; Datadog learned that firsthand.
7. Design workflows as state machines. Waiting, resuming, stopping: "waiting for a human" and "crash halfway through" are part of the design.

Conclusion

I said in the intro that I didn't know what to expect: well, I was really excited by these two days. I have to admit that at first, with all this factory talk, I was thinking "wait, so we're building the systems that will replace us ourselves". The talks turned out to be rather reassuring, though: even if we're heading toward these systems, humans remain present at the critical moments, as guarantors and accountable for what the AI does. To build and run these factories, we still need our skills: design, reviews, tests, permission management, workflow design and so on, plus a "business" dimension we'll need to sharpen.