AI for developers

Papers 7

• Attention Is All You Need, the original transformer paper

  The 2017 paper that introduced the transformer and dropped recurrence in favour of attention. Dense in places, but short, and nearly every modern language model descends from it. Pair it with the illustrated walkthrough.

  arxiv.orgPapersAdvanced

• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks

  The paper that named RAG: a generator combined with a dense vector index over Wikipedia, trained together. Useful for understanding what the acronym originally meant before it became a catch-all for "put documents in the prompt".

  arxiv.orgPapersIntermediate

• ReAct: let the model think between tool calls

  The ReAct paper (Yao et al.) proposes interleaving reasoning traces with actions, so the model plans, acts, looks at what came back, and adjusts. Most agent loops you will meet today are descendants of that idea. You can reproduce the pattern with plain prompting before reaching for a framework: Your code does the boring part: parse the Action, run it, append the Observation, and call the model again. Stop on Final or after a fixed number of rounds. Reading the paper is worthwhile for its failure analysis: the loop only helps when observations are reliable, so spend your effort on tool quality.

  arxiv.orgPapersIntermediate

• Lost in the Middle: where you put evidence in a long prompt matters

  This paper measured how models use long contexts and found performance tends to be best when the relevant information sits at the beginning or end, and worse when it is buried in the middle. Models differ and have changed since, so treat it as a reason to test rather than a law. A quick experiment for your own RAG or document-QA setup: If the middle is weaker, cheap mitigations include retrieving fewer, better passages, reranking so the strongest evidence lands near the edges, and repeating the question after the context. Whatever you change, rerun the same 20 questions so you know it helped.

  arxiv.orgPapersIntermediate

• LLM-as-judge works, and it has biases you must control for

  The MT-Bench paper (Zheng et al.) studied using strong models to grade other models' answers. Its finding was encouraging: strong judges agreed with human preferences about as often as humans agree with each other. It also listed biases: position bias, verbosity bias and self-enhancement bias (favouring text from the same model family). Controls you can add when you build a judge: Treat the judge as an instrument that needs calibration against human labels on your task, not as ground truth.

  arxiv.orgPapersIntermediate

• QLoRA: fine-tune a large model on modest hardware

  QLoRA (Dettmers et al.) backpropagates through a frozen, 4-bit quantised base model into small LoRA adapters. The authors report fine-tuning a 65B-parameter model on a single 48GB GPU while keeping full 16-bit fine-tuning quality, which is why the technique spread so widely. You do not need to implement it. The Hugging Face PEFT library packages LoRA-style methods, and the shape of the setup is: Before reaching for fine-tuning, check three cheaper options: better prompts, retrieval, and a small eval set that shows what is actually failing. Fine-tuning is best for style, format and narrow behaviours, not for loading in fast-changing facts. Keep the data clean; adapters faithfully learn your mistakes too.

  arxiv.orgPapersAdvanced

• Indirect prompt injection: the attack arrives inside the data

  Greshake et al. studied indirect prompt injection: instead of typing malicious instructions to a model, an attacker plants them in content the application will later retrieve, such as a web page or document. The model reads them as part of its context and may follow them. Retrieval and tool use are what make this practical. Defensive habits to apply when you build: Labelling data as untrusted lowers risk but does not remove it, so the structural controls matter most. Read the paper's threat taxonomy to see how many routes into a context window exist.

  arxiv.orgPapersAdvanced

Agents 7

• Building Effective Agents: workflows vs agents

  A calm essay that separates predefined workflows from model-directed agents and lays out five composable patterns. Its main advice is to start with the simplest thing that works and add complexity only when it measurably helps.

  anthropic.comAgentsIntermediate

• LLM Powered Autonomous Agents by Lilian Weng

  A thorough overview of agents built around a language model, organised around planning, memory and tool use, with pointers to the research behind each. A good map of the territory before you pick a framework.

  lilianweng.github.ioAgentsIntermediate

• LangGraph: stateful, long-running agent orchestration

  MIT-licensed, low-level framework for agents modelled as stateful graphs, with durable execution so a run can resume after a failure. Reach for it when a plain loop stops being enough and you need control over state and flow.

  github.comAgentsAdvanced

