Como medir a adoção de IA no time de desenvolvimento: métricas de uso, de entrega e de qualidade que resistem a uma revisão honesta

Medir produtividade com IA no desenvolvimento, e a adoção que a sustenta, exige três camadas lidas juntas (uso, entrega e qualidade) e uma linha de base coletada antes da adoção, com as mesmas definições que serão usadas depois. Volume de código gerado mede atividade, não valor. O que sustenta uma conclusão é a comparação de métricas de entrega e de qualidade do mesmo serviço, antes e depois, com os fatores que confundem sob controle.

Verificado contra a documentação do Kiro na atualização de 15/10/2026, dois dias depois da publicação, para conferir os nomes de métricas e de configuração citados.

A medição fecha o ciclo de adoção. Colocar o Kiro, a IA agêntica da AWS para desenvolvimento de software, para trabalhar com método passa por specs, steering, hooks, governança e pipeline. A pergunta seguinte, vinda do CTO ou da área financeira, é se o investimento está mudando a entrega. A resposta só é defensável se a medição tiver sido desenhada antes da primeira assinatura.

Como referência oficial, o anúncio da AWS sobre a disponibilidade nas regiões GovCloud (US) descreve o Kiro como IA agêntica com IDE e CLI voltada ao desenvolvimento orientado a specs, e o site oficial informa que ele é construído e operado pela AWS. A medição descrita aqui parte das fontes de dado que a documentação oficial do Kiro expõe para organizações.

Por que métricas de volume enganam

Linhas geradas, sugestões aceitas e mensagens trocadas com o agente são fáceis de coletar e crescem rápido. Por isso aparecem primeiro nos relatórios. O problema é o que elas medem: quanto a ferramenta foi acionada, não se o software chegou mais rápido e com menos falha a quem usa.

O artigo que apresentou o framework SPACE, escrito por pesquisadores do GitHub, da Microsoft Research e da Universidade de Victoria e publicado na ACM Queue e republicado na Communications of the ACM em junho de 2021, é direto sobre isso: métricas de atividade servem como pontos de referência, mas nunca devem ser usadas isoladamente para tomar decisões sobre produtividade individual ou de time, por causa de limitações conhecidas. Sozinhas, elas não revelam por que a atividade subiu ou caiu. O mesmo texto marca linhas de código entre as métricas a usar com cautela ainda maior, porque podem representar muitas coisas diferentes.

Há um segundo efeito, mais perigoso. Quando uma métrica vira meta, o comportamento muda para atingir a meta. O guia de métricas do DORA recomenda usar as métricas para melhorar e não como alvo, porque fixar alvo convida a manipulação, como descreve a lei de Goodhart. Com IA, o risco é concreto: um time cobrado por "percentual de código gerado" tem incentivo para aceitar sugestões longas, duplicar trechos e adiar a refatoração. O número sobe e a base de código piora.

O próprio relatório legado de atividade do Kiro traz colunas de volume, como Inline_AICodeLines e Dev_AcceptedLines, segundo a documentação de atividade por usuário. São úteis para saber se a ferramenta está sendo usada. Não servem para dizer se valeu a pena.

Como medir a produtividade com IA no desenvolvimento: três camadas de métrica

A estrutura proposta aqui separa o que cada dado consegue responder. Nenhuma camada sozinha sustenta conclusão; a leitura é sempre cruzada.

Uso: a ferramenta entrou no fluxo de trabalho?

• Ativação: proporção de pessoas com assinatura que começaram a usar. Responde se o problema é assinatura parada ou onboarding.
• Frequência: usuários ativos por semana, agregados por time. Responde se o uso se sustentou depois da novidade.
• Superfícies usadas: IDE, CLI ou ambas. Uso de CLI em pipeline indica que o time levou o agente para a automação, assunto do post sobre Kiro CLI no pipeline.

Entrega: o software chega mais rápido e com estabilidade?

Aqui a referência são as métricas de software delivery do DORA. O guia oficial, na versão atualizada em janeiro de 2026, lista cinco métricas em dois grupos:

O mesmo guia traz três orientações que valem como regra para medir IA: aplicar as métricas a uma aplicação ou serviço por vez, porque misturar sistemas diferentes engana; usar várias métricas em tensão entre si, em vez de um número único; e comparar o time com ele mesmo ao longo do tempo, não com outros times.

