Novos padrões de desenvolvimento na era da IA

xguru · 2025-05-26T11:03:01+09:00

Está se formando uma cultura de desenvolvimento que trata a IA não como uma simples ferramenta, mas como uma tecnologia de base As formas tradicionais de controle de versão, dashboards, templates, documentação e gestão de segredos estão mudando para se adequar à era da IA O Git está sendo reinterpretado não mais como um sistema de acompanhamento de mudanças linha por linha no código, mas como um modelo de gerenciamento de estado centrado em prompts e resultados de testes Os agentes passam a ser autores e consumidores de código, aumentando a necessidade de redesenhar as próprias ferramentas Dashboards e UIs estão migrando para interfaces baseadas em linguagem natural, evoluindo para formatos usados em conjunto por pessoas e agentes de IA A documentação está se transformando em uma base de conhecimento para humanos e IA, sendo reorganizada em formatos que os agentes consigam entender 1. AI-Native Git: redefinindo o controle de versão para agentes de IA O Git foi originalmente projetado para rastrear o histórico de mudanças linha a linha em código escrito diretamente por pessoas Mas, em um cenário em que a IA gera e modifica automaticamente grande parte do código, esse rastreamento detalhado se torna menos importante Os desenvolvedores passam a focar não mais nas mudanças em si, mas na adequação do comportamento resultante (se os testes passaram, se tudo funciona corretamente etc.) O SHA informa que houve uma mudança, mas não traz informação sobre por que ela ocorreu ou se ela é válida Especialmente em mudanças de grande escala ou em código gerado automaticamente, os desenvolvedores não revisam cada diff manualmente Em um workflow AI-first, a combinação dos elementos abaixo se torna uma unidade mais útil Prompt: a entrada que orientou a geração do código Teste: o teste usado para validar o comportamento esperado Spec e constraints: requisitos de projeto, como especificações e restrições Esses elementos passam a ser tratados e rastreados como um único bundle versionável Levando isso um passo adiante, em um workflow orientado por agentes, a Source of Truth pode se mover upstream em direção a prompts, esquemas de dados, contratos de API e intenção arquitetural Como resultado, o código passa a ser tratado como um artefato compilado, ou seja, como um subproduto dessas entradas, e não como a fonte principal O Git passa a funcionar não como workspace de código, mas como um artifact log Quem gerou o código, com qual modelo e usando qual prompt Quais testes passaram E metadados como quais partes precisam de revisão humana O histórico de mudanças inclui prompts, objetivo, testes relacionados e informações sobre o modelo que gerou o código Com integração a ferramentas de revisão por IA como o Diamond, torna-se possível criar fluxos automatizados de review Também é possível estruturar metadados mais ricos em camadas, como a separação entre código gerado por agentes e áreas protegidas mantidas por humanos Em um possível workflow de AI-Native Git Pode surgir um novo tipo de dashboard do Git, mostrando em conjunto prompts, fluxo de mudanças derivado deles, resultados de testes, informações sobre os agentes envolvidos e dados do bundle 2. Dashboards → Synthesis: evolução para interfaces dinâmicas baseadas em IA Durante anos, dashboards serviram como a principal interface para interagir com sistemas complexos, como sistemas de observabilidade, ferramentas analíticas e consoles de nuvem (AWS etc.) No entanto, o excesso de controles, gráficos e abas gerou sobrecarga de UX, fazendo com que os usuários frequentemente se percam entre explorar informações e executar ações Especialmente para não especialistas ou em cenários de colaboração entre várias equipes, esses dashboards podem ser percebidos como ferramentas intimidantes e ineficientes Muitas vezes, o usuário sabe o que quer alcançar, mas não sabe onde procurar nem quais filtros aplicar A geração mais recente de modelos de IA aponta uma possibilidade de resolver esse problema Ela permite reinterpretar o dashboard não como uma tela fixa, mas como um espaço de exploração e interação Um LLM pode apoiar o usuário das seguintes formas: Localização de controles, como em “Onde altero a configuração de rate limit desta API?” Resumo integrado de dados, como em “Resuma a tendência de erros de todos os serviços no ambiente de staging nas últimas 24 horas” Sugestão de insights ocultos, como em “Com base no meu contexto de negócio, recomende as métricas que devo acompanhar neste trimestre” Hoje, tecnologias como Assistant UI já permitem que agentes usem componentes React como se fossem ferramentas Assim como o conteúdo se torna dinâmico e personalizado, a própria UI também está sendo recomposta conforme a intenção do usuário e evoluindo para um formato conversacional Dashboards estáticos podem em breve ser vistos como ultrapassados Exemplo: Se o usuário disser “Mostre as anomalias ocorridas na Europa no último fim de semana”, logs resumidos e tendências são apresentados automaticamente, sem que ele precise manipular filtros manualmente Diante da pergunta “Por que a pontuação de NPS caiu na semana passada?”, a IA pode oferecer análise de sentimento das pesquisas, correlação com deploys de produto e um resumo diagnóstico Em uma visão mais ampla, se agentes se tornarem consumidores de software, o próprio conceito de dashboard também precisará ser redesenhado Por exemplo, um dashboard pode renderizar visões otimizadas para Agent Experience Fornecendo interfaces estruturadas e acessíveis programaticamente para que o sistema reconheça estado, tome decisões e execute ações Como resultado, pode surgir uma estrutura de interface dupla, com uma UI para humanos e outra para agentes As duas UIs compartilham o mesmo estado, mas são organizadas de forma diferente conforme o modo de consumo Os agentes passam a assumir o papel antes desempenhado por alertas, cron jobs e automações condicionais, mas como executores com muito mais contexto e flexibilidade Exemplo: Antes: if error rate > threshold then send alert Baseado em agentes: “A taxa de erro está subindo. A causa é este serviço, e estes são os componentes afetados e as ações recomendadas” Assim, o dashboard deixa de ser apenas um lugar de observação e passa a ser um espaço onde humanos e IA colaboram, integram informações e executam ações 3. Documentação está evoluindo para uma combinação de ferramenta, índice e base de conhecimento interativa A forma como os desenvolvedores usam documentação está mudando Antes, era comum ler seguindo o índice ou percorrer uma spec de cima para baixo, mas agora “fazer a pergunta primeiro” está se tornando o padrão Em vez de “vou estudar esta spec”, surge a mudança de mentalidade para “reorganize a informação do jeito que eu quero” Essa mudança também afeta o formato da documentação, que está evoluindo não para HTML ou Markdown estático, mas para um sistema de conhecimento interativo sustentado por índices, embeddings e agentes com reconhecimento de ferramentas Com isso, ferramentas como Mintlify estão ganhando espaço A Mintlify não apenas organiza a documentação como um banco de dados pesquisável por significado, como também a usa como fonte de contexto para agentes em diversas plataformas Ex.: em AI IDEs, extensões do VS Code e agentes de terminal, a documentação do Mintlify é usada como material de referência em tempo real Isso acontece porque agentes de geração de código usam a documentação atualizada como contexto baseado em aprendizado Com isso, o próprio objetivo da documentação está mudando A documentação deixa de ser apenas um meio de transmissão de informação para leitores humanos e passa a precisar ser desenhada como uma estrutura para consumidores-agentes Nessa nova dinâmica, a documentação passa a funcionar como um manual de instruções para agentes de IA Não se trata apenas de expor conteúdo, mas de explicar como o sistema pode ser usado corretamente 4. De templates para geração: vibe coding substituindo o create-react-app No passado, era comum começar um projeto escolhendo templates estáticos como create-react-app, next init e rails new Esses templates forneciam uma estrutura de app consistente, mas era difícil personalizá-los de acordo com a intenção do desenvolvedor ou a stack, e era preciso seguir os padrões definidos pelo framework Como resultado, sair da configuração padrão exigia muito refatoramento manual Agora, esse fluxo está mudando com o surgimento de plataformas text-to-app como Replit, Same.dev, Loveable, Chef by Convex, Bolt e de IDEs com IA como o Cursor Por exemplo, se o desenvolvedor descrever algo como “um servidor de API em TypeScript com Supabase, Clerk e Stripe”, a IA monta automaticamente um projeto sob medida em segundos O starter gerado não é um template genérico, mas uma estrutura otimizada para a intenção e a stack do desenvolvedor Essa mudança também está transformando a estrutura de distribuição do ecossistema Em vez de alguns poucos frameworks ocuparem o centro do ecossistema como antes, está se espalhando um fluxo de geração personalizado que combina várias ferramentas e arquiteturas O ponto central deixa de ser escolher um framework e passa a ser explicar “o que você quer construir” Um desenvolvedor pode escolher a combinação de Next.js com tRPC, outro pode optar por Vite com React, e em ambos os casos é possível gerar imediatamente um projeto pronto para rodar Claro, as stacks padronizadas também têm vantagens: maior produtividade da equipe, onboarding mais eficiente, mais facilidade para depurar etc. Mas refatorar entre frameworks não é apenas um problema técnico; isso se entrelaça com produto, infraestrutura e capacidade organizacional O ponto de virada é justamente que o custo de trocar de framework caiu Agentes de IA passaram a entender a intenção do projeto e a executar grandes refatorações de forma semiautomática Com isso, ficou mais fácil experimentar, e surgiu mais espaço para testar diferentes stacks nas fases iniciais ou até voltar atrás Como resultado, a escolha de framework está se tornando reversível (decision reversible) Ex.: começar com Next.js, depois mudar para Remix + Vite, com o agente cuidando de toda a refatoração Com menos lock-in de framework, até stacks opinionated podem ser testadas sem grande peso 5. Além do .env: gerenciamento de segredos em ambientes centrados em agentes Durante décadas, arquivos .env foram a forma padrão de desenvolvedores gerenciarem localmente, de maneira simples, segredos como chaves de API, URLs de banco de dados e tokens de serviço Esse modelo é simples, portátil e amigável para desenvolvedores, mas começa a causar problemas quando IDEs com IA ou agentes escrevem código, implantam serviços e coordenam ambientes Em outras palavras, fica incerto quem é o verdadeiro “dono” do arquivo .env Está surgindo um movimento para resolver esse problema Por exemplo, a especificação mais recente do MCP inclui um framework de autenticação baseado em OAuth 2.1 Essa estrutura aponta para um modelo em que agentes de IA recebem tokens com escopo limitado, revogáveis (scope-based, revocable tokens), em vez de segredos brutos Ex.: em vez de dar ao agente uma chave completa da AWS, ele receberia uma credencial temporária que permite apenas ações restritas, como “fazer upload de arquivos para o S3” Outra tendência é o surgimento de brokers locais de segredos (secret brokers) Eles rodam localmente ou ao lado do app e atuam como serviços intermediários entre o agente e os segredos sensíveis Em vez de acessar diretamente o .env ou embutir segredos no código, o agente faz uma solicitação para uma tarefa específica, e o broker decide em tempo real e concede a permissão necessária Ex.: pedidos como “fazer deploy em staging” ou “enviar logs para o Sentry” O broker trata isso no modelo just-in-time, com todas as ações de acesso passíveis de auditoria Essa abordagem transforma o acesso a segredos de um modelo baseado em sistema de arquivos para um modelo de permissões via API Como resultado, o gerenciamento de segredos evolui da configuração com .env para uma estrutura de controle de acesso baseada em OAuth 6. Acessibilidade como interface universal: o app visto pela perspectiva do LLM Recentemente, apps como Granola e Highlight pedem permissões de acessibilidade no macOS, mas isso não é para o propósito tradicional de suporte a pessoas com deficiência, e sim para que agentes de IA possam observar e interagir com a UI Isso não deve ser visto como um hack temporário, mas como um sinal de uma mudança de interface mais fundamental As APIs de acessibilidade foram criadas originalmente para melhorar a acessibilidade digital de usuários com deficiência visual ou motora Mas, ao expandir esse uso, elas podem funcionar como uma camada de interface universal para agentes de IA Em vez de clicar em coordenadas de pixel ou fazer scraping do DOM, o agente pode observar e agir sobre o app de forma semântica, assim como uma tecnologia assistiva interpreta a UI A árvore de acessibilidade já expõe elementos de UI estruturados como botões, títulos e campos de entrada Se a isso forem adicionados metadados como intenção (intent), papel/função (role) e possibilidade de ação (affordance), os agentes poderão operar com precisão de acordo com o objetivo e o contexto Essa direção pode se expandir para funcionalidades como: Extração de contexto: consultar, via APIs de acessibilidade/semântica, quais elementos estão visíveis na tela, quais itens são interativos e qual é a ação atual do usuário Execução orientada por intenção: em vez de encadear manualmente várias chamadas de API, declarar um objetivo de alto nível, como “adicionar um item ao carrinho e escolher a entrega mais rápida”, e deixar o backend montar o procedimento de execução UI de fallback para LLMs: recursos de acessibilidade podem fornecer uma interface de backup para que agentes usem apps que não têm API pública Além da UI visual ou do DOM, o desenvolvedor pode definir uma superfície de renderização (render surface) reconhecível por agentes usando anotações estruturadas ou componentes centrados em acessibilidade Em resumo, as APIs de acessibilidade estão evoluindo para uma camada central de interface para a interação entre IA, sistemas e aplicativos, e não mais apenas um recurso voltado a humanos 7. A ascensão do trabalho assíncrono de agentes À medida que os desenvolvedores passam a colaborar de forma natural com agentes de escrita de código, a transição para fluxos de trabalho assíncronos está se acelerando Os agentes executam trabalhos em paralelo em segundo plano e, ao atingir determinado nível de progresso, reportam os resultados Essa interação está se aproximando cada vez mais de uma orquestração de tarefas (task orchestration) do que de pair programming Ou seja, o desenvolvedor transmite o objetivo, o agente executa e a checagem acontece depois O ponto importante não é apenas aliviar trabalho, mas comprimir a própria colaboração Por exemplo, em vez de pedir a outra equipe uma atualização de arquivo de configuração, triagem de erros ou refatoração de componentes, o desenvolvedor pode transmitir diretamente sua intenção ao agente e instruí-lo a processar isso em segundo plano Antes, eram necessárias reuniões síncronas, handoffs entre departamentos e ciclos longos de revisão, mas agora o loop de solicitar → gerar → validar (request → generate → validate) acontece de forma natural As formas de interagir com agentes também estão se expandindo Além de simplesmente inserir prompts no IDE ou na CLI, também são possíveis formas como: Solicitar tarefas por mensagem no Slack Escrever comentários em mockups no Figma Adicionar comentários inline em code diffs ou PRs (ex.: assistente de revisão do Graphite) Adicionar feedback em previews de aplicativos implantados Explicar verbalmente mudanças por meio de interfaces de voz ou baseadas em chamadas Essa mudança faz com que os agentes estejam presentes em todo o ciclo de vida do desenvolvimento Não se limitam a escrever código: também interpretam design, incorporam feedback e fazem triagem de bugs em toda a plataforma O desenvolvedor assume o papel de orquestrador (orchestrator), decidindo quais threads de trabalho avançar, excluir ou mesclar Esse movimento sugere, no fim das contas, a possibilidade de threads de trabalho baseadas em agentes se tornarem o novo conceito de “branch do Git” Em vez de um fork estático de código, seriam threads dinâmicas orientadas por objetivo, executadas de forma assíncrona e integradas quando concluídas 8. MCP: o Model Context Protocol um passo mais perto de se tornar um padrão universal Desde a publicação recente de um artigo de análise aprofundada sobre o MCP, a velocidade de adoção do MCP vem acelerando A OpenAI adotou oficialmente o MCP, vários novos recursos foram incorporados à especificação, e cada vez mais criadores de ferramentas estão aceitando o MCP como a interface padrão entre agentes e o mundo real O MCP, em essência, resolve dois problemas importantes: Fornece o contexto necessário para que LLMs possam executar até tarefas que encontram pela primeira vez Elimina integrações personalizadas no modelo N×M e simplifica para uma estrutura em que as ferramentas expõem uma interface padrão (servidor), utilizável por todos os agentes (clientes) Espera-se que a adoção do MCP continue se ampliando e, com o surgimento de MCP remoto e de um registro de MCP de facto (de-facto registry), muitos apps poderão ser lançados já trazendo uma interface MCP por padrão Assim como no passado as APIs permitiram conectar ferramentas SaaS e compor workflows, o MCP pode criar um ecossistema de componentes interoperáveis para agentes de IA Plataformas com cliente MCP embutido deixam de ser apenas “compatíveis com IA” e passam a fazer parte de um ecossistema conectado diretamente a uma rede de funcionalidades acessíveis por agentes Os clientes e servidores do MCP são apenas conceitos lógicos, não separados fisicamente Isso significa que qualquer cliente MCP pode se tornar um servidor, e vice-versa Isso abre espaço para um alto grau de composabilidade (composability), como: Ex.: um agente de programação pode, como cliente, buscar issues no GitHub e, ao mesmo tempo, como servidor, fornecer a outros agentes cobertura de testes ou resultados de análise de código O MCP está se consolidando como uma camada básica de interface para um ecossistema em que ferramentas e agentes interagem organicamente 9. Primitivos abstraídos: autenticação, pagamentos e armazenamento de que todo agente de IA precisa À medida que agentes de vibe coding ficam cada vez mais poderosos, uma coisa se torna clara: embora possam gerar muito código, esse código precisa de uma base confiável à qual se conectar Assim como desenvolvedores humanos dependem de Stripe para pagamentos, Clerk para autenticação e Supabase para banco de dados, os agentes também precisam de primitivos de serviço confiáveis e combináveis Esses serviços oferecem limites de API claros, SDKs fáceis de usar e configurações padrão razoáveis, e cada vez mais passam a atuar como a interface de runtime dos agentes Por exemplo, ao criar uma ferramenta que gera apps SaaS, em vez de o agente implementar diretamente um sistema de autenticação ou a lógica de pagamentos, ele integra Clerk e Stripe de forma rápida e segura Quando esse padrão amadurecer, os serviços poderão ir além de simplesmente fornecer APIs e também expor: Schema: definição de dados estruturados Capability metadata: especificação das ações que podem ser executadas Example flows: exemplos de como fazer a integração → isso permitirá que agentes integrem de forma mais estável Alguns serviços podem até ser lançados já com um servidor MCP embutido Ex.: a Clerk pode expor, por meio de um servidor MCP, recursos como consultar a lista de produtos disponíveis, criar um novo plano de preços ou modificar uma assinatura Em vez de procurar especificações de API ou documentação, o agente faz a solicitação em linguagem natural, e o servidor MCP valida e processa o pedido dentro do escopo de permissões e restrições Ex.: > “Crie um plano Pro de US$ 49 por mês e configure cobrança adicional por uso” → o servidor MCP da Clerk interpreta e executa essa solicitação Assim como rails new permitiu desenvolvimento rápido nos primórdios da web, na era dos agentes serão necessários primitivos confiáveis (identidade plug-and-play, pagamentos, controle de acesso etc.) Eles precisam ser suficientemente abstraídos para que agentes possam usá-los na geração, mas também devem ter uma estrutura capaz de escalar junto com o crescimento do app Conclusão Esses 9 padrões mostram que não se trata apenas de adicionar IA ao modo atual de desenvolvimento, mas de uma redefinição da própria forma de produzir software, centrada em agentes, contexto e intenção Com isso, os padrões de comportamento dos desenvolvedores também estão mudando, e novos toolchains e protocolos (como o MCP) estão surgindo rapidamente para dar suporte a essa mudança Camadas centrais de ferramentas tradicionais, como Git, templates, dashboards e formas de documentação, estão sendo fundamentalmente redesenhadas junto com a IA Diante dessa fase de transição, espera-se que a construção e o investimento em ferramentas e infraestrutura de nova geração para compor o novo ecossistema de desenvolvimento avancem ativamente