• The tool-use loop in four steps, and the stop reason that drives it

  Tool use looks magical until you see the loop. You describe your tools (name, description, input schema), the model answers with a structured call instead of text, your code runs it, and you send the result back. The documented signal for "the model wants a tool" is stop_reason: "tool_use" plus tool_use blocks; your reply goes in a tool_result block carrying the matching tool_use_id. Skeleton (Anthropic-style shapes, other providers differ in names but not in structure): Two habits worth copying: always cap iterations, and have run_tool return errors as text the model can read rather than raising.

  platform.claude.comAgentsBeginner

• Write tool descriptions like an onboarding note for a new teammate

  Agents fail on tools more often than on reasoning, and the fix is usually in the tool definition. The guidance in Anthropic's engineering write-up boils down to a few rules you can apply today: - Name tools with a shared prefix per service or resource, so similar ones group together. - Describe niche terms and query formats as you would to a new colleague, and prefer unambiguous parameters (user_id rather than user). - Return high-signal fields (names, types) instead of raw UUIDs, and offer a concise/detailed switch. - Paginate, filter and truncate by default so one call cannot flood the context. - Make errors say how to fix the input. A before/after: Then test with realistic multi-step tasks and read the transcripts to see where the agent hesitates.

  anthropic.comAgentsIntermediate

• Context engineering: compaction, notes and sub-agents

  Long agent runs fail when the context fills with stale detail. Anthropic's engineering article frames context engineering as curating the smallest useful set of tokens at every model call, and names techniques for work that outgrows one window: 1. Compaction: summarise a nearly full conversation and continue in a fresh window. 2. Structured note-taking: the agent writes progress to a file and reloads it later. 3. Sub-agents: a worker explores in a clean context and hands back a condensed summary. 4. Just-in-time retrieval: keep paths and queries in context, load the content only when needed. A cheap way to start is a notes file: Instruct the agent to update it after each milestone and to read it first in any new session. It costs a few lines and survives resets.

  anthropic.comAgentsIntermediate

• The lethal trifecta: the three capabilities you must not combine carelessly

  Simon Willison names three capabilities that become dangerous together in an agent: access to your private data, exposure to untrusted content, and the ability to communicate externally in a way that could exfiltrate data. If one agent has all three, an attacker who can get text in front of it may be able to steer it into sending your data out. Use it as a design review: Removing the outbound channel (no arbitrary network, no auto-loading links) is often the cheapest cut. He also points out that mixing tools from different MCP servers can assemble the trifecta without anyone intending to. Guardrail prompts help but are not a reliable boundary; architecture is.

  simonwillison.netAgentsIntermediate

Local AI 7

• Ollama: run open models locally with one command

  Open-source runner that pulls a model and serves it with ollama run, plus a local REST API on port 11434. The quickest route to trying open models offline; customise behaviour later with a Modelfile.

  github.comLocal AIBeginner

• llama.cpp: C/C++ inference for local models

  The engine behind much of the local-model ecosystem, running GGUF models on CPUs and GPUs. It includes llama-server with an OpenAI-compatible API. Choose it when you want control over quantisation, context size and offload.

  github.comLocal AIIntermediate

• Open WebUI: a self-hosted chat interface for local models

  Open-source, self-hosted web interface designed to run fully offline. It connects to Ollama or any OpenAI-compatible API, so you can give a team a familiar chat UI over models you host yourself.

  github.comLocal AIBeginner

• Shape a local model with an Ollama Modelfile

  Once Ollama is installed, a Modelfile lets you save a configured variant instead of retyping settings. It starts from a base with FROM (a model name or a local GGUF file) and can set parameters and a system prompt. Build and run it: Why bother: the behaviour travels with the name, so teammates get the same setup, and you can keep several variants (a strict reviewer, a loose brainstormer) side by side. Keep the SYSTEM text short and testable. Check the Modelfile reference for the full list of instructions and parameters, since they change between releases.

  docs.ollama.comLocal AIBeginner

• Serve a local model over an OpenAI-style API with llama-server

  llama.cpp ships llama-server, an HTTP server that exposes OpenAI-compatible endpoints such as /v1/chat/completions. Because many tools can target an OpenAI-style base URL, this lets editors, scripts and agents use a model on your machine. What the flags do: -m picks the GGUF file, -c sets the context window, --port chooses the port (set it explicitly rather than relying on defaults), and -ngl controls how many layers go to the GPU. If you bind beyond localhost with --host, add --api-key, since the server has no authentication by default. Larger context uses more memory, so raise it only as far as you need.

  github.comLocal AIIntermediate

