The Engineering of Intent, Chapter 17: The Flow Loop
This is Part 17 of a series walking through my book The Engineering of Intent. In the previous chapter, we walked the morning routine. Once you’re through it, the question is: what does a great Vibe Coding hour actually look like? Chapter 17 answers it.
Flow, With an Agent in the Loop
Classical flow is the state where the work is doing itself through you — hands moving without deliberation, time compressing. Vibe Coding flow is different. You’re not typing the code; the agent is. But flow still exists, and it is still the performance-defining state of your day.
The rhythm, when it’s happening: you type a short, dense instruction. The agent responds in under a minute. You read, adjust, approve or redirect. Two to four minutes per cycle. Ten to twenty cycles in an hour. At the end, you’ve shipped something and could not quite explain how.
It is not a daydream and not a trance. It is more like driving a familiar neighborhood while having a good conversation. The car is the code. The conversation is your intent. The agent is doing the driving. You’re making sure the destination is right.
The Two-Minute Rule
If the agent takes longer than two minutes to respond, your flow is breaking. This is empirical, not theoretical — I’ve timed myself and a dozen other practitioners, and two minutes is roughly the line. Under it, we stay engaged. Over it, we tab away, and the cost of tabbing back in is not recovered by letting the agent think longer.
The Three-Strike Rule
If the agent gets it wrong three times in a row, stop. Do not try a fourth prompt variation. Three strikes is the signal that the problem is not in the prompt — it’s in your understanding of the task.
Close the editor. Open a notepad. Write, in prose, what you actually want to build and why the agent’s attempts were wrong. Nine times out of ten, the act of writing uncovers an ambiguity you had not noticed. The fourth prompt, after the notepad exercise, succeeds.
“The anti-pattern is running the same prompt five times hoping for a better sample. Models are not slot machines. If three samples failed, the fourth is not your hero. Change the question.”
Flow Killers, in Order of Importance
- Slow models. A three-minute wait per cycle drops you out of flow every time.
- Non-deterministic agent behavior. If the same prompt produces different shapes of output, your mental model thrashes.
- Confusing tool output. A wall of code without a summary breaks the trance.
- Notifications. Slack, email, calendar popups.
- Your own internal monologue of doubt. If you’re second-guessing the architecture mid-cycle, you’re not in flow — you’re in anxiety. Learn to separate “valid design concern that needs its own plan” from “anxiety I should note and come back to.”
Micro-Rituals That Maintain Flow
Between cycles, do not tab to Slack. Between cycles, do one of: read the last response slowly; sip water; straighten your posture; stretch your wrists. Ten seconds of body awareness resets cognitive fatigue better than a five-minute distraction.
At the top of each hour, stand up. Walk to a window. Look far. Return. This is not a productivity hack — it is basic operator maintenance. Engineers who cannot do this are engineers whose afternoons are worse than their mornings.
At the end of each flow block, write one sentence in your memory bank summarizing what just happened. You will need it tomorrow.
Next up — Chapter 18: The Prompt Patterns Catalog. Flow is the rhythm; prompts are the beats. Chapter 18 is my catalog of the specific prompt patterns I use every day — the ones that produce reliable output where naive prompts produce noise.
📖 Want the full picture?
The chapter walks each flow killer and its remedy, the two-minute and three-strike rules in detail, the full micro-ritual set, and the checkout-refactor case study hour by hour.
Sho Shimoda
I share and organize what I’ve learned and experienced.カテゴリー
タグ
検索ログ
Development & Technical Consulting
Working on a new product or exploring a technical idea? We help teams with system design, architecture reviews, requirements definition, proof-of-concept development, and full implementation. Whether you need a quick technical assessment or end-to-end support, feel free to reach out.
Contact Us