- Expérience consistant à construire un serveur web sans aucune logique applicative, où le LLM traite toutes les requêtes
- Le serveur se contente de recevoir une requête HTTP et de demander au LLM « que faut-il faire ? », puis le LLM prend entièrement le relais
- Le serveur n’utilise que trois outils, database, webResponse et updateMemory, pour assurer les fonctions CRUD
- Le LLM réalise lui-même la conception du schéma SQL, la génération de HTML et de JSON, ainsi que la prise en compte des retours, pour implémenter une application simple de gestion de contacts
- Le temps de réponse est de 30 à 60 secondes, le coût est 100 à 1000 fois plus élevé qu’une application web traditionnelle, et des problèmes de cohérence de l’interface et de mémoire persistent
- Malgré cela, l’expérience montre qu’il est possible d’implémenter une application CRUD complète sans code, ce qui suggère que le code lui-même pourrait n’être qu’un concept transitoire
Contexte
- Le projet est né d’une idée un peu fantaisiste (Shower Thought) : « un jour, nous n’aurons peut-être plus besoin d’écrire du code »
- À l’avenir, les LLM pourraient traiter des entrées en temps réel et produire de la vidéo à 120 fps, rendant possible une informatique purement fondée sur l’intention, sans applications ni code
- Dans la réalité, cela relève encore de la science-fiction, mais l’auteur a décidé de tester pendant un week-end jusqu’où la technologie actuelle permet d’aller
- L’hypothèse de départ partait du principe que l’expérience échouerait
- Alors que la plupart des IA se concentrent sur la génération de code (par exemple Claude Code, Cursor, Copilot, etc.),
le projet a été lancé pour vérifier une autre idée : « et si l’on supprimait complètement l’étape de génération de code ? »
- Le résultat est un serveur HTTP sans routes, sans contrôleurs et sans logique métier, qui fonctionne en demandant au LLM, pour chaque requête, « que faut-il faire ? »
- L’objectif de l’expérience est de montrer à quelle distance se trouve réellement cet avenir
Présentation du projet
- nokode est une expérience qui teste une architecture où un serveur web sans logique applicative confie tout le traitement des requêtes à un LLM
- Le serveur se contente de recevoir une requête HTTP et de demander au LLM « que faut-il faire ? », puis le LLM fait le reste
- Le but est de vérifier si un LLM peut exécuter directement la logique applicative sans passer par la génération de code
- Le cas d’usage choisi est une application de gestion de contacts (contact manager), avec les opérations CRUD de base (création, consultation, modification, suppression)
Architecture du système
- Le backend se compose de seulement trois outils
- database : exécution de SQL dans SQLite, avec un schéma conçu directement par le LLM
- webResponse : génération de réponses dans le bon format, comme HTML, JavaScript ou JSON
- updateMemory : enregistrement des retours utilisateur en Markdown pour pouvoir s’y référer lors des requêtes suivantes
- Par exemple, une requête vers
/contacts génère une page HTML, tandis qu’une requête vers /api/contacts produit une réponse JSON
- Chaque page inclut un widget de feedback, permettant d’appliquer immédiatement des demandes comme « agrandis les boutons » ou « passe en thème sombre »
Résultats de l’expérience
- Sur le plan fonctionnel, cela marche
- Soumission de formulaires, enregistrement des données, affichage de l’interface et réponses API fonctionnent correctement
- Même sans exemple, le LLM génère un schéma de base de données pertinent, du SQL sûr, une API de type REST, une mise en page responsive, la validation des formulaires et la gestion des erreurs
- Problèmes de performance
- Chaque requête prend 30 à 60 secondes, soit 300 à 6000 fois plus lentement qu’une application web classique (10 à 100 ms)
- Chaque requête coûte 0,01 à 0,05 $, soit 100 à 1000 fois plus cher
- Incohérences dans les couleurs et la mise en page de l’interface, incapacité à se souvenir de l’état précédent, et erreurs immédiates en cas de SQL incorrect
- Les tentatives d’optimisation du prompt, comme « ⚡ THINK QUICKLY », ont au contraire ralenti le système
Conclusion et implications
- Les LLM ont bien la capacité d’exécuter directement de la logique applicative
- Le vrai problème tient aux limites de vitesse, coût, cohérence et fiabilité
- Cependant, ces limites relèvent davantage d’améliorations quantitatives que de problèmes qualitatifs
- La vitesse d’inférence progresse d’environ 10× par an
- Les coûts sont orientés à la baisse
- L’allongement du contexte peut améliorer la mémoire
- Le taux d’erreur tend à diminuer
- En conséquence, l’ère où l’IA exécute directement pourrait être plus proche que l’ère où l’IA écrit simplement du code
- À ce stade, il ne reste plus que du code d’infrastructure, comme la configuration HTTP, la définition des outils ou la connexion à la base de données,
ce qui laisse entrevoir à long terme une transition vers une informatique où il n’existe plus que l’intention et l’exécution
Mode d’exécution
- Après
npm install, configurer le fournisseur LLM et la clé API dans le fichier .env
- Lancer
npm start, puis ouvrir http://localhost:3001 (la première requête prend 30 à 60 secondes)
- Il est possible de modifier
prompt.md pour changer le type d’application ou ses fonctionnalités
- On peut essayer différents chemins, comme
/game, /dashboard ou /api/stats
- Des retours comme « make this purple » ou « add a search box » sont appliqués immédiatement
- Le coût par requête varie entre 0,001 et 0,05 $ selon le modèle
- Publié sous licence MIT
2 commentaires
La question sera jusqu’où le computing peut devenir plus rapide et moins coûteux.
Dans un avenir où un serveur moyen serait 100 000 fois plus rapide qu’aujourd’hui, tout en conservant les mêmes coûts d’exploitation et d’installation, cela pourrait aussi être une bonne approche.
Comme le computing est devenu moins cher, on est passé du langage machine au C, puis du C à Node.js ou Python ; peut-être qu’à l’avenir, on passera aux LLM.
Beaucoup de choses vont changer, et cela devrait être assez intéressant. De nombreuses opportunités apparaîtront aussi.
Commentaires sur Hacker News
J’ai eu une réflexion similaire moi aussi
J’ai commencé à penser à cela quand ChatGPT 3.5 est apparu
Un jour, l’IA pourra peut-être remplacer complètement les programmes, mais le vrai point clé est de trouver la bonne abstraction (abstraction)
Par exemple, tout comme le passage de CVS à Git a ouvert l’ère des microservices, une bonne abstraction a le pouvoir de transformer un problème à la racine
Pour qu’un LLM découvre ce type d’abstraction par lui-même, il devra apprendre en interagissant longtemps avec le monde réel
Si on ajoutait aux LLM des outils leur permettant de modifier directement des fichiers de code, la vitesse de réponse et la cohérence s’amélioreraient fortement
Le code jouerait alors en quelque sorte le rôle de mémoire (memory)
Envoyer directement des requêtes HTTP à un LLM ressemble à un cache miss, et on pourrait aussi conserver un mécanisme de feedback qui déclenche des mises à jour du code
Il y a beaucoup de marge pour optimiser, mais en pratique l’approche de codage traditionnelle restera probablement plus efficace
Cela ressemble à la question : « si un comportement non déterministe (non-deterministic) est possible, pourquoi faudrait-il absolument être déterministe ? »
Mais la plupart des gens ne voudront sans doute pas d’une webapp qui fonctionne différemment à chaque fois
Le code déterministe a ses limites face à des problèmes complexes, et une approche plus souple, plus proche de l’humain, peut être mieux adaptée
Mais à l’avenir, ils disposeront probablement de capacités bien plus riches en sortie et en stockage
Par exemple, un LLM pourrait générer lui-même des liens, puis lorsqu’on clique dessus relancer une requête en interne, ou encore gérer une base de données temporaire
Mises à jour automatiques, tests A/B, changements d’UX : l’expérience utilisateur évolue en permanence
Fait intéressant, cette approche fonctionne uniquement avec la fenêtre de contexte, sans outil supplémentaire
J’en ai fait un POC en juillet 2025
Cette expérience montre bien comment la notion de code boilerplate pourrait évoluer
Si l’on exécute plusieurs instances en parallèle dans des sandboxes et que l’on fournit le meilleur résultat selon une évaluation interne, cela devient une forme de méta-apprentissage par renforcement (meta reinforcement learning)
Le problème, c’est qu’il est difficile de traduire l’intention de l’utilisateur en sortie déterministe, tandis que les apps traditionnelles manquent de flexibilité
Au final, tout l’enjeu est de savoir comment implémenter de manière fiable l’évaluation de l’intention (intent evaluation)
Concevoir une bonne méthode d’évaluation est en soi presque aussi complexe que de construire un modèle d’IA
Traiter une requête de manière traditionnelle est bien plus rentable que d’utiliser directement un LLM
En gros, générer 10 tokens avec un modèle de 7 milliards de paramètres demande plus de 100 GFLOPs
C’est un énorme gaspillage d’énergie
Quand on travaille dans l’IT d’entreprise, on voit bien que l’inefficacité humaine n’est pas négligeable non plus
Dans la pratique, même l’inefficacité peut devenir une tendance
On pourrait peut-être simplement mettre un LLM sur le port 443 et lui dire : « tu es à la fois le serveur HTTPS et le serveur applicatif » ;)
A-t-on vraiment besoin de webapps ? Pourquoi ne pas simplement parler à son ordinateur à la voix ?
« Montre-moi les photos prises pendant mes vacances l’an dernier, efface les nuages, puis envoie-les à mon ami »
« Régle-moi un minuteur d’entraînement, mais enlève les jumping jacks »
« Compose-moi un beat techno style Detroit »
« Trouve-moi un date pour ce soir, je préfère les cheveux noirs »
J’imagine un monde où tout se ferait ainsi, à la parole
Au final, l’humanité pourrait se diviser entre ceux qui l’acceptent et ceux qui la refusent
On en voit déjà des signes avec des phénomènes comme le retour du vinyle
Même entre humains, on préfère souvent le texte
Elle gère mes tâches, mes courses et mon planning, le tout entièrement personnalisé selon mes besoins
Les tâches complexes peuvent très bien être exprimées à la voix, mais pour les tâches simples et répétitives, une UI reste plus efficace
Par exemple, si l’on dit « achète-moi un pantalon » et qu’il faut choisir parmi 30 résultats, une interface visuelle redevient indispensable
J’ai moi aussi mis un PoC similaire sur GitHub
Au début, j’utilise un « modèle de design » lent pour créer le thème de l’app et le schéma de base de données, puis un modèle plus rapide pour gérer les réponses
J’ai essayé de mettre la logique dans la base avec PostREST, mais les échecs de génération de schéma et les requêtes incorrectes étaient fréquents
J’ai utilisé une bibliothèque CSS pour maintenir la cohérence de l’UI, et j’ai fait en sorte que le système se souvienne de la page précédente
Ce type d’approche pourrait servir d’App Bench pour évaluer si un LLM peut créer une application complète en une seule fois