Building Systems That Build My Systems

Most of my work is system building.

I spend my time figuring out how useful work can happen repeatedly: what starts it, what information it needs, where judgment belongs, and how to tell whether it succeeded. The visible result might be a product, a publishing process, or a way to deliver a service. Underneath it is a system.

That already puts me one level away from daily execution. Now I am working another level out: building systems that help build and improve those systems.

The practical expression is surprisingly simple. I can open a conversation on my phone, describe an outcome, and direct a worker on my computer to investigate or prepare it. The findings return to the conversation. I review the result and decide what happens next.

But the phone is only the interface. What interests me is the change in where my attention goes—and whether the capability we create stays mine.

Three places to apply your effort

Consider a business that produces a regular report.

You can prepare today's report yourself. You can build a process that prepares the report every day. Or you can build a way to inspect that process, find problems, and help improve it.

Each position has a different reach.

I think of the last position as working two dimensions out. It describes a shift in perspective, rather than an escape from responsibility.

The appeal is that a useful change can carry forward. Improving a piece of work helps that piece. Improving the process can help many later pieces. Improving how you develop the process can make subsequent changes easier.

There is no automatic compounding. A bad process can reproduce bad work very efficiently. You still have to understand what is happening at the end.

I was still carrying the handoffs

Before connecting these pieces, I was already using AI extensively. It could help think through a problem, write instructions, investigate a project, or prepare a change.

I was responsible for moving the work between those capabilities.

I would discuss an idea, carry the instructions to another tool, bring back the result, explain the context again, and ask what should happen next. If I stepped away from the computer, the next handoff often waited for me.

That coordination was easy to underestimate because each individual movement was small. Together, they made me the connection between otherwise capable tools.

The change was to give the conversation a defined route into the work. It could help turn my request into an assignment, pass the relevant context, and bring back something I could assess.

My requests started to change accordingly. More of them became: inspect the current state, reconcile what has already happened, prepare an approach, show the result, and continue from there.

I do not have a measured productivity multiplier to attach to this. What I can observe is that work can begin with fewer manual transfers, and I can return to a result instead of returning to the task of getting started.

Ownership is the condition

For me, this approach only works as intended when the systems being built are my own.

I want the code, schedules, records, and operating instructions in places I control. I want to be able to inspect them, back them up, move them, and have someone else maintain them.

That comes from being conservative with trust. I am willing to use an outside service when it is useful. I am careful about letting its continued availability become a condition of my livelihood.

An application might change its features, lose availability, restrict an account, or stop being the right choice. I want the work we have already built to survive that change.

The distinction matters because it is possible to become more productive while becoming less independent. If every new capability exists only inside an application I cannot operate without, my business may become more exposed as it grows.

I want useful work to accumulate as assets I can carry forward.

Building with AI and running on AI are separate decisions

An AI can help create a program without becoming a requirement every time that program runs.

If a routine reads records, calculates totals, and saves a report, those steps may be expressed as ordinary code. Once the routine works, I do not need a model to rediscover the procedure each morning.

This is why I use cron jobs for recurring work rather than an AI application's reminders. A cron job is a schedule that tells a computer to run something at a specified time. The schedule belongs to my operating setup, where I can inspect and change it.

For daily functions, I try ordinary code first. When the task needs AI, I look at local models and local compute before adding a dependency on a cloud model.

Those choices are distinct. A worker on my computer can still rely on a model running elsewhere. Putting the worker on my machine does not, by itself, make the task independent.

Sometimes a cloud model is worth the dependency because it provides a capability I need. The point is to make that a deliberate choice for a particular function.

I ask: what has to be available tomorrow for this to keep working?

That question is more useful than asking how impressive the system looked in the conversation that built it.

Separate improvement from fulfillment

The service a customer already receives should have a clear way to operate while I am improving the machinery behind it.

I think about two kinds of activity. One is the established work: the schedules, procedures, and code that deliver the service. The other is development: investigating problems, proposing changes, and building new capability.

The conversational AI is especially useful in that second activity. Losing access to it may slow development or remove a convenient way to give instructions. My goal is to keep that interruption from automatically stopping existing fulfillment.

That separation has to be designed. A routine that calls an outside model every time it runs still depends on that model. A local scheduler cannot remove the dependency.

For each essential function, I want to know what can continue, what can wait, and what someone could take over manually. The answer will differ by service.

Owning the code gives me options. It does not guarantee uptime: computers fail, backups need to work, and software needs maintenance. The value is retaining the ability to recover and adapt without needing permission from the application that helped build it.

What the conversation is responsible for

I use the conversation to help coordinate the development work.

It needs to understand the desired outcome, retrieve the relevant context, form a bounded assignment, and return the result. A worker with appropriate access can inspect or change the actual project.

The conversation also needs to distinguish history from current reality. An earlier message can establish what someone intended or reported. The project itself can show what exists now. When those disagree, the discrepancy needs investigation.

This becomes especially useful after an interruption. Before continuing, the system should establish what completed, what changed elsewhere, and what remains. Resuming an old instruction without checking can duplicate work or undo a newer decision.

The ability to recover context is valuable because it makes returning to a project less expensive. It also lets me switch between directing work remotely and working at the computer without treating each transition as a new beginning.

