The new abstraction
Every step in computing has been an abstraction over the one before it. We learned to flip a light switch. Then transistors flipped billions of them a second, then machine code told the transistors what to do, then compiled languages wrote the machine code, then scripting languages took the ceremony out of compiling. Language models are the next layer. You describe what you want, and something underneath turns it into code.
That is not cheating, and it is not going away. Linus Torvalds uses these tools on the Linux kernel. Most teams already lean on them for nearly everything, and many developers have not hand-typed a line in a year. The problem is that we still talk about it like a guilty secret. People downplay how much of their work is AI-written, and the team loses the one thing it most needs: an honest comparison of what works.
So the first rule is openness. Talk about your prompts, your instruction files, your skills and your failures the way you would talk about your editor setup or your build pipeline. Configuring an agent well is genuinely hard. It is its own programming language, with its own bugs, and a team that shares its configurations will get better at it far faster than individuals working in private.
Your agent’s instructions are code
An agent reads instruction files before it does anything. In Claude Code that means
CLAUDE.md files, plus skills and memories, and it collects them by walking up the
directory tree. Open a session in one resource folder and it reads that folder’s file, then
the parent’s, then the repo root’s, then whatever sits above that in your home directory,
then a global one. Every layer gets loaded into context.
That has two consequences.
First, instructions accumulate. After a year of daily use, files get written in folders you forgot about, and many of them go stale. Nothing warns you. The agent just quietly follows advice that stopped being true months ago.
Second, overriding is not deleting. If a team file says X and your personal file says Y, the agent may defer to one of them, but both are still in its context, pulling in different directions. Conflicting instructions don’t cancel out; they add noise.
The fix is to treat the team’s base instructions like any other shared code: checked into the repo, reviewed, and owned. Everyone works from the same foundation. Personal layers sit on top for personal taste, not for contradicting the foundation. If your repo currently gitignores agent instruction files so everyone can do their own thing, consider what that costs: every developer’s agent has a different idea of how the codebase should be written.
A change like this rewrites people’s working environment, so it needs real consent. Give everyone notice to back up what they have, and don’t flip it on without agreement from the whole team.
Prune your memories
Agents now keep their own memory: notes they write down to carry from one session to the next. This is enormously useful, and it is also where the worst bugs hide, because nobody reviews it.
Here is how it goes wrong. You ask the agent to build a UI and take a screenshot to check it. It reaches for a screenshot tool that only captures the game engine, not the UI layer. The UI never shows up. The agent doesn’t know why, so it thrashes, and eventually invents a workaround that happens to work, something absurd like fetching a core framework object every frame. Then it writes that workaround down as a lesson learned. From then on, every session believes the workaround is how things are done. The real fix, take a picture of the desktop, never occurs to it again.
Real examples turn up when you look. A memory claiming a phantom second copy of a library exists with its own cache. A memory asserting some obscure engine limitation that never existed, which justified a daemon running twenty-four hours a day to work around it. Each one is small. Each one bends every future session a little.
So read your memories. Pick five or six a day and check them against reality. Delete what is wrong, fix what is stale. A small, curated, living set of memories is worth more than hundreds of unreviewed ones, because the curated set means you never have to tell the agent the same thing twice, and the unreviewed set means it keeps repeating a mistake you fixed long ago.
Encode the rules that matter
Some mistakes agents make over and over unless told not to. In a game server framework, the classic is fetching the shared framework object every time it is needed instead of once when the script loads. It looks harmless in review. At two hundred players it becomes thread hitches that tank the server on the busiest night of the month. One script fetching it every hundred milliseconds nearly took a server down.
Whoever on the team spends their time profiling the system knows a handful of rules like this. That knowledge belongs in the shared instructions, not in one person’s head. Then every agent follows the rules all the time, and when it does break one, it can explain why in terms the team understands.
Shared conventions, automated
When every commit message looks the same and every change goes through the same review flow, the history becomes readable and the tooling becomes simple. With agents this is close to free. A single command at the end of a task, something like “send it”, can stage the work, write the commit message from what was actually done, and open the pull request. Nobody on the team should still be writing commit messages by hand.
Skills are how you package that. A skill is a reusable, named procedure the agent follows on request. Share them the way you share libraries.
Spend most of the session learning
A rule worth adopting: roughly eighty percent of a session is research and discussion, and the last twenty percent is code. Talk the problem through before anything gets written. Have the agent ask you questions, ten if it needs them, but one at a time so you actually think about each answer. You can code faster with these tools, but you can learn much faster still, and learning is what makes the code right.
A method for building features
This is the sequence that works best, especially for long-running server code:
- The core idea. What is this thing fundamentally supposed to do?
- The lifecycle. When does it start? When does it stop? What happens when its resource restarts, when the server crashes, when a player disconnects halfway through? This is the most important step, and the one most often skipped.
- Edge cases. With the idea and lifecycle settled, have the agent list everything that could go wrong, and handle what you can now.
- Features. Only then build out the extras that occur to you along the way.
Done in that order, the rest is easy. Two standing stipulations belong on everything: performance at your real scale (“this runs on a two-hundred-player server, think about performance the whole time”) and cleanup (“everything this creates must be torn down”).
Build the first one carefully, then reuse it. Once one feature has worked through its safety cases, the next similar feature starts from that template instead of from zero, and each one gets easier.
Ask what already exists
Agents love to build their own tools. A mature codebase is full of problems that are already solved: registries, helpers, systems nobody remembers are there. Before building anything, ask the agent to check whether the capability already exists. It costs one question and prevents a second, slightly different copy of something you already maintain.
Keep your context clean
Think of a session’s context as a snowball. When everything is aligned, no mistakes yet and every step building on the last, it rolls forward clean and gets more useful as it grows. When you go back and forth, change your mind, hit errors and push through anyway, the snowball picks up dirt. The agent is now reasoning on top of discarded ideas and failed attempts.
So watch the quality of what is accumulating, not just the quantity. When a session is going well, protect it: branch it, fork it, write down what it figured out. When it has gone sideways, don’t fight it. End it with a handoff note that captures only what mattered, and start fresh from that note. A good handoff habit turns a dirty session into a clean one in under a minute.
Let the agents test
The highest-leverage setup is one where agents test the work themselves. A configuration can drive real clients against a test server, two at once if the feature involves interaction, so a developer never has to launch the game to check a change. Testing stops depending on who happens to be online, and a developer can be away from the machine while the work gets verified.
Ship from one branch
Long-lived feature branches create integration work every single day. An alternative: stage the next release’s content on the main branch behind a global flag that keeps it switched off, then flip the flag on release day. There is a learning curve, and things will slip through at first, but it removes the constant cost of keeping two branches in sync.
In short
Treat the agent’s instructions and memories as part of the codebase: shared, reviewed, pruned. Encode the hard-won rules so every agent follows them. Spend more time understanding than typing. Design from the lifecycle out. Check what exists before building. Keep sessions clean and hand off when they aren’t. Let the agents do the testing. And be honest with each other about how you work, because that is how the whole team gets better at the new abstraction instead of each person rediscovering it alone.