Since the turn of the year, a growing sentiment has emerged in the Copenhagen software development community: AI genuinely helps us build meaningful software. Convergence is happening around Claude Code, with agents having access to Git and Markdown files spanning documentation and requirements systems and of course access to the collaboration infrastructure. Use cases stretch from scope definition and requirements to code suggestions, automated testing, and review.
It is, however, clear that reaping the benefits at any meaningful scale is neither simple nor straightforward. Many developers are expressing fatigue and stress from managing multiple agents while struggling to keep pace with rapid tooling changes. Some organizations are drowning in pull requests. And we have seen some rather unfortunate security incidents in recent weeks.
All of this means we need to have a serious conversation about how to organize for success with these new tools. Matthew Skelton and Manuel Pais’ important work on Team Topologies gives us a useful framework for that conversation.
Learning and iteration in small teams
It has been suggested that AI agents can replace team members in the ideal 6 to 10 person stream-aligned team. I would argue the opposite. During transitions to new technology, we need to increase investment, not cut, to create the capacity to experiment and learn. Teams should be kept intact and even reinforced with enabling product operations teams carrying specialized AI knowledge. As that learning matures into new ways of working, we can revisit team sizes.
Staying true to Conway’s Law
Conway’s Law states that organizations which design systems are constrained to produce designs that mirror their communication structures, commonly know as “shipping their organizational chart”. LLMs are indeterministic by nature, not unlike the humans from whose language they were reconstructed. We are already seeing vibe-coded software that inherits this indeterminism. Gas Town being your extreme example. That is not a property you want in production systems.
What we need instead is intentional design: be explicit about where AI assists and where humans must intervene, verify, and improve. I take genuine pleasure in the wave of online posts where people experimenting with AI arrive at the realization that they need to articulate their problem space and user needs in well-structured Markdown files before touching implementation. We have been preaching discovery for years. It turns out that a stubborn LLM is an unexpectedly effective advocate for the point.
As we touch on organisational design, leaders should also be careful not to anthropomorphise AI agents too literally. Naming agents after existing functions like “Marketeer” or “Sales agent for high-end subscriptions” risks reinforcing current silos, even when the objective, such as go-to-market, cuts across the organisation. Agentic processes can naturally span multiple teams and domains, so we should design them around outcomes and value streams rather than mirroring the existing org chart.
The same applies to automated testing
The parallel with testing is equally instructive. AI-generated code without a corresponding discipline around automated testing quickly accumulates invisible debt. Tests are actually an ideal entry point for AI assistance: the scope is constrained, the success criteria are concrete, and the feedback loop is fast. Define what customer value looks like, then let the agents help you get there with automated tests.
Be aware of cognitive load
Almost everyone I speak to describes something close to a game-like addiction to agentic development. There is so much happening simultaneously that the human brain struggles to keep up. One of the central principles of Team Topologies is taking cognitive load seriously, both the domain complexity a team must hold, and the operational burden of the tools and processes surrounding it.
If we ask teams to adopt AI-assisted workflows, we need to frame the assignment and scope in a way that will actually deliver business results. As already mentioned above, a sensible starting point is testing: the scope is predefined by existing software, and the boundaries are clear. From there, teams can move toward requirements and code, where the domain is less constrained and the judgment calls are harder. Walk before you run.
Respect team boundaries and responsibilities
The other foundational principle from Team Topologies, rooted directly in Domain-Driven Design, is the notion of explicit boundaries. Bounded contexts exist for a reason: they reduce coupling, clarify ownership, and make systems comprehensible to the people responsible for them.
Define your bounded contexts in your Markdown architecture files. Give everyone a map, agents as well as team members. Make Conway’s Law work for you by ensuring the structures you communicate reflect the structures you actually want in your system. Matthew Skelton has recently introduced the notion of “bounded agency” and argued that organisations that already work in bounded agency for humans find it much easier to create rules and quardrails for AI agents.
This is where product and engineering leadership must step in. The teams doing agentic development need clear mandates, not just technically, but organizationally. Who owns what? Where does one team’s context end and another’s begin? These are not new questions, but AI makes them even more relevant.
Conclusion: Only organizations in control of their team topology should scale AI tooling
Team Topologies gives us a vocabulary for thinking clearly about new technologies and new tools. Keep cognitive load manageable. Protect team boundaries. Invest in learning before you optimize for efficiency. And do the discovery work: collaborate across functions and with customers in defining the problem space, iterate the requirements, iterate the tests, and gradually build your solution step-by-step. LLMs did not change what good software development looks like. It just made it harder to ignore when we skip the fundamentals.
At Copenhagen Product Collective, I work with companies to assess their product and technology leadership structures and build capabilities across both domains. If you’re wrestling with questions about how to structure your senior leadership and team topology, let’s talk.
