A faxina deixada pelos desenvolvedores rockstar da IA

• No passado, o problema de codebases difíceis de entender deixadas por “desenvolvedores rockstar” cresceu e virou uma carga de manutenção para toda a equipe com a disseminação de código gerado por LLM
• Desenvolvedores rockstar adotavam rapidamente novas tecnologias, novos paradigmas e novas arquiteturas, e concluíam trabalhos difíceis com rapidez, mas tinham pouco interesse em escrever código que outras pessoas pudessem entender e com o qual pudessem colaborar
• Agentes com LLM produzem dezenas de milhares de linhas de código em pouco tempo sem lembrar do trabalho anterior, e não se preocupam se isso combina com o sistema como um todo ou se melhora a compreensibilidade
• Quanto mais código gerado se acumula, mais a complexidade do sistema aumenta significativamente, criando um fluxo em que se pode voltar a depender de LLMs para entender isso
• Para software duradouro, é necessário limitar o uso de LLMs à geração de pequenos trechos de código, deixar o design nas mãos de humanos e simplificar a arquitetura de acordo com a complexidade do problema

---

A estrutura deixada pelo desenvolvedor rockstar

• Depois de entrar na equipe, o desenvolvedor rockstar apresentava ideias fortes sobre novas tecnologias, novos paradigmas e novas arquiteturas
• Reescrevia a maior parte da arquitetura central da empresa e introduzia novos processos de build, ferramentas e linguagens
• Rejeitava muitos pull requests, elevando o padrão exigido dos colegas, e os outros não conseguiam demonstrar se entendiam aquele código ou não
• As tarefas mais difíceis eram atribuídas ao desenvolvedor rockstar, e ele as concluía mais rápido que os demais
• Os outros membros da equipe avançavam mais devagar enquanto aprendiam novas bibliotecas e tentavam se adaptar ao modo de trabalhar do desenvolvedor rockstar
• Anos depois, o desenvolvedor rockstar deixava a equipe em busca de projetos mais difíceis e maiores em outra empresa

Lidando com as consequências

• A equipe que ficou herdava os projetos do desenvolvedor rockstar e passava pela experiência de se sentir sobrecarregada dentro do código
• Era difícil seguir o fluxo de dados, a ponto de parecer que alguém estava tentando encobrir um assassinato
• Tudo começava com uma simples correção de bug, mas levava uma semana só para conseguir rodar o código no notebook
• Metade do código estava escrita em uma linguagem que ninguém entendia, e a outra metade usava bibliotecas das quais ninguém nunca tinha ouvido falar
• Ao dizer ao chefe que era necessário reescrever o código, a sugestão era rejeitada pelo simples fato de ter sido escrita pelo desenvolvedor rockstar
• Enquanto se perdia naquele código caótico, a pessoa se imaginava indo embora ao olhar vagas de emprego

Limpando a bagunça deixada pelo rockstar

• Muitas equipes e agências precisam organizar codebases deixadas por esse tipo de desenvolvedor rockstar
• O processo de entender e salvar uma codebase complexa é comparável a desembaraçar um fio de luzes enrolado para poder usá-lo de novo
• Desenvolvedores rockstar gostam de programar, aprender e usar novos paradigmas, e forçam suas capacidades até o limite
• Tentam escrever o código mais inteligente possível e se concentram em avançar o mais rápido que conseguem
• Escrever código com o qual outras pessoas possam colaborar vira a menor prioridade para o desenvolvedor rockstar

A chegada da inteligência artificial

• Nos últimos anos, muitas equipes passaram pela experiência de serem sobrecarregadas por uma legião de desenvolvedores rockstar
• Surge o risco de adicionar um desenvolvedor rockstar à equipe cada vez que alguém inicia um novo chat
• O agente não se lembra do que fez ontem e gera dezenas de milhares de linhas de código em poucos minutos
• O agente busca concluir tarefas em uma velocidade humanamente impossível
• Não se importa se o código gerado combina com o restante do sistema nem se o sistema fica mais fácil de entender
• A IA traz uma caixa de ferramentas de boas práticas que pode não se encaixar no contexto
• Mesmo quando a complexidade supera os benefícios, a IA insiste em salvaguardas excessivas no estilo “cinto e suspensório”
• Ao pedir uma revisão de código, ela produz uma longa lista de melhorias com muitos itens difíceis de aceitar
• Cada vez mais gente sente que, se não usar LLM, ficará para sempre para trás
• A visão aqui é que deixar o LLM escrever todo o código acaba, no fim, levando justamente a ficar para trás

