O Ocidente esqueceu como fabricar coisas — e agora está esquecendo o código

• O colapso da capacidade de produção de defesa mostra que, quando a mão de obra especializada se aposenta e o conhecimento de processo desaparece, não é possível reativar rapidamente a produção mesmo quando surge demanda em tempos de guerra
• Os casos da restauração do Stinger, dos projéteis de 155 mm e do Fogbank mostram que a otimização de custos e os pontos únicos de falha aumentaram a eficiência em tempos de paz, mas enfraqueceram drasticamente a folga da cadeia de suprimentos e a velocidade de recuperação
• O software também está seguindo um caminho em que depende de substitutos mais baratos e enfraquece o pipeline de talentos, e após a adoção de IA vêm crescendo ao mesmo tempo a redução na contratação de juniores e o review bottleneck
• Competência não pode ser criada rapidamente só com dinheiro, e tanto na defesa quanto no software o acúmulo de conhecimento e habilidade exige anos de experiência prática e capacidade de revisão
• Se os juniores não passarem por erros formativos e depuração, o conhecimento tácito não se acumula, aumentando o risco de faltar no futuro engenheiros senior e institutional knowledge

---

O paralelo entre o colapso da capacidade de produção de defesa e a redução da força de trabalho em software

• A Raytheon precisou chamar de volta engenheiros na casa dos 70 anos para reiniciar a produção do Stinger, restaurando o processo com base em desenhos antigos em papel e equipamentos de teste guardados em depósitos
• Depois de o Pentágono passar 20 anos sem comprar novos Stinger, a guerra na Ucrânia fez a demanda disparar, mas a linha de produção estava fechada, componentes eletrônicos e o seeker haviam saído de linha, e os pedidos feitos em maio de 2022 só estavam previstos para entrega em 2026
• Em apenas 10 meses de guerra, a demanda foi tão alta que consumiu o equivalente a 13 anos de produção de Stinger, e o conhecimento de produção já perdido junto com a lacuna de mão de obra virou gargalo
• Não era apenas um problema de orçamento: o principal obstáculo era a estrutura em que a mão de obra especializada aposentada saiu e não foi substituída por uma nova geração

A fragilidade da cadeia de suprimentos exposta pelo fracasso em aumentar a produção de munição

• A promessa de 1 milhão de projéteis e a capacidade real de produção

  • Em março de 2023, a UE prometeu fornecer 1 milhão de projéteis de artilharia à Ucrânia em 12 meses, mas a capacidade anual de produção da Europa era de cerca de 230 mil, enquanto a Ucrânia consumia entre 5 mil e 7 mil por dia
  • Até o prazo final, a Europa entregou apenas cerca de metade, e uma investigação de 11 veículos em 9 países estimou a capacidade real de produção em aproximadamente um terço do número oficialmente alegado pela UE
  • O marco de 1 milhão de projéteis foi adiado para dezembro de 2024, 9 meses depois da promessa original

• Uma estrutura em que vários gargalos se sobrepõem ao mesmo tempo

  • A França interrompeu sua produção doméstica de propelente em 2007 e ficou 17 anos sem produzi-lo
  • O principal produtor europeu de TNT era apenas um, na Polônia, e o estoque de munição da Alemanha cobria apenas dois dias
  • A fábrica da Nammo na Dinamarca foi fechada em 2020 e teve de ser reiniciada do zero
  • A indústria de defesa europeia era otimizada para produtos personalizados caros em pequenos volumes e não foi desenhada com produção em massa e resposta a crises como premissas

• Os EUA têm fraquezas parecidas

  • Os EUA também dependiam de uma única fábrica em Scranton, de uma única instalação de enchimento de explosivos em Iowa, e estavam sem produção doméstica de TNT desde 1986
  • Mesmo após investir bilhões de dólares, a produção continuou abaixo de metade da meta

Pontos únicos de falha criados pela otimização de custos

• Em 1993, o Pentágono passou aos CEOs do setor de defesa a mensagem de que quem não se consolidasse seria eliminado, e depois disso 51 grandes empresas do setor encolheram para 5
• Os fornecedores de mísseis táticos caíram de 13 para 3, os estaleiros de 8 para 2, e a força de trabalho caiu 65%, de 3,2 milhões para 1,1 milhão de pessoas
• Surgiram single points of failure em toda a cadeia de suprimentos de munição, e a fabricação dos corpos dos projéteis de 155 mm ficou concentrada em uma única empresa em Coachella, Califórnia
• As cargas propelentes também dependiam de uma única instalação no Canadá, e a otimização orientada ao menor custo aumentou a eficiência em tempos de paz, mas quase não deixou margem para picos de demanda

