A IA não deve substituir o pensamento, mas elevá-lo
(koshyjohn.com)- Quanto mais rápido se produzem resultados plausíveis, mais fácil fica repetir sem compreender, e pular a prática que desenvolve a capacidade de julgamento enfraquece a competência de longo prazo
- Em padrões familiares, a ajuda é grande, mas em problemas desconhecidos, condições ambíguas, informações incompletas e restrições conflitantes, a imitação superficial desmorona facilmente e a habilidade real aparece
- Engenheiros fortes delegam tarefas mecânicas como boilerplate, resumos, scaffolding de testes e aceleração de pesquisa, mas mantêm sob sua responsabilidade direta a definição do problema, a revisão, as escolhas e os descartes
- O maior valor da engenharia de software está menos em produzir código e mais em capacidade de julgamento; torna-se mais importante enxergar restrições ocultas, perceber problemas mal formulados e transformar discussões ambíguas em trade-offs
- Especialmente no início da carreira e na gestão organizacional, importam ainda mais os critérios que preservam 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 I.A. processa rapidamente tarefas como geração de código, resumo de reuniões, explicação de conceitos, rascunhos de design e atualizações de status, mas também pode criar facilmente o hábito de entregar resultados plausíveis sem compreensão
- Quando alguém repete a resposta da máquina como se fosse seu próprio entendimento, acaba apenas imitando um estado de aparente competência sem de fato desenvolver capacidade
- Quanto mais os resultados gerados substituem a própria compreensão, mais se pula a prática que desenvolve o julgamento, trocando competência de longo prazo por aparência de curto prazo
- Em situações que não cabem em templates — como problemas desconhecidos, condições ambíguas, informações incompletas e restrições conflitantes — a imitação superficial se rompe com facilidade
-
Analogia de copiar resposta de prova
- Dá para manter boas notas copiando respostas, mas quando se entra em uma situação que exige compreensão real, fica evidente que a base está vazia
- Sem a intuição construída ao fazer o trabalho por conta própria, torna-se difícil raciocinar sobre problemas não familiares ou reagir a mudanças nas condições
- Reutilizar repetidamente respostas dadas pela I.A. empresta apenas a aparência de experiência, sem construir experiência de verdade
-
Analogia da calculadora
- A calculadora é uma ótima ferramenta para economizar tempo, mas depender dela sem senso numérico impede verificar se o resultado faz sentido
- Um engenheiro com boa base consegue revisar a saída da I.A., filtrar erros e corrigi-los ou descartá-los
- Um engenheiro sem base não está usando a I.A.; ele está sendo conduzido pela I.A., o que é ainda mais perigoso em funções nas quais precisão e responsabilidade pelo resultado importam
-
Analogia do carro autônomo
- A direção autônoma reduz o cansaço e lida com situações do dia a dia, mas depender dela antes de entender como dirigir aproxima a pessoa mais de um passageiro com direito aos controles
- É em situações não padronizadas — visibilidade ruim, estradas complexas, outros veículos imprevisíveis, falhas do sistema ou perigos repentinos — que a habilidade real aparece
- A I.A. também é forte em padrões gerais e estruturas familiares, mas a engenharia constantemente sai desse terreno com mudanças de requisitos, bugs sutis, propriedade pouco clara, objetivos arquiteturais concorrentes, dados parciais, atrito organizacional e trade-offs sem resposta perfeita
Como engenheiros excelentes usam I.A.
- Engenheiros excelentes não usam menos I.A.; eles usam mais ativamente, sem transferir o próprio pensamento
- Delegam de bom grado tarefas mecânicas como escrever boilerplate, resumir documentos, gerar scaffolding de testes, sugerir refatorações, explorar possíveis falhas, acelerar pesquisas e comprimir trabalho repetitivo
- Em vez disso, formulam perguntas mais afiadas, definem o problema real em vez de apenas responder ao pedido imediato e priorizam clareza e concisão acima de frases elegantes sem substância
- Não se limitam a recombinar conhecimento já existente no sistema; produzem novo conhecimento de alto valor
- E reinvestem o tempo ganho em pensamento e julgamento de nível mais alto
A fonte real do valor
- Por muito tempo, a engenharia de software foi tratada como sinônimo de produção de código, mas o maior valor não está aí
- Se o núcleo do trabalho fosse apenas gerar código sintaticamente correto, a I.A. estaria de fato substituindo grande parte da função; na prática, o centro está na capacidade de julgamento
- Engenheiros valiosos enxergam restrições ocultas antes que causem incidentes, percebem quando a equipe está resolvendo o problema errado, transformam discussões ambíguas em trade-offs claros, encontram abstrações ausentes e fazem debugging não do código, mas da realidade
- A I.A. pode apoiar esse tipo de trabalho, mas não pode assumi-lo no lugar da pessoa
- No futuro, os engenheiros que criarão mais valor estarão mais próximos de construir princípios de design, entendimento de domínio, padrões, contexto e frameworks de decisão que tornem a I.A. mais útil
- Nesse ambiente, em vez de ser substituído pela I.A., o engenheiro ganha mais alavancagem ao trabalhar acima da camada de saída bruta
Um risco maior para engenheiros no início da 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 competências fundamentais como senso de debugging, intuição de sistemas, precisão, bom gosto, revisão cética, decomposição de problemas e a capacidade de explicar por que algo funciona
- Essas competências se constroem por meio de atrito, tentativa e erro, correção de falhas, rastreamento da causa raiz e experiências em que a pessoa colide com a realidade
- Se a I.A. remove todas as dificuldades do processo de aprendizado, pode haver ganho de eficiência no curto prazo, mas ao custo de pular a fase em que a capacidade é forjada
- Por um ou dois trimestres, isso pode até parecer eficiente, mas silenciosamente pode comprometer a habilidade que sustentaria o futuro
- Sistemas de apoio podem fazer parecer que tudo funciona, mas não criam capacidade real no lugar da pessoa
Não há atalho para o julgamento
- Ler explicações geradas não faz com que a habilidade seja transferida para a cabeça sem que a pessoa trabalhe por conta própria
- Não existe caminho para desenvolver raciocínio forte depois de terceirizar o raciocínio por muito tempo
- É possível e desejável terceirizar tarefas mecânicas, acelerar a pesquisa e comprimir trabalho repetitivo
- Mas não se adquire uma habilidade pulando o próprio processo de formação técnica
- O erro central do uso mais ingênuo da I.A. é achar que se está economizando tempo quando, na verdade, só se está adiando a cobrança de um preço em julgamento fraco, entendimento superficial e baixa adaptabilidade
A linha divisória e as implicações no nível organizacional
- Se a I.A. ajuda a construir entendimento mais rápido, a pensar com mais profundidade e a trabalhar em nível mais alto, o valor humano aumenta
- Se a I.A. ajuda a evitar o entendimento, evitar a dificuldade e evitar a responsabilidade pelo raciocínio, o valor humano diminui
- Um caminho se acumula como juros compostos; o outro esvazia por dentro e empurra para um estado de facilmente irrelevante
- O futuro favorece não os engenheiros que simplesmente usam I.A., mas os que distinguem com precisão o que delegar e o que manter sob sua responsabilidade, convertendo economia de tempo em pensamento melhor
Por que isso pesa ainda mais na saúde organizacional
- A gestão de engenharia também ficará nessa mesma fronteira entre o uso que acelera o entendimento e o uso que imita entendimento
- Liderança forte precisa ser capaz de distinguir resultados polidos de capacidade real de julgamento; se recompensar apenas velocidade, fluidez e boa apresentação, perderá os sinais de profundidade técnica
- Quando se espalha um trabalho de baixa compreensão e alta fluidez, não cai apenas a qualidade da produção individual; enfraquece-se o próprio ambiente de conhecimento da organização
- As revisões ficam mais fracas
- As discussões de design ficam mais rasas
- A documentação fica mais polida, mas 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 essencial não é a simples adoção de ferramentas de I.A., mas preservar as condições em que pensamento real, aprendizado real e artesania real sobrevivem
- Já no recrutamento, são necessários meios de identificar entendimento real em vez de mera fluidez aparente
- Entrevistas devem testar o processo de raciocínio mais do que respostas polished
- Avaliações devem recompensar clareza, profundidade, julgamento sólido e contribuições técnicas duradouras mais do que volume de output
- Isso também afeta o desenho das equipes e a cultura
- É preciso evitar que engenheiros fortes gastem tempo demais limpando trabalho plausível, mas superficial feito por quem terceirizou o pensamento
- Se isso não for contido, quem tem alta performance acaba sendo consumido como amplificador para todos os outros, o que tende a levar a frustração, queda de padrão e saída de pessoas
- No fim, a qualidade organizacional na era da I.A. dependerá mais da capacidade da liderança de continuar distinguindo entre alavancagem e dependência, aceleração e imitação, competência real e output persuasivo
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