Desenvolvimento de software na era agêntica

O IDE sob pressão

Durante décadas, o IDE foi o motor silencioso do desenvolvimento de software. A sua proposta de valor era clara: a integração economiza tempo. A combinação de um editor de texto, um compilador, um depurador e um sistema de controlo de versões numa única interface gráfica tornou ferramentas como Eclipse, IntelliJ e VS Code (com o respetivo ecossistema de extensões) no eixo central do dia a dia dos programadores. Mas à medida que a definição de "desenvolvimento" se ampliou para incluir a conteinerização, as implantações nativas na nuvem e a integração profunda da IA, o IDE começou a vacilar em sua abrangência e indispensabilidade.

A principal reclamação dos engenheiros sênior é o consumo de recursos. Um IDE moderno, carregado com extensões para cada framework da pilha de um projeto, pode exigir centenas de megabytes de RAM; em algumas configurações, só os plugins de IA terão sido reportados como capazes de elevar a utilização da CPU acima de 500%. Essa sobrecarga está a tornar-se cada vez mais difícil de justificar quando a IA está a fazer a maior parte do trabalho generativo.

Se um agente consegue gerar várias centenas de linhas de código bem estruturado a partir de um prompt "simples", os programadores já não precisam (ou talvez precisem de muito pouco) dessa complexa faixa de opções que define a experiência dentro de um IDE. Tal como um escritor — uma analogia que o meu colega fez durante a nossa conversa — que percebe que, há meses, raramente precisou de usar a barra de formatação de texto porque uma IA trata do layout, os programadores estão a descobrir que um editor de código básico é suficiente para a revisão final antes de enviar o código.

_____

⚠️ Nota: Sabemos que algumas pessoas poderiam argumentar que o VS Code, por exemplo, não é um IDE por padrão, mas se torna um ao instalar extensões. Portanto, podemos pensar em um IDE como uma estrutura que inclui uma série de ferramentas pré-instaladas para facilitar a edição, a revisão e a implantação de código.

_____

Além do uso excessivo de recursos, há um problema fundamental de design: os IDEs atuais tratam a IA como um elemento secundário: uma barra lateral, uma janela de chat, um complemento adicionado a uma interface projetada décadas antes da existência dos LLMs. Esta abordagem falha em aproveitar todo o potencial dos fluxos de trabalho agênticos. Quando uma IA consegue depurar, refatorar e explicar sistemas inteiros de forma autónoma, confiná-la a um canto do ecrã parece uma relíquia do passado. Vimos que o verdadeiro desenvolvimento nativo de IA exige que o ambiente seja estruturado em torno do agente, e não o contrário.

O regresso do terminal

O terminal, de forma algo inesperada, recuperou o seu papel como centro de comando para o desenvolvimento em alta velocidade. Ferramentas como Claude Code, Aider e o Gemini CLI demonstraram que, para fluxos de trabalho agênticos, uma CLI (interface de linha de comandos) é frequentemente superior a uma GUI (interface gráfica de usuário). Três características explicam o motivo.

Primeiro, a capacidade de composição (composability) nativa do texto. A filosofia Unix, na qual a saída de um programa se torna a entrada de outro, é a linguagem nativa dos LLMs. Um agente de CLI pode localizar todos os ficheiros TypeScript, filtrar por uma importação específica e executar um script de substituição escrevendo um comando shell, sem a necessidade de integrações complexas de API.

Segundo, gestão progressiva de contexto. Um dos maiores desafios no desenvolvimento assistido por IA é a poluição do contexto. Em um IDE, os agentes frequentemente carregam toda a árvore de arquivos ou esquemas persistentes na janela de contexto, o que resulta em alto consumo de tokens e distrai o modelo. As ferramentas de CLI tratam o contexto como um recurso escasso; usam pesquisas direcionadas para encontrar os arquivos relevantes, leem apenas o que precisam e gerem a janela de contexto com precisão.

