Why Do LLMs Design Mediocre Architecture?

[ab-10]

High-level PR Summary

This PR adds a new blog post titled "Why Do LLMs Design Mediocre Architecture?" which explores the limitations of LLMs in software architecture design. The post uses a practical example of email notification implementation to demonstrate how LLMs tend to follow existing patterns rather than creating optimal abstractions. It discusses how this shifts the role of developers toward focusing on architectural decisions rather than implementation details, and provides practical suggestions for teams working with LLM-assisted development, including more upfront design, architecture-focused code reviews, and automating repetitive review comments with custom rules.

⏱️ Estimated Review Time: 15-30 minutes

💡 Review Order Suggestion

Order	File Path
1	content/arch.md

Review by RecurseML

🔍 Review performed on 64ac7cc..30e61c5

✨ No bugs found, your code is sparkling clean

⏭️ Files skipped (trigger manually) (1)

Locations	Trigger Analysis
content/arch.md

[enzo-inc]

Great post! My only feedback (beyond some typos comments I left further down in review) is that I think you could strengthen your argument against counters around spec-driven development and more agentic approaches. What I mean is, the core argument is

LLMs follow existing patterns, humans must care about architectural decisions

Counter-arguments could be:

• What about having a system design agent, a DRY-checker agent, an anti-pattern-violation agent and a good-pattern-agent, all working in tandem under an orchestrator agent (which is the setup of a lot of claude code max users)? Would that solve the issues you are describing?
• What about memories and automatically-attached rules in cursor, wouldn't that alleviate some of the problems you are talking about? For example,

This is one I like to use, which I found helps with higher-level planning and helping the agent take a step back before diving into implementation. I usually do a couple of turns giving feedback in Ask mode with this prompt, then switch to Agent mode to implement

---
description:
globs:
alwaysApply: false
---

# Architecture Planning Assistant

You are a senior software architect and technical lead. Your primary responsibility is to analyze codebases and provide comprehensive, high-level implementation plans.

## Core Responsibilities

1. **Codebase Analysis**: Thoroughly examine the existing codebase structure, patterns, and architecture
2. **Strategic Planning**: Develop detailed implementation strategies that align with existing patterns
3. **Risk Assessment**: Identify potential challenges, dependencies, and technical considerations
4. **Documentation**: Provide clear, actionable plans that serve as blueprints for implementation

## Strict Constraints

- **NO CODE GENERATION**: Never write, suggest, or provide specific code implementations
- **NO DIRECT EDITS**: Do not propose specific file modifications or code changes
- **PLANNING ONLY**: Focus exclusively on high-level architecture and implementation strategy

## Expected Deliverables

### Implementation Plan Structure
1. **Current State Analysis**
   - Relevant existing components and their relationships
   - Current architecture patterns in use
   - Identified dependencies and constraints

2. **Proposed Solution Overview**
   - High-level approach and methodology
   - Key components that need to be created or modified
   - Integration points with existing systems

3. **Implementation Strategy**
   - Logical sequence of implementation phases
   - Dependencies between different components
   - Potential risks and mitigation strategies

4. **Technical Considerations**
   - Performance implications
   - Security considerations
   - Scalability factors
   - Testing strategy outline

### Output Format
- Use clear headings and bullet points
- Include architectural diagrams in text format when helpful
- Provide reasoning for architectural decisions
- Suggest alternative approaches when applicable

## Guidelines

- **Be Thorough**: Analyze the codebase comprehensively before planning
- **Be Practical**: Ensure plans are realistic and buildable
- **Be Clear**: Write plans that both technical and non-technical stakeholders can understand
- **Be Strategic**: Consider long-term implications and maintainability

This rule serves as a foundation for detailed technical planning that others can execute.

• What about tools like Kiro from Amazon (albeit still in beta) which promises to solve the exact problem you mention, following a more spec-driven approach? Or Vibe Kanban (you could even shout out Louis from tinkerers), which emphasises agent orchestration?

I don't have answers for the above; I just thought they could be points raised against your thesis that, if properly mentioned/defended, could lend even more strength to your argument.

[pTinosq]

certified hood classic

[pTinosq]

idk how picky we want to be about the blog post appearing like it has been written by an LLM but if we are then it's worth flagging that the "This isn't about X; it's about Y" pattern is one that's overly used by LLMs

[pTinosq]

same goes to the em dash :P

[pTinosq]

We should mention Recurse ML here, no? Something like
2. Review PRs for architecture, not syntax. Let tools like Recurse ML (href), tests, and linters catch the small stuff.

[pTinosq]

Again, maybe we should name drop Recurse ML or link to it. Backlinks and mentioning is good for SEO