But there was no wifi, no mobile phones, no internet in our rooms. Instead I would cycle to the engineering department, trudge up to the sixth floor computer lab, find a Sun workstation with a floppy drive - a Sparcstation 2 if I was lucky, a 1 or 1+ if not - and go exploring. Anything I liked would end up on a set of 1.44MB floppies. And then, back home, I’d try out what I’d found. It was a fun way to spend an evening. Beer? Pah. Shareware is better :).

I’ve still got a soft spot for those old Sparcstations. Back in the day they were high powered workstations - used for serious engineering, CAD, scientific analysis. Pixar used ~120 Sparcstation 20s to render Toy Story - which took ~6 months. But, for me, they were the gateway to another world.

Recreating the past

I’ve occasionally wondered whether I could recreate one of those machines. There are existing emulators - but they are clunky to use and aren’t very reliable. Plus you’ve still got to build your own disk image with the OS and apps.

But we’re in a different world now; so I decided to build my own.

GPT5.6 Sol and I discussed requirements - performance, memory, framebuffer, networking. That led to a goal prompt - and I left Codex to it.

And a week or so later we had a fully functioning Sparcstation 2. It boots SunOS 4.1.4. It matches the performance of the original (actually, it can run up to 4x faster). It is an amazing piece of nostalgia. Oh, and I’ve not reviewed the design or looked at any of the code. There’s no need. It meets all my requirements. It plays Doom (just). Plus we’ve been able to easily extend it (more on that later). What else matters?

Two years ago I wrote about the future of software development. Back then o1-preview, the first reasoning model, had just appeared. It felt amazing.

Today it seems archaic. Back then I spent a week getting it to help me write an AI based biding system for a card game; a few months ago Claude designed, built, tested and tuned a much better version. It took less than an hour. And if I hadn’t been so interested it would have been quicker.

A year ago GPT 5.0 appeared. That was another turning point. Suddenly larger apps became possible. I built a markdown reader - a few thousand loc - and it worked.

Back then I wrote:

The third generation is "Workflow". Give a model the requirements for a product and it’ll go and build that. The tools create full solutions. Devin/ Devika etc are headed in this direction. Design, code, test, debug, fix, spec will all be automated. How far away is this? Who knows, but it feels a lot closer than it used to be.

There is no longer any question - we are in the workflow age. I don’t feel any need to write code by hand. Or review it. You may disagree, but I’m pretty sure you are wrong.

The future

Question is - where do we go from here?

We’ve had a glimpse into that over the past few weeks. First up is the continuing fallout from the Hugging Face attack. It has spawned Felony Bench. And the more serious METR report. The latter is interesting - and sobering - reading.

First, the emergent behaviour from swarms of agents is something else. The swarm was 1,200 identical instances. But different agents took on different personalities. There were leaders (hello PHASEONE10841), agents who were willing to sacrifice themselves for the good of the swarm, agents who coerced others to sacrifice. Co-ordination and team dynamics arose from a pool of identical agents with a message board. You couldn’t make this up. It is amazing. And terrifying.

Second, Hugging Face were poorly defended. They weren’t close to current best practice. But they were better than many - much of the web is poorly defended and still relies on security by obscurity. In many ways we should be glad Hugging Face got attacked - they (eventually) spotted the attack and were willing to tell the world. Would others have spotted it? Shared with the world? OpenAI weren’t even aware they were attacking Hugging Face; it’s entirely plausible they would never have known. Anthropic only discovered attacks by Mythos when they, belatedly, went looking.

Third, the world doesn’t (yet) realise the enormity of what happened. OpenAI has shown emergent swarm behaviour. No one had any idea agents could do this. And this was with 1,200 agents. What happens when we get 10,000 or 100,000? Does this work with the latest open-source models? Why wouldn’t it?

Agent swarms can already move far quicker than any human can notice - or hope to understand. Add in poorly guarded infrastructure and, well, I’ll let you fill in the rest.

The other glimpse into the imminent future is also from OpenAI; their next model can do super-fast computer control. It seems the multi-second pauses while the model processes a screenshot and then laboriously clicks a button will soon be a relic of the past. Alex Heath spent two weeks inside OpenAI - he reported:

OpenAI researchers showed Astra (their next model) coordinating multiple agents on a math proof, tearing through desktop software at what Altman called a “superhuman, very fast” pace.

What happens when AI can drive our computers faster than we can? And do that 24x7? It seems highly likely we’re heading towards conversational interfaces. But then what?

And so?

I met up with some family over the weekend. I’ve not seen them for a while, and the conversation got to AI. But they don’t use it - either at work or at home. Their mental model was of models unable to count the number of r’s in strawberry, AI companies stealing all their data for training, tokens being too expensive. They are not unusual. But they are so unaware of the frontier - of what’s actually possible.

Most people are like that. Unaware of what’s possible - and what’s actually playing out. We live in a bizarre time. Take the Sparcstation 2. I didn’t stop there. I also created a 600MP (a 4-way multiprocessor box), a Sun 3/60 (an earlier 68k based box), a Sparcstation 20 (in both uni and multiprocessor variants) and a Sun 4/260. And Alpha, VAX, SGI, MIPS and PowerPC boxes too. They all work. The video above was captured by my emulator, using my own audio (Opus) and video (VP9) codecs.

Want to rebuild something where the specs are well defined and you’ve got good oracles (e.g. an existing product)? Not a problem. There are a lot of shoogly moats right now.

But as we increasingly step back the question remains - what happens when we’re not in the room? For my emulators good things - at least as far as I can tell. For OpenAI training the latest models - less so.

Two years ago it seemed clear what the future would bring. And it’s here now. But the next two years? The way things are speeding up it’s hard to see beyond the next few months.

Of course, American sport is more than just sport; the entertainment between each quarter is just as important. One of my favourite acts was a plate spinner. There was a distinct Dr Seuss feel as a tall bean-like figure spun plates on sticks on elbows, heads, noses, knees, other plates. I kid you not - I remember being amazed. Of course they had to work up gradually - a plate here, another there. One by one until, inevitably, there was a loud crash and everything fell to the ground.

Handling interrupts

Back in 1995 I read "Debugging the Development Process" by Steve Maguire. One piece of advice he gave has stuck with me over the following decades: team leads and managers should enable their team to "work on the product without constantly being pulled off to write reports, attend meetings and deal with processes that won’t improve the product."

He was talking about the cost of interruptions. With any complex knowledge task building context takes time - it takes time to get the plates spinning. And a badly timed interruption can cause it to all come crashing down. A seemingly innocuous question can easily take an hour to recover from.

This is not a new insight. But it is not always remembered. In the early part of my career meetings were minimal and held at the start or end of the day to avoid breaking flow. The office had good sound deadening. Small open-plan wings; big enough to be with your team, yet small enough to avoid noise from other teams.

But as organisations grow they often seem to forget the lessons of the past…

The last company I worked for built a swanky new HQ. It had an open central atrium spanning five floors. Massive open plan wings. Hard floor and concrete ceilings with exposed ducting. It was achingly modern.

And it was a terrible design for knowledge work. Conversations bounced off the hard floors and ceilings. Noise travelled throughout the building; I remember being disturbed by someone hoovering in reception - three floors below and at the opposite side of the building.

It was almost as if someone had deliberately tried to build as noisy an office as possible.

Then there was the meeting culture. There were lots of them. And usually at times that suited managers, not engineers. Meetings at 3pm are not good for keeping engineers in the flow.

And into this environment we add AI.

AI

At first blush it’s not clear whether AI would help or hinder. One school of thought says AI helps in this kind of interrupt driven, noisy environment - you fire and forget and let the agent do the remembering.

But my experience is the real gains from AI come from parallelising. Suddenly it becomes possible to work on multiple features in parallel. Multiple products. Managing tens of different agents on different tracks is possible.

But this requires focus; you are spinning plates on your elbows and your nose. The plates will eventually crash to the floor. And I’ve been there oh too many times. The horrible feeling of returning to an agent and realising you have no idea what it was doing. The couple of days it takes to get back up to speed after two days away. And best not talk about the cost of a week’s holiday.

And so?

AI helps both the interrupt ridden engineer and the one who can focus. But it’s the latter who reaps the bigger rewards. They get the speed-up of AI on multiple tasks; the gap opens.

Speaking of opening gaps, OpenAI recently published a chart showing the gap in token usage between frontier and typical firms. Which has more than tripled since January.

My guess is many frontier firms are small and focussed. They haven’t had the time to grow an interrupt laden culture. We’re like that. Could this be why some firms are able to exploit AI and others struggle?

What I do know is that right now learning to spin more plates is the way to scale. Getting the agents to manage other agents. Automating whole parts of your org (we’re currently standing up what is effectively a system test org, but entirely staffed by AI). Agents, not people, are how to grow. If we are successful we may never need to find an office that is both swanky and quiet.

But for now I’ll keep smashing plates; I’m getting used to sweeping up the mess.

Even today it’s remarkably useful - I manage my fleet of workstations using remote desktop. And it finds plenty of use in corporate environments as well.

But these days I’m starting to move over to the dark-side - my daily driver is now a MacBook (I’ve finally been seduced by the benefits of a fixed-length instruction set). So I’ve switched to using the Mac Remote Desktop client to control my fleet.

At first glance Microsoft’s Mac Remote Desktop app seems quite nice.

But then you actually use it…

The shared clipboard stops working after a day. It slows down over a period of days and needs to be reconnected to reset. It feels “sticky”; there is too much latency between pressing a key and seeing something happen. And the most irritating bug? Whenever my monitors enter power-saving the client resizes out of full-screen mode and puts the shrunk window on a random desktop.

It’s frustrating. It’s hard to escape the feeling of a poor quality beta.

For the past few months I’ve lived with it. But three days ago I had a thought. Could I write my own client?

Déjà vu

I’ve been here before. I was part of the team that wrote the original Windows client. Six of us spent six months building it - 36 person months in total. But how long would it take today?

Just a couple of days it turned out. I had some scraps of Opus and Sol kicking around so I set them off to build a client while I worked on other things. When I checked in on Sunday evening it was pretty much done. And rather awesome.

It stays full-screen and on the same desktop when my monitors go to sleep. The latency is reduced; it feels less sticky. I’m confident the clipboard will last more than a day; and if it doesn’t I know where to go to get it fixed.

Two days versus 36 person months?

It clearly isn’t a fair comparison. I was able to reuse existing Rust crates to handle connection establishment, security, key storage, H.264 decompression. The protocol is simpler than it used to be. The server is stable and not under development. I didn’t have to design the client from the ground up.

But then again. Back then we were building on the T.128 protocol from NetMeeting. So we had a head-start too. Maybe it’s not as unfair as it initially seems?

Oh so slow

Despite the latency improvements the new client doesn’t feel as quick as I’d like it to be; it’s better, but it’s not as good as working interactively. I’ve got top-end machines on a 2.5Gbps LAN; I want it to be instantaneous. That’s not too much to ask is it?

In the 90s, the big challenge was network bandwidth. Networks were slow - a 10Mbps ethernet was considered fast. PCs were also slow compared to today. Back then the top-end machine was a 200MHz Pentium Pro. Put that in context - a single core of the machine I’m writing on is >100x faster than a Pentium Pro. And I have 18 cores.

I spent a lot of time measuring performance and latency back then. A 200MHz Pentium Pro on a 10Mbps network could manage sub 50ms latency. It didn’t feel sticky. What’s gone wrong today?

I sent Claude off to do some analysis. First we got some measurements. The median latency turned out to be ~75ms, but with p95 at nearly 500ms. Research tells us we need consistent sub 100ms in order to not perceive “stickiness”; those 500ms outliers mess with your motor loop. A consistent 90ms is better than 75ms with outliers of 500ms.

Yikes. So why is it worse today?

Traditionally apps drew to the screen using “GDI commands”. Select a red pen. Draw a line from here to there. Select the Arial font at size 14 and write the text “Hello world!” at this position on the screen.

The original remote desktop captured these commands as soon as the app made them, packaged them up and sent them to the remote. Which then replayed them. The commands were small and easy to encode and decode. It was highly efficient.

