ai-engineering-cheatsheets: three Markdown decision tables, reviewed as a reference set
Give you decision-ready references for the most common AI engineering problems
At a glance
- What is it?
- Louis-Francois Bouchard's repository packages AI engineering decisions as three Markdown cheatsheets: a playbook, an agent architecture guide, and an anti-slop writing guide. The value is the decision-table format, not the prose, and the model preferences are explicitly dated to August 2026.
- Who is it for?
- Adopt this if you need a compact, table-driven reference for choosing between workflow, single agent, and multi-agent designs, or for assembling a RAG and eval stack without reading a book first. Skip it if you need runnable code, because the repository is Markdown documents and the README points to paid Towards AI courses for lessons and hands-on projects.
- Can I use it commercially?
- Not without permission. GitHub finds no licence file in the repository, and without a licence all rights are reserved by default: you may read the code but not reuse it. Check the README, or ask the authors, before using it.
- Is it still maintained?
- Yes. The repository last received commits 43 days ago.
- What is it written in?
- GitHub does not report a main language for this repository.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What the repository actually contains
Three Markdown files, plus a README that explains how to use them. The README names them directly: AI_Engineering_Playbook.md, Agent_Architecture_Guide.md, and Anti_Slop_AI_Writing_Guide.md. The stated goal is to "give you decision-ready references for the most common AI engineering problems." Each file is described as containing decision tables: you open the cheatsheet, find your situation in the table, and follow the recommendation.
The repository metadata does not list a primary language or a license. That matters more than it sounds. A repository of Markdown files with no license file is not automatically reusable in a commercial setting, and the README does not state terms. If you plan to paste these tables into internal documentation, that is the first thing to check, not the last. Nothing in the supplied material says a LICENSE file exists, so treat the reuse question as open.
The decision-table format is the whole product
Most AI reference material is prose that describes options without ranking them. This repository inverts that. The README's instruction is procedural: find your situation in a table, follow the recommendation. The AI Engineering Playbook is described as covering technique selection, model choice, effort level, modality workflow, prompting strategy, RAG setup, memory pattern, eval method, and production config. That is a wide surface, and the table format is what keeps it navigable.
The Agent Architecture and Operations Guide narrows to one axis: workflow versus single agent versus multi-agent, then operation concerns listed as curated context, evidence stores, phased review, portable skills, feedback loops, and safe scheduling. Those are specific enough to be checkable against your own system. If your agent has no evidence store and no phased review step, the guide names the gap.
The third file is different in kind. The Anti-Slop AI Writing Guide targets output quality rather than system architecture, with a 7-section prompt, what the README calls "checkable anti-slop rules," a long-form starting point attributed to Towards AI, an evidence-first review step, one targeted rewrite, and platform checks. The word checkable is doing real work there: rules you can verify against a draft are more useful than style advice you can only agree with.
How you consume it, and what that implies
There is nothing to install. The README gives a three-step loop: open the relevant cheatsheet, find your situation in the decision tables, follow the recommended approach. For the Anti-Slop guide the order is stricter: assemble the sources first, fill in the complete template, finish the draft, then run the separate evidence-first review before your human edit.
That sequence is the most concrete instruction in the repository, and it is worth noting why. It forces source collection ahead of drafting, which is the step most writing workflows skip. If you follow only one thing from this repository, that ordering is the candidate.
Because the artifacts are Markdown, your integration path is whatever your team already uses for documents: a docs folder, a wiki, a pull request template. There is no CLI, no config file, no package to pin. Any claim about a command to run would be invented, so there is none to give.
The August 2026 snapshot is the main limitation
The README states plainly that model and tool preferences are "a snapshot from August 2026" and instructs readers to "treat them as tested starting points, then validate them on your own workload." That is an honest framing, and it is also the repository's structural weakness. A decision table that recommends a model is only as good as the model landscape at the time of writing. Model names, pricing, context limits, and relative quality move faster than a Markdown file maintained by one author.
The last push recorded is 2026-08-04, consistent with the snapshot date, and no releases were retrieved. So the freshness question is not hypothetical: the tables are as current as that push and no more. Validation on your own workload is not optional advice here, it is the documented condition of use.
A second limitation is scope. The README describes recommendations and frameworks, not implementations. The courses are where "full lessons, code, and hands-on projects" live, per the README. If your need is a working RAG pipeline you can run today, a table telling you which RAG setup to pick is upstream of your problem.
Where it sits against a hand-rolled internal doc
The realistic alternative is not another repository. It is the decision doc your team already keeps, or should keep: a page listing which model you use for which task, when you escalate to a multi-agent design, and what your eval method is. That document has one advantage this repository cannot match, which is that it reflects your constraints, your data residency rules, and the models you are actually allowed to call.
The difference in approach is authorship and specificity. A hand-rolled doc is written after you hit the problem; these cheatsheets are written before, as a starting taxonomy. The Agent Architecture Guide's workflow-versus-single-agent-versus-multi-agent split is a useful frame to impose on that internal doc, because most teams default to agents when a workflow would do, and the guide makes the choice explicit rather than assumed. Use the repository to structure the decision, then record your own answer next to it. The tables are the prompt, not the record.
Maintenance cost and the licence gap
Maintenance cost for a consumer of this repository is low and mostly manual: re-read the tables when your model stack changes, and check whether the August 2026 snapshot has been superseded by a later push. There is no dependency to upgrade, no version to pin, no breaking change to absorb. The cost is attention, not engineering time.
For the author, the cost is the opposite. Keeping model and tool recommendations current across ten decision areas is ongoing work, and the repository carries no release history to signal how often that work happens. The single last-push timestamp is the only cadence signal available.
On licensing, the supplied material does not state a license. That is not a small omission for a repository whose entire value is text meant to be reused in engineering decisions. Do not assume permissive terms because the content is Markdown. Confirm the license from the repository itself before copying tables into internal or client-facing documentation. This is a factual gap in the material, not legal advice.
Who this is for, stated narrowly
It fits an engineer or tech lead who already knows the vocabulary and needs a compact way to compare options: which prompting strategy, which RAG setup, which memory pattern, whether the problem warrants an agent at all. The Agent Architecture Guide is the strongest candidate for that reader because it addresses a choice teams get wrong by default.
The Anti-Slop guide fits a different reader: someone producing long-form technical writing who wants a review step with rules that can be checked rather than a list of adjectives to avoid.
It does not fit someone looking for a library, a scaffold, or a runnable example. The README routes that reader to the Towards AI courses for code and projects, which is a clear boundary: the repository is the reference layer, the courses are the implementation layer. Decide which layer you are missing before you spend time here.
Editorial conclusion
Adopt this if you need a compact, table-driven reference for choosing between workflow, single agent, and multi-agent designs, or for assembling a RAG and eval stack without reading a book first. Skip it if you need runnable code, because the repository is Markdown documents and the README points to paid Towards AI courses for lessons and hands-on projects. Before relying on it, open AI_Engineering_Playbook.md and check whether the August 2026 model snapshot still matches the models you actually deploy.
Community notes