Limpando a bagunça deixada por centenas de rockstars de IA

• Organizar uma pilha caótica de código gerado não é tão agradável quanto limpar o código deixado por um único desenvolvedor rockstar
• Pelo menos o desenvolvedor rockstar tinha alguma intenção de design e uma tentativa de fazer o melhor possível
• A pilha caótica de código criada por vibe coding não foi escrita por um único desenvolvedor artificial
• Ela se torna uma codebase em que cada funcionalidade ou cada correção de bug foi gerada em diferentes chats e diferentes contextos
• Isso se parece com uma codebase escrita por centenas de desenvolvedores rockstar diferentes
• Em alguns casos, a dívida técnica fica tão grande que se torna impossível de pagar

Criando software duradouro

• Há várias maneiras de usar LLMs sem deixá-los agir como desenvolvedores rockstar
• Humanos podem liderar a engenharia e orientar o LLM a gerar apenas pequenos trechos de código por vez
• É preciso garantir que o software seja escrito de um modo que todos da equipe consigam entender facilmente e no qual possam trabalhar
• Se o LLM se perdeu sem que ninguém entenda o que está fazendo e por quê, é hora de desacelerar
• Não há problema em avançar mais devagar para garantir a qualidade do software que está sendo gerado
• Não há problema em continuar simplificando para evitar overengineering e fazer a arquitetura combinar com a complexidade do problema
• Às vezes, não há problema em deixar o LLM parado na caixa de ferramentas e escrever o código diretamente
• O artesanato do software sempre continua nas mãos humanas, uma área que não pode ser terceirizada para máquinas

[GN⁺]

Comentários do Hacker News

• A última frase, de que a arte do ofício sempre permanece nas mãos humanas e nunca pode ser terceirizada para máquinas, me preocupa um pouco
  Em outras indústrias, a arte do ofício não morreu, mas foi deixada para trás por alternativas muito mais baratas e fáceis de obter. Ainda dá para comprar sapatos de couro feitos à mão, mas poucas pessoas querem pagar mais de $1000, e ainda dá para comprar quadros que levaram semanas para serem feitos, mas a maioria compra decoração de parede e bugigangas na HomeGoods
  A diferença central é a premissa de descartabilidade e, infelizmente, o software também está se tornando cada vez mais “descartável”, como outros produtos. Se for um app simples de contagem regressiva, tudo bem jogar fora, mas software que sustenta processos de trabalho de longa duração não deveria ser tratado assim
  Se você foca na arte do ofício em software, o problema pode parecer “algo necessário para o meu uso” versus “algo boutique, caro e desnecessário”. Na prática, deveria ser “algo manutenível e confiável” versus “algo que pode ser descartado”
  Independentemente de essa tendência beneficiar grandes provedores de modelos como OpenAI ou Anthropic, esse não é o ponto aqui

  • A arte do ofício em outras indústrias não está morrendo do jeito que se diz no software
    A minha mesa barata, que veio numa caixa achatada e que eu montei com uma chave de fenda, também foi produzida em massa numa fábrica, mas o projeto dela pode ter envolvido muito mais arte especializada do que uma peça sob medida. A estrutura é de alto custo inicial de projeto seguido de baixo custo marginal para produção em massa
    O software foi, em grande parte, assim desde o começo. Quando eu baixo o Firefox, não há um artesão fazendo um navegador só para mim; algum servidor de CDN num datacenter em algum lugar está copiando bytes do cache para mim
    O que a IA ameaça é a substituição da arte do ofício baseada em investimento inicial, algo que nunca ocorreu em larga escala em outras indústrias. O que a IA substituiu com mais sucesso foi o software “artesanal” de baixo custo, uma categoria que até agora praticamente não existia porque sua viabilidade econômica era baixa demais
  • Indústrias físicas e software são muito diferentes. Sapatos de couro são feitos várias vezes, um par para cada cliente, enquanto o código é feito uma vez e todos os clientes usam o mesmo produto
    Por isso existe uma alavancagem muito maior no investimento em qualidade
    Também é difícil concordar que software seja descartável no mesmo sentido. Se o problema for temporário, dá para jogar o código fora e fazer outro quando surgir um problema diferente. Mas se for um problema persistente, o código continua existindo
  • Há uma perspectiva interessante do lado da usinagem
    Parafusos já foram itens valiosos feitos sob medida, e era preciso um enorme investimento de tempo e esforço para fazer um único parafuso bom. Até o que hoje chamamos de parafuso de máquina só podia ser feito por alguém muito habilidoso com trabalho extremo
    Mas as máquinas podem transferir a arte do ofício. Se você faz um parafuso realmente bom, a máquina transfere a qualidade desse parafuso para inúmeros parafusos novos
    Hoje, parafusos de todos os tipos e qualidades viraram consumíveis quase idênticos, e parafusos que antes levariam dias ou semanas para serem talhados à mão agora são feitos aos bilhões
    Vejo a IA como um torno sem fuso-guia. No começo, você precisa fazer os parafusos manualmente, e depois pode transferir para novos parafusos toda a qualidade que consegue produzir. Se você passa a conseguir fazer parafusos melhores, coloca isso no torno e faz mais parafusos melhores. Mas, no fundo, continua limitado pela qualidade do parafuso que você consegue fazer com as próprias mãos. Se tudo o que você consegue fazer é algo torto, irregular e ruim, é só esse nível que a máquina também vai produzir
  • Essa é uma forma totalmente errada de ver a questão. O equivalente a “arte do ofício” em software não é a fabricação do sapato, e sim o projeto do sapato
    Desenvolvedores de software criam propriedade intelectual única, não fabricam unidades de software. São mais parecidos com autores de livros ou músicos
    Não existe equivalente à fabricação unitária no software. É só uma questão de copiar e mover bits
    Portanto, no contexto de software, “arte do ofício” significa o quanto você se importa em projetar algo bom. Isso não vai desaparecer a menos que cheguemos a um ponto em que até a qualidade do software que usamos deixe de importar, e não há sinal de que estejamos indo nessa direção
  • A analogia com sapatos feitos à mão não parece correta, a menos que se esteja falando de software usado por uma única pessoa
    Uma comparação mais adequada talvez seja com engenheiros que criam e fazem a manutenção do maquinário de fabricação numa fábrica de sapatos. Está um nível afastado do consumidor, mas certamente ainda há arte do ofício ali

