Muitas vezes dizemos o código “entender” o AIS, mas eles não entendem realmente seu problema ou sua base de código, no sentido de que os humanos entendem as coisas. Eles estão imitando padrões de texto e código que viram antes, incorporados ao seu modelo ou fornecido por você, com o objetivo de produzir algo que parece certo e é uma resposta plausível. Muitas vezes, é correto, e é por isso que a codificação da vibração (alimentando repetidamente a saída de um immediate de volta à IA sem ler o código que gerou) funciona tão bem, mas não é garantido que esteja correto. E devido às limitações de como os LLMs funcionam e como solicitamos com eles, as soluções raramente explicam a arquitetura geral, a estratégia de longo prazo ou muitas vezes até bons princípios de design de código.
O princípio que achei mais eficaz para gerenciar esses riscos é emprestado de outro domínio inteiramente: Confie, mas verifique. Embora a frase tenha sido usada em tudo, desde relações internacionais até administração de sistemas, ela captura perfeitamente o relacionamento de que precisamos com o código gerado pela IA. Confiamos na IA o suficiente para usar sua saída como ponto de partida, mas verificamos tudo antes de comprometermos.
Confie, mas verifique é a pedra angular de uma abordagem eficaz: confie na IA para um ponto de partida, mas verifique se o design suporta mudanças, testabilidade e clareza. Isso significa aplicar os mesmos padrões críticos de revisão que você usaria para qualquer código: verificando suposições, entender o que o código está realmente fazendo e garantir que ele se encaixe no seu design e padrões.
Verificar o código gerado pela IA significa lê-lo, executá-lo e, às vezes, até depurando-o linha por linha. 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. Essas etapas extras ajudam você a se envolver com o pensamento crítico e impedir que você bloqueie os erros antecipados na base de código, onde eles se tornam difíceis de corrigir.
Verificar também significa tomar medidas específicas para verificar suas suposições e a saída da IA - como Gerando testes de unidade para o códigocomo discutimos anteriormente. A IA pode ser útil, mas não é confiável por padrão. Não conhece o seu problema, seu domínio ou o contexto de sua equipe, a menos que você o faça explícito em seus avisos e revisar a saída cuidadosamente para garantir que você o comuniquei bem e a IA entendeu.
A IA também pode ajudar com essa verificação: 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.
Além de revisar o código diretamente, existem várias técnicas que podem ajudar na verificação. Eles são baseados na ideia de que a IA gera código com base no contexto com o qual está funcionando, mas não pode dizer por que fez escolhas específicas da maneira que um desenvolvedor humano poderia. Quando o código não funciona, geralmente é porque a IA preencheu lacunas com suposições com base em padrões em seus dados de treinamento que na verdade não correspondem ao seu problema actual. As seguintes técnicas foram projetadas para ajudar a superfície as suposições ocultas, destacando as opções para que você possa tomar as decisões sobre seu código em vez de deixá -las para a IA.
- Peça à IA para explicar o código que acabou de gerar. Acompanhe as perguntas sobre por que fez escolhas específicas de design. A explicação não é a mesma que um autor humano que o leva a intenção deles; É a IA que interpreta sua própria saída. Mas essa perspectiva ainda pode ser valiosa, como ter um segundo revisor descrever o que vê no código. Se a IA cometeu um erro, sua explicação provavelmente ecoará esse erro, porque ainda está funcionando no mesmo contexto. Mas essa consistência pode realmente ajudar a superfície as suposições ou mal -entendidos que você pode não pegar apenas lendo o código.
- Tente gerar várias soluções. Pedir à IA que produza duas ou três alternativas a obriga a variar sua abordagem, o que geralmente revela suposições ou compensações diferentes. Uma versão pode ser mais concisa; outro mais idiomático; um terceiro mais explícito. Mesmo que nenhum seja perfeito, colocar as opções lado a lado ajuda a comparar padrões e a decidir o que melhor se encaixa na sua base de código. Comparar as alternativas é uma maneira eficaz de manter seu pensamento crítico envolvido e permanecer no controle da sua base de código.
- Use a IA como seu próprio crítico. Depois que a IA gera código, peça para revisar esse código para problemas ou melhorias. Isso pode ser eficaz porque força a IA a abordar o código como uma nova tarefa; É mais provável que a mudança de contexto de superfície de casos de arestas ou problemas de design que a IA não detectou a primeira vez. Devido a essa mudança, você pode receber um suggestions contraditório ou de maneira que também pode ser útil – revela lugares onde a IA está baseando em padrões conflitantes de seu treinamento (ou, mais precisamente, onde se baseia em padrões contraditórios de seu treinamento). Trate essas críticas como instruções para o seu próprio julgamento, não como correções para se inscrever cegamente. Novamente, esta é uma técnica que ajuda a manter seu pensamento crítico envolvido, destacando os problemas que você poderia pular ao esparecer o código gerado.
Essas etapas de verificação podem parecer que elas diminuem você, mas na verdade são investimentos em velocidade. A captura de um problema de design após cinco minutos de revisão é muito mais rápido do que depurar seis meses depois, quando é tecido em toda a sua base de código. O objetivo é ir além da codificação de vibração simples adicionando pontos de verificação estratégicos, onde você muda do modo de geração para o modo de avaliação.
A capacidade da IA de gerar uma enorme quantidade de código em um tempo muito curto é uma faca de dois gumes. Essa velocidade é sedutora, mas se você não tiver cuidado com isso, pode vibrar o código do seu caminho direto para os antipateriais clássicos (consulte “Veja“Construindo dívida técnica resistente à IA: Quando a velocidade cria dor a longo prazo”). In my very own coding, I’ve seen the AI take clear steps down this path, creating overly structured options that, if I allowed them to go unchecked, would lead on to overly advanced, extremely coupled, and layered designs. I noticed them as a result of I’ve spent many years writing code and dealing on groups, so I acknowledged the patterns early and corrected them—identical to I’ve achieved tons of of instances in code opinions with workforce members. This implies desacelerando o suficiente para pensar em designuma parte crítica da mentalidade de “confiança, mas verificar” que envolve a revisão de mudanças cuidadosamente para evitar a construção de complexidade em camadas que você não pode relaxar mais tarde.
Há também um forte sinal em quão difícil é escrever bons testes de unidade para código gerado pela IA. Se os testes são difíceis para a IA gerar, é um sinal para parar e pensar. A adição de testes de unidade ao seu ciclo de código de vibração cria um ponto de verificação-um motivo para pausar, questionar a saída e voltar para o pensamento crítico. Essa técnica toma empréstimos do desenvolvimento orientado a testes: o uso de testes não apenas para capturar bugs posteriormente, mas para revelar quando um design é muito complexo ou pouco claro.
Quando você pede à IA para ajudar a escrever testes de unidade para o código gerado, primeiro o faça gerar um plano para os testes vai escrever. Observe os sinais de problemas: muito zombar, configuração complexa, muitas dependências – especialmente precisando modificar outras partes do código. Esses são sinais de que o design é muito acoplado ou pouco claro. Quando você vê esses sinais, Pare de codificação da vibração e leia o código. Peça à IA para explicar. Execute -o no depurador. Mantenha -se no modo de pensamento crítico até ficar satisfeito com o design.
Também existem outros sinais claros de que esses riscos estão surgindo, que dizem quando parar de confiar e começar a verificar:
- Loops de rehash: Os desenvolvedores andam de bicicleta por pequenas variações do mesmo immediate de IA sem fazer progresso significativo, porque estão evitando recuar para repensar o problema (consulte “Veja“Compreendendo o loop de rehash: quando a AI fica presa”).
- Código gerado pela IA que quase funciona: O código que parece próximo o suficiente para confiar, mas oculta bugs sutis e difíceis de diagnosticos que aparecem mais tarde na produção ou manutenção.
- Alterações de código que requerem “cirurgia de espingarda”: Pedir à IA que faça uma pequena mudança exige que ela crie edições em cascata em várias partes não relacionadas da base de código – isso indica uma rede crescente e cada vez mais incontrolável de interdependências, o Cirurgia de espingarda cheiro de código.
- Testes de unidade frágeis: Testes excessivamente complexos, fortemente acoplados ou confiam em muita zombaria apenas para obter o código gerado pela IA.
- Debugando a frustração: Pequenas correções que continuam quebrando em outro lugar, revelando falhas de design subjacentes.
- Overconfidence na saída: Pular etapas de revisão e design porque a IA entregou algo que visible finalizado.
Todos esses são sinais para sair do loop codificador de vibração, aplicar pensamento crítico e usar a IA deliberadamente para refatorar seu código para simplificar.