Qualidade e experiência: o ganho é sustentável?

• Retrabalho: a taxa de retrabalho de deploy do DORA e, dentro do repositório, mudanças revertidas ou corrigidas logo depois do merge.
• Incidentes: quantidade e severidade por serviço, cruzadas com a taxa de falha de mudança.
• Tempo de revisão: do pull request aberto até a primeira revisão e até o merge. Se o agente acelera a escrita e a revisão vira fila, o gargalo só mudou de lugar.
• Experiência do desenvolvedor: pesquisa curta e anônima. O artigo do SPACE define cinco dimensões (satisfação e bem-estar; desempenho; atividade; comunicação e colaboração; eficiência e fluxo), recomenda métricas de pelo menos três delas e pede que ao menos uma seja perceptiva, como dado de pesquisa.

Um exemplo de pesquisa trimestral, em escala de 1 a 5, com uma pergunta por dimensão do SPACE:

# Anônima, respondida por time, resultado publicado só agregado.
# Mesmas perguntas na linha de base e depois da adoção.
escala: "1 (discordo totalmente) a 5 (concordo totalmente)"
perguntas:
  - dimensao: satisfacao_bem_estar
    texto: "Estou satisfeito com as ferramentas que uso para entregar meu trabalho."
  - dimensao: desempenho
    texto: "O que meu time entrega chega em produção com a qualidade esperada."
  - dimensao: atividade
    texto: "Passo a maior parte do tempo em trabalho que exige meu julgamento."
  - dimensao: comunicacao_colaboracao
    texto: "Encontro com facilidade a documentação e o contexto de que preciso."
  - dimensao: eficiencia_fluxo
    texto: "Consigo trabalhar em blocos de foco sem esperar por outras pessoas."
pergunta_aberta: "O que mais atrapalhou sua entrega nas últimas semanas?"

O que o Kiro oferece para a camada de uso

Quando as assinaturas são gerenciadas pela organização no console do Kiro na AWS, a documentação de monitoramento lista estas fontes. Só o que está documentado entra aqui.

• Painel de uso: visível só para administradores, com o controle Kiro usage dashboard ligado nas configurações. Segundo a página do painel, mostra assinaturas totais, ativas e pendentes por plano (Pro, Pro+, Pro Max e Power), usuários ativos por dia, semana e mês, e créditos consumidos, separados por tipo de cliente (IDE ou CLI) e por plano. A maior parte das métricas atualiza de hora em hora; usuários ativos, uma vez por dia, no relógio UTC. Assinaturas pendentes são de quem ainda não começou a usar e não são cobradas.
• Relatório de atividade por usuário: diário, gerado às 02:00 UTC, um CSV por tipo de cliente (IDE, CLI e Plugin) em um bucket S3 da conta, ou métricas agregadas enviadas a um coletor OpenTelemetry. As colunas incluem Date, UserId, Client_Type, Chat_Conversations, Credits_Used, Total_Messages, Subscription_Tier, New_User, User_Email, campos de excedente (Overage_*) e uma coluna de mensagens por modelo, segundo a documentação de atividade por usuário.
• Registro de prompts: grava prompts e respostas do chat e sugestões inline da IDE e do CLI, com ID do usuário e horário, em JSON, num bucket S3 da sua conta, conforme a página de registro de prompts. A página cita auditoria, depuração, análise e conformidade como finalidades.
• Amazon CloudWatch: a documentação de monitoramento dá como exemplo acompanhar quantas vezes o Kiro é invocado na conta e o número de usuários ativos diários, com alarmes por limite (documentação do CloudWatch).
• AWS CloudTrail: registra chamadas de API feitas pela conta ou em nome dela, com identidade, IP de origem e horário, entregues num bucket S3 (documentação do CloudTrail). Serve à trilha de auditoria, não à medição de valor.
• Exportação de assinaturas: botão Download CSV na tabela de assinaturas da página Users & Groups do console, com os campos User name, Subscription status, Kiro plan, Plan source e Activation date. É a fonte da métrica de ativação.

Três detalhes de configuração que evitam retrabalho. O bucket do relatório precisa estar na mesma conta onde os usuários são assinantes e na região onde o perfil do Kiro foi instalado; bucket entre contas não é suportado. A documentação recomenda um bucket diferente do usado para o registro de prompts. E o primeiro arquivo só chega no ciclo das 02:00 UTC seguinte à ativação, então ligue o relatório antes de começar a contar a linha de base de uso.

