The new leverage of software engineering

Engineering teams have been investing heavily in AI and there are clear benefits emerging. Engineers move faster. Boilerplate takes less time. Tests are easier to write. Documentation is less painful to maintain.

But if the headline impact is that the same team gets through the same backlog a little faster, that isn't the transformation we were promised, and it's a pretty poor return on the investment.

Software companies are built around a familiar constraint: engineering capacity. Developers can only do so much, so everything queues behind them.

A designer wants to test a new dashboard component? Add a ticket.

A support lead wants to improve an internal workflow? Ticket.

Someone in operations wants to automate a repetitive task? Ticket.

The bottleneck has rarely been coming up with ideas. It's that every change must flow through a small number of people. But if agents can understand a system, generate code, wire up an interface and explain the errors, hasn't that bottleneck gone away?

The lazy version of this argument is: "AI makes everyone a developer now." It doesn't, and it shouldn't. Letting anyone vibe-code straight into production isn't empowerment. It's arson.

Engineers are right to worry about low-quality code, missing tests, accessibility problems and security holes. Those concerns separate "works on my machine" from "safe to run our business on."

But the answer can't be that only engineers are allowed to change software. The more interesting question is: what would need to be true for more people to change it safely?

Build the tracks, not just the trains

None of this is new thinking. Platform engineering has been preaching golden paths for years: clear service boundaries, automated tests, feature flags, approval workflows, observability, automatic rollbacks. The idea was never the problem. The cost was. Those foundations take months of work that rarely reaches the top of the backlog, because guardrails don't ship features.

That's what I believe AI actually changes here. The same capability that makes engineers faster at writing features also collapses the cost of the boring foundational work — drafting tests, configuring integrations, extending delivery pipelines, fitting existing tools together. Guardrails that were unaffordable become affordable. And affordable guardrails expand who can contribute.

The best place to start with this is somewhere low-risk and high-friction: internal tools, dashboard components, onboarding flows and admin interfaces. Let someone propose a change. Let AI refine the idea and draft code, run the checks and then create a preview. Require approval where needed, and roll back if it misbehaves.

A product manager shouldn't be able to edit authentication because they had an idea on a Tuesday afternoon. But should a designer be able to create a button text A/B test, run visual and accessibility checks, launch it to 20% of users and measure the outcome? Why on earth not?

And honestly, the primary beneficiaries of this will be developers. A front-end engineer who can confidently make a change deep in an unfamiliar backend, because the tests, boundaries and rollbacks catch mistakes before they matter, owns a complete problem instead of half of one. The guardrails that make it safe for a designer make it safe for everyone.

Beware, though: the bottleneck doesn't vanish, yet.

Now it’s worth being honest about the catch here: if every AI-drafted change still needs an engineer to approve it, you haven't removed the queue. You've just turned engineers into full-time reviewers, and review is its own bottleneck.

But review scales differently to authorship. A well-guarded change — tests passed, checks green, blast radius contained, rollback ready — takes minutes to review, not hours. And the checks compound: every failure mode you automate is one a human never has to catch again. The goal isn't zero engineering involvement. It's engineering judgement applied where it matters: what should change, where the risk sits, and what standard a contribution must meet.

That doesn't make engineers less important. It makes their judgement incredibly valuable. This is the new leverage of AI software engineering, I believe. Not clearing the queue faster, but building a system in which fewer changes need to join it at all.

Back in the era of the generalist

For most of my career, the advice has been to specialise.

Choose a discipline. Become excellent at it. Build a career around the depth of expertise that other people do not have.

That advice made sense. Most organisations were built around specialists because most worthwhile work required specialist tools and knowledge. A software developer wrote the code. A designer designed the interface. A researcher spoke to users. A product manager decided what should be built and tried to keep the whole thing moving in roughly the same direction.

One person could have a view across all of it, sure, but they could not do all of it well enough to produce a serious result.

Now though, I think it’s different.

We are back in an era in which someone with a broad set of skills, good judgement and an ability to learn can have an extraordinary ability to just get shit done.

Not because expertise no longer matters. Not because one person should replace an entire team. But because AI has dramatically increased how far one capable person can follow a problem before they need to hand it to someone else.

Following the problem

The most useful generalists are not simply people who can do a bit of everything. They are people who can stay with a problem.

They can work out what is actually happening, rather than accepting the first description they are given. They can speak to the people affected, examine the evidence, understand the constraints and explore more than one possible answer. They can make something, put it in front of people, learn where they are wrong and improve it.

Until recently, that journey usually crossed too many professional boundaries for one person.

