The Team Is the New Context Window
AI makes the individual developer faster, but not necessarily the team. Give ten developers the same tools and you get ten different ways of working, and that friction gets paid at the team level. The answer is not to make everyone work the same way, it is a shared base of rules, skills, and review criteria.
A few days ago a colleague told me something that stuck with me. He pulled down a project someone else had been working on and tried to use his own AI models, the way he always does. The skills barely existed, or were not built for how he works, and the agents kept generating code that did not follow any of the standards he is used to.
He was not the only one that week. I ran into more than one colleague going through something similar, and that is what got me thinking about this.
Something is happening in software engineering. Individual developers got considerably faster. Ideas that used to take hours now get explored in minutes, we prototype, validate, discard, and try again with an effort that was not possible before. That is good.
I also do not see AI as a dangerous dependency. We already lived through something similar with the Internet, search engines, and modern editors. Tools do not remove the need for judgment, they change where you apply it. AI is a tool. How much you trust what it produces still depends on your own judgment.
But there is a more interesting problem. AI can sharply increase individual productivity without increasing team productivity.
Ten developers, ten ways of working
Give the same tools to ten developers and you get ten completely different ways of working. One will have carefully defined rules and skills; another will stay on the defaults. One will watch the context window and token usage; another will not even look. Some will review almost every line an agent writes; others will only glance at the final diff. Some will run one agent, others several.
None of this is bad on its own. Experimentation is part of what makes AI so powerful. The problem shows up when all those individual systems have to live inside the same team.
The bottleneck moved
A software team is not a collection of independent developers. They share architecture, code, documentation, decisions, and responsibilities. If every person works differently with AI, the productivity gained individually starts generating friction at the team level.
The old concern was whether developers could write code fast enough. That is not it anymore. The bottleneck today is whether the organization can coordinate all the code AI lets them produce.
A shared base, not a single mold
The answer is not to control how each developer uses AI. It is to set a shared base, principles for working with agents, project instructions, reusable skills, criteria for context and code review, limits on autonomous actions, documentation standards, and mechanisms to validate what the agent produces. The goal is not for everyone to use AI the exact same way. It is for the system to stay coherent even though the people using it are different.
That is, in practice, what we ended up building with .agents, one place for rules and skills any AI editor can read, so the source of truth does not depend on which tool each person picked.
You also have to be careful with what you measure. Tokens spent, prompts sent, or lines of code generated are not productivity. The goal is not to maximize AI usage. It is to maximize useful outcomes.
I think we are entering a second stage of adoption. The first question was how to use AI, we tried models, agents, MCP servers, skills, context windows, and increasingly autonomous workflows. The next question is how we work with AI as a team. And that question is much bigger, it involves culture, architecture, tooling, documentation, and organizational design.
The companies that solve it will not be the ones whose developers write the most sophisticated prompts. They will be the ones that turn individual AI capability into a capability shared across the whole organization.
Close
AI gives individual leverage. Teams build systems. If every developer gets much more capable but the system around them stays the same, that system eventually becomes the bottleneck.
Maybe the next generation of engineering practice is not about teaching each developer how to use AI, but about teaching the team how to think with it.
The most important context window of an AI-native organization is not the one inside the agent. It is the one the whole team shares.