Para transformar o CSV em métrica de time, a documentação do Kiro sugere consultar os arquivos com o Amazon Athena. Um caminho direto é catalogar o prefixo com um crawler do AWS Glue. Três cuidados. Aponte o crawler para KiroLogs/user_report/, e não para KiroLogs/, porque o relatório legado (by_user_analytic) fica ao lado com outro esquema, e prefixo com esquemas diferentes confunde a tabela no Athena. Confira se a primeira linha virou cabeçalho: o classificador CSV nativo só infere cabeçalho quando alguma linha de dados tem tipo diferente de texto; se não reconhecer, as colunas aparecem como col1, col2. E use só as colunas fixas, porque as colunas por modelo mudam conforme os modelos usados. A view abaixo já nasce minimizada: sem e-mail, sem identificador de pessoa na saída e com supressão de grupos pequenos. A supressão vale para cada combinação de semana, time e cliente; o tamanho mínimo de grupo (k) é decisão da sua política de dados, e o valor no exemplo é ilustrativo.

-- kiro_user_report: tabela criada pelo crawler do Glue sobre
--   s3://BUCKET/PREFIXO/AWSLogs/CONTA/KiroLogs/user_report/
-- mapa_times: userid -> time, exportado dos grupos do provedor de identidade.
-- A documentação do Kiro não fixa o formato de Date; o crawler pode tipar
-- Date como string ou date e os números como string. Valide antes da view.

-- Passo 1: validação (rode sozinha e confira o resultado).
SELECT "date",
       typeof("date")       AS tipo_date,
       typeof(credits_used) AS tipo_creditos
FROM kiro_user_report
LIMIT 5;

-- Passo 2: view minimizada. Se Date não vier como AAAA-MM-DD,
-- troque o CAST por date_parse com o formato observado no passo 1.
CREATE OR REPLACE VIEW kiro_uso_por_time AS
WITH parametros AS (
  SELECT 5 AS k   -- parâmetro da sua política de privacidade, não valor da AWS
)
SELECT
  date_trunc('week', CAST(r."date" AS date)) AS semana,
  m.time,
  r.client_type,
  COUNT(DISTINCT r.userid)                    AS usuarios_ativos,
  SUM(CAST(r.chat_conversations AS bigint))   AS conversas,
  SUM(CAST(r.credits_used AS double))         AS creditos
FROM kiro_user_report r
JOIN mapa_times m ON m.userid = r.userid
CROSS JOIN parametros p
GROUP BY 1, 2, 3, p.k
HAVING COUNT(DISTINCT r.userid) >= p.k;

O acesso ao bucket bruto fica com quem administra a plataforma; quem consome o painel lê só a view. Créditos por time alimentam a conversa de custo, que o post de FinOps de IA generativa trata com alocação e limite.

O que a pesquisa diz

O relatório DORA 2025 sobre desenvolvimento assistido por IA, do Google, reúne mais de 100 horas de dados qualitativos e respostas de quase 5.000 profissionais de tecnologia, segundo a página do relatório. A conclusão central, segundo o relatório, é que a IA funciona como amplificador: aumenta as forças das organizações que já entregam bem e as disfunções das que têm dificuldade. Para quem mede, a consequência prática é que o efeito da IA depende do sistema em volta dela, e a medição precisa olhar para esse sistema.

O Modelo de Capacidades de IA do DORA, publicado em setembro de 2025, identifica sete capacidades que ampliam ou destravam os benefícios da IA:

1. Posição clara e comunicada da organização sobre IA.
2. Ecossistema de dados saudável.
3. Dados internos acessíveis à IA.
4. Práticas fortes de controle de versão.
5. Trabalho em lotes pequenos.
6. Foco no usuário.
7. Plataformas internas de qualidade.

Duas observações do texto importam para o desenho da medição. A primeira: na ausência de foco no usuário, a adoção de IA pode ter impacto negativo no desempenho do time. A segunda: várias capacidades são de processo (lotes pequenos, commits frequentes, plataforma interna), o que reforça que não se mede IA isolada da forma de trabalhar. No Kiro, a spec e o steering são essa forma de trabalhar registrada no repositório, e o steering é também um dos caminhos para dar ao agente o contexto interno do projeto.