Understanding a problem might require user research and data analysis. Exploring it might require service design or technical investigation. Testing an answer might require interface design, software development, copywriting and some kind of operational process. Even a relatively simple prototype could involve a small team, a collection of handovers and several different queues of work.

Now, someone who is strong in one of those areas can become capable enough in the others to carry an idea much further.

A product manager can interrogate a dataset, build a working prototype and put it in front of customers. A designer can connect an interface to real data and test the interaction rather than presenting a static mock-up. An engineer can analyse customer conversations, explore the wider service and test whether the thing they can build is the thing anyone needs.

The output will not always be production-ready, and I’m not sure that it should be expected to be. The important change is that one person can now get far enough to at least learn something real.

From specialist to product person

I studied software engineering and started my career as a software developer. Over time I moved towards product management.

That move was treated as a change of discipline. I stopped being a developer and became a product manager. The skills I had learned as an engineer were useful, but the organisational model encouraged me to work through an engineering team rather than continue building things myself.

There were good reasons for that. The software became more complex. The consequences of getting it wrong became greater. Doing both jobs properly was difficult, and half-doing either one was not useful.

But I can now do enough of both again.

I can explore a problem, research unfamiliar areas, work with data, design a service, build a prototype and test it with real people. I can use specialist tools without spending years becoming a specialist in each of them. Where I lack knowledge, I can get much further before needing help—and ask much better questions when I do.

That does not make me the best designer, engineer, researcher or analyst in the room. It makes me capable of getting to the point where we know which room we need, who should be in it and what they should work on.

That is a different kind of leverage.

Generalism is not vibe coding

The shallow version of this argument is that AI makes everyone an expert. It does not.

Generating some code does not make someone a software engineer. Producing a plausible interface does not make them a designer. Summarising a set of interviews does not mean they understand the people they are trying to serve.

AI makes it easier to produce convincing rubbish as well as good work. Without judgement, a generalist can move very quickly in the wrong direction.

The useful skill is not knowing a little about lots of things. It is knowing how the different parts of a problem fit together, where your own understanding is weak and when the work requires genuine depth. It is being able to distinguish a shortcut that helps you learn from one that quietly creates risk for somebody else.

The best generalists will still depend heavily on specialists. They will bring in an experienced engineer before a prototype becomes critical infrastructure. They will involve a researcher when the people affected are difficult to reach or the conclusions carry real consequences. They will know that legal, clinical, security and policy expertise cannot be approximated by a confident conversation with a language model.

AI does not remove the need for expertise. It changes when it is needed and makes it easier to use precisely.

Instead of assembling a full team around an untested assumption, a generalist can do enough work to expose the parts that are genuinely difficult. Specialist time can then be spent on the questions that deserve it.

Organisations built around outcomes

This should change how teams are formed.

The default response to a new idea has often been to identify all the disciplines it might require, estimate the capacity needed from each and put the work into their respective queues. That is expensive, so organisations understandably reserve it for ideas that already appear fairly certain.

The result is a familiar trap: an idea needs evidence before it can earn a team, but it needs a team before anyone can produce the evidence.

A capable generalist can break that loop.

Give one person a meaningful problem, access to the people who understand it and the tools to investigate it. Let them produce the first useful account of what is happening. Let them test the cheapest version of an intervention. Then form the team around what the work reveals, rather than around the assumptions made at the beginning.

This is not a case for running organisations as collections of heroic individuals. Important work still needs teams, institutions and durable expertise. It is a case for recognising that the smallest useful unit of progress has changed.

One person can now create enough momentum to make a problem legible, testable and worth organising around.

A return, but not a reversal

There is nothing particularly new about the generalist. Anyone building something from nothing have always had to move between disciplines. Early-stage founders do not get to declare that customer research, finance or operations sit outside their role. People doing difficult work in small organisations have always learned whatever the problem demanded.

What is new is the quality and range of work that one person can now produce, and how much more accessible this ability is. 

The generalist is no longer limited to coordinating specialists or producing a rough approximation while waiting for the real team to arrive. With good tools, good judgement and selective specialist help, they can investigate, build and test to a standard that creates genuine evidence.

We were told to specialise because specialisation was how ambitious work got done. That will remain true for many parts of the work.

But the ability to cross boundaries, learn quickly and hold the whole problem in view is becoming valuable again. As execution gets cheaper, the scarce capability is increasingly knowing what deserves to be done, seeing how its parts connect and staying with it long enough to make progress.

The age of the specialist is not over.

But we are definitely back in the era of the generalist.