Quando o conhecimento desaparece, a recuperação também fica mais lenta

• O fracasso na restauração do Fogbank

  • Fogbank é um material sigiloso usado em ogivas nucleares, produzido de 1975 a 1989 antes do fechamento da instalação
  • Em 2000, tentou-se produzi-lo novamente para um programa de extensão de vida útil, mas a maior parte das pessoas com especialização no processo já havia se aposentado, morrido ou deixado a organização, e quase não restavam registros
  • Segundo informações relacionadas da GAO, só foi possível recuperar um Fogbank novamente produzível após mais US$ 69 milhões e vários anos de engenharia reversa

• O conhecimento tácito que não estava na documentação era decisivo

  • O novo Fogbank produzido tinha pureza alta demais, e só depois se descobriu que uma impureza não intencional presente nos lotes originais era importante para seu funcionamento real
  • Essa informação não estava em documento algum; apenas os trabalhadores responsáveis pela produção original sabiam disso, e eles já estavam aposentados
  • A razão de não conseguirem recriar nem mesmo um material que haviam criado antes era que o conhecimento havia permanecido apenas nas pessoas

O software também está seguindo o mesmo caminho

• Substitutos mais baratos e mais rápidos enfraquecem o pipeline de talentos

  • O padrão de trocar capacidades construídas ao longo de décadas por substitutos mais baratos, enfraquecer o pipeline humano e depois precisar de novo dessa capacidade numa crise se repete tanto na defesa quanto no software
  • Se na defesa esse substituto foi o peace dividend, no software a IA ocupa esse mesmo lugar
  • O já visível colapso do pipeline de talentos e a crise de compreensão já vinham aparecendo, e o caso da defesa também mostra quanto tempo a reconstrução leva

• Reconstruir exige tempo, mais do que dinheiro

  • Grandes expansões de produção no setor de defesa levaram de 3 a 5 anos para sistemas simples e de 5 a 10 anos para sistemas complexos
  • No Stinger, o prazo mínimo do pedido à entrega era de 30 meses; no Javelin, foram necessários quatro anos e meio para elevar a produção a menos que o dobro; e os projéteis de 155 mm seguem abaixo da meta após quatro anos e US$ 5 bilhões investidos
  • A França também levou 17 anos para retomar a produção de propelente, e a limitação estava menos no financiamento do que em conhecimento e habilidade
  • Um estudo da RAND estimou que 10% das habilidades de projeto de submarinos ainda exigem 10 anos de experiência prática após o PhD, e também nos ofícios especializados da defesa eram necessários de 2 a 4 anos de aprendizado e de 5 a 8 anos até a capacidade de supervisão

• A curva de crescimento em software também não se comprime

  • Um desenvolvedor júnior leva de 3 a 5 anos para se tornar um mid-level estável, de 5 a 8 anos até senior, e mais de 10 anos para chegar a principal ou architect
  • Esse tempo não diminui só por gastar mais dinheiro, e também parece difícil de comprimir com IA

Gargalos e enfraquecimento de habilidades após a adoção de IA

• O gargalo de revisão cresce mais do que a velocidade de produção

  • Em um experimento randomizado controlado da METR, desenvolvedores experientes levaram 19% mais tempo em tarefas reais de open source ao usar ferramentas de coding com IA
  • Antes de começar, esperava-se que a IA os tornasse 24% mais rápidos, mas a diferença entre a expectativa e o resultado real foi de 43 pontos percentuais
  • Em um experimento posterior, também não foi pequena a parcela de desenvolvedores que disse que não participaria se tivesse de trabalhar sem IA, e já não parece fácil sequer imaginar a volta ao trabalho sem IA

• Redução nas contratações e queda nas matrículas universitárias

  • A Salesforce disse que não fará novas contratações adicionais de engenheiros de software em 2025
  • Em uma pesquisa da LeadDev, 54% dos líderes de engenharia disseram acreditar que AI copilots reduzirão as contratações de juniores no longo prazo
  • Em uma pesquisa da CRA, 62% dos departamentos universitários de computação relataram queda nas matrículas neste ano