• Run vLLM when one local user becomes many

  Ollama and llama.cpp shine for one person on one machine. When several users or jobs hit the same model, throughput starts to matter, and vLLM is built for that. Its README highlights PagedAttention for managing attention memory, continuous batching of incoming requests, and an OpenAI-compatible API server. Starting point on a GPU machine: Decide before you deploy: - Will the model fit in GPU memory with room for the KV cache? - What concurrency and context length do you really need? - Who can reach the endpoint, and is there an API key in front? - How will you monitor latency and queueing? Load-test with your real prompt lengths rather than a toy example; batching behaviour depends heavily on them.

  docs.vllm.aiLocal AIAdvanced

• Docker Model Runner: pull and run a model like an image

  If your team already lives in Docker, Docker Model Runner offers a familiar workflow for local models. The docs show commands in the style of the image CLI: You can also configure settings such as context size with docker model configure, per the docs. The appeal is consistency: models are pulled by name from a registry, versions are explicit, and the same muscle memory covers containers and models. It is a reasonable choice for developer machines and CI experiments where you want repeatable pulls without installing yet another runner. Practical tips: pin a specific tag in scripts rather than relying on a default, keep an eye on disk use since models are large, and confirm what hardware acceleration your platform supports in the current docs, because that varies by OS.

  docs.docker.comLocal AIBeginner

MCP 6

• Model Context Protocol: the official introduction

  Home of the open protocol that lets AI applications connect to tools, data and prompts through a common interface. Start with the introduction and architecture pages, then build a small server of your own.

  modelcontextprotocol.ioMCPBeginner

• MCP reference servers repository

  Reference implementations of MCP servers, including a filesystem server. Read the source before writing your own; seeing how tools are declared and results returned is faster than reading the spec cold. Review any server before you run it.

  github.comMCPBeginner

• MCP in one picture: host, client, server and what each owns

  MCP confuses people because three roles share one name. The architecture page separates them cleanly: - Host: the AI application (an editor, a chat app, a CLI agent) that coordinates everything. - Client: a component inside the host that keeps one connection to one server. - Server: a program that provides context, locally over stdio or remotely over streamable HTTP. Servers can expose three primitives: tools (functions the model can invoke), resources (data for context) and prompts (reusable templates). Clients discover tools with tools/list and invoke them with tools/call. Mental model for debugging: When something misbehaves, ask which layer: is the server returning the wrong thing, is the client not surfacing it, or is the host not offering it to the model? The protocol evolves, so confirm details in the current spec.

  modelcontextprotocol.ioMCPBeginner

• Anatomy of an MCP tool: schema, results and the isError flag

  A tool in the MCP spec is a small contract: a unique name, a human-readable description, and an inputSchema written as JSON Schema. Servers can also declare an optional outputSchema for structured results. The part people miss is error handling. Protocol errors (unknown tool, malformed request) are JSON-RPC errors. Failures inside the tool, such as a bad date format, should come back as a normal result with isError: true and a message the model can act on, so it can correct itself and retry. The spec also says there should be a human in the loop who can deny tool calls, and that clients should treat tool annotations as untrusted unless the server is trusted. Design your tools with both in mind.

  modelcontextprotocol.ioMCPIntermediate

• Before you install an MCP server: a security checklist from the spec authors

  The MCP project publishes its own security best practices, and one section should change how you install things: local servers run with your privileges. A one-click config can launch an arbitrary command, so the page says clients must show the exact command and get explicit approval first. A checklist you can apply as a user: If you build servers, the page also covers token passthrough (never accept tokens not issued for your server), SSRF when clients fetch URLs, hijacking of state handles, and scope minimisation. Skim those headings even if you only consume servers; they explain why the rules exist.

  modelcontextprotocol.ioMCPAdvanced

