Escrever código agora é barato

• A realidade em que o custo de escrever código caiu drasticamente está abalando os hábitos de engenharia como um todo
• No passado, como produzir código tinha alto custo, formou-se uma cultura de desenvolvimento eficiente centrada em design, estimativas e planejamento
• Com o surgimento dos agentes de codificação, um único desenvolvedor passou a conseguir executar várias tarefas ao mesmo tempo, como implementação, refatoração, testes e documentação
• Porém, criar “bom código” ainda exige padrões elevados de qualidade e o julgamento do desenvolvedor
• Com isso, surge o desafio de construir novos hábitos de desenvolvimento, tanto individuais quanto organizacionais

---

Mudança no custo de escrever código

• No passado, escrever algumas centenas de linhas de código limpo e testado levava mais de um dia
  • Por causa disso, os desenvolvedores avaliavam o valor e a prioridade das funcionalidades com base no tempo e no custo limitados
  • Design de projeto, estimativas de cronograma e planejamento de funcionalidades eram todos orientados pelo “uso eficiente do tempo de codificação”
• Com a introdução dos agentes de codificação, o custo de digitar código caiu abruptamente, abalando os critérios de decisão existentes
  • Um único engenheiro pode executar vários agentes em paralelo para realizar trabalho de desenvolvimento simultâneo em várias frentes
  • Essa mudança leva à revisão da estrutura tradicional de avaliação de valor em relação ao tempo

O “bom código” continua caro

• A produção de código novo ficou praticamente próxima de gratuita, mas criar “bom código” ainda continua custando caro
• As condições para um bom código são as seguintes
  • Funcionar corretamente e cumprir seu objetivo sem bugs
  • Passar por procedimentos de verificação para comprovar que o código é confiável
  • Focar em resolver o problema adequado, tratando situações de erro de forma previsível
  • Manter uma estrutura simples e mínima para aumentar a manutenção e a compreensão
  • Testes e documentação devem permanecer atualizados
  • Considerar a possibilidade de mudanças futuras, sem adicionar complexidade desnecessária
  • Atender a atributos de qualidade não funcionais, como acessibilidade, segurança, escalabilidade e manutenibilidade
• Os agentes de codificação ajudam em parte desse processo, mas a responsabilidade final pela garantia de qualidade continua sendo do desenvolvedor

A necessidade de novos hábitos de desenvolvimento

• Em um ambiente de engenharia baseada em agentes (agentic engineering), os hábitos tradicionais de desenvolvimento já não são mais válidos
• Tanto indivíduos quanto organizações precisam formar novas formas de trabalho e novos critérios de julgamento
• Em toda a indústria, essas melhores práticas (best practices) ainda estão sendo estabelecidas
• A abordagem proposta é experimentar executando sessões assíncronas de agentes mesmo no momento em que se pensa “isso vai tomar tempo demais”
  • No pior caso, você verifica depois de 10 minutos e conclui que foi apenas um desperdício de tokens

Lugar no guia Agentic Engineering Patterns

• Este texto faz parte de “Principles”, o primeiro capítulo do guia Agentic Engineering Patterns
• No próximo capítulo, sobre entendimento de código (Understanding code), a sequência continua com Linear walkthroughs
• Depois, na seção Testing and QA, são abordados temas como Red/green TDD e First run the tests
• Está previsto adicionar 1 ou 2 capítulos por semana, em um formato parecido com um livro, mas organizado como um “guia”

[GN⁺]

Opiniões do Hacker News

• Não sei se a expressão “código sempre foi caro” está correta
  Na prática, o que era caro não era o código em si, mas tudo ao redor dele — garantir correção, manutenção, coordenação entre equipes, suporte de longo prazo etc. eram os verdadeiros fatores de custo
  Se houver excesso de testes ou etapas de aprovação, o processo acaba representando a maior parte do custo
  Os LLMs reduziram bastante, no curto prazo, o custo de gerar código que funciona, mas no longo prazo podem aumentar a carga de manutenção, segurança e testes
  No fim, só olhando dados de longo prazo dá para saber se houve uma mudança real

  • Concordo com a ideia de que “o que é caro é tudo ao redor do código”
    Antigamente, até escrever algumas centenas de linhas de código tinha custo alto
    Coloquei 256 linhas de JavaScript na ferramenta SLOCount dos anos 2000 (versão WebAssembly) e a estimativa deu cerca de US$ 6.461 nos parâmetros da época
    Claro, esse número é só por curiosidade
  • Pela minha experiência, não só programação, mas também DevOps, análise de dados e suporte foram fortalecidos por IA
    Hoje eu pareço mais um gerente de mim mesmo, administrando meu trabalho em vez de executá-lo diretamente
    A sensação é de que minha produtividade aumentou cerca de 2,5 vezes em relação a antes
  • Se você olhar o ciclo de vida de desenvolvimento de software (SDLC), codificação é só uma etapa
    Levantamento de requisitos, design, testes, deploy e manutenção continuam sendo necessários, e a maior parte do custo ainda acontece na fase de manutenção
    Como na lei de Amdahl, mesmo que o custo de codificar chegue perto de zero, o limite passa a ser o custo das outras etapas
  • A verdadeira redução de custo vem de saber com precisão o que o usuário “realmente quer”
    O problema é que, por natureza humana, isso é difícil
  • Código era caro no passado, é caro agora e continuará caro no futuro
    Elementos de qualidade como correção, manutenibilidade e desempenho são custos ocultos que só se aprendem com experiência