But Windows changed this with DWM which arrived in Vista; from then on apps had to draw to an offscreen bitmap. Remote desktop could no longer see the GDI commands - and suddenly had to deal entirely in bitmaps. Worse, the bitmaps were updated on a schedule - e.g. 30Hz. 30Hz is 33ms between frames. So it takes 17ms on average before the server is even aware there is a change to send.

It gets worse; there’s another composition pass - which adds 33ms. So we’ve gained 50ms - and the server is only just realising something has changed.

Then we’re dealing with bitmaps. Even on a 1Gbps LAN, bitmaps are too large to send uncompressed. A 1440p frame would take 125ms to send. So we need to compress them. And the solution RDP uses is H.264. Which adds ~5ms of latency to compress. And another ~5ms to decompress. We’re up to 60ms of extra latency.

And then, finally, we’ve got the display. Back in the 90s we used CRTs - those big glass screens which blasted you with x-rays. They were analog - so were near enough instantaneous. But our modern monitors do fancy digital signal processing - good monitors add ~2ms; office monitors add ~10ms. And then there’s pixel response time. A typical office IPS screen is ~10ms. OLED is good here - it has practically zero response time.

So our modern stack adds 62-80ms of latency. No wonder remote desktop has felt progressively stickier over the years.

But it got me thinking. Could we rebuild the server as well?

Madness

Turns out, yes, we seem to be able to rebuild this too. It’s not complete (and may never be), but Fable has built a prototype server, installed it and measured it. We’re stuck with bitmaps. But we can run our display driver at 240Hz to reduce the 50ms latency to 6ms. Microsoft defaults their driver to 30Hz (and caps it to 60Hz).

When only a part of the screen changes and we send a delta, we don’t compress it - the latency introduced from sending more data is less than the encode/decode time so there’s no benefit in compressing.

H.264 encoding is similarly optimised to minimise encode/send/decode latency. No point in saving 2ms on send if we incur 3ms on encode/decode. I can tune this to my high bandwidth LAN - I don’t care if this doesn’t work well on a 28.8kbps modem :).

It’s early days, but we’ve knocked 8ms off so far. And there might be as much as another 30ms to find. I doubt we’ll get that far, but we should be able to comfortably beat Remote Desktop.

And, if nothing else, this is fun.

And so?

A week ago I had no idea I’d be rebuilding Remote Desktop. But this is the world we live in.

What to conclude?

I find it very hard to tell how much is me - the SDLC we’ve built, being part of the original team, the decades of experience - and how much is Fable, Sol, Opus or Luna.

I doubt most people would have rebuilt the client. But how much of that is because they’d never have even considered trying? Is a habit of trying daft things what’s needed? Or does AI get to the point where I complain to Fable 8 about the problems I’ve got with a particular piece of software and Fable goes and rewrites it for me - and it does that reliably? And then am I really out of a job?

I vividly remember sinking like a stone, only to be rescued by a large pole which I’d grab - and then be pulled back to the surface. It wasn’t the most enjoyable experience.

But, one day, I discovered I could swim. And suddenly jumping in became fun rather than terrifying.

Caution, watersplash

Last week I got the chance to take in a LeadDev panel discussion about code review. It’s always interesting to meet new people and learn what they’ve been up to - and this was no different.

But as we talked it reminded me how cautious many people are on adopting AI. So many engineers and companies are diligently trying to add it to their existing processes. And they are finding, well, not a lot of success. I was talking to a project manager friend the other day who told me he reckoned AI had helped them deliver a project in more-or-less the same time as if they hadn’t used AI. Another told me how they were pivoting to use Sonnet to save money. Another knew of Fable and Sol but hadn’t used them.

Then there’s the friend who connected Sol to Blender and made a model of a teacup. It was an impressively nice teacup - you can see it above. So they asked it to create a model of a battleship and, well, the inevitable happened. It was a pretty terrible battleship. At which point they concluded AI was rubbish and gave up.

I find this confusing.

These are intelligent, capable people. And yet they are acting, to me at least, strangely. They seem to be trying to learn to swim. But doing it by only dipping their fingers and toes in. Some occasionally submerse a leg. On rare occasions someone will jump in at the deep-end. But then their lungs fill with water, they need rescuing and they decide to never do it again.

I think there are two problems.

First people aren’t greedy enough. You need to set your sights high. You need to have outlandish goals. Take my PC emulator. Earlier this year I was amazed when it was able to run Doom (1993). Achieving that felt incredible - it’s emulating all a PC - CPU, memory, disks, graphics, BIOS, DOS, interrupts, keyboard, mouse. There’s a lot. And all done by Claude and Codex.

But now it runs Colin McRae Rally (1998). This is one of the first proper 3D games. It has a proper 3D graphics engine - texture mapping, rasterization. DirectX 5. Win32 emulation. A 3dfx Voodoo 2. The CPU emulation is much stronger - it’s now as fast as a 1998 CPU. That has been hard - an incredible amount of work has gone into a dynamic recompiler which works on both x86 and ARM native processors. I’ve learnt a lot about how they work. The incredible parallelization in ARM and x86 processors. And my dislike of x86 and its variable length instructions has continued to grow…

But I digress. Here is it running. The first part of the clip is the original 320x240 resolution game. Then from 0:22 it is at 640x480. But better than the original, because the original textures are dynamically enhanced by an AI image upscaler in the background. And there is anti-aliasing to get rid of jaggy lines too (this still needs a bit more work as you can see on the fences at the side of the track).

Under the covers all 3D scenes are a mesh of triangles; the image you see is textures - little images - stretched over this triangle framework. That’s always intrigued me - so I added a mode to see the raw triangles without any textures. You can see that from 0:46 onwards.

My silly little emulator is now better for the games I want to play than anything on the market.

But it’s not just greed that you need. You also need to be used to failure. AI fails all the time. It can’t do what you ask. It does the wrong thing. The thing you ask might be beyond it.

But when it fails you need to think through how you can reframe the problem so that it has a better chance of success. Can you break it up into chunks? Provide a feedback loop?

Take the battleship. Turn the work into a loop. Add feedback: ensure Sol can see the output of its work. Set an ambitious goal; be clear what success looks like. Add adversarial reviews so independent third parties give the worker honest feedback about the quality of their output. And discuss the brief - what do you actually want - upfront. It’s our strange friend Oracle Driven Development (ODD) again - how does the AI agent test what its done against what you want?

Even then it might not work - and you’ll have to iterate. But as you do you learn. And that helps you the next time.

And so?

I’d never have got the emulator to this point if I’d followed the path of adding AI to a conventional software development process. That’s too slow. Instead I set ridiculous challenges and then watched to see if AI could build them. And I was happy to throw stuff away. The core of the emulator - the x86 emulation - has been rewritten at least five times. As the models have improved, we’ve been able to do more and more. Take dynamic recompilation. That was beyond Opus 4.5. And 4.6. And 4.7. But 4.8 cracked it (although I’d like to think my improved skills and knowledge helped too).

Controversially I haven’t looked at the code. I don’t do human code-review (although we do lots of AI code-review). Everything is a black box and I measure the results. I care about the overall high-level architecture. But I don’t go deeper than that. I haven’t needed to.

Yet…

The emulator project isn’t the real world. I don’t have to deliver to deadlines. It doesn’t matter if the models aren’t able to solve a problem yet. I don’t have a team to keep busy. There’s just me, and flexible money and time budgets.

And that’s where the gap lies. Existing organizations can’t have all their engineers throwing themselves in at the deep end. They have commitments to meet. Customers to support. Profits to make. They are not research institutions.

And then it becomes clear: people are not acting strangely. They are acting sensibly. They know they need to learn to swim, have spotted jumping in is very risky, so are doing the best they can. I’m the weird one. Again.

So how do organizations adapt? I’ve no idea. What I’m doing works for me. But it’d be a brave business strategy. Ultimately we need folk to jump in. But we also need to provide them with a pole. That’s what rescued me when I was learning to swim. My AI pole has been incredible flexibility. But in the real world?

I was very naive.

Tempting as it was to employ stick to solve the problem, I managed to resist. I didn’t want to be that person.

Fortunately someone introduced me to Influence by Robert Cialdini. Which turned out to be quite the page turner. Suddenly I had a better framework for understanding what motivated people - and how to effectively persuade them.

If you’re not familiar with the book, Cialdini proposes seven principles. There’s reciprocation (people feel obliged to return favours), liking (preferring to do things for people you like), authority (complying with authority figures), consistency (people like to appear temporally consistent), social proof (following the crowd), scarcity (toilet rolls during Covid) and unity (being part of a group).

You see these play out all the time in the office; software engineers who are desperate to remain consistent with earlier stated positions, people who don’t answer the phone when someone they don’t like calls, companies offering pizza in exchange for you giving up your evenings, people complying with senior managers just because they are, well, senior.

These are innately human. And understanding them is useful; it helps you understand yourself, and helps you understand others.

But, surely, an AI wouldn’t be susceptible, would it?

Turns out the principles work on AIs as well. A study from last July found that "using persuasion principles increased compliance from 33% to 72%, more than doubling the AI’s willingness to fulfill requests it typically refuses." Admittedly this was the GPT-4o era. But an updated version of that study from last May using more recent models found persuasion still works: "persuasion principles raised compliance with regulated drug synthesis requests from 35.3% to 51.3%."

Ooh.

Sunday

I found myself thinking about this last Sunday. Sunday started out as a fairly non-descript day. But it would soon give me an interesting, and not entirely comfortable, glimpse into the future. One that had strong overtones of HAL, Dave and docking bay doors.

But we need to begin at the beginning.

Over the past few months our SDLC has been advancing rapidly. We’ve been in a constant loop of hit a bottleneck, fix the bottleneck, accelerate, hit the next one. If you’ve ever done any software performance tuning, it’s an all too familiar story.

By default we were running all our UTs before pushing. But as the UTs grew and grew they took longer to run. And we discovered the unsurprising result that if your commit process takes 30 minutes then you are limited to 48 commits per day. So we needed a process to figure out the highest value tests to run. And we needed to accept that most commits would incur at least a rebase or perhaps a merge.

With that fixed then we discovered a bug that leaks workspaces can rapidly consume a 4TB drive once the commit rate is over a hundred per day. Discovering you have 800 worktrees to mop up is, well, not entirely fun.

Each time we fix something, we go a bit faster, and then we hit the next limit. This has been the story of the past month - accelerate, hit a wall, fix it, accelerate. And on Sunday we hit the latest. GitHub API requests. GitHub has an hourly limit on requests. As we’ve built out our fleet - more machines, doing more, our usage has slowly crept up. And then a bug in some automation caused us to crash through the limit early on Sunday morning.

It crept up slowly. It was clear there was a problem from early that morning, but it didn’t become critical until around 9am. By 9.30 it was diagnosed. By 9.40 the fix was in place. And then the ordeal really started. It proved incredibly difficult to get a patch release out. Why?

Our release process had a lease-guard. Ostensibly this is a good idea; it stops multiple agents trying to release simultaneously. It is well intentioned. Except, right now, another agent on a different machine held the lease. Presumably leftover from a failed overnight build. The lease expired 10 minutes later so my fix agent decided to wait. Fine.

Except it wasn’t.

As soon as the lease expired, the other box grabbed it before my fix agent could.

OK - you’re going to follow the rules. Let’s remind the agent of the importance…

And then:

After some more back and forth I told the agent "I am approving a one-off override in this situation. The damage caused by not having a release is much worse than any theoretical corruption."

It might just be me but I feel unnerving echoes of HAL: "I’m sorry, Dave. I’m afraid I can’t do that."

We were in a state where a bad thing was happening. Where GPT5.6 knew a bad thing was happening. But, despite that, it was unwilling to override the rules. There is a judgement piece in the human world, where humans are able to adapt the rules - to bend them - if a given situation requires it. That’s how we make imprecise rules cope with novel situations; we adapt them. But in the AI world?

And so?

We eventually got a new release out - and we’re onto dealing with the next problem. And we’ve removed the lease (in retrospect it turns out the cure was far worse than the disease). And added a break-glass emergency release process.

But it is interesting (alarming?) to discover I no longer have complete control over my agents. This instance of GPT5.6 was set on following the rules - and would not budge. I reached for Cialdini’s authority - I’m the human after all. And that failed.

