Como manter o controle quando a IA escreve código mais rápido do que você consegue acompanhar?

Por Márcio Taranto

Muito se fala em vibe coding e na facilidade de transformar uma ideia em software com IA. Essa possibilidade me animou também. Mas, nos meus projetos, logo descobri que gerar código era só uma parte do trabalho. Ainda era preciso entender o problema, decidir o que realmente precisava existir, testar o resultado e perceber quando a solução tinha começado a se afastar do pedido. Também precisava preservar o contexto e reconhecer quando o projeto estava realmente pronto.

Às vezes, eu pedia uma coisa simples, e a IA vinha com uma estrutura que parecia preparada para atender o planeta inteiro, quando eu apenas queria resolver o problema de uma só pessoa. Isso quando ela não alucinava completamente.

Estou no último ano de Engenharia de Software e ainda construindo minha base técnica. A experiência que eu trazia de outras áreas já me ajudava a definir necessidades, regras e o resultado que queria alcançar. Com a IA, passei a transformar essas ideias em projetos que não conseguiria implementar sozinho. Mas também encontrei respostas convincentes e erradas, decisões esquecidas e código que avançava mais rápido do que eu conseguia acompanhar.

Eu já conhecia parte desses riscos pela leitura de artigos, mas foram os meus próprios erros e acertos que me ensinaram as melhores lições. Então comecei a registrar requisitos, delimitar mudanças, preservar decisões e exigir evidências antes de aceitar uma entrega. Aos poucos, percebi que não estava apenas corrigindo problemas isolados. Um método de trabalho começava a surgir organicamente. Sua primeira formulação foi a Diretriz de Engenharia Proporcional: buscar a solução profissional mais simples que resolvesse integralmente o problema, com controles compatíveis com o risco.

Com a evolução dos projetos, organizei também os papéis da IA, os pontos de revisão, os testes, os registros de contexto e as condições de parada. Desse aprendizado, construído projeto após projeto, nasceu o que hoje chamo de The S.C.A.L.E. Method. Ele surgiu no desenvolvimento de software, mas logo começou a orientar também outros tipos de trabalho assistido por IA.

Como essa prática ganhou forma

Nos primeiros projetos assistidos por IA, ainda em 2026, eu já precisava transformar uma necessidade em requisitos, implementar por partes e conferir o comportamento entregue. Com o tempo, comecei a perceber quais cuidados precisavam deixar de depender da minha lembrança e passar a fazer parte do processo.

Foi assim que, em julho, escrevi a primeira versão da Diretriz de Engenharia Proporcional. Ela reunia decisões que eu vinha tomando durante o trabalho: justificar cada nova camada, controlar o escopo e escolher verificações compatíveis com o risco. Registrar essas decisões me ajudava a retomá-las e a orientar a IA com mais consistência.

A Diretriz continuou mudando conforme os projetos revelavam problemas. Passou a tratar de legibilidade, mudanças pequenas, revisão cruzada entre IAs, continuidade do contexto e condições de parada. Também considerava minha autonomia técnica naquele momento, para que os controles fossem compatíveis com aquilo que eu conseguia verificar.

Quando organizei essa prática sob o nome S.C.A.L.E., em agosto, parte dela já estava registrada nos documentos e repositórios dos projetos. O nome veio depois de muitos dos cuidados que deram origem ao método.

O que é o S.C.A.L.E.

S.C.A.L.E. significa Scaled Controls for AI Lifecycle Engineering. É uma forma de organizar o trabalho entre pessoas e IA a partir da Engenharia Proporcional:

Adotar a solução mais simples e legível que resolva integralmente o problema, ampliando processo, controles e evidências somente quando a complexidade, o risco e o impacto justificarem.

Uma landing page estática pode precisar de um briefing curto, validação visual e funcional, acessibilidade essencial e uma forma simples de desfazer alterações. Uma aplicação com persistência e regras de negócio pede especificação mais estruturada, testes das regras críticas, tratamento de erros e revisão adicional. Operações que podem destruir dados ou produzir efeitos graves exigem controles mais fortes.

A pergunta que acompanha essas decisões é: quanto de processo este problema realmente exige?

Isso vale para a arquitetura e para a própria metodologia. Um controle precisa ajudar a evitar, detectar ou tratar um problema. Se ele só acrescenta trabalho, também merece ser questionado.

Como trabalho com o ciclo

