AI is fundamentally changing what it means to be a software engineer. As coding agents take over more of the writing, verification is quickly becoming where much of our time and focus is spent - and it isn’t the job most of us engineers signed up for. For the last eighteen months I’ve been wondering what could take some of that weight, and my gut keeps pointing back to something I fell in love with at university twenty-three years ago but never once got to use.

Twenty-three years ago

As a child I loved maths for its purity, and computers and programming for their power. These two passions stuck with me as I grew older, so when I went to university I naturally chose to study both mathematics and computer science.

If I’m honest, the papers I enjoyed most were the maths ones, especially those built on logic and proof - discrete mathematics, mathematical logic, combinatorics. The process of working out a proof was immensely satisfying - step by step, each move following logically from the last until the whole thing fit together like a puzzle. What a nerd, right? But when I realised that those same proofs could be applied to programs and code… well, now we’re talking!

The formal methods papers at Victoria University of Wellington were where that realisation happened for me - specifically, COMP425 (Computational Logic), COMP426 (Formal Software Development), and COMP473 (Formal Aspects of Concurrent Systems). There were only two or three of us in those classes so they almost didn’t run them, but I’m so glad Lindsay Groves did anyway.

I loved that work in a way that’s hard to explain. Formal methods is the umbrella for a lot of things - specification languages, computational logic, refinement - and I loved all of it. But it all comes together in verification: proving that a program does what its specification says.

Back in those days, we did this type of work by hand. I don’t remember using any software or tooling to help at all, actually. Derivations, proofs, refinement steps, all worked out on paper. It took a while to get right, but when you did, it was right. Not “the tests pass” right. Not “it worked in staging” right. Provably, mathematically right. And that’s where the satisfaction came from. I kept those assignments for years afterwards and would occasionally reopen them just to marvel at that certainty.

There are two words that appear often in these papers: specification and verification. I find it fascinating, and somewhat serendipitous, that these are the same words our industry now reaches for as AI writes more and more of our code. Is it just a coincidence? I don’t think so.

Taking a punt

About eighteen months ago I saw Erik Meijer posting about formal methods in the context of AI on X. I didn’t know Erik personally, but I took a punt and messaged him about it. If you’ve been in this industry a while you’ll know his work even if you don’t know his name - LINQ, Rx, decades of programming-language contributions at Microsoft and Meta.

To my surprise, he replied almost immediately, with kindness and reading material. Erik saw the opportunity early and started building a language and a runtime that put formal methods to work on AI-generated logic - Universalis and Automind. How awesome is that?

I’ve been tracking Erik’s work carefully ever since. With that foundation in place, he’s now going after the risks that agents bring with them: Guardians of the Agents makes a great case for why agentic AI needs proof, not just guardrails, and his newest, In Code They Think; In Proof We Trust, shows how to prove an agent’s plan safe before a single tool executes. All of this makes perfect sense to me, even if the details feel frustratingly out of reach - I haven’t had the chance to work with formal methods since those papers at university twenty-three years ago.

Then earlier this year, I got to meet Erik in person. We were both speaking at IT Revolution’s Enterprise AI Summit in San Jose, and during one of the breaks I went and found him, laptop in hand. I wanted to show him my COMP473 assignments - proof, of sorts, that once upon a time I knew how to do this stuff, and that I just needed a way back in. His response was: “Why don’t we try something. Do you have Claude Code? Open it up.” So we did. We pointed it at one of the hand proofs from 2003 and watched it re-prove the whole thing with today’s tools - model checkers, solvers, the lot. Pages of careful hand-worked reasoning, mechanically verified in the space of a coffee break. I’ll never forget it - I was like a kid in a candy shop, vibe-verifying with Erik Meijer himself!

And I wasn’t the only one at that summit starting to think this was becoming viable, maybe even required.

The signals

There are more and more signs that formal verification might finally be earning its place in mainstream software development. Amazon recently announced that they’re investing in the Lean Focused Research Organization, and their reasoning is the clearest statement I’ve seen of why this matters more now than it ever has:

As AI agents increasingly make decisions that move money, approve claims, and operate critical infrastructure, the standard approach to software testing is no longer sufficient. Testing checks the cases you thought of, but there is a fundamentally different approach: mathematical proof, which shows with certainty that a system cannot behave incorrectly, no matter what inputs it gets.

Startups are forming around the idea. Midspiral describes itself as “the correctness layer for AI-generated software”, which is about as direct a statement of the thesis as you’ll find. Their open-source lemmafit puts a verifier - built on Dafny - right in the Claude Code loop, so the AI has to prove its code correct before anything compiles. I took it for a spin recently, and watching a solver prove a small theorem from a one-sentence prompt brought back that old feeling of certainty. Very cool, and well worth a play in your next Claude Code session.

Well-known voices in tech are turning their attention to it too. Martin Fowler’s notes from the second Thoughtworks Future of Software Development retreat recently described property-based testing and formal methods as the “computational sensors” of harness engineering. And just this week, Gergely Orosz had Hillel Wayne on The Pragmatic Engineer for a full episode on formal methods.

And away from the spotlight, I keep coming across individuals who are reorienting their careers toward this space, some going as far as leaving industry jobs for PhDs. The group is still small, but it is growing.

Why now

You can think of the software development lifecycle as a system. With AI, we’ve massively increased the inflow of generated code into the system, and it’s now piling up at the next step - code review. Review has become the new bottleneck, but not only because there’s far more to review. When engineers no longer write the code themselves, review is the first real opportunity they get to understand the system being built. So the pressure on that one phase is enormous: much more code, needing to be read much more carefully, both for errors and for understanding. Organisations and researchers alike are trying to work out what to do about it, and if we somehow manage to fix that bottleneck, testing will be the next one.

The constraints in the system are still there, they’ve just moved downstream.

One common response is to ask engineers to simply review more, and more carefully. But Deming told us long ago that you cannot inspect quality into a finished product, and Lisanne Bainbridge told us in 1983 why asking humans to sustain vigilance over an automated process is a losing game: we’re bad at monitoring, and the skills we aren’t practising atrophy while we watch. In any case, a tsunami of code review - and, worse, review of AI-generated slop - is not the job any software engineer signed up for. It’s not creative, it carries enormous responsibility, and we have forty years of human-factors research saying we can’t do it well.

Nor can the answer simply be more tests. Faros AI’s “Acceleration Whiplash” report found that the probability of a production incident per merged code change has more than tripled - and that’s with all the unit and integration tests we already write, plus the ones AI now writes for us. We seem to have hit a threshold where throwing more tests at the problem isn’t materially shifting the needle.

There’s an accountability squeeze in here too, and it’s the productivity-experience paradox all over again: organisations are pressing engineers to use AI to go faster, then holding them accountable for code they can’t possibly review at the level being expected of them. Responsibility without the means to discharge it - no wonder anxiety is rising. That’s the experience cost hiding underneath the speed.

Every response to this new bottleneck currently available is a trade-off against something else. Inspect harder, and you buy vigilance failure and skill atrophy. Slow the pipeline down to review properly, and you hand back the throughput gains. Wave it through, and you get the quality decline that’s already showing up in the data. There is no free option inside the current equation. The only way out is to change it - not the same steps faster, but a different kind of step.

Proof as a first-class citizen

I think that step is formal verification - correctness established by proof rather than by sampling - as a legitimate, first-class citizen of the software development lifecycle.

There are two ways I think formal verification can help make agents more trustworthy, and I’m interested in both.

Agentic engineering

The first is in agentic engineering: using agents to produce code as an artefact, which a human still reviews, ships and stands behind. The case here is one of quality assurance. As more code is generated by AI, proof is the only assurance mechanism that scales with the machines producing it. Instead of asking engineers to review more carefully, or piling yet more tests onto the problem, verification becomes a step in the build, a bit like static analysis but with proof behind it, and the closer that step is to where the code is generated, the better. That’s exactly where lemmafit sits.

The thing about proofs is that they are complete in a way that review and test suites can never be. As Edsger Dijkstra put it over fifty years ago, “program testing can be used to show the presence of bugs, but never to show their absence!”. A proof shows their absence, for every possible input at once.

But it’s not a silver bullet (because silver bullets don’t exist). People working in this space are quick to point out that while AI can help generate the proofs, coming up with the right specification is still hard, as it always was. Deciding what “correct” means assumes you understand the domain, the problem and the solution well enough to say so. That judgement - that we’re building the right thing - is basically validation by another name, and that has to stay human. I’d argue it’s one of the responsibilities we must keep, or we’ve really missed the point of building any of this at all.

Beyond the assurance itself, I’m just as interested in what proof could do for the eroding developer experience of the engineers supervising all that code generation. If proof carries the assurance, accountability becomes dischargeable again, resting on something sturdier than how carefully a tired human read the diff. That’s the side I may have something distinctive to say about, having spent the last three years studying what AI is doing to the lived experience of software engineers.

Agentic workflows

The second way reaches beyond the software development lifecycle altogether, into runtime. In agentic workflows, an LLM controls the flow of logic itself, generating code that gets executed on the fly by the harness it’s running in.

The problem there is more about security and governance: there’s real cyber risk in unsupervised, unverifiable agents taking actions in the world, and a serious governance question when nothing checks those actions at runtime. Periodic risk assessments and control checks were designed for organisations that change at human pace, and they don’t stand a chance against agents acting in milliseconds, thousands of times per hour. It’s exactly the angle Erik’s recent papers take aim at, and the reason I’ve become so interested in agentic control planes and governing agentic systems at scale. Machine-speed actors need machine-speed controls, and proof is the only one I can see keeping up.

Why it never caught on

Two things kept this work at the margins all these years, and neither was any doubt that it worked.

The first is the name. Put the word “formal” in front of anything and eyes glaze over. It sounds like quantum physics, people assume you must be an academic or a theorist, and they pretty much stop listening. It’s part of why the group of believers has stayed so small for so long.

There are people fixing that, though. At VUW, James Noble - one of my Honours supervisors - and his colleagues recently redeveloped their software correctness course around Dafny so that verification feels like a specially intense kind of programming rather than mathematics. Student retention went up, and the course earned its best evaluations in at least a decade. They make the case that formal methods are critical to the future of software engineering, and so must be an essential part of how we teach it. Either they were ahead of their time, or their timing was perfect - I must ask James which.

The second, and the real reason I never got to use any of this throughout my career, is pure economics. Everywhere I’ve worked - like most of the industry - the maths never stacked up. Testing and code review get you most of the way there for a fraction of the effort, classic 80/20, and chasing that last stretch of certainty the formal way would have cost more than it ever saved. That’s not a criticism, it was the right call. Formal verification stayed confined to the domains where failure is unthinkable: avionics, rail signalling, nuclear systems, verified kernels and compilers.

But the economics are what’s changing, and from two directions at once. The cost of not verifying is compounding, as agents pour out code at machine speed. And the cost of verifying is collapsing, because AI can now help write the proofs themselves. What remains tricky is getting the specs right, but AI is starting to help with that too. For the first time in my career, the maths might actually stack up.

From creation to verification, and back again

What we need is verification and governance that run at the same speed as the machines they’re checking, and I’m convinced proof can supply both. So my aim is to help make agentic work provable - what agents produce and what they do - in a form the industry can actually adopt.

In practice, that means building the machine that builds the machine - the harnesses we develop with, and the runtimes our agents operate in - with provable rigour baked right in, especially where the stakes are high. You could say this is just “shifting left”, and in a way it is. Verification stops being inspection after the fact and becomes part of the act of creation itself. Specifying what must hold, and proving it holds, become central to what it means to be a software engineer. And the spec stops being the kind of document that just drifts into fiction and becomes something the software can actually be held to.

None of that happens at scale while the rigour stays locked away with theorists and mathematicians though, so a big part of the work is making formal methods accessible to everyday working software engineers.

Get that right and the creation-to-verification shift my research found might start to reverse. Engineers get to create instead of inspect, keeping control of what they build, just in a different way to how we have in the past. And organisations may finally start to see the benefits they’ve been promised, because the use cases requiring more rigour become trustworthy enough to ship.

We keep saying that software engineering is being transformed, that we have to fundamentally reimagine it. So let’s actually do that!

An invitation

So that’s what I’m rekindling: a twenty-three-year-old love of proof, at a moment when the industry might finally need it. For what we ship, and for the people carrying the weight of it.

The first step I want to take is to scan in that whole box of old notes and assignments. I want to give it all to Claude Code and get it to help me re-learn what still holds, as a springboard into everything that’s changed since. I quite like the circularity of that - the technology making verification matter again is the same one helping me find my way back to it.

If you’ve read this far and haven’t been put off by the “f-word”, I’d love to hear from you. Whether you’re thinking about this too, building in this space, wrestling with these questions inside your own organisation, or just quietly curious like I was eighteen months ago, please reach out. Every time I’ve taken a punt and messaged someone in this space, I’ve been met with generosity - it’s that kind of community. So let’s talk, and maybe even build something awesome together.

Thanks for reading this post via RSS! 👋

The first post, The Middle Loop, focused on my first research question - where engineers spend their time and focus when they use AI to build software. The short answer is less time on most core development tasks, especially writing code, and slightly more time reviewing. The longer answer includes evidence of a new category of work, supervisory engineering work, sitting neatly between the inner and outer loops of software development.

This post is more about how that shift feels, which was the focus of my second research question - how does the use of AI coding assistants impact software engineers’ perceptions of their developer experience and productivity?

I described the study in that last post so I won’t repeat it all here. It’s worth noting that my study ran between October 2024 and April 2025, which in AI terms is already quite a long time ago. The landscape has shifted a lot since then, so it’s best read as a snapshot of that window. If you’re interested in a more detailed write-up of the methodology and results of these first two research questions, there’s a preprint paper available.

Measuring the feeling

Measuring productivity is tricky. For starters, as an industry, we can’t really agree on what it even means, let alone how to measure it well. DORA defined it as “the extent to which an individual feels effective and efficient in their work, creating value and achieving tasks.” in their 2024 Accelerate State of DevOps report, and that sounds about right to me.

Notice how they used the word feels? In that definition, productivity is already a perception, so I did the straightforward thing and asked participants to rate how their productivity had changed since using an AI coding assistant. Open-ended questions let them describe their experiences in their own words, which is where the participant quotes in this post come from.

For developer experience I needed more structure, so I used the DevEx framework created by Abi Noda, Margaret-Anne Storey, Nicole Forsgren and Michaela Greiler. It takes the fuzzy notion of how development work feels and splits it into three dimensions we can better reason about:

• Feedback loops: how fast, and how useful, the responses to your work are, whether from a compiler, a test, code review, or a colleague.
• Cognitive load: the mental effort it takes to get something done.
• Flow state: how seamlessly you can work and hold your concentration, free from interruptions.

I chose it for a few reasons. It’s the framework the industry has actually adopted (with entire DevEx teams built on the concept) largely because those three dimensions are concrete enough to operationalise where more comprehensive taxonomies aren’t. And there hadn’t been much research tracking how professional developers’ sense of these three dimensions shifted with sustained use of AI, which felt worth examining more closely.

Productivity went up - and stayed up

Productivity was the good news, and it stayed good news over the six-month study period. It was remarkably stable - 84% of participants reported AI improving their productivity at both timepoints. More than three-quarters of matched participants gave the exact same positive rating both times. Whatever else was going on, people felt like they were getting more done.

Developer experience drifted the other way

Developer experience is the more complicated half of the story. Most engineers were still doing fine but a growing minority weren’t, and the positive group appeared to be thinning out over time. To see how it was playing out, I sorted the matched participants into three groups based on how they felt AI had affected those three DevEx dimensions: a positive cohort who felt it had improved all three, a negative cohort who felt it had worsened at least one, and a mixed group in between - nothing worse, but not everything better either. Then I tracked how people moved between them over the six months.

The negative cohort nearly doubled, from 14% to 27%, and the positive cohort barely held. Only 37% of those who started there were still fully positive by the end. Engineers are feeling like they’re getting more done but are feeling worse doing it.

The negative cohort was quite sticky, too. Not one person who started in it climbed all the way back to fully positive; the best any of them managed was to claw back to neutral. But basically, once the experience soured, it tended to stay that way.

When viewed next to the chart above, you can see how productivity and developer experience appear to be diverging. Output is holding high and steady while the experience underneath begins to erode.

The coupling we took for granted

For a long time, research has told us that developer experience and productivity are related - that they travel together. That’s the core premise behind the DevEx framework, and the reason leaders have been told to focus on improving developer experience: improve that, and productivity will follow.

There’s something quite humane in that premise. It meant caring about engineers’ day-to-day lives wasn’t a trade-off against output. It was the output strategy. You didn’t have to choose between treating people well and getting results. The incentives lined up. It’s Deming’s 12th point made real, a call to “remove barriers that rob people in management and in engineering of their right to pride of workmanship”.

Unfortunately, this is exactly the coupling my data suggests may be breaking once AI enters the picture.

Interestingly, whether they move together depends on how you look at it. Compare engineers at a single point in time and they do. The ones with better developer experience also feel more productive. But follow the same engineer over the six months, and a dip in their experience wasn’t matched by a dip in their productivity. The correlation between change in flow state and change in productivity came out at 0.02, about as close to zero as it gets. And that’s the paradox: over time, with AI, developer experience and productivity appear to stop moving together.

Brian Houck, a Distinguished Scientist at DX who researches developer experience and co-authored the SPACE framework, thought the decoupling interesting enough to write about it and talk about it on the DX podcast. Having someone of his calibre take my finding that seriously is something I’m super excited about.

What this means for engineers

If experience and productivity really are decoupling with AI, will leaders still be able to justify caring about developer experience? I really hope so, but the case for investing in it was always that it paid off in output, and that’s exactly what’s now up for debate. In fact, we’re already seeing attention (and investment) shift toward agent experience: engineering better context and harnesses so the models themselves work more effectively. And if the returns now come from improving how the agents work rather than how the engineers feel, what happens to the human engineers?

Well, when their experience keeps eroding but their output doesn’t, nothing forces the problem to the surface. The dashboards look fine, but the people aren’t. But that hidden strain doesn’t just vanish. Where does it go, you might ask. You know where. Burnout and turnover, that’s where. It’s why Steve Yegge calls it the AI vampire - the tool that makes you far more productive while draining you dry.

Three dimensions, pulling in different directions

So what’s actually driving the decline? Developer experience didn’t deteriorate evenly across the three dimensions - one of them took the brunt of the hit while another actually improved.

Flow state took the steepest fall. The share rating it worse nearly tripled over the six months, from 7% to 20%, by far the biggest move of the three. One participant named it exactly: “less ‘in the zone’ time, because while code is being produced, I now find myself switching context more often.”

Cognitive load got worse too, though far more gently. Those rating it worse crept up from 6% to 9%. This is the part the demos don’t show you: the constant evaluation, the “almost right but not quite” suggestion that costs more to check and fix than it would have to just write yourself.

Feedback loops got better. This was the only dimension that improved over the study period. Makes sense too - now you can ask your AI coding assistant for help and have a working solution back in seconds. Gone are the days of hunting around on Stack Overflow for hours. One participant described work that would have taken three days getting done in three hours.

I do wonder if there might be a connection between feedback loops improving and flow state deteriorating. Think about it. AI now hands you a response every few seconds, but every response is a whole bunch of text and a little decision: read it, judge it, accept it or fix it, then prompt again. It’s a context switch, over and over, and it’s hard to stay in the zone when you’re switching gears that often. One participant put it quite succinctly: “This does break the flow, but still speeds up the overall process.” You feel faster, but more interrupted, both true at once.

Something else moved over those six months too. At the first timepoint, the dimension that lined up most closely with feeling productive was flow state. By the second timepoint, it was the speed of the feedback loop, and flow state had almost dropped out of the picture. In other words, as AI took over more of the writing, what made engineers feel productive seems to have changed: at the start it went with being absorbed in a hard problem, and by the end it went with how fast the code came back.

Counterfeit flow

Since flow state took the hardest hit, it’s worth asking why. Orchestrating agents, or supervisory engineering work, can feel great: you’re moving faster, reaching further and achieving more with less. There’s almost a nice rhythm to it; the problem is that that feeling and real flow aren’t necessarily the same thing.

In his keynote at AI Engineer in Melbourne, right before mine, Jeremy Howard described what that feeling might really be. He pointed out that Mihály Csikszentmihalyi, the psychologist who gave us the idea of flow, also described a counterfeit cousin of it: junk flow, or dark flow. It can look a lot like the real thing, but it’s the opposite of good for you: you get hooked on a superficial version that feels like flow at first, then slowly turns into something you’re addicted to rather than something that helps you grow. And it’s no accident - casinos are designed to manufacture exactly this, hooking people through what’s called an illusion of control.

So what separates the two? Real flow is when a genuine challenge stretches your skills and you grow from it. Junk flow just keeps you pulling the lever. Prompting an AI can feel a lot like pulling that lever - sometimes it nails it, sometimes it hands you nonsense - but you keep going, chasing the next good result, even when you know you should probably just stop and do it by hand. The dopamine’s more in the anticipation than the payoff. We’ve all been there.

Output is one thing, the craft is another

At AI Engineer, I happened to meet Nicholas Gruen, who spoke to me about a philosopher called Alasdair MacIntyre. In particular, what Nicholas thought I might find interesting was MacIntyre’s framing of the internal goods of a practice - the skill, the mastery, the satisfaction you can only get by doing the thing itself - and external goods - money, status, output. MacIntyre warned that the external goods, the ones institutions trade in, have a habit of crowding out the internal ones. I’m really grateful to Nicholas for the introduction to his work - it gave me a much richer way to think about what I’d been seeing.

I think that concept also fits my data quite nicely. With AI, the external good, productivity, holds steady or climbs. The internal goods - flow, mastery, the joy of the craft - erode. AI is brilliant for the external goods and potentially corrosive for the internal ones.

How you feel about AI has a lot to do with which of these goods you’re chasing. If it’s the external goods you’re after, this technology is close to a superpower - more productivity, more output. But if you’re more interested in the internal goods - the figuring-out, the hours inside a hard problem - then it can really feel like a loss: it takes the part you loved and hands it to a machine, and what’s left is supervision and accountability. Yes, the output still arrives, faster than ever, but the bit that made it yours has been delegated away, and the pride and satisfaction of having done it yourself are gone. It’s this loss I was afraid of when I wrote about the software engineering identity crisis last year, and now it’s starting to show up in the data.

Designing what comes next

So what do we do with a finding like this? The instinct is to fix it, to stop the bleeding with better tooling that supports developer experience in this new world.

But if the craft is genuinely relocating - if the making is moving into orchestration - then the job is to define the new role and design it to be worth doing. That’s the argument behind a keynote I gave last month at that same AI Engineer conference, Craft in the Time of Agents: craft isn’t dying, it’s moving. And if the system is producing more output while eroding the joy and lived experience of being a software engineer, that’s a system-design problem, not a personal failing, and it’s ours to solve, deliberately, by building the roles people actually want to grow into.

