Ce que dit la source

Les agents de codage actuels sont opaques sur ce qu'ils envoient au modèle, coûteux à opérer à l'échelle d'une équipe, et difficiles à intégrer dans des environnements d'entreprise (sandboxing, permissions, reproductibilité). L'article défend l'idée qu'il reste de la place pour un harness pensé pour l'exécution fiable plutôt que pour la démo.

• >Le modèle n'est plus le différenciateur : les écarts entre frontier models se resserrent, l'exécution autour du modèle devient le terrain de jeu.
• >Le harness (boucle d'outils, compaction du contexte, gestion des erreurs, reprise après échec) explique une grosse part de la qualité perçue d'un agent.
• >Argument central : les agents actuels sont conçus pour impressionner en démo, pas pour tourner sans surveillance sur des bases de code réelles.
• >Isolation et permissions sont traitées comme des fonctionnalités de premier ordre, pas comme un pansement : condition d'adoption en entreprise.
• >Position assumée de l'auteur : construire quand même, en pariant que la commoditisation des modèles profite aux couches au-dessus.

• >« Un wrapper de plus » : plusieurs commentateurs estiment que tout le secteur réimplémente la même boucle agentique et qu'aucun moat n'existe à ce niveau.
• >Le risque d'être écrasé par les labos revient sans cesse : chaque feature d'un harness tiers finit intégrée dans Claude Code ou Codex à la release suivante.
• >Doutes sur la viabilité économique : marges écrasées par le coût des tokens, valeur captée par le fournisseur de modèle, pas par l'outil.
• >Une partie du fil considère que le vrai problème n'est pas l'agent mais la revue du code généré, et qu'aucun harness ne résout ça.
• >Les habitués des CLI existants ne voient pas de raison objective de migrer : coût de changement réel, gain marginal.

Alternatives citées : Claude Code, OpenAI Codex CLI, Cursor, Aider, Cline, OpenCode, Amp

Ce que dit la source

Le plafond de verre de React Native chez un acteur à très grande échelle : friction permanente avec les API natives et les nouveautés OS, coûts de migration imposés par la roadmap de Meta (New Architecture), performance et qualité perçue sur les parcours critiques, et dépendance à une couche d'abstraction que l'on ne contrôle pas.

• >Retournement symbolique : Shopify était la vitrine entreprise de React Native depuis 2020, avec une équipe dédiée et un sponsoring visible de l'écosystème. Le signal envoyé dépasse le cas Shopify.
• >La thèse de l'article : le gain principal du cross-platform était l'économie de duplication de code. Avec des LLM capables de porter une feature Swift vers Kotlin, cet arbitrage économique s'inverse.
• >Le coût caché de l'abstraction : chaque nouveauté iOS/Android arrive avec un délai, chaque bridge natif est du code custom à maintenir, et les migrations majeures du framework sont subies, pas choisies.
• >La performance et le "feeling natif" restent le talon d'Achille sur les écrans complexes, malgré des années d'optimisation interne.
• >Le vrai coût d'une app mobile n'est pas la ligne de code : c'est le design, le produit, la QA sur deux plateformes et les releases. Ce poste-là ne disparaît pas avec le natif.
• >À l'échelle de Shopify, financer deux équipes natives est soutenable. Pour une DSI avec trois développeurs mobiles, l'équation reste inchangée.

• >Beaucoup lisent la justification par l'IA comme un habillage narratif : la vraie raison serait que React Native n'a jamais tenu ses promesses à cette échelle, et "grâce à l'IA" sonne mieux en communication corporate que "on s'est trompés".
• >Duplication assistée par LLM = dette technique dupliquée. Plusieurs commentateurs pointent que deux implémentations générées divergent inévitablement, produisant des bugs asymétriques iOS/Android impossibles à tracer.
• >Le coup porté à l'écosystème React Native : Shopify était un contributeur majeur. Départ d'un sponsor de ce poids, effet domino redouté sur les bibliothèques communautaires.
• >Le coût humain du zigzag : les équipes qui ont passé cinq ans à devenir expertes RN doivent réapprendre SwiftUI et Compose. Le "technology bet" à 5 ans a un prix, rarement chiffré dans les billets d'ingénierie.
• >Argument de survivorship bias : on ne compte que les migrations spectaculaires vers le natif, jamais les milliers d'apps RN qui tournent très bien et dont personne ne blogue.
• >Certains rappellent qu'Airbnb avait tiré les mêmes conclusions en 2018, avec des raisons quasi identiques — l'industrie n'aurait donc rien appris en sept ans.

Alternatives citées : Flutter (souvent cité, mais les inquiétudes sur l'engagement long terme de Google reviennent systématiquement), Kotlin Multiplatform et Compose Multiplatform (l'option la plus défendue : logique métier partagée, UI native), Expo (jugé nettement supérieur au RN "brut" et rarement mentionné dans l'article), un cœur partagé en Rust ou C++ avec UI native (approche Dropbox/Signal), Capacitor/Ionic et .NET MAUI pour les cas moins exigeants.