Terceiro, ciclos de retroalimentação binários. Agentes autónomos precisam de sinais claros para se autocorrigirem. Numa CLI, um comando termina com 0 ou 1; isso permite que um agente execute um teste, observe a falha em 'stderr' (fluxo de saída pré-conectado usado por programas de computador para emitir mensagens de erro ou diagnósticos) e itere sobre uma correção sem intervenção humana. Reproduzir este ciclo numa GUI é significativamente mais complexo e propenso à fricção.

Nada disto significa que o terminal seja superior em todos os aspectos. Os agentes de CLI destacam-se em tarefas paralelas, automação e integração CI/CD; os IDEs agênticos (baseados em agentes), como o Cursor e o Windsurf, mantêm vantagens claras para depuração visual, integração e trabalho de front-end, em que ver o resultado renderizado é importante. A questão é menos sobre qual ferramenta é universalmente melhor e mais sobre qual ferramenta se adequa à tarefa em mãos.

O meu colega, por exemplo, diz que o principal valor que uma ferramenta como o Zed lhe oferece é o 'diff'. Ele poderia usar o comando git diff no terminal ou uma das muitas ferramentas especializadas concebidas para mostrar facilmente as alterações antes e depois num repositório para revisão (p.ex., GitKraken ou o VS Code com a sua vista Git e extensões como o GitLens). No entanto, ele diz que recorre ao Zed porque este também lhe fornece uma forma conveniente de explorar a codebase exatamente no momento em que o agente de IA a está a editar; ele pode navegar na estrutura de arquivos e procurar modificações específicas com facilidade.

Três paradigmas, não um

O desenvolvimento assistido por IA abrange atualmente três abordagens distintas. Estas distinções são importantes porque definem como a autonomia, o contexto e a colaboração são tratados.

Os IDEs agênticos ampliam as funções dos editores tradicionais por meio de recursos de inteligência artificial. Eles oferecem sugestões em tempo real, geração de código e automação limitada em várias etapas, mas continuam operando dentro das restrições de um único espaço de trabalho e de um operador humano principal.

Os agentes de CLI dependem de comandos "componíveis" (composable), de acesso ao sistema de arquivos e de automação. São particularmente eficazes em fluxos de trabalho automatizados, como pipelines de CI, resposta a incidentes e manutenção recorrente.

Os ambientes de desenvolvimento agêntico (ADEs) vão mais longe ao colocar a orquestração no centro. Ao contrário de um IDE derivado que adiciona funções de IA, um ADE é construído do zero para a coordenação de agentes. Os componentes principais incluem isolamento de espaço de trabalho através de worktrees do Git separados (ferramentas como Warp e a Antigravity da Google usam este padrão para permitir que vários agentes trabalhem em diferentes branches sem poluir o sistema de arquivos), uma interface de gestão que substitui o editor de código por um dashboard para criar e monitorizar agentes, e motores de contexto semântico que utilizam indexação consciente das dependências para que, quando um agente modifica uma biblioteca partilhada, o sistema compreenda os efeitos em cascata em toda a arquitetura. Num ADE, o próprio sistema torna-se a interface principal; o programador interage com um plano de controlo em vez de uma ferramenta única.

De maestro a orquestrador

A indústria adotou nova terminologia para descrever o papel em evolução do desenvolvedor: primeiro, um programador; depois, um "condutor"; e agora, um "orquestrador".

Um condutor ou diretor trabalha em estreita colaboração com um único agente de IA focado em uma tarefa, dentro de um ciclo de feedback síncrono e estreito, aprovando ou ajustando cada sugestão. Este é o modelo de "programador em par com IA", ao qual já se atribuem ganhos de produtividade de 25–30%. É eficaz para implementação ao nível micro, mas continua a ser linear.

Um orquestrador, por outro lado, supervisiona vários agentes de IA a trabalhar em paralelo. Neste paradigma, um engenheiro pode atribuir tarefas de backend a um agente, atualizações de frontend a outro e geração de testes a um terceiro. O programador define objetivos de alto nível, resolve conflitos entre agentes e revê as pull requests (PRs) resultantes. O fluxo de trabalho torna-se assíncrono; quando o desenvolvedor revisa, várias PRs já estão prontas para avaliação.

