Ask HN: Alguém está experimentando diferentes maneiras de usar LLMs para programar?

Discussão no Hacker News ↗

Programação orientada por especificações vs. agentic/orquestrada

  • Muitos argumentam que o maior ganho está em especificações mais claras, não em orquestração complexa: intenção única, contratos explícitos de I/O, restrições e pré-condições, além de esclarecimento progressivo.
  • Alguns preferem uso de “clean slate”: memória de longo prazo mínima ou inexistente para evitar “context rot” e diluição da intenção; usar markdown/docs externas que o modelo possa grep.
  • “Skills” (instruções e ferramentas estreitas e reutilizáveis) são vistas como subestimadas; “agents” ajudam principalmente com gestão de contexto e restrições.
  • Outros relatam sucesso com equipes multiagente, fluxos baseados em grafos e modelos com papéis fixos (baratos para mecânica, fortes para planejamento/revisão), mas reconhecem custos altos de tokens e complexidade.

Estado de flow e experiência humana

  • Reclamação comum: prompts em estilo chat e a espera quebram o flow; usuários se sentem como gerentes supervisionando um dev júnior em vez de programar.
  • Alguns recuperam o flow por meio de:
    • Fazer trabalho profundo de planejamento/especificação e depois deixar os agents rodarem sem supervisão, revisando mais tarde.
    • Usar ferramentas no estilo programador em dupla, em que o humano conduz e a IA auxilia em pequenos incrementos.
    • Executar várias tarefas/agents em paralelo e tratar a “orquestração” em si como a atividade de flow.
  • Outros sentem que alternar entre muitos agents é desgastante, não indutor de flow.

Fluxos de trabalho práticos e harnesses

  • Padrões frequentes:
    • Fluxos centrados em issue/PR, nos quais LLMs implementam tickets, geram planos e iteram via comentários.
    • Documentos em três camadas (filosofia → especificação → design) antes da geração de código.
    • “Workboxes” / sandboxes por feature com branches automatizadas, PRs e instâncias de teste implantáveis.
    • Agents herméticos: gerar código e testes separadamente a partir da mesma spec para evitar viés de confirmação.
  • Harnesses personalizados abrangem terminais, sandboxes baseadas em navegador, motores DAG/grafo e VMs/containers locais, frequentemente com permissões e ferramentas estritas (por exemplo, loops de caça a bugs, sandboxes de segurança).

Autocomplete, pairing e integração com editor

  • Forte interesse em fluxos centrados no editor: autocomplete inline, conclusão de edição, múltiplas conversas ancoradas por região de código e terminais onde agents trabalham em painéis paralelos.
  • Alguns veem o harness de autocompletar e a UX como mais importantes do que extrair modelos ligeiramente melhores.

Aprendizado, qualidade e segurança

  • Preocupação de que programação totalmente agentic prejudique entendimento e aprendizado, especialmente para juniores; alternativas incluem fazer o LLM produzir documentos instrucionais detalhados ou atuar como tutor/revisor.
  • Muitos enfatizam usar LLMs para melhorar a compreensão humana (diagramas, resumos, explicações), porque a compreensão do código por humanos agora é o gargalo.
  • Segurança e guardrails são temas recorrentes: agents em sandbox, ferramentas restritas e verificações/testes automatizados entre iterações.