When coding becomes agent management

Agent management is not coding.

That sounds obvious, but it is easy to forget when the agent is good. You give it a task, it edits files, writes tests, refactors a component, opens a diff, and suddenly a chunk of work has moved forward. The first time this happens properly, it feels like magic.

Then the magic becomes the workflow.

You prompt, wait, review, correct, reprompt, test, check the diff, ask for another pass, clean something up, and try to remember what the original task was supposed to be. The agent is doing more of the typing, but you are doing more supervision. The day starts to feel less like building and more like managing a stream of partial outputs.

That is the strange part of agentic coding. It can make you faster and more tired at the same time.

A lot of developers seem to be circling the same discomfort from different angles. Web Dev Cody’s video, AI killed the joy of coding, Lars Faye’s essay, Agentic Coding is a Trap, Linear’s Issue tracking is dead, and commentary from people like Mo Bitar and ThePrimeagen are all useful references for anyone thinking about how AI is changing software work.

The part we keep coming back to is the shape of the working day. What happens when coding becomes less about direct implementation and more about prompting, reviewing, sequencing, and supervising agents?

For us, the concern is not only joy. It is contact with the work. If the agent does more implementation, what happens to the instincts you used to build by doing the work yourself? What happens to debugging fluency, codebase memory, taste, and the quiet confidence that comes from being close to the material?

We use these tools. We think they are useful. But useful is not the same as harmless, and faster output does not automatically create a better relationship to the work.

The problem is not that agents write code

Agents writing code is not the problem.

The problem is when agent work becomes continuous and unbounded. The agent can always do another pass, open another branch, try another implementation, generate another test, or refactor another part of the codebase. That sounds productive, but without a rhythm around it, the work starts to sprawl.

You are no longer just asking whether the code works. You are asking whether the work was worth doing, whether the task was framed well, whether the agent understood the constraints, whether the diff belongs in this week, whether the output needs review now, and whether the follow-up work should be scheduled or ignored.

That is not coding in the old sense. It is agent management.

Agent management has a different texture. It is less about entering a flow state and more about keeping multiple loops from becoming tangled: the prompt loop, the review loop, the testing loop, the planning loop, and the follow-up loop.

If those loops all happen at once, the day becomes mush.

This is the part that can feel draining. Not the existence of agents, and not the fact that they can help. The draining part is when the agent becomes an always-on source of new work to inspect, correct, absorb, and reconcile.

Prompting is not the whole workflow

It is tempting to treat the prompt as the main interface with an agent.

Write a better prompt. Add more detail. Tell it the constraints. Ask it to explain the change. Ask it to write tests. Ask it to be careful.

All of that helps, but it is not enough.

The prompt is only one part of the context. The agent also needs to understand where the work sits: what project it belongs to, what kind of time it should occupy, what should not be touched, what kind of review is expected, and where the output should return.

A small bug fix, an exploratory refactor, a production-facing change, a prototype, a design pass, and a cleanup task should not all be treated the same way. They need different levels of context, different levels of supervision, and different review rhythms.

The danger is that every task starts to look prompt-shaped. If the only question is “what should I ask the agent to do?” then everything becomes a candidate for immediate generation. That is how agent work starts to leak across the whole day.

A better question is: where does this work belong?

Some work belongs in your own maker time. Some work belongs in an agent execution block. Some work belongs in review. Some work should stay in the backlog. Some work should not be done at all.

Without that structure, agentic coding becomes another surface for producing work that someone has to reconcile later.

The week gives agents a boundary

Backlogs are too large to be useful as an operating context.

A backlog can contain hundreds of things: bugs, ideas, cleanup tasks, product improvements, old experiments, half-decisions, and tasks that mattered three months ago. An agent can technically work on any of them, but that does not mean it should.

The week creates a smaller boundary.

It asks: what matters now? What should move forward in this cycle? What is realistic? What needs review? What should not be touched yet?

That boundary is useful for humans, and it is useful for agents. It separates “this exists somewhere” from “this belongs in the current rhythm of work.”

Without that boundary, agents make it easier to do the wrong work faster.

This is where we think issue tracking, task management, and agent workflows start to blur. A task is no longer just a record of something a human might pick up later. It can become an input to an agent now. That means the task needs to carry more context, not less.

The agent does not just need a ticket. It needs a place in the week.

Agent work needs routine-based time

This is the first part of our answer.

Agent input and output should be linked to routine-based time. If you ask an agent to do something, that work should belong somewhere in the week. It should have a project, a routine, a review point, and a place for the output to return.

Otherwise agent work becomes another stream: prompts in one place, branches in another, review notes somewhere else, and follow-up tasks scattered across the system.

A task for an agent should not just float in a backlog or sit inside a prompt history. It should belong to a routine: an agent execution block, a review block, a cleanup block, or a planning block.

That does not mean making the workflow heavier. It means giving the work a shape.

