AI Coding Is Making My Context Window Bigger

Lately, I have been thinking about factory machinery and combine harvesters while working with coding agents.

It is a loose comparison. I keep imagining someone whose job used to depend on doing something by hand, then finding themselves responsible for the machine that does it. From the outside, it might look as though the effort has disappeared. From where I sit, the effort is moving somewhere else.

The agents write more and more of my code. My days are still full, and so is my head.

I used to hold the context of a project in mind while writing its code. Now I spend more time describing work, organizing agents, following their progress, and checking the result. Increasingly, the context I need to hold is the whole product, including changes that cross several projects and repositories.

After the initial amazement

There was a period when the most striking thing about AI coding was simply watching it happen. The machine was doing something I had spent years learning to do. It was easy to get stuck on that fact, whether with excitement or with the uncomfortable feeling that it had just taken my job.

I think I am getting past that stage.

At first, I delegated the kinds of local changes I would previously have made myself. Fix this function. Adjust this page. Add this behavior. I kept roughly the same scope of attention and handed over the implementation.

As I gained confidence, I started asking for larger pieces of work. A whole feature, then a feature involving several parts of the same product, sometimes spread across repositories. The amount of code I personally typed went down while the amount of work I needed to understand grew.

I had already written about how agents were pushing me to make my thinking explicit. This feels like the next part of that experience. Being clearer about a task lets me delegate more of it. Delegating more means I have more interactions and consequences to keep track of.

My own context window

We talk a lot about the context window of a model. I am becoming more aware of my own.

Before implementation, I need to reason about what the product should do and how the work fits into what already exists. While writing prompts, I need to give the agents enough of that picture to make useful decisions. During execution, I need to keep track of what is happening in parallel. At the end, I need to check whether the pieces make sense together.

That picture has to survive the entire process. A good initial prompt helps, but I still need to recognize when the work has drifted from the original need, or when two individually reasonable decisions conflict.

I can become more comfortable with how an agent implements a feature and still have plenty to worry about when that feature meets another one. Especially if both were developed at the same time, with different agents holding different slices of the context.

That is where much of my attention is going now. I am spending less of it on the exact shape of every line and more on the coherence of the result across the product.

It is mentally demanding. Following several workflows at once means remembering what each one is trying to achieve, what it depends on, and what evidence I am still waiting for before I can call it finished.

Someone still has to understand why the machine stopped

External dependencies are part of that context too.

One morning, GitHub problems got in the way of the work. An agent getting stuck was only the visible symptom. I still had to understand whether the cause was a flaw in our approach, something wrong with the local machine, or a service we depended on.

Those possibilities require different responses. If I misunderstand the cause, I can send an agent back to change perfectly reasonable code because the infrastructure around it is having a bad day.

This is another reason the machinery comparison keeps coming back to me. Operating the machinery includes knowing enough about the process to understand an interruption. The fact that the machine performs the work does not make every failure its own problem to solve.

With coding agents, I find myself watching the work at several levels: implementation, integration, merges, deployment, and the services that make all of that possible. Even when I delegate parts of the diagnosis, I need enough understanding to judge whether the explanation fits what is happening.

Is this becoming project management?

Some of it feels close. I think about dependencies, priorities, ordering, and the relationship between pieces of work. I coordinate things that can happen in parallel and things that have to wait.

I am still unsure how useful that label is for what I am doing.

There is a lot of technical judgment involved. I need to understand how the proposed work can actually be delivered, what a merge will bring together, and whether a deployment will leave the product behaving as expected. I may spend less time inspecting certain implementation details, but I still need enough technical knowledge to question what the agents are doing.

The difficult part, for me, is increasingly the interaction between changes. Trust in an agent’s ability to write a piece of code does not automatically tell me that several pieces developed in parallel will work well together.

For now, I want to remain close enough to the technical work to see those collisions coming and to investigate them when I miss them.

Checking against the human need

The machinery analogy has a limit. With AI, I am delegating some reasoning as well as execution. That makes it harder to draw a clean boundary around what I can safely leave to the machine.

Still, the work I am asking for starts with a human need. Someone wants the software to do something. However much of the process I delegate, I need a way to come back to that need and check whether it has been met.

I suspect that responsibility will remain even as the tools become more reliable. This is not a prediction that a person must manually inspect every output forever. It is how I currently understand my role: I am accountable for accepting the result, including deciding which checks are enough to accept it.

The initial amazement has faded enough that I can see the work more clearly. I am getting used to letting the agents handle larger stretches of implementation. My attention is following the feature across repositories, through the merge and deployment, and back to the behavior the person using it actually needed.

That is what I need to verify before I consider the work done.