Qualquer pessoa que tenha usado a IA para gerar código viu cometer erros. Mas o verdadeiro perigo não é a resposta errada ocasional; Está no que acontece quando esses erros se acumulam em uma base de código. Questões que parecem pequenas a princípio podem se compor rapidamente, dificultando o código de entender, manter e evoluir. Para realmente ver esse perigo, você deve ver como a IA é usada na prática – que para muitos desenvolvedores começa com a codificação da vibração.
Codificação da vibração é uma abordagem exploratória e rápida para o desenvolvimento de software program, onde os desenvolvedores solicitam rapidamente, obtêm código e iteram. Quando o código parece próximo, mas não certo, o desenvolvedor descreve o que está errado e permite que a IA tente novamente. Quando não compilar ou os testes falham, eles copiam as mensagens de erro de volta para a IA. O ciclo continua – promovido, execução, erro, pasta, solicita novamente – geralmente sem ler ou entender o código gerado. Parece produtivo porque você está fazendo um progresso visível: os erros desaparecem, os testes começam a passar, os recursos parecem funcionar. Você está tratando a IA como um parceiro de codificação que lida com os detalhes da implementação enquanto dirige em um nível alto.
Os desenvolvedores usam a codificação da vibração para explorar e refinar idéias e podem gerar grandes quantidades de código rapidamente. Muitas vezes, é o primeiro passo pure para a maioria dos desenvolvedores que usam ferramentas de IA, porque parece tão intuitivo e produtivo. A vibração de codificação descarrega os detalhes da IA, tornando a exploração e a ideação rápida e eficaz – e é exatamente por isso que é tão widespread.
A IA gera muito código e não é prático revisar todas as linhas toda vez que se regenera. Tentando ler tudo isso pode levar a Sobrecarga cognitiva– Exaustão psychological de percorrer muito código – e torna mais difícil jogar o código que não está funcionando apenas porque você já investiu tempo na leitura.
A codificação da vibração é uma maneira regular e útil de explorar com a IA, mas por si só apresenta um risco significativo. Os modelos usados pelo LLMS podem alucinar e produzir respostas inventadas-por exemplo, gerar código que chama APIs ou métodos que nem existem. Prevendo que esses erros gerados pela IA comprometam sua base de código inicia com a compreensão dos recursos e as limitações dessas ferramentas e adotando uma abordagem ao desenvolvimento assistido pela IA que leva em consideração essas limitações.
Aqui está um exemplo simples de como esses problemas se compostos. Quando peço à IA que gere uma classe que lida com a interação do usuário, ela geralmente cria métodos que leem e escrevem diretamente para o console. Quando o peço para tornar o código mais testável, se eu não solicitar muito especificamente uma correção simples, como ter métodos, assumir a entrada como parâmetros e retornar a saída como valores, a IA frequentemente sugere envolver todo o mecanismo de E/S em uma camada de abstração. Agora eu tenho uma interface, uma implementação, objetos simulados para teste e injeção de dependência por toda parte. O que começou como uma classe direta se tornou uma estrutura em miniatura. A IA não está errada, exatamente – a abordagem de abstração é um padrão válido -, mas é exagerado para o problema em questão. Cada iteração acrescenta mais complexidade e, se você não estiver prestando atenção, acabará com camadas e camadas de código desnecessário. Este é um bom exemplo de como a codificação da vibração pode balançar na complexidade desnecessária se você não parar para verificar o que está acontecendo.
Os desenvolvedores iniciantes enfrentam um novo tipo de desafio de dívida técnica com a IA
Três meses depois de escrever sua primeira linha de código, um usuário do Reddit passando por SpacetimeMeRcerer postou uma atualização frustrada: seu projeto assistido por IA chegou ao ponto em que fazer qualquer alteração significava editar dezenas de arquivos. O design havia endurecido em torno de erros iniciais, e todas as mudanças trouxeram uma onda de depuração. Eles atingiram a parede conhecida no design de software program como “cirurgia de espingarda”, onde uma única mudança ondula por tanto código que é arriscado e lento para trabalhar – um sinal clássico de dívida técnicao custo oculto dos atalhos iniciais que tornam as mudanças futuras mais difíceis e mais caras.
AI não causou o problema diretamente; O código funcionou (até que não funcionou). Mas a velocidade do desenvolvimento assistido pela AA permite que esse novo desenvolvedor pule o design que impede que esses padrões se formem. O mesmo acontece com os desenvolvedores experientes quando os prazos impulsionam a entrega sobre a manutenção. A diferença é que um desenvolvedor experiente geralmente sabe que está assumindo dívidas. Eles podem identificar antipateriais mais cedo porque os viram repetidamente e tomar medidas para “pagar” a dívida antes que fique muito mais caro para consertar. Alguém novo na codificação pode nem perceber que está acontecendo até que seja tarde demais – e ainda não construíram as ferramentas ou hábitos para evitá -lo.
Parte da razão pela qual os novos desenvolvedores são especialmente vulneráveis a esse problema, remontam ao Paradoxo de atalho cognitivo.1 Sem a experiência prática de depuração prática, refatoração e trabalho de requisitos ambíguos, eles não têm os instintos construídos através da experiência para identificar problemas estruturais no código gerado pela IA. A IA pode entregar a eles uma solução limpa e funcional. Mas se eles não conseguem ver as falhas de design escondidas dentro dela, essas falhas crescem desmarcadas até que elas sejam trancadas no projeto, incorporadas às fundações do código, portanto, alterá -las exige um trabalho extenso e frustrante.
Os sinais da dívida técnica acelerada da AI-I-I-I-A-I-ALENTE aparecem rapidamente: código altamente acoplado, onde os módulos dependem dos detalhes internos um do outro; “Objetos de Deus” com muitas responsabilidades; soluções excessivamente estruturadas, onde um problema simples é enterrado em camadas extras. Esses são os mesmos problemas que normalmente refletem a dívida técnica no código construído pelo ser humano; A razão pela qual eles emergem tão rapidamente no código gerado pela IA é porque ele pode ser gerado muito mais rapidamente e sem a supervisão ou decisões intencionais de design ou arquitetura. A IA pode gerar esses padrões de forma convincente, fazendo -os parecer deliberados mesmo quando emergiram por acidente. Como a saída compila, passa testes e funciona conforme o esperado, é fácil de aceitar como “feito” sem pensar em como ele se sustentará quando os requisitos mudarem.
Ao adicionar ou atualizar um teste de unidade, parece irracionalmente difícil, esse é geralmente o primeiro sinal de que o design é muito rígido. O teste está dizendo algo sobre a estrutura – talvez o código esteja muito entrelaçado, talvez os limites não sejam claros. Esse loop de suggestions funciona se o código foi gerado por IA ou manuscrito, mas com a IA o atrito geralmente aparece mais tarde, depois que o código já foi mesclado.
É aí que entra o hábito de “confiança, mas verifique”. Confie na IA para fornecer um ponto de partida, mas verifique se o design suporta mudanças, testabilidades e clareza. Pergunte a si mesmo se o código ainda fará sentido para você – ou qualquer outra pessoa – a partir de agora. Na prática, isso pode significar revisões rápidas de design, mesmo para código gerado pela IA, refatorar quando o acoplamento ou a duplicação começa a entrar e a fazer um passe deliberado na nomeação, para que variáveis e funções lidassem claramente. Estes não são toques opcionais; Eles são o que impedem que uma base de código bloqueie suas piores decisões iniciais.
A IA também pode ajudar com isso: pode sugerir refatorings, apontar a lógica duplicada ou ajudar a extrair código confuso para abstrações mais limpas. Mas cabe a você direcioná -lo para fazer essas mudanças, o que significa que você precisa identificá -las primeiro – o que é muito mais fácil para desenvolvedores experientes que viram esses problemas ao longo de muitos projetos.
Deixado para seus padrões, o desenvolvimento assistido pela AA é tendencioso para adicionar novo código, não revisitando decisões antigas. A disciplina para evitar a dívida técnica vem de verificações de projeto de construção no seu fluxo de trabalho, para que a velocidade da IA funcione a serviço de manutenção em vez de contra.
Nota de rodapé
- Discutirei isso com mais detalhes em um próximo artigo de radar em 8 de outubro.