cloud / systems
Agentic coding changes more than how code gets written. It changes how I need to plan my time. I hand over a task, the agent starts working, and suddenly I have a decision of my own: do I stay here, or is this a useful window for something else?
If I knew it would need another twenty minutes, I could start a different topic. If it needed my input in thirty seconds, I would probably stay. The awkward part is not knowing which situation I am in.
Waiting is also work
A running agent creates an unusual kind of waiting. I am no longer typing every change myself, but I am not necessarily free either. I may need to approve something, clarify a requirement or review the result.
Watching the transcript feels like staying productive. Sometimes it just means reading updates without moving anything forward. Yet leaving can mean that the agent reaches a question and sits idle while I am occupied elsewhere.
That creates an attention problem: I can end up waiting for the agent, or the agent can end up waiting for me.
Is there enough time to start something else?
Not every gap is equally useful. A short pause might fit a small administrative task. A longer uninterrupted stretch might fit a different engineering problem. Starting that second problem has a cost: I need to load its context, understand where I left off and begin making progress.
If the first agent finishes just as I get into the second topic, I have to choose again. Interrupt the new work and lose momentum, or let the completed result wait? Launching another agent does not remove that choice; it can create several streams that all need review at once.
The useful question is therefore not simply “How long until the code is ready?” It is “How much time can I reasonably use elsewhere before this task needs my attention again?”
A spinner cannot help me plan
“Working” tells me that something is happening. It does not tell me whether the agent is still exploring the problem, making changes, running checks or waiting on an external dependency.
Those situations imply different choices. Early exploration may reveal a missing requirement. A running test may leave a more predictable window. A permission request needs me now. A finished patch needs review, which is still part of the work rather than free time recovered automatically.
Without that distinction, I am planning around a black box. I either check too often or come back too late.
What an ETA should actually tell me
I do not need a countdown that pretends to know the future. I need enough information to make the next scheduling decision.
- What phase is the agent in?
- Does it need me now, or can it continue independently?
- Is the next attention window likely to be short or long?
- How uncertain is that estimate, and has anything changed?
For example, “Verification running · rough window: several minutes · no input needed” would be more useful than a spinner. This is an illustrative interface, not a measured prediction or an existing feature claim.
The display should also distinguish an expected finish from an expected interruption. A task can take a long time overall and still need a decision almost immediately.
Better planning, not a promise
An initial estimate will be uncertain. Scope can change, a check can fail, or an external service can take longer than expected. A useful estimate acknowledges those changes instead of silently letting a countdown expire.
The first improvement could be very small: make “working independently” and “waiting for you” unmistakable. Then add rough time ranges where there is evidence, and compare them with actual outcomes before trusting them for more ambitious planning.
The aim is to help me choose sensible work for the available window. Sometimes that means staying with the agent. Sometimes it means handling a small task. Sometimes there really is room to pursue another topic.
Agentic coding can move implementation forward while I do something else. To make that useful, I also need to understand when to leave, when to return and how much attention the handoff will require.
Continue with the practical companion: Build an honest ETA display.