Ideia

Dar um enquadramento a código produzido fora do time técnico é ligá-lo ao ferramental que já existe

Info

Escrito originalmente em francês. Traduzido por IA — o sentido foi preservado, não a prosa.

Ideia principal

Quando um time de produto, de suporte ou de negócio começa a fabricar telas e ferramentas com um assistente, o reflexo é desenhar para ele um regime próprio: sua carta de princípios, suas regras, seu processo de validação, seu nível de exigência. Esse reflexo fabrica um segundo sistema, paralelo ao primeiro, que vai precisar ser mantido separadamente e vai divergir.

Só que o ferramental já existe, e foi construído exatamente para esse problema: integração contínua, scanners de segurança, convenções de repositório, regras de qualidade, ambientes delimitados e, cada vez mais, arquivos de instruções, prompts e skills que os desenvolvedores escrevem para uso próprio. Nada disso precisa ser reinventado para perfis não desenvolvedores; basta que a produção deles passe por ali.

O trabalho de enquadramento é, portanto, um trabalho de conexão — quais repositórios, quais ambientes, quais verificações automáticas se aplicam a essa produção — e não um trabalho de invenção normativa.

Por que isso importa

Isso muda a natureza da pergunta feita ao time técnico. "O que devemos exigir de um Product Manager que programa?" pede uma resposta longa e discutível; "onde a gente pluga isso?" pede uma resposta operacional e em boa parte já disponível.

Também evita uma assimetria absurda, na qual uma produção feita por um perfil de produto seria submetida a regras escritas na hora, mais rígidas ou mais vagas que as aplicadas ao código do time.

Nuances e limites

A conexão pressupõe que o ferramental exista e esteja em bom estado. Numa organização em que as verificações automáticas são fracas, não há em que plugar, e o assunto volta a ser a construção desse ferramental — para todo mundo, não só para os recém-chegados.

Alguns pontos não se conectam e precisam mesmo ser decididos: o escopo dos repositórios acessíveis, os direitos de escrita sobre os dados, a propriedade dos objetos produzidos.

Questões em aberto

  • Que parte do ferramental que os desenvolvedores escrevem para si mesmos continua inutilizável por um não desenvolvedor, por falta de vocabulário comum em vez de falta de permissões?