Quando produzir código fica barato e compreendê-lo não

Discussões sobre o efeito da geração assistida de código na engenharia de software tendem a se organizar em torno de uma pergunta mal formulada — se a ferramenta aumenta ou não a produtividade. A formulação é problemática porque trata produtividade como grandeza única, quando o trabalho de software compreende atividades cujos custos foram alterados de maneira desigual. Escrever ficou substancialmente mais barato. Revisar, compreender e responder pelo que entra em produção permaneceu com o custo que sempre teve.

A proposição central deste texto é que essa assimetria, e não o ganho absoluto de velocidade, é o fenômeno que exige resposta da liderança técnica. Quando um dos termos de uma relação tem seu custo reduzido e o outro não, o sistema não fica uniformemente mais rápido: ele se reorganiza em torno do termo que permaneceu caro, e o que antes era folga passa a ser restrição.

O deslocamento da restrição

Durante décadas, o planejamento de equipes de engenharia assumiu implicitamente que a capacidade de produzir era o fator limitante. Estimativas, dimensionamento de time e negociação de escopo derivavam dessa premissa, ainda que raramente enunciada. A premissa era razoável enquanto escrever código constituía a parcela dominante do esforço.

Reduzido o custo de produção sem redução equivalente no custo de verificação, a restrição migra. Ela se aloja onde há capacidade humana escassa e não substituível: a fila de revisão, a compreensão do que está sendo integrado, a capacidade de diagnosticar quando algo falha em produção. Equipes que otimizam apenas a etapa cujo custo caiu observam o efeito com alguma defasagem, geralmente quando a manutenção começa a consumir proporção crescente do tempo disponível.

Há uma consequência contraintuitiva nesse rearranjo. Acelerar a produção sem ampliar a capacidade de verificação pode reduzir a vazão do sistema como um todo, pois aumenta o trabalho em curso sem aumentar a taxa de conclusão — um resultado bem estabelecido na literatura de sistemas de fluxo, e que a engenharia de software redescobre periodicamente sob nomes diferentes.

Por que as métricas usuais deixam de informar

A pressão por demonstrar retorno de uma tecnologia recém-adotada favorece indicadores de coleta fácil, e no caso presente os mais acessíveis são também os menos informativos: volume de código produzido, número de sugestões aceitas, percentual de adoção da ferramenta pela equipe. Nenhum deles guarda relação demonstrável com a qualidade do software resultante.

O problema não é novo. Linhas de código sempre foram um indicador ruim, com a diferença de que antes eram apenas inúteis e agora são ativamente enganosas, por medirem precisamente a atividade cujo custo caiu. Um aumento de volume acompanhado de aumento proporcional na fila de revisão não representa ganho algum, mas produz um gráfico ascendente.

Os indicadores que preservam capacidade informativa são os que já existiam e que se referem a resultado: tempo entre a decisão de mudar e a mudança em produção, frequência com que uma alteração provoca falha, tempo para restabelecer o serviço após incidente. Conjuntos consolidados como as métricas DORA e o quadro SPACE se organizam justamente sobre essa distinção, e sua virtude no contexto atual é serem indiferentes a quem ou o que escreveu o código.

A pergunta que informa não é quanto código foi produzido, e sim quanto do que está em produção alguém consegue explicar sem recorrer à ferramenta que o gerou.

Autoria como propriedade operacional

Convém distinguir aceitar uma sugestão de assumir a autoria dela, porque a diferença não é de mérito profissional e sim de capacidade operacional. Quem assume autoria consegue sustentar a decisão em revisão, adaptá-la quando o requisito mudar e investigá-la quando falhar em horário inconveniente. Código cuja lógica ninguém no time consegue reconstituir constitui dívida técnica independentemente de sua qualidade intrínseca, porque a manutenibilidade não é propriedade apenas do artefato, mas da relação entre o artefato e quem o mantém.

Essa observação tem implicação direta sobre o processo de revisão. Revisar código gerado exige atenção de natureza distinta da revisão convencional: o texto costuma ser sintaticamente correto, idiomático e plausível, o que suprime justamente os sinais superficiais que revisores usam para alocar atenção. A plausibilidade sem correção é uma categoria de erro para a qual os hábitos de revisão não foram desenvolvidos.

O efeito sobre a formação profissional

Há um efeito de segunda ordem que merece registro, ainda que suas consequências só se manifestem em horizonte mais longo. A formação de profissionais em início de carreira sempre dependeu do enfrentamento de problemas pequenos e da experiência de errar neles — mecanismo pelo qual se constrói o repertório que, mais tarde, permite reconhecer padrões em problemas grandes.

Boa parte desses problemas pequenos passou a ser resolvida antes de se converter em ocasião de aprendizado. A consequência não é que se aprenda menos, e sim que se aprenda outras coisas, e provavelmente mais tarde. Cabe à liderança recriar deliberadamente as condições que a ferramenta suprimiu, o que na prática significa revisão conjunta, explicação verbalizada de decisões e discussão das alternativas descartadas — atividades que consomem tempo e cuja supressão não produz efeito visível no curto prazo, o que as torna candidatas naturais ao corte.

As decisões que não podem permanecer implícitas

Três definições costumam permanecer tácitas em organizações que adotaram a ferramenta sem deliberação, e a ausência de cada uma produz um tipo distinto de exposição. A primeira diz respeito ao dado: onde a ferramenta pode ser usada e com que informação. Cumpre observar que a ausência de política não corresponde a ausência de uso — corresponde a uso sem registro, o que é situação pior do ponto de vista de quem responde pela organização.

A segunda diz respeito ao grau de autonomia admissível, que deveria variar inversamente ao impacto do erro. Trata-se de princípio já estabelecido em outros domínios de automação, e sua aplicação aqui implica que a exigência de revisão humana não pode depender da aparência de correção do resultado, uma vez que é precisamente essa aparência que se tornou pouco informativa.

A terceira diz respeito à responsabilidade pelo que entra em produção, cuja resposta não pode ser a ferramenta. A observação parece óbvia enunciada assim, mas dilui-se com facilidade em organizações onde a autoria se tornou difusa e onde a pergunta sobre quem responde por um comportamento inesperado passa a receber respostas evasivas.

O que permaneceu inalterado

Encerra-se pelo que não mudou, porque a atenção dedicada à novidade tende a obscurecer as invariantes. Requisito mal compreendido continua produzindo software incorreto, agora com maior velocidade. Sistema sem observabilidade permanece opaco independentemente de sua origem. Arquitetura inadequada não se corrige por volume de implementação.

Sobretudo, a decisão sobre o que construir — e sobre o que deliberadamente não construir — nunca constituiu um problema de digitação. A ferramenta alterou o custo de escrever; não alterou o custo de decidir errado, que continua sendo pago integralmente e com atraso. É nesse intervalo entre a decisão e sua consequência que a liderança técnica sempre operou, e é ali que sua contribuição permanece.