Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Don't Wait for Claude

jeapostrophe.github.io

Post reply on HN
Print view View original

51–60 of 67 posts

Re: Don't Wait for Claude

#51

Post by jeapostrophe »

pllbnk wrote: post #40

I don't know how and if people really manage to run many tasks in parallel and also not check the output. Very recently I had two items that for a reasonably intelligent engineer wouldn't be very complex, but would take time to implement. One of them was vibe-coding an Electron app for myself that was running a Llama server. Claude couldn't find out why it wasn't running on Windows while it worked fine on Linux and M…

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.

Re: Don't Wait for Claude

#52

Post by jeapostrophe »

trjordan wrote: post #8

I'd offer a different approach: think about how you're going to validate. An only-slightly-paraphrased Claude conversation I had yesterday: > me: I want our agent to know how to invoke skills. > Claude: [...] > Claude: Done. That's the whole change. No MCP config, no new env vars, no caller changes needed. > me: ok, test it. > Claude: This is a big undertaking. That's the hard part, right? Maybe Claude will come back…

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.

Re: Don't Wait for Claude

#54

Post by jeapostrophe »

flakiness wrote: post #15

The old saying is "don't multitask" but apparently that time is gone. I wonder what people think about this. I know there is a class of SWE/dev who now consider oneself as "the manager of agents". Good luck to them and articles like this would work for these people. I'm not there yet and I hope I don't have to. I'm not a LLM and my mental model is (I believe) more than a markdown. But I haven't figured out the mental…

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.

Re: Don't Wait for Claude

#55

Post by jeapostrophe »

joshgachnang wrote: post #27

This looks absolutely wonderful. Is it possible to run against Claude remotely (e.g. on a VM?). Or should I ask Claude to add that?

Ask Claude ;) Right now it is hard-coded to run `claude --resume ` 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.

Re: Don't Wait for Claude

#56

Post by jeapostrophe »

satisfice wrote: post #45

For every single post of this type: please stop writing as if you know that any of this works well. You don’t know! You are experimenting, speculating, and excited to share. That’s fine. What’s not okay is presenting a false impression that you have deep experience and did sufficient experimentation and that you know the risks and have experienced the problems associated with your wonderful idea. This takes time. I w…

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

Re: Don't Wait for Claude

#57

Post by jeapostrophe »

cruffle_duffle wrote: post #37

This advice will be very dated when inference gets an order of magnitude faster. And it will happen—it’s classic tech. Probably will even follow moores law or something. Wait until that 8 minute inference is only a handful of seconds and that is when things get real wild and crazy. Because if the time inference takes isn’t a bottleneck… then iteration is cheap.

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.

Re: Don't Wait for Claude

#59

Post by satisfice »

fragmede wrote: post #49
satisfice wrote: post #46

Earlier quoted context omitted.

Yes, I want to see the prompts. Yes. But I won’t promise to read it, because it’s bad writing. So maybe it would be better to not use the LLM to draft writing that pretends to be you. That would be easier on everyone who reads. Instead we live in a world where all of us are reading through a cynical lens. This comment was written without using any form of AI.

Was this written by an LLM? > This comment was written without using any form of AI. That's exactly what ChatGPT would write if it didn't want us to think it wrote that comment!

In this ever-changing world, it pays to delve beneath the surface of a casual claim— if you know what I mean.

Re: Don't Wait for Claude

#60

Post by btown »

bwestergard wrote: post #26
samename wrote: post #13

Earlier quoted context omitted.

Why should Claude finish complex tasks in less than seven minutes?

The need for "complex tasks" should be exceptional enough that you're not building your workflow around them. A good example of such an exception would be kickstarting a port of a project for which you have a great test suite from one language to another. This is rare in most professional settings.

I wholeheartedly disagree with this. For any iteration, Claude should be reading your codebase, reading hundreds of thousands of tokens of (anonymized) production data, asking itself questions about backwards compatibility that goes beyond existing test suites, running scripts and CI to test that backwards compatibility, running a full-stack dev server and Chrome instance to QA that change, across multiple real-world examples.

And if you're building a feature that will call AI at runtime, you'll be iterating on multiple versions of a prompt that will be used at runtime, each of which adds token generation to each round of this.

In practice on anything other than a greenfield project, if you're asking for meaningful features in complex systems, you'll be at that 10 minute mark or more. But you've also meaningfully reduced time-to-review, because it's doing all that QA, and can provide executive summaries of what it finds. So multitasking actually works.

Post reply on HN