Linguagem de programação é uma forma de pensar
Desafio você a fazer um cálculo mental simples de soma ou subtração. Primeiro uma pergunta fácil 1 + 3, você provavelmente não pensou muito para responder, no entanto agora tente 49 + 27 ou 43 - 26, já muda o nível de pensamento.
Você pode contar nos dedos ou tentar calcular por partes, mas na medida que os números vão crescendo ou a operação muda, a dificuldade aumenta.
Existem alguns métodos, mas o mais fácil, rápido e menos custoso costuma ser rabiscar e desenhar os números. Se você tentar simular o papel na cabeça, visualizando o processo, isso fica difícil rapidamente. Mesmo sendo um cálculo simples, a imagem mental se perde.
E quanto maiores os números, maior a dificuldade. Uma das grandes evoluções da humanidade foi criar formas de representar o cálculo e tirar parte do esforço da mente.

Às vezes, a melhor forma de pensar algo é misturando vários métodos de pensamento (desenho, números, textos, rabiscos ). Um desenho pode significar coisas diferentes dependendo de quem vê, da mesma forma de um pensamento ou ideia.
Geralmente só conseguimos entender algo quando já passamos por aquilo, temos vivência ou referência. Mesmo tendo todos os pontos, isso não garante compreensão, porque nem tudo segue uma lógica direta. Parte é contexto, parte é interpretação, e parte pode ser até emocional ou irracional.
Na imagem a baixo, você pode dizer que é um chapéu, outra pessoa pode dizer que é uma cobra engolindo um elefante.
Cada problema pode ser visto de várias formas e resolvido de várias maneiras. Porém, alguns métodos são extremamente ineficientes dependendo do tipo de problema.
No vídeo O FIM DA PROGRAMAÇÃO ANTIGA! 💀, tem um ponto interessante no vídeo sobre um teste, onde o mesmo prompt é feito em duas linguagens diferente, e teve um resultado interessante: uma forma e formato diferente de pensar gerou resultado diferente. Uma linguagem custou muito menos que a outra, com menos código, token e tempo de resposta.
O teste feito foi bem simples, daria para fazer testes melhores com todas linguagens, gerando 50x os mesmos prompts para ver se os resultados seriam muito diferente nas 50x. Porem acredito que ninguém ainda fez algo assim, mas esse simples teste feito, podemos perceber que a forma de pensar faz diferença para as LLM.
As linguagens de programação, não são apenas ferramentas, são uma forma de pensar e estruturar problemas. Somar 1 + 1, mentalmente é fácil, porem não escala bem para operações como 259 × 7. O modo de pensar precisa mudar conforme a complexidade aumenta.
Tenho visto muitos relatos de desenvolvedores dizendo que já não sentem mais que estão programando. Em parte isso faz sentido, porque programar é uma forma de pensamento: você lê o código, interpreta, ajusta e evolui conforme sua forma de pensar muda. Escrever código é uma forma de estruturar o pensamento. Cada programador pensa de uma forma diferente e representa isso de maneira diferente. Bons códigos, em geral, são reflexos de formas mais eficientes de pensar e resolver problemas.
Algumas linguagens, frameworks e bibliotecas tentam ser mais opinativas, limitando sua forma de pensar e padronizando pensamentos. Dependendo do projeto, faz sentido para um time usar algo assim. Pois ela resolve problemas de arquiteturas, padronização de código , bibliotecas... Um time grande precisa ter padrões para qualquer pessoa pegar o código e entender o pensamento com facilidade.
Fábio Akita, em um post, comenta que o VS Code virou o novo cartão perfurado:
https://akitaonrails.com/2026/04/11/vs-code-e-o-novo-cartao-perfurado/
Ele argumenta que a programação está passando por uma transição.
Teve uma época em que programar significava saber converter números pra binário de cor e enfiar instrução direto em endereço de memória, bit por bit, na mão. Teve uma época em que programar significava saber organizar baralho de cartão perfurado, saber que ordem do deck estava certa, saber onde um furo errado destruiu a execução, e saber debugar visualmente sem a fantasia moderna de backspace infinito. Teve uma época em que programar de verdade significava saber 6502, Z80 e Assembly porque os computadores tinham tão pouco recurso que cada byte importava mesmo, não como figura de linguagem.
Esses exemplos representam mais execução do que pensamento, são formas de operar dentro de um sistema já definido. A linguagem de programação muda isso porque aumenta o nível de abstração. Ela permite estruturar o pensamento de forma mais direta, sem precisar lidar com cada detalhe físico da máquina.
A calculadora é um bom paralelo com a IA. Existem vários tipos para diferentes propósitos, mas muitos ainda preferem papel ou quadro, porque isso permite acompanhar toda a construção do raciocínio, não só o resultado final.
Às vezes faz até sentido ter anotações escritas misturadas com números e desenhos, três formas diferentes de pensar juntas. Cada forma de pensamento é única. Tentar explicar um número apenas em texto, sem usar números, é quase impossível, porque números já são uma ideia e uma forma própria de representação.
Vejo que atualmente estamos tentando representar código com prompts e me pergunto se isso realmente faz sentido, pois da mesma forma que não resolvemos cálculos com texto, por que faria sentido resolver problemas de programação apenas com prompt?
A frase “uma imagem vale mais do que mil palavras” entra nesse mesmo contexto: cada situação faz mais sentido com um determinado método de representação, apenas números, apenas imagem ou apenas texto.
Uma IA hoje também funciona nesse modelo: ela entrega respostas a partir de entradas. Isso é útil quando você quer chegar rápido a algo já conhecido. Mas em muitos casos de criação de produto, onde o processo de pensamento precisa ser ajustado e controlado em detalhes, ela não substitui esse fluxo. Ela ajuda, mas não mostra o caminho completo do raciocínio, apenas gera uma saída a partir de um input.
Em um momento, em que eu queria apenas mudar a cor de um botão, demorei mais para explicar do que faria diretamente no código. “Como descrevo exatamente onde está o botão e qual parte alterar?” No código isso seria direto: filtrar pelo nome do botão e identificar exatamente o que precisa ser alterado com base no arquivo e no contexto, sabendo onde cada coisa está e como o sistema está estruturado.
A IA levou alguns segundos para interpretar, analisar e modificar. Um processo simples acabou ficando mais indireto. Depois disso ainda precisei ajustar várias vezes até chegar no resultado ideal.
Em alguns casos, tive que usar a URL da página como referência entre outros métodos, porque várias páginas tinham botões com padrões semelhantes. Aconteceu de eu pedir uma mudança descrevendo como era a página, onde estava o elemento e o que deveria ser alterado, mas a modificação acabou sendo aplicada em outra página. Depois disso, tive que caçar onde a alteração realmente foi feita. Isso aconteceu porque eu estava ciente da mudança, mas isso levanta outra questão: quantos outros problemas são gerados sem que eu perceba.
Existem ideias que continuam sendo muito mais fáceis de entender quando você está dentro do código. Algumas coisas são mais naturais de testar, ajustar e pensar diretamente em uma linguagem estruturada.
Essa imagem é de um post 2012, Ela contém um erro que só conseguimos identificar ao olhar o código.
A linguagem de programação é responsável por estruturar o pensamento. É nela que o raciocínio fica organizado, claro, verificável e sob controle. Criar algo novo, que exige controle, precisão e organização do pensamento, ao meu ver, ainda é mais direto com código do que com prompts.