AI made you faster. It made your team slower.
By Kaia Colban
Last Thursday I spent four hours in a Claude Code session untangling a rate-limiting bug in our payments service. I tried three approaches. Two failed in ways that aren't obvious from the code. The third worked, but only after I found an edge case that took an hour to surface. I wrote code. I merged the PR. My teammate Sarah, who's touching the same service this week, has no idea any of this happened.
Not because I didn't tell her. Because there's no real mechanism to tell her, short of writing a doc nobody asked for or scheduling a meeting to explain context she didn't know she needed.
This is the version of the AI productivity story we're not telling yet. And in 2026, it might be the most important one.
The number everyone cites, and the one nobody talks about
91% of engineers use agentic AI coding tools at work now. Three out of four have shipped production code primarily generated by AI in the last six months. Individual throughput numbers are genuinely up. GitHub Octoverse data shows it. Cursor's case studies show it. The numbers are real, and I'm not here to relitigate them.
But here's the number I keep thinking about: developers report spending 4 to 7 hours per week reconciling AI-generated code that ignored team conventions. That's not a rounding error. That's a workday. And 63% of engineering organizations now run two or more AI coding assistants concurrently, each with its own memory, its own context, its own view of the codebase.
We built the AI era almost entirely as a single-player experience, then measured it with single-player metrics. Of course individual velocity looks good. The question is what's happening at the team level, and most teams aren't measuring that yet.
The reframe that actually matters
The popular version of this problem goes like this: the reasoning disappeared. Your AI writes the code, you ship it, and now you can't explain the decisions behind it. Context evaporates. The team is left holding PRs without understanding.
I've seen this framing in engineering blogs, Slack threads, conference talks. I think it's exactly backward.
The reasoning didn't disappear. It's written down.
Every decision, dead end, and workaround from that Claude Code session last Thursday is sitting in my session history, more complete than anything I would have written in a Notion doc at 5pm. I know why I rejected the first approach (it caused timeout cascades under load). I know why I picked the specific library I landed on. I know where the test coverage is thin and why. All of it is captured, in real time, in the session.
The problem isn't that the context disappeared. The problem is that it's mine.
For the first time in the history of software engineering, we actually have more captured context than we've ever had. More than memory, more than inline comments, more than Slack threads. It's sitting in AI sessions, accumulating every day. We're just not using it as a team resource.
Why "document more" is the wrong answer
I know what the standard response is. Write ADRs. Update the wiki. Leave better commit messages. Be the engineer who documents things properly.
I've tried this. The gap isn't willingness, it's overhead. And beyond the overhead, it's a category error.
A Claude Code or Cursor session is already documentation. It's a real-time record of every hypothesis tested, every approach rejected, every rabbit hole explored. When the session ends, there's more written context in that conversation than in any architecture decision record I've produced in years. The bottleneck isn't that nobody wrote it down. The bottleneck is that what got written is invisible to everyone else on the team.
When Sarah hits something that rhymes with my rate-limiting bug, she'll file a ticket. She'll spend two days on it. I'll probably hear about it on Friday and say, oh, I was just in there, and then we'll both feel bad about the two days, without anyone being at fault. The context existed. It just wasn't findable.
That's the team-level cost of single-player tooling.
What's actually broken
The thing that shifted in the AI era isn't that context moves too fast to capture. It's that context is now being captured automatically, at the moment decisions get made. The bottleneck moved.
It's not: did we write it down? We wrote it down. The bottleneck is: can the team find it before they redo the work?
For most teams right now, the answer is no. Not because engineers are hoarding context, but because the tools don't connect. When five engineers each have their own Claude Code setup, their own session histories, their own AI workflows, you get five fast engineers who don't know what each other's sessions learned. Sarah's Claude doesn't know what mine figured out about the payments service. It can't. The sessions don't talk to each other.
You end up with a team that is individually very fast and collectively slower than it looks. Five engineers, five private context stores, five Claude instances that don't share memory. The intelligence is there. It's just not shared.
What a connected team looks like
The interesting engineering teams I've talked to in 2026 are starting to figure this out, and what they're doing is less dramatic than you'd expect. They're not building elaborate documentation systems or mandating AI session summaries. They're making session context findable.
The shift in thinking is simple: stop treating AI sessions as ephemeral chat history, and start treating them as the primary artifact of engineering work. The PR is the output. The session is the reasoning. These are not the same thing, and for the first time, you can actually preserve both.
When a team can search across its sessions, something changes. The question isn't "can I remember why we did this?" anymore. It's "can I find the session where we figured it out?" That's a different kind of question, and it has a different kind of answer.
Dead ends become shared. Decisions become findable. The next engineer to touch the payments service can find out what I figured out last Thursday before they file a ticket.
The question I keep coming back to
I think about that rate-limiting session a lot. Four hours of context, all of it written down. The decisions are in there. The dead ends are in there. The edge case that would take Sarah an hour to find on her own is in there.
None of it is where she can get to it.
Most engineering teams in 2026 have accumulated a lot of sessions like that. The AI made us faster individually. The question is whether we've actually built a team out of it, or just a collection of very fast individuals who happen to share a codebase.
That gap is closable. The reasoning already exists, in more detail than we've ever had before. The question is whether it's shared.
What does your team know about what your AI figured out last week? If you're not sure, that's probably the answer.
The intelligence is there. The question is whether anyone else can find it.
FAQ
Why can't engineers just share their session logs manually?
The overhead is the problem. An AI session can run for hours and contain dozens of branching decisions. Asking engineers to summarize and share every meaningful session is asking them to do documentation work on top of the work they already did. The right answer is making sessions searchable without requiring manual curation.
Doesn't this already exist? What about wikis, ADRs, Confluence?
Those tools require someone to decide to document, and then to actually write it. AI sessions are captured automatically, in real time, without a separate documentation step. The challenge is surfacing the signal from the sessions, not generating it.
Is this a problem only for large teams?
It shows up earlier than you'd expect. I've heard the same story from teams of eight that I've heard from teams of eighty: one engineer figures something out in a session, merges the PR, and two weeks later a colleague repeats the same investigation. Team size scales the pain, but doesn't cause it.
Does this mean AI coding tools are making teams worse?
No. Individual velocity is genuinely up. The issue is that the tooling was built for individual productivity, and teams haven't yet built the infrastructure to capture the collective benefit. That's fixable.
What's the first step for a team that wants to close this gap?
Start by auditing one week of work: for every PR merged, ask whether the reasoning behind it is findable by a teammate. If the answer is consistently no, you've confirmed the problem. The solution follows from that.