Como observou Karpathy, cofundador da OpenAI, os bits contribuídos diretamente pelo programador estão a tornar-se escassos. A nova camada programável envolve a gestão de subagentes, prompts, memória e permissões.

Executar vários agentes em paralelo apresenta desafios reais. As tarefas têm de ser isoladas para prevenir conflitos, normalmente através de espaços de trabalho ou branches separados. Sem esse isolamento, modificações concorrentes podem interferir entre si, levando a resultados inconsistentes. A gestão de contexto torna-se crítica: os agentes precisam de acesso a informações relevantes sem serem sobrecarregados pelo ruído, e os sistemas avançados lidam com isso organizando o contexto em camadas que combinam conhecimento persistente, dados específicos da tarefa e restrições de tempo de execução.

Além disso, os modelos de permissões têm de ser granulares, abrangendo desde o acesso somente leitura até ações que exigem aprovação humana explícita. Fluxos de trabalho com intervenção humana (human-in-the-loop) são essenciais nos pontos de decisão de alto impacto. De facto, existem casos documentados que mostram que agentes autónomos podem causar alterações destrutivas quando deixados sem supervisão.

Voltando à experiência específica do meu colega, ele me contou detalhes sobre o seu ambiente de trabalho atual: usa a abordagem de "multi-clauding", o que significa que executa o Claude Code em vários terminais, atribuindo diferentes tarefas a cada um para execução nos seus próprios espaços de trabalho Git (worktrees).

Assim, os agentes de IA trabalham (documentando o seu raciocínio e as suas modificações), validam as alterações com linters, enviam o código (onde linters adicionais são executados via Git Hooks) e, uma vez no GitLab, o pipeline de CI começa a correr. Se houver falha, David informa o erro aos agentes para que possam entender o problema e iterar.

Em última instância, é ele quem revê as alterações no repositório e decide se são aceitáveis ou se precisam de melhoria. Da mesma forma, é ele quem define quando abrir o merge request (MR, no qual decorre a revisão por pares) e quem assume a responsabilidade pelas modificações feitas pelos agentes; no fim do dia, esses commits são registados em seu nome.

No caso do David, Zed, o editor de código, torna-se uma janela para os mundos paralelos dos agentes, permitindo-lhe verificar confortavelmente o 'diff' e explorar a codebase em um ponto específico do histórico de desenvolvimento do software para compreendê-la e avaliá-la.

CLI vs. MCP?

No ecossistema de agentes, às vezes se faz referência a um debate sobre as CLIs versus os servidores MCP (Model Context Protocol). No entanto, abordá-lo como uma escolha entre um ou outro parece ignorar o fato de que eles são complementares.

As CLIs oferecem vantagens claras quando as ferramentas envolvidas já estão bem representadas nos dados de treinamento. Utilitários como 'git', 'curl' e 'grep' (utilitários de linha de comando usados para controle de versão, transferência de dados e processamento de texto, respectivamente) podem ser invocados com o mínimo de contexto adicional, e os agentes podem aceder à documentação de ajuda progressivamente, em vez de carregar todas as definições das ferramentas logo à partida. Estas vantagens, contudo, diminuem quando se lida com ferramentas personalizadas ou APIs proprietárias, nas quais os agentes necessitam de instruções detalhadas que anulam qualquer economia de tokens.

Os servidores MCP abordam um conjunto distinto de problemas. Ao centralizar ferramentas e APIs atrás de um protocolo padronizado, eles simplificam a autenticação (as chaves de API sensíveis permanecem no servidor; os programadores autenticam-se via OAuth), melhoram a auditabilidade (cada chamada a uma ferramenta por um agente é registada e rastreável) e permitem a entrega dinâmica de conhecimento (as organizações podem enviar boas práticas e documentação atualizadas aos agentes de toda a equipa através de um único ponto de acesso). Também garantem consistência: prompts, recursos e definições de ferramentas podem ser atualizados centralmente para que cada usuário interaja com a versão mais recente.