A página do relatório no Google Cloud destaca ainda a gestão de fluxo de valor (value stream management) como multiplicador, para que ganhos locais de produtividade se convertam em desempenho de produto em vez de virar desordem mais adiante no fluxo. Em termos de medição: um ganho no tempo de escrita só conta se aparecer no lead time de ponta a ponta.

Desenho da medição

O método tem cinco peças. Todas são decididas antes da adoção e registradas num arquivo versionado, para que ninguém redefina a métrica depois de ver o resultado.

1. Pergunta de negócio escrita. Uma frase que diga o que se quer saber e qual decisão depende da resposta. "A IA está ajudando?" não é pergunta mensurável. "A adoção com specs e steering reduz o lead time de mudança do serviço A sem aumentar a taxa de falha de mudança?" é.
2. Linha de base. Ciclos de entrega suficientes para capturar a variação normal do time, com as mesmas definições, fontes e frequência que serão usadas depois. Como recomendação de método, ajustada ao contexto: partir de pelo menos dois ciclos completos e estender quando os ciclos forem longos ou a sazonalidade for forte. Dado histórico do pipeline ajuda, desde que a definição seja a mesma.
3. Adoção em ondas por time. Em vez de liberar para todos no mesmo dia, entre com um time e mantenha outro como comparação até a onda seguinte. Assim, uma mudança que afetou a empresa toda no período (reorganização, troca de ferramenta de CI) aparece nos dois grupos e não é confundida com efeito da IA.
4. Controle do que confunde. Registre no mesmo arquivo os eventos que mexem nas métricas: sazonalidade de negócio, mudança de escopo, entrada e saída de pessoas, mudança de processo feita junto com a adoção.
5. Marcação na origem. Ondas comparam times; dentro de um mesmo time, a pergunta é como separar trabalho assistido por IA do restante. Uma convenção recomendada é um rótulo de pull request (assistido-por-ia) ou um trailer de commit (Assistido-por-IA: kiro), declarado pela própria pessoa e voluntário. O dado serve para análise agregada por serviço de tempo de revisão, tamanho de lote e retrabalho, e nunca para avaliar pessoa.

# Revisado em pull request antes da primeira assinatura. Mudança de definição = novo PR.
pergunta_de_negocio: >
  A adoção do Kiro com specs e steering reduz o lead time de mudança
  do serviço servico-a sem aumentar a taxa de falha de mudança?
decisao_que_apoia: "Expandir para a onda 2 ou ajustar o método antes"

escopo:
  servicos: [servico-a]
  unidade_de_analise: servico   # nunca pessoa

linha_de_base:
  inicio: AAAA-MM-DD
  fim: AAAA-MM-DD
  criterio: "ciclos suficientes para a variação normal do time"
  recomendacao_de_metodo: "partir de dois ciclos completos e ajustar"

ondas:
  - nome: onda-1
    times: [time-a]
  - nome: onda-2
    times: [time-b]      # grupo de comparação até entrar

metricas:
  uso: [ativacao, usuarios_ativos_semanais_por_time, superficies]
  entrega: [lead_time_mudanca, frequencia_deploy, tempo_recuperacao,
            taxa_falha_mudanca, taxa_retrabalho_deploy]
  qualidade: [tempo_ate_primeira_revisao, incidentes_por_severidade,
              tamanho_pr_mediana]   # controle de lote, não de produtividade
  experiencia: [pesquisa_space_trimestral]

marcacao_origem:
  rotulo_pull_request: assistido-por-ia
  trailer_commit: "Assistido-por-IA"
  obrigatoria: false               # voluntária e autodeclarada
  uso: "comparação agregada por serviço, nunca por pessoa"

estatistica:
  resumo_tempo: mediana          # lead time tem cauda longa
  janela_comparacao: "mesmo número de semanas antes e depois"

eventos_que_confundem: []        # preencher durante o período, com data

privacidade:
  nivel_minimo_de_agregacao: time
  ranking_individual: proibido
  comunicado_ao_time: AAAA-MM-DD

As métricas de entrega saem do pipeline, não de planilha. Um evento por deploy, emitido pelo próprio CI/CD, já carrega o necessário para as cinco métricas do DORA:

