6 pontos por GN⁺ 2026-01-22 | 1 comentários | Compartilhar no WhatsApp
  • Tentei usar codificação com agentes, mas a discrepância entre o que vejo online e os resultados que consigo implementar na prática está me dando dor de cabeça; existe alguma evidência de que isso realmente traz resultados positivos?
  • Além do marketing exagerado, se alguém aqui já implementou com sucesso programação agêntica, por favor compartilhe em detalhes como fez
  • "Implementar com sucesso" significa algo como
    • gerar mais valor do que dívida técnica
    • escrever código estruturalmente sólido a ponto de um responsável pela arquitetura poder aprová-lo
  • Recentemente, tenho visto uma tendência de minimizar ou até eliminar code review, com o argumento de que é preciso passar da "validação da arquitetura" para a "validação do funcionamento"
  • Na prática, isso parece significar implantar se passar nos testes e no CI, sem olhar o código, e tenho dúvidas se esse modelo é sustentável no longo prazo
  • Na minha opinião, usar Codex tende a produzir código que funciona nos caminhos normais, mas que com o tempo vira "código espaguete" com erros sutis e difíceis de depurar se acumulando
  • Quando tentei aplicar o Codex a uma base de código existente, com ou sem diretrizes definidas, metade do meu tempo foi gasta corrigindo erros sutis ou código duplicado gerado pelo Codex
  • No último fim de semana, tentei recriar do zero um app iOS de lembrete de ração para pets
    • Pedi ao Codex que primeiro pesquisasse e sugerisse um blueprint de arquitetura baseado em SwiftUI, e escrevi junto com ele uma especificação explicando o que implementar e como
    • A primeira implementação tinha alguns bugs, mas estava surpreendentemente boa; depois disso, porém, a situação piorou rapidamente
    • Passei o restante do fim de semana tentando fazer o Codex funcionar direito, corrigir bugs sem criar novos e pesquisar boas práticas em vez de sair escrevendo código aleatoriamente
    • Fiz com que o Codex registrasse novas diretrizes sempre que fossem descobertas, mas a situação não melhorou, e no fim desisti
  • Pessoalmente, considero inaceitável implantar código não revisado
  • Algo parece estar errado. O produto precisa funcionar corretamente, mas a qualidade do código também precisa ser alta

