Une carte du flux et des responsabilités
Définissez le dépôt ou la partie de la livraison, les critères d’acceptation, les responsables des tâches et les décisions réservées aux personnes.
AI Engineering
Donnez aux agents de programmation IA un flux de travail que votre équipe peut maîtriser.
Reliez les agents de programmation au contexte du projet, à des tâches définies et aux vérifications de livraison. Nous aidons votre équipe d’ingénierie à mettre en place un flux qu’elle peut exploiter et améliorer.
Évaluez ensemble le délai de livraison, la qualité et les coûts d’exploitation. Votre équipe garde la responsabilité de l’architecture et des décisions de mise en production.
Fondé sur notre pratique interne du harness et de Devbus. La mise en œuvre pour chaque client a son propre périmètre convenu.
Écrivez-nous en précisant vos outils actuels et un problème de livraison logicielle à résoudre.
Rendez explicite le travail autour de chaque agent.
Une modification peut concerner un dépôt, plusieurs agents et une chaîne de mise en production. Chaque agent a besoin d’un contexte pertinent, d’actions autorisées et d’une tâche claire. Votre équipe doit savoir ce qui a changé, ce qui a été vérifié et ce qui reste à résoudre.
Nous aidons les CTO et les responsables d’ingénierie à transformer cette coordination en un flux opérationnel. Partez d’un problème de livraison, puis convenez des éléments qui permettront d’évaluer l’utilité du changement.
- Les agents ont régulièrement besoin du même contexte projet ou perdent des décisions entre les tâches.
- L’implémentation avance alors que la revue, la responsabilité des tests ou les transmissions de travail restent mal définies.
- Votre équipe a besoin d’une méthode contrôlée pour évaluer les agents de programmation par rapport à son processus de livraison actuel.
Un harness relie les agents au processus d’ingénierie.
Un harness pour agents de programmation est la structure de travail qui entoure un agent. Il relie les consignes du projet, les limites des tâches et l’accès aux outils aux tests, aux transmissions enregistrées et aux décisions d’acceptation.
L’agent implémente une modification définie. Le harness rend ses responsabilités, résultats et éléments de revue accessibles aux personnes qui exploitent le processus.
Définissez une mise en œuvre que votre équipe peut utiliser.
Nous évaluons le flux actuel lorsque des contraintes importantes restent à clarifier. Si la tâche et les critères d’acceptation sont déjà clairs, le périmètre de mise en œuvre peut être convenu directement.
Le travail convenu peut comprendre :
Un flux configuré avec des agents de programmation
Reliez le contexte du projet et les consignes des tâches aux outils autorisés, aux limites de travail et aux transmissions enregistrées pour le périmètre choisi.
Des éléments de test et de revue
Reliez les vérifications automatisées et les étapes de CI pertinentes. Définissez la revue indépendante, le traitement des échecs et les éléments nécessaires à l’acceptation.
Un transfert opérationnel
Documentez comment votre équipe lance le travail, examine les résultats, traite les échecs et modifie le flux. Convenez de la responsabilité de la maintenance et des coûts des modèles.
Le périmètre précise les intégrations, les livrables et les éléments d’acceptation. Une évaluation, une expérimentation d’adoption et un flux implémenté ont chacun des résultats distincts.
Suivez une modification de la tâche à la mise en production.
Le flux est adapté à votre dépôt et à votre équipe. Une séquence représentative rend les limites concrètes.
- 01
Convenir de la tâche
Consignez la modification prévue, les contraintes et les critères d’acceptation avant le début de l’implémentation.
- 02
Définir le contexte et les permissions
Donnez à l’agent les informations pertinentes du projet et des limites explicites pour l’accès aux outils et au dépôt.
- 03
Implémenter et transmettre
L’agent de programmation réalise sa tâche et consigne le résultat, les vérifications effectuées et les questions non résolues.
- 04
Exécuter les vérifications
Les tests automatisés unitaires, d’intégration et de régression couvrent le comportement retenu pour la modification. Les échecs retournent dans la file de travail.
- 05
Effectuer une revue indépendante
Un relecteur distinct de la personne ou de l’agent chargé de l’implémentation examine la modification et ses éléments de vérification. Les constats importants conduisent à une correction et à une nouvelle vérification.
- 06
Décider de la mise en production
La personne responsable examine les éléments d’acceptation et décide de la mise en production. Les agents peuvent exécuter les étapes de déploiement dans un flux explicitement approuvé.
Les tests et la revue indépendante éclairent l’acceptation. Les personnes restent responsables de la mise en production et de ses conséquences opérationnelles.
Choisissez les outils et les modèles pour la charge réelle.
Nous examinons vos outils actuels avant de proposer des changements. Les décisions concernant les modèles et l’hébergement dépendent de la tâche, des exigences de traitement des données et des limites d’intégration.
Claude Code, Codex et Qwen Code sont des exemples d’outils de programmation que nous évaluons pour le projet. Selon les besoins, vLLM peut servir les modèles et LiteLLM peut relier les fournisseurs de modèles via une passerelle. Le choix dépend de la charge de travail, des besoins d’intégration et des contraintes opérationnelles.
Comparez les services hébergés et les solutions autogérées sur des tâches représentatives. Intégrez à l’évaluation la qualité des résultats, les besoins de contexte, la capacité, l’effort d’exploitation et le coût total.
Notre pratique interne de service de modèles constitue un exemple distinct de configuration de matériel dédié à des charges spécifiques. Elle éclaire l’évaluation ; vos exigences déterminent la configuration proposée.
Pratique interne d’ingénierie
Notre pratique interne rend l’approche concrète.
Devmojos est un studio de développement logiciel basé à Lisbonne, au Portugal.
Dans notre méthode de livraison, des agents opérateurs organisent un travail délimité et coordonnent les agents de programmation. Devbus relie des agents identifiés et enregistre la communication et l’état de la livraison. Le responsable humain garde la responsabilité de l’architecture et de la mise en production.
L’illustration et la démonstration publiques du harness utilisent des données fictives. Elles expliquent la méthode ; elles ne présentent ni résultats clients ni vue en direct de leur travail.
Four-Eyes Delivery est une recherche distincte menée de mai à septembre 2026. Elle se distingue de la pratique actuelle du harness et de Devbus.
Le travail commercial adapte l’approche pertinente aux dépôts, aux responsabilités et aux contraintes de votre équipe. L’intégration, l’acceptation et l’accompagnement continu sont convenus pour cette intervention.
Évaluez la modification à partir d’éléments de livraison.
Convenez d’une référence initiale et de mesures utiles avant d’étendre le flux. Elles peuvent porter sur l’effort de revue, les reprises, le délai de livraison et le coût des modèles ou de l’infrastructure.
Utilisez ces éléments pour décider quoi conserver, ajuster ou arrêter. Les résultats dépendent du code, des tâches choisies, des outils et du processus opérationnel.
Ce travail fait partie de l’offre AI Engineering de Devmojos. Nous développons aussi des logiciels et des flux métier intelligents, en reliant architecture, implémentation et amélioration continue aux objectifs de l’entreprise.
Commencez par un problème de livraison en ingénierie.
Dites-nous ce que votre équipe veut changer, les outils qu’elle utilise et la principale contrainte de livraison. Nous pouvons discuter d’une évaluation ciblée ou d’un périmètre de mise en œuvre.
Convenez du premier livrable et des éléments d’acceptation avant d’étendre le travail. L’exploitation continue et les changements ultérieurs ont leur propre périmètre et leurs propres conditions commerciales.
Questions fréquentes
Pouvons-nous conserver nos outils de programmation actuels ?
Nous partons de vos outils, dépôts et processus de livraison actuels. Nous proposons des changements d’outils lorsque le travail convenu et son évaluation les justifient.
Comment les permissions et les informations du projet sont-elles traitées ?
Le périmètre définit le contexte reçu par un agent et les actions qu’il peut effectuer. Les limites d’accès, le traitement des données et les exigences d’hébergement des modèles orientent l’implémentation.
S’agit-il d’un produit prêt à installer ?
Il s’agit d’un service d’ingénierie au périmètre défini, fondé sur notre pratique interne. Nous convenons du flux, des intégrations et du transfert opérationnel à votre équipe avant la mise en œuvre.
Qui décide de la mise en production d’une modification ?
La personne responsable de l’exploitation examine les éléments d’acceptation et prend la décision de mise en production. Les agents peuvent effectuer les étapes de déploiement approuvées dans le cadre de cette décision.
Parlons du flux dont votre équipe a besoin.
Écrivez à info@devmojos.com en précisant un problème de livraison, vos outils de programmation actuels et les contraintes opérationnelles importantes. Nous discuterons de l’adéquation et du prochain périmètre utile.
Écrivez-nous en précisant vos outils actuels et un problème de livraison logicielle à résoudre.