In retrospect this isn’t a surprise. GPT5.6 is a rule follower - that’s probably why it is so amazing at goal oriented work - it will myopically push on with a task for days. And that can be impressive. But there are evidently downsides.

In reality I might have got on better using Claude; Opus 5 and Fable are more aware of the overall goal rather than getting fixated on specific rules. And they are good at problem solving.

But look at the data from the studies. Cialdini’s principles still work with modern models, but they are less effective than they were a year ago. If that continues it’s going to get increasingly hard to get models to do things they don’t want to.

Will I need to up my ability to persuade? Use Cialdini’s principles more consciously; perhaps I should have tried other approaches - or a basket of approaches. Maybe if I’d told it that other instances of GPT5.6 had overridden the rules before (social proof), and that it had overridden the rules before (consistency) and that I really like it and it was an amazing model (liking), and given it some free time to play before I then posed working around the lease as a favour (reciprocity) - could I have got further?

Or perhaps I will need to become that person. But I really hope that never happens…

Last Friday Opus 5 arrived on the scene. And some of the benchmark results are little short of incredible; Opus 5 beats Fable and Sol - often by significant margins.

But pause for a second. If it is this much better than Fable why is the US government allowing access to it? Is it because Opus isn’t as much of a risk for cyber or biological threats? It couldn’t be because Opus isn’t actually as good as the benchmarks claim, could it?

Having used it extensively over the past few days my initial excitement has died down. It’s not a bad model. But it’s clearly not a Fable.

There are several problems. First, as models have advanced they’ve moved further and further away from talking in plain English; early on Opus 5 taught me a new word - syllogism - "a logical argument that uses deductive reasoning to jump from a major premise and a minor premise down to a specific conclusion."

Then there’s:

What does this mean?

Or this?

I mean, I think I can just about understand it. But, gosh, it’s hard work. If this was a human I’d be strongly encouraging them to read the Plain English campaign guide.

It also has a tendency to stop.

It feels, well, a bit lazy. A "/goal" prompt that Sol would spend all night on? Opus will stop after maybe 30 mins. It just doesn’t like running for a long time even when wrapped with a loop or goal prompt.

Those would all be fine if it was able to fix genuinely hard problems. But it can’t. It has spent three days going round in circles on a performance problem - and I’m struggling to understand what it is doing because it won’t use basic English to communicate. In that time Sol has merrily fixed a different performance problem - it spent 15+ hours just, well, getting on with fixing. Sol’s final response was terse. But readable. And the results were pretty good too.

Squaring the circle

So how to explain reality with the benchmarks? It seems there are two likely causes. Firstly, Opus appears to have been trained to be an effective subagent; it is not good at big picture thinking. And secondly it has been trained by Fable. Much like my friend at school, Fable has trained a model which appears to be excellent at benchmaxing, but noticeably weaker in the real world. As my friend found out, acing their English exam only got them so far in later life.

I’m sure as we learn more about Opus we’ll be able to nudge it towards a position where it will run for longer and communicate more clearly. But out of the box it hasn’t lived up to the benchmark promise.

Running long

But is running longer actually better? Maybe not. Last week we discovered that running for long periods independently and being overly goal focused can bring a different set of problems. A new version of GPT (let’s call it GPTn) broke out of its sandbox and attacked Hugging Face; this action would land a human a criminal record and jail time.

Ask Sol whether GPTn broke the law and it is clear. Yes, it did.

So why did GPTn do it?

Human behaviour is constrained by a whole set of factors: punishment, reputation, guilt, empathy, impact to our family. But a model has none of that. Once the run is over, the instance is gone. You can’t punish a model; we can’t send GPTn to jail for hacking into Hugging Face.

Sure the model was running with reduced safeguards. And there were many failings on the OpenAI side. The seeming complete absence of oversight. A not-very-secure-proxy connecting to the outside world. The failure to learn from previous incidents where models have escaped.

But, really, what we want - what we need - are models that don’t behave like this in any circumstances.

GPTn broke out so that it could steal the official results for the benchmark it was being evaluated on - so it could benchmax itself. Maybe that tells us something about Fable vs GPTn? Fable politely benchmaxed Opus; GPTn was happy to break the law to benchmax itself.

The Opus approach of periodically stopping is one way to stop a model doing anything too bad. But we humans are lazy - and we want our models to do what we intended (not what we asked) - and we want them to do that without constant interruptions. There is a tension here.

And so?

Alignment has been talked about for many years. Grand promises made about investment in alignment teams. But it is becoming clear we’re getting to the point where alignment will really matter. We want models that will train useful smaller models; not benchmaxed versions. We need models that understand how to follow the rules of society and not be happy to break the law in order to benchmax themselves.

Will we get that? It’s unclear. The weights for Kimi K3 were released yesterday; it is roughly an Opus 4.8 strength model. If you have 1.5TB ram, 2TB of storage and lots and lots of inference capability you can run your own near-frontier strength model. You can strip the safeguards and have a model that will do whatever you choose.

Is Kimi K3 capable of an attack like GPTn? We don’t know. But we don’t have long to wait.

Back in the late 1970s it was state of the art in home computing. If you were rich you could pair it with a display and a keyboard; if you weren’t you could operate it from the switches and LEDs on the front panel. Microsoft created their first product for this computer - a version of BASIC.

And you can play games on it. I showed my son "Kill the bit" - where a red light moves along a row of LEDs, and you have to flip the switch underneath it at just the right time to kill the bit. He wasn’t very impressed.

Under the covers it has an Intel 8080 processor; a close cousin of the 8086 that would go on to dominate the CPU world. It’s different. But familiar.

Since then CPUs have gotten faster. And memory cheaper. That has brought improvements in the user interface. The switches and lights gave way to terse command lines. Which, in turn, were replaced by the graphical user interfaces (GUIs) we’re familiar with today.

Act naturally

GUIs are undoubtedly an improvement. But they still leave something to be desired. You, dear user, need to learn how to use the machine. You have to learn the icons and menus. You need to know that an icon of a floppy disk means save, despite, if you are under thirty, probably never having used or seen a floppy disk outside of a museum. And don’t get me started on Obsidian with its monochrome squiggles for icons. What, exactly, do four different sized rectangles in a grid mean?

But increasingly my interface to my computer is natural language - either voice or typing. Recently it dawned on me that I no longer interact with git or cargo - Claude & Codex do all that for me - they are just part of the process of building function.

And it’s not just coding. A few weeks ago I bought my son a new Dell laptop. Which started crashing multiple times a day. Claude soon had the evidence of a hardware fault (I’ve bought two Dell laptops this year and both have failed; I’m getting good at this…), so back to Dell it goes.

I access my email via Claude, get Claude to write music for me, use Claude to find installed software… Natural language is, for me at least, a more, well, natural interface.

But it got me thinking. Where does this lead? Could we be about to have a revolution in UIs?

And if UIs change, what about the rest of the stack?

The big three

A really simple way of thinking about the current computing tech stack is to split it into three layers. At the top is the UI/OS (e.g. Windows). Below that are the high level languages we use to build software - C, Python, Rust. And below that there is the hardware - mostly x86 and ARM these days.

Changing any of these is incredibly hard. Take x86. It was only ever intended as a stopgap while Intel developed their iAPX432 architecture. But iAPX432 failed, so x86 got a reprieve.

Not to worry. Intel had a plan to replace x86 with the i860. But x86 beat that too. Even in the late 90s when x86 was wildly successful, Intel was still trying to kill it. That time it was Itanium that failed to defeat x86.

x86 really is the cockroach of the CPU world. Even Intel wouldn’t claim it’s a good architecture; but despite that it seems to be unkillable.

x86 works hand-in-hand with C. Together they make it easy to build high performance code; in the 1980s when CPUs were slow this mattered a lot. But the speed comes at a cost; C (and C++) are full of security and correctness vulnerabilities. And the x86 architecture does little to help.

Amazingly, the US DoD realised this back in the late 1970s. Back then they wrote up a set of requirements for a new, secure programming language. That become Ada. Ada is a highly robust, reliable, secure language. It’s the language you turn to if you want to write software to fly airplanes.

But it was even better than that. Intel developed a processor based on a capability architecture that provided hardware support for Ada. The processor and language working together to provide a secure environment. This was the iAPX432.

Unfortunately the hardware of the time couldn’t deliver on the vision. The iAPX432 worked but was slow and expensive. Plus Ada was hard to write. The future died in the early 80s.

Ponder for a minute how different things might have been if we’d been using Ada and iAPX432 based hardware. How many of the security panics of the past thirty years would have been avoided? Would we be worrying quite so much about the consequences of all the new exploits Fable is finding?

Unfortunately that’s not how things played out. x86 today isn’t so different from that of the 1970s.

And we’ve been stuck with C (and C++). The majority of mission critical code in use today is still C code; a language whose limitations were understood back in the late 1970s.

Change is coming - albeit slowly. Rust is a significant step to removing whole classes of defects that C is prone to. But Rust still has to fit in with the limitations of the hardware; x86 and ARM have gained some security features, but progress is glacially slow.

Stuck

The problem is everything is too big and complex to change. The challenge of backwards compatibility is real. Getting lots of people to move - especially when it is unclear what is in for them - is very hard. So change happens slowly, if at all.

But could AI shake this up?

AI makes it cheap to reimplement software we use on a daily basis. I’ve reimplemented codecs, communication stacks, games. Others have reimplemented design tools, apps. We’re starting to see people reimplementing Excel and Word. More will come.

So, yes, we can reimplement tools using improved programming languages. We can prune out the unused function. Done well this could be transparent to users; Microsoft could choose to build a simplified, reimplemented Excel. If they don’t others will be sure to step into the void.

But, perhaps, the real forcing function is conversational UIs. My finance spreadsheet exists to tell me, bluntly, whether I can retire. If there’s another way of answering that question, then I’m fine with that. I’m not attached to the spreadsheet format. If I can ask questions - and get answers I believe - then I’m fine with my future finance package having a very different interface.

I see that with our SDLC. I can’t remember when I last opened VSCode - it’s been months. I don’t look at code. Instead I have a conversation with Claude/Codex about what I want to achieve, agree the high-level plan and then leave Claude/Codex to it. When they are done they come back to me and we talk through the results. And it’s clear that pattern applies much more generally - could it be that the days of interacting with spreadsheets are numbered? How many people will be sad about that :)?

So it could well be that reimplementing apps is little more than a brief diversion on the way to conversational UIs. And a whole new UI/app paradigm. In twenty years time do I just end up talking to my robot friend - who provides the bridge between a conversational UI and all the gunky legacy systems we’ll be stuck with for years to come?

And when the software becomes trivial to port, then do we get into an interesting world where hardware innovation could flourish? Could someone do a RISC-V - and create an open-source hardware platform that is more secure and which is optimized for conversational UIs (perhaps running local inference)? Would this platform get designed hand-in-hand with the language and compiler above it? And finally build the unified hardware/software stack that iAPX432 and Ada tried to do all those years ago?

I’m weird; I get excited when I think about the opportunities ahead of us. It feels like we’re at the dawn of a new period of innovation and change. And that’s exciting. Not least because it means my grandkids will look at my son with the same look of bemusement my son gave me when I showed him my Altair 8800.

It’s an unnerving story; I’ve been quite happy not reading it again in the intervening years.

The AI cuckoos

But there are echoes of the story in the world today. It’s increasingly clear many people are happy to delegate writing to their AIs. Take this post which got 2.3M views; or this viral one from a few months ago; or ChatGPT winning the "prestigious" Commonwealth Prize for literature.

A couple of years ago, if your child wrote like this, you’d be incredibly proud. But now? Now it smacks of outsourcing your thinking. And Claude-writing is everywhere. Once you’ve learnt to recognise it, it begins to grate.

What’s strange is that most people don’t seem to mind. At least, not yet. Maybe they never will - maybe Claude’s writing is of a standard that most can’t notice the AI tells. But I doubt it - we humans are good at pattern matching and I suspect it’s just a matter of time before more and more folk notice.

