O checklist do Uncle Bob para trabalhar com IA


Uma ideia muito forte do Uncle Bob sobre IA:

“Sem restrições, os agentes fazem qualquer coisa.”

Por isso ele insiste muito na criação de “physical barriers”.

Ou seja: mecanismos concretos que limitam o que a IA pode fazer dentro do sistema.

O checklist que ele sugere é interessante:

  • unit tests com cobertura extremamente alta (os agentes usam os testes para entender o comportamento esperado do sistema)
  • acceptance tests escritos em Gherkin/BDD (testes legíveis por humanos funcionando como “leis” do sistema)
  • mutation tests (a ferramenta altera automaticamente partes do código (por exemplo trocando > por < ) para verificar se os testes detectam o problema. Se os testes continuam passando, significa que eles provavelmente estão fracos)
  • linters (evita erros básicos e força padrões mínimos de código)
  • dependency checkers (controlam dependências entre módulos e ajudam a proteger a arquitetura)
  • code coverage tools (forçam os agentes a cobrirem partes esquecidas do sistema)
  • CRAP metric: complexidade ciclomática + cobertura de testes (ajuda a identificar funções complexas e perigosas)
  • architecture viewers (ajudam humanos a visualizar sistemas que ficaram grandes demais para entender só lendo código)
  • implementation plans com checkpoints (evita que agentes saiam implementando coisas longas sem supervisão)

A ideia é simples: não confiar apenas em prompts e instruções.

Porque os agentes:

  • esquecem contexto
  • ignoram regras
  • focam demais na última instrução
  • “compactam” memória quando o contexto enche
  • começam a agir de forma imprevisível

Então os testes deixam de ser apenas garantia de qualidade e viram mecanismos de controle dos agentes.

Achei especialmente interessante essa frase implícita no episódio: “tests are documentation for the AI”.

A IA lê os testes para entender o comportamento esperado do sistema.

Talvez esse seja um dos pontos mais contraintuitivos da era de IA: quanto mais código conseguimos gerar automaticamente, mais importante fica criar mecanismos que impeçam o sistema de degradar silenciosamente ao longo do tempo.

Fonte: episódio “Agentic Discipline”, do Clean Coders / Uncle Bob.

Leo Andreucci - CTO Mentor

Ex-VP Engineering @ Creditas ($4.8B). 20+ years building and scaling tech teams. Today, I help CTOs make better decisions.

Read more from Leo Andreucci - CTO Mentor

Imagina la siguiente situación: eres responsable de algunos equipos de desarrollo. Esos equipos tienen stakeholders. El CEO de la empresa se acerca a uno de ellos y le pregunta por qué una determinada iniciativa está retrasada o por qué no se alcanzó algún resultado. Escenario A: el stakeholder se queja del equipo de tecnología. Dice que el equipo no entrega, que es lento, que no entiende lo que realmente necesita. Escenario B: el stakeholder dice que hubo algunos obstáculos, pero que está...

Imagine a seguinte situação: você é responsável por alguns times de desenvolvimento. Esses times tem stakeholders. O CEO da empresa chega para um dos stakeholders e pergunta por que uma determinada iniciativa está atrasada ou algum resultado não foi entregue. Cenário A: o stakeholder reclama do time de tecnologia. Diz que o pessoal não entrega, que é lento, que não entendem o que ele realmente precisa. Cenário B: o stakeholder diz que houve alguns obstáculos, mas que ele está trabalhando bem...

Camille Fournier escribió un muy buen artículo sobre el uso de IA en equipos. Es la autora de The Manager's Path, uno de los libros que más recomiendo para quienes lideran equipos de tecnología. La idea central del artículo es diferente de la mayoría de las discusiones sobre IA. No trata de seguridad ni de compliance. Trata de respeto hacia tus compañeros de trabajo. La idea es simple: La IA puede aumentar mucho la productividad individual. Pero eso no puede ocurrir a costa de la...