Como sobreviver à IA com a Cadeia de Integridade de Intenções

Os patches do php2shell (CVE-2026-109618 e CVE-2026-109619) para o PHP em fim de vida (EOL) já estão disponíveis. Como as respostas do atendimento de vendas estão mais demoradas do que o normal devido à alta demanda, a maneira mais rápida de obter os pacotes corrigidos é adquirir o ELS para Runtimes on-line (abre em uma nova aba). Leia as perguntas frequentes sobre os patches

Vá direto para um resumo gerado por IA desta postagem do blog

  • Resuma esta postagem com o Perplexity
  • Resuma esta postagem com o Gemini

A ideia de que todos serão demitidos em breve por causa da IA pode parecer uma piada para alguns, mas é uma realidade inquietante com a qual muitos desenvolvedores estão lutando. À medida que avançamos em direção ao futuro, a IA não está mais apenas escrevendo código; ela está substituindo os programadores.

Satya Nadella, da Microsoft, afirmou recentemente que quase 30% do código da Microsoft é agora escrito por ferramentas de IA, como o Copilot. Poucos dias após a divulgação dessa estatística, veio o golpe duro: a Microsoft demitiu 2.000 funcionários. Será que isso é uma coincidência, ou existe uma relação entre os 30% do código gerado por IA e as demissões dos funcionários?

Essas coincidências não se limitam apenas à Microsoft. Um fenômeno semelhante pode ser observado na CloudStrike, na IBM e em outras empresas. Até mesmo a Goldman Sachs prevê que até 300 milhões de empregos serão substituídos pela IA em um setor que, há alguns anos, enfrentava um déficit de quase dois milhões de engenheiros.

Esta não é a primeira vez que o mundo da tecnologia entra em pânico com a possibilidade de extinção de empregos. 

Seja em relação aos bytecodes do Java ou à migração para a nuvem, os desenvolvedores sempre enfrentaram ceticismo, medo e resistência quando surgem novas tecnologias. Mas, desta vez, é diferente. Por quê?

Porque, desta vez, estamos lidando com ferramentas que não se limitam a automatizar — elas geram resultados imprevisíveis. Essas ferramentas são imprevisíveis. Podem ser rápidas, mas não são confiáveis. Apesar disso, estão sendo utilizadas para gerar código de nível de produção. 

Neste artigo, exploramos essa tensão e analisamos por que algo chamado “Cadeia de Integridade da Intenção” pode ser nossa melhor opção para sobreviver à IA sem perder o controle. Vamos começar! 

Pânico e progresso – O ciclo continua

 

O pânico em torno da IA no desenvolvimento de software pode parecer algo novo, mas não é. Na verdade, a cada abstração na área de tecnologia — seja o Java, o uso de ferramentas SaaS ou a migração para a nuvem —, as dúvidas sempre surgem.

Houve um tempo em que os engenheiros questionavam o bytecode do Java, perguntando se ele era confiável. Havia quem considerasse a computação em nuvem arriscada demais para dados confidenciais. A resistência sempre existiu, mas — apesar disso — cada mudança que se impôs até agora ajudou os desenvolvedores a criar soluções melhores do que antes. 

Com o passar do tempo, as abstrações se tornaram a espinha dorsal da escalabilidade, levando ao desenvolvimento de sistemas mais rápidos, mais complexos e mais resilientes. Mas o que diferencia o momento atual é a natureza da IA. As abstrações tradicionais visavam principalmente simplificar as complexidades, mantendo um comportamento consistente e repetível. No entanto, avanços como os grandes modelos de linguagem (LLMs) abrem espaço para a aleatoriedade. 

Os LLMs são projetados para funcionar com base em probabilidades, o que significa que os resultados desses modelos podem variar mesmo quando alimentados com entradas idênticas. Essa imprevisibilidade representa uma ruptura em relação às abstrações do passado.

Embora as ferramentas do passado realmente causassem medo e resistência, elas vinham acompanhadas de uma estrutura que podia ser definida. Com os LLMs, os desenvolvedores agora trabalham com sistemas que se comportam de maneira diferente a cada vez, o que significa que precisam enfrentar novos desafios relacionados à precisão e à confiabilidade do software gerado por esses modelos. 

