A working reference: 20 prompts, the repos, the MCP servers and the models

This is a reference post rather than an argument. It is what I actually reach for, written down mostly so I stop re-deriving it every few months.

Some context on where it comes from. I went through an AI generalist fellowship while holding down a full-time engineering job, which mainly taught me how much of this field is unlearning. I have had an agent solve a two-week-old deployment failure that a room of us could not. I have also had a local model confidently judge a compliance rule wrong in a hackathon, which was cheap to discover because we had built the experiment to be checkable. Both of those are in here somewhere.

Treat the model section in particular as a snapshot with a date stamped on it. That part ages in weeks.

Twenty prompt patterns worth keeping

1. Show your working before your answer, then state the answer separately.
2. List what you would need to know to be confident, before answering.
3. Give me three approaches with the trade-off that decides between them.
4. Argue the opposite case as strongly as you can.
5. What in this is a fact, what is an inference, and what is a guess?
6. Rewrite this so a smart person outside the field can follow it.
7. Find the assumption that, if wrong, breaks the whole thing.
8. Review this as the person who will be paged when it fails.
9. Reduce this to the smallest version that still does the job.
10. What would make you change your mind about this recommendation?
11. Translate this requirement into test cases before writing code.
12. Explain the failure mode, not just the fix.
13. Here is the error and the surrounding code — what did I not paste that you need?
14. Summarise this for someone who has ten seconds, then for someone who has ten minutes.
15. Check this for things that are true but misleading.
16. What is the boring, well-understood solution I am overlooking?
17. Grade this against the criteria I gave you, one at a time, with evidence.
18. If this is wrong, where will it be wrong first?
19. Ask me one question at a time until you can do this properly.
20. What did I ask for that I probably should not have?

Repositories worth reading, not just installing

• The Model Context Protocol specification and its reference servers — the clearest worked example of tool interfaces done deliberately.
• LangChain and LlamaIndex — read the retrieval and chunking code even if you use neither; the trade-offs are visible in the source.
• vLLM — where inference throughput is actually won or lost.
• Evaluation harnesses generally: whichever you pick, the discipline of a fixed test set matters more than the framework.
• Any well-maintained agent framework's tool-calling loop. It is a hundred lines and understanding it removes most of the mystery.

MCP servers that earn their place

• Filesystem — scoped, read-only where possible.
• Git and GitHub — history and review context, not just files.
• A database server (Postgres or SQLite) — schema-aware querying beats pasted dumps.
• Fetch — retrieval with the source preserved.
• A browser driver such as Playwright — for what only a real page can answer.
• Memory or a note store — the difference between a session and a colleague.
• An issue tracker — where the intent behind the code is written down.
• A search server — for what is outside your repository.

The pattern worth noticing: the useful servers all supply context that is expensive for a human to gather and cheap for a machine to hold.

Models: a shortlist, with the caveat stated first

This moves faster than any blog post can. Verify before you commit. As of writing, the families I see doing real work:

• Claude — Opus for hard reasoning and long agentic runs, Sonnet as the everyday workhorse, Haiku where latency and cost dominate.
• GPT — broad capability and the largest tooling ecosystem around it.
• Gemini — very long context and strong multimodal handling.
• Llama — the serious open-weights default when you must self-host.
• Mistral — small models that punch above their size, permissive licensing.
• DeepSeek — strong reasoning at unusually low cost.
• Qwen — excellent multilingual coverage and a wide size range.
• Command — retrieval-oriented, built for grounded enterprise answers.
• Phi — small-model quality where the constraint is the device.
• Grok — real-time-leaning, worth watching rather than standardising on.

The only durable advice here

Choose by evaluation on your own task, not by leaderboard. Build the eval set before you pick the model, and the choice mostly makes itself — and remakes itself cheaply when something new lands.

How I would use this list

Not as a shopping list. Almost everything here is worth reading once and adopting only if it answers a problem you already have.

The prompt patterns are the part I would take first, because they cost nothing and they change the quality of what you get back immediately. Most of them are variations on one idea: make the model expose its reasoning and its uncertainty, so that you have something to check rather than something to accept. That is the same instinct I apply to a compliance finding or a root-cause claim from an engineer. The tool changed. The habit did not.

The rest of it is infrastructure, and infrastructure should follow need. I have watched teams stand up a full retrieval stack before establishing that their documents were worth retrieving.

If you take one thing: build the checkable version first. Every experiment on this list that taught me something was one where I could hold the output against reality. The ones that taught me nothing were the impressive demos.