1. Splitting the agent into specialized “sub‑agents” (architect, developer, reviewer, etc.)
Many users argue that breaking a single LLM into role‑specific agents helps manage context, enforce permissions, and reduce hallucinations.
“If you want to separate capabilities, definitely.” – chriswarbo
“The orchestrator runs the whole thing… architect → developer → reviewer.” – marcus_holmes
2. Cost‑vs‑quality trade‑off and token budgeting
A recurring point is that multi‑agent pipelines can be expensive, but they can also save tokens by delegating simple tasks to cheaper models.
“One tier, one model is cheaper, but the quality comes with the reviewers.” – stavros
“You spend your token & context budget in full in 3 phases.” – hakanderyal
3. Human understanding and the “vibe‑coding” critique
Several comments caution that relying on LLMs without reading or reviewing the code turns developers into “no‑code” users and erodes architectural insight.
“If you fail to even read the code produced, then I might as well treat it like a no‑code system.” – ashwinsundar
“I can understand the high‑levels of how no‑code works, but as soon as it breaks, it might as well be a black box.” – ashwinsundar
4. Workflow & tooling integration (CLI vs IDE, markdown artifacts, harnesses)
Users discuss how to embed agents into existing toolchains, the value of markdown‑based plan files, and the pros/cons of terminal‑based vs. IDE‑based agents.
“I’m using a hierarchy of artifacts: requirements doc → design docs → code+tests.” – aix1
“All artifacts are version controlled.” – aix1
“I just want to talk to a model all day, but that’s not the same as writing code.” – lbreakjai
These four themes capture the main strands of opinion in the discussion.