Optimizing your AI coding setup: instruction files, skills, and memory

Claude Fable 5 came out this week, and the obvious question is whether a smarter model makes your coding agent better. It does. But here is the thing I keep relearning while shipping iOS apps with an agent in the loop every day: the gap between a default setup and a tuned one is bigger than the gap between models. A frontier model dropped into a project with no instructions, no skills, and no memory still guesses your conventions, repeats last month's mistakes, and cannot check its own work. This post is the detailed version of how I tune the four layers that sit around the model: the instructions file, skills, memory, and verification. Then where the new model actually fits.

Layer 1: the instructions file

Every serious coding agent reads a plain markdown file from your project root before doing anything, named something like CLAUDE.md or AGENTS.md depending on the tool. This file is your highest-leverage real estate, and most people use it wrong in one of two ways: they leave it empty, or they dump everything they know into it.

It loads into the agent's context every single session, so every line costs attention. The rule I follow: only things that are always true and always needed, stated short.

A real example from my own projects. My website runs a framework version newer than what the model was trained on, so a fresh agent would confidently write last year's patterns into it. The entire fix is a three-line instructions file. It says, roughly: this version has breaking changes, your training data is outdated, read the docs shipped inside node_modules before writing any code. That is it. Three lines ended a whole class of wrong code, because the agent now checks current docs instead of trusting stale knowledge.

Notice the shape of that fix: the file does not contain the documentation. It points to where the truth lives. Pointing beats pasting, because pasted copies go stale and bloat every session.

Other lines that earn their place in my instruction files: which command builds the project, which directories never to touch, and the one or two project quirks that would otherwise burn ten minutes every session, like the fact that in my iOS projects the editor's live error checking reports ghost errors, and the terminal build is the only truth.

Layer 2: skills, the instructions you load on demand

The instructions file has a problem: it is always loaded, so it has to stay small. Skills solve the other half. A skill is a packaged set of instructions for one specific procedure, and the agent only pulls it in when that task comes up. Think of the instructions file as what the agent always knows, and skills as what it knows how to look up.

The test for when something should become a skill is simple: if you have explained the same procedure to your agent twice, package it. Mine include a skill that saves everything a session taught us into my knowledge base at the end of a work session, so the lessons survive (more on that in the next layer).

This idea just went mainstream in a big way. At WWDC, Apple shipped seven official agent skills with Xcode 27, written by Apple, covering things like modern SwiftUI practice and migrating old test code, and you can export them for use in other tools, including terminal agents (I covered the details in my WWDC post). The vendor writing skills for everyone's agents is the clearest sign yet that this is how agent knowledge will be distributed. Worth adopting the habit now: your own repeated procedures deserve the same packaging.

Layer 3: memory that survives the session

This is the layer with the highest payoff and the one most setups are missing entirely. Everything above is static: you write it, it sits there. But the most valuable knowledge shows up while you work: the bug that turned out to be a config issue, the API that does not behave like its docs, the approach you tried that failed. Close the session and all of it evaporates.

My fix is a searchable knowledge base the agent can read and write through MCP, the open protocol for connecting tools to AI assistants. Before planning anything non-trivial, the agent searches it. At the end of a session, it saves what we learned. The full setup is its own post, so here I will just show why it matters with two real notes from mine:

• One note says the editor diagnostics in my iOS projects show false errors and the command line build is the truth. Without it, every fresh agent chases ghost errors.
• Another documents that a specific ad behavior in one of my games is intentional, because review-style passes kept flagging it as a bug. The note ends the false alarm permanently.

Neither of those lives in any documentation on earth. They are the specific, hard-won truth of my projects, and the mistake-shaped notes turn out to be the most valuable ones. An agent with access to them starts every session as the senior developer on my codebase instead of a brilliant new hire on day one.

Layer 4: let the agent verify its own work

An agent that cannot check what it did needs you to babysit every change. So the last layer is making verification a command. In my iOS projects, building, running tests, and installing onto my actual iPhone are all terminal commands the agent runs itself. My loop on Slime Merge was: I describe the change, the agent edits, builds, installs to the phone, and tells me when it is ready to play-test. The only human steps left are the ones that genuinely need a human.

This is also where the industry is heading: the headline feature of Xcode 27's agent support is exactly this, agents that run tests, check previews, and drive a simulator to verify their own work. Whatever your stack, the question to ask is: can my agent find out on its own whether its change worked? Every yes removes a babysitting loop.

Where Fable 5 fits

So what does the new model change? Claude Fable 5 is Anthropic's strongest generally available model, the first of the Claude 5 family, a tier above the Opus models that were the previous ceiling. On the API it costs 10 dollars per million input tokens and 50 per million output, premium pricing that positions it as the model you reach for when judgment matters, not the one you burn on boilerplate.

That maps cleanly onto the layers above. The setup work, instructions, skills, memory, verification, is model-independent: it makes every model better, and it is what compounds over months. The model choice then decides the quality of judgment running on top of that setup: the planning, the tricky debugging, the architectural calls. My honest framing: a stronger model raises your ceiling, a tuned setup raises your floor, and the floor is where you live most of the day.

If you want to feel the difference yourself, there is a window for that: Fable 5 is included on paid Claude plans until June 22, after which using it costs extra usage credits. Try it on your hardest real problem, not a toy, and with your setup layers in place, because that is the only comparison that means anything.