Construído de dentro para fora: como o AWS Professional Services virou uma equipe de fronteira em IA

Uma virada de chave no modelo de consultoria da AWS

O AWS Professional Services (AWS ProServe) conseguiu comprimir prazos de engajamento que antes levavam meses para apenas dias. Mas o que chama atenção não é o resultado em si — é o caminho. A mudança não veio de adicionar ferramentas de Inteligência Artificial (IA) sobre processos antigos. Veio de reconstruir completamente a forma de entregar, de dentro para fora.

Essa abordagem ecoa o que foi descrito no artigo Como Equipes de Fronteira estão Reinventando o Desenvolvimento Nativo em IA: os ganhos reais de produtividade surgem quando se reimagina como o software é construído, não quando se empilha IA sobre fluxos de trabalho que já existiam.

O que é uma equipe de fronteira?

No contexto da AWS, uma “equipe de fronteira” é aquela que absorveu o desenvolvimento nativo em IA como parte do seu dia a dia — não como experimento, não como piloto, mas como o modo padrão de operar. Segundo a AWS, qualquer organização pode se tornar uma equipe desse tipo. Para quem quiser acelerar esse processo com apoio especializado, o AWS ProServe se posiciona como um parceiro que já percorreu esse caminho.

O desenvolvimento nativo em IA opera em um ritmo que o modelo tradicional de consultoria não foi projetado para acompanhar. Trabalhos que antes ocupavam meses se comprimem em dias. Os ciclos ficam mais curtos, o feedback é mais rápido, e decisões passam a ser tomadas no próprio fluxo da construção. Para ajudar clientes a operarem nesse ritmo, os consultores precisam saber quais decisões podem ser tomadas rapidamente, quais exigem julgamento humano cuidadoso, e como manter a qualidade quando a velocidade de execução aumenta. Essa intuição só vem com a prática.

O objetivo central do AWS ProServe foi liberar os consultores das tarefas que não envolvem código — documentação, coordenação, relatórios de status, scaffolding repetitivo — que consumiam grande parte de cada engajamento. Com isso, o julgamento humano passou a se concentrar onde realmente gera resultado.

O time APEX: a equipe que redesenhou o modelo

O AWS ProServe começou sua jornada como um “pathfinder” — uma equipe pioneira que explora o caminho antes dos demais. Essa equipe foi batizada de APEX, sigla para Agentic AI ProServe Experiences (Experiências de IA Agêntica do ProServe).

O mandato do APEX era único: redesenhar a forma como o ProServe entrega. Para isso, o APEX construiu o ProServe Delivery Agent, um sistema multi-agente que cobre todo o ciclo de vida de uma entrega: levantamento de requisitos, validação de arquitetura, implementação, revisão de segurança, testes e implantação. Um agente supervisor orquestra sub-agentes especializados em cada fase.

O Delivery Agent é a implementação prática do AI-DLC, o Ciclo de Vida de Desenvolvimento Orientado por IA (AI-Driven Development Lifecycle). O AI-DLC foi construído por equipes de campo da AWS e refinado ao longo de centenas de workshops práticos com clientes. O desenvolvimento nativo em IA é a base; o AI-DLC é o processo que a AWS construiu para executá-lo em um ciclo de entrega completo — tanto internamente quanto para seus clientes.

O APEX validou o modelo em suas próprias cargas de trabalho de produção antes de levá-lo a clientes. Hoje, o Delivery Agent trabalha ao lado de consultores humanos em engajamentos globais, e os padrões validados pelo APEX estão se tornando o modelo padrão de entrega em todo o ProServe. Não se trata de um piloto — é o modo como a AWS entrega em escala.

Como o modelo de entrega foi redesenhado

Um engajamento típico do ProServe seguia um ritmo familiar de consultoria: descoberta em documentos extensos, decisões arquiteturais debatidas em workshops, implementação em sprints, testes e revisão de segurança nas bordas das fases. Cada handoff introduzia atrasos, e cada artefato era escrito apenas para consumo humano.

O redesenho mudou cada etapa desse processo:

• Requisitos saíram de textos em prosa e passaram a ser especificações estruturadas que tanto humanos quanto agentes conseguem interpretar — tornando-se a fonte da verdade, não um subproduto.
• Padrões arquiteturais e lições de projetos anteriores foram codificados em arquivos de direcionamento que os agentes consultam continuamente.
• Implementação deixou de ser serial (um ticket por vez) e passou a ser paralela, com consultores alimentando múltiplos agentes simultaneamente com tarefas bem delimitadas.
• Testes e revisão de segurança foram incorporados ao próprio ciclo de construção, com agentes validando saídas localmente e se autocorrigindo antes de qualquer revisão humana.
• Relatórios de status e overhead de coordenação praticamente desapareceram.

O resultado líquido é um fluxo contínuo, com o julgamento humano concentrado em priorização, validação e decisões de alto impacto.

Construindo o Delivery Agent com o próprio Delivery Agent

Uma das práticas mais interessantes do APEX é que ele constrói o Delivery Agent usando as mesmas práticas nativas em IA que oferece aos clientes. Uma solicitação de funcionalidade entra no sistema; os agentes geram tickets estruturados, produzem código e executam testes automatizados por meio de um pipeline DevOps integrado ao GitLab. Após revisão e aprovação humana, a mudança é implantada.

