YOW! Tech Leaders Summit 2026: when AI writes the code, what’s left for engineers?
Serar, Head of Product and Delivery at Restive, shares five insights from YOW! Tech Leaders Summit 2026 on AI, engineering judgment, team constraints, and where value gets made or lost.
Author
Head of Product & Delivery
Topics
Key takeaways
- The bottleneck in most software teams sits upstream of your engineers – in governance, demand management, and decision-making, not in the engineering itself
- AI accelerates code generation; engineering judgment – trade-offs, security, design decisions, long-term maintainability – remains a human job
- Framing technical debt as business risk rather than an engineering complaint changes who owns the decision
- Cognitive capacity is finite, and AI tools introduce a new form of context-switching that erodes it faster than most teams realise
- As execution gets faster, the structure and decision-making around it matters more, not less
There is a version of a tech conference that most of us know well – opening keynotes about transformation, slides with hockey-stick graphs, a great deal of confidence about the pace of change, and very little about what to actually do differently on Monday morning. YOW! Tech Leaders Summit in Melbourne last month was different from that.
I saw five sessions from practitioners who’ve spent years working on some of the most complex delivery problems in Australian and global tech. The audience was mostly CTOs, engineering managers, and delivery leads – people already doing the thing, already grappling with AI’s implications for how teams are built, and who’ve developed a healthy immunity to promises that don’t survive contact with a real organisation. What struck me wasn’t any one session in isolation – it was the same observation surfacing in different language from every speaker across the day: the constraint on your team’s performance almost never lives where you think it does, and until you find it you can optimise everything around it and still go nowhere.
Now I’m not saying this is a new, groundbreaking concept (this has been talked about in software delivery for at least forty years). What gives it new urgency now is AI, which is about to make the execution layer – where code actually gets written – substantially faster. If the bottleneck was never really there to begin with, accelerating past it just throws a brighter light on everything that was already slow.
Where the constraint actually lives
Simon White made the point with an analogy that sounds obvious once you hear it: a highway where too many cars are let on at once doesn’t produce more throughput, it produces congestion. The lanes are technically full, traffic is technically moving, and nobody is getting anywhere quickly. Push for high utilisation across every team in your engineering organisation and you’ll get exactly the same result.
The reason this pattern persists, despite being obviously wrong when stated plainly, is that engineers look overloaded because that’s where demand, context-switching, incomplete specs, and accumulating technical decisions all collide and become visible. They’re the signal of the bottleneck, not the source. The actual constraint is almost always upstream – in how priorities get set, how much demand enters the system, and critically, how often that flow gets interrupted by unplanned executive requests. Well-intentioned, usually urgent, and carrying enough authority that they land immediately into an already-loaded system and destroy the flow of everything around them.
We see this constantly with clients at Restive. The instinct when delivery slows is to look at the engineering layer – more engineers, better processes, different tooling. What’s usually happening is that something upstream is creating pressure that has nowhere else to go except into engineering, where it becomes visible. Widening that part of the highway when the problem is too many on-ramps doesn’t help.
A highway where too many cars are let on at once doesn’t produce more throughput, it produces congestion. The same is true of your engineering team.
The invisible standards problem
Selena Small’s session will be recognisable to anyone who has sat through engineering calibration sessions that go in circles: three CTOs across nine years at one organisation, each with their own unwritten definition of what a senior engineer looked like. Managers evaluating people against standards that existed only in their own heads. And feedback that sounds like direction but conveys nothing actionable – “be more strategic,” “step up,” “show more leadership” – which are personality critiques dressed as guidance, telling the recipient nothing useful about what to do differently, often because the person delivering it doesn’t fully know either.
The engineering management literature has been pointing at this problem for a long time – Camille Fournier on engineering ladders, Will Larson on staff-plus career paths – and the consistent finding is that invisible standards make genuine development nearly impossible. You cannot move toward something you cannot see. Selena’s reframe was precise: performance is an outcome, capability is the system that produces it, and managing performance without first building the capability system underneath it is like trying to improve a factory’s output by shouting at the assembly line. Her team of 29 ran the experiment properly – shared expectations, defined behaviours at each level, observable skills rather than vibes-based assessments – and career opportunities score went from 43 to 88, survey participation from 65% to 95%, and “my manager is genuinely invested in my development” hit 100% of the team.
Her honest qualification: a capability system launched and left alone becomes just another artefact. The real work is maintenance – new examples, live conversations, resisting the drift back toward evaluation as the default mode of a management relationship.
Why the language of engineering is broken
Jon Eaves has been building software for forty years and opened with something I’ve watched play out too many times: most engineering teams have accurate, high-quality information about the health of their systems, and the business consistently ignores all of it. He traced the root of the problem back to Ward Cunningham, who coined “technical debt” in 1992 and has spent the decades since watching the metaphor get spectacularly misapplied. Cunningham’s original framing was deliberate – debt was something you consciously took on, ship simpler now and refine later, with the full intention of paying it back. What it became was a catch-all term for accumulated mess with no owner and no plan, which sounds like an internal department concern and gets funded accordingly.
Jon’s solution is to stop using the word debt entirely. Call it risk instead – because risk is something every organisation already has a formal structure for. Risk goes on a register. Risk gets an owner, a mitigation strategy, a review cycle. When an engineer frames a technical concern as a business risk – here are the options, here are the implications, here is what the organisation is accepting by doing nothing – the conversation shifts from “engineering complaints” to “business information requiring a decision.” And once a risk has a formal owner, the engineering team is genuinely free of it: free of carrying unresolved anxiety about a problem they can see but can’t fix, and occasionally free to discover that the constraint they assumed was fixed can be removed by someone with authority they didn’t know was there.
The attention economy inside your own head
Callum Silcock’s session connected to research on human attention that doesn’t get nearly enough discussion in engineering contexts. Gloria Mark at UC Irvine has been studying workplace interruptions for over two decades, and the number that tends to stop people cold is this: after an interruption, it takes an average of twenty-three minutes to return to a task at full concentration. Not a few minutes to re-orient. Twenty-three minutes, per interruption, in environments where the average knowledge worker switches tasks every three to five minutes. By that arithmetic, most people are working in a state of perpetual partial attention and have simply accepted it as a normal day.
Callum framed cognitive capacity like a phone battery, and the important nuance is that the drain happens even when you don’t act on an interruption – “is this important?” is itself a cognitive event and the brain pays the cost regardless of the answer. The AI-specific point he raised is one of the most underexplored aspects of the current productivity conversation: today’s LLMs are slow enough to tempt you into switching to another task while waiting for a response, but fast enough that you’re still expected to hold the original context when it arrives. That loop is being sold as a productivity multiplier. For complex, sustained work, it’s often a context-switching trap dressed up as efficiency, and the cost never shows up on a dashboard.
After an interruption, it takes an average of twenty-three minutes to return to a task at full concentration.
AI writes code. Engineers do something harder.
The talk I’m still thinking about was Ben Taylor from Stile Education, who made a distinction I haven’t heard framed this clearly anywhere else – and which sits at the centre of the most important unresolved question in AI and engineering right now.
There is a prominent version of the AI narrative advancing from several directions simultaneously. Dario Amodei has suggested AI will be writing essentially all code within a couple of years. Jensen Huang has argued that natural language is now a programming language and everyone is therefore a programmer. GitHub’s research on Copilot found developers completing certain bounded tasks up to 55% faster with AI assistance. On a narrow reading of what “writing code” means, there’s something to all of this.
But writing code and engineering software are two distinct activities. They just looked the same for most of software history, because you discovered edge cases, security implications, and design consequences by loading the implementation into your head as you wrote it. The act of writing was also the act of understanding. AI decouples those two things by making the writing fast enough to happen before the understanding has fully formed, which works when the engineering judgment is already in place and becomes a meaningful risk when it isn’t.
Ben’s team built a pipeline that lets non-engineer science writers create interactive educational content using AI, without engineers in the review loop. Making that safe didn’t mean adding more careful reviewers – it meant building what he called “critics”: automated systems checking for specific known failure modes, accessibility compliance, security, design system adherence, internationalisation. The engineering work shifted from checking individual artefacts to building the system that checks all artefacts. That shift matters because the alternative – putting a human in the review loop – is less robust than it sounds. There’s a documented phenomenon called vigilance decrement, studied extensively in aviation safety and industrial monitoring, which describes the way humans monitoring a process passively miss substantially more errors than humans actively building. It’s a cognitive mode problem, not a motivation problem, and passive review at scale is a risk most teams are currently taking without having explicitly decided to.
As code generation gets cheaper, the decisions around it – how the system is architected, what failure modes it tolerates, what the next engineer who touches it will be able to understand – are what separate good outcomes from expensive problems. That’s still human work. In an AI-accelerated environment, it’s more human work than it’s ever been.
The constraint has moved. The question is whether you've noticed.
Five very different talks, the same through-line in all of them. Simon White on demand management. Selena Small on capability systems. Jon Eaves on risk translation. Callum Silcock on cognitive load. Ben Taylor on the coding-engineering split that AI is forcing into view whether organisations are ready for it or not. They were all pointing at the same gap: the technical problem is rarely purely technical, and the bottleneck is almost always in the system surrounding the work rather than in the work itself.
At Restive, a significant part of what we do with AI and engineering teams is work on exactly this structural layer – how teams are organised, how decisions flow, how priorities get set and communicated, how change actually lands. The code gets written, the tools get deployed, but the structure underneath all of that is where value gets made or lost. The organisations that will get the most from AI are not necessarily the ones that moved fastest to adopt the tools. They’re the ones that understood where their constraint was before they let AI make everything around it run faster.
Worth asking yourself where yours actually sits.
Serar Serar is Head of Product and Delivery at Restive. He works with engineering and product teams to close the gap between strategy and execution.
Frequently asked questions
What is the difference between coding and engineering in the age of AI?
Coding refers to writing valid syntax, implementing specified logic, and handling common error cases – the aspects of software development that AI tools are now significantly faster at, with GitHub’s research showing developers completing certain bounded tasks up to 55% faster. Engineering is the broader discipline: making trade-offs between competing constraints, identifying security implications, considering performance under load, designing for the person who maintains this code in two years. For most of software history these were inseparable – you discovered edge cases by loading the implementation into your head as you wrote it. AI is making them separable by accelerating the writing while the judgment still takes the same time it always did.
What is the productivity trap in software teams?
The productivity trap occurs when organisations optimise for high utilisation across every team simultaneously and produce congestion rather than throughput – the same way a highway with too many cars slows down despite every lane being full. Drawing on Goldratt’s Theory of Constraints, every system has exactly one bottleneck, and improving anything that isn’t the bottleneck creates local efficiency that doesn’t translate to system-level output. In most software organisations, the constraint isn’t in engineering – it’s in the upstream processes that control how demand enters the system.
What is technical debt as business risk, and why does it matter?
Ward Cunningham coined ‘technical debt’ in 1992 as a precise metaphor for deliberate deferral – ship simpler now, refine later, with the intention of paying it back. Over time it came to describe accumulated engineering problems with no owner and no plan, which business leaders consistently fail to fund because it sounds like an internal department concern. Reframing these issues as business risks – with formal options, implications, and register entries – shifts ownership to people with the authority to act and frees engineering teams from carrying unresolved problems they can see but cannot fix.
What is vigilance decrement in AI-assisted development?
Vigilance decrement is a documented cognitive phenomenon, studied in aviation safety and industrial monitoring, in which humans monitoring a process passively catch substantially fewer errors than humans actively participating in building it. In AI-assisted development, placing an engineer in the review loop for AI-generated code provides less safety coverage than it appears to. The more reliable approach is building automated critic systems – checks for specific known failure modes like accessibility, security, and design compliance – making quality enforcement a property of the system rather than a function of sustained human attention.
How does AI change the structure of software engineering teams?
As AI accelerates code generation, the engineering constraint moves from writing to deciding: how is the system architected, what failure modes does it tolerate, what does quality enforcement look like at scale. Engineering work shifts from checking individual artefacts to building systems that ensure all artefacts meet quality standards. Organisations that treat AI adoption as a coding productivity multiplier without addressing the structural and decision-making layers around the code tend to produce faster versions of whatever problems they already had.
Related articles
Real outcomes, for real Australian organisations.
How we built AI-powered personalisation and retail media for one of Australia’s largest supermarket chains.