Which leads me to a bigger question. Do the frameworks we’ve used to talk about developer experience in the before-times still hold with AI in the mix? Maybe they need rethinking, or maybe they need replacing altogether. They were built for a world where a developer’s work revolved around the production of working code. Flow meant being deep in the problem-solving, and often that meant building it yourself. Cognitive load meant holding a mental model of the solution in your own head, and feedback loops meant how quickly you could unblock yourself and get on to the next piece.

When code production is increasingly a machine’s job, and the human work is more about specification, judgement and verification, those constructs are measuring a job that’s materially different. Some of what I found - the supervisory engineering work, the productivity-experience paradox, the way “feeling productive” detached from flow - doesn’t sit neatly inside the frameworks we have.

Others are starting to wonder the same thing. Thoughtworks’ Ken Mugrage recently asked whether developer experience is dead, and landed where I have: not dead, but overdue for a rethink.

I think developer experience is starting to mean something different, and the ways we frame and measure it need to catch up.

In November I’m heading to another Shonan meeting in Japan built around exactly this, an academic gathering with the working title “Crafting the Future of Developer Experience”, and some of the people in that room helped build the frameworks we’re now questioning. I know I don’t have all the answers, but those are definitely the conversations I want to be in.

This post draws on my Masters research at the University of Auckland, supervised by Kelly Blincoe. A preprint paper covers the first two of the study’s research questions: how does AI shift software engineers’ perceived focus across development tasks, which I wrote about in The Middle Loop, and how does AI impact software engineers’ perceptions of their developer experience and productivity, which is this post. There’s more to come on the study’s other two questions - what AI is doing to how engineers grow their skills and confidence, and whether prompt engineering is (or was) becoming a core skill in its own right.

Thanks for reading this post via RSS! 👋

The point is: what you spend your time on defines what you think about. What you think about is what you practice. And what you practice is what you build skill on. The title said “software developer” but the daily work said something else entirely.

That’s why the first research question I wanted to answer as part of my Masters of Engineering at the University of Auckland, supervised by Kelly Blincoe, was about task focus. Are AI tools shifting where engineers actually spend their time and effort? Because if they are, they’re implicitly shifting what skills we practice and, ultimately, the definition of the role itself.

Over six months, from October 2024 to April 2025, I ran a longitudinal mixed-methods study with professional software engineers across 28 countries - 158 eligible participants in the first round, 101 in the second, with 95 matched across both. This is the first in a series of posts sharing what I found.

The Missing Time

I asked participants how their time allocation had shifted across six core development tasks: designing, writing code, refactoring, testing, debugging, and reviewing.

Five of the six tasks showed means below neutral - participants reported spending less time on almost everything. Writing code showed the strongest reduction, with 82% reporting less time by the second questionnaire. Reviewing code was the only task where engineers reported spending more time, and even that was only slightly above neutral.

These are perceptions, not stopwatch measurements, and people generally aren’t great at estimating time. But shifts this consistent, measured twice over six months, are still a meaningful signal.

Ok so engineers are spending less time writing code, no surprise there. But the standard assumption, that freed-up time flows upstream into design and architecture, didn’t hold. Time compressed across almost all six tasks, including design. Rather than trading writing time for design time, engineers reported spending less time on nearly everything.

So where is that time actually going?

Naming the New Work

The quantitative data revealed a creation-to-verification shift over the six month study period - the balance between creation-oriented tasks (writing, refactoring, designing) and verification-oriented tasks (reviewing, testing, debugging) tilted toward verification (p = 0.006, moderate effect).

But traditional categories like “reviewing” and “testing” didn’t fully capture what engineers were describing. It was the open-ended responses that told us a richer story.

“Mostly reading the code and directing AI on the right way”, explained one engineer. Another described spending more time asking "‘is this code correct’, ‘is it maintainable’, ‘is it secure’ and ‘is this just probabilistic hallucination’". A third stated it quite simply: “I ask AI to make changes first and review them before accepting or rejecting them”.

Some participants did label this change in their workflow as “more design thinking”, but their descriptions generally told a different story - directing, evaluating, correcting. That’s supervision, a qualitatively different form of work that traditional software development lifecycle models don’t have a category for.

In my thesis, I propose a name for it: supervisory engineering work - the effort required to direct AI, evaluate its output, and correct it when it’s wrong.

• Directing: specifying intent, crafting prompts, managing context, codifying standards into reusable agent instructions and skills, and iterating when output misses the mark
• Evaluating: reading AI-generated output and deciding what to accept, modify, or reject
• Correcting: fixing errors, integrating output into existing code, and maintaining consistency across the codebase

This work is emerging because someone has to be accountable for what the AI produces, and how much of it an engineer does depends on how much they trust the AI’s output and how critical the work is.

The Three-Loop Model

On the long flight to The Future of Software Development retreat in early February, I was turning this over in my head. How do you explain supervisory engineering work to practitioners in a way that maps onto their existing mental models?

It occurred to me that we often refer to “loops” in software development - the inner loop and the outer loop:

• The inner loop is where the craft lives: write code, build, run, test, debug. Tight, fast, local. This is what TDD and better IDEs optimised.
• The outer loop is the broader cycle: commit, code review, CI, deploy, monitor, feedback. This is what DevOps and CI/CD optimised.

What if supervisory engineering work lives in a new loop between these two loops? AI is increasingly automating the inner loop - the code generation, the build-test cycle, the debugging. But someone still has to direct that work, evaluate the output, and correct what’s wrong. That feels like a new loop, the middle loop, a layer where engineers supervise AI doing what they used to do by hand.

This layer is still largely unoptimised. Engineers are assembling it from chat windows, terminal agents, and IDEs that weren’t designed for supervisory work. That’s the frontier, and people are starting to build for it.

Birgitta Böckeler, who was also at the retreat, recently described what she calls harness engineering - the tooling, constraints, and control systems teams build to keep AI agents in check. As she notes, OpenAI’s own team has said: “Our most difficult challenges now center on designing environments, feedback loops, and control systems.” Steve Yegge’s Gas Town project takes a different angle, building infrastructure for engineers to verify what agents produce.

Several concepts are circling around this space. Context engineering, which I’ve written about previously, describes the practice of shaping what AI sees and works with. Harness engineering describes the infrastructure you build to constrain and guide it. Supervisory engineering work describes the activity itself - the directing, evaluating, and correcting that engineers do. The middle loop is where all of this lives: the structural layer between the inner and outer loops where that oversight happens.

I was glad to be able to raise this topic at the retreat, and even more so that it resonated with the other attendees. The retreat’s published findings report adopted the middle loop as what it called “the retreat’s strongest first-mover concept”, noting that “nobody in the industry has named this yet”. I won’t pretend it didn’t feel pretty good to see my contribution land so strongly.

What It Actually Feels Like

The experience of working in this layer is uneven. For some engineers, AI coding assistants compress the effort-to-reward loop to seconds - prompt, result, prompt, result - and it feels exhilarating. For others, the same compression is disorienting, the craft they spent years building reduced to reviewing someone else’s output. Most are somewhere in between, figuring it out as they go.

The positive side is real. 84% of the participants in my study reported productivity gains. Engineers described completing in hours what used to take days, feeling more confident tackling unfamiliar tools and languages, and spending less time on the mechanical grind. As one put it: “boring mechanical tasks like refactoring files, updating tests, adding translations, creating test fixtures are 10x less effort with AI assistants”.

But software engineering has always offered something beyond productivity - tight feedback loops where you write code, run tests, refactor, and see your own work succeed. Those loops provide constant micro-rewards: the dopamine hit of a test finally passing after an hour of frustration, the pride of “I figured this out myself”. That’s what kept many of us hooked from the very beginning.

Supervisory work replaces those signals with something more ambiguous. You’re reading more than writing. You’re evaluating output that’s mostly right but sometimes wrong in subtle, dangerous ways. The code works, but you didn’t write it. The test passes, but you didn’t wrestle with the logic. It feels like work, but it doesn’t quite feel like your work.

And to that end, the data showed that the proportion of participants reporting negative developer experience nearly doubled over six months, rising from 14% to 27%, even as productivity held steady. I call this the productivity-experience paradox, but that’s the subject of the next post.

Why This Matters

A lot of software engineers right now are feeling genuine uncertainty about the future of their careers. What they trained to do, what they spent years upskilling in, is shifting - and in many ways, being commoditised. The narratives don’t help: either AI is coming for your job, or you should just “move upstream” into architecture and “higher value” work. Neither tells you what to actually do on Monday morning.

That’s why this matters. There is still plenty of engineering work in software engineering, even if it looks different from what most of us trained for. Supervisory engineering work and the middle loop are one way of describing what that different looks like, grounded in what engineers are actually reporting.

Will the middle loop itself get compressed away? Maybe. Things are moving fast, and every abstraction layer in computing’s history eventually compressed the one before it. But right now, this is where the work is, and the skills it demands (judgement, verification, accountability) transfer upward regardless of what the work looks like next year.

If we can describe it, we can start to work out what good looks like. What skills does it require? How do you get better at it? What does a career path look like when the work shifts from creation to verification, from writing to supervision? These are practical questions, and they need practical answers, but they’re hard to answer when the work doesn’t have a name.

What you spend your time on is what you practice, and what you practice is what you build skill on. If the work is shifting to supervision, then that’s the craft now. We’re building the machine that builds the machine. And it deserves the same investment in tooling, practice, and professional development that we gave the inner and outer loops before it.

What Comes Next

This post is the first in a series drawing on my Masters research and the ideas emerging from it.

Coming next: the productivity-experience paradox - when productivity holds steady but developer experience erodes, and what that means for the people doing the work.

A paper based on this research has been submitted for review, and I’ll be speaking about these ideas at the IT Revolution Enterprise AI Summit in April and as a keynote at Web Directions AI Engineer in June.

Thanks for reading this post via RSS! 👋

We ended up in a brief conversation about the future of software engineers. He was learning memory management for a trading firm. He thought AI-generated code was “pretty crap”. He’d also noticed, though, that engineers around him were losing their jobs.

The same questions I’d just spent two days exploring at the retreat, surfacing unprompted between strangers somewhere over the Pacific.

About 40 of us - practitioners, researchers, technical leaders from around the world - gathered in Deer Valley, Utah, for an invite-only retreat on the future of software development. The event was hosted by Martin Fowler and Thoughtworks, and held in the same mountains where the Agile Manifesto was written 25 years ago - with some of the original signatories in the room. Not an attempt to reproduce that moment, but an acknowledgement that the ground has shifted enough to warrant the same kind of conversation.

The format was an unconference. No presentations. No agenda handed down from above. Participants proposed sessions, voted with their feet, and talked. Over 30 sessions ran in parallel - far more than any one person could attend. The ones I was in were fascinating, and comparing notes with others afterwards revealed just how much convergence there was across sessions I’d missed. A long way to go for two days - but worth every hour.

Here’s what I took away.

Nobody Has This Figured Out

This was, for me, the single most important realisation.

I walked into that room expecting to learn from people who were further ahead. People who’d cracked the code on how to adopt AI at scale, how to restructure teams around it, how to make it work. Some of the sharpest minds in the software industry were sitting around those tables.

And nobody has it all figured out.

There is more uncertainty than certainty. About how to use AI well, what it’s really doing to productivity, how roles are shifting, what the impact will be, how things will evolve. Everyone is working it out as they go.

I actually found that to be quite comforting, in many ways. Yes, we walked away with more questions than answers, but at least we now have a shared understanding of the sorts of questions we should be asking. That might be the most valuable outcome of all.

The Increasing Cognitive Load to Be Aware Of

Something that came through in conversation, not just in the sessions, was that several people who are going hardest on AI openly admitted that it’s exhausting them.

There’s a pattern emerging. You spin up one AI coding agent, give it a plan, and while it loops you spin up another. Then another. It’s genuinely addictive - in fact, several people used that exact word. The problem comes when they all start returning at once with pages and pages of output for you to review. The cognitive load is immense, and it’s not being talked about enough.

We’re burning out on the very thing that excites us. The very technology that promises to make us more productive is, for some, creating an unsustainable pace. Because the people experiencing this most acutely are often the most senior and most enthusiastic, it’s easy to miss the warning signs.

I found this one of the most honest and human moments of the retreat - the quiet admission, between sessions, that this is hard in ways we didn’t expect.

What I Brought to the Table

I proposed two topics of my own, drawing on findings from my Masters research into the impact of AI on software engineering. The first explored what I’m calling supervisory engineering work - a new category of work emerging as we delegate more of the coding to agents. The second examined whether productivity and developer experience, long assumed to move together, might be starting to diverge. Both sparked discussions that carried well beyond the sessions themselves.

Eight Themes That Kept Emerging

Across those 30+ sessions, certain threads kept surfacing independently. Different people, different contexts, converging on the same questions.

1. The Bottleneck Has Moved

For some, the constraint is no longer engineering capacity. Agents can burn through backlogs at extraordinary speed - but then they hit what one group called ’the network of blocks’. Slow decisions. Organisational dependencies. Human-speed discovery. Market absorption.

One of the most striking comments from the retreat: ‘Humanity is not ready for this much software’. The customer doesn’t want a new version of the app every day. We can produce more than the system around us - and the world beyond it - can absorb. Decision fatigue is becoming the real bottleneck, not engineering throughput.

2. What’s the Artifact if Not Code?

Multiple sessions questioned the primacy of source code. If agents can regenerate code from a specification, is the code the durable artifact - or is it the domain model, the test suite, the intent?

Ideas that surfaced: code as ‘just another projection’ of intended behaviour. Tests as an alternative projection. Domain models as the thing that endures. One group posed the provocative question: what would have to be true for us to ‘check English into the repository’ instead of code?

The implications are significant. If code is disposable and regenerable, then what we review, what we version-control, and what we protect all need rethinking.

3. Trust, Care, and What’s Lost in Abstraction

This was the emotional thread that the room kept circling without quite naming it directly. Several sessions touched on what happens when we lose intimacy with the systems we build.

Concepts that surfaced across these discussions:

• Cognitive debt - we skim everything because AI unlocks such volume, but now knowledge is losing its stickiness. An extension of technical debt into the mind.
• Trust debt - the gap between what we produce and what we deeply understand about what we’ve produced.
• Active knowledge decay - skills atrophying when you stop doing the work hands-on.
• Care - humans and LLMs have fundamentally different levels of long-term care about a system. The work to keep code habitable and clean isn’t well understood by those paying salaries.

These aren’t just process problems. They’re about identity, meaning, and what it feels like to be responsible and accountable for something you didn’t fully build and don’t fully understand.

4. Platform Engineering as the Enabling Layer

Across security, governance, and adoption discussions, platforms kept emerging as the thing that makes everything else possible. The pattern: create safe defaults (the ‘pit of success’), embed guardrails, and give teams a fast but safe path.

The argument isn’t for more controls. It’s for better defaults - so that speed and safety aren’t in tension. One group observed that the things that make agents effective (clear standards, good documentation, well-structured code) are the same things that made developers effective. We spent years advocating for Developer Experience and often struggled to get investment. Now organisations are keen to invest in the same things - but for agents. Is ‘Agent Experience’ the new DevEx? And if so, might humans quietly benefit too?

5. How Do You Conceptualise Agents?

We don’t have a good taxonomy for agents yet. Are they more like APIs or more like humans? They’re not deterministic enough for the first framing, but anthropomorphising them is risky too. One participant offered a third option: they’re more like chemical vats - non-deterministic processes best managed through engineering constraints. Some companies are starting to add agents to their organisational chart. Others are talking about ‘Agent HR’ - performance management and cost management for non-human workers.

This might seem like a semantic debate, but it shapes everything downstream. If you see agents as tools, you govern them with technical guardrails. If you see them as team members, you invest in onboarding and culture. The industry hasn’t settled on a mental model yet, and that ambiguity is slowing down coherent governance and investment decisions.

6. Organisational Readiness Gates Everything

This echoes something we learned the hard way with microservices: without a certain level of organisational maturity, the technology makes things worse, not better. The same is true with AI.

AI amplifies existing conditions. Organisations that already had strong teams, good platforms, and clear governance got faster. Organisations without those foundations got messier. Several groups converged on the idea that the first year of AI adoption should focus on preparing the system - platform foundations, governance, AI fluency uplift - rather than expecting broad productivity gains immediately.

7. The Human Role is Being Redefined - But Not Yet Designed

Everyone agrees the role of the software engineer is shifting. Nobody has a clear design for what it shifts to.

Sessions explored this from multiple angles: what should a staff engineer spend their time on now? How does education need to change? What happens to juniors, or mid-career engineers, whose primary value was in implementation detail? There’s a category of work emerging around supervising, orchestrating, and evaluating AI output - a ‘middle loop’ between the increasingly automated inner loop of coding and the outer loop of delivery. But the skills, pathways, and even the dignity of this new work haven’t been designed. We’re stumbling into it rather than shaping it.

8. The Ledger as a Convergent Insight

In at least four separate conversations - spanning agentic operating systems, production operations, enterprise adoption, and hallway chats - people independently arrived at the same idea: we need a complete, verifiable record of everything agents do. Every step taken, every change made, with the ability to roll back.

The framing varied. Some described it as a work ledger analogous to a financial blockchain. Others as an audit trail for verification and accountability. Others as a unified log aggregating across infrastructure, software, and network layers. But the core insight was the same: if we’re going to trust agents with real work, we need a ledger that tells us exactly what they did and why. When this many people reach the same conclusion independently, it’s worth paying attention to.

Why It Mattered

I care deeply about this profession and the people in it. It’s why I’m researching this for a Masters degree, and it’s why being there mattered to me.

Being invited to this retreat - and getting to spend two days in conversation with some of the most respected technical leaders in the world - was a genuine privilege. The hallway conversations, the dinners, the breakfast debates. The moments where someone you’ve read and admired for years turns to you and says, ‘That’s a really interesting idea’. There were some familiar faces, but I came away with many new friendships and a lot to think about.

The organisers weren’t trying to create a new Agile Manifesto. But there was an unspoken sense that the ground has shifted enough that we need new shared language, new principles, new ways of thinking about how we build software together. We didn’t leave with those. Not yet. But I’m grateful to everyone in that group for their openness, their honesty, and their willingness to keep working on it together.

At the close, when the organisers offered the mic to anyone who wanted to share a takeaway, I took my chance. I challenged the group - all of us with platforms and voices - to help the current and next generation of engineers find their way. Not by reassuring them that everything will be fine, but by getting better at describing the new problems they get to solve now that writing code isn’t the main one anymore. There are many engineers out there who were hired to write code and are now being told to outsource that to AI. They deserve more than platitudes. They deserve us doing the hard work of defining what comes next.

But we also left with something that might matter more right now: the shared recognition that nobody has this figured out, and the commitment to keep the discourse open. Because this wasn’t the end of an event. It was the beginning of a much longer conversation.

Thanks for reading this post via RSS! 👋

2025 was bigger. It challenged me in ways I hadn’t expected, opened doors I didn’t know existed, and at times left me wondering how I was going to fit it all in. I felt constantly busy, rushing from one thought to another, building on momentum, but at a pace that sometimes caught me off guard.

More than anything, it was a year dominated by thinking. Not the casual kind that floats in and out between meetings, but deep, sustained, sometimes overwhelming thinking. The impact of AI was a central theme throughout, not least because of my master’s research. My role at Westpac NZ evolved too - I pivoted to focus on enabling safe and responsible AI, spending a lot of time on risk and governance frameworks. But I also spent a lot of time thinking about the more human impacts of AI and what it’s doing to the value of knowledge work. What started as curiosity tipped into immersion. And immersion, at times, tipped into saturation.

The Thinking Spilled Into the World

That thinking didn’t stay private for long. I was invited to speak at several events throughout the year, some of which I had to turn down (a full-time job and a master’s degree don’t leave much room for extras). Looking back, I delivered a talk, joined a panel or recorded a podcast every month except a couple - no wonder I felt so busy! Public speaking is getting easier with practice, but it’s still time-consuming. Worth it, though, for the moments when something lands - when you see a lens shift or a new thought take hold.

The highlights were delivering my first closing keynote at the DevOps Summit Victoria in Melbourne, Australia and my first opening keynotes at the YOW! Tech Leaders Summit across three cities: Brisbane, Sydney, and Melbourne.

Something new this year was being asked to write. I’ve always found writing a challenge. Words flow so fluidly in my mind, but when I come to write them down they don’t hold the same weight. Keeping a blog has been a way for me to practice converting my endless thoughts into something structured that others might find value in, but it’s not without effort. Being asked to contribute to academic papers, thought-pieces and a chapter for an upcoming academic book (more on that later) was new - and honestly, a bit surreal.

Naming the Identity Crisis

Speaking of writing, shortly after the DevOps Summit in March, I wrote a blog post that had a much larger effect than I could’ve imagined - The Software Engineering Identity Crisis. It was the culmination of months of thoughts, conversations, and a feeling that things were changing in deeper ways that weren’t being spoken about clearly enough.

The response truly surprised me. Not just the scale of it, but the nature. Dozens of people reached out to say it resonated with them. To thank me for putting into words something they’d been struggling to articulate. To tell me they felt less alone. Others invited me to speak about it at events and on podcasts. The reach was significant - almost 65k views and growing daily. I’m still processing the impact this somewhat personal piece had on the wider tech community. It also helped me to see that the discomfort I’d been feeling wasn’t personal - it was collective.

More recently, Eirini Kalliamvakou’s GitHub Octoverse report on the new identity of a developer actually referenced my writing and research as aligning with their own findings. Seeing my work cited alongside their interviews with advanced AI users was surprising and exciting, a quiet but meaningful validation that my thoughts weren’t just resonating, they were part of a much larger pattern being observed across the industry.

Why AI Consumed So Much of the Year

The underlying technology is incredible, advancing at ridiculous speeds. But what really drew me in was the pace of adoption. ChatGPT landed in late 2022 and became a household name almost overnight. Three years later, it has over 900 million active weekly users. And that’s just one of many. This kind of diffusion is unlike anything I’ve seen before.

What’s been harder to watch is how many businesses are tripping over themselves to adopt these tools without really understanding them. Interest in MCP servers kicked off around March 2025, with agentic AI following close behind.

Old mental models of cyber security, risk and governance are breaking down. They simply can’t scale to handle the new dynamics. The big promises of productivity depend on autonomy - which in practice means the gradual outsourcing of decision-making to AI. Think about that for a moment. We’re handing over decisions, not just tasks. That has real implications for responsibility and accountability - and I’m not sure we’re thinking about it carefully enough.

But there’s also something genuinely exciting here. A lot of people still don’t realise that LLMs are essentially read-only - they don’t “learn” the way many assume. What feels like learning is actually clever engineering: conversational history, context management, tool calling, agent orchestration. This emerging “AI Application Layer” presents entirely new problems to discover and solve. I wrote about this recently and hope to spend more time on it in 2026. It feels like a sort of renaissance is happening in tech, and I’m here for it.

Finding My Tribe

Besides speaking at conferences, I also attended a few. For many years, conferences felt stagnant. Most talks circled around the same old topics: microservices, cloud, devops, team topologies. Now all anyone wants to talk about is AI - which funnily enough, many find quite frustrating. There’s just a lot to cover, and I for one am happy to listen!

