A mentalidade necessária para exercer o novo papel

As orientações desta seção são uma síntese aplicada. Elas articulam o manifesto com as evidências e com princípios de engenharia.

3.1. Identidade profissional ancorada em resultado

O engenheiro precisa conseguir reconhecer sua contribuição mesmo quando nenhuma linha do resultado foi digitada por ele. Descobrir o requisito decisivo, formular um experimento, escolher uma arquitetura simples ou criar um mecanismo de verificação pode exigir mais competência que produzir a implementação correspondente.

Isso muda a fonte do orgulho profissional. Um bom sinal de evolução é conseguir dizer: “o sistema resolve o problema, sabemos em quais condições funciona, acompanhamos seus efeitos e conseguimos modificá-lo com segurança”. A quantidade de esforço visível deixa de ser uma boa medida da importância da contribuição.

Essa orientação também permite rejeitar trabalho desnecessário. Se uma demanda pode ser resolvida com uma mudança de processo, uma configuração ou a remoção de uma etapa, a facilidade de gerar código não obriga a construir uma aplicação nova. Saber eliminar escopo continua sendo uma forma de engenharia.

3.2. Responsabilidade ampliada

A responsabilidade inclui o resultado e o mecanismo que o produziu. Quando uma falha se repete, vale investigar se faltam requisitos, documentação, acesso a evidências, ferramentas, testes ou uma divisão de trabalho melhor.

Um exemplo simples: o agente consulta repetidamente uma API descontinuada. Corrigir cada resposta resolve a tarefa imediata. Tornar a versão correta explícita, disponibilizar documentação atual e adicionar uma verificação pertinente pode eliminar a classe de erro. A segunda intervenção modifica a capacidade do sistema de trabalho.

Nem todo problema precisa virar plataforma. O ponto é escolher a menor melhoria que reduza recorrência de forma verificável: às vezes um exemplo; às vezes um comando; às vezes um teste; às vezes uma decisão organizacional.

3.3. Confiança baseada em evidências

A confiança útil é específica. Pode-se confiar bastante em um agente para atualizar documentação de uma interface bem definida e exigir evidência mais forte quando ele altera autorização, concorrência ou uma migração de dados.

O engenheiro deve aprender a perguntar: qual afirmação estou aceitando, em que evidência ela se apoia e o que poderia mostrar que está errada? A aparência de segurança de uma explicação não substitui um teste, uma medição ou a inspeção do estado real.

Uma pesquisa apresentada na CHI 2025, com 319 trabalhadores e 936 exemplos autorrelatados, encontrou associações entre confiança na IA e esforço crítico, além de uma redistribuição desse esforço para verificação, integração e responsabilidade pela tarefa. O desenho é correlacional e não demonstra perda de capacidade cognitiva. Ele reforça a utilidade de tornar esses hábitos de avaliação explícitos. F16

3.4. Ambição com disciplina de escopo

A IA amplia o conjunto de problemas que um engenheiro consegue explorar. Isso favorece iniciativa: testar hipóteses, produzir protótipos, investigar sistemas desconhecidos e automatizar trabalho que antes parecia caro demais.

Essa capacidade também muda a relação com a iniciativa pessoal. Uma oportunidade que antes esperaria a disponibilidade de várias pessoas pode começar como uma investigação conduzida por um engenheiro com agentes. Ele ganha espaço para atravessar fronteiras entre produto, dados e implementação, tornando uma ideia concreta o suficiente para ser examinada. Exercitar essa liberdade com bons critérios é parte da excelência proposta aqui.

A disciplina correspondente é escolher experimentos que respondam a perguntas importantes. Um protótipo deve permitir aprender algo: se o fluxo é compreensível, se a integração é viável, se a latência cabe no orçamento, se o usuário precisa da funcionalidade. Um protótipo impressionante que não reduz incerteza consome atenção e pode criar compromisso prematuro com uma solução.

É útil distinguir explicitamente exploração, implementação candidata e mudança pronta para operar. O nível de acabamento e de evidência muda entre essas etapas. A velocidade da geração torna essa distinção ainda mais necessária.

3.5. Pensamento sobre o sistema inteiro

O engenheiro excelente acompanha o caminho da necessidade até seu efeito. Se o código fica pronto cedo e aguarda dias por ambiente, integração ou decisão, há um problema de fluxo a resolver.

Essa visão exige conversar com produto, design, segurança, operação e outras equipes. Também exige perceber limitações de capacidade: aumentar trabalho em andamento pode aumentar filas, conflitos e custo de integração. A competência inclui escolher quantas frentes abrir e onde uma intervenção humana realmente destrava o processo.

O framework DevEx propõe observar experiência dos desenvolvedores em conjunto com dados dos sistemas de engenharia. Sua aplicação destaca feedback, carga cognitiva e fluxo. Esses conceitos ajudam a avaliar se agentes estão liberando atenção ou criando uma nova fila de interrupções. F12

3.6. Conhecimento como capacidade compartilhada

Uma decisão que só existe na memória de alguém obriga pessoas e agentes a reencontrá-la. Documentar motivos, restrições e caminhos de investigação aumenta a capacidade de trabalho independente.

O capítulo de compartilhamento de conhecimento de Software Engineering at Google descreve os custos de concentração de expertise e de informação fragmentada, e também a necessidade de manter documentação e formar pessoas. Essa base continua relevante: o conhecimento precisa ser acessível, atualizado e interpretável. F36

Aplicada ao presente, a orientação é concreta: uma descoberta recorrente deve encontrar um lugar estável. O lugar pode ser o código, um teste, uma decisão arquitetural ou um procedimento. O critério é sua utilidade para o próximo trabalho, inclusive quando o autor não estiver disponível.

3.7. Humildade técnica com capacidade de decisão

Trabalhar bem com IA exige admitir lacunas sem terceirizar toda decisão. O engenheiro pode investigar uma tecnologia nova com ajuda do modelo e ainda distinguir o que verificou do que está apenas supondo.

É particularmente valioso conseguir dizer: “isto foi testado nestas condições; esta propriedade vem do contrato da plataforma; este ponto ainda é uma hipótese; esta consequência precisa de decisão do responsável pelo domínio”. Essa precisão permite avançar com menos ambiguidade.

A analogia do manifesto com liderança de uma equipe é útil para delegação e coordenação. Na prática, o engenheiro também precisa projetar memória, acesso, continuidade e limites operacionais: esses elementos dependem do sistema que executa os agentes. Não se pode pressupor que uma intenção comunicada uma vez permaneça disponível em todas as execuções.