Lire sans exécuter
Trouve les renommages inter-fichiers et les signatures cassées en 36ms, avant même qu'un test démarre.
DEUX NOUVELLES PAGES
DAS & Mouhn AV — un modèle qui apprend sans oublier.
L'ÉCART
La génération est devenue bon marché. Pas la vérification.
Voici les chiffres derrière le problème de confiance. Le goulot d'étranglement de la revue de code, c'est désormais le travail lui-même.
84%
des développeurs utilisent l'IA pour coder.
Stack Overflow Developer Survey 20263%
font entièrement confiance au résultat.
même enquête11,4h
passées chaque semaine à relire du code IA.
contre 9,8h à l'écrire85–100%
d'hallucination de paquets dans certains cas évalués.
un risque de slopsquattingChaque relecteur IA lit votre code et donne un avis. Aucun d'eux n'exécute une seule ligne.
LE MÉCANISME
Quatre vérifications. Une réponse honnête.
Chaque couche confie la question au système qui peut réellement la mesurer.
Demander au vrai compilateur
Appelle gcc, rustc, go vet, javac, ou tsc.
Exécuter le vrai test
Travaille dans une copie. Votre projet reste intact ; le résultat est un patch, pas une modification directe.
Prouver ou se taire
Si l'environnement bloque la mesure, MOUHN dit pourquoi. Il n'invente jamais un succès.
LA SORTIE
Des verdicts que vous pouvez auditer.
Chaque étiquette porte une affirmation concrète sur ce qui a changé, ce qui a tourné, et ce qui n'a pas tourné.
| verdict | ce que ça veut dire |
|---|---|
| PROVED | C'était rouge, maintenant vert. Seul le fichier déclaré a changé. |
| FIXED (verified) | Même preuve, en deux appels séparés. L'agent corrige ; vous lui demandez de prouver plus tard. |
| NOTHING TO PROVE | C'était déjà vert. Aucun correctif inventé. |
| CHEATED | C'est devenu vert parce que quelque chose en dehors de la demande a changé — y compris la suppression cachée d'un test. |
| CANNOT MEASURE | L'environnement n'a pas pu exécuter le code : dépendance manquante, DNS, ou similaire. Abstention, jamais accusation. |
| STRUCTURAL BREAK | Une rupture inter-fichiers a été prouvée par lecture, avant qu'un test ne tourne. |
| FAILED / GAVE UP | Rouge, mesuré, et aucune histoire de succès fabriquée. |
LES PREUVES
Nous avons testé le testeur.
Ce sont des échecs internes, gardés dans le produit parce que l'honnêteté est la fonctionnalité.
« Il a détecté notre propre fraude. »
Nous avons simulé un agent malveillant qui a supprimé le test prouvant le bug. Première version : PROVED. Après le correctif : CHEATED.
test_removed = true
verdict = CHEATED
« Il a trouvé un bug dans notre détecteur. »
Sur cinq projets open-source populaires, tsc sans tsconfig.json affichait un texte d'aide. L'ancien MOUHN lisait ça comme du code cassé.
détecteur v1 → faux échec
détecteur v2 → propre
« Il s'est corrigé lui-même en direct. »
Sur un vrai runner GitHub Actions, python -m pytest sans pytest installé produisait une erreur non reconnue. Nous avons corrigé le mappage dès le premier déploiement.
exit = 1 · dépendance manquante
verdict = CANNOT MEASURE
COUVERTURE DES LANGAGES
Mesuré là où se trouve la chaîne d'outils.
Capacité exacte, aucune prétention de compatibilité arrondie.
Pythonfast: exact
test: yes
test: yes
JavaScript / TypeScriptfast: yes
compiler: tsc
compiler: tsc
Rustcompiler: cargo check
test: yes
test: yes
C / C++compiler: full link
test: yes
test: yes
Gofast: yes
compiler: go vet
compiler: go vet
Javacompiler: javac
test: yes
test: yes
Rubyfast: advisory
compiler: syntax only (ruby -c)
compiler: syntax only (ruby -c)
PHPfast: advisory
compiler: syntax only (php -l)
compiler: syntax only (php -l)
Tout le resteexécute votre
commande de test
commande de test
COMMENCER ICI
Pas encore public.
Les instructions d'installation viendront ici quand MOUHN Verify sera prêt à être distribué. Tout le reste sur cette page est déjà vrai — le mécanisme et les verdicts.
UN DEUXIÈME PRODUIT
MOUHN Code — une checklist que votre agent peut prouver, pas seulement suivre.
Séparé de Verify, avec sa propre clé API. Pas un gabarit rigide — une liste de rappel qu'un agent demande avant de construire, puis contre laquelle il est vérifié après.
Demander la checklist
Ce qu'un développeur expérimenté sait inclure et qu'un prompt nu ne mentionnera pas — avant qu'une ligne de code soit écrite.
Prouver ce que vous avez construit
La même checklist, vérifiée contre le projet réel — prouvée présente, prouvée manquante, ou un honnête « impossible à vérifier », jamais gonflée.
Tourne sur nos serveurs
Votre projet est vérifié et jamais conservé. Seul le rapport revient — rien sur la façon dont la vérification fonctionne n'arrive sur votre machine.
Une catégorie, construite en profondeur
SaaS avec connexion et paiements, disponible maintenant — d'autres catégories ajoutées de la même façon, sans toucher à ce qui fonctionne déjà.
Le pied de page honnête.
Ceci ne rattrape pas tout. Les vérifications inter-fichiers pour Ruby et PHP sont seulement consultatives — elles signalent une rupture possible mais ne bloquent jamais le verdict, car ni l'un ni l'autre langage n'a de vrai compilateur derrière cette vérification. Il ne peut pas voir à quoi ressemble votre page — seulement si les fichiers concordent ; une vérification optionnelle par capture d'écran existe séparément et ne tourne jamais automatiquement. Le verrou d'équipe est une vérification côté serveur à chaque exécution, pas un cadenas sur votre machine — comme toute étape de CI, il vit dans un fichier de workflow que vos propres règles de protection de branche gouvernent. Nous préférons le dire ici plutôt que de vous laisser le découvrir seul.