• O code review se desloca para o centro da restrição

  • A IA gera código rapidamente, mas a revisão humana avança devagar, criando um review bottleneck
  • Em resposta, em vez de deixar IA revisar código gerado por IA, passou-se a exigir nos templates de pull request a inclusão obrigatória de mudanças feitas, motivo das mudanças, tipo de mudança e screenshots de antes e depois
  • Também se usa a adição de revisores dedicados por projeto para ampliar o número de olhos procurando o que o modelo deixou passar

As capacidades que vão faltar no futuro

• O ambiente mudou para algo em que técnica sozinha não basta

  • Agora já não basta apenas especialização técnica; também são necessários julgamento e liderança para assumir responsabilidade, explicar trade-offs e rejeitar sugestões erradas apresentadas com confiança pela máquina
  • Em uma contratação recente, 2.069 de 2.253 candidatos foram rejeitados e apenas 4 contratados, para uma taxa de conversão de 0,18%
  • Isso expõe a realidade de que quase não há no mercado pessoas que, além de habilidade técnica, tenham discernimento para identificar erros da IA

• Documentação sozinha não encerra a transferência de conhecimento

  • Está sendo feita documentação ampla, incluindo Site Books, SDDs, relatórios RVS e até módulos boilerplate com cobertura completa
  • Hoje isso funciona porque quem lê essa documentação ainda tem especialização em engenharia, mas não está claro se o mesmo modelo continuará funcionando quando essa especialização desaparecer
  • Não dá para prever o desempenho dos modelos em 2031, e tampouco é certo que a IA ficará boa o bastante para causar menos problemas

• Crises não avisam, e seniors não são criados instantaneamente

  • Assim como ninguém esperava uma guerra total na Europa em 2022, crises não chegam seguindo cronogramas
  • Em 5 a 10 anos, será preciso contar com engenheiros senior capazes de entender o sistema inteiro, depurar falhas distribuídas às 2 da manhã e carregar também o institutional knowledge que está fora do codebase
  • Só que esse tipo de profissional não está sendo formado agora, e os juniores que deveriam aprender ou não estão sendo contratados ou estão acumulando a AI-mediated competence estimulada por pesquisas financiadas pelo DoD
  • Pode sobrar a capacidade de escrever prompts para IA, mas não crescer a capacidade de apontar onde a IA erra

O risco de o código virar o Fogbank

• Se os juniores pularem a depuração e os erros formativos, o conhecimento tácito não se acumulará, e quando a geração atual de engenheiros se aposentar esse conhecimento não será transferido para a IA
• Como resultado, o conhecimento pode simplesmente desaparecer, em uma estrutura muito parecida com o que aconteceu com o Fogbank
• A guerra na Ucrânia foi o momento em que o fracasso da otimização na defesa voltou como custo real, e Stinger, Javelin, Fogbank e o milhão de projéteis que não puderam ser produzidos mostram esse preço
• A engenharia de software também está apostando na mesma otimização, e se a IA ficar boa o bastante essa aposta pode dar certo — mas, se não ficar, a mesma conta pode voltar

[GN⁺]

Comentários do Hacker News

