There’s a moment in every technology cycle when the conversation shifts register. The question stops being whether to adopt AI, and becomes how — and, more importantly, at what organizational, cognitive, and quality cost. If you’re a senior developer, you’ve probably already moved past demo-day enthusiasm and into the more uncomfortable phase: figuring out what actually works once the agent leaves the playground and lands in production, inside a ten-year-old monorepo, reviewed by a team that didn’t write that code.
From the Codemotion AI & Tech Conference in Milan, we’ve picked out seven talks that, taken together, trace a coherent learning path: from organizational scale (hundreds of engineers) down to the fine configuration of a single agent, from individual potential to the discipline required not to get swept up in the noise. This isn’t an uncritical celebration of AI adoption. It’s closer to a map of trade-offs — exactly what you need if you’re the one making technical decisions, not just getting excited at a keynote.
1. Start with scale: what happens when you have to convince 300 engineers
The natural starting point is organizational. In “Scaling AI Adoption: The Real Challenges of Transforming 300 Engineers,” Alfonso Graziano describes what it actually takes to push an organization past the experimentation phase and toward repeatable, “AI-native” development — not one enlightened team, but hundreds of people at wildly different levels of maturity.
The most useful part for a senior audience isn’t the list of wins — it’s the list of failures: resistance patterns, false starts, over-reliance on tooling, and, above all, the gap between perceived and actual productivity. It’s a healthy reminder: enterprise AI adoption isn’t a licensing-procurement problem, it’s a large-scale behavioral change problem — and self-reported productivity numbers should always be taken with a grain of salt.
2. Then configuration: the agent isn’t a tool, it’s a system to govern
If Graziano’s talk operates at the organizational level, Alexio Cassani’s — “Configuring the Harness: From Claude Code as a Tool to Claude Code as a Working System” — drops down to actual engineering. His thesis is sharp: a modern coding agent already ships with its own harness; what changes the outcome isn’t building one from scratch, it’s configuring it well.
Cassani walks through the surfaces that govern an agent’s behavior — project instructions, skills, permissions, hooks, subagents, MCP, all the way to the plugin layer that makes a configuration shareable across a team — and lands on a point every tech lead should internalize: not every rule belongs in the same place. Contextual knowledge isn’t a hook. A constraint that must always hold isn’t a line buried in a prompt. It’s a lesson in architecture applied to agent governance, not prompt engineering.
3. Individual potential: when one engineer replaces a team
From there the focus shifts to the individual contributor. “Kill the Standup: How One Engineer Ships What Five Cannot” by Matteo Collina is probably the most provocative talk in the lineup. Starting from Brooks’s Law on communication channels — which scale as n(n-1)/2 — Collina argues that AI has changed the equation: a single engineer with autonomy, technical taste, and an AI that removes the throughput bottleneck can ship in two weeks what a team ships in two months.
But the talk isn’t naive cheerleading. Collina is explicit about what happens when the model breaks down: autonomy without technical taste produces disasters, and he admits as much himself, describing a production vulnerability he introduced through an AI-assisted PR he didn’t review carefully enough. It’s a valuable case study precisely because it doesn’t hide the risk: this kind of solo, high-leverage engineering only works if technical taste can carry the weight of that autonomy.
4. The necessary counterpoint: when adoption just produces “slop”
Every respectable AI-adoption narrative needs a counterweight, and that’s where “Everything Is Slop, Let’s Slow the F*ck Down” by Mario Zechner comes in. The talk opens with an observation any open-source maintainer knows all too well: repositories drowning in agent-generated issues and PRs, exciting experiences on greenfield hobby projects that don’t translate at all to real production codebases.
It’s the talk a senior audience waits for at every AI conference — the one that doesn’t sell the transformation but interrogates it, asking how to recover discipline and agency without giving up the real benefits of agentic tools entirely. Set next to Graziano’s and Collina’s talks, it works as an epistemic corrective: adoption has a dark side made of volume without quality, and it’s worth knowing that before you scale something that can’t hold up.
5. The architectural question that precedes every adoption: do you even need an agent?
Before configuring or scaling anything, there’s a question too often skipped: is an agentic architecture actually the right one? Jigyasa Grover tackles it head-on in “When NOT to Use an Agent: Choosing Between Workflows, Services, and LLM Orchestration,” reminding us that agents aren’t an automatic upgrade — they’re a trade-off, one that brings non-determinism, a larger attack surface, harder evaluation, and operational unpredictability.
The talk’s value for a senior developer is its comparison framework across three architectural patterns — deterministic workflows, service-oriented architectures augmented with LLMs, and full agentic orchestration — analyzed along very concrete axes: failure isolation, latency and cost predictability, observability, security boundaries, and regression-testing strategy. It’s the antidote to the “automation? integration? reasoning? build an agent” reflex that’s becoming dangerously close to a default.
6. The process that has to adapt: code review under agentic pressure
If agents write code faster than teams can review it, the bottleneck shifts to PR review. Vladi Stevanovic addresses this in “The Swiss Cheese Fix: Why PR Quality Needs Layers,” starting from a problem many teams had already quietly accepted — PRs left unreviewed for days, 500-line diffs skimmed rather than read, rubber-stamp approvals on changes nobody truly understood — and showing how the sudden flood of agent-generated PRs pushed that situation past sustainable.
His proposal is the “Swiss cheese” model: several imperfect layers of defense — spec-driven development, competition between multiple agents, automated verification, and correct runtime context from the start — that together produce a system more reliable than any single layer on its own. It’s the talk that completes the picture: AI adoption doesn’t just require new tools, it requires processes redesigned around a volume of generated code that the old processes were never built to absorb.
7. The necessary closer: why we need more engineers, not fewer
We close with the talk that, in our view, gives meaning to all the others: “Why Coding Agents Need You More Than Ever” by Alfonso Fuggetta. The question “will AI make developers obsolete?” gets dismissed as false simplicity — whether in its hype version or its denial version (“it’s just autocomplete”).
Fuggetta’s argument is structural: an LLM has no internal reference for correctness, no understanding of the domain it’s building for, no orientation toward the system’s future, no memory across sessions. This isn’t a gap the next model release will close — it’s a structural void that has to be filled with method, domain knowledge, design judgment, process, and engineering depth. The conclusion — uncomfortable and liberating at once — is that capable agents don’t reduce the need for software engineering. They increase it.
The thread that ties the seven talks together
Read in sequence, these talks don’t tell a single, linear story (“AI works” or “AI doesn’t work”). They trace a multi-layered lesson that mirrors exactly the questions a senior developer is asking today:
- Organizationally, adoption is a behavioral-change problem at scale, not a tooling problem (Graziano).
- At the configuration level, result quality depends on how you govern the agent’s surfaces, not on the tool itself (Cassani).
- Individually, AI-amplified autonomy is extremely powerful but fragile without technical taste (Collina).
- Critically, you need the discipline to recognize when adoption is producing only noise (Zechner).
- Architecturally, the right question isn’t “which agent” but “do we even need an agent” (Grover).
- At the process level, review workflows need to be redesigned in layers to handle the new volume (Stevanovic).
- Strategically, all of this increases — rather than reduces — the value of real software engineering (Fuggetta).
If there’s one single takeaway, it’s this: mature AI adoption isn’t the accumulation of tools — it’s the accumulation of judgment about when, where, and how to use them. And that, it turns out, is exactly the kind of judgment that still requires a human engineer.
Want to hear these talks live?
These seven talks — and many others on the same thread of AI adoption, agentic engineering, and software engineering in the age of LLMs — are on the program at Codemotion AI & Tech Conference in Milan. If you work with code every day and want to compare notes with people who’ve already faced these trade-offs in production, this is the place to do it.
