Ask HN: Why is my Claude experience so bad? What am I doing wrong?

Also I suggest giving it low-level instructions. Its half-decent for low level stuff especially if it has access to preexisting code. Also note that it does exactly what you tell it to do like a genie. I've asked it to write a func that already exists in the codebase and it wrote a massive chunk of code. It wasn't until after it was done that I remembered we already have the solution to the problem done. Anyhow the hype is unreal so tailor expectations accordingly.

Yes, this is what the hype says doesn't it?

Or... are they all lying?

In my little experience, what I've seen work is that you need to provide a lot of constraints in the form of:

- Scope: Don't build a website, but build a feature (either user facing or infra, it doesn't matter). I've found that chunking my prompts in human-manageable tasks that would take 0.5-1 day, is enough of a scale down.

- Docs .md files that describe how the main parts of the application work, what a component/module/unit of code looks like, what tools&technologies to use (and links to the latest documentation and quickstart pages). You should commit these to code and update them with every code change (which with Claude is just a reminder in each prompt).

- Existing code, if it's not a greenfield project.

It really moves away from the advertised paradigm of one-shot vibe-coding but since the quality of the output is really good these days, this long preparation will give you a production ready output much sooner than with traditional methods.

Like OP, I've been similarly struggling to get as much value from CC (grok et c) as "everyone" else seems to be.

I'm quite curious about the workflow around the spec you link. To me, it looks like quite an extensive amount of work/writing. Comparable or greater than the coding work, by amount, even. Basically trading writing code files for writing .md files. 150 chat sessions is also nothing to sneeze at.

Would you say that the spec work was significantly faster (pure time) than coding up the project would have been? Or perhaps a less taxing cognitive input?

This reminds me of someone who dropped into #java on undernet once upon a time in the 90s. "I can't get it to work" , and we kept trying to debug, and for some reason we kept hitting random new walls. It just never would work! Turns out that they were deleting their .java file and starting over each time. Don't do that.

---

Take it as a sequence of exercises.

Maybe start like this:

Don't use claude code at all to begin with. It's a pair programming exercise, and you start at the keyboard, where you're confident and in control. Have claude open in the web interface alongside, talk through the design with it while working; and ask to google stuff for you, look up the api, maybe ask if it remembers the best way(s) to approach the problem. Once you trust it a bit, maybe ask for code snippets or even entire functions. They can't be 100% correct because it doesn't have context... you might need to paste in some code to begin with. When there's errors, paste them in, maybe you'll get advice.

If you're comfy? Switch seats, start using claude code. Now you're telling claude what to do. And you can still ask the same questions you were asking before. But now you don't need to paste into the web interface anymore, and the AI sure as heck can type faster than you can.

Aren't you getting tired of every iteration where you're telling the AI "this went wrong", " that went wrong"? Maybe make sure there's a way for the AI to test stuff itself, so it can iterate a few cycles automatically. Your LLM can iterate through troubleshooting steps faster than you can type the first one. Still... keep an eye on it.

And, really that's about where I am now.