Brahim Bousnguar

Comment je travaille avec l'IA

Les agents écrivent le code. Je décide de ce qui part en production.

Mis à jour le

La boucle

Les agents IA écrivent aujourd'hui une bonne partie du code de mes propres projets. Chaque changement passe quand même par les mêmes cinq étapes, et la dernière, c'est toujours moi.

  1. D'abord une issue. Tout ce qu'un utilisateur pourrait remarquer commence par une issue GitHub : on sait pourquoi ça existe.
  2. Un agent le construit sur sa propre branche, souvent dans son propre worktree, pour ne pas écraser le travail en cours.
  3. Il prouve que ça marche. Build et tests, et pour tout ce qui se voit, des captures dans un vrai navigateur à 320 px et sur desktop.
  4. Un deuxième avis. Dans le pipeline qui tourne sans moi, un modèle d'un autre éditeur relit le changement avant l'ouverture de la pull request.
  5. Une pull request que je lis et que je merge. Elle ferme l'issue et porte sa propre entrée de changelog. Rien n'arrive sur main autrement.

Les outils que j'ai construits pour ça

  • Une CLI git maison qui rédige noms de branche, messages de commit et pull requests à partir du diff, avec un modèle local sur mon Mac mini ou un modèle cloud.
  • Des serveurs MCP pour que les agents travaillent sur des données réelles plutôt que sur des suppositions : mulewatch lit les logs MuleSoft, et mes propres applications exposent les leurs de la même façon.
  • Meterlex calcule ce que coûterait mon usage d'IA au tarif des API. C'est en le construisant que j'ai découvert que compter les tokens depuis les logs surestime de 2,5×.
  • Des modèles locaux sur un Mac mini M4 Pro avec 64 Go, pour ce qui ne doit pas quitter la machine.

Des règles nées de vraies erreurs

  • Vérifier ce que le modèle a produit, pas ce qu'il dit avoir fait. Un modèle de synthèse vocale a inventé des phrases dans l'audio de mes notes : chaque morceau est maintenant retranscrit avec Whisper et réenregistré s'il ajoute ou oublie un mot.
  • Une relecture vide n'est pas une validation. Les modèles relecteurs reviennent parfois sans rien. Le pipeline le dit dès la première ligne au lieu de déclarer le changement propre.
  • Les agents n'inventent pas de faits. Sur ce site, aucun chiffre, client ou expérience n'entre si je ne l'ai pas donné, et aucun nom de client, jamais.

Demandez à votre agent

Ce site est aussi un serveur MCP. Ajoutez https://api.heybrahim.com/mcp comme serveur MCP distant (Streamable HTTP, sans clé) dans Claude, Cursor ou tout client MCP : votre agent pourra lire mon profil, ma disponibilité, mes missions, projets et notes, ou y chercher.

Il est en lecture seule, avec une exception : il peut demander mon CV pour vous, exactement comme le formulaire. Je lis toujours chaque demande et j'envoie le CV moi-même.

Au travail

GitHub Copilot au quotidien (je suis certifié GH-300), plus Claude et Codex pour la relecture et la génération. Sur ma mission MuleSoft actuelle, j'ai d'abord construit un serveur MCP de lecture des logs pour le parc du client, puis publié une version sans rien du client : mulewatch.

Ce que j'apporterais à une équipe, c'est cette boucle : les agents tapent le code, la preuve avant la relecture, et un humain qui lit chaque merge. Ce que je fais en ce moment est sur /maintenant.

Contact

Écrivez-moi.

b.bousnguar@gmail.com

Intégration SAP Commerce Cloud, MuleSoft et Salesforce · Nantes · FR / EN