(a16z.com)

48 pontos por xguru 2025-05-26 | 8 comentários | Compartilhar no WhatsApp

Está se formando uma cultura de desenvolvimento que trata a IA não como uma simples ferramenta, mas como uma tecnologia de base
As formas tradicionais de controle de versão, dashboards, templates, documentação e gestão de segredos estão mudando para se adequar à era da IA
- O Git está sendo reinterpretado não mais como um sistema de acompanhamento de mudanças linha por linha no código, mas como um modelo de gerenciamento de estado centrado em prompts e resultados de testes
- Os agentes passam a ser autores e consumidores de código, aumentando a necessidade de redesenhar as próprias ferramentas
- Dashboards e UIs estão migrando para interfaces baseadas em linguagem natural, evoluindo para formatos usados em conjunto por pessoas e agentes de IA
- A documentação está se transformando em uma base de conhecimento para humanos e IA, sendo reorganizada em formatos que os agentes consigam entender

1. AI-Native Git: redefinindo o controle de versão para agentes de IA

O Git foi originalmente projetado para rastrear o histórico de mudanças linha a linha em código escrito diretamente por pessoas
- Mas, em um cenário em que a IA gera e modifica automaticamente grande parte do código, esse rastreamento detalhado se torna menos importante
- Os desenvolvedores passam a focar não mais nas mudanças em si, mas na adequação do comportamento resultante (se os testes passaram, se tudo funciona corretamente etc.)
- O SHA informa que houve uma mudança, mas não traz informação sobre por que ela ocorreu ou se ela é válida
- Especialmente em mudanças de grande escala ou em código gerado automaticamente, os desenvolvedores não revisam cada diff manualmente
Em um workflow AI-first, a combinação dos elementos abaixo se torna uma unidade mais útil
- Prompt: a entrada que orientou a geração do código
- Teste: o teste usado para validar o comportamento esperado
- Spec e constraints: requisitos de projeto, como especificações e restrições
- Esses elementos passam a ser tratados e rastreados como um único bundle versionável
Levando isso um passo adiante, em um workflow orientado por agentes, a Source of Truth pode se mover upstream em direção a prompts, esquemas de dados, contratos de API e intenção arquitetural
- Como resultado, o código passa a ser tratado como um artefato compilado, ou seja, como um subproduto dessas entradas, e não como a fonte principal
- O Git passa a funcionar não como workspace de código, mas como um artifact log
  - Quem gerou o código, com qual modelo e usando qual prompt
  - Quais testes passaram
  - E metadados como quais partes precisam de revisão humana
