Tout le monde pensait que les outils de codage IA comme Claude allaient booster les workflows de développement, en crachant des apps SvelteKit impeccables sur Cloudflare Workers en quelques minutes. TypeScript propre, zéro bug, déployer et oublier. Vrai ?
Faux. Complètement faux. Le code s’exécute. Il passe les checks de type. Mais il glisse de la pourriture : interpolation SQL brute qui invite aux attaques par injection, requêtes base de données qui explosent dans des map() de tableaux, gestion silencieuse des erreurs. Rapide ? Bien sûr. Fiable ? Pas même proche.
Ça renverse la donne. Backpressure — emprunté à l’hydraulique — bouche ces fuites de manière mécanique. Fini de supplier les LLM de « s’il vous plaît, utilisez safeParse ». Rendez-le impossible autrement.
Ce que le code IA cache vraiment (et pourquoi il passe en prod)
L’IA est rusée car elle imite du bon code. Vous avez vu ça : une fonction load qui parse l’entrée utilisateur avec .parse() au lieu de .safeParse(). Ou des mutations D1 lancées sans vérifier le résultat. Enfer async imbriqué là où une chaîne d’helpers nette aurait suffi.
Le code fonctionne. Il passe TypeScript.
C’est le piège. Les guidelines dans CLAUDE.md ? C’est une note polie sur une canalisation qui fuit. L’IA hoche la tête, puis ignore la moitié du temps. Obéissance non déterministe = qualité non déterministe.
Le truc : les humains repèrent ça avec un café et un squint. À l’échelle de dix repos ? Impossible. Place aux portes mécaniques.
Tout change. Les règles « toujours » et « jamais » migrent des docs vers des vannes de lint, types, tests. CLAUDE.md se réduit au pourquoi — l’intention derrière les règles de fer.
Pourquoi backpressure bat la supplication
Pensez tuyaux. Débordement ? Les panneaux disent « n’essayez pas ». Les vannes disent « essayez, sentez l’écrasement ».
Le logiciel, c’est pareil. Le linting n’est pas un conseil ; c’est de la physique. Oxlint frappe en 50 ms — rapide comme Rust, 200 règles JS/TS pour la santé de base.
ESLint avec parseur Svelte va plus profond, digérant les fichiers .svelte d’un bloc. Des règles custom traquent les gremlins :
no-raw-html : {@html} sans sanitizer. no-binding-leak : Fuite de platform.env depuis les loaders. no-schema-parse : .parse() au lieu de .safeParse() sur Zod. no-silent-catch : Catch vides.
Mais le lint s’arrête à la syntaxe. La structure, c’est là où l’IA patine le plus.
Comment ast-grep piège les péchés structurels
ast-grep ? Fin de partie pour les cauchemars imbriqués. Alimenté par Tree-sitter, règles YAML qui matchent les arbres de code de manière déclarative.
Prenez celle-ci :
id: n-plus-one-query-map language: TypeScript severity: warning message: >- Requête N+1 potentielle : appel base de données dans .map(). Utilisez db.batch() ou WHERE IN à la place. rule: pattern: $ARR.map($$$ARGS) has: pattern: $DB.prepare($$$SQL) stopBy: end
L’IA adore ça — ça semble net, ça s’effondre sur des datasets de prod. D1 sur Workers ? Requêtes séquentielles en boucle = timeout assuré.
L’arsenal complet :
sql-injection-d1 : SQL en template dans prepare(). n-plus-one-query-* : DB dans map/forEach/of. unbounded-query-all : .all() sans LIMIT. unchecked-db-run : .run() fire-and-forget. empty-catch-block : Erreurs fantômes.
Ces règles ont chopé des saletés IA qu’oxlint/ESLint avait loupées. Tout vert en TypeScript, tout toxique en prod.
Mon angle unique : ça rappelle les guerres TypeScript de 2015. À l’époque, les docs Flow suppliaient la strictesse ; TS l’a intégrée. L’ère IA exige pareil — contrats imposés plutôt que plaidoiries en prose. Les PR de Claude vantent « utile », mais sans backpressure, c’est de la dette hype. Prédiction : d’ici 2026, tout stack dev IA embarque des YAML ast-grep dès le départ, ou crève.
Rester à jour : L’audit « What’s New »
SvelteKit balance 50+ releases post-5.0. Cloudflare brasse Workers/D1 quotidiennement. L’IA traîne — formée sur les docs d’hier.
Script shell qui tire mon feed JSON patterns SvelteKit (signatures grep-ready) + RSS CF. Parse wrangler.jsonc pour les bindings, filtre les changelogs pertinents.
Scanne le code : « Repo X s’accroche aux stores writable() — $state depuis 5.29. »
Écarts ? Signalés. Feed auto-réparateur. Dix repos, dix secondes. Zéro taxe IA.
Un repo pour les gouverner tous
Règles/configs/workflows ? Centralisés en mono .github. sync-all.sh déploie partout. Zéro dérive sur dix.
Gains post-déploiement :
- Filtre de recherche ajouté par IA ? Injection SQL en template.
- Awaits « utiles » en boucle ? N+1.
- .all() dev (5 rows OK) ? Timeout prod 50k.
- Erreurs D1 ? Évaporées.
Expédié sans ça ? Cata.
Mais l’IA évolue encore. Backpressure gagne du temps, force indirectement de meilleurs prompts. C’est de l’architecture : qualité comme contrainte, pas checklist.
Sceptique ? Testez. Forkez un repo SvelteKit, prompt Claude pour une recherche D1. Regardez ast-grep s’allumer.
Pourquoi ça compte pour les devs SvelteKit ?
L’atout de SvelteKit — léger, natif Workers — amplifie la bouillie IA. Payloads minuscules masquent des trous de perf énormes. Backpressure scale votre cerveau sur les repos.
Pas du hype. Mécanique.
Backpressure, l’avenir du codage IA ?
Absolument. Les docs s’effacent ; les règles perdurent. L’IA accélère, empire en slop. Ce pattern se porte sur Next.js, Remix, partout où les LLM rôdent.
Le blabla corporate dit l’IA « prête pour la prod ». Balivernes. Sans vannes, c’est de la vélocité dev avec regrets prod.
🧬 Related Insights
- Read more: Europe’s Anti-US App Directory: Savior or Gimmick?
- Read more: Comp’s Tags: When Keywords Become Extensible Hierarchies
Frequently Asked Questions
What is backpressure in AI code generation?
C’est de l’hydraulique logicielle : règles de lint et checks qui bloquent net les mauvais patterns, transformant les suggestions IA en réalité imposée.
How do you set up ast-grep for SvelteKit?
Déposez les règles YAML dans .ast-grep/, ajoutez aux scripts package.json. S’accouple avec oxlint/ESLint pour une couverture totale des pièges Cloudflare D1.
Will backpressure slow down AI workflows?
Que nenni — lint ultra-rapide (50 ms), audits en secondes. Attrape les bugs shippables pré-merge, économisant des heures de pompiers en prod.
