Quando os agentes de IA viram parte da capacidade de entrega, uma AI Developer Platform passa a servir Developers humanos e artificiais. A alternativa é cada time seguir por conta própria, com o custo que isso acumula.

De licença de copiloto a estratégia de plataforma

Hoje 84% dos desenvolvedores já usam ou planejam usar ferramentas de IA no trabalho (Stack Overflow, 2025). A adoção aconteceu de baixo para cima, squad por squad, cada um escolhendo seu copiloto, seu agente e seu modelo. O resultado é fragmentação: uma organização de mil funcionários opera em média de 14 a 18 ferramentas de IA, e apenas 4 a 6 passaram por uma revisão formal de segurança (levantamentos de mercado, 2025).

No Brasil, o buraco de governança é ainda mais visível. Oito em cada dez empresas brasileiras ainda não têm uma política formal de governança de IA, enquanto o custo médio de uma violação de dados no país chega a R$ 7,19 milhões (IBM, Cost of a Data Breach 2025). Cada ferramenta adotada sem coordenação central soma capacidade no curto prazo e risco no médio. Sem uma base comum, essa adoção espontânea vira o que o mercado começou a chamar de passivo invisível: ferramentas de IA em uso que não entram em nenhum inventário e que ninguém governa.

A conta também aparece no custo direto. Licenciar IA de forma fragmentada, cada time com seu contrato, custa entre US$ 1.800 e US$ 2.800 por usuário ao ano, contra US$ 800 a US$ 1.400 quando a empresa consolida numa plataforma única (estimativas de 2025). Somando o gasto duplicado à exposição de segurança, o número fica difícil de defender diante do board.

Distribuir licenças de copiloto para os times resolve o acesso individual de cada desenvolvedor. A capacidade de entrega da empresa como um todo depende de algo maior: uma base comum sobre a qual humanos e agentes trabalhem com os mesmos modelos aprovados, o mesmo contexto, as mesmas políticas e a mesma observabilidade. Essa base tem nome, AI Developer Platform, e é uma decisão de arquitetura, não de compra de ferramenta.

O que compõe uma AI Developer Platform

Uma plataforma de desenvolvimento para a era da IA reúne, num lugar governado, o que hoje está espalhado por times e contas pessoais. Pensar nos componentes ajuda a enxergar o tamanho da lacuna.

Componente	O que entrega
Modelos aprovados	Catálogo de modelos homologados, com custo e política de uso definidos
Coding agents	Agentes de desenvolvimento disponíveis de forma padronizada, não por conta de cada time
Templates e golden paths	Caminhos prontos para tarefas recorrentes (criar API, subir serviço, migrar)
Contexto e integrações	Acesso governado a repositórios, dados e sistemas, por um padrão comum
Ambientes	Ambientes de desenvolvimento e teste consistentes para pessoas e agentes
Políticas e permissões	Regras de segurança, permissão mínima e aprovação para ações sensíveis
Observabilidade e avaliação	Rastreio do que os agentes fazem e avaliação da qualidade do que produzem
Gestão de custos	Visibilidade e controle do gasto com modelos e ferramentas

Nenhum desses itens é novo para quem já pensa engenharia de plataforma. O que muda é que a plataforma agora precisa atender também um novo tipo de usuário: o agente.

Dois componentes concentram a maior parte do risco quando ficam de fora. As integrações governadas definem como o agente acessa repositórios, dados e sistemas por um padrão comum, o território de Tool Use e MCP. A avaliação mede se o que o agente produz é confiável antes de ir para produção. Uma plataforma que oferece modelos e agentes sem esses dois vira uma vitrine de capacidade, sem controle do que essa capacidade faz na prática.

Uma plataforma para humanos e agentes

A ideia de Internal Developer Platform nasceu para reduzir a carga cognitiva de quem desenvolve, oferecendo ferramentas, ambientes e caminhos prontos para o time focar no problema de negócio. A pesquisa de produtividade da Spotify já mostrava, em 2023, que desenvolvedores gastavam de 30% a 40% do tempo em tarefas de infraestrutura sem relação com a lógica de negócio (Spotify, 2023).

Com agentes de IA participando da entrega, essa mesma plataforma ganha um segundo público. O agente precisa das mesmas coisas que a pessoa precisa: modelos confiáveis, contexto correto, ambiente isolado, política clara de permissão e um lugar onde suas ações ficam registradas. Uma plataforma que serve só o desenvolvedor humano deixa o agente operar em terra de ninguém, e é ali que o risco cresce sem ninguém olhando.

Tratar o agente como usuário de primeira classe da plataforma organiza o que a adoção espontânea deixa solto. Em vez de cada squad conectar um agente do seu jeito, a empresa oferece um caminho comum, com o controle embutido desde o início.

Golden paths: velocidade com trilhos

O conceito que amarra tudo isso vem da Spotify, que cunhou o termo golden path. Um golden path é um caminho recomendado e suportado para uma tarefa comum de engenharia, com as boas escolhas já embutidas. O desenvolvedor que segue o trilho ganha velocidade e cai automaticamente dentro das políticas da empresa.

Na era dos agentes, os golden paths cobrem tarefas que se repetem: criar um serviço novo, subir uma API, gerar testes, abrir um pull request de agente, escolher o modelo certo para um caso. Cada trilho carrega segurança, padrão e observabilidade por baixo, sem exigir que cada time redescubra o caminho.