O histórico de mudanças inclui prompts, objetivo, testes relacionados e informações sobre o modelo que gerou o código
- Com integração a ferramentas de revisão por IA como o Diamond, torna-se possível criar fluxos automatizados de review
- Também é possível estruturar metadados mais ricos em camadas, como a separação entre código gerado por agentes e áreas protegidas mantidas por humanos
Em um possível workflow de AI-Native Git
- Pode surgir um novo tipo de dashboard do Git, mostrando em conjunto prompts, fluxo de mudanças derivado deles, resultados de testes, informações sobre os agentes envolvidos e dados do bundle

2. Dashboards → Synthesis: evolução para interfaces dinâmicas baseadas em IA

Durante anos, dashboards serviram como a principal interface para interagir com sistemas complexos, como sistemas de observabilidade, ferramentas analíticas e consoles de nuvem (AWS etc.)
- No entanto, o excesso de controles, gráficos e abas gerou sobrecarga de UX, fazendo com que os usuários frequentemente se percam entre explorar informações e executar ações
- Especialmente para não especialistas ou em cenários de colaboração entre várias equipes, esses dashboards podem ser percebidos como ferramentas intimidantes e ineficientes
- Muitas vezes, o usuário sabe o que quer alcançar, mas não sabe onde procurar nem quais filtros aplicar
A geração mais recente de modelos de IA aponta uma possibilidade de resolver esse problema
- Ela permite reinterpretar o dashboard não como uma tela fixa, mas como um espaço de exploração e interação
Um LLM pode apoiar o usuário das seguintes formas:
- Localização de controles, como em “Onde altero a configuração de rate limit desta API?”
- Resumo integrado de dados, como em “Resuma a tendência de erros de todos os serviços no ambiente de staging nas últimas 24 horas”
- Sugestão de insights ocultos, como em “Com base no meu contexto de negócio, recomende as métricas que devo acompanhar neste trimestre”
Hoje, tecnologias como Assistant UI já permitem que agentes usem componentes React como se fossem ferramentas
- Assim como o conteúdo se torna dinâmico e personalizado, a própria UI também está sendo recomposta conforme a intenção do usuário e evoluindo para um formato conversacional
- Dashboards estáticos podem em breve ser vistos como ultrapassados
- Exemplo:
  - Se o usuário disser “Mostre as anomalias ocorridas na Europa no último fim de semana”, logs resumidos e tendências são apresentados automaticamente, sem que ele precise manipular filtros manualmente
  - Diante da pergunta “Por que a pontuação de NPS caiu na semana passada?”, a IA pode oferecer análise de sentimento das pesquisas, correlação com deploys de produto e um resumo diagnóstico
