Programando em Alto Nível

Quando escrevemos uma função em uma linguagem como Python ou Java, já estamos aceitando que outra ferramenta cuide de uma grande parte do trabalho. Não escolhemos cada instrução executada pelo processador. Não decidimos, a cada linha, em qual registrador da CPU o valor será armazenado. Confiamos em linguagens de programação, compiladores, frameworks e sistemas operacionais para transformar o que escrevemos em algo que o computador consiga entender e executar.

Essa distância do hardware costuma parecer perfeitamente normal. Até surgir uma ferramenta que nos permita trabalhar um pouco mais longe dele.

Agora podemos descrever uma tarefa em linguagem natural e pedir a um modelo de IA que produza uma implementação. O pedido pode ser em inglês, português ou outra língua que o modelo compreenda. Para quem passou anos desenvolvendo a habilidade de escrever código, isso pode provocar um incômodo bastante compreensível: O quanto do que eu sei ainda tem valor?

O ponto de partida desta reflexão é o vídeo “A IA vai acabar com a programação?”, de Otavio Lemos. No trecho sobre a história da computação, ele apresenta a programação com IA como mais uma camada de abstração. Essa perspectiva me parece útil para entender tanto a novidade técnica quanto a resistência que ela provoca.

As camadas sobre as quais construímos

Uma abstração permite trabalhar com um problema sem precisar manipular todos os detalhes de sua implementação o tempo inteiro. Podemos organizar algumas dessas camadas assim:

Esse esquema simplifica uma história muito mais ramificada. As camadas coexistem, e ser compilada ou interpretada não determina, por si só, o nível de abstração de uma linguagem. Bibliotecas, frameworks, ferramentas e IDEs também nos permitem delegar decisões que antes precisavam ser tomadas uma a uma.

O efeito prático é familiar: conseguimos dedicar mais atenção ao problema que queremos resolver. Por exemplo, para calcular uma média aritmética, podemos escrever uma expressão com números e variáveis, deixando para o compilador a escolha de instruções assembly e registradores da CPU. Os detalhes de baixo nível continuam existindo, incorporados nas ferramentas e disponíveis quando precisamos investigar o que elas estão fazendo.

Já passamos por isso antes

Essa delegação já encontrou resistência antes. Em um memorando de 1974, Betty Holberton relembrou testes de Fortran realizados em 1957 e relatou que programadores de seu laboratório temiam que aquela nova forma de programar ameaçasse seu sustento. A preocupação com o valor econômico de uma habilidade sempre esteve presente, muito antes dos assistentes de IA.

Também havia boas razões técnicas para desconfiar. John Backus descreveu, em sua história do Fortran, a desconfiança em relação à eficiência dos programas produzidos automaticamente. Parte dela vinha da experiência com tentativas anteriores, que tornaram os programas mais lentos. Fazer um compilador merecer confiança exigiu trabalho de engenharia.

Isso me parece essencial para a discussão atual. É possível reconhecer a resistência à mudança e, ao mesmo tempo, levar a sério as críticas sobre qualidade, controle e confiabilidade. Uma ferramenta nova precisa demonstrar onde funciona bem. Se provar na prática.

Quando uma habilidade vira parte de quem somos

Há ainda uma dificuldade mais pessoal. Uma habilidade muitas vezes é motivo de orgulho, resultado de muita dedicação e estudo, se tornando parte da nossa identidade profissional. Quando uma ferramenta passa a executar aquela tarefa, o abalo pode ir além de aprender uma interface nova. Podemos sentir que algo que custou anos ficou irrelevante de repente.

Algumas tarefas realmente podem perder valor econômico quando ficam mais baratas de executar. Saber fazer algo manualmente deixa de ser um diferencial tão grande quando muitas pessoas conseguem obter um resultado aceitável com ajuda de uma ferramenta. Ainda assim, o valor da experiência depende também da capacidade de perceber quando um resultado é inadequado e o porquê.

A linguagem de programação também deixa perguntas em aberto

No caso dos modelos de IA, essa avaliação merece atenção especial. O próprio Otavio ressalta os limites da analogia com compiladores. Uma linguagem de programação tem regras formais; um pedido em linguagem natural pode deixar decisões importantes em aberto. O modelo também pode produzir implementações diferentes para o mesmo pedido. Ele não oferece o mesmo determinismo na tradução que esperamos de um compilador, que, por sua vez, também não garante que o programa escrito resolva o problema da melhor maneira possível.

Pense neste pedido:

Calcule o total dos pagamentos aprovados.

Uma implementação em Python poderia ser:

total_cents = sum(
    payment["amount_cents"]
    for payment in payments
    if payment["status"] == "approved"
)

O código soma valores inteiros em centavos e filtra um status. Mas o pedido deixou muita coisa sem definição. Todos os pagamentos estão na mesma moeda? A lista já contém apenas o período desejado? Como entram os estornos? Um pagamento aprovado, mas ainda não liquidado, deve fazer parte do total?

Podemos esclarecer essas regras no pedido e pedir testes com exemplos concretos. Também podemos examinar o código, consultar quem conhece o processo e verificar o comportamento do sistema. A experiência aparece na escolha dessas perguntas e na avaliação das respostas. Uma implementação curta pode esconder um problema de negócio difícil.

A experiência ainda tem o seu lugar

Por isso, vejo utilidade em continuar aprendendo o que existe nas camadas de baixo. Entender memória ajuda a investigar consumo excessivo. Entender bancos de dados ajuda a reconhecer uma consulta que vai piorar conforme os dados crescem. Entender concorrência ajuda a perceber uma falha que um teste single-threaded não revelaria. Esse conhecimento pode orientar uma ferramenta mesmo quando ela escreve boa parte do código.

Minha aposta é que vale aprender a trabalhar nesse novo nível e conservar a disposição de descer às camadas mais baixas quando o problema exigir. Quero achar que a minha experiência anterior vai ajudar a definir melhor o que construir, reconhecer limites e verificar resultados. Sem, claro, ter que abrir mão dos ganhos absurdos de produtividade que esse novo nível oferece.

A programação já envolve confiar parte do trabalho a outras ferramentas. Com a IA, estamos renegociando o tamanho dessa parte e os critérios para confiar nela. Levantar da mesa, abrindo mão dos ganhos de produtividade, seria um erro. É nessa negociação que pretendo focar.