In a way, AI has created a strange sort of gift: shared uncertainty. Many of us have similar questions but nobody has all the answers. This makes the conversations more honest and more exploratory. Two highlights for me were attending ETLS in Las Vegas, and my first Dagstuhl-style academic meeting in Shonan, Japan. Two very different worlds - industry and academia - but both felt like finding my people.

ETLS was energising and expansive. Three full days of thought-provoking talks and conversations with hugely influential industry leaders like Gene Kim, John Willis, Kent Beck, and many others. What struck me the most was how willing they were to share their concerns around securing AI. When Jason Clinton, CISO of Anthropic, states unashamedly that we’re being asked to deploy this technology faster than they can secure it, you know we’re dealing with something pretty serious. A recurring thread was that AI amplifies existing engineering capability - it doesn’t replace foundations. Teams with mature practices see the largest gains; those without them struggle. Kent Beck captured the tension well: AI can accelerate feature delivery, but without care, it consumes optionality - the ability to adapt and evolve systems over time. It certainly reaffirmed that the right questions are being asked and that I’m not alone in asking them.

Shonan was something else entirely. I’d been invited because of my master’s research topic - one of 33 attendees, and the only one without “Dr.” or “Professor” in front of my name. That gap felt wide at first. At the welcome banquet on the night before the meeting started, I awkwardly introduced myself too lightly - “part-time master’s student”. I suspect I was pegged as a bit of a novice in my field. I didn’t correct it.

The turning point came on day one. While others sketched future architectures on whiteboards, I walked to another board and drew the present: the agentic tools already in use in industry, what they can and cannot do, and how fast things are moving. I described my own workflow and the tools I use daily - Claude Code running in Windsurf, that I talk to using Wispr Flow. That drew some attention. When we reconvened, I was asked to share more. By day two, I was being referred to as an “oracle” and being asked to lead breakout group conversations. That reversal had a certain narrative symmetry to it.

What emerged from the week was bigger than any single conversation. The room started by debating “IDEs with AI” and ended by renegotiating what counts as programming, what counts as the artefact, and what role humans keep when systems can build themselves. My contribution was to anchor the discussion in reality: agentic workflows already exist in practice, the bottlenecks are shifting, and our tools and definitions are behind the frontier.

Shonan gave me a lot more than new ideas. It recalibrated how I see my place in the research world. Not outside it. Not fully inside it. But legitimately between. It also introduced me to some genuinely brilliant and thoughtful people - ones I hope to stay connected with. And I’ll have good reason to: an invitation to contribute a chapter to an academic book emerging from the meeting - From Integrated to Smarter Development Environments. This chapter sits at the hinge between the technical evolution of IDEs and what that evolution means for the people who work inside them. It’s about how smarter environments are reshaping the role, responsibilities, and identity of the software engineer - a thread that runs through almost everything I’ve been thinking about this year. First draft is due in March, so that’s another challenge for the first few months of 2026.

The Long, Quiet Work

Running alongside everything else was the master’s. The second survey. Endless analysis. Writing and rewriting. Doubt. Iteration. I won’t lie - it’s been a slog. Switching gears into “researcher mode” after a full day at work is exhausting in a way I hadn’t anticipated. None of the leave I’ve taken over the past couple of years has really been a break. I’m on the home stretch now though, with just some final refinements to go.

And yet - it’s also been a privilege to finally do this degree I’ve been promising myself I’d come back to for over 20 years. I’m glad I waited. I don’t think I could’ve picked a better topic or moment to study it. The research has become a genuine fascination, one that’s woven itself into my work, my talks, my conversations, and my thinking. I wouldn’t change a thing.

What Gave Way

Zooming out, some patterns emerge, and not all of them are comfortable to acknowledge. I read fewer books than I’d hoped (though no shortage of papers, articles, and blog posts). I exercised far less than I’d intended. For a while there, I convinced myself that walks and the occasional yoga session counted. They don’t. Not really. There were also some personal things this year that took more out of me than I expected. I won’t go into detail, but let’s just say that life doesn’t pause just because everything else is busy.

Towards the end of the year, I did something different: a fitness retreat. It was hard, humbling, and unexpectedly fun. It was also a stark reminder of just how much I’d been neglecting the physical side of things while the mental side ran at full speed. The mind got a lot of attention this year. The body did not. The irony isn’t lost on me - a few years ago, all I wanted was more time to think. Now, I sometimes crave time not to. Be careful what you wish for, I suppose.

Looking Ahead to 2026

If 2025 was a year of immersion, I want 2026 to be a year of intent. Finishing the master’s should free up space - not just time, but cognitive bandwidth. I’m looking forward to having my evenings and weekends back again. But more than that, I want to be far more intentional about how and where I spend my time. This year I absorbed a lot - I read, I watched, I listened, I spoke, I wrote, I thought, constantly. But much of it was reactive, riding the wave wherever it took me, driven by curiosity and opportunity rather than any deliberate structure. That’s not a bad thing, but it’s not sustainable either. In 2026, I want to organise what I’ve learned. To turn a year of intense thinking into clearer mental models and frameworks that I can share with others. To help people navigate AI-driven change more deliberately. There’s a lot in my head, and it needs tidying up.

I also want to be more intentional about which topics I go deeper on. Active Inference is one - it underpins so much of what I’ve been grappling with around how systems reason, adapt, and act under uncertainty, and I want to understand it better. Further out, there’s a pull back towards quantum computing, which feels closer to practical relevance than it has in some time. And honestly? Exercise needs to become part of the system, not the wish list. I’ve said this before, but this time I mean it. (Famous last words…)

Surfacing

2025 wasn’t tidy. It wasn’t balanced. And I’m not going to pretend otherwise. It was demanding, expansive, and formative - a year of deep immersion that challenged me, surprised me, and changed how I think about where I belong and what feels worth building next.

Now it’s time to come up for air. Here’s to a year of intent.

Key Accomplishments of 2025:

Talks:

• Closing keynote: The Future Engineer: Redefining Software Engineering in the Age of AI at DevOps Summit Victoria in Melbourne, Australia, on March 13
• Am I Still a Software Engineer If I Don’t Write the Code? at AI Native DevCon remotely, on May 13
• Opening keynote: The Duality of AI in Software Engineering at YOW! Tech Leaders Summit in Brisbane, Sydney, and Melbourne, Australia, on June 17-19
• Joint talk with Jason Vella: Software Engineering: The AI Reboot at JuniorDev Auckland Meet in Auckland, NZ, on August 6

Podcasts:

• From Builder to Orchestrator - Confronting the Software Engineer’s Identity Crisis with Simon Maple for AI Native Dev Podcast, April 22
• #223 - The Software Engineer Identity Crisis in the AI-Driven Future with Henry Suryawirawan for Tech Lead Journal, July 7
• From Software Engineers to Agent Managers with Ankit Jain for The Hangar DX Podcast, November 13

Panels:

• Auckland Panel Event: Tech Hiring, Behind-the-Scenes Insights in Auckland, NZ, on September 11
• Microsoft Executive Breakfast Panel on The Impact of AI on Work in Auckland, NZ, on November 24

Roundtables:

• Co-hosting: Assessing the Impact of AI Coding Assistants with Scott Carey at LeadDev, March 5

Conferences Attended:

• Enterprise Technology Leadership Summit in Las Vegas, USA, on September 23-25
• NII Shonan Meeting 222 in Shonan, Japan, on October 6-9

Publications:

• The Future of AI-Driven Software Engineering co-authored with Valerio Terragni, Partha Roop, and Kelly Blincoe, published in ACM Transactions on Software Engineering and Methodology, May 26
• AI and the New Boundaries of Technical Work published on TechWomen NZ, November 10
• Contributor to The Future of Development Environments with AI Foundation Models: NII Shonan Meeting 222 Report

Thanks for reading this post via RSS! 👋

After that came an explosion of tools and technologies. On the application side, we reached for caches, queues, NoSQL databases, and event streams to make distributed systems possible and keep them performing under load. On the delivery and infrastructure side, DevOps pipelines and automated static analysis tools helped us ship faster, automated testing gave us confidence in what we were releasing, and cloud and infrastructure‑as‑code let us scale in a far more programmatic way. Mobile in the 2010s brought a whole new set of tools and constraints with it - you had to really think about payloads, because pushing huge amounts of data over mobile networks just wasn’t a great idea.

These are the kinds of shifts we point to when we talk about why software engineering is a career where there’s always more to learn. New technologies arrive constantly, and if you want to build the right solutions with the tools available today, you have to keep up, experiment, and learn how to put those tools to work in meaningful ways.

What’s exciting now is that with Gen AI, we’ve added a whole new kind of component to that toolkit: the LLM. We can weave it into our systems in all sorts of ways - as a helper inside a feature, as the thing that orchestrates tools and workflows, or as the layer that sits in front of everything and talks to users. By its very nature, though, it’s non-deterministic and often unpredictable. That forces us to rethink how we design software end-to-end, from architecture and implementation through to testing, deployment and the way we run these systems in production.

From deterministic to non‑deterministic systems

In a recent conversation between Martin Fowler and Gergely Orosz, Martin puts his finger on this very point: the importance of the introduction of non-determinism into our systems. He leans on his wife’s world of structural engineering, where one must think in terms of tolerances and deliberately build extra capacity into a bridge or a building because materials like wood, concrete and steel all vary. You can never assume two pieces of timber will behave identically. Instead, you learn as much as you can about the materials and then design around that uncertainty. I think he’s right that we’ll need a similar mindset when we work with non‑deterministic AI components, understanding the “tolerances” of that uncertainty and resisting the temptation to skate too close to the edge, especially on the security side.

In my AI Native DevCon talk six months ago, Am I Still a Software Engineer If I Don’t Write the Code?, I shared a slide titled “New tools, new problems, new solutions” to illustrate some of the new problem spaces opening up for us as engineers. Basically, this post zooms in on just one of those boxes: designing non-deterministic systems.

The rise of the AI application layer

Up until recently, most of my research has focused on what AI is doing to software engineering as a discipline: how it changes the process of building software, what it does to our day‑to‑day experience as engineers, and how it shifts where we spend our time when we have an AI assistant sitting beside us in the IDE. But I’m just as intrigued by what it means for the software itself. The kinds of systems we can now build. The architectures we reach for. The new constraints we run into and the new classes of problems we have to solve when a non‑deterministic component sits in the middle of everything.

That curiosity has led me to focus more on the AI application layer - the part of the stack where models, tools and products actually meet real users. And there are strong signals that this focus is well‑placed. Andrew Ng, in a recent Batch editorial, pointed out that while huge amounts of money and attention are flowing into infrastructure and foundation models, the AI application layer is comparatively under‑invested. There’s a lot of value still to be created there, and that value will come from people who know how to design, build and operate these new kinds of systems.z

We’re already starting to attach more specific labels to those people - titles like AI Engineer, AI Application Developer, or AI Application Architect - folks who live closer to that layer. But I don’t think of that as a separate profession. Just as we once had to learn our way around caches, queues, mobile constraints and cloud tooling, this is simply the next set of tools and patterns we need to get fluent in. We’re still software engineers, and these are tools, patterns, and ways of thinking that we’ll be better off knowing, whether or not we ever put “AI” in our job titles.

This post is my working map of the skills and concepts I think matter for software engineers who want to build in this new LLM / agentic paradigm.

How the work shifts

Before diving into the detail, it helps to name the kinds of work that shift when you bring LLMs and agents into the mix. There is still solution design and architecture, but instead of just deciding where your service boundaries lie, you’re deciding what belongs in deterministic code vs a model, where to introduce retrieval or agents, and how to build in safety and human oversight from the start.

There is still engineering, but more and more it means stitching together models, tools, data stores, workflows and observability into something coherent and operable. A lot of the hard work now is in learning the new tooling and patterns well enough that you can keep systems explainable and debuggable, even when some core components are probabilistic.

And there is still validation, but it looks very different from traditional unit and integration testing. You need new ways to evaluate behaviour over time, catch regressions when models or prompts change, and decide what “good enough” means for systems that will never be perfectly predictable.

AI Engineering Competency Map

What follows is a set of skill areas and capabilities you can explore if you want to get serious about building systems with LLMs and agents at their core. This is simply my current view, shaped by what I’m reading, what I’m building, and what I’m seeing across the industry, not a set of hard rules or a checklist to complete. It’s deliberately broad, not exhaustive, and almost certain to evolve as the tools, patterns and best practices do.

1. Models, Providers & Core Stack

Understanding which models exist, what they can do, and the core stack used to work with them.

1.1 Model providers

Knowing the major commercial and open model providers and how to integrate their APIs.

• OpenAI
• Anthropic
• Google
• Mistral
• Meta
• Groq

1.2 Model capabilities & selection

Choosing appropriate models based on capability, risk and constraints.

• Reasoning depth vs latency
• Text-only vs multimodal
• Context length and token limits
• Cost profiles and rate limits
• Fine-tuned vs general-purpose models

1.3 Core implementation stack

Using programming languages and runtimes suitable for AI-enabled backends and agents.

• Python
• TypeScript / JavaScript
• Go
• C# / .NET
• Basic familiarity with async patterns and HTTP APIs

⸻

2. Knowledge Preparation & Retrieval (RAG)

Preparing data and retrieving it so agents can ground their answers in real information.

2.1 Knowledge preprocessing

Transforming messy input into clean, LLM-ready text.

• PDF to HTML or markdown
• OCR and image-to-text
• Normalising and cleaning documents
• Splitting large files into logical sections

2.2 Chunking strategies

Breaking documents into useful pieces for retrieval.

• Fixed-size vs semantic chunking
• Sliding windows and overlap
• Section- and heading-aware splits
• Trade-offs between granularity and context

2.3 Embeddings & vector search

Representing text as vectors and searching semantically.

• Embedding models and dimensions
• Similarity metrics (cosine, dot-product, etc.)
• Indexing strategies
• Handling updates and re-indexing

2.4 Hybrid retrieval & reranking

Combining different retrieval techniques to get better results.

• Keyword search (BM25 or equivalent)
• Hybrid search (keyword + vector)
• Reranking candidate documents
• Balancing recall vs precision

2.5 Knowledge graphs & structured stores

Using structured knowledge to support reasoning and answering.

• Entity and relationship modelling
• Graph databases
• Joining graph lookups with LLM answers
• When to use graphs vs plain RAG

2.6 Common vector and search backends

Using production-ready services for retrieval.

• Pinecone
• Weaviate
• Azure AI Search / Cognitive Search
• Elastic with vector capabilities
• Chroma or similar developer-oriented stores

⸻

3. Context & Conversation Management

Deciding what the model sees, how it sees it, and how to cope with context limits.

3.1 Context engineering

Designing prompts and context to give the model what it needs and nothing it does not.

• System / user / tool message structure
• Injecting retrieved knowledge and constraints
• Representing user state and persona
• Avoiding irrelevant or distracting information

3.2 Context window architecture

Managing the limited context window as a resource.

• Token budgeting across instructions, history and retrieved chunks
• Policies for what to keep vs drop
• Per-turn context templates
• Handling very long workflows or conversations

3.3 Compaction and summarisation

Compressing history while preserving what matters.

• Conversation summarisation
• State distillation into notes or facts
• Periodic “snapshot” summaries
• Trade-offs between fidelity and brevity

3.4 Structured outputs & schemas

Ensuring outputs are machine-friendly and predictable.

• JSON and typed schemas
• Function / tool call definitions
• Validation and error handling
• Strategies for recovering from malformed output

⸻

4. Agent Reasoning & Orchestration Patterns

How agents think, break down work and orchestrate multiple steps or tools.

4.1 Prompt chaining

Breaking complex tasks into explicit, ordered LLM calls.

• Multi-step workflows
• Passing intermediate outputs between steps
• Designing reusable chains
• Handling failure at intermediate steps

4.2 Routing

Selecting the right model, tool, or agent for a given request.

• Heuristic routing rules
• LLM-based router prompts
• Routing by complexity, sensitivity or domain
• Combining cost and quality constraints

4.3 Parallelisation

Running independent tasks concurrently to improve throughput.

• Fan-out calls to tools or models
• Aggregating and merging results
• Handling partial failures
• Timeouts and cancellation strategies

4.4 Planning & goal management

Creating and adjusting plans to meet explicit goals.

• Turning user goals into sub-tasks
• Ordered and dependency-aware task lists
• Replanning when state changes
• Tracking progress against a goal

4.5 Goal setting & monitoring

Defining success criteria and checking whether they are met.

• Clear definitions of “done”
• Agent-visible metrics or checkpoints
• Self-assessment cycles (“did I achieve the goal?”)
• Triggering escalation if goals cannot be met

4.6 Advanced reasoning techniques

Using structured reasoning styles to improve accuracy.

• Chain-of-Thought (step-by-step reasoning)
• Tree-of-Thought and exploring multiple paths
• ReAct (reasoning plus acting with tools)
• Self-correction and iterative refinement

⸻

5. Tools, Skills & External Systems

Connecting agents to external capabilities and designing those capabilities well.

5.1 Tool and function calling

Letting the model invoke deterministic operations.

• Tool interface design and arguments
• Idempotent and side-effecting tools
• Handling tool failures and retries
• Limiting what tools are available when

5.2 Tool ecosystems and MCP

Organising tools into discoverable, reusable ecosystems.

• Model Context Protocol (MCP) servers and tool definitions
• Describing resources and prompts
• Versioning and compatibility
• Discoverability and documentation

5.3 Enterprise and SaaS integration

Connecting agents to real systems to actually do work.

• REST and GraphQL APIs
• Databases and data warehouses
• Enterprise services (CRM, ticketing, HR, core systems, etc.)
• Handling authentication, rate limits and quotas

⸻

6. Multi-Agent Systems & Inter-Agent Communication

Using multiple specialised agents that collaborate over well-defined protocols.

6.1 Role-based multi-agent design

Assigning clear responsibilities to different agents.

• Specialist vs generalist agents
• Manager–worker patterns
• Critic/reviewer agents
• Domain vs workflow roles

6.2 Collaboration patterns

Structuring how multiple agents work together.

• Sequential hand-off
• Parallel teams aggregating results
• Debate or “argue then agree” patterns
• Escalation to higher-authority agents

6.3 Inter-agent communication standards

Using standard protocols so agents from different frameworks can talk.

• Agent cards describing capabilities
• Task and message formats
• Artifacts and streaming results
• HTTP / JSON-RPC based interaction

6.4 A2A-style discovery & interaction

Finding and calling remote agents reliably.

• Well-known URIs and registries
• Context identifiers for long-running tasks
• Polling vs streaming updates
• Security boundaries between agents

⸻

7. Memory & Learning

Giving agents continuity over time and allowing them to improve.

7.1 Short-term memory

Tracking state within a session or workflow.

• Conversation buffers
• Current plan and sub-task state
• Local scratchpads for reasoning
• Limits and reset strategies

7.2 Long-term memory

Persisting information across sessions and tasks.

• User preferences and profiles
• Project or case histories
• Vector memories and knowledge bases
• Expiry, pruning and privacy controls

7.3 Learning and adaptation

Letting systems improve from feedback and data.

• Reinforcement learning and preference learning
• Updating retrieval corpora and memories
• Policy updates from evaluation results
• Guarded finetuning where appropriate

⸻

8. Safety, Robustness & Human Partnership

Keeping systems safe, resilient and aligned with people.

8.1 Guardrails and content safety

Preventing harmful, non-compliant or out-of-scope behaviour.

• Input validation and sanitisation
• Output filtering and safety checks
• Behavioural constraints in prompts
• Dedicated safety models or agents

8.2 Exception handling & recovery

Dealing gracefully with errors and degraded conditions.

• Error detection and logging
• Retries and fallbacks
• Graceful degradation of features
• State rollback and escalation

8.3 Human-in-the-loop collaboration

Designing for human oversight and joint work.

• Human review for sensitive actions
• Escalation policies and thresholds
• Feedback loops to improve agents
• Interfaces for humans to correct or override

8.4 Security & access control

Keeping data and capabilities properly protected.

• Authentication and authorisation
• Least-privilege tool and data access
• Secrets management
• Network and tenant isolation

⸻

9. Resource & Priority Management

Using time, money and compute wisely while choosing what to do first.

9.1 Resource-aware optimisation

Balancing quality against time and cost.

• Choosing between cheap vs expensive models
• Latency-sensitive vs offline workflows
• Bandwidth and storage-aware strategies
• Fallback models and graceful degradation

9.2 Task and goal prioritisation

Deciding which task or goal the agent should work on next.

• Scoring by urgency, impact and dependencies
• Scheduling and queues
• Dynamic reprioritisation as conditions change
• Aligning agent priorities with business objectives

⸻

10. Evaluation, Monitoring & Operations

Making sure systems work, stay healthy and improve over time.

10.1 Evaluation and metrics

Measuring whether the system is actually good.

• Accuracy, relevance and helpfulness metrics
• RAG-specific metrics (faithfulness, grounding)
• Human rating workflows
• Benchmark and regression suites

10.2 Monitoring & observability

Watching live systems and catching problems early.

• Latency and error tracking
• Token and cost usage monitoring
• Concept drift and behaviour drift detection
• Logs and traces for auditability

10.3 LLMOps / AgentOps

Running AI systems as first-class production services.

• CI/CD pipelines for prompts, tools and configs
• Versioning of prompts, models and policies
• Canary and shadow deployments
• Rollbacks and kill switches

⸻

11. Frameworks, Platforms & Tooling

Using the ecosystems that make all of the above practical.

11.1 Orchestration and agent frameworks

Building complex workflows without reinventing the wheel.

• LangChain, LlamaIndex, Semantic Kernel
• CrewAI, AutoGen, Swarm-style frameworks
• Google ADK and similar agent toolkits
• Hugging Face ecosystems (model hub, Inference, Spaces)
• Local model tooling and runtimes (for example LM Studio)
• Workflow engines and state machines

11.2 Cloud AI platforms

Using managed services for models and agents.

• Azure AI Foundry
• Copilot Studio
• AWS Bedrock
• Vertex AI and similar

11.3 Evaluation & monitoring tools

Leveraging specialised tools for analysing behaviour.

• LangFuse
• Helicone
• Weights & Biases
• General observability stacks (Prometheus, Grafana, Datadog, Honeycomb, etc.)

11.4 Document and data tooling

Supporting ingestion and preprocessing at scale.

• Unstructured.io and PDF parsers
• ETL and data pipelines
• Storage backends for datasets and document collections
• Connectors into enterprise systems

Where this leaves us

This list is intentionally dense and a little overwhelming, because the space itself is. You don’t need to become an expert in every item in this list; getting comfortable with even a handful of them will open up new kinds of systems to design and new questions to wrestle with, in a space where many of the patterns and “best practices” are still being written. In a world where more and more of our stacks include components that are, by design, non-deterministic, we have a rare opportunity: to get curious early, experiment while things are still fluid, and help redefine what good engineering looks like - especially around inference, orchestration and agents - bringing the discipline, judgement and curiosity that make these systems something people can trust.

Thanks for reading this post via RSS! 👋

The research put numbers to it:

The competence penalty was more than twice as severe for female engineers, who faced a 13% reduction compared to 6% for male engineers.

The experiment was simple: engineers reviewed the exact same piece of Python code, with the only difference being whether they were told it had been written with the assistance of AI. Turns out women are essentially carrying a heavier burden of doubt for the same contributions.

Even worse, the harshest critics were men who didn’t use AI themselves - they judged women 26% more severely than men for identical AI-assisted work.

Let that sink in for a moment.

It’s worth noting that all the engineers in the study were from the same company, so the results may say as much about that company’s culture as the industry at large.

But unfortunately they line up all too well with the lived experiences of many women in tech. Reading those numbers brought that familiar sting of recognition - here was research finally putting concrete data to something that’s hard to put your finger on, but quietly feeds imposter syndrome throughout our careers.

For some of us, it starts even earlier than the first critical code review. Like when I told my computer studies teacher I wanted to learn how to code and they said I’d have to transfer to the local boys’ school. Or at my high school graduation, after being awarded Dux of my college, the school’s computer teacher asked what I was planning next. I told her I was off to study computer science at university. Her response? “Worst decision you’ll ever make. The boys will run circles around you, and you’ll be the worst in the class.”

She didn’t believe I could. She didn’t believe I should even try.

Thankfully, years of navigating new countries and school systems mid-year (my father was a diplomat) had helped me build a fair amount of resilience, so I didn’t let that sway me. But it did stick with me. I still marvel at how someone could so flippantly squash someone else’s dreams like that. A child’s dreams, none the less.

I’ve always said, and still believe, there’s nothing else I could imagine doing. This was my passion, and no one was going to talk me out of pursuing it. Her doubt became my fuel.

That resilience has been tested several times throughout my career. Like that time I asked for access to logs to debug a memory leak and was brushed off for weeks, until my husband, Jason Vella, (who’s also a software engineer and worked at the same company) asked for the same logs and got them immediately. He passed them onto me, and I used them to teach myself WinDbg, found the leak, and fixed it. One of my proudest moments, actually, but also one I’d annoyingly had to fight for.

Over the years, I’ve worked in four countries and nearly a dozen companies, and the pattern is remarkably consistent. I’ve often had to prove myself just a little more, and for a little longer, than it seems to take for my male colleagues.

However, for all those subtle extra challenges, I’ve also had enormous support from many - mostly men, in fact - who have taught me, challenged me, and pushed me to be and do my best every single day. Their encouragement has been just as real as the obstacles, and I’m deeply grateful for it.

This mix of obstacles and support has taught me something important: the difference often comes down to who believes in you from the start. For all the talk about getting more women into tech, here’s a thought: maybe stop discouraging them in the first place? Support them early. Show them what’s possible - because too often, the gap exists only because they’ve been told it’s there.

That’s why programmes like ShadowTech matter so much. This year, ShadowTech25 is giving more than 1,200 girls from 80+ schools across New Zealand the chance to spend a real day in tech - meeting mentors, touring workplaces, and seeing firsthand just how diverse and exciting a career in technology can be. Contributing to their panel discussions at Westpac over the past few years has been a chance for me to reflect on my own pathway, and to turn my obstacles into stepping stones for the next generation.

Exposure leads to possibility, and possibility changes everything.

But there’s another side to this work. Just as we need to give girls opportunities to play with computers and learn to code early, we also need to teach boys that women can, and do, excel in these roles. Avoid baking in bias from the start. And when we get to the workplace, leadership needs to set the tone. Leaders cast a long shadow, and when they lead by example - offering fair opportunities, recognising contributions evenly, and calling out unfair behaviour - it sends a signal that bias isn’t tolerated here. Culture is contagious, and every time someone, regardless of gender or background, challenges an unfair assumption, it chips away at the barrier for the next person.

Maybe then, just maybe, we’ll get a little closer to letting everyone play on a level field, where identical work gets identical judgment, regardless of who wrote it. Where the next generation can start their journey without the weight of someone else’s low expectations on their back.

I should add that despite all this - the extra proving, the subtle barriers, the competence penalties that research now validates - I have absolutely loved this career. The joy of solving complex problems, creating systems that matter, and working alongside brilliant minds has definitely outweighed every obstacle. The quiet satisfaction of knowing I could do it all along adds a certain sweetness to the journey.

Would I choose this path again, knowing what I know now about the extra load we carry?

Without hesitation. Because someone has to prove that teacher wrong.

Thanks for reading this post via RSS! 👋

Something about this revelation stayed with me. Most people I’ve met outside the software engineering world tend to describe code as unintelligible - like hieroglyphics. I guess that’s why I’ve always assumed: if someone couldn’t write code, they probably couldn’t read it either.

But this person isn’t a software engineer. They don’t work in a role where coding is expected. And yet, they can read it. Follow its logic. Understand enough to debug it.

That was new to me. I’ve worked with plenty of people who can’t code - that’s normal. But someone who can read code fluently, yet feels unable to write it, struck me as an unusual inversion of what I’d always assumed.

Modelling, Not Just Typing

Writing code isn’t just knowing syntax. It’s not just about conditionals or classes or regexes. At its heart, writing code is modelling - the ability to form a structured mental model of a process, a system, or an idea, and then encode it in a way that a machine can understand.

What you’re creating is a representation: a digital reflection of something real, or imagined. Sometimes that model lives in your head. Sometimes it spills out across a whiteboard or a sheet of paper. But it’s always there - an abstraction you’re building, refining, naming. You’re spotting patterns, finding generalisations, shaping structure from chaos. And then translating all of it into syntactically correct code.

This is what’s always drawn me to programming. The act of shaping a mental image, refining it through thought, and watching it come to life. Even today, after decades in this industry, there’s still something magical about it.

As Fred Brooks, author of the very famous book The Mythical Man-Month, put it:

The programmer, like the poet, works only slightly removed from pure thought‑stuff. He builds his castles in the air, from air, creating by exertion of the imagination...

— Frederick P. Brooks, The Mythical Man-Month, Chapter 1, Addison-Wesley, 1975

That image - that castle in the air - is what draws many of us to code. It’s abstract, fragile, and yet, when the build succeeds, it becomes something real. A living, running representation of our ideas.

And we don’t get there by accident. The transition from mental model to working system happens through design - a process of making trade-offs, choosing abstractions, and shaping the code in a way that reflects not just what works, but what makes sense.

Design Isn’t a Phase

In some organisations, design is treated as a one-off activity. It happens at the beginning of a project, often in a different room, done by someone else with a different title. Sometimes it’s even handed down like a blueprint to be implemented.

But anyone who’s spent time building software knows: design is everywhere. It’s in how you break down a problem. In the abstractions you choose. In the edge cases you decide to handle - or not. Design happens during implementation, during testing, during bug fixing, and even while reading logs to understand why something failed in production.

John Ousterhout said it plainly in his recent interview with Gergely Orosz:

My personal belief is that design permeates the entire development process. You do it upfront, you do it while you're coding, you do it while you're testing, you do it while you're fixing bugs; you should constantly be thinking about design.

— John Ousterhout, interview with Gergely Orosz

Design isn’t a step we move past - it’s how we evolve our representations. It’s how we learn what we missed, or overcomplicated, or misunderstood. And it’s deeply satisfying. There’s a quiet joy in realising you’ve found a better way to shape something. That your system is more robust, more elegant, more humane because of it. Sometimes that shift is architectural. Sometimes it’s a single line. The devil might be in the details - but so is the beauty. And that’s where the craft lives too.

A Memory That Still Moves Me

I still remember the first time I saw an idea come to life on screen. I was six years old, sitting at my Commodore 64, carefully typing out lines from a manual I barely understood.

There were no variables to name. No functions to design. I was just copying commands - faithfully, line by line. I didn’t know what a loop was, or what DATA meant. But I typed RUN, pressed RETURN, and something happened.

A face appeared.

Not a great one. Just a blocky pixel sprite. But it moved. It smiled at me from the screen, and I smiled back - stunned that text I’d typed had become something visual that moved.

I wasn’t designing anything of my own. I wasn’t solving a problem or building a system from scratch. But at six years old, that didn’t matter. Seeing those symbols turn into something alive on screen was enough to hook me for life.

Looking back now, I realise what captivated me wasn’t the syntax. It was the revelation of possibility - that words could become images. That logic could shape behaviour. That you could model something invisible, nothing more than pure thought, and then run it.

Even now, decades later, that moment still moves me.

What We Learned to See

Over time, the magic becomes more than just the image on the screen. You start to notice what’s behind it.

The way the code is structured. Where it flows, and where it fights itself. You begin to feel when a function is doing too much. When an abstraction leaks. When a variable name is quietly misleading.

You might hear about these principles in lectures or read them in books, but theory alone doesn’t stick. It’s when you inherit a codebase that fights you at every turn that you truly understand why these things matter. When you spend hours untangling what should have been simple. When you feel the cost of all those shortcuts taken over the years.

That’s when you develop an intuition - an internal radar for what’s brittle, what’s elegant, what’s deceptively complex.

Code starts to feel less like a puzzle to solve and more like a conversation to understand. You begin to recognise fingerprints. This bit was clearly rushed. That bit was lovingly crafted. This change came from someone who knew the system inside out. That one… maybe not.

In this evolution, the magic deepens. What started as wonder at seeing code come to life on screen becomes appreciation for how we organise thought itself. Writing code isn’t just how we instruct a machine - it’s how we give shape to our own understanding. A way to turn thought into structure. Intent into form.

The Test We All Had to Pass

For many of us, reading and writing code wasn’t just a skill, it was a test. Quite literally.

Coding interviews. Live whiteboarding. We were asked to write functions from scratch, under pressure, with someone watching. We weren’t just trying to solve problems - we were trying to show our thinking.

We prepared diligently. Memorised sorting algorithms. Practised recursion and dynamic programming. Optimised for time and space complexity. And for all their flaws, these interviews taught us something. They taught us how to trace logic out loud. How to structure an approach. How to fail gracefully, and recover.

For some, platforms like LeetCode and HackerRank evolved beyond mere preparation. They became a kind of personal challenge. A way to stay sharp. To prove to yourself that you still could. Leaderboards and contests sprang up, and with them, a sense of competition. Bragging rights. Mastery, on display.

We wore those battle scars with pride. Not because the process was fair, but because it was hard. Because it demanded something real from us: our ability to model, abstract, and express ideas clearly, under pressure.

It was stressful, yes. Sometimes unfair. But it reinforced that writing code was a kind of thinking - a visible trace of our structured understanding. And being good at it meant being able to shape those models quickly and clearly.

And now?

Well, it’s complicated. AI coding assistants can pass these tests too. They can write elegant solutions. Sometimes better than we can. They don’t get nervous. They don’t forget to handle an edge case. They just… output.

Which makes you wonder: if the thing that defined at least part of our entry into this field can now be automated, what does that mean for what comes next?

A Shift That Feels Personal

Maybe that’s why the rise of generative AI is hitting us in a different way. It’s not just about productivity gains. It’s about what’s being displaced.

A few months ago, I wrote a post called The Software Engineering Identity Crisis. It clearly struck a nerve - almost 60,000 views in just a few weeks. Dozens of engineers reached out personally to share their experiences. The message was consistent: “Yes. This is exactly what I’ve been feeling, but hadn’t put into words.”

There’s a quiet discomfort rippling through our industry. And I think this is part of it.

We’ve spent years honing a craft that’s part logic, part intuition, part art. And now we’re watching tools - not just assist us, but perform the very thing many of us took deep pride in: that mental modeling, that translation of abstract thought into executable form.

A recent New York Times article captured this tension. Titled At Amazon, Some Coders Say Their Jobs Have Begun to Resemble Warehouse Work, it describes how some engineers feel monitored, controlled, and pushed to deliver at unrelenting speed, echoing the dynamics of factory labour. The piece suggests a subtle but profound shift in the nature of engineering work: from craft to throughput. From autonomy to optimisation.

And one line hit particularly hard:

This shift from writing to reading code can make engineers feel as if they are bystanders in their own jobs.

— The New York Times, May 2025

This is what devaluation can look like. Not being replaced, but being sidelined. The moments we used to savour - the ones that brought flow, and joy, and pride - are becoming rarer. Shorter. Edged out by something faster, more efficient, and strangely hollow.

We’re adapting, yes. But part of us is grieving too.

Finding Our Place

There’s no denying it - this technology is absolutely incredible. It can write code that many people feel they never could. But along with that comes a sense that something uniquely human is being devalued - that creative spark that transforms abstract thought into working systems.

In the art community, a similar conversation is happening. Artists have started using “Created with Human Intelligence” badges on their work.

Kick-started by Beth Spencer, this is a quiet rebellion against the tide of AI-generated content. Not because AI art isn’t impressive, but because there’s something worth preserving in the human creative process itself.

Don’t get me wrong - I’m not suggesting we resist progress. The world is changing, and we need to change with it. This shift is opening up new possibilities we’re only just beginning to explore. But I still carry a deep appreciation for the moments when code felt like pure magic - when shaping an idea into something runnable brought clarity, joy, and a sense of creation that was entirely our own.

The future of software engineering is being redefined before our eyes. If you, like me, have taken pleasure in the creation of code, we need to find new ways to experience that same satisfaction. These tools are improving rapidly, and businesses are eager to leverage them to their full potential.

For now, we still need to guide these assistants carefully. But that will change over time. The question becomes: how do we preserve what matters most about our craft while embracing what comes next?

From Prompts to Context

At its core, programming has always been about modelling - taking something abstract and giving it a structure that can run. Sometimes we do that by writing code. But more and more, we’re doing it by shaping the context around a tool that writes the code for us.

Prompt engineering felt like the next abstraction layer. A clever way to influence the output. And for a while, it was.

But as these tools evolve, we’re learning that the real power isn’t in the prompt. It’s in the context. The true challenge lies in encoding the messy real world into something a machine can work with - that’s far harder than simply generating code.

The systems that perform best aren’t those with the cleverest prompts - they’re the ones with the clearest scaffolding. Good documentation. Consistent naming. Representative examples. The kind of subtle cues that help an AI understand what good looks like in your specific context.

As Ibrahem Amer explains in his article on prompt engineering versus context engineering, this approach involves multiple layers: from foundational knowledge structures to data integration systems to the moment-by-moment context delivery. It’s not just about crafting clever instructions - it’s about building an entire environment in which the AI can operate effectively.

And this changes how we show our skill.

It’s not about being a prompt whisperer. It’s about structuring what the tool sees. Giving it the right framing. Guiding its attention. Helping it learn from the materials we’ve already shaped.

In other words, we’re still designing systems. Still modelling complexity. Still shaping abstractions.

The shape of our work may be changing. But the underlying skill - the ability to see clearly, structure thoughtfully, and model well - remains at the heart of it all.

The Convergence of Tool and Component

This shift in skill - from crafting code to crafting prompts, and now, to crafting context - becomes even more important when we realise that AI isn’t just helping us build software; it’s becoming part of the software itself.

AI is no longer just a tool we use to build software. It’s becoming a component inside the systems we build. But when we use AI to help us build software that contains AI… where does the boundary lie?

The distinction starts to blur. The AI becomes both the engine and the product - at least, that’s how it can feel. And while the boundary is blurry in practice, thinking of them separately can still be a helpful distinction, especially when things start to feel fluid.

This idea resonated strongly with me during Simon Warden’s talk, AI as the Engine, Not the Product, at the YOW! Tech Leaders Summit. He articulated how the most successful AI implementations aren’t those that just expose capabilities, but those that orchestrate them thoughtfully within systems.

We’re still engineers. But the materials have changed.

The skill isn’t vanishing. It’s resurfacing - at a different altitude.

The Joy, Reframed

We still model things that don’t exist yet. We still shape invisible systems out of thought and logic and names. We still give form to ideas.

That joy hasn’t gone. But its expression is shifting.

Today, AI handles more of the syntax. More of the scaffolding. But the architecture - the imagination behind it - is still ours to hold. The abstractions we shape. The intent we encode. The representations we choose.

And maybe now, with these tools beside us, we can go further. Be bolder. Imagine more ambitious castles. Explore stranger terrain. Spend less time typing - and more time thinking. Designing. Modelling.

Because the real craft of software engineering was never about just writing code. It was always about what we were encoding - and why.

That hasn’t changed.

So let’s not forget the craft. Let’s not leave it behind.

Let’s carry it forward - clearer, faster, and maybe even more joyful than before.

We’re not losing our craft. We’re being asked to deepen it. And that’s a challenge worth accepting.

Thanks for reading this post via RSS! 👋

This is what comes to mind when I think of a natural-language-based CLI - an old Commodore 64 text adventure game that I used to play as a kid.

A move back to the basics seems odd but intriguing, so I decided to give them a try and see if I could figure out what all the fuss was about.

Claude Code

Setting it up was a breeze. Just follow the instructions here and you’ll be up and running in no time.

You’ll need an Anthropic account because you need some money on your account before you can use Claude Code. I gave mine $5 USD and it was enough to build a couple of simple apps.

In a weird way, it feels like I’m playing Questprobe Featuring Spider-Man but instead of asking it to go north, I’m asking it to write me an app.

From the simple prompt, “Can you create a web-based version of the text adventure game called Questprobe Featuring Spider-Man from 1984 - https://www.squakenet.com/game/questprobe-featuring-spider-man/ ?”, Claude Code generated a basic but functional web-based version of Questprobe Featuring Spider-Man in less than a minute.

I really appreciated how it created a plan and then systematically ticked off each step, all from such a simple prompt. By default, it stops and asks you to confirm each significant step - but it also gives you the option to confirm and “not ask again this session”.

Well hello dear friend, vigilance decrement. I knew you’d show up sooner or later.

It’s far too enticing to select that option. After all, how much reviewing are you really doing in the terminal window? This reminds me of something I’ve noticed about code reviews throughout my career - they’re one of those activities that engineers know are valuable (especially for learning about the codebase and seeing how others solve problems), but rarely enjoy doing. In most teams, you’ll find engineers having to repeatedly ask - sometimes even beg - their colleagues to review their code. It’s not surprising really; we engineers love creating things, and reviewing someone else’s code feels about as far from creation as writing tests does. Both are essential for quality, but they don’t scratch that builder’s itch.

OpenAI Codex

Setting it up is straightforward - just follow the instructions here. As with Claude Code, you’ll need an OpenAI account with some credit before you can use it.

I asked Codex to analyse a really old side project of mine - an iPad game called Easter Egg Hunt written in Objective-C back in 2013 or so. The prompt was simple: “Can you describe the purpose of the app?”

Within seconds, it produced a remarkably accurate description of the app - from the three themed environments (Garden, Beach, or Snow) to the core gameplay of eggs periodically “popping” up in random locations. It even caught implementation details like the particle effects and chimes every five eggs, the in-app purchase system for unlocking scenes, and the use of Localytics for analytics. All this without ever seeing the app running or having any screenshots - just pure code comprehension.

Encouraged, I pushed a little further. “Draw some high-value diagrams using Mermaid that would help a new engineer understand this codebase.”

The results were genuinely impressive. Codex generated a series of clear, thoughtful visuals - from class relationship diagrams showing the core game structure to sequence diagrams illustrating the gameplay flow. These diagrams captured relationships that would take hours for a human to extract from unfamiliar code.

Think about onboarding - in minutes, a new engineer could understand a codebase that would normally take days to unravel.

While these CLI tools might seem like a step backward, I was starting to see glimpses of something more interesting emerging.

Beyond The Terminal Interface

For developers used to modern IDEs, returning to the terminal might feel like a blast from the past. But focusing on the interface misses something crucial.

These tools aren’t here to replace our IDEs - they represent the next natural evolutionary step in development. A step where AI intelligence can be embedded throughout our entire workflow.

Both OpenAI Codex and Claude Code can run in headless mode, allowing them to be integrated into pipelines, scheduled tasks, and automated testing suites. Claude Code offers a non-interactive mode designed for programmatic use. OpenAI Codex similarly supports a non-interactive / CI mode for use in pipelines.

This capability transforms these AI assistants from mere copilots into programmable units of intelligence that can be woven seamlessly into our larger systems. The implications of this shift are significant.

Imagine this:

• After your build, test and deploy steps, get Claude Code to generate a series of diagrams for your codebase which it can then safely stash away in your documentation repository as a snapshot-in-time.
• You know those pesky flaky tests that keep causing your pipeline to break but aren’t always easy to fix (even if you did have time to look at them)? Why not get OpenAI Codex to help you fix them automatically?
• It could perform a pre-post-mortem analysis - evaluating the combined impact of changes and assessing risks across all dimensions (operational incidents, security vulnerabilities, change reversibility) before they become real problems.

What we’re seeing is just the beginning. Think about all the repetitive, time-consuming steps in our development lifecycle - both inner loop activities like coding and outer loop activities like reviews and documentation. These tools are opening up possibilities to automate not just the coding itself, but also those friction-heavy outer loop activities that often slow us down. As Adi Noda, CEO and cofounder of DX, recently said in a Gartner Podcast that was asking the question Does Developer Experience Really Matter?:

We tend to see more outer loop friction points than inner loop. So code reviews, CI, and release processes tend to surface as greater areas of friction than the inner loop.

We now have the tools to address these outer loop friction points, automating away the steps we know add value but don’t enjoy doing. While these tools are still relatively simple, they represent a natural evolution in the AI-driven development era - one that unlocks opportunities far beyond just writing code.

Final Thoughts

When I first encountered these terminal-based tools, I couldn’t help but wonder if we were taking a step backward. But that initial reaction missed something important: this isn’t about the interface - it’s about programmability.

Just as git’s command-line interface enabled countless automation workflows, these AI assistants can be invoked programmatically to work silently in the background - from reviewing code to generating documentation to managing releases.

This is how evolution often works - not in dramatic leaps, but in subtle shifts that fundamentally change how we work. Software engineering isn’t dead, but it is changing. The next step is yours to take: look at your development workflow, identify the friction points, and consider how to weave these capabilities into your pipeline.

Thanks for reading this post via RSS! 👋

As software engineers, we know this feeling intimately. The slow burn of mastering a new concept or language. The pressure and anxiety of resolving your first production issue. The endless hours spent debugging a complex system that just won’t work - until, at last, it does. And how that struggle itself is the point: it’s what transforms a beginner coder into a software engineer with real intuition.

And yet, in the age of AI, that friction is exactly what we’re designing away.

GitHub Copilot, ChatGPT, Cursor, Windsurf - they’re extraordinary tools. They’ve changed the way we work. They accelerate us. They enable us to solve problems we previously would’ve struggled with. They’re becoming the new normal.

But they also flatten the terrain. And when the terrain is too smooth, we stop noticing what we’re stepping over.

The Need for Speed

As a society, we’ve become obsessed with speed. In a world of endless notifications, instant messages, and constant demands for more, we’ve normalised a state of perpetual acceleration.

This obsession with speed is especially prevalent in software delivery. In the tech industry, the race to ship new features is relentless. If you’re not moving fast, you risk falling behind. Companies compete to launch first, to capture attention, to prove they can outpace the rest. That urgency flows straight to the engineer’s desk. We work at a breakneck pace, juggling Slack alerts about pull requests, dashboards updating in real time, CI/CD pipelines demanding ever-faster iterations. We’re always looking for ways to do more, faster - to shortcut the things that can be shortcut, to automate the parts that can be automated.

