跪拜 Guibai
← Back to the summary

AI Killed Your Flow State Because You Designed a Relay Race, Not a Pipeline

A Confusion That Many People May Have

Since I started using AI to write code, I've lost something: flow.

Before, when writing code, my hands were always on the keyboard, with no waiting between my brain and the code. Changing a line and seeing the result immediately gave instant feedback, which felt great. Now? I throw a requirement to the Agent, and it runs for tens of minutes or even hours. I sit beside it not knowing what to do, and I can't help but pull out my phone to scroll. When it finishes, I come back and stare blankly at a huge chunk of output—the context has long been broken, and I have to pick it up again from scratch.

Time is fragmented into pieces, and people end up even more tired. I once thought this was an inevitable cost of the AI era, something I just had to endure.

Later, I figured it out: This is not AI's fault; I designed my own workflow wrong.

First, Clarify: Which Layer Exactly Is AI Eating Up?

I break down the judgment in development into two layers:

Layer 1, AI can handle, and it does a pretty good job—so I set up a bunch of Agents to cross-review each other (test review, code review, feature acceptance) to take over that layer.

Layer 2, AI cannot handle. It fails to deliver not because it's stupid, but because the business context is insufficient, or the context is too much and causes hallucinations. This layer of judgment is precisely my most scarce and irreplaceable productivity in this process.

The Mistake I Made: Designing Humans and AI as a "Relay Race"

My original workflow was like this: at the very beginning, a human confirms whether the AI has understood the requirements document (PRD) correctly, and then the AI runs fully automatically—generating the plan, writing tests, writing code, cross-reviewing each other—with no human intervention in between, and finally, the human comes back to review a massive finished product.

The original intention was to "let humans interfere as little as possible," thinking this was the most efficient.

But hidden here is a contradiction I didn't even realize myself: While I admit that human judgment is the most scarce, I am desperately trying to delete humans from the process. These two things cannot be true at the same time.

The result is that familiar pain: when the AI is working, the human has nothing to do and can only scroll on their phone; when it finishes, all the Layer 2 business judgments are piled up at the end, turning into a huge batch review.

What's worse, deviations in Layer 2 have a characteristic—the earlier they are discovered, the cheaper they are; the later they are discovered, the more expensive. If the business intent deviates by 10% during the planning phase, it gets magnified into a whole mess when the code is written. Seeing it only at the end means either a massive rework or holding your nose and accepting it.

What I was catching at the tail end were all deviations magnified N times. It's no surprise that the flow state broke there.

SDD: Moving Judgment from the "End" to the "Documentation Phase"

The real solution is hidden in a structure that already existed in my workflow: Planning documents have a sequence—Requirements Document → Design Document → Task Breakdown, each layer depending on the previous one.

This sequence naturally creates a pipeline:

When the AI is generating the Design Document, I am reading the Requirements Document; when the AI is breaking down tasks, I am reading the Design Document.

Do you see the brilliance here? The AI and I are in the same context, each pushing forward, neither of us idling.

The feeling of "uninterrupted attention" that I want isn't achieved by finding something to fill the waiting time—rather, the waiting itself disappears. Because the next segment the AI is generating happens to be the downstream of the segment I am reading.

And at this point, human judgment is at its most valuable: the documents are short, readable, and the cost of changing one line is extremely low. Plus, I've just finished reading the PRD, so the information in my head is the most complete. Correcting a 10% business intent deviation here is dozens of times cheaper than waiting for it to turn into a piece of code and then reworking it.

This is the same as "continuing to think and calibrate boundaries around the generated context"—except I've solidified it into the workflow, rather than relying on self-discipline.

One Thing That Must Be Added: "Confirmation Gates" Between Stages

There's a pitfall here that needs a warning, so a good plan doesn't become a new form of self-deception.

The premise for this pipeline to work is: Between each stage, there must be a gate where "a human nods before proceeding," not the AI running automatically to the end while I chase after it reading.

If the AI starts breaking down tasks while I'm still reading the requirements document, and I haven't finished reading it yet—then I've turned back into "chasing review," just slicing that big chunk at the end into a series of small chunks I'm chasing.

The correct approach is to use human confirmation as a valve: I nod after reading the requirements document, and only then does the AI generate the design document; while I'm reading the design document, it is not allowed to proceed; it is waiting for me. This way, I set the pace, I always have the complete current context, neither idling nor chasing.

What's the cost? Admitting that the original intention of "letting humans interfere as little as possible" was wrong from the start. In the documentation phase, humans precisely need to interfere, and this is the most cost-effective interference in the entire process. Use a few nods to replace that batch review at the end.

A Final Summary

The problem has never been "what should I do while the AI is working," but rather "why did I design humans and AI as a mutually exclusive relay, instead of parallel collaboration within the same context."

The flow state of the new era is no longer about typing code, but about continuously holding onto the problem and judgment. And this judgment is precisely honed, time and again, in the gaps between these "nods."