Os LLMs estão corroendo minha carreira em engenharia de software, e eu não sei o que fazer
(human-in-the-loop.bearblog.dev)- Ferramentas de desenvolvimento baseadas em LLM participam da escrita de documentos de design, do planejamento de implementação, da programação e até da depuração, enfraquecendo o diferencial construído ao longo de 10 anos de especialização em backend de pagamentos e finanças
- O conhecimento de domínio em finanças e pagamentos era uma vantagem competitiva baseada em experiência com conformidade PCI, livros-razão de partidas dobradas, escrow, reconciliação, ciclo de vida de pagamentos e idempotência em transferências bancárias, mas o primeiro choque veio quando os modelos passaram a captar as conexões estruturais dos sistemas
- Com Claude Code, Codex, MCP e DataDog MCP, a automação da depuração se expandiu: alguns bugs passaram a ser resolvidos apenas com stack trace e contexto do Sentry, e depois 90% dos bugs em sistemas distribuídos passaram a ser resolvidos de uma vez
- Os pilares restantes, qualidade de código e arquitetura, também estão sendo reduzidos a “taste”, e o mercado caminha para aceitar codebases de nível
CouD, manipuladas por LLMs, em vez de codebases de nívelAouB, agradáveis para leitura humana - Para preservar a empregabilidade no longo prazo, seria preciso mover a especialização para áreas em que os LLMs ainda não sejam facilmente bons, mas a transição para pesquisa é limitada pelo país onde mora, pela concorrência nas vagas, pela situação familiar e pela possibilidade de RSI
Histórico de carreira
- É engenheiro de software profissional há 10 anos; começou no frontend web porque era mais fácil depurar, mas depois migrou para o backend
- Acabou por acaso assumindo funções de desenvolvimento de software em finanças, bookkeeping e processamento de pagamentos, com alta autonomia em relações próximas e francas com Product Managers e stakeholders
- Acumulou conhecimento de domínio em conformidade PCI (PCI compliance), livros-razão de partidas dobradas (double-entry ledgers), escrows, reconciliação (reconciliation), ciclo de vida de pagamentos (payment lifecycles) e idempotência em transferências bancárias (bank transfer idempotency)
- A estratégia de carreira de se tornar especialista de domínio era uma escolha clara para diferenciar a própria especialização em uma área que dava sinais de aumento na demanda por especialistas
O primeiro pilar a começar a ruir: conhecimento específico de domínio
- No ano passado, mudou para uma empresa da área financeira; as empresas anteriores tinham forte componente de pagamentos e finanças, mas não eram centradas exclusivamente em finanças
- A nova empresa abraçou a IA por completo e forneceu contas de ChatGPT e Claude Enterprise já no primeiro dia, incentivando o uso de IA para pesquisa, exploração e programação
- Com a condição de que cada linha de código que fosse para produção precisaria ser revisada pessoalmente e assumida como responsabilidade própria
- O primeiro projeto foi refazer um sistema legado bagunçado de pagamentos online, tarefa assumida por causa de experiências anteriores de implementação
- Os Design Docs escritos antes da programação precisavam ser legíveis tanto para engenheiros quanto para Product Managers, e exigiam mais visão de arquitetura do que análise técnica profunda
- Os primeiros Design Docs foram escritos com ajuda mínima de IA; na época, chamava os LLMs de “stochastic parrots”, visão que hoje já não mantém
- O feedback do gerente era que o código saía em bom ritmo, mas os Design Docs demoravam demais, e era preciso usar mais IA
- Os modelos daquela época não eram tão bons quanto os de hoje, mas já eram eficazes o suficiente para acelerar a escrita e a tomada de decisões
- Foi aí que o conhecimento acumulado por anos sobre trade-offs de implementação, o funcionamento de acquiring e como estruturar idempotência para evitar cobranças duplicadas começou a perder valor
- Os modelos ainda exigiam coordenação, mas já conseguiam captar os elos de como estruturar um sistema, justamente a parte mais difícil, que normalmente só se forma na cabeça após anos de experiência prática
- Como há muitos textos explicativos na web, documentação técnica e posts de blog sobre aplicar ferramentas técnicas a esse domínio, concluiu que os modelos conseguem absorver isso como dados de treinamento
- Restava a esperança de que a área em que humanos continuariam se destacando seria a depuração, e a experiência com race conditions em produção e depuração de sistemas distribuídos era a base da empregabilidade no longo prazo
O segundo pilar a começar a ruir: depuração e sistemas distribuídos
- Depois de se tornarem muito bons em documentação e apoio ao planejamento de implementação, os LLMs também passaram a programar bem, e a tendência se ampliou no segundo semestre de 2025 com o hype do Claude Code e a chegada do Codex
- Mesmo antes disso, LLMs já eram usados diariamente para escrever testes unitários, mas ainda não havia confiança para delegar implementações inteiras
- Introduzir mais IA na escrita de código foi o passo seguinte natural, e como implantar em produção e satisfazer usuários sempre foi algo tão valorizado quanto programar, essa troca pareceu aceitável
- Os LLMs ficaram bons em escrever código, mas ainda não conseguiam depurar a bagunça deixada por modelos ou humanos, então o papel humano permanecia maior do que apenas coordenar robôs
- Com MCP, workflows agentivos e a chegada do Claude 4.5, até esse pilar da depuração começou a vacilar
- O Claude 4.5 passou a resolver cerca de 60% dos bugs apenas com stack trace e algum contexto, e na maioria dos casos bastava um link do Sentry com o Sentry MCP ativado
- Às vezes, gerava soluções plausíveis, porém completamente erradas
- Nesse ponto, deixou de desconfiar da máquina e passou a ver o Claude Code resolver de primeira bugs que antes consumiriam um dia inteiro de depuração
- Depois vieram 4.6, 4.7, GPT 5.5, Opus 4.8 e o DataDog MCP, e o CLI passou a resolver bugs de sistemas distribuídos em uma tacada só
- Incluindo bugs que antes não conseguia resolver, bugs que exigiriam dois dias de depuração em tempo integral e bugs de sistemas distribuídos com observabilidade distribuída insuficiente
- Cerca de 90% dos bugs — race conditions estranhas, corner cases inesperados, problemas de integração com terceiros, edge cases de APIs não documentadas — passaram a ser resolvidos de primeira
- Ainda é preciso alguém para revisar o código e coordenar os robôs, então o emprego continua, mas agora a sensação é de ter virado um engenheiro comoditizado
- A especialização em finanças e pagamentos, a intuição de depuração e o conhecimento em sistemas distribuídos viraram conhecimento que pode ser transformado em prompt para outro engenheiro sênior ajustar com LLMs
- Ao contrário do discurso tradicional de que há espaço tanto para generalistas quanto para especialistas, o mercado parece estar transformando todos em generalistas
- E se todos viram generalistas sem que a demanda acompanhe, o preço do generalista cai — justamente quando a demanda também está encolhendo
O terceiro pilar que ainda não ruiu: qualidade de código e arquitetura
- O pilar que ainda resta é a qualidade de código e a arquitetura de software, área que hoje está sendo reduzida à palavra “taste”
- Ao longo da carreira, sempre gostou de refatoração, valorizou código bom e negociou tempo dentro das sprints para fazer isso
- Sempre gostou de discutir trade-offs e estrutura de codebases em temas como DDD, Hexagonal e Clean Architecture
- Agentes são ferramentas muito fracas para manter uma codebase organizada
- Sem coordenação, problemas de dependência circular aparecem rapidamente
- Acrescentam código duplicado, inserem comentários desnecessários, misturam funções puras com efeitos colaterais e ignoram princípios SOLID
- Essa deveria ser a área capaz de preservar a empregabilidade humana, mas a indústria a reduz à palavra “taste” e caminha para um mundo em que a importância da organização do código é menor
- Ainda é papel humano coordenar agentes para impedir que a codebase vire espaguete com grafos de dependência circular
- Ninguém quer uma codebase de nível
Fque quebra ao tentar corrigir qualquer coisa, mas níveisCouDagora parecem aceitáveis - A razão de não serem mais necessárias codebases de nível
AouBé que elas estão sendo feitas para LLMs manipularem, e não para humanos lerem - Se o código-fonte agora passa a ser escrito para ser lido por máquinas, então também se torna possível escolher mirar as máquinas
- O conhecimento sobre qualidade de código e arquitetura também está perdendo valor, e o tempo investido em leitura, prática real, discussões com engenheiros e escrita de ADRs está se tornando inútil
E agora, o que fazer
- Por enquanto, acredita que continuará empregado — pelo menos na empresa atual —, mas a perspectiva de longo prazo é incerta
- No longo prazo, o valor do que levou 10 anos, ou mais se contar a experiência não especializada, para aprender está diminuindo gradualmente
- Até o último pilar de especialização foi reduzido a “taste”
- Cerca de 8 meses atrás, houve uma demissão em massa na empresa atual — segundo a empresa, sem relação com IA —, e antigos colegas brilhantes demitidos ainda seguem procurando trabalho
- Muitos deles enfrentam o mesmo problema: especialização de domínio já não basta para diferenciá-los
- A empresa voltou a contratar para alguns cargos, mas familiaridade com o domínio já não é mais um diferencial forte
- Antes, as vagas eram anunciadas como “Software Engineer - Area”; agora, aparece apenas “Software Engineer”, e a equipe é definida depois da aceitação da oferta
- Para engenheiros excelentes que nunca tiveram a chance de acumular experiência profunda de domínio, essa mudança abriu oportunidades melhores de emprego
- Engenheiros excelentes que passaram a vida toda acumulando conhecimento de domínio agora competem na mesma faixa
- A única escolha para preservar a empregabilidade no longo prazo é mover a especialização de domínio para áreas em que os LLMs ainda não consigam se sair bem com facilidade
- Considera até voltar para a universidade para estudar matemática, estatística e Machine Learning avançado e candidatar-se a vagas de pesquisa em frontier labs
- No país onde mora, não existem frontier labs, e os poucos institutos de pesquisa existentes estão sobrecarregados de candidatos
- Por questões familiares, é difícil mudar para outro país
- E até o momento em que essa mudança se tornasse viável, existe a possibilidade de a RSI (melhoria recursiva de si mesma) tornar pesquisadores desnecessários
- Chega a considerar transformar o hobby de marcenaria em profissão, de tão sem saída que a situação parece
1 comentários
Comentários do Hacker News
O quê? Eu passo o dia inteiro pilotando LLMs, mas nunca concordaria em ser o responsável por um produto financeiro
O primeiro pilar ainda continua de pé. Pode ser que o autor não perceba a própria influência, mas vendo a evidência de PRs revertidos, eu sei que, quando saio de uma área que conheço a fundo, já não consigo mais distinguir se o agente está falando bobagem. Até o nosso agente de ponta, que segundo o autor tem acesso a sistemas distribuídos, erra com frequência, tem visão estreita e continua fazendo burradas. No fim, a especialização dos engenheiros da equipe recoloca tudo nos trilhos
O Mythos concluiu com confiança que parte do nosso codebase violava uma determinada norma e disse que, se operássemos do jeito atual, haveria risco grave. Mas isso não era verdade; ele alucinou exigências regulatórias. Foi possível saber disso porque aquele código já tinha sido revisado por um consultor jurídico humano. Disseram que esse é o modelo de ponta disponível hoje. Eu uso bastante IA generativa para ajudar a escrever código, mas, nem no médio prazo, dá para depender desse tipo de ferramenta para realmente construir produtos financeiros em conformidade regulatória. Isso seria pura insanidade. É verdade que muitas empresas de FinTech usam agentes para ganhar velocidade, mas, se forem usados para lançar produto sem que uma pessoa realmente investigue a fundo, estão assumindo um risco enorme
Antes dos LLMs, havia espaço na maioria das empresas para engenheiros excelentes e engenheiros medianos trabalharem juntos. Depois dos LLMs, só os engenheiros “de elite” poderão sobreviver. Não há mais necessidade de engenheiros medianos. Pela natureza do HN, a maioria dos engenheiros que lê este texto deve achar que está entre os 10% ou 5% melhores da sua empresa/cidade/país, e por isso vai considerar que não é um engenheiro “mediano” que será afetado pela adoção de LLMs. Estatisticamente, isso provavelmente está errado. No fim, é uma questão de ego. Muito provavelmente você não é um rockstar, e os LLMs podem acabar tomando o seu trabalho. Como sempre, os únicos vencedores serão as empresas e os executivos, e a maioria de nós vai sair prejudicada por estar na ponta mais fraca da corrente
No meu caso, o desenvolvedor fez vibe coding em algumas partes e, por não ter entendimento profundo dos requisitos nem do próprio código, foram necessárias várias rodadas até corrigir. Dá para dizer que isso é um problema humano, mas o efeito líquido que eu vejo é este: nos casos complexos, o antigo “tempo razoavelmente longo para escrever o PR + tempo razoavelmente longo de revisão” parece ter virado “tempo muito curto para escrever o PR + tempo de revisão mais longo”. Não sei se há ganho real nesses casos. Às vezes o código está funcionalmente correto, mas fica verboso demais por causa de funções intermediárias em excesso, e isso parece que vai afetar revisões futuras
Eu tenho as mesmas preocupações, mas frequentemente sou descartado ou enrolado com algo na linha de “a velocidade de entrega e o ROI compensam, então não se preocupe”
Pessoalmente, toda empresa de FinTech com que tive contato já tinha, desde o ano passado, algo como uma conta de IA para desenvolvedores. Até em lugares como a Jane Street, funcionários publicaram blogs dizendo que basicamente comandam agentes na maior parte do tempo. Por quanto tempo você acha que a sua empresa vai aguentar?
Vejo muitos comentários do tipo “como a IA não consegue fazer X com 80~100% de precisão, nossa profissão está segura”
Não quero soar excessivamente pessimista, mas os modelos estão melhorando rápido. Se, há uns 3 anos, alguém tivesse descrito o estado atual dizendo “o modelo cria um app MVP inteiro em cerca de 30 minutos com um único prompt”, isso teria soado como ficção científica. Os obstáculos atuais dos modelos — como reduzir alucinações, garantir conformidade com regras e manter uma base de código limpa — não parecem estar tão longe de ser resolvidos. Até buscar informações específicas já é parcialmente possível com vários servidores MCP/RAG. Estou preocupado com o futuro dos engenheiros de software. Quando essas falhas forem resolvidas, onde a profissão vai se encaixar? Num papel de delegar tarefas para modelos de IA? Infelizmente, isso não exige anos de especialização, então é uma faca de dois gumes. Revisar a saída da IA? Basta pedir que ela explique cada linha que você não entendeu. Assim como os calculistas humanos foram substituídos pelos computadores digitais, acho que ainda veremos uma onda maior de demissões. Fazer cálculos matemáticos complexos de cabeça pode ser um desafio divertido, mas é muito mais lento e sujeito a erros do que um computador. Da mesma forma, escrever código manualmente vai parecer um “desafio” divertido, e a IA vai parecer a calculadora moderna
https://youtu.be/5eqRuVp65eY?si=3fLT6S5q2OIUcu6r
Muita coisa vai continuar melhorando bastante. Mas, olhando para a história moderna das disrupções tecnológicas, há um padrão recorrente. Como uma avalanche ou uma enchente súbita, essas mudanças abruptas muitas vezes começam com uma ou mais descobertas importantes em determinada tecnologia. No começo, o ritmo de mudança é rápido e turbulento, mas depois desacelera gradualmente à medida que os frutos mais fáceis são colhidos e novas barreiras e atritos aparecem em territórios recém-abertos. No início desses períodos, extrapolar para o futuro a taxa excepcional de mudança recente tem baixo poder preditivo. Explosões repentinas e extremas tendem a voltar para a linha de tendência de longo prazo. A disrupção atual dos LLMs pode ser vista como resultado do acúmulo de pesquisas desde 2010 até o artigo dos Transformers de 2017, que rapidamente impulsionou pesquisas ao seu redor. Se for assim, talvez estejamos agora no meio ou na fase final do surto explosivo dos LLMs. O ritmo de avanços fundamentais e amplos, que elevam todas as aplicações de LLM, claramente desacelerou, e muitas das descobertas recentes de grande impacto estão em expansão para áreas específicas, otimização, tuning e productização. Isso não significa que amanhã não possa surgir outro avanço do nível dos Transformers, mas, historicamente, cisnes negros raramente andam em bando
Os clientes deixariam de comprar ferramentas de software como fazem hoje e poderiam criar internamente todo o software de que precisam, ou fazê-lo por meio de consultores de prompt engineering. Pode ser um mundo muito diferente
Ou vamos ter algo como 700 empresas de fundador solo no mundo inteiro e o resto não vai conseguir trabalhar? É a Matrix?
Minha produtividade não aumentou tanto assim desde que o Claude 3.5 saiu. Tenho acesso ilimitado a todos os LLMs, mas a maioria é lixo, e eu gasto mais tempo consertando do que criando. As únicas pessoas que ganham com essa ferramenta são as que conseguem despejar resultados de baixa qualidade rapidamente. Se você discorda, então você também é esse tipo de pessoa
Minha trajetória de carreira é surpreendentemente parecida com a do autor. Curiosamente, a parte que o autor vê como o primeiro pilar a ruir agora me parece a mais intacta
LLMs falham repetidamente nas particularidades do nosso negócio. Coisas como legislação tributária local, detalhes de procedimentos contábeis e as especificidades da implementação do nosso razão. Eles são excelentes para refatoração, conversão entre linguagens e rastreamento de bugs em código existente, mas, ao iterar e expandir nosso domínio, sempre há muitos pontos sutilmente errados. Talvez isso aconteça porque as empresas em que trabalhei lidavam deliberadamente com áreas complexas para construir um fosso competitivo. São empresas que se sustentam porque não existe livro no mundo para criar uma cópia, e o know-how fica dentro de casa. Além disso, se for uma FinTech em que gestores recomendam criar documentos de design rapidamente com IA, isso parece descuido demais para um negócio que lida com dinheiro. Especialmente quando há um grande volume de transações pequenas, é fácil demais alocar incorretamente valores na casa dos milhões. Esses bugs são realmente difíceis de lidar. Corrigir a lógica é só a etapa 1; depois disso, é preciso consertar dados calculados incorretamente em um banco de dados imutável e lidar com procedimentos regulatórios e comunicação com clientes. As correções viram armadilhas que novos recursos e a observabilidade precisam considerar. Algo como: “lembre-se de que esse pico nos dados de 2 de fevereiro foi por causa do incidente X”
Estou criando vários produtos baseados em simulação física, puramente a partir de primeiros princípios. Mas, se eu delegar isso sem pesquisa ativa, raciocínio e validação, ele cria código de cálculo centenas de ordens de grandeza mais lento e enfia caminhos alternativos e atalhos absurdos, resultando em cálculos inúteis no fim. Isso acontece provavelmente em uns 95% dos casos. Supervisão é extremamente importante, e o pensamento arquitetural ainda não pode ser terceirizado. O que pode ser terceirizado é a execução
Claro, muitas vezes engenheiros de software sênior são especialistas nisso, mas não é obrigatório. Tradicionalmente, era útil para uma produção sem atritos que o engenheiro conseguisse tocar cerca de 90% do trabalho sem precisar perguntar ao especialista de negócio, mas justamente o ponto central do texto original é que essa “tradição” acabou. No novo mundo, o trabalho do engenheiro sênior não é ter pessoalmente essa expertise de domínio, e sim fazer com que o agente a tenha ou a adquira, e garantir que isso esteja correto de forma verificável. Engenheiros sênior que se agarram à ideia de que uma expertise avançada no domínio de negócio vai mantê-los seguros vão logo se ver em um beco sem saída, assim como juniores que não fizeram a transição
Eles têm um vocabulário profundo, então soam como se soubessem mais do que realmente sabem. São muito bons em escrever código e depurar erros visíveis, mas isso em parte é graças ao dispositivo de teste
A ideia central é fornecer a documentação ao LLM e fazer com que ele resolva ambiguidades e possíveis mal-entendidos fazendo muitas perguntas. Recomendo dar uma olhada em Skills. Ajuda bastante. https://www.youtube.com/watch?v=6BB6exR8Zd8
Conseguimos resolver o problema com arquivos claude.md/agents.md bem organizados. Também implementamos o supermemory.ai aqui, para que decisões tomadas recentemente sejam sempre relembradas ao agente de IA cada vez que uma nova sessão é iniciada
Sempre penso na frase infame de Steve Jobs, “ideias são baratas”
Execução é tudo, e se os LLMs de ponta resolverem a execução, então as ideias passam a ser a porta de entrada para a abundância. Mas a abundância em si não garante “poder de retenção”. O que muitas vezes é ignorado é a vontade humana de continuar naquilo e o quanto a pessoa se importa. Muita gente não se importa o bastante, nem quer o suficiente, para criar, manter e possuir algo. Talvez dê para lançar uma V1 mais rápido, mas dá para continuar insistindo depois? Um bom exemplo é a ferramenta de música com IA Suno. Ela já produz resultados bem bons. Muita gente brinca um pouco no seu mundinho particular, mas logo cansa e vai embora, e só ficam alguns poucos criadores prolíficos, transformando aquilo em um ambiente que “parece trabalho”. A escala e a economia da delegação e da execução podem ter mudado, mas ainda há muitos fatores a considerar
Mesmo com meu conhecimento musical limitado, sinto isso; então é bem possível que músicos sejam ainda mais críticos. Nas primeiras vezes impressiona, e as melodias são até grudentas. Antes soava estranho no fundo, mas a maior parte disso foi corrigida. Só que, depois de dezenas de músicas, tudo começa a soar igual. É tudo genérico, as músicas não contam uma história e passam uma sensação de trilha de propaganda corporativa. Tentei escrever prompts mais precisos, mas não funcionou muito bem, e quase sempre ele ignora os detalhes que tornariam a faixa interessante. Os resultados mais interessantes, na verdade, apareceram quando eu o fazia sair dos trilhos quase como um bug. Pedi para misturar dois gêneros muito diferentes e saiu algo com uma sensação desconfortável que eu não lembrava de já ter ouvido antes. Mas, para trabalhar mais em cima disso, sempre fica difícil, e ele continua tentando voltar para resultados genéricos, ignorando instruções detalhadas. O Suno consegue fazer remix. É parecido com código. LLMs já são muito bons em portar algo que já funciona para fazê-lo rodar em outra linguagem. Mas, quando você só tem a ideia, eles falham justamente na parte original. Para fazer um LLM implementar bem uma ideia, é preciso dar tanta orientação que você acaba lutando contra a ambiguidade da linguagem natural e isso vira praticamente o mesmo que escrever o código você mesmo
Se você insistir o bastante e tiver um sistema que consiga extrair código realmente funcional, talvez consiga resolver a execução. Mas isso é justamente engenharia. No estado atual, está muito longe de substituir engenharia. Talvez daqui a 3 anos consiga. Está avançando rápido. Mas hoje você ainda não pode simplesmente dizer “faça um compilador Rust melhor” e se recostar esperando o resultado
Eu gosto das músicas e ouviria na minha playlist, mas elas não tiveram grande resposta no algoritmo do Suno. Também não divulguei muito em outros lugares e, quando postei, recebi só alguns likes. Não fiquei decepcionado. Fiz música para mim mesmo, e compartilhar foi um efeito colateral. A conclusão que tirei disso é que dá muito trabalho fazer com que as pessoas se interessem e gostem do que eu criei. É preciso fazer marketing, levar isso até as pessoas e fazer com que prestem atenção. Também tenho certeza de que é preciso conectar isso a vídeo, história, persona, algum tipo de atmosfera, para dar um motivo para gostarem. Para “pegar”, você precisa repetir tudo isso para o mesmo público e fazer com que ele se acostume. Por isso é preciso persistência, e é preciso realmente se importar com aquilo que você quer vender. Antes de as pessoas se apegarem, eu preciso me apegar primeiro
https://en.wikipedia.org/wiki/Sturgeon%27s_law
A lei de Sturgeon diz que “90% de tudo é lixo”. Esse aforismo foi criado pelo escritor e crítico americano de ficção científica Theodore Sturgeon ao defender o valor do gênero. Sturgeon argumentava que, em qualquer área, a maior parte das obras é de baixa qualidade, e que, portanto, a ficção científica não era excepcionalmente inferior
Minha impressão é que elas são usadas como ferramentas de geração de uma vez só. Não entendo muito de música, mas imagino que, para artistas, sejam necessários elementos como etapas intermediárias, separação de faixas, customização de instrumentos e várias outras coisas que eu nem conheço. Sem isso, me parece difícil usar esse tipo de ferramenta em trabalho profissional
Não concordo totalmente com este texto. Um vibe coder não tem como projetar, desenvolver e implementar um sistema de complexidade média sem explodir tudo no processo
Uma parte grande de usar bem aplicações como Claude é ter entendimento conceitual e experiência com conceitos de ciência da computação. Coisas que um vibe coder simplesmente não tem. Se tivesse, não seria um vibe coder
Se você “não sabe o que fazer”, então surfe a onda
Também surfei quando a onda era sites/apps web. Entrei na indústria de software antes da internet e continuei trocando de montaria. Nunca é tarde demais para aprender uma tecnologia nova. Cada nova onda cria novos tipos de trabalho e de trabalhadores. Basta se tornar um deles. Monte a fera e domine as ferramentas. É o mesmo jogo voltando de novo
Se existe uma habilidade que sempre tem demanda, é a capacidade de estruturar as coisas na cabeça — trabalho novo, processo novo, pessoas novas, qualquer coisa. Eu entendi e desenvolvi essa habilidade como uma ferramenta afiada trabalhando como prototipista mecânico. Para quem não conhece, um prototipista mecânico é alguém que faz o que for preciso para fabricar peças difíceis em cronogramas curtos, semana após semana. Metal, plástico, o que for. Você fica bom em se familiarizar rapidamente com processos, máquinas-ferramenta e materiais. Depois de fazer isso por um tempo, passa a absorver informações novas muito rápido e a entender o trabalho muito mais rápido e com mais precisão do que muita gente. Qualquer pessoa pode começar. Basta ter curiosidade e construir alguma coisa. E depois construir mais. Compartilhe o que fez e faça o que as outras pessoas querem
Nos anos 90 e 2000 houve a onda de “programação orientada a objetos vai mudar tudo”. Era tipo pegar coisas que já vinham sendo feitas com sucesso havia centenas de vezes e agora fazê-las em OO. Você escreve código relacionado a aviões? Na faculdade eu realmente ouvi dizerem que bastava comprar um objeto avião onipotente que faria tudo sobre aviões. Mas então OO não era a solução para tudo? Geração de código, experimenta Ruby on Rails. Crie um site em 2 segundos. Geração de código estava por toda parte. A coisa foi tomando rumos estranhos e aí veio TDD. Já vi conversas reais em que diziam que, se você não faz TDD, é um engenheiro tão ruim que deveria ir para a prisão. Não, não, TDD não — a solução era BDD. Lean, não, Agile, não, agile em minúsculas, mas no começo era isso, não, Scrum, não, XML, espera, isso foi a década passada, JSON, e por fim SAFe. E agora é “você viu esse chatbot?”. Cada repetição traz coisas boas se você prestar atenção. Mas também traz muito exagero e ansiedade. É só experimentar e aprender. Uma coisa que para mim nunca mudou é que quase todo mundo preferiria morrer a pensar com cuidado nas consequências de ter o seu sonho realizado. Enquanto isso continuar sendo verdade, as pessoas vão continuar pagando para alguém montar por elas o dragão das modas exageradas
Todo o fluxo de fábrica de resultados ruins em escala, ou melhor, o fluxo “AI native”, é assim. “Uau, convenci o chatbot a fazer algo que eu não entendo nem um pouco. Como eu sou bom no meu trabalho!” É como um prêmio de participação por fazer coisas. Outra coisa produz, e eu levo o mérito sem nem entender direito. Não há retorno composto no meu esforço. Não há lições aprendidas. Não há compreensão acumulada. Não há insight que leve a inovação futura. Não há diferenciação. Só gritar para o vazio até a mente entorpecer, e quando a máquina caça-níquel cospe uma mistura ruim que “parece boa o suficiente”, você repete tudo no dia seguinte. Se esse é o jogo, estou fora. Que bom que outras pessoas se divertem com isso, mas achar que existe algum domínio aí é delírio. A única condição para “ter sucesso” com essa ferramenta é parar de se importar e se render
Já postei isso antes, mas vale a pena postar de novo
Trabalho com DevOps numa empresa muito agressiva no uso de LLMs. As etapas foram mais ou menos assim: tentar fazer o LLM fazer “muita coisa”, fazer mais coisas ainda, rodar vários agentes, voltar para um único agente, mas fazendo-o criar ferramentas, e então migrar para ferramentas determinísticas que tanto humanos quanto LLMs possam usar. O motivo é o seguinte. Em deploy e em testes, ferramentas determinísticas dão respostas binárias e são repetíveis. Quando dá problema, sempre dá para voltar a ferramentas que um humano consegue executar. É mais rápido. Scripts simples rodam em menos de 30 segundos, mas a “baboseira plausível” sempre parecia levar de 2 a 3 minutos. No fim, isso me leva de volta a este texto. https://spawn-queue.acm.org/doi/10.1145/3194653.3197520 Em outras palavras: “faça uma lista de tarefas, escreva o script de cada tarefa, combine os scripts em funções, e as funções viram o sistema”. E, para acrescentar, se você deixar o LLM fazer o que quiser, ele vai escrever código com prazer. Dá para adicionar testes e verificar se esses testes funcionam. Já fazíamos isso com código humano antes. Também dá para ler o código. E, quando você lê o código, às vezes vê que ele produz código funcional enquanto ao mesmo tempo faz coisas completamente malucas. Humanos também fazem isso, mas isso é outra história. No fim, você ainda precisa verificar se o sistema produzido faz sentido. Em termos mais simples, a programação pode ter morrido, mas a engenharia de software está viva e muito bem
Você pode pedir para um LLM grande fazer tudo. Dá para fazer, e de fato fazem. Mas custa caro demais e demora muito. Em vez disso, se você usar IA para criar ferramentas que tratem de forma determinística o máximo possível das tarefas do processo, e fizer a IA usar essas ferramentas, tudo roda muito mais rápido e mais barato. De quebra, no fim você talvez consiga até largar a IA cara de nuvem e passar a usar modelos locais pequenos ou médios
Se a visão de futuro do autor estiver correta, engenheiros de software competentes estarão seguros
Conhecimento de domínio pode ser aprendido muito mais rápido do que como aplicar bons princípios de engenharia. Engenheiros cuja principal vantagem competitiva é o conhecimento de domínio talvez não sejam tão bons assim na engenharia em si. Ainda assim, podem encontrar trabalho em outras áreas do setor onde o conhecimento de domínio acumulado seja necessário
Muitos bons engenheiros de software, agindo com arrogância como se conhecimento de domínio fosse algo fácil de obter, já destruíram inúmeros sistemas ERP. Uma parte enorme de TI é, literalmente, colocar regras de negócio dentro de sistemas
Mesmo assim, ainda vejo e reviso código de desenvolvedores de software “especialistas” que não seguem boas práticas de engenharia de software. Dizer que engenheiros cuja principal vantagem competitiva é o conhecimento de domínio podem não ser excelentes em engenharia também vale para engenheiros sem conhecimento de domínio. Pelo menos essa é a minha experiência. Talvez tenhamos tido azar
Porque conhecimento de domínio valioso não é o conhecimento de ontem, mas o de hoje e o de amanhã. Em áreas onde conhecimento de domínio importa, ele está profundamente entrelaçado com a engenharia. Ninguém pediria ao Jeff Dean para desenvolver a Unreal Engine do zero. Mesmo assim, há muitos princípios de engenharia de software que especialistas em domínio não internalizaram completamente ou não executam bem o suficiente. Enquanto conhecimento de domínio tiver valor, esse estado das coisas continuará. Porque engenharia de software também é outro domínio
Metodologia pode ser melhorada muito mais rápido do que adquirir conhecimento especializado. A primeira é uma questão de abordagem, então pode ser imposta e elevada rapidamente. A segunda depende da inclinação da pessoa para aprender, da sua capacidade e do tempo disponível no momento, e não pode ser forçada além de um suporte razoável. Além disso, ela tem um caráter cumulativo, então a curva de aprendizado inicial é muito mais íngreme
Estou usando Claude Code e Opus 4.7, e a tendência não é tanto o código gerado estar errado, mas escrever código demais
Ainda há valor em pensar numa funcionalidade específica e encaixá-la da melhor forma no código. O Claude muitas vezes escolhe uma camada da stack, por exemplo a camada de apresentação, e enfia tudo ali. Se algumas semanas depois os mesmos dados também forem necessários em outro lugar, o Claude não consegue reutilizar o código da camada de serviço e faz uma espécie de “transplante”. Se uma pessoa não prestar atenção, a quantidade de código dobra e a lógica fica duplicada. Não parece que ferramentas de IA como o Claude vão melhorar nisso tão cedo. Onde eu trabalho, já existe pressão para reduzir o uso do Opus 4.7 para economizar custos. Alguém sugeriu usar um modelo menor para “correções simples de bug”. Às vezes isso pode funcionar, mas com que frequência dá para saber de antemão que realmente é uma correção simples? Se o custo subir, acho que vai diminuir o interesse em usar essa ferramenta para escrever “todo o código”. Se as pessoas migrarem para modelos mais baratos e menos eficazes, é bem possível que também desapareça a pressão para não revisar esse código. Vamos ver onde isso vai dar, mas talvez não mude de forma tão dramática quanto o autor teme
Só de dizer para a IA cortar pela metade o número de linhas de código de produção e verificar se existe alguma outra biblioteca reutilizável já é surpreendentemente eficaz. Também parece que daria para criar um bot de refatoração que encontrasse duplicações e as extraísse. Isso não vem por padrão agora, mas claramente não parece impossível
Mas a questão em aberto é se código demais é de fato um problema. Essas ferramentas agora fazem parte da vida. Se resolvem problemas mais rápido ou ajudam a depurar, e se o software tem menos bugs, então talvez não seja código demais, mas exatamente a quantidade certa de linhas de código
fooBar()efooBarExtended()A segunda tinha os parâmetros e funcionalidades extras necessários para o problema atual. Mas, em vez de chamar essa função, o Claude continuava tentando adicionar os mesmos parâmetros de extensão à primeira função. Mesmo depois de eu dizer para não fazer isso, mais tarde ele sugeriu a mesma coisa de novo, e às vezes isso é realmente irritante
Independentemente de como se veja o futuro do setor, acho difícil encontrar mais sucesso profissional em marcenaria artesanal do que em software artesanal
Já me disseram para tentar vender os móveis que fiz, mas minha resposta é sempre a mesma. Já cometi uma vez o erro de transformar um hobby em profissão e não pretendo repetir esse erro. Pelo menos software ainda paga bastante bem
Tem alguém com quem trabalho que constrói decks, jardins, caravanas, galpões e cercas, e ganha muito bem com isso. Claro, para ser justo, essa pessoa também é extremamente habilidosa
O batente apodreceu, e paguei 4 mil dólares a um marceneiro para fabricar uma peça de reposição. Para substituir a porta em si, facilmente custaria 25 mil dólares. Se você se mudar para um grande distrito histórico com muitas portas esculpidas à mão, dá para ganhar um bom dinheiro
Mas a parcela do mercado disposta a pagar por software feito à mão é exatamente 0%
Não é marcenaria, é agricultura. Você precisa conseguir terra e cultivar sua própria comida. Não participar da economia de jeito nenhum é a única forma de sobreviver