7 ms·

Weirdly enough I have the opposite experience where it will take several minutes to do something, then I go in and debug for a while because the app has become

Weirdly enough I have the opposite experience where it will take several minutes to do something, then I go in and debug for a while because the app has become fubar, then finally realize it did the whole thing incorrectly and throw it all away. And I reach for Claude quite a bit because if it worked as well for me like everyone here says, that would be amazing. But at best it’ll get a bunch of boilerplate done after some manual debugging, at worst I spend an hour and some amount of tokens on a total dead end

jm4 1y ago
You can tell Claude to verify its work. I’m using it for data analysis tasks and I always have it check the raw data for accuracy. It was a whole different ballgame when I started doing that. Clear instructions go a long way, asking it to review work, asking it to debug problems, etc. definitely helps.
- vunderba 1y ago
  > You can tell Claude to verify its work Definitely - with ONE pretty big callout. This only works when a clear and quantifiable rubric for verification can be expressed. Case in point, I put Claude Code to work on a simple react website that needed a "Refresh button" and walked away. When I came back, the button was there, and it had used a combination of MCP playwright + screenshots to roughly verify it was working. The problem was that it decided to "draw" a circular arrow refresh icon and the arrow at the end of the semicircle was facing towards the circle centroid. Anyone (even a layman) would take one look at it and realize it looked ridiculous, but Claude couldn't tell even when I took the time to manually paste a screenshot asking if it saw any issues. While it would also be unreasonable to expect a junior engineer to hand-write the coordinates for a refresh icon in SVG - they would never even attempt to do that in the first place realizing it would be far simpler to find one from Lucide, Font Awesome, emojis, etc.
  - deleted 1y ago
    [deleted]
  - DrewADesign 1y ago
    In general, using your own symbol forms for interactions rather than taking advantage of people’s existing mental models is a bad idea. Even straying from known libraries is shaky unless you’re a competent enough designer to understand what specific parts of a visual symbol signify that specific idea/action, and to whom. From a usability perspective, you’re much better off not using a symbol at all than using the wrong one.
- yakz 1y ago
  I second this and would add that you really need an automated way to do it. For coding, automated test suites go a long way toward catching boneheaded edits. It will understand the error messages from the failed tests and fix the mistakes more or less by itself. But for other tasks like generating reports, I ask it to write little tools to reformat data with a schema definition, perform calculations, or do other things that are fairly easy to then double-check with tests that produce errors that it can work with. Having it "do math in its head" is just begging for disaster. But, it can easily write a tool to do it correctly.
- bigiain 1y ago
  > Clear instructions go a long way, asking it to review work, asking it to debug problems, etc. definitely helps. That's exactly what I learned. In the early 2000's, from three expensive failed development outsourcing projects.
tcdent 1y ago
This has a lot to do with how you structure your codebase; if you have repeatable patterns that make conventions obvious, it will follow them for the most part. When it drops in something hacky, I use that to verify the functionality is correct and then prompt a refactor to make it follow better conventions.
hnaccount_rng 1y ago
Yeah that is kind of my experience as well. And - according to the friend who highly recommended it - I gave it a task that is "easily within its capabilities". Since I don't think I'm being gaslighted, I suspect it's me using it wrong. But I really can't figure out why. And I'm on my third attempt now..
0x_rs 1y ago
Some great advice I've found that seems to work very well: ask it to keep a succinct journal of all the issues and roadblocks found during the project development, and what was done to resolve or circumvent them. As for avoiding bloating the code base with scatterbrained changes, having a tidy architecture with good separation of concerns helps leading it into working solutions, but you need to actively guide it. For someone that enjoys problem-solving more than actually implementing them, it's very fun.
- taude 1y ago
  to continue on this, I wouldn't let claude or any agent actually create a project structure, i'd guide it in the custom system prompt. and then in each of the folders continue to have specific prompts for what you expect the assets to be coded like, and common behavior, libraries, etc....
  - gonzo41 1y ago
    So you've invented writing out a full business logic spec again. btw, I'm not throwing shade. I personally think upfront design through a large lumbering document is actually a good way to develop stuff. As you either do it upfront, or through endless iterations in sprints for years.
    - bugglebeetle 1y ago
      Yeah, my experience of working with Claude Code is that I’m actually far more conscientious about design. After using it for awhile, you get a good sense of its limits and how you need to break things down and spell thing out to overcome.
    - underdeserver 1y ago
      The problem with waterfall wasn't the full business spec, it was that people wrote the spec once and didn't revise it when reality pushed back.
    - taude 1y ago
      I spent 10 minutes writing out the business logic, you don't have to do it all at once. We're not talking about long complicated things here.