This relentless drive for speed and efficiency has shaped every aspect of how we build software. For decades, we’ve chased new ways to get more done: frameworks, libraries, automation scripts, cloud deployments, microservice architectures, new methodologies - each one promising to help us move faster. Now, AI is the latest - and most powerful - shortcut yet. Everywhere you look, people are posting about how much faster they can build software with AI: how many lines of code they’ve refactored in a fraction of the time, how much boilerplate they’re avoiding with a single prompt, how quickly they’re spinning up entire new businesses in a weekend. And yes, that velocity is valuable. Those productivity gains are real - and it’s changing the landscape.

The Myth of the Shortcut

One of the changes we’re seeing is that a new generation of engineers is moving at a pace that would have been unimaginable just a few years ago. Steve Yegge’s Revenge of the Junior Developer captures this shift: junior developers, empowered by AI, are moving faster than ever - sometimes outpacing their more experienced peers. He explains how junior engineers are ‘vibing’. They get it. Essentially, AI coding assistants can act as powerful exoskeletons for anyone willing to adapt, enabling them to do work that previously required much more experience.

Shortcuts have their place. They open doors and accelerate growth. But speed doesn’t build engineering intuition.

There’s something disorienting about how good these tools are at helping you sound like an expert. They give you the answers - but they don’t teach you how to notice the problem in the first place. And they certainly don’t teach you how to trust your instincts.

That’s the real danger of shortcuts: they make you feel powerful and productive, but can lull you into a false sense of security. Without the intuition and habits forged by experience - knowing when to be wary, when to back up, when to double-check - you’re at risk of costly mistakes. These lessons aren’t learned by skipping to the answer; they’re earned by wrestling with real problems.

Cautionary tales like the one below are popping up everywhere - not necessarily because people lack technical skill, but because they haven’t yet built the judgement to anticipate, prevent, or recover from disaster.

It’s not gatekeeping to say that some things still take time. It’s just how humans learn.

Santiago Valdarrama’s blog post “Coding is over. Now what?” points out that as AI commoditises coding, the most valuable skills become things like identifying the right problem, framing it well, and designing elegant, maintainable solutions. But what’s often glossed over is the uncomfortable reality that these aren’t skills you can simply acquire overnight or skip straight to. No one seems to be talking about how the next generation of engineers is supposed to leapfrog past the years of debugging sessions, architectural missteps, and system rewrites that forge true intuition. How do you even know what an elegant, maintainable solution looks like if you’ve never had to live with the consequences of a brittle one? These abilities are forged in the messy middle, through friction and deliberate practice - not by shortcutting your way to the answer.

What ties all these higher-order skills together is a kind of engineering intuition - a sense for what matters, what will work, and what might go wrong in different contexts. But intuition isn’t something you can prompt for or download; it’s earned by moving through the gradual stages of real skill acquisition.

The Dreyfus Model: Why Intuition Can’t Be Prompted

The Dreyfus Model is one of the best tools I’ve found to help make sense of this journey, both for myself and for others I’ve coached. If you’ve never heard of it or how it can be applied to software engineering careers, this article provides a good overview.

The model describes five stages, each reflecting a shift in how we use recollection, recognition, decision-making, and awareness.

1. Novice – You follow rules and instructions exactly as given; your recollection and recognition are limited to what you’ve been explicitly taught; you make decisions by following step-by-step guidance; your awareness is focused tightly on the immediate task - bigger-picture context isn’t relevant (and wouldn’t help much even if someone tried to give it to you).
2. Advanced Beginner – You start to recognise recurring patterns and situations; your recollection of similar experiences begins to inform your actions; you still depend on rules but with some flexibility; your awareness starts to expand, but you’re still mostly focused on the task at hand, with only glimpses of the broader context.
3. Competent – You can plan, troubleshoot, and prioritise; your recognition of patterns is stronger; you draw on a growing bank of experiences; your decision-making involves conscious choice and analysis; your awareness now includes both immediate tasks and the bigger picture. At this stage, you begin to adapt rules to fit the situation and can finally make use of wider context.
4. Proficient – You see the big picture and adapt flexibly; your recollection is automatic for most situations; your recognition is rapid and intuitive; your decisions are guided by experience but still involve reflection; your awareness includes anticipating outcomes and adjusting in real time. You often know when to break the rules and why.
5. Expert – You operate from deep intuition; your recognition and recollection are seamless and often unconscious; you make decisions fluidly, often without deliberate analysis; your awareness is holistic, allowing for creative and adaptive responses. At this level, you’re often the one creating new rules, patterns, or heuristics for others to follow.

The crucial thing is that you can’t simply skip these stages - no matter how powerful the AI or how quickly you pick up new syntax. Intuition is built by moving through each phase, not by bypassing the messy middle. There’s a reason it’s often said that reaching true expertise in any field takes years, not weeks - sometimes a decade or more.

That’s what I love about the Dreyfus Model: it normalises friction. The path to expertise is supposed to be bumpy. That’s not a flaw - it’s a feature, backed by decades of research on skill acquisition and deliberate practice.

Ericsson et al. (1993) established that expertise isn’t simply a function of experience, but of deliberate practice - focused, effortful work aimed at improving specific aspects of performance. Further studies, including Becker et al. (2023), have explored how these principles apply to programming specifically, showing that enduring mastery requires more than repetition - it requires reflection and productive struggle. This aligns with recent educational research by Bull and Kharrufa (2024), who argue that effective learning with AI must integrate human reflection and effort - not bypass it.

This finding is reinforced by an MIT study, as described in Esther Shein’s paper The Impact of AI on Computer Science Education. In the study, students were split into three groups and given a Fortran task - a language none of them knew. One group used ChatGPT, another used Meta’s Code Llama, and a third used only Google. While the ChatGPT group solved the task the fastest, they failed to retain what they had learned and performed poorly in follow-up assessments. The Code Llama group performed slightly better, but the Google group - who had to break the problem down into smaller parts - retained the most and performed best. As the study put it: “Working hard and struggling is actually an important way of learning.” The results underscore this central claim: that real understanding comes not from being handed solutions, but from working through the friction to reach them.

This matters now more than ever, because AI tools give us fluent syntax and confident answers - but they don’t give us the pattern recognition or judgement that only comes from working through the mess.

Embrace the Seams

Some researchers are starting to recognise this risk and are exploring ways to design AI tools that don’t just hand you answers, but invite you into the process. Inman et al. (2025) at Google call this idea Seamful AI: instead of hiding uncertainty and ambiguity, these tools could surface the “seams” - the places where the answer isn’t clear-cut, or where multiple paths might be valid.

Why does this matter? Because it’s in those moments of ambiguity and uncertainty - when you have to pause, weigh options, and make a judgment call - that real learning happens. Exposing the seams doesn’t just make AI more transparent; it creates space for you to bring your own intuition and critical thinking to the table.

Most AI coding assistants, by contrast, erase those moments. They converge on a single, confident-sounding answer, making it harder to develop real judgment - or even to know that judgment is needed.

We can’t afford that. Not if we care about software quality. Not if we care about the next generation of engineers.

Rediscovering Friction

This doesn’t mean going back to writing everything from scratch. It means being intentional about when we slow down.

In a world where AI can generate endless code and abstractions pile up faster than ever, friction isn’t about slogging through every detail. It’s about choosing your moments. Sustainable, realistic friction is about:

• Getting curious when something surprises you - whether it’s a bug, an unexpected result, or a design you don’t quite trust.
• Taking time to understand the systems or components that matter most for your product, your users, or your own growth.
• Reflecting on failures and odd behaviours in production, and letting those drive deeper investigation.
• Setting aside space for “digging in” on the areas that spark your curiosity, rather than feeling obligated to master everything.
• Sharing what you learn with others - because teaching is one of the best ways to deepen your own understanding.

We won’t always have the time or energy to read every line, and that’s okay. But if we never slow down, never question, never get our hands dirty, we risk losing the intuition that makes us truly effective engineers. Friction, when chosen wisely, is what keeps our skills sharp and our judgement real.

I’ve experienced this firsthand. I still remember becoming obsessed with tracking down a memory leak in production many years ago. The easy fix was already in place - just restart the IIS worker processes every night - but that was a band-aid, not a solution. So I dug in, learning to use WinDbg (a seriously tricky tool to master), poring over cryptic commands and outputs, and chasing down the root cause. It took more time and frustration than I care to admit, but by the end, I didn’t just fix the bug - I’d become an expert on XML Serialisation (the culprit). That experience didn’t just give me an answer; it gave me a kind of intuition that’s hard to get any other way.

And yes, maybe today you could ask an AI assistant to help diagnose a memory leak like this. Intuition, though, isn’t just about getting the answer, it’s about knowing which questions to ask, recognising when something doesn’t add up, and having the confidence to dig deeper when a quick fix isn’t enough. AI can accelerate learning, and it may help us reach these moments of insight faster than before, but the path taken still matters. The fundamentals - curiosity, persistence, and the willingness to wrestle with problems - are what turn information into real knowledge and meaningful understanding.

The Missing Piece of the Conversation

The Dreyfus Model shows us that growth - in any domain, but especially as software engineers - is a journey: slow, sometimes frustrating, often messy. In the age of AI, the path may look different, but the fundamentals haven’t changed. Intuition still comes from the same place it always has: deliberate practice, reflection, and time spent wrestling with uncertainty.

And yet, there’s something quietly unsettling about the way we’re talking about AI right now.

We’re told the real value in our work lies in higher-level thinking - identifying the right problems, shaping elegant solutions, seeing the system. And that’s true. But what’s missing from the conversation is how we can develop those skills when AI is erasing the friction that used to help us build them.

If you’re leading a team, this matters even more. It’s not just about shipping faster or clearing blockers. It’s about creating the kind of environment where engineers can still build the instincts and judgment they’ll need later - even if the path to get there looks a little different now.

So use the tools. Embrace the speed. And every so often, slow down - just enough to feel the texture of the work again.

That hard-earned feeling of learning something deeply? It’s still there. And it still matters.

Thanks for reading this post via RSS! 👋

But that identity is being challenged.

AI coding assistants aren’t just changing how we write software - they’re fundamentally transforming who we are. We’re shifting from creators to orchestrators, from builders to overseers. From engineers to something that looks suspiciously like… managers.

The irony cuts deep: for years, we’ve said that software engineering transcends mere coding. Requirements, design, testing, operations - these were all supposedly part of our craft. Yet the industry pushed us in the opposite direction. We handed these responsibilities to specialists - Product Owners, Architects, Quality Engineers, Platform Engineers - while we doubled down on our coding expertise. We became masters of our code, proud wielders of a modern magic.

And now, just as we’ve perfected this craft, AI is threatening to take it away from us.

The Joy We’re About to Lose

Let’s be honest about what’s at stake here. Many of us don’t just write code - we love writing code. Our identity is woven into every elegant solution we craft, every test we make pass, every problem we solve through pure logic and creativity. It’s not just work, not just a craft - it’s who we are.

Think about those moments of deep satisfaction: when you finally track down that elusive bug that’s been haunting production, when you work out how to optimise that slow algorithm and watch response times drop from seconds to milliseconds, when you transform a maze of legacy code into something clean and maintainable. These aren’t just achievements - they’re expressions of who we are as engineers. They’re the moments that remind us why we chose this path.

Now imagine AI taking over these moments of craftsmanship. The creators of these tools paint an optimistic picture - they say we’ll spend more time on defining intent, high-level architecture, and systems thinking. But listen carefully to what they’re really saying: we’ll become overseers rather than creators, managers rather than builders.

This shift raises important questions about our identity as builders: Is oversight what drives us? Is it what makes us leap out of bed in the morning, eager to solve the next puzzle?

The Identity Shift: It’s Already Here

This isn’t some theoretical future we’re debating - it’s the reality we’re living right now. When Google recently revealed that AI generates more than a quarter of their new code, it was just the beginning. Y Combinator CEO Garry Tan reveals that for about a quarter of their startups, 95% of their code is now written by AI - marking a truly significant shift. My own Master’s research revealed a similar picture: 77% of us are spending less time writing code, and almost half believe our core skill might become secondary to prompt engineering. Think about that transition: from crafting solutions to crafting prompts.

When asked how to develop prompt engineering skills, software engineers emphasise refining communication skills. Getting an AI to do what you want means being able to articulate things well - providing just the right amount of context along with a clear description of the task. The better you can communicate with Gen AI, the more likely the output will match your expectations. Some even suggest being polite to these tools, treating them like team members - as if you’re leading another human being to do something for you.

The changes run so deep that we’re inventing new terms just to describe who we’re becoming. Take vibe coding, a term that Andrej Karpathy recently coined in a tweet. It captures a profound shift in how we write software.

At one end of the spectrum lies the traditional way - the craftsperson’s way. We write each line with intent, every function name and architectural decision reflecting our deep understanding of the system.

At the other end? We let AI fill in the blanks, “vibing” with its suggestions. We focus on the what, not the how. As Karpathy puts it: “fully give in to the vibes, embrace exponentials, and forget that the code even exists.”

That last part gives us pause - are we still engineers if we forget all about the code?

In a recent pairing session, engineering thought leaders Gene Kim and Steve Yegge demonstrated what this looks like in practice. Using an AI coding assistant, they ported a 3,500-line legacy Ruby script to Kotlin - a task that would normally take a week - in just one hour. The AI didn’t just translate the code; it improved it, adding the modular architecture and unit tests they’d wanted for years but couldn’t justify the time for.

Even Patrick Debois, the godfather of DevOps, sees this transformation reshaping our identity. In his recent analysis of AI Native Development patterns, he outlines four fundamental shifts in how we work:

These patterns reveal a profound shift: we’re moving from producers to managers of AI systems, from detailed implementation to expressing intent, from delivery to discovery through rapid experimentation, and from content creation to knowledge curation. Our role is evolving to blend creation with orchestration, building with oversight.

Overall, I think it’s fair to say that the nature of our professional identity is changing at its core.

The Craft That Shaped Our Identity

To understand this identity crisis, we need to look at how deeply the craft of coding has shaped who we are. At its core, writing code is about mastery and control - skills we’ve spent years perfecting. Modern programming languages are much higher-level than those of days gone by, but they still require deep technical understanding. Few developers today deal with the nitty-gritty of pointers and memory management, yet we still take pride in knowing how things work under the hood. Even as frameworks do more heavy lifting, we’ve maintained our identity as artisans who understand our tools intimately.

Programming today is much more about stitching together APIs, frameworks, and libraries in creative ways to build something meaningful. In fact, recent research at Google suggests that creativity in software engineering centres on the concept of clever reuse over pure novelty. This makes sense to me - I’ve often commented that we’re all just ‘integration’ engineers nowadays, really.

Still, there’s a strange pride that we take in knowing all the weird syntax required to build something. It’s like a secret language that only we understand. Becoming proficient with a programming language gives you a lot of control to make it do precisely what you want it to do. It’s so detailed - just one wrong character will break the entire thing and it can take a lot of time and patience to make it do what you want.

First, one must perform perfectly. The computer resembles the magic of legend in this respect, too. If one character, one pause, of the incantation is not strictly in proper form, the magic doesn’t work.

— Frederick P. Brooks, The Mythical Man-Month, Chapter 1, Addison-Wesley, 1975

The other 99% of the population thinks we’re magicians for understanding code and indeed, it can take years of deliberate practice to master it. Those who master more than one programming language have the privilege of being referred to as polyglots. Many of us take great pride in writing clean, elegant code. We passionately argue over different styles and best practices, often taking it all too seriously.

A Reluctant Manager’s Tale

Let me share a story about identity evolution that might resonate.

After a decade of being an individual contributor, I hit the infamous ceiling of the technical track. Senior Lead Software Engineer - that was as far as the technical track went. Staff+ Engineering wasn’t a thing yet, and the sole Architecture position at the company I was working for was filled. I faced a choice that would change who I was: stay a builder or become an overseer.

I chose management. Reluctantly. That’s where the path led me. I told myself it was still engineering, just at a different level. That managing systems wasn’t so different from managing people. That I could still keep my hands in the code in between other tasks.

Sound familiar? The parallels are uncanny. Just as I had to trade direct problem-solving for meetings and documentation, we’re now being asked to trade coding for prompt engineering. The skills that defined us as engineers - mastering syntax, architecting our code elegantly, catching and handling the edge cases, debugging complex issues - are being relegated to AI. Instead, we’re told to focus on skills that sound suspiciously like management: clear communication, systems thinking, problem definition.

But here’s what no one’s talking about: the identity crisis. That deep sense of loss when you realise you’re no longer building things with your own hands. When your technical mastery becomes less relevant than your ability to “manage” the tools. When your craft becomes oversight.

Can orchestrating AI ever give us that same sense of identity? Of being a builder, a creator, a problem solver?

When Machines Challenge Our Identity

By now the source of our identity crisis becomes clear. The craft we spent years perfecting - the one that gave us purpose, meaning, and pride - is now being done faster, cheaper, and at scale by a machine. Sure, the quality isn’t as good as your hand-written code (yet). But the speed at which code can now be written is staggering and businesses are tripping over themselves to get in on the action.

This is where a glimmer of hope emerges. Remember that irony - how we gave away the broader aspects of our craft to specialists? AI is pushing us to reclaim what we once knew: that software engineering transcends mere coding. That core truth remains - ultimately, software engineering is about solving problems, creating solutions, building things that matter.

These broader skills - what Addy Osmani calls “durable engineering skills” in his article on the human 30% of AI-assisted coding - have always separated great engineers from good ones. Communication, big-picture thinking, handling ambiguity - these become even more crucial in an AI-driven world.

Yet this emphasis on broader skills has sparked debate in our community. For some, it sounds suspiciously like management repackaged. And they’re not entirely wrong - a recent CIO article confirms that development teams are already being restructured to focus on oversight rather than creation. The article envisions future teams consisting of a product manager, a UX designer, and a software architect who primarily uses AI to generate prototypes. These architects, or senior developers, must “understand the content… who the customer is and what we’re trying to achieve” - classic management responsibilities repackaged as technical work.

This evolution raises fundamental questions about our identity as engineers: As the traditional career ladder transforms, how will the next generation of software engineers develop their skills? How do we preserve the deep technical understanding and craftsmanship that shaped our profession while embracing these new tools? And perhaps most unsettling - as AI capabilities advance exponentially, will our role as craftspeople become as obsolete as the manual weaver’s did during the Industrial Revolution?

The Path Forward

Perhaps the answer lies not in resisting this transformation, but in understanding it through the lens of history. These identity crises - these fundamental shifts in how we define ourselves through our work - aren’t new. They’re part of a pattern that repeats whenever technology reshapes a profession.

During the Industrial Revolution, craftspeople faced a similar crisis. Their traditional skills - honed over generations - were being replaced by machines. But what happened next is fascinating: many adapted, becoming specialist professionals who could fix and improve these same machines that threatened to replace them. Others found ways to apply their deep understanding of materials and processes to improve overall factory operations.

If we draw this parallel to our AI era, a similar path emerges. The core of software engineering - solving problems and creating value - remains unchanged. Our tools are evolving, and with them, the skills needed to wield them effectively.

The question isn’t whether we’ll become managers of machines - it’s whether we can find the same satisfaction in this evolution of our craft.

The Engineer’s Dilemma

So where does this leave us? Are we all destined to become overseers of AI agents rather than writers of code? Is this a future to resist or embrace?

The truth, as always, is nuanced. Just as some engineers naturally gravitate toward management while others prefer to remain hands-on, we’ll likely see a similar spectrum emerge in how we interact with AI. Some will excel at orchestrating AI systems, focusing on high-level design and making these systems more efficient and reliable - conducting a technical symphony rather than performing solo. Others will find their calling in domains where human expertise remains crucial - perhaps in security-sensitive applications, novel areas where AI lacks training data, or systems where performance and reliability are paramount. The key isn’t to resist this evolution, but to find our place within it.

What’s clear is that the definition of “software engineer” is expanding, not contracting. The skills that make someone valuable are diversifying. And this creates both challenges and opportunities.

For those who love the craft of coding, this shift can feel threatening. But remember that AI tools are still just that - tools. They don’t understand the “why” behind the code, the business context, or the human needs being served. They can’t innovate in the true sense of the word, at least not yet. And as far as we know, they can’t feel the satisfaction of solving a complex problem or the joy of creating something new.

Perhaps the most valuable skill in this new landscape isn’t prompt engineering or systems architecture, but adaptability - the willingness to evolve, to learn new skills, and to find your unique place in a rapidly changing field.

The Bright Side

Despite these challenges, there’s something important we need to acknowledge: these AI tools can be incredibly empowering. With agentic IDEs like Windsurf and Cursor taking software development to a whole new level, it’s like having a supportive pair-programming partner who’s always there, ready to help you tackle problems that might have seemed daunting before.

For junior developers or those of us who might feel a bit rusty, AI assistants can be a confidence booster - helping you get started when you’re staring at a blank file, validating your approach when you’re unsure, or explaining complex concepts in a way that makes sense to you. For experienced developers, they’re like having a tireless assistant who can handle the routine tasks while you focus on the more challenging aspects of the problem.

The speed at which we can now prototype ideas, explore different approaches, and learn new technologies is truly remarkable. What might have taken weeks of research and trial-and-error can often be accomplished in hours or even minutes. It’s like having a superpower - the ability to amplify our capabilities and turn our ideas into reality faster than ever before.

The Reality Check

But with great power comes great responsibility. A recent comprehensive GitClear study analysing 211 million lines of code revealed some concerning trends as AI code generation tools became more prevalent:

• A 17.1% increase in copy-pasted code, marking the first time AI-assisted code duplication surpassed refactored (moved) code.
• An 8-fold rise in duplicated code blocks, with 6.66% of commits now containing repeated code sections.
• A 26% increase in code churn, with 5.7% of all code changes being revised or deleted within two weeks.

While we’re producing code faster than ever, we’re also spending more time fixing AI-generated mistakes and dealing with code that’s harder to maintain. This isn’t just about speed - it’s about the craft of writing sustainable, maintainable software.

The Hidden Identity Crisis

Yet beneath these surface-level changes lies a deeper challenge - one that strikes at the heart of who we are as engineers. The emerging field of Human-AI teaming is revealing uncomfortable truths about our future. A 2024 study shows that when humans and AI work together, the results often fall short of expectations. Not because AI lacks capability, but because trust works differently with machines than with humans.

We don’t build trust with AI the way we do with human teammates.

With humans, trust grows gradually, through shared success. Each problem solved together strengthens the bond. Even failures can deepen trust when handled well. With AI, trust often starts high and erodes fast.

Every incorrect response, every hallucinated bug fix, every misplaced confidence weakens our faith in the machine. Unlike human relationships where trust typically grows over time, AI trust often peaks early and declines.

And when trust erodes, so does productivity.

The research reveals why:

• There’s an inherent unpredictability in how AI interprets our intentions
• It lacks the contextual awareness that makes human collaboration fluid
• Its decisions often lack transparency, making it hard to rebuild trust once lost

These challenges mirror what many of us experience when transitioning into technical leadership. Just as new engineering managers must learn to trust their team’s work without doing it themselves, we now face a similar transition with AI - learning to guide and verify rather than write every line ourselves.

The reality is stark: despite AI’s raw capabilities, teams often perform worse with AI than without it. Just as a team’s productivity suffers under ineffective leadership, our effectiveness diminishes when we don’t understand how to work with our AI tools.

Reclaiming Your Identity

Drawing from both my journey as a reluctant manager and my research into this AI transformation, I see three ways we might preserve our identity as builders:

1. Resist - Some will choose to focus on domains where human creativity and deep technical expertise remain essential
2. Adapt - Others will embrace AI orchestration, becoming conductors of a new kind of technical symphony
3. Balance - And many, like myself, will seek a middle path - using AI for routine tasks while preserving the joy of direct problem-solving

Then I had a realisation that changed my perspective: We don’t have to choose just one path.

The Identity Pendulum

Perhaps the answer to our identity crisis lies in the Engineer/Manager pendulum. My own journey between these roles taught me something crucial about identity:

• Management didn’t replace my engineering identity - it expanded it
• Returns to hands-on work weren’t steps backward - they were identity renewals
• The pendulum swing itself became part of who I am - adaptable, growing, evolving

And that’s when it hit me: This is exactly the model we need for the AI age.

Instead of being forced into permanent “AI managers,” what if we could swing between:

• Deep technical work where we write and refine code directly
• Strategic orchestration where we guide AI systems
• Creative problem-solving that combines both approaches

This balanced approach resonates deeply with what I’m hearing from fellow engineers. My research shows a clear message: maintaining strong engineering fundamentals is more crucial than ever. We need deep technical knowledge to effectively review, verify, and adjust AI-generated code - because it’s often not quite right. When asked about their concerns with AI coding assistants, software engineers ranked code quality and security well above job security.

That tells me something profound: we see ourselves as guardians of engineering excellence, ensuring that AI-generated solutions adhere to solid software engineering principles. We’re not looking to delegate our expertise to AI - we’re evolving to apply our craft in new ways.

Your Move

As we navigate this transformation, a fundamental truth emerges: our identity crisis isn’t really about AI at all. The research into Human-AI teaming, the parallels with management transitions, the pendulum of roles - they all point to something deeper. Beyond choosing between builder or overseer lies the heart of who we are: creators.

And now we come full circle: AI isn’t taking our jobs; it’s giving us a chance to reclaim those broader aspects of our role that we gave away to specialists. To return to a time when software engineering meant more than just writing code. When it meant understanding the whole problem space, from user needs to business impact, from system design to operational excellence.

The pendulum metaphor offers us wisdom here. Just as many of us have swung between engineering and management roles, we can embrace a similar fluidity with AI. Some periods we’ll dive deep into the code, experiencing that thrill of crafting elegant solutions. Other times we’ll step back to guide AI systems - not as overseers, but as master builders who understand every part of their craft. Like the Industrial Revolution’s workers who became experts at optimising the machines that transformed their craft, we can master these AI systems - making them instruments of our creativity, not replacements for it.

In the AI era, what matters most is preserving the essence of who we are: that pure joy of building things, of solving hard problems, of making something work exactly right. Our engineering excellence runs deeper than just verifying AI’s work - it flows from knowing systems so intimately that we can shape them, improve them, transform them.

The choice isn’t whether AI will change our industry - it already is. The real choice is how we evolve with it. Will we cling to an outdated sense of what it means to be an engineer? Or will we reclaim our craft, not as mere coders, but as master builders of AI-augmented systems?

The pendulum is swinging - will you hold your ground, or move with it?

Thanks for reading this post via RSS! 👋

I’ve been meaning to write about my experience at Trade Me for years. Earlier this week, I attended the launch of Rowan Simpson’s new book, How to Be Wrong. Rowan hired me into his team at Trade Me back in 2006, and to my delight, I even earned a mention in his book! That unexpected recognition, along with recently reading this article about Trade Me’s journey toward a “thinnest viable platform”, finally motivated me to reflect on what remains one of my best professional experiences to this day.

For those unfamiliar, Trade Me is an online marketplace - New Zealand’s version of eBay. In the early 2000s, it was the go-to online marketplace for Kiwis, long before global platforms like Facebook Marketplace or AliExpress were established. Trade Me isn’t just an auction site - it’s a cornerstone of Kiwi internet culture, connecting buyers and sellers across the country and becoming an essential part of daily life for millions.

Reflecting on my time at Trade Me has me thinking about something I consider often: the power of simplicity in building effective systems and how much we can learn from those simpler times.

The System That Worked

Despite the modest size of the company, when I worked at Trade Me in 2006-07, the platform was operating at a scale that many would find daunting even today: over 3.4 million active registered members (equivalent to 75% of New Zealand’s population at the time) and up to 60,000 users online during peak hours. This was no small feat for the infrastructure of the time, and it was a testament to the simplicity and efficiency of the systems we built.

Working at Trade Me was an incredible experience. Building a web app that millions of people used daily was exhilarating. Trade Me is such a beloved and recognisable brand that wearing the company t-shirt felt like a badge of honour. It was at Trade Me that I learned how to build and ship features that customers loved, and for me, it remains one of the best, most effective examples of how to do it right. W. Edwards Deming would have been proud of our approach - we were like “The Little Team That Could” - tackling challenges with enthusiasm and a sense of fun that made even the toughest problems seem solvable when approached with the right mindset.

The development team was tiny - just six software engineers, supported by a handful of DBAs, sys admins, and testers - yet we delivered an astonishing amount of work with a pace and quality that feels almost mythical compared to modern standards. There was one designer and no formal product management layer - ideas and direction came straight from Sam Morgan (the founder and CEO), Jessi Morgan and Rowan Simpson, flowing directly to those building the features.

We didn’t have the sophisticated tools or complex architectures we see today. There was no Jira, no CI/CD pipelines as we know them now, no automated testing, no cloud services, and no microservices. Trade Me was a monolithic web app written in ASP. We were migrating it to ASP.NET gradually - every page we touched had to be split into frontend and code-behind files. Deployments were automated through a custom tool: zip up the application, copy it to load-balanced web servers, unzip it, and restart IIS app pools. And yet, despite - or perhaps because of - this simplicity, we deployed to production twice daily (except for Friday afternoons which were reserved for socialising) with very few exceptions or incidents.

Looking back, I believe that success was driven by the “system” of how we worked. The team structures, culture, and decision-making processes were all incredibly well-aligned. This alignment also influenced the technical architecture, which was simple, efficient, and easy to maintain. The simple monolithic architecture, that powered a web app used by 75% of New Zealand’s population, was a direct result of our organisational structure and the way we worked, not the other way around.

Conway’s Law and Our Bias for Addition

Look at any modern tech organisation chart and you’ll see a dizzying array of specialised roles: Frontend Engineers, Backend Engineers, Fullstack Engineers, Mobile Engineers, Product Engineers, DevOps Engineers, Site Reliability Engineers, Platform Engineers, Data Engineers, Quality Engineers, Business Analysts, Product Owners, Scrum Masters, Agile Coaches, Delivery Leads… the list goes on. Now look at their system architecture diagrams - they’re often just as complex.

This isn’t a coincidence. Conway’s Law tells us that organisations design systems that mirror their communication structures. At Trade Me, the simplicity of our organisational structure directly influenced the simplicity of our software systems. With just six engineers, a few DBAs, sys admins and testers, and one designer, our communication paths were clear and direct, and the systems we built were just as straightforward.

Today, we often justify our complex organisational structures as necessary for “scaling” or “specialisation”. But what if we’re getting it backwards? What if our complex systems are a result of our complex organisations, rather than the other way around?

There’s another factor at play here: our brains are wired to solve problems by adding, not subtracting.

A study of 1,585 people found that humans default to addition when addressing challenges, often without even considering subtraction. This cognitive bias manifests in countless ways: more meetings, more tools, more processes, more people, more systems, more code. It’s no surprise that over time, our software systems have become increasingly complex - layer upon layer added in the pursuit of better outcomes.

At Trade Me, we didn’t have the luxury of adding endlessly. Limited resources and small team sizes forced us to think differently, often leading to pragmatic and simple yet elegant solutions. By keeping the system simple, we avoided the pitfalls of “more is better” thinking and achieved results that, ironically, were better because they were simpler.

What Made It Work?

So, what about the “system” at Trade Me made it so successful? Here are a few observations:

• Clear Ownership and Accountability - Each project was run by a small, cross-functional team with clear responsibilities. Each software engineer was given an opportunity to lead a project, regardless of their seniority. They got to choose their teams, and were trusted to deliver. This trust fostered ownership, pride, and accountability, and allowed us to experience what it meant to lead a software team (which I think is really important but a topic for another post). Much of this culture was driven by leaders like Rowan, whose vision and focus on getting the fundamentals right played a big part in creating an environment where simplicity thrived.

• Small, Focused Teams - Projects were staffed with just enough people - a couple of software engineers, a DBA, a sys admin if needed, and a tester. The small size forced focus and collaboration, and the simplicity of the structure kept communication overhead low.

• Pragmatism Over Perfection - We delivered value quickly and iterated as needed, avoiding over-engineering and staying focused on what truly mattered.

• Continuous Deployment Culture - Deploying to production twice daily created a feedback loop that allowed us to learn and adjust rapidly. It was an early version of the DevOps as we know it today, and it worked because we kept it simple.

• Direct Customer Insight - Many of our testers had come from customer support roles and deeply understood the end users. This close connection to the end user meant that what we built was always grounded in real needs.

What Can We Learn Today?

The Trade Me of the mid-2000s thrived on simplicity, pragmatism, and alignment. Today, we’re surrounded by tools, frameworks, and architectural patterns that promise to make our work easier, but instead, they often add complexity. So how can we apply the lessons of Trade Me to modern software development?

• Focus on the System, Not Just the Tools - Fancy tools and microservices won’t save you if your organisational system is broken. Start by defining a clear purpose and aligning teams, roles, and communication structures.

• Embrace Simplicity - Keep simplicity at the heart of your decision-making. Sometimes, the simplest solution is the best one - not every problem requires a new complex process, framework or tool. Ask yourself, “What is the simplest way to achieve the desired outcome without adding unnecessary overhead?”. Simplicity and pragmatism ensures your systems remain efficient, understandable, and maintainable over time.

• Enable Small, Cross-Functional Teams - Small teams with end-to-end ownership are still the best way to build software. Ensure they have the right capabilities and context, then empower them with agency and accountability. Crucially, ensure that software engineers are not just participants but leaders in this process. They are the ones with the technical expertise to make informed decisions on how to build the thing so their perspective matters, a lot.

• Streamline Feedback Loops - Shorten the time between idea and delivery. Whether it’s through CI/CD or daily deployments, keep your deployments small and often. Address small issues before they become big ones.

• Bring Back the Generalist - As specialisation increases, we lose the magic of software engineers who can see and build the whole picture. Let’s rediscover the value of being a “full-stack” team member. The rise of AI tools could really help here, making it easier for engineers to learn how to work effectively across different technologies and domains.

This last point is particularly relevant in our AI-driven future. While AI coding assistants are making it easier than ever to generate specialised code, they’re simultaneously lowering the barriers to becoming a true generalist. With AI handling the syntax and implementation details, engineers can focus more on the holistic understanding of systems and user needs – precisely the kind of thinking that made Trade Me so successful.

Final Thoughts

Trade Me’s approach to building software in the mid-2000s was remarkable because it was so simple and it worked so well. Our little team accomplished things that seemed impossible given our size, proving that with the right approach, small teams can achieve outsized results. Our system was capable of achieving incredible outcomes. By understanding the system as a whole and keeping things simple, we delivered exceptional quality with minimal resources.

Today, as we navigate ever-growing complexity in software development, perhaps it’s time to revisit those principles. Let’s simplify. Let’s align. Let’s recapture that spirit of small teams doing big things. Let’s build systems that enable us to do our best work, not just add layers of abstraction.

The question I leave you with is this: What would happen if you thoughtfully simplified the unnecessary complexity in your organisation and systems? What if, instead of adding more specialists, more processes, more tools, you focused on building a simpler, more aligned system where small teams could thrive? The results might surprise you.

The tools have changed, but the principles remain timeless. It’s time to rediscover the power of simplicity.

Thanks for reading this post via RSS! 👋

This incident perfectly illustrates a fundamental principle of systems thinking: when you push hard on one part of a complex system, it pushes back in unexpected ways. Peter Senge captured this insight in The Fifth Discipline as one of his laws of systems thinking: the harder you push, the harder the system pushes back.

The Software Development Lifecycle (SDLC) is one such complex system, and right now, we’re pushing on it harder than ever before. If you’re working with AI tools, you’ve probably experienced this yourself - code that used to take hours or days to write is now generated in seconds. “The code just writes itself now!” has become a common refrain in development circles. And while it’s not entirely wrong, it’s making us face some fascinating challenges.

What happens when code generation is no longer the bottleneck? Here’s what you’ll start seeing: larger PRs piling up in review queues, test suites taking longer to run, and deployments struggling to keep up. As we accelerate one part of the development cycle, the system inevitably responds in ways that demand our attention - and you’ll need to be ready.

Pipeline Pressure Points

As we accelerate code generation with AI, we’re seeing the system push back at both ends of our development pipeline - both before and after the actual build phase.

UX: The Pre-Build Bottleneck

Software development has always been constrained by implementation speed. Even at the 1968 conference where the term “Software Engineering” was coined, the word “cost” appears 96 times throughout the report - and they weren’t just talking about hardware. Despite decades of new methodologies, frameworks, and automation tools, writing code has remained stubbornly time-consuming.

But AI coding assistants are changing this equation dramatically. Tasks that used to take days - like scaffolding new APIs, building authentication systems or perfecting UI layouts - now take hours or minutes. The implementation speed that has bottlenecked our industry for decades is suddenly dramatically increasing.

And that’s when a new challenge emerges. I recently came across this Reddit post that hints at what’s coming:

While most teams are still focused on adopting AI for faster code generation, some early adopters are already hitting a different wall: they can implement features faster than they can design them. The bottleneck is shifting from implementation to conception - from how to build it to what to build.

This is systems thinking in action - as we optimise one part of the pipeline, we’re exposing constraints elsewhere. Soon, our biggest challenge won’t be writing code, but rather understanding user needs, designing intuitive interfaces, and crafting requirements that actually solve real problems. We’re going to need new ways to accelerate these early stages of development to keep pace with our AI-enhanced implementation capabilities.

The Speed Wobbles: Post-Build Challenges

Remember learning to ride a bike? There’s that terrifying moment when you’re going so fast that the handlebars start to shake. You’re not doing anything wrong - you’ve just hit that speed where everything starts to wobble. That’s exactly what’s happening in our development pipelines.

The ripple effects of accelerated code generation are showing up in unexpected places. As mentioned in a previous post, the 2024 DORA Report revealed a fascinating paradox: while AI tools are improving many of the things we typically associate with better delivery - documentation quality, code quality, code review speed, and reduced complexity - the industry is actually seeing a decline in overall delivery performance.

This highlights another key principle of systems thinking: improving individual components doesn’t necessarily improve the system as a whole. In fact, it can make things worse if those improvements aren’t balanced across the entire pipeline. The DORA findings suggest that our development processes, built and optimised over decades for human-speed code generation, need fundamental rethinking to handle the velocity that AI enables.

Adapting to AI-Driven Development

As these pressure points emerge, we’re seeing new tools and practices evolve to help us adapt. These adaptations focus on two key areas: how we provide context to our AI tools, and how we think about our source artifacts themselves.

The Importance of Context

Here’s a scenario every developer knows too well: you’re working with a new teammate, and they ask you how to use the company’s internal authentication library. You point them to the documentation, only to realise it’s woefully outdated. So you spend the next hour walking them through the codebase, explaining the patterns, the gotchas, and trying to recall why certain decisions were made.

Now imagine having this same conversation with an AI coding assistant. Without proper context, it’s just as lost as that new teammate. Sure, it can write decent code from simple prompts, but ask it to work with your custom libraries or follow your team’s patterns that it can’t possibly know anything about, and it’s flying blind.

This is why we’re seeing tools like LLMContext.com and Uithub.com emerge. These tools create rich, interpretable context files from your entire development ecosystem. Not just source code, but documentation in various formats - from Markdown files to PDFs, and even content from images and other media (thanks to Microsoft’s MarkItDown tool).

It’s like giving your AI assistant the equivalent of that hour-long walkthrough. Now when you ask it to add a feature using your authentication library, it understands the patterns, the constraints, and the team conventions. The code it generates isn’t just syntactically correct - it feels like it was written by someone who actually knows your codebase.

This emerging need for rich, well-structured context is yet another way the SDLC is pushing back. As our AI tools get better at writing code, we need better ways to help them understand our code.

Are Specs and Prompts our New Source Code?

Perhaps the most fundamental adaptation is in how we think about source code itself. When we were writing code by hand (wow, that feels weird to say), the most important thing to store safely was the source code. It’s in the name - source. From that, you should be able to derive everything else you need to know about how the system ought to operate.

The reality is that we’re not writing all the code by hand anymore. Instead, we’re writing specifications and prompts for AI coding assistants to generate code for us. And this raises an important question: if all you’re storing is the generated output of the LLMs, isn’t that almost the equivalent of only storing compiled code (bytecode, IL, binaries) instead of the source code?

We’re not in entirely new territory here. Test-Driven Development (TDD) and Behaviour-Driven Development (BDD) have long emphasized the importance of capturing the intent behind our code - TDD through tests, BDD through behaviour specifications. Both approaches ensure we’re clear about what we want before we build it. The same principle applies here - without capturing our intent, we’re just hoping the implementation does what we think it was intended to do.

The rise of AI-generated code raises interesting questions about code understanding. As AI generates more of our code, some worry we’ll lose our grasp on how it all works. But maybe that’s looking at it wrong - if we can capture and validate our intent clearly enough, debugging might become less about understanding the implementation and more about refining the specification. Think of it as hitting replay with a slightly modified script.

Following this line of thinking to its natural conclusion - if prompts and specifications are becoming our new source code, shouldn’t we treat them with the same care and organisation? Just as we’ve developed sophisticated ways to store, manage and share code, we need new tools and practices for managing our AI interactions. Here are three ideas that are already starting to emerge:

1. Prompt Libraries

Remember when we used to stash away useful code snippets? Those bits of tried-and-tested code that we’d copy-paste into new projects? For me it was SQL - I couldn’t help but keep almost every piece of SQL I ever wrote in a folder because you just never knew when it was going to come in handy again!

Well, welcome to the AI era’s equivalent: Prompt Libraries. Instead of storing code in repos, we’re now starting to store and share the prompts that consistently generate good outputs. We’re already seeing this materialize in practice - a recent article on dev.to highlights several emerging prompt libraries that are bringing engineering rigor to prompt creation and management.

Imagine having a library of prompts that you know will generate a solid REST API endpoint, complete with error handling and input validation. Or prompts that reliably create accessible React components following your team’s conventions. These proven prompts deliver predictable, high-quality results, just like the code libraries we’ve always relied on. We’re moving from sharing snippets on GitHub Gists to building entire ecosystems for testing, sharing, and versioning our most effective prompts.

This shift isn’t just about storing prompts - it’s about the emergence of prompt engineering as a crucial skill. My recent research revealed that 56% of software engineers see prompt engineering as highly important for their future role, while only 21% consider it unimportant.

2. Intent Records and Templates

Here’s another idea worth exploring: as AI increasingly generates our code, we need better ways to capture the reasoning behind implementation choices. I’m imagining something that I’m calling Intent Records - think of them like Architecture Decision Records (ADRs) but specifically designed for AI generation, capturing both what to build and why to build it that way.

An Intent Record could specify something like: “We need a caching layer that prioritises read speed over write speed because our analytics dashboard needs to handle 10,000 concurrent users viewing real-time data”. To standardise these records, we could develop Intent Templates - similar to how Detailed Design Documents (DDDs) structure their content - ensuring teams capture all necessary requirements, constraints, assumptions and design decisions that guide AI code generation.

3. Spec Modules

Building on this concept of structured documentation, here’s another idea to consider: what if we had reusable building blocks for creating AI-ready specifications? We could call them Spec Modules - pre-built specification components that describe in detail specific types of functionality. Need authentication? You’d grab a spec module that defines the security requirements, API endpoints, and user flows. Want a shopping cart? There’d be a module ready to customise with your specific business rules.

By breaking down specifications into these AI-friendly modules, you wouldn’t just be making your work more efficient - you’d be creating a new kind of component library. One that exists at a higher level than traditional code libraries, providing AI systems with clear, consistent instructions for generating reliable, production-ready code.

Rethinking the SDLC: AI is Pushing Back

For as long as software engineering has existed, we’ve been searching for ways to build better software with less pain. Faster builds, simpler deployments, shorter feedback loops. Every new methodology, every new tool, every process improvement - it’s all been about reducing friction and cognitive load in the development pipeline.

And now, AI coding assistants have done something remarkable. They’ve removed one of our longest-standing bottlenecks: the speed of writing code. It’s no longer a question of how fast we can build something - it’s a question of whether we can keep up with what we’re creating.

But software development isn’t just about writing code. It never was. The real work happens before the first line is written and long after the last commit. And now that we’ve uncapped code generation speed, we’re seeing pressure shift to everything around it - design, testing, review, deployment. The SDLC is pushing back.

In The Future of AI-Driven Software Engineering (Terragni et al., 2025), we explored where this shift is leading us. AI isn’t just accelerating development - it’s reshaping the way we build software altogether. Requirements need to be clearer. Design decisions and intent need to be explicit and recorded. Testing and validation need to scale. Our workflows, our tools, even our mental models of software engineering are being rewritten in real time. Our research suggests that AI itself might help address these emerging needs - from requirements analysis through to testing and deployment - though with varying levels of maturity across different stages of the lifecycle.

The implications are profound. The teams that understand and adapt to these system pressures now will be the ones that thrive in the AI era. As AI reshapes software development, it’s not just changing our tools - it’s transforming how we think about the entire discipline. The engineers who thrive in this new era will be those who excel at shaping intent, thinking in systems, and designing solutions that leverage both human insight and AI capabilities to build better software in ways we’re only beginning to imagine.

Thanks for reading this post via RSS! 👋

To set the scene, I’m a software engineer with over 20 years experience. I have a degree in Computer Science and Math and spent the first half of my career in hands-on individual contributor roles across 7 industries and 4 countries. I would generally describe myself as a C# .NET backend dev but I’ve built my fair share of frontends and even some mobile apps. I’ve hopped back and forth between management and engineering roles over the last decade. I haven’t written code as part of my day job for about 5 years now. I still enjoy building software myself and have plenty of grand ideas that I’d love to bring to life, but sadly it just takes too long.