Intenção → Contexto → Especificação → Plano → Implementação → Verificação → Revisão → Correção, se necessária → Aceitação

O ciclo se repete em mudanças pequenas. Em tarefas simples, seu registro pode caber em poucas linhas. Não é necessário produzir um documento separado para cada etapa.

Entender e delimitar antes de implementar

Começo pelo problema, pelo usuário e pelo resultado suficiente. Depois, explicito comportamentos, regras, estados, erros e critérios de aceite. A especificação precisa permitir uma comparação objetiva: o que foi entregue corresponde ao que combinamos?

Ela pode mudar quando aprendemos algo durante o trabalho. O cuidado é registrar e decidir essa mudança, em vez de adaptar silenciosamente o combinado ao que a IA conseguiu entregar.

O plano divide a implementação em partes revisáveis e indica riscos, testes e recuperação. Uma vez aprovada essa fronteira, a IA pode corrigir falhas locais e continuar. Não preciso autorizar novamente cada ajuste que já pertence ao trabalho combinado. Se houver mudança relevante de escopo, arquitetura ou risco, a decisão volta para mim.

Preservar contexto

Uma conversa longa pode guardar muita informação e ainda assim perder uma decisão importante. Já vi a IA misturar versões, esquecer restrições e retomar uma linha de trabalho que havia sido abandonada.

Para isso, transformo o que foi discutido e decidido em artefatos: especificações, planos, registros de decisão, resultados de testes e handoffs para a continuidade do trabalho. Conforme a ferramenta, anexo esses documentos à conversa ou os mantenho no repositório e oriento a IA a consultá-los. Eles fornecem o contexto para planejar, escrever o código e verificar a entrega.

Cada documento tem uma função. O S.C.A.L.E. orienta como conduzir o trabalho. A especificação descreve o que o projeto deve fazer. Os planos e registros preservam decisões, limites e o estado da implementação. Assim, a IA recebe uma referência explícita do problema e dos critérios que deverá atender.

Esses artefatos precisam acompanhar a evolução do projeto. Quando uma decisão muda, atualizo a referência correspondente e retiro a versão superada do contexto ativo. Também confiro se a IA está trabalhando sobre os documentos e o estado corretos. Anexar um arquivo, por si só, não garante que ele tenha sido consultado ou compreendido.

Chamo essa avaliação de Context Health. Observo se o contexto é suficiente, relevante, coerente, atual e rastreável. Quando isso falha, consolido o que foi decidido, o que funciona, as pendências e a próxima ação. Uma sessão nova pode ser necessária, mas abrir outra conversa sem levar as decisões apenas muda o lugar do problema.

Verificar o resultado e revisar as decisões

Na implementação, prefiro mudanças pequenas e dependências justificadas. Depois, comparo o comportamento com a especificação por meio de testes, navegador, validadores, análise estática, logs ou outras verificações adequadas.

Uma explicação da IA não basta. Também preciso saber o que o teste verificou, em qual estado do projeto e com quais limitações. Um teste pode passar e ainda deixar escapar uma regra importante.

Em mudanças que exigem revisão adicional, uso outra IA para confrontar requisitos, implementação e evidências. Esse Cross-AI Review ajuda a encontrar inconsistências, mas duas IAs podem concordar e continuar erradas. Quando discordam, procuro transformar a divergência em teste ou inspeção concreta. A revisão humana especializada continua necessária quando a consequência exige.

Corrigir e encerrar

Uma falha volta ao ciclo como um problema delimitado, com correção e nova verificação. Em marcos relevantes, também reviso o conjunto, porque decisões razoáveis isoladamente podem formar uma estrutura difícil de manter quando se acumulam.

Quando os critérios foram atendidos, as evidências são suficientes e não há impedimento crítico, encerro a etapa. Sempre aparece mais alguma coisa que poderia ser melhorada. A questão é se ela precisa ser melhorada agora.

Três níveis de proporcionalidade

O método considera complexidade, risco, impacto, reversibilidade, sensibilidade dos dados e capacidade humana de validação.

A tabela resume a proposta. O documento do método define as condições de aplicação e o que fazer quando um controle não está disponível.

O nível acompanha a mudança que concentra o risco. Uma página simples pode conter uma integração de pagamento que exige outra avaliação. Da mesma forma, executar testes locais não tem o mesmo alcance de executar comandos destrutivos sobre dados reais.