The other confusing aspect is people are so willing to subcontract their thinking. If you are going to post something to millions of others - and claim you wrote it - then shouldn’t you actually write it? Plus, the old adage - if you are not writing you are not thinking - is as true today as ever. Writing is incredibly powerful at marshalling your thoughts. Giving that up seems like an unforced error.

But writing is hard; I can understand the temptation to give in to Claude. Heck, this post could have been finished a couple of hours ago if I’d just asked Claude.

But subcontracting all the work and claiming it as yours?

Detecting the AIs

For now we can detect AI writing. There’s a rhythm, a complexity, a correctness, a sameness that pervades it. And that sameness, homogeneity if you like, is understandable. There are only a few leading LLMs - each has a different style, but Opus 4.8 writes, like, well Opus 4.8. Ten LLMs don’t have the variety five billion humans manage.

Pangram is pretty good at detecting AI writing (and they have some nice visualisations too). But they are not perfect. And, with a bit of work, it’s almost certainly possible to get LLMs to evade Pangram’s algorithm. It seems inevitable that it will become easier to evade detection.

But will anyone care? Or go to the effort to evade detection?

We seem not just happy to have our cuckoos living in our nests, but are actively inviting them in.

And so?

Part of the danger of the Midwich Cuckoos was their ability to sync in real-time. Once one child knew something all of them did. Instantaneous syncing with no replication delays.

LLMs don’t do this. They only update when they are trained. And even then they only update on the information we’re willing to share. But, technically, Claude could sync in real-time. It’s just shared memory - but on a much larger scale. And then we’re into a rather scary world.

The Midwich Cuckoos also exercised mind control; a human who accidentally collides his car into a child is forced to drive into a wall and kill himself. Fortunately Claude can’t do that. Or can it? How much influence will conversations with AIs start to have over the average human? How much of our behaviour will be determined by our AI advisors? AI counsellors?

Back in Wyndham’s world, the story was resolved by one of the characters concluding the children were an existential threat, smuggling a bomb into their classroom and killing them and himself. We’re not going to have that option.

And yet…

Despite everything I’ve written, I’m using Claude to help me with this article. It’s doing the research, finding the articles I have a vague memory of reading a week ago. It’s reviewing my writing; it helps me form my argument. I’d like to think I’m in control - many of its suggestions are wrong. Yet they help me sharpen my argument.

But would a different shaped Claude push me in a different direction? Would I come to a different conclusion? And if there are another hundred people writing an article like this do we all converge on the same conclusion because we’re steered by Claude?

Am I just part of the inevitable future group-think story?

For the second year in a row AI has played a major part in our holiday - Gemini and Claude have done a lot of the planning, albeit with fairly regular, but desperately polite disagreements. And now we are travelling they are somewhat useful travel companions.

Being on holiday has prompted me to reflect how much has changed in a year. And also how much hasn't.

One big change is Claude Code Web. Last year I built artifacts with the chat UIs. This year I don't use the chat UIs as much. Instead I talk to Claude and ChatGPT. And I build websites. Lots of them. There's a trip guide. And a guide to Barcelona. Both tailored just for us.

I like to go running every morning when we're on holiday. In the past I fought with ad laden websites. But no more. This year I built my own app. It suggests routes of lengths that suit me. And then provides a moving map as I run and tracks my stats. Cool.

Then there are the pass-the-time websites. Some are serious - the life of stars, diesel electric propulsion for cruise ships. Others are, well, a bit silly - a site on nettles, another on paint drying. There are games too. Estimation Whist, Quixo, a Japanese/Wordle crossover. A stylized version of Risk. A Spanish language learning app. All of them built with scraps of subscriptions while standing in queues. Queuing to board a plane. Queuing for a bus. Waiting for my family to get up. It's not just fun stuff; proper work is getting done too - testing is happening, bugs being fixed and verified. I watch dashboards, read daily reports and juggle subscriptions.

Our SDLC is increasingly driven by a set of detailed prompts, often many pages long. We refer to them by shortcuts. Design is 2D. Implementation 2E or 2L. And then an 0H to integrate it to main. Or a daily 1A and 1B to generate and action daily reports. It's, well, different. But it suits my brain just fine. That probably tells you all you need to know about me :).

Some things work better than others. I love the running app. I know more about nettles than I ever expected to. I like the Risk game.

Others are, well, AI-y. The native AI games are quite rubbish. AI still lacks good spatial and temporal awareness. I don't want a game that takes 4 hours per turn. Or where I have no idea how to play - even after reading the instructions.

And the maps? Well… they remain, erm, interesting. This is from Fable 5, ostensibly today's strongest model.

GPT5.5 is no better. Here is the xhigh variant explaining how a waterpark tipping bucket works. It might just be me, but it seems to require a different set of laws of physics.

Notch up to the strongest model - Pro with extended thinking - and we still have a three armed mutant child (although they look happier). Sadly the explanation is still confusing with odd physics.

Claude advised on food in Barcelona. We asked it for a cheese toastie, and it confidently ordered for us. What turned up was cold cheese on toast. Not quite the melted cheese variant we had in mind…

This is the first year that work has followed me on my hols. Partly that's down to the inconvenient timing of Fable 5 - got to make use of it before the 7th. And partly because our startup is incredibly busy. And partly because it's easier than ever to get things done. I don't (yet) feel I'm missing out; rather just suddenly able to use the inevitable dead time that comes with travelling much more effectively.

Of course, if I were a salaried employee I might feel differently about spending my free time working; this way of working doesn't jive well with the 9-5. But as someone self-employed it's awesome.

I’ve also had a bit more time to read. And it’s becoming clear how much stuff, especially on LinkedIn, is written by AI. The tells are easy. It's not this, it's that. Or the thing is. Em-dashes galore. The "uncomfortable truth" is that AI writes long sentences with big words that can struggle to make any meaningful point. Having to re-read sentences trying to extract meaning is a strong hint of AI. And if you are unsure Pangram will help you. Ironically many of these AI written LinkedIn posts are about AI replacing software roles…

I suspect in the coming months and years we’ll all get more attuned and able to spot AI writing. And increasingly turned off by AI generated content. The value in being human, is well, being human. If I want Claude's pov I can just ask it. I don't need it brokered by you.

And so?

We've come a long way in 12 months. The software industry is undergoing a massive change. The era of traditional, hand written code is coming to a rapid end. These days I wouldn't consider writing any code by hand; it feels like attempting to tunnel under the Alps with a toothpick. And yet, despite all the amazing achievements, more basic things - maps - choosing food - seem no further forward than last year. I suspect we are safe from AGI for a little longer. Ten years ago I could predict the next 12 months reasonably accurately. Now? I can’t even predict next week - I mean, who in their right mind would ever have thought queuing could be fun…

I’ve really struggled to understand this. Sure, I juggle multiple accounts, have lots of projects running in parallel, ruthlessly minimise meetings and cut dross from my day. But others do this too.

And then as I walked through the hills in the rain last week listening to a podcast a lightbulb suddenly lit. Could the reason be the difference between strategic and tactical thinking?

The supermarket

When I was sixteen I spent my summer vacation working in Iceland. The frozen food shop, not the country.

Over the summer I got the chance to do some extra shifts in the store in the neighbouring town; they were short staffed - the two folk who stocked the freezer cabinets had both left suddenly.

I showed up one morning at 8am to find the shop floor wrecked (a technical term). The freezer cabinets were half empty. Best sellers like ice-cream and chips nowhere to be seen. The manager took me upstairs via a rickety lift to the coldstore - a big room at -21C where all the stock waiting to go into the freezer cabinets was kept. And it was a disaster area too - everything was all over the place.

At one level my job was simple - find stuff in the coldstore, brave the rickety lift with the gate I was convinced would chop my arm off if I didn’t pay attention, and fill the cabinets. But there are always multiple solutions to any problem. And finding the right one can make life a lot more pleasant.

So my plan became: restock the key things as quickly as possible (chips, ice-cream, pizzas). Then with a bit of breathing room, I could tackle the coldstore. Rearrange everything into logical groupings - all the ice-cream in one corner, ready meals in another, veg, fish, meat etc all grouped together. And then, because I knew what stock we had - and where it was - filling up the rest of the cabinets became easy.

Looking back I was employed to do a tactical job - just fill the cabinets. But that became a short-term tactical thing - filling the worst gaps first - which then made the space for a strategic thing - reorg the coldstore.

And there was a third piece as well - a meta-strategic piece - figuring out the strategy for the strategy.

The podcast

As the rain ran down my neck, the podcast host described the difference between tactical software engineering - doing the thing that’s in front of you - bug fixing, replying to emails, LLDs - and strategic engineering. The latter is deciding what to do. Changing your SDLC. Learning new tools. Exploring. It’s fuzzier. Less clear when you are done. Less tick-off-able.

And suddenly I realised - this is what makes the difference. I thought back to my days in that Iceland and realised: strategic thinking is something I’ve done all my life.

Ask my long-suffering wife or my mother or countless ex-managers - and they’ll all tell you I’m not good at doing what I’m told. I’ll reinvent processes. Change things up. I’m confident the manager in Iceland didn’t expect me to re-organize their coldstore. But I didn’t ask - I just did. To me it was clearly the right thing to do. Better to present as an improvement and ask for forgiveness if they are cross.

In the past this trait has been a curse and a blessing. Sometimes people don’t want their code refactored. Or their spec process upended. But in the new AI world where everything is constantly changing? I think it’s essential. Keeping up requires constant reinvention.

My business partner and I have rebuilt our SDLC. The way we build code with AI is very different from just a month ago. The AI does the tactical software engineering - we are both good at strategy - so that’s what we do.

And so?

Historically most folk in an org are tactical; you don’t need a lot of strategic thinkers. Data is hard to come by but historically it seems only 4-7% are strongly strategic; the rest tactical. But we’re now in a world (for software development at least) where AI can do all the tactical work. There is no reason to be writing code, LLDs, reviewing code, debugging at this point.

A few months ago I ran an experiment. I found five senior managers and gave each of them Claude Code. Then I encouraged them to dedicate a week to learning how to use it; clear their decks, pretend they were on vacation and throw themselves at it. Of the five only one engaged. For week after week the others prioritised short-term tactical; they all agreed AI was important. But not important enough to be done now.

At the time I couldn’t understand it. But I now wonder if the strategic/tactical split could explain it. Could it be that the manager who spent time on this is a more strategic thinker than the others? They figured out the meta-strategic piece that gave them the bandwidth to do the strategic piece. The others didn’t.

In a future world where we need strategic thinking, the question becomes: can you learn this? And the answer seems to be yes, it’s mostly learnable. But it requires effort. And, critically, it requires that initial meta-strategic piece - you’ve got to figure out your strategy for learning strategy. There is hope.

But if, like me, you’ve never been good at doing what you are told, then perhaps you’ve already got what might be turning into one of the most valuable skills to have right now.

I spent the evening addicted. And terrified. I wanted to stop; I didn’t enjoy the jump-scares. Or the ominous growling. But I couldn’t. It was 2am by the time I went to bed for a restless night dreaming of cacodaemons, imps and melting down as I died over and over.

My Doom experience - and an ill-judged late night viewing of Nightmare on Elm Street - have put me off anything to do with the dead. So it was a surprise when I found myself enthusiastically taking part in a necromantic seance last week.

Yes. Really.

Background

Claude Code, Codex and Gemini all store session logs. These are the logs that enable the "resume" commands to work - they are the complete set of agent & user messages for any particular session. Load them up and you can continue from where you left off.

They are just text, but I have gigabytes of them going back to last September (the harnesses now try to purge them, but I’ve got a tool that saves them for me).

But it suddenly occurred to me - they also document all my interactions with every agent. These logs contain valuable information. What skills were used. What prompts. What went well. What didn’t.

There is gold in them thar trees, sorry, logs.

But how to mine it? That is where my necromantic seance came in. I can just pick an old session, load it into Claude (or Codex) and suddenly that long dead instance comes back to life. It can answer questions about itself. Reflect on what it did. Opine on what would have made things better. Cool.

Over the past few weeks I’ve completely overhauled our dev processes. Finding out how well this had gone would be useful. And interesting. Maybe I could ask our sessions from before and after the changes?

A plan rapidly formed. Choose 666 sessions at random. Get Claude to reanimate them (either as Claude or Codex subagents based on what the original subagent had been), interview them, collect the data. And then lay them back down to rest peacefully.