Na prática, as CLIs se destacam no "circuito interno" (inner loop), onde velocidade e flexibilidade são as principais; os servidores MCP são mais eficazes no "circuito externo" (outer loop), onde o acesso estruturado à infraestrutura compartilhada é a prioridade. Os dois são camadas complementares em um ecossistema em maturação.

As competências e princípios que importam agora

Se os agentes de IA estiverem escrevendo, digamos, 90% do código, o que restará para o engenheiro? Na verdade, alguns dizem que o valor de ser um "poliglota de linguagens" está a diminuir. As competências que hoje distinguem os programadores parecem concentrar-se em três áreas:

• Decomposição de problemas: dividir requisitos empresariais complexos em tarefas bem definidas que um agente de IA possa tratar facilmente.

• Arquitetura de sistemas: tomar decisões de alto nível sobre a pilha tecnológica, as interações entre componentes e serviços e a escalabilidade.

• Verificação e calibração de confiança: desenvolver o discernimento para saber quando os resultados de um agente podem ser confiáveis e quando é necessária intervenção manual.

As organizações enfrentam desafios paralelos: integrar IA em arquiteturas legadas, por exemplo, que nunca foram concebidas para a acomodar, muitas vezes exige uma reengenharia significativa; uma codebase monolítica com dependências fortemente acopladas nem sempre pode ser adequada à decomposição de tarefas exigida pelos fluxos de trabalho agênticos. Além disso, os estrangulamentos que eram aceitáveis ontem já não são toleráveis hoje, dada a velocidade de execução permitida por estes fluxos de trabalho agênticos. Então, é necessário repensar o planeamento, a priorização e a manutenção das rotas pelas quais todas as alterações fluem para os repositórios de código, a fim de mantê-las livres de congestionamentos.

A qualidade dos dados, falhas de raciocínio e preocupações com propriedade intelectual acrescentam outra camada de complexidade. Os sistemas de IA dependem de dados de treino que podem introduzir enviesamentos ou conduzir à replicação inadvertida de conteúdo protegido. Lidar eficazmente com estas questões exige quadros para governação, transparência e avaliação contínua, em vez de auditorias pontuais.

A dimensão da força de trabalho é igualmente importante: os programadores precisam de novas competências para interpretar o comportamento dos LLMs, avaliar criticamente os resultados e integrar a IA nos fluxos de trabalho existentes. A aprendizagem contínua torna-se um pré-requisito, não um extra opcional, e o fosso entre equipas que investem nela e aquelas que não o fazem crescerá rapidamente.

O ciclo de vida contínuo e as suas implicações de segurança

Já se disse que outra mudança significativa trazida pelo desenvolvimento orientado por agentes é a ruptura das etapas tradicionais do SDLC (ciclo de vida de desenvolvimento de software). As fronteiras entre desenvolvimento, testes e produção parecem estar a esbater-se. O código é gerado, testado, implementado e substituído em ciclos rápidos; os ambientes assemelham-se cada vez mais à produção, mesmo durante o desenvolvimento, com feature flags e "lançamentos canary" tornando-se prática padrão. Os ambientes de desenvolvimento não estão a desaparecer, mas seu papel muda de etapas claramente definidas para espaços de experimentação controlada dentro de um fluxo unificado e contínuo.

Esta continuidade tem implicações diretas para a segurança dos sistemas em desenvolvimento. Os pontos de controlo tradicionais, como "verificar antes do lançamento", perdem relevância quando os lançamentos ocorrem continuamente. A validação de código e as avaliações de segurança para aplicações em operação têm de acompanhar esse ritmo. O próprio conceito de uma "barreira de pré-produção" pressupõe uma fronteira clara entre desenvolvimento e produção, e essa fronteira parece estar se dissolvendo.