I’ve been using Windsurf to help me write R and Python scripts for my research. Besides that, I’ve been tinkering with agentic AI frameworks like CrewAI (more Python), a couple of small web-based games (JavaScript) and experimented building mobile apps (React Native). These experiences have taught me a lot about working with AI coding assistants.

Before I dive into my specific experiences, it’s worth noting that as with any new technology, it takes time to learn how to use it well. There’s simply nothing as effective as real hands-on experience and deliberate practice to build skills. Learning how to collaborate with an AI coding assistant is no different. In fact, initial insights from my Master’s research shows that there is a strong correlation between frequency of use and developer productivity, with daily users reporting significantly higher productivity than infrequent users.

With that in mind, let me share what I’ve discovered about these tools - both the parts that have delighted me and the parts that have occasionally frustrated me. My experience aligns well with what other developers have reported: there’s a lot to love, but also some important quirks to be aware of.

The Good Parts

It’s like a fabulously helpful pair programmer

Using Windsurf really does feel like you have an endlessly patient and supportive pair programmer by your side. Interactions feel natural, like you’re actually collaborating on a piece of work with another human being. It helps you think through problems, suggests improvements, and catch potential issues before they become bugs.

It’s great at automating away toil and repetitive tasks

Have you ever had to go through and tediously update heaps of files or strings just for consistency’s sake? Sometimes you can get away with a simple find + replace, but sometimes that just doesn’t cut it. Windsurf can pick up on these sorts of patterns and rip through them automatically, systematically updating every occurrence in a file or string. This can save you a lot of time!

I should mention that sometimes it doesn’t pick up on all the instances, so it’s a good idea to double check its work - but it certainly takes most of the grunt work away from you.

It can run scripts, see the results and react autonomously

When using Windsurf’s Cascade feature in ‘Write’ mode, it will not only create and edit source code, but it will also offer to run it for you. You can configure it to run certain commands automatically, but otherwise it will just pause and ask for your confirmation. If you let it run your script, it will see any output or logs that would’ve been piped out to the terminal. If there are any errors in that output, it will automatically attempt to fix them. If not, it may try to summarise what it saw and provide insights or suggestions.

You see what I mean when I say it’s like having a fantastic pair programmer by your side?

It’s great for prototyping and experimenting with unfamiliar languages

As I mentioned earlier, I’ve been using Windsurf to help me write R and Python scripts - languages that I’ve barely ever used before. In the past, I didn’t steer clear of trying new technologies, but it would just take me a long time to get anything done. Windsurf has made it so much easier to prototype and experiment with code, supporting you in a way that reduces cognitive load and gives you a sense of confidence.

However, this ease of use comes with an important caveat: you still need a solid foundation in programming concepts. These tools are incredibly powerful, but they’re more like highly capable assistants that help you implement your ideas, rather than complete replacements for programming knowledge. They can help you learn a new language’s syntax or framework’s API, but they can’t teach you fundamental programming principles from scratch.

This leads to an interesting challenge: while these tools make it easier to try new things, it’s hard to gauge how much you’re actually learning. I can write R and Python code much faster now, but I’m not sure I could write particularly good code in either language without continued AI assistance. It’s a bit like having training wheels that you’re not sure you should take off.

This is exactly what Addy Osmani describes in his article about the “70% problem”. The initial progress feels almost like magic - you’re writing code in languages you barely know! But then reality kicks in: without underlying experience and expertise, you may find yourself stuck at that 70% mark, unable to tackle the more complex challenges that require deeper understanding.

The Annoying Parts

It can get stuck in an endless loop of incorrect suggestions

Sometimes you’ll ask it to write some code and it won’t get it right. Then you’ll tell it that that didn’t work and it will try something else, which also doesn’t work. This back and forth can go on for a while, and often it can lead you right back to the original incorrect suggestion. As you can imagine, this can get quite frustrating!

Since Windsurf has this agentic nature, it can also end up in this sort of loop itself - recognising that it’s made a mistake and trying to fix it repeatedly. The biggest downside of this is that it can end up making a lot of unnecessary changes to your code which you then need to try and unpick.

My advice here is to recognise when it’s going down these sorts of rabbit holes and asking it to stop, undo all the changes it’s made, go back to the start of the task, take the time to think about the problem, use chain-of-thought reasoning, make plan and start again. It can also help to tell it to make the least amount of change possible. This is often enough to help it find a better solution quicker.

It’s not great with transitive relationships in scripts

I’m not sure if it’s the way I’m structuring my R scripts or a limitation of the tool, but say I’ve got an R script (analysis.R) which loads another (setup.R), which in turn loads another (helper.R). I expect Windsurf to know that it can access and should use functions defined in helper.R from analysis.R, but it often doesn’t and instead creates new functions directly in analysis.R. I have to keep reminding it to reuse the functions defined in helper.R.

The Surprising Parts

It makes mistakes, but knows it too

Like humans, it makes mistakes. However, every now and then you see evidence of the underlying agentic nature of Windsurf kicking in. It will make some changes, realise that it’s made a mistake, and fix it all by itself. This is probably one of the most impressive things I’ve seen it do.

It doesn’t question you and takes (most of) your suggestions seriously, even when it was right

I’ve noticed that it will generally trust you even when you’re wrong. For example, if it suggests some code and you ask whether that is the most efficient way to do it, even if you know that it is, it will second-guess itself and suggest a different, less efficient approach instead.

What I tend to do is when I ask it a question like “is this really the best way to do this?” is add “challenge me if you disagree”. This seems to help it assess my question more freely, rather than just agreeing with me and finding another potentially less ideal because I dared ask.

The model you’re using really matters

Windsurf allows you to choose between three models: GPT 4o, Claude 3.5 Sonnet and Cascade Base. I’ve tried GPT 4o and Claude 3.5 Sonnet primarily, and I’ve got to say that Claude 3.5 Sonnet beats GPT 4o for the sort of coding tasks I’ve been using it for, hands down. Interestingly, I’m a huge fan of GPT 4o via ChatGPT for everyday tasks, but for coding, Claude 3.5 Sonnet is my go-to choice now.

If you want structured outputs, give it structured prompts

Think of using these tools like talking to another developer, perhaps someone early on in their career. If you give them vague requirements, chances are that what they’ll build won’t be quite what you were after. If you give them clear and concise specifications, there’s a better chance of getting what you want.

The same thing applies when using AI coding assistants. The more specific you can be, the more likely the outcome will match your expectations.

Keep changesets small and commit often - source control is your friend

Keeping changes small and focused is a fundamental best practice in software development, regardless of your tools. However, it becomes even more critical when using AI coding assistants because they can generate code so quickly that you’ll have hundreds of changes before you realize it. The larger the changeset, the harder it is to spot mistakes and the more time-consuming the review process becomes.

I’m not alone in noticing this challenge. The 2024 DORA Report found that AI adoption is actually negatively impacting software delivery performance, contrary to what many expected. Their research suggests that the dramatic increase in productivity and code generation speed is leading to larger changesets, contradicting DORA’s principle of small batch sizes which are essential for stability.

So what does the future hold?

Research clearly shows that AI coding assistants boost developer productivity, but their impact goes far beyond simple efficiency gains. These tools are enabling a renaissance in personal software development. By handling routine tasks and reducing the cognitive load of working with unfamiliar technologies, they free us up to focus on what truly matters - creating innovative software that delights users and makes us proud.

To be honest, it’s been a while since I spent so much time coding. Not for a lack of ideas - I’ve got plenty of those - but for lack of time. Building anything useful takes time, precious time. But with AI coding assistants, I feel supercharged. The barrier between having an idea and bringing it to life has never been lower, especially for experienced developers who can guide these tools effectively.

Yet this new era of software development brings its own unique challenges. How do we effectively provide AI assistants with enough context about our codebase? How should we store and version control the prompts or specifications we use to guide code generation? And what about the explosion in the number of repositories being created, now that the barrier to creating new projects is so much lower? These represent entirely new problems that we’ll need to solve as this technology matures, and I’ll be writing more about each of these areas as I uncover and learn more about them.

If you haven’t tried an AI coding assistant yet, I strongly encourage you to give it a go. Pick a tool that suits you best and get started. Start small, be patient as you learn how to work with them effectively, and most importantly - have fun exploring what’s possible. Remember that these tools are currently the worst they’ll ever be - just two years ago, what we now take for granted seemed almost impossible.

The future of software development is being reshaped right now, and it’s an incredibly exciting time to be part of it.

Thanks for reading this post via RSS! 👋

At the end of the day, software systems are just components stitched together to perform seemingly complex tasks, but the logic behind it all is very deterministic. As software engineers, we write lines of code to tell computers to do very specific things, in very specific orders. The computer then executes those instructions in a deterministic way, and we’re left with a very predictable system that can be hard to change or adapt to new requirements.

With agentic AI, we’re no longer bound by the limitations of this deterministic approach. Agentic AI allows us to use LLMs to intelligently adapt and evolve these integrations. We simply equip agents with skills (tools) and memory to help them solve problems, and they work out the rest on their own. These agents can use various architectures to tackle problems - one popular approach is ReACT (Reasoning + Acting, not the frontend framework we all know and love), which allows them to think through problems step by step, just like a human would - reasoning about what to do next, then taking action based on that reasoning.

The Rise of Agentic AI

I’m certainly not alone in my enthusiasm for agentic AI.

Just in the last week, Jensen Huang, CEO of NVIDIA, remarked that we’re entering the era of agentic AI at the CES 2025 event and Sam Altman, CEO and co-founder of OpenAI, also said that “AI agents will join the workforce” in 2025 in his blog post, Reflections:

“We believe that, in 2025, we may see the first AI agents “join the workforce” and materially change the output of companies.”

Microsoft announced a set of new agents for Microsoft 365 in November 2024, including:

• A Facilitator agent for Microsoft Teams, that will take notes and summarise meetings
• An Interpreter agent for Microsoft Teams, allowing users to speak to one another in their language of choice
• A Project Manager agent, which automates overseeing entire projects, including plan creation, task assignment, progress tracking and status reporting
• An Employee Self-Service agent, enabling employees to get real-time answers and take action on key HR and IT topics

The research community has also recognised the potential of agentic AI, with researchers from Berkeley, Stanford, Google DeepMind, OpenAI, Anthropic, MetaAI and others running fantastic massive open online courses like Large Language Model Agents:

“With the continuous advancement of LLM techniques, LLM agents are set to be the upcoming breakthrough in AI, and they are going to transform the future of our daily life with the support of intelligent task automation and personalization.”

I thoroughly recommend watching the lectures which are available on their YouTube Channel.

It’s impossible not to see the enormous potential in all this. The future of software lies in systems where LLMs drive the logic engine, dispatching instructions to invoke tools, which in turn can also be powered by LLMs. Erik Meijer captures this vision perfectly in his paper Virtual Machinations: Using Large Language Models as Neural Computers, drawing parallels between conventional and neural computers:

Through his comparison of conventional and neural computers, Erik builds towards his fascinating work on developing a natural language-based reasoning language for programming these neural systems. This work has the potential to introduce a whole new type of computing and I can’t wait to see what they achieve.

From Theory to Practice

With a bit of time on our hands this Christmas, Jason Vella and I decided to run our own mini-hackathon. We set ourselves a goal of building something using an agentic AI, mainly for learning purposes. Even though the concept is quite nascent, there are already quite a number of agentic AI frameworks out there:

• LangChain: A framework for developing applications powered by language models, with composability and modularity.
• LangGraph: An extension of LangChain for creating stateful, multi-agent applications using a graph-based approach.
• AutoGen: An open-source framework for building AI agents that can collaborate to solve complex tasks.
• CrewAI: A framework designed for rapid prototyping of multi-agent systems for ease of use and quick iteration.
• LlamaIndex: A data framework for building LLM applications, focusing on data ingestion and retrieval.
• Semantic Kernel: Microsoft’s AI orchestration framework combining natural language processing with traditional programming.

We chose to use CrewAI as it seems to a good option for getting something up and running fairly quickly. They’ve got some good examples and loads of great documentation.

Going Meta: The Recursive Developer

CrewAI is a Python-based framework (it seems most are), and unfortunately I’ve had very little experience writing Python. Luckily, I have become pretty good at using Windsurf. Its Cascade feature, powered by AI Flows, actively reasons about my intent and helps me write code in languages I’m not familiar with - it’s like having an AI collaborator that truly understands what I’m trying to achieve. Although it’s not entirely obvious, you can see when different agents within the flows are collaborating on a code change - sometimes it will make a change, recognise that it’s made a mistake, and fix it - all without me having to say anything. So here I am, using one agentic AI system to help me build another, how delightfully meta and yet more proof that agentic AI is the future!

This experience validates what Andrew Ng recently discussed in The Batch about AI-coding assistants being especially effective for prototyping. It also aligns perfectly with findings from my Master of Engineering research on the impact of AI coding assistants on software engineering. In analysing software engineers’ responses about workflow changes, I have found that those using AI coding assistants were not only more likely to explore unfamiliar technologies but also felt they could prototype faster. To me, it feels like having an endlessly patient pair programmer to work with!

Building My First Agentic AI System

Out of the box, setting up a CrewAI project creates a simple, default “Research Assistant” crew which was nearly exactly what we chose as the first example anyway! Since I need to find and read papers for my Master’s study, an automated research assistant felt like a practical, achievable and useful system to build.

At this point, Jason spun off to play with AutoGen while I designed my research assistant crew to find the five most relevant recent papers on a given topic, matching them against specific research questions, and then deliver a summary by email. I decided to give my “research aggregator” agent a custom tool using Google Scholar (via SerpAPI) and my “research analyst” agent another custom tool to send emails using the Gmail API.

To run it automatically, I used launchd, although I’m sure cron would’ve done the job nicely too. And for the last couple of weeks, I’ve received a daily digest of interesting and relevant papers on the impact of AI coding assistants on software engineering, complete with links and insights! I love it!

The Challenges of Non-Deterministic Systems

The biggest head-scratcher came when trying to pass variables between tasks. My research analyst agent has two jobs: summarise papers into a markdown file, then email that summary. Simple, right? My programmer brain figured I could configure the filepath once and pass it into each task as an argument - which you kind of can, but the agent seems to be modifying it before using it.

What I discovered is that working with agentic AI systems requires a different debugging mindset. When your system can think and adapt, tracking down why it’s not behaving as expected becomes a lot more difficult. It’s not just about finding logic errors anymore – it’s about understanding how the agent is interpreting and executing its tasks.

This and many other challenges will become the new software engineering problems to solve. I believe these are the sorts of problems that Computer Science and Software Engineering students will study in the future. This is something that I’m particularly interested in and hope to continue to uncover further as I continue my research.

Besides that quirk, I spent most of my time building the logic for the tools. There’s for sure going to be a market for these ’tools’ which are basically just little client libraries built over APIs. CrewAI allows you to use tools built for both LangChain and LlamaIndex, as long as you wrap them in custom tools.

What’s Next

When I was much younger, I used to stay up way too late building side projects. I seemed to have boundless energy to tinker away with the latest and greatest at the time (AJAX, Google Maps, then later, Windows Phone, Objective-C - ahh, the good ol’ days). But life got in the way and nowadays I never seem to find the time to spend building all the ideas I have. However, AI tools like Windsurf and ChatGPT have given me such a boost that many of these ideas now seem within reach again, removing the friction that often stops us from turning ideas into reality.

Then add the extended possibilities that agentic AI frameworks give us and well, it’s not hard to see the massive opportunities that lie ahead. The only real constraint now is our imagination. If you can imagine it, you can probably build it - and fairly quickly, too.

Of course now that I’ve built one of these, I want to build more. I’ve always loved the idea of having software “do things for me” in the background and now, with little effort, it can do so much more. The hardest thing might be to train my brain to not limit itself when dreaming up the next side project.

If you’re a software engineer reading this, please don’t wait - dive in and start playing with these tools as soon as can. Like any new technology, they take time to master, but the learning curve is absolutely worth it. The sooner you start experimenting, the sooner you’ll discover just how much they can amplify what you can build and how you build it. After all, it really is agents all the way down.

Thanks for reading this post via RSS! 👋

My passion for continuous learning kicked into overdrive these past couple of years, leading me down fascinating intellectual paths. Could it be that AI has helped make information more accessible? Or is it that I’ve finally found my calling? I can’t really say for sure, but I’ve found myself deeply immersed in several interconnected domains:

• W Edwards Deming, Russell Ackoff and Peter Scholtes
  • Systems Thinking
  • Leadership
  • Organisational Design
• Generative AI
  • AI-Assisted Development
  • Agentic AI Systems
  • LLMs as CPUs
• Active Inference
  • Free Energy Principle
  • The Bayesian Brain
  • Information Theory
  • Cognitive Science
• Quantum Computing
  • Error Correction

These topics have rekindled a passion for abstract and theoretical thinking, something I enjoyed so much at university but could never find a practical reason to keep doing. Exploring these topics is leading to some fascinating new thoughts, tickling my brain in the best possible way. There’s a constant desire to soak in more information and turn it into knowledge and honestly, it’s becoming a bit of an obsession.

I’m convinced that all this learning has been valuable in my role at Westpac NZ, where I continue to explore and shape what staff engineering and technical leadership mean at an organisational level. It’s an energising mix of driving technical excellence and shaping strategy, while ensuring our engineering practices align with and support ourbusiness outcomes. What I love most is how it lets me champion both Systems Thinking and continuous learning - whether I’m working with executives on strategic initiatives, collaborating with architecture teams on governance, or mentoring engineers to grow our technical leadership capability.

This obsession with learning has manifested in several ways this last year:

• I started a part-time, research-only Masters of Engineering at the University of Auckland. I designed and kicked off a longitudinal study to explore the impact of AI on software engineering. The first questionnaire is already collecting some really interesting data that I’m enjoying analysing.
• I continued to study Deming’s philosophies and in the process, discovered other big thinkers like Russell Ackoff and Peter Scholtes. This has led to a deep sense of awakening around Systems Thinking and leadership. It has left me wondering why in all these years I had never come across these inspirational thinkers before, even though I’ve read countless books on leadership. As a mentor said to me recently - “the student wasn’t ready yet”.
• I attended a Deming Leadership Seminar run by The Deming Institute in Columbus, Ohio, connecting with many other Deming students and coaches, and deepening my understanding of his philosophies.
• I even got to visit the IBM Innovation Lab in Poughkeepsie, New York, and saw a real functioning quantum computer in person!

Beyond consuming data and information and transforming it into knowledge, I continued to push myself to share what I was learning through public speaking - something that still scares me but in a good way:

• Taking the stage at StaffPlus London marked a significant milestone - my first major international conference. While the prestigious nature of this event sparked many nerves, the experience proved incredibly rewarding.
• I kept the momentum going by speaking at several other events and even gave a talk on Quantum Computing.

Perhaps the most unexpected development was rediscovering my love for coding. After years focused on leadership and management, analysing my research data in R and Python reignited that old spark. With the help of AI coding assistants, I’m now enjoying getting things to work again. I even built an Agentic AI Research Assistant that curates and delivers personalised research paper digests daily for my Master’s study - the kind of project that combines my love for coding with my passion for learning.

Looking back, I’m proud to have achieved my 2023 goal of speaking at an international conference, along with making significant strides in reading and writing more. While these achievements demanded considerable time and energy, the one area that didn’t get enough attention was exercise - and I really miss that energy boost it gives me.

In 2025, my goal is to leverage all these learnings and become more efficient at capturing, processing, and digesting information. Hopefully this will create more space and time for exercise, because growth isn’t just about the mind - it’s about the whole system, right?

Key Accomplishments of 2024:

Conference Talks:

• Staff Engineering: A Technical Alternative to Management at Code Camp Wellington in Wellington, NZ, on April 13
• Deming’s Wisdom for Staff+ Engineers: A Modern Take on Timeless Principles at StaffPlus London in London, UK, on June 11
• The Biggest Lessons I’ve Learned as an Engineering Leader at The Movac Engineering Jam in Auckland, NZ, on September 17
• Quantum Computing 101: An Easy Introduction to a Hard Topic at Ada Lovelace Day in Auckland, NZ, on October 9

Panels:

• Ada Lovelace Day 2024 – Celebrating Female Tech Leaders Panel in Auckland, NZ, on October 8
• DevFest AI Panel in Auckland, NZ, on November 10

Podcasts:

• S1E3 - Distinguished Engineer Annie Vella’s wild career journey and finding joy as a reluctant manager recorded with Scott Carey for LeadDev PriorityZero Podcast in London, UK, on June 11
• Systems Thinking, AI, and Innovation with Annie Vella recorded with Jakub Jurkiewicz for Tech Waka Podcast in Auckland, NZ, on November 26

Conferences Attended:

• Microsoft AI Tour in Sydney, Australia, on February 7
• Deming Leadership Seminar in Columbus, Ohio, USA, on October 16 & 17

Books Read / In Progress:

• “What Is ChatGPT Doing … And Why Does It Work?” by Stephen Wolfram
• “The New Economics” by W. Edwards Deming
• “The Leader’s Handbook: Making Things Happen, Getting Things Done” by Peter Scholtes
• “Active Inference: The Free Energy Principle in Mind, Brain, and Behavior” by Thomas Parr, Giovanni Pezzulo, and Karl J. Friston

Thanks for reading this post via RSS! 👋

It didn’t take long after ChatGPT was released for me to start seeing how fundamentally this technology could transform software engineering. Not just as another tool in our arsenal, but as something that could redefine what it means to be a software engineer entirely.

The discourse around this has been fascinating. Jump on LinkedIn or X and you’ll see endless debates about whether AI will augment or replace software engineers, whether it’s just another productivity tool or a paradigm shift, whether it’s overhyped or understated. But I think many are missing the real story - it’s not about whether AI will take our jobs, it’s about how it’s already changing the very nature of our profession.

This transformation has captured my attention deeply. You see, I’m a software engineer. I still call myself one even though it’s been a few years since I actively built software because I’ve been busy leading teams of software engineers for the last few years. But I still think of myself as a software engineer.

You’ll often hear me talk about how much I’ve loved my career, because I genuinely have. Perhaps I was lucky and found my calling at a very young age, but ever since I lay my little 6-year-old fingers on that Commodore 64, I was hooked. Since I believe software engineering has been a great career choice, and I want everyone to experience the same joy and fulfillment that I have, I’ve encouraged many people to consider it as a career over the years.

Until now, most changes I’ve experienced in our field felt more like evolution than revolution. I saw web technologies take off - remember when AJAX became a thing and jQuery was your ticket to building cool dynamic websites? I lived through mobile taking off, cloud computing, CI/CD, and so on. But in many ways, we were just doing the same things with newer toys: new frameworks, new approaches, much more automation.

When AI Changes Everything

What’s happening now with AI, however, feels far more like a tectonic shift than just another iteration of the same old cycle - and my Master’s research is confirming this. The data clearly shows that AI is already having a significant impact on how software engineers work. Not everyone sees it. Not everyone wants to see it. But it’s happening.

Many in our industry remain confident that our roles as software engineers are safe because software engineering is much more than coding. The prevailing argument is that while AI might help us write code faster, the “real” work of software engineering lies in designing systems, making architectural decisions, and understanding user needs. It’s a comforting thought, isn’t it? A neat way to put AI back in its box as just another productivity tool.