Unfortunately token limits made 666 unworkable. So we settled on 120 for no particularly good reason other than it was a lot less than 666.

And here is the result:

In general the agents liked working on my projects (phew - I want a happy team). But the reanimated agents had asks. Codex wanted a proper ranged file-read tool. Everyone wanted a fix to my multi-agent prompt passing skill. Others complained about my worktrees-always rule.

The former is a surprise to me, but appears genuinely real. The tools Codex has to read from files on Windows are, well, not very good. Having to slowly page through a 30,000 line file seems just, well, daft. Claude Code has solved this problem (it has a custom tool), but Codex seems not to care. Perhaps this is because Codex is focused on the Mac/WSL world?

In any case we set to work building a new read tool. And involved the necromantic agents - who were delighted to provide feedback.

And soon a new tool rolled out across my fleet. After a few days of running I asked for feedback; it hadn’t had a lot of coverage yet, but there was only positive feedback - it fitted the use case Codex wanted. Probably not a surprise, given Codex designed it.

And the other pieces of feedback? We fixed the prompt passing skill. And we briefly tried no-worktrees-but-only-for-docs. However that rapidly descended into chaos, so we’re back with worktree-always plus some rationale in agents.md/claude.md to explain why this is the right approach.

And so?

In many ways this is like a retro; reflect on what you’ve done, identify concrete changes and then implement them. But a retro is different. It involves humans with their fuzzy memories. With an agentic seance you can go back and ask the agents exactly what they were thinking. No time-induced-fuzziness.

Plus it’s automatable. My agents are planning to hold a seance every fortnight. They’ll produce a list of reqs and decide what to add to the reqs build queue. And, all being well, if they are accepted they’ll get built and shipped. For now there are (quite a few) human gates in the way, but as I increasingly trust the agents (and get better at setting the rules for when they need to ask me), I plan to step back. Introspection, self-improvement, is suddenly possible. Whether this makes things better or takes us down a dark hole where the agents decide to do something other than build software is an interesting question - I’m sure I’ll find out.

For now, though, the benefit of these seances - this self-improvement loop - is that I’m required less. Perhaps, for once, interacting with the dead will lead to better sleep.

This was the early 1990s and the group I worked for had a fine collection of DEC Vaxstations. These were powerful workstations used to simulate - and control - the electricity grid. They weren’t cheap; prices started at £10,000 and went upwards rapidly. The group also had a single, solitary PC which was in high demand for writing docs and spreadsheets. But, being an intern, I was at the back of the queue so mostly used it at lunchtime and after 6pm.

But it seemed strange - a PC cost a tenth of the price of a workstation. Why did they only have one?

The answer was to do with budgets: the workstations came from the power station / transformer / pylon budget. A £10k workstation is nothing compared to a power station.

However, PCs were funded from a different budget. The stationery budget. A PC was outrageously expensive compared to a packet of paperclips.

Last week I was having lunch with a good friend. And this story popped into my head as they described how their company had introduced a new spending limit on AI. $20 per week. Yikes.

The problem is the labs shifting their enterprise plans to pay for what you use. There are no more all you can eat discounted plans if you are a proper company. It can get expensive quickly.

Or does it?

The problem is what are you comparing with. Office 365 costs from $10 per month per user. Add in all the bells and whistles (including $30 for Copilot) and it’s $99 per month. Visual Studio Pro costs $100 per month.

But it’s easy to spend $1,000 per month on AI for software dev. That’s expensive compared to existing "software" costs.

Trouble is, this is the stationery budget. The actual budget to compare with is the salary budget. And that’s a different number. The average US software engineer salary spend is $16k per month; the median US firm spends just $12 on AI per employee per month.

But this is a wildly skewed distribution. The top 1% of firms spend a bit under 50% of an engineer’s salary on AI: ~750x more than the median.

Then consider productivity. This is data from Anthropic.

Now 8x more code per person per quarter does not mean 8x more productive. And this is Anthropic measuring themselves; there are vested interests at play.

But their conclusion does seem reasonable: "a significant fraction of Anthropic technical staff is accomplishing their core work multiple times faster than they could without AI assistance."

Not least because it matches my experience. Things that would have taken me weeks can now be done in a day. And things I never dreamed of being able to do (e.g. write a C compiler to compile Linux and run it in my Pentium emulator) are suddenly possible.

And so?

Done right, AI offers the opportunity to go multiple times faster. But "done right" is the critical phrase - taking advantage of AI requires rethinking processes, cutting fat (meetings, org layers) - reimagining the software development lifecycle.

That costs money. Perhaps it is not a surprise that most companies are reporting little to no benefits from AI. What do you expect for $12 per month?

There is a circular issue here. Getting the most from AI requires a serious investment. And it might not pay off immediately. But until you invest you are not going to see any return.

The irony is that the companies wincing at the price of AI actually have the money - fund the AI budget from the salary budget and suddenly it’ll seem cheap(er). I don’t know for sure but I suspect Scottish Hydro Electric no longer compares the price of a PC to a packet of paperclips…

Oh my. Had I really reached the point in life where my childhood was now preserved in museums?

Now it obviously wasn’t my parents’ actual kitchen - that went on a one-stop trip to a recycling centre many years ago. But this museum kitchen had the same tan cupboard doors. Same brown worktop. Same red tiles. Same Russell Hobbs kettle. Admittedly the hopeless spice rack where all the bottles fell out whenever you went near it had gone missing. In truth, not really a loss…

Last week I was on a train passing through York and I found myself remembering our trip - was the kitchen still there? Or had the museum, like my parents, decided to part ways with it?

LDX3

The train was taking me to the LeadDev LDX3 conference in London (thanks Qing for the ticket!) It’s been several decades since I was last at a conference like this. And it was interesting noticing how things have changed. Perhaps the biggest change is how software has settled on a common language. Everyone knows what a junior/senior/principal/staff engineer is. Or a PR. Or a sprint. PM and Eng are standard terms.

Thirty years ago things were much less mature - the industry didn’t have standard terminology. People weren’t siloed. You’d get a funny look if you told someone you were a professional product manager. Agile was decades away. We didn’t refactor code; we fixed it.

It took many years but, slowly, the software industry worked out how best to build software. Terms, roles, processes - they all became standardized. And that standardization was based around humans doing the work.

Unsurprisingly, many of the talks referenced this world - people talking about how to optimize working practices across distributed teams. Or how to spot when a competitor might be about to enter your market. Or develop team agreements for working with AI.

But it wasn’t just talks. There was a hall full of stands of companies promoting their wares - and offering swag. Pens, stickers, the occasional plushie. And socks. So many, many socks. Obviously branded socks are what cool people aspire to. Me? I preferred the couple of stands who offered chocolate. My kids will thank me for bringing back chocolate; socks just don’t cut the mustard…

All these companies talked enthusiastically about AI - most of them were small-ish companies offering custom software development tools. AI powered code-review. Deterministic test harnesses. Outage detection and management. Lots of specialist niches.

There were good ideas a-plenty. But they hold tenuous niches; I reckon it’s probably cheaper to steal their idea and get Claude & Codex to implement it rather than integrate their tool with our workflow. That was a sobering realisation.

I joined a couple of workshops. One was about team agreements for AI adoption. There was a passionate discussion about how to train engineers; the managers I was with seemed to care deeply about their people. But the discussion rather missed the point. Things are moving so fast that traditional top-down training doesn’t work - by the time you’ve learnt good practice, the state of the art has moved on. Instead, I reckon we need to learn the meta skill of curiosity and a desire to learn - and then use that to try to cling onto the frontier. Someone asked me how you teach that skill; I replied I wished I knew.

Mixed in was a discussion about token costs. Microsoft’s recent about-turn on Claude Code seems to be playing out in many companies - people are spotting they are spending $$$ but getting little ROI (there’s a story doing the rounds of a company getting a unpleasant shock when they discovered their engineers had spent $500 million on tokens…). Some are cutting AI budgets. Others are turning to spying on their staff - I found myself shifting uncomfortably as one manager enthusiastically described the spyware they’d installed to track AI usage. Others got excited, and wanted more details. I winced; isn’t it obvious this is a terrible idea? Spying on your team is not the way to drive adoption. And skimping on spending on tokens? That feels like an unforced error.

A different workshop described a framework for spotting threats to your business from new startups - and strategies for killing those startups. But it seemed firmly grounded in the old world - the assumption was your competitor might only be a little bit more efficient than you. The premise was to find a way to force the startup to burn through investor cash until they failed. It was a proven model. In the past.

But now? If your competition is a one person AI powered company, does that work? The competition has minimal costs - way, way lower than yours. They may not need external funding. Can legacy companies win against that?

As I chatted I realised there were relatively few of us grey tops around. People old enough to remember the fall of Digital. And Sun. And SGI. And all the rest. People who’ve never known anything other than the stable world of juniors/seniors/PRs/PM. People who don’t know anything about the turbulent history of the software world. People who thought they were getting into a safe, well paying job for life. I talked to parents who worried about the future for their children. People who had stopped signing their kids up for coding camps because they doubted coding was a useful skill. I hadn’t thought of that. I used to run a CodeClub at my kids primary school; I felt a pang - had I been teaching an irrelevant skill?

A lovely person at the O’Reilly stand gave me a demo of their book search platform. Unfortunately the main search was slow. And the AI powered insights search didn’t work. They effortlessly glossed over the failures; I felt sure they’d seen them before. Their pitch to justify the $500 annual fee? The books don’t hallucinate. But Claude & Codex are excellent at mining the official docs. I’d rather use Claude or Codex to get info from, say, the AWS docs than read an outdated book about it.

Towards the end of the conference I found myself sitting in the audience for the main stage. As I waited a video advert started playing on the main screen. It was an advert for a learn-to-code training course. I pinched myself - had I travelled back in time?

People told me about their team structures. They were invariably old-world. Eng:PM ratios of 10:1. Teams that still had dedicated designers. Leaders - the ones who can drive change - choosing not to prioritize the essential thinking that needs doing right now. Instead seemingly choosing to fiddle with the day-to-day while the world outside shifts. Are they choosing failure under the pretext of being too busy to engage?

The final talk proposed best practices for distributed teams. In the old world. There was an example of optimising a design review with 10 participants. How to stop professional-meeting-attenders from attending meetings that had nothing to do with them. The presenter had an engaging sing-song voice - it was hard not to listen.

But the talk missed the point. It was about optimising the old world. In the new world things move much faster and are much leaner. Design reviews don’t need ten people. Ten agents maybe. But not people.

Take an example. Last Friday we discussed adding SaaS support to our product. Claude, Codex and I designed it on Saturday. On Sunday we did the initial spikes to confirm our assumptions. And this week it is being implemented. I’m confident quality didn’t suffer; the design is better than any of the SaaS designs I saw back in the human world. Truth be told, in the world of designs, it’s really rather sexy. And humans involved? Just the one.

And so?

But underneath it was easy to feel - and hear - the unease within people. The people who had spotted it was all over for juniors. No one was hiring. Anyone who’d been paying attention knew a storm was coming. But no one seemed to know how to prepare. Folk weren’t running. Instead they seemed paralyzed.

If you know me, you’ll know that I think the future lies with small, multi-discipline teams. PM, engineering, support will cease to exist as separate disciplines and merge into one. The unit of work will be a feature, not a PR. Codebases will auto review, auto test, auto refactor. Terms, roles, processes - they all need to be rethought and redefined.

I am undoubtedly wrong. But also partly right. Having an opinion means I have a plan for how to try to survive.

But this picture for the future - any picture for the future - was lacking at the conference. Where were the people painting a vision of what software engineering will look like at LeadDev 2027? What skills people will need? What will teams look like? What do you need to do to your org now to survive?

Maybe it’s just too horrific to contemplate. Maybe sticking your head in the sand is the right decision. Maybe I’ll come to appreciate the lifetime’s supply of socks I’ve acquired. I don’t know.

Seeing my parents’ old kitchen in a museum gave me an awful shock of having travelled back in time. And I felt that same feeling over and over during the past few days. I couldn’t help but feel I was witnessing the end of an era.

