Lembra desse comentário do Quora (que também virou meme)?

(Fonte: Quora)

Na era Stack Overflow do modelo de linguagem pré-grande (LLM), o desafio era discernir qual trechos de código para adotar e adaptar de forma eficaz. Agora, embora a geração de código tenha se tornado trivialmente fácil, o desafio mais profundo reside na identificação e integração confiável de código de nível empresarial de alta qualidade em ambientes de produção.

Este artigo examinará as armadilhas e limitações práticas observadas quando os engenheiros usam agentes de codificação modernos para trabalhos empresariais reais, abordando as questões mais complexas relacionadas à integração, escalabilidade, acessibilidade, práticas de segurança em evolução, privacidade de dados e capacidade de manutenção em ambientes operacionais ao vivo. Esperamos equilibrar o entusiasmo e fornecer uma visão mais fundamentada tecnicamente das capacidades dos agentes de codificação de IA.

Compreensão limitada do domínio e limites de serviço

Os agentes de IA enfrentam dificuldades significativas para projetar sistemas escaláveis ​​devido à enorme explosão de opções e à falta crítica de contexto específico da empresa. Para descrever o problema em termos gerais, as bases de código e monorepos de grandes empresas são muitas vezes vastas demais para que os agentes possam aprender diretamente, e o conhecimento crucial pode ser frequentemente fragmentado em documentação interna e experiência individual.

Mais especificamente, muitos agentes de codificação populares encontram limites de serviço que prejudicam a sua eficácia em ambientes de grande escala. Os recursos de indexação podem falhar ou diminuir a qualidade em repositórios que excedam 2.500 arquivos ou devido a restrições de memória. Além disso, arquivos maiores que 500 KB são frequentemente excluídos da indexação/pesquisa, o que afeta produtos estabelecidos com arquivos de código maiores e com décadas de existência (embora projetos mais recentes possam enfrentar isso com menos frequência).

Para tarefas complexas que envolvem contextos de arquivos extensos ou refatoração, espera-se que os desenvolvedores forneçam os arquivos relevantes e, ao mesmo tempo, definam explicitamente o procedimento de refatoração e as sequências de construção/comando circundantes para validar a implementação sem introduzir regressões de recursos.

Falta de contexto e uso de hardware

Os agentes de IA demonstraram uma falta crítica de conhecimento em relação às instalações do sistema operacional, da linha de comando e do ambiente (conda/venv). Esta deficiência pode levar a experiências frustrantes, como a tentativa do agente de executar comandos Linux no PowerShell, o que pode resultar consistentemente em erros de “comando não reconhecido”. Além disso, os agentes frequentemente exibem uma “tolerância de espera” inconsistente na leitura das saídas dos comandos, declarando prematuramente uma incapacidade de ler os resultados (e avançando para tentar novamente/pular) antes mesmo de um comando ser concluído, especialmente em máquinas mais lentas.

Isto não é apenas sobre criticar características; antes, o diabo está nesses detalhes práticos. Estas lacunas de experiência manifestam-se como verdadeiros pontos de atrito e necessitam de vigilância humana constante para monitorizar a atividade do agente em tempo real. Caso contrário, o agente pode ignorar as informações iniciais da chamada da ferramenta e parar prematuramente ou prosseguir com uma solução incompleta que exige desfazer algumas/todas as alterações, reativar prompts e desperdiçar tokens. Não é garantido enviar um prompt na sexta-feira à noite e esperar que as atualizações do código sejam feitas na verificação na segunda-feira de manhã.

Alucinações acabaram repetido ações

Trabalhar com agentes de codificação de IA geralmente apresenta um desafio de longa data de alucinações ou informações incorretas ou incompletas (como pequenos trechos de código) dentro de um conjunto maior de alterações que devem ser corrigidas por um desenvolvedor com esforço trivial a baixo. No entanto, o que se torna particularmente problemático é quando o comportamento incorreto é repetido dentro de um único thread, forçando os usuários a iniciar um novo thread e fornecer novamente todo o contexto ou intervir manualmente para “desbloquear” o agente.

Por exemplo, durante uma configuração de código de função Python, um agente encarregado de implementar alterações complexas de preparação para produção encontrou um arquivo (Veja abaixo) contendo caracteres especiais (parênteses, ponto final, asterisco). Esses caracteres são muito comuns na ciência da computação para denotar versões de software.

(Imagem criada manualmente com código padrão. Fonte: Microsoft Aprenda e Editando o arquivo host do aplicativo (host.json) no Portal do Azure)

O agente sinalizou incorretamente isso como um valor inseguro ou prejudicial, interrompendo todo o processo de geração. Essa identificação incorreta de um ataque adversário ocorreu de 4 a 5 vezes, apesar de vários avisos na tentativa de reiniciar ou continuar a modificação. Este formato de versão é, na verdade, padrão, presente em um modelo de código de gatilho HTTP Python. A única solução alternativa bem-sucedida envolveu instruir o agente a não leia o arquivo e, em vez disso, solicite que ele simplesmente forneça a configuração desejada e garanta que o desenvolvedor o adicionará manualmente a esse arquivo, confirme e peça para continuar com as alterações restantes no código.

A incapacidade de sair de um loop de saída de agente repetidamente defeituoso dentro do mesmo thread destaca uma limitação prática que desperdiça significativamente o tempo de desenvolvimento. Em essência, os desenvolvedores tendem a gastar tempo depurando/refinando o código gerado pela IA, em vez de trechos de código Stack Overflow ou seus próprios.

Falta de práticas de codificação de nível empresarial