• O verdadeiro problema não é a IA em si
  O problema é um modelo de gestão que elimina a folga de pessoas e organizações porque isso não gera lucro imediato, e ao mesmo tempo acredita que esse conhecimento ainda vai estar lá quando for necessário no futuro
  O corte de custos de curto prazo reduz contratações júnior e também tira dos engenheiros experientes o tempo para ensinar, interrompendo a transferência de conhecimento tácito
  No fim, só restam documentação e automação, mas documentação não é experiência de campo e automação não substitui julgamento
  Quando saem as pessoas que realmente já operaram o sistema, o conhecimento tácito desaparece da organização e a produtividade acaba caindo também
  Agora a IA está sendo vendida no mesmo padrão, e em muitas áreas o que parece estar sendo buscado é menos ganho de produtividade e mais redução de pessoal
  É uma forma de pensar parecida com a da GE, que esvaziou capacidades de longo prazo ao se obcecar com resultado trimestral e retorno para acionistas
  Tomadores de decisão muito distantes da engenharia real acreditam que ferramentas, processos e documentação podem substituir conhecimento tácito, mas isso não é verdade
  Se você elimina as pessoas e o pipeline de aprendizado, esse conhecimento não permanece na organização — ele desaparece

  • Depois que os bean-counters dominaram o ecossistema, só otimizaram a rentabilidade imediata, e por isso acham que toda parte do sistema tem de operar sempre a 100% de utilização
    Não sobra nenhuma margem para experimentar, consertar ou absorver choques, e eu diria que 90% dos sistemas quebrados hoje estão assim porque não têm slack para aguentar impactos de curto prazo
  • Tem uma parte que muita gente deixa passar
    Projetos de startup precisam continuar construindo coisas desde o começo, então adicionar funcionalidades vira valor quase por definição, mas empresas como Visa, Salesforce e LinkedIn muitas vezes já têm produto, funcionalidades e recursos suficientes
    Essas empresas acabam frequentemente tentando forçar pregos para caber no martelo do write more software
    Mesmo que pareça haver muito wishlist e muitos sistemas de teste A/B, se realmente existissem oportunidades claras de ganhar mais dinheiro só construindo mais software, provavelmente isso já teria sido feito
    O crescimento real e a nova demanda surgem mais fora desses lugares, e empresas que não conseguem construir ou comprar software podem acabar capturando essas oportunidades
    E o ponto central é a fungibility
    Capital humano não é uma mercadoria fácil de reempacotar; é algo vivo, e pipelines de talento e habilidade podem simplesmente desaparecer se forem interrompidos
    O risco da programação com IA também está nisso: ela só puxa o capital humano já existente, mas não cria novo capital humano para o futuro
  • Não tenho total certeza dessa parte
    Uma boa parte do conhecimento dos sistemas pelos quais sou responsável até pode ser documentada, e em teoria uma pessoa nova poderia assumir só com essa documentação
    O problema é que a quantidade de documentação necessária seria absurda
    Mesmo para um sistema pequeno, acho realista falar em dezenas de milhares de páginas A4 densas
    O novo responsável precisaria entender quase tudo aquilo como se tivesse decorado o material inteiro, e a empresa não quer gastar nem com o custo de produzir essa documentação nem com o custo de aprendizado de quem entra
    Pela minha experiência, é por isso que isso não funciona — não porque seja absolutamente impossível em princípio
  • Parece uma mudança mais profunda e mais ampla
    Estamos aos poucos removendo os motivos para conversar com outras pessoas
    No momento em que você pergunta algo para uma IA, uma interação humana que teria acontecido com um colega deixa de existir
    Isso não é só um problema da programação; faz pensar em que tipos de interação social o ChatGPT no bolso passa a substituir
    O ser humano é essencialmente social, mas estamos continuamente otimizando a socialização para eliminá-la o máximo possível
    Eu mesmo não estou livre disso, já que hoje prefiro muito mais Doordash do que telefonar para um restaurante como fazia antes
  • Isso parece um sinal de que os sistemas de governo ocidentais estão quebrados
    Num mundo ideal, empresas deveriam otimizar lucro de curto e médio prazo, governos deveriam otimizar o interesse de longo prazo, e indivíduos deveriam otimizar a vida inteira
    Se as empresas reduzem slack e espremem tudo ao máximo, o governo deveria preservar essa margem e o fluxo de talentos por meio de regulação, protegendo a capacidade nacional
    Mas no Ocidente parece que grupos de lobby e MBAs controlam as empresas e ainda arrastam os governos na direção de otimizar só o dinheiro

