From the flow of coding to the flow of orchestrating

At the end of the first log I wrote: the flow doesn’t vanish, it moves. Today is about where to. I noticed it in a case where I did not hesitate at all: I approved, I merged, and everything felt as good as always. But it was not right.

An example from the work on this website: the feature for the bilingual log, with its home page and banners, lived in four PRs that build on each other, #21 to #24 in the authorship.dev repo. The AI had created the stacks, but I overlooked that. Each PR hung on the branch of the one before it, not on main. I approved and merged them one after the other.

Only later did I see: just #21 was in main. #22 to #24 sat in the feature branches. I noticed because the log home page and the banners were missing on the website. Nothing bad happened, just some git work and another deploy. But I had confirmed four times with my name without once looking at where it goes.

What bothers me is less the mistake than how it felt. In Log 1, green CI stood between me and the sign-off, but I hesitated. Here there was nothing that made me hesitate. I was in a rhythm: approve, merge, next PR - there was no flow killer. But approve and merge confirm the action, not the target. I read “done” as “signed”. The button became my substitute signature, just like the green pipeline in Log 1.

In the workflow plan, this case is called “The agent opens the PR”, and the risk is described there like this: “The risk: you feel like a reviewer. You are the author.” The sign-off is the point where I stand behind it with my name. That is exactly where I did not look.

Why didn’t I look? I love flow, coding and creating in the tunnel. With AI-generated code it is tempting to stay there: the “Approve” button is always ready, without any hurdle - that is what keeps me in the flow. That is the old flow of coding, just without the frictions that used to make me look closer by themselves. The task now is to stay in the flow and still hesitate. That is the flow of orchestrating.

It has more elements than the flow of coding: in this example, the split, the base, and the handover from one PR to the next. That gives it a different rhythm. The pause feels like a break at first. With a little practice the resistance gets smaller and the pause becomes part of the flow. In my work with precision athletes this is everyday: the pre-/post-shot routine is a pause that becomes part of the shot. And the hesitation is more than a pause: it is the moment when I deliberately stand behind the change with my name. It is the point where I deliberately strengthen my identity as an author.

So what do I sign in that moment of pausing? For a single PR the answer is simple: the diff. For a stack it is three things: the content, meaning the diff; the target, meaning the base it lands on; and the effect, meaning what is actually in main afterwards. Correct content on the wrong target is not what I meant to sign.

My exercise for this week is a single question before every merge: where does this go? The answer is right below the title of the PR, which says which branch it merges into. I read that line before I click. With a stack, I also look into main once after the merge to see whether what I signed has arrived. That is the smallest form of accountability.

And you? Where did your last merge go, and did you check?