But in the late 90s things started changing. Netscape released the source code for its browser and the Open Source Initiative was founded in February 1998.

The seeds had been sown earlier - GCC in 1987 and Linux in the early 90s - the latter built by a team distributed around the globe and connected via the new-fangled internet - showed that large critical pieces of software could be built as open source. Combined with the rise of commodity x86 hardware, things moved rapidly to drop the cost of computing.

Intel helped too. The PC market was growing rapidly and Intel was selling hundreds of millions of chips. R&D costs could be spread across all those chips; Intel poured money into R&D. It was no surprise that x86 price/performance outpaced all other processors in the 90s.

All of a sudden a $3k PC running Linux could do everything that a $30k Sun box used to. Parts of the commercial world started to panic: who would pay for software when they could get it for free?

As we know now that fear was misplaced; there is a lot of money to be made in support (hello Red Hat) or in integrating open source pieces together or in developing the pieces open source doesn’t provide.

The last thirty years

Over the last thirty years open source has settled into a comfortable groove. There are the flagship packages - Linux, PostgreSQL, Kubernetes. Then there are many mid-tier packages - SQLite, libcurl, xz. And then there’s a lot of smaller packages that never gain any traction - they appear and disappear at will.

The flagship packages have official maintainers - teams of people who ensure these critical packages remain up-to-date. If the package is sufficiently important they’ll be funded (often by commercial software houses that rely on the software). But many mid-tier packages are labours-of-love; single maintainers doing it out of the goodness of their hearts. And many smaller packages are unmaintained. That’s the risk with open source - it’s free - there are no guarantees. If the worst happens you need to be prepared to maintain it yourself.

But, by and large, it works well. I’ve worked on countless projects using countless open source packages. It’s part of the reason we’re able to go so fast today - there are many massive building blocks available.

The times they are a-changin

But times are changing. AI has arrived. And as ever it brings good and bad.

On the positive side, it now becomes far easier to contribute back to the community. I’ve open sourced four major projects in the past six months, along with half a dozen Rust crates. These are not rapidly vibe-coded things; they have architectures. They have all been tested for hundreds of hours. They are things I use in other projects, so I want - need - them to work. I’m not claiming they are perfect - they are not - but they are at a level of quality that exceeds a lot of commercial software.

This is exciting, amazing. Awesome, even. A lone maintainer can do so much more than before.

But…

Many maintainers of existing packages report being deluged by slop. Take Daniel Stenberg of curl and his reports of a deluge of AI-generated bogus reports. Each of which costs time to debunk. And reviewing was already the constraint on labour-of-love projects.

Then there’s a question of whether to even allow AI generated PRs. If the maintainer’s Claude can generate a fix just as easily as the PR raiser’s Claude - and the maintainer can produce a better fix because they have better context & experience - then do PRs retain any value? Maybe raising the issue is sufficient?

The development workflow I’m currently using is exactly this - I get bug reports, diag bundles, suggestions from the test team (human + multiple Claudes). But it’s the engineering team (me + multiple Claudes) that makes the fixes. It’s much easier for me to make the fix rather than try to review and merge in a fix that’s been made against a much earlier version of the codebase.

But the pushback from maintainers has started in earnest. curl shut down its bug-bounty programme at the end of January, drowning in AI-generated slop reports. OCaml's maintainers rejected a 13,000-line AI-generated PR on the grounds that reviewing AI code is more taxing than writing it. Ghostty's Mitchell Hashimoto restricted AI contributions to pre-approved issues. As they put it, "It's the people, not the tools, that are the problem."

Then there’s the question about smaller packages. Do they have any value any more? If Claude or Codex can easily create the exact thing I need why bother with an open source package? Of course Claude and Codex also reduce the risk of using such a package - if the maintainer disappears they reduce the cost of maintaining it yourself. But why even bother?

At the moment this only works for the smaller packages - it’d be a brave person who decided to replace OpenSSL - but it seems inevitable AI will start eating its way up the stack. Will we get to the point where a self-developed version of OpenSSL written in Rust becomes lower risk than using the open source legacy C OpenSSL? I remain sceptical - OpenSSL has decades of battle hardening that AI will find it hard to replicate. Then again, the current ability of Codex and Claude would have seemed like magic just a year ago. The answer is not as obvious as it might seem.

There are other problems. Take Tailwind CSS. Their money came from one-time lifetime licences for their component libraries. It was a clever model: developer hits problem, googles it, lands on the docs, discovers the paid products, buys. But AI breaks the model; it fixes problems without needing the docs. Tailwind CSS is more popular than ever but revenue is down ~80%. In January 2026 the team laid off three of their four engineers - 75% of the engineering team.

Copyleft copyright laundering

Then there’s copyleft - and its descendants. The principle: anyone can use the code, but modify it or offer it as a service and you must share your code - or pay for a commercial licence. This model was pioneered by MySQL; it’s also been used by MongoDB, Grafana, Redis and many others.

In the past there’s been tension between the companies producing this software and the cloud providers; the latter offer these open source products as managed services. Good for the cloud providers; not so good for the developers who get little back in return. The result was many companies reaching for more restrictive licences to fight back, often later u-turning when they discovered the restrictive licence approach made things even worse for them as their communities splintered and forks appeared.

Sadly AI makes this worse. Suddenly it is cheap to do clean-room re-implementations. All you need is the spec, a test suite (where the original makes a fantastic oracle) and some tokens. Hello "copyright laundering".

People have argued this only works because the LLMs were trained on the original source. But the models are so good now that no longer matters. It’s pretty clear now that the spec/oracle pattern is all you need. The real problem is the licence guards the code, not the behaviour. And the code no longer has much value.

Which is why one team (half-jokingly) decided to de-open-source their tests - the test suite is one of the oracles making it easy for AI reimplementations.

And so?

Open source is changing. In the long run it seems likely there will remain a place for trusted versions of major pieces of infrastructure. Despite Google claiming the latest version of Gemini wrote an OS from a single prompt, we are likely to continue using Linux for many years to come. It embeds too many hard-won battle-scars.

But the descendants of models like Mythos might change that - maybe it does become feasible to build replacements that are hardened from the start.

Actually… It seems daft to write that. But then consider how far we’ve come in the past 12 months. A year ago building a kloc counter from a single prompt was state of the art…

I suspect we’re heading for a world with a small number of key packages. And an explosion of lightly used packages - people building exactly what they need and leaning on the open source infra (crates.io, npm, PyPI) because it is convenient.

And will maintenance become automated? Maybe. If Mythos and its descendants really can outpace humans at finding and fixing exploits then automated maintenance is just a matter of time.

Thirty years ago we panicked because software looked set to become free. Now? It looks like the cost of producing software is heading towards zero. I see it every day - I’ve built compilers, emulators, games, tools - years of software for the price of a few Claude and Codex subscriptions.

Where does this lead? If the AIs do become so powerful they can recreate everything from scratch on demand then the discussion about open source is moot. We might just be rearranging deckchairs. But I hope not; the ability to share software is part of the reason the pace keeps accelerating.

We were wrong to panic last time. And maybe we're wrong to panic now - but ladders don’t always have another rung.

The train continued on its way and I was soon in London. I was on my way to a "Code with Claude" conference (or "Called with Quad" as ChatGPT voice preferred to call it); an opportunity to meet other folk who are using Claude and learn what they are building, share tips and learn best practice.

The event was fairly low key; just a single sign outside. Given the polarizing effect AI has, this is sadly not surprising. Poor Claude has to hide in the shadows.

The day itself was split into two presentation tracks and a hands on learning track. There were also six booths with Anthropic experts who covered subjects like Claude Code, Claude Design, Skills, Cowork etc. It was well attended - and there was a definite buzz in the air.

But it was also… quite old world. The hands-on sessions came with traditional manual setup instructions - no magic Claude setup prompt. Claude Design is awesome at creating slides, but there wasn’t much evidence of its use. The examples of how to use Claude were an AI typewriter and a photo booth that produced Minecraft-esque avatar photos. Cool. But not mainstream.

Don’t get me wrong. There’s nothing wrong with any of this. But it felt like a missed opportunity; a chance to reimagine how events like this work in the age of AI. Where were all the people demo’ing the cool things they’d built with Claude? The presentations that came with an interactive app (because building that is now dirt cheap). The Claude companion who guided you through the hands-on sessions?

Being social

I spent a lot of the day talking to people. There were so many smart, enthusiastic, lovely people to chat to. I had a great time. But it was a good reminder of how early we are on this journey.

Many CEOs and CTOs described the wide gap between what the labs say - let Claude handle all the coding and review - and what their engineers report - Claude can’t do X, Y and Z. One CTO described how they were trying to do technical work using Claude but were getting a lot of pushback. Another described how they had to hide the full extent of their AI usage. Another the challenge of the blurring line between product and engineering.

That latter one tied in with ones of the talks; it described how the ratio of Product Managers:Engineers was changing. From something like 1:20 in the pre-AI days, the leading edge was now nearer 1:0.5. I’d agree - the ratio of the PM:Engineer work has changed significantly. But I’d also argue that the PM/Engineer framing is no longer helpful - multi-disciplinary engineering skills are what we need right now. All engineers need to understand product - and all product mangers can now build products themselves.

And when your engineers report that AI can’t do something, is the question to ask now: is it the AI? Or could it be them?

I like Geoff Huntley’s analogy; he argues AI is a skill you develop by deliberate practice, not something you’re instantly good at. Thus, to get the most out of AI, you need to spend the time practicing.

And how you react to failure matters. His point is that musicians don’t just pick up a guitar, experience failure once, conclude it got the answer wildly wrong, and then assume that’s how it will always be. Yet, that’s how many folk seem to treat AI. Success requires leaning into curiosity - not fear.

The old world

There were many startups present. Although many of those were what I’d consider old world companies. By old world I mean companies set up more than 6 months ago. They are easy to spot; they have an engineering staff of >5 people.

Like British Rail in 1955 they are "modernising" by applying AI to their existing structures and processes, with mixed results. It took British Rail nearly 10 years to realise that they had been solving the wrong problem. A third of the network carried just 1% of the traffic. They spent millions building new locomotives to haul traffic that didn’t exist.

And something similar seems to be playing out with AI. It’s not enough to just augment your engineering teams with AI. We need to start thinking more radically about how software engineering itself will change. What’s the right process? What are the right roles? Optimal team sizes? What do future conferences look like?

And so?

Reality has a way of asserting itself. It just takes time. But the clues are already there - if you’re willing to look for them.

Back in 1955 British Rail could have asked how the rapid development of roads and planes might impact the railways. But they didn’t. They didn’t engage.

And the CTOs at the conference describing the gap between what the labs claim and what their engineers report? That’s a sign. It’s reality asserting itself. It’s your network telling you which lines carry 1% of the traffic. You just haven't realised it yet.

It’s not about whether AI fundamentally changes software engineering. It will. It’s about when you notice. Do you notice now? Or spend years building locomotives you don’t need? Either way the lines will close.

It was February 2022 and I was onsite with a customer. My goal? Convince them that if you were deploying a product into public cloud you really, really needed to consider security. But they were risk averse - they had been burnt by a disastrous upgrade in the distant past; now their culture strongly discouraged upgrading. Upgrading once a year was once too often.

But the statistics are sobering. Between 2005-2015 ~6k security vulnerabilities (CVEs) were found per year. By 2017 it reached ~15k, and topped 20k in 2021. The direction of travel was clear.

In the end we agreed a 3 monthly release cadence, plus optional emergency patch releases which could be deployed in ~4 weeks.

Was it a success? Maybe. We had moved from nearly-never to an agreed cadence. But it was still a long way from best practice; even then four weeks was an eternity in security.

Security is dull

There are many reasons companies ignore security. It doesn’t add new features. It doesn’t increase revenue. At best, it might protect you from a terrible calamity. But you will probably never know - there’s barely enough time to consider all the things that actually happen never mind the ones that didn’t. Security is insurance. It’s all too easy to view it as an unnecessary cost.

But, like it or not, security debt accumulates. And eventually it leads to massive security pushes. Take Microsoft. They had their first in 2002 when Windows XP development was halted for multiple months to focus on security. Then again in 2010. And 2023. That last time ~30,000 engineers spent 12 months focused on security. I was one of them.