{
  "evento": "deploy",
  "servico": "servico-a",
  "ambiente": "producao",
  "deploy_id": "d-000123",
  "commits": [
    { "sha": "9f3c2a1", "commit_ts": "2026-09-30T14:02:11Z",
      "assistido_por_ia": true }
  ],
  "deploy_ts": "2026-10-01T10:15:40Z",
  "planejado": true,
  "exigiu_intervencao": false,
  "incidente_id": null,
  "recuperado_ts": null
}

• Lead time de mudança: deploy_ts menos cada commit_ts, resumido pela mediana.
• Frequência de deploy: contagem de eventos por semana, por serviço.
• Taxa de falha de mudança: deploys com exigiu_intervencao verdadeiro sobre o total.
• Tempo de recuperação: recuperado_ts menos deploy_ts, nos deploys com falha.
• Taxa de retrabalho de deploy: deploys com planejado falso e incidente_id preenchido sobre o total.

Se o time ainda não tem esse evento, criá-lo é o primeiro entregável da medição e vale por si só. O post de observabilidade na AWS cobre onde guardar e como montar o painel.

Assistido e não assistido no mesmo time

O campo assistido_por_ia do evento vem da marcação na origem. Com trailer de commit, o próprio Git grava e extrai a informação, sem ferramenta adicional:

# Ao commitar trabalho feito com o agente (Git 2.32 ou superior)
git commit -m "Valida limite de parcelas no checkout" \
  --trailer "Assistido-por-IA: kiro"

# No CI, ao montar o evento de deploy: sha e valor do trailer por commit
git log --format='%H %(trailers:key=Assistido-por-IA,valueonly,separator=%x2C)' \
  ULTIMO_DEPLOY..HEAD

Com o rótulo de pull request, a mesma separação sai da API do repositório. Nos dois casos, valem três regras. A marcação é voluntária, então a ausência dela não prova que o trabalho foi manual e o dado subestima o uso. A leitura é sempre por serviço e por período, nunca por pessoa, o que deve estar escrito no plano e comunicado ao time. E a comparação entre os dois grupos é sugestiva, não causal, porque quem escolhe usar o agente também escolhe em quais tarefas.

Há confundidores próprios da IA que essa separação ajuda a enxergar. O primeiro é o lote maior: quando escrever código fica barato, o pull request tende a crescer, e lote grande pesa contra a estabilidade. O anúncio do relatório DORA 2024 registrou queda estimada de vazão e de estabilidade de entrega associada ao aumento da adoção de IA, e lembrou que melhorar o processo de desenvolvimento não melhora a entrega sem os fundamentos, como lotes pequenos e testes robustos. Trabalho em lotes pequenos é também uma das sete capacidades do Modelo de Capacidades de IA do DORA, listadas acima. O segundo é a revisão virando fila: o tempo de escrita cai e o tempo até a primeira revisão sobe. Por isso o plano acompanha a mediana do tamanho de pull request como controle, lida ao lado do tempo de revisão e da taxa de falha de mudança.

Privacidade e LGPD na medição

Dado de uso de ferramenta, ligado a ID e e-mail, é dado pessoal do colaborador. O registro de prompts vai além: guarda o texto da conversa e, nas sugestões inline, o código ao redor do cursor, onde pode haver dado de cliente. A LGPD se aplica aos dois, e os princípios do art. 6º, junto com as regras de término do tratamento, viram decisões de desenho:

• Finalidade: a medição existe para avaliar a adoção e o processo do time. Escreva isso no plano e não reutilize os dados para avaliação de desempenho individual.
• Necessidade e minimização: o painel usa agregados por time. O relatório por usuário fica no bucket bruto, com acesso restrito; a view de consumo descarta User_Email e UserId na saída.
• Transparência: o time sabe o que é coletado, para quê, quem acessa e por quanto tempo, antes de o relatório e o registro de prompts serem ligados. O artigo do SPACE vai na mesma direção ao recomendar reportar só resultados anonimizados e agregados no nível de time ou grupo.
• Retenção e eliminação (arts. 15 e 16): o registro de prompts tem prazo definido e aplicado por regra de ciclo de vida no bucket. A página de registro de prompts do Kiro não fixa prazo de retenção; a decisão é da sua política de dados.

O desenho completo do registro de prompts (buckets separados, criptografia, acesso e prazo) está no post sobre governança de IA no código. Para orientação regulatória atualizada, a referência é a ANPD.

Painel mínimo

Cada linha do painel tem dono e uma decisão associada. Métrica que não apoia decisão sai do painel.

E o ROI da IA no desenvolvimento?