Um exemplo deixa concreto. O golden path de criar um novo microsserviço já entrega o template do repositório, o pipeline de CI, as políticas de segurança, o modelo de IA aprovado para geração de código e a observabilidade ligada. O desenvolvedor, ou o agente, pede um serviço novo e recebe tudo isso configurado de uma vez, com a governança embutida no ponto de partida. A alternativa comum é cada time montar essas peças na mão, esquecer metade e descobrir a lacuna quando algo quebra em produção.

O retorno aparece nos números de quem tem plataforma madura. O relatório DORA de 2025 apontou que organizações com plataformas maduras alcançaram frequência de deploy 3,5 vezes maior e tempo de entrega até 4 vezes menor, com níveis mais baixos de esgotamento das equipes (DORA, 2025). Velocidade e controle andam juntos quando o caminho fácil também é o caminho certo.

Construir ou comprar

A pergunta de build vs buy chega cedo nessa conversa, e a resposta honesta depende de contexto. Comprar uma plataforma pronta acelera o começo e traz práticas já maduras, ao custo de aderência menor às particularidades da empresa. Construir dá controle total e encaixe fino no ambiente existente, ao custo de tempo, time dedicado e manutenção contínua.

O critério útil não é ideológico. Ele passa por quão específico é o seu ambiente, quanto de time de plataforma você consegue sustentar, e quão rápido a capacidade precisa estar de pé. A maioria das empresas acaba num modelo híbrido, comprando a base e construindo os golden paths que refletem o jeito próprio de operar. O erro comum é não decidir, e deixar a plataforma nascer por acidente, como soma de escolhas isoladas de cada time.

Um caminho pragmático é começar pequeno e visível. Escolher um golden path de alto uso, o de criar um serviço ou o de abrir um pull request de agente, e transformá-lo em padrão antes de tentar cobrir a plataforma inteira. Um trilho bem-feito, adotado de verdade, prova o valor e financia o próximo, com muito menos risco do que um projeto de plataforma de dois anos que promete resolver tudo de uma vez e entrega tarde.

O novo papel da engenharia de plataforma

Nada disso é tendência distante. O Gartner projeta que 80% das grandes organizações de engenharia de software terão times dedicados de plataforma até 2026, ante 45% em 2022 (Gartner). A função deixou de ser um luxo de empresa grande e virou parte do padrão de quem entrega software em escala.

O que a IA acrescenta é uma mudança de papel. A engenharia de plataforma sai de provedora de ferramentas e assume a curadoria do sistema produtivo inteiro, o conjunto de modelos, agentes, dados, políticas e trilhos sobre o qual a empresa constrói. É a área que decide qual modelo entra no catálogo, qual golden path vira padrão e qual permissão um agente recebe. Numa organização que leva IA a sério na engenharia, esse papel decide se a adoção vira vantagem estruturada ou dívida espalhada.

Essa curadoria não acontece no vácuo. Ela reúne decisões que a engenharia já vem tomando peça por peça: a especificação que orienta o agente, o contexto que ele recebe, os testes que validam seu trabalho e a governança que controla suas permissões. A plataforma é onde esse conjunto ganha um lugar comum, com padrão e visibilidade, em vez de viver espalhado na cabeça de cada líder técnico e no setup particular de cada squad.

Perguntas que a liderança faz sobre AI Developer Platform

O que é uma AI Developer Platform?

É a plataforma de engenharia que oferece, de forma governada, os recursos que humanos e agentes de IA precisam para desenvolver: modelos aprovados, agentes, contexto, ambientes, políticas, observabilidade e controle de custo.

O que é um golden path?

É um caminho recomendado e suportado para uma tarefa comum de engenharia, com as boas escolhas de segurança e padrão já embutidas. Quem segue o trilho ganha velocidade e cai dentro das políticas da empresa.

Qual a diferença entre Internal Developer Platform e AI Developer Platform?

A Internal Developer Platform serve o desenvolvedor humano. A AI Developer Platform estende a mesma ideia para atender também agentes de IA como usuários, com modelos, contexto e permissões governados.

Construir ou comprar?

Depende da especificidade do ambiente, do tamanho do time de plataforma e da urgência. A maioria adota um modelo híbrido: compra a base e constrói os golden paths que refletem seu jeito de operar. O caminho de menor risco é começar por um trilho de alto uso, prová-lo e expandir a partir dali, em vez de tentar cobrir a plataforma inteira de uma vez.

Por onde começar

A adoção de IA na engenharia já aconteceu, ferramenta por ferramenta, time por time. A decisão que ainda está aberta na maioria das empresas é se isso vira um sistema produtivo governado ou um acúmulo de ferramentas sem dono. A plataforma é o que separa esses dois destinos, e pensá-la é uma conversa de arquitetura antes de ser uma conversa de compra.

Esse é o mesmo terreno da engenharia invisível na era de IA, a infraestrutura que sustenta a operação sem aparecer, e da arquitetura de referência que vira o golden path da empresa. Se a sua engenharia já tem agentes e copilotos espalhados pelos times, vale desenhar a plataforma agora, enquanto dá para escolher o padrão, e não depois, quando cada exceção já virou regra.