From coder to orchestrator: notes from Codemotion 2026
Picture a room full of developers wearing headphones, each tuned to a different speaker on a different stage. That was Codemotion Milan 2026, two days at Superstudio Più billed as an “AI & Tech Conference”. And AI really was everywhere: even talks that were, on paper, about something else ended up talking about agents, LLMs and how they are reshaping the way we work, with no sign of stopping.
My colleague Alessio and I came back with one question stuck in our heads. If agents can write most of the code, what is a developer for? The answer we heard, in different words, from many stages was the same: we are becoming orchestrators. We no longer play every instrument ourselves, we decide what the orchestra plays, and we’re responsible for how it sounds.
This article is half reflection and half guide. First, why this shift is less strange than it looks. Then, what it costs: for junior developers, for budgets and for the planet. Finally, five practical rules we took home for orchestrating agents well.
Part 1: what stays ours
Every language moved closer to us
Andrey Breslav, the creator of Kotlin, made an observation that put the whole conference in perspective. Throughout the history of computing, every new programming language has moved a little further from the machine and a little closer to human language. Punch cards gave way to assembly, assembly to C, C to languages that read almost like English. Each step let us think less about how the machine works and more about what we want it to do.
Seen this way, AI isn’t a break with that history. It’s the next step: for the first time, the language we program in is simply our own. That is exciting, but it also changes where the hard part of the job lives.
From writing to deciding
When writing code becomes cheap, three things become more valuable, not less.
Judgement. An agent will happily produce ten solutions. Someone still has to know which one fits the problem, the users and the constraints, and why the other nine don’t. The Loop Engineering workshop opened with two well-known voices in the field saying they no longer prompt agents, they design the loops that do. Designing a good loop takes more understanding of the problem, not less.
Values. One talk on regulation summed it up in a sentence: “Algorithms are opinions written in code.” Every default setting, every shortcut, every piece of data we choose to send or keep is a choice about people. An agent can apply those choices, but it can’t own them.
Responsibility. Giorgio Natili’s talk, The Ethics Layer, proposed a principle we liked a lot: an agent’s authority to act is borrowed, never owned. It acts on our behalf. When it gets something wrong, “the AI did it” is not an answer anyone will accept, and rightly so.
An orchestra conductor doesn’t play the violin during the concert. But nobody becomes a conductor without knowing what a violin can and can’t do. The same is true for us: the less code we type, the more we need to understand it.
Part 2: what the shift costs
Every talk celebrated what AI can do. Fewer talked about the bill. We think three costs deserve more attention.
The junior question
Most of us learned the job through small tasks: a bug fix, a form, a simple endpoint, reviewed line by line by someone more senior. Those are exactly the tasks agents now do in seconds. So where will the next generation of seniors come from? Nobody at Codemotion had a definite answer, and we liked that honesty.
What everyone agreed on is that critical thinking has to be trained from day one. Erik Pronk’s talk on teams showed the risk: when not knowing something feels like a weakness, people quietly ask the AI instead of a colleague, and the mentoring moment never happens. For juniors, AI can be a great tutor, but only if someone still asks them “why did you choose this?” and waits for the answer.
The real price of a prompt
AI tools look cheap per request, but agents rarely make just one. A single task can trigger dozens of model calls, each with a large context, and the cost grows with every loop, retry and review. Several speakers admitted that the real cost of this new way of working is still far from clear, for companies and for clients. A vague prompt is not only less precise: it’s more expensive, because the agent spends tokens guessing.
The environmental bill
There is also a cost that doesn’t show up on the invoice. According to the International Energy Agency, data centres used about 415 TWh of electricity in 2024, and that figure is set to more than double to around 945 TWh by 2030, with AI as the main driver (source).
We can’t solve that on our own, but our choices count, starting with how we talk to the model. A prompt is not a chat with a colleague we need to be polite to: it’s a set of orders. Say what to do, in what order and what not to touch. Softened, vague requests such as “could you maybe have a look at…” leave the agent room to interpret, and every interpretation is another round of calls. Add a frontier model doing a job a small one could do, or an agent running in circles, and we waste money and energy at the same time. Efficient orchestration is also sustainable orchestration.
Part 3: five rules for orchestrating agents
So what does a good orchestrator actually do? Here is what we took home, written as rules we’re trying to follow ourselves.
Split the work, and pick the right player for each part
Don’t hand one agent the whole job. Several talks described “decomposing intelligence”: breaking a task into steps and giving each step to the model that suits it. A small, fast model can classify, summarise or check formatting; a frontier model is for the hard reasoning. It’s cheaper, faster and uses less energy, and each piece is easier to verify.
Some teams go a step further with routing intelligence: a layer in front of the models that decides, request by request, where each call should go, based on the task, the quality needed, latency, cost and privacy. Simple requests go to a small or local model, sensitive data stays on infrastructure you control, and only the hard problems reach the expensive frontier models. The choice stops being a habit and becomes a rule the system applies every time.
Brief it like a senior colleague
An agent knows nothing about your project except what you tell it. Give it context, constraints, examples and, above all, what “done” looks like before it starts. It’s not the length of a prompt that drives up costs: it’s the guessing. Unclear instructions let the agent make assumptions and decisions it shouldn’t make. And every wrong guess means another round of calls, tokens and time. A long, precise prompt is often the cheapest one.
Build trust with validators
Trust is the whole point. If you can’t trust what an agent produces, you end up checking everything by hand and lose the time you saved. And trust doesn’t come from a better prompt: it comes from validators, mechanisms that check the work automatically, outside the model. A rule written in a prompt is a request; a validator is a rule. “An instruction can be ignored, a hook can’t.”
In practice, good validation works in layers:
- automatic checks, such as tests, linters and type checks, that run every time the agent says it’s finished and send it back if something fails;
- an independent reviewer, another model or a colleague, because the checker should never be the maker: an agent tends to write tests its own code will pass;
- a final human approval before anything reaches production: no auto-merge, no auto-deploy.
Validators need to be trustworthy too. A test only counts once it has proved it can fail, by going red on the code before the fix. And the further a validator is from the maker, the more its green is worth.
Give it a box and watch what it does
Let agents work in a sandbox, with the fewest permissions and credentials they need. Then look at what they actually do. In I Spy on my Agent, a simple proxy showed every request an agent sends to its provider, including how much of our own context leaves the machine. Know what “normal” looks like, so you notice when something isn’t.
Own what ships
The agent writes; you sign. Read the diff, ask a colleague to review it, and make sure you could explain every line to someone else. If you can’t, it isn’t ready.
This matters because a new kind of debt is taking the place of technical debt: comprehension debt. Technical debt is code we know is messy. Comprehension debt is code that works, but that nobody in the team really understands, because nobody really wrote it. You don’t notice it until something breaks or needs to change, and then the interest is due all at once. The only way to pay it off is to keep understanding what goes into the product.
And keep learning: the opening keynote warned that the biggest risk of AI isn’t the technology, it’s that we stop learning.
The takeaway
AI is evolving at an incredible pace, and it’s up to us, as people and as developers, to adapt. Codemotion 2026 convinced us that adapting doesn’t mean typing less and thinking less. It means thinking more about the parts machines can’t own: what to build, for whom, at what cost, and with which values. The orchestra is getting bigger. The conductor still matters.
At COMMpla we work this way every day, in software development, UX/UI design and digital platforms for European projects. If you’re looking for a team that uses AI to move faster without losing control of quality, costs or people, get in touch with us.
Marco Carollo and Alessio Fabrizio, Full-stack Developers at COMMpla