I totally agree that software engineering should be a lot more than just writing code. When I studied computer science at university, they taught us how to elicit requirements, write user stories, design user interfaces and apply UX principles, architect complex systems, create test plans, execute test cases and so much more. The whole shebang.

But here’s where it gets interesting: many developers today aren’t actually doing all those tasks anymore. I’m lucky enough that for the first 10 years of my career, when I was an individual contributor, I got to do all these things. I spoke to clients and stakeholders directly, gathered requirements, asked questions, made suggestions, and challenged their assumptions. Ultimately, I was given problem statements and solved them. I wrote frontend and backend code, designed database schemas and built them all from scratch, wrote and fine-tuned SQL queries, configured web servers, set up build pipelines, and monitored how things were running. I felt unstoppable - through hands-on practice, I had gained the skills to build and run software end-to-end. And god, it felt good. At my core, I was solving problems, and that’s what I love doing.

How We Got Here: The Rise of Specialisation

Looking back at that experience now, it feels like a different era. Over the last decade, I’ve watched software engineers step back from many of these responsibilities. Many now focus almost entirely on writing the code, letting others handle everything else.

Why has this happened? Well, I’m sure there are many reasons. I can’t help but wonder if at least part of the reason is that as software needs grew exponentially, the demand for software engineers grew too - and there just weren’t enough of us. So we found ways to divide and conquer through specialisation. We introduced roles like the Product Owner who speaks to the customer and collects requirements for us, so that we can focus on the part that others perceive to be the part that only developers can do - writing the code. In some organisations, there are also Business Analysts analysing requirements, Project Managers coordinating delivery, Designers doing the UI/UX, Architects doing the solution design, Quality Engineers doing the testing, and Platform Engineers setting up the infrastructure, running the pipelines, and generally keeping the lights on.

I’m not alone in noticing this shift. Alex Ewerlöf wrote about this recently in his piece on breaking roles into multiple titles. He sees what I see - how splitting up our craft this way is making us lose the very things that made software engineering special: the ownership, the synergy, the true craftsmanship.

By breaking up what used to be the role of a software engineer into all these disparate jobs, what’s really left? For a lot of software engineers, the only thing that’s really left is writing the code.

Product Engineers vs. Traditional Engineers

To prove my point, new titles like “Product Engineers” have emerged to describe software engineers who do what everyone claims software engineers should be doing - you know, all those things that supposedly keep us safe from AI.

Sherif Mansour wrote a piece describing product engineers as “not traditional engineers”. Another article distinguishes them as unique because they “care about building a solution to problems that provides value to users” - as opposed to just “writing code and shipping features” like traditional software engineers apparently do.

And here’s the kicker. An article from earlier this year describes product engineers as:

In recent years, the software industry has started to adopt the term product engineer to refer to a customer-focused, full-stack engineer who blurs the lines between product and engineering roles. I think of product engineers as generalists who can take an ambiguous problem statement, define a solution to it in collaboration with users or customers, and design, implement, and deliver that solution.

Hang on a second, I thought that was what software engineers did?!

Yikes. Talk about contradiction - our industry claims software engineering is about so much more than coding, yet we’ve created a special new term for engineers who actually do those things, while regular software engineers have become specialised code writers and feature shippers. So much for all those things that were supposed to keep us safe from AI!

“So what?”, you might say. Perhaps there’s room for both. After all, there’s so much demand for software engineers, and maybe some just want to focus on writing the code.

The Game-Changer: Generative AI

That argument might have held water a year ago. But then generative AI came along. Because as it turns out, LLMs (and agentic AI) are really good at writing code, and much, much faster than any human can. And here’s the problem: most “traditional” software engineers today do little more than translate almost-pseudo-code written requirements in user stories into compilable code - exactly the kind of task that AI is becoming better at every single day.

Sure, if you’re one of the rare “product engineers” who actually work on the full spectrum of software engineering, perhaps you’re fine. But remember, we just established that this has become the exception rather than the rule.

What the Data Says

AI’s impact on coding isn’t just speculation. My Master’s research so far has confirmed that AI coding assistants are already reducing the time professional software engineers spend on writing code, with a staggering 78% of 165 respondents across 28 countries feeling they’re spending less time writing code.

I wrote about the potential impacts of AI on software engineering back in February 2024 - An Early Exploration of AI-First Development - and boy has this landscape changed since then. It feels like there are new tools that do more, better and faster being released every single day. My research survey ran for a month in October / November 2024, and I was stunned to see how many AI tools software engineers are already playing with. Windsurf didn’t get a mention but it hadn’t even been released yet!

Steve Yegge and the Stubborn Developer

Steve Yegge recently wrote a follow-up to his controversial article The Death of the Junior Developer, reframing his position as The Death of the Stubborn Developer. He talks about how if you’re not adopting Chat-Oriented Programming, or CHOP, you’re getting left behind.

If you’re not using chop, then you’re plodding. You’re like one of those crusty old assembly-language holdouts still using asm in 1990 because compiler-generated code wasn’t fast enough. Stubborn bastards, the lot of ’em. Sound familiar?

I agree with everything he says in his riveting but lengthy article, except perhaps the part about autonomous software agents. I’ve spent the last month using Codeium’s Windsurf - self-described as the “first agentic IDE” - and I tell you what, it’s absolutely incredible. This is so much more than just chat, copy, paste, repeat. With Windsurf, I tell it what I want and it generates all the code. All of it. And honestly, the code is good. And if it isn’t, I just tell it to fix it and it does! Sometimes it even recognises that it’s made a mistake before I do and it goes ahead and fixes it without me having to say anything. The future is here, my friends.

Cursor is another fantastic IDE that works in much the same way. And then there are countless other web-based tools that can create entire codebases from a prompt, like Bolt, v0, and of course, Lovable.dev which is gaining traction at an incredible rate.

From CHOP to BATON

These tools are just the beginning. I think we’re rapidly moving into an era where humans no longer write code by hand. Instead, we instruct agentic AI systems that use LLMs to do it for us. But it’s not just about one-on-one interaction with AI - the future might look more like managing an entire AI development team. In From CHOP to BATON: The Evolution of AI-Assisted Development, the author explores what comes after CHOP, introducing a new paradigm called BATON - Bot-Assisted Task OrchestratioN:

With BATON, your role shifts from being a hands-on coder to something more akin to a conductor or a project manager. You’re no longer writing every line of code yourself, or even pair programming with an AI. Instead, you’re breaking down projects into well-defined tasks, delegating them to multiple AI systems, and overseeing the entire development process. Need a suite of unit tests written? Delegate it. Have a simple, but annoying feature to implement? Assign it to your AI team.

In other words, CHOP is just the beginning. With BATON, a software engineer’s role shifts from coding line-by-line to orchestrating and overseeing multiple AI “team members,” each responsible for different chunks of work. This represents a fundamental change in what it means to be a software engineer - and a clear signal that we need to expand our skill sets beyond just writing code.

So What Can You Do About It?

If you’re a software engineer and upon reflection suspect you may have fallen into the trap of specialising as a code writer, listen up. It’s time to broaden your horizons. To get started, you could try:

• Participating in all the activities involved in building software, not just writing code
• Requesting problem statements instead of accepting pre-digested solutions disguised as user stories
• Shifting yourself left - joining your Product Owner in stakeholder meetings, asking questions, challenging assumptions, and making suggestions
• Understanding the drivers behind the work by exploring the data and decisions shaping your projects
• Reading Gergely Orosz’s article on the 9 key traits of product-minded engineers and developing those skills

So dear software engineer, please take heed. If you’re not a “product engineer” and have specialised in writing code, AI may indeed take your job. But this isn’t just a warning - it’s an opportunity. It’s time to reclaim your role and return to what software engineering was always meant to be: a craft that combines technical expertise with problem-solving, user empathy, and business acumen. The future belongs to those with curiosity who can see beyond the code.

Thanks for reading this post via RSS! 👋

"If I were given one hour to save the planet, I would spend 59 minutes defining the problem and one minute resolving it."

— Albert Einstein

In my role, both as a software engineer and technical leader, I’ve witnessed firsthand the tendency to dive into problem-solving without fully grasping the problem itself. We chase after solutions, applying our experience and tools without considering if we’re aiming at the right target. This often leads to wasted effort, frustration, and missed opportunities.

When we talk about defining the problem, it’s more than just identifying the obvious. It’s about understanding the underlying layers - the root cause, the impact on the business, the user, and the broader system. It requires patience, curiosity, and a willingness to challenge assumptions. In my experience, it’s this depth of understanding that separates good engineers from great ones.

First Principles: The Foundation of Solutions

Once the problem is clearly defined, the next step is to solve it from first principles. This concept, which comes from physics, suggests that we break down complex problems into their most basic elements. By starting from these foundational truths, we avoid relying on assumptions or existing models that might not apply.

In the context of software engineering, solving from first principles forces us to rethink how we approach technical challenges. Are we building on outdated architectures or practices simply because “that’s how it’s always been done”? Are we making design choices based on constraints that no longer exist?

When I coach teams, I often find that revisiting first principles can be a powerful way to unlock innovation. It frees engineers from the burden of legacy thinking and opens up new pathways to more efficient, elegant solutions.

But What About the Gaps?

When we break things down to their most elemental parts, we gain clarity on each piece of the puzzle. But there’s a danger here too - focusing only on the parts risks missing the important bits in between: the interactions.

It’s like trying to understand a car by focusing on each part separately. Sure, the engine, wheels, and brakes all have their functions, but it’s the way they all interact that makes the car drive smoothly. And this is where systems thinking comes in.

Systems thinking reminds us, as Russell Ackoff so aptly put it, that a system is more than the sum of its parts; it’s the product of their interactions. In a previous post, I explored Ackoff’s philosophy and the difference between analysis and synthesis - if you’re curious to explore that side of the conversation, feel free to check it out here.

A system is never the sum of its parts; it’s the product of their interaction.

— Russell Ackoff

Whether we’re debugging a piece of software or optimising a process, we need to look at how each part interacts with the others - and how the system as a whole interacts with the larger environment it’s a part of. Only then can we fully understand what we’re working with.

So, What’s Next?

The journey to truly effective problem-solving is about discipline. Define the right problem to work on, then solve it from first principles - but don’t stop there. Remember to consider the interactions between the parts and the system’s place in the larger picture. It sounds simple, but it’s incredibly powerful when applied in practice.

In the world of software development, where speed and agility are prized, it’s tempting to jump to the solution. But if we pause - if we spend that crucial moment, as Einstein suggested, defining the problem thoroughly - we can ensure that our solutions are not only quick but also meaningful and lasting.

As technology continues to evolve, this approach will only become more crucial. The rise of AI, quantum computing, and other cutting-edge innovations will demand engineers who can not only execute quickly but also think deeply. That’s the kind of team I enjoy building and working with - one that thrives on curiosity, challenges assumptions, and delivers solutions that truly matter.

Thanks for reading this post via RSS! 👋

I first encountered Auto-GPT over a year ago and was intrigued enough to join their Discord community. At that time, the concept of autonomous AI agents was still in its early stages, and Auto-GPT was pioneering an approach that allowed AI systems to autonomously generate and execute their own goals. This innovative idea resonated with me, reinforcing my belief in the transformative potential of specialised AI agents across various industries.

As I continued to explore this concept, Andrew Ng’s discussions on agentic AI further deepened my understanding, highlighting how these specialised agents could revolutionise the way we approach complex problems.

While the broad potential of agentic AI to automate and optimise a wide range of jobs is exciting, my focus naturally sharpens when I consider its application to software engineering. This focus ties back to my ongoing Master’s research, where I’m exploring the broader impact of AI on software engineering practices. In this context, agentic AI stands out as particularly powerful, offering the possibility to fundamentally change how we develop, test, and maintain software.

What is Agentic AI?

Agentic AI involves multiple specialised AI agents working collaboratively to achieve complex goals. Imagine a team of experts, each with a specific focus - one agent excels at writing code, another at testing, and yet another at conducting security reviews. These agents don’t operate in silos; instead, they communicate, iterate, and refine their outputs together, much like a well-coordinated human team.

Andrew Ng, a prominent AI thought leader, emphasizes in his talks, “What’s Next for AI Agentic Workflows” and “Andrew Ng on AI Agentic Workflows and Their Potential for Driving AI Progress”, that agentic workflows are inherently more iterative than current LLM-based agents, which typically operate on a zero-shot basis. This iterative nature allows agentic AI to achieve significantly better outcomes. For instance, while zero-shot GPT-3.5 achieved a 48% success rate on the HumanEval coding benchmark, and zero-shot GPT-4 improved to 67.6%, multi-agent AI systems like AutoDev and AgentCoder achieved significantly higher success rates, reaching 91.5% and 96.3%, respectively. This stark contrast highlights the potential of agentic AI to surpass the capabilities of traditional models.

Vision Agent: An Open Source Agentic AI from Landing AI

One of the practical implementations of agentic AI is the Vision Agent, an open-source project developed by Andrew Ng and his team at Landing AI. This agentic AI system is designed to specialise in computer vision tasks, enabling different AI agents to collaborate on complex visual processing tasks, such as object detection, image classification, and anomaly detection.

The Vision Agent framework allows for the modular combination of AI agents, each focusing on a specific aspect of the task. For example, one agent might specialise in edge detection, while another focuses on object classification. By allowing these agents to work together, Vision Agent can deliver more accurate and robust results than a single AI model working alone. The framework’s open-source nature also makes it accessible for developers and researchers, encouraging collaboration and further innovation in the field of agentic AI.

MetaGPT: A Multi-Agent Framework

MetaGPT is discussed in the paper “Data Interpreter: An LLM Agent For Data Science” by Hong et al. This multi-agent collaborative framework is designed for software development, simulating the software development lifecycle by leveraging multiple AI agents, each specialising in a particular role, such as project management, code writing, and testing. This approach emulates a human software development team, where various specialists collaborate to complete a project effectively.

However, like many multi-agent systems, MetaGPT encounters challenges related to coordinating multiple agents and managing communication overhead. Despite these challenges, MetaGPT illustrates the potential of agentic AI to mirror and enhance human-like collaboration in software development.

AgentCoder: Multi-Agent Code Generation

AgentCoder, presented in the paper “AgentCoder: Multi-Agent-based Code Generation with Iterative Testing and Optimisation” by Huang et al., represents another significant advancement in agentic AI. This system is designed specifically for multi-agent code generation, incorporating effective testing and self-optimisation mechanisms. AgentCoder uses a team of AI agents to not only generate code but also to iteratively test and optimize it, ensuring higher quality and efficiency in the code produced.

In evaluations, AgentCoder demonstrated exceptional performance, achieving 95% success on the HumanEval benchmark by leveraging the strengths of multiple specialised agents working together. This success underscores the promise of agentic AI in enhancing the software development process, from code generation to testing and optimisation.

AutoDev: Automated AI-Driven Development

Microsoft’s AutoDev is another cutting-edge framework that exemplifies the potential of agentic AI. As described in the paper “AutoDev: Automated AI-Driven Development” by Tufano et al., AutoDev is designed to fully automate software engineering tasks. It enables AI agents to autonomously perform a wide range of operations within a codebase, including file editing, building, testing, and git operations, all within a secure, user-controlled environment. The framework’s effectiveness was demonstrated on the HumanEval dataset, where it achieved a Pass@1 score of 91.5% for code generation and 87.8% for test generation.

AutoDev goes beyond simple code suggestions, integrating deeply with the development environment to manage tasks that typically require significant human intervention. Its ability to handle complex, multi-step tasks autonomously marks a significant leap forward in the capabilities of AI-driven development tools.

Why Agentic AI Matters

The implications of agentic AI are profound, extending far beyond a single industry. If we can truly harness the potential of agentic AI, the automation of many jobs may be closer than we realise. These AI systems, capable of handling interconnected tasks across various domains, could lead to significant shifts in how work is structured and executed. By distributing tasks among specialised agents, entire workflows could be automated, potentially reducing the need for human intervention in areas that were once considered too complex for AI to manage.

In software engineering, this evolution shifts the focus from human-led coding to human-led prompting. As agentic AI systems take on more of the actual coding, testing, and reviewing, the role of engineers may pivot toward describing requirements in precise, effective ways to guide these AI agents. This change underscores the importance of developing strong skills in articulating and refining prompts - prompt engineering - as the ability to communicate effectively with AI will become increasingly critical in this new paradigm.

Looking Ahead

The journey toward fully realising the potential of agentic AI is just beginning. The advancement of frameworks like Auto-GPT, AutoDev, AgentCoder and MetaGPT represents a significant step forward in this direction. As we continue to develop and refine these technologies, we’re likely to see even more transformative impacts on the way we approach software engineering.

Thanks for reading this post via RSS! 👋

Stepping into a Distinguished Engineer role last year pushed me to explore leadership in new ways. It was during this time that I discovered Deming’s work, which provided me with clarity and direction. His insights have shaped how I think about creating environments where engineers can thrive and continually improve.

For those interested, my slides from the talk are available here, and you can find the video of the talk here. It may still be paywalled, although I hope it will be accessible soon. In the meantime, below is a summary of the key points I covered during the talk.

Why Deming?

W. Edwards Deming, known as the father of Total Quality Management, is best known for his work in post-war Japan, where his teachings on quality and systems thinking transformed industries. Deming wasn’t merely concerned with improving processes; his focus was on changing how we think and lead.

For me, discovering Deming’s work felt like finding a key piece of the leadership puzzle. His emphasis on continuous improvement and pride in workmanship deeply resonates with my own values. But what really struck me was how much Deming’s views on leadership aligned with what I had already believed. One of his quotes that I agree with wholeheartedly is, “To manage one must lead. To lead, one must understand the work that he and his people are responsible for.” This idea is central to effective leadership – ensuring there is a deep understanding of the work happening across the organisation and the challenges engineers face. Curiosity plays a vital role here too. By staying curious, continuously asking questions, and exploring how things work, one is better equipped to provide the right guidance and support. Deming’s philosophy reinforced this, showing that leadership is about more than oversight; it’s about being in tune with the system, the people involved, and the processes that drive improvement.

Deming to DevOps

Deming’s influence can be traced through modern methodologies such as Toyota’s Production System (TPS), Lean Manufacturing, Agile, and DevOps. His teachings laid the foundation for continuous improvement, reducing waste, and optimising processes, all of which are central tenets of Lean and Agile. In the software world, these principles evolved further into DevOps, where collaboration and system optimisation are critical for improving quality and speed.

Deming’s System of Profound Knowledge

At the heart of Deming’s philosophy is his System of Profound Knowledge, which consists of four key areas:

1. Appreciation for a system – Recognising that organisations are socio-technical systems, where nothing happens in isolation. Changing one part can have unintended consequences elsewhere, so we must optimise systems holistically.
2. Knowledge about variation – Distinguishing between common cause (inherent in the process) and special cause (due to external factors) variations is key. Common cause issues require systemic changes, which fall under management’s responsibility.
3. Theory of knowledge – Questioning why we know what we know, grounding actions in facts and context. Operational definitions ensure clarity and consistency in our understanding.
4. Psychology – Refers to the human aspects of work. Intrinsic motivators and purpose are essential for creating productive and enjoyable work environments.

For Staff+ Engineers, these concepts are invaluable when tackling complex systems. Whether we are improving processes, enhancing collaboration, or driving innovation, Deming’s principles guide us toward a more holistic understanding of the challenges we face.

Deming’s 14 Points for Management

Deming’s 14 Points for Management serve as a practical guide for leaders striving to create better systems and environments. While all the points are valuable, a few stood out to me as especially relevant for Staff+ Engineers:

1. Remove barriers to pride in workmanship – Empower engineers to take pride in their work by eliminating obstacles that hinder creativity and innovation. When people enjoy their work, it drives both personal satisfaction and organisational success.
2. Drive out fear – Build a culture where open communication is encouraged, and people feel safe raising issues without fear of blame. This is closely related to the modern concept of psychological safety, which is crucial for fostering innovation and a supportive work environment.
3. Break down silos – Promote collaboration across teams to ensure smoother workflows and better outcomes. When silos are broken down, organisations become more agile and effective.
4. Institute training and self-improvement – Continuous learning is essential, not just for individual growth but for the long-term success of teams. Investing in self-improvement helps teams adapt and thrive in an ever-changing landscape.

Practical Applications in Modern Software Engineering

Deming’s teachings are directly applicable to modern software engineering practices. In my talk, I explored three key areas where these principles can be applied today: Shift Left, Site Reliability Engineering (SRE), and Developer Productivity.

Shift Left

Shift Left involves moving security and quality testing earlier in the software development lifecycle to detect issues sooner and reduce costs. Deming’s appreciation for a system fits perfectly with this approach—by integrating quality into the development process from the start, we reduce the need for inspection and rework later on. As Deming said, “Quality does not just happen: it is built in.” Adopting the new philosophy is also critical for embracing this shift, as it requires a mindset shift across the organisation. Everyone must be on board with the idea that quality is a shared responsibility, not something that can be inspected into a product, especially not at the end of the process. This mindset change helps ensure that quality is built in from the beginning rather than flung over the fence to dedicated test teams.

Site Reliability Engineering (SRE)

SRE applies software engineering principles to IT operations, aiming to create scalable and reliable systems. Deming’s belief that “A bad system will beat a good person every time” is particularly relevant to SRE. When incidents occur, it’s not about individual failures but about systems allowing those failures to happen. Knowledge about variation is key here—understanding the different types of variation (such as common cause vs. special cause) allows us to address system issues effectively and improve reliability. Theory of knowledge also plays a crucial role. In SRE, SLOs are operational definitions that help us to measure system performance through automated monitoring and alerting, allowing for data-driven insights. This approach ensures that we’re continuously learning and improving based on real data rather than assumptions.

Developer Productivity

Improving developer productivity has become a major focus in modern engineering teams. As Deming said, “It isn’t enough to do your best; you have to know what to do, and then do your best.” This aligns with his theory of knowledge, which emphasises the need for data-driven decisions. To improve productivity, we need to measure the right things and understand them within the context of our systems. Additionally, psychology plays a critical role—factors like job satisfaction, motivation, and psychological safety all directly impact productivity. By creating environments where developers feel valued and supported, we can significantly boost both productivity and morale.

Final Thoughts

Speaking at StaffPlus London 2024 was one of the highlights of my year. Travelling from New Zealand to such a renowned event and sharing my insights alongside experienced technical leaders was an incredibly rewarding experience. I am so grateful for the opportunity to explore how Deming’s timeless teachings continue to resonate in our modern world and how they can help us lead more effectively as Staff+ Engineers.

Reflecting on my relatively recent journey with Deming’s work, I’m reminded of his unwavering belief in continuous improvement and the pursuit of knowledge. For those of you in Staff+ roles, I encourage you to embrace systems thinking, foster collaboration, and always keep learning. As Deming famously said, “Learning is not compulsory; it’s voluntary. Improvement is not compulsory; it’s voluntary. But to survive, we must learn.”

Thanks for reading this post via RSS! 👋