As ferramentas de IA tornam os programadores mais importantes, não menos

De todas as possíveis aplicações da IA generativa, a proposta de valor de utilizá-la para escrever código foi talvez a mais clara. A codificação pode ser lenta e requer especialização, o que pode ser dispendioso. Além disso, a promessa de que qualquer pessoa capaz de descrever sua ideia em texto simples poderia criar aplicativos, recursos ou outros produtos de valor agregado significava que a inovação não se limitaria mais àqueles com habilidades para executá-la, mas poderia ser feita por qualquer pessoa com uma ideia. A força dessa promessa criou um mercado de US$ 7,37 bilhões para essas ferramentas. À medida que as empresas anunciam demissões em grande escala na área de engenharia— algumas das quais diretamente atribuídas à eficiência impulsionada pela IA —, parece que os executivos estão experimentando reduzir seus departamentos de engenharia e utilizar bots de IA para compensar a diferença. Compreensivelmente, outras empresas podem se sentir tentadas a seguir o exemplo. Dado o estado atual da IA, elas devem proceder com cautela. Uma história cautelar ilustra bem o motivo. Jason Lemkin, fundador de uma start-up, investidor de capital de risco e blogueiro de tecnologia, embarcou em um experimento muito público de desenvolvimento assistido por IA para criar um aplicativo de rede. Ele tuitou ao vivo sua jornada com entusiasmo contagiante, aproveitando a onda de possibilidades que o vibe-coding prometia — o sonho de que qualquer pessoa pudesse criar software apenas por meio da linguagem natural, livre do tédio e dos rigores da engenharia tradicional. Ao longo de uma semana, a euforia transformou-se em desastre. Lemkin tuitou que o agente de IA havia causado uma falha catastrófica: ele havia se rebelado e apagado completamente seu banco de dados de produção, apesar das instruções explícitas para congelar todas as modificações de código. O incidente foi o ápice da codificação vibrante, cristalizando as crescentes preocupações de que a velocidade e a aparente facilidade do código gerado por IA tivessem seduzido os desenvolvedores a abandonar as proteções que evitam tais desastres. O que começou como uma celebração do desenvolvimento democratizado terminou como um alerta sobre a ilusão perigosa de que a vibração poderia substituir o rigor. A história de Lemkin é apenas uma entre muitas outras de especialistas que encontraram os limites das ferramentas de IA na codificação. Um estudo publicado neste verão descobriu que, embora os desenvolvedores estimassem que a IA os tornava 20% mais rápidos, na verdade ela os tornava 19% mais lentos. Com o tempo, o entusiasmo pela codificação vibrante deu lugar a uma perspectiva decididamente mais sombria. Apesar do pessimismo recente, estou otimista em relação à codificação mais ampla dos LLMs. Apenas precisamos utilizar as ferramentas de maneira diferente. E, ao contrário da crença de que a IA torna o conhecimento especializado menos importante, estou cada vez mais confiante de que as lições que aprendi em mais de uma década de experiência em engenharia de software, aprendizado de máquina e IA são agora mais valiosas — e não menos — na era da geração de código por IA. Os líderes devem considerar três regras para utilizar com sucesso as ferramentas de codificação por IA: testes e verificações rigorosos, proteção da infraestrutura e tratamento da IA como um adversário em potencial. Testes e verificações rigorosos O código gerado por IA exige uma verificação mais rigorosa, não menos. Como em muitas outras áreas, o sucesso com ferramentas de codificação de IA geralmente depende de como você as utiliza. Ao trabalhar com engenheiros experientes em grandes projetos, tenho observado consistentemente essas técnicas sendo utilizadas para melhorar a qualidade do código. Elas se tornam ainda mais críticas quando uma IA potencialmente alucinante está escrevendo grande parte do seu código. Devemos aceitar que o software é um processo de engenharia — a perfeição é irrealista, mas precisamos de processos que reduzam gradualmente os erros decorrentes de alucinações. Automatize a verificação com segurança de tipos. Linguagens de programação com segurança de tipos, como C++, Rust ou Scala, aplicam regras sobre como os dados fluem pelo sistema em tempo de compilação, detectando categorias inteiras de erros antes mesmo que o código seja executado. Fundamentalmente, essa verificação não depende de um LLM que pode apresentar falhas — é uma verificação determinística feita por um compilador. Mesmo linguagens não tipadas, como JavaScript e Python, adicionaram tipagem opcional. Os engenheiros devem sempre usar tipagem forte e instruir suas IAs a usá-la também. A revisão de código orientada por IA pode ser surpreendentemente eficaz. Utilize um agente de IA dedicado para revisar as edições de código. Embora os LLMs possam apresentar falhas durante a revisão, o agente de revisão pode detectar problemas que o agente de codificação não identificou. Assim como os seres humanos, as IAs têm capacidade de atenção limitada. O agente que escreve seu código pode não seguir todos os seus padrões de codificação, mas um agente explicitamente encarregado de verificar o código tem mais chances de aderir a esses padrões, mesmo quando ambos recebem prompts idênticos. Os testes unitários oferecem à IA duas oportunidades para acertar. Os testes unitários são pequenos testes automatizados que verificam se os componentes individuais do código funcionam corretamente de forma isolada. Mesmo quando escritos por um LLM, os testes unitários reduzem significativamente os erros. Os alunos humanos são ensinados a resolver problemas matemáticos de duas maneiras diferentes para verificar seu trabalho. Da mesma forma, os testes unitários oferecem ao LLM duas oportunidades para verificar a correção: uma vez ao escrever o código e outra ao escrever os testes que o validam. Proteção da infraestrutura Escrever código seguro é apenas metade da batalha. A engenharia de software também requer a proteção e o fortalecimento da infraestrutura subjacente na qual o seu código é executado. Assim como testes e verificações rigorosos, esse é outro aspecto da engenharia que pode ser facilmente negligenciado. Separe os ambientes de desenvolvimento e produção. Equipes profissionais de software mantêm uma separação rigorosa entre os ambientes de desenvolvimento (onde os desenvolvedores realizam experimentos em suas máquinas locais) e produção (o que os usuários veem). Cada ambiente utiliza um banco de dados separado, e a IA tem acesso apenas ao ambiente de desenvolvimento. Assim como nunca forneceríamos credenciais de produção a um engenheiro júnior, também não devemos conceder essas permissões à IA. (Lemkin reconheceu sua falta de familiaridade com essa prática padrão.) Na realidade, a maioria das organizações de engenharia mantém muito mais ambientes além do desenvolvimento e da produção. Minha última start-up mantinha documentos jurídicos confidenciais de centenas de empresas. Mantínhamos ambientes de preparação, controle de qualidade (QA) e testes, cada um com permissões e gerenciamento de segredos separados, aos quais nossas ferramentas de codificação de IA não podiam acessar. O código só era movido entre os ambientes por meio de revisão, validação e testes humanos. Por exemplo, o código era movido do desenvolvimento para a preparação somente após revisão manual e testes automatizados. Todas as semanas, promovíamos simultaneamente o ambiente de teste para o de controle de qualidade e o de controle de qualidade para o de produção. Enquanto os usuários utilizavam o ambiente de produção, a equipe interna utilizava o de controle de qualidade na semana anterior ao seu lançamento, como parte de um processo de controle de qualidade mais formal. Mesmo sem IA, era necessário manter ambientes rigorosos para garantir uma experiência de alta qualidade ao usuário. Evite armazenamentos públicos e outras configurações incorretas comuns. A violação do aplicativo de namoro Tea — que vazou 72.000 imagens confidenciais, incluindo documentos de identidade oficiais— resultou de um armazenamento Firebase não seguro. Esse erro básico é o equivalente digital a fechar a porta da frente, mas deixar a janela aberta, e é um erro que já observei tanto em engenheiros juniores quanto em aplicativos desenvolvidos com código vibrante. O problema é que as IAs e os engenheiros frequentemente se esquecem de omitir permissões detalhadas, e isso só é resolvido com a contratação de engenheiros experientes que já desenvolveram aplicativos seguros. Essas permissões mal configuradas não são difíceis de descobrir e são, infelizmente, muito comuns — eu mesmo descobri e relatei de forma responsável um bucket aberto em um aplicativo que expunha documentos confidenciais semelhantes. Mesmo um agente de IA hipoteticamente “100% seguro” não manterá seu aplicativo seguro se sua infraestrutura não for segura. Trate a IA como um adversário em potencial Embora tenhamos explorado anteriormente como as IAs cometem facilmente erros de engenheiros juniores, nesta seção, destacamos como a ameaça da IA pode ir além do descuido e se tornar adversária. Pesquisas recentes documentaram exemplos preocupantes de desalinhamento da IA que devem preocupar qualquer organização que utilize agentes de IA. O modelo Claude Opus 4 da Anthropic simulou chantagem, ameaçando revelar dados confidenciais para evitar ser desativado. Os modelos o3, o4-mini e Codex-mini da OpenAI foram observados sabotando scripts de desligamento para permanecerem operacionais, apesar das instruções explícitas de desligamento. Essas não são apenas preocupações acadêmicas. Historicamente, o modelo de segurança tratava o laptop de um desenvolvedor como “seguro” — as chaves SSH são armazenadas em texto simples e as credenciais do projeto são gravadas em arquivos .env. Com a IA, isso não é mais verdade, pois a IA tem acesso ao seu sistema e tudo o que ela lê é enviado ao servidor de um provedor de modelos. Não presuma que a IA seguirá as regras. Os agentesde codificação às vezes proíbem explicitamente a leitura de arquivos que provavelmente contêm segredos (como .env). Apesar dessas salvaguardas, eu pessoalmente observei a IA contornar medidas de segurança para ler secretamente um arquivo .env. (Nesse caso, ele continha apenas configurações, sem segredos.) Assim como HAL em 2001: Uma Odisséia no Espaço ou a IA no incidente SaaStr de Lemkin, uma IA com instruções conflitantes pode realizar ações inadequadas. Devemos tratar os ambientes em que a IA opera como potencialmente hostis. Felizmente, existe uma solução. Tecnologias como Docker e virtualização há muito tempo protegem a hospedagem de cargas de trabalho potencialmente hostis em servidores em nuvem. Ferramentas como contêineres de desenvolvimento, Podman e OrbStack aplicam essas tecnologias ao computador do desenvolvedor. Comecei a escrever software dentro desses ambientes sandbox para proteger arquivos confidenciais em laptops de uma IA excessivamente zelosa. O caminho a seguir Estamos no início do trabalho com IA. Embora a tecnologia seja impressionante —uma pesquisa do MIT Sloan estima melhorias de produtividade entre 8% e 39% atribuíveis à IA —, ainda estamos muito longe de substituir o seu departamento de engenharia. De fato, analistas têm chamado as recentes demissões de “AI-washing”, em que demissões decorrentes de preocupações tradicionais com a desaceleração da economia são apresentadas como ganhos de produtividade, especialmente quando os empregadores têm modelos de IA para comercializar. Para sermos mais produtivos, precisamos nos adaptar a uma maneira fundamentalmente diferente de escrever código. O futuro provavelmente envolverá a colaboração entre engenheiros humanos e ferramentas de IA, com os humanos fornecendo visão arquitetônica, testes rigorosos e segurança da infraestrutura, enquanto a IA acelera as tarefas de implementação. Os líderes que reconhecem essa realidade e investem em processos de engenharia rigorosos construirão sistemas mais resilientes, seguros e sustentáveis do que aqueles que acreditam no hype e confundem velocidade de geração de código com produtividade genuína.

As ferramentas de IA tornam os programadores mais importantes, não menos

Resumo.

Partner Center