Resumo em cinco segundos
A IA mais rápida não é necessariamente a que responde primeiro. Em automação séria, velocidade é chegar ao sistema pronto com menos retrabalho.
Em alguns dias, aproximadamente uma semana de mudanças intensas, um pipeline de conteúdo saiu de “pedir texto à IA e salvar arquivo” para uma pequena fábrica autônoma com monitoramento, recuperação, controle de concorrência, checkpoints, isolamento de trabalho problemático, gates de qualidade e rastreamento de evidências.
Para grandes mudanças de arquitetura, ultra pode ser valioso porque coordena vários fluxos de trabalho em paralelo. Uma execução pode custar mais tempo e recursos, mas pode reduzir a sequência “implementar, achar falha estrutural, refazer, testar de novo, achar outra race condition”.
Em linguagem industrial: o tempo de ciclo pode aumentar, mas o lead time total pode cair porque o retrabalho diminui.
Aviso: Level 6 e Level 7 não são padrões universais
Os níveis deste artigo são rótulos internos para explicar maturidade. Não são certificações ISO nem uma escala oficial do setor.
A inspiração conceitual se aproxima de autonomic computing da IBM: sistemas capazes de se autoconfigurar, se autocurar, se auto-otimizar e se autoproteger.
Aqui, Level 6 é voltar sozinho para um estado correto já definido. Level 7 é procurar uma política de operação melhor sem violar limites rígidos de segurança e qualidade.
Começou com “deixa a IA escrever”. Depois o blog ganhou fencing
Uma automação simples agenda, gera texto, salva, envia e chama um humano quando falha.
Com vários idiomas, auditoria, links internos, atualização e decisão de publicação, as perguntas mudam: e se dois workers mexerem no mesmo item? Onde retomar depois de uma queda? Como impedir retry infinito? Como evitar que auditoria velha vire evidência nova? Como impedir que a IA invente revisão humana? O trabalho local seguro continua se um serviço externo cair?
Nesse ponto, não é só blog. É um pequeno sistema de produção cujo insumo é conteúdo.
Level 6: quebrar, recuperar e voltar ao estado conhecido
Level 6 parte de um estado-alvo definido e compara continuamente o estado atual com ele.
Entre os mecanismos estão desired state, reconciliation loop, lease/fencing, checkpoint formal, CAS, transactional outbox, retry limitado, quarantine, gate seguro de publicação, failure injection e observability.
Em um snapshot operacional, todos os 21 requisitos de implementação de Level 6 estavam em PASS e a implementação de controle marcava 100. Mesmo assim, o assurance estava em cerca de 69%, a publicação permanecia em HOLD e o Level 7 seguia desligado porque ainda faltavam medições externas, evidência humana e histórico operacional maior.
Ou seja: 100% implementado não significa 100% comprovado em operação real por longo prazo.
Sol profundo versus Ultra: um especialista pensando mais versus vários especialistas em paralelo
A OpenAI descreve max como um nível de raciocínio mais profundo para GPT-5.6 Sol, enquanto ultra coordena múltiplos agentes em fluxos paralelos para tarefas complexas.
Sol profundo é como entregar repositório e requisitos a um engenheiro excelente e dar tempo para pensar.
Ultra parece mais uma sala com arquiteto, implementador, tester, crítico e uma pessoa cuja missão é “vamos tentar quebrar isso”, com os resultados combinados depois.
Não é simplesmente dobrar inteligência. É atacar pontos cegos diferentes ao mesmo tempo.
Nos números públicos da OpenAI para Terminal-Bench 2.1, Sol aparece com 88,8% e Sol Ultra com 91,9%. Pelo lado da falha, 11,2% contra 8,1% representa aproximadamente 28% menos falhas nesse benchmark específico. Isso não é promessa de 28% menos bugs em qualquer projeto, mas mostra a direção do ganho em trabalho complexo e divisível.
Por que uma execução mais pesada pode ser mais rápida no total
Uma conta mais útil é:
Lead time total = implementação inicial + retrabalho + novos testes + recuperação de incidente + correção de mal-entendido
Uma resposta em 30 minutos que cria seis horas de refatoração não foi realmente rápida. Uma tentativa de duas horas que evita essas seis horas venceu.
Isso é engenharia da qualidade: produzir defeitos muito rápido e descartá-los na inspeção final não é eficiência.
Depois do “soco de Ultra”, boa parte do trabalho posterior reforçou evidência e observabilidade, em vez de substituir a arquitetura. Exemplos: provar execução real de cada worker, impedir reaproveitamento de auditoria antiga, separar revisão de IA e revisão humana, marcar UNKNOWN quando falta evidência externa e aceitar NOOP correto como resultado válido.
É menos “refazer a fundação” e mais colocar o QC dentro da fábrica pronta para calibrar cada instrumento.
Por que o primeiro desenho resistiu
Não foi perfeito de primeira. Ele resistiu porque já perguntava sobre colisões, morte no meio do processo, escrita atrasada de worker antigo, falha de API externa, retry infinito, checker quebrado e falso sucesso.
Chaos Engineering usa uma lógica parecida: definir steady state mensurável, introduzir falhas realistas e tentar provar que o sistema não aguenta.
Em português simples: faça o teste chorar antes da produção.
Quão impressionante é no mundo real?
É claramente mais maduro que geração simples de conteúdo com IA ou uma automação linear de Zapier/n8n, porque trata concorrência, recuperação, integridade de estado, evidência e isolamento de falhas.
Ele já compartilha vários temas arquitetônicos com um backend sério de SaaS pessoal ou uma plataforma interna de automação de empresa pequena.
Mas ainda está abaixo de serviços comerciais maduros com equipes dedicadas de SRE e segurança, que têm meses ou anos de operação, validação independente, histórico de carga e métricas de impacto real em usuários.
Comparar com infraestrutura de Google ou Amazon é outra escala de universo.
O detalhe incomum em um projeto individual não é “a IA escreve artigos”. É a quantidade de engenharia dedicada a o que fazer quando dá errado.
Level 7: o gerente da fábrica começa a experimentar
Level 7 mediria qualidade, throughput, custo, latência, idade do backlog e taxa de falha. Regras duras ficariam fora do alcance do otimizador. Novos prompts e políticas seriam testados em shadow, promovidos via canary e revertidos automaticamente se as métricas piorassem. Se a confiabilidade cair, congela-se o experimento, não a produção conhecida como segura. Cada teste entra num ledger com hipótese, baseline, resultado e ponto de rollback.
Isso combina ideias de self-optimization da IBM, error budget do Google SRE e canary/rollback.
Mas ativar Level 7 cedo demais complica diagnóstico enquanto Level 6 ainda coleta evidência operacional. O próximo passo mais útil é um ledger único por worker, mostrando execução, entrada, saída, checkpoint e motivo de NOOP.
Use o mês pago como mês de investimento em equipamento
Ultra não precisa fazer cada correção pequena. Workers repetitivos, auditorias conhecidas e patches menores muitas vezes ficam bem com Sol normal ou raciocínio profundo.
Ultra faz mais sentido em redesenho de sistema, grande refactor, topologia de workers, recuperação, fronteiras de segurança, infraestrutura shadow e grandes baterias de falhas simuladas.
A estratégia racional é operar normalmente, acumular melhorias de alto impacto e usar o modo mais forte como uma janela concentrada de investimento na fábrica.
A maior lição da semana
Capacidade prática de IA não é só acertar respostas. Importam arquitetura inicial, capacidade de refutar a própria solução, paralelismo, evidência do que realmente rodou e recuperação depois de falhas.
Uma boa fábrica autônoma não é a que nunca falha.
É a que espera falhas, não fabrica sucesso falso, mantém trabalho seguro em movimento e sabe voltar ao estado conhecido.
Conclusão: velocidade é o tempo até a linha de chegada
O salto de aproximadamente uma semana não aconteceu só porque a IA escreveu código rápido. O ganho veio de concentrar raciocínio forte nas decisões arquitetônicas caras e depois voltar a produção rotineira para uma operação estável e mais barata.
Ultra é menos um botão mágico de acerto e mais uma forma de pagar agora para evitar retrabalho depois.
Se uma execução demora mais, mas o projeto termina antes, essa foi a execução mais rápida.
- OpenAI GPT-5.6: https://openai.com/index/gpt-5-6/
- IBM Research Autonomic Computing: https://research.ibm.com/publications/autonomic-computing-architectural-approach-and-prototype
- Google SRE Error Budget: https://sre.google/workbook/error-budget-policy/
- Principles of Chaos Engineering: https://principlesofchaos.org/
- AWS Canary Deployments: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/canary-deployment.html
