jeapostrophe

I agree that it is very exhausting

Yea, I think it will be totally useless to switch at that level and instead it will be about reviewing the work more effectively. I think I would believe in the more "autonomous Claude" systems in that world.

I agree. This is what has worked for the past few weeks and I want to share. Maybe I will regret my life choices. If I'm still doing it next year, that will be something different to say. But I want to try to help and share before I really know. <3

Ask Claude ;) Right now it is hard-coded to run `claude --resume <uuid>` but there's a natural abstraction to use a different script to start the Claude session.

If you're being sarcastic, I love you anyways.

Whether multi-tasking is good or bad, I think that if you're "waiting for Claude" at all, you're going to be multi-tasking or staring into space. I try to stare into space when I'm pumping gas, but I don't want to do that when I'm "working" at my laptop... in part because I know I'd be more likely to check my email or HN.

LOTs of key bindings.

Amen. Making the checking painless and easy to do is a major boon. There's a spectrum of "checking is easy": the compiler telling you the code doesn't compile is the easiest, but doesn't capture "is this the program I want". Some checks like that are inherently not mechanically checkable and some sort of written "testing protocol" is necessary.

My personal experience matches this. When I'm "succeeding", I am at the 5-to-7 minute cycle time and when I (or Claude) are failing, there's constant attention and no ability to switch away.

My human programming experience is encouraging me to keep going on the debugging, like I did when it was my code that I invested a lot of time and energy into.

Now that the code is cheap, I am trying to "learn" to throw away everything, go back to a stable checkpoint, and try a different approach that is more likely to succeed. (Probably having the new plan incorporate the insights I gained the first round.)

It is hard to do that when you coded for a week (or even a weekend) but it should be much easier when you got it faster with Claude. I think people (me at least) need to learn new norms.

I've gone through a bunch of different processes learning how to use Claude.

Giving it large tasks that take 40 minutes basically always fails for me. Giving it small tasks that take 30s to a minute feels like it is my typist and not a worker. I find that I am happiest and most effective at the 5 to 7 minute cycle timeframe.

I disagree. My workflow is built around reviewing what it produces and trying to build a process where it is effective to do that. I definitely can't and don't watch edits as they go by because it is too fast, but I want to easily review every line of code. If you're not "reviewing afterwards", then when would you be reviewing?

As far as planning the next steps, that's definitely a valuable thing and often times I find myself spending many cycles working on a plan and then executing it, reviewing code as I go. I tend to have a plan-cycle and a code-cycle going on at the same time in different projects. They are reactive/reviewing in different ways.

My tool supports doing many, but I find it hard to use it for much more than 3 or 4 concurrent projects. I've tried more than that open and I fail. I find that 3 project with 2 or 3 concurrent tasks at the same time works best for me. But I think I'm learning.

The issues you mention are all alleviated by the stateless continuations which do not store state on the server and allow various ways of closing off the session from simply having the URL.

The documentation discusses the features of the Web framework, many of which have to do with its unique aspects. As you can see in this post, all normal Web programming is possible and easy, but there's very little special to say about it, because it's just a normal program.