[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fi4xuyfcdolhfrsB9UwvupMGtBGUWxLCx9T-Xi8XeBgg":3,"$f6hx9wRs7ANxEu1_T07-0E3qwlIh7A9NUCUR0osyJpNA":22},{"id":4,"slug":5,"titleFr":6,"titleEn":7,"titleKm":8,"contentFr":9,"contentEn":10,"contentKm":11,"excerptFr":12,"excerptEn":13,"excerptKm":14,"tags":15,"createdAt":21,"updatedAt":21},114,"claude-code-equipe-engineering","Comment j'ai intégré Claude Code dans mon équipe d'engineering","How I integrated Claude Code into my engineering team","របៀបដែលខ្ញុំបានរួមបញ្ចូល Claude Code ក្នុងក្រុមវិស្វកម្មរបស់ខ្ញុំ","## Introduction\n\nEn janvier 2026, au retour de mes vacances, j'ai découvert Claude Code. Quelques semaines plus tard, je commençais à l'intégrer dans le workflow de mon équipe de 5 personnes chez DJUST. On est encore au tout début de l'aventure — c'est frais, c'est récent, et les résultats ne sont pas encore spectaculaires.\n\nCe n'est pas un article promotionnel. C'est un retour d'expérience honnête — avec les premiers succès, les résistances humaines, les ajustements, et ce qu'on commence à comprendre — sur ce que ça implique concrètement de demander à une équipe d'engineering en production de changer ses habitudes pour intégrer un outil IA.\n\n---\n\n## Chapitre 1 : Le contexte — une équipe sous pression\n\n### DJUST en 2024\n\nDJUST est une plateforme e-commerce B2B SaaS. Mon périmètre en tant qu'Engineering Manager couvre l'Order Management System (OMS), les Payments et le Cart. C'est le cœur transactionnel de la plateforme — là où passent les commandes de clients enterprise dans la grande distribution, la construction et la mode.\n\nL'équipe :\n- 5 personnes : 2 développeurs seniors, 1 mid-level, 1 junior, et 1 QA senior\n- Stack : Java 17, Spring Boot, PostgreSQL, Elasticsearch, Kubernetes sur AWS\n- ~15 modules Maven interdépendants\n- Releases hebdomadaires le jeudi\n- SLA contractuels avec les clients enterprise\n\n### Le problème de productivité\n\nEn analysant où passait le temps de l'équipe, j'ai identifié un pattern récurrent :\n\n**30% du temps était consommé par des tâches répétitives à faible valeur ajoutée :**\n\n- **Code reviews** : 2-3 heures par jour pour moi en tant que lead technique. Chaque PR nécessitait une lecture attentive, des commentaires sur le style, la couverture de tests, les edge cases\n- **Tests boilerplate** : écrire des tests unitaires pour des CRUDs, des mappers, des DTOs — du code prévisible mais chronophage\n- **Briefings de déploiement** : chaque release nécessitait un document récapitulatif des changements, des risques, des rollback plans\n- **Analyse de bugs** : fouiller les logs, croiser les stacktraces avec le code, identifier le commit fautif\n- **Documentation** : mettre à jour les ADRs, les runbooks, les README après chaque changement d'architecture\n\nCes tâches ne sont pas inutiles — elles sont essentielles. Mais elles sont **prévisibles et structurées**, ce qui les rend parfaites pour l'automatisation par IA.\n\n## Chapitre 2 : La découverte de Claude Code\n\n### Le chemin avant Claude Code\n\nAvant d'arriver à Claude Code, j'ai exploré d'autres outils IA :\n\n**GitHub Copilot** (6 mois) — L'autocomplétion est utile, mais limitée : elle suggère du code ligne par ligne sans comprendre le contexte global du projet. Pour du boilerplate, c'est bien. Pour de l'architecture, c'est insuffisant.\n\n**Zencoder** — J'ai utilisé Zencoder pour m'aider à valider certaines tâches. C'était un bon intermédiaire entre le \"pas d'IA\" et le \"full AI-assisted\". Ça m'a montré le potentiel de l'IA pour les tâches de validation et de vérification, mais l'outil restait limité dans son intégration au workflow.\n\n**Google Gemini** — J'ai utilisé Gemini massivement pendant plusieurs mois pour mes recherches techniques. Pour comprendre un concept, explorer une librairie, comparer des approches architecturales — Gemini était mon moteur de recherche amélioré. Mais il restait cantonné au navigateur, déconnecté du code.\n\n### Pourquoi Claude Code a tout changé\n\nCe qui m'a convaincu avec Claude Code :\n\n1. **L'accès au codebase complet** : Claude Code voit tous les fichiers du projet, comprend l'architecture, les conventions, les patterns existants\n2. **Les skills personnalisés** : on peut créer des prompts réutilisables qui encapsulent le contexte métier\n3. **L'intégration MCP** : connexion native à Slack, Jira, GitLab, Notion — Claude peut lire un ticket Jira et proposer un plan d'implémentation\n4. **Le mode agentic** : Claude ne se contente pas de suggérer du code, il peut exécuter des commandes, lancer des tests, vérifier que ça compile\n\n### Le premier test : une code review automatisée\n\nMon premier skill Claude Code a été une code review automatisée. Le prompt :\n\n*\"Analyse cette PR GitLab. Vérifie : la couverture de tests, les conventions de nommage DJUST, les edge cases manquants, les problèmes de performance potentiels, la cohérence avec l'architecture hexagonale. Produis un rapport structuré avec des suggestions concrètes.\"*\n\nLe résultat m'a bluffé. Non seulement Claude identifiait des problèmes que j'aurais vus, mais il en trouvait certains que j'aurais manqués — notamment des race conditions subtiles dans du code asynchrone et des incohérences de nommage entre modules.\n\n## Chapitre 3 : L'écosystème de 25+ skills\n\n### Architecture des skills\n\nOn a organisé nos skills en 5 catégories :\n\n### 1. Code Quality (7 skills)\n\n- **review-pr** : analyse complète d'une PR avec scoring\n- **review-security** : audit de sécurité (OWASP top 10, injection, XSS)\n- **review-perf** : analyse de performance (N+1 queries, mémoire, complexité)\n- **check-conventions** : vérification des conventions DJUST (nommage, structure, patterns)\n- **suggest-refactor** : suggestions de refactoring avec justification\n- **check-api-contract** : vérification de la compatibilité backward des changements d'API\n- **check-migration** : validation des migrations DB (reversibilité, performance, locks)\n\n### 2. Testing & QA (7 skills)\n\nC'est la catégorie qui a le plus d'impact — et c'est notre QA senior qui en tire le plus de valeur. Avant Claude, elle passait des heures à rédiger des cas de test manuellement. Maintenant, elle utilise Claude pour générer une première matrice de tests qu'elle affine ensuite.\n\n- **generate-unit-tests** : génération de tests unitaires pour une classe\n- **generate-e2e-test** : génération de scénarios E2E à partir d'un ticket Jira\n- **generate-test-data** : création de fixtures réalistes\n- **analyze-test-coverage** : identification des chemins non testés\n- **generate-mutation-tests** : suggestions de tests de mutation\n- **generate-test-matrix** : génération d'une matrice de cas de test (nominal, edge cases, erreurs) à partir d'une spec — le skill préféré de notre QA\n- **explore-edge-cases** : Claude explore les combinaisons improbables qu'un humain ne penserait pas à tester (valeurs limites, concurrence, encodages exotiques)\n\n### 3. Deployment & Ops (5 skills)\n\n- **briefing-mep** : génération du briefing de mise en production\n- **analyze-incident** : analyse d'incident à partir des logs et metrics\n- **generate-rollback-plan** : plan de rollback pour une release\n- **check-deploy-readiness** : checklist de déploiement\n- **post-mortem** : template de post-mortem à partir d'un incident\n\n### 4. Documentation (4 skills)\n\n- **update-adr** : mise à jour d'un Architecture Decision Record\n- **generate-runbook** : création d'un runbook opérationnel\n- **document-api** : documentation OpenAPI à partir du code\n- **changelog** : génération du changelog à partir des commits\n\n### 5. Productivity (4+ skills)\n\n- **plan-implementation** : plan d'implémentation à partir d'un ticket\n- **estimate-complexity** : estimation de complexité d'un ticket\n- **daily-summary** : résumé quotidien de l'activité de l'équipe\n- **onboarding-guide** : guide d'onboarding contextualisé pour un nouveau développeur\n\n### Le MCP : le vrai game-changer\n\nCe qui rend ces skills vraiment puissants, c'est l'intégration MCP (Model Context Protocol). Claude se connecte directement à nos outils :\n\n- **GitLab** : lecture des PRs, des pipelines, des commits\n- **Jira** : lecture des tickets, des sprints, des epics\n- **Slack** : envoi de résumés, notifications d'incidents\n- **Notion** : mise à jour de la documentation\n\nConcrètement, quand un développeur finit une PR, il tape `/review-pr 1234` et Claude :\n1. Lit la PR sur GitLab\n2. Lit le ticket Jira associé\n3. Analyse le code par rapport aux conventions\n4. Poste un rapport de review structuré\n5. Notifie sur Slack si des problèmes critiques sont trouvés\n\nLe tout en 30 secondes au lieu de 45 minutes.\n\n## Chapitre 4 : Les premiers résultats (honnêtes)\n\n### Ce qu'on observe après quelques semaines\n\nSoyons clairs : on n'a pas encore 3 mois de recul. On est en février 2026, l'intégration a commencé en janvier. Les chiffres qu'on peut donner sont des **premières tendances**, pas des métriques consolidées.\n\nCe qu'on observe concrètement :\n\n| Tâche | Avant | Maintenant | Ressenti |\n|-------|-------|------------|----------|\n| Code review (première passe) | 45 min | ~20 min | Gain réel, Claude pré-mâche le travail |\n| Tests boilerplate | 2h/feature | ~1h | Gain variable selon la complexité |\n| Briefing MEP | 1h30 | ~30 min | Bon gain, le template est fiable |\n| Analyse de bug | Variable | Variable | Parfois bluffant, parfois à côté |\n\n### Ce qui marche vraiment\n\n- **Les code reviews assistées** : le gain est le plus clair. Claude détecte des choses que la fatigue cognitive nous fait rater\n- **La génération de tests** : pour les CRUDs et le boilerplate, c'est un vrai time-saver\n- **Les briefings de MEP** : le skill produit un document structuré en 30 secondes\n- **La QA** : c'est la surprise. Notre QA senior utilise Claude pour générer des matrices de tests à partir des specs Jira. Elle produit en 10 minutes ce qui prenait 2 heures. Et surtout, Claude trouve des edge cases auxquels personne n'aurait pensé — des combinaisons de données exotiques, des scénarios de concurrence, des cas limites sur les encodages. Elle dit que c'est \"comme avoir un junior QA infatigable qui pose des questions stupides brillantes\"\n\n### Ce qui ne marche pas encore\n\n- **L'analyse de bugs complexes** : Claude est bon sur les NPE évidentes, mais sur les bugs de logique métier, il tâtonne autant que nous\n- **La vélocité globale** : on ne peut pas honnêtement dire \"+40% de productivité\". C'est plus nuancé — certaines tâches sont 3x plus rapides, d'autres ne changent pas\n- **L'adoption n'est pas uniforme** : sur 5 personnes, les 2 seniors et moi l'utilisons quotidiennement, le mid-level commence à accrocher, le junior a été une vraie surprise — il a directement créé plein de skills et voulu tout automatiser, c'est un excellent élément qui mériterait d'aller plus haut, et la QA senior — ironiquement — est celle qui en tire le plus de valeur immédiate (génération de cas de test, exploration de scénarios edge case)\n\n### Le vrai impact : le temps libéré\n\nLe gain le plus concret n'est pas un pourcentage. C'est que **je passe moins de temps sur les reviews mécaniques et plus sur l'architecture et le mentoring**. Et ça, c'est précieux pour un Engineering Manager.\n\n## Chapitre 5 : Les résistances et les échecs\n\n### La résistance humaine\n\nPas tout le monde était enthousiaste au départ :\n\n**\"Ça va nous remplacer\"** — La crainte classique. J'ai dû expliquer que Claude ne remplace pas les développeurs, il remplace les tâches que les développeurs n'aiment pas faire. Un senior qui passe 3h par jour en code review n'est pas bien utilisé. Un senior qui passe 3h par jour en conception d'architecture, si.\n\n**\"Le code généré est médiocre\"** — Vrai au début. Les premiers skills produisaient du code générique. Il a fallu itérer sur les prompts, ajouter du contexte (conventions, exemples, patterns existants) pour obtenir un output utilisable. C'est un investissement de 2-3 semaines.\n\n**\"Je préfère le faire moi-même\"** — Le syndrome du \"not invented here\" appliqué à l'IA. Certains développeurs ont mis du temps à faire confiance aux reviews automatisées. La clé : montrer que Claude trouve des bugs que les humains manquent.\n\n### Les échecs\n\n**Skill \"auto-fix-bug\"** — On a essayé de créer un skill qui fixe automatiquement les bugs à partir des stacktraces. Ça marchait pour les bugs simples (NPE, type mismatch) mais échouait sur les bugs logiques complexes. On l'a transformé en \"analyze-bug\" qui propose des hypothèses plutôt que des fixes.\n\n**Sur-confiance initiale** — Les premières semaines, certains développeurs validaient les suggestions de Claude sans vérification. On a eu un incident mineur (un test E2E qui passait en CI mais cachait un faux positif). Ça nous a rappelé que l'IA est un outil, pas un oracle.\n\n**Coût des tokens** — La facture mensuelle est significative. On a dû optimiser les prompts et mettre en place des limites d'usage pour rester dans le budget.\n\n### Le paradoxe de l'IA pour les profils en formation\n\nC'est la question qui me travaille le plus en tant que manager. Mon junior et mon mid-level produisent plus de code, plus vite, avec moins de bugs. Sur le papier, c'est un succès. Mais en creusant, je me demande : **est-ce qu'ils apprennent autant ?**\n\nQuand j'étais junior, je passais des heures à debugger un NPE. C'était frustrant, mais c'est comme ça que j'ai compris en profondeur le cycle de vie des objets Java. Aujourd'hui, mon junior tape un prompt et Claude lui donne la solution en 30 secondes. Il livre plus vite, mais a-t-il vraiment compris pourquoi ça marchait pas ?\n\nMon mid-level utilise Claude pour écrire des tests qu'il n'aurait jamais écrits seul. Les tests sont bons. Mais est-ce qu'il a intériorisé les patterns de test, ou est-ce qu'il dépend de Claude pour ça ?\n\n**Je n'ai pas la réponse.** Ce que je fais en attendant :\n- Je demande au junior de m'**expliquer** le code que Claude a généré avant de le valider. Si tu ne peux pas l'expliquer, tu ne peux pas le committer\n- J'organise des sessions de **live coding sans IA** pour garder les fondamentaux\n- Je valorise la **compréhension** autant que la **livraison** dans mes évaluations\n\nC'est peut-être la question la plus importante de cette décennie pour les Engineering Managers : **comment former des développeurs solides dans un monde où l'IA écrit du code à leur place ?** Je n'ai pas de réponse définitive, mais j'y réfléchis chaque jour.\n\n## Chapitre 6 : Les leçons apprises\n\n### 1. Commencer petit, itérer vite\n\nNe lancez pas 25 skills d'un coup. On a commencé par un seul (review-pr), on l'a peaufiné pendant 2 semaines, puis on a ajouté les suivants un par un. Chaque skill nécessite du tuning spécifique au contexte de votre équipe.\n\n### 2. Le contexte est roi\n\nUn prompt générique produit un résultat générique. La qualité des skills dépend directement du contexte que vous leur donnez :\n- Les conventions de nommage de votre équipe\n- Des exemples de code existant\n- Les patterns architecturaux de votre projet\n- Les erreurs fréquentes à surveiller\n\n### 3. L'humain reste dans la boucle\n\nClaude ne remplace pas la review humaine, il la prépare. Le workflow optimal : Claude fait une première passe (conventions, tests, edge cases), le reviewer humain se concentre sur la logique métier et les choix d'architecture.\n\n### 4. Mesurer, mesurer, mesurer\n\nSans métriques, c'est de l'intuition. On a mis en place un dashboard simple qui track le temps passé par catégorie de tâche. C'est ce qui nous a permis de prouver le ROI et de justifier le budget.\n\n### 5. Former l'équipe au prompting\n\nL'IA est aussi bonne que le prompt qu'on lui donne. On a organisé des sessions de \"prompt engineering\" internes pour que chaque développeur sache tirer le meilleur de Claude.\n\n## Chapitre 7 : L'avenir — où va-t-on ?\n\n### Ce qu'on prépare\n\n- **Review automatique sur chaque PR** : Claude se déclenche automatiquement sur chaque merge request GitLab via un webhook\n- **Tests de non-régression intelligents** : Claude identifie quels tests doivent tourner en fonction des fichiers modifiés\n- **Assistant d'architecture** : un skill qui connaît l'historique des ADR et peut suggérer des décisions cohérentes avec le passé\n\n### Ma conviction (humble)\n\nOn est au tout début. C'est excitant et frustrant à la fois. L'IA n'est pas magique — elle ne transforme pas une équipe du jour au lendemain. Il faut investir du temps, convaincre, itérer, et accepter que certains collègues ne seront pas convaincus tout de suite.\n\nMais je suis convaincu que les équipes qui expérimentent maintenant, même imparfaitement, auront une longueur d'avance. Pas parce que l'IA remplace les développeurs, mais parce qu'elle **libère du temps pour le travail qui compte** : penser, concevoir, mentorer.\n\nC'est encore le début. On verra dans 6 mois si les promesses se confirment. En attendant, on continue à itérer — une skill à la fois.\n\n---\n\n*Chetana YIN — Février 2026*\n*Engineering Manager chez DJUST, 25+ skills Claude Code en production.*","## Introduction\n\nIn January 2026, right after coming back from vacation, I discovered Claude Code. A few weeks later, I started integrating it into my team's workflow of 5 people at DJUST. We're still at the very beginning of this journey — it's fresh, it's recent, and the results aren't spectacular yet.\n\nThis isn't a promotional article. It's an honest experience report — with early wins, human resistance, adjustments, and what we're starting to understand — about what it concretely means to ask an engineering team in production to change their habits and integrate an AI tool.\n\n---\n\n## Chapter 1: The Context — A Team Under Pressure\n\n### DJUST in 2024\n\nDJUST is a B2B SaaS e-commerce platform. My scope as Engineering Manager covers the Order Management System (OMS), Payments, and Cart. It's the transactional core of the platform — where orders flow for enterprise clients in food distribution, construction, and fashion.\n\nThe team:\n- 5 people: 2 senior developers, 1 mid-level, 1 junior, and 1 senior QA\n- Stack: Java 17, Spring Boot, PostgreSQL, Elasticsearch, Kubernetes on AWS\n- ~15 interdependent Maven modules\n- Weekly Thursday releases\n- Contractual SLAs with enterprise clients\n\n### The Productivity Problem\n\nAnalyzing where the team's time went, I identified a recurring pattern:\n\n**30% of time was consumed by low-value repetitive tasks:**\n\n- **Code reviews**: 2-3 hours per day for me as technical lead. Each PR required careful reading, comments on style, test coverage, edge cases\n- **Boilerplate tests**: writing unit tests for CRUDs, mappers, DTOs — predictable but time-consuming code\n- **Deployment briefings**: each release needed a summary document of changes, risks, rollback plans\n- **Bug analysis**: digging through logs, cross-referencing stacktraces with code, identifying the faulty commit\n- **Documentation**: updating ADRs, runbooks, READMEs after every architecture change\n\nThese tasks aren't useless — they're essential. But they're **predictable and structured**, making them perfect for AI automation.\n\n## Chapter 2: Discovering Claude Code\n\n### The Road Before Claude Code\n\nBefore arriving at Claude Code, I explored other AI tools:\n\n**GitHub Copilot** (6 months) — Autocompletion is useful but limited: it suggests code line by line without understanding the project's global context. For boilerplate, it's fine. For architecture, it's insufficient.\n\n**Zencoder** — I used Zencoder to help validate certain tasks. It was a good intermediate between \"no AI\" and \"full AI-assisted.\" It showed me AI's potential for validation and verification tasks, but the tool remained limited in its workflow integration.\n\n**Google Gemini** — I used Gemini extensively for several months for my technical research. To understand a concept, explore a library, compare architectural approaches — Gemini was my enhanced search engine. But it stayed confined to the browser, disconnected from the code.\n\n### Why Claude Code Changed Everything\n\nWhat convinced me about Claude Code:\n\n1. **Full codebase access**: Claude Code sees all project files, understands the architecture, conventions, and existing patterns\n2. **Custom skills**: you can create reusable prompts that encapsulate business context\n3. **MCP integration**: native connection to Slack, Jira, GitLab, Notion — Claude can read a Jira ticket and propose an implementation plan\n4. **Agentic mode**: Claude doesn't just suggest code, it can execute commands, run tests, verify compilation\n\n### The First Test: An Automated Code Review\n\nMy first Claude Code skill was an automated code review. The prompt:\n\n*\"Analyze this GitLab PR. Check: test coverage, DJUST naming conventions, missing edge cases, potential performance issues, consistency with hexagonal architecture. Produce a structured report with concrete suggestions.\"*\n\nThe result amazed me. Not only did Claude identify issues I would have seen, but it found some I would have missed — particularly subtle race conditions in asynchronous code and naming inconsistencies between modules.\n\n## Chapter 3: The 25+ Skills Ecosystem\n\n### Skills Architecture\n\nWe organized our skills into 5 categories:\n\n### 1. Code Quality (7 skills)\n\n- **review-pr**: comprehensive PR analysis with scoring\n- **review-security**: security audit (OWASP top 10, injection, XSS)\n- **review-perf**: performance analysis (N+1 queries, memory, complexity)\n- **check-conventions**: DJUST convention verification (naming, structure, patterns)\n- **suggest-refactor**: refactoring suggestions with justification\n- **check-api-contract**: backward compatibility verification for API changes\n- **check-migration**: DB migration validation (reversibility, performance, locks)\n\n### 2. Testing & QA (7 skills)\n\nThis is the category with the most impact — and it's our senior QA who gets the most value. Before Claude, she spent hours writing test cases manually. Now she uses Claude to generate a first test matrix that she refines.\n\n- **generate-unit-tests**: unit test generation for a class\n- **generate-e2e-test**: E2E scenario generation from a Jira ticket\n- **generate-test-data**: realistic fixture creation\n- **analyze-test-coverage**: identification of untested paths\n- **generate-mutation-tests**: mutation test suggestions\n- **generate-test-matrix**: test case matrix generation (nominal, edge cases, errors) from a spec — our QA's favorite skill\n- **explore-edge-cases**: Claude explores unlikely combinations a human wouldn't think to test (boundary values, concurrency, exotic encodings)\n\n### 3. Deployment & Ops (5 skills)\n\n- **briefing-mep**: production deployment briefing generation\n- **analyze-incident**: incident analysis from logs and metrics\n- **generate-rollback-plan**: rollback plan for a release\n- **check-deploy-readiness**: deployment checklist\n- **post-mortem**: post-mortem template from an incident\n\n### 4. Documentation (4 skills)\n\n- **update-adr**: Architecture Decision Record update\n- **generate-runbook**: operational runbook creation\n- **document-api**: OpenAPI documentation from code\n- **changelog**: changelog generation from commits\n\n### 5. Productivity (4+ skills)\n\n- **plan-implementation**: implementation plan from a ticket\n- **estimate-complexity**: ticket complexity estimation\n- **daily-summary**: daily summary of team activity\n- **onboarding-guide**: contextualized onboarding guide for new developers\n\n### MCP: The Real Game-Changer\n\nWhat makes these skills truly powerful is MCP (Model Context Protocol) integration. Claude connects directly to our tools:\n\n- **GitLab**: reading PRs, pipelines, commits\n- **Jira**: reading tickets, sprints, epics\n- **Slack**: sending summaries, incident notifications\n- **Notion**: updating documentation\n\nConcretely, when a developer finishes a PR, they type `/review-pr 1234` and Claude:\n1. Reads the PR on GitLab\n2. Reads the associated Jira ticket\n3. Analyzes the code against conventions\n4. Posts a structured review report\n5. Notifies on Slack if critical issues are found\n\nAll in 30 seconds instead of 45 minutes.\n\n## Chapter 4: Early Results (Honest)\n\n### What We're Seeing After a Few Weeks\n\nLet's be clear: we don't have 3 months of data yet. It's February 2026, integration started in January. The numbers we can share are **early trends**, not consolidated metrics.\n\nWhat we're concretely observing:\n\n| Task | Before | Now | Feeling |\n|------|--------|-----|---------|\n| Code review (first pass) | 45 min | ~20 min | Real gain, Claude pre-chews the work |\n| Boilerplate tests | 2h/feature | ~1h | Variable gain depending on complexity |\n| Deployment briefing | 1h30 | ~30 min | Good gain, template is reliable |\n| Bug analysis | Variable | Variable | Sometimes amazing, sometimes off |\n\n### What's Actually Working\n\n- **Assisted code reviews**: the clearest gain. Claude catches things that cognitive fatigue makes us miss\n- **Test generation**: for CRUDs and boilerplate, it's a real time-saver\n- **Deployment briefings**: the skill produces a structured document in 30 seconds\n- **QA**: this is the surprise. Our senior QA uses Claude to generate test matrices from Jira specs. She produces in 10 minutes what used to take 2 hours. And above all, Claude finds edge cases nobody would have thought of — exotic data combinations, concurrency scenarios, encoding boundary cases. She says it's \"like having a tireless junior QA who asks brilliantly stupid questions\"\n\n### What's Not Working Yet\n\n- **Complex bug analysis**: Claude is good on obvious NPEs, but on business logic bugs, it fumbles as much as we do\n- **Overall velocity**: we can't honestly claim \"+40% productivity.\" It's more nuanced — some tasks are 3x faster, others don't change\n- **Adoption isn't uniform**: out of 5 people, the 2 seniors and I use it daily, the mid-level is starting to get hooked, the junior was a real surprise — he immediately created tons of skills and wanted to automate everything, he's an excellent talent who deserves to go higher, and the senior QA — ironically — is the one getting the most immediate value (test case generation, edge case scenario exploration)\n\n### The Real Impact: Freed Time\n\nThe most concrete gain isn't a percentage. It's that **I spend less time on mechanical reviews and more on architecture and mentoring**. And that's invaluable for an Engineering Manager.\n\n## Chapter 5: Resistance and Failures\n\n### Human Resistance\n\nNot everyone was enthusiastic at first:\n\n**\"It will replace us\"** — The classic fear. I had to explain that Claude doesn't replace developers, it replaces tasks that developers don't enjoy doing. A senior spending 3h/day on code review isn't well utilized. A senior spending 3h/day on architecture design is.\n\n**\"Generated code is mediocre\"** — True at first. The initial skills produced generic code. We had to iterate on prompts, add context (conventions, examples, existing patterns) to get usable output. It's a 2-3 week investment.\n\n**\"I prefer doing it myself\"** — The \"not invented here\" syndrome applied to AI. Some developers took time to trust automated reviews. The key: showing that Claude finds bugs that humans miss.\n\n### Failures\n\n**\"auto-fix-bug\" skill** — We tried creating a skill that automatically fixes bugs from stacktraces. It worked for simple bugs (NPE, type mismatch) but failed on complex logic bugs. We transformed it into \"analyze-bug\" that proposes hypotheses rather than fixes.\n\n**Initial overconfidence** — In the first weeks, some developers validated Claude's suggestions without verification. We had a minor incident (an E2E test that passed in CI but hid a false positive). It reminded us that AI is a tool, not an oracle.\n\n**Token costs** — The monthly bill is significant. We had to optimize prompts and set usage limits to stay within budget.\n\n### The AI Paradox for Junior/Mid Developers\n\nThis is the question that weighs on me most as a manager. My junior and mid-level developers produce more code, faster, with fewer bugs. On paper, it's a success. But digging deeper, I wonder: **are they learning as much?**\n\nWhen I was a junior, I spent hours debugging an NPE. It was frustrating, but that's how I deeply understood Java object lifecycle. Today, my junior types a prompt and Claude gives him the solution in 30 seconds. He ships faster, but did he really understand why it wasn't working?\n\nMy mid-level uses Claude to write tests he would never have written alone. The tests are good. But has he internalized the testing patterns, or does he depend on Claude for that?\n\n**I don't have the answer.** What I'm doing in the meantime:\n- I ask the junior to **explain** the code Claude generated before validating it. If you can't explain it, you can't commit it\n- I organize **live coding sessions without AI** to keep fundamentals sharp\n- I value **understanding** as much as **delivery** in my evaluations\n\nThis might be the most important question of this decade for Engineering Managers: **how do you train solid developers in a world where AI writes code for them?** I don't have a definitive answer, but I think about it every day.\n\n## Chapter 6: Lessons Learned\n\n### 1. Start Small, Iterate Fast\n\nDon't launch 25 skills at once. We started with just one (review-pr), fine-tuned it for 2 weeks, then added others one by one. Each skill requires tuning specific to your team's context.\n\n### 2. Context Is King\n\nA generic prompt produces a generic result. Skill quality depends directly on the context you provide:\n- Your team's naming conventions\n- Examples of existing code\n- Your project's architectural patterns\n- Common errors to watch for\n\n### 3. Keep Humans in the Loop\n\nClaude doesn't replace human review, it prepares it. The optimal workflow: Claude does a first pass (conventions, tests, edge cases), the human reviewer focuses on business logic and architecture choices.\n\n### 4. Measure, Measure, Measure\n\nWithout metrics, it's intuition. We set up a simple dashboard tracking time spent per task category. That's what allowed us to prove ROI and justify the budget.\n\n### 5. Train the Team on Prompting\n\nAI is only as good as the prompt you give it. We organized internal \"prompt engineering\" sessions so every developer could get the best out of Claude.\n\n## Chapter 7: The Future — Where Are We Headed?\n\n### What We're Preparing\n\n- **Automatic review on every PR**: Claude triggers automatically on every GitLab merge request via webhook\n- **Intelligent regression testing**: Claude identifies which tests should run based on modified files\n- **Architecture assistant**: a skill that knows the ADR history and can suggest decisions consistent with the past\n\n### My Conviction (Humble)\n\nWe're at the very beginning. It's exciting and frustrating at the same time. AI isn't magic — it doesn't transform a team overnight. You need to invest time, convince people, iterate, and accept that some colleagues won't be convinced right away.\n\nBut I'm convinced that teams experimenting now, even imperfectly, will have a head start. Not because AI replaces developers, but because it **frees time for the work that matters**: thinking, designing, mentoring.\n\nIt's still early days. We'll see in 6 months if the promises hold up. In the meantime, we keep iterating — one skill at a time.\n\n---\n\n*Chetana YIN — February 2026*\n*Engineering Manager at DJUST, 25+ Claude Code skills in production.*","## សេចក្តីផ្តើម\n\nក្នុងខែមករា ២០២៦ បន្ទាប់ពីវិស្សមកាល ខ្ញុំបានរកឃើញ Claude Code។ ជាការចាប់ផ្តើមថ្មី ខ្ញុំកំពុងរួមបញ្ចូលវាក្នុង workflow របស់ក្រុម។ យើងស្ថិតនៅដំបូងនៃការផ្សងផ្រាសនេះ។\n\nនេះមិនមែនជាអត្ថបទផ្សព្វផ្សាយទេ។ វាជារបាយការណ៍បទពិសោធន៍ពិត — ជាមួយភាពជោគជ័យ ការបរាជ័យ ការប្រឆាំងរបស់មនុស្ស និងមេរៀនដែលបានរៀន — អំពីអ្វីដែលវាមានន័យជាក់ស្តែងក្នុងការរួមបញ្ចូលឧបករណ៍ AI ក្នុងក្រុមវិស្វកម្មដែលដំណើរការក្នុង production។\n\n---\n\n## ជំពូកទី ១៖ បរិបទ — ក្រុមក្រោមសម្ពាធ\n\n### DJUST ក្នុងឆ្នាំ ២០២៤\n\nDJUST គឺជាវេទិកា e-commerce B2B SaaS។ វិសាលភាពរបស់ខ្ញុំក្នុងនាមជា Engineering Manager គ្របដណ្តប់ Order Management System (OMS), Payments និង Cart។ វាជាស្នូលប្រតិបត្តិការរបស់វេទិកា — កន្លែងដែលការបញ្ជាទិញហូរសម្រាប់អតិថិជន enterprise ក្នុងការចែកចាយ ការសាងសង់ និងម៉ូដ។\n\nក្រុម៖\n- ៥ នាក់ (២ senior devs, ១ mid, ១ junior, ១ QA senior)\n- Stack៖ Java 17, Spring Boot, PostgreSQL, Elasticsearch, Kubernetes លើ AWS\n- ~១៥ Maven modules ដែលពឹងផ្អែកគ្នា\n- Releases រៀងរាល់ថ្ងៃព្រហស្បតិ៍\n- SLA កិច្ចសន្យាជាមួយអតិថិជន enterprise\n\n### បញ្ហាផលិតភាព\n\nដោយវិភាគកន្លែងដែលពេលវេលារបស់ក្រុមត្រូវបានចំណាយ ខ្ញុំបានកំណត់គំរូដដែលៗ៖\n\n**៣០% នៃពេលវេលាត្រូវបានប្រើប្រាស់ដោយកិច្ចការដដែលៗដែលមានតម្លៃទាប៖**\n\n- **Code reviews**៖ ២-៣ ម៉ោងក្នុងមួយថ្ងៃសម្រាប់ខ្ញុំក្នុងនាមជា lead technique។ PR នីមួយៗត្រូវការការអានដោយប្រុងប្រយ័ត្ន មតិយោបល់អំពី style ការគ្របដណ្តប់ tests edge cases\n- **Tests boilerplate**៖ ការសរសេរ unit tests សម្រាប់ CRUDs, mappers, DTOs — កូដដែលអាចព្យាករណ៍បានប៉ុន្តែចំណាយពេល\n- **Briefings deployment**៖ release នីមួយៗត្រូវការឯកសារសង្ខេបនៃការផ្លាស់ប្តូរ ហានិភ័យ rollback plans\n- **ការវិភាគ bugs**៖ ស្វែងរកក្នុង logs ផ្គូផ្គង stacktraces ជាមួយកូដ កំណត់ commit ដែលមានកំហុស\n- **ឯកសារ**៖ ធ្វើបច្ចុប្បន្នភាព ADRs, runbooks, READMEs បន្ទាប់ពីការផ្លាស់ប្តូរស្ថាបត្យកម្មនីមួយៗ\n\nកិច្ចការទាំងនេះមិនមែនគ្មានប្រយោជន៍ទេ — វាចាំបាច់។ ប៉ុន្តែវា **អាចព្យាករណ៍បាន និងមានរចនាសម្ព័ន្ធ** ដែលធ្វើឱ្យវាល្អឥតខ្ចោះសម្រាប់ស្វ័យប្រវត្តិកម្មដោយ AI។\n\n## ជំពូកទី ២៖ ការរកឃើញ Claude Code\n\n### ផ្លូវមុន Claude Code\n\nមុនពេលមកដល់ Claude Code ខ្ញុំបានស្វែងយល់ឧបករណ៍ AI ផ្សេងទៀត៖\n\n**GitHub Copilot** (៦ ខែ) — Autocompletion មានប្រយោជន៍ប៉ុន្តែមានកម្រិត។\n**Zencoder** — ខ្ញុំបានប្រើ Zencoder ដើម្បីជួយផ្ទៀងផ្ទាត់កិច្ចការមួយចំនួន។\n**Google Gemini** — ខ្ញុំបានប្រើ Gemini យ៉ាងច្រើនរយៈពេលជាច្រើនខែសម្រាប់ការស្រាវជ្រាវបច្ចេកទេស។\n\n### ហេតុអ្វី Claude Code បានផ្លាស់ប្តូរអ្វីៗទាំងអស់\n\nអ្វីដែលបានបញ្ចុះបញ្ចូលខ្ញុំអំពី Claude Code៖\n\n1. **ការចូលប្រើ codebase ពេញលេញ**៖ Claude Code ឃើញឯកសារគម្រោងទាំងអស់ យល់ស្ថាបត្យកម្ម conventions និង patterns ដែលមានស្រាប់\n2. **Skills ផ្ទាល់ខ្លួន**៖ អ្នកអាចបង្កើត prompts ដែលអាចប្រើឡើងវិញដែលរួមបញ្ចូលបរិបទអាជីវកម្ម\n3. **ការរួមបញ្ចូល MCP**៖ ការតភ្ជាប់ដើមទៅ Slack, Jira, GitLab, Notion\n4. **របៀប agentic**៖ Claude មិនត្រឹមតែស្នើកូដទេ វាអាចប្រតិបត្តិពាក្យបញ្ជា ដំណើរការ tests ផ្ទៀងផ្ទាត់ការ compile\n\n## ជំពូកទី ៣៖ ប្រព័ន្ធអេកូនៃ 25+ Skills\n\nយើងបានរៀបចំ skills របស់យើងជា ៥ ប្រភេទ៖\n\n### 1. Code Quality (៧ skills)\n- **review-pr**៖ ការវិភាគ PR ពេញលេញជាមួយការដាក់ពិន្ទុ\n- **review-security**៖ សវនកម្មសន្តិសុខ (OWASP top 10)\n- **review-perf**៖ ការវិភាគប្រតិបត្តិការ\n- **check-conventions**៖ ការផ្ទៀងផ្ទាត់ conventions DJUST\n- **suggest-refactor**៖ ការស្នើ refactoring ជាមួយការបកស្រាយ\n- **check-api-contract**៖ ការផ្ទៀងផ្ទាត់ភាពឆបគ្នាថយក្រោយ\n- **check-migration**៖ ការផ្ទៀងផ្ទាត់ migrations DB\n\n### 2. Testing (៥ skills)\n### 3. Deployment & Ops (៥ skills)\n### 4. Documentation (៤ skills)\n### 5. Productivity (៤+ skills)\n\n### MCP៖ Game-Changer ពិត\n\nអ្វីដែលធ្វើឱ្យ skills ទាំងនេះមានថាមពលពិតប្រាកដគឺការរួមបញ្ចូល MCP (Model Context Protocol)។ Claude ភ្ជាប់ដោយផ្ទាល់ទៅឧបករណ៍របស់យើង៖ GitLab, Jira, Slack, Notion។\n\n## ជំពូកទី ៤៖ លទ្ធផលដែលវាស់វែង\n\n| រង្វាស់ | មុន | ក្រោយ | ភាពខុសគ្នា |\n|---------|------|-------|------------|\n| ពេលវេលា code review មធ្យម | ៤៥ នាទី | ១៥ នាទី | -៦៧% |\n| ពេលវេលាសរសេរ tests | ២ម៉ោង/feature | ៤៥នាទី/feature | -៦៣% |\n| ពេលវេលា briefing deployment | ១ម៉ោង៣០ | ២០ នាទី | -៧៨% |\n| Bugs រកឃើញក្នុង review | ៣.២/PR | ៥.១/PR | +៥៩% |\n| Sprint velocity | ៤២ | ៥៨ | +៣៨% |\n\n### លេខសំខាន់៖ +៤០% ផលិតភាព\n\nលើ **កិច្ចការដដែលៗ** ជាពិសេស ផលិតភាពបានកើនឡើង ៤០%។\n\n## ជំពូកទី ៥៖ ការប្រឆាំង និងការបរាជ័យ\n\n**\"វានឹងជំនួសយើង\"** — ខ្ញុំត្រូវពន្យល់ថា Claude មិនជំនួសអ្នកអភិវឌ្ឍន៍ទេ វាជំនួសកិច្ចការដែលអ្នកអភិវឌ្ឍន៍មិនចូលចិត្តធ្វើ។\n\n**\"កូដដែលបង្កើតមានគុណភាពទាប\"** — ពិតនៅដំបូង។ យើងត្រូវធ្វើឡើងវិញលើ prompts បន្ថែមបរិបទ ដើម្បីទទួលបាន output ដែលអាចប្រើបាន។\n\n## ជំពូកទី ៦៖ មេរៀនដែលបានរៀន\n\n1. **ចាប់ផ្តើមតូច ធ្វើឡើងវិញលឿន** — កុំចាប់ផ្តើម 25 skills ក្នុងពេលតែមួយ\n2. **បរិបទជាស្តេច** — Prompt ទូទៅផលិតលទ្ធផលទូទៅ\n3. **រក្សាមនុស្សក្នុងរង្វង់** — Claude រៀបចំ review មនុស្សផ្តោតលើតក្កវិជ្ជាអាជីវកម្ម\n4. **វាស់ វាស់ វាស់** — គ្មាន metrics វាជាការស្មាន\n5. **បណ្តុះបណ្តាលក្រុមលើ prompting** — AI ល្អប៉ុណ្ណាក៏ដោយ prompt ដែលអ្នកផ្តល់\n\n## ជំពូកទី ៧៖ អនាគត\n\nយើងស្ថិតនៅដើមដំបូងនៃបដិវត្តន៍ AI ក្នុងវិស្វកម្ម។ ក្នុងរយៈពេល ២ ឆ្នាំ ការមិនប្រើ AI ក្នុង workflow អភិវឌ្ឍន៍របស់អ្នកនឹងហួorg សម័យដូចជាការមិនប្រើ linter។\n\nAI មិនមែនជារឿងលេងទេ។ វាជា **កម្លាំងពង្រីកជាក់ស្តែង**។ ហើយពេលវេលាល្អបំផុតដើម្បីរួមបញ្ចូលវាគឺឥឡូវនេះ។\n\n---\n\n*Chetana YIN — កុម្ភៈ ២០២៦*\n*Engineering Manager នៅ DJUST, 25+ Claude Code skills ក្នុង production។*","Retour d'expérience honnête sur l'intégration de Claude Code dans une équipe de 5 personnes : premiers résultats après quelques semaines, résistances humaines, et ce qu'on commence à comprendre.","Honest experience report on integrating Claude Code into a team of 5: early results after a few weeks, human resistance, and what we're starting to understand.","របាយការណ៍បទពិសោធន៍លើការរួមបញ្ចូល Claude Code ក្នុងក្រុម ៥ នាក់ (devs + QA)៖ 25+ skills ផ្ទាល់ខ្លួន +៤០% ផលិតភាព ការប្រឆាំង និងមេរៀនដែលបានរៀន។",[16,17,18,19,20],"AI","Claude Code","Management","Productivity","MCP","2025-12-26T19:00:00",[]]