You’ve seen the demos. Your developers are typing at lightning speed, using LLMs to generate boilerplate, refactor functions, and autocomplete entire modules. The individual productivity metrics look incredible. But as an engineering manager, you’re staring at the dashboard and realizing something terrifying: the team isn’t actually getting faster.
Recently, a software engineering manager at a massive tech company asked a simple question on Hacker News: Are any of you finding real gains outside of individual developers using AI? The silence on team-level improvements was deafening.
We are paying for a 10x developer and getting a 10x silo.
We bought into the promise that AI would be a force multiplier for the entire engineering org. Instead, we’ve handed every developer a private jetpack. They are flying faster than ever, but they are flying straight into their own isolated corners. The code is being written, but the shared understanding of how or why it works is evaporating.
Think about the “bus factor”—the risk associated with information not being shared among team members. AI is actively making this worse. When a developer relies on an LLM to write a complex script or automate a bash command, they often skip the documentation phase. The code works, the ticket closes, but the rest of the team has no idea what just happened under the hood.
Speed without shared context isn’t progress; it’s just faster accumulation of technical debt.
I’ve seen this firsthand. A junior dev uses an AI agent to spin up a microservice in an afternoon. Impressive, right? Two weeks later, it breaks in production. The dev who wrote it is on vacation, and the rest of the team is staring at an opaque wall of AI-generated code they didn’t architect and don’t understand. The incident response time triples because the collective knowledge isn’t there.
The real bottleneck in software engineering was never how fast an individual could type. It was always team-level coordination, knowledge transfer, and reducing toil. Yet, most AI adoption strategies completely ignore this.
If your AI tool only helps the person typing, it’s a liability disguised as a feature.
If you’re an engineering manager or team lead, you need to stop evaluating AI based on how many lines of code your devs can produce. That metric is a trap. The real ROI lies in redesigning your workflows for shared AI context. You need AI that helps distribute work requests, automates incident responses, and captures the context of the code it generates so the team owns it, not just the individual.
The frontier of AI in software development isn’t personal productivity. It’s collective intelligence. Stop optimizing for the individual, or watch your team’s cohesion disintegrate at the speed of light.
FAQ
Q: Isn't faster individual output still a net positive for the team?
A: Not if it creates isolated knowledge. A team of fast coders who can't understand each other's AI-generated work is a fragile liability, not an asset.
Q: What's the practical implication for engineering managers?
A: Stop measuring AI success by lines of code or individual ticket throughput. Start measuring incident response times, onboarding speed, and cross-team code comprehension.
Q: What's the contrarian take on AI coding assistants?
A: The current wave of AI coding assistants is actively anti-collaborative. They optimize for the individual at the direct expense of team resilience and shared context.