O Lab de IA

Um ambiente de engenharia de ponta onde as specs entram e o software sai.

Ambiente de Engenharia – Rung 5 (Produção Autônoma)

O Lab de IA é um ambiente operacional paralelo que visa o mais alto nível do desenvolvimento conduzido por IA. Ele experimenta novas formas de trabalho e serve como espaço de teste para práticas, agentes e fluxos de trabalho que serão aplicados em toda a engenharia. O Lab opera fora dos procedimentos operacionais padrão de engenharia. Ele tem suas próprias regras.

---

Duas escalas de maturidade

Este documento usa duas escalas distintas definidas no framework de referência: a escala organizacional (Levels 1-3, aplicável em toda a empresa) e a escala de engenharia (Rungs 0-5, específica para o desenvolvimento de software). Veja o framework para definições completas e critérios de aceitação.

O Lab mira o Rung 5. A engenharia fora do Lab visa o Level 3 organizacional (Rungs 4-5).

A transição mais difícil é a passagem do Rung 3 para o Rung 4: aceitar que você não lê mais o código e confiar nos cenários para validar o resultado. É uma mudança psicológica antes de ser técnica. A maioria dos engenheiros se estagna no Rung 3 porque largar o controle sobre o código vai contra todos os seus instintos profissionais.

---

Regras absolutas

Duas regras definem o Lab. Elas não são aspirações – são condições de admissão.

O humano define a arquitetura, as restrições e os cenários de satisfação. A IA produz o código, roda os testes e converge para a solução. Se você está escrevendo ou lendo código linha por linha, não está operando no modo de trabalho do Lab.

---

Critérios de admissão de projetos

Sequência típica para um brownfield:

Essas etapas pressupõem uma base de código sendo transicionada diretamente para o Rung 5 sob as regras do Lab. As decisões a montante (avaliar a maturidade do código e escolher entre os modos brownfield: remediar, strangler-fig, reconstruir) ficam fora do próprio Lab.

1. Extrair a especificação implícita – O sistema existente É a especificação. Ninguém nunca documentou as mil decisões implícitas acumuladas ao longo de anos de patches, hotfixes e gambiarras que se tornaram permanentes. Essa extração é o trabalho mais difícil e mais humano da transição. Ela requer as pessoas que sabem por que aquele módulo tem aquela exceção, por que aquele serviço foi separado daquela forma, por que aquele valor está configurado assim. A IA pode ajudar a documentar o que o sistema faz (gerar specs a partir do código). Mas distinguir comportamentos intencionais de acidentes históricos continua sendo um julgamento humano.
2. Escrever cenários de ponta a ponta que descrevam o comportamento esperado atual, baseados na especificação extraída na etapa 1
3. Verificar que os cenários passam no código existente
4. A partir daí, todas as mudanças são feitas pelo agente, validadas por cenários
5. Iterar: cada componente em transição aumenta a cobertura de Rung 5 do projeto

O que NÃO pertence ao Lab

• Qualquer projeto cujo desenvolvimento continua usando práticas tradicionais (humano escreve ou revisa código)
• Projetos cujas restrições de entrega não toleram nenhum risco de aprendizado

Regra: a condição de entrada não é a ausência de código existente – é o compromisso de que todo novo trabalho segue as regras do Lab.

---

Modo de trabalho: a unidade operacional

Os cinco estágios

O Lab estrutura todo o trabalho em torno de um loop recorrente de cinco estágios. O humano se concentra nas fronteiras; o agente roda por dentro.

1. Stage 1
   Contexto

   Contexto de trabalho vivo (CLAUDE.md / AGENTS.md, ferramentas com escopo, skills sob demanda) validado contra o sistema antes de o trabalho começar. Contexto desatualizado produz trabalho errado com confiança.

2. Stage 2
   Clarificação

   O agente expõe premissas e faz perguntas calibradas. Nenhuma execução enquanto houver ambiguidade material. Regra de custo: custo de clarificação ≪ custo de correção.

3. Stage 3
   Execução

   O agente produz, roda testes, converge. O humano não supervisiona a execução.

4. Stage 4
   Validação

   Portão graduado por risco (§ 4). Testes, cenários, agente revisor para trabalho reversível; aprovação humana para irreversível.

