Quem anda por San Francisco já se habituou a ver carros sem ninguém ao volante. Param nos semáforos, esperam que o peão atravesse e contornam obras na via. Do passeio, parece que o carro simplesmente sabe conduzir.
O que torna isto possível vai além do modelo que decide cada manobra. O carro opera dentro de um conjunto de peças que funcionam 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 equipa 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 aumenta a cada versão. Mesmo assim, um agente à solta num repositório, sem o contexto do negócio e sem limites, produz um trabalho em que é difícil confiar. Não sabe que regras a empresa segue, que 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 que contexto, dentro de que limites e com quem a rever o resultado.
O harness, a estrutura à volta da IA
No Tog Method, essa estrutura chama-se 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 travam o que foge à regra e um profissional da Tog Lab revê antes de publicar.
Tudo começa pelo contexto. Os modelos de IA acertam mais quando recebem o contexto do negócio, por isso todos os projetos começam por um Domain Context: a fonte única com as regras, os riscos e as decisões que orientam cada etapa. No carro, este é 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 condutor | No Tog Method |
|---|---|
| Mapa detalhado de cada rua | Domain Context |
| Câmaras, lidar e radar redundantes | Testes automatizados e TDD |
| Área de operação delimitada | Âmbito e permissões |
| Regras que vetam manobras perigosas | Guardrails que bloqueiam ações destrutivas |
| Equipa 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 confirmam-se entre si: se a câmara falha, o radar e o lidar continuam a ver 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 passa a ser âmbito 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 passam a ser guardrails: ações destrutivas, como apagar dados ou mexer em produção, são bloqueadas por regra antes de serem executadas.
A equipa 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 percorridos em simulação passam a ser 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 da equipa do cliente e da Tog Lab decidem o que entra e reveem 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 está à altura. Numa proposta comercial, só entra como promessa o que já foi validado num cliente.
Onde a analogia termina
Todas as analogias têm limites. 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 alteração pode ser revertida. Isto permite colocar a pessoa nos pontos de decisão do fluxo, onde a sua aprovação tem mais efeito.
Há outra diferença importante. No carro, a estrutura pertence ao fabricante. No AI-Accelerated, pode correr dentro da conta na nuvem do cliente, com a sua chave de modelo e o modelo de IA que escolher. Trocar de modelo é uma alteração de configuração: contexto, regras, agentes e verificações mantêm-se, e o projeto não tem de ser refeito.
O que isto muda para quem contrata
Para quem contrata desenvolvimento com IA, a estrutura à volta do modelo pesa tanto como o modelo. Na prática, isto significa três coisas.
- 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 é sua, e trocar de modelo não obriga a refazer o projeto.
Na altura de avaliar um fornecedor, vale a pena perguntar como organiza essa estrutura: onde está o contexto do negócio, o que as verificações travam, quem revê e o que fica registado.