taude 1y ago
do you create the claude.md files at several levels of your folder structure, so you can teach it how to do different things? Configuring these default system prompts is required to get it to work well. I'd definitely watch Boris's intro video below [1] [1] Boris introduction: https://www.youtube.com/watch?v=6eBSHbLKuN0 https://www.youtube.com/watch?v=6eBSHbLKuN0 [2] summary of above video: https://www.nibzard.com/claude-code/ https://www.nibzard.com/claude-code/
- dawnerd 1y ago
  By the time you do all of that you might as well just write code by hand.
  - serf 1y ago
    that's really just a scale question. Yes, I would write a 4 line bash script by myself. But if you're trading a 200 line comprehensive claude.md document for a module that might be 20k LoC? it's a different value proposition.
    - darkwater 1y ago
      And how do you actually know that those 20k line of codes have no glaring bugs, or bugs that you can find yourself, or be able to understand it completely at some point?
      - rovr138 1y ago
        The way I do this is by still writing tests.
        darkwater 1y ago
        Do tests let you understand a codebase you have not written?
        1y ago
libraryofbabel 1y ago
Sigh. As others have commented, over and over again in the last 6 months we've seen discussions on HN with the same basic variation of "Claude Code [or whatever] is amazing" with a reply along the lines of "It doesn't work for me, it just creates a bunch of slop in my codebase." I sympathize with both experiences and have had both. But I think we've reached the point where such posts (both positive and negative) are _completely useless_, unless they're accompanied with a careful summary of at least: * what kind of codebase you were working on (language, tech stack, business domain, size, age, level of cleanliness, number of contributors) * what exactly you were trying to do * how much experience you have with the AI tool * is your tool set up so it can get a feedback loop from changes, e.g. by running tests * how much prompting did you give it; do you have CLAUDE.me files in your codebase and so on. As others pointed out, TFA also has the problem of not being specific about most of this. We are still learning as an industry how to use these tools best. Yes, we know they work really well for some people and others have bad experiences. Let's try and move the discussion beyond that!
- reactordev 1y ago
  Seconded, that a summary description of your problem, codebase, programming dialect in use, should be included whenever a “<Model> didn’t work for me” response.
- dejavucoder 1y ago
  Fair point. For context, I was using Claude Code on a Ruby + Typescript large open source codebase. 50M+ tokens. They had specs and e2e tests so yeah I did have feedback when I was done with a feature - I could run specs and Claude Code could form a loop. I would usually advise it to fix specs one by one. --fail-fast to find errors fast. Prior to Claude Code, I have been using Cursor for an year or so. Sonnet is particularly good at NextJS and Typescript stuff. I also ran this on a medium sized Python codebase and some ML related work too (ranging from langchain to Pytorch lol) I don't do a lot of prompting, just enough to describe my problem clearly. I try my best to identify the relevant context or direct the model to find it fast. I made new claude.md files.
  - 1y ago
wyldfire 1y ago
I have seen both success and failure. It's definitely cool and I like to think of it as another perspective for when I get stuck or confused. When it creates a bunch of useless junk I feel free to discard it and either try again with clearer guidelines (or switch to Opus).
leptons 1y ago
Have you tried vibing harder?
baka367 1y ago
For me it fixed a library compatibility issue with React 19 in 10 mins and several nudges startign from the console error and library name. It would have been a half-day worth of adventure at least should i have done it myself (from diagnosing to fixing)
Philpax 1y ago
> I go in and debug for a while because the app has become fubar, then finally realize it did the whole thing incorrectly and throw it all away. This seems consistent with some of the more precocious junior engineers I've worked with (and have been, in the past.)
nzach 1y ago
> take several minutes to do something The quality of the generated code is inversely proportional to the time it take to generate it. If you let Claude Code work alone for more than 300 seconds you will receive garbage code. Take that as a hint, if it can't finish the task in this time it means you are asking too much. Break up your feature and try with a smaller feature.

