Why LLMs can't really build software
TL;DR Highlight
Zed editor's CEO argues that LLMs lack the core software engineering skill of 'maintaining mental models' — analyzing the realistic limits and proper use of AI coding tools.
Who Should Read
Developers using or evaluating AI coding tools (Cursor, Claude Code, Copilot, etc.) who need criteria for deciding what to delegate to LLMs vs. handle personally.
Core Mechanics
- The core of software engineering is simultaneously maintaining two mental models — 'what the requirements are' and 'what the code actually does' — and iteratively closing the gap. LLMs can't hold and compare both models at once.
- LLMs generate code well but can't judge whether to fix the code or fix the test when tests fail. When frustrated, they tend to rewrite everything from scratch.
- Breaking work into small units is key — LLMs struggle with large, interconnected changes but handle focused, well-scoped tasks much better.
- TDD (Test-Driven Development) with explicit Red-Green-Refactor stages in prompts helps LLMs stay on track.
Evidence
- A developer using Cline + Sonnet 3.7 for Rails TDD countered: 'Writing tests first and reviewing in small units works surprisingly well — at least junior engineer level.' But admitted 'not perfect, some bugs it can't solve.'
- A GPT-5 user building a WebGPU/wgpu renderer hit a wall with runtime errors — the model kept making changes without understanding the problem, eventually breaking more than it fixed.
- Consensus: LLMs are powerful code generators but poor software engineers — the gap is in judgment, not generation.
How to Apply
- When delegating complex tasks to LLMs, break them into small units — avoids mental model maintenance failures and dramatically reduces wasted iterations.
- For TDD-based LLM usage, specify the Red-Green-Refactor stage in your prompt: 'You are in the GREEN stage — write only the minimal code to pass this test.' This prevents code/test confusion.
- Use LLMs for code generation but maintain the mental model yourself — review generated code against requirements rather than trusting it to understand the system holistically.
Terminology
Related Papers
Show HN: OpenKnowledge – open source AI-first alternative to Obsidian/Notion
Git 기반 동기화와 Claude/Codex/Cursor 연동을 내장한 로컬 우선 마크다운 에디터로, AI 에이전트의 두 번째 뇌(LLM Wiki)로 활용할 수 있는 오픈소스 도구다.
The Unfireable Safety Kernel: Execution-Time AI Alignment for AI Agents and Other Escapable AI Systems
AI 에이전트가 자신의 안전장치를 우회할 수 없도록, 에이전트 프로세스 바깥에 수학적으로 증명된 강제 통제 게이트를 배치하는 아키텍처
RubyLLM: A Ruby framework for all major AI providers
OpenAI, Claude, Gemini 등 주요 AI 프로바이더를 단일 인터페이스로 통합한 Ruby 프레임워크로, Rails 통합과 에이전트 기능까지 지원해 Ruby 개발자가 AI 기능을 빠르게 붙일 수 있다.
Qwen-AgentWorld: Language World Models for General Agents
Alibaba Qwen 팀이 AI 에이전트가 행동 결과를 미리 시뮬레이션할 수 있는 'Language World Model'을 공개했다. 에이전트 훈련과 실행 경로 검증에 새로운 패러다임을 제시하는 연구다.
SHERLOC: Structured Diagnostic Localization for Code Repair Agents
버그 위치만 알려주는 게 아니라 '왜, 어떻게 고쳐야 하는지'까지 진단 리포트를 생성해서 코드 수정 에이전트의 성능을 높이는 training-free 프레임워크
Show HN: peerd – AI agent harness that runs entirely in your browser
백엔드 서버 없이 Chrome/Firefox 확장 프로그램으로만 동작하는 AI 에이전트 실행 환경으로, 브라우저 탭을 직접 조작하고 WASM Linux VM까지 구동할 수 있어 프라이버시와 보안을 동시에 챙길 수 있다.