DEV Community

Cover image for Don’t let AI break your collective thinking: a practical guide for engineering teams
Julien Avezou
Julien Avezou Subscriber

Posted on

Don’t let AI break your collective thinking: a practical guide for engineering teams

Individual speed vs collective drift

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?
_____________________________________________________________________
_____________________________________________________________________
Enter fullscreen mode Exit fullscreen mode

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?
_____________________________________________________________________
_____________________________________________________________________
Enter fullscreen mode Exit fullscreen mode

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?
_____________________________________________________________________
_____________________________________________________________________
Enter fullscreen mode Exit fullscreen mode

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. _______________________________________________________________
Enter fullscreen mode Exit fullscreen mode

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)

Collapse
 
itskondrat profile image
Mykola Kondratiuk

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.'

Collapse
 
javz profile image
Julien Avezou

team knowledge sharing remains core I agree

Collapse
 
itskondrat profile image
Mykola Kondratiuk

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

Collapse
 
itsugo profile image
Aryan Choudhary

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!

Collapse
 
javz profile image
Julien Avezou

Thanks Aryan!

Collapse
 
capestart profile image
CapeStart

AI scales output. Teams still need to scale understanding.

Collapse
 
javz profile image
Julien Avezou

100%

Collapse
 
atatatko profile image
Yurii Cherkasov • Edited

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:

  • Who worked on it?
  • When?
  • What system/component was involved?
  • What was the problem?
  • What hypotheses were explored?
  • What was verified manually?
  • What was the final solution?
  • What should the team remember?

Including links to the ticket, PR, annotated commits history, logs

Then the team can ask questions like:

Something was discussed in May about rendering flicker on Intel GPUs. Who worked on it, what was the cause, and how did we fix it?

This effectively turns AI output from private productivity pieces into a collective team memory.

Collapse
 
javz profile image
Julien Avezou

I like that idea and framing. Thanks for sharing this.

Collapse
 
mudassirworks profile image
Mudassir Khan

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?

Collapse
 
javz profile image
Julien Avezou

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.

Collapse
 
coridev profile image
Cor E

This is really good. Just stopping to ask some of those critical questions makes you think more like an engineer.

Collapse
 
javz profile image
Julien Avezou

Exactly. Are there particular critical questions that have helped you as an engineer?

Collapse
 
coridev profile image
Cor E

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.

Collapse
 
monom profile image
Rasmus Ros

Having the PR template include a section on how AI was used is great. I'm gonna implement this with my team!

Collapse
 
javz profile image
Julien Avezou

Happy this post inspired you Rasmus. Sounds great!
It's a little added friction but that can compound into very useful insights over time.