# Build Something That Stays Source: https://www.bobzhu.tech/build-something-that-stays/ Markdown: https://www.bobzhu.tech/assets/agents/build-something-that-stays.md Tags: Essays, AI, Agents, Systems Summary: The useful difference is not who uses the most AI. It is whether each task leaves behind something that makes the next one cheaper, safer, or more consistent. Feature image: https://storage.ghost.io/c/ea/80/ea80b01b-c9d0-45fd-a95f-5fbcd52ed925/content/images/2026/07/ai-output-vs-capability-feature.png Feature image alt: Hand-drawn editorial illustration contrasting a machine that produces loose pages from tokens with a connected system of notes, scripts, checks, and documentation. Feature image caption: One way of using AI produces another output. The other leaves behind a better way of working. There are two broad ways people seem to use AI. The first is to treat it like a copilot that does the work for you. You ask for a report, a document, some research, a spreadsheet, a bit of code, or a plan. The AI produces something. You use it, then come back with another task. The second is to use AI to build a better way of doing the work. That might mean a script, a skill, a template, a test, a small app, a source-of-truth document, an approval step, or a whole workflow. The thing you build may use AI every time it runs. It may only use AI for the uncertain parts. It may not need AI at runtime at all. The difference is what remains after the task is finished. One approach gives you an output. The other gives you an output and a higher starting point for next time. For repeated work, the second approach is usually better. It is more consistent, easier to inspect, and less dependent on reconstructing the same context through another expensive conversation. ## The seductive loop The default AI loop is very easy to fall into: 1. describe a task 2. wait for the model 3. review the result 4. ask for corrections 5. take the output and leave This can be genuinely useful. If I need to do something once, there is no great virtue in turning it into a system. A one-off answer for a one-off problem is often the right trade. The problem starts when the work is repeated and important. You might use the same AI product every week and still find yourself explaining the same audience, the same preferred structure, the same exceptions, and the same source material. The model looks productive because it keeps producing. The process underneath it has barely improved. This is a kind of rented output. The value arrives, gets consumed, and the next unit of value needs another session with roughly the same setup cost. There is no shame in renting capability. I rent plenty of things I do not want to own. But it is useful to notice when a temporary arrangement has quietly become the permanent operating model for work you do all the time. ## What builders leave behind Builders use the first run as raw material for the second. They notice which instructions had to be repeated and save them somewhere visible. They turn a recurring document into a template. They move a mechanical transformation into code. They add a test for the mistake the model made. They put the source material in a predictable place. They write down who approves the result and what happens when the system is unsure. None of this needs to be grand. A versioned instruction file is better than a prompt you keep recovering from chat history. A small validation script is better than remembering to check five things by eye. A template with known sections is better than asking the model to rediscover the format every week. The builder's advantage is visible by the twentieth run. The first run may have taken more work because some of that effort went into the system around the output. But later runs start with the context, structure, and checks already in place. The task becomes cheaper to run and harder to get subtly wrong.
Hand-drawn workflow showing loose prompts becoming reusable instructions, a script, a template, checks, and a living manual, with a loop raising the next starting point.
The first run teaches you what the task needs. The useful question is whether that learning survives the session.
The durable artefacts are not necessarily software either. A research method, a review checklist, a decision log, a set of examples, or a well-maintained brief can all make later AI work more reliable. The aim is not to remove judgement. It is to stop spending judgement on the same avoidable setup and correction work every time. ## Claude Code and Cowork pull in different directions [Claude Code](https://www.anthropic.com/product/claude-code) and [Claude Cowork](https://support.claude.com/en/articles/13345190-get-started-with-claude-cowork) are a useful comparison because they increasingly share similar underlying capability while encouraging different ways of working. As of July 2026, Anthropic's current Claude Fable 5 model is available across Claude.ai, Claude Code, and Cowork. Cowork uses the same agentic architecture as Claude Code. It can run long tasks remotely, coordinate sub-agents, use plugins, organise work into projects, and run scheduled tasks. This makes the distinction more interesting, not less. Cowork's default promise is still close to a one-off hand-off: describe an outcome, step away, and come back to finished work. That is friendly and powerful. It is also easy to keep using it as a sequence of isolated jobs. Projects, plugins, scheduled tasks, skills, and instructions can make Cowork more reusable. They are just less intuitive as a complete builder surface. The pieces can be harder to find, track, version, and review as one coherent system. You can end up with useful instructions in one place, a scheduled task in another, a project memory somewhere else, and a plugin whose behaviour is not obvious from the output in front of you. Claude Code puts more of the system in the workspace. The instructions can be files. The workflow can be a script. Behaviour can be covered by tests. Changes can be reviewed in git. Documentation can sit beside the thing it describes. A future person, or a future agent, can inspect the parts together and understand why the workflow behaves as it does. [Anthropic originally described Claude Code as a low-level, flexible and scriptable power tool](https://www.anthropic.com/engineering/claude-code-best-practices). That is the important affordance. It does not force you to build a durable workflow, but it makes the accumulated system visible. Neither product determines the result. You can use Claude Code as an expensive autocomplete box and leave nothing useful behind. You can use Cowork carefully and build strong projects, plugins, instructions, and schedules. The surfaces simply make different behaviours feel natural. I think Claude Code is better for the builder pattern because inspectability is part of building. If I cannot easily see where the instructions live, what changed, what the checks are, and how the next run is meant to work, I have delegated a task but I have not really designed a system. ## The unhealthy kind of token dependence Tokens are not bad. A difficult task may deserve a long run with a frontier model. Saving a person's time can easily justify the inference cost. The unhealthy dependence appears when every unit of value requires another large, bespoke run from the beginning. Anthropic itself notes that Cowork uses more of a person's usage allocation than standard chat because complex, multi-step tasks consume more tokens. Again, that is not automatically a problem. The problem is paying the full reasoning and context cost every time because the process does not preserve what it learnt. If every weekly report needs the same 30 pages uploaded, the same organisational background explained, the same formatting corrections made, and the same factual checks requested, the AI is doing work but the workflow is not learning. A builder tries to move stable parts out of the conversation: - durable instructions instead of repeated explanation - retrieval from an approved source instead of pasting everything again - deterministic preprocessing instead of asking a model to clean the same input - schemas and templates instead of regenerating structure - tests and validation instead of hoping the next answer is consistent - smaller model calls for bounded steps instead of one frontier model doing everything This does not eliminate tokens. It makes them do the part of the work that actually needs a model. The model should handle ambiguity, synthesis, interpretation, and generation. It does not need to be the database, the scheduler, the file format, the calculator, the style guide, and the memory system at the same time. ## Documentation exposes the difference Documentation is where the one-off approach becomes obviously inconsistent. Ask a model to write the same documentation in three separate sessions and it will produce three plausible versions. The tone will drift. Terminology will shift. One version will describe the current system, another will quietly retain an old assumption, and a third will invent a neat explanation that the implementation does not quite support. The answer is not to stop using AI for documentation. AI is very good at turning structured material into readable prose. The answer is to give the documentation something stable to be consistent with. That might be a schema, an API specification, a set of source files, a terminology guide, a voice file, generated reference material, or tests that compare documented behaviour with the implementation. It also needs ownership. Someone or something has to know which source wins when two pieces of information disagree. This is one reason I like repo-based workflows. The documentation, the code, the instructions, and the checks can change together. A pull request can show that the behaviour changed and the explanation changed with it. In a looser AI workspace, the document may be beautifully written but detached from the process that created it. When it goes stale, the next AI session has no reliable way to know. Consistency comes from having something to be consistent with. ## Expertise still shapes the result There is also a temptation to describe this as technical people versus everyone else. I do not think that is right. A non-developer who understands a real business process can be much better at building an AI workflow than a developer who only understands the tools. The valuable knowledge is often knowing which inputs are trustworthy, which exceptions are real, what a good result looks like, and where a human decision belongs. [Anthropic's June 2026 study of roughly 400,000 Claude Code sessions](https://www.anthropic.com/research/claude-code-expertise) found that people typically made most of the planning decisions while Claude made most of the execution decisions. Greater domain expertise was associated with more work completed per instruction and a higher chance of success. That matches what I see. The model can do more when the person has a clearer mental model of the work. Builders are not necessarily the people who write the most code. They are the people who can turn what they know into a process another person or agent can follow, check, and improve. This is why the broader move of tools such as [OpenAI Codex into research, documents, spreadsheets, apps, plugins, and repeatable knowledge work](https://openai.com/index/codex-for-every-role-tool-workflow/) is important. Building workflows is no longer reserved for software engineers. More people can now turn their own domain knowledge into working tools. The difficult part is still deciding what should become durable. ## A simple test After the AI finishes, ask: **What remains that makes the next run cheaper, faster, safer, or more consistent?** If the answer is nothing, you produced an output. That may be exactly what you needed. But the next task will probably start from the same place. If the answer is an updated instruction, a reusable template, a script, a test, a better source, a documented exception, or a measurable check, you built some capability. The next run starts higher. For repeated work, I would take that one step further: 1. do the task with AI once 2. save the instructions that actually helped 3. separate the stable steps from the judgement-heavy ones 4. turn stable steps into templates or code 5. add a check for the most expensive mistake 6. keep the workflow and its documentation together 7. review failures and improve the system, not only the latest output This is the pattern behind the more useful levels of [AI proficiency](https://www.bobzhu.tech/the-ai-proficiency-ladder/). It is also why [MCP versus CLI is the wrong fight](https://www.bobzhu.tech/mcp-vs-cli-is-the-wrong-fight/): the interface matters less than whether the whole workflow is inspectable, repeatable, and suited to the job. The strongest AI model will keep changing. Fable 5 will eventually be replaced, just as every frontier model before it was replaced. A better model will make both one-off delegation and workflow building more capable. It will not decide which one you are doing. The better use of AI is not always to get it to finish the task for you. For the work you expect to do again, use the task to build a better way of doing it. Then the tokens leave something behind. ## Try this prompt Review this recurring task as a system rather than a one-off request. Separate the stable steps from the parts that need human or model judgement. Identify the instructions, templates, scripts, sources, tests, approval points, and documentation that would make the next run cheaper, safer, and more consistent. Start with the smallest durable artefact I should build after the first run. ## Related on this site - [The AI Proficiency Ladder](https://www.bobzhu.tech/the-ai-proficiency-ladder/) follows the move from prompting towards workflows, assistants, and systems. - [Five Levels of Running Claude Code More Autonomously](https://www.bobzhu.tech/five-levels-of-running-claude-code-more-autonomously/) explains why longer agent runs only become useful when they have context boundaries and evaluation loops. - [MCP vs CLI Is the Wrong Fight](https://www.bobzhu.tech/mcp-vs-cli-is-the-wrong-fight/) looks at choosing integration surfaces around the workflow rather than treating one interface as the answer. - [Organic Software](https://www.bobzhu.tech/organic-software/) explores software that can keep changing with the person and process around it. - [AI Does Not Automatically Give You Time Back](https://www.bobzhu.tech/ai-does-not-automatically-give-you-time-back/) explains why faster output does not automatically produce a calmer or better way of working. ### Sources - [Get started with Claude Cowork](https://support.claude.com/en/articles/13345190-get-started-with-claude-cowork) - [Claude Code](https://www.anthropic.com/product/claude-code) - [Claude Code: Best practices for agentic coding](https://www.anthropic.com/engineering/claude-code-best-practices) - [Agentic coding and persistent returns to expertise](https://www.anthropic.com/research/claude-code-expertise) - [Claude Fable 5 and Claude Mythos 5](https://www.anthropic.com/news/claude-fable-5-mythos-5) - [Codex for every role, tool, and workflow](https://openai.com/index/codex-for-every-role-tool-workflow/)