5. Stage 5
   Recuperação

   Quando a validação falha ou o agente fica preso: recalibrar (refazer a spec, refazer o contexto, brainstorm) em vez de depurar. Veja § 5.

O Estágio 2 (Clarificação) já está em ferramentas de produção – o /speckit.clarify do spec-kit, o modo plan da Anthropic e a ferramenta AskUserQuestion operacionalizam o padrão como um portão discreto. O Estágio 4 é detalhado em Portões de validação graduados por risco; o Estágio 5 em Protocolo de estado bloqueado.

Os dois pontos de controle humano

O trabalho humano se concentra na fronteira frontal (Contexto + Clarificação) e na fronteira traseira (Validação + Recuperação). Dentro do loop, os agentes e avaliadores rodam. Este é o padrão operacional que torna o Rung 5 sustentável – a atenção do humano não é um gargalo de revisão linha por linha; é um papel de direção e julgamento por loop.

O padrão é de tarefas discretas, não específico de engenharia

O Lab aplica o loop ao código, mas a mesma forma governa outros trabalhos de tarefas discretas:

Estágio	Engenharia	Atendimento ao cliente	Operações financeiras
Contexto	Base de código + CLAUDE.md	Base de conhecimento + histórico do cliente	Razão contábil + plano de contas + regras de período
Clarificação	O agente pergunta sobre critérios de aceitação ambíguos	O agente pergunta "o que o cliente realmente quer?" antes de redigir	O agente expõe ambiguidade na categorização de transações
Execução	PR com testes	Resposta + ações	Lançamentos contábeis redigidos
Validação	Agente revisor + CI; portão humano em deploy de produção	Agente revisor para tom + política; portão humano em reembolso acima do limite	Agente reconciliador; aprovação humana antes do lançamento
Recuperação	Refazer a spec quando um bug sutil aparece	Retreinar quando os padrões de escalada mudam	Refazer a spec quando um caso de borda revela uma lacuna de categoria

O substrato muda; o loop não. As regras do Lab – código não escrito nem revisado por humanos – são a instância de engenharia do princípio mais amplo: os humanos dirigem e validam; a IA executa dentro de portões graduados por risco.

Cenários vs testes

• Testes: validações armazenadas no código. Vulneráveis a manipulação por agentes – um agente pode reescrever um teste para fazê-lo passar. Úteis mas insuficientes.
• Cenários: jornadas de usuário de ponta a ponta que descrevem o comportamento esperado da perspectiva do usuário. Mais difíceis de contornar. O Lab favorece cenários.

Quando os humanos não leem mais o código, os testes unitários perdem uma vantagem crucial: a capacidade do engenheiro de identificar casos extremos a partir do seu conhecimento da implementação. Em um modelo de execução opaco, apenas a validação comportamental de ponta a ponta permanece confiável, porque não depende do conhecimento dos detalhes internos.

Métrica de satisfação

O Lab não mede o sucesso de forma binária (testes verdes / vermelhos). Ele mede satisfação: "em todas as trajetórias observadas através de todos os cenários, qual fração satisfaz o usuário?"

Quando a satisfação é insuficiente, o problema está na especificação, não no agente. Itere na spec, não no código.

Economia de tokens

O tempo de relógio é a métrica errada no Rung 5 – os agentes trabalham em paralelo, de forma assíncrona, e durante a noite. As métricas vinculantes são:

• Custo por unidade entregue (PR, ticket, transação). A Anthropic quantifica o prêmio multi-agente: agentes típicos usam ~4× os tokens do chat; sistemas multi-agente podem usar ~15× (Anthropic, 2025). O custo por unidade entregue torna isso visível.
• Margem bruta da IA no nível da equipe – valor produzido em relação ao gasto com inferência. Equipes IA-nativas tratam o custo de tokens como uma métrica de engenharia de primeira classe. Veja Economia da IA em maturidade.
• Throughput de agente por dólar – unidades entregues por dólar de inferência. Distingue equipes de alto gasto e alto throughput de equipes de alto gasto e baixo throughput.

O Lab acompanha essas métricas junto com a satisfação. Uma equipe que chega ao Rung 5 executando loops multi-agente caros em cada tarefa pode ser tecnicamente bem-sucedida e economicamente insustentável ao mesmo tempo.

