AI is changing software engineering at an extraordinary pace.
From agentic coding assistants to autonomous workflows and AI-powered SDLC tooling, engineering teams are now operating in an environment where the pace of change itself has become a major architectural concern.
But amid the excitement, an important question is emerging:
Do socio-technical systems and Team Topologies still matter when AI agents can generate code, orchestrate workflows, and accelerate delivery?
In a recent Serverless CrAIc discussion, David Anderson, Mark McCann, and Michael O’Reilly explored how AI is reshaping engineering organisations, cognitive load, and team structures — and why the human side of software engineering may actually become more important, not less.
The Real Challenge Isn’t AI — It’s Cognitive Load
One of the strongest themes from the discussion was the explosion of cognitive load across engineering teams.
The team reflected on how Team Topologies was one of the first widely adopted frameworks to treat cognitive load as a first-class concern in software engineering.
Historically, engineers experienced cognitive overload without necessarily having a formal language for it:
“My head’s melted.”
That was often the reality.
But AI introduces a completely new dimension.
The pace of capability evolution is no longer measured in years or even months. It changes weekly.
As Mark McCann explained, engineers are now:
- learning entirely new workflows
- evaluating rapidly evolving tooling
- adapting to emerging AI capabilities
- redesigning delivery practices in real time
- attempting to distinguish signal from noise
All while still shipping production software.
The result is an industry drinking from a fire hose of information.
The cognitive load challenge is no longer just about understanding a codebase.
It is now about understanding:
- ecosystems
- AI tooling
- orchestration frameworks
- governance models
- security implications
- organisational constraints
- platform enablement
- product context
- business outcomes
And this changes where engineers spend their mental energy.
Engineers Are Moving Higher Up the Value Chain
One of the most important observations from the conversation was that AI shifts engineering cognition away from implementation detail and towards business value.
Previously, much of an engineer’s focus sat in areas such as:
- programming languages
- framework implementation
- infrastructure mechanics
- technical optimisation
- code-level concerns
AI increasingly automates portions of that work.
But this does not remove complexity.
It simply moves complexity elsewhere.
Now engineers must think more deeply about:
- domain understanding
- stakeholder needs
- product outcomes
- user experience
- system boundaries
- governance
- orchestration
- architectural trade-offs
Michael O’Reilly described this as a shift towards “outcome-value-driven cognition”.
In practice, this means engineering teams are spending more time asking:
- Is this solving the right problem?
- Who validates this outcome?
- Which domain expert owns this capability?
- How should responsibilities be separated?
- What constraints should exist?
This is a major evolution in modern engineering.
And for many teams, it increases cognitive load because these concerns sit outside traditional technical comfort zones.
AI Agents Still Need Organisational Design
One of the most interesting parts of the discussion centred around whether AI agents should be considered “team members”.
While the answer was nuanced, the broader conclusion was clear:
The same organisational principles still apply.
Even if AI agents become increasingly autonomous, organisations still require:
- clear boundaries
- defined responsibilities
- communication paths
- orchestration models
- governance constraints
- separation of concerns
Without those structures, organisations simply recreate the same bottlenecks software engineering has faced for decades.
Mark McCann highlighted that swarm-based agent orchestration introduces many of the same challenges Team Topologies was designed to solve:
- unclear ownership
- duplicated responsibilities
- coordination overhead
- dependency bottlenecks
- scaling friction
In other words:
AI does not remove socio-technical complexity.
It amplifies it.
And this is precisely why Team Topologies still matters.
Platform Teams Become More Important — Not Less
The discussion also explored the evolving role of platform teams.
There is often confusion in organisations where “platform engineering” becomes little more than rebranded infrastructure operations.
But true platform teams are strategic enablers.
In an AI-driven environment, their responsibilities become even broader.
Modern platform teams now need to support:
- AI development environments
- agentic runtimes
- orchestration frameworks
- security guardrails
- observability tooling
- FinOps governance
- runtime policies
- AI SDLC enablement
- organisational standards
As Mark McCann described it:
“There’s freedom within the fences.”
Platform teams create the enabling constraints that allow stream-aligned teams to innovate safely and autonomously.
This becomes critical as AI accelerates delivery throughput.
Because while AI may increase development speed, organisations still need:
- governance
- security
- compliance
- operational reliability
- production standards
- architectural consistency
The faster teams move, the more important those enabling systems become.

AI Changes the Shape of Software Engineering — Not the Need for Humans
One of the strongest conclusions from the conversation was that the difficult part of software engineering has never been typing code.
The hardest part has always been:
- people
- communication
- organisational alignment
- discovery
- prioritisation
- decision-making
- ambiguity
- constraints
- operational trade-offs
AI may optimise portions of implementation.
But the human complexity remains.
Possibly more than ever.
David Anderson summarised this clearly:
“If code generation throughput goes up, then all the other stuff becomes even more important.”
That “other stuff” includes:
- product discovery
- domain modelling
- architecture
- governance
- production readiness
- operational excellence
- platform strategy
- stakeholder management
- organisational design
Which is exactly why socio-technical thinking remains foundational.
Team Topologies Still Matters in the AI Era
The final takeaway from the discussion was not that Team Topologies becomes obsolete.
Quite the opposite.
AI increases the need for:
- organisational clarity
- cognitive load management
- enabling constraints
- clear team boundaries
- platform enablement
- socio-technical awareness
The tools may evolve.
The workflows may accelerate.
The SDLC may become increasingly agentic.
But the need to design effective systems of humans, platforms, processes, and constraints remains.
Because software engineering has always been about more than code.
And AI is proving that faster than ever.
Key Takeaways
AI increases cognitive load
Engineering teams now face rapid capability shifts, tooling fragmentation, and continuous ecosystem change.
Engineers are moving closer to business outcomes
AI reduces some implementation burden but increases the need for product, domain, and organisational understanding.
Platform teams become strategic enablers
AI-native engineering organisations require stronger governance, observability, security, and operational enablement.
Socio-technical systems still matter
AI agents still require structure, orchestration, boundaries, and governance.
Team Topologies remains highly relevant
The principles behind cognitive load management and organisational design are arguably more important in the AI era.
Final Thought
The future of software engineering is not humans versus AI.
It is humans designing systems where humans and AI can work together effectively.
And that is ultimately a socio-technical systems problem.
References
This article was adapted from a Serverless CrAIc discussion featuring David Anderson, Mark McCann, and Michael O’Reilly exploring AI, Team Topologies, cognitive load, platform engineering, and socio-technical systems.
