If you know the feeling from performance or from trance-like coding sessions, there's no mapping of that to the use of agents as described in this article. It's not that I don't achieve it, it's that using agents doesn't have the depth of technique or immediacy of reaction needed to be worthy of anyone reaching a proper flow state with it.
I feel like we've already corrupted the meaning of vibe now, do we have to corrupt the meaning of flow state too?
https://github.com/williamcotton/webpipe
And a work in progress article about it:
I’m 16 years into my career, build some fairly complex production systems, and definitely enjoyed flow state in normal coding. I’m still figuring out a rhythm with Claude Code, but flow state is certainly achievable.
I think this is a problem with the current agents, though. If it responded immediately with its ideas and code then I wouldn't flip away and could stay present.
> flip over to something else
A flow state is possible with 100% focus at any level of abstraction.
If you just "flip over" to HN while the agent thinks, then you're not 100% focused.
But if you're managing three agents at the same time on the same codebase, and while Agent 2 is thinking you "flip over" to Agent 3, you're still fully participating, just at a higher level of abstraction.
Doe-eyed self-reporting is not credible.
Interesting also that so few people on Hacker News value testing.
s/(agentic|llm|vibe) coding/outsourcing/g
To give a relatable analogy, it's like how it's hard to hit a flow when working with compiled languages and where you're far enough you have to start compiling. If it is a fast compile, there's no time to get into the state (think like when you're a dumb junior print statement debugging C++ code as your only weapon). If it is long and for some reason you can't do incremental building then you might be able to do something like reviewing other areas, reading docs, writing docs, working on the call graph structure, or something else. Usually I can stay in flow here (but never when print statement debugging!). The medium time might be the worst. Sometimes there's a magic sweet spot but too often it makes distractions easy. You know you don't have enough time to do anything serious but it's too much time to just watch.
The extra burden I have with the LLMs is that it's kinda like working with someone but not. Working with a person we can formulate the design and get a good understanding of what things should look like, we start planning for edge cases and challenge ourselves to make sure we have the right model. We then go program our parts, meet back up, and debrief. Things will change but it'll have a similar structure. When this happens we both have a fairly good understanding of everything. But with the LLM, I have to be extra vigilant. It will lie to me, it makes mistakes that are difficult to find or notice (just because it compiles and just because it runs doesn't mean it's right... only very junior programmers think that), and most importantly, it doesn't have a good model of the program.
I expect a lot of people will push back on that last one. You can give it all the lines of code, you can even talk to it and explain, but it still won't get that good world model. FFS we program because natural language is so messy[0]. It's not trying to interpret what I mean, finding out what I want, but just follows directions. It doesn't innovate on its own (though it can draw from some similar sources [1]). Like the terminal, it doesn't second guess and just goes along with it. Worse, it does do cheery faced, praising you all along the way while it lies about what it did. If a human did that we'd call them evil. I won't call them evil because a machine is a machine, it has no desires and isn't intending to lie.
They work fine for small stuff, Repetitive things, or even when you're rapid testing, but that's a very small portion of coding. I can't rely on it to do anything serious. But many of these things can be handled in other ways. Is the repetitive work? You're a programmer, anything repetitive can be resolved with classic automation.
Worst of all, agents take away the most enjoyable part of coding and leave me with the worst part. I'd rather debug my code than someone else's. Debugging my own code is not fun, debugging a junior's code is exhausting
[0] https://www.cs.utexas.edu/~EWD/transcriptions/EWD06xx/EWD667...
[1] That is not so much the impressiveness of the machine but more the lack of impressiveness of myself
Even doing small functions with vscode copilot, possibly due the lack or quantity of, the context in passing it seems to be very poorly understood - and loses either the big picture, or the details. That is if I give it - > a high level task, it leaves things like unauthenticated endpoints, end to end flow that's vaguely right but broken at various steps, fails to utilise existing code and creates duplication/spaghetti, etc > a specific 'make this function" request, it fails to appreciate the overall situation of that function and how it needs to interact with the codebase, which builds what feels like inflexibility when trying to iterate or immediately-felt tech debt.
Note, I haven't found a way to do purely "agentic coding" in vscode with copilot.
aswegs8•6mo ago