A maneira como desenvolvedores trabalham com IA mudou radicalmente nos últimos meses, e quem está dentro dessa rotina sente a evolução semana após semana. Toda nova ferramenta exige uma adaptação do fluxo de trabalho, e logo aparece outra propondo um modelo melhor. O lançamento do SDK do Cursor em TypeScript, somado ao novo Composer 2, parece ser mais um daqueles momentos em que a fundação inteira é repensada — não apenas a ponta da interface.
Do CLI ao multi-agente: por que o fluxo antigo quebrou
Por muito tempo, o fluxo "sério" de quem trabalha com agentes de código foi via CLI: várias sessões de terminal abertas, cada uma rodando um agente em um worktree distinto, às vezes em repositórios diferentes. Funciona — até um certo ponto. O ponto em questão costuma ser quatro sessões em paralelo. A partir daí, a janela de contexto da pessoa que pilota tudo aquilo passa a ser o gargalo. Não a do modelo, mas a humana.
A consequência prática é familiar: você pergunta a um agente algo que estava sendo discutido com outro; manda uma instrução no terminal errado; perde o fio do que cada sessão estava fazendo; confunde o estado de um pull request aberto aguardando review com uma feature ainda em implementação local. Acrescente a isso mensagens do time chegando em paralelo — alguém de produto querendo saber como funciona uma feature flag, um bug report, um comentário de code review — e o cérebro humano simplesmente não escala.
A solução não é parar de paralelizar. É parar de gerenciar o paralelismo manualmente. É exatamente esse o problema que o Cursor 3 e, mais recentemente, o SDK do Cursor se propõem a resolver.
O que é, de verdade, um "AI harness"
A palavra mais importante que entrou no vocabulário do desenvolvedor de IA neste ano é harness. Antes do harness, há o que muita gente assume ser o trabalho todo: o modelo. Treinar um bom modelo de código exige quantidades absurdas de dados, compute e dinheiro. Mas o modelo, sozinho, é apenas 20% do produto final. Os outros 80% — os que fazem a diferença entre uma demo bonita e um agente realmente útil — vivem no harness.
O harness é a infraestrutura que cerca o modelo e transforma uma sequência de tokens em algo capaz de operar em um repositório real. Os componentes essenciais são:
Context management. Antes de gerar qualquer resposta, o agente precisa encontrar o pedaço certo do código no qual atuar. Em um repositório com cem mil arquivos, isso não é trivial. As ferramentas modernas combinam várias técnicas: indexação completa do codebase, busca semântica (embeddings que encontram trechos por significado, não só por correspondência textual), busca por grep clássico (rápido e exato para nomes de função, símbolos, strings literais) e mapas de dependências para entender o que se conecta a quê. Sem isso, o LLM gasta tokens preciosos "adivinhando" onde mexer, e geralmente erra.
Sandboxing. Cada agente roda em uma VM dedicada, com um clone do repositório, ambiente de desenvolvimento pré-configurado e isolamento de credenciais. Esse é um detalhe que muitos subestimam. Rodar um agente diretamente na própria máquina, com acesso a chaves de produção, tokens de cloud e variáveis de ambiente sensíveis, é uma receita pronta para desastres. O sandbox transforma cada sessão em algo descartável e seguro: se o agente fizer besteira, o blast radius está contido.
Session management. O agente precisa sobreviver às intempéries do mundo real. Laptop entra em modo de espera, conexão de rede cai, o computador é reiniciado. Quando o desenvolvedor volta, a sessão tem que estar lá, exatamente onde parou. Isso exige persistência de estado, checkpoints, sincronização entre cliente e backend, e tratamento robusto de falhas de rede. É o tipo de problema clássico de sistemas distribuídos que, paradoxalmente, virou central em uma ferramenta de codificação.
Ferramental: MCP, hooks, skills, subagents. O agente precisa de ferramentas para ler arquivos, rodar comandos, consultar APIs externas. O padrão emergente é o MCP (Model Context Protocol), que define uma forma uniforme de servir tools a qualquer modelo. Por cima disso vêm os hooks (pontos de extensão que executam código do usuário em momentos específicos do ciclo do agente — antes da edição, depois do commit, antes de chamar o modelo), as skills (pacotes de instruções e arquivos auxiliares que o agente carrega quando o contexto pede) e os subagents (capacidade de o agente principal delegar uma subtarefa a outro agente especializado, com contexto isolado).
Cada um desses componentes é, por si só, um produto. Construir um harness completo do zero, com qualidade de produção, é trabalho para um time inteiro durante muitos meses. É exatamente esse o ponto: até agora, quem queria ter um agente próprio precisava reimplementar tudo isso. O Cursor SDK muda essa equação.
O Cursor SDK em TypeScript
Em três linhas de código em TypeScript, o SDK permite instanciar um agente com o mesmo runtime, o mesmo harness, o mesmo sandbox e o mesmo sistema de context management que rodam dentro do Cursor 3. O modelo padrão é o Composer 2, mas qualquer modelo suportado pode ser escolhido. A execução pode acontecer localmente para iteração rápida, na cloud do Cursor para cargas pesadas ou em ambiente self-hosted para empresas com restrições de rede e compliance.
A implicação prática é grande. Quem tem um produto que poderia se beneficiar de um agente embarcado — uma ferramenta interna de DevOps, um assistente customizado para um stack específico, um automator de tarefas repetitivas em um SaaS — agora consegue colocar isso de pé em horas, não meses. O SDK assume todo o trabalho de infraestrutura, e o desenvolvedor se concentra na lógica do produto, nas tools específicas do domínio e na experiência do usuário.
Outra mudança importante é filosófica. Até pouco tempo, as ferramentas de IA para código se dividiam em duas categorias estanques: produtos de prateleira (Cursor, Copilot, Windsurf) e frameworks para construir seu próprio agente (LangChain, LangGraph, frameworks customizados). Quem escolhia o primeiro caminho ficava preso à interface; quem escolhia o segundo reimplementava o mundo todo. O SDK borra essa fronteira: a mesma fundação que serve o produto de prateleira está agora disponível como biblioteca para quem quer construir algo próprio.
Composer 2: o caso dos modelos especializados em código
Ao lado do SDK, há outra peça que merece atenção: o Composer 2. Ao contrário dos modelos generalistas das grandes fornecedoras, o Composer 2 foi treinado especificamente para tarefas de código. A diferença não está apenas no fine-tuning de superfície — é uma decisão de arquitetura e de pipeline de treinamento. O reinforcement learning é direcionado a tarefas de programação reais: passar testes, resolver issues de repositórios open source, executar refactorings corretos, operar em terminais.
Os benchmarks específicos do domínio (SWE-bench Pro, Terminal-Bench 2.0, Cursor Bench) mostram resultados de nível "frontier" — comparáveis aos melhores modelos generalistas em tarefas de código. Mas a métrica que muda tudo é a econômica: o custo de inferência fica em uma fração do que se paga por um modelo generalista equivalente em capacidade.
Esse ponto merece um momento. A indústria está percebendo que treinar um modelo gigantesco para "fazer tudo" tem retorno decrescente. Um modelo de 200 ou 300 bilhões de parâmetros que sabe escrever poesia, traduzir, programar, raciocinar sobre física e debater filosofia é caro de servir e, em qualquer uma dessas tarefas, perde para um modelo menor e bem treinado naquele domínio específico. Para tarefas de código, em que o universo de respostas válidas tem estrutura forte (sintaxe, tipos, semântica) e em que existem sinais de recompensa claros (compila? passa nos testes?), modelos especializados podem ser drasticamente mais eficientes.
A consequência para o desenvolvedor é direta: o custo por tarefa cai. Um agente que antes consumia o equivalente a alguns dólares para resolver um bug agora consome centavos. Isso muda completamente o cálculo de quando vale a pena usar um agente. Tarefas que antes pareciam pequenas demais para "queimar" um modelo caro agora cabem confortavelmente no orçamento.
A economia do token: a nova métrica de eficiência
Em equipes de desenvolvimento que adotam essas ferramentas em escala, uma métrica vem ganhando espaço nos dashboards: tokens consumidos por desenvolvedor por período. Não é incomum encontrar engenheiros queimando 25 milhões de tokens por semana, ou mais de 50 milhões em vinte dias. Esses números traduzidos em dólar, dependendo do modelo, podem chegar a milhares de dólares por mês por pessoa.
Isso não é necessariamente um problema — se o retorno em produtividade compensa, é dinheiro bem gasto. Mas exige uma disciplina nova: a de escolher o modelo certo para cada tarefa. Usar o modelo mais caro disponível para todas as interações é o equivalente a usar um bisturi de cirurgia para cortar pão. Funciona, mas é desperdício.
A regra emergente é simples na intenção e complexa na execução: tarefas de exploração e geração de código de média complexidade vão para o modelo especializado (Composer 2 ou equivalente); tarefas que exigem raciocínio profundo, decisões arquiteturais ou síntese de muitos artefatos diferentes vão para o modelo generalista de topo (Claude Opus, GPT da geração mais recente, Gemini Ultra). Tarefas pequenas — formatação, renomeação, refactorings simples — podem ir para modelos menores e mais baratos.
A métrica de "eficiência por mil tokens" (custo dividido por valor entregue) está se tornando central. Reduzir essa métrica de uma fração de centavo para uma fração menor ainda, vezes dezenas de milhões de tokens por mês, vira economia real.
Multitarefa com agentes: o novo workflow
Com o harness pronto e a economia equacionada, o workflow muda de forma. A interface visual de múltiplas sessões — cada uma representando uma tarefa em andamento, com seu próprio estado, repositório, branch e histórico de conversação — passa a ser o centro de operações.
Algumas práticas se firmam:
Pinar sessões ativas. Sessões que têm um pull request aberto aguardando review, ou que envolvem uma tarefa que precisa ser retomada na manhã seguinte, ficam fixadas. Ao abrir a ferramenta, é a primeira coisa que aparece. É o equivalente moderno do "post-it na tela".
Ordenar por última atualização. Tarefas dormentes saem do campo de visão; tarefas que receberam input recente (um comentário de review, uma resposta de CI) sobem.
Indicadores visuais de estado. Saber de relance se um PR foi mergeado, fechado, ou ainda está aberto reduz drasticamente o custo cognitivo de gerenciar dezenas de tarefas simultâneas. É a diferença entre vasculhar abas de terminal e olhar para um kanban.
Separação por VM. Como cada agente roda em sandbox próprio, alternar entre tarefas não tem custo de "trocar de contexto" no nível do ambiente. A branch certa está checada, as dependências instaladas, o estado do banco de testes preservado. O desenvolvedor só precisa trocar de contexto mentalmente — e mesmo isso fica mais fácil quando a interface ajuda.
O resultado prático é que o limite de quatro tarefas em paralelo (típico de quem trabalha via CLI) sobe consideravelmente. Não é incomum manter dez, quinze sessões ativas, com diferentes graus de envolvimento humano em cada uma. Algumas exigem atenção constante; outras estão no modo "agente trabalha sozinho até concluir ou pedir ajuda".
Para onde isso aponta
A combinação de SDK aberto, modelo especializado eficiente e infraestrutura de execução robusta indica uma transição importante. Ferramentas de IA para código deixam de ser apenas "lugares onde você programa" e passam a ser plataformas sobre as quais outras ferramentas são construídas. A linha entre "usuário do produto" e "desenvolvedor que constrói com a plataforma" começa a se dissolver.
Para quem desenvolve software como atividade principal, isso significa mais alavancagem. O limite do que uma pessoa consegue produzir em um dia deixou de ser a velocidade de digitação ou o número de janelas que cabem na tela. Passa a ser a capacidade de orquestrar agentes, definir bem cada tarefa, revisar com critério o que volta e manter a visão de produto no comando das decisões importantes.
Para empresas que dependem de software como meio (a maioria, hoje), o impacto é estratégico. Construir agentes próprios para fluxos internos, com a mesma qualidade técnica das ferramentas comerciais de ponta, agora cabe no orçamento e no calendário. Quem entender isso primeiro vai ter uma vantagem competitiva que não vinha da escolha de stack — vinha da escolha de quando, e em quê, aplicar agentes.
E para o ecossistema como um todo, vale registrar: estamos saindo de uma fase em que o gargalo era o modelo, e entrando em uma fase em que o gargalo é a infraestrutura ao redor dele. Os próximos avanços relevantes em produtividade de desenvolvedores provavelmente não virão de modelos significativamente maiores. Virão de harnesses mais inteligentes, melhor integração com ferramentas existentes e workflows que respeitem como humanos realmente trabalham — em paralelo, de forma fragmentada, com interrupções, e precisando preservar contexto entre sessões longas.
O Cursor SDK, com tudo que ele encapsula, é um marco nesse caminho. Vale prestar atenção.
Top comments (0)