Give enough direction to make delegation possible

The quality of an assignment depends on a few clear decisions.

Explain the outcome, the relevant context, what the worker may do now, and what should come back for review. Then describe the evidence you want at the end.

For example:

Review this recurring process and identify where it breaks down. Compare its current behavior with the intended outcome. Prepare a recommendation before changing it. Preserve the parts that already work, and show me how you will check the result.

That is enough to begin an investigation without pretending to know the answer.

For a small, understood change, a separate planning stage may be unnecessary. For a consequential or ambiguous change, investigation gives me something concrete to approve.

The amount of review should follow the decision being made. Requiring permission for every minor action makes coordination cumbersome. Leaving the boundaries vague makes it difficult to know what has actually been authorized.

Replace reassurance with evidence

A completion message is useful only if we agree on what completion means.

A draft can be complete without being published. A change can be prepared without being released. A release can succeed while the original problem remains.

I want the result tied to the outcome I asked for: show the finished work, explain what was checked, and identify anything unresolved.

For a process, that may mean demonstrating a successful run. For a customer-facing change, it means inspecting the experience someone will actually have. For a recurring function, it includes checking the schedule and the dependencies it will need later.

Status needs the same discipline. A task described as running should be distinguishable from one that is disconnected, blocked, or waiting for input. Otherwise, I am forced to keep checking whether the system's description corresponds to reality.

Trust grows when I can inspect the work and understand its limits.

A different rhythm for the workday

The biggest routine change is what can happen between moments of attention.

Previously, identifying a problem on my phone could become a note to deal with later. With a working connection, that moment can become a clear assignment. When I return, there may be findings to review.

The work still takes time. It simply does not require my continuous participation throughout that time.

I find it useful to separate my attention from the task's elapsed time. A task can take the same amount of time to finish while requiring fewer minutes of explanation, transfer, and supervision from me.

That creates room for a different rhythm: get oriented, choose a few priorities, assign bounded work, and return when there is a meaningful result or decision.

The temptation is to start more work because starting has become easier. But review capacity is finite. If everything arrives at once, my ability to make thoughtful decisions becomes the new constraint.

I want fewer unresolved handoffs and more useful completions. That requires limiting active work as well as making execution easier.

Moving outward makes contact with reality more valuable

Working at a higher level can create distance from the people the system serves.

A process might complete every step and still produce something unhelpful. A report might arrive on time and fail to answer the question. A product change might work as designed and remain confusing to use.

The further I move from daily execution, the more deliberately I need to sample its results.

Read the output. Use the experience. Follow the customer journey. Ask whether the person at the end is better served.

Those observations should influence the next improvement. Otherwise, I would be making it easier to develop machinery while becoming less informed about what the machinery produces.

My judgment remains responsible for the purpose, the priorities, and the quality standard. The system should bring the evidence closer to those decisions.

How to start with one piece of work

You do not need to recreate an entire business to try this approach. Choose one recurring function whose result you can recognize and whose coordination currently takes too much effort.

1. Map the handoffs

Write down where the request starts, where the necessary information lives, how the work gets done, and how someone checks it.

Include the small movements: finding an earlier decision, carrying instructions, and discovering whether the task finished. These are often where the avoidable friction lives.

2. Define what you will own

Identify the code, records, schedule, and instructions that should remain under your control. Decide how they will be backed up and how someone could run or maintain the function without the conversational interface.

If you need technical help, these are plain-English requirements you can give the person helping you.

3. Choose the simplest way to run it

Use ordinary code for predictable steps. Consider a local model where judgment or language generation is needed and its quality is sufficient. Introduce an outside service when its contribution justifies the dependency.

The aim is a function you understand well enough to rely on.

4. Test the result and the interruption

Check that the routine produces the intended outcome. Then establish which parts can continue when the AI application is unavailable.

A low-impact trial can reveal whether the independence you intended exists in practice. Also check how a stopped or partially completed task can be resumed without duplicating its effects.

5. Keep the successful pattern

Preserve the instructions, review criteria, and completion record. The next run should benefit from what you learned.

Expand only when the first function is dependable enough that you are recovering attention rather than spending more of it supervising the arrangement.

Measure what became easier to finish

Task counts and generated words are easy to track. They say little about whether the work helped.

I would look at how much attention a completed task required, how often context had to be repeated, how much correction followed, and whether the result was used.

For a system, I would also ask whether the improvement carried into later runs. A change that saves a small amount of effort repeatedly may be more valuable than a large batch of output that never becomes part of the business.

These questions keep the comparison honest. The useful unit is work that reaches an agreed outcome and remains useful afterward.

What I want to keep

I want AI to help me build capability that lasts beyond a particular application.

That means my own code and records, schedules that run independently, and a clear understanding of where outside services remain necessary. It also means a way to direct improvements without carrying every instruction and result between tools myself.

The phone gives me a convenient place to participate. The systems underneath give that participation somewhere durable to land.

My work was already about building repeatable ways for useful things to happen. Now I am building a repeatable way to develop those systems too.

The test is whether each improvement leaves the business more capable, the work easier to continue, and me with enough freedom to step away.