image

Access unlimited bootcamps and 650+ courses forever

70
%OFF
Article image
Carlos Pinheiro
Carlos Pinheiro16/05/2026 14:08
Share

A falta de padronização na orquestração básica de agentes de IA

  • #Ideação Estruturada
  • #LLMs

Tenho observado com bastante atenção a forma como diferentes ferramentas vêm tentando resolver um problema cada vez mais comum no desenvolvimento com Inteligência Artificial Generativa: a definição de regras, instruções e comportamentos para agentes de programação. Cada ambiente parece ter criado sua própria maneira de orientar o agente, e isso, embora traga liberdade, também cria uma grande fragmentação.

O arquivo AGENTS.md, por exemplo, surge como uma proposta mais genérica para descrever como o agente deve atuar dentro de um projeto. Já o Claude adota o CLAUDE.md, seguindo uma lógica própria para orientar seu modelo. O Windsurf, por outro lado, utiliza uma abordagem mais estruturada, baseada principalmente nas pastas .windsurf/rules e .windsurf/workflows. Quanto ao Cursor, não posso fazer uma análise justa, pois ainda não o utilizei o suficiente para falar com propriedade.

Neste artigo, portanto, quero focar no Windsurf, que hoje é meu editor favorito quando o assunto é trabalhar com agentes de IA aplicados ao desenvolvimento de software. É nele que costumo organizar boa parte dos meus projetos, combinando regras, fluxos de trabalho e interação direta com o Cascade, que é o agente do Windsurf. Quando acabam os créditos das IAs Generativas Premium disponíveis no próprio Windsurf, também recorro ao GPT Codex como alternativa para continuar o trabalho.

O que mais me chama atenção no Windsurf é a flexibilidade do sistema de regras. A pasta .windsurf/rules permite definir arquivos separados para cada regra, orientação de escrita de código, padrão arquitetural, convenção de documentação ou comportamento esperado do agente. Isso é muito poderoso, porque o projeto deixa de depender apenas de um prompt longo e repetitivo. Em vez disso, podemos criar um conjunto organizado de instruções reutilizáveis, cada uma com uma finalidade bem definida.

Essas regras podem ser aplicadas de formas diferentes conforme o contexto. Algumas podem ficar sempre ativas, usando a configuração conhecida como Always On. Outras podem depender da decisão do modelo, no modo Model Decision, em que o próprio agente avalia, com base na descrição da regra, se ela deve ou não ser incluída no prompt daquele momento. Há também o modo manual, em que o usuário escolhe explicitamente quais regras deseja usar para enriquecer a interação com o agente.

O modo Model Decision é especialmente interessante, porque ele cria uma camada de inteligência na própria seleção das instruções. Em vez de o programador precisar lembrar manualmente todas as regras disponíveis, o modelo analisa a descrição de cada uma e decide quais são relevantes para aquele pedido. Assim, se estou trabalhando em documentação, arquitetura, testes, firmware, backend ou frontend, o agente pode selecionar automaticamente as orientações mais adequadas ao contexto.

Essa abordagem torna o Windsurf muito dinâmico. Não estamos falando apenas de um arquivo estático com instruções gerais para o projeto inteiro. Estamos falando de um mecanismo mais granular, capaz de adaptar o comportamento do agente conforme a tarefa, o tipo de código, a camada do sistema ou até o estilo de documentação esperado.

É justamente nesse ponto que vejo uma limitação importante em propostas mais genéricas, como a discutida no site agents.md. Considero muito positivo existir um movimento tentando padronizar o descritor de ação dos agentes. A padronização é necessária, porque hoje cada ferramenta cria sua própria convenção, seu próprio nome de arquivo e sua própria lógica de uso. Isso dificulta a portabilidade das instruções entre ambientes diferentes e aumenta o esforço de manutenção dos projetos.

Porém, ao mesmo tempo, percebo que o modelo baseado apenas em um arquivo global, aplicado ao projeto como um todo, ainda não oferece a mesma flexibilidade que encontro no Windsurf. Um único descritor geral pode funcionar bem para regras amplas, mas nem sempre é suficiente quando o projeto cresce, quando há múltiplas linguagens, diferentes camadas de arquitetura, padrões específicos de teste, documentação técnica, scripts, firmware, backend, frontend e infraestrutura.

