O gargalo nunca foi o código
(thetypicalset.com)- A Codex criou em poucas horas a primeira versão funcional de um experimento de algoritmo de geração estruturada que a .txt vinha adiando havia mais de um ano, mas a principal mudança foi revelar o gargalo da colaboração, mais do que a velocidade individual de programação
- Quando agentes assumem a implementação, o que desacelera a equipe deixa de ser quem escreve o código e passa a ser a criação de especificações precisas que o agente consiga executar imediatamente, como roadmap, critérios de aceitação e documentos de design
- Quando o custo de escrever código cai, aumentam os protótipos e ferramentas internas que antes não seriam feitos, enquanto a velocidade que os usuários conseguem absorver continua a mesma, tornando mais importante a disciplina de foco para decidir o que não construir
- Agentes podem extrair decisões implícitas e convenções de Slack, PRs, issues, commits e documentos de design para criar uma base de conhecimento, mas não conseguem reconstruir totalmente o contexto compartilhado que humanos acumulam diretamente
- A vantagem dos próximos 10 anos provavelmente estará nas empresas que conseguirem manter coerência organizacional alinhada a um conjunto cada vez menor de decisões, mesmo em escalas de 50, 200 ou 2.000 pessoas, mais do que nas que tiverem o melhor modelo
O gargalo que os agentes de programação mudaram
- O experimento que a .txt vinha adiando havia mais de um ano consistia em testar algoritmos de geração estruturada e alternativas open source, verificando não apenas se “aceita esta string”, mas algo mais próximo de “gera a distribuição correta de tokens”
- Esse experimento continuava no roadmap, mas, após cerca de 30 minutos explicando a abordagem ao Codex, a primeira versão funcional foi criada em poucas horas
- Agentes de programação já estão mudando bastante a forma como indivíduos escrevem código, mas é difícil concluir que ganhos de produtividade individual se traduzam diretamente em aumento da velocidade de toda a indústria de software
- Softwares de grande impacto costumam ser feitos por várias pessoas em colaboração, e a unidade de análise mais interessante não é a produtividade individual, mas sim a colaboração
- Software se parece mais com o resultado que sobra depois que as pessoas negociam o que um sistema deve fazer, e o código, embora importante, é o resíduo do trabalho mais difícil
O roadmap vira o limite
- Em equipes onde agentes assumem a implementação, o que reduz a velocidade é criar especificações com precisão suficiente para que o agente possa pegá-las e executá-las imediatamente
- Roadmaps, critérios de aceitação e “o que realmente queremos” precisam estar claramente escritos em formas como suítes de teste, tickets e documentos de design
- Funcionalidades são implementadas muito rapidamente, e surge uma situação em que, em vez de um engenheiro esperar por outro, espera-se pela próxima especificação corretamente escrita
- O gargalo se desloca de quem escreve o código para quem decide que código deve existir, o que acaba sendo um problema de gestão
Código mais barato exige mais consenso
- Quando o custo de escrever código cai, não significa apenas gastar 10% do esforço para o mesmo resultado; significa aplicar o mesmo esforço a resultados que antes não valiam a pena
- Protótipos que três meses atrás seriam vistos como “perda de tempo” passam a ser feitos em uma tarde, e ferramentas internas sem demanda clara podem ser criadas e depois esquecidas
- A velocidade com que os usuários conseguem absorver funcionalidades tende a permanecer a mesma, quer a equipe lance 10 ou 50
- Como Steve Jobs disse em 1997, “foco é dizer não”, e a Apple reduziu cerca de 70% de sua linha de produtos naquele ano
- Com agentes, a sensação de lançar novas funcionalidades fica mais fácil, então a disciplina de decidir não apenas o que construir, mas também o que não construir, se torna mais difícil
Contexto vira o recurso central
- Negociação e consenso operam sobre um contexto compartilhado dentro da organização
- Esse contexto inclui o que está sendo construído, por que isso importa, o que já foi tentado, quem decidiu o quê e o que é essencial versus o que é apenas vestígio
- As pessoas de uma equipe acumulam contexto naturalmente por estarem na mesma sala, lerem os mesmos canais no Slack e depurarem a mesma falha às 2 da manhã
- A maior parte desse contexto não é documentada, e quando um engenheiro sênior diz em uma revisão de PR “isso vai quebrar a migração”, ele pode estar usando um contexto que não existe em documento algum
- Agentes não conseguem adquirir esse tipo de osmose: não estão na sala, não escutam pela metade uma conversa de planejamento e não carregam a memória de incidentes anteriores
- O contexto que não cabe em prompts, árvore de arquivos, ferramentas e instruções explícitas não está disponível de forma confiável para o agente
- Sem contexto, agentes podem produzir respostas plausíveis para perguntas ligeiramente erradas
- Na .txt, mesmo quando agentes fizeram trabalho útil, na prática havia um humano que já tinha feito o trabalho de contexto, e isso não significa que os próximos 10 engenheiros terão essa mesma visão automaticamente
- O contexto do qual as organizações sempre dependeram de forma implícita agora se tornou um insumo que limita a velocidade, e as pessoas tendem a deixá-lo implícito justamente porque nunca houve um destinatário capaz de ler uma versão explícita dele
O loop em que agentes produzem contexto
- Produzir contexto em um formato facilmente consumível por pessoas é um tipo de trabalho de que as pessoas não gostam
- Agentes têm vantagem em ler sem falhas comentários de PR, issues fechadas, mensagens de commit, documentos antigos de design e arquivos do Slack, extraindo padrões que ninguém havia documentado
- Na .txt, começou-se a construir agentes que rastreiam codebase, issues, PRs e threads para transformar decisões implícitas, convenções e o “por que isso foi feito assim” em uma base de conhecimento
- Essa base de conhecimento registra não apenas “este módulo existe”, mas contextos como “este módulo é estranho porque a migração precisa preservar o comportamento existente” ou “este benchmark é importante porque uma otimização anterior alterou silenciosamente a distribuição”
- Outros agentes usam essa base de conhecimento quando precisam agir sobre o codebase
- A osmose informal antes realizada por humanos é externalizada em uma forma legível tanto por agentes quanto por pessoas
- Agentes que consomem contexto exigem agentes que produzam contexto, e quando esse loop funciona, a organização passa a ter uma base documentada que talvez nunca tivesse produzido por conta própria
- Ainda assim, o quadro produzido por esse loop é sempre parcial
- Como disse Michael Polanyi, “sabemos mais do que conseguimos dizer”, e parte do contexto essencial existe justamente por nunca ter sido posta em palavras, podendo até mudar no momento em que é escrita
- A camada de osmose construída presencialmente por pessoas não pode ser totalmente reconstruída apenas a partir de subprodutos documentados
- O resultado se parece mais com um ponto de partida útil do que com uma reconstrução completa, e ainda é uma questão em aberto se isso basta para gerar efeito cumulativo
O novo fosso está mais na organização do que na tecnologia
- Os vencedores dos próximos 10 anos talvez não sejam necessariamente as empresas com o melhor modelo ou a melhor infraestrutura de agentes, mas aquelas que conseguirem produzir mais por pessoa mantendo alinhamento com um conjunto cada vez menor de decisões à medida que crescem para 50, 200 ou 2.000 pessoas
- Essas empresas são organizações que já sabiam, antes da chegada dos agentes, que o problema mais difícil era a coerência
- Isso é uma questão de cultura e gestão, e sempre foi
- Ferramentas de gerações anteriores como IDE, controle de versão, CI, microsserviços e DevOps prometiam resolver coordenação com ferramentas melhores, mas na prática atuaram amplificando a coerência organizacional que já existia
- Equipes pequenas obtêm coerência quase de graça, então esse efeito de amplificação tende a ser positivo, e uma das razões pelas quais tantas vozes pró-agentes vêm de equipes pequenas é que, no contexto delas, isso está majoritariamente correto
- Depois de certo tamanho, coerência precisa ser criada e mantida, e o efeito de amplificação se torna afiado nos dois sentidos
- Organizações boas ficam melhores, e organizações ruins se deterioram mais rápido
- Agentes são amplificadores muito maiores do que as ferramentas anteriores, e são superestimados como meio de fazer indivíduos escreverem código mais rápido, mas subestimados como meio de externalizar o que uma organização sabe
Agentes como extensão da cultura da empresa
- Agentes podem parecer uma extensão do próprio pensamento, e essa sensação é poderosa
- A tarefa mais difícil é transformar agentes em uma extensão da cultura da empresa
- Para isso, é preciso uma cultura de escrita, uma gestão suficientemente reflexiva para identificar onde ainda é um gargalo de contexto e pessoas que tratem coerência como um resultado real que precisa ser mantido
- O que há de novo é que agora já é possível construir parte dessas coisas
- O loop de ler e extrair é uma dessas formas, e outras podem surgir
1 comentários
Comentários do Hacker News
Ao longo de toda a carreira, engenheiros reclamando de tudo que atrapalhava aquelas horas de estado de fluxo de programação que eles juravam ser a atividade mais essencial e sagrada — reuniões de equipe, rituais ágeis, rastreadores de issues, backlog, Slack, e-mail, revisões de design — e agora que as máquinas escrevem código mais rápido do que eles, de repente começarem a pregar sem a menor vergonha a importância da colaboração e a insignificância do código e de programar... isso me parece engraçado
Não está errado, mas ainda assim é surpreendente a hipocrisia descarada das pessoas que, até um ano atrás, eram as mais antissociais e menos colaborativas de qualquer equipe
De qualquer forma, as duas coisas podem ser verdade ao mesmo tempo: escrever código pode não ser o gargalo, então dá para desenvolver funcionalidades mais rápido do que a velocidade com que elas podem ser lançadas, e ainda assim ser irritante e quebrar o fluxo ser interrompido quando você está fazendo um trabalho que exige concentração profunda
https://en.wikipedia.org/wiki/Group_attribution_error
Reuniões que realmente aumentam a sincronização entre cliente e programador são raras e valiosas. Em organizações grandes, reuniões ritualizadas aumentam pelos motivos errados. As pessoas tentam se enfiar no processo entre cliente e programador para mostrar que existem
Pessoalmente, gosto de reuniões com clientes, usuários finais, designers de UX e stakeholders reais. Detesto reuniões com gente ocupada por política corporativa, que consome banda para ganhar influência interna. Não preciso de mais um gerente intermediário entre mim e meus usuários
No novo mundo, em que escrever código ficou muito rápido e a parte difícil passou a ser entender os requisitos de negócio e técnicos que precisam ser atendidos, a mesma pessoa pode priorizar mais esses rituais e tolerar interrupções enquanto o agente de IA escreve o código
Mudar de ideia quando os fatos da situação mudam não é hipocrisia
Se você estivesse fazendo um projeto criativo com alguém fora de uma empresa, há muitos motivos pelos quais Scrum ou Jira não seriam a primeira coisa em que pensaria. Valorizar colaboração e ainda assim criticar essas coisas é totalmente consistente
A equipe reclama que há trabalho demais e que não consegue fazer nada, então o gerente me coloca lá. Aí, de repente, ninguém quer me passar nada. Estou exatamente no meio disso agora
A equipe diz que está “afogada”, mas ainda encontra energia para afirmar que praticamente tudo que eu poderia assumir é melhor se for feito por eles e que não precisam de ajuda. Para mim tanto faz, posso ficar sentado recebendo. Mas o cheiro é sempre o mesmo
A: não querem admitir que são substituíveis e que o trabalho não é tão único assim, B: não querem admitir que o gargalo não é o processo nem a carga de trabalho, e sim eles mesmos
Acho que engenheiros veteranos já sabiam que a verdadeira causa dos problemas de velocidade sempre esteve mais na organização do que na tecnologia
A incapacidade do negócio de definir um roadmap produtivo e focado sempre foi um problema antigo da engenharia de software. Continuar pulando para o próximo brilho com quase nenhum ROI, enquanto não se resolve a dívida técnica sistêmica, acabou prejudicando várias empresas em que trabalhei no longo prazo
Conheço engenheiros juniores que usam C++ o ano inteiro e ainda assim não entendem
std::unique_ptr, e esse tipo de pessoa sempre é a mais lenta da equipeQuando eu escrevia avaliações de desempenho de engenheiros juniores, o desempenho de fato dependia bastante de velocidade, medida mais ou menos pela quantidade de linhas de código sem bugs escritas em certo período. Um bom júnior recebia uma funcionalidade bem definida e escrevia código bom rapidamente; um júnior ruim recebia a mesma tarefa e escrevia devagar, ou escrevia rápido um código cheio de bugs, criando muito mais trabalho de depuração e reescrita
Quando você entende com clareza a justificativa de negócio, o escopo, as entradas e a saída desejada, o modelo de dados, o design do sistema e o código praticamente surgem naturalmente, ou ao menos ficam muito mais claros
— Melvin E. Conway, 1967
Primeiro, vale pensar se você entende o que são leis de escala como Chinchilla e como aprendizado por reforço com verificação funciona de forma fundamental
Concordo totalmente que a limitação fundamental está em o negócio conseguir se expressar e expressar sua estratégia de forma consistente
Mas a vantagem agora é que dá para fazer protótipos praticamente de graça. Antes era preciso ser extremamente cuidadoso com investimento em pessoal de engenharia; agora dá para tentar muito mais coisas dentro das mesmas restrições de tempo
Quais funcionalidades e correções lançar e quando, e como desenvolver e gerenciar o produto como um todo, sempre foram o verdadeiro desafio, e boa parte dessa estratégia depende de ciclos de feedback que a IA não consegue produzir rapidamente
Ao mesmo tempo, também sinto que líderes do lado do negócio muitas vezes usam a velocidade da engenharia como bode expiatório em vez de assumir responsabilidade pelas más decisões do próprio lado
Normalmente o gargalo é o código, sim, mas não escrever código; é o código em si. Na minha carreira, já tive incontáveis atrasos causados por aplicações lentas
Preciso usar um editor baseado em Eclipse que é lento e trava ou cai periodicamente. Builds levam de 15 a 20 minutos. Também encontro com frequência apps web que levam uma eternidade para processar algo que deveria terminar em no máximo 50 ms
A lista pode continuar indefinidamente. Todo atraso é uma interrupção que destroça minha concentração. Hoje estou em gestão, lidando com dezenas de pessoas e interrupções administrativas, mas ainda escrevo código na empresa
Se o software é lento, ele vira minha prioridade mais baixa. Não me importo com quem isso afete. Se fosse realmente importante, não estaríamos todos reféns desse melaço de software lento que nos puxa para baixo
Código é dívida
Pode ser fácil ver código como ativo, mas no fundo ele é dívida. Parte dos “gargalos” para código novo existe para garantir que a produção gerada seja maior do que a dívida aumentada. Agentes que produzem mais código mais rápido estão produzindo mais dívida mais rápido
Grande parte do entusiasmo e do ceticismo em relação a agentes de codificação gira em torno de saber se o ganho imediato de produtividade — isto é, produção imediata como novas funcionalidades, novos produtos e nova receita — compensa o aumento da dívida de longo prazo. A resposta só vai aparecer daqui a 1 a 3 anos, e vai variar por área
Sob essa ótica, faz algum sentido tentar colocar esses gargalos diretamente dentro do workflow agentivo. Dar ao agente de codificação um contexto extra que valorize uma visão consistente do projeto e possa se opor a novas funcionalidades ou processos sem restrição tem valor
É isso que o texto quer dizer? Uma tentativa de fazer com que algum agente assuma a responsabilidade de gestão de produto, sintetize o máximo possível em uma visão de produto coesa e relembre essa visão ao agente de codificação da forma mais rígida possível?
Esse agente deveria revisar novas propostas e novos pull requests pelo critério de “aderência ao quadro geral”? Chame isso de contexto, visão ou outro nome qualquer
Esse tipo de agente pode ser muito bom em sintetizar contexto e apresentar um roadmap coerente que, linguisticamente, pareça alinhado aos valores e à visão da equipe. Mas sou cético de que terá o discernimento de um bom gestor ou de uma boa equipe. Aprovar um roadmap específico de forma rápida e convincente pode acabar fazendo mais mal do que bem
O mínimo de código necessário para resolver uma necessidade de negócio sem complexidade adicional é um ativo com uma dívida de manutenção atrelada. Como o trator de um fazendeiro, que é um ativo que precisa de manutenção e se deprecia por deterioração se for negligenciado
Código escrito para criar complexidade desnecessária é dívida pura
Sim, mas escrever código sempre ensina alguma coisa
Já trabalhei em startups no tamanho de fundadores e em empresas abertas de centenas de bilhões de dólares, e nunca vi uma especificação de produto, pitch deck ou PRD que, se implementado como estava, realmente descrevesse uma solução para o problema. É quando você de fato constrói que aprende como aquilo deveria funcionar
Software é um meio complexo e interativo. Iterar no código com pessoas que querem entender e resolver o problema sempre foi a única forma de chegar a um produto que tenha valor. Reuniões e diagramas ajudam, mas até você escrever software funcionando, não sabe se realmente tem algo
“O objetivo era testar nosso algoritmo de geração estruturada e seus equivalentes open source, substituindo o ingênuo ‘ele aceita esta string?’ por uma pergunta mais próxima do problema real: ‘ele gera a distribuição de tokens correta?’… No mês passado, passei 30 minutos explicando o método ao Codex. Algumas horas depois, a primeira versão funcional apareceu. Foi isso”
Isso prova que o gargalo realmente era o código. Agora quem escreveu esse código foi a IA
Quem achou que “o gargalo não era o código” já tinha discutido o objetivo e organizado isso de forma coerente na própria cabeça
Dizer que código é o gargalo não precisa significar “eu queria essa funcionalidade, mas levaria meses para codificá-la”. Pode incluir também “eu queria essa funcionalidade havia 2 anos, mas adiei por causa do atrito de sentar, traduzir em código e gastar de 5 a 10 dias nisso”
Se código não fosse o gargalo, a pessoa simplesmente teria sentado e escrito. Mas não queria investir o esforço e o tempo de codificar por conta própria, e sabia que isso não exigiria tão pouco quanto um LLM exige
Mesmo quando a especificação final não está clara, escrever código de forma exploratória, verificar, descartar e tentar de novo um novo design fica mais rápido com LLMs. Justamente porque a parte de “código” fica mais rápida
Em outras palavras, o gargalo era o código
O próprio texto também parece um texto gerado por IA com uma instrução para evitar clichês, e por isso continua sendo chato de ler
O texto dizia: “Paradoxo de Jevons: quando algo fica mais barato, você não usa menos; usa mais”, mas isso estraga a formulação do paradoxo de Jevons
Essa frase não é um paradoxo, é um efeito totalmente natural. Quando algo fica mais barato, é óbvio que o uso aumenta
O que o paradoxo de Jevons realmente descreve é a situação em que o uso de um recurso se torna mais eficiente, reduzindo a quantidade necessária para uma certa tarefa, mas ainda assim o consumo total desse recurso aumenta
Mas, se o uso de um recurso se torna mais eficiente, o preço desse “uso” não fica naturalmente mais barato também?
Então, se a eficiência aumenta, o uso naturalmente sobe. Chamam isso de paradoxo porque algumas pessoas ingenuamente acham que ganhos de eficiência são uma boa forma de reduzir consumo
Quase tudo que é chamado de “paradoxo” é assim, meio óbvio
Ou talvez no fato de que, se um processo fica mais eficaz, ou seja, leva menos tempo, acabamos dedicando mais tempo a esse processo
Gargalo para quê? Mais funcionalidades?
Não acho que a quantidade de software determine o sucesso de uma empresa. Também não vejo como tão importante capturar mais contexto
O importante é a qualidade do contexto. Quão bem os humanos raciocinam?
Depois vem a atitude. Quão bem os humanos reagem a situações ruins?
Depois, gestão de recursos. Quão bem a empresa lida com pessoas e dinheiro?
Por último, sorte. Quantos dos fatores fora do nosso controle estão a nosso favor?
Esses são gargalos bem melhores de uma empresa. Não parece que agentes vão resolver isso tão cedo
O gargalo para tornar melhores as aplicações de software usadas por negócios não relacionados a software está em garantir que o software realmente faça todo o trabalho de software que seja benéfico ao negócio
Coisas que economizam tempo, tornam humanos mais produtivos, reduzem erro humano, deixam o negócio mais eficiente e aumentam as margens
Tudo isso é bastante difícil de prever e quantificar. Você pode começar com uma ideia que ajude o negócio, projetar, criar um protótipo e testar. No fim, tenta construir ou melhorar a aplicação de software e medir o quanto ela melhorou o negócio
Ao longo de todo esse processo, garantir que o software esteja lidando com o problema certo da maneira certa e que no fim torne o negócio melhor é a parte difícil. Isso independe de quão rápido e fácil ficou criar software
Ainda assim, velocidade pode ajudar muito. Dá para prototipar, testar e melhorar o ciclo de feedback
Com assistentes de codificação por IA, coisas que antes seriam vistas como trabalho de desenvolvedor júnior agora são implementadas com um prompt rápido e um agente rodando em segundo plano
Esse tipo de trabalho júnior agora é entregue quase sem esforço pelo assistente de codificação, com quase nenhuma intervenção humana. O backlog é esvaziado mais rápido do que novos itens são adicionados. E, como a capacidade de execução deixa de ser problema, mais itens novos continuam sendo adicionados
Agora o desafio é acompanhar o volume de mudanças. Estamos vendo isso diretamente na nossa organização
Só porque é possível imaginar outros gargalos, isso não significa que geração de código não fosse o gargalo, ou que não seja o gargalo agora. O próprio conceito de backlog mostra que isso é um gargalo
“Software é o que sobra depois que um grupo de humanos negocia entre si o que o sistema deve fazer”
Gosto dessa formulação. Concordo especialmente sobre contexto. É exatamente aí que equipes experientes e duradouras são recompensadas
Gerenciei equipes assim por décadas. Quando nosso departamento acabou sendo integrado, até o engenheiro com menos tempo de casa já tinha 10 anos de empresa
Quando uma equipe fica junta por tanto tempo, a sobrecarga de comunicação cai para um nível quase desprezível
Por isso a cultura atual de permanência relâmpago me entristece tanto
Hoje em dia trabalho mais sozinho. Minha produtividade é muito alta, mas o escopo é realmente limitado
Sinto falta da época em que eu fazia parte de uma boa equipe
Que tipo de projeto, afinal, vocês fazem, em que a única parte difícil é entender as funcionalidades que a diretoria quer, e o resto basta “digitar” ou hoje em dia passar para um LLM?
Se esse é o trabalho, não é surpresa que tanta gente no HN ache que LLMs podem substituí-los
Aí ficamos dando mais uma volta no mesmo círculo, falando de ansiedade, conversando sem nos entender e esperando 30 minutos pela próxima chance de comentar
A maior parte é lixo em brasa em termos de qualidade de código, por causa dos ciclos de terceirização para fora e demissões