Ask HN: Is anyone experimenting with different ways of using LLMs for coding?

Hacker News Discussion ↗

Engineers experimenting with large language models for coding are split between lightweight, spec-driven workflows and increasingly complex agent orchestration systems. Many report that current “vibe coding” and autonomous agents generate lots of code but hurt flow state, understanding, and long‑term maintainability, pushing them toward patterns like detailed upfront specs, issue/PR‑based workflows, narrow role‑specific tools, and pair‑programmer style assistants. Across approaches, the bottleneck is shifting from code generation to human comprehension, review, and system design, with emerging tools focused on better planning, constraints, and safety rather than raw autonomy.

Spec-driven vs. agentic/orchestrated coding

  • Many argue the biggest win is clearer specs, not complex orchestration: single intent, explicit I/O contracts, constraints, and preconditions, plus progressive clarification.
  • Preference by some for “clean slate” use: minimal or no long-term memory to avoid “context rot” and intent dilution; use external markdown/docs that the model can grep.
  • “Skills” (narrow, reusable instructions and tools) are seen as underrated; “agents” mostly help with context management and constraints.
  • Others report success with multi-agent teams, graph-based workflows, and role-pinned models (cheap for mechanics, strong for planning/review), but acknowledge high token costs and complexity.

Flow state and human experience

  • Common complaint: chat-style prompting and waiting breaks flow; users feel like managers supervising a junior dev instead of coding.
  • Some reclaim flow by:
    • Doing deep planning/spec work, then letting agents run unattended and reviewing later.
    • Using pair-programmer-style tools where the human drives and AI assists in small increments.
    • Running multiple parallel tasks/agents and treating “orchestration” itself as the flow activity.
  • Others feel multitasking across many agents is draining, not flow-inducing.

Practical workflows and harnesses

  • Frequent patterns:
    • Issue/PR-centered workflows where LLMs implement tickets, generate plans, and iterate via comments.
    • Three-tier documents (philosophy → spec → design) before code generation.
    • “Workboxes” / sandboxes per feature with automated branches, PRs, and deployable test instances.
    • Hermetic agents: separately generating code and tests from the same spec to avoid confirmation bias.
  • Custom harnesses span terminals, browser-based sandboxes, DAG/graph engines, and local VMs/containers, often with strict permissions and tooling (e.g., bug-hunting loops, security sandboxes).

Autocomplete, pairing, and editor integration

  • Strong interest in editor-centric flows: inline autocomplete, edit-completion, multiple anchored conversations per code region, and terminals where agents work in parallel panes.
  • Some see autocompletion harness and UX as more important than squeezing out slightly better models.

Learning, quality, and safety

  • Concern that fully agentic coding harms understanding and learning, especially for juniors; alternatives include having the LLM produce detailed instructional docs or act as a tutor/reviewer.
  • Many stress using LLMs to improve human understanding (diagrams, summaries, explanations) because human code comprehension is now the bottleneck.
  • Security and guardrails are recurring themes: sandboxed agents, restricted tools, and automated checks/tests between iterations.