• Code execution with MCP: stop dragging every tool result through the model

  Two costs appear when an agent talks to many MCP tools directly: every tool definition sits in context up front, and every intermediate result passes through the model. Anthropic's article describes an alternative: present MCP servers as code modules the agent can browse, and let it write code that calls them. The shape of it: The document body never enters the model's context; only what the code chooses to return does. The article reports a large token reduction on its own example, but treat that number as illustrative. The trade-off is real: you now need a secure execution sandbox, resource limits and monitoring. Adopt it when tool counts or payload sizes hurt, not by default.

  anthropic.comMCPAdvanced

Courses 5

• Hugging Face LLM Course

  A free, hands-on course on using and fine-tuning transformer models with the Hugging Face libraries. Good first stop if you want to move from calling an API to understanding tokenizers, models and training loops.

  huggingface.coCoursesBeginner

• Hugging Face Agents Course

  A free course on building, running and evaluating AI agents, with practical units rather than only theory. Reach for it when you want a structured path into agents instead of piecing blog posts together.

  huggingface.coCoursesBeginner

• Practical Deep Learning for Coders (fast.ai)

  A free, code-first course that teaches deep learning top-down: you build working models early and learn the theory underneath as you go. A strong fit for developers who learn by running things.

  course.fast.aiCoursesIntermediate

• Neural Networks: Zero to Hero

  Free video series by Andrej Karpathy that builds from backpropagation by hand up to a GPT-style language model in code. Slow and rewarding: the best way to make the maths feel concrete if you are willing to type along.

  karpathy.aiCoursesIntermediate

• Generative AI for Beginners from Microsoft

  A free, open-source 21-lesson course. Lessons are either "Learn" (concepts) or "Build" (code in Python and TypeScript where possible). Pick the lessons you need; they do not have to be taken in order.

  github.comCoursesBeginner

Prompting 5

• Prompt Engineering Guide by DAIR.AI

  A free, community-maintained reference covering prompting techniques, with examples and links to the papers behind them. Use it as a lookup when you want to name and try a technique such as few-shot, chain-of-thought or ReAct.

  promptingguide.aiPromptingBeginner

• Anthropic prompt engineering documentation

  Vendor docs, but the habits transfer to other models: be explicit, show examples, structure your inputs clearly, and iterate against a small set of test cases. Free to read; running the examples needs API access.

  platform.claude.comPromptingBeginner

• OpenAI prompt engineering guide

  OpenAI's official guidance on writing prompts and structuring messages. Read it alongside another vendor's guide: where the two agree, you can trust the advice to travel across models. Free to read; API use is billed.

  developers.openai.comPromptingBeginner

• Simon Willison's prompt injection series

  A running series of posts on prompt injection, the attack where untrusted text steers a model. Free and practical; read it to understand why filtering alone is not a defence and why architecture matters.

  simonwillison.netPromptingIntermediate

• Chain-of-thought prompting: show your reasoning steps in the examples

  The chain-of-thought paper (Wei et al.) showed that including worked, step-by-step reasoning in few-shot examples lets large models solve multi-step problems they otherwise miss. The practical lesson: when accuracy matters, give the model room and a pattern for intermediate steps. Template you can adapt: Two cautions. Check the final answer, not the story: fluent reasoning can still be wrong. And many current models reason by default, so test whether the explicit scaffold still improves results on your task before paying for the extra tokens.

  arxiv.orgPromptingBeginner

RAG 5

• LlamaIndex documentation for building RAG over your data

  Docs for an open-source framework that covers loading data, indexing, retrieval and query engines. A practical way to get a first retrieval pipeline running so you can see where quality really gets lost.

  developers.llamaindex.aiRAGIntermediate

• Sentence Transformers: embeddings, retrieval and reranking

  The standard open-source Python library for computing text embeddings and running rerankers, with thousands of pretrained models on the Hugging Face Hub. Runs locally and for free; a good default for semantic search prototypes.

  sbert.netRAGBeginner

• Contextual retrieval: give every chunk a sentence of context before embedding

  Chunking loses context: a chunk saying "revenue grew 3% over the previous quarter" no longer says which company or period. Contextual Retrieval fixes this by having a model write a short, chunk-specific note placing the chunk in its document, then prepending it before indexing. A prompt in that spirit: Index the augmented text for both embeddings and a BM25 keyword index, since exact identifiers are where embeddings slip. In Anthropic's own tests, this combination cut failed top-20 retrievals by 49 percent, and adding a reranker took it to 67 percent. Those are their datasets, so measure on yours. Cost note: it adds one model call per chunk at indexing time.

  anthropic.comRAGIntermediate

