AI made me a faster engineer. It didn't make us a better team.
By Kaia Colban
I noticed it the third time this month. I shipped a feature in two days that would have taken me a week in 2024. I felt fast. I felt good. Then I tried to brief a new engineer on it, and I realized I couldn't explain half the decisions I made.
AI made me a faster engineer. I'm not sure it made our team a better team.
The number nobody wants to talk about
70% of developers say AI has helped their personal productivity. Only 17% say it has improved team collaboration. That's a 53-point gap, and it's the most strategically important number in engineering right now.
The first number is obvious. Of course AI helps you personally. The model writes the function, you accept the suggestion, you move on. Saved 90 seconds. Repeat 50 times a day. By Friday you have shipped twice as much.
The second number is the one that should be keeping engineering managers up. The thing that used to bind a team together (the long Slack debates, the design review where someone said wait, why are we doing it that way, the lunch conversation where the new hire learned why the auth layer sits outside the gateway) is now happening inside individual sessions. Each engineer is more productive. The team is operating on less shared context than before.
The two things people are doing
When engineers say AI is helping, they mean one of two things, and they are not the same.
The first is typing assistance. The model writes the function you would have written. You read it, accept it, move on.
The second is thinking assistance. You bring the model a problem you don't fully understand. You explore three approaches. You reject two for specific reasons. You discover a constraint mid-session. By the end the code is shipped, and the more valuable artifact is the conversation that produced it.
Typing assistance shows up as velocity. Thinking assistance shows up as understanding. Most teams measure neither at the team level, even though both are happening.
Where the team is losing
Here is what is actually happening to your team while individual productivity climbs.
Engineers are duplicating each other's work. 47% of developers say they duplicated a teammate's effort in the last six months (Stack Overflow 2025). Not because they're lazy. Because they didn't know the other person had already explored that approach. The collision used to surface in standup or in a PR comment. Now it surfaces never, because both engineers had a quiet productive afternoon with Claude Code and shipped two implementations of the same thing.
Engineers are duplicating each other's thinking. Two engineers ask the model the same architectural question, get similar answers, neither knows the other did. Your team is paying for the same exploration twice.
Onboarding has not improved. New senior engineers still take roughly nine months to reach full productivity at a new company. The codebase is being written faster than ever. The why behind the code is moving inside session histories. Nine months is what it takes to ask enough people enough questions to recover that context.
PR review time is up 91% on high-AI teams (Faros AI 2025). The model writes code faster than the human can review it. Quality control has become the bottleneck, and reviewers are catching less because there is more to look at.
Why the standard answer is wrong
The standard answer to this is more documentation. Run a wiki. Mandate ADRs. Schedule weekly knowledge-shares. None of this scales, because the reasoning that needs to be captured is the reasoning that happened inside a Claude Code session yesterday. By the time an engineer writes a doc on Friday, the context is stale.
The other standard answer is more meetings. Daily standup. Weekly design review. Bi-weekly engineering all-hands. This re-creates the collaboration that used to happen incidentally. It also kills the velocity gains AI was supposed to deliver.
Neither works because both treat the team layer as something to add on top of individual work. The team layer used to be where the work happened. The work moved. The team layer didn't.
What actually closes the gap
The real answer is to make the individual work visible at the team level. The Claude Code session where I figured out why the auth layer needs to sit outside the gateway should be sourced, shareable, and under our control. When the new engineer asks why next month, the answer should be findable in 30 seconds without my involvement.
This is what Lore is built for. Sessions get ingested from Claude Code, Cursor, Codex. The reasoning gets extracted and structured into decisions, dead ends, open threads. The team operates on a shared substrate instead of 100,000 disconnected threads.
The how is in the code. The why used to evaporate. Now it can stay.
The honest summary
The 70/17 gap is the canary. AI is making engineers faster individually. It's not yet making teams better as teams. The only way that changes is if the work that used to bind a team (the debates, the shared context, the reasoning) gets back into the team's bloodstream.
You won't fix this with more wikis or more meetings. You fix it by making the sessions themselves the substrate your team operates on.
What is your team doing to close the 53-point gap this quarter?