As habilidades críticas: especificação e process design

O gargalo do Lab não é a velocidade de implementação – é o trabalho na fronteira frontal. Duas habilidades novas:

• Especificação – escrever instruções suficientemente precisas para que o agente implemente corretamente sem intervenção humana.
• Process design para IA – projetar as restrições, portões e níveis de validação dentro dos quais o agente opera de forma consistente. Distinto da engenharia de prompts e da escrita de spec em si. Veja Padrões de Execução de IA § Camada 5.

Quase ninguém desenvolveu plenamente nenhuma das duas.

A dificuldade com a especificação: quando um humano recebe uma spec ambígua, ele preenche as lacunas com julgamento, contexto ou uma mensagem perguntando "você quis dizer X ou Y?" O agente constrói o que você descreveu. Se a descrição for ambígua, o software preenche as lacunas com suposições de máquina, não com intuições de clientes. O estágio de clarificação da unidade operacional é a correção estrutural – mas só se a equipe o usar.

Essa habilidade se desenvolve com prática:

• As clínicas de IA devem incluir revisões de spec: "aqui está minha spec, aqui está o que o agente produziu, aqui está o que faltava na spec"
• As sessões de dupla devem trabalhar exercícios de especificação, não apenas exercícios de código
• Cada iteração com falha é um sinal sobre a spec, não sobre o agente – documente o que a spec não declarou claramente o suficiente

O objetivo do Lab não é apenas produzir software por meio de agentes. É desenvolver engenheiros que possam especificar com o rigor que os agentes exigem.

---

Portões de validação graduados por risco

O Estágio 4 (Validação) da unidade operacional é graduado por risco – classes diferentes de ação recebem portões diferentes. As dimensões que determinam o portão, adaptadas de SAE J3016 (direção) como o análogo mais limpo:

• Operational design domain (ODD) – as condições sob as quais o agente é projetado para funcionar. Fora do ODD, o agente não faz alegações; o portão recua para o humano.
• Responsabilidade de fallback – quem lida com a ação quando o agente fica preso ou atinge uma fronteira proibida.
• Expectativa de supervisão – o que o humano deve fazer durante a operação.
• Transferência de controle – como a autoridade muda entre agente e humano.

As três posturas operacionais

Uma equipe madura no Rung 5 opera os três simultaneamente. Exemplos:

Ação	Portão	Justificativa
Merge de código para main (repositório bem testado, agente revisor)	HOOTL	Reversível (revertível); raio de impacto limitado pelo CI
Deploy de produção	HITL	Irreversível no nível de percepção do cliente; alto impacto
Transação financeira redigida no sistema contábil	HITL	Irreversível (trilha de auditoria); implicações regulatórias
Resposta rotineira de suporte ao cliente (dentro do escopo da base de conhecimento)	HOTL	Reversível; qualidade monitorada; agente revisor para tom/política
Reembolso ou crédito emitido acima do limite	HITL	Irreversibilidade financeira; implicações de confiança

As regras absolutas do Lab ("código não escrito nem revisado por humanos") continuam se aplicando dentro do modo HOOTL. Mas equipes no Rung 5 deliberadamente saem do HOOTL para trabalho irreversível – essa é uma escolha de design graduada por risco, não uma regressão.

Fadiga de vigilância

O HOTL é operacionalmente frágil quando tratado como monitoramento passivo. Para que o HOTL seja significativo, o humano deve (a) ter autoridade de intervenção (kill switch, rollback, override) e (b) estar de fato prestando atenção. A fadiga de vigilância está bem documentada; equipes que rotulam tudo como HOTL como teatro de conformidade descobrem que sua supervisão é ilusória. O custo cognitivo da vigilância sustentada é real (veja Custo cognitivo).

---

Protocolo de estado bloqueado

Quando a validação falha ou o agente fica preso em um entregável, a resposta é governada pelo estágio de Recuperação da unidade operacional – e pelas regras do Lab.

O modo de falha de gargalo de IA