• Eu gosto de consertar código de IA ou terceirizado. Na semana passada descobri que um cliente tentou fazer uma ferramenta para o departamento com vibe coding, e o resultado foi um lixo em Next.js gigantesco que precisava de 10 GB de memória para compilar, tinha milhares de erros de lint e até logs barulhentos de desenvolvimento no Git
  Agora nós temos que corrigir isso, então esse tipo de coisa equivale repetidamente a trabalhos grátis de 10 mil a 50 mil euros. Se você sabe o que está fazendo, é muito fácil; se não sabe, é impossível. Pode mandar mais

  • Em certo sentido, é como se o cliente tivesse te dado a especificação e mockups de UI do que queria implementar
  • Concordo 1000 vezes com isso
    Trabalho com resposta a incidentes para pequenas e médias empresas, e nos últimos anos o volume de trabalho aumentou a ponto de ficar difícil dar conta, e minha conta bancária parece um monte de ouro de dragão
    Sempre fui da opinião de que segurança precisa ser integrada e planejada desde o início, e não estou dizendo de forma alguma que quero ver incidentes de violação
    Mas o fato de pessoas com especialização duvidosa agora poderem despejar apps em uma hora foi um ganho absurdo para pessoas como eu
  • Agências focadas nesse tipo de trabalho vão ganhar muito dinheiro. Já peguei alguns trabalhos assim, e enquanto as pessoas acharem que conseguem fazer vibe coding de um produto, isso vai continuar chegando. Como você disse, é dinheiro fácil
  • Muita gente está apostando muito dinheiro em IA. Algumas dessas apostas parecem promissoras, mas nem todas vão dar certo
    Dá para ver esse tipo de mentalidade como uma caça-níquel humana na qual as pessoas continuam colocando dinheiro
  • Fico curioso para saber se você pode contar mais sobre como isso se desenrola na prática, sem revelar sua identidade nem a dos clientes
    Quando os clientes chegam até você, eles já estavam desde o começo querendo ajuda para colocar isso em produção, ou isso é o último recurso depois que toda a abordagem com IA fracassou?
    Também tenho curiosidade se existe um jeito típico de esses projetos desmoronarem, ou se o fracasso costuma ser mais sutil

