I turned ideas from thirteen well-known software engineering books into practical rule files for AI coding agents. The repository includes book-specific rules and one unified Codex AGENTS.md file for everyday implementation, review, refactoring, testing, documentation, legacy, production, data, and domain-modeling tasks.

Open the repository

Supported Tools

• Codex: AGENTS.md
• Cursor: .cursor/rules/*.mdc
• Claude Code: .claude/rules/*.md

The important part is task fit: use the unified rule set as a broad default, then choose a focused rule set only when the task needs stronger guidance for architecture, refactoring, legacy code, production systems, data systems, or domain modeling.

Books

• A Philosophy of Software Design by John Ousterhout
• Clean Architecture by Robert C. Martin
• Clean Code by Robert C. Martin
• Code Complete by Steve McConnell
• Designing Data-Intensive Applications by Martin Kleppmann
• Domain-Driven Design by Eric Evans
• Domain-Driven Design Distilled by Vaughn Vernon
• Implementing Domain-Driven Design by Vaughn Vernon
• Patterns of Enterprise Application Architecture by Martin Fowler
• Refactoring by Martin Fowler
• Release It! by Michael T. Nygard
• The Pragmatic Programmer by Andrew Hunt and David Thomas
• Working Effectively with Legacy Code by Michael Feathers

Update, 25.04.2026

A few days ago, I published my "translations" of 13 software engineering books into AGENT rules.

Yesterday, I shared the project on Reddit. So far, the post has reached 166,000 views, the repo got 340 GitHub stars, and, most importantly, I received a lot of valuable feedback about the idea.

I wanted to summarize the most constructive criticism here.

1. There is no clear measurement of improvement (9/10)
   This is probably the most important point. Right now, the project is based mostly on intuition and personal experience. To make it truly useful, it needs some form of evaluation: before/after comparisons, benchmark tasks, review effort, defect counts, or at least examples where the rules clearly changed the agent's output.
2. This can burn tokens and pollute the context (9/10)
   Many of the generated rule files are large. Loading too many rules at once can increase token usage, crowd out task-specific context, and make the agent less focused. More instructions do not automatically mean better behavior.
3. Skills, RAG, or progressive loading may be a better fit than one huge AGENTS.md (9/10)
   This is a strong point. These rules probably work best when loaded selectively. Refactoring rules should be used when refactoring. Legacy-code rules should be used when working with legacy systems. DDIA-inspired rules should be used for data-heavy systems. Not everything has to be in the context all the time.
4. A short set of project-specific rules may work better (9/10)
   A compact AGENTS.md with 10-15 strong, testable, project-specific instructions may be more useful in daily work than a large generic rule set. Book-derived rules can be a starting point, but the final rules should probably be adapted to the actual codebase.
5. The model may ignore many of the rules anyway (8/10)
   LLMs do not reliably follow hundreds of instructions at once. A long rule file may increase coverage, but it can also create ambiguity, conflicts, and instruction fatigue. The agent may follow the "vibe" of the rules rather than each rule precisely.
6. Rules should also come from real project failures (8/10)
   Book-derived rules are useful, but the most valuable rules are often written after something actually went wrong. "Do not do X" becomes much stronger when X happened in your project and caused a specific problem. Production incidents create better rules than abstract principles alone.
7. Rules from different books may conflict (8/10)
   Clean Code, Clean Architecture, DDD, DDIA, PoEAA, Refactoring, and A Philosophy of Software Design do not always push in the same direction. They operate at different levels of abstraction and optimize for different tradeoffs. A good agent rule system needs priorities, not just more rules.
8. This may cause overengineering (8/10)
   If the agent applies heavyweight architecture rules to a small feature or simple CRUD task, it may introduce unnecessary layers, factories, ports, adapters, aggregates, or domain events. The rules need to be applied with context and proportion.
9. The project could include more AI-agent-specific material (7/10)
   Software engineering books teach good design, but coding agents also need operational guidance: how to plan, how to use tools, how to verify changes, how to run tests, how to avoid guessing, how to keep edits scoped, and how to recover from failed runs.
10. Too many abstract rules may lead to pseudo-compliance (7/10)
    The agent may produce code that looks architecturally "proper" while still missing the actual task. The goal is not to make code look like it follows a book. The goal is to make the solution correct, maintainable, and appropriate for the problem.
11. There may be legal or licensing concerns (6/10)
    This came up too. My current view is: the project contains practical agent instructions inspired by software engineering principles, not replacements for the books themselves.
12. The LLM may already know these books (5/10)
    That is partly true. The model probably knows many of these ideas already. But knowing a principle and applying it consistently are different things. Developers also know many best practices and still violate them under pressure. Explicit rules can help, but they need to be short, relevant, and actionable.
13. Some principles may be outdated in the AI coding era (5/10)
    AI changes the economics of writing, rewriting, and refactoring code. But many fundamentals still matter: readability, modularity, testability, resilience, clear boundaries, and maintainability.

My current conclusion:

This project is probably most useful not as "put 13 books into AGENTS.md and hope for the best," but as a source library for building smaller, task-specific, project-specific rule sets.

The next step is to experiment with selective loading, skills, RAG, and measurable comparisons.

Thanks to everyone who gave thoughtful criticism. The Reddit discussion was much more useful than I expected.

Update, 27.04.2026: Addressing Reddit Feedback

I made a second pass over the repository after the Reddit discussion. The biggest change is that the project no longer presents one large rule file as the natural default. Every book now ships in three versions: full, mini, and nano.

full is now treated as the complete reference version: useful for audits, review, and deriving smaller rules, but not something I would load globally for normal work. mini is the recommended working layer for most real tasks. It keeps the book's decision pressure, triggers, and tradeoffs, but removes enough bulk to avoid turning the prompt into a wall of generic advice. nano is the compact fallback for very tight always-on budgets, portable setups, or tools where even mini would compete with more important project context.

This directly addresses one of the strongest objections: token burn. The repo now says, in practice: pick one primary rule set, use mini by default, use nano only when you really need a tiny baseline, and keep full as reference material. That is a much healthier default than trying to stuff thirteen books into one global AGENTS.md.

I also added a more explicit usage guide for Codex, Claude Code, and Cursor. It describes always-on rules, scoped rules, on-demand rules, skills, nested instruction files, MCP, retrieval, and RAG. The important shift is that the repository is now positioned as a source library for building smaller, task-specific and project-specific rule layers, not as a single magic prompt.

The README now includes a release matrix with line counts, rule counts, and raw file sizes for every full, mini, and nano file. The workbench also keeps traceability files and a compression process, so it is easier to see what survived compression and why. This still does not solve the hardest criticism: there are no real evals yet. But at least the project is now more auditable and less hand-wavy about what each file is for.

I updated the criticism document as well. Some points are now largely addressed, especially context pollution, progressive loading, and overengineering risk. Others are only partially addressed: measurement, model obedience, real project failures, and legal concerns are still open problems. That feels like the honest state of the project.

The current recommendation is simple: do not load everything. Start with one mini rule set that matches the task. Use nano only as a tiny baseline. Bring in other books on demand when the work actually needs them.