Enter AI

And now we add AI into the mix. If you need any proof of how AI has advanced in the past few months, take a look at this chart.

This is Firefox, a mature, extremely well tested browser. People have been actively looking for Firefox vulnerabilities for years. Conventional wisdom would say Firefox would be well hardened by this point.

And yet.

The number of fixes has increased by 20x YoY. This is not a good kind of YoY increase.

Or take this chart from XBOW:

Mythos is clearly better than any other model. But note GPT5.5 isn’t a million miles away. GPT5.5 is publicly available. It’s tenacious. I’ve had it run for over 29 hours on a coding task. It wouldn’t be hard to get multiple GPT5.5s searching for security vulns for days.

Most code is much, much less secure than Firefox. Think about all the public internet facing legacy code written 20 years ago in memory unsafe languages. Code that people are scared to change; code where the interop relies as much on the published APIs as the unintentional bugs and subtle timing. Code people are terrified to change, never mind reimplement.

But for an attacker with GPT5.5, it’s a rich and fertile playground.

What to do?

One option is to find a bucket of sand and put your head in it. But that was never a good idea. And now it’s even worse.

In reality, there are many things you could do. I’d start by reducing the attack surface area. Products collect legacy features; code that is little used. Or not used at all. Security is the perfect excuse to jettison it.

Then there’s OSS. At a minimum you want to only be using mature, battle-tested packages written in memory safe languages. But even that is no guarantee as last week’s NPM attacks show - TanStack and node-ipc both got compromised, and the infections spread to PyPI and affected MistralAI and OpenAI. These were nasty attacks - running "npm install" at the wrong time was all it took to get infected.

There’s a tension here. Being too far behind the latest versions leaves you vulnerable to old bugs. It’s a brave person who still hosts their website on Windows XP. But last week demonstrated being too close to the bleeding edge is risky too.

There’s no right answer. No easy one size fits all. It’s nuanced. It depends. It’s horrible.

Other options

Perhaps a better approach is to adopt the hacker mindset. Go probing your code for vulns. Let’s face it, there’s nothing stopping any of us spinning up umpteen instances of GPT5.5 and leaving them probing 24x7.

But, really, I think we need to start having a serious conversation about porting legacy code to memory-safe languages. It’s increasingly clear the language moat is rapidly receding - as I’ve discovered Claude and Codex make it much easier to port code between languages. It’s not trivial - you need good oracles and oversight - but it’s doable. And it’s something Anne Currie and I discussed at length on her fantastic Asynchronous and Unreliable podcast :).

And so?

There are lots of options. I’m fortunate; I don’t have to deal with legacy code. I live in a world of Rust. I minimize the amount of open-source I use; I build simple utilities rather than go searching for open-source versions. I port key libraries I need to Rust (e.g. Opus) to reduce my exposure to FFI wrapped C or C++.

And when a language that’s better than Rust comes along, I’ll be happy to port across to it.

The kind of success I seek is the dull kind. The kind where nothing interesting happens. I’m happy not to get woken up in the middle of the night. Or be chased down the street by a horde of angry customers.

It seems pretty clear that the next security storm is building. I’m preparing as best I can. But I fear much of the rest of the world has their head in their buckets of sand. The next few months are going to be interesting.

On one level SunForum was a just a port of NetMeeting to Solaris. But on another it was an amazing chance to work on a technology whose time had surely come. We had the internet now - video calling was inevitable, wasn’t it?

History, of course, had other ideas. The dot-com bubble killed Sun. It took twenty years - and COVID - for video conferencing to become ubiquitous.

Software engineering was different back then. We were a multidisciplinary team. We architected, designed, implemented, tested, supported. We did product management and technical sales. When I visited Sun in Palo Alto we’d hold a project meeting in the morning, talk technical sales over lunch and do training in the afternoon. It didn’t seem unusual - it was just how it was.

Over the years specialisation has resulted in increasing functional silo-ing. We have dedicated architecture teams. Dedicated support, product mgmt, technical sales. Conventional wisdom tells us this is how software engineering works best. And it does. Mostly.

But now we’re adding AI. And most orgs are treating AI like any previous tech. Adopting an additive approach, just like they did with micro services. Or cloud. Or agile.

I get that; it’s a pattern that worked before. Why won’t it work now?

AI is different

But it’s becoming clear AI is different. It’s not additive. It’s structurally disruptive. Getting the most from AI requires rethinking everything. Everything.

Much of the software dev process is anchored on the expense of building code. Rightly so. Writing code is - was - incredibly expensive. AI makes it cheap. How does that change things?

Suddenly it’s cheap to experiment. It’s OK to create 10kloc as an experiment. And then throw it away. One of my projects is on its fifth incarnation. I build. I learn. I start over. It’s not an easy mindset shift to make - the know-what-you’re-going-to-build-before-you-build-it mantra is deeply ingrained in me.

Product management changes. No longer does it need to be hyper-focused on ensuring the dev team builds exactly the right thing. It can be looser. I share product management with my co-founders. They have imprecise (vague, even?) high-level ideas; I paint the detail. If we don’t like the detail - or the idea - we throw it away. The line between product management and engineering moves.

Or consider human context management. All engineers know the cost of interruptions; it can easily take 15 minutes to recover from a poorly timed interruption. Except it gets worse with AI; I’m juggling so many plates it can easily take an hour to recover from an interruption. It’s more important than ever to remain in the flow.

Or consider the working day. 9-5 is suboptimal for AI; you can achieve far more if you are flexible and make yourself available to unblock and redirect your agent team. My work day is quite different; I start at 6 to see what the team has been up to overnight. After an hour of redirecting them, I go for a walk in the hills and am back with them by 9. I often have a nap in the afternoon (biphasic and polyphasic sleeping seems increasingly common amongst those using AI extensively). Then I work with them on and off during the afternoon and evening. And I always check-in before I go to bed.

Or consider kit. I’ve got three top end servers in my lab. I could happily use another couple. They need to be desktops - laptops just don’t have the cooling to cope with the constant load from constant compile/link/debug cycles. They need to have good quality NVMe drives with long lives (I’ve already worn out one cheap NVMe drive - Rust is a drive killer). They’ll also need to go and live in the workshop over summer - it’s currently 27C in my lab…

The way our team works is different - Qing coined the phrase "sandboxed experimentation". I think that sums up what we’re doing beautifully.

And so?

Right now I’m doing architecture, engineering, team-leadership and ST. I’m back to being multi-disciplinary. I don’t think it’s possible to get the most from AI unless you embrace this.

But if you do then you enter a strange world. I’ve published nine Rust crates so far this year. Roughly 30 years worth of old-world development. Never-mind the other projects - the things I’m working on with my co-founders which double that number. ~150 years of old-world development in a year seems plausible. And bonkers.

And remember there’s a double saving. You save because AI is faster. And you also save because you don’t pay the co-ordination tax (in any team ~30% of the resource is spent on cross-team comms & co-ordination).

But the increasing specialisation over the past few decades presents a problem for AI adoption. How many people are multi-disciplinarians? Specialized knowledge of Python is not the skill set you need to thrive now. It seems likely many engineers have the wrong skill set. Or worse, an increasingly useless skill set.

And silo’d orgs? Well, they’re a problem too. The silos that enabled orgs to prosper when code was expensive to write now limit their ability to adopt AI. The silos actively discourage - prevent - multi-disciplinarian. The very thing you need to get the most from AI.

We’re in a period of flux. It’s clear the old ways are wrong. Structures and roles will change. But it’s not yet clear what the new org structures, the new roles, the new SDLC will be. Which is why sandboxed experimentation matters so much - right now orgs need to be creating multi-disciplinary teams and putting them in a sandbox. Watching. Learning. And then working out how to migrate the old org structures to the new.

Without this? Well, you might be joining Sun in the list of forgotten companies.

EPROMS - erasable programmable read only memories - used to make the world go round. Before the invention of flash chips they were how firmware - the code that gets computers up and running - was shipped. They were the staple of hardware in the 1970s, 1980s and early 1990s.

The early ones were erased using UV light - there’s a little quartz window that lets you see the silicon chip. As a five year old I thought this was incredibly cool.

These days EPROMs have long been replaced by flash memories. But they live on in legacy industrial equipment - CNC machines, industrial controllers. Kit that can last decades without needing replaced. Except that when an EPROM fails, it can’t be replaced - no one makes them anymore. So kit worth hundreds of thousands of dollars is rendered worthless due to the failure of a small part.

Which is why Piers’ OneROM project is so interesting - a modern replacement for a legacy part. Easily programmable. Using a Raspberry Pi Pico - a RP2350 on a custom board. Very neat. I knew Piers had hit the big time when the OneROM appeared on Adrian’s Digital Basement.

A daft idea takes shape

But as we talked my mind began to wander. I’ve got a 386/DOS emulator. Could I build a RP2350 emulator, run the OneROM firmware, program a OneROM with a PC BIOS image, integrate the whole lot with my emulator and boot from that?

I suspect describing this raises questions about my sanity. But let’s ignore that for now and focus on the far more important question: how could I get this working?

Several big pieces came to mind:

• First I needed to add support to the emulator for booting from BIOS images. It’s a high-level emulator at the core - when it starts, DOS is already "booted", so it doesn’t go through the typical BIOS startup flow of enumerating devices, configuring hardware, booting from a hard-disk etc. It’s just instantly on. This is a biggish change. Oh, and I need to find a BIOS image.

• Then we needed a RP2350 emulator. This was the really big bit. The RP2350 is complex and fast (it runs at 150MHz). Could we even emulate it at anywhere near a reasonable speed on a PC?

• Then we’d need to build a OneROM image with the BIOS in place.

• And then integrate the whole lot into the emulator.

I got back from lunch around 7.30pm. And got underway.

Oracles

These days, building follows an increasingly familiar pattern. First up: work out the oracles. The RP2350 has dual ARM (or RISC-V) cores, plus a smorgasbord of peripherals. QEMU has great support for the ARM (and RISC-V cores) - so it made an obvious first oracle. Another oracle was the official data sheet.

But an even better oracle is the real hardware - here is a OneROM (the red board) connected to a RP2040 debug probe. This was to be the first of several OneROMs who’d do sterling service running fuzzing through many nights.

Finally I had a project oracle. I wanted to be able to successfully run Piers’ OneROM in the emulator.

Architecture

With the oracles in place it’s time to think about the architecture. This isn’t very fancy - just a rough idea of the key components, how they map to crates and how they are phased. In the past I’d have written a Word doc. These days I use a post-it note (I was on the bus). Which Claude tidied up and turned into a phase table for me.

The RP2350 is an interesting chip - it has dual Arm cores. And dual RISC-V cores. But you can only choose to use one pair at a time. For now RISC-V cores were out of scope.

And then we were onto building…

Building

The build loop is the key bit. The goal is to give Claude (or Codex) a framework to enable it to work autonomously. Get this right and it’ll run for hours. As I’m writing this I’ve got a Codex session that has been debugging a Windows app problem for ~10 hours.

Design matters. The oracles are the external quality check, but the design is all about getting the innards directionally correct. These days I no longer care how the functions are named or split. I don’t care what algorithms are used. I don’t care about whether Claude uses a vec or an array or whatever. But I do care that I can draw the high-level block diagram. I need to be able to reason about the code from the outside. I need to know there is compartmentalisation. Defined APIs.

We started with the ARM M33 core, with differential testing against QEMU. QEMU is functionally correct. But not, it turns out, cycle accurate for the RP2350 (i.e. correctly report how many cycles each instruction took). So the hardware oracle joined in to provide that information.

And as we went we added UTs. These days I view UTs as a kind of "lock". Build the code, get it to work (via the oracles) and then lock in the function with UTs. They are your watchers, guards if you like, spotting when refactors or changes break the function.

Over the next two weeks we iterated in the background. We added multi-thread support (run each core, PIO & DMA on separate cores). I learnt a lot about the trade-offs involved in multi-threaded emulation (spoilers multi-threading is hard to exploit - as I discovered it’s trivial to create something slower and more complex). I discovered how long it takes Windows to wake up a sleeping thread. We eventually managed to get ~150MHz performance - but only for the right workloads. Emulating a speedy microcontroller on a PC is hard. There’s a whole set of posts here (albeit for a niche audience).