Os humanos cuidam do julgamento: priorizar, validar qualidade, aprovar decisões de alto impacto. Os agentes cuidam do scaffolding. Decisões de baixo risco rodam de forma autônoma. Os pontos de controle humano se concentram onde o julgamento realmente importa.

À medida que equipes de entrega em todo o ProServe adotam o Delivery Agent em seus projetos, elas retroalimentam o sistema com aprendizados — tornando-o mais preciso a cada projeto. É assim que a Amazon constrói: usa seus próprios produtos, observa o que quebra e corrige.

As cinco práticas que sustentam o modelo

Cinco práticas descritas pela AWS definem como o AI-DLC opera dentro do ProServe:

• Desacelere para acelerar. Equipes de fronteira investem antes de acelerar — constroem o contexto dos agentes e padronizam as práticas antes de ganhar velocidade. O APEX fez esse investimento uma vez, e agora transfere esse aprendizado diretamente para os clientes, sem que cada um precise começar do zero.
• Invista pesado no contexto dos agentes. Arquivos de direcionamento e padrões arquiteturais são artefatos de primeira ordem em cada engajamento. Quanto mais rico o contexto, mais autonomia o agente pode exercer com segurança.
• Alimente os agentes em vez de babá-los. Os construtores mantêm um backlog constante de tarefas bem delimitadas e rodam múltiplos agentes em paralelo, revisando saídas de forma assíncrona.
• Use especificações como fonte da verdade. O desenvolvimento orientado por especificações (spec-driven) é o fluxo padrão. Specs não são documentação — são o contrato contra o qual os agentes constroem.
• Mova os testes para o início. Os agentes validam localmente e se autocorrigem antes de qualquer saída chegar a um revisor humano.

Como funciona em ambientes de clientes

Em engajamentos com clientes, o Delivery Agent opera ao lado de consultores humanos, cobrindo todo o ciclo de vida — do planejamento à implantação — tendo como norte os resultados de negócio selecionados pelo cliente.

O princípio que governa o processo é claro: humanos fornecem a intenção, a IA cria, humanos verificam. Os clientes mantêm a escolha dos modelos de fundação e podem estender o sistema com seus próprios dados e ferramentas.

O que a AWS aprendeu ao ir primeiro

A AWS destaca que a calibração não é opcional, mas também não é preciso começar do zero. As equipes precisam de tempo para construir confiança no que os agentes fazem bem, decompor trabalhos complexos em tarefas verificáveis e reestruturar artefatos para consumo por IA. O ProServe transfere esse aprendizado diretamente durante o engajamento, encurtando a curva de adoção.

Outro ponto importante: o fluxo de trabalho é a constante; as ferramentas são habilitadoras. A AWS menciona o uso de Kiro, Amazon Bedrock AgentCore e Strands, mas deixa claro que não é o stack que gera o ganho de produtividade. As ferramentas só potencializam quando o fluxo de trabalho foi redesenhado ao redor delas.

Por fim, há uma mudança no modelo comercial: o ProServe migrou de engajamentos por tempo e material para contratos de preço fixo atrelados a resultados de negócio implantados em produção. Quando o modelo comercial se alinha com as necessidades do cliente, todo o resto segue.

Resultado real: o caso LexisNexis

A LexisNexis Legal & Professional compartilhou sua experiência com o modelo. A empresa adotou a funcionalidade Region Switch do Amazon Application Recovery Controller (ARC) para simplificar sua abordagem de resiliência multi-região. O Region Switch substituiu orquestrações de failover customizadas por planos declarativos que coordenam escalonamento, troca de banco de dados e roteamento de DNS em paralelo.

Segundo o CTO de Infraestrutura & Operações da empresa, o Kiro com o AWS Professional Services Delivery Agent comprimiu semanas de criação de backlog em horas, acelerou a entrega de código em 60% e garantiu qualidade consistente em todas as entregas. O teste de troca de região foi executado no prazo e a empresa conseguiu operar em sua região secundária com sucesso.

Como começar

A AWS oferece dois caminhos para quem quer experimentar o modelo:

• Workshops práticos: Solutions Architects da AWS conduzem workshops de AI-DLC com duração de dois a cinco dias, demonstrando o desenvolvimento nativo em IA contra o próprio stack do cliente. Centenas de clientes já participaram.
• Engajamentos de produção: quando a organização está pronta para levar casos de uso de negócio à produção, o AWS ProServe entra na jornada. Consultores e o Delivery Agent se integram à equipe do cliente para entregar resultados em produção enquanto constroem a capacidade organizacional para sustentar e escalar a prática. Ao final, o cliente tem sistemas funcionando em produção e campeões internos treinados para continuar.

Para saber mais, é possível entrar em contato com o time de conta AWS ou acessar a página do AWS Professional Services.

Fonte

Built from the inside out: How AWS Professional Services became a frontier team first (https://aws.amazon.com/blogs/machine-learning/built-from-the-inside-out-how-aws-professional-services-became-a-frontier-team-first/)