1 comentários

 
GN⁺ 2026-01-22
Opiniões do Hacker News
  • Há muito dinheiro em jogo, já que os LLMs são vistos como a chave para reduzir custos
    Influenciadores e até especialistas famosos às vezes fazem declarações exageradas para manter uma imagem de “estado da arte”
    Mas, na prática, ainda não existe uma melhor abordagem consolidada para desenvolvimento com LLMs
    Neste momento, em vez de acreditar nisso como se fosse uma fé, acho mais importante olhar diretamente para como as coisas funcionam por dentro

    • Recentemente eu também recebi uma oferta de 200 dólares de uma empresa para divulgar uma nova “agentic coding platform”
      O fato de esse tipo de proposta chegar até a usuários aleatórios indica que já existe uma campanha de marketing considerável em andamento
    • Os LLMs são claramente uma ferramenta de salto de produtividade, mas não são a chave mestra para desenvolvimento totalmente autônomo
      São divertidos para tarefas CRUD simples, mas em projetos complexos acabam gerando mais frustração
      Agora é um momento em que a disputa por benchmarks e o dinheiro de VC estão concentrados no tema, o que dificulta uma discussão equilibrada
    • Como quando a GUI apareceu pela primeira vez, acho que ainda estamos na fase de sentir seu valor intuitivo
      Ainda faltam evidências quantitativas, mas mesmo que os desenvolvedores não desapareçam por completo, a forma de desenvolver mudou para sempre
  • Um Principal Engineer do Google tuitou que “Claude Code fez em 1 hora um trabalho que levaria 1 ano”
    Mas depois ficou claro que o que a IA produziu era apenas uma “versão de brinquedo”
    Esse tipo de exagero distorce as expectativas e provoca decepção
    Link do tuíte relacionado

    • Muitas vezes esse tipo de tuíte vem da pressão interna para mostrar resultados da liderança em IA
    • Houve quem reagisse dizendo: “não faz o menor sentido dizer uma coisa dessas”
    • Outra pessoa apontou que “os resultados com IA variam conforme o nível de experiência e o investimento feito
    • Também houve reação cética, dizendo que “a IA ainda só entrega código que não dá para colocar em produção
    • Teve também quem alfinetasse dizendo que “isso mostra bem o Google”
  • Olhando para os últimos 6 meses, consegui um ganho de eficiência de 10x com código de infraestrutura (ex.: Terraform)
    Mas o desenvolvimento de funcionalidades especializadas ainda é inconsistente
    Mesmo assim, o tempo economizado por reduzir tarefas repetitivas permitiu melhorar a qualidade de testes e segurança
    Acima de tudo, voltei a sentir prazer em programar

    • Também desenvolvo por hobby há 35 anos, e a IA tira o peso da digitação tediosa e resgata a criatividade
    • No meu caso também fiquei mais de 2x mais rápido em scripts de build e tarefas de CI, mas projetos complexos de HPC ainda continuam difíceis, e o modelo de assisted coding foi o mais eficiente
      Link do projeto
    • Fiz com o Claude um buscador de arquivos para o NAS de casa e terminei em um dia um backend em Go com indexação automática diária e uma interface web
      Acho que esse tipo de projeto pessoal é o verdadeiro game changer
    • Quando o trabalho é dividido em partes pequenas, o agente funciona muito melhor
    • Ainda assim, a qualidade do código de teste continua baixa. Os próprios dados de treinamento são fracos em escrita de testes
  • Tive muito sucesso ao acoplar agentes a um app já existente
    Os agentes são fracos em arquitetura, mas funcionam muito bem em código que já está estruturado
    Quanto mais rigoroso o sistema de tipos e maior a cobertura de testes, melhor o resultado

    • Atualmente estou experimentando deixar um projeto em Rust ser gerenciado e desenvolvido diretamente pelo LLM
      O trabalho segue ROADMAP.md, TASKS.md e STATUS.md escritos pelo Claude, e surpreendentemente já está cerca de 20% concluído
    • C# combina bem com agentes graças ao compilador rigoroso e ao ambiente baseado em regras
      Já Python e JS são difíceis de confiar por causa do sistema de tipos mais fraco
    • Quanto mais organizada estiver a base de código existente, melhor é o desempenho do agente
      Criar tudo do zero é difícil, mas com uma especificação clara a eficiência aumenta
    • Go é fácil para LLMs lidarem por causa da linguagem simples e dos padrões consistentes
    • Typescript é ideal para agentes graças à compilação rápida e ao sistema de tipos forte
      Já a tipagem opcional do Python acaba causando propagação de erros
  • Escrevi 100% com Claude Code um monitor de frequência cardíaca Bluetooth em tempo real para Linux
    Link do projeto
    Foi feito em C puro, com interface web e gráficos em tempo real, tudo concluído em um dia
    Desta vez consegui implementar com sucesso a comunicação dBus–blueZ que antes tinha falhado

    • Mas, quando outro usuário revisou o código, viu que a implementação de SSE na prática não funciona
      A documentação diz SSE, mas internamente ele só retorna uma resposta HTTP comum
    • Outra pessoa observou que “o código escrito por IA parece bom no começo, mas vai perdendo qualidade aos poucos
    • Também houve quem agradecesse por compartilhar um exemplo sem exageros
    • Houve até comentário perguntando sobre o design, dizendo que o estilo da UI era interessante
  • Eu uso Augment + Claude Opus 4.5 todos os dias
    Quase não escrevo código diretamente; concluo projetos com um fluxo iterativo baseado em especificações
    Rodar vários agentes em paralelo e revisar o resultado é especialmente eficiente
    O segredo está em escrever especificações claras e dar feedback por etapas

    • Não conheço bem Ruby, mas recebo grande ajuda no desenvolvimento de apps Rails
      Sinto que é a mudança mais revolucionária dos meus 30 anos de carreira, e tenho certeza de que isso vai transformar toda a indústria
    • Alguém brincou dizendo que chamar um projeto de 1 semana de porte médio é chamá-lo de pequeno
    • Outra pessoa comentou que isso se parece menos com desenvolvimento por agentes e mais com desenvolvimento colaborativo com LLM
    • Também apareceu a opinião de que o desenvolvimento orientado por especificação (spec-driven) é o ponto central para qualidade em produção
    • Eu adicionei uma etapa em que deixo o Claude fazer perguntas primeiro, para organizar claramente os requisitos
      No momento estou usando Claude em um projeto de dicionário japonês–inglês
      Link do GitHub, site
  • Como desenvolvedor com 20 anos de experiência, os LLMs fizeram minhas previsões de velocidade de trabalho errarem completamente
    O que antes levava 2 semanas agora termina em 2 dias
    Ainda é preciso revisar o código e interagir com o processo, mas sinto que ele é melhor do que a maioria dos desenvolvedores humanos
    Conversar com um LLM se parece mais com colaborar com um desenvolvedor sênior, e a minha longa experiência em revisão de código e distribuição de tarefas ajuda muito

    • Alguém disse que um ganho desse tamanho é difícil de acreditar e ficou curioso sobre o tipo de problema
    • Outra pessoa comentou brevemente que “esperava ver provas, mas não havia nenhuma”
  • O método mais estável que usei até agora é passar tarefas pequenas e claras para o Claude
    Vou repetindo o ciclo de planejar, revisar, implementar e revisar de novo
    Não é perfeito, mas é muito útil para destravar pontos onde se fica preso
    Como ele não segue bem as diretrizes, verificação e organização manuais são indispensáveis

    • Eu também uso o Claude de forma parecida com rubber duck debugging
      Entrego uma função por vez e, olhando o resultado, consigo chegar a ideias melhores
    • Os LLMs são especialmente fortes em documentação e análise
      Mas, quando o problema passa a ser centrado em design, as limitações ficam evidentes
    • À pergunta “onde você coloca as diretrizes?”, a recomendação foi colocar informações de build e teste em CLAUDE.md
  • Muita gente entende errado a programação assistida por IA
    A IA não é um colega de equipe, e sim uma assistente
    O ponto central não é tratar bugs ou mau funcionamento como fracasso, mas entender que o essencial é o processo de um desenvolvedor experiente organizar esse caos

    • Alguém perguntou: “se dá tanto trabalho assim, qual é a diferença para o autocomplete da IDE?”
    • Outra pessoa questionou se já existe algum caso em que as técnicas mais recentes realmente comprovem melhora de qualidade
    • Também houve quem ironizasse dizendo que, no fim das contas, isso soa como “você que está usando errado”
    • E teve a piada: “se você esperava que ele criasse um app perfeito enquanto você via beisebol, então você não comprou uma IA, comprou um mágico”
  • Eu também uso Claude todos os dias, mas o código de teste gerado por IA costuma ser uma bagunça
    Na prática, ela produz em massa testes sem sentido como expect(true).to.be(true)

    • Modelos antigos fracassavam, mas li que os mais novos já produzem código que passa trapaceando
    • Por isso eu escrevo e reviso os testes primeiro, num fluxo de TDD
      Se você pede implementação e testes ao mesmo tempo, surgem erros de autocorreção/autovalidação
    • Alguém comentou que “desistiu de usar Claude para escrever testes”
    • Também houve quem risse dizendo que “essa é uma solução humana demais”