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.
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.
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.
Llm-buddy is an “Emacs package that watches your recent buffer edits and asks an LLM to review them. When it finds something worth pointing out, it can add a short inline note in the relevant buffer or show a message in a popup buffer (it usually does the former).
The goal is lightweight feedback while you work: typos, logic mistakes, questionable edits, or prose issues that a normal compiler, linter, or spell checker may not catch.”
This is a UI/UX problem, no? While the current suppliers are mostly locked in the ‘chat for everything’ mode. Guess what, we didn’t go to the moon in chat mode, we don’t drive cars via chat and cyborgs don’t play chess that way. Domain specific interfaces are the way to go (opinion).
Edit with an example: Read some interesting science news yesterday regarding man made risk of high water (Nature). Mailed the author, found the article (popular news doesn’t do attribution) and data and code was open source. Claude Fable had it running very fast and explained the things I forgot from high school. Started on localization and adding some methods from my background (econometrics, extreme value theory). All nice in the /hobby/ way. I can overlap fields in hours now. A brilliant feeling (but probably not brilliant).
What I cannot do is assess the value and novelty of the created work on my own. So I still need to have a set of geologists and econometricians / actuaries work through ‘my work’. That’s what we need tools for! We need UI/UX in this case for novel fields interacting with quality controls made easy. I currently wouldn’t dare ask the author for her time based on my slop. And I cannot critically assess what I’ve made. I only learned today that Greenlands ice attracts water, that Manila and other cities are sinking due to exhaustion of their aquafiers and that the North Sea is surge heavy and unique that way.
I think "without being obtrusive" is a key point here, because any type of popups in the midst of working would break flow as well. Fixing compiler warnings is flow-inducing because it's very linear and has a fast feedback loop, so it would have to be something akin to that.
Side-note, I wonder if audio cues would work well here. When another person is commenting on something, we as humans can typically remember their point while still being focused on text, but if a popup with text comes up we usually get distracted by it. Just my two cents.
I've found AI code reviews as a first pass on PRs to be quite non-obstructive to my workflow and the AI code reviewer (while not instantaneous) is certainly faster on a response than the human pass will be.
> 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.
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.
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.
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.
(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.
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.
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.
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.
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.
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.
You can't, "agents" and "agentic coding" are incompatible with the deep understanding of your code that getting into the flow state requires. By definition, prompting a tool to do your job for you means giving up the depth of control that comes with actually writing the code.
Some people can work like that, some very few people may even produce acceptable results like that. I cannot and I am not interested in doing so.
The closest you can get to agentic coding while still actually being in the control loop is something like intellisense - where it just fills out the implementation of small chunks of code, one block at a time and only when you specifically request it.
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
> 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.
When you're deep thinking you have a constant information inflow that's coming from your own thoughts. This is different from relying on an exterior tool because in that scenario your brain is blocked from thinking by relying on that tool giving it a breather to wander off a garden path. That isn't necessarily a bad thing (it's nice to give your brain a stare off into the distance break every once in a while) but if you've adapted your thinking and working style to the constant inflow and outflow of information it can be highly disruptive.
Not sure what the OP or the person in the videos means but a direct, fast way I have found to “drop in” is to stop thinking and intensify my awareness of everything. Takes about 5-10 seconds to transition into a nonthinking timeless presence.
Attention is on the full body, and the field of perception, then field of awareness, all at the same time.
A bit like shavasana practice, but instead of scanning part by part, expand presence to everything.
The thinking analytical mind stops, the nonthinking mind activates and softly intensifies.
Yes this would be one “provisional” method among many, maybe hundreds of techniques but they all seem to lead to the same place as one gets familiar. In Buddhist Vajrayana schools this is called “non-meditation”. The ultimate instruction is to simply do nothing, but this requires a bit of initiation (and paradoxically, concentration) to get right.
Michael Taft has many different guided approaches to this on his channel but there are many other teachers as well, e.g. Adyashanti, Angelo Dillulo, Loch Kelly, Shinzen Young (specifically his Do Nothing and Auto Focus techniques) and expanding the gamut to traditional Vajrayana teachers, Lama Lena, Mingyur Rinpoche, Lama Dawai Gocha, all with accessible online teachings. Also Sayadaw U Tejaniya and Christopher Wallis who are less conventional, so to speak.
Not familiar with the infinite gamut of techniques, and yes sounds right.
It is possible, there are many ways, some people are curious about this state and lean into it, most are not. Who does, or doesn’t, and when, in my experience, is matter of grace. So no need to worry about it.
I see it as something that happens to me rather than caused by willpower. Much like a memory or a flashback that then transports you.
That's also my experience. It's absolutely a letting go rather than a doing; one of Michael Taft's analogies for it is "dropping the ball".
The provisional techniques are great because different techniques click for different people. Once they've seen what it is, it's easier to drop in more directly. If there's any willpower involved, it's more a subtle dropping of discursive mental commentary (especially on the process itself: I've got it - almost there - why can't I get there today - ah so this is what works, etc).
Once you're there, it feels like the most familiar and comfortable place in the world. As one of my teachers said, this is real rest.
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 :)
Usually take mushrooms or gummies and see what happens.
This isn't even troll post. AI has killed the ability to reach flow for me, but I basically have to use it at work so <shrug>. But if I'm WFH or at night, a little help helps me stay focused and connected to my work, sometimes even with AI. Does my mind drift? sure. But that's as close as I get to flow now.
Do not wait for replies, try to structure your workflow so that you are always either refining requirements for the future tasks that you are going to to give to the agent later or reviewing (sometimes also manually testing) the code that the agent has produced before.
I think that this is mostly a UI problem. Chat UI is just not a good UI for programming and the fact that the current "AI"-coding sphere has converged on it is incredibly silly.
One of of the first things that I did when I first seriously tried an LLM-based coding agent is making an ad-hoc task manager on skills and simple daemons.
So that I can interact with it using files instead of this stupid workflow of typing a prompt into the console and then just doing nothing while waiting for the response.
There is absolutely no reason not to do it asynchronously.
For working on a single project, I have a text document open where I’m working on future prompts. For working on tasks in a team setting, with prs and reviews, i built a tui that manages multiple tmux sessions. It creates a worktree for each task. It has status indicators for each session, hotkeys to quickly cycle through them, hotkeys to pull, annotate and paste pr comments, pull, annotate and paste linear tasks and comments, hotkeys to launch external tools and to jump directly to the pr url, and any time there’s a period when all the dots are busy i just start a new task. It’s a bit manic, but it’s manageable because it’s all in one terminal window. It’s also for AI as it existed 3 months ago, work slowed down and i haven’t tried to apply loops or whatever the latest crazy thing is.
Indeed, the code generated by AI is very poorly readable. After a while, I gave up reading the code! I feel like my coding ability has been reduced, and I don’t know if this is a good thing. I used to work hard on coding, but now I feel more and more like a product manager.
Start with a set of work that's well specified and reasonably chunked to sizes that make it so that the review parts fit in the gaps of the working chunk and interleave (1-4 tasks of this). While the agent is working on the A task, you're reading the B task, only add a 3rd task if you're waiting on the agent excessively. Give yourself some slack on this to think about side quests (maintenance / tech debt / planning future work to your system etc.)
Make sure the handoffs are reasonably detailed (prompts / AGENTS.md instructions) - make your agents provide more context than normal - make them assume that you don't read all the text they spit out and need to be handed succinct summaries with information that helps reduce cognitive burdens (what I was doing, how I did it, what's next etc.)
It's reasonable to regularly ask the agent what things you've worked on choices made, options considered and discarded, context rehydrating. There's a lot of small tweaks you do when interactive prompting that get lost in a drift rather than captured as a neat single list. Make the agent help track that stuff. (at least prior to shipping, but often in intermediate steps.
Write flows that keep software in a buildable state so you can run it and queue up changes based on what you see. Avoid long periods of broken refactoring (caller code written before callee, deletion before add in a move etc.) Run quick checks (e.g. rust's cargo check) after each change, not at the end.
Correction of agent errors should end up as future steering. If the agent makes a mistake once it's the agents fault, twice it's your fault.
Leave time to stop and evaluate the current state regularly (where are we on the work). It's easy to mistake momentum for progress when you're the human part of an agentic loop.
While I don't have the answer, I will leave my thoughts here, maybe my comment helps you or some of the responses might...
I was thinking about this when I tried a faster model (Cursor released something fast about a month ago?). It was such a joy to use (well, at least compared to other models, where you wait 5-10 mins for even simpler tasks), and I noticed I felt much closer to the problems, and I got closer to a "flow" state... ...but unfortunately, the models are faster for a reason, and the output got worse. While I did enjoy my job more, I was also left worried that the model missed important things (and it did when cross referenced with other models or just doing the thinking myself).
IMO we need much faster yet capable models to bring back a bit of a flow state.
Another approach worth trying is to get some agents researching 4-5 tasks thoroughly in the background, discovering all the relevant details, collecting all the files likely to be edited, their content etc..., then work on one thing at a time with a better focus for yourself, maybe use a faster model.
One thing I try to do is code manually if I know that I can be faster and better. It's convenient to stick to one tool, the agents, when editing code, but for smaller clean up tasks, they just never get it right, and sometimes it's better to do 1 min manual work over 5 mins of explaining what you want and the agents still not delivering it...
I like to bounce around between a few different things at once.
Normally, I work on my core work plus something tangentially related (e.g. 20% projects). The 20% projects keep my attention while the core work is LLM'ing.
As a Staff level engineer, a large part of my job is taking interruptions from others. I also do a lot of code reviews, design meetings and the like. Which is to say I have only rarely been in the flow anyway. I just more/better code written these days just because the AI can be in the flow while I'm answer those things. However I have even more code to review because the AI needs constant "this is a bad design" prompts.
It is hard. Much harder than regular software work. A few things need to line up: model iteration speed, task chunk size, and your own context window and comprehension abilities. Too slow and you lose interest. Too easy and it's just tedious riffing. Too large and you're burned out by reviewing giant complicated walls of text. Etc. The bites have to be the right size and speed for both you and the LLM.
In the few instances I've been able to achieve really joyful flow state, there are usually two simultaneous workstreams, plus or minus one. They're usually working towards a large goal that I roughly know how to judge, in digestible bites.
For example, sequentially modifying the UI in a series of operations towards an overarching goal, where it's easy to tell if a step worked, and what the next step should be, but where you're not sure exactly what you want, so there's some curiosity and discovery rather than just feeding the bot tiny instructions. I try to keep the two workstreams from overlapping. If both streams start fighting over a file they both dirty, things go south fast.
Adjusting your prefs/harness/etc for model terseness goes a LONG way. Context quality is absolutely everything. A good context "seed" can go back and forth for many turns cleanly and with focus, and even compact successfully once or twice. A bad seed will be annoying to work with from the jump, will thrash towards compaction faster, at which point it gets even worse. This is difficult to troubleshoot objectively, but I'll frequently restart conversations if I don't like the vibe of the first couple turns. It's made harder by constant model churn. Until opus 4.8, I ran opus/sonnet 4.5 high for a long time in large part for continuity of intuition, if that makes sense.
There are also many elements of human knowledge management that make a difference. I've found "append only" to be a magic word, generating markdown logs of changes, or learnings, etc. Whatever workflows create visibility and resumability so that you can return from a spell away and get up to speed effectively. Manually keeping your own dev log alongside the session sometimes helps, makes things sticky and ensures you understand what's happening.
But it's hard. Feels incredible when it goes well, but going well feels very nearly random, and whittling towards reproducibility can be very mentally draining, in terms of both energy and morale.
You need to saturate your attention span with running so many agents at once that when you issue the last prompt to the last agent, the first one is already finished. This way you need to continuously concentrate, so flow is achievable.
The difficulty is to break down the task in a way that multiple agents can work on it.
I usually spin two or three major issues with 10-12 agents in total.
I have converged on a workflow that is just what I was doing before, but use LLMs just for boring or tedios parts. General guidelines are: only single agent at a time, small targeted queries, understand what you are building, if something would seem like a fun task, do it yourself. I use LLMs for bug hunting, to trace the flow, to build quick visualizatios (paste csv, ask to generate visualization), to search in the code of the dependencies using github mcp, to write 100 line scripts (deno + ts + zx was a game changer for me). Even "dumber" opensource models are good for this kind workflow, more tokens per second is generally more benefitial than plain intelligence. I would use LLMs more or less, sometimes even full vibecoding if the task is something like quick tooling web app and the flow is just firing of the next LLM query every 30 seconds. But, depending on the type of task or domain that you work in, YMMV
im finding it way way more "flowy" than pre-ai. all the boring trivia is gone, i can focus on what i actually care about - the shape of what i am building, tradeoffs, second- and third-order consequences of decisions.
the trick to get it uninterrupted is "selective multitasking". i don't like having too many Claudes / Codexes in parallel on auto-pilot; this way im finding i'm getting _something_ that is perfectly plausible, but rarely what i wanted. but I have N going at any given time, just enough to be basically non-stop reading. problems need to be related; within one project, ideally adjacent areas that are complementary. then my "flow" is just switching between reading and typing non-stop. never felt time flying by faster in my life, pure flow
also forgot to mention that 90% of the work (and time) is bouncing markdown files back and forth until the design is clear and I feel happy about it. design docs, working docs, etc. implementing then is where I can engage way less and switch to a different tab in cmux to drive it
I reach the same flow state by multitasking across multiple tasks in multiple repos. I can hold my own context across 5-10 different terminal tabs each running their own Claude code or pi. Watching Claude especially with sub agents is like watching paint dry.
Since I built my own dev tool to allow me to better organize and manage multiple sessions, I've found my flow state hits when I've got agents staggering to completion. Conversation with one, wrap it up, send my response, and another one finishes. I currently have 49 agent sessions open in atrium and when I'm grinding, 5-15 are going at a time. If I get em all onto longer horizon tasks, I start to comb through other sessions to pick up parked conversations.
I try and make very small and deterministic steps. I do the planning (in flow state) and let the model to the execution. When the model is executing, I follow the "thinking" and keep seeing the diff like I would when I was coding.
I never really got into flow state from planning. Too much brain power, dead ends, etc. I reached flow state from the "busy work." Knowing what needed to be built and implementing it.
I think if you find that your coding style is disrupting your productivity or job satisfaction then you're misapplying the tool to your particular working style. We're all different in how we approach problems and tools should support our preferred approach (assuming that approach isn't unacceptable from a working performance perspective which, to defeat your imposter syndrome, I absolutely guarantee you isn't the case if your performance hasn't majorly shifted since the introduction of AI).
I've actually embraced the asynchronous element of AI programming in my personal projects.
Playing Star Citizen? There's pockets of 5 minutes all over the place traveling from A to B. I keep my laptop nearby and have a prepared todo list of items to work through. Those moments wasted on Reddit are now moments wasted on feature experiments!
Waiting for a cup of tea? Run an experiment. Waiting on wife? Run an experiment.
Piece by piece an app is coming together built from 5 minute increments of reclaimed time.
Pair programming. I call it pilot / copilot / autopilot. Two real people plus one or two agents working together. Classic XP stuff, the copilot can help remind what we are focusing on, file follow up issues, give instant code reviews.
Bake offs. Do the same task but in two different chats or agents or approaches (TDD vs vibe or legacy app vs next app).
I don’t do these all the time, and they don’t guarantee ROI, but it keeps me focused on one thing to completion intend of getting distracted
I've never been surfing the web as much as now. I get sidetracked really often, I forget that a prompt was running, I lose trains of thought. It's horrible.
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.
Just give it a zillion linters - including ones you wrote yourself - and make it write its own tests (red/green) so it doesn’t need to stop until it’s made working software with nothing dumb in it.
Then get into a flow state when you write your weekly update emails and respond to customers.
It's hard as yet for me to feel skilled in interacting with AI agents when coding, and the challenges I face are more interaction with agents, and less around the object of the coding.
I use the trust but verify method. Build in snippets, review what AI spits out and chive on if it meets my satisfaction. I cannot blindly write something with AI and utilize it.
Keeping build in steps keeps me as well as AI focused.
I don’t, nor I want to. If I’m forced to train my replacement by using these tools, I might as well enjoy the time it takes the agent to do work by doing something I like and enjoy in the meantime.
I've just started up a new gig where I'm swearing off any agents, I'm even not looking up answers with an LLM. There's nothing so crazy I'm doing SO still doesn't have the answer.
So far, I'm having a great time. I'm progressing quickly, understanding the domain better.
I'm also finishing an older job at the moment, which has been almost 100 percent agent-driven. Real brain-dead drudge work, there's no flow to get into with these things. I'm not sure it's been any quicker than the old-fashioned way. Certainly a lot less fun.
You accept that what made this career rewarding (besides money) is gone and pick up a hobby that gets you into flow state. That's why I've picked up drawing again :)
Flow comes from continuous engagement with the problem. Agentic coding often turns programming into project management.
The more time I spend waiting for an AI to think, the less flow I experience. Fast autocomplete-style AI boosts flow. Slow autonomous agents usually break it.
My workaround is to stay in the loop: AI handles the typing, I handle the thinking.
Could you not just, you know, not use Claude? Or if you must, delegate some tasks to the agent and go work on something yourself, the agent doesn't mind waiting for you to get back.
That's likely the optimal approach but I think a lot of employers are mandating usage amounts especially with the PE firms making deals for user committal in exchange for cash from Anthropic and folks.
How do you get in the flow state while waiting for a junior dev to submit their changes that you will have to spend the rest of the day reviewing? You don't, you get annoyed the rest of the day is going to suck.
I code by hand asking AI specific questions via emacs gptel and claude-code-ide. The ai works in the background as I write. When the answer is complete I context switch back
When I'm running for exercise, my brain is telling me to stop running, would it be better for me long-term to stop running or continue, regardless of what that pesky voice is telling me?
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.
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.
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.
I recently found llm-buddy (https://github.com/ahyatt/llm-buddy) which might be a good fit.
Llm-buddy is an “Emacs package that watches your recent buffer edits and asks an LLM to review them. When it finds something worth pointing out, it can add a short inline note in the relevant buffer or show a message in a popup buffer (it usually does the former).
The goal is lightweight feedback while you work: typos, logic mistakes, questionable edits, or prose issues that a normal compiler, linter, or spell checker may not catch.”
This is a UI/UX problem, no? While the current suppliers are mostly locked in the ‘chat for everything’ mode. Guess what, we didn’t go to the moon in chat mode, we don’t drive cars via chat and cyborgs don’t play chess that way. Domain specific interfaces are the way to go (opinion).
Edit with an example: Read some interesting science news yesterday regarding man made risk of high water (Nature). Mailed the author, found the article (popular news doesn’t do attribution) and data and code was open source. Claude Fable had it running very fast and explained the things I forgot from high school. Started on localization and adding some methods from my background (econometrics, extreme value theory). All nice in the /hobby/ way. I can overlap fields in hours now. A brilliant feeling (but probably not brilliant).
What I cannot do is assess the value and novelty of the created work on my own. So I still need to have a set of geologists and econometricians / actuaries work through ‘my work’. That’s what we need tools for! We need UI/UX in this case for novel fields interacting with quality controls made easy. I currently wouldn’t dare ask the author for her time based on my slop. And I cannot critically assess what I’ve made. I only learned today that Greenlands ice attracts water, that Manila and other cities are sinking due to exhaustion of their aquafiers and that the North Sea is surge heavy and unique that way.
I think "without being obtrusive" is a key point here, because any type of popups in the midst of working would break flow as well. Fixing compiler warnings is flow-inducing because it's very linear and has a fast feedback loop, so it would have to be something akin to that.
Side-note, I wonder if audio cues would work well here. When another person is commenting on something, we as humans can typically remember their point while still being focused on text, but if a popup with text comes up we usually get distracted by it. Just my two cents.
I've found AI code reviews as a first pass on PRs to be quite non-obstructive to my workflow and the AI code reviewer (while not instantaneous) is certainly faster on a response than the human pass will be.
> 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.
*You dont*
Skill issue, not a universal 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.
Oh they'll grow, but mostly to the benefit of someone else.
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.
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.
Never, has made my programming joyless and boring. If it wasn't a requirement to keep my job I'd never touch it.
(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.
I can't believe "prioritise context switching" is now advice being doled out on HN.
Agents allow for delegation, that’s something we aren’t used to as devs. But it’s very useful.
It’s why the execs get so excited about these tools: they understand how to delegate.
I still do deep work, but I actually enjoy a session bouncing between agents. And I can chose how much focus to give each tasks.
Be real, most of that flow state was typing boilerplate
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.
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.
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.
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.
same as before.
i am solving a problem, so i think (keyword) about how im doing to do that.
then i lay that out for the LLM. i have a bunch of documentation and todos etc.
i manage that and then orchestrate the ai to implement what ive asked it to do.
it is really fun!
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.
You can't, "agents" and "agentic coding" are incompatible with the deep understanding of your code that getting into the flow state requires. By definition, prompting a tool to do your job for you means giving up the depth of control that comes with actually writing the code.
Some people can work like that, some very few people may even produce acceptable results like that. I cannot and I am not interested in doing so.
The closest you can get to agentic coding while still actually being in the control loop is something like intellisense - where it just fills out the implementation of small chunks of code, one block at a time and only when you specifically request it.
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...
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
> 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.
When you're deep thinking you have a constant information inflow that's coming from your own thoughts. This is different from relying on an exterior tool because in that scenario your brain is blocked from thinking by relying on that tool giving it a breather to wander off a garden path. That isn't necessarily a bad thing (it's nice to give your brain a stare off into the distance break every once in a while) but if you've adapted your thinking and working style to the constant inflow and outflow of information it can be highly disruptive.
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.
[1] https://x.com/OortCloudAtlas/status/2062208343192769004
Interesting. I still don't get what that means. Ironically, he suggests you just watch his YouTube.
Not sure what the OP or the person in the videos means but a direct, fast way I have found to “drop in” is to stop thinking and intensify my awareness of everything. Takes about 5-10 seconds to transition into a nonthinking timeless presence.
Attention is on the full body, and the field of perception, then field of awareness, all at the same time.
A bit like shavasana practice, but instead of scanning part by part, expand presence to everything.
The thinking analytical mind stops, the nonthinking mind activates and softly intensifies.
Yes this would be one “provisional” method among many, maybe hundreds of techniques but they all seem to lead to the same place as one gets familiar. In Buddhist Vajrayana schools this is called “non-meditation”. The ultimate instruction is to simply do nothing, but this requires a bit of initiation (and paradoxically, concentration) to get right.
Michael Taft has many different guided approaches to this on his channel but there are many other teachers as well, e.g. Adyashanti, Angelo Dillulo, Loch Kelly, Shinzen Young (specifically his Do Nothing and Auto Focus techniques) and expanding the gamut to traditional Vajrayana teachers, Lama Lena, Mingyur Rinpoche, Lama Dawai Gocha, all with accessible online teachings. Also Sayadaw U Tejaniya and Christopher Wallis who are less conventional, so to speak.
Not familiar with the infinite gamut of techniques, and yes sounds right.
It is possible, there are many ways, some people are curious about this state and lean into it, most are not. Who does, or doesn’t, and when, in my experience, is matter of grace. So no need to worry about it.
I see it as something that happens to me rather than caused by willpower. Much like a memory or a flashback that then transports you.
That's also my experience. It's absolutely a letting go rather than a doing; one of Michael Taft's analogies for it is "dropping the ball".
The provisional techniques are great because different techniques click for different people. Once they've seen what it is, it's easier to drop in more directly. If there's any willpower involved, it's more a subtle dropping of discursive mental commentary (especially on the process itself: I've got it - almost there - why can't I get there today - ah so this is what works, etc).
Once you're there, it feels like the most familiar and comfortable place in the world. As one of my teachers said, this is real rest.
don't forget the love :)
The feeling of gentle content / blissful love emerges automatically as the grip of thinking convulsions releases the body.
It’s direct, effortless, always available, takes no time.
Easily done in any situation of passivity including meetings. Recommended during stand ups ;)
There's an XKCD for that, "Compiling" : https://xkcd.com/303/
The difference is your boss isn’t going to fire the middleman so he can talk straight to the compiler
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 :)
Usually take mushrooms or gummies and see what happens.
This isn't even troll post. AI has killed the ability to reach flow for me, but I basically have to use it at work so <shrug>. But if I'm WFH or at night, a little help helps me stay focused and connected to my work, sometimes even with AI. Does my mind drift? sure. But that's as close as I get to flow now.
Instead of context switching to a different worktree, contemplate on next steps of the same problem. This keeps you in the loop.
I can not fathom context switching between multiple worktrees so that the PM can make JIRA graph look better.
Do not wait for replies, try to structure your workflow so that you are always either refining requirements for the future tasks that you are going to to give to the agent later or reviewing (sometimes also manually testing) the code that the agent has produced before.
I think that this is mostly a UI problem. Chat UI is just not a good UI for programming and the fact that the current "AI"-coding sphere has converged on it is incredibly silly.
One of of the first things that I did when I first seriously tried an LLM-based coding agent is making an ad-hoc task manager on skills and simple daemons.
So that I can interact with it using files instead of this stupid workflow of typing a prompt into the console and then just doing nothing while waiting for the response.
There is absolutely no reason not to do it asynchronously.
For working on a single project, I have a text document open where I’m working on future prompts. For working on tasks in a team setting, with prs and reviews, i built a tui that manages multiple tmux sessions. It creates a worktree for each task. It has status indicators for each session, hotkeys to quickly cycle through them, hotkeys to pull, annotate and paste pr comments, pull, annotate and paste linear tasks and comments, hotkeys to launch external tools and to jump directly to the pr url, and any time there’s a period when all the dots are busy i just start a new task. It’s a bit manic, but it’s manageable because it’s all in one terminal window. It’s also for AI as it existed 3 months ago, work slowed down and i haven’t tried to apply loops or whatever the latest crazy thing is.
Indeed, the code generated by AI is very poorly readable. After a while, I gave up reading the code! I feel like my coding ability has been reduced, and I don’t know if this is a good thing. I used to work hard on coding, but now I feel more and more like a product manager.
A couple of things to consider:
Start with a set of work that's well specified and reasonably chunked to sizes that make it so that the review parts fit in the gaps of the working chunk and interleave (1-4 tasks of this). While the agent is working on the A task, you're reading the B task, only add a 3rd task if you're waiting on the agent excessively. Give yourself some slack on this to think about side quests (maintenance / tech debt / planning future work to your system etc.)
Make sure the handoffs are reasonably detailed (prompts / AGENTS.md instructions) - make your agents provide more context than normal - make them assume that you don't read all the text they spit out and need to be handed succinct summaries with information that helps reduce cognitive burdens (what I was doing, how I did it, what's next etc.)
It's reasonable to regularly ask the agent what things you've worked on choices made, options considered and discarded, context rehydrating. There's a lot of small tweaks you do when interactive prompting that get lost in a drift rather than captured as a neat single list. Make the agent help track that stuff. (at least prior to shipping, but often in intermediate steps.
Write flows that keep software in a buildable state so you can run it and queue up changes based on what you see. Avoid long periods of broken refactoring (caller code written before callee, deletion before add in a move etc.) Run quick checks (e.g. rust's cargo check) after each change, not at the end.
Correction of agent errors should end up as future steering. If the agent makes a mistake once it's the agents fault, twice it's your fault.
Leave time to stop and evaluate the current state regularly (where are we on the work). It's easy to mistake momentum for progress when you're the human part of an agentic loop.
While I don't have the answer, I will leave my thoughts here, maybe my comment helps you or some of the responses might...
I was thinking about this when I tried a faster model (Cursor released something fast about a month ago?). It was such a joy to use (well, at least compared to other models, where you wait 5-10 mins for even simpler tasks), and I noticed I felt much closer to the problems, and I got closer to a "flow" state... ...but unfortunately, the models are faster for a reason, and the output got worse. While I did enjoy my job more, I was also left worried that the model missed important things (and it did when cross referenced with other models or just doing the thinking myself).
IMO we need much faster yet capable models to bring back a bit of a flow state.
Another approach worth trying is to get some agents researching 4-5 tasks thoroughly in the background, discovering all the relevant details, collecting all the files likely to be edited, their content etc..., then work on one thing at a time with a better focus for yourself, maybe use a faster model.
One thing I try to do is code manually if I know that I can be faster and better. It's convenient to stick to one tool, the agents, when editing code, but for smaller clean up tasks, they just never get it right, and sometimes it's better to do 1 min manual work over 5 mins of explaining what you want and the agents still not delivering it...
Yes, and I'm hoping we get there soon. I do much better locked in and focused on one thing. I HATE multitasking. I feel like using AI is:
a) making me not think at all
b) giving me weird adhd brain (I never struggled before with this)
I like to bounce around between a few different things at once.
Normally, I work on my core work plus something tangentially related (e.g. 20% projects). The 20% projects keep my attention while the core work is LLM'ing.
As a Staff level engineer, a large part of my job is taking interruptions from others. I also do a lot of code reviews, design meetings and the like. Which is to say I have only rarely been in the flow anyway. I just more/better code written these days just because the AI can be in the flow while I'm answer those things. However I have even more code to review because the AI needs constant "this is a bad design" prompts.
It is hard. Much harder than regular software work. A few things need to line up: model iteration speed, task chunk size, and your own context window and comprehension abilities. Too slow and you lose interest. Too easy and it's just tedious riffing. Too large and you're burned out by reviewing giant complicated walls of text. Etc. The bites have to be the right size and speed for both you and the LLM.
In the few instances I've been able to achieve really joyful flow state, there are usually two simultaneous workstreams, plus or minus one. They're usually working towards a large goal that I roughly know how to judge, in digestible bites.
For example, sequentially modifying the UI in a series of operations towards an overarching goal, where it's easy to tell if a step worked, and what the next step should be, but where you're not sure exactly what you want, so there's some curiosity and discovery rather than just feeding the bot tiny instructions. I try to keep the two workstreams from overlapping. If both streams start fighting over a file they both dirty, things go south fast.
Adjusting your prefs/harness/etc for model terseness goes a LONG way. Context quality is absolutely everything. A good context "seed" can go back and forth for many turns cleanly and with focus, and even compact successfully once or twice. A bad seed will be annoying to work with from the jump, will thrash towards compaction faster, at which point it gets even worse. This is difficult to troubleshoot objectively, but I'll frequently restart conversations if I don't like the vibe of the first couple turns. It's made harder by constant model churn. Until opus 4.8, I ran opus/sonnet 4.5 high for a long time in large part for continuity of intuition, if that makes sense.
There are also many elements of human knowledge management that make a difference. I've found "append only" to be a magic word, generating markdown logs of changes, or learnings, etc. Whatever workflows create visibility and resumability so that you can return from a spell away and get up to speed effectively. Manually keeping your own dev log alongside the session sometimes helps, makes things sticky and ensures you understand what's happening.
But it's hard. Feels incredible when it goes well, but going well feels very nearly random, and whittling towards reproducibility can be very mentally draining, in terms of both energy and morale.
You need to saturate your attention span with running so many agents at once that when you issue the last prompt to the last agent, the first one is already finished. This way you need to continuously concentrate, so flow is achievable.
The difficulty is to break down the task in a way that multiple agents can work on it.
I usually spin two or three major issues with 10-12 agents in total.
I have converged on a workflow that is just what I was doing before, but use LLMs just for boring or tedios parts. General guidelines are: only single agent at a time, small targeted queries, understand what you are building, if something would seem like a fun task, do it yourself. I use LLMs for bug hunting, to trace the flow, to build quick visualizatios (paste csv, ask to generate visualization), to search in the code of the dependencies using github mcp, to write 100 line scripts (deno + ts + zx was a game changer for me). Even "dumber" opensource models are good for this kind workflow, more tokens per second is generally more benefitial than plain intelligence. I would use LLMs more or less, sometimes even full vibecoding if the task is something like quick tooling web app and the flow is just firing of the next LLM query every 30 seconds. But, depending on the type of task or domain that you work in, YMMV
im finding it way way more "flowy" than pre-ai. all the boring trivia is gone, i can focus on what i actually care about - the shape of what i am building, tradeoffs, second- and third-order consequences of decisions.
the trick to get it uninterrupted is "selective multitasking". i don't like having too many Claudes / Codexes in parallel on auto-pilot; this way im finding i'm getting _something_ that is perfectly plausible, but rarely what i wanted. but I have N going at any given time, just enough to be basically non-stop reading. problems need to be related; within one project, ideally adjacent areas that are complementary. then my "flow" is just switching between reading and typing non-stop. never felt time flying by faster in my life, pure flow
also forgot to mention that 90% of the work (and time) is bouncing markdown files back and forth until the design is clear and I feel happy about it. design docs, working docs, etc. implementing then is where I can engage way less and switch to a different tab in cmux to drive it
I reach the same flow state by multitasking across multiple tasks in multiple repos. I can hold my own context across 5-10 different terminal tabs each running their own Claude code or pi. Watching Claude especially with sub agents is like watching paint dry.
Since I built my own dev tool to allow me to better organize and manage multiple sessions, I've found my flow state hits when I've got agents staggering to completion. Conversation with one, wrap it up, send my response, and another one finishes. I currently have 49 agent sessions open in atrium and when I'm grinding, 5-15 are going at a time. If I get em all onto longer horizon tasks, I start to comb through other sessions to pick up parked conversations.
I try and make very small and deterministic steps. I do the planning (in flow state) and let the model to the execution. When the model is executing, I follow the "thinking" and keep seeing the diff like I would when I was coding.
I never really got into flow state from planning. Too much brain power, dead ends, etc. I reached flow state from the "busy work." Knowing what needed to be built and implementing it.
Welcome to management!!!
lol, it is funny,but sadly is partly true...
I think if you find that your coding style is disrupting your productivity or job satisfaction then you're misapplying the tool to your particular working style. We're all different in how we approach problems and tools should support our preferred approach (assuming that approach isn't unacceptable from a working performance perspective which, to defeat your imposter syndrome, I absolutely guarantee you isn't the case if your performance hasn't majorly shifted since the introduction of AI).
I've actually embraced the asynchronous element of AI programming in my personal projects.
Playing Star Citizen? There's pockets of 5 minutes all over the place traveling from A to B. I keep my laptop nearby and have a prepared todo list of items to work through. Those moments wasted on Reddit are now moments wasted on feature experiments!
Waiting for a cup of tea? Run an experiment. Waiting on wife? Run an experiment.
Piece by piece an app is coming together built from 5 minute increments of reclaimed time.
What has worked for me…
Pair programming. I call it pilot / copilot / autopilot. Two real people plus one or two agents working together. Classic XP stuff, the copilot can help remind what we are focusing on, file follow up issues, give instant code reviews.
Bake offs. Do the same task but in two different chats or agents or approaches (TDD vs vibe or legacy app vs next app).
I don’t do these all the time, and they don’t guarantee ROI, but it keeps me focused on one thing to completion intend of getting distracted
I've never been surfing the web as much as now. I get sidetracked really often, I forget that a prompt was running, I lose trains of thought. It's horrible.
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.
This is multi-tasking and the opposite of "deep focus".
It's interesting that the guy providing an actual answer gets downvoted, and everyone saying "it's impossible" got upvoted.
In my experience switching contexts breaks flow
I don't believe that multi tasking and flow can happen at the same time
What works for me is:
- Use a fast model like DeepSeek Flash V4 on high (it's Sonnet level, but fast and cheap).
- While the LLM is working, start writting your next prompt. A good prompt usually takes between 1 and 10 minutes to write anyway.
Doing this should keep you busy enough to never leave flow.
But it is intense and demanding when the LLM is fast, I'll tell you that.
How does that work if you depend on the output of the first prompt?
I write prompt for another feature or fix.
Why would you try?
Just give it a zillion linters - including ones you wrote yourself - and make it write its own tests (red/green) so it doesn’t need to stop until it’s made working software with nothing dumb in it.
Then get into a flow state when you write your weekly update emails and respond to customers.
I do 3-4 things at the same time, and in between waiting periods, keep pushing on something else.
It's more taxing because I'm switching problems but at least these are all libraries within the same ecosystem so eventually, they line up.
I've half-joked a few times that ADHD with hyperfocus is a perk in this agentic coding era.
ctrl-f Csikszentmihalyi ... nothing.
Flow = high talent/skill + high challenge
It's hard as yet for me to feel skilled in interacting with AI agents when coding, and the challenges I face are more interaction with agents, and less around the object of the coding.
Today I fall more into:
Anxiety (high challenge level, low skill level) Arousal (high challenge level, medium skill level)
I know it isn't the original flow state but I get lost in conversations with Claude even when slow.
I have a couple of terminals open and work on at max 3 things.
A main task, an exploration task and another prompt/skill improvement or documenting an issue (or a proposal)
I use the trust but verify method. Build in snippets, review what AI spits out and chive on if it meets my satisfaction. I cannot blindly write something with AI and utilize it.
Keeping build in steps keeps me as well as AI focused.
The planning part is the flow state now. Coding is done by AI while I eat and set the domain vision
Open 16 windows, that's the flow state, non-stop bot mode.
I don’t, nor I want to. If I’m forced to train my replacement by using these tools, I might as well enjoy the time it takes the agent to do work by doing something I like and enjoy in the meantime.
My experience has been that I can't.
I've just started up a new gig where I'm swearing off any agents, I'm even not looking up answers with an LLM. There's nothing so crazy I'm doing SO still doesn't have the answer.
So far, I'm having a great time. I'm progressing quickly, understanding the domain better.
I'm also finishing an older job at the moment, which has been almost 100 percent agent-driven. Real brain-dead drudge work, there's no flow to get into with these things. I'm not sure it's been any quicker than the old-fashioned way. Certainly a lot less fun.
You accept that what made this career rewarding (besides money) is gone and pick up a hobby that gets you into flow state. That's why I've picked up drawing again :)
Use composer 2.5 fast in cursor (or cursor cli).
YMMW but I find it fast enough to maintain focus on one task (if that's what you're going for given a particular problem
I tried, but I just found it not smart enough. I do love how fast it is though.
Built my own orchestration layer, to allow me to optimize the one thing that is most precious when working with AI. My attention and my time.
I just work on multiple projects at the same time. This way, the time it takes for one prompt to complete does not disturb my productivity
Flow comes from continuous engagement with the problem. Agentic coding often turns programming into project management.
The more time I spend waiting for an AI to think, the less flow I experience. Fast autocomplete-style AI boosts flow. Slow autonomous agents usually break it.
My workaround is to stay in the loop: AI handles the typing, I handle the thinking.
It feels like constant stop and go traffic, even with multiple agents.
Never. It is like babysitting a special needs child while trying to accomplish actual work.
at least four entirely separate trains of though works for me!
git worktrees and sidequests
I don't think you can. The joy is gone. But that also makes me wonder, what other careers had a "flow state"? Maybe art?
step away from the computer while it’s working
Could you not just, you know, not use Claude? Or if you must, delegate some tasks to the agent and go work on something yourself, the agent doesn't mind waiting for you to get back.
That's likely the optimal approach but I think a lot of employers are mandating usage amounts especially with the PE firms making deals for user committal in exchange for cash from Anthropic and folks.
How do you get in the flow state while waiting for a junior dev to submit their changes that you will have to spend the rest of the day reviewing? You don't, you get annoyed the rest of the day is going to suck.
I code by hand asking AI specific questions via emacs gptel and claude-code-ide. The ai works in the background as I write. When the answer is complete I context switch back
Keeping an IDEAS.md or SCRATCH.md, which I work on while reviewing changes / code / docs, and it is working on other things.
I tend to focus on on project at a time with multiple agents, rather than agents on multiple project, and then time slice myself across projects
Related:
Ask HN: Do you struggle with flow state when using AI assisted coding tools?
https://news.ycombinator.com/item?id=44811457
Do something better with your life. Honestly, not /s. Your brain is trying to tell you something.
When I'm running for exercise, my brain is telling me to stop running, would it be better for me long-term to stop running or continue, regardless of what that pesky voice is telling me?
I don't know, I get runner's high and want to go running again a couple of days later.
try more difficult tasks
mkfs.ext4