DEV Community: 💻🎮

Managing AI in a Mixed Team

💻🎮 — Thu, 09 Jul 2026 17:13:18 +0000

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.

When should you really delete an app?

💻🎮 — Thu, 16 Oct 2025 06:47:26 +0000

React 16, Node 12, no TypeScript, a single CSS file with 1,500 lines... and of course no functional specs.

That's what our subscription application for TV devices looked like. The majority of the team decided it would be best to start over from scratch.

An application with constraints

Our application allows people to subscribe directly to services on their televisions, such as packages giving access to applications, without needing another device.
The main challenge with this type of device comes from technical constraints that are stricter than on the traditional web. Built-in browsers cannot be updated, which prevents the use of certain recent JavaScript, CSS, or HTML features.

So we are stuck with so-called “old” technologies more out of necessity than choice.

The code reflected these constraints:

React 16, therefore in the React class
No TypeScript
No React Router
CSS styling

For a developer accustomed to modern stacks, this was not at all appealing.

Restarting the project: challenges and constraints

When a new Product Owner took over the project, his first observation was that the application was “too outdated.”
The obvious solution, which was immediately proposed, was to start a new project. It seems easier to start over than to repair what already exists.

But there was a catch: despite numerous UX and architectural proposal meetings, we kept coming back to the same technical constraints.
What's more, the new project would have the same constraints as the old one, but with:

Several months of development
A complete qualification phase
Integration of the company's various teams (sales, support, etc.)
A risk of functional regression
Zero value delivered for the company during this time

One question kept running through my mind: What if we improved what we already had?

The more I compared the models for the new project with what we already had, the less I saw a revolution...
The real question that no one was asking at that moment was:
“Have we really tried to improve what we already have?”

Unfortunately, the answer was no. We had always focused on features, never on continuous improvement of the product.

I pushed this idea, and my superiors followed me.

The strategy: incremental improvement

Phase 1: Design and UX (1 sprint)

We started with what is visible, for example:

Redesign of the background image
Redesign of the buttons
Improvement of UX positioning

The result was already visible when it was presented to the sales team.

Phase 2: Continuous technical improvement (2-3 sprints)

We tackled technical debt in small steps:
Backend:

Migration from Node 12 to Node 22 (progressive, in several stages)
Refactoring of endpoints
Improvement of code structure

Frontend:

Creation of reusable components
Improvement of folder structure

Quality:

Systematic processing of the anomaly backlog
Correction of bugs that had been around for years
Improvement of stability

Phase 3: Measurable results

After several months of this approach:

Technical

Node 12 → 22: successful migration without regression
Reusable components created
Technical documentation

Quality

Bug backlog: reduced by approximately half
Pilot site testing: 0 anomalies reported

Business

Positive user feedback
Sales staff satisfied to see a product improving

Team

Motivation maintained (continuous delivery of value)
Increased skills in refactoring
Pride in seeing the product improve

Lessons learned

1. New things are always more appealing, but they come at a cost

Starting from scratch gives the illusion of building on a solid foundation. In reality:

We always underestimate the time required
We lose the business knowledge hidden in the code
We often repeat the same mistakes
We deliver no value for months

2. Legacy code isn't always bad

Our application was described as “legacy,” which should not be confused with “obsolete”:

It runs on React 16 - This isn't the most recent version, but it's still functional
It worked and had satisfied users
It contained proven business logic
It was stable in production

The real problem was that we never took the time to continuously improve the existing code; we just kept adding features.

3. Technical constraints do not magically disappear

Our main limitation (devices) still existed. Rewriting would not have changed that.

Sometimes the best option is to optimize according to constraints rather than believe in a world without constraints.

Conclusion: Think before starting from scratch

Yes, our application still does not meet the criteria of the latest recommendations for modern JS stacks.

Yes, there is still room for improvement.

But today it is:

More maintainable
More user-friendly
More reliable

And above all: we have delivered concrete improvements at the end of each sprint.

Sometimes, technical debt isn't in the code, but in the time we never devoted to it.

Cover image generated using AI

React Native : comment une simple mise à jour fait tout s'écrouler

💻🎮 — Sat, 16 Aug 2025 16:54:35 +0000

En tant que développeuse full-stack dans une entreprise qui jongle avec plusieurs produits, je travaille principalement sur des applications web. Le mobile n'est pas notre spécialité, et comme souvent, nous faisons les montées de version au dernier moment. C'est dans ce contexe que replonge dans les profondeurs de React Native.
Première appréhension, est ce que le projet rebuild ? Là, j'ai déjà une petite victoire, celui qui a déjà fait du mobile connaît cette joie de voir passer son npm run android et l'application se lance, mais tout ce n'est pas passé comme prévu.
Je souhaite partager avec vous les difficultés rencontrées pendant une semaine dans cet article.