Em uma visão mais ampla, se agentes se tornarem consumidores de software, o próprio conceito de dashboard também precisará ser redesenhado
- Por exemplo, um dashboard pode renderizar visões otimizadas para Agent Experience
  - Fornecendo interfaces estruturadas e acessíveis programaticamente para que o sistema reconheça estado, tome decisões e execute ações
- Como resultado, pode surgir uma estrutura de interface dupla, com uma UI para humanos e outra para agentes
  - As duas UIs compartilham o mesmo estado, mas são organizadas de forma diferente conforme o modo de consumo
Os agentes passam a assumir o papel antes desempenhado por alertas, cron jobs e automações condicionais, mas como executores com muito mais contexto e flexibilidade
Exemplo:
- Antes: if error rate > threshold then send alert
- Baseado em agentes: “A taxa de erro está subindo. A causa é este serviço, e estes são os componentes afetados e as ações recomendadas”
Assim, o dashboard deixa de ser apenas um lugar de observação e passa a ser um espaço onde humanos e IA colaboram, integram informações e executam ações

3. Documentação está evoluindo para uma combinação de ferramenta, índice e base de conhecimento interativa

A forma como os desenvolvedores usam documentação está mudando
- Antes, era comum ler seguindo o índice ou percorrer uma spec de cima para baixo, mas agora “fazer a pergunta primeiro” está se tornando o padrão
- Em vez de “vou estudar esta spec”, surge a mudança de mentalidade para “reorganize a informação do jeito que eu quero”
- Essa mudança também afeta o formato da documentação, que está evoluindo não para HTML ou Markdown estático, mas para um sistema de conhecimento interativo sustentado por índices, embeddings e agentes com reconhecimento de ferramentas
Com isso, ferramentas como Mintlify estão ganhando espaço
- A Mintlify não apenas organiza a documentação como um banco de dados pesquisável por significado, como também a usa como fonte de contexto para agentes em diversas plataformas
  - Ex.: em AI IDEs, extensões do VS Code e agentes de terminal, a documentação do Mintlify é usada como material de referência em tempo real
