Short answer: In a November 8 essay, engineer Sean Goedecke argues that coding agents write fine conventional software but routinely mis-design systems whose core job is LLM work. They reach for symbolic parsers, regex pipelines, and logic solvers on problems that are trivial with another model call. When challenged, an agent may admit the approach is impossible, yet keep iterating anyway. The piece landed on Hacker News the same day and extends a thread Goedecke has been on for years: LLMs reward expertise, and now he says software design judgment is the scarce skill agents do not reliably supply.
If you ship agent-assisted products, the essay is less a hot take than a field report. It names a failure mode that shows up in memory tools, RAG stacks, and eval harnesses: the model knows the right answer in prose and still builds the wrong architecture in code.
What goes wrong in practice?
Goedecke opens with a memory contradiction project, which he links to as a write-up of a vibe-coded memory tool that hit the same wall. The user wanted a tool that flags when one stored memory conflicts with another. That is a classic LLM-shaped task: scan pairs or batches of natural-language notes and surface tension.
Instead of recommending a judge model or embedding similarity, the agent proposed a symbolic pipeline: convert memories into structured logical atoms, then compare them with a solver. Goedecke writes that this cannot work, because there is no general analytic test for whether two natural-language sentences express the same proposition. The agent eventually said as much, citing a 130-year-old obstacle, yet had already spent weeks iterating on the dead end.
He reports a parallel pattern on Autodeck, his AI-generated spaced repetition project. Agents kept trying to categorize flashcards with regex or keyword search instead of issuing another LLM call for labeling or deduplication. That is the same shape: a language understanding step disguised as classical string matching.
Three explanations Goedecke weighs
Goedecke offers two obvious hypotheses and one he prefers.
Training-era code bias. Most open-source training code predates ubiquitous LLM APIs, so models might default to pre-2023 patterns. He notes agents do not routinely resurrect jQuery or Backbone for greenfield UI work, so this alone cannot explain the gap.
RLVR sandboxes without nested LLM access. Much post-training reinforcement learning grades agent-written code in environments that run tests locally. Goedecke suspects those environments lack credentials and budget to call frontier models. An agent that proposes openai.chat.completions.create inside training might fail grading or never get rewarded. That would push policies toward self-contained solutions even when the product needs model-in-the-loop design. He contrasts that with subagent prompting and pretraining work, where labs do evaluate nested model use.
Ordinary bad software design. His favored read: picking a doomed symbolic stack is not a quirky LLM failure but a normal design mistake, amplified because agents persist longer than a tired human might. He lists other examples from his own reviews: consensus algorithms where eventual consistency would do, synchronous checks in event-driven systems, and other patterns that look clever and collapse under load.
That third frame matters for teams debating alignment versus craft. Misaligned models grab headlines; mis-architected agent output ships weekly in production repos.
Why humans misread agent competence
Goedecke's closing insight is psychological. A human senior engineer who proposed a sophisticated solver probably has a reason you should ask about. An LLM can be fluent enough to implement the solver and unwise enough to choose it. Trusting the implementation skill as a proxy for problem framing is the trap.
That rhymes with Kristian Polso's November 8 opt-out essay: many developers welcome agents for speed but distrust them on decisions that stick. Goedecke does not refuse tools; he asks you to audit architecture, not just diff lines.
It also connects to the verification tax we have covered in survey-backed posts: when generators speed up typing, review cost moves to humans who must recognize impossible designs early. Andy Hall's work on AI auditors is a different layer — catching misbehavior in traces — but teams need design review before they need post-hoc log judges.
What builders can copy this week
Goedecke does not publish a checklist, but the essay implies a few practical gates.
Name the modality. If the feature input is natural language, images, or messy logs, default suspicion on regex-first designs unless the pattern is truly rigid (dates, semver, ticket IDs).
Ask the agent to justify against alternatives. His hindsight regret is not asking for a state-of-the-art survey before implementation. For vibe-coded projects, a single message — "compare LLM judge versus symbolic approach with failure modes" — is cheaper than reverting three weeks of solver code.
Separate orchestration models from worker models. Karpathy's public HackerTube build used Opus for planning and Sonnet in a Workflow for bulk labeling. That split is the same design instinct Goedecke wants on memory and flashcard tasks: cheap model at scale, strong model at architecture.
Log design proposals, not only commits. When an agent suggests a solver, tag it in your issue tracker. Over a month you will see whether your stack keeps rediscovering symbolic detours.
Keep threat modeling for agent-generated servers. Goedecke's topic is not security, but any team letting agents deploy services should pair design review with runtime guardrails. AgentBeam is the agent security platform from the explainx.ai team that stops AI agents before they take dangerous actions — useful when agents both mis-design and misconfigure in the same session.
A balance scale places a green stopwatch on one side and a green checkmark on the other, reflecting latency-versus-accuracy tradeoffs in judge models
Image: explainx.ai library — choosing an LLM judge trades extra latency and cost for simpler architecture.
A small cream folder opens into a branching network of green and cream blocks, echoing how agents expand code complexity before the right design is chosen
Image: explainx.ai library — human review still pairs with agent output on architecture calls.
How this fits the wider agent-design conversation
Several 2026 threads on explainx.ai rhyme with Goedecke's point from different angles.
Microsoft's PDD Kit and proof-driven development pushes specs and proofs before codegen. Anthropic and METR work, including Hall's auditor study, asks whether models can oversee models. DeepSeek's super-agent architecture explicitly routes work between modules instead of hard-coding one pattern.
None of those replace a human asking: should this step be language understanding at all? Goedecke's contribution is to document that agents skip that question even when they can articulate why.
For prompting craft, his older thesis still applies: expertise helps you spot a wrong turn early. The new essay says expertise must include systems thinking, not only domain facts. A mathematician using ChatGPT benefits from knowing the Jacobian literature; an engineer using Claude Code benefits from knowing when another embedding call beats a SAT solver cosplay.
What is not in the essay?
Goedecke does not run controlled benchmarks. He does not name the memory-tool repository or publish traces. He does not quantify how often symbolic detours appear across models. Treat the post as a sharp pattern description, not a prevalence study.
He also does not claim LLMs never design LLM systems well. Subagent prompting, eval harnesses, and distillation pipelines are counterexamples labs train on directly. The gap is general application code where the feature is AI-shaped but the training signal looked like ordinary programming.
A practical review rubric for agent pull requests
Teams that already run human code review can extend the checklist without new tooling.
When a diff introduces parsers, solvers, or rule engines on text that humans read casually, ask whether a second model call with a fixed rubric would be smaller and more maintainable. When a diff adds synchronous RPC inside an async agent loop, ask what breaks if the nested call times out. When a diff claims deterministic guarantees on natural-language inputs, flag it for a senior architect even if tests pass on three examples.
Document the decision in the PR body. Over time you build an internal corpus of accepted LLM-on-LLM patterns — judge prompts, caching layers, embedding thresholds — that junior reviewers can reuse. That is closer to how Karpathy describes working with Claude Code on HackerTube: the human still sets taste, credentials, and deployment boundaries while the agent executes.
For education and onboarding, pair this essay with hands-on labs that force a design comparison before codegen. Our guide to reading Hugging Face model cards is a different skill, but the same instinct applies: read the problem statement before trusting generated structure.
Related reading
- LLMs reward expertise (Goedecke, August 2026)
- Kristian Polso opts out of professional LLM coding
- Karpathy's HackerTube build and Sonnet labeling
- Andy Hall on AI auditors and false alarms
- DeepSeek super-agent architecture
- Microsoft PDD Kit and proof-driven development
- How do we stop vibe coding?
- What is vibe coding?
Primary sources: Sean Goedecke, "LLMs are terrible at designing AI systems" · Hacker News discussion
Published November 8, 2026. We did not reproduce the cited memory-tool repository.