Ângulo

Um Product Manager equipado com um assistente de código produz em quatro dias o que teria levado um mês, e essa velocidade não diz nada sobre o que ele tem direito de construir. O que diz isso é o estado do terreno sobre o qual ele apoia o trabalho: um catálogo de APIs internas atualizado poupa dele os desvios que fabricam incoerência; testes que carregam a intenção de negócio devolvem a ele uma pega sobre um código que ele não leu; uma codebase cuja linguagem de negócio é legível decide sozinha se ele compõe com blocos existentes ou improvisa ao lado do produto; e controles de segurança automáticos sustentam a única exigência que não se negocia nem com o que está em jogo nem com o prazo. Onde essas quatro peças faltam, a mesma pessoa, com a mesma competência e a mesma ferramenta, só produz objetos que não vai saber nem explicar nem consertar — e a competência técnica dela, quando existe, só atrasa o momento em que isso aparece. O terreno fixa, portanto, ao mesmo tempo o perímetro autorizado e a velocidade alcançável, o que coloca a abertura do código a perfis de produto entre as decisões de arquitetura antes de fazer disso uma questão de permissão.

Síntese

As notas, tomadas separadamente, descrevem cada uma uma peça do problema: a velocidade, os defeitos que o assistente cria sozinho, a autorização, a revisão, os testes, os trilhos, o papel das pessoas desenvolvedoras. O que elas fazem aparecer juntas é um deslocamento do parâmetro de decisão. A discussão corrente recai sobre a pessoa — ela tem bagagem técnica suficiente, é preciso um nível mínimo, é preciso proibir para perfis não técnicos. Cada nota, pega pela sua ponta, remete a outro lugar: ao que foi preparado antes dela.

O mecanismo é o mesmo toda vez, e depende de uma propriedade do assistente: ele não adivinha o que não está escrito em lugar nenhum. Ele desconhece as volumetrias reais, então projeta para o conjunto de teste. Ele não conhece os pontos de entrada legítimos, então inventa alguns. Ele não retém o que você corrigiu ontem, então recomeça. Nenhuma dessas lacunas é preenchida pela competência de quem conduz; todas são preenchidas por uma informação depositada no ambiente — e é isso que joga a responsabilidade para o lado de quem sustenta esse ambiente.

Segue daí uma consequência menos esperada. A competência técnica de quem conduz continua útil, mas o emprego dela muda: ela não serve mais para produzir, serve para detectar — ver um arquivo que cresce demais, sentir uma camada se misturando a outra, reconhecer uma resposta de API que não vai aguentar a carga. Essa capacidade de detecção não tem substituto automático, e é a única coisa que o terreno não fornece. Ela explica por que a questão do perímetro não desaparece: um terreno excelente amplia o que é viável sem tornar o operador capaz de avaliar o que produz.

Falta o que esse ângulo custa à organização. Deslocar a decisão para o terreno equivale a dizer que a abertura do código a outras funções se paga primeiro em trabalho de arquitetura — APIs limpas, convenções mantidas, ambientes seguros, controles automáticos —, ou seja, em despesa sem entregável visível para o cliente. É a linha mais fácil de cortar, e é justamente ela que decide se a abertura produz alívio ou gambiarra. A pergunta "os Product Managers podem desenvolver?" não tem, portanto, resposta geral: ela tem uma por empresa, e essa resposta foi escrita antes de a pergunta ser feita, no estado da codebase.

Tensões / contradições

Essas notas não concordam sobre o peso real da competência individual. As que deslocam a decisão para o terreno pressupõem que as lacunas do assistente são preenchidas pelo ambiente; a que descreve a operação de uma ferramenta lembra que saber diagnosticar uma falha não está escrito em catálogo de API nenhum. Se essa parte for grande, o terreno é apenas uma condição necessária e a competência continua sendo o fator limitante.

Um desacordo mais nítido opõe duas leituras da aceleração. O ângulo defendido aqui trata a velocidade como um benefício a enquadrar, e considera que os mecanismos perdidos são reinstalados pelo terreno. A leitura desenvolvida em outro lugar sobre a fabricação da competência sustenta que alguns desses mecanismos — o erro analisável, o primeiro degrau, o preço do gesto — não são reinstalados por ferramental, porque exigiam ter sido responsável pelo resultado. Nada aqui decide: um terreno que elimina os desvios elimina também as ocasiões de aprender a reconhecê-los.

Por fim, a exigência de segurança não graduada e o afrouxamento da revisão sobre objetos descartáveis convivem mal na prática: elas pedem à mesma organização que afrouxe um controle humano e sustente um controle automático, o que pressupõe um ferramental que as organizações que afrouxam a revisão frequentemente não têm.

Questões

• Que parte do terreno precisa ser construída antes de abrir, e que parte se constrói em resposta aos primeiros usos, correndo o risco de deixar passar os objetos fabricados nesse meio-tempo?
• Um terreno pensado para assistentes e um terreno pensado para pessoas desenvolvedoras divergem, e em que momento é preciso manter dois?
• Como uma organização avalia o estado do próprio terreno antes de abrir, sem ser constatando depois o que foi produzido?
• Em que se baseia a decisão de investir nesse trabalho de arquitetura, quando o benefício dele se mede em incoerências que não aconteceram?