Why are coding agents so dumb?

Original Article ↗ Hacker News Discussion ↗

Frustration is growing among developers who find that “coding agents” built on modern LLMs still struggle with real-world software work, from coordinating subtasks and choosing appropriate models to maintaining code quality and following project architecture over time. Commenters split between those who see current limitations as symptoms of immature harnesses and workflows—arguing that with careful context, custom tools, and agent orchestration the results can be excellent—and others who believe the tech fundamentally underdelivers on claims of autonomous coding. The exchange highlights an emerging divide: some engineers are investing heavily in bespoke agent frameworks and tooling, while others stick to using LLMs as assistants rather than letting them drive complex development.

Overall sentiment

  • Many agree current coding agents feel “dumb” in practice, but there is a split:
    • Some say recent top-tier models plus better setups have largely fixed the article’s pain points.
    • Others report months of frustration, especially for non-trivial, long-lived projects.

Harnesses vs. models

  • Several argue most problems are harness/orchestration issues, not model limitations:
    • Poor default prompts; no emphasis on subagents, parallelism, or role separation.
    • Some harnesses (e.g., newer versions) can spawn many async subtasks; others stay sequential or fragile.
    • People describe custom orchestrators that delegate to cheaper/faster models and use distinct roles.

Subagents, parallelism, and model selection

  • Mixed experiences:
    • Some report excellent results with autonomous agents that take tickets and open PRs, or run many agents in one repo.
    • Others find subagents slow things down and worsen results.
  • Dynamic model selection (smart vs. cheap) is still mostly manual or prompt-driven; fully automatic difficulty estimation is seen as hard.

Code quality and review workflows

  • Many complain AI-written code “works but is ugly”:
    • Overcomplicated, weak typing, unclear architecture, poor “taste”.
  • Suggested mitigations:
    • Doc-driven development; write specs/docs first with the agent.
    • Codify philosophy and style in AGENTS.md and markdown “source-of-truth” docs.
    • Use hooks/review subagents that automatically critique and rewrite code against explicit style and “definition of done”.

Prompting, context, and environment engineering

  • Some insist careful context/prompt/environment design is essential:
    • Treat everything the model sees—files, docs, structure—as part of the prompt.
    • Build local tools and skills instead of relying on generic plugins.
  • Others push back, noting most users don’t have time to spend months building bespoke frameworks.

Security and sandboxing

  • Strong concern about agents with filesystem/network access:
    • Sandboxes/containers are recommended but still have escape and supply-chain risks (e.g., scripts in .git).
    • Some give agents read-only git access and isolate them on networks.

Meta: expectations and maturity

  • Several say the wishlist of “obvious” features should be built into harnesses by default, but we’re early in the “AI age”.
  • There’s tension between “if you want it, build it with an agent” and “most people reasonably expect better out-of-the-box behavior.”