- Ferramentas de codificação com IA prometem aumentar a velocidade de desenvolvimento, mas o gargalo real não está na escrita de código, e sim nos processos organizacionais ineficientes
- Ao aumentar o volume de código produzido, o acúmulo nas etapas fora do desenvolvimento — como espera por review, atraso em deploy e requisitos pouco claros — se intensifica, e o tempo de ciclo real pode até aumentar
- Segundo a Theory of Constraints de Eli Goldratt, otimizar uma etapa que não é o gargalo não acelera o sistema; na verdade, pode piorá-lo
- Quando nem mesmo quem “escreveu” o código gerado por IA o entende completamente, surge um risco estrutural em que a superfície de resposta a incidentes aumenta e diminui o número de pessoas capazes de raciocinar sobre o sistema
- A vantagem competitiva não vai para a equipe que escreve código mais rápido, e sim para a equipe que descobre o que precisa ser construído e entrega isso nas mãos do usuário
O início de uma otimização errada
- Surgiram anúncios dizendo que, com a adoção de assistentes de código com IA, o volume de código gerado aumentou 40%
- Mas falta a pergunta: “velocidade em direção a quê?”
- Quando se investe recursos em uma etapa que já é rápida (escrever código), o sistema como um todo fica mais lento
- Acelerar uma parte que não é o gargalo faz acumular estoque de código inacabado e gera queda de qualidade e confusão
Otimizar fora do gargalo piora ainda mais o sistema
- O ponto central da Theory of Constraints, apresentada por Eli Goldratt no romance The Goal de 1984: todo sistema tem exatamente um gargalo, e a vazão total é determinada pela capacidade desse gargalo
- Quando se otimiza uma etapa que não é o gargalo, o sistema não fica mais rápido; apenas acumula estoque de trabalho inacabado, o que leva a aumento do lead time, confusão e queda de qualidade
- Em termos metafóricos: mesmo que a estação A produza widgets mais rápido, se a estação B — que é o gargalo — continuar na mesma velocidade, isso equivale apenas a formar uma pilha de widgets não processados entre A e B
O que “3x mais output de código” realmente provoca
- Desenvolvedores passam a produzir PRs mais rápido do que nunca, mas como o número de reviewers continua o mesmo, os PRs ficam parados na fila de revisão por um, dois ou até sete dias
- O autor já mudou de contexto para a próxima funcionalidade assistida por IA e, ao responder a comentários de review sobre um código escrito 8 dias antes, mal se lembra daquele código
- O volume de revisões fica tão alto que surgem reviews do tipo rubber stamp, aprovados sem leitura de verdade
- O CI leva 45 minutos, falha por causa de testes flaky e precisa ser executado de novo; o pipeline de deploy fica aguardando aprovação manual de alguém que está em reunião, e a funcionalidade fica esquecida em staging por 3 dias
- O desenvolvedor já abriu mais 2 PRs, o WIP (Work In Progress) dispara e todo mundo toca 6 coisas ao mesmo tempo sem concluir nenhuma
- Produz-se mais código, mas lança-se menos software; o tempo de ciclo piorou, mas o dashboard mostra aumento de 40% na produtividade
- Há ainda um risco adicional no código gerado por IA: quem “o escreveu” na prática não escreveu, apenas gerou por prompt e fez uma revisão superficial; então, às 2 da manhã, durante um incidente em produção, nem a pessoa de on-call nem quem escreveu o prompt conseguem explicar aquele código
- Quando há mais código e menos entendimento, isso não é ganho de produtividade; é uma bomba-relógio com um dashboard mais bonito
Gargalo real 1: não saber o que construir
- O PM não conversa com usuários reais há 2 meses, e os requisitos chegam em 3 linhas num ticket do Jira e um link do Figma
- Engenheiros tomam 50 microdecisões por dia (comportamento, edge cases, tratamento de erro) na base da adivinhação, sem especificação clara
- Houve equipe que passou 6 semanas desenvolvendo uma funcionalidade com base no que um vendedor disse no Slack sobre o que um potencial cliente talvez tivesse comentado numa ligação; esse potencial cliente não comprou, e a funcionalidade foi usada por 11 pessoas (9 delas da QA interna)
- Escrever código mais rápido apenas aumenta a velocidade de construir a coisa errada, automatizando a adivinhação
- O gargalo é o entendimento do problema, e digitar mais rápido não resolve isso
Gargalo real 2: tudo o que vem depois de o código estar “pronto”
- Na maioria das organizações, escrever código representa apenas cerca de 20% de toda a jornada; os outros 80% são tempo de espera em várias filas
- Há casos em que uma funcionalidade levou uma tarde para ser codificada, mas 2 meses para chegar à produção
- Review de PR, CI, staging, QA, review de segurança, aprovação de produto, janela de deploy, rollout canário: uma cadeia longa de handoffs, esperas e filas
- Na maior parte do tempo, o código não está se movendo; está esperando alguém olhar, o pipeline rodar, receber permissão para existir
- Para lançar mais rápido, é preciso encontrar onde o trabalho fica esperando e medir a proporção entre tempo real de trabalho e tempo parado em fila
Gargalo real 3: o ciclo vicioso da falta de confiança no deploy
- Quando os testes são flaky, a observabilidade é ruim e ninguém confia no processo de canário, as equipes passam a ter medo de fazer deploy
- Por medo, agrupam mudanças em releases maiores; isso aumenta o risco, torna o deploy ainda mais assustador e leva a agrupamentos ainda maiores — um ciclo vicioso de medo
- Se você adiciona a isso uma geração de código mais rápida: há mais código, mas a cultura de deploy continua marcada pelo medo, então os lotes ficam maiores e a frequência de releases cai ainda mais
Gargalo real 4: ausência de feedback depois do lançamento
- Depois de criar e lançar uma funcionalidade, não há análise adequada, não há entrevistas com usuários após o release, e ninguém verifica se ela realmente resolveu o problema
- A próxima funcionalidade também é baseada em adivinhação, e a seguinte também; todo o roadmap do produto vira uma sequência de suposições sem feedback
- Aumentar a produção de código só acelera o ciclo de “construir, lançar e dar de ombros”
Gargalo real 5: o calendário é uma parede estrutural
- Às vezes o gargalo não é técnico, e sim reuniões para tomar decisões, acordo de contrato de API entre 3 equipes que não se falam há um mês, ou o backlog de 2 semanas de um arquiteto que é o único ponto de aprovação para todo design importante
- Há processos trimestrais de planejamento que levam 6 semanas, fazendo com que até trabalho urgente precise esperar 5 semanas para começar
- Também existe a situação real em que uma funcionalidade não foi lançada porque estava esperando uma reunião com alguém que está de férias
- Isso é um problema de coordenação, humano e político, sem relação com a velocidade de escrever código
O que fazer no lugar disso
- Mapeamento do fluxo de valor: acompanhe uma funcionalidade da ideia até a produção e registre quanto tempo cada etapa leva e quanto tempo ela fica esperando entre as etapas
- Medição de cycle time: em vez de medir linhas de código, número de PRs mergeados ou story points, meça o tempo entre o commit e o momento em que o usuário realmente pode usar a funcionalidade em produção
- Eliminar estados de espera: se review de PR leva 2 dias, resolva com pair programming, PRs menores, horário dedicado para review ou normas de review assíncrono. Se o deploy espera aprovação manual, automatize ou ao menos troque por um botão no Slack
- Pare de começar e foque em terminar: existe um motivo para limitar WIP; é melhor 3 coisas concluídas do que 10 em andamento. Tudo o que está em progresso tem custo de troca de contexto
- Converse com quem faz o trabalho: os desenvolvedores já sabem onde está o gargalo; eles reclamam disso no stand-up e fazem memes no Slack há meses. Só achavam que ninguém estava ouvindo
Conclusão principal
- Em vez de um VP anunciar “aumentamos o output de código em 40%”, ele deveria dizer: “nossa análise do fluxo de valor mostrou que uma funcionalidade passa em média 9 dias esperando entre etapas, e vamos cortar isso pela metade”
- A vantagem competitiva não vai para a equipe que escreve código mais rápido, e sim para a equipe que descobre o que construir, constrói e entrega nas mãos do usuário
- O gargalo não é o teclado
4 comentários
> Esse potencial cliente não comprou, e a funcionalidade foi usada por apenas 11 pessoas (9 delas eram do QA interno)
rsrs
O pipeline continua o mesmo
parece que os desenvolvedores é que ficaram irresponsáveis
Dá vontade de virar um artesão de software
Comentários do Hacker News
Quando nossa equipe adotou de verdade o desenvolvimento baseado em agentes, fiquei preocupado se a velocidade de codificação aumentaria, mas o tempo de review também cresceria
Ainda não houve uma mudança clara, e como todo mundo ainda está aprendendo o novo workflow, não há dados suficientes
Mas há casos em que codificar rápido é especialmente útil — experimentos de ideias, trabalho repetitivo complexo, implementações simples porém intensivas em mão de obra, tratamento de edge cases depois do happy path etc.
Os agentes funcionam especialmente bem quando estendem diretamente uma branch ou PR já existente
O maior ganho de produtividade é que posso fazer outra coisa enquanto o agente codifica. Por exemplo, faço review de um PR e, quando volto, o resultado está pronto
No começo eu era cético, mas agora estou cautelosamente otimista. Um ganho de 10x é improvável, mas mesmo um ganho de 2x já seria enorme
Isso só vale a pena quando o custo do erro é baixo ou o escopo da mudança é pequeno. Caso contrário, qualidade e satisfação caem, e só o cronograma fica mais apertado
No fim, não é recuperar tempo em paralelo, mas só adiar um pouco menos o trabalho que já estava sendo adiado
Mas fazer outra coisa enquanto o agente codifica dá uma fadiga estranha
A IA é produtiva, mas é um tipo de trabalho totalmente diferente de programar como artesão humano
Um refactoring que eu teria dificuldade de abandonar se tivesse feito com as próprias mãos é mais fácil de avaliar honestamente como “isso não ficou bom” quando foi a IA que fez
Ficar multitarefa o tempo todo leva rapidamente ao burnout. É uma pena que o elemento humano esteja ausente da discussão
Eu nem sempre quero trabalhar em um estado ‘otimizado’
Alguém disse que “entender o problema é o gargalo”, e eu queria perguntar por que digitar rápido não ajudaria a entender o problema
Se você construir a coisa errada rapidamente, talvez encontre o caminho certo mais cedo, não?
Muitas vezes eu percebo o que realmente quero enquanto estou construindo algo. Quanto mais barato fica prototipar, mais forte essa tendência se torna
Claro, no fim isso costuma terminar com a retrospectiva de que “eu deveria ter falado mais com o usuário”, mas isso é outro problema
Em lugares como bancos, no máximo dá para experimentar algo uma vez por semana
Mas a maior parte do software não é assim. Escrever código é apenas uma parte do trabalho todo
Assim como um cirurgião não faz apenas o ato de ‘cortar’, um engenheiro também não se resume a escrever código
Se você está só lapidando código sozinho, isso apenas cria uma confusão maior
Às vezes conversar uma hora com o PM ou com o cliente é muito melhor
A atual febre dos LLMs dá a sensação de que a solução veio antes do problema
Para realmente ganhar velocidade, primeiro é preciso perguntar “qual é o gargalo?”
Quando a gestão assiste a uma apresentação de IA e conclui “isso vai nos deixar mais rápidos”, isso não passa de gestão por vibe (vibe management)
Codificação é a parte mais intensiva em mão de obra e mais automatizável desse processo
Os LLMs podem aliviar bastante essa parte. Especialmente coisas como escrever testes, em que a IA se sai bem
Os desenvolvedores humanos ainda não conseguem abandonar sua obsessão com o código
Na prática, código é apenas uma representação intermediária (IR) da solução
Assim como o GCC não se preocupa com otimizações internas ao converter para assembly, se um agente gerar o código, basta avaliarmos a correção do resultado
Se houver uma especificação clara e um processo repetitivo de revisão, tanto humanos quanto agentes podem produzir a mesma implementação
LLMs não são assim. Eles podem entender errado ou alucinar (hallucination)
Por isso ainda precisam de revisão humana
Agentes muitas vezes escolhem padrões errados ou acumulam dívida técnica
Talvez um dia a própria linguagem de programação desapareça, mas ainda estamos longe disso
O significado pode ser expandido, comprimido ou até desaparecer
Muitas empresas na verdade não querem código bom de verdade
A avaliação interna é feita por “quanto foi entregue em produção”, e se você aponta problemas ouve que está “sendo detalhista demais”
No fim, os stakeholders internos só querem a justificativa de que ‘deu certo’
Cabe ao técnico explicar esse risco
Depois da adoção de IA, a queda de qualidade já está aparecendo de fato
Na nossa empresa, a aprovação de PR também é feita de qualquer jeito, o CI leva 45 minutos e os deploys atrasam dias
Além disso, o uso de IA é proibido. Dizem que a maior parte do código foi escrita por humanos, mas eu tenho minhas dúvidas
O que este texto deixou de fora são duas coisas — (A) usar agentes e otimizar processos são coisas compatíveis, (B) em alguns tickets o código realmente é o gargalo
No fim, o importante não é IA ou não, e sim melhorar o processo para eliminar gargalos
Eu sou desenvolvedor solo. Velocidade de codificação realmente é um problema, porque rouba tempo de outras coisas
Hoje configurei o Claude Code, e agora gasto menos tempo com Google e escrevendo testes
A produtividade não vai subir 10x, mas, como tecnologia de economia de trabalho, isso já tem bastante valor. É como uma lava-louças
Agora a IA escreve até os testes e me avisa sobre edge cases
Não é perfeito, mas a velocidade de lançamento de novas funcionalidades aumentou e eu também ganhei mais tempo
Dizer “não dá para confiar na IA” soa para mim como dizer “não dá para confiar no compilador”
No fim, é um processo em que o humano dá a direção, melhora os prompts e evolui junto
Em startups ou no ambiente de VC, o essencial é resolver problemas de negócio, não codificar mais rápido
Mesmo que a produção de código aumente, não há garantia de que o resultado do sistema como um todo melhore
Como templates ou geradores de código, a velocidade aumenta, mas, a menos que a coleta de requisitos fique 10x mais rápida, 10x de produtividade é impossível
Como analogia, é um pouco inadequada
Como evitar que a IA cometa erros que humanos normalmente não cometem?
Humanos revisam o código de forma lógica, passo a passo, mas a IA não
Mesmo em lugares como a Amazon, ainda que um engenheiro sênior faça o review, review não é um processo feito para capturar todos os bugs
Além disso, quanto mais sênior a pessoa, mais reuniões ela tem e menos contexto de código conhece. Quão eficaz pode ser esse tipo de review?
É ilusão achar que humanos são perfeitos
Estamos exigindo da IA um padrão mais alto do que exigimos de humanos
No fim, o importante é fortalecer o processo de QA. Não se deve deixar os testes nas mãos dos desenvolvedores
Isso me lembrou o livro The Goal, que li no passado. Quando você automatiza uma etapa do processo, a etapa seguinte vira o gargalo
No software é a mesma coisa: mesmo que a geração de código fique mais rápida, isso não significa nada se o processo inteiro não acompanhar
No fim, tudo está subordinado ao objetivo de gerar lucro. Qualidade de código também é apenas um conceito subordinado a isso
Velocidade de escrita de código não é o gargalo em situações de alto risco
Às vezes é melhor planejar devagar e refletir sobre o resultado
Por exemplo, se construirmos sistemas enormes rápido demais, como na indústria de IA, isso pode gerar um risco civilizacional na direção errada
Já num joguinho pequeno feito sozinho no fim de semana, tanto faz. No fim, é a magnitude do risco que determina a velocidade