Cursor Automations résout le problème créé par le codage agentique. Les ingénieurs peuvent désormais gérer plus de 10 agents de codage à la fois, mais l'attention humaine est devenue le goulot d'étranglement. Vous ne pouvez pas surveiller une douzaine d'agents tout en faisant votre vrai travail. Les automatisations inversent le modèle : au lieu que vous lanciez des agents, ce sont les événements qui le font. Un PR fusionné déclenche un audit de sécurité. Une alerte PagerDuty active un agent qui interroge les journaux et propose une solution. Un job cron examine les lacunes de couverture des tests chaque matin. Chaque automatisation s'exécute dans un bac à sable cloud isolé avec un accès complet aux outils que vous configurez via MCP (un protocole standard qui permet aux agents de se connecter à Slack, Linear, GitHub, Datadog ou toute API personnalisée). L'agent suit vos instructions, vérifie son propre travail et apprend des exécutions passées grâce à un système de mémoire intégré. Cursor exécute des centaines de ces automatisations par heure en interne. Leur automatisation de sécurité a détecté plusieurs vulnérabilités en auditant chaque push vers main sans bloquer les PR. Cela débloque 4 choses qui n'étaient pas pratiques auparavant : 1. Revue de code continue à une profondeur que les humains négligent 2. Réponse aux incidents qui commence à enquêter avant que vous ne soyez alerté 3. Travail de maintenance qui se fait selon un calendrier, et non quand quelqu'un s'en souvient 4. Synthèse des connaissances à travers les outils Les deux prochaines années seront définies par qui construit la meilleure usine, et non le meilleur code. Les entreprises qui avancent le plus vite ne seront pas celles avec les meilleurs ingénieurs. Ce seront celles dont les ingénieurs ont passé du temps à configurer des automatisations au lieu d'écrire du code.

Un modèle de 24 milliards de paramètres vient de fonctionner sur un ordinateur portable et a choisi le bon outil en moins d'une demi-seconde. La véritable histoire est que les agents d'appel d'outils sont enfin devenus assez rapides pour ressembler à des logiciels. Liquid a construit LFM2-24B-A2B en utilisant une architecture hybride qui mélange des blocs de convolution avec une attention par requête groupée dans un rapport de 1:3. Seuls 2,3 milliards de paramètres s'activent par jeton, même si le modèle complet contient 24 milliards. Ce schéma d'activation sparse est la raison pour laquelle il tient dans 14,5 Go de mémoire et dispatches des outils en 385 millisecondes sur un M4 Max. L'architecture a été conçue grâce à une recherche hardware-in-the-loop, ce qui signifie qu'ils ont optimisé la structure du modèle en le testant directement sur les puces sur lesquelles il fonctionnerait. Pas de couche de traduction cloud. Pas de retour d'API. Le modèle, les outils et vos données restent sur la machine. Cela débloque trois choses qui étaient impraticables auparavant : 1. Les industries réglementées peuvent faire fonctionner des agents sur les ordinateurs portables des employés sans que les données quittent l'appareil. 2. Les développeurs peuvent prototyper des flux de travail multi-outils sans gérer des clés API ou des limites de taux. 3. Les équipes de sécurité obtiennent des pistes d'audit complètes sans sous-traitants de fournisseurs dans la boucle. Le modèle a atteint 80 % de précision sur la sélection d'outils en une seule étape à travers 67 outils répartis sur 13 serveurs MCP. Si cette performance se maintient à grande échelle, deux hypothèses doivent être mises à jour. Tout d'abord, les agents sur appareil ne sont plus un compromis sur la durée de vie de la batterie ; ils sont une fonctionnalité de conformité. Deuxièmement, le goulot d'étranglement dans les flux de travail agentiques passe de la capacité du modèle à la maturité de l'écosystème des outils.

Quelqu'un vient de contourner le Neural Engine d'Apple pour entraîner des modèles. Le Neural Engine à l'intérieur de chaque Mac de la série M a été conçu pour l'inférence. Exécutez des modèles, ne les entraînez pas. Pas d'API publique, pas de documentation, et certainement pas de rétropropagation. Un chercheur a quand même reverse-engineered les API privées et a construit une boucle d'entraînement de transformateur qui exécute des passes avant et arrière directement sur le matériel ANE. La méthode contourne complètement CoreML. Au lieu d'utiliser les outils officiels d'Apple, le projet construit des programmes en MIL (Model Intermediate Language), les compile en mémoire en utilisant des API `_ANEClient` non documentées, et alimente les données via des tampons de mémoire partagée IOSurface. Les poids sont intégrés dans les programmes compilés en tant que constantes. Chaque étape d'entraînement envoie six noyaux personnalisés : attention avant, feedforward avant, puis quatre passes arrière qui calculent les gradients par rapport aux entrées. Les gradients de poids s'exécutent toujours sur le CPU en utilisant les bibliothèques de matrices d'Accelerate, mais le travail lourd (multiplications de matrices, softmax, fonctions d'activation) se fait sur l'ANE. Cela rend trois choses possibles qui ne l'étaient pas auparavant : 1. Entraîner de petits modèles localement sans épuiser votre batterie 2. Affiner sur l'appareil sans envoyer de données à un serveur ou faire tourner le GPU 3. Recherche sur ce que le matériel ANE peut réellement faire lorsque vous ignorez les garde-fous d'Apple Si cette approche se développe, la prochaine vague d'IA sur appareil ne sera plus seulement une question d'exécution du modèle figé de quelqu'un d'autre.