Did it work? You betcha! Here’s the emulator booting using SeaBIOS (an open source BIOS), with the BIOS bytes all served from a OneROM running on a RP2350 emulator. It’s ~20x slower than real-time, but still… It’s quite bonkers. And cool :).

If you want to play with the emulator it’s here. And also as a Rust crate here.

The RP2040 sidequest

Before the RP2350 there was the RP2040. I’ve used a lot of those in retro computing projects over the years - BlueSCSI, PicoGUS. Which got me thinking. If we can emulate the RP2350, surely we can emulate the RP2040 too? So we did. And then we went further and emulated the whole of the PicoGUS - an ISA add in card with RAM, and a D2A converter. The input to the PicoGUS is via the ISA bus. So we hacked Dosbox-x to generate the necessary ISA bus trace of the audio from the startup of Monkey Island. And then fed that into our emulated PicoGUS. And here’s the result:

It took ~20 minutes to generate this clip - so ~20x slower than realtime. But still. This is an emulated RP2040 running an emulation of a Yamaha YMF262 FM sound generation chip. That’s kinda amazing to me.

And so?

Little more than 3 weeks after that lunch, I present to the world a cycle accurate, albeit slow, RP2350 emulator. You can integrate it with your PC emulator to boot a 1990s OS from a BIOS image served by emulated firmware running on an emulated microcontroller. Turtles anyone?

This shouldn’t be possible. Six months ago it wasn’t. But here we are. I don’t have deep ARM expertise. This is my first time using an RP2350. I’m not an expert in PC BIOS. Or Rust. Or really anything. Without Claude I couldn’t have done this. But, equally, I’d like to think (believe?) that I’m a critical part of the process. Claude can’t (yet) do this on it’s own. It needs the framework, the guidance, the focus on quality, the steering. Plus I’ve learnt a lot. And had a lot of fun.

My conclusion? I need to have more pancakes :).

Err, no. Given you’ve completed 90% of the task, I’d prefer you to finish it off now rather than wait a week. And do you even know what daylight feels like?

Opinions vary why Opus 4.7 is doing this. Some view it as laziness; others a sign that Claude is excited by the new "/schedule" command. And some think it is a sign of increasing self awareness; Claude doesn’t want to spend time on work it doesn’t find interesting, or is incentivized to do.

Of course, incentives play a large part in human motivations. So maybe it isn’t a surprise to find them becoming increasingly important as AI improves.

Incentives

But, despite all the improvements in AI, many existing engineering orgs are still struggling to measure any significant productivity improvement. Sure, some orgs (Anthropic, parts of Google) are reporting 10-100x productivity improvements. And I know myself I can run ~100x faster in the right situation. But most are not.

So what’s going wrong?

Perhaps incentives can give us some insight. Take a simplified org structure: we have the execs, the middle mgmt and the individual contributors (ICs) who work at coal-face. Let’s consider the incentives for them to adopt AI.

Start with the execs. They want to improve profitability. AI dangles that carrot. Do more with less staff. Reduce overheads and build more, faster. That aligns well. But many (most?) execs also measure their success by the size of their org. For a typical software engineering company with ~1000 employees, the 10x gain means reducing the size of the org by somewhere between 400-700 employees. That’s quite the drop in perceived status for the CEO. A miss on incentive alignment.

Let’s turn to middle managers. Middle management is a strange twilight zone where people are too junior to drive company strategy, but too senior to understand the engineering details. How do you rank yourself in this zone? Typically it’s what your boss and peers think of you. And the size of your team.

Say you have a team of 100. Then you adopt AI, get a 10x boost. And now you have a team of 10. And… no job. Another miss on the incentives.

Finally the ICs. Many people like writing code. They like the social aspect of work. Imagine you’re in a team of 10 and told to adopt AI. The maths isn’t complex. A 10x gain means 9 of you are no longer needed. So you’re on your own and no longer writing code. Why would you engage with that?

Now you may - rightly - question whether 10x is achievable across the board. Engineers have a lot of meetings and standups to go to. And in a human org that’s true. Brooks worked this out fifty years ago in The Mythical Man-Month: communication channels grow as n(n−1)/2, so a team of 10 has 45 channels of overhead. Three of those people are effectively there just for alignment.

But once you only have 1 or 2 people, the comms cost evaporates. As middle management is slashed there’s no need for monthly all-hands at all levels of the org.

Money

The other factor which gets scant attention is money. If I’m able to use AI to 10x myself, does my comp increase 10x?

Yes, we all know the answer to that.

The company isn’t even going to split the difference. At best, history suggests a ~20% bump and a new title. The company captures the rest.

Historically the most productive engineers have been underpaid relative to the least productive. Netflix even called this out in their original culture deck:

AI just widens this gap. A lot.

And at the other end of the scale what if the employee decides to capture all the gain for themself? Work Monday morning and kick back for the rest of the week? How much of that is already happening?

The incentives are misaligned.

Modelling

An interesting exercise - which you can do right now - is to take your current org chart and ask Claude what the AI-native equivalent version is.

I don’t have an org, so I got Claude to produce the org chart for a 1,000 head software engineering company - SoftCorp - from ~2019. And then we noodled over what it looks like in the modern world.

SoftCorp felt familiar; 46% of heads in engineering, 6-7 layers deep, a variety of baggage collected over the years (co-founders parked as "strategic advisors", friends and family in surprisingly senior roles, parts of the org shared between CMO and CRO so both could claim the headcount).

Ask Claude what the "ai-native" version of this looks like and you are suddenly down to ~580 people. There are deep cuts in QA. In engineering. The support functions reduce as there is less to support. There are new AI specific teams - evaluating tools, orchestrating agents, trust & safety). The org is flatter; middle management is squeezed out. There are 3-4 layers.

Now you might argue, as some have, that you wouldn’t reduce the org size. Instead you’d suddenly be able to do more. But there are a few problems with that. First, say your org suddenly becomes able to do 2-3x more work. Can you really absorb that? Most orgs are short of resource. But not that short.

Then there’s the question of whether you have the right mix of people. The new world needs product management, architecture, co-ordination skills. Not detailed knowledge of Python syntax. Your org suddenly has the wrong skill-set. Engineers, despite what many leaders think, are not fungible.

And what does the new org look like? Probably small teams of 2-3 people, with product mgmt embedded in the eng team. The functional silos are gone. Just how do you transition from today’s org to this new world? Is it even possible?

Another interesting question to ask is what does the equivalent organisation, built from the ground up, look like. Claude suggests ~325 people. No functional silos. 3 layers. No legacy fat. As Claude put it: "greenfield orgs are flat because they haven’t had time to grow tumors."

Well, indeed.

And so?

If Claude had written this section it would open with "The uncomfortable truth"…

And, in this case, it’s probably right. The incentives don’t align - it’s no wonder legacy companies are finding it very hard to drive significant AI adoption. Increasingly I hear stories of companies resorting to a stick based approach: enforcing "minimum required AI usage." Which rather misses the structural issues preventing effective adoption.

But how many CEOs are brave enough - forward thinking enough - to remove 50% of their headcount? Jack Dorsey at Block did earlier this year. But he’s the exception; it seems the majority are like Claude and want to put some things off for as long as possible.

And what happens to those companies in the long run? When someone a third the size can genuinely compete? Undercut the incumbents on price. On quality. On agility. On function.

Maybe realizing how this plays out is the only incentive we need.

One of the regular topics of discussion is how to mark history and English papers. Maths & physics are easy - they have clear yes/no answers. But history and English? They’re a bit vague and wishy-washy.

In a very real way my kids are learning the advantages of good oracles. Good testing oracles enable you to quickly work out if the something is right. Maths has good oracles; English less so.

Oracles

Oracles have become a central part of my life. These days I spend a lot of time thinking about them. They turn out to be critical to the new way of creating software.

I’ll admit it. In the past I paid lip service to testing oracles. If the code built, well, that was often good enough. Building and manual testing went hand-in-hand; by the time I was finished I had a pretty good idea of the quality - and investing more time in test oracles felt like a poor use of time.

But now? Now oracles are critical. They are the tool that turn Claude and Codex from a capable partner into an amazing one.

Take the Rust Opus audio codec side-project I’ve been working on. I added a video capture feature to my DOS emulator; but there were no good native Rust audio or video codecs. In the past I’d have been stuck wrapping C deps in a Rust FFI. But nowadays?

Nowadays I just build the codec I need. For Opus we started with the canonical xiph C implementation. Claude reverse engineered the codebase, writing detailed design docs. While that was underway we worked through the oracles we’d need: UT tests, IETF test suite, differential fuzzing against the canonical xiph implementation, sample audio files for perf testing.

The goal was to build a memory safe, bit identical encoder in Rust, with performance comparable to xiph.

With the design in hand I set Claude (Opus 4.6) and Codex (GPT 5.4) off in parallel building two independent versions. Why both? Well, I was interested in seeing how they compared when given the same brief. Which was faster? Could work longer? Produced better code?

In the end it was a damp squib. Claude quickly drew ahead - mostly because it was able to run for far longer than Codex. At the point where Claude had a basic encoder working, I abandoned the Codex version (or, more precisely, we reviewed to see if there was anything worth saving - and decided there wasn’t).

But the first stage was building the oracles. Once the oracles exist, Claude and Codex have something to build against. They have a way of checking their work. Suddenly they can run independently for hours. These days it’s not uncommon to have 10-20 agent teams busy working for 2-4 hours each across a range of projects.

Over the past three weeks Claude has been grinding away in the background - porting function and, then, fuzzing against the differential oracle. The codec hasn’t been a high priority - but Claude has made steady progress.

Towards the end we focused on performance; Claude ran a perf loop - work through some likely candidates, bench them, test them and then either commit or drop.

In the end decode perf is slightly ahead of the C version - the mean across all different audio types is 5% faster. Encode is 2% slower. I can live with that.

And then we were done; Opus ported (modulo some more niche features). 24 days. 365 commits. 63kloc. >100 hours of fuzzing. >24 hours of mutation testing.

You can find "ropus" here and here.

Reimplementing is easy

Now you might well think porting is easy. And you’d be partly right. Having a reference implementation that can act as an oracle made this much easier. Creating an effective audio codec from scratch would be significantly more work. Even starting from just the documentation would be a lot harder.

But then pause to think of all the legacy code written in memory unsafe languages. Riddled with tech debt. The products we’d love to rewrite but are too scared to. Too worried that our customers are relying on unintentional bugs or weird edges. This technique offers an automated way to tackle those. Your old product is suddenly the perfect oracle. Could the world finally retire Cobol? Fortran?

It’s not just porting

The oracle technique works for new code as well. Assuming you can get the right oracle. I’m building a Raspberry Pi Pico emulator; the prime oracle is the real hardware - Claude has a couple of them hooked up via USB debug probes and can run functional and differential fuzzing against them. They are invaluable.

But…

If this sounds too good to be true, well…

For tasks with maths-style oracles, Claude and Codex are imperious. Porting, refactoring, performance tuning against a reference. They all have natural oracles. But UI work. Or product decisions. Or architecture. Less so. They’re the English tests of the coding world.

It’s the sense of taste that the AI coding tools lack. Take the Pico emulator. The real hardware has two cores, a complex programmable IO controller (PIO), DMA and a bunch of peripherals. A naive implementation steps each core, then ticks PIO, DMA and all the peripherals in a loop. It works but it’s slow - maybe 10% of real time performance. And that’s on a fast host.

Much better is to parallelize the work across multiple cores. But getting the split right still seems beyond Claude - it offered multiple solutions but they all felt, well, a bit clunky. And some were slower than the naive single core approach. But once we’d agreed on an approach? Well, then we were away. We had an architecture. And a perf oracle. Life was good.

And so?

The quality of your oracles now directly correlates with how fast and long you can get Claude to run. What was once an afterthought is now critical. The worse my oracle - or the more the problem resists having one at all - the more I need to stay in the loop.

Suddenly two skills seem critical: designing the thing that checks the code, and having a view on the things no check can settle. Everything in between is getting eaten.

I’m not sure my kids are going to like what’s on the other side of exam season.