• Eu programo todos os dias sem assistente de código porque acredito que só assim não esqueço a sensação manual das coisas, inclusive os detalhes pequenos
  A principal razão para não usar IA é que, quando estou diante da tela, se possível eu não quero depender de nada
  Claro, com exceção de documentação, livros e coisas como Stack Overflow
  Vejo com frequência pessoas ao meu redor se apoiando em IA até para tarefas banais do dia a dia, e isso me assusta bastante porque significa uma redução extrema do esforço de pensar
  Entregar esse esforço mental não é pouca coisa
  Para mim, a partir do momento em que cedo isso, viro uma espécie de zumbi dependente, e acredito que conhecimento vem em grande parte do ciclo quase diário de tentativa e erro
  A tecnologia sempre mostrou que consegue empurrar e dirigir as pessoas, e a dependência de IA parece a forma final de empresas invadirem até a capacidade humana mais delicada: pensar e ter curiosidade

  • Depois de passar cerca de um mês fazendo bastante programação assistida por IA, tentei voltar por alguns dias ao meu jeito antigo de programar
    Passei a maior parte do tempo em confusão e frustração, e só terminei a tarefa depois de quase 7 horas brigando com o problema
    Mas a própria dificuldade foi tão chocante que cheguei a me perguntar se meu cérebro tinha apodrecido um pouco por falta de uso
    Depois lembrei que sempre tinha sido assim quando eu enfrentava problemas novos
    A sensação de encarar algo inédito já era naturalmente difícil nesse nível; eu é que tinha deixado de estar acostumado com isso
    Quando você se acostuma com a dificuldade, ela parece normal; quando se acostuma com a ausência de dificuldade, reencontrá-la parece esmagador e estranho
    Por isso acho que a capacidade de suportar desconforto e dificuldade é um músculo que precisa ser preservado
  • Eu já esquecia sintaxe com frequência mesmo antes da IA, por causa do autocompletar da IDE
    Isso só virou problema real quando mudei de emprego e tive de escrever código de entrevista numa plataforma sem checagem de sintaxe nem autocompletar, então pratiquei antes nesse tipo de ambiente
    No trabalho, depender de autocompletar de sintaxe nunca foi um grande problema; o importante era entender os conceitos centrais da linguagem e o runtime
    Por exemplo, era mais importante entender como funciona o event loop do Node.js e como escrever programas assíncronos e orientados a eventos
  • Eu sou completamente o oposto
    Dá para dizer que, nos últimos 6 meses, quase não houve código que eu tenha colocado em produção e do qual eu tenha lido sequer uma linha diretamente
    E, mesmo assim, trabalhar desse jeito é muito mais cansativo
    Quando eu codificava na mão, o processo de resolver problemas era como um quebra-cabeça, e ao final havia um loop de satisfação e uma recompensa de dopamina
    Agora passo a maior parte do dia me sentindo menos um resolvedor de quebra-cabeças e mais alguém de QA, e isso é extremamente desgastante
    Mesmo que a IA resolva os problemas difíceis por mim, a satisfação da slot machine de LLM é muito menor do que quando eu mesmo resolvia
  • Hoje em dia já não tenho o mesmo tempo nem a mesma paciência de antes, então uso IA 3 dias por semana
    Nos outros dois dias não uso assistente de código e só peço revisão depois de terminar o trabalho
    Acho que esse método ajuda tanto a preservar a saúde mental quanto a manter meu nível técnico afiado
  • Eu sempre fui do tipo que, se fico um pouco afastado de uma linguagem, perco a fluidez e a destreza mais rápido do que a maioria
    Mesmo em linguagens em que eu era bastante bom, a parte mecânica fica nebulosa muito rápido
    Por isso, trabalhar com apoio de LLM me parece algo como jogar água sanitária no meu cérebro
    Eu mesmo consigo sentir que, quanto mais eu usar, pior vai ser para mim
    Minha capacidade de estruturar o que preciso e resolver problemas continua boa, mas os nuts and bolts evaporam rapidamente

• A frase "o dinheiro não era a restrição; o conhecimento era a restrição" soa irônica
  Isso porque o próprio texto é difícil de ler por ter um estilo muito parecido com algo escrito por IA
  O fluxo é artificial, truncado, e cheio de vícios típicos de LLM
  Escrever também é uma habilidade que acaba atrofiando
  Até entendo usar IA por fluência linguística, mas ainda acho tradução por IA melhor do que texto gerado
  Se a pessoa nem se importa o suficiente para escrever por conta própria, também não vejo muito motivo para eu ler

  • É curioso que todo mundo seja bastante tolerante com geração de código end-to-end ou dark factory, mas quando um LLM escreve um texto aparece uma rejeição imediata
    Para mim, código e prosa não são tão diferentes em essência
    Ambos são compostos de palavras-chave, gramática, sintaxe e combinações significativas
    Se frases geradas por IA não têm sentido ou são difíceis de ler, pela mesma lógica código gerado por IA também deveria ser difícil de ler e pouco confiável
    Queria que esse duplo padrão parasse um pouco
  • Para mim não pareceu nem um pouco um texto escrito por IA
    Na verdade, achei bem melhor do que a verborragia de IA que no HN muita gente deixa passar como se fosse boa
  • LLMs aprendem gramática e estilo a partir do que seres humanos realmente escreveram
    Então algumas características que as pessoas sentem como típicas de LLM talvez sejam, na verdade, estilos humanos anteriores que agora voltam a ser repetidos por mãos humanas
  • Você diz que é claramente gerado por IA, e eu fico curioso em saber como distingue isso
  • Não sei se é realmente tão óbvio assim
    Vejo todo dia vários textos feitos por IA no topo dos resultados de busca e passo direto por eles, mas este aqui me pareceu bem diferente desse tipo de material