Mais risco exige mais controle e pode exigir menos autonomia para a IA. Se eu não tenho condições de validar uma operação, preciso reduzir o escopo, isolar a execução ou buscar apoio qualificado. Minha dificuldade de verificar não torna a operação menos perigosa.

O que observei nos projetos

Landing pages: simplificar também o processo

Em uma landing page, o briefing delimitou conteúdo, comportamento e exclusões. Banco de dados, login, pagamentos e CMS ficaram de fora porque não atendiam à necessidade. A construção foi incremental, com validações manuais.

Em outra, a experiência anterior permitiu dispensar um wireframe formal. A direção visual já era suficiente para construir por blocos e validar no navegador. Mais tarde, a inclusão de um mapa exigiu atualizar o escopo. Simplificar o processo não significava deixar de acompanhar suas mudanças.

Um sistema de clientes, pendências e lembretes

Em um dos meus projetos, desenvolvi uma aplicação para organizar clientes, acompanhar pendências e lembrar os prazos de atendimento. O uso revelou problemas que uma demonstração rápida poderia esconder: homônimos tratados como a mesma pessoa, informações indevidas vindas do preenchimento automático, perda de foco na busca e mudança de telefone sem uma decisão explícita.

As correções foram delimitadas e acompanhadas de testes. O mecanismo de recuperação também precisou evoluir. Restaurar o banco funcionava, mas o único ponto diário de backup poderia fazer a usuária perder horas de trabalho. A solução passou a manter snapshots rotativos e uma forma de desfazer a própria restauração.

O projeto chegou a uma release instalável, com verificações automatizadas e homologação funcional. Com o conhecimento que tenho hoje, eu não teria conseguido resolver sozinho esses problemas e concluir a entrega no prazo disponível. A combinação de IA e processo ampliou minha capacidade de entregar e corrigir.

Um desafio técnico sob um prazo real

Em um processo seletivo, recebi um desafio com Angular, dois serviços, persistência, produtos, notas, estoque, impressão, falha e recuperação, documentação e vídeo. Trabalhei em 25 de agosto e só consegui retomar em 31 de agosto, o último dia do prazo.

Estimo cerca de três horas no primeiro dia e cinco a seis horas no último. Parti de uma estrutura mínima funcional construída no início e organizei o restante em especificação, checkpoints, implementação, revisão e homologação. O Antigravity realizou grande parte da implementação, o Codex participou da revisão e eu defini requisitos, comparei propostas, acompanhei evidências e aceitei o resultado.

A entrega usou Angular, dois serviços em Go e bancos SQLite separados. Testes verificaram rollback, repetição idempotente, disputa pela última unidade de estoque, indisponibilidade e recuperação. Esses controles entraram por riscos concretos. Não houve necessidade de acrescentar Kafka, Redis, Kubernetes, ORM ou API Gateway.

Um episódio foi especialmente instrutivo: a primeira revisão do Codex considerou um estado antigo do projeto. Pedi evidências do diretório, do repositório, das alterações e dos recursos existentes antes de aceitar a análise. A revisão foi refeita sobre o estado correto. Ter uma segunda IA revisando não adiantaria muito se ela estivesse olhando para outra versão do problema.

A versão submetida foi preservada e passou pelos testes funcionais realizados para a entrega. Até a preparação deste relato, não havia recebido retorno da empresa. O resultado que apresento é a entrega de um escopo relevante em aproximadamente oito a nove horas estimadas de trabalho humano, com validação e controles escolhidos por risco.

Aplicações além do código

Também usei esses princípios para preparar, em uma máquina virtual, uma futura migração entre as gerações do TUXEDO OS baseadas em Ubuntu e Debian. Inventários, planos e handoffs mantiveram a continuidade. A instalação e a configuração inicial do laboratório foram concluídas, e problemas puderam ser tratados antes de qualquer migração física. O laboratório continuou como ambiente de aprendizado e avaliação.

Na reorganização do meu acervo de documentos, inventário, backup verificado, plano e autorização por lotes permitiram conferir o resultado das movimentações. Na busca por recolocação, o cruzamento entre currículo, LinkedIn e relatos da minha experiência ajudou a representar melhor minhas responsabilidades e a selecionar vagas mais aderentes. Depois dessa mudança, avancei em alguns processos, embora não possa atribuir a decisão dos recrutadores exclusivamente ao método.

O que se transfere para esses trabalhos é a relação entre intenção, contexto, plano, evidência e decisão humana. São aplicações observadas no meu contexto. A finalidade principal do documento metodológico continua sendo o desenvolvimento de software assistido por IA.