Melhores práticas de segurança: Os agentes de codificação geralmente adotam métodos de autenticação menos seguros, como autenticação baseada em chave (segredos do cliente), em vez de soluções modernas baseadas em identidade (como Entra ID ou credenciais federadas). Esta supervisão pode introduzir vulnerabilidades significativas e aumentar a sobrecarga de manutenção, uma vez que a gestão e a rotação de chaves são tarefas complexas e cada vez mais restritas em ambientes empresariais.

SDKs desatualizados e reinventando a roda: Os agentes podem não aproveitar consistentemente os métodos mais recentes do SDK, gerando implementações mais detalhadas e mais difíceis de manter. Aproveitando o exemplo do Azure Function, os agentes geraram código usando o SDK v1 pré-existente para operações de leitura/gravação, em vez do código SDK v2, muito mais limpo e de fácil manutenção. Os desenvolvedores devem pesquisar as práticas recomendadas mais recentes on-line para ter um mapa mental de dependências e implementação esperada que garanta a manutenção a longo prazo e reduza os esforços futuros de migração tecnológica.

Reconhecimento de intenção limitado e código repetitivo: Mesmo para tarefas modulares de escopo menor (que normalmente são incentivadas para minimizar alucinações ou tempo de inatividade de depuração), como estender uma definição de função existente, os agentes podem seguir as instruções literalmente e produzir lógica que acaba sendo quase repetitiva, sem antecipar o que está por vir ou desarticulado necessidades do desenvolvedor. Ou seja, nessas tarefas modulares, o agente pode não identificar e refatorar automaticamente lógica semelhante em funções compartilhadas ou melhorar as definições de classe, levando a uma dívida tecnológica e a bases de código mais difíceis de gerenciar, especialmente com codificação de vibração ou desenvolvedores preguiçosos.

Simplificando, aqueles rolos virais do YouTube que mostram o desenvolvimento rápido de aplicativos de zero a um a partir de um prompt de uma única frase simplesmente não conseguem capturar os desafios diferenciados do software de nível de produção, onde segurança, escalabilidade, capacidade de manutenção e arquiteturas de design resistentes ao futuro são fundamentais.

Alinhamento de viés de confirmação

O viés de confirmação é uma preocupação significativa, pois os LLMs frequentemente afirmam as premissas do usuário, mesmo quando o usuário expressa dúvidas e pede ao agente para refinar seu entendimento ou sugerir ideias alternativas. Essa tendência, em que os modelos se alinham com o que eles percebem que o usuário deseja ouvir, leva à redução da qualidade geral da saída, especialmente para tarefas mais objetivas/técnicas, como codificação.

Há ampla literatura para sugerir que se um modelo começa emitindo uma afirmação como “Você está absolutamente certo!”, o restante dos tokens de saída tendem a justificar essa afirmação.

Necessidade constante de babá

Apesar do fascínio da codificação autónoma, a realidade dos agentes de IA no desenvolvimento empresarial exige frequentemente vigilância humana constante. Instâncias como um agente tentando executar comandos do Linux no PowerShell, sinalizadores de segurança falsos positivos ou introdução de imprecisões devido a motivos específicos do domínio destacam lacunas críticas; os desenvolvedores simplesmente não podem se afastar. Em vez disso, eles devem monitorar constantemente o processo de raciocínio e compreender as adições de código de vários arquivos para evitar perda de tempo com respostas abaixo da média.

A pior experiência possível com agentes é um desenvolvedor aceitar atualizações de código de vários arquivos repletos de bugs e, em seguida, evaporar o tempo na depuração devido à aparência ‘bonita’ do código. Isto pode até dar origem ao falácia do custo irrecuperável de esperar que o código funcione após apenas algumas correções, especialmente quando as atualizações ocorrem em vários arquivos em uma base de código complexa/desconhecida, com conexões a vários serviços independentes.

É o mesmo que colaborar com um prodígio de 10 anos que memorizou amplo conhecimento e até aborda todas as intenções do usuário, mas prioriza exibir esse conhecimento em vez de resolver o problema real e não tem a visão necessária para o sucesso em casos de uso do mundo real.

Esse "babá" Essa exigência, juntamente com a recorrência frustrante de alucinações, significa que o tempo gasto na depuração de código gerado por IA pode eclipsar a economia de tempo prevista com o uso do agente. Escusado será dizer que os desenvolvedores em grandes empresas precisam ser muito intencionais e estratégicos ao navegar pelas ferramentas e casos de uso modernos.

Conclusão

Não há dúvida de que os agentes de codificação de IA têm sido revolucionários, acelerando a prototipagem, automatizando a codificação padronizada e transformando a forma como os desenvolvedores constroem. O verdadeiro desafio agora não é gerar código, é saber o que enviar, como protegê-lo e onde escalá-lo. Equipes inteligentes estão aprendendo a filtrar o hype, usar agentes estrategicamente e redobrar o julgamento da engenharia.

Como CEO do GitHub Thomas Dohmke observou recentemente: Os desenvolvedores mais avançados “passaram da escrita do código para a arquitetura e verificação do trabalho de implementação realizado pelos agentes de IA”. Na era da agência, o sucesso não pertence àqueles que conseguem gerar códigos, mas àqueles que conseguem projetar sistemas duradouros.

Rahul Raja é engenheiro de software da equipe do LinkedIn.

Advitya Gemawat é engenheira de aprendizado de máquina (ML) na Microsoft.

Nota do editor: As opiniões expressas neste artigo são opiniões pessoais dos autores e não refletem as opiniões de seus empregadores.

Fonte ==> Cyberseo