Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- Read the blog posts from Peter Steinberget blog steipete.me about his setup. Many AI builders converged on using the terminal with multiple panes. When a prompt is running if you don't have anything to do add another pane and start another prompt. Little by little you might have 1-6 prompts in parallel at some point. The flow state with AI is managing productively several prompts in parallel.by giorgioz
- It's interesting that the guy providing an actual answer gets downvoted, and everyone saying "it's impossible" got upvoted.by johnfn
- This is multi-tasking and the opposite of "deep focus".by rglullis
- Task size matters more than task count. Before sending a prompt, I try to predict the approximate shape of the diff. If I can't, the task is too large - I'll spend more time reviewing and fixing than if I'd just written it.
- Assuming you're like me and flow means learning interesting things and being engaged with the results...
Run tons of experiments. Turn yourself into a researcher. If you don't have a constant interface to the latest interesting experiment results to engage with/learn novel things/see novel solutions, you aren't running enough experiments.
Running an experiment means you don't already know the result, and you've looked at the prior art so you are doing genuinely new things. Establishing this prerequisite is completely trivial with modern agents.
Hopefully the answer is interesting and impactful enough that it will be useful in your work. This is honestly easier than it sounds; if you're a smart person working in a field where people are willing to pay money for impactful results, you can do this.
Anything that's not running experiments -- including debugging -- is grunt work that you should automate away, and you increasingly can if you set up your harnesses correctly. Make a pipeline so that the novel results of your experiments are polished, packaged, and shipped by your agents. How to do this obviously varies by domain but it's increasingly possible for most things.
And if your job is not doing the above, I have bad news for you: your job is going away fast. So you might want to set up a day on the weekend to give this approach a try; it'll be good for your flow and your career.
by avaer - Flow state relies on a constant information inflow that holds your attention perfectly, often hinging on competency and challenge. You can't enter it in AI coding because you need to wait for replies. It's incompatible.
I just watch YouTube in the downtime these days, or movies that I don't care too much about
by aaarrm - There's an XKCD for that, "Compiling" : https://xkcd.com/303/by jasonjayr
- Meditation teacher Michael Taft recommends "dropping into awake awareness" whenever you're waiting for a response. [1]
It's the opposite of watching YouTube, pretty much.
by kranner - > Flow state relies on a constant information inflow
Does that mean when I'm in deep thinking without any external "information inflow" I'm not "in flow state"?
I'd agree that waiting for replies kind of pulls you out of flow if you just sit and wait, but I'm not sure why you'd do that. You can continue working along-side, validate, or continue iterating on the design while the agent does other things.
- I have this problem too. The only thing that has 10x'd is my boss's expectations and the number of draft PRs I have open...by SCUSKU
- For me the flow state has always come from a sensation of creative juices spawning ideas, a vision for an end result, and the deep focus that ensues in working towards that.
Such a cycle previously could take hours or days, resulting in long, deep flow states. But now I go through dozens such cycles a day.
So less of a single flow state, more so many short flow states. As for waiting, that’s when you can explore another idea in parallel. Double the flow states for me :)
by mck- - (1) Spending time building a plan. I have lots of artifacts like diagrams, tables, web pages that help me think through all the details quickly. Get code snippets to reduce uncertainty, get options for architectural decisions, flesh out assumptions.
Main thing is (1) how do I verify the agent hits the happy path and (2) how can I elicit and clarify assumptions it might make.
Then follow up the build with exploring and refactoring.
(2) prioritized context switching (like playing an RTS) I have several tasks going at once, while one works I hop onto other tasks.
I usually have one or two “core” goals I’m trying to accomplish that take deeper thinking and get priority. The other tasks are smaller and require less thinking.
A lot of times I’ll have the secondary agents build research docs I can review in detail later.
by jlos - Yeah, I definitely do something similar with my personal projects.
I come from more of a hardware & environmental engineering background and we were always taught that projects were iteratively built via Design, Build, Test, Learn cycles.
I drive the Design and basic skeleton of the build (pseudocode or boilerplate), then pass off the rest of the Build and Test to the agent. I pick up after the test and read the agent commits/notes, then write up next steps. Repeat DBTL. Maybe spin a few features out at a time in parallel depending on how much time I want to devote to reviewing new project features later in the day.
by rbartelme - I think planning is a big part. ironically, this wasn't a part of my typical routine as an engineer before AI came around. Sure I thought through the work or ticket I was assigned but not always at as much of a birds eye view.
Nowadays with AI I try to start most tasks with a plan, review each phase/step, research parts I'm more unsure of, and try to refine it. Ironically it's more of a dev cycle like process anyway IMO.
by spike021 - I can't believe "prioritise context switching" is now advice being doled out on HN.by specproc
- I use "comment-driven development" by building out the skeleton manually, writing comments instead of code, and letting the agent fill the code in (and then repeat, until done). It is a "lower level" of AI usage, compared say to full-vibe mode, spec-driven development, whatever. But I feel that it's even easier to stay in the flow, because I do not get bored by boilerplate or mundane implementation details.
"Higher levels" of AI usage are exhausting and flow-free endeavours.
by bad_username - This sounds good except when you need to cross multiple files. I feel like a significant part of the value of AI is that it can just find things instantly instead of me having to navigate some menu or enter any commands. At least in my experience changing 1 thing requires traversing a large slice.
I guess to take it a step further you could just write everything in a single file with enough context to let the LLM figure out location but this is quite literally just a prompt.
by nonethewiser - Never, has made my programming joyless and boring. If it wasn't a requirement to keep my job I'd never touch it.
- I genuinely have a lot of fun coding with AI, possibly more than I used to have coding normally. It’s true that I don’t spend hours on a single problem any more, but I instead spend a lot of time thinking and researching higher level issues like architecture and design. I find this work to be very rewarding because I very much enjoy learning new things. I don’t know if I would call it a flow state in the same way that coding was a flow state, but I definitely have a lot of fun learning. For instance, yesterday I was learning a lot about AWS infra, which I found very enjoyable. Before that I was learning about Fly Sprites, which it turns out are a little broken, but it was still interesting to learn about them. Pre-AI I think coding was slow enough that I would be able to learn a new thing like this once every couple of weeks, because then you'd have to go spend a ton of time on the implementation work. Now the implementation work has compressed and I get to learn new things more often, which is fun.
When I send one agent off to do work I usually begin thinking about some other unrelated problem I also want done, and then I try to spin up a parallel agent to do that as well. The thinking itself is where a lot of the deep work happens for me IMO. I probably spend like 80% of my time thinking, researching and reviewing plans. The other 20% is actually promoting.
I see a lot of people saying that agents trivialize work now - like you just push a button and an answer comes out. This is so far from my experience I actually don’t know how to bridge the gap. If you are not spending a lot of time researching you are likely going to be asking the agent to do things that don’t really make sense.
by johnfn - 100% agree. People talk as if they were paid to tap keys - not think, research, plan and provide and measured solutions to problems. I’m doing more engineering than ever, just less pointless tapping.by solumunus
- Exactly my experience.
Literally every task/feature now involves me learning or thinking through an architecture. I enjoy it because that was always my favorite part pre ai thinking through and designing the system.
It is actually more mentally taxing I think because now all I do is work through complex architectures and thr fact that code comes near instant means the scale and volume at designing the architecture is 10x now.
Top models are so good at not messing up code whenever there's lots of bugs it actually means my design and testing methodology was poor which is also a much harder problem.
- Short answer is I don’t and it adversely affects my job satisfaction.
I’m quite sure I’ve left money on the table over the years as a result of my reluctance to manage and mentor junior developers. Disappointing that I’ve ended up managing junior AI developers who won’t even grow as a result of the time I’m putting into them.
by afavour - Oh they'll grow, but mostly to the benefit of someone else.by randledangle
- Here's the neat thing: you don't.
I've tried, and I feel like I've got closer with faster models, but ultimately the agentic loop excludes you. Even if you're asking the agent to do simple short tasks, it's still: prompt, wait, wait, wait, check, and you never really feel like you're the one in control.
The problem with faster models is also that they're more stupid, so that additionally breaks your flow when you have to fix something dumb it's done.
LLM-powered autocomplete is a bit more like it, but that tends to be either so dumb as to be a net negative, or slow enough to be useless. And autocomplete is pretty distracting for me.
I feel like I'm missing a mode that works more like a pair programmer. Perhaps a multimodal model that can talk to you about what you're writing, as you write it, and offer suggestions rather than trying to take over and do everything for you.
by marmarama - *You dont*
Skill issue, not a universal problem.
by jlos - > I feel like I'm missing a mode that works more like a pair programmer. Perhaps a multimodal model that can talk to you about what you're writing, as you write it, and offer suggestions rather than trying to take over and do everything for you.
This is exactly what I have also been thinking and wanting for a while now. A realtime agent that I can share a screen and mouse / keyboard with. and we can just work together at times. I think it will probably come at some point but we might be a few years away from it.
by jdmoreira - I want something that works in the background, checking my work as I code, running tests and making suggestions... Without being obstrusive. Like a pair programmer.
- Getting in the flow means continuous, deep concentration and attention, at least in my experience. Prompting and checking is more like managing an underling, I couldn't get in the flow that way. It would be like a driver trying to get in the flow with a vehicle that randomly does unexpected things.by ASalazarMX