Escrever código nunca foi o verdadeiro gargalo
(ordep.dev)- Em desenvolvimento de software, o gargalo não está em escrever código, mas em diversos processos centrados em pessoas, como code review, transferência de conhecimento, testes, depuração, colaboração/comunicação
- Graças aos LLMs, a geração de código em si ficou muito fácil, mas o custo e a carga de entendimento, validação e confiança aumentaram ainda mais
- A geração rápida de código impõe mais carga a revisores, integradores e responsáveis pela manutenção, e a velocidade do time como um todo não acelera de fato
- Entender o código é a parte mais difícil, e mesmo que um LLM gere o código, a qualidade não é garantida sem confiança e contexto compartilhado no time
- LLMs são poderosos para prototipagem e automação, mas não substituem os fundamentos do desenvolvimento de software, como design cuidadoso, revisão e contexto compartilhado
O verdadeiro gargalo na escrita de código
- Há anos, a própria tarefa de escrever código não era o gargalo da engenharia de software
- Os gargalos reais surgem em code review, mentoria e transferência de conhecimento por meio de pair programming, testes, depuração e no custo da colaboração e da comunicação
- Gestão de tickets, reuniões de planejamento, reuniões ágeis e outros procedimentos complexos tornam o ritmo ainda mais lento
- Esses processos necessários para garantir qualidade exigem, na prática, muito mais tempo e reflexão do que a escrita do código em si
- No entanto, graças aos LLMs, o custo de gerar código funcional está convergindo para zero
- Mas o custo de entender, testar e estabelecer confiança no código está ficando ainda maior
- A velocidade da implementação inicial aumentou, mas mais código passou a exigir revisão/integração/manutenção, ampliando a carga
LLMs mudam a natureza do trabalho — não o eliminam
- Ferramentas de LLM como Claude aumentam a velocidade da implementação inicial, mas no fim acabam despejando mais código no sistema em menos tempo, o que impõe uma carga maior a quem faz review e manutenção
- Essa carga se intensifica especialmente nas situações a seguir
- Não está claro se quem submeteu o código realmente entende bem o que enviou
- O código gerado segue padrões pouco familiares ou viola convenções existentes
- Condições de contorno e efeitos colaterais não intencionais não aparecem de forma clara
- Com isso, mesmo que produzir código fique mais fácil, a dificuldade de validá-lo aumenta e, no fim, a velocidade do time como um todo não melhora
- Já existia entre desenvolvedores a piada sobre “engenharia de copiar e colar”, mas com LLMs esse fenômeno foi muito ampliado
Entender código é a verdadeira dificuldade
> “O maior custo do código não é escrevê-lo, mas entendê-lo”
- Graças aos LLMs, a produção de código em si acelera, mas inferir o comportamento, encontrar bugs sutis ou garantir manutenção de longo prazo não fica nem um pouco fácil
- Isso fica ainda mais difícil quando o revisor não consegue distinguir entre código gerado e código escrito manualmente, ou quando é difícil entender por que determinada solução foi escolhida
O time ainda depende de confiança e contexto compartilhado
- O desenvolvimento de software é, por natureza, baseado em colaboração e depende totalmente de entendimento compartilhado, alinhamento e mentoria
- Quando o código é gerado mais rápido do que a equipe consegue discutir e revisar, o time pode acabar acreditando por engano que a qualidade já foi validada, mesmo sem ter realmente confirmado isso
- Isso aumenta a carga psicológica sobre revisores e mentores, e a velocidade do time inteiro pode desacelerar de novas maneiras
LLMs são poderosos, mas não resolvem o essencial
- LLMs têm grande valor para prototipagem rápida, scaffold e automação, mas não eliminam a necessidade de pensamento claro, revisão cuidadosa e design aprofundado
- O custo de escrever código caiu, mas o custo de o time entender o código em conjunto e atribuir significado a ele não mudou
- O verdadeiro gargalo ainda está em "entendimento e colaboração"
7 comentários
Sou exatamente o tipo de desenvolvedor a quem faltam as habilidades apresentadas neste texto e que depende fortemente de LLMs.
Como me falta conhecimento técnico, estou numa situação em que é difícil trabalhar de acordo com a WBS sem IA...
Mesmo assim, o que eu poderia fazer para reduzir pelo menos o tempo de revisão dos desenvolvedores mais experientes..?
De quebra, seria ótimo se eu também pudesse acumular conhecimento..
Para reduzir o tempo de review, você mesmo precisa decidir e ser capaz de explicar em que contexto o código que escreveu surgiu e, entre várias formas de implementação, por que escolheu justamente aquela. Para isso, é importante praticar o item 3. de forma consistente, seja no fim de semana ou no tempo livre, e também vale a pena explorar aleatoriamente bibliotecas conhecidas ou códigos que outras pessoas publicaram no GitHub, analisando coisas como a estrutura do código e o estilo de implementação.
Muito obrigado pelas gentis palavras!!
Mesmo assim, vendo a redução de pessoal, dá um desânimo... Como é que 4 pessoas vão tocar 12 projetos? E ainda por cima uma delas também fazendo gestão...
Puxa, você deve estar passando por muita coisa.
Comentários do Hacker News
Como mentor experiente, ao orientar estagiários ambiciosos, mas ainda imaturos, observei casos em que eles despejavam em um dia o equivalente a uma ou até duas semanas de código. Mas meu trabalho acabou ficando ainda mais difícil do que antes. Na hora de revisar o código, os estagiários não refletiam o suficiente sobre o que escreveram, então meu feedback não era bem assimilado. Bugs simples ou problemas triviais quase desapareceram, mas os problemas que restaram ficaram mais sutis e complexos, e muito mais difíceis de explicar. Além disso, começaram a surgir tipos totalmente novos de bugs que eu nunca tinha visto. À primeira vista, o código parece normal, mas na prática não funciona de jeito nenhum; muitas vezes parece acabado, mas já está quebrado desde o básico. Juniores que trabalham junto com LLM tendem, em vez de entregar código simples e que valha a pena discutir, a produzir de uma vez código complexo que parece pronto, mas causa problemas de colaboração e manutenção em vários aspectos. No fim, parece que o método tradicional de “melhoria incremental”, refinando um PR até chegar à qualidade final, deixou de funcionar direito. Quando se dá feedback, em vez de corrigirem o PR original, às vezes eles propõem uma abordagem totalmente nova — frequentemente criando outro conjunto de problemas inéditos. Por isso, os sêniors acabam gastando muito mais tempo nesse PR do que os juniores. Do lado dos juniores, eles podem até sentir que estão sendo muito produtivos, mas também surge o fenômeno de o feedback do revisor sênior deixar de ter aquele tom caloroso ou encorajador de antes. No fim das contas, exigir muitos casos de teste foi o que teve algum efeito, mas até esses testes batem no limite por causa de problemas parecidos
Ao ver esse tipo de código que “parece pronto, mas não funciona de jeito nenhum”, lembrei de um projeto internacional de desenvolvimento de software de 250 mil dólares pelo qual passei no passado. Pelo documento de especificação, parecia que tudo estava certo, mas na prática era um sistema completamente inconsistente. Ficaram obcecados em interpretar a especificação e deixaram passar o que era senso comum, então acabamos descartando o projeto inteiro imediatamente. É impressionante que esse tipo de coisa agora esteja sendo automatizada e praticamente gratuita graças aos LLMs
Concordo completamente com esse problema. Pela minha experiência pessoal, com LLM é possível gerar milhares de linhas de código muito rápido, mas o trabalho realmente difícil é revisão de código, correção de bugs, verificação de vulnerabilidades de segurança, refatoração e remoção de código desnecessário. No fim, muitas vezes codar diretamente foi mais produtivo. O uso mais realista de LLM é para autocompletar ou gerar trechos simples. Se um júnior usar LLM no meio do processo e eu ainda tiver que intermediar isso, a eficiência parece cair ainda mais. Quem hoje sente que está sendo mais produtivo com LLM talvez esteja pulando justamente essas tarefas importantes, ou simplesmente nem se importando com elas. Na prática, só uma minoria preocupada com a qualidade do produto acaba carregando o fardo de lidar com esse volume enorme de código. Às vezes essas pessoas são vistas como desnecessariamente exigentes, mas na verdade são os verdadeiros protagonistas que tentam entregar o melhor produto possível ao usuário. Não vejo uma solução clara; na verdade, parece que a situação só vai piorar. Desenvolvedores treinados usando apenas LLM continuarão entrando no mercado, e as empresas que criam essas ferramentas continuarão fazendo marketing exagerado. No final, só aumenta o peso de manter a qualidade
Também estou passando por esse fenômeno de
effort inversion, em que os sêniors colocam mais esforço em um PR do que os juniores. No meu caso, autores de textos de RP usam IA para escrever posts de blog ou releases, e quando eu, como especialista no assunto, recebo o material, meu tempo de trabalho aumenta 3 ou 4 vezes para corrigir alucinações e erros de IA. O trabalho deles deveria me dar suporte, mas agora sou eu que tenho de ajudá-los. E como as alucinações da IA mudam toda vez, o sofrimento é sempre novo. Já avisei até executivos sobre isso, e se continuar assim, parece que metade da equipe de RP vai desaparecer no ano que vem. Se o papel deles é copiar um email, colar no ChatGPT e me mandar de volta, então eu mesmo posso fazer issoFiquei curioso se você poderia explicar melhor a parte de “durante a revisão, meu feedback não foi bem assimilado”. Estou passando por um problema parecido, então, se houver alguma solução ou insight, gostaria que compartilhasse
Acrescentando minha visão: a geração anterior construiu naturalmente uma compreensão profunda da estrutura e do design de software por meio de refatoração e testes unitários. Mas, se no futuro o LLM também gerar os testes unitários, o desenvolvedor pode perder oportunidades de autorreflexão e aprendizado, como se perguntar “do que eu preciso?”, “qual é a forma mais simples de fazer isso?”. Para mim, é aí que está a diferença entre “programador”, “engenheiro” e “arquiteto”. LLM ou
vibe codingjamais cultivam esse tipo de mentalidade. Em linguagens com pouca carga sintática, como Go, esses erros de design aparecem com mais facilidade na revisão. A estrutura de testes unitários em Go é útil para diagnosticar a complexidade do código. No fim, precisamos de métodos melhores de teste e revisão. Fuzz testing, testes unitários e testes de integração não bastam. Acho que precisamos de um framework de testes automatizado que consiga verificar logicamente se os ramos do código estão sendo realmente chamados e se as condições de satisfação estão sendo atendidasGraças aos LLMs, o custo de introduzir software novo está chegando perto de zero, mas o custo de entender esse código em profundidade, testá-lo e confiar nele parece mais alto do que nunca. Ainda assim, pela minha experiência, não acho que o código gerado por LLM seja tão pior assim do que muito código antigo deixado por gente que já foi embora e sobre o qual nem dá para fazer perguntas direito, ou código que fica circulando pela internet. Pelo contrário, LLM não sente preguiça de escrever testes nem deixa passar coisas por estar cansado, como humanos fazem. Minha filosofia parte do princípio de que “todo código é dívida potencial”. Por isso, não me preocupo tanto com a confiabilidade do código em si. De fato, já consegui fazer uma codebase enorme funcionar usando IA — desde que o domínio pudesse ser validado e houvesse muitos testes e iteração. Em resumo, os LLMs aceleraram a produção de código, mas a atividade intelectual de programar em si parece ter ficado menos estimulante, e sinto meu cérebro ficando mais preguiçoso junto. Em vez disso, estamos entrando numa era em que o trabalho mental da etapa anterior, como definição de requisitos e design, se torna muito mais importante
Mesmo sem LLM, a indústria já não sofria de “falta de código”, mas de um limite de velocidade de desenvolvimento causado pela demanda do mercado e pelas restrições de capital. As ferramentas ficaram boas demais, e codar em si deixou de ser o ponto central. O ambiente atual é completamente diferente do começo de tudo. Lembrei de uma história dos tempos em que Bill Gates era adolescente, quando a simples capacidade de “saber programar” era um recurso escasso. Uma empresa estava com tanta pressa que contratou Gates, de 16 anos, e Paul Allen, e ficou impressionada só porque eles conseguiam escrever código rapidamente. Hoje, a questão mais importante é “o que vamos desenvolver, e existe um negócio viável nisso?”
Vídeo relacionado
Concordo com a afirmação de que código não era o gargalo por causa da demanda de mercado. Antes do boom da IA, Marc Andreessen também disse que “há capital de sobra, mas faltam boas ideias para investir”. Não acho que isso reflita perfeitamente a realidade, mas pelo menos, olhando os dados, a fala dele parece crível
Como naquela velha história de Bill Gates, a capacidade de escrever código de alta qualidade e entendê-lo profundamente continua sendo um recurso raro. A diferença, em relação ao passado, é que a indústria já não parece valorizar tanto essa capacidade
Do ponto de vista de análise de impacto da IA, temos a tendência de superestimar demais a eficiência. Mas a economia real tem gargalos em estruturas muito mais complexas do que isso. Mesmo que a produção de código aumente 100 vezes, não está claro se isso será realmente útil
Ultimamente, quando vejo relatos desse tipo, tudo parece muito deprimente. Se um júnior entrega um bloco gigantesco de código que não funciona, sem testar nem validar por conta própria, sem simplificar nem refinar, e ainda sem documentação, comentários ou explicação, então isso por si só já pode ser descrito como “uma versão do LLM instalada em um humano”. No fim, o importante é pensamento crítico e senso de responsabilidade pelo resultado. Aliás, acho até que um LLM tem mais chance de responder fielmente ao feedback do que um engenheiro de software júnior tradicional
Eu também já achei que escrever código era o gargalo, mas depois de 10 anos percebi que a verdadeira dificuldade é alinhar tecnologia ao negócio. Mesmo em ambientes como B2B ou SaaS, com pilhas complexas de código que variam de cliente para cliente, se a tecnologia estiver corretamente alinhada ao negócio, tudo flui bem. Hoje a tecnologia já amadureceu o suficiente; agora a questão central é o “ego” do desenvolvedor e a capacidade de focar no valor para o cliente. É preciso pensar no que o cliente realmente quer, se ele pagaria por isso, e até se uma interface web é mesmo necessária. Funcionalidades “brinquedinho de gato” que o desenvolvedor faz para satisfação própria são a verdadeira causa do aumento de custos em nuvem. O mais triste é que nem incentivos agressivos, nem stock options, nem salários altos resolvem esse problema essencial. É preciso que exista alguém — nem que seja uma única pessoa — com senso de missão para fazer um bom software e vontade de falar diretamente com o cliente para fazer isso direito
O momento em que LLM realmente ajudou na organização foi em projetos pessoais ou paralelos. Ao desenvolver um app para resolver um problema pequeno, a falta de tempo faz com que escrever código se torne de fato um grande gargalo. Nesses projetos, o aproveitamento de LLM é de 100%
Concordo 100%. Se eu investir 1 ou 2 horas por dia no Claude code, no fim do fim de semana aparece um resultado utilizável na prática. Com pouco tempo investido, fica fácil validar ideias ou fazer experimentos. Acho que essas ferramentas de LLM realmente geram enorme valor até em organizações profissionais. Também dá para prototipar rapidamente ferramentas de gestão e sistemas de automação que normalmente nunca seriam construídos por falta de tempo. Se um colega precisa de uma query de banco de dados ou de uma automação simples, basta pedir ao Claude, revisar e colar direto. O objetivo do meu projeto mcp-front[0] também é justamente dar suporte para que pessoas que não são engenheiras consigam resolver sozinhas tarefas repetitivas da própria área
GitHub do mcp-front
Sinceramente, no estágio atual da minha carreira, é difícil me dedicar por semanas seguidas, e por causa de muita experiência acumulada eu sempre levo em conta requisitos não funcionais e a perspectiva de longo prazo. Mesmo pulando coisas como testes, no fim ainda há muita coisa em que continuar pensando
Lembrei da famosa frase de Robert C. Martin de que “o tempo gasto lendo código é mais de 10 vezes maior do que o tempo gasto escrevendo”
Citação relacionada
Infelizmente, em muitos casos o estilo de clean code dele, na prática, fragmenta o contexto e torna ainda mais difícil entender a intenção
Pior ainda: talvez o tempo de escrita diminua, mas o tempo de leitura aumente, e a carga total de trabalho não diminua
Ninguém mencionou o texto de Joel Spolsky de 2 de outubro de 2000
Joel on Software: Painless Functional Specifications (2000)
O verdadeiro gargalo não é o código, mas a especificação funcional (
spec). É mais importante criar especificações claras de como o software deve funcionar, em inglês, diagramas, user stories etc. Se a especificação estiver bem definida, um LLM pode muito bem gerar de uma vez uma solução excelente, testes e testes de integração. Se ficar grande demais, a especificação não deveria ser gerenciada em um único arquivo Markdown, mas dividida por funcionalidade, como uma wiki, com links e referências. A verdadeira vantagem competitiva não está na dificuldade de implementação, mas em quanto esforço foi colocado na especificaçãoO autor não concorda com a opinião apresentada no texto. Da perspectiva de grandes empresas, talvez código não seja o gargalo, mas, para startups, os recursos são limitados e planejamento eficiente era mais importante. Ou seja, em muitos casos, o maior gargalo era justamente produzir código que realmente funcionasse. No fim, não dá para generalizar o quanto AI/LLM é útil nesse tipo de discussão. Para algumas equipes, código era o gargalo; para outras, não
Como todo mundo sabe, o código gerado por LLM muitas vezes é uma bagunça e chega a ser impossível de revisar. Quando o código com LLM enviado por um júnior parece estranho e você pergunta o motivo, ele mesmo não sabe e responde que foi o LLM que fez. No fim, essa tendência só aumenta o “ruído” e o overhead da manutenção de código. Se não for possível evitar a adoção de LLM, então revisão e manutenção também acabarão tendo que ser entregues ao LLM. Claro, o resultado será um espaguete ainda mais complexo. Mas, realisticamente, na maioria dos negócios a qualidade simplesmente não importa tanto assim, e, se o código do LLM funcionar mais ou menos, isso já basta. Ou então basta continuar empilhando mais LLM em cima até resolver o necessário de algum jeito