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.
1. 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.
2. Critérios de admissão de projetos
O terreno natural do Lab. Sem legado, sem dívida técnica, sem hábitos. As regras do Lab (Rung 5) se aplicam de ponta a ponta desde o primeiro dia.
- O escopo é suficientemente definido para escrever specs e cenários
- O projeto pode tolerar um ritmo de aprendizado
O Lab também assume projetos existentes em transição para o Rung 5. Isso é mais difícil – o código existe, e os hábitos também – mas é onde a transformação tem mais impacto.
- Cobertura de cenários suficiente (ou compromisso de construí-la primeiro)
- Todo novo trabalho segue as regras do Lab – sem retroceder
- O código existente é contexto para o agente, não é intocável
- O risco de regressão é gerenciado por cenários, não por revisão humana
Sequência típica para um brownfield:
- 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.
- Escrever cenários de ponta a ponta que descrevam o comportamento esperado atual, baseados na especificação extraída na etapa 1
- Verificar que os cenários passam no código existente
- A partir daí, todas as mudanças são feitas pelo agente, validadas por cenários
- 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.
3. Modo de trabalho: desenvolvimento não interativo
O ciclo
- O humano escreve a especificação (arquitetura, restrições, cenários)
- O agente produz o código
- Os cenários validam o resultado
- O humano avalia a satisfação e itera na especificação se necessário
O humano não intervém na execução. O humano intervém na definição e na avaliação.
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.
A habilidade crítica: escrever specs para um agente
O gargalo do Lab não é a velocidade de implementação – é a qualidade da spec. Escrever uma spec suficientemente precisa para que um agente implemente corretamente sem intervenção humana é uma habilidade nova. Quase ninguém a desenvolveu.
A dificuldade: 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.
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.
4. 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 nativo em IA
- 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.
5. 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.
6. 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 spec → agente → cenário → avaliação deve ser rápido. Se uma iteração leva dias, o ciclo é pesado demais
7. Armadilhas a evitar
- 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.
- Especificações insuficientes – quando o agente produz código ruim, o problema está na spec. Itere na spec, não no código.
- Isolamento – um Lab que não compartilha seus aprendizados é um hobby, não um Lab.
- 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.
- Perfeccionismo de agente – o objetivo não é um agente perfeito. É um agente que produz valor. Itere.
- 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.
- 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.
- 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.
8. Ciclo de vida
O Lab começa com projetos greenfield e inicia a transição de 1-2 projetos brownfield selecionados. Equipe pequena. Regras absolutas em vigor. Output = projetos entregues + práticas documentadas + agentes funcionando + playbook de transição brownfield.
Os projetos brownfield em transição no Lab tornam-se os casos de referência para o restante da engenharia. Os engenheiros que passaram pelo Lab tornam-se os parceiros de dupla para quem ainda não passou. Mais projetos brownfield entram no Lab.
O Lab absorveu a engenharia. A distinção desaparece. Tudo é Rung 5. O Lab nunca foi um destino – foi o veículo de transição. Tanto projetos greenfield QUANTO brownfield operam sob as mesmas regras.
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