As automações do Cursor resolvem o problema que a codificação agentic criou. Os engenheiros agora podem gerenciar mais de 10 agentes de codificação ao mesmo tempo, mas a atenção humana se tornou o gargalo. Você não pode cuidar de uma dúzia de agentes enquanto também faz seu trabalho real. As automações invertem o modelo: em vez de você lançar agentes, os eventos o fazem. Um PR mesclado aciona uma auditoria de segurança. Um alerta do PagerDuty ativa um agente que consulta logs e propõe uma correção. Um trabalho cron revisa as lacunas na cobertura de testes todas as manhãs. Cada automação é executada em um sandbox de nuvem isolado com acesso total às ferramentas que você configura através do MCP (um protocolo padrão que permite que os agentes se conectem ao Slack, Linear, GitHub, Datadog ou qualquer API personalizada). O agente segue suas instruções, verifica seu próprio trabalho e aprende com execuções passadas através de um sistema de memória embutido. O Cursor executa centenas dessas por hora internamente. A automação de segurança deles detectou várias vulnerabilidades ao auditar cada push para o main sem bloquear PRs. Isso desbloqueia 4 coisas que não eram práticas antes: 1. Revisão contínua de código em uma profundidade que os humanos ignoram 2. Resposta a incidentes que começa a investigar antes de você ser notificado 3. Trabalho de manutenção que acontece em um cronograma, não quando alguém se lembra 4. Síntese de conhecimento entre ferramentas Os próximos dois anos serão definidos por quem constrói a melhor fábrica, não o melhor código. As empresas que se movem mais rápido não serão aquelas com os melhores engenheiros. Serão aquelas cujos engenheiros passaram tempo configurando automações em vez de escrever código.

Um modelo de 24 bilhões de parâmetros acabou de ser executado em um laptop e escolheu a ferramenta certa em menos de meio segundo. A verdadeira história é que os agentes de chamada de ferramentas finalmente se tornaram rápidos o suficiente para parecerem software. A Liquid construiu o LFM2-24B-A2B usando uma arquitetura híbrida que mistura blocos de convolução com atenção de consulta agrupada em uma proporção de 1:3. Apenas 2,3 bilhões de parâmetros são ativados por token, mesmo que o modelo completo tenha 24 bilhões. Esse padrão de ativação esparsa é o motivo pelo qual ele cabe em 14,5 GB de memória e despacha ferramentas em 385 milissegundos em um M4 Max. A arquitetura foi projetada através de busca com hardware em loop, o que significa que otimizaram a estrutura do modelo testando-o diretamente nos chips em que seria executado. Sem camada de tradução em nuvem. Sem ida e volta de API. O modelo, as ferramentas e seus dados permanecem na máquina. Isso desbloqueia três coisas que eram impraticáveis antes: 1. Indústrias regulamentadas podem executar agentes em laptops de funcionários sem que os dados deixem o dispositivo. 2. Desenvolvedores podem prototipar fluxos de trabalho com múltiplas ferramentas sem gerenciar chaves de API ou limites de taxa. 3. Equipes de segurança obtêm trilhas de auditoria completas sem subprocessadores de fornecedores no loop. O modelo alcançou 80% de precisão na seleção de ferramentas de um único passo em 67 ferramentas que abrangem 13 servidores MCP. Se esse desempenho se mantiver em escala, duas suposições precisam ser atualizadas. Primeiro, agentes em dispositivo não são mais um compromisso de duração da bateria; eles são um recurso de conformidade. Segundo, o gargalo em fluxos de trabalho agentes está mudando de capacidade do modelo para maturidade do ecossistema de ferramentas.

Alguém acabou de contornar o Neural Engine da Apple para treinar modelos. O Neural Engine dentro de cada Mac da série M foi projetado para inferência. Executar modelos, não treiná-los. Sem API pública, sem documentação e certamente sem retropropagação. Um pesquisador fez engenharia reversa das APIs privadas de qualquer forma e construiu um loop de treinamento de transformador que executa passes para frente e para trás diretamente no hardware do ANE. O método contorna completamente o CoreML. Em vez de usar as ferramentas oficiais da Apple, o projeto constrói programas em MIL (Model Intermediate Language), compila-os na memória usando APIs `_ANEClient` não documentadas e alimenta dados através de buffers de memória compartilhada IOSurface. Os pesos são incorporados nos programas compilados como constantes. E cada passo de treinamento despacha seis núcleos personalizados: atenção para frente, feedforward para frente, e depois quatro passes para trás que computam gradientes em relação às entradas. Os gradientes de peso ainda são executados na CPU usando as bibliotecas de matriz do Accelerate, mas o trabalho pesado (multiplicações de matriz, softmax, funções de ativação) acontece no ANE. Isso torna três coisas possíveis que não eram antes: 1. Treinar pequenos modelos localmente sem esgotar a sua bateria 2. Ajustar finamente no dispositivo sem enviar dados para um servidor ou ativar a GPU 3. Pesquisar sobre o que o hardware do ANE pode realmente fazer quando você ignora as barreiras da Apple Se essa abordagem escalar, a próxima onda de IA no dispositivo deixa de ser sobre executar o modelo congelado de outra pessoa.