• Tenho dificuldade de acreditar que empresas consigam medir direito o nível de carreira de um desenvolvedor
  Divisões como junior, mid, senior e lead são mais aparência do que realidade; na prática, isso é um contínuo em vários eixos e facilmente distorcido por tecnologias da moda
  Tecnicamente, acho possível virar um desenvolvedor de nível senior mesmo sem ser contratado por empresa alguma
  No fim, o essencial é a disposição de aprender e construir por conta própria, e o tempo investido nisso
  O que as empresas parecem realmente querer hoje não é tanto habilidade de desenvolvimento, mas experiência em contornar de algum jeito estruturas organizacionais quebradas e esquemas ruins de comunicação e orçamento
  Não sei se isso significa ser senior ou só ser bom de política
  Esse padrão fica especialmente visível quando o software falha e a ilusão se desfaz

  • Acho que há dois grandes tipos de desenvolvedor
    Um tipo recebe um problema e aprende sozinho o que for necessário, investiga o que não sabe, entrega resultados relevantes repetidamente, se comunica com as pessoas certas, compartilha o andamento, ajuda e recebe ajuda da equipe, e ainda preenche por iniciativa própria o que estiver faltando
    O resto é só o resto
    Em geral, dá para perceber nos primeiros anos de carreira em qual dos dois grupos alguém está, e é quase impossível transformar o segundo tipo no primeiro
    Por isso, até alguém com 30 anos de carreira e título de senior pode ser do segundo tipo, enquanto alguém recém-formado pode ser do primeiro
    Claro, também existe gente que é excelente em política, relações interpessoais ou pose, e aos olhos da gestão parece do primeiro tipo quando na prática é do segundo
    Mas aí já não estamos mais falando de capacidade de construir software
    Também acontece de pessoas do primeiro tipo serem subvalorizadas ou não receberem promoção, e a correlação com sucesso real de carreira não é tão grande assim
  • Fora de organizações grandes o bastante, o termo seniority para desenvolvedores dificilmente tem um significado realmente prático
    Você pode se dar qualquer rótulo, mas é meio estranho
    Freelancers são avaliados por portfólio, pesquisadores de ciência da computação por artigos, e contribuidores de OSS pelo volume e impacto das contribuições
    Em todos os casos, no fim das contas isso é proporcional ao esforço investido em aprender e construir
    Ainda assim, independentemente de vínculo empregatício, especialização não é definida só por aquilo que se pode aprender em livros
    Gestão de stakeholders e apresentação de soluções não são coisas que se dominam só lendo; exigem prática real e feedback
    Um engenheiro senior não é só alguém que escreve bem código, mas alguém que consegue contribuir por conta própria e ajudar outros ao longo de todo o SDLC, e esse tipo de capacidade provavelmente se desenvolve muito mais facilmente em ambiente profissional do que em projetos amadores
  • No fim, enquanto você trabalha em sociedade, a capacidade de gerar influência se conecta à senioridade
    Isso normalmente exige habilidades sociais e organizacionais, e o mundo funciona assim, gostemos ou não
  • Isso me parece deprimente, mas bastante verdadeiro
    Ao mesmo tempo, eu queria não saber dessas coisas, na medida do possível
    Não quero desmontar minha mente para me adaptar a quem quer que seja, e trabalhar em problemas desse tipo é sofrimento puro
  • Acho que se tornar senior developer sem nunca ter sido empregado de fato é algo extremamente raro na prática
    É parecido com perguntar se um cirurgião não empregado conseguiria virar um senior surgeon
    É difícil se tornar senior sem passar alguns anos fazendo isso de verdade como profissão, porque nessa área experiência é quase tudo
    Livros não bastam para incorporar o entendimento necessário, e seres humanos não internalizam o suficiente só lendo ou assistindo
    É preciso fazer de verdade para haver aprendizado real
    Dá para aprender fatos e técnicas em livros, mas ler sobre restaurantes Michelin não faz de ninguém um Michelin Chef imediatamente