Outro ponto muito relevante no Windsurf é o uso de memórias. Essas memórias complementam o comportamento geral do Cascade e também podem ser relacionadas ao workspace. Isso permite que o agente compreenda melhor o estilo de trabalho, as preferências do desenvolvedor e certas decisões recorrentes do projeto. A combinação entre regras, workflows e memórias cria uma experiência muito mais rica do que simplesmente entregar um prompt fixo ao modelo.

Além disso, a pasta .windsurf pode existir em diferentes níveis: de forma geral, no workspace e também dentro de subprojetos. Isso traz uma flexibilidade enorme, principalmente para quem trabalha com monorepos, sistemas distribuídos ou projetos compostos por várias partes independentes. Posso ter regras gerais para todos os projetos, regras específicas para um workspace e ainda regras particulares para um módulo, biblioteca ou aplicação específica.

Essa estrutura permite organizar melhor o conhecimento operacional do projeto. Em vez de depender apenas da memória humana ou de instruções soltas em conversas com a IA, podemos versionar regras, documentar fluxos de trabalho e criar uma espécie de contrato de comportamento entre o desenvolvedor e o agente. Para mim, isso é uma evolução importante na forma como usamos IA Generativa no desenvolvimento de software.

A falta de padronização, entretanto, continua sendo um problema. Quando cada ferramenta usa um nome diferente, um formato diferente e uma lógica diferente, o desenvolvedor acaba tendo que reaprender a orquestração do agente a cada ambiente. Isso cria atrito, principalmente para equipes que usam múltiplas ferramentas ou que desejam migrar de uma solução para outra. Seria muito útil termos uma convenção mínima comum, mas que não sacrificasse a flexibilidade oferecida por ferramentas mais avançadas.

Na minha visão, o ideal seria uma padronização que reconhecesse diferentes níveis de instrução. Poderíamos ter um descritor geral do agente, como o AGENTS.md, mas também uma estrutura complementar para regras contextuais, workflows, decisões automáticas do modelo e memórias de projeto. Assim, uniríamos o melhor dos dois mundos: interoperabilidade entre ferramentas e flexibilidade real para projetos complexos.

É por isso que considero o Windsurf uma ferramenta muito versátil, tanto para pequenos quanto para grandes projetos. Ele não se limita a ser apenas um editor com IA acoplada. Ele oferece uma forma prática de organizar a colaboração entre desenvolvedor e agente, permitindo que o conhecimento técnico, as convenções e os fluxos de trabalho sejam distribuídos em arquivos específicos e acionados conforme a necessidade.

Por esse motivo, acredito que a DIO faria um trabalho de grande valor ao criar um curso dedicado ao Windsurf. Insisto nisso porque vejo a ferramenta como algo muito útil para quem está aprendendo programação, mas também para profissionais experientes que desejam estruturar melhor seus projetos com apoio de agentes de IA. Um curso bem feito poderia mostrar não apenas como usar o editor, mas como pensar a orquestração do agente, organizar regras, criar workflows, usar memórias e transformar a IA em uma parceira mais disciplinada no desenvolvimento de software.

No fim, minha crítica não é contra a existência de diferentes abordagens. Pelo contrário, essa diversidade mostra que estamos em uma fase de experimentação muito rica. Minha crítica é à ausência de uma base comum que facilite a vida do desenvolvedor. Precisamos de padronização, mas não de uma padronização pobre. Precisamos de uma estrutura comum que permita portabilidade, mas que também respeite a complexidade real dos projetos modernos.

O Windsurf, nesse sentido, aponta um caminho interessante: regras contextuais, workflows, memórias e organização por níveis de projeto. Talvez o futuro da orquestração de agentes esteja justamente nessa direção, em que não apenas dizemos ao agente o que ele deve fazer, mas também organizamos quando, onde e em qual contexto cada orientação deve ser aplicada.

Share
Recommended for you
GFT - Fundamentos de Cloud com AWS
Bootcamp Afya - Automação de Dados com IA
Bootcamp NTT DATA: Backend Java com Spring AI
Comments (0)
Read below