• Não concordo com a afirmação de que “código sempre foi caro”
  Na verdade, código ficou caro porque tentamos escrever ‘bom código’
  Se você baixar o padrão, o código gerado sai rápido e barato, mas o esforço para trazê-lo de volta ao nível de um bom código continua o mesmo
  Para defender agent coding, é preciso usar outra lógica

  • Pela minha experiência, ao usar agentes de IA fica até mais difícil garantir bom código
    Quando eu mesmo escrevo, entendo a razão de cada linha, mas no código gerado por IA preciso validar cada instrução
    No último mês fiz a maior parte do trabalho com agentes, e continuam aparecendo bugs de casos de borda que um humano não criaria
    No fim, o custo de revisão cresce e o ganho de curto prazo desaparece
  • Eu formulei isso com cautela como “bom código ainda custa caro”
    Mas, graças aos agentes de codificação, esse custo cai bastante
    Como eles cuidam de ajustes minuciosos, dá para produzir código de melhor qualidade mais rápido
  • Código simples é barato, mas código complexo continua caro
    Complexidade se acumula, então o jeito mais barato é tratá-la com cuidado já na primeira implementação
    Agora o ganho de curto prazo é grande, mas no longo prazo o ruído pode aumentar 10 vezes
  • O ponto central é que programar é barato, mas engenharia de software é cara
  • Isso lembra o conceito de Ousterhout de programação tática vs. estratégica
    Os LLMs são especializados em programação tática, isto é, implementar funcionalidades rapidamente
    Por isso, gerenciar a complexidade no nível do sistema fica ainda mais importante

• Gerar código é tão barato quanto se diz, mas a habilidade de transformá-lo em um resultado valioso é o verdadeiro diferencial
  Agentic engineering é, no fim, a técnica de conduzir insumos baratos até resultados valiosos

  • Concordo totalmente com a frase “a habilidade de conduzir insumos baratos a resultados valiosos”
    Agentic engineering não é simplesmente escrever software, mas criar ferramentas para resolver rapidamente um problema específico
    Mas, quando a resolução do problema termina, a IA em si deixa de ser interessante
    Muita gente toma a própria IA como objetivo, quando o valor real está em resolver problemas
    Como dizia Alan Watts, depois que você recebeu a mensagem, deve desligar o telefone
  • Só porque existe uma escavadeira, você não fica rico cavando buracos em qualquer lugar
    O fato de uma ferramenta ficar barata não cria valor automaticamente
  • O ato de digitar código, na prática, não é o valor
    Capacidade de projetar e estruturar é o que tem valor de verdade
  • Se a saída vem do mesmo cérebro, seja por instrução minuciosa ou por sorte em uma única tentativa, a qualidade tende a ser parecida
    No fim, o essencial é a qualidade da decisão
  • Levantar 100 milhões de dólares não significa que a ideia seja boa
    Captação de recursos não é prova de valor

• Tenho dúvidas sobre a afirmação de que “código sempre foi caro”
  A própria definição de código limpo e testado já é ambígua
  Se você exagera nos testes, o custo explode, e processos organizacionais de aprovação também são um grande fator de custo
  LLMs reduzem o custo de curto prazo, mas podem aumentar o custo de manutenção no longo prazo

  • Código sempre foi caro
    Quando eu era estagiário, trabalhei barato em uma startup, mas incidentes, corrupção de dados e dívida técnica se acumularam
    Na aparência parecia barato, mas havia muito custo escondido
    Com os LLMs, hoje parece possível obter código de boa qualidade de forma barata, mas ainda estou me adaptando
  • Do ponto de vista de uma startup, antes era necessário contratar desenvolvedores por mais de 6 meses para lançar um produto
    Hoje fazer um v1 é barato, mas as decisões complexas de um produto maduro continuam caras