- Isso acontece porque agentes de geração de código usam a documentação atualizada como contexto baseado em aprendizado
Com isso, o próprio objetivo da documentação está mudando
- A documentação deixa de ser apenas um meio de transmissão de informação para leitores humanos e passa a precisar ser desenhada como uma estrutura para consumidores-agentes
- Nessa nova dinâmica, a documentação passa a funcionar como um manual de instruções para agentes de IA
- Não se trata apenas de expor conteúdo, mas de explicar como o sistema pode ser usado corretamente

4. De templates para geração: vibe coding substituindo o create-react-app

No passado, era comum começar um projeto escolhendo templates estáticos como create-react-app, next init e rails new
- Esses templates forneciam uma estrutura de app consistente, mas era difícil personalizá-los de acordo com a intenção do desenvolvedor ou a stack, e era preciso seguir os padrões definidos pelo framework
- Como resultado, sair da configuração padrão exigia muito refatoramento manual
Agora, esse fluxo está mudando com o surgimento de plataformas text-to-app como Replit, Same.dev, Loveable, Chef by Convex, Bolt e de IDEs com IA como o Cursor
- Por exemplo, se o desenvolvedor descrever algo como “um servidor de API em TypeScript com Supabase, Clerk e Stripe”, a IA monta automaticamente um projeto sob medida em segundos
- O starter gerado não é um template genérico, mas uma estrutura otimizada para a intenção e a stack do desenvolvedor
Essa mudança também está transformando a estrutura de distribuição do ecossistema
- Em vez de alguns poucos frameworks ocuparem o centro do ecossistema como antes, está se espalhando um fluxo de geração personalizado que combina várias ferramentas e arquiteturas
- O ponto central deixa de ser escolher um framework e passa a ser explicar “o que você quer construir”
- Um desenvolvedor pode escolher a combinação de Next.js com tRPC, outro pode optar por Vite com React, e em ambos os casos é possível gerar imediatamente um projeto pronto para rodar
Claro, as stacks padronizadas também têm vantagens:
- maior produtividade da equipe, onboarding mais eficiente, mais facilidade para depurar etc.
- Mas refatorar entre frameworks não é apenas um problema técnico; isso se entrelaça com produto, infraestrutura e capacidade organizacional
O ponto de virada é justamente que o custo de trocar de framework caiu
- Agentes de IA passaram a entender a intenção do projeto e a executar grandes refatorações de forma semiautomática
- Com isso, ficou mais fácil experimentar, e surgiu mais espaço para testar diferentes stacks nas fases iniciais ou até voltar atrás
Como resultado, a escolha de framework está se tornando reversível (decision reversible)
- Ex.: começar com Next.js, depois mudar para Remix + Vite, com o agente cuidando de toda a refatoração
Com menos lock-in de framework, até stacks opinionated podem ser testadas sem grande peso

