Crise de identidade do programador
(hojberg.xyz)- A identidade do programador está sendo ameaçada recentemente com o surgimento da IA e das ferramentas de LLM
- A cultura da programação começou com a ética hacker do MIT nos anos 1950 e passou a tratar o próprio ato de escrever código como um ofício profundo, tendo como valores centrais a lógica precisa e a imersão na resolução de problemas
- Porém, hoje a indústria de IA e as ferramentas de LLM estão tentando transformar desenvolvedores em meros redatores de especificação ou operadores, impondo uma forma de "vibe-coding" em que, em vez de escrever código diretamente, só se dão instruções em linguagem natural
- O código gerado por LLM é não determinístico e impreciso, e elimina a compreensão profunda e a imersão que o desenvolvedor obtém ao ler e escrever código diretamente, rompendo sua conexão com a base de código
- Empresas estão forçando o uso dessas ferramentas em nome do aumento de produtividade e substituindo a cultura de colaboração e mentoria entre equipes por interações com IA, enfraquecendo os vínculos humanos entre desenvolvedores
- O valor essencial de ver a programação não como um simples produto final, mas como um processo de pensamento e compreensão, está se perdendo, e os desenvolvedores precisam resistir a essa mudança para proteger sua habilidade, seu prazer e sua identidade profissional
A essência e a tradição do programador
-
Escrever código não é apenas uma tarefa, mas a própria identidade do desenvolvedor, e o editor é oficina e santuário ao mesmo tempo, um espaço para lapidar a técnica e entrar em estado de fluxo (
flow)- Com ferramentas como o Vim, trabalha-se sem barreiras entre pensamento e código, criando um mundo imaterial que afeta o mundo real
- O processo de resolver o quebra-cabeça é mais importante do que a imagem final, e o tempo desaparece no fluxo técnico que vai dos dedos ao buffer
-
No fim dos anos 1950, no MIT, nasceu uma nova cultura de programação, em que hackers de perfil experimental e contracultural usavam o Flexowriter e o computador TX-0 em busca do programa perfeito
- O objetivo era escrever código elegante e conciso em torno do conceito de "The Right Thing"
- Os membros do Tech Model Railroad Club mergulhavam em linguagem de máquina, aprendiam magia digital e estabeleciam uma cultura de compartilhar com outros estudantes o conhecimento descoberto
-
No cadinho da computação do Building 26, a técnica de programação foi forjada, e essa cultura estabelecida há cerca de 70 anos continua até hoje, ainda presente na mente dos desenvolvedores e nas máquinas
- O legado dos hackers antigos permanece como uma habilidade profunda e quase física, sobre a qual foi construída uma indústria movida por paixão
- Desenvolvedores continuam sendo motivados pelo mesmo senso de maravilhamento, realização e elegância na solução de quebra-cabeças
-
Porém, esses valores centrais que compõem a identidade do programador estão sob ameaça, e o futuro da programação, antes claro e promissor, agora está encoberto por uma escuridão inquietante, fraude e incerteza
A imposição de uma nova identidade pela indústria de IA
-
A indústria bilionária de IA, a comunidade do Hacker News e defensores de LLM no LinkedIn afirmam que o futuro do desenvolvimento de software quase não se parece com programação, e o "vibe-coding", que há um ano parecia um meme, está virando mainstream
- Desenvolvedores agora deveriam escrever especificações em Markdown em vez de código, enquanto desaparecem a imersão profunda e a profundidade técnica de explorar cada canto do codebase, resolver quebra-cabeças e descobrir segredos
- Em vez disso, deve-se aceitar uma cognição dispersa e trocas constantes de contexto enquanto agentes pensam pelo desenvolvedor; a solução criativa de problemas fica a cargo da máquina, e o desenvolvedor vira apenas um operador
-
Alguns desenvolvedores recebem bem essa mudança e a nova identidade chamada "Specification Engineering", empolgados com a ideia de virar operadores e, como Steve Jobs, "conduzir a orquestra"
- Isso levanta a dúvida de por que se tornaram programadores se aparentemente não têm interesse em programar, como se tivessem confundido Woz com Jobs
- Não parece que Prompt, Context e Specification "Engineering" tragam uma carreira brilhante e próspera para programadores
-
Isso representa uma desvalorização da técnica, da habilidade e do trabalho, deslocando a capacidade única de abstração do desenvolvedor para uma área em que ela já não é mais necessária, entrando num espaço que já vem sendo ocupado por gerentes de produto e designers
A mudança na dinâmica de poder dentro das empresas
-
À medida que essa nova identidade é imposta dentro das empresas, a dinâmica de poder muda, e numa tentativa frenética de aumentar a produtividade no lugar errado, desenvolvedores estão sendo obrigados a usar LLMs de formas cada vez mais específicas
- Quem não se conforma é empurrado para fora e precisa escolher entre usar produtos que anunciam sua própria inutilidade ou pedir demissão
- No passado, era raro a gestão dizer de forma tão específica quais ferramentas os desenvolvedores deveriam usar
-
Como chefs ou carpinteiros, desenvolvedores sempre tiveram grande orgulho em curar e lapidar suas ferramentas, personalizando-as ao seu modo de pensar com configurações minuciosas do editor, ajustes em dotfiles e montagem do ambiente de desenvolvimento
- Houve dedicação em personalizar o conjunto de ferramentas como parte da própria técnica, e ver uma gestão quase desconectada do trabalho cotidiano ditar isso soa como invasão
- Para programadores que passaram décadas sendo privilegiados dentro das empresas, essa narrativa oferece à gestão uma nova forma de inclinar o equilíbrio novamente a seu favor
A diferença essencial entre LLMs e linguagens de programação
-
Alguns comparam o impacto dos LLMs à transição de linguagens de baixo nível para linguagens de alto nível (de Assembly para Fortran), mas essa analogia está errada em vários aspectos
- O Fortran tinha raízes na programação e não tentava remover a técnica, mas construir sobre ela, ampliando a precisão e a expressividade da programação em vez de eliminá-las
- O Fortran sempre gerava corretamente o resultado esperado a partir da entrada; no mundo dos LLMs, nada disso é verdade
-
Computadores e programação podem ser extremamente frustrantes, mas pelo menos sempre foi possível confiar na precisão, porque a programação executava exatamente o que se instruía
- Justamente por essa dependência e confiança na precisão do computador, é fácil acreditar quando um chatbot faz gaslighting e afirma ter feito a tarefa pedida
-
LLMs e seu trabalho são essencialmente imprecisos, tanto pelas propriedades dos grandes modelos de linguagem quanto pela própria forma de instruí-los em linguagem natural, que abre margem para mal-entendidos
- É curioso que programadores que detestam não determinismo tenham escolhido essa abordagem, já que preferem previsibilidade, composicionalidade, idempotência e testes de integração estáveis
- O código de LLM representa o oposto: caos inconsistente
-
Dijkstra, em "On the foolishness of natural language programming", apontou que é preciso questionar a suposição de que a linguagem natural simplificaria a tarefa, e enfatizou que a vantagem do texto formal é exigir apenas o cumprimento de algumas regras simples para ser válido
A perda da compreensão profunda e da imersão
-
Existe um movimento para separar o desenvolvimento assistido por IA do vibe-coding por meio de rigor e burocracia, mas isso ignora a essência do problema
- Não se lê com o mesmo cuidado o código gerado por LLM que se leria se tivesse sido escrito por você ou revisado num PR, e há algo intrínseco no código por LLM que entorpece o olhar
- A tendência é passar os olhos por cima, sentir-se sobrecarregado e entediado, e, se o CI passar e o programa compilar, aceitar cegamente armadilhas perigosas
- Não se verifica se os testes realmente foram configurados para rodar, se foi importada uma biblioteca inexistente ou se o modelo implementou sozinho uma biblioteca inteira
-
A resenha ou o resumo de um livro não substitui a experiência de lê-lo diretamente; é preciso consumir cada frase com cuidado ao longo de centenas de páginas e refletir sobre as ideias
- Da mesma forma, passar os olhos pelo resumo de um trabalho concluído por IA rouba a compreensão profunda do domínio, do problema e das possíveis soluções, e corta a conexão com o codebase
- Mergulhar no abismo da ignorância, revelar o tema e suas implicações, aprender e compreender é algo satisfatório e essencial para um bom software
- Propriedade, autonomia e trabalho profundo e gratificante são substituídos por atenção dispersa entre abas de agentes
-
Joan Didion disse: "Escrevo para descobrir o que estou pensando, o que estou vendo, o que vejo e o que isso significa", e Peter Naur explorou a mesma ideia em "Programming as Theory Building"
- A "Theory" de Naur encarna a compreensão da base de código, incluindo como ela funciona, seu formalismo e sua representação do mundo real
- Esse contexto e esse insight só podem ser obtidos por meio da imersão, e Naur descreve a "Theory" como o principal resultado da programação, mais importante até do que o software em si, o verdadeiro produto
- Só com uma "Theory" bem desenvolvida é possível aplicar extensões e corrigir bugs com eficácia em uma base de código
-
Um bom design nasce da imersão, aparecendo no vai e vem dentro do buffer de texto e muitas vezes também longe do teclado
- Como não é possível manter todo o codebase na cabeça, é preciso mergulhar em módulos, classes e funções para tornar mais nítido um modelo mental ainda difuso
- É necessário ler e escrever código para expandir a cognição e recuperar a familiaridade e a compreensão do domínio do problema
-
Parte do contexto vai sendo construída, e só após muitas tentativas falhas finalmente se encontra uma solução; é preciso sentir a dissonância de um design ruim
- Só ao escrever código feio e repetitivo se percebe que existe um jeito melhor, mais conciso, elegante, combinável e reutilizável
- Isso faz a pessoa parar para pensar profundamente no problema, dar um passo atrás e recomeçar do zero
- Já o trabalho com agentes de IA é sem atrito, o que leva a evitar soluções alternativas; não dá para saber se o que foi aceito é excelente, mediano, terrível ou até prejudicial
O colapso da colaboração em equipe e da conexão humana
-
A dívida cognitiva da programação centrada em LLM vai além da erosão técnica: "slop-jockeys" de atenção curta despejam seu trabalho em pull requests e documentos de design, prejudicando a colaboração e atrapalhando a equipe
- Colegas que revisam código estão ficando desnorteados com a percepção chocante de que já não são a última camada de controle de qualidade, mas a primeira
- Precisam apontar funções recém-adicionadas mas nunca chamadas, bibliotecas alucinadas e erros óbvios de compilação ou de runtime
- O autor, que claramente só passou os olhos pelo próprio código, não assume responsabilidade e diz: "Foi o Claude que escreveu assim. IA boba, haha"
-
Gestores intrometidos e executivos obcecados por economizar pressionam as equipes a reduzir as interações humanas — espera-se que de forma inconsciente
- Em isolamento e privados de conexão, desenvolvedores agora recebem permissão e incentivo para erguer muros em torno da própria experiência de trabalho
- Quando precisam de pair programming, de trocar e discutir soluções, criar protótipos, rascunhar arquitetura ou responder dúvidas especializadas sobre partes obscuras do codebase, passam a recorrer ao LLM em vez de a outra pessoa
- Já não seria necessário onboarding buddy, mentor ou colega; basta conversar com a máquina
- Evitar contato humano com LLMs está se tornando tão fácil que isso pode virar o padrão
A defesa da identidade do programador
-
É chocante o quanto estamos sendo conformistas diante da narrativa de hype da IA, participando ativamente da eliminação planejada da técnica e abrindo mão de bom grado dos nossos meios de pensar
- Tivemos a sorte de conseguir viver de um hobby, mas, mesmo criando processos rígidos e meticulosos para reagir ao slop, ainda estamos terceirizando a parte divertida do trabalho e trocando-a por um fardo prescritivo
-
LLMs parecem uma solução de jogar uma bomba nuclear em órbita sobre a complexidade do software, recorrendo a algo muito mais complexo e opaco para tratar sintomas em vez de resolver o problema real
- Trocar
sedpor Claude, ou pedir respostas sobre uma biblioteca ou framework cuja documentação foi vasculhada por horas sem trazer clareza, tudo bem - Mas não há desejo de virar apenas operador ou revisor de código, ficando no banco de trás do trabalho divertido e interessante
- Trocar
-
A preferência é por ferramentas que ajudem em tarefas repetitivas, na compreensão do codebase e na escrita do programa correto, e há repulsa por produtos projetados para pensar no meu lugar
- Rejeitam-se produtos que eliminam a autonomia sobre a compreensão do software produzido e rompem a conexão com os colegas
- Mesmo que os LLMs cumpram todo o hype, ainda assim perderemos tudo isso e também a técnica
- Seres humanos importam mais do que máquinas e as empresas que as sustentam, enquanto elas lucram e o restante de nós corre atrás do novo sonho americano que estão vendendo
- Em troca, estamos entregando capacidade de pensamento crítico, diversão, habilidade, privacidade e talvez até o planeta
3 comentários
No geral, concordo bastante
Especialmente a troca de contexto? Você faz o pedido do prompt e, no tempo de espera, perde o foco, o que acaba reduzindo a produtividade. Talvez isso se resolva se a velocidade dos LLMs aumentar e as respostas vierem de forma imediata
Parece fortemente que o próprio texto já parte de uma conclusão pronta e foi escrito para confirmá-la. A questão da remoção do senso de ownership dos desenvolvedores, independentemente dos LLMs, me soa mais como uma discussão sobre "a era do espírito artesão vs. a era da industrialização".
Opinião do Hacker News
O que mais me impressionou foi ver os revisores de código surtando aos poucos ao perceberem que agora eles deixaram de ser a etapa final de controle de qualidade e passaram a ser a primeira linha de defesa. Recebem pedidos de revisão, mas agora precisam identificar um por um funções recém-adicionadas que nunca são chamadas, bibliotecas incluídas do nada e erros óbvios de runtime ou compilação. O autor do código foge da responsabilidade e passa pano com um “foi o Claude que escreveu, a IA errou, haha”. Depois da adoção de LLMs, a lei de Brandolini (a energia necessária para refutar besteira é muito maior do que a necessária para produzi-la) ficou ainda mais real. Quando um desenvolvedor inexperiente ou tecnicamente fraco despeja milhares de linhas em poucos minutos, a responsabilidade de garantir a sanidade do sistema acaba sendo transferida para os revisores. Se você olha o delta de LoC adicionadas/removidas em PRs, os PRs escritos por LLM quase sempre só continuam adicionando código, enquanto engenheiros sêniores experientes frequentemente removem código existente na mesma medida em que adicionam código novo
Na minha visão, isso não é um problema técnico, é um problema de pessoas. Se isso acontecer uma vez, deve haver um aviso sério; se acontecer pela segunda vez, eu mandaria ao gerente e recusaria. Não importa quem escreveu o PR, no fim seu nome está no resultado, então se o código está uma bagunça, a responsabilidade também é sua
Eu já não faço mais code review em times grandes, mas se eu estivesse numa situação dessas, até deixaria passar essa fuga de responsabilidade uma vez; se se repetisse, tentaria tirar essa pessoa do time. Se não fosse possível, eu pediria demissão. É um ambiente horrível nesse nível
Acho que isso também está relacionado ao fato de eu sentir que minha produtividade caiu ultimamente. Existe a pressão para produzir mais código mais rápido e, quando uso algo como um agente, não consigo entender direito todo o contexto do código que saiu. Só consigo garantir qualidade dentro do que posso revisar minuciosamente linha por linha, e esse é o limite. Por isso, hoje uso IA de forma mais lenta e conservadora e aumentei a proporção de código que escrevo manualmente. A IA ajuda um pouco quando é para aplicar definições de tipos claras ou uma spec repetidamente em várias propriedades, mas mesmo nesses casos o resultado nem sempre é confiável
Quanto mais experiente é o engenheiro sênior, mais comum é que ele remova código antigo na mesma medida em que adiciona código novo. Vale ler também Negative 2,000 Lines Of Code
Acho que, no momento em que um LLM entra na equação, a forma como deslocamos responsabilidade para alguém passa a ser um problema social mais amplo. As pessoas ficam com o mérito quando o resultado é bom, mas, quando é ruim, culpam a IA com facilidade. Acredito que bastariam alguns precedentes judiciais adequados para essa cultura mudar bastante
Há muito tempo tenho a impressão de que muita gente que entra na área vê código menos como um ofício e mais como um jeito fácil de ganhar dinheiro. Desde quando li textos sobre desenvolvedores de infraestrutura open source que mal conseguem se sustentar, passando por devs codando em cafeteria, bootcamps e o movimento do “basta aprender a programar”, grinders de Leetcode e desenvolvedores morando no carro em São Francisco porque o aluguel é absurdo, agora o tema virou automatizar a si mesmo com IA e perder o emprego. O problema é a percepção de que desenvolvedores não são profissionais de verdade. Os critérios são frouxos, não há código de ética, nem conjunto consistente de habilidades, nem representatividade. Pior: a própria categoria não tem agência nem para defender os próprios interesses. Advogados têm a OAB, médicos têm conselhos e associações médicas, mas desenvolvedores só têm ansiedade existencial. Agora até chefe ameaça com “vou automatizar seu trabalho com IA e acabar com seu cargo”. Outras profissões não são tão hostis aos próprios interesses, e eu mesmo me pergunto por que só nesta área isso acontece
Acho que “coder” e engenheiro de software são coisas diferentes. Só porque alguém terminou um bootcamp e consegue fazer um programa simples em Python não significa que seja engenheiro de software. Quando digo que tenho diploma, já ouvi que isso seria elitismo e que o que se aprende em ciência da computação não serve para o trabalho real. Mas também existem claramente casos de gente que, sem diploma, cresceu por conta própria e virou excelente engenheiro. Ainda assim, concordo que precisamos de algum tipo de padrão. Se um bootcamper entra numa startup unicórnio cheia de buzzwords, ótimo, parabéns para ele; mas sistemas sensíveis como o Therac-25 devem mesmo ficar nas mãos de gente formalmente treinada
Chefe dizendo “se você não automatizar, seu trabalho vai desaparecer”? Mas esse é justamente o nosso trabalho. Automatizar trabalho é a essência do que fazemos, e nós somos a categoria com mais oportunidade e entendimento para automatizar o próprio ambiente de trabalho
Acho que a docência tem algo em comum com ser desenvolvedor. Há professores excelentes, professores péssimos e muitos no meio do caminho. Saber a matéria não significa saber ensinar. Talvez o desenvolvedor seja um professor de máquinas. Há quem ensine um personagem de Munch, letra por letra, pensamento por pensamento, e há quem ensine pela atmosfera geral
Deixando os LLMs um pouco de lado, às vezes eu escrevo código do qual realmente me orgulho. A estrutura, cada linha, tudo foi decidido por um motivo; é um código sobre o qual sou especialista e que domino completamente. Mas a maior parte do código eu não escrevo nesse nível de perfeição. Na maior parte das vezes é mais um “só preciso terminar a tarefa”, então permito a mim mesmo um padrão um pouco mais baixo. Ainda assim, quando de vez em quando consigo entrar no fluxo e terminar algo de forma realmente caprichada, é muito recompensador e está entre as melhores experiências que já tive programando. Pensando nos LLMs, paradoxalmente ficou tanto mais fácil quanto mais difícil programar com alto nível de acabamento. Psicologicamente, quando consigo entrar num estado profundo de concentração, uso bem os LLMs e produzo resultados mais rápidos e com padrão mais alto. Consigo escrever código muito melhor do que o código escrito por LLM, mas, com a ajuda deles, também consigo escrever código ainda melhor. O problema é que está ficando cada vez mais difícil manter esse estado. Você dá uma olhada superficial no código gerado pelo LLM, ele parece bonito e funciona, e então simplesmente deixa passar. Mas esse código deixado passar sem rigor vai se deteriorando aos poucos e, quando você percebe, já é tarde. No fim, você não vira especialista naquele código e só vai acumulando código malfeito
Gostei muito de ler esse ensaio porque bateu exatamente com o que eu penso. Tentei usar IA no trabalho, mas na maioria dos casos o resultado foi ruim e no fim tive de reescrever quase tudo eu mesmo. Tenho convicção de que entregar à IA tempo de raciocínio ou resolução de problemas de forma desnecessária é uma das piores escolhas possíveis para a minha carreira. IA não passa de um gerador de texto de qualidade mediana
Sobre a pergunta “afinal, por que essas pessoas decidiram virar programadoras, se nem parecem interessadas em código?”, eu enfatizaria que “resolver problemas é o objetivo”. Programar é o meio, não o fim em si. “Mexer em configuração de editor, dotfiles e ambiente de desenvolvimento” pode até ser divertido, mas eu vejo isso como complexidade desnecessária e delegaria sem problema
Configurar editor, dotfiles e ambiente de desenvolvimento por conta própria no fim ajuda a criar familiaridade com o ambiente de trabalho, desenvolver habilidade com ferramentas e montar um ambiente mais produtivo. O fato de você virar “a pessoa que chamam” quando precisam mexer em scripts de build vem justamente dessa manutenção. Tem gente que usa Git há dez ou vinte anos e ainda não entende conflito de merge nem o básico de uso, e aí todo trabalho chato acaba caindo sobre quem realmente aprendeu as ferramentas direito
Esse tipo de argumento de “isso não tem valor” pode, se levado até o fim da lógica, acabar virando “que valor a própria existência tem?”
O objetivo de quase toda profissão no mundo é resolver problemas, então fico me perguntando por que, entre tantas carreiras, essas pessoas escolheram justamente software
Concordo 100% com a ideia de que “resolver problemas é o objetivo, e programar é só o meio”. Quem fica triste porque a IA passou a programar no seu lugar é mais o tipo “artista do código”, alguém mais apegado à “forma” do que está sendo criado. Eu foco no problema em si, então não ligo nem um pouco se a IA programar no meu lugar
Tanto a ideia de que “programar não é o objetivo, é o meio” quanto a de que “mexer no editor pode ser divertido, mas não tem valor” são extremamente subjetivas. Há pessoas que gostam genuinamente de programar por si só, mesmo se a resolução de problemas desaparecesse, e muita gente continuaria gostando de programar mesmo se não existisse nenhum problema no mundo
Achei este texto muito interessante. Ele coincide quase totalmente com o que sinto em relação à programação com LLM. Eu era simplesmente alguém que gostava de programar e também gostava disso como profissão. Mas hoje sinto falta de poder levar para o trabalho esse hobby de que eu gostava. Virou uma atividade completamente diferente
Já tenho certa idade. Por volta de 1995, eu programava num ambiente totalmente diferente do atual. Naquela época, o engenheiro conhecia o cliente-alvo, a stack, as tendências do setor, e realmente tinha o controle. Seu código era seu playground; você refatorava tudo do jeito que quisesse e definia até o estilo de indentação e chaves por conta própria (se quebrasse, você mesmo consertava). Não existiam testes unitários como hoje (na época era mais validação de parâmetros), e quase não havia code review formal; a cultura era conversar com colegas no escritório e rabiscar no quadro branco. Se havia bug, corrigia na hora. No fim, a gestão venceu, e agora acho difícil que aquela era do “cowboy coding” volte um dia. Dá para sentir saudade da Apple dos anos 90, mas não dá mais para voltar para aquilo. Foi muito divertido
Também comecei por essa época, mas por causa da ISO 9001 fazíamos code reviews periódicos. Imprimíamos os artefatos, três pessoas se reuniam numa sala, conferiam cada linha e assinavam. Isso era usado em um RTOS de controle industrial. A gestão do projeto era feita com um gráfico de Gantt de 40 pés impresso e colado na parede. Era a era waterfall total
Eu comecei no fim dos anos 2000, e naquela época o plano de carreira e as fronteiras entre especialidades eram bem mais claros. Sysadmin e desenvolvedor eram funções claramente separadas, mas hoje esperam que eu também faça o papel de operador de sistemas, então o escopo do trabalho aumentou. Eu desenvolvi habilidades de sistemas mais como hobby e, quando de fato precisei assumir isso no trabalho, fiquei com vontade de ignorar tudo porque a documentação e os treinamentos dos fornecedores eram péssimos no mundo real
Talvez o setor como um todo não volte ao cowboy coding, mas acho que esse estilo ainda sobrevive em alguns ambientes. No WhatsApp, entre 2011 e 2019, o ambiente era bem livre. Vai depender do contexto, dos custos de pegar erro antes e de pegar erro em produção. Eu pessoalmente prefiro uma abordagem que reduza o custo de corrigir erros. Claro, ainda assim tento não cometer erros vergonhosos e faço os testes realmente necessários
Hoje em dia entraram gente demais com mentalidade de negócio, vibe coders e script kiddies, e isso estragou tudo
O problema do cowboy coding é que um único membro não confiável pode arruinar o time inteiro. Quanto maior a organização, mais inevitável é que o número de membros problemáticos aumente, e, para impedir que isso exploda, são necessários mecanismos cada vez maiores. Em times pequenos e de elite, baseados em confiança, cowboy coding é o auge da eficiência, mas como é difícil avaliar bem a habilidade dos candidatos na contratação, isso não funciona de jeito nenhum em organizações grandes. No futuro, talvez isso continue existindo só em empresas pequenas ou em equipes pequenas dentro de empresas grandes
Tenho dificuldade de concordar com a frase do autor: "<i>LLMs são uma solução tipo arma nuclear final apontada para a complexidade do software. Em vez de resolver o problema real, tentam aliviar os sintomas trazendo uma complexidade ainda maior</i>". O objetivo central da adoção de IA é centralizar “talento criativo caro e altamente qualificado” em um número mínimo de empresas que projetam IA, e fazer com que todas as outras empresas demitam trabalhadores criativos e mantenham apenas mão de obra simples. Ou seja, o objetivo é simplificar com IA toda a complexidade de qualquer negócio. Pensando em O Mágico de Oz, ninguém quer olhar atrás da cortina; todo mundo só quer que o próprio trabalho fique mais fácil. É um fenômeno gerado por ignorar completamente os riscos de longo prazo e correr atrás apenas do ganho de curto prazo
Gostei muito deste texto. Também concordo com parte das opiniões de que resolver problemas importa mais do que código. Mas, na minha visão, se começarmos a entregar até problemas que exigem raciocínio profundo para a IA, essa própria capacidade de resolução profunda pode atrofiar com o tempo. Simplesmente dizer “faça alguma coisa” não é, para mim, resolver problema de verdade