Today, everything revolves around AI and its performance. Me, I wanted to talk about something else: the life of a cross-functional team, and how to manage AI within a heterogeneous group, where no one shares the same approach or the same feelings about it.
Getting every discipline to work together is already a source of small conflicts: sprints, tickets, the friction between developers, POs, PMs… And lately, AI has amplified all of it even more. Between the companies pushing to adopt it, the articles promising to double your productivity, and the tech conferences where AI now shows up on every booth, the famous "just ask Claude to do it" is now circulating in every office. And it's fueling a kind of war: those who are against it and relay every failure they find online, the moderates who manage to keep some perspective, and the die-hard pro-AI crowd who swear by nothing else.
On the ground, in a real Merge Request
Let me give you a concrete example, because I'm living it right now. I'm currently building an application with OpenSpec and Claude, which I use daily on a real project, not as a simple experiment. In practice, everything plays out at code review time: when a developer proposes their changes through a Merge Request, the whole team can review it before approval. And that's where, on a real MR, the true limits start to appear: not in LinkedIn threads, but at the office.
The first thing that jumps out: MRs get bigger. It takes enormous concentration to review, and the generated tests follow a logic that isn't a human's: you don't read AI code the way you read a colleague's whose habits you know. As a result, the whole review flow has to be rethought. And the real questions, the ones we ask each other, go well beyond "for or against":
How do we make AI-generated code and hand-written code coexist? How do we make sure the blend holds together? Is code review as effective when the code comes from AI, or does the risk of error climb because we read it differently, maybe less carefully?
And that's when the debate within the team shifts to something concrete, and everyone shows up with their own answer. Should humans stop coding altogether and just steer the tool? Or, on the contrary, does the code remain the single source of truth, the thing we keep the day we unplug the tool, the thing we'll have to maintain, the thing we need to keep under control to avoid the silent accumulation of anti-patterns? On that question, we don't agree among ourselves. And that's normal: no one has the answer.
But something is taking shape all the same: value is shifting. It has left the writing of code to settle upstream, in design, and downstream, in review, integration, and the choice of what we keep or not. Deciding what to build, how to architect it, what makes sense for the product: that's what takes over when writing becomes delegable. On MRs, what we look at first is the code and the tests, because that's where we see what needs adjusting, that's where what actually runs in production is decided. The craft doesn't disappear, it slides elsewhere: today, what really matters is being able to read code with a critical eye and spot the subtle error, far more than writing fast.
And this shift feeds real discussions within the team, because everyone experiences it through their own lens. On the senior side, we wonder what becomes of years of expertise in the face of a tool that catches up in seconds to what we'd mastered. On the junior side, the worry is different but just as well-founded: the latest Stanford HAI AI Index finds that employment for developers aged 22 to 25 has dropped by nearly 20% since late 2022, while employment for more experienced developers grew. The routine implementation tasks, the ones we used to learn the craft through, are precisely the first to be automated.
Seen from this angle, the "for or against AI" debate loses its meaning. The real question becomes: who keeps their value, and who feels they're losing it? And no one has told us where we're supposed to stand now.
The referee with no rulebook
And in the middle of all this, there's someone we don't talk about enough: the lead, the manager. The one stuck between the two. From above, they're told "we need to adopt AI, show us the gains." From below, they have a divided team, with clashing sensibilities. And they're the one who has to arbitrate.
Except no one gave them the rules of the game. Do they impose it? Do they let it go and watch the fracture quietly settle into their team? Do they measure it? And if they measure, measure what, the number of lines generated per sprint? We can clearly see that makes no sense and ends in surveillance.
That's where, I think, the real subject lies. The same organizational conflict I described at the start plays out again here, but this time with a referee who has no rules. Because deep down, no one has yet written the manual for managing a team that's half-AI, half-human.
And in the end, maybe that's the real work ahead: learning to manage ourselves, before we even manage the tool.
Top comments (0)