No Rung 5, "atrasado em um entregável" raramente significa que a capacidade humana é insuficiente. Significa que o agente atingiu um limite estrutural – direção errada, spec ambígua, caso de borda subjetivo que ele não consegue resolver sozinho. Cemri et al. (Why Do Multi-Agent LLM Systems Fail?, 2025) constataram que 41,8% das falhas em sistemas multi-agente são problemas de especificação ou design que precisam de re-especificação, não de nova tentativa.

Recalibração, não depuração

A literatura sobre autocorreção intrínseca é unânime: um modelo que se comprometeu com uma direção errada não a perceberá com confiabilidade sozinho; reflexão na mesma janela de contexto após uma resposta errada agrava o erro em vez de corrigi-lo. A jogada de recuperação é reconstruir o entendimento do agente – contexto novo, spec rearticulada, brainstorm multi-perspectiva – não depurar o artefato que o agente produziu.

Padrão prático no Rung 5:

1. Detecte o estado bloqueado – limite de iteração atingido; mesmo padrão de falha recorrente; problema subjetivo levantado por um usuário.
2. Pare de iterar. Convoque uma sessão de recalibração – um ou mais humanos engajam o agente em diálogo; o objetivo é trazer à tona a premissa errada.
3. Refaça a spec ou o contexto. Refine critérios de aceitação, corrija requisitos ambíguos, atualize CLAUDE.md / AGENTS.md se a intenção tiver se afastado do contexto documentado.
4. Reinicie o loop a partir de Contexto, não da Execução. Uma execução nova do agente sobre uma spec corrigida quase sempre supera correções continuadas dentro da janela de contexto original.

Regra do Lab para estados bloqueados

Quando um projeto do Lab está bloqueado, não retome o trabalho manualmente. Trazer a implementação de volta para mãos humanas viola as regras absolutas do Lab e substitui o sintoma (entrega lenta) por outro pior (o Lab deixa de demonstrar como o Rung 5 se parece). A resposta certa é a recalibração coletiva: traga mais humanos para a spec/clarificação, traga à tona a premissa errada, execute o loop novamente.

Se o trabalho é genuinamente irrecuperável no Rung 5, a maturidade do código do projeto está abaixo de onde a equipe está operando – recue para um Rung mais baixo temporariamente e remedeie o harness (maturidade do código, estratégia brownfield). Esta é uma jogada legítima; reverter para codificação manual dentro do Lab não é.

---

Ingenuidade deliberada

O maior obstáculo para o Rung 5 não é técnico – é o hábito.

Engenheiros experientes têm reflexos profundos: estruturar o código de uma certa forma, revisar linha por linha, escrever testes eles mesmos, refatorar manualmente. Esses reflexos eram pontos fortes no desenvolvimento tradicional. No Lab, são obstáculos.

Ingenuidade deliberada significa:

• Remover as convenções tradicionais de desenvolvimento e ver o que se sustenta sem elas
• Perguntar sistematicamente: "Por que estou fazendo isso? O modelo deveria estar fazendo isso."
• Aceitar que abordagens que parecem "ingênuas" ou "incorretas" pelos padrões tradicionais podem ser corretas num ambiente IA-nativo
• Tratar tarefas historicamente consideradas muito caras (construir réplicas completas de serviços, escrever milhares de cenários) como rotina quando os custos de execução da IA o tornam viável

A pergunta permanente do Lab:

“

Por que estou fazendo isso? O modelo deveria estar fazendo isso.

Se a resposta é "porque sempre fiz assim", esse é exatamente o motivo para mudar.

---

Papel de suporte

O Lab não está isolado do restante da engenharia. Ele a serve.

O Lab produz:

• Padrões de trabalho documentados: como especificar para um agente, como escrever cenários, como avaliar satisfação
• Agentes reutilizáveis ou adaptáveis
• Prova concreta de que o Rung 5 funciona em projetos reais
• Feedback honesto – o que funciona e o que ainda não funciona

O Lab compartilha através de:

• Clínicas de IA: sessões regulares, formato curto. "Aqui está o que tentamos, aqui está o que aconteceu."
• Documentação: cada padrão e antipadrão descoberto é documentado
• Dupla Lab / não-Lab: um membro do Lab trabalha temporariamente com um engenheiro fora do Lab para transferir práticas

Um Lab que não compartilha é inútil. Compartilhar é tão importante quanto produzir.

---

Cultura do Lab