Chronologie : une semaine mouvementée avec React native

Jour 1. La migration Android SDK - L'optimisme du début

Mission : passer d'Android SDK33 à 35 pour supporter Android 15
La première étape semblait simple sur le papier. J'ai attaqué méthodiquement :

Modification du android/build.gradle pour basculer compileSdkVersion et targetSdkVersion vers 35
Mise à jour buildToolsVersion vers "35.0.0"
Upgrade Android Gradle Plugin : 8.2.0 → 8.6.0 (première alerte rouge que j'aurais du voir venir)
Ajout de la propriété magique android.suppressUnsupportedCompileSdk=35 dans gradle.properties

verdict : Build Android réussi ! Je pensais naïvement que ce serait aussi simple que ça.

2. Jour 2 : le château de cartes des dépendances npm commence à vaciller

C'est là que la réalité m'a rattrapé. Les conflits de dépendances ont commencé leur danse infernale :

Voici un exemple d'un de mes nombreux problèmes de la journée :
React 18.2.0 ne voulait plus parler à react-intl@4.5.0 qui réclamait demande React ^16.3.0.

Ma descente aux enfers* :

Premier réflexe : le classique rm -rf node_modules suivi d'une réinstallation
Échec. Tentative avec npm install --legay-peer-deps pour forcer la roue
Miracle : 2266 packages installés ! (avec seulement 62 vulnérabilités comme cadeau bonus)

Jour 3 : Gradle, un vieil ennemi oublié

Au moment où je pensais avoir dompté npm, Gradle s'est rappelé à moi :

" Error resolving plugin [id : 'com.facebook.react.settings'] node_modules/@react-native/gradle-plugin' does not exist"

Le diagnostic : notre React Native 0.71.8 ne connaissant pas ce plugin qui n'existe qu'à partir de la version 0.72+.
A ce moment là j'ai même pensé recommencer l'application de zéro entre les soucis de dépendances et de build, j'étais à deux doigts de faire lancer un npx create-expo-app@latest

La méthodologie : réécriture complète du settings.gradle en remplaçant les références futuristes par la vielle méthode @react-native-community/cli-platform-android

Jour 4 : Jitsi - Le boss final

C'est ici que j'ai compris l'ampleur du désastre :
Oui, Jitsi (Logiciel de visioconférence open source gratuit pour le web et les appareils mobiles) sort des versions régulières, la dernière 11.4.0. Mais entre la théorie et la pratique, il y a un gouffre, faire tourner ces versions avec un projet React native qui a été initié il y a 5 ans.

" Could not resolve com.android.tolls.build:gradle:3.5.3"

La révélation : la version implémentée dans mon projet du SDK Jitsi vivait encore en 2019 avec Android Gradle Plugin 3.5.3, complètement incompatible avec notre stack moderne (SDK35+AGP 8.6.0).
Les repositories Maven refusaient même de répondre à des requêtes aussi lointaines...

L'espoir : du coup, j'ai installé la dernière version du SDK Jitsi et j'ai été heureuse, car un moment, j'avais même réussi à faire monter la version de React native en 0.77.3, mais là retour de la boucle infernale des dépendaces...

Issues :
Après de l'errance sur le web, je tombe sur l'issue qui disait https://github.com/jitsi/jitsi-meet/issues/14912 ne supportait pas les versions React natives supérieures à 0.73.

Jour 5 : les erreurs runtine

Après avoir réussi à compiler (petit miracle même si cela ne marchait pas !), l'application a décidé de me gratifier d'un magnifique :
"Failed to get room and jwt using code : 10208310 [Error: Request failed with status code 500]"
L'origine : une fonction appelée dans le front ne marchait plus, ce n’était même pas lié à la migration. Le backend avait ses propres problèmes...

Cette semaine m'a vraiment fait prendre conscience à quel point c'est compliqué de garder une application mobile à jour, surtout quand ce n'est pas notre cœur de métier. On pense naïvement qu'on va juste mettre à jour une petite dépendance, mais en fait, c'est toute une cascade de changements qui s'enchaîne...

Le plus dur, c'est qu'on touche à cette application de temps en temps seulement. Du coup, à chaque fois qu'on y revient, on se retrouve avec des mois de retard à rattraper d'un coup.

La prochaine fois qu'on me dira " on a juste besoin de mettre à jour le SDK pour publier", je saurai que c'est le début d'une nouvelle aventure, car avec React native il n'y a pas de petites mises à jour juste de grandes batailles... Où je poserai mes vacances à ce moment-là ...

Image de couverture générée à partir d'une IA