jm4 1y ago

You can tell Claude to verify its work. I’m using it for data analysis tasks and I always have it check the raw data for accuracy. It was a whole different ballgame when I started doing that. Clear instructions go a long way, asking it to review work, asking it to debug problems, etc. definitely helps.

vunderba 1y ago
> You can tell Claude to verify its work Definitely - with ONE pretty big callout. This only works when a clear and quantifiable rubric for verification can be expressed. Case in point, I put Claude Code to work on a simple react website that needed a "Refresh button" and walked away. When I came back, the button was there, and it had used a combination of MCP playwright + screenshots to roughly verify it was working. The problem was that it decided to "draw" a circular arrow refresh icon and the arrow at the end of the semicircle was facing towards the circle centroid. Anyone (even a layman) would take one look at it and realize it looked ridiculous, but Claude couldn't tell even when I took the time to manually paste a screenshot asking if it saw any issues. While it would also be unreasonable to expect a junior engineer to hand-write the coordinates for a refresh icon in SVG - they would never even attempt to do that in the first place realizing it would be far simpler to find one from Lucide, Font Awesome, emojis, etc.
- deleted 1y ago
  [deleted]
- DrewADesign 1y ago
  In general, using your own symbol forms for interactions rather than taking advantage of people’s existing mental models is a bad idea. Even straying from known libraries is shaky unless you’re a competent enough designer to understand what specific parts of a visual symbol signify that specific idea/action, and to whom. From a usability perspective, you’re much better off not using a symbol at all than using the wrong one.
yakz 1y ago
I second this and would add that you really need an automated way to do it. For coding, automated test suites go a long way toward catching boneheaded edits. It will understand the error messages from the failed tests and fix the mistakes more or less by itself. But for other tasks like generating reports, I ask it to write little tools to reformat data with a schema definition, perform calculations, or do other things that are fairly easy to then double-check with tests that produce errors that it can work with. Having it "do math in its head" is just begging for disaster. But, it can easily write a tool to do it correctly.
bigiain 1y ago
> Clear instructions go a long way, asking it to review work, asking it to debug problems, etc. definitely helps. That's exactly what I learned. In the early 2000's, from three expensive failed development outsourcing projects.

tcdent 1y ago

This has a lot to do with how you structure your codebase; if you have repeatable patterns that make conventions obvious, it will follow them for the most part. When it drops in something hacky, I use that to verify the functionality is correct and then prompt a refactor to make it follow better conventions.

hnaccount_rng 1y ago

Yeah that is kind of my experience as well. And - according to the friend who highly recommended it - I gave it a task that is "easily within its capabilities". Since I don't think I'm being gaslighted, I suspect it's me using it wrong. But I really can't figure out why. And I'm on my third attempt now..

0x_rs 1y ago

Some great advice I've found that seems to work very well: ask it to keep a succinct journal of all the issues and roadblocks found during the project development, and what was done to resolve or circumvent them. As for avoiding bloating the code base with scatterbrained changes, having a tidy architecture with good separation of concerns helps leading it into working solutions, but you need to actively guide it. For someone that enjoys problem-solving more than actually implementing them, it's very fun.

taude 1y ago
to continue on this, I wouldn't let claude or any agent actually create a project structure, i'd guide it in the custom system prompt. and then in each of the folders continue to have specific prompts for what you expect the assets to be coded like, and common behavior, libraries, etc....
- gonzo41 1y ago
  So you've invented writing out a full business logic spec again. btw, I'm not throwing shade. I personally think upfront design through a large lumbering document is actually a good way to develop stuff. As you either do it upfront, or through endless iterations in sprints for years.
  - bugglebeetle 1y ago
    Yeah, my experience of working with Claude Code is that I’m actually far more conscientious about design. After using it for awhile, you get a good sense of its limits and how you need to break things down and spell thing out to overcome.
  - underdeserver 1y ago
    The problem with waterfall wasn't the full business spec, it was that people wrote the spec once and didn't revise it when reality pushed back.
  - taude 1y ago
    I spent 10 minutes writing out the business logic, you don't have to do it all at once. We're not talking about long complicated things here.

