AI for Engineering Teams / Agentic Coding and Team Topologies: How Engineering Teams Should Actually Rethink Workflows in the Age of AI

Agentic coding has quickly moved from niche developer conversation to a mainstream engineering practice. Chances are, your team is already doing it, worrying about it, or arguing about it.

Matthew Skelton, co-author of Team Topologies, asks a more useful question: “Does agentic coding actually change how your engineering team needs to be structured?”

If you watch the full interview, you’ll see that his answer is mostly a no. The reasoning behind this, as you’ll read here, reveals something much more interesting about how AI is changing the way engineering teams work.

Agentic coding is a development mode where you describe what you want to an AI, accept its generated code, and iterate based on the results, often without fully understanding the code it wrote. For individuals building prototypes, this can accelerate early experimentation. For production engineering teams, the risk is accumulating code that nobody fully owns or understands, and that risk compounds quickly as the codebase grows beyond anyone's comprehension.

The more useful question is what agentic coding does to your team’s existing practices. Skelton’s framing is that AI amplifies what your team already does well, as well as what it does poorly. Teams with strong practices that clearly lay out ownership, testing, and the flow of value can move faster with AI assistance. Teams with unclear ownership and messy architecture will only get messier – even faster than they otherwise would without AI.

You are still maintaining production systems with real customers who depend on them, and that context should shape what responsible AI adoption looks like for your team.

AI coding tools can make existing engineering problems surface much faster. When responsibilities are clear, and review practices are strong, teams can turn that speed into real productivity gains. When those foundations are weak, the same tools can make it easier to produce code that no one fully owns, understands, or maintains. That amplification effect is one of the biggest risks leaders can overlook when introducing AI coding tools.

The risk Skelton describes is teams generating high volumes of agent-written code that no one actually understands. He describes this as a modern version of the "throw it over the wall to QA" failure mode from the 1990s, just with extra steps. You end up with a codebase that has no clear owner, that no one can confidently modify, and that drifts further from your architecture with every AI-assisted iteration.

When poorly controlled agents create AI slop, the commit count looks impressive, but the value delivered to customers isn't moving.

The right measure of AI adoption is whether cognitive load across your stream-aligned teams is actually going down, not lines of code generated or pull requests merged. AI used well eliminates extraneous overhead. AI used poorly creates a codebase no one fully understands, raising cognitive load sharply with every iteration.

Team Topologies distinguishes between three types of cognitive load, namely intrinsic load (the inherent complexity of the task itself), extraneous load (unnecessary mental overhead that gets in the way of the work), and germane load (the kind that builds lasting expertise). Reducing extraneous cognitive load is the goal, which means clear ownership, minimal context switching, systems your team actually understands, and fast feedback loops.

AI, when used well, can genuinely reduce extraneous cognitive load. It can handle boilerplate, speed up documentation, and help teams prototype ideas before committing to them. Used poorly, however, AI can have the opposite effect. Teams end up mentally parsing code that nobody intentionally wrote or fully owns. Over time, that code can accumulate and drift beyond anyone’s understanding.

Stream-aligned teams, one of the four fundamental team types in Team Topologies, are organized to deliver value to customers quickly with minimal handoffs. AI does not change that underlying principle. What changes is the cognitive load each person carries and whether your AI tooling helps reduce it or adds to it.

If you measure AI adoption by only commit volume or pull request count, you are measuring the wrong thing. A better question is whether your stream-aligned teams are delivering value faster while carrying less cognitive load than they were six months ago.

Organizations adopting AI in engineering are taking two broad approaches. Enterprises are often integrating AI into specific workflows with minimal disruption. Startups and smaller teams are more willing to use agentic coding to build or rewrite systems from scratch, trading some short-term risk for speed. In both cases, success depends on clear ownership and keeping cognitive load under control.

