- Já faz cerca de 2 anos que ferramentas de assistência à programação baseadas em LLM foram lançadas
- Alguns desenvolvedores relatam que a produtividade aumentou em até 5 a 10 vezes
- Porém, não há evidências claras de que a produtividade de toda a indústria de software tenha aumentado de 5 a 10 vezes
- Na prática, em tarefas que vão além de adicionar funções simples e boilerplate a um codebase, as ferramentas de LLM se mostram difíceis de usar
- A maioria dos programadores não sabe como usar ferramentas de LLM de forma eficaz ou não tem interesse nisso
Por que o ganho de produtividade parece concentrado em usuários específicos
- Se a produtividade realmente aumentou de 5 a 10 vezes, é muito provável que isso esteja restrito a uma minoria de usuários avançados ou desenvolvedores experientes que sabem lidar bem com LLMs
- Não há sinais de que toda a indústria de software esteja entregando de repente muito mais recursos úteis ou apresentando uma melhora perceptível de qualidade
- O autor diz que quase não sentiu o impacto dos LLMs nos últimos 1 a 2 anos
Que tipos de projetos os LLMs realmente tornaram possíveis?
- Não está claro quais projetos foram viabilizados pelo desempenho dos LLMs
- Mesmo nos resultados de pesquisa, quase não aparecem casos concretos (refatoração de COBOL é praticamente o único exemplo)
- Até produtos baseados em LLM de laboratórios de AGI não mostram resultados particularmente impressionantes
- Ficam no nível de oferecer funções básicas, como upload de PDF em uma caixa de diálogo
- Falta capacidade de fazer o LLM interagir de forma fluida com diferentes tipos de software e dados
Pergunta: existe alguma área em que a produtividade realmente aumentou?
- Não há evidência clara de quais projetos foram lançados mais rápido graças aos LLMs
- Não se vê nenhum sinal de uma área específica do ecossistema de software ter crescido 10 vezes
O que se quer são evidências práticas e claras
- Informações dos tipos abaixo não são úteis
- Afirmações vagas sobre ganho de produtividade de 10 vezes
- Menções a indicadores econômicos abstratos ou aumento da produção de código
- Exemplos simples de geração de ferramentas ou recursos baseados em LLM
- Exemplos triviais como "fazer um clone de Snake com ChatGPT"
Teoria: talvez os LLMs não estejam aumentando de fato a produtividade
- Pode haver perda de tempo corrigindo e resolvendo problemas em código gerado por LLM
- Quando um grande codebase gerado por LLM ultrapassa certo nível de complexidade, ele pode se tornar impossível de corrigir e acabar precisando ser reescrito do zero
- Mesmo quando os LLMs criam software novo, há grande chance de isso se limitar a ferramentas de uso único ou código de demonstração que ninguém usa
- Mesmo em software realmente útil, o aumento no volume de código pode trazer recursos desnecessários ou mais bloatware
- Pode ser que programadores estejam sendo enganados pela experiência "mágica" de obter resultados imediatos com LLMs
Faixa realista de ganho de produtividade
- Pela experiência do autor, os LLMs só são úteis em casos específicos como
- escrever funcionalidades triviais
- ajudar no aprendizado de uma biblioteca ou codebase específico
- realizar refatorações simples
- O ganho de produtividade mais provável fica em torno de 10% a 30%
- Parece difícil maximizar a produtividade antes do surgimento de uma AGI (inteligência artificial geral)
[Comentário de Richard Horvath]
Casos em que um LLM pode trazer ganho de velocidade de 10 vezes em situações específicas
- Escrita de scripts pequenos e independentes
- Mostra grande efeito ao escrever tarefas simples (ex.: script bash para manipulação de arquivos, código VBA para Excel)
- Dá para escrever facilmente com uma descrição curta e também é fácil de validar
- É possível produzir algo mesmo sem conhecimento profundo da linguagem
- Não é preciso considerar manutenção, modularização, testes unitários etc.
- É especialmente eficaz em tarefas relacionadas a expressões regulares (regex)
- Maior velocidade de aprendizado ao trabalhar em uma stack desconhecida
- Permite entender rapidamente classes e métodos de bibliotecas novas
- Mesmo quando o código não funciona por completo, fornece uma abordagem para resolver o problema
- Reduz drasticamente o tempo antes gasto procurando documentação ou aulas
- Porém, o código gerado ainda precisa ser corrigido e refatorado manualmente
Os tipos de pessoas que provavelmente relatam aumento de produtividade de 10 vezes
- Quando têm pouco conhecimento de desenvolvimento
- Se a habilidade básica de programação é fraca, o código produzido com ajuda de LLM pode parecer muito melhor do que antes
- Porém, nesse caso, é grande a chance de o código de LLM ter efeitos negativos no longo prazo
- Quando precisam escrever muitas soluções pequenas e independentes
- Automação de Excel ou escrita de shell scripts em DevOps são casos em que o LLM é especialmente útil
- Quando precisam experimentar stacks e bibliotecas diferentes com frequência
- Mais do que trabalhar a longo prazo em uma stack específica, isso se aplica a trabalhos centrados em experimentação
- Quando ocorre o efeito de ancoragem (Anchoring Effect)
- Como o LLM gera resultados imediatos em certas tarefas, as pessoas podem superestimar isso como ganho de produtividade de longo prazo
[Comentário de Davidmanheim]
- Do ponto de vista de quem programa em empresas comuns e da gestão, o ganho de produtividade com LLM pode ser inevitavelmente limitado na prática
- Isso pode ser explicado pela Theory of Constraints:
- Suponha que antes o trabalho era concluído por meio do seguinte processo:
- Analista de negócios (Business Analyst) → leva 1 dia
- Testador de QA → leva 1 dia
- Programador → leva 1 dia
- Mesmo que a produtividade do programador dobre ou aumente 5 vezes, o tempo total do trabalho não diminui
- Como as outras etapas (análise de negócio e QA) viram gargalos, a velocidade do processo inteiro permanece a mesma
- É necessária uma reconfiguração dos processos da empresa
- Para aproveitar ao máximo o ganho de produtividade dos LLMs, é preciso reorganizar o processo como um todo
- Porém, hoje isso só começou a acontecer em algumas empresas
[Comentário de faul_sname]
- Com LLMs, houve experiência especialmente positiva na geração de mockups de UI:
- Antes, a criação de mockups de UI consumia cerca de 10% do tempo total de trabalho
- Com LLMs, a velocidade de criação desses mockups ficou cerca de 5 vezes maior
- Porém, o tempo total de trabalho em si não diminuiu
- Em vez disso, houve grande melhora no nível de detalhe e na interatividade dos mockups
- Ficou possível fazer mais iterações e, no fim, a qualidade do produto melhorou
- "Código que vai ser descartado" não significa necessariamente código inútil
- Mesmo protótipos ou provas de conceito podem contribuir para a criação de um produto final melhor
- Além disso, LLMs fornecem respostas para erros específicos que são difíceis de achar em motores de busca
- Exemplo: "como resolver um erro ocorrido em uma tarefa rodando em uma stack xyz"
- Podem ajudar no debugging em situações com uma stack específica e configurações de Kubernetes
- O aumento total de produtividade é avaliado em cerca de 10% a 30%
- Mas a produtividade não melhorou de maneira uniforme em todos os tipos de trabalho
- Ganho radical de velocidade em tarefas específicas (ex.: mockups de UI, debugging etc.)
- Quase nenhum resultado em código complexo ou legado
- O ganho é mais marcante no início do projeto, e o efeito diminui em fases complexas de manutenção
- Portanto, o limite aqui não seria falta de agência (agency), mas um problema de gerenciamento de contexto (context management)
[Comentário de Noosphere89]
- Citando a visão de Ajeya Cotra, ele destaca os seguintes pontos sobre o efeito dos LLMs na produtividade de programadores:
- A produtividade da IA em tarefas de programação é maior do que o esperado
- A IA está tendo resultados consideráveis em tarefas de programação
- Porém, em tarefas fora da programação, o desempenho cai bastante
- Por isso, o impacto industrial total da IA ainda é limitado
- Links para falas relacionadas de Ajeya Cotra
- Sobre a afirmação de que "para resultados de longo prazo é preciso AGI"
- Na trajetória atual de avanço da IA, há menos capacidade geral (Generality) do que se esperava
- O desempenho da IA costuma melhorar muito em tarefas específicas ou mostrar fraquezas em áreas específicas
- Por causa desse desequilíbrio de desempenho, o conceito de AGI (inteligência artificial geral) pode ser menos útil do que se imaginava
[Comentário de yo-cuddles]
- Exemplo de uma pessoa no meu escritório que trabalha com automação robótica de processos (RPA)
- Ele insiste fortemente que é muito mais produtivo
- Mas, na prática, trabalha de forma ineficiente e pouco confiável, fazendo os outros perderem tempo corrigindo o que ele fez
- Os colegas tentam excluí-lo do workflow
- As pessoas não medem bem a própria produtividade e tendem a perceber apenas certos ganhos ou perdas:
- Foco em resultados visíveis
- Quando uma tarefa é concluída rapidamente com automação, a sensação imediata de realização é grande
- Como o resultado rápido aparece de imediato, ele é percebido como efeito positivo
- Custos de longo prazo são difíceis de perceber
- O custo em tempo que aparece depois da tarefa não é facilmente rastreado
- Especialmente quando outra pessoa corrige o problema, esse custo quase não aparece
- Mesmo que erros gerados pela automação sejam corrigidos, a perda de tempo causada por eles é difícil de sentir
- Os problemas causados por código gerado por LLM são difíceis de perceber pelos seguintes motivos:
- Quando surge um bug, é difícil rastrear com precisão que a causa foi código gerado por LLM
- Outra pessoa pode desperdiçar tempo extra no processo de correção
- Muitas vezes não se percebe a causa raiz do problema nem que ela veio do uso da ferramenta de automação
- A sensação de "terminei rápido graças à automação" é forte, mas o "tempo perdido por causa da automação" é difícil de sentir
- Embora o uso de LLMs tenha se tornado comum, ainda não se vê claramente um aumento de produtividade em toda a indústria
- As pessoas dizem ser "2 vezes mais produtivas", mas é bem possível que, na prática, a produtividade tenha até caído por causa de problemas ocultos
- Ou seja, como o tempo e os recursos gastos na resolução de problemas não ficam visíveis, cria-se uma percepção exagerada de resultado
6 comentários
Parece bem parecido com a minha experiência.
Em casos como os acima, economizei bastante tempo. Muitas vezes isso também não era fácil de encontrar só com a combinação Google + Stack Overflow, e no Stack Overflow em especial, quando havia alguma resposta, sempre apareciam muitos questionamentos nos comentários, ou diziam que era uma forma de implementação de versão antiga e que não deveria mais ser usada, então havia muitas situações realmente irritantes...
Parece que a produtividade 10x aparece na hora de fazer prototipagem.
Para mim, está bem agradável.
> A maioria dos programadores não sabe como usar ferramentas de LLM de forma eficaz ou não tem interesse nisso
Surpreendentemente, muitos desenvolvedores ao meu redor não se interessam por tecnologia. Eles passam a maior parte do tempo consumindo mecanicamente shorts do YouTube, novos ou repetidos.
Opiniões do Hacker News
Trabalho em uma empresa de tecnologia popular de Seattle, e o uso de IA está sendo imposto. A liderança está monitorando o quanto os desenvolvedores usam IA e até me perguntou pessoalmente por que eu não a uso mais. Acredito que é importante usar a ferramenta certa para a tarefa certa, e a IA nem sempre é adequada
Existe um velho ditado de que os últimos 10% de um projeto de software consomem 90% do tempo. A IA é útil nos primeiros 90%, mas não ajuda nos últimos 10%
Na FAANG, usamos LLM integrado ao IDE e há um leve efeito positivo
Como exemplo de um desenvolvedor que de fato teve uma melhora de 10x, há o caso de Pieter Levels, que codificou um simulador de voo multiplayer 3D em poucos dias
Tentei usar LLM para gerar código, mas no começo minha produtividade caiu
Faço parte da equipe que desenvolve o Copilot Autofix no GitHub, que fornece sugestões de correção com base em alertas do CodeQL
A qualidade das respostas de assistentes de código com LLM é fortemente afetada pela capacidade de comunicação do programador
A suposição de que a produtividade em software não aumentou de 5x a 10x pode estar errada
Acho que há um erro de tradução no último item do resumo de opiniões do Hacker News, “A suposição de que a produtividade do software não aumentou de 5 a 10 vezes pode estar errada”. Pelo texto original, um resumo mais neutro seria algo como: “Dizer que a produtividade do software aumentou de 5 a 10 vezes se baseia em premissas equivocadas sobre ganho de produtividade”.