Os LLMs são apenas um macaco com uma GPU?

 

Apesar de sua popularidade, os LLMs continuam sendo pouco confiáveis no que diz respeito ao desenvolvimento de software. Suas capacidades de geração de código parecem mais tentativas e erros do que o trabalho de um engenheiro.

Em vez de uma ferramenta precisa e inteligente, você pode pensar em um LLM como um macaco com uma GPU que fica tentando coisas até que elas deem certo.

Como essa realidade se reflete no desenvolvimento na prática? Há inúmeros exemplos desses modelos simplesmente inventando funções, criando nomes de pacotes e até mesmo produzindo lógicas perigosamente falhas. 

Por exemplo, os LLMs já fizeram referência a bibliotecas do npm que não existem, e agentes mal-intencionados utilizaram esses nomes inventados para registrar pacotes, introduzindo um novo vetor de ataques à cadeia de suprimentos.

Muitos podem considerar esse risco algo que existe apenas na teoria, mas não é esse o caso. Estudos que comparam os resultados de qualidade de código obtidos com ferramentas líderes, como o GitHub Copilot, o Amazon CodeWhisperer e o ChatGPT geram código correto em apenas 31% a 65% das vezes, o que significa que o código apresenta falhas em quase metade das vezes. 

O pior de tudo é que 40% do código de IA estava vulnerável, pois continha falhas exploráveis e não seguia práticas básicas de segurança.

Olhando para isso agora, fica claro que a questão não se resume apenas a imprecisões. Ela também envolve uma confiança mal depositada. Essas ferramentas apresentam seus códigos com alto grau de certeza, mesmo nos casos em que os resultados estão errados.

Já houve casos em que desenvolvedores pediram à IA para otimizar seu código em termos de velocidade. O resultado? O modelo remove verificações de validação ou interrompe totalmente a cobertura de testes em prol do desempenho.

Diante disso, podemos afirmar que os LLMs não substituem os seres humanos, pelo menos por enquanto. São ferramentas que, no entanto, podem ampliar as intenções e as capacidades de quem as utiliza. Dito isso, esses modelos carecem de uma compreensão sólida dos sistemas e do contexto; não se pode confiar neles cegamente, e o julgamento humano é hoje mais crucial do que nunca.  

A Cadeia de Integridade da Intenção 

 

Considerando tudo o que abordamos até agora, fica claro que confiar em código gerado por IA acarreta uma série de riscos em constante evolução. A Cadeia de Integridade de Intenção é uma estrutura projetada para garantir que tais riscos não prevaleçam e que a ideia original do desenvolvedor seja transformada em um software funcional e confiável. 

O conceito fundamental dessa estrutura é que algo se perde entre a ideia do desenvolvedor e o resultado final, e é isso que se chama de “lacuna de tradução”. Essas lacunas existem entre um prompt e o resultado final produzido por um modelo LLM. Isso ocorre porque o comportamento do modelo é imprevisível e baseado na improvisação, o que significa que não há garantia de que o resultado final reflita o que foi inserido. 

A Cadeia de Integridade de Intenção pode ajudar a resolver essa questão por meio de um processo em várias etapas, centrado em quatro artefatos:  

  • Prompt – Redigido por pessoas, representa a intenção original ou a funcionalidade desejada.
  • Especificação – Uma versão estruturada e padronizada da solicitação, ainda em linguagem natural, mas formatada para maior clareza e consistência.
  • Teste – Gerados automaticamente a partir da especificação; esses testes definem como deve ser o comportamento correto.
  • Código – Gerado pelo LLM, com o objetivo de passar nos testes baseados nas especificações. 

Antes de prosseguirmos com isso, é essencial saber que cada artefato funciona como um elo da cadeia, mas não pode ser aceito cegamente.

Embora o prompt não precise de validação, já que se trata apenas de um ponto de partida, a especificação deve ser revisada por pessoas para garantir que ela reflita a intenção do prompt. Da mesma forma, o teste deve ser fixado e verificável, e o código gerado pelo LLM só deve ser validado se for aprovado no teste fixado.