• O valor econômico do software está na informação contida no código
  Escrever código é apenas o processo de mapear essa informação, e é a qualidade da informação que determina o valor real
  Escrever código mais rápido não melhora a qualidade da informação
  É como consultoria: fazer slides mais rápido não cria valor por si só

  • Esse conceito se conecta ao tema recente de dívida cognitiva (cognitive debt)
    Quando a velocidade de implementação aumenta demais, o modelo mental do desenvolvedor se desalinha do código
    Texto relacionado: Cognitive Debt by Simon Willison
  • Eu também tive a experiência de que, ao usar agentes de codificação, a qualidade do mapeamento entre informação e código melhorou
    Isso porque consegui repetir refatorações rapidamente
  • No fim, o gargalo é o processo de transmitir intenção à máquina
    A IA vai entender cada vez mais contexto, mas, em troca, teremos de abrir mão de parte do julgamento humano
    Quando um dia a máquina passar a compreender totalmente a intenção, o humano será empurrado para fora do loop

• O cerne de toda metodologia de desenvolvimento é o fato de que os requisitos sempre mudam
  Por isso, bom código é “código fácil de modificar”
  Fico em dúvida se os agentes LLM de hoje produzem esse tipo de código
  Até que sejam completamente confiáveis, parece que vão continuar no nível de protótipo

  • O verdadeiro gargalo não é escrever código, mas o custo de comunicar a intenção com clareza
    Se a especificação é vaga, tanto testes quanto validação de valor ficam difíceis
  • Nem engenheiros humanos fazem alterações com 100% de segurança
    Mesmo com testes, há algo como 70% de confiança
  • Eu gerencio LLMs de perto e frequentemente os uso para modificar funcionalidades e corrigir bugs
    É mais rápido do que codificar diretamente, e o resultado sai como código manutenível
  • Eu já tenho todos os commits 100% gerados por agentes
    Se você explicitar código limpo e boas práticas, o resultado pode ser perfeitamente manutenível
    No fim, é Garbage in, garbage out
  • Mas algumas pessoas sentem que LLMs são bons até o nível de demo, mas desmoronam até com pequenas alterações

• Como eu disse no texto que escrevi (The Final Bottleneck),
  a velocidade de escrever código aumentou, mas as etapas seguintes não conseguiram acompanhar
  Não é apenas uma questão de hábito; a estrutura de responsabilidade, o design das linguagens e toda a arquitetura dos sistemas precisam mudar

  • Nem toda empresa consegue trabalhar dessa nova forma
    Se a produtividade realmente tivesse aumentado 10 vezes, as startups já teriam virado o mercado de cabeça para baixo
  • Quando os LLMs ficarem pequenos e baratos o suficiente, vai chegar a era em que estarão embutidos nos apps e ajustarão o código para cada usuário
  • Também existe a dúvida: “por que precisamos escrever código tão rápido?”
    Só porque é possível, não quer dizer que seja necessário
  • Desenvolvedores de open source deveriam liderar a era em que até não desenvolvedores se tornam builders
    Abordagens como AI evals(measure-first-optimize-last, ai-evals.io) apontam nessa direção
  • “Precisamos mesmo continuar fazendo deploy nessa velocidade?”
    Explosão de funcionalidades não é algo que ninguém deseja

• Cada linha de código é uma responsabilidade (liability)
  Na era em que LLMs despejam código, essa responsabilidade explode
  A ferramenta em si não é ruim, mas é perigoso ter uma estrutura em que programas sem responsabilidade reescrevem a base de código

  • Ao longo de décadas, acumulamos sistemas de validação, review e rollback para fazer deploy de código
    Dizer que “código é barato” significa que gerar ficou barato, não que o custo de aprovar o deploy tenha diminuído
    Se você elimina a etapa de julgamento, não ganha produtividade; cria um control gap
    Dar uma chave mestra só porque algo é rápido é perigoso
  • Tanto escrever quanto manter continuam caros
    Nenhum dos dois ficou barato

• Eu também concordo quase integralmente com essa opinião
  Escrever código ficou mais barato, mas o custo de review e validação continua alto
  Especialmente em monorepos com milhões de linhas, o essencial é aumentar a testabilidade
  Sou grato por esse tipo de discussão trazer equilíbrio em meio ao clima superaquececido do Twitter

  • Eu observei a mesma coisa
    Code churn ficou mais fácil, mas validar qualidade virou o novo desafio
    As mudanças em massa criadas por LLMs produzem falhas sutis, e esse fluxo não para

• Código não é barato
  Existe também o custo de tokens, e a estrutura real de custos ainda é incerta
  Como startups sem receita estão monopolizando a cadeia de suprimentos de GPU, faltam dados

  • Escrever ficou mais barato, mas manter continua igual
    Quanto mais LOC, maior a dívida
    A distância entre pensar e executar encurtou, mas o código em si continua sendo uma responsabilidade
  • Modelos locais mostram o piso de custo
    Agora está barato graças a subsídios, mas pode ficar ainda mais barato se caírem os custos de hardware, energia e mão de obra