For example, an agent execution block might be used for a contained implementation pass. The input is the task, the relevant context, and the boundary of what should not be touched. The output is not “done work.” The output is something to review.

A review block is different. That is where you inspect the diff, test the behaviour, decide whether the implementation belongs, and turn anything unresolved into follow-up tasks.

A cleanup block is different again. That might be where agent output gets tidied, merged, documented, or broken apart.

The point is that agent work should not appear everywhere at once. If it has no place in time, it becomes ambient. Ambient agent work is what turns the day into a loose stream of prompts, diffs, and half-decisions.

Human and agent blocks should be separate

This is the second part.

Your maker time is not the same as the agent’s execution time. Your review time is not the same as the agent’s generation time. If those collapse into one continuous flow, you can spend the whole day watching output, checking diffs, and reprompting without ever entering the kind of focused work that still needs to be yours.

A two-hour maker block for you might be for thinking, designing, writing, or making careful architectural decisions. A two-hour agent block might be for generating an implementation pass or exploring a contained refactor. A review block might be where you inspect the output, decide what to keep, and turn the rest into follow-up work.

This separation matters because agentic work can easily blur the day.

You prompt the agent, wait, review, reprompt, test, check another file, ask for a fix, then start another task while waiting. Suddenly the whole day becomes a half-attentive review loop.

That is neither deep work nor good management. It is just being pulled around by output.

A better rhythm gives the agent a place to work without making your whole day revolve around its output. The agent can generate work in one routine. You can review that work in another. Your own maker time can stay protected.

The atrophy problem

There is another reason to separate the blocks: atrophy.

Writing code is not only production. It is also a way of thinking. It is how you notice awkward abstractions, understand the shape of the system, and discover that the original task was not quite right.

When you work through code yourself, you build a kind of contact with the material. You learn where the sharp edges are. You remember the weird decisions. You develop a feel for what looks wrong before you can fully explain why.

If every implementation step becomes agent output, you may get the code faster, but lose some of the friction that keeps your understanding sharp.

That does not mean manually writing everything. It means being intentional about which parts of the work you still stay close to.

Some blocks should be yours. Some blocks can belong to the agent. Some blocks should be for reviewing what the agent produced. The point is not to preserve manual coding as a ritual of suffering. The point is to avoid losing the judgment that makes agent supervision possible in the first place.

You cannot review well if you are too far away from the work.

Review is where agentic coding becomes useful

The review loop is where agentic coding either becomes useful or becomes noise.

An agent can produce a pull request, but the team still has to understand what changed and whether it should exist. The question is not only “does this code work?” It is also “does this solve the right problem?” “Did it introduce a new kind of complexity?” “Is this the right abstraction?” “Does this match the product direction?” “Should this be merged now, or is it a distraction?”

That review burden is real.

If agents increase output, they also increase the need for judgment. Without a review ritual, the system fills with unfinished threads: diffs to inspect, comments to respond to, branches to clean up, tasks that look done but are not really integrated.

This is why reviews should not be an afterthought. Review is where the work becomes part of the system. It is where output becomes learning, where mistakes become adjustments, and where the next plan becomes better than the last one.

The useful question is not only “how much code did the agent generate?” It is also: what did it help move forward, what required too much cleanup, which tasks were badly framed, where did review become the bottleneck, and what should change next week?

Without review, agentic coding can look productive while quietly creating more unresolved work.

The danger is becoming reactive

One strange effect of agentic coding is that it can make the week feel more reactive.

Because agents can do more, it becomes tempting to throw more at them. Fix this. Try this. Refactor that. Explore this idea. Write the first version. Clean up this component. Add tests. Open a PR.

Each instruction might be reasonable on its own, but together they can create a lot of motion without a clear centre.

This is similar to the problem we found with automatic scheduling. A scheduler can make it easier to place tasks into time, but that does not replace the planning ritual. In the same way, an agent can make it easier to turn instructions into output, but that does not replace deciding what matters.

We are not trying to automate judgment away. We are trying to keep the right decisions visible: what matters this week, what kind of work needs maker time, what needs manager time, what should be delegated to an agent, what needs human review, and what should not be started yet.

The better agents get, the more important that decision-making surface becomes.

Try separating the loops

Agent management becomes draining when everything collapses into one continuous loop: prompt, wait, review, reprompt, test, repeat.

A simple thing to try is separating the loops.

Block time for your own maker work. Block time for the agent to run. Block time to review what came back. Do not let all three happen at once by default.

The next time you use an agent, do not just ask what it can do. Ask where the work belongs in your week. Is this something for the agent to explore while you do something else? Is it something you need to sit with and guide closely? Is it something that should wait until you have a proper review block?

The point is not to make agentic coding slower. The point is to stop it from turning the whole day into a loose stream of prompts, diffs, and half-decisions.

Give the agent a place to work. Give yourself a place to think.