O Lab tem uma cultura distinta do restante da organização:

• Curiosidade obrigatória – a pergunta "e se tentarmos..." é sempre bem-vinda
• Monitoramento agressivo – os membros do Lab acompanham os avanços mais recentes dos modelos de IA. Quando um novo modelo ou ferramenta é lançado, o Lab o testa rapidamente e avalia se é um divisor de águas. Esperar que as coisas "amadureçam" é incompatível com o Lab.
• Ousadia nos métodos, rigor nos compromissos – o Lab empurra os limites de como trabalhamos: quais ferramentas adotamos, quais fluxos de trabalho reinventamos, quais abordagens "ingênuas" testamos. Mas as obrigações contratuais, econômicas, legais e de segurança com os clientes continuam sendo inegociáveis. A ousadia se aplica aos meios, não às garantias.
• Alto risco, baixo impacto – os projetos do Lab são escolhidos para tolerar falhas. Use isso para correr riscos que não correria em outro lugar
• Transparência radical – as falhas são compartilhadas com tanto detalhe quanto os sucessos. Uma falha documentada tem mais valor do que um sucesso silencioso
• Liderança significa elevar a equipe – no Lab, a liderança não é medida pelo desempenho individual. Líderes são aqueles que tornam o restante da equipe melhor: que compartilham suas descobertas, documentam seus padrões, desbloqueiam seus colegas e transformam sua expertise em práticas reproduzíveis. Um engenheiro brilhante que guarda seus métodos para si não é um líder do Lab.
• Velocidade de iteração – o ciclo de feedback da spec ao entregue deve ser rápido. Se uma iteração leva dias, o ciclo é pesado demais

---

Armadilhas a evitar

• Pitfall: Reverter aos hábitos

  O reflexo de "verificar manualmente o código só para ter certeza" é exatamente o que o Lab proíbe. Se os cenários passam, o código é validado pelos cenários.

• Pitfall: Especificações insuficientes

  Quando o agente produz código ruim, o problema geralmente está na spec. Recalibre (refaça a spec, refaça o contexto) antes de depurar o artefato. Itere na spec, não no código.

• Pitfall: Isolamento

  Um Lab que não compartilha seus aprendizados é um hobby, não um Lab.

• Pitfall: Projetos críticos demais cedo demais

  O Lab tem alta tolerância ao risco. Não coloque um projeto cuja falha coloque em perigo um cliente ou um contrato.

• Pitfall: Perfeccionismo de agente

  O objetivo não é um agente perfeito. É um agente que produz valor. Itere.

• Pitfall: Brownfield sem extração de *spec*

  Fazer a transição de um projeto existente sem primeiro extrair a especificação implícita e escrever cenários que protejam o comportamento atual é voar sem rede. A extração é o trabalho mais difícil – não subestime.

• Pitfall: Brownfield "meio Lab"

  Se parte do trabalho em um projeto brownfield é feita no modo tradicional "porque é mais rápido para essa parte", o projeto não está no Lab. As regras são absolutas, mesmo quando é desconfortável.

• Pitfall: A parede dos seis meses

  Projetos conduzidos por IA sem forte envolvimento humano (specs, cenários, arquitetura) acumulam dívida estrutural que explode por volta dos seis meses. O código gerado por IA sem restrições claras é frequentemente menos estruturado e menos manutenível. Os cenários e especificações do Lab são exatamente a defesa contra essa parede – eles impõem rigor a montante que evita que a dívida se acumule silenciosamente.

• Pitfall: Tratar um gargalo de IA como problema de produtividade

  Quando o agente não consegue entregar, quase nunca é um problema de capacidade (o agente tem capacidade quase infinita). É quase sempre um problema de spec ou de contexto. Redistribuir trabalho para humanos substitui a causa raiz errada e viola as regras do Lab. A resposta certa é a recalibração (veja § 5).

---

Ciclo de vida

Este ciclo de vida se alinha com o caminho de transformação organizacional: a Fase 1 corresponde à transição Level 2→3 (6-12 meses na escala organizacional).

---

Regra resumo

“

Por que estou fazendo isso? O modelo deveria estar fazendo isso.

---

← Voltar para o início · O framework de referência · Padrões de Execução de IA · Glossário