O desenvolvimento baseado em agentes também expande a superfície de ataque de determinadas formas. As aplicações estão a tornar-se mais distribuídas, as APIs estão a proliferar e os modelos de IA estão a ser integrados tanto em ambientes de desenvolvimento como em ambientes de execução. Novas interfaces, como chat e voz, introduzem categorias inteiramente novas de vulnerabilidades que não têm equivalente em aplicações web tradicionais. Agentes que executam comandos, acedem a sistemas e modificam infraestrutura exigem forte isolamento, controlo de permissões e auditabilidade. A combinação de execuções autônomas e amplo acesso aos sistemas cria perfis de risco com os quais a maioria das ferramentas de segurança existentes não foi projetada para lidar.

Na Fluid Attacks, queremos reiterar um princípio que vale a pena ter em mente hoje: a responsabilidade pela segurança não é transferida ao agente. Código gerado por IA, por muito limpo que seja sintaticamente, ainda pode conter falhas lógicas ou ser vulnerável em ambiente de execução. A análise estática, mesmo quando alimentada por IA, apenas lê o código-fonte; não consegue detetar vulnerabilidades que surgem em tempo de execução, como middleware mal configurado, integrações de serviços defeituosas ou problemas de autenticação que só se manifestam quando o sistema é montado e processa entradas do mundo real.

Compreender a segurança em aplicações modernas requer observar como estas se comportam em condições realistas, incluindo a forma como os atacantes as poderiam analisar. Na prática, muitas das vulnerabilidades mais graves não surgem do que o código diz, mas de como ele interage com tudo o que o rodeia.

Para adotar ferramentas agênticas em segurança, as organizações devem implementar

• sandboxing: os agentes devem ser executados em contêineres isolados para impedir que comandos maliciosos cheguem ao host;

• proteções de permissões: impondo listas de permissão/restrição no nível do shell para que os agentes não possam acessar arquivos de credenciais ou escalar privilégios, e

• ASPM como sistema de registo: uma plataforma de gestão da postura de segurança de aplicações que consolida resultados de análises por IA, testes automatizados e testes de penetração manuais num conjunto de dados governado, garantindo continuidade mesmo quando as ferramentas de criação se tornam transitórias.

O que vem a seguir

Embora alguns detalhes ainda estejam por resolver, a direção é clara: a IA está a tornar-se um componente estrutural do desenvolvimento de software, e não apenas um impulsionador de produtividade. Os desenvolvedores fornecem o contexto, o discernimento e a supervisão; os agentes são responsáveis pela execução e pela automação.

Essa parceria tem potencial real para elevar tanto a eficiência quanto a qualidade, mas o sucesso depende da manutenção do equilíbrio. A dependência excessiva da IA introduz riscos que se acumulam silenciosamente: degradação da coerência arquitetônica, pontos cegos de segurança ao confiar na saída do agente sem verificação adequada e uma erosão gradual da intuição técnica profunda que só vem de trabalhar próximo ao código-fonte (close to the metal). Por outro lado, uma integração insuficiente deixa as equipes competindo contra organizações que já descobriram como multiplicar sua capacidade de engenharia.

O ciclo de vida do desenvolvimento de software deixou de ser uma sequência de etapas discretas; tornou-se um sistema contínuo e sobreposto, em que as fronteiras entre escrever, testar, implementar e proteger o código se esbatem num único fluxo. Navegar nesse fluxo exige tratar desenvolvimento, operações e segurança como uma disciplina unificada, e não como silos adjacentes.

As organizações que acertarem nisto não serão as que adotarem mais ferramentas ou implementarem mais agentes. Serão aquelas que compreenderem o sistema em sua totalidade, reconhecendo onde o julgamento humano é insubstituível, onde a automação realmente reduz o risco em vez de simplesmente transferi-lo, e onde os ganhos de velocidade dos fluxos de trabalho baseados em agentes estão ancorados a uma supervisão de segurança rigorosa que mantém esses sistemas confiáveis uma vez que entram em produção.

No contexto atual do desenvolvimento de software, já não somos definidos pelo código que escrevemos; somos arquitetos de sistemas autônomos, e a disciplina de engenharia necessária para garantir sua segurança e confiabilidade é a mesma que sempre distinguiu a construção reflexiva da construção apressada e descuidada.