Mind the gap

Is there a clue lurking in it?

Last week I found myself on a train passing Darlington. As we slowed for the station, I found myself thinking about British Rail’s modernisation plan from 1955. Back then British Rail realised technology was changing - and it needed to modernise. Replace steam locos with diesels (many built in Darlington), modernise stations, signaling, freight yards. It was an ambitious project - and gave us the railways we have today. It’s part of the reason my journey took four hours and not the eight back in 1955.

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.