On 29 October I was on Stage II at Codemotion Milan with my talk, Scaling AI Adoption. It was about how we are upskilling around 400 engineers to move past experiments and into real, repeatable AI-native engineering, including the parts that didn't work.
While I was talking, the event app chat filled up with more questions than I could answer in the Q&A slot. I took screenshots and answered them afterwards, on camera. Here are the answers, written up. The questions are copied exactly as people wrote them.
The short answers
- Tools go obsolete fast? Agree on good defaults at the team level, and use boring tech for important projects.
- Juniors and judgment? Learn the fundamentals, then use the agent as a teacher.
- Spec-driven development in brownfield? Yes, with spec islands and lazy specs.
- Ambiguity in agent-written code? Context, specs, verification and quality gates.
- Five-person scrum teams? The size changes less than the roles do.
- Human review as the bottleneck? A harness, an LLM judge and an AI risk scorer in front of the human.
1. How do you keep up when AI tools go obsolete so fast?
How do you manage the rate at which tools, practices and information become obsolete as agents advance within a company with many projects and engineers?
Tools and practices change so fast that staying ahead of the curve is hard for one person. In a big organization, with a lot of projects and a lot of engineers, it gets messy very quickly.
My recommendation is to agree on good defaults. In our case we don't have one default harness. We have a set of two or three harnesses, and teams choose from that set. The team picks, not the single engineer. The same goes for the ways of working and for the spec-driven development framework: the choice happens at the team level.
We still give a default. If you don't know where to start, we say "use this, this is what we recommend." If you want something different, feel free.
Then there is one principle I love: the more important the project is, the more boring the tech should be. If you are building something your company depends on, you probably don't want the SDD framework that came out last week, or the new harness that is so cool because it has something crazy in it. You want something relatively stable. (Even though "stable" is a weird word these days, at the pace we have.)
A tool I've seen a lot of teams use well for this is the AI-Native Engineering Canvas. It is a free template that gets a team in a room to agree on these principles and tools. It works at the team scale, and you can run it at the organization scale too.
2. How do junior developers build judgment with AI agents?
How can junior developers learn to make the right decisions without a solid background built through coding experience?
All of us, me included, learned to be software engineers by writing code by hand, building systems by hand and feeling the complexity by hand. Now an agent can manage a lot of that complexity, or at least the agent plus a human engineer can. So how does a junior build the experience that used to come from all those hours?
First, the fundamentals are still there. If you are a junior engineer, put real time and effort into operating systems, networking and programming. I still think you should learn a programming language properly. Not so you can type code by hand all day, but because knowing how to program is still very valuable.
Second, agents are a huge opportunity to learn. You can ask the coding agent to explain what you are doing while you do it. Want to understand caching? Implement caching from scratch with an LLM. Build something on top of WebSockets, maybe without any library. You might not write the code by hand, but you are learning how it works.
The skills you need as an engineer have not gone anywhere: systems thinking, debugging, breaking a problem into pieces. You still have to learn them, one way or another, and learning with an agent is a very good way.
I am already seeing junior engineers who, in a few months, learn so much that they can compete with people with 10 years of experience.
3. Does spec-driven development work in brownfield projects?
Are you able to successfully use spec-driven development in brownfield projects? Do you have any tips to share?
Almost every project we work on is brownfield. Usually you land in a codebase someone else already worked on. SDD works there too, with a few changes.
The main problem in a brownfield codebase is that the knowledge is trapped in people's heads. You can read the code to learn what it does. Why it behaves that way usually lives in the heads of the people who wrote it, and sometimes those people are not even in the company anymore. If you have the chance, start by building specs retroactively: write down what the code does and, most of all, why.
Two techniques help a lot:
- Spec islands. Don't try to specify the whole system to start with. Specify only the parts most likely to change and the parts that are mission critical in your domain, like authentication or payments.
- Lazy specs. When you are about to change a part of the codebase, stop for a second and write the spec for that part first.
This works well because the value of specs compounds over time, and you don't need a fully specified system to start using SDD. You need two things. A good harness around your repo, so the coding agent doesn't go off and do weird stuff. And real collaboration with your product manager, your designers and the other engineers, so the spec becomes the source of truth for the change you are making.
4. How do you manage ambiguity when AI agents maintain the code?
How do you manage the ambiguity in a project maintained by agents?
A project can stay maintainable even when 99% of the code, or all of it, was written by agents. You need these layers.
Context. Have a good context engineering stack: specs, rules, an AGENTS.md, everything that steers the agent in the right direction from the start. Every time the agent does something weird, find where it came from and fix it at the source. (I wrote about a small skill that does this after every session in the self-improving harness.)
Specs. The ambiguity in AI-generated code comes from letting the agent decide what to build and how. The spec removes that. In the spec you can say: we are building this microservice, in this language, with this framework, using these libraries and not those ones, following these rules.
The harness. Build a system that stops the agent from going off-road. Tests (which you should already have), linting, dead code elimination. Then an LLM as a judge: once a feature is done, a second model checks whether the code follows the spec, whether we forgot an acceptance criterion, whether we missed an edge case.
Safe deploys. Feature flags, canary releases, staged rollouts, blue-green deployments. Something will go wrong at some point. When it does, you want the blast radius to be a subset of users you can manage, not the whole system.
Observability. When something bad happens, you want to know what happened and fix it fast. You can even point an agent at the logs, metrics and traces, ask it to run the investigation and draft the PR.
5. Does the classic scrum team still make sense in an AI-native team?
Does the classic structure of scrum teams composed of 5 people with devs, QA, PO make sense today in an AI-native context?
Yes and no. We can now ship safely to production with smaller teams. Where we needed five or seven people, three can ship the same amount of code: usually a tech lead and two engineers, or a tech lead, an engineer and a product manager who also does design.
What I find more interesting than the size is the roles. The lines between designer, product manager, engineer and QA are blurring. I see product managers shipping features to production because they have Claude Code and access to the repo. I see designers building full prototypes in code, connected to a backend, and owning the design system in code before they hand it over to the engineers, so the engineers can work on what really matters from an engineering point of view. And I see engineers going the other way and doing product discovery.
A product manager asks "what is a backend? how does the database work?" and gets to iterate fast. In a safe environment, of course. We still want engineers to control what goes into production and what touches sensitive data, so there are layers of autonomy.
So the classic scrum team might not change much in size, even though very small teams are possible now. It changes in how the team behaves.
If you want to go deeper, chapter 10 of my book covers how to work in an AI-native team. Chapter 11 follows a newly formed AI-native team through a hard, complex challenge. It is a fictional chapter. Mostly.
6. How do you stop human code review from becoming the bottleneck?
How to prevent human validation from becoming the bottleneck?
In an AI-native team, the rate of PRs is more than humans can review. It takes too much time, and you don't want your engineers spending their entire day reading diffs. (I wrote more about this shift in what happens when coding is not the bottleneck anymore.)
First, you need a great harness. I cannot stop repeating this one. Deterministic gates, tests, linters, everything in place so the agent can fix its own mistakes before anyone looks.
Second, an LLM as a judge. A judge that checks the change against the spec catches far more than a judge that only reads the diff, because it can ask "did we forget an edge case we planned for? did we skip an acceptance criterion?" That frees up engineers' attention for the moments when it really matters.
Third, a technique I am starting to see more: the AI risk scorer. Instead of a human going through every PR, an agent assesses whether a change is safe to ship. It sits behind deterministic guardrails, for example glob patterns or file names, so the sensitive parts of the codebase can never skip review. When in doubt, it falls back to "not safe, a human reviews this."
After all those layers (the harness, the judge, a little loop of self-correction) there is a PR that only changes the color of a button. Do we really want a human to spend their focus on it? Probably not. Merge it, ship it to production or to a lower environment, and rely on safe deployments with feature flags and good observability to make sure nothing breaks.
None of this is free. It takes engineering discipline, tooling and good practices.
Thanks to everyone who asked. If you disagree with an answer, tell me on LinkedIn. The full playbook is in AI-Native Software Engineering, my book with O'Reilly.