The Modular Imperative: Rethinking LLMs for Maintainable Software
summary
Runs experiments with cursor and cloud sonnet 4 and finds models default to monolithic code, often amplifying complexity and introducing bugs when porting or editing. Adding a rubric DSL generates per-module contracts, yields single-file edits, avoids breaking signature changes, and can place new features in new modules. Models mimic modular patterns but leave hidden dependencies and broken encapsulation, so scaffolding like dependency graphs plus concrete checks improves targeted edits and verification.
AI-written summary · about
chapters (10)
- 0:00Modular LLMs for maintainable code
- 1:06Developer frustrations with AI code
- 2:28Why modularity matters
- 3:51Experiments on unguided modularity
- 5:58Improving modularity with Rubric specs
- 7:42LLMs mimic modularity blindly
- 8:25Encoding modularity as a principle
- 10:30Challenges of LLM modularity
- 12:14Summary and open questions
- 13:58Q&A on design decisions
related talks
38mNobody Pages the LLM: Engineering Rigour for Vibe Coding
10mRethinking collaboration: LLMs, teams, and cognitive load
19mLLM codegen fails and how to stop 'em
53mSemantics-based program manipulation in the age of LLMs
33mClean Code Revisited in the Age of AI
01h 15m10x Development: LLMs For the working Programmer
30mEfficient programming with Scala and LLMs
17mRLM: Recursive Language Models for Large Codebases