Further Learning

Section 15 · Lesson 5 · Level: beginner · ~12 min · Prereq: none

Why this matters

This wiki is deliberately shallow in one direction: it covers a lot quickly and stops where the field becomes a moving target. This page is the handoff — a grouped index of sources worth your next hour, with who each one is for and what to read first. None of them will stay current, which is why the last two sections exist.

Courses, and the order that works

• Anthropic's courses — exercises rather than prose, in a recommended order: API fundamentals, the prompt engineering interactive tutorial, real-world prompting, prompt evaluations, then tool use. Do the evaluations course before you build a model feature. Prefer clicking to notebooks? There is a web version.
• Agent Skills with Anthropic — for the reader who has written one skill and wants the shape of a library.
• Spec-driven development with coding agents — for the reader whose agent keeps solving the wrong problem precisely.

Agent engineering, from the people building it

• Anthropic Engineering — browse the root, and read in this order: Building effective agents for the vocabulary, Effective context engineering for AI agents, then Agent Skills. Best practices for Claude Code is the most immediately useful, and Steering Claude Code answers "rules file, skill, hook or subagent?". Vendor write-ups: good mental models, worth verifying on your own repo.

Specification-driven development

• Understanding spec-driven development: Kiro, spec-kit and Tessl — vendor-neutral and the best first read.
• Spec-driven development with AI (GitHub blog) — the workflow with a real toolkit.

CI/CD, Actions and hardening

• GitHub Actions documentation and workflow syntax — the two pages you will return to most.
• Secure use reference — read it after your first green pipeline and before your first third-party action.
• Pinning GitHub Actions for security — why @v3 is a promise and a commit SHA is a fact.

Deployment and databases

• Railway docs and deploying with the CLI — for Capstone 1; railway up --ci and project tokens are the parts that matter.
• Neon documentation — read the branching material before you build environments.

MCP

• Model Context Protocol and the specification — read the architecture once, then skim tools, resources and prompts.
• github/github-mcp-server — read one server's code before you install five.
• Read MCP security risks first; a server is code you invite to act for you.

Security: OWASP first

• genai.owasp.org and the LLM Top 10 archive — the editions differ, so check which one you are reading; the 2026 list is current. For a model feature, start with LLM01 prompt injection, LLM05 improper output handling, LLM06 excessive agency and LLM10 unbounded consumption.
• Agentic AI — threats and mitigations — the same failures once the model can act.
• LLM prompt injection prevention cheat sheet and MCP tool poisoning — the two checklists to work against.
• Slopsquatting: hallucinated package names — check that a dependency exists before you install it.

Evals

• Evaluation best practices (OpenAI) — best first read.
• Eval-driven development (DeepEval) — the loop, with examples.
• Best practices for LLM evaluation (Databricks) — when your eval set gets real.

System design

Start with this wiki's own Section 06: Why architecture before code, Thinking in boundaries, Reliability patterns. Beyond that, prefer writing that states its date and the versions it tested.

Open skill and server collections

• anthropics/skills — read the simplest skill end to end; it is ten minutes and it recalibrates yours.
• modelcontextprotocol/servers — what other people have plugged in, and what they had to write to do it.

How to judge a resource, and what will rot

Four questions: does it carry a date, a version or a commit hash; is it vendor-neutral or a product page; does it ship code you can run; does it say what it tested against? Three yeses earns an hour; none earns a closed tab.

This field moves fast and links rot. Every number in this wiki — free-tier limits, model names, action versions, spec revisions — is either marked "as of" or left out, and the same rule applies to everything above. Check the date before you trust a figure, and expect a 2025 answer to be wrong about a 2026 product. Dead link? Search the title: docs are reorganised far more often than deleted. If a page here has rotted, that is a contribution, not a complaint.

Try it

1. Pick one group above and read only its first item, start to finish. Note its date.
2. Run the code in it. No code? Note where it was tested.
3. Take two sources on the same topic from different vendors and write down one claim they disagree on.
4. Add the three sources you finished to your notes file with dates. Not the ten you bookmarked.

Common mistakes

• Treating a vendor blog as neutral — a good mental model and a biased comparison. Verify on your own repo.
• Starting three courses at once — finishing one beats sampling four.
• Trusting a number with no date — quota, price and version answers expire quietly.
• Installing an MCP server before reading about tool poisoning — a server is code acting with your credentials.
• Collecting links instead of running code — an unread bookmarked course teaches nothing.

Key takeaways

• Read one source to the end and run its code; a bibliography is not knowledge.
• The OWASP GenAI pages are the only group to read before shipping anything model-facing.
• Prefer documentation roots over deep links you cannot verify, and check a page's date before trusting its numbers.
• Everything here will age; the four-question test ages much more slowly.
• When you find the better source, add it here through a pull request.

Further learning

• Link index — every verified link used across this wiki, in one place.
• Contributing to this wiki — how to add the source that should have been on this page.
• The 30-day learning plan — where these sources fit into practice.
• Capstone 2 — the exercise that will tell you whether you understood the security group.