Traditional Coding vs Agentic Coding: The Flow State Problem

A developer argues that agentic coding workflows erode the flow state and sense of ownership that make traditional manual coding satisfying, because handing work to an agent replaces the tight think-write-run-observe loop with a prompt-wait-notification cycle. Running multiple agents across projects at once can feel like superpowers early on, the developer writes, but often leaves them scattered, repeatedly rebuilding context instead of settling into one problem.

One of the things I've always enjoyed about coding is getting completely locked into a problem. You know what you're building, each small obstacle leads to the next decision, and you stop noticing how much time has passed. With agentic coding, I don't always get that feeling. I can produce more code and still feel less connected to the project. I don't think that means AI ruined coding. I use it every day. But the way many of us start using it replaces the tight feedback loop that made coding satisfying with a prompt, a wait, a notification, and a context switch. The workflow deserves a closer look. When you write code manually, you move through a fairly tight loop: think, write, run, observe, adjust. You start with a feature and work through the details. Which files need to change? How does the data move through the application? What should happen when someone submits the form? Then you write enough code to try it. Maybe it works. Maybe it throws an error. Maybe it technically works but doesn't behave the way you imagined. Whatever happens, you have something to respond to. Each result gives you something to respond to, keeping the next decision close to the last one. That loop can repeat dozens of times while you build a feature. As you get into it, you stop consciously moving between planning, coding, and testing. You're just solving the problem in front of you. Manual coding has plenty of interruptions too. Builds take time, documentation sends you down rabbit holes, and sometimes you're simply stuck. But the work itself keeps asking you to make the next decision. For me, that involvement has always been part of the reward. Getting a difficult feature working feels good because I experienced the little decisions and breakthroughs that got it there. With an agent, the planning may look similar. You have an idea, a project plan, and a feature to build. Then you describe the feature and hand it off. Now you wait. You're probably not going to sit there watching the agent work. You check your email, open another tab, or move to another project. Desktop tools make that especially easy. Project A is running, so you prompt project B. While that's running, you start something in project C. Eventually, project A finishes. Now you have to remember what you asked for, what you expected, and which parts of the application might be affected. You review the changes, test the result, and find something that needs adjusting. You send another prompt. While you're doing that, project C finishes. In the beginning, this can feel like having superpowers. You have several agents working at once, and things that once took days appear in minutes. The amount of output is exciting. But I've found that it can also leave me scattered. Instead of spending two hours working through one difficult problem, I spend those hours repeatedly remembering where I left off in several different problems. An illustration of fragmented attention, not measured productivity data. The colored rows represent different projects. The work is moving, but I'm never fully settled into any of it. AI coding gives your brain repeated opportunities to leave. Each project has details you need to keep in your head: the current feature, the relevant files, the unresolved questions, and the decisions that brought you here. Returning to a project means rebuilding enough of that understanding to judge what the agent did. You reread files. You forget why an approach was chosen. You overlook a change that conflicts with an earlier decision. None of those moments seems like a big deal on its own, but together they can make the whole process tiring. Your attention also starts following notifications. You switch because an agent finished, rather than because you reached a sensible stopping point. The other thing I notice is a loss of ownership. That doesn't mean you did nothing because an agent wrote the code. You had the idea, planned the work, directed the agent, and decided whether the result was acceptable. Those are real contributions. But the bigger the task you hand off, the more decisions arrive without your involvement. An authentication feature might include choices about the user model, validation, error handling, session management, and how the interface responds. If all of that appears in one large diff, you have a lot to understand before you can confidently accept it. You can review the result, but you didn't follow how those decisions developed. That difference becomes noticeable when something needs to change. You may know the feature works without knowing where its assumptions live. One-shotting an entire application takes this further. You can end up with something that looks convincing while leaving you with a codebase you barely understand. For me, that distance affects both the quality of the work and how satisfying it feels to build. I don't have a perfect system that will put everyone into a flow state. I'm still figuring this out myself. But a few changes have helped me stay closer to the code without giving up the useful parts of AI. Instead of asking an agent to build an entire authentication system, I might start with the user model. I review it and check that the fields match what the application needs. Then I ask for the registration endpoint, test it, and review that change before moving on. Smaller requests create opportunities to understand and redirect the implementation before moving on. The exact size of a task depends on the project. An experienced developer working in a familiar codebase may be comfortable handing off a complete feature. Someone learning the stack may need smaller steps. The point is to choose a checkpoint you can meaningfully review. If the result is too large for you to understand the important decisions, the handoff was probably too large. Notice the difference between "build authentication" and "create the registration endpoint using this user model." The second request connects you to the structure of the software. You're thinking about what the application needs and how the pieces fit together. That's one reason fundamentals still matter. You need to understand models, routes, endpoints, components, and data flow well enough to ask useful questions and recognize when the implementation is wrong. Some people will say this defeats the purpose. If the agent can build the entire feature, why break it into smaller requests? Because generating the most code in the shortest time isn't always my goal. I also want to understand what I'm building and be able to change it myself. When the agent starts processing, I try not to automatically jump into something unrelated. There's usually something useful I can do within the same project. I can read the surrounding code, think through an edge case, prepare a test, or check the current task against the plan. I don't need to watch every line appear. I just want to keep the problem fresh enough that I can make sense of the result when it arrives. If I'm waiting on project A, immediately loading project B into my head makes it harder to return. Staying with project A gives me a better chance of keeping some continuity. When the agent finishes, I look at the diff and test the behavior before moving on. Did it solve the problem I asked it to solve? Did it change unrelated files? Does the implementation fit the existing code? Do I understand the decisions well enough to work on it manually? If something needs adjusting, I'd rather catch it now, while I still remember what I wanted and why. Letting complicated agent tasks pile up creates another kind of backlog. The code may be written, but I still have to understand and verify it. Leaving that until later doesn't remove the work; it gives me more to reconstruct when I return. I'm not against parallel agents. They can be useful when they're investigating related parts of a project or handling work I can review at a planned checkpoint. The problem is having several unrelated projects compete for my attention throughout the day. The number of agents matters less than what their work demands from me. Several agents contributing to one clear goal may be manageable. Three agents working on three different applications can leave me constantly switching between unrelated decisions. I want to choose when I review background work, rather than let every completion notification choose for me. The workflow I'm aiming for feels closer to working with a fast pair programmer. The agent handles a lot of implementation, while I stay involved in the decisions and feedback. Will that produce as much raw code as opening ten tabs and handing off ten features? Probably not. But the amount of code generated tells me very little about whether I'm building something good. I care about whether the result works, whether I understand it, and whether I can maintain it without asking an agent to explain my own application every time I return. I'd also be lying if I said this gives me exactly the same satisfaction as writing code manually. It doesn't. But it feels much better than handing off huge tasks and coming back to a pile of changes. I know the product better. I can jump in and work on a feature myself because I understand where things are and why they were built that way. If you've been getting more output from AI while enjoying the work less, try changing the size of the handoff. Pick a checkpoint you can understand, stay with the project while the agent works, and review the result before moving on. That's the experiment I'm still running: finding how much I can delegate while keeping the involvement that made me enjoy coding in the first place. Adapted from my video, Traditional Coding vs Agentic Coding: The Flow State Problem https://www.youtube.com/watch?v=aVvRELbjcNU . All illustrations are frames from the video.