• Geradores de código por IA parecem trolls
  Eles entregam coisas plausíveis com muita confiança, mas parte está errada, e no fim um humano precisa encontrar esses erros
  Isso não é divertido e não tem flow

  • Minha experiência foi exatamente o oposto
    Eu gosto de corrigir erros feitos por outros, e especialmente gosto da sensação de vencer o LLM
    Consegui até me concentrar por mais tempo monitorando obsessivamente o LLM do que em estados tradicionais de imersão
  • Acho que isso deveria ter uma dinâmica parecida com revisão de PR feita por humanos
  • Tudo que a IA faz me parece trollagem
    Não há lógica ali, só repetição de padrões, e eu não entendo por que engenheiros supostamente inteligentes caem nisso

• É um pouco irônico que o próprio texto pareça ter recebido uma ajuda de IA bem evidente
  Não estou criticando o uso de assistência por IA em si, mas, quando isso aparece lado a lado com o tema do texto, dá o que pensar

  • Os clichês que a IA enfia na escrita saltam aos olhos, incomodam bastante e parecem muito artificiais
    As pessoas acham que estão "lapidando" o texto, mas provavelmente ele era melhor de ler antes disso
    Uma coisa que me irrita especialmente hoje é o abuso de frases curtas com ponto no lugar de vírgula
    My people lived the other side of this equation. Not the factory floor. The receiving end.
    Parece uma tentativa de dar peso, mas usam isso até quando não precisa, e no fim fica com cara de fala de trailer de filme de ação
  • Eu também parei depois de alguns parágrafos
    Não é que eu ache eticamente errado usar IA, mas o estilo de LLM me incomodou demais
    Além disso, como as pessoas usam isso para inflar textos com volume e filler desnecessários, agora é preciso atravessar páginas e mais páginas desse tipo de material
    O pior é que não existe um jeito fácil de saber se um texto ao menos traz algum insight novo de um ser humano ou se foi tudo gerado a partir de um prompt do tipo write me something about X
    No estado atual, não é absurdo dizer que, se for o segundo caso, quase não vale a pena ler
  • Eu também não tenho problema com assistência por IA em si, mas neste caso isso enfraquece por conta própria a tese central do texto
    Para mim, é como um padre que condenava a homossexualidade ser pego na cama com um garoto de programa
    Se houve cocaína ou não é opcional, mas de qualquer forma fica um gosto amargo
  • Fico curioso para saber em que você baseia esse julgamento
    Este texto não tem muitos daqueles sinais óbvios de IA que as pessoas costumam citar, e o que eu vejo como possível traço de LLM é só a estrutura de frases curtas e assertivas
    Mas esse estilo também foi um modo de escrita bastante respeitado no inglês desde Hemingway

• Tenho a impressão de que antes da IA a alternativa mais barata era contratar equipes remotas terceirizadas do Leste Europeu, não?

  • Não sei por que isso teria sido o plano
    Para começar, nem gente suficiente existe
    E mesmo aqui a leste do meridiano 15°E, no fim todo mundo foi demitido do mesmo jeito
    O plano real parece ter sido mais algo como simplesmente fazer menos em geral, a menos que tivesse relação com IA, e todo mundo ficou só esperando para ver quem começaria as demissões primeiro
    Eu trabalhei em regime de meio período por 6 meses, e os tomadores de decisão disseram claramente que, no longo prazo, isso era melhor
    Era melhor do que ser demitido, mas não dava para sustentar esse tipo de vida por muito tempo
    Sou econômico, mas não a esse ponto
  • Era algo como oferecer ajuda de bom grado e, no fim, até substituir você
  • Mão de obra barata no exterior continua sendo extremamente comum em todas as grandes empresas de tecnologia
    Eles realmente não querem gastar dinheiro, e menos ainda com americanos e plano de saúde
    Parece estranho que empresas americanas estejam numa trajetória tão acelerada de empurrar americanos para fora do mercado de trabalho sem quase nenhuma reação
  • Na maioria dos casos era India
  • Na prática, o centro da história sempre foi indianos com H1B e outsourcing para a Índia
    Como europeu, eu certamente vi desenvolvedores do Leste Europeu também, mas eles não estavam em todas as empresas em que trabalhei
    Já profissionais da Índia sempre estavam lá
    Em termos de qualidade, a conversa de sempre continuava sendo a mesma; não vou entrar em detalhes, mas quem estiver disposto a aceitar já sabe o que estou querendo dizer

