Manus et les agents AI changent le développement : le code d’un MVP apparaît désormais en 20 minutes

Les agents d'IA ont atteint cette partie du développement où les jours disparaissaient autrefois : démarrage du projet, intégration frontend-backend, architecture approximative et premier écran de démonstration fonctionnel. Dans un article sur Habr AI, l'auteur a testé ceci avec Manus et montré comment une idée de startup se transforme en code fonctionnel en environ 20 minutes.

Pourquoi le code s'est accéléré

La programmation s'est avérée être l'un des environnements les plus convenables pour les modèles génératifs. Les langages de programmation ont une syntaxe stricte, des modèles répétitifs et un format de résultat clair : soit le code compile et fait ce qui est nécessaire, soit il ne le fait pas. C'est pourquoi les LLM ont déjà pris en charge une grande part du travail routinier — de la recherche d'exemples et la rédaction de boilerplate aux requêtes SQL, aux index, à l'intégration API et aux corrections entre frontend et backend. Là où un développeur avait l'habitude de passer des heures sur la documentation, les forums et la fusion de fragments, le premier brouillon apparaît maintenant presque instantanément.

Mais un chatbot ordinaire atteint rapidement son plafond. Plus la tâche est complexe, plus il y a de copier-coller, de synchronisation manuelle et de lutte contre la perte de contexte. La même personne est forcée de réexpliquer constamment au modèle quels endpoints existent déjà sur le backend, comment le composant frontend est structuré et ce qui s'est exactement cassé après la dernière correction. En conséquence, il y a une accélération, mais elle se heurte à une gestion mécanique : vous n'écrivez plus tant du code que vous ne transférez du contexte entre les fenêtres et les messages.

Expérience avec Manus

Sur ce fond, l'auteur a pris Manus — un outil basé sur des agents qui ne fait pas que répondre dans le chat, mais décompose la tâche en une séquence d'actions et exécute de nombreuses étapes consécutives à travers le modèle. Au lieu de fragments dispersés, il devrait retourner un résultat plus cohérent : concept de produit, structure du projet, fichiers prêts à l'emploi et une démonstration fonctionnelle. Pour tester ceci, l'auteur lui a donné une idée de startup et lui a demandé d'assembler un MVP pratiquement à partir de zéro.

Selon sa description, la génération a pris environ 20 minutes et a coûté quelques centaines de roubles. Le résultat n'était pas seulement un ensemble de fichiers, mais un brouillon de produit tangible qui peut être téléchargé, ouvert dans un IDE, affiné et montré à d'autres. Ce qui était plus important pour l'auteur, c'est que l'agent a retourné non pas des fragments de logique, mais un cadre connecté avec lequel on peut travailler comme un MVP normal, plutôt que comme un tas de suggestions de chat.

• Concept MVP bien pensé sans feuille blanche
• Backend et frontend liés dans un système
• Version de démonstration sur laquelle vous pouvez cliquer immédiatement
• Capacité à poser des questions sur le code généré

"Ce n'est pas 100% fini — mais c'est opérationnel."

L'effet principal ici n'est pas la magie, mais la compression du temps. Ce qui prenait autrefois des jours d'assemblage initial, d'architecture de base et d'intégration manuelle, l'agent le compresse en une seule exécution longue. Pour un fondateur solo ou une petite équipe, cela réduit le prix d'entrée d'un MVP : il y a une chance de tester l'idée plus rapidement sans commencer à partir d'un référentiel vide et d'une liste interminable de petites tâches techniques. Cela change le rythme des premiers lancements et permet de montrer le concept aux partenaires, aux premiers utilisateurs ou aux investisseurs plus rapidement.

Où l'agent atteint ses limites

En même temps, l'auteur ne conclut pas que les développeurs ne sont plus nécessaires. Au contraire : plus un ingénieur ou un fondateur de startup est expérimenté, plus les limitations de cette approche sont évidentes. L'agent fonctionne bien pour remplir une page blanche, mais a du mal à sentir les priorités du produit, les compromis et les conséquences à long terme des décisions.

Il peut assembler une base fonctionnelle, mais ne comprend pas vraiment où établir un noyau solide, où couper les coins pour la vitesse et où la dette technique frappera plus tard tout le projet. Il y a aussi un second problème — l'illusion de productivité. Lorsqu'un outil génère l'interface, la partie serveur et la démo tout seul, il semble que le produit soit presque prêt.

Mais ensuite commence la phase la plus coûteuse : déchiffrer la logique d'un autre, examiner l'architecture, vérifier les goulots d'étranglement, la sécurité, la maintenance et le développement. Si une personne n'a pas contrôlé le système pendant l'assemblage, elle paiera plus tard — avec le temps passé à comprendre comment ce code fonctionne et ce qui cassera en premier.

Ce que cela signifie

Les agents d'IA comme Manus rendent déjà la création de brouillons de logiciels notablement moins chers et plus rapides, mais ce n'est toujours pas un remplacement pour les développeurs forts, mais un amplificateur pour ceux qui savent comment établir une tâche et prendre des décisions d'ingénierie. Le marché se déplace de la rédaction manuelle de code vers la capacité de formuler des exigences, de vérifier les résultats, de voir les risques architecturaux et de prendre la responsabilité du système après que l'effet "wow" initial de la génération s'estompe et que le travail d'ingénierie ordinaire commence.