5. Além do `.env`: gerenciamento de segredos em ambientes centrados em agentes

Durante décadas, arquivos .env foram a forma padrão de desenvolvedores gerenciarem localmente, de maneira simples, segredos como chaves de API, URLs de banco de dados e tokens de serviço
- Esse modelo é simples, portátil e amigável para desenvolvedores, mas começa a causar problemas quando IDEs com IA ou agentes escrevem código, implantam serviços e coordenam ambientes
- Em outras palavras, fica incerto quem é o verdadeiro “dono” do arquivo .env
Está surgindo um movimento para resolver esse problema
- Por exemplo, a especificação mais recente do MCP inclui um framework de autenticação baseado em OAuth 2.1
- Essa estrutura aponta para um modelo em que agentes de IA recebem tokens com escopo limitado, revogáveis (scope-based, revocable tokens), em vez de segredos brutos
- Ex.: em vez de dar ao agente uma chave completa da AWS, ele receberia uma credencial temporária que permite apenas ações restritas, como “fazer upload de arquivos para o S3”
Outra tendência é o surgimento de brokers locais de segredos (secret brokers)
- Eles rodam localmente ou ao lado do app e atuam como serviços intermediários entre o agente e os segredos sensíveis
- Em vez de acessar diretamente o .env ou embutir segredos no código, o agente faz uma solicitação para uma tarefa específica, e o broker decide em tempo real e concede a permissão necessária
  - Ex.: pedidos como “fazer deploy em staging” ou “enviar logs para o Sentry”
  - O broker trata isso no modelo just-in-time, com todas as ações de acesso passíveis de auditoria