• Quando olho da aula de Formal verification in software que ouvi pela primeira vez no fim dos anos 80 até a disciplina de Programming in Java que eu deixei com calouros no começo dos anos 2000 antes de sair, sinto que o rigor acadêmico despencou de um penhasco e foi substituído por alinhamento ao mercado de trabalho
  Antes o ensino era mais sobre como pensar; depois virou mais sobre como conseguir um emprego que paga bem

  • Exato
    Porque as empresas deixaram de querer treinar funcionários novos
    Como salário de trainee e custo de quem ensina custam dinheiro, elas empurraram esse custo para universidades, estudantes e governo por meio de exigências de diploma
    É curioso que pedir ao funcionário que pague diretamente pelo treinamento como condição de emprego cheire a golpe, mas o sistema de fábrica de diplomas passe tão facilmente

• Seres humanos não são perfeitos
  Quando fui para a Ucrânia poucos dias antes da invasão russa, viajar e se hospedar em Kyiv era muito barato, e quando eu perguntava aos locais sobre a possibilidade de invasão todos diziam isso não vai acontecer
  A reação era que a Rússia sempre falava agressivamente, mas nunca passava disso
  Não havia preparação suficiente, e o resultado foi perder 20% do território em poucos dias
  Depois de voltar para a Áustria, fiquei com a sensação persistente de que algumas das pessoas que eu conheci talvez tivessem morrido
  Depois disso, também como empreendedor e engenheiro em Dubai e na Arábia Saudita, eu perguntava o que fariam se drones atacassem a infraestrutura, porque, vendo a guerra da Rússia e o primeiro ataque do Irã, esse tipo de ataque já era claramente previsível
  E de novo ouvi a resposta isso não vai acontecer
  Não se prepararam adequadamente, perderam dezenas de bilhões de dólares, e acho que isso poderia ter sido evitado com algumas centenas de milhões gastas ao longo de alguns anos
  No fim, o problema não é a IA — é o ser humano

  • A Ucrânia vinha se preparando desde 2014
    Se não tivesse se preparado, acho que hoje haveria um porta-voz russo sentado em Kyiv
  • Eu também diria que a Ucrânia estava, na verdade, muito bem preparada
    Ela resistiu às duas primeiras semanas e por isso a guerra virou um conflito longo, além de a guerra no Donbas já durar 8 anos
    Não me parece correto dizer que os ucranianos estavam iludidos achando que o adversário não era a Rússia
  • Por outro lado, o mundo está cheio de líderes que vivem falando de guerra contra um inimigo imaginário e querem gastar bilhões com isso
    Muitas vezes, se você olhar de perto, eles até têm um amigo que precisa ganhar aquele contrato, e vendem o medo de que, se o outro lado invadir, sua família morre imediatamente
  • É fácil posar de inteligente depois que tudo aconteceu
    Você só escolheu dois casos em que alguém disse isso nunca vai acontecer e, no fim, aconteceu
    O que fazemos com os inúmeros casos em que disseram a mesma coisa e realmente nada aconteceu?
    Se eu disser a milhões de pessoas que compram loteria que elas não vão ganhar, estarei certo para quase todas
    O fato de uma pessoa ganhar não torna minha previsão errada; isso pode ser só reporting bias
  • Na prática, houve preparação sim
    Ninguém tinha certeza de que Putin seria tão idiota a esse ponto, mas as forças armadas da Ucrânia estavam muito ocupadas preparando linhas de defesa, estoques e táticas defensivas para o caso de acontecer

• A cada dia sinto que programming as theory building, de Peter Naur, fica mais importante
  Link: https://gwern.net/doc/cs/algorithm/1985-naur.pdf

  • Foi exatamente esse artigo que me veio à cabeça primeiro
    É uma leitura que eu recomendo fortemente