O ROI é a pergunta que a área financeira faz depois da primeira fatura. Ele só é defensável se usar as mesmas fontes do painel, com custo e benefício medidos no mesmo serviço e no mesmo período.

• Custo: assinaturas por plano e créditos consumidos por time, do painel de uso e do relatório de atividade do Kiro. Inclua os excedentes, que nas assinaturas da organização são opcionais, habilitados pelo administrador e cobrados por crédito, conforme a página de planos do Kiro. Some o tempo de capacitação e de configuração da medição, que também é custo.
• Benefício observado: variação de lead time de mudança e de taxa de falha de mudança do mesmo serviço, contra a linha de base e contra o grupo da onda seguinte. Ganho no tempo de escrita que não aparece no fluxo de ponta a ponta não entra na conta.
• Conversão em dinheiro: depende de valores que só a empresa define, como o custo de oportunidade de entregar uma funcionalidade mais tarde e o custo médio de um incidente. A ferramenta não fornece esse número, e o cálculo herda a qualidade dessas premissas.

# Mesmo serviço, mesma janela da linha de base. Premissas assinadas por quem as define.
servico: servico-a
periodo: { antes: "linha de base", depois: "onda-1" }

custo:
  assinaturas:         { fonte: "painel de uso do Kiro, por plano" }
  creditos_excedentes: { fonte: "relatório de atividade (Overage_*)" }
  capacitacao_horas:   { fonte: "registro do time" }
  configuracao_horas:  { fonte: "registro da plataforma" }

beneficio_observado:
  delta_lead_time_mediana:  { fonte: "evento de deploy" }
  delta_taxa_falha_mudanca: { fonte: "evento de deploy" }

premissas_de_negocio:          # não vêm da ferramenta
  valor_por_dia_de_antecipacao: { dono: "produto", valor: null }
  custo_medio_de_incidente:     { dono: "SRE e financeiro", valor: null }

regra: "horas economizadas autodeclaradas não entram como benefício"

A última regra é uma recomendação de método: percepção de tempo economizado é dado valioso para a camada de experiência, mas não é benefício financeiro observado. Se a conta só fecha com ela, o resultado é uma hipótese a validar na próxima onda.

Armadilhas e como evitar

• Ranking de desenvolvedores. O dado por usuário existe e a tentação de ordenar pessoas aparece rápido. O efeito é o descrito pela lei de Goodhart: o time otimiza o número, não a entrega, e a confiança na medição acaba. Agregue por time desde a primeira consulta e registre a proibição no plano.
• Medir só uso. Usuários ativos altos com lead time parado indicam ferramenta usada em trabalho que não era o gargalo. Leia uso sempre ao lado de entrega.
• Comparar trimestres diferentes sem ajuste. Fim de ano, fechamento fiscal e datas de pico do negócio mudam a frequência de deploy por motivos alheios à IA. Compare janelas equivalentes e use o grupo da onda seguinte como comparação. Ao normalizar períodos longos, cuide das ausências, como licenças: o artigo do SPACE alerta que olhar métricas de um ano inteiro sem esse cuidado enviesa contra quem se afastou.
• Atribuir à IA o efeito de mudança de processo. Adotar specs, steering e hooks muda o processo, e processo melhor melhora métrica com ou sem agente. Seja explícito no relatório: o que se mede é a adoção do pacote (ferramenta mais método), e o registro de eventos que confundem diz o que mais mudou no período.
• Trocar a definição no meio. Mudar o que conta como deploy com falha depois de ver o número invalida a comparação. Definição mudou, linha de base é recalculada com a nova regra.
• Misturar serviços. Somar lead time de um monólito com o de uma função serverless produz um número sem significado. O guia do DORA pede uma aplicação ou serviço por vez.

Antes de medir: o caminho de adoção

1. Panorama. Kiro, a IA agêntica da AWS para desenvolvimento de software: o que é, como funciona e como adotar no time; IA agêntica no desenvolvimento de software: categorias, raio de ação e como escolher a abordagem; e, para quem vem de outra ferramenta da AWS, Amazon Q Developer para o Kiro: o que muda e como migrar.
2. Método. Specs no Kiro: do requisito à tarefa revisada; Steering no Kiro: as convenções do repositório para o agente; Hooks no Kiro: automação por evento e bloqueios.
3. Integração. MCP no Kiro: ferramentas, Powers e contas AWS com permissão mínima.
4. Controle. Governança de IA no código: permissões, revisão humana e trilha de auditoria; Kiro CLI no pipeline: revisão de pull request em modo headless.
5. Custo. FinOps de IA generativa na AWS: estimar, alocar e limitar o custo de inferência.
6. Modernização. Modernização de aplicações com IA: AWS Transform e specs no Kiro.

