How I write software with LLMs
Developers compare emerging workflows for using large language models to write software, from multi‑agent “architect → implementer → reviewer” pipelines to single strong models guided by carefully crafted prompts. Many report big productivity gains and new ways to structure specs, design docs, and reviews, but others highlight downsides: messy or unmaintainable code, shallow understanding of the resulting systems, and uncertainty over how far human roles like architect or programmer will be displaced. The exchange also touches on practical issues such as cost and context management, the value of specialized vs general agents, and ethical concerns about training data and license compliance.
Multi‑agent vs Single‑agent Workflows
- Big debate on whether architect → developer → reviewer pipelines outperform a single strong model in one session.
- Pro‑pipeline: better context isolation, clearer planning, cheaper implementation models, more tokens spent in focused phases (plan / implement / review), and permission boundaries that prevent “runaway” edits.
- Skeptical view: coordination overhead, complexity, and cost; experiments show a single well‑prompted session can match multi‑agent results at a fraction of time and money.
- Some see many “personas” as cargo cult; others argue they’re mainly useful for context management and cost optimization, not because models “think” differently with different hats.
Planning, Documentation, and Artifacts
- Several people anchor plans, designs, and open questions in markdown or design docs under version control.
- Hierarchies like: requirements → design docs → test plans → code + tests, with different LLM calls per layer and occasional separate reviewers.
- Clean artifacts reduce reliance on long chat histories, ease model switching, and support later review by humans and other models.
Code Quality, Maintainability, and Review
- Many report LLM code “works” but is messy: long functions, weak low‑level design, disposable‑script style, overuse of panics or type erasure, and coupling concerns.
- Some argue this is acceptable for internal tools or “vibecoded” side projects but terrifying for large, long‑lived systems.
- Strong emphasis that human code review, good tests, and clear constraints (e.g., style guides, best‑practice bullets) are still essential.
- Disagreement over whether maintainability matters if code becomes cheap to regenerate; critics note tests rarely cover all user‑visible behavior.
Role of Developers and Future of Work
- Split views:
- One side: the core value shifts from typing code to understanding problems, architecture, and requirements; coding becomes “grunt work” for agents.
- Other side: dismisses “we just architect now” as downplaying real engineering; maintainability, debugging, and non‑functional requirements still need deep technical skill.
- Concern that artisanal coding may only support a small niche; others see new roles in orchestrating and inspecting AI output.
Prompting Style and Tooling
- Discussion on polite, full‑sentence prompts vs terse shorthand.
- Some think professional, well‑structured language nudges models toward higher‑quality reasoning; others just write naturally.
- Mixed experiences with IDE‑integrated tools vs CLI agents; functionally similar, choice depends on whether you plan to read and edit code directly.
Ethics and Legality
- Worry about LLMs reproducing GPL or other licensed code without attribution, especially in closed‑source products.
- A few commenters avoid LLM‑generated code entirely for ethical reasons.
Productivity and Hype Skepticism
- Skeptics question where the supposed massive productivity gains are in real economic outcomes.
- Others say code‑generation is largely solved, but finding valuable problems and navigating organizational friction remain the real bottlenecks.