⚡ TL;DR
Agentic coding tools can produce a lot more code. They also produce more PRs, more churn, more bugs, and a lot more review work. Chris Simon’s talk argues that technical excellence comes down to one thing: protecting your team’s theory of the programme, meaning the shared understanding that lets you change software sensibly. Systems thinking explains why “more output” and other assumptions often fail to turn into better outcomes.
Check out the full recording here.
🚀 Two software worlds
You’ve probably heard the old rocket ship story. A team under pressure to ship fast cuts corners, piles up debt, and slows down over time. That story still holds, but AI has changed its shape.
In the new world, it isn’t one team shipping code anymore. It’s lots of agents running in parallel, more Jira tickets, more PRs, and more people stuck reviewing and fixing output they didn’t write. Throughput goes up. So does the confusion about design and gaps in domain knowledge.
🎢 Despondent to euphoric
Reactions to agentic coding are all over the place. Chris lays them out on a scale from despondent to euphoric, with pragmatic and strategic positions in between. Most teams are somewhere in the middle, and where they sit depends a lot on what they choose to measure.
📊 What the evidence says
The research points in different directions, but a few patterns keep showing up:
- One study found experienced developers took longer with AI tools, and still believed they’d been faster.
- Another reported gains in self-reported value.
- Another found higher throughput, along with far more incidents per PR.
- A longitudinal study found developers spent more time reviewing code, less time writing it, and were less satisfied overall.
🔭 Think in systems
Systems thinking is at the heart of the talk. Chris presents three ideas:
- Non-existent boundaries. A system’s boundary is something you choose, not something that’s already there. It’s a social construct developed by the team.
- Layers of limits. Fix one bottleneck, and the next one shows up.
- Wardley mapping. Look at the wider world your software lives in.
Together, these explain why two teams can use the same tools and get very different results.
Your frame decides what gets optimised
Draw a narrow boundary around the system, and you end up optimising prompts, code, and deployments. Draw a wider one that includes product decisions, customers, domain experts, and the social and environmental effects of what you ship. You get different answers depending on which frame you pick.
🎲 LLMs are probabilistic token extruders
LLMs don’t understand things the way people do. They generate tokens through random sampling, they’re limited by their context window, and the quality of what they produce depends on how common a pattern was in their training data.
That’s why domain knowledge matters so much:
- Well-modelled domains with common patterns get good results.
- Unmodelled or unusual domains need domain experts and much more context-setting.
- Domain modelling itself is still an area where coding agents struggle.
🧩 Programming is only one piece
Writing code is one part of building software. Product, UX, quality, and domain knowledge matter just as much, and good teams depend on people whose strengths complement each other.
This is where layers of limits come back in. If you speed up coding but validation, design, and checking against what customers actually need stay weak, you just end up with problems in a different area in the chain.
🏁 To wrap up
If you want technical excellence to survive the move to agentic tools:
- Think in systems, not just pipelines.
- Choose your frame on purpose. It decides what you end up optimising.
- Understand your constraints, and expect the next bottleneck to appear once you clear the current one.
- Respect every skill involved in building software, not only programming.
- Hold on to your team’s theory of the programme. It’s what lets you change software well.
Stay chill 🧊