Essa abordagem transforma o acesso a segredos de um modelo baseado em sistema de arquivos para um modelo de permissões via API
- Como resultado, o gerenciamento de segredos evolui da configuração com .env para uma estrutura de controle de acesso baseada em OAuth

6. Acessibilidade como interface universal: o app visto pela perspectiva do LLM

Recentemente, apps como Granola e Highlight pedem permissões de acessibilidade no macOS, mas isso não é para o propósito tradicional de suporte a pessoas com deficiência, e sim para que agentes de IA possam observar e interagir com a UI
- Isso não deve ser visto como um hack temporário, mas como um sinal de uma mudança de interface mais fundamental
As APIs de acessibilidade foram criadas originalmente para melhorar a acessibilidade digital de usuários com deficiência visual ou motora
- Mas, ao expandir esse uso, elas podem funcionar como uma camada de interface universal para agentes de IA
- Em vez de clicar em coordenadas de pixel ou fazer scraping do DOM, o agente pode observar e agir sobre o app de forma semântica, assim como uma tecnologia assistiva interpreta a UI
- A árvore de acessibilidade já expõe elementos de UI estruturados como botões, títulos e campos de entrada
- Se a isso forem adicionados metadados como intenção (intent), papel/função (role) e possibilidade de ação (affordance), os agentes poderão operar com precisão de acordo com o objetivo e o contexto
Essa direção pode se expandir para funcionalidades como:
- Extração de contexto: consultar, via APIs de acessibilidade/semântica, quais elementos estão visíveis na tela, quais itens são interativos e qual é a ação atual do usuário
- Execução orientada por intenção: em vez de encadear manualmente várias chamadas de API, declarar um objetivo de alto nível, como “adicionar um item ao carrinho e escolher a entrega mais rápida”, e deixar o backend montar o procedimento de execução
- UI de fallback para LLMs: recursos de acessibilidade podem fornecer uma interface de backup para que agentes usem apps que não têm API pública
  - Além da UI visual ou do DOM, o desenvolvedor pode definir uma superfície de renderização (render surface) reconhecível por agentes usando anotações estruturadas ou componentes centrados em acessibilidade
Em resumo, as APIs de acessibilidade estão evoluindo para uma camada central de interface para a interação entre IA, sistemas e aplicativos, e não mais apenas um recurso voltado a humanos

7. A ascensão do trabalho assíncrono de agentes

À medida que os desenvolvedores passam a colaborar de forma natural com agentes de escrita de código, a transição para fluxos de trabalho assíncronos está se acelerando
- Os agentes executam trabalhos em paralelo em segundo plano e, ao atingir determinado nível de progresso, reportam os resultados
- Essa interação está se aproximando cada vez mais de uma orquestração de tarefas (task orchestration) do que de pair programming
- Ou seja, o desenvolvedor transmite o objetivo, o agente executa e a checagem acontece depois
O ponto importante não é apenas aliviar trabalho, mas comprimir a própria colaboração
- Por exemplo, em vez de pedir a outra equipe uma atualização de arquivo de configuração, triagem de erros ou refatoração de componentes,
  o desenvolvedor pode transmitir diretamente sua intenção ao agente e instruí-lo a processar isso em segundo plano
- Antes, eram necessárias reuniões síncronas, handoffs entre departamentos e ciclos longos de revisão,
  mas agora o loop de solicitar → gerar → validar (request → generate → validate) acontece de forma natural
As formas de interagir com agentes também estão se expandindo
- Além de simplesmente inserir prompts no IDE ou na CLI, também são possíveis formas como:
  - Solicitar tarefas por mensagem no Slack
  - Escrever comentários em mockups no Figma
  - Adicionar comentários inline em code diffs ou PRs (ex.: assistente de revisão do Graphite)
  - Adicionar feedback em previews de aplicativos implantados
  - Explicar verbalmente mudanças por meio de interfaces de voz ou baseadas em chamadas
Essa mudança faz com que os agentes estejam presentes em todo o ciclo de vida do desenvolvimento
- Não se limitam a escrever código: também interpretam design, incorporam feedback e fazem triagem de bugs em toda a plataforma
- O desenvolvedor assume o papel de orquestrador (orchestrator), decidindo quais threads de trabalho avançar, excluir ou mesclar
Esse movimento sugere, no fim das contas, a possibilidade de threads de trabalho baseadas em agentes se tornarem o novo conceito de “branch do Git”
- Em vez de um fork estático de código, seriam threads dinâmicas orientadas por objetivo, executadas de forma assíncrona e integradas quando concluídas

8. MCP: o Model Context Protocol um passo mais perto de se tornar um padrão universal

