Over the past few years, my workflow as an engineer has changed a lot.
I went from the occasional autocomplete to using AI for ideation, debugging, refactoring, and system design when appropriate.
At the individual level, the gains were obvious.
But something more subtle started happening at the team level.
The unexpected downside
AI didn’t just make us faster.
It changed how we think together.
I’ve been in teams that adopted strong practices around knowledge sharing and AI usage, and others that didn’t.
The difference is noticeable.
Some teams became faster and sharper.
Others became:
- faster… but misaligned
- productive… but shallow
- shipping more… but understanding less
From experience, teams have always struggled with effective knowledge sharing.
However, AI is accelerating the issue for teams that are not prepared.
The core issue
AI can improve individual productivity when used appropriately.
But engineering is rarely an individual activity.
It’s a coordination problem.
It depends on:
- shared mental models
- clear reasoning
- aligned decisions
Without these, speed creates drift.
“AI can generate output. Teams must generate shared understanding.”
That’s the gap most teams aren’t addressing yet.
From individual thinking → team thinking
In my previous guide (Thinking in the Age of AI introduced via this post), I focused on:
- How engineers can maintain strong thinking individually
We will now focus on the next layer:
- How teams can think well together while using AI
At the team level, more dynamics come into play than at the individual level.
This is my attempt to put forward some practical solutions to help engineering teams.
What I’ve been experimenting with
I’ve been experimenting with a series of practices that can be used across teams.
Not big process changes.
Just lightweight habits that:
- make reasoning visible
- slow thinking down just enough
- turn daily work into learning
4 practical exercises you can try with your team this week
1. AI usage transparency
After AI-assisted code is merged, add a simple note:
- Was AI used?
- Where was it used?
- What was verified manually?
This sounds trivial, but it changes team behavior.
Without this, AI usage becomes invisible.
Over time, no one knows:
- where the team relies on AI the most
- what types of problems are being outsourced
- where verification is weak
With this, patterns start to emerge.
This leads to better discussions around:
- when AI is actually helpful
- where we should slow down
- where we were over-relying without realizing it
You can use this template:
AI Usage Declaration
AI used? ☐ Yes ☐ No
If yes:
• Where was AI used?
_____________________________________________________________________
_____________________________________________________________________
• Purpose:
☐ Generate
☐ Refactor
☐ Debug
☐ Explore
• What was verified manually?
_____________________________________________________________________
_____________________________________________________________________
2. Team AI dependency check
Every couple of weeks, take 5 minutes and ask:
- Are we skipping initial reasoning more often?
- Are we accepting AI outputs without challenge?
- Is debugging depth decreasing?
- Are explanations getting weaker?
You don’t need metrics. Just honest discussion.
This is less about “reducing AI usage” and more about using it intentionally.
I’ve seen teams drift without noticing it.
Nothing breaks immediately.
But over time:
- intuition weakens
- understanding becomes uneven
- fewer people can explain the system clearly
This exercise helps catch that early—and adjust before it becomes a real problem.
You can use this template:
Team AI Dependency Signals
☐ Engineers skip initial reasoning
☐ AI outputs accepted without challenge
☐ Debugging depth decreasing
☐ Code explanations unclear
☐ Increased reliance for simple tasks
What pattern do we observe?
_____________________________________________________________________
_____________________________________________________________________
What adjustment will we make?
_____________________________________________________________________
_____________________________________________________________________
3. No-AI debugging sessions
Pick a real bug.
One engineer debugs it without AI, while narrating their reasoning.
The team watches and helps out when needed.
At first it feels slow.
Then you realize most engineers rarely see how others think anymore
This surfaces:
- debugging patterns
- assumptions
- decision-making
In my experience, debugging sessions under this format are one of the fastest ways to level up a team.
Ideally, document the session with notes from both the debugger and the observers.
You can use this template:
Debugger Notes
What do I think is happening?
_____________________________________________________________________
_____________________________________________________________________
What signal am I checking first?
_____________________________________________________________________
_____________________________________________________________________
What assumption am I testing?
_____________________________________________________________________
_____________________________________________________________________
What changed my understanding?
_____________________________________________________________________
_____________________________________________________________________
Team Observation Notes
What reasoning pattern did we notice?
_____________________________________________________________________
_____________________________________________________________________
What step was most valuable to observe?
_____________________________________________________________________
_____________________________________________________________________
What should we reuse next time?
_____________________________________________________________________
_____________________________________________________________________
4. Shared mental model builder
Teams encounter valuable learning moments every day:
- debugging complex issues
- resolving incidents
- designing systems
- working with AI-generated solutions
But without deliberate extraction, these lessons remain isolated.
This exercise converts a specific team experience into a shared mental model.
In other words, a reusable principle that applies beyond a single situation.
Over time, these models become a powerful layer of collective intelligence.
You can use this template:
Situation:
_____________________________________________________________________
_____________________________________________________________________
Underlying mechanism:
_____________________________________________________________________
_____________________________________________________________________
Complete the sentence:
“In systems like this, ____________________________________________.”
Where else does this apply?
1. _______________________________________________________________
2. _______________________________________________________________
3. _______________________________________________________________
Now you have a reusable insight, not just a fix
Over time, this builds real team intuition.
Open discussion
I’m curious how others are handling this.
Most teams aren’t thinking about this yet. That’s why I think it’s worth discussing.
- Are you seeing similar patterns in your teams?
- Have you introduced any practices around AI usage at a team level?
- Or is it mostly individual-driven right now?
If you’re interested
I put together a full system with:
- exercises like the ones above
- workflow templates
- prompt cards for team reflection
You can get the guide for free here
I would love your feedback on this.
Final thought
AI is making it easier than ever to move fast.
But speed is not the same as understanding.
The teams that stand out won’t just be the ones using AI the most.
They’ll be the ones that learn the fastest and think most clearly together
Curious to hear how others are navigating this.
Top comments (16)
individual gains are obvious but team costs are subtle - that's what makes them dangerous to catch. in my experience the tell is whether teammates can still explain their decisions to each other, or just say 'AI suggested it.'
team knowledge sharing remains core I agree
yeah and the gap between "i know how this agent works" and "anyone on my team could debug it" is wider than most people track until someone goes on leave
It seems to me that you've really stumbled upon something profound here. The more we rely on AI, the more we risk losing sight of what makes us a team in the first place - our shared humanity. I love that he's proposing these practical exercises, like building a shared mental model, to keep our feet on the ground. It's such a simple yet vital reminder that AI is just a tool, not a replacement for the messy beauty of collaboration. Great Post Julien!
Thanks Aryan!
AI scales output. Teams still need to scale understanding.
100%
One very practical solution (that I also work on now) is to stop treating AI conversations as disposable personal artifacts of the team members.
Many useful things happen inside AI-assisted workflows. Let's say, developer investigates a rendering bug. AI suggests several possible causes - the engineer rejects some, verifies one, a workaround or real fix is found.
The entire logical chain disappears inside a private chat window.
That is lost team memory.
A possible solution is to collect selected AI-assisted work into a shared searchable store: PostgreSQL + pgvector, or a dedicated vector database.
The goal is not to store every token forever, but to preserve useful engineering context - for that the context should be analyzed and compress into a useful informational artifact:
Including links to the ticket, PR, annotated commits history, logs
Then the team can ask questions like:
This effectively turns AI output from private productivity pieces into a collective team memory.
I like that idea and framing. Thanks for sharing this.
the 'AI usage in PR template' practice is one of those things that sounds like overhead until you realize your team has been debug fixing AI code for months without anyone knowing where the shortcuts were taken.
we added a similar note to our internal reviews. the pattern that emerged: AI was being used most in the parts of the codebase nobody wanted to touch. the less understood the module, the more AI assistance, the more drift. circular.
the 'debugging without AI, narrated aloud' session is the one i'd actually steal. curious: do you record those, or is the value mostly in the live observation?
You can host a live session with your team and use it as a knowledge sharing session while collectively debugging. If you can record it that's even better, and get a transcript so you can use it as context for future tooling if beneficial.
This is really good. Just stopping to ask some of those critical questions makes you think more like an engineer.
Exactly. Are there particular critical questions that have helped you as an engineer?
Let's just say I've learned to question outputs in detail. :D I like your ideas though and will definitely give them some more consideration.
Having the PR template include a section on how AI was used is great. I'm gonna implement this with my team!
Happy this post inspired you Rasmus. Sounds great!
It's a little added friction but that can compound into very useful insights over time.