• Ao longo da vida, conheci algumas pessoas que dá mesmo para chamar de brilhantes. Daquelas que fazem pensar: “como alguém consegue ser tão inteligente assim?”
  Há duas coisas que aparecem em pessoas realmente inteligentes, e em geral elas se excluem mutuamente. Uma é não saber o quanto são inteligentes. Para elas aquilo é simples, ou é um assunto que conhecem, então assumem que qualquer pessoa com formação em ciência da computação também sabe, lembra e entende. Já ouvi amigos falando sem parar sobre matemática ligada à criptografia e pensei: “eu passei nessa disciplina, mas não posso dizer que realmente entendo o que você acabou de falar”
  A outra é gente que está dolorosamente consciente, o tempo todo, de que é mais inteligente do que a maioria ao redor. Alguns acabam sendo cruéis, e outros estão apenas exaustos de estar cercados por pessoas relativamente “burras”. Com estes últimos, eu até simpatizo em certa medida. Basta imaginar viver com tudo parecendo claro, óbvio e fácil de resolver, e ainda ter de ver a humanidade repetir escolhas idiotas apesar de as respostas já serem conhecidas há muito tempo

  • Existe também um terceiro problema. É que uma maioria bem maior das pessoas acredita que se encaixa nessa última frase
  • Eu não diria que li muitos livros ou que tenho QI alto, mas me sinto de forma parecida em pequenas coisas que parecem senso comum
    Quando vejo as pessoas se atrapalhando, ou fazendo X mesmo quando é óbvio que isso vai gerar -Y, um resultado ruim, eu quase enlouqueço. A maioria só aprendeu a não falar isso em voz alta
    Em relações familiares próximas isso é especialmente pouco saudável. Eu vejo isso tanto que sinto que poderia matar alguém de tanto reclamar
  • Já conheci e convivi com pessoas assim
    Mas nenhuma delas era um desenvolvedor 10x que deixou um caos gigantesco para a equipe e para mim passarmos meses limpando
  • Viver como alguém no extremo de uma característica fundamental é algo solitário
    Por mais que você tente, é difícil se relacionar com a maioria das pessoas, e elas também têm muita dificuldade para entender você. A diferença de experiências vividas é muito grande e muitas vezes difícil de superar
  • Muitos desenvolvedores simplesmente escolhem tocar as tarefas do dia a dia ou seguir o cargo cult
    Nem todo desenvolvedor vai produzir no mesmo nível, mas qualquer pessoa pode ficar mais inteligente à sua maneira se decidir continuar pensando além da média cultural
    A maioria nem percebe que poderia fazer isso

• Essas duas frases me marcaram
  “Era tão difícil seguir o fluxo de dados que parecia que alguém estava tentando encobrir um assassinato”
  “Levei uma semana só para conseguir rodar o código no notebook”
  Eu sempre achei que só eu tinha dificuldade para entender o fluxo de dados ou montar um ambiente de desenvolvimento decente. A síndrome do impostor e, às vezes, ambientes tóxicos que forçam “velocidade” também não ajudavam
  Foi bom descobrir que não sou o único

  • Essa parte de “levei uma semana só para conseguir rodar o código no notebook” me surpreendeu
    O Claude Code na CLI tornou muito mais fácil do que antes subir o app e depurar problemas aleatórios de dependência ou relacionados a Docker. Antes eu tinha de aprender a arquitetura e, ao mesmo tempo, resolver por que aquilo não funcionava na minha máquina
  • Você não é o único. Eu senti exatamente a mesma coisa, e esse tipo de conhecimento costuma ficar na cabeça das pessoas ou perdido em threads aleatórias do Slack
    Com código de IA isso piora ainda mais. Porque muitas vezes ele só gerou algo que parecia plausível naquele momento

