The weekly letter from Systems Thinking Lab: systems thinking insights for junior engineers, framed through the seven building blocks.
Picture handing a brand-new engineer the raw Stripe API documentation on their first morning and telling them to ship a working payment flow by five o'clock. Nobody does this. A new hire is supposed to get a kickoff meeting, an onboarding doc, and a senior engineer who walks them through how this particular codebase works before they touch a line of it.
Now picture what we do to an AI coding agent instead. Every session starts the same way that new hire's first morning would, except nobody runs the kickoff meeting. The agent opens a codebase it has never seen, guesses at your naming conventions, and writes code that works but matches nothing else in the repository. We call the result disappointing. The result was never the problem.
Here is what that gap actually costs, across three sessions on one codebase. Session one: you ask an agent to add a webhook handler to a service with a dozen existing endpoints. It writes reasonable code. It also invents its own naming convention for the file, skips the retry wrapper every other endpoint in the service already uses, and never notices the codebase already has a small library built for exactly this kind of validation. You catch it in the diff, fix the naming by hand, and explain the retry pattern in the chat. The session ends. The explanation ends with it.
Session two, new task, new context window, same codebase. The agent remembers none of it. It reinvents the naming convention, wrong in a different way this time. So instead of correcting it again and moving on, you write the two rules it keeps missing, naming and retries, into a short file the agent reads before it starts anything. You also ask it to add one line to a second file describing what it just learned about how this service handles errors. Two files. Ten minutes.
Session three, same codebase, a different feature. This time the agent reads both files before writing anything. It matches the naming on the first try. It does not ask how to handle retries. It asks whether the new endpoint belongs in this service at all, or whether the work is slow enough that it should go through the queue the rest of the service already uses for background jobs. That is not a better answer. That is a better question, the kind a new hire only asks after someone has actually shown them how the system fits together.
The two files were not a trick. They were the onboarding a new hire gets and an agent almost never does. The first file, a kickoff skill, is the version of that first-morning meeting: your naming rules, how errors get handled, how services are supposed to talk to each other, loaded before the agent writes a line. The second file, a wiki, is the version of a senior engineer explaining how this particular codebase works, except the agent writes it down itself, and it is there again waiting for the next session. Handing an agent the raw Stripe docs and expecting a shipped payment system by five o'clock was never going to produce clean work. The two files are what you would have given the new hire instead.
The tempting move, especially the first time an agent gets something wrong, is to write a better prompt. Spend twenty minutes getting the instructions exactly right, ship the task, feel clever about it. That cost gets paid again next session, because a prompt lives inside one conversation and disappears with it. The kickoff skill and the wiki live outside the conversation. Session one is expensive because the agent is learning your codebase from nothing, the same as any new hire's first week. Session three is fast because the learning from session one and two is sitting in a file, waiting to be read instead of relearned. That is the entire difference between a cost you pay once and one that compounds.
I am building this habit into a course I am finishing.
You do not get a better agent by writing a better prompt. You get one by building the memory it reads before it writes the next line.
P.S. If you want the framework behind how I think about designing systems in the first place, it starts here: https://systemthinkinglab.ai/learn/building-blocks/7-building-blocks/