[dgb23]

I want to add something to this which is rarely discussed.

I personally value focus and flow extremely highly when I'm programming. Code assistance often breaks and prevents that in subtle ways. Which is why I've been turning it off much more frequently.

In an ironic way, using assistance more regularly helped me realize little inefficiencies, distractions and bad habits and potential improvements while programming:

I mean that in a very broad sense, including mindset, tooling, taking notes, operationalizing, code navigation, recognizing when to switch from thinking/design to programming/prototyping, code organization... There are many little things that I could improve, practice and streamline.

So I disagree with this statement at a fundamental level:

> The technical skill of writing code has been largely commoditized (...)

In some cases, I find setting yourself up to get into a flow or just high focus state and then writing code very effective, because there's a stronger connection with the program, my inner mental model of how it works in a more intricate manner.

To me there are two important things to learn at the moment: Recognizing what type of approach I should be using when and setting myself up to use each of them more effectively.

[thrwthsnw]

Just move up an abstraction level and put that flow into planning the features and decomposing them into well defined tasks that can be assigned to agents. Could also write really polished example code to communicate the style and architectural patterns and add full test coverage for it.

I do notice the same lack of flow when using an agent since you have to wait for it to finish but as others have suggested if you set up a few worktrees and have a really good implementation plan you can use that time to get another agent started or review the code of a separate run and that might lend itself to a type of flow where you’re keeping the whole design of the project in your head and rapidly iterating on it.

[bluefirebrand]

> Just move up an abstraction level and put that flow into planning the features and decomposing them into well defined tasks that can be assigned to agents

This doesn't work because you still have to read and verify all of the stuff your agents produce

So the new workflow is: Move up an abstraction level to use an agent to produce code Then move down an abstraction level to review the code it produces

This sounds like way more cognitive overhead and way harder (and therefore probably slower) to do than just writing the code by hand in a good flow

[dgb23]

There's something fundamentally different between writing the program directly that you visualize in your head versus staying one level away and reviewing someone else's code. I'm really talking about the former.