Quando a pergunta é o uso de IA fora de qualquer ferramenta aprovada, o tema é outro: Shadow AI e governança. Para IA aplicada além do código, veja RAG na AWS, agentes em produção e o pilar de IA aplicada da RFX.

Para capacitar o time antes do piloto, a oficina Kiro na Prática tem turmas recorrentes, em que cada participante escreve e revisa a primeira spec de um item real do próprio backlog com um arquiteto da RFX. Se a dúvida é anterior a isso, como escolher o primeiro serviço ou o que medir no cenário atual, fale com a RFX.

Perguntas frequentes

Quais métricas usar para medir a adoção de IA no desenvolvimento?

Três camadas lidas juntas. Uso: ativação, usuários ativos por time e superfícies usadas. Entrega: as métricas DORA de software delivery (lead time de mudança, frequência de deploy, tempo de recuperação de deploy com falha, taxa de falha de mudança e taxa de retrabalho de deploy). Qualidade e experiência: tempo de revisão, incidentes e uma pesquisa de experiência baseada no framework SPACE. Tudo comparado contra uma linha de base anterior à adoção.

Linhas de código geradas por IA são uma boa métrica de produtividade?

Não como medida de valor. Linhas geradas e sugestões aceitas medem atividade. O framework SPACE recomenda que métricas de atividade nunca sejam usadas isoladamente para decidir sobre produtividade individual ou de time, e o guia de métricas do DORA alerta que transformar métrica em meta convida a manipulação, como descreve a lei de Goodhart. Use volume só como sinal de uso.

Por quanto tempo coletar a linha de base antes de adotar a IA?

O critério é ter ciclos de entrega suficientes para capturar a variação normal do time, com as mesmas definições de métrica que serão usadas depois. Como recomendação de método, o ponto de partida é de pelo menos dois ciclos completos, ajustada ao contexto: em times com ciclos maiores ou sazonalidade forte, a janela precisa ser maior. O ponto é que a comparação seja entre períodos equivalentes do mesmo serviço.

Dá para medir a produtividade de cada desenvolvedor com os dados do Kiro?

O relatório de atividade por usuário do Kiro existe, mas a recomendação de método é agregar por time. O artigo do framework SPACE orienta reportar apenas resultados anonimizados e agregados no nível de time ou grupo, e a LGPD exige finalidade definida e uso limitado ao necessário. Ranking de pessoas a partir de dados de uso distorce o comportamento e expõe a empresa.

O que o Kiro oferece para medir o uso na organização?

Segundo a documentação de monitoramento do Kiro, a gestão pela organização inclui painel de uso agregado (assinaturas por plano, usuários ativos e créditos consumidos), relatório diário de atividade por usuário em CSV no Amazon S3 ou via OpenTelemetry, registro de prompts em um bucket S3 da sua conta, métricas no Amazon CloudWatch, eventos no AWS CloudTrail e exportação CSV das assinaturas pelo console.

Como calcular o ROI da IA no desenvolvimento?

Coloque de um lado o custo por time (assinaturas, créditos e excedentes, vindos do painel e do relatório de atividade do Kiro, mais o tempo de capacitação) e, do outro, a variação de lead time de mudança e de taxa de falha de mudança do mesmo serviço contra a linha de base. O ganho só conta se aparecer no fluxo de ponta a ponta. A conversão em dinheiro depende de valores que a própria empresa define, como o custo de oportunidade de entregar mais tarde e o custo de um incidente; a ferramenta não fornece esse número.

Sobre o autor

Rodrigo Araújo

Arquiteto de Soluções, IA e Cloud | RFX Tecnologia

Arquiteto de Soluções, IA e Cloud na RFX Tecnologia, lidera projetos de migração, FinOps e IA aplicada na nuvem para empresas do Nordeste e de todo o Brasil. É também o idealizador da Jornada de Inovação AWS em João Pessoa, encontro que aproxima donos de negócio da região das aplicações reais de cloud e inteligência artificial.