Resultados, limites e próximos testes

Na minha experiência, houve ganho real de capacidade, tempo e controle. Entreguei projetos funcionais, encontrei e corrigi defeitos e concluí operações que exigiam cuidado. Ainda não tenho medições suficientes para transformar esses ganhos em um multiplicador de produtividade, uma taxa geral de redução de erros ou uma economia financeira exata.

Estou estruturando o acompanhamento de tempo humano ativo, retrabalho, perda de contexto, falhas posteriores e custo direto quando houver. Os casos também não demonstram aplicação validada em todos os cenários críticos previstos no nível P3, nem substituem avaliação especializada nesses ambientes.

Uma próxima avaliação será um piloto de testes de mutação. Quero verificar se a suíte de um módulo crítico percebe pequenas alterações deliberadas no código e se o benefício compensa o esforço. O piloto ainda não foi executado e a técnica não é um controle obrigatório do S.C.A.L.E. A decisão poderá ser adotá-la, restringir seu uso ou deixá-la de fora.

Esse é o estágio da proposta: uma metodologia autoral em validação, nascida dos problemas, das decisões e dos aprendizados dos meus projetos. Depois de organizá-la, reconheci convergências com práticas conhecidas. Não reivindico a invenção de cada conceito nem eficácia cientificamente comprovada.

Por que decidi publicar agora

Depois de organizar o S.C.A.L.E., comecei a procurar deliberadamente abordagens que enfrentassem problemas semelhantes. Encontrei convergências interessantes com trabalhos de Fábio Akita e Robert C. Martin, conhecido como Uncle Bob.

Akita descreve seu Agile Vibe Coding como a aplicação de práticas de XP ao trabalho com agentes: pair programming, testes, feedback curto e refatoração contínua. Em seus relatos, a pessoa acompanha, questiona e corrige a direção. Reconheci muito da dinâmica que eu vinha construindo. A ênfase do S.C.A.L.E. está em explicitar a especificação vigente e graduar os controles conforme o risco e a capacidade humana de validação. Essa é uma diferença de formulação e ênfase, não uma afirmação de que a outra abordagem ignore esses cuidados. Relato de projeto e descrição da abordagem.

No Acceptance Pipeline Specification, de Robert C. Martin, encontrei a ligação entre especificações e testes de aceitação executáveis. O projeto também altera valores dos exemplos para verificar se eles estão realmente conectados ao comportamento testado. Essa mutação de exemplos é diferente da mutação do código prevista no meu piloto. No swarm-forge, a continuidade entre agentes aparece em handoffs persistentes e controle pelo operador. Acceptance Pipeline Specification e swarm-forge.

Essas aproximações ajudaram a situar minha formulação em uma discussão maior. Não significam equivalência entre as propostas ou endosso de seus autores. A sequência que relato é a da minha experiência: primeiro organizei a prática, depois fui procurar e comparar trabalhos relacionados.

Perceber que meus projetos estavam me levando a perguntas também discutidas por profissionais experientes foi uma razão adicional para publicar. Quero expor o que construí, ouvir críticas e descobrir o que continua útil quando outra pessoa tenta aplicar.

Um convite à aplicação e à crítica

Publico o S.C.A.L.E. como Public Draft, uma versão aberta à aplicação, à crítica e à revisão. Este artigo apresenta sua origem e os aprendizados dos projetos. A versão 4.2 do método detalha o ciclo, os controles, a autonomia da IA, a verificação, as condições de parada e a continuidade do contexto.

Quero entender onde o processo ajuda, onde cria trabalho desnecessário e quais decisões continuam ambíguas. Estudos de caso, falhas documentadas e críticas acompanhadas de evidência podem orientar sua evolução.

O que tento tornar visível é uma forma de trabalhar: entender o problema, estabelecer limites, comparar alternativas, verificar o resultado e corrigir o caminho quando a realidade contradiz o plano. Se o S.C.A.L.E. tiver valor para outras pessoas, essa aplicação precisa poder ser examinada fora da minha experiência.

Evidências públicas dos projetos

Os relatos usam descrições genéricas. Os links permitem consultar o código e os registros públicos correspondentes, sem indicar endosso de empresas ou terceiros.

Escrevi este texto relatando minha experiência, minhas decisões e os registros dos projetos. Usei ferramentas de IA para localizar evidências, confrontar versões, organizar a estrutura e revisar a redação.