• Tenho um pouco de inveja das pessoas que precisam limpar a bagunça deixada por outros. Pelo menos parece um quebra-cabeça para resolver
  Meu trabalho agora é simplesmente entediante. São tarefas tão simples que até um júnior conseguiria fazer, mas insistem que precisam de um desenvolvedor pleno. Não estou dizendo que sou bom demais para isso, nem que pessoas plenas não façam esse tipo de trabalho. Só que eu não consigo me forçar a me importar com o código que essa empresa produz. É velho, empoeirado e nem é usado por pessoas importantes. Os clientes compraram essa ferramenta em algum momento e continuam usando porque ela é sem graça demais até para se importarem a ponto de trocar
  Prometeram que em breve viria um trabalho mais alinhado com minha experiência, mas não parece que esse tipo de cliente vá aparecer numa empresa tão estagnada
  Não me surpreende que a empresa esteja perdendo clientes e funcionários. Mas eu preciso pagar a hipoteca. Hoje ouvi que talvez não renovem meu contrato e, na prática, isso soou como uma ameaça para eu assumir mais responsabilidade e mais trabalho pelo mesmo salário
  Infelizmente, preciso aguentar até encontrar uma vaga nova que seja realmente interessante. Nem preciso de tanto dinheiro assim e não ligo nem um pouco para “crescimento”. Só preciso do suficiente para sobreviver
  Talvez este comentário não tenha muito a ver com o assunto, desculpem. Não tenho outro lugar para descarregar isso

  • Você não está sozinho. Passei exatamente pela mesma situação na Microsoft e acabei pedindo demissão
    Eu era L63, mas o trabalho que fazia era de nível L60~L61, e muitas vezes parecia que eu estava em um daqueles Bullshit Jobs de que David Graeber falava. A remuneração era generosa, mas quando as ações do bônus de contratação acabaram, percebi que eu só estava naquele emprego pela estabilidade
    Eu me sentia como um daqueles engenheiros tomando sol no terraço do escritório da Hooli enquanto esperavam as ações vestirem. Eu já tinha 9 anos de carreira e aquilo não parecia o melhor para minha trajetória naquele momento
    Só que, no meu caso, eu não tinha grandes obrigações financeiras, então foi uma decisão muito mais fácil
  • No começo achei que “medior” fosse um erro de digitação estranho de “senior”, mas como apareceu duas vezes fui pesquisar. Parece ser usado em algumas partes da Europa com o sentido de nível intermediário
  • Me identifiquei muito com a frase “eu não consigo me forçar a me importar com o código que essa empresa produz”
    Produtos lixo feitos por empresas lixo sobrevivem parasitando a preguiça e a falta de gosto da maioria, e os marqueteiros monetizam isso
    Agora, para piorar, o campo inteiro está sendo LLMizado, amplificando isso em 100 vezes. Isso torna o código impossível de manter e, pior ainda, deixa todos nós mais burros
    Sinceramente, eu gostaria que a gente nunca tivesse descoberto isso
  • Se você olhar com atenção para o codebase em que está trabalhando agora, provavelmente vai encontrar muitas oportunidades de limpar coisas, sejam deixadas por outros ou por você mesmo
  • Fiquei um pouco curioso com a parte de “ameaçado a assumir mais responsabilidade e mais trabalho pelo mesmo salário”
    Queria entender se isso significa apenas fazer mais horas e tarefas inúteis, se há de fato mais chances de programar, ou se a expectativa é provar de repente que você vale mais
    Não estou tentando minimizar o que você passou. Se for o último caso, fiquei curioso se existe algo concreto que dê para fazer

• As primeiras seções me tocaram. Acho que antigamente eu era um desenvolvedor rockstar, mas percebi que isso não era algo bom
  Eu talvez conseguisse terminar o trabalho 10 vezes mais rápido que meus colegas. Mas em certo momento percebi que isso não acontecia porque eu era 10 vezes mais produtivo que uma pessoa comum, e sim porque meu jeito de trabalhar fazia as pessoas comuns ao meu redor ficarem com 1/10 da produtividade
  Depois disso, desacelerei, e isso foi uma mudança positiva para a minha vida como um todo. Virar um jogador de equipe não dá o mesmo nível de mobilidade ascendente neste setor maluco, mas foi surpreendentemente bom para a minha saúde mental

  • Eu também certamente já atirei no próprio pé ao implementar coisas no estilo rockstar no passado
    No meu caso, geralmente era abstrair demais coisas desnecessárias ou criar algo para casos de uso que nunca aconteciam de fato. Então, sempre que percebo que meu pensamento está indo na direção da abstração excessiva, tento me lembrar de YAGNI e KISS