Established enterprises tend to move cautiously. Their systems are large, their teams are distributed, and their tolerance for instability is low. They are more likely to use AI for specific tasks such as code review, test generation, and documentation. Rebuilding a core system entirely with AI-generated code carries significant risk when compliance requirements, complex integrations, and decades of institutional knowledge are involved.

Startups and smaller teams can take a different approach. Some are rewriting systems from scratch with AI, describing what they want at a high level and iterating quickly on the output. This is vibe coding in its most literal form. Prompt, accept, test, and repeat. The speed gains can be substantial, but so can the risks – especially when those systems need to scale, founding engineers leave, or something breaks in production and nobody can explain why.

A startup with little technical debt and a need to move quickly faces very different constraints from an enterprise running 20-year-old financial infrastructure. The same questions still apply to both: Are you staying focused on delivering value? Are you keeping the cognitive load that AI introduces under control?

Shadow AI refers to the use of AI tools outside your organization's governed environment. It tends to emerge when the official platform is too slow, too restrictive, or too disconnected from developers' actual workflows. That means it’s a platform trust problem as much as it is a governance problem. When developers work around official tooling, it can signal that the platform is failing to meet their needs.

When centralized AI tooling is difficult to procure, too restricted to be useful, or disconnected from day-to-day development, teams find their own solutions. They bring in AI models, build internal wrappers, and develop practices that remain invisible to the wider organization. This is shadow AI, the engineering equivalent of shadow IT. The barrier to adopting an AI tool is much lower than setting up an unauthorized server, so the behavior can spread much faster.

The motivation is usually simple. Developers need tools that help them get their work done, and they will look elsewhere when the official path gets in the way. The risks can be significant. Ungoverned AI tools may lack security reviews, shared organizational context, consistent quality controls, and visibility for the teams responsible for governance. Platform engineers can end up playing catch-up with tools and workflows they did not know existed.

Tighter restrictions alone rarely solve the problem. They can simply push more of this activity underground. A better approach is to build a platform that developers trust and want to use. It needs to move quickly enough to keep pace with their needs while providing the governance that security and compliance teams require. JetBrains Air Governance connects AI tools, agents, and workflows under centralized governance, helping teams move quickly without fragmenting into disconnected shadow setups.

Team Topologies provides a practical lens for evaluating AI adoption. Stream-aligned teams still need to stay focused on delivering value with minimal handoffs. New AI tooling should support that goal by reducing friction rather than creating more dependencies. As AI becomes part of everyday development, organizations also need clear ownership of the practices and standards surrounding it. Platform teams need to keep pace, or developers may turn to shadow AI.

Introducing AI tools to stream-aligned teams should not mean adding more review gates, approval workflows, or dependencies on other teams. If adopting an AI tool creates three additional handoffs, you have increased cognitive load rather than reduced it. You have also introduced the kind of friction that can push developers toward unofficial tools.

By helping stream-aligned teams adopt new capabilities, enabling teams provide the specialized expertise needed to bridge the gap. They can help teams develop effective prompting practices, establish review approaches for AI-generated code, and define where AI should and should not be used. This kind of cross-cutting support allows stream-aligned teams to adopt new capabilities without having to become experts in every aspect of AI development themselves.

Platform teams also need to move quickly enough to keep up with developers' needs. If the response to a request for AI coding tools is a six-month procurement cycle, developers are likely to find alternatives long before that process is complete. The job of an engineering leader remains the same. Create the conditions that allow teams to deliver value with as little unnecessary friction as possible. AI changes the tools available to teams, but it doesn’t change that core responsibility.

The strongest engineering teams generate plenty of AI code, but they also maintain clear ownership, manage cognitive load deliberately, and stay focused on delivering value to their customers.

Agentic coding is the way of the future, but only when it is quality-controlled. Speed without structure creates exactly the kind of AI slop that Skelton warns against, impressive velocity toward a codebase that nobody can confidently change six months from now.

If you're working through how to adapt your team structure and practices for an AI-heavy environment, the full interview with Matthew Skelton is worth your time: Watch it here.