1995 - the Anniversary edition of Fred Brooks' "The Mythical Man Month" which documented Fred's insights into software development complexity. I remember in that year, being at work while an 'old guy' sat at the single computer updating the program. I can't recall what he was changing, but it would have been related to stock and invoicing. The computer wasn't even linked to the cash register.

I wonder if either Fred, or the 'old guy' could have imagined that so many people might believe programmers (all of them?) will be replaced non-programmers, as was promised with the low-code capabilities. A decade (or more) later, I wonder if they'd imagine that so many believe programmers will be replaced by programs?

I don't think either will happen in any scale, not any time soon. I've spent a quite some time over the last year (designing & developing software) using AI & AI-driven tooling. It's great. It's faster. It's also painful and slower. My experiences indicate the promise versus reality reveals a nuanced picture.

When I reflect on what these new capabilities might mean beyond the mega-hype in 'social media' (btw, is it really social?) - I've come to a preliminary conclusion that those who believe 'replacing all engineers' with AI-agents to autonomously build software are in for a hard time. No doubt this is unpopular, perhaps just wrong. My contention though is that it's really hard for businesses - whether technology companies or corporates - to implement (or maintain) basic hygiene and practices let alone build great software, and that letting what I think amounts to an inexperienced developer with awesome research skills loose on something that is core to a business, or is the product, is a high risk strategy.

I believe it does have a place in a software engineering team—a role. Fred Brooks pointed to Harlan Mills' "surgical team". This is where I think AI can today, right now, be the most effective.

We need the surgeon, the expert senior programmer, the tech lead. The software, particularly its critical parts, need to have design decisions made, and the integrity of the system looked after. This isn't a role for AI. However, lets look at the other roles.

Guided by perhaps some skilled engineers, AI can play a significant portion of the tester role, the toolsmith and in many cases, the language layer. I find this division of labour both exciting and a little daunting—it's a real shift from how teams were structured even a decade ago.

I think this fits quite neatly with Martin Fowler's notes in his architectural thinking framework: software design requires understanding trade-offs that extend far beyond the immediate implementation. This is a capability current AI lacks, whereas the expert senior programmer has this as a core role capability.

Even in this model the engineering leadership needs to consider the gap—how do you get senior, experienced engineers and tech leads? If the prompt-jockey (or is this now vibe-coding?) career path replaces real learning and hands-on experience, there's a problem brewing.

In any case, it is obvious that the use of AI aligns in some ways to these roles/capabilities. But I wonder, if (who and how) this model/concept is really being designed/implemented more formally in organisations? So many engineering leaders use Team Topologies as a model. How does some structure, consistency and perhaps even, formalised approach evolve?