• Este texto tem valor baixo demais
  Nem ficou claro o que ele queria dizer, e parece apenas um texto de autoelogio

  • Código ruim claramente existe. Mas este texto parece misturar “código ruim” com “código complexo, grande e que leva tempo para se acostumar”
    Uma parte considerável do que é chamado de enorme quantidade de código ruim deixada por um “desenvolvedor rockstar” na verdade foi o resultado de uma complexidade que se acumulou aos poucos, de forma longa e lenta, em resposta a mudanças de requisitos
    E muitas vezes as pessoas acham que estão “refatorando por legibilidade”, quando na prática estão “reescrevendo o código e passando a entendê-lo durante o processo”
  • Em resumo, a mensagem é “ao usar LLMs, vá mais devagar e pense no que está fazendo”. Você me poupou 5 minutos
    Eu esperava mais conteúdo ou exemplos reais. 90% do texto é o autor reclamando e definindo o problema, e no penúltimo parágrafo aparece uma solução vaga, como se tivesse sido improvisada. Quase não há relevância ou utilidade real

• Foi realmente uma idiotice da minha parte pressionar com força dois engenheiros de produção para construir a infraestrutura em torno de dois projetos lucrativos que eu fiz
  Eu poderia ter ganhado muito mais dinheiro se tivesse feito tudo como um chefe 10x, com código espaguete, e ido para a Anthropic receber um pacote de remuneração de 9 dígitos. Fui burro, burro demais
  Pelo menos essa foi a conclusão que tirei daqui

• O código escrito normalmente precisa ser mantido por alguém que não foi quem o escreveu. Então, se você escreve código que ninguém consegue entender, isso inevitavelmente leva a um fracasso de manutenção
  O que se otimiza pode variar: código fácil para a equipe entender, velocidade, excelência técnica etc.
  Mas mesmo que você tenha otimizado pela excelência técnica, se ninguém mais na equipe consegue entender aquele código, ainda assim é um fracasso
  Já vi código excessivamente projetado

[GN⁺]

Opiniões no Lobste.rs

• Este texto tem muito pouco conselho realmente útil

  • Parece alguém embrulhando uma reclamação pessoal com dois jargões da moda para fazê-la soar plausível
    A expressão “desenvolvedor rockstar” sempre me parece suspeita, mas desenvolvedores realmente excelentes existem. Só que essas pessoas não agem do jeito descrito no texto: elas trabalham dentro do ambiente existente até onde dá, melhoram a base de código, não introduzem novidades não testadas como se fossem brinquedos e deixam tudo mais estável quando saem, com testes, deploy automatizado, linting etc.
    Aqui, IA parece ter sido acrescentada como se esse comportamento fosse piorar por causa dela. Pode até ser, mas ainda não me parece algo suficientemente comprovado. Trabalhei por décadas como consultor organizando bases de código caóticas, e às vezes a causa era gente que foi longe demais, mas com mais frequência eram equipes que simplesmente não conheciam um jeito melhor. Em nenhum dos casos pensei “isso deve ter sido obra de um desenvolvedor rockstar/ninja/da moda”

• Agora não basta limpar o lixo que chatbots despejaram por cima de tudo, ainda temos que arrumar a bagunça de quem nem se importa com isso
  Fico só esperando a bolha estourar

  • Sempre foi assim, e a IA só amplifica o problema. Por outro lado, também dá para dizer que o trabalho de arrumação ficou mais fácil