• Pick an embedding model with MTEB, then verify on your own queries

  The MTEB leaderboard on Hugging Face ranks embedding models across many tasks, which makes it a good place to build a shortlist. It is a bad place to make the final call, because your documents and queries are not the benchmark's. A 30-minute procedure: Keep the same chunking across runs so you are testing the model, not the splitter. Also remember that switching models later means re-embedding everything, so record the model name and version next to the vectors.

  huggingface.coRAGIntermediate

• Vector search in Postgres: your first pgvector query and index

  If you already run Postgres, pgvector lets you keep embeddings next to your relational data. The README's basics fit in a few lines: Three details trip people up. The vector size (3 here) must equal your embedding model's output size. The operator in your query (<->, <=>) should match the operator class of the index, or the index will not be used. And <=> returns distance, so similarity is 1 - distance. IVFFlat is the other index type if you need it.

  github.comRAGBeginner

AI Coding 5

• Aider: AI pair programming in your terminal

  Free, open-source terminal tool that edits code in your repository and works with git. It connects to most hosted models and to local ones, so you pay only your model provider, or nothing if you run locally.

  aider.chatAI CodingIntermediate

• Continue: open-source coding agent for VS Code, JetBrains and the CLI

  Apache-2.0 coding assistant available as a VS Code extension, JetBrains plugin and CLI. Pick it when you want an editor-integrated assistant that you can point at the model of your choice, hosted or local.

  github.comAI CodingBeginner

• Give your coding agent a way to check its own work

  The Claude Code best-practices page makes a point that applies to any coding agent: give it a check to run. If the agent can run tests, a linter or a build and read the result, it can correct itself instead of handing you plausible-looking code. (The tool itself needs a paid plan or API access; the habits are free and transfer.) Practical steps: The docs make that last distinction explicit: instructions are guidance the model can weigh, while hooks and permissions are deterministic. Choose accordingly.

  code.claude.comAI CodingIntermediate

• AGENTS.md: one instructions file for many coding agents

  AGENTS.md is a plain Markdown file at the repository root, described by its site as a README for agents. The same page lists many supporting tools, including Codex, Cursor, Aider, Gemini CLI, Zed, Windsurf and GitHub Copilot's coding agent, so one file can serve several of them. Nested files in subdirectories can tailor guidance for sub-projects. Recommended contents from the site are project overview, build and test commands, code style, testing expectations, security notes and commit or PR rules. A compact version: Keep it factual and short, and update it when commands change. A stale instruction file is worse than none, because the agent will follow it confidently.

  agents.mdAI CodingBeginner

• Copilot custom instructions: repository-wide and path-specific

  GitHub's docs describe two levels of repository instructions for Copilot. Repository-wide guidance lives in .github/copilot-instructions.md. Path-specific guidance goes in files named NAME.instructions.md under .github/instructions, each with frontmatter whose applyTo takes glob patterns. The docs also say AGENTS.md is supported, with the nearest file in the tree taking precedence, and that a single CLAUDE.md or GEMINI.md at the root can be used instead. So if your team mixes assistants, you can often share one set of rules rather than maintain three. Scope rules by path to keep each instruction short and relevant, and review what the assistant actually does with them in a real pull request.

  docs.github.comAI CodingIntermediate

Agent Skills 4

• Anthropic's open skills repository

  A repository of example Agent Skills: folders of instructions, scripts and resources that an agent loads when relevant. Study a few before writing your own; the structure and tone of the descriptions are the useful lesson.

  github.comAgent SkillsBeginner

• Agent Skills: the open format

  Documentation for the open Agent Skills format, built around a SKILL.md file with a name and description plus optional scripts and references. Read this to see what stays portable between tools that support skills.

  agentskills.ioAgent SkillsBeginner

• Write your first SKILL.md: a description that triggers, a body that guides

  A skill is a folder with a SKILL.md file. Its frontmatter needs a name (lowercase letters, numbers, hyphens; up to 64 characters) and a description (non-empty, up to 1,024 characters). The description is what the agent matches your request against, so it must say what the skill does and when to use it. The docs describe loading in stages: only name and description are always in context, the body loads when triggered, and extra files or scripts load only when referenced. So keep the body focused and push detail into side files. Only install skills from sources you trust, since they can include scripts.

  platform.claude.comAgent SkillsBeginner