Desde a publicação recente de um artigo de análise aprofundada sobre o MCP, a velocidade de adoção do MCP vem acelerando
A OpenAI adotou oficialmente o MCP, vários novos recursos foram incorporados à especificação, e cada vez mais criadores de ferramentas estão aceitando o MCP como a interface padrão entre agentes e o mundo real
O MCP, em essência, resolve dois problemas importantes:
- Fornece o contexto necessário para que LLMs possam executar até tarefas que encontram pela primeira vez
- Elimina integrações personalizadas no modelo N×M e simplifica para uma estrutura em que as ferramentas expõem uma interface padrão (servidor), utilizável por todos os agentes (clientes)
Espera-se que a adoção do MCP continue se ampliando e,
com o surgimento de MCP remoto e de um registro de MCP de facto (de-facto registry),
muitos apps poderão ser lançados já trazendo uma interface MCP por padrão
Assim como no passado as APIs permitiram conectar ferramentas SaaS e compor workflows,
o MCP pode criar um ecossistema de componentes interoperáveis para agentes de IA
Plataformas com cliente MCP embutido deixam de ser apenas “compatíveis com IA” e passam a fazer parte de um ecossistema conectado diretamente a uma rede de funcionalidades acessíveis por agentes
Os clientes e servidores do MCP são apenas conceitos lógicos, não separados fisicamente
- Isso significa que qualquer cliente MCP pode se tornar um servidor, e vice-versa
- Isso abre espaço para um alto grau de composabilidade (composability), como:
  - Ex.: um agente de programação pode, como cliente, buscar issues no GitHub e, ao mesmo tempo, como servidor, fornecer a outros agentes cobertura de testes ou resultados de análise de código
O MCP está se consolidando como uma camada básica de interface para um ecossistema em que ferramentas e agentes interagem organicamente

9. Primitivos abstraídos: autenticação, pagamentos e armazenamento de que todo agente de IA precisa

À medida que agentes de vibe coding ficam cada vez mais poderosos, uma coisa se torna clara:
embora possam gerar muito código, esse código precisa de uma base confiável à qual se conectar
Assim como desenvolvedores humanos dependem de Stripe para pagamentos, Clerk para autenticação e Supabase para banco de dados,
os agentes também precisam de primitivos de serviço confiáveis e combináveis
Esses serviços oferecem limites de API claros, SDKs fáceis de usar e configurações padrão razoáveis,
e cada vez mais passam a atuar como a interface de runtime dos agentes
Por exemplo, ao criar uma ferramenta que gera apps SaaS, em vez de o agente implementar diretamente um sistema de autenticação ou a lógica de pagamentos,
ele integra Clerk e Stripe de forma rápida e segura
Quando esse padrão amadurecer, os serviços poderão ir além de simplesmente fornecer APIs e também expor:
- Schema: definição de dados estruturados
- Capability metadata: especificação das ações que podem ser executadas
- Example flows: exemplos de como fazer a integração
  → isso permitirá que agentes integrem de forma mais estável
Alguns serviços podem até ser lançados já com um servidor MCP embutido
- Ex.: a Clerk pode expor, por meio de um servidor MCP, recursos como consultar a lista de produtos disponíveis, criar um novo plano de preços ou modificar uma assinatura
- Em vez de procurar especificações de API ou documentação, o agente faz a solicitação em linguagem natural,
  e o servidor MCP valida e processa o pedido dentro do escopo de permissões e restrições
- Ex.:
  > “Crie um plano Pro de US$ 49 por mês e configure cobrança adicional por uso”
  → o servidor MCP da Clerk interpreta e executa essa solicitação
Assim como rails new permitiu desenvolvimento rápido nos primórdios da web,
na era dos agentes serão necessários primitivos confiáveis (identidade plug-and-play, pagamentos, controle de acesso etc.)
- Eles precisam ser suficientemente abstraídos para que agentes possam usá-los na geração,
  mas também devem ter uma estrutura capaz de escalar junto com o crescimento do app

Conclusão

Esses 9 padrões mostram que não se trata apenas de adicionar IA ao modo atual de desenvolvimento, mas de uma redefinição da própria forma de produzir software, centrada em agentes, contexto e intenção
Com isso, os padrões de comportamento dos desenvolvedores também estão mudando, e novos toolchains e protocolos (como o MCP) estão surgindo rapidamente para dar suporte a essa mudança
Camadas centrais de ferramentas tradicionais, como Git, templates, dashboards e formas de documentação, estão sendo fundamentalmente redesenhadas junto com a IA
Diante dessa fase de transição, espera-se que a construção e o investimento em ferramentas e infraestrutura de nova geração para compor o novo ecossistema de desenvolvimento avancem ativamente

8 comentários

aa1567 2025-05-28

Tem gente que realmente faz a opção 1...?

hhcrux 2025-05-27

Os LLMs não garantem a mesma saída para a mesma entrada; será que um controle de versão desse jeito funciona mesmo...?
Será que eu ainda estou usando isso de forma unidimensional demais?

beoks 2025-05-27

Pelo que eu sei, definir a opção temperature como 0 garante a mesma saída para a mesma entrada.

fanotify 2025-05-28

De qualquer forma, em alguns meses o próprio modelo vai mudar de novo, então isso não seria sem sentido?

beoks 2025-05-27

Deixando isso de lado, é categórico demais presumir que nem se considera a intervenção humana,
no caso de ajustes simples em números ou mensagens, a intervenção humana tende a ser mais eficiente do que um LLM.

nicewook 2025-05-26

É um texto que transmite uma percepção profunda. Como esperado da a16z.

ruinnel 2025-05-26

https://pt.news.hada.io/topic?id=21091
Depois de ler este texto, fico pensando se isso está mesmo certo.

ahwjdekf 2025-05-26

O item 1 é realmente uma mudança digna de pesadelo, algo que eu jamais gostaria de aceitar. É como ver o rastreamento do histórico do código-fonte se tornar sem sentido.