Essa estrutura basicamente introduz pontos de verificação em cada etapa, o que pode ajudar a reduzir o risco de falhas de segurança e recursos irrelevantes, garantindo que o resultado esteja alinhado com a intenção humana. 

Confiar, Verificar, Solicitar

 

O código gerado por IA está se tornando cada vez mais comum. Diante disso, estabelecer medidas de segurança não é apenas uma questão de seguir boas práticas; é uma questão de sobrevivência.

Sem restrições claramente definidas, como especificações e testes, os LLMs podem gerar software inseguro ou totalmente defeituoso. Além disso, técnicas como o Desenvolvimento Orientado a Testes (TDD) e o Desenvolvimento Orientado a Comportamento (BDD) oferecem uma estrutura desde o início, mas têm enfrentado dificuldades para serem adotadas, pois os desenvolvedores tendem a dar mais prioridade à escrita de código do que à criação de testes.

Com o desenvolvimento e a IA deixando de ser apenas uma tendência, a habilidade mais importante que os desenvolvedores podem adquirir é a articulação de intenções. 

Isso significa que os desenvolvedores agora precisam se tornar engenheiros de prompts, capazes de expressar requisitos de maneira precisa, elaborar especificações que possam ser testadas e verificar se há falhas nos resultados gerados pelos LLMs. Diante disso, a liderança técnica hoje em dia tem se tornado mais uma questão de ter a capacidade de orientar um modelo por meio de prompts estruturados e da validação de restrições. 

Um entendimento comum e um conjunto de habilidades preparadas para o futuro 

 

O uso de especificações estruturadas, como o Gherkin, pode ajudar a reduzir mal-entendidos entre pessoas e máquinas. Embora essas especificações não sejam código, elas são formais o suficiente para serem compreendidas tanto por pessoas quanto por máquinas.

Embora trabalhar com especificações para testar e, em seguida, programar possa ajudar a limitar os erros de IA no resultado final, para conseguir fazer isso, os desenvolvedores precisam mudar sua mentalidade.

Eles precisam parar de ver os LLMs como especialistas e passá-los a considerar como uma ferramenta projetada para ampliar a intenção. No entanto, se a intenção inicial for ruim, o resultado do código também será ruim.

Com isso em mente, três habilidades essenciais nas quais os desenvolvedores devem se concentrar para aprimorar seu desempenho e se preparar para o futuro incluem escrever prompts melhores, validar resultados e elaborar especificações claras. Aqueles que desenvolverem essas três habilidades essenciais poderão ter mais chances de serem eficazes em suas carreiras. Aqueles que não o fizerem podem acabar sendo substituídos pela IA. 

Considerações finais

 

A IA mudou e continua mudando o desenvolvimento de software de uma forma que nunca vimos antes. Embora seja capaz de programar de maneira mais rápida e eficiente, seu resultado nem sempre é o esperado ou pode conter falhas lógicas, vulnerabilidades exploráveis, políticas de segurança mal configuradas e muito mais.

Os desenvolvedores, no entanto, podem usar a Cadeia de Integridade de Intenção para manter o controle e garantir que o código de IA seja gerado conforme pretendido, alinhando a intenção humana com a saída da máquina por meio de estrutura e validação.

 

Resumo
Como sobreviver à IA com a Cadeia de Integridade de Intenções
Nome do artigo
Como sobreviver à IA com a Cadeia de Integridade de Intenções
Descrição
Quer saber para onde o desenvolvimento de software está indo agora que a IA está ganhando espaço? Descubra o que os desenvolvedores devem fazer para sobreviver a essa onda!
Autor
Nome da editora
TuxCare
Logotipo da editora

Junte-se a mais de 4.500 profissionais de Linux e código aberto!

2 vezes por mês. Sem spam.

Índice
Obtenha as respostas sobre segurança de código aberto de que você precisa

Junte-se a mais de 4.500 profissionais de Linux e código aberto!

2 vezes por mês. Sem spam.