• Skill hygiene from the open spec: size, structure, validation

  The Agent Skills specification is the portable part: a directory with SKILL.md, plus optional scripts/, references/ and assets/. Notably, the name must match the parent directory name, must not start or end with a hyphen, and must not contain consecutive hyphens. Guidance from the spec worth adopting: Optional fields include license, compatibility (for environment needs such as required tools), metadata and an experimental allowed-tools. Tool support for the optional fields varies, so test in the agent you actually use. A good habit is to write the description last, once you know what the skill really covers.

  agentskills.ioAgent SkillsIntermediate

LLMs 3

• Intro to Large Language Models: Karpathy's one-hour talk

  A single free talk that explains an LLM as an artifact (a big parameter file plus a small program that runs it), how training and fine-tuning produce one, and where the security problems come from. Start here if you use models daily but have never looked inside.

  youtube.comLLMsBeginner

• The Illustrated Transformer

  Jay Alammar's diagram-driven walkthrough of the architecture from the original transformer paper: self-attention, multi-head attention, positional encoding and the encoder and decoder stacks. Read it before the paper, then keep it open next to the paper.

  jalammar.github.ioLLMsIntermediate

• OWASP Top 10 for LLM Applications

  The community-maintained list of the main risks in LLM apps, led by prompt injection and including excessive agency, system prompt leakage and unbounded consumption. Use it as a review checklist before you ship.

  genai.owasp.orgLLMsIntermediate

MLOps 3

• MLflow for tracing and evaluating AI applications

  Open-source platform that covers experiment tracking for classic models and tracing, evaluation and monitoring for LLM apps and agents. Choose it when you want one self-hostable tool across both kinds of work.

  mlflow.orgMLOpsIntermediate

• Langfuse: open-source LLM observability

  MIT-licensed, self-hostable platform for tracing LLM calls and agent runs. Use it to see what your application actually sent and received, which is the first step to debugging quality problems in production.

  langfuse.comMLOpsIntermediate

• Evals begin with assertions: Hamel Husain's level-one tests

  Teams stall on evals because they imagine a platform. Hamel Husain's widely read post describes three levels, and the first is plain assertions, like you would write in pytest, that run fast and cheap while you develop. He also notes you keep adding tests as you see new failures in real data. A starter in that spirit: Run it on every prompt change. Each production bug becomes a new case. Later levels (reading traces, model-graded checks, A/B tests) build on this habit,.

  hamel.devMLOpsBeginner

Tools 3

• Typed outputs you can trust: validated results with Pydantic AI

  Free-form text is a poor interface between a model and your code. Pydantic AI, from the Pydantic team, lets you declare the shape you want and get back a validated object, which turns "parse and hope" into a typed contract. Sketch (the model string is a placeholder, use whichever provider you have a key for): Why it helps: invalid shapes are caught at the boundary, your IDE knows the fields, and tests can assert on real types. Keep the schema small and the field names self-explanatory, since the model reads them too.

  github.comToolsIntermediate

• A first prompt eval in a YAML file with promptfoo

  Promptfoo is an open-source tool that treats prompts like testable code: you declare prompts, providers and test cases, run them, and compare. Its docs describe the cycle as defining test cases, running them, then iterating. A minimal config shape (provider ids vary, check the docs for yours): Run npx promptfoo@latest eval and then npx promptfoo@latest view to compare outputs side by side. Use cheap deterministic assertions first, and add the rubric-graded ones only for qualities you cannot check with a string match. Swapping providers lets you see the cost-quality trade-off on your own cases.

  promptfoo.devToolsBeginner

• Inspect AI: write an eval as a task, a solver and a scorer

  Inspect is an open-source framework for LLM evaluations from the UK AI Security Institute. Its structure is worth learning even if you end up using something else: an eval is a Task with a dataset, a solver (how the model is driven) and a scorer (how answers are graded). The docs' own example has this shape: Run it with inspect eval my_eval.py --model provider/model. The decorator registers the function so the CLI can find it by name. The project also ships a large collection of pre-built evaluations, which is a good place to see how experienced teams structure datasets and scorers.

  inspect.aisi.org.ukToolsAdvanced

More from the Vault