Programar em par com IA mudou o que eu coloco no quadro branco

Durante a maior parte da minha carreira o quadro branco era onde eu descobria o que digitar. Caixas eram módulos, setas eram chamadas, e a sessão terminava quando eu conseguia ver o código na cabeça. Desde que um modelo passou a escrever a maior parte do código comigo, esse tipo de desenho ficou quase sem valor. O modelo produz o módulo a partir de uma frase. O que ele não produz é a frase. Então o quadro branco subiu um nível, e sinceramente foi para onde deveria ter estado desde o início.

Menos formato de código, mais formato de falha

A primeira coisa que saiu do quadro foi estrutura por si mesma. Não esboço mais hierarquias de classe nem layout de pastas, porque o modelo vai propor algo razoável e eu aceito ou ajusto em minutos. O que entrou no lugar foi falha. Para cada seta que desenho, agora escrevo o que acontece quando a coisa do outro lado está lenta, ausente, duplicada ou mentindo. Isso costumava ser uma segunda passada que eu fazia se sobrasse tempo. Agora é a primeira, porque o comportamento sob falha é a parte que o modelo vai errar se eu não especificar, e vai errar com confiança.

Invariantes e fronteiras

A segunda coisa que cresceu no quadro é uma lista, geralmente num canto, de afirmações que precisam ser sempre verdadeiras. Um pedido nunca é cobrado duas vezes. Um tenant nunca vê as linhas de outro. Um resultado publicado sempre tem fonte. Essas frases são a especificação real do sistema, e se traduzem diretamente em prompts, em testes e em checklists de revisão. Quando passo uma tarefa ao modelo, os invariantes vão junto, e quando reviso a saída, confiro cada um. As caixas e setas são andaime. Os invariantes são o prédio.

Fluxo de dados com posse

A terceira mudança é que todo dado no quadro agora tem um dono e um ciclo de vida, desenhados explicitamente. Onde é criado, quem pode alterar, quando é apagado, para onde é copiado e se as cópias podem divergir. Modelos são muito bons em escrever código que move dados de um lado para o outro, e muito ruins em perceber que o dado agora existe em dois lugares com duas verdades. Essa falha, a que ninguém encontra até a auditoria, é uma falha de quadro branco. Se a posse está desenhada, o código segue. Se não está, o código vai ser escrito sem ela, rápido e bonito.

Para que serve o quadro agora

O quadro branco agora é onde decido as coisas que o modelo não pode decidir: quais trade-offs o produto aceita, qual consistência os dados precisam, o que o usuário deve ver quando algo quebra, qual é o teto de custo, quem aprova as ações irreversíveis. Essas decisões costumavam ficar diluídas em cem pequenas escolhas de código, tomadas meio inconscientemente enquanto eu digitava. Agora precisam ser tomadas de forma deliberada, antes, em palavras, porque a digitação acontece em outro lugar e rápido demais para carregar julgamento junto.

A reunião mudou também

Um efeito colateral que não esperava é que as sessões de quadro branco ficaram mais úteis para quem não escreve código. Quando o quadro está cheio de nomes de módulo, um gerente de produto ou um especialista do domínio acena com educação e espera. Quando o quadro está cheio de falhas, invariantes e posse, eles têm opinião, e a opinião costuma estar certa, porque são perguntas sobre o negócio, não sobre sintaxe. O modelo levou a sintaxe. O que sobrou é a parte que sempre foi o trabalho de verdade, e descobrimos que mais gente consegue fazê-lo do que imaginávamos.