• Se eu entrasse numa empresa em 2026 e descobrisse que ainda usam create-react-app, eu realmente queria saber qual seria a conduta recomendada. A ideia é simplesmente não dizer nada?

  • Se for um projeto novo, basta dizer que agora está deprecated e não é mais recomendado
    Se for um projeto antigo, você encontrou dívida técnica. Todo mundo tem. A melhor forma de convencer as pessoas a corrigir isso é construir uma justificativa que faça sentido para o negócio. Se está funcionando, isso é mesmo um risco? Qual é a prioridade em comparação com outras dívidas técnicas? Que riscos implícitos vocês assumem por não atualizar? Quanto esforço seria necessário para atualizar?
    Se o esforço for pequeno e seus colegas também quiserem, dá até para simplesmente fazer o trabalho sem pedir permissão. Mas isso funciona melhor quando há apoio das pessoas afetadas pela mudança e quando não atrapalha suas entregas. Talvez não seja algo para fazer na primeira semana de trabalho
    Em geral, quase sempre é melhor perguntar e entender por que as coisas estão como estão agora, em vez de dizer como “deveriam ser”. Toda base de código com história é o resultado de milhares de decisões que você ainda não conhece. É preciso se armar com conhecimento e empatia
  • Quando entro em algum lugar, prefiro primeiro observar antes de apontar tudo o que deveria ser diferente. Existe um equilíbrio entre a pessoa nova chegar querendo mudar tudo e focar no que realmente gera impacto. Logo no começo, você ainda não sabe o que gera impacto
  • Depende de quais batalhas você escolhe. Pessoalmente, eu não acho que valha a pena, mas eu não sou você. Código legado existe em todo lugar, e o custo de sair de um framework como create-react-app e reescrever tudo é muito maior do que o custo de continuar com algo que as pessoas já conhecem
  • Não sou desenvolvedor web, então qual é exatamente o sentido dessa pergunta? Quer dizer que create-react-app está obsoleto, ou que React está obsoleto?
  • Só queria dizer o quanto me sinto validado por ver que as pessoas agora odeiam CRA
    Eu já odiava desde 2020, quando ainda parecia algo legal

• A ideia de que “agentes não lembram de nada do que fizeram ontem” é um problema solucionável. Dá para usar abordagens de memória e afins. Não é algo universalmente bom, mas está melhorando
  A ideia de que “não se importam se esse código combina bem com o resto do sistema” não bate com a minha experiência. Em geral, código gerado por LLM tende a ficar bem parecido com código semelhante da área relacionada. O código que ele leu para se orientar costuma aparecer quase exatamente igual
  A ideia de que “não se importam se o sistema fica mais fácil de entender ou pior” também é solucionável. Dá para pedir ao LLM que avalie isso e ir reduzindo gradualmente. O que é fácil de entender muitas vezes é uma propriedade não determinística do sistema, então, paradoxalmente, LLMs podem ser uma forma mais fácil de medir isso do que outras ferramentas. Dá para abrir uma nova sessão e perguntar “quanto do sistema alguém precisa entender para compreender este código recém-adicionado?” e otimizar reduzindo esse escopo
  A parte de que “a IA tem uma caixa de ferramentas de boas práticas que talvez não se encaixe aqui” faz sentido porque usar IA muitas vezes se parece com treinar um desenvolvedor júnior que entra num projeto novo com os mesmos ideais. Para um júnior, você explica verbalmente e espera que ele se lembre e aplique esse conhecimento; para a IA, você documenta isso em arquivos como AGENTS.md / CLAUDE.md e esse conhecimento continua lá
  A parte de que “quando você pede review de código vem uma enxurrada de melhorias com as quais você não concorda” no caso do Codex parece estar ajustada para manter a lista pequena, concisa e de alto valor. Outros modelos podem ser diferentes, mas isso também acaba sendo uma questão de instrução. Coisas com as quais você se importa muitas vezes valem a pena ser documentadas, e usar IA faz isso passar a ser necessário

• Metade do problema ao lidar com rockstars é o ego, mas pelo menos um rockstar que deixou código escrito por humanos tinha reflexão e intenção por trás daquilo
  Já os “rockstars” que são só uma casca humana em cima de IA têm a mesma pose — ou até mais —, mas às vezes não entendem completamente nem metade dos problemas que dizem estar resolvendo

• Se você aplicar o máximo possível uma abordagem de programação funcional, criando componentes independentes de contexto que possam ser combinados de formas diferentes, consegue uma alavancagem considerável
  Se você separar blocos de construção individuais, que abstraem detalhes de implementação, das tarefas que dependem de um contexto específico, fica fácil reorganizar esses blocos quando os requisitos mudam ou quando você adota outra abordagem. Além disso, dá para raciocinar sobre cada parte isoladamente sem conhecer o contexto completo da implantação, e entender a lógica de mais alto nível observando como essas partes se encaixam
  Linguagens funcionais oferecem uma boa base para trabalhar com LLMs, porque naturalmente levam a escrever código de uma forma que limita o contexto. Isso ajuda tanto o modelo quanto os usuários humanos, ao reduzir o escopo necessário para entender uma funcionalidade específica do programa