taude 1y ago

do you create the claude.md files at several levels of your folder structure, so you can teach it how to do different things? Configuring these default system prompts is required to get it to work well. I'd definitely watch Boris's intro video below [1] [1] Boris introduction: https://www.youtube.com/watch?v=6eBSHbLKuN0 https://www.youtube.com/watch?v=6eBSHbLKuN0 [2] summary of above video: https://www.nibzard.com/claude-code/ https://www.nibzard.com/claude-code/

dawnerd 1y ago
By the time you do all of that you might as well just write code by hand.
- serf 1y ago
  that's really just a scale question. Yes, I would write a 4 line bash script by myself. But if you're trading a 200 line comprehensive claude.md document for a module that might be 20k LoC? it's a different value proposition.
  - darkwater 1y ago
    And how do you actually know that those 20k line of codes have no glaring bugs, or bugs that you can find yourself, or be able to understand it completely at some point?
    - rovr138 1y ago
      The way I do this is by still writing tests.
      - darkwater 1y ago
        Do tests let you understand a codebase you have not written?
        1y ago

libraryofbabel 1y ago

Sigh. As others have commented, over and over again in the last 6 months we've seen discussions on HN with the same basic variation of "Claude Code [or whatever] is amazing" with a reply along the lines of "It doesn't work for me, it just creates a bunch of slop in my codebase." I sympathize with both experiences and have had both. But I think we've reached the point where such posts (both positive and negative) are _completely useless_, unless they're accompanied with a careful summary of at least: * what kind of codebase you were working on (language, tech stack, business domain, size, age, level of cleanliness, number of contributors) * what exactly you were trying to do * how much experience you have with the AI tool * is your tool set up so it can get a feedback loop from changes, e.g. by running tests * how much prompting did you give it; do you have CLAUDE.me files in your codebase and so on. As others pointed out, TFA also has the problem of not being specific about most of this. We are still learning as an industry how to use these tools best. Yes, we know they work really well for some people and others have bad experiences. Let's try and move the discussion beyond that!

reactordev 1y ago
Seconded, that a summary description of your problem, codebase, programming dialect in use, should be included whenever a “<Model> didn’t work for me” response.
dejavucoder 1y ago
Fair point. For context, I was using Claude Code on a Ruby + Typescript large open source codebase. 50M+ tokens. They had specs and e2e tests so yeah I did have feedback when I was done with a feature - I could run specs and Claude Code could form a loop. I would usually advise it to fix specs one by one. --fail-fast to find errors fast. Prior to Claude Code, I have been using Cursor for an year or so. Sonnet is particularly good at NextJS and Typescript stuff. I also ran this on a medium sized Python codebase and some ML related work too (ranging from langchain to Pytorch lol) I don't do a lot of prompting, just enough to describe my problem clearly. I try my best to identify the relevant context or direct the model to find it fast. I made new claude.md files.
- 1y ago

wyldfire 1y ago

I have seen both success and failure. It's definitely cool and I like to think of it as another perspective for when I get stuck or confused. When it creates a bunch of useless junk I feel free to discard it and either try again with clearer guidelines (or switch to Opus).

leptons 1y ago

Have you tried vibing harder?

baka367 1y ago

For me it fixed a library compatibility issue with React 19 in 10 mins and several nudges startign from the console error and library name. It would have been a half-day worth of adventure at least should i have done it myself (from diagnosing to fixing)

Philpax 1y ago

> I go in and debug for a while because the app has become fubar, then finally realize it did the whole thing incorrectly and throw it all away. This seems consistent with some of the more precocious junior engineers I've worked with (and have been, in the past.)

nzach 1y ago

> take several minutes to do something The quality of the generated code is inversely proportional to the time it take to generate it. If you let Claude Code work alone for more than 300 seconds you will receive garbage code. Take that as a hint, if it can't finish the task in this time it means you are asking too much. Break up your feature and try with a smaller feature.