Building Software with LLMs: Part 1 – The Pain Points (blog.laurentcharignon.com)

Author ran 10 parallel LLM coding sessions (Claude Code + Emacs) and cataloged the real-world pain points that only appear at scale: session sprawl and no visibility into which conversations need attention, lost audit trails and context compaction by token limits, LLMs introducing regressions, language-specific edit fragility (notably parenthesis-brittle Lisps), slow cold-starts for new projects, isolated sessions that don’t share knowledge, poor diff review without IDE integration, lack of long-term memory, coordination problems for parallel agents, and dangerous ease-of-access to private data. The piece frames these as systemic workflow problems rather than mere model faults and previews a multipart series on ergonomic, abstraction, orchestration, and learning solutions. Key technical remedies and implications: enforce test-driven changes (treat every LLM edit like a pull request: make test), use persona-based prompts to get consistent architecture/style, add validation tooling to pinpoint structural errors (e.g., unbalanced parens), snapshot and preload project context to avoid cold starts, build a shared-context/orchestration layer so sessions can coordinate, and integrate LLMs with IDEs for proper diff review. For safety, move access control out of prompts into OS-level enforcement (user/group permissions, chattr, directory/pattern filters) and API-level blocks so sensitive files are impossible to read. These patterns highlight that building reliable, scalable LLM-assisted engineering requires new tooling, observability, and enforced constraints—not just better prompts.