More and more I'm appreciating just how important communication is in all aspects of life, and how incredibly difficult it is to be genuinely good at it. Professionally speaking, I now see my ability to communicate as the most important aspect holding back career growth. The ability to execute, have good ideas and deliver improvement are all worth so much less if they're not effectively and intelligently communicated to the right people. 

I know I need to write more. To think more deeply. But it feels like everything around me works to break my focus, and recovering that is something I struggle with.

When reading Bill Gates' autobiography I learned about his think weeks. A week alone, offline, with little more than a stack of books, paper and a pen. At the time I felt that was unnecessary. Now I think that would be the ultimate luxury. 

I’ve just ordered the Rabbit R1.

I was tempted when it was first announced, but the first version seemed to miss the mark and was widely considered almost useless. But the team behind it kept going. They’ve refined it, improved it, and the new version of the OS looks much more capable.

I’ve also had a craving to play with hardware for a while now. The Playdate is on the wish list, as is basically everything designed by Teenage Engineering.

The R1 still has a compelling promise: a simple, dedicated device for asking questions, checking a status, capturing a thought or task. Maybe having a specific device for that means I pick up my phone less often, and avoid getting dragged into the usual time-draining habits.

Maybe it still isn’t quite there and ends up unused in a drawer within a couple of weeks.

Only one way to find out.

Back to Whoop

After twelve months away from it I'm returned to Whoop. I got a lot of value out of it when I first used it, but when my son was born I knew training would have to take a back seat for a little while. We're now in more of a position where regular training is happening, goals are being reset and my craving for more data is increasing. 

Of course 24 hours after re-subscribing, Google announced the Fitbit Air. It looks great but perhaps a little basic in terms of sensors and datapoints. I'm looking forward to seeing what the early reviews make of it because the price point is otherwise excellent. A screen-free, cheap, data capture device that I can then apply my own analysis to is exactly what I'd opt for.

Switching to Fastmail

I've used Google Workspace for about 15 years now, and it's been great. The Google ecosystem is comfortable and works well. But more recently — and AI may well be the trigger here — I've wanted to have more ownership of my own data. To know where it is and what it is being used for.

To this end, I've started to build a personal database. I'll share more on that another time, but I'm opting to capture books, films, wines and coffee beans in there rather than use and maintain four different social services that are all essentially just advertising platforms. AI can now provide answers to the "based on my profile, what would I next enjoy" question, so I can trim away the rest.

It's a common saying that if you're not paying for the service, then you and your data are the service. So much of the Google ecosystem is shared, analysed, surfaced and optimised around keeping you inside it, rather than simply providing a requested service.

Email felt like the obvious place to start. Not because I think it's the most at risk, but because it sits underneath so much else. It’s a 15-year archive of messages, receipts, logins, family admin, travel plans, account recovery. A boring utility, until you stop and realise how much of your life passes through it.

I’ve had my own domain for years, so my email address itself isn’t changing. That makes this a much lower-risk move than it would otherwise be. I don't need to ask anyone to update contact details (my parents still try and email my university address!) and I’m not breaking old accounts. I’m just moving the plumbing from Google Workspace to Fastmail.

In theory, this is exactly the kind of internet I prefer. Open standards. A paid service with a clear business model. IMAP, SMTP, custom domains, boring reliability. Less “ecosystem”, more utility.

There’s something quite appealing about that. So let’s see how long this phase lasts.

Having Kids

And while having kids may be warping my present judgement, it hasn't overwritten my memory. I remember perfectly well what life was like before. Well enough to miss some things a lot, like the ability to take off for some other country at a moment's notice. That was so great. Why did I never do that?

See what I did there? The fact is, most of the freedom I had before kids, I never used. I paid for it in loneliness, but I never used it.

With my son now approaching his first birthday I can relate a lot to this piece from Paul Graham. Raising a child has been considerably harder than I anticipated. Don't get me wrong, it's equally the most incredible and fulfilling experience too, but it is relentless, and in the tougher moments it's easy to look back and think about the freedom you've since lost. 

Except I never used it.

It's just easier to essentially blame that fact on another part of your life than own up to it. There's also no reason why that freedom has to be lost, and this is something my wife and I are trying to fight. Sure, it's harder to travel with a one year old. Even more so with a dog. But it's far from impossible if that's what you really value. 

Craig Mod: MacBook Neo and How the iPad Should Be

I agree with a lot of this. The iPad has for too long occupied this strange middle ground. The hardware has been extremely capable for years whilst the software has inexplicably lagged behind. This is now more noticeable with AI.

I've been tempted through the years to consider the iPad Pro as my primary machine. After all, a vast majority of my work only requires a browser; everything of note is a web app or would have an iOS app available. But now, a main device that cannot run Claude Code or Codex wouldn't really be an option. It would feel like having my hands tied behind my back.

The Neo looks to be a great machine. A desire for that kind of device is why I picked up a second-hand 12-inch MacBook last year. Small and capable, though without an M-series chip it was never going to be a long-term main machine.

I still wonder where the iPad fits into my routine. Not as capable for work as a MacBook. Not as good to read on as my Kindle. Not as immediately available as my iPhone.

As Craig finishes by saying, it'll be very interesting to see how John Ternus approaches this when he begins as Apple CEO in September. The iPad is clearly very successful and a popular device, but is an ever closer convergence between iOS and macOS the right approach?

It'll also be fascinating to see how rumoured devices like the OpenAI hardware Jony Ive is working on may disrupt this space. Does the future of computing look completely different in ten years' time?

Manipulation versus management, tools versus agents

I recently read an essay by Alan Kay from 1989 that originally featured in The Art of Human-Computer Interface Design, edited by Brenda Laurel. This was essentially before the internet, before smartphones, and long before any of the AI assistants we now use daily. And yet it describes the exact problem we’re still trying to solve.

Kay makes a distinction I haven’t seen articulated as clearly anywhere else. Humans have extended themselves in two ways throughout history.

First, through tools. Physical things we manipulate directly. A hammer, a keyboard. The feedback is immediate. You hit a nail and it moves.

The second way is through management. Convincing other entities to work toward our goals. Other people, historically. But increasingly, software that acts on our behalf. What Kay calls agents.

The interface challenge for these two categories is completely different. With tools, the question is how efficiently can I manipulate this? With agents, the question is how do I know if I can trust this to complete the task I set?

This has been something that I’ve been thinking about this as I’ve played with various AI products. The onboarding for poke.com felt immediately familiar. Within minutes it felt like it “knew” me. But after a week the novelty wore off. Sure, it drafted emails, but I always felt the need to adjust before sending.

This is essentially the gap Kay identified. We’re trying to apply tool-based expectations to something that requires a completely different interaction pattern.

Kay wrote that the thing we most want to know about an agent is not how powerful it is, but how trustable it is. The agent must explain itself well enough so that we have confidence it’s working for us rather than as what he calls an escaped genie.

He predicted agent development would move in two directions. First, expanding into domains where mistakes don’t matter much. Where undo is easy. These would move fast. The second direction would move slowly. Domains where undo is hard or impossible. Where mistakes affect real relationships or irreversible decisions.

Looking at where AI has actually expanded, this prediction holds remarkably well. Code completion moved fast. Autonomous decisions in healthcare or finance remain constrained. The pattern isn’t about technical capability. It’s about reversibility, confidence and trust. Not in the technical abilities, but in the agent itself.

What strikes me most is his claim about explanation. Kay argued that well-done explanation will be needed regardless of how the agent is instructed. The interface challenge isn’t about making AI more conversational. It’s about making the reasoning legible enough to calibrate trust. When I ask an AI to draft something and then need to adjust it before sending, that gap represents a trust calibration failure. The AI was confident. I wasn’t. And I couldn’t easily understand why our judgments differed.

The hardest part to accept is that this might not be primarily a technical problem. Tool-based interfaces can be evaluated through direct feedback. Agent-based interfaces require something closer to the trust calibration we use with human colleagues. But with humans, we have shared context. We have social structures that create accountability. We build trust through repeated interactions where we observe judgment against outcomes.

None of these mechanisms exist for AI agents. The conversational interface creates an illusion of familiarity, but the underlying trust architecture is still largely missing.

Kay saw this clearly in 1989. We’re still figuring it out. But we’ll get there.

Wales stands at a critical moment as our economy continues to degrade the natural resources that underpin our health, security, and prosperity. Wales is one of the most nature depleted countries in the world, with almost 1 out of 5 species at risk of extinction.

Wales’ consumption levels far exceed sustainable limits. If replicated globally, our resource use would require more than two Earths, demonstrating the amount of natural resources we import, all accompanied by impacts on other countries

— State of Natural Resources Report 2025

The State of Natural Resource Report 2025 paints a very bleak picture. All too often we look elsewhere, at what other countries are doing or the United Kingdom as a whole. But here in Wales we’re at a critical point. Our history, particularly agriculture which accounts for 90% of Welsh land, isn’t easily compatible with achieving climate goals. Recent changes to legislation, including the Sustainable Farming Scheme has real potential, though it’s still not perfect and is still struggling to balance the agricultural industry and people with the broader needs of our country.

Reading this report is making me really think about my own impact. We’ve all got to do more to protect nature. I need to find out what that is, though. There’s a lot to think about here.