O problema da ponte de papéis | smcleod.net

Uma observação sobre correção funcional sem qualidade de domínio.

As ferramentas de IA estão permitindo que as pessoas trabalhem além de suas capacidades existentes para aprender e contribuir em lugares onde de outra forma não o fariam. O risco surge quando se opera fora da área de especialização – quando a capacidade de gerar resultados ultrapassa a capacidade ou o incentivo para avaliar a sua qualidade. A tecnologia torna isso possível, mas se não for controlada, os resultados demonstram por que a especialização no domínio ainda é importante.

A lacuna de experiência#

Sem experiência no domínio para arquitetar, orientar e criticar o trabalho gerado pela IA, surgem dois caminhos:

1. Seguir em frente sem ter consciência da lacuna de qualidade e alinhamento que decorre da falta de experiência no domínio.
2. Desistir, pensar que a IA não é capaz de entregar resultados de qualidade.

Vamos nos concentrar no primeiro caminho – o mais insidioso.

O código é escrito, as interfaces são construídas, os documentos são produzidos e tudo isso olhar correto o suficiente para enviar. O resultado parece competente, por isso avança sem a avaliação crítica que a experiência no domínio proporciona.

Isto é particularmente problemático porque o trabalho muitas vezes é funcionalmente correto. Os testes são aprovados, a IU é renderizada e a API responde. O que está faltando é a mentalidade do domínio – as considerações arquitetônicas, o tratamento de casos extremos, as preocupações de manutenção que surgem da compreensão real do domínio em que você está trabalhando.

É o dilema do ultracrepidariano: a IA fornece a competência para produzir, mas não a experiência para avaliar.

Considere estes cenários:

• Um analista de dados usa IA para enviar uma solicitação pull para bases de código que de outra forma não tocariam – eles estão produzindo código, mas não aplicando princípios de engenharia de software.
• Um desenvolvedor front-end gera código back-end que funciona hoje, mas não possui os padrões que o fazem funcionar de maneira confiável em escala.
• Os designers usam ferramentas como Figma AI ou V0 para gerar código front-end onde a interface parece polida, mas o código abaixo não pode ser mantido ou introduz um acoplamento rígido.
• Os engenheiros elaboram propostas que são lidas de forma coerente, mas carecem do pensamento estratégico e da consciência das partes interessadas que os BAs experientes e os proprietários de produtos trariam.

O trabalho é enviado porque atende superficialmente aos requisitos. Os problemas surgem mais tarde.

Dívida Técnica em Escala#

O custo real não é visível imediatamente. Ele se acumula ao longo do tempo à medida que estes resultados se compõem:

Erosão dos padrões de qualidade: À medida que os resultados gerados pela IA que “parecem bons o suficiente” são enviados com mais frequência, as equipes podem diminuir inconscientemente sua barra de qualidade. A distinção entre correção funcional e qualidade de engenharia é confusa.

Carga de manutenção: Código que funciona, mas não foi construído com uma mentalidade de engenharia, torna-se cada vez mais caro para modificar. Cada mudança requer a compreensão e a solução de padrões que não se alinham com as práticas recomendadas do domínio.

Lacunas de conhecimento: quando as pessoas contribuem com código para sistemas que não são capazes de compreender, a base de código fica fragmentada. Seções diferentes seguem padrões diferentes, tornando mais difícil para a equipe manter um modelo mental coerente.

Revise a fadiga: as equipes de desenvolvimento gastam cada vez mais tempo rejeitando solicitações pull de contribuidores bem-intencionados ou limpando código mesclado que funciona tecnicamente, mas viola princípios fundamentais.

Velocidade falsa: as equipes podem parecer se mover mais rápido porque há mais trabalho sendo enviado, mas o atrito acumulado retarda o desenvolvimento futuro. A dívida técnica cresce mais rápido do que é resolvida.

O padrão é consistente em todos os domínios: correção funcional sem qualidade de domínio. O código é executado, o documento é lido de forma coerente, a interface é renderizada – mas nada disso reflete as práticas e considerações provenientes da experiência real nessa área.

Seguindo em frente#

As ferramentas de IA são excelentes em aceleração, automação e nos ajudam a aprender. A questão não são as ferramentas em si, mas como as aplicamos. Os problemas de engenharia exigem uma mentalidade de engenharia – o pensamento crítico para avaliar resultados, iterar soluções e reconhecer quando o código gerado não possui padrões de arquitetura ou tratamento de erros que forneçam resultados de alta qualidade.

A solução não são regras prescritivas sobre o que você pode ou não fazer com a IA, ou restrições que o prendem às suas capacidades iniciais. Use IA para acelerar seu trabalho e aprender domínios adjacentes, mas aplique o pensamento crítico aos resultados. Quando você estiver trabalhando fora de sua especialidade, faça perguntas. Envolva as pessoas que vivem nesse domínio e aprenda com elas. Recue quando os gerentes esperam que as ferramentas de IA signifiquem que você pode, sozinho, entregar um trabalho que abrange diversas especialidades.

Uma boa engenharia ainda requer bons engenheiros – a IA não muda isso, mas pode criar a ilusão de competência sem substância.

Preenchendo a lacuna#

Se você estiver usando IA para trabalhar em domínios adjacentes, existem etapas práticas para melhorar a qualidade dos artefatos que você produz:

Estenda a capacidade de IA além do conhecimento básico: Use ferramentas do Model Context Protocol (MCP) para conectar IA à documentação, repositórios de código e conhecimento específico do domínio. Em vez de simplesmente confiar nos dados de treinamento internos do modelo, que estarão desatualizados e certamente genéricos.

Restringir e orientar com regras de agente: As regras do agente (na verdade, mais sugestões do que regras) ajudam a reforçar limites, padrões e padrões. Sempre que a IA falha repetidamente em seguir as instruções ou operar fora do escopo pretendido, essa é uma oportunidade para considerar adicionar ou refinar as regras do seu agente.

Documente e faça com que a IA opere a partir de um plano: estabeleça barreiras de qualidade, bons fluxos de trabalho ajudam a manter os agentes concentrados nas tarefas e criam pontos de verificação onde os especialistas do domínio analisam os resultados antes de avançarem.

Reconheça seus limites de avaliação: você provavelmente está fora de sua capacidade de avaliar adequadamente os resultados da IA ​​quando:

• Você está aceitando código porque ele é executado, não porque entende (ou poderia entender) suas implicações arquitetônicas
• Você não consegue articular por que uma abordagem pode ser melhor que outra nesse domínio
• Você não tem certeza de quais casos extremos são importantes ou como devem ser tratados
• Você se pega defendendo os resultados da IA ​​sem ser capaz de explicar as compensações

Se você reconhecer esses padrões, considere envolver um especialista no domínio. Não se trata de controle, mas de aproveitar pessoas com as habilidades, experiência e julgamento certos para ajudar a gerar resultados de alta qualidade.