{"id":36547,"date":"2026-09-03T16:18:52","date_gmt":"2026-09-03T14:18:52","guid":{"rendered":"https:\/\/www.codemotion.com\/magazine\/?p=36547"},"modified":"2026-09-03T16:18:53","modified_gmt":"2026-09-03T14:18:53","slug":"7-ai-adoption-lessons-from-people-whove-already-been-through-it","status":"publish","type":"post","link":"https:\/\/www.codemotion.com\/magazine\/ai-ml\/7-ai-adoption-lessons-from-people-whove-already-been-through-it\/","title":{"rendered":"7 AI Adoption Lessons From People Who’ve Already Been Through It"},"content":{"rendered":"\n

There’s a moment in every technology cycle when the conversation shifts register. The question stops being whether<\/em> to adopt AI, and becomes how<\/em> \u2014 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.<\/p>\n\n\n\n

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 \u2014 exactly what you need if you’re the one making technical decisions, not just getting excited at a keynote.<\/p>\n\n\n\n

1. Start with scale: what happens when you have to convince 300 engineers<\/h2>\n\n\n\n

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 \u2014 not one enlightened team, but hundreds of people at wildly different levels of maturity.<\/p>\n\n\n\n

The most useful part for a senior audience isn’t the list of wins \u2014 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 \u2014 and self-reported productivity numbers should always be taken with a grain of salt.<\/p>\n\n\n\n

2. Then configuration: the agent isn’t a tool, it’s a system to govern<\/h2>\n\n\n\n

If Graziano’s talk operates at the organizational level, Alexio Cassani’s \u2014 “Configuring the Harness: From Claude Code as a Tool to Claude Code as a Working System” \u2014 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.<\/p>\n\n\n\n

Cassani walks through the surfaces that govern an agent’s behavior \u2014 project instructions, skills, permissions, hooks, subagents, MCP, all the way to the plugin layer that makes a configuration shareable across a team \u2014 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.<\/p>\n\n\n\n

3. Individual potential: when one engineer replaces a team<\/h2>\n\n\n\n

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 \u2014 which scale as n(n-1)\/2 \u2014 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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

4. The necessary counterpoint: when adoption just produces “slop”<\/h2>\n\n\n\n

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.<\/p>\n\n\n\n

It’s the talk a senior audience waits for at every AI conference \u2014 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.<\/p>\n\n\n\n

5. The architectural question that precedes every adoption: do you even need an agent?<\/h2>\n\n\n\n

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 \u2014 they’re a trade-off, one that brings non-determinism, a larger attack surface, harder evaluation, and operational unpredictability.<\/p>\n\n\n\n

The talk’s value for a senior developer is its comparison framework across three architectural patterns \u2014 deterministic workflows, service-oriented architectures augmented with LLMs, and full agentic orchestration \u2014 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.<\/p>\n\n\n\n

6. The process that has to adapt: code review under agentic pressure<\/h2>\n\n\n\n

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 \u2014 PRs left unreviewed for days, 500-line diffs skimmed rather than read, rubber-stamp approvals on changes nobody truly understood \u2014 and showing how the sudden flood of agent-generated PRs pushed that situation past sustainable.<\/p>\n\n\n\n

His proposal is the “Swiss cheese” model: several imperfect layers of defense \u2014 spec-driven development, competition between multiple agents, automated verification, and correct runtime context from the start \u2014 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.<\/p>\n\n\n\n

7. The necessary closer: why we need more engineers, not fewer<\/h2>\n\n\n\n

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 \u2014 whether in its hype version or its denial version (“it’s just autocomplete”).<\/p>\n\n\n\n

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 \u2014 it’s a structural void that has to be filled with method, domain knowledge, design judgment, process, and engineering depth. The conclusion \u2014 uncomfortable and liberating at once \u2014 is that capable agents don’t reduce the need for software engineering. They increase it.<\/p>\n\n\n\n

The thread that ties the seven talks together<\/h2>\n\n\n\n

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:<\/p>\n\n\n\n