Quem anda por San Francisco já se acostumou a ver carros sem ninguém ao volante. Eles param no sinal, esperam o pedestre atravessar e contornam obras na pista. Da calçada, parece que o carro simplesmente sabe dirigir.
O que torna isso possível vai além do modelo que decide cada manobra. O carro opera dentro de um conjunto de peças que trabalham juntas: um mapa detalhado das ruas, sensores que se confirmam entre si, uma área de operação delimitada, regras que vetam manobras perigosas e uma equipe remota que assume os casos difíceis. O modelo é uma parte do sistema, e a confiança vem do conjunto.
A IA que escreve código tem o mesmo problema
Agentes de IA já redigem requisitos, propõem arquiteturas, escrevem código e geram testes. A capacidade dos modelos sobe a cada versão. Mesmo assim, um agente solto num repositório, sem o contexto do negócio e sem limites, produz um trabalho difícil de confiar. Ele não sabe quais regras a empresa segue, quais decisões já foram tomadas nem onde não pode mexer.
Por isso, a pergunta mais útil para quem lidera tecnologia é em que estrutura o modelo vai trabalhar: com qual contexto, dentro de quais limites e com quem revisando o resultado.
O harness, a estrutura em volta da IA
No Tog Method, essa estrutura se chama harness. É o conjunto de contexto, regras, agentes, padrões de arquitetura e verificações que faz a IA trabalhar dentro do padrão da empresa. A IA gera, as verificações barram o que foge da regra e um profissional da Tog Lab revisa antes de publicar.
Tudo começa pelo contexto. Modelos de IA acertam mais quando recebem o contexto do negócio, por isso todo projeto começa por um Domain Context: a fonte única com as regras, os riscos e as decisões que orientam cada etapa. No carro, esse é o papel do mapa detalhado das ruas.
Peça por peça
A correspondência entre as duas estruturas é quase direta. Cada peça que dá segurança ao carro tem um equivalente no ciclo de desenvolvimento.
| No carro sem motorista | No Tog Method |
|---|---|
| Mapa detalhado de cada rua | Domain Context |
| Câmeras, lidar e radar redundantes | Testes automatizados e TDD |
| Área de operação delimitada | Escopo e permissões |
| Regras que vetam manobras perigosas | Guardrails que bloqueiam ações destrutivas |
| Equipe remota para casos difíceis | Revisão de um profissional da Tog Lab no plano e no pull request |
| Milhões de quilômetros em simulação | Evals e testes de regressão antes do merge |
Os sensores do carro se confirmam entre si: se a câmera falha, o radar e o lidar continuam vendo a rua. No software, os testes automatizados cumprem essa função. Com TDD, o teste é escrito antes do código, e o agente só termina a tarefa quando o teste passa.
A área de operação delimitada vira escopo e permissões. O agente recebe acesso apenas à parte do repositório e às ferramentas que a tarefa pede. As regras que vetam manobras perigosas viram guardrails: ações destrutivas, como apagar dados ou mexer em produção, são bloqueadas por regra antes de rodar.
A equipe remota que assume os casos difíceis corresponde à revisão de um profissional da Tog Lab, que acontece em dois momentos: no plano, antes de o agente começar, e no pull request, antes de o código entrar. E os quilômetros rodados em simulação viram evals e testes de regressão, que verificam o comportamento antes do merge.
Nada avança para a etapa seguinte sem que uma pessoa leia e aprove o documento da etapa atual.
Uma pessoa aprova cada etapa
No AI-Accelerated, o modelo de desenvolvimento com IA da Tog Lab, o trabalho passa por sete etapas: contexto, requisitos, arquitetura, especificação, protótipo, código e testes, e infraestrutura. Cada uma gera um documento que alguém lê e aprova. Agentes fazem o trabalho pesado entre uma decisão e outra. Pessoas do time do cliente e da Tog Lab decidem o que entra e revisam todo o código antes de ir para produção.
O nível de autonomia da IA tem um limite definido para cada tipo de tarefa. Como no carro, a autonomia cresce à medida que a estrutura mostra que dá conta. Numa proposta comercial, só entra como promessa o que já foi validado em cliente.
Onde a analogia para
Toda analogia tem limite. O carro decide em frações de segundo, no meio do trânsito, e um erro tem consequência física imediata. No software, existe tempo entre gerar e publicar: o código passa por testes, verificações e revisão antes do merge, e uma mudança pode ser desfeita. Isso permite colocar a pessoa nos pontos de decisão do fluxo, onde a aprovação dela tem mais efeito.
Há outra diferença importante. No carro, a estrutura pertence ao fabricante. No AI-Accelerated, ela pode rodar dentro da conta de nuvem do cliente, com a chave de modelo dele e o modelo de IA que ele escolher. Trocar de modelo é uma mudança de configuração: contexto, regras, agentes e verificações continuam os mesmos, e o projeto não precisa ser refeito.
O que isso muda para quem contrata
Para quem contrata desenvolvimento com IA, a estrutura em volta do modelo pesa tanto quanto o modelo. Na prática, isso significa três coisas.
- Você acompanha o projeto pelos documentos de cada etapa e aprova antes de a próxima começar.
- Repositório, documentação e chaves ficam em nome da sua empresa desde o primeiro commit.
- A escolha do modelo de IA fica com você, e trocar de modelo não obriga a refazer o projeto.
Na hora de avaliar um fornecedor, vale perguntar como ele organiza essa estrutura: onde está o contexto do negócio, o que as verificações barram, quem revisa e o que fica registrado.