I run a pipeline in which a coding agent picks up a bug report and delivers a reviewed pull request without a human typing any code. When I describe it to other engineers, the questions are always about the model. Which one, is it clever enough, does it hallucinate. In my experience the model is rarely the constraint. The constraint is context. An agent starts every session knowing nothing about your codebase beyond what you hand it, and most teams have never written that down. A new hire absorbs the unwritten rules over months of review comments and corridor conversations. An agent only gets what exists in a file.
Start with the rules file
The place to start is the AGENTS.md that is loaded into every session. My first version was a wish list. Write clean code, add tests, follow the style guide. It achieved nothing, because nothing in it was specific enough to change a decision. The version that works was built one failure at a time. When a session goes wrong, I work out what single piece of context would have prevented it, reduce that to one enforceable sentence, and add it to the file. Keep dataframes in one library end to end. Never suppress a type error to make CI pass. Before claiming a task is done, state what was verified and what was not. Every rule in the file exists because a session went wrong without it.
Move procedures into skills
A single rules file cannot hold everything, and stuffing it bloats every session with context that has nothing to do with the task at hand. So the rules stay small, and everything procedural moves into skills. A skill is a self-contained, step-by-step instruction file for one kind of task, loaded only when that task comes up. Bootstrapping a new dashboard app is a skill. Adding a pipeline is a skill. Fixing type errors properly is a skill. The trigger for writing one is the same as for extracting a function. The second time I catch myself explaining the same procedure to an agent, it becomes a file.
Give agents tools, not descriptions
The biggest jump in capability came from MCP servers, which give agents tools rather than descriptions. Our process-expert chatbot answers from live plant data because it can call tools that retrieve signals and run backend calculations. Nothing about that data needs to be explained to it in prose. The same holds for development agents. A tool that runs the tests, queries the database or reports the type errors is worth pages of instructions about what the tests probably say, because prose in a prompt goes stale and a tool call is checked against reality every time it runs.
None of this depends on the next model release. The benchmark I hold the setup to is whether an agent can turn a real bug report into a pull request I would accept from a junior engineer. Increasingly it can, and every rule, skill and tool that got it there came from a session that went wrong.