A IA não deve substituir o pensamento, e sim elevá-lo
(koshyjohn.com)- Quanto mais rápido se produzem resultados plausíveis, mais fácil fica repetir sem entender; se você pula o treino de desenvolver a capacidade de julgamento, sua capacidade de longo prazo enfraquece
- Em padrões familiares, a ajuda é grande, mas diante de problemas desconhecidos, condições ambíguas, informações incompletas e restrições conflitantes, a imitação superficial desmorona com facilidade e a habilidade real aparece
- Engenheiros fortes delegam de bom grado trabalho mecânico como boilerplate, resumos, scaffolding de testes e aceleração de pesquisa, mas mantêm propriedade direta sobre definição do problema, revisão, escolhas e descarte
- O maior valor da engenharia de software está menos na produção de código e mais na capacidade de julgamento; torna-se mais importante enxergar restrições ocultas, perceber o problema errado e transformar debates ambíguos em trade-offs
- Especialmente no início da carreira e na operação das organizações, torna-se ainda mais importante ter critérios para preservar o entendimento real; quanto melhor se distingue o que delegar e o que assumir diretamente, mais a IA se torna uma ferramenta que amplia o valor humano
Modos de falha que surgem ao terceirizar o pensamento
- A IA processa rapidamente tarefas como gerar código, resumir reuniões, explicar conceitos, redigir rascunhos de design e escrever atualizações de status, mas também facilita o hábito de entregar apenas resultados plausíveis, sem compreensão
- Quando alguém repete a resposta da máquina como se fosse seu próprio entendimento, passa a imitar apenas um estado de aparente competência, sem de fato construir capacidade
- Quanto mais os resultados gerados substituem a compreensão própria, mais se pula o treino necessário para desenvolver julgamento, trocando capacidade de longo prazo por aparência de curto prazo
- Em situações que não cabem em um template — como problemas desconhecidos, condições ambíguas, informações incompletas e restrições conflitantes — a imitação superficial quebra facilmente
-
A analogia de copiar a resposta na prova
- Dá para manter boas notas copiando respostas, mas, quando se entra numa situação em que a compreensão real é necessária, fica evidente que a base está vazia
- Sem a intuição construída ao fazer o trabalho por conta própria, fica difícil raciocinar sobre problemas não familiares ou reagir a mudanças nas condições
- Reutilizar repetidamente as respostas dadas pela IA só empresta a aparência da experiência, sem acumular experiência de verdade
-
A analogia da calculadora
- A calculadora é uma ótima ferramenta para economizar tempo, mas, sem senso numérico, a dependência faz com que você não consiga verificar se o resultado faz sentido
- Um engenheiro com base sólida consegue revisar a saída da IA, filtrar erros e corrigi-la ou descartá-la
- Um engenheiro sem essa base não está usando a IA — está sendo levado por ela, e isso se torna ainda mais perigoso em funções onde precisão e responsabilidade pelo resultado são cruciais
-
A analogia do carro autônomo
- A direção autônoma reduz a fadiga e lida com situações cotidianas, mas, se houver dependência antes de entender como dirigir, a pessoa se aproxima mais de um passageiro com acesso aos controles
- É em situações fora do padrão — visibilidade ruim, estradas complexas, outros veículos imprevisíveis, falha do sistema e riscos súbitos — que a habilidade real aparece
- A IA também é forte em padrões gerais e estruturas familiares, mas a engenharia constantemente sai disso com mudanças de requisitos, bugs sutis, propriedade pouco clara, metas arquiteturais em conflito, dados parciais, atrito organizacional e trade-offs sem resposta perfeita
Como engenheiros excelentes usam IA
- Engenheiros excelentes não usam menos IA; eles a usam mais ativamente, sem abrir mão do próprio pensamento
- Delegam com gosto trabalho mecânico como escrever boilerplate, resumir documentos, gerar scaffolding de testes, sugerir refatorações, explorar possibilidades de falha, acelerar pesquisa e comprimir tarefas repetitivas
- Em vez disso, formulam perguntas mais afiadas, definem o problema real em vez de apenas responder à solicitação imediata e priorizam clareza e concisão acima de frases polidas sem substância
- Não ficam apenas recombinando conhecimento já existente no sistema; produzem novo conhecimento de alto valor
- O tempo ganho assim é reinvestido em pensamento e julgamento de nível mais alto
A verdadeira fonte de valor
- Por muito tempo, tratamos engenharia de software como sinônimo de produção de código, mas o maior valor não está aí
- Se o essencial fosse apenas produzir código sintaticamente correto, a IA já estaria substituindo diretamente uma grande parte do trabalho; na prática, o núcleo está na capacidade de julgamento
- Engenheiros valiosos enxergam restrições ocultas antes que causem incidentes, percebem que a equipe está resolvendo o problema errado, transformam debates ambíguos em trade-offs claros, encontram abstrações que faltam e fazem debug não do código, mas da realidade
- A IA pode apoiar esse tipo de trabalho, mas não pode assumi-lo no seu lugar
- No futuro, os engenheiros que gerarão mais valor estarão mais próximos de criar princípios de design, entendimento de domínio, padrões, contexto e frameworks de decisão que tornem a IA mais útil
- Nesse ambiente, em vez de ser substituído pela IA, o engenheiro ganha mais alavancagem ao trabalhar em um nível acima da saída bruta
Um risco ainda maior para engenheiros em início de carreira
- Esse problema é especialmente importante para quem está no início da carreira
- Os primeiros anos são o período em que se formam capacidades fundamentais como faro para debug, intuição de sistemas, precisão, gosto, revisão cética, decomposição de problemas e a habilidade de explicar por que algo funciona
- Essas capacidades se constroem com atrito, tentativa e erro, correção de falhas, rastreamento da causa raiz e experiências em que suas ideias colidem com a realidade
- Se a IA remove toda a dificuldade do processo de aprendizagem, pode haver ganho de eficiência no curto prazo, mas ao custo de pular a fase em que a capacidade é afiada
- Por um ou dois trimestres, a pessoa pode parecer eficiente, mas silenciosamente deixa de desenvolver a habilidade que sustentará o futuro
- Sistemas de apoio podem fazer algo parecer funcional, mas não conseguem criar, no lugar da pessoa, a capacidade real
Não há atalho para o julgamento
- Apenas ler explicações geradas não faz com que a experiência se transfira para a cabeça sem que a pessoa trabalhe por conta própria
- Não existe caminho em que alguém terceiriza o raciocínio por muito tempo e, ainda assim, termina com uma forte capacidade de raciocínio
- É possível e desejável terceirizar trabalho mecânico, acelerar pesquisa e comprimir tarefas repetitivas
- Mas não se chega a possuir uma habilidade simplesmente pulando o processo de formação dessa habilidade
- O erro central do uso mais ingênuo de IA é pensar que se está economizando tempo quando, na verdade, só se está adiando a conta de um julgamento fraco, compreensão superficial e baixa adaptabilidade
A linha divisória e as implicações no nível organizacional
- Se a IA ajuda a construir entendimento mais rápido, pensar com mais profundidade e trabalhar em um nível mais alto, o valor humano cresce
- Se a IA ajuda a evitar a compreensão, evitar a dificuldade e evitar a propriedade sobre o raciocínio, o valor humano diminui
- Um caminho se acumula como juros compostos; o outro esvazia por dentro e empurra para um estado de fácil irrelevância
- O futuro favorece menos os engenheiros que simplesmente usam IA e mais os que distinguem com precisão o que delegar e o que manter sob propriedade direta, convertendo a economia de tempo em pensamento melhor
Por que isso pesa ainda mais na saúde organizacional
- A gestão de engenharia também passa a estar na mesma fronteira entre usos que aceleram a compreensão e usos que imitam compreensão
- Liderança forte precisa distinguir resultados polidos de julgamento real; se recompensar apenas velocidade, fluência e apresentação, perderá os sinais de profundidade técnica
- Quando se espalha trabalho com baixa compreensão e alta fluência, não cai apenas a qualidade da produção individual: enfraquece-se o ambiente de conhecimento da própria organização
- As revisões ficam mais fracas
- As discussões de design ficam mais rasas
- A documentação fica mais polida, porém menos útil
- Com o tempo, a organização perde a capacidade de produzir a clareza e o julgamento técnico dos quais depende
- Por isso, o ponto central não é apenas adotar ferramentas de IA, mas preservar as condições em que pensamento real, aprendizado real e domínio do ofício consigam sobreviver
- Já na contratação, é preciso ter meios de distinguir entendimento real de mera fluência aparente
- Entrevistas devem testar o processo de raciocínio, não respostas polished
- Avaliações devem recompensar clareza, profundidade, julgamento sólido e contribuições técnicas duradouras, e não apenas volume de saída
- Isso também tem grande impacto no desenho das equipes e na cultura
- É preciso evitar que engenheiros fortes gastem tempo demais limpando trabalho plausível, porém superficial produzido por quem terceirizou o pensamento
- Se isso não for evitado, profissionais de alta performance acabam consumidos como amplificadores para todos os outros, o que tende a levar a frustração, queda de padrão e evasão
- No fim, a qualidade organizacional na era da IA dependerá cada vez mais de a liderança conseguir distinguir continuamente entre alavancagem e dependência, aceleração e imitação, capacidade real e saída persuasiva
1 comentários
Opiniões do Hacker News
Quanto mais releio essa tese, mais a sofisticação da formulação me agrada, mas ainda parece que não chegou ao nível de um aforismo
Para virar uma frase que acerte muita gente em poucas palavras, como "the medium is the message", "you ship your org chart" ou "9 mothers can't make a baby in a month", é preciso passar anos ou décadas lapidando o significado
E como nem sabemos lidar com a formação de significado via RL, a IA não consegue fazer isso no nosso lugar
O original correto é "9 women can't make a baby in one month"
Aprender fazendo por conta própria. Essa frase me parece mais próxima de um aforismo
Intelligence amplification, not artificial intelligence parece bom
Abreviado, vira IA, not AI e, em espanhol, fica ainda mais divertido como "AI, no IA"
Gosto e capacidade de julgamento não são coisas que a IA possa gerar por você
Se você perguntasse a 100 americanos o que esse aforismo significa, provavelmente quase ninguém apontaria corretamente o sentido original de McLuhan
Acho que, em geral, dá para usar IA de duas formas
Uma é como apoio para escrever código que eu possuo e entendo; a outra é usar a IA como uma camada de abstração e deixá-la encarregada de escrever e manter o código
A segunda funciona bem para protótipos, exemplos e referências, onde a vida útil é curta e a qualidade do código ou o meu nível de entendimento não importam tanto
O problema surge quando se usa a opção 2 em tarefas que, na verdade, precisam da opção 1, enganando a si mesmo e aos outros
Pode parecer rápido e fácil, mas no fim é como hipotecar a base de código, e acho que é aí que começa a atrofia da capacidade
As funcionalidades continuam saindo e, por fora, tudo parece normal, mas quando algo quebra você percebe que nem consegue debugar o próprio código sem voltar a perguntar ao modelo
Há muitos engenheiros que não conseguem trabalhar sem uma IDE moderna, uma linguagem com gerenciamento de memória e bibliotecas do GitHub ou de um gerenciador de pacotes
Por isso, a dependência de IA não me parece essencialmente tão diferente assim
O próprio significado da palavra Engineer pode mudar, e na prática já existem "web developers" que só usam Webflow ou WordPress
Numa definição estrita, entre as pessoas da área de Software Engineering quase não há engenheiros credenciados de fato, e em alguns países isso até envolve licença e título profissional
No começo da carreira, com tempo suficiente, eu provavelmente fazia quase qualquer coisa, mas hoje há uma longa lista de coisas que eu poderia fazer e não faço porque não acho divertido
Não sabemos se a IA vai custar como uma assinatura do Slack, como o custo de um membro da equipe, ou se o serviço vai desaparecer e será preciso contratar separadamente alguém com acesso à IA
Então depender de IA é bem diferente de depender de uma IDE, que pode ser uma ferramenta local ou open source
Alguém com uns 10 anos de experiência entende o fluxo e a lógica do código, então consegue usar IA e ainda assim produzir código e melhorar o próprio método
Já um iniciante tende a não entender o fluxo nem a lógica e só sair copiando e colando, então não me parece que a IA dê mais espaço para esse tipo de pessoa pensar
O jeito atual de usar IA me parece mais cansativo do que os últimos 20 anos de programação
Jogar o problema, avaliar sugestões, escolher a direção certa, descartar sugestões estranhas e depois refinar tudo até ficar quase certo é uma parte especialmente exaustiva
Depois disso, deixo a codificação rodando por 1 a 5 horas, e ela às vezes entrega um resultado que, se eu fizesse sozinho, levaria pelo menos 2 ou 3 semanas
Só que, depois de umas 5 horas trabalhando assim, de forma centrada em planejamento, eu fico completamente esgotado, e esse cansaço é diferente do que sinto fazendo programação pura
Parece que estou aprendendo alguma coisa, mas sinceramente também dá uma sensação de estar fazendo mais trabalho de gerente
Para definir um problema com calma junto com um LLM e chegar a uma solução plausível, preciso manter um estado de concentração o tempo todo, então aquele velho fluxo de imersão quase não aparece
É preciso processar uma montanha de saídas e ficar repetidamente extraindo o essencial, e mesmo quando o resultado é bom quase sempre existe alguma pequena distorção irritante
Também é necessário manter um nível alto de vigilância por causa dos erros estranhos e falhas de raciocínio típicos de LLMs, e só o ato de interpretar esse estilo de comunicação não humano já é cansativo
Mas às vezes penso que pacing ou procrastination talvez funcionem para humanos como uma espécie de válvula de alívio de pressão
Sempre houve muitos engenheiros que simplesmente não pensam bem, e a IA não muda esse fato
Esse é um dos motivos de a área de Software Engineering ter se deteriorado tanto, e a IA talvez não resolva isso, apenas adie temporariamente uma confusão ainda maior
Mesmo quem passou pela faculdade colando precisava de pensamento crítico para não ser pego e sair impune
Pode ser desagradável ouvir isso, mas até colar bem exige bastante capacidade de raciocínio
Acho que quem delega o pensamento à IA em qualquer nível nunca valorizou isso de verdade
Como diz o ditado "use it or lose it", e embora venham surgindo cada vez mais estudos que sustentam isso, continuam aparecendo textos dizendo que usar LLMs no desenvolvimento de software está tudo bem e que nosso valor estaria na capacidade de pensar
Um dos encantos desse trabalho é justamente o momento em que, mesmo estando totalmente absorvido em outra coisa, a solução simplesmente surge de repente
Agora a IA virou uma ferramenta para transformar esse pensamento em ação rapidamente
Antes, eu às vezes perdia o fio antes mesmo de conseguir agarrar a ideia; agora, em poucos minutos no celular, consigo pelo menos tornar parte do pensamento real e depois voltar ao que estava fazendo
É especialmente valioso não precisar mais se preocupar em perder a ideia só porque desviei o olhar por um instante
Estou reescrevendo o numba agora, e é difícil imaginar fazer isso só na mão
Quando tentei há alguns anos, foi extremamente doloroso, lento e bagunçado
Havia um acúmulo interminável de pequenas coisas sobre camadas e mais camadas de abstração construídas ao longo dos anos
Desta vez estou refazendo com ajuda de LLM, e algo que normalmente levaria semanas às vezes termina de um dia para o outro
Mesmo assim, eu continuo olhando o código, examinando a saída em C gerada e mantendo o controle da arquitetura para que, no futuro, eu e o LLM consigamos lidar com ela com facilidade
Não sei ao certo se isso está substituindo o meu pensamento
Se eu tivesse passado meses escrevendo e corrigindo tudo manualmente, provavelmente teria aprendido mais sobre compiladores ou transpilers, mas então eu teria ficado preso só nisso
Em vez disso, agora ainda me sobra tempo para escrever suporte de servidor NFS para um sistema de arquivos customizado em Golang
Já montei sistemas em que agentes encontram as mudanças necessárias para uma funcionalidade inteira, destrincham isso com enorme detalhamento na fase de planejamento e depois acertam a implementação praticamente de primeira
Ao longo do último ano, fui lendo cada vez menos código diretamente, e muitas vezes me pego questionando se o meu nível de conforto com o sistema atual não está alto demais
Vi níveis tão altos de precisão e taxa de sucesso se repetirem tantas vezes que já não desconfio por instinto
Fico esperando levar uma grande pancada algum dia, mas, estranhamente, esse momento quase nunca chega
Claro que houve pequenas omissões e reversões, mas isso também acontecia antes
A diferença é que antes eu tinha uma relação muito mais pessoal com o código, porque fui eu quem sofreu para escrevê-lo
Agora, quando surge um problema, em vez de culpar o código, eu acabo investigando de novo por que o sistema não conseguiu chegar sozinho à resposta certa, ou por que ele não conseguiu revelar o quadro completo no planejamento antes de implementar
A maior vantagem da IA em software é permitir criar código mais rápido
A maior desvantagem é te seduzir a querer criar tudo absurdamente mais rápido
Por isso, não uso IA em projetos pessoais
Quero manter a mente afiada
Se for um projeto que envolva IA, pode haver exceções, mas eu não uso IA para escrever esse código
Já no trabalho da empresa, não me importo
Se o gerente quiser fazer vibe coding total com Claude, então é isso que vai ser, porque não sou eu quem vai pagar o custo da dívida técnica gerada por isso