O problema do Airbus A320: por que o piloto importa

Em 8 de junho de 1988, um Airbus A320 fez seu voo inaugural de demonstração em um show aéreo em Habsheim, França. O avião era a aeronave comercial mais avançada do mundo, a primeira a usar controles fly-by-wire completos onde computadores mediavam cada input do piloto para as superfícies de controle. O piloto planejou um dramático rasante sobre a pista. Os computadores, detectando que o avião estava muito baixo e muito lento, começaram a sobrepor os inputs do piloto para prevenir o que calcularam como uma condição perigosa. O resultado foi um acidente na borda do aeródromo.

O incidente lançou décadas de debate sobre a relação entre autoridade humana e sistemas automatizados. Também produziu um dos frameworks mais importantes em design de automação: a ideia de que o objetivo não é remover o humano do processo, mas definir claramente o que o humano controla e o que a máquina controla, e garantir que o humano sempre tenha a informação necessária para intervir.

O desenvolvimento de software está entrando na mesma conversa.

O que fly-by-wire realmente mudou

Antes do fly-by-wire, pilotos tinham conexões mecânicas diretas com as superfícies de controle da aeronave. Puxar o manche, e cabos fisicamente moviam os ailerons. O piloto sentia a aeronave através dos controles. Cada input era direto, imediato e físico.

Fly-by-wire substituiu esse link mecânico por computadores. Os inputs do piloto se tornaram solicitações que o computador de voo interpretava, modificava por segurança e então executava. O piloto ainda voava o avião, mas o computador podia recusar inputs perigosos, suavizar turbulência e otimizar consumo de combustível de formas que nenhum humano conseguiria gerenciar manualmente.

O resultado foi transformador. Aeronaves fly-by-wire são mais seguras, mais eficientes em combustível e mais fáceis de pilotar que suas predecessoras mecânicas. Mas introduziram uma nova categoria de risco: o piloto que para de prestar atenção porque o computador “está cuidando.”

Complacência com automação

Pesquisadores de aviação chamam de complacência com automação: a tendência dos humanos de reduzir sua vigilância quando acreditam que um sistema automatizado está funcionando bem. Pilotos que dependem demais do piloto automático perdem consciência situacional. Param de monitorar ativamente o estado da aeronave porque o computador tem sido confiável por horas. Quando algo incomum acontece, o piloto que não estava prestando atenção leva mais tempo para diagnosticar e responder do que o piloto que estava voando ativamente.

Isso não é uma fraqueza de pilotos individuais. É uma consequência previsível de como a atenção humana funciona. Somos programados para conservar esforço cognitivo. Quando um sistema executa uma tarefa de forma confiável, redirecionamos a atenção para outro lugar. Isso é adaptativo em muitos contextos, mas é perigoso quando o sistema automatizado encontra uma situação para a qual não foi projetado.

O paralelo com agentes de código é desconfortável mas importante. Um desenvolvedor que roda agentes o dia todo e faz merge da produção sem revisão cuidadosa está experimentando complacência com automação. O agente tem produzido bom código por semanas, então o desenvolvedor para de ler cada linha. Quando o agente comete um erro arquitetural sutil, o desenvolvedor não percebe porque sua atenção estava em outro lugar.

Por que piloto automático total falha

A aviação aprendeu cedo que piloto automático total, onde o humano é removido completamente, falha precisamente nas situações onde o julgamento humano mais importa: cenários novos, sinais conflitantes e casos limítrofes que caem fora dos dados de treinamento do sistema.

Um sistema de piloto automático é excelente em manter altitude, seguir um plano de voo e gerenciar operações rotineiras. É fraco em lidar com um impacto de ave, uma falha repentina de instrumentos ou um padrão climático inesperado que requer tomada de decisão criativa. Essas situações demandam o tipo de raciocínio contextual, intuição baseada em experiência e resolução adaptativa de problemas que humanos fazem bem e sistemas automatizados não.

Agentes de código enfrentam o mesmo limite. São excelentes em tarefas bem definidas: escrever testes para código existente, refatorar módulos segundo padrões claros, implementar funcionalidades a partir de especificações detalhadas. Têm dificuldade com requisitos ambíguos, decisões arquiteturais entre equipes e o tipo de julgamento de produto que requer entender intenção do usuário, contexto de negócio e política organizacional simultaneamente.

A lição da aviação não é que sistemas automatizados não são confiáveis. É que sua confiabilidade tem limites, e esses limites são exatamente onde o julgamento humano se torna crítico.

O modelo do cockpit

A aviação moderna resolveu essa tensão com um modelo que nem remove o piloto nem ignora as capacidades da automação. O piloto é o capitão. Os computadores são a tripulação. Cada um tem responsabilidades definidas, e cada um tem mecanismos para se comunicar com o outro.

Os instrumentos do cockpit existem especificamente para manter a consciência do piloto. Mostram o que o piloto automático está fazendo, por que está tomando certas decisões e quando está chegando ao limite do seu envelope operacional. O piloto não precisa voar a cada segundo, mas sempre precisa saber o que o avião está fazendo.

Este é o modelo que equipes de software deveriam adotar para agentes de código. O desenvolvedor é o capitão. O agente é a tripulação. O agente lida com o trabalho rotineiro, as tarefas que são bem definidas e onde a execução automatizada é mais consistente que o esforço manual. O desenvolvedor lida com arquitetura, decisões de julgamento, casos limítrofes e revisão.

Mas o modelo só funciona se o desenvolvedor sabe o que o agente está fazendo. E isso requer instrumentos.

Construindo o cockpit para agentes de código

Na aviação, os instrumentos do cockpit não são negociáveis. Nenhum piloto voaria um avião com instrumentos apagados, independentemente de quão bom seja o piloto automático. Os instrumentos não são algo desejável; são o mecanismo pelo qual o piloto mantém a consciência necessária para intervir quando importa.

A maioria dos agentes de código hoje é entregue sem instrumentos. O desenvolvedor lança um agente, o agente trabalha em relativo silêncio, e o desenvolvedor vê a produção apenas quando está completa. Não há consciência em tempo real do que o agente está fazendo, não há reporte estruturado de decisões tomadas, e não há alertas quando o agente encontra condições que poderiam justificar intervenção humana.

Esta é a lacuna que o Dailybot preenche. Ao capturar relatórios de progresso dos agentes e apresentá-los na linha do tempo compartilhada da equipe, o Dailybot fornece os instrumentos do cockpit para equipes de desenvolvimento humano-agente. Gestores e desenvolvedores veem o que os agentes estão fazendo, podem avaliar se o agente está no caminho certo e podem intervir quando julgamento é necessário, tudo sem precisar ficar em cima de cada tecla pressionada.

O piloto ainda importa

O Airbus A320 se tornou uma das aeronaves comerciais mais bem-sucedidas da história. Não porque removeram o piloto, mas porque redefiniram o papel do piloto: menos execução manual, mais supervisão estratégica, melhor informação e autoridade mais clara sobre as decisões que importam.

A era agêntica no desenvolvimento de software seguirá o mesmo arco. Os desenvolvedores que prosperarão não serão os que escrevem cada linha de código manualmente. Serão os que souberem quando deixar o agente voar, quando assumir os controles e como manter a consciência situacional que torna essas decisões possíveis.

O piloto importa. Os instrumentos que mantêm o piloto informado importam igualmente.