225

...and I still don't get it. I paid for a month of Pro to try it out, and it is consistently and confidently producing subtly broken junk. I had tried doing this before in the past, but gave up because it didn't work well. I thought that maybe this time it would be far along enough to be useful.

The task was relatively simple, and it involved doing some 3d math. The solutions it generated were almost write every time, but critically broken in subtle ways, and any attempt to fix the problems would either introduce new bugs, or regress with old bugs.

I spent nearly the whole day yesterday going back and forth with it, and felt like I was in a mental fog. It wasn't until I had a full night's sleep and reviewed the chat log this morning until I realized how much I was going in circles. I tried prompting a bit more today, but stopped when it kept doing the same crap.

The worst part of this is that, through out all of this, Claude was confidently responding. When I said there was a bug, it would "fix" the bug, and provide a confident explanation of what was wrong... Except it was clearly bullshit because it didn't work.

I still want to keep an open mind. Is anyone having success with these tools? Is there a special way to prompt it? Would I get better results during certain hours of the day?

For reference, I used Opus 4.6 Extended.

you are viewing a single comment's thread
view the rest of the comments
[-] zbyte64@awful.systems 11 points 14 hours ago* (last edited 14 hours ago)

In my experience there are three ways to be successful with this tool:

  • write something that already exists so it doesn't need to think
  • do all the thinking for it upfront (hello waterfall development)
  • work in very small iterations that doesn't require any leaps of logic. Don't reprompt when it gets something wrong, instead reshape the code so it can only get it right

The issue with debugging is that it doesn't actually think. LLMs pattern match to a chain of thought based on signals, not reasoning. For it to debug you need good signals in your code that explicitly tell what it is doing and the LLMs do not write code with that level of observability by default.

Edit: one of my workflows that I had success with is as follows:

  • write a gherkin feature file describing desired functionality, maybe have the LLM create multiple scenarios after I defined one to copy from
  • tell the LLM to write tests using those feature files, does an okay job but needs help making tests run in parallel.
  • if the feature is simple, ask the LLM to make a plan and review it
  • if the feature is complex then stub out the implementation in code and add TODOs, then direct the LLM to plan. Giving explicit goals in the code itself reduces token consumption and yield better plans
[-] spartanatreyu@programming.dev 3 points 9 hours ago

write something that already exists so it doesn’t need to think

If something already exists, it shouldn't need to be rewritten.

Doing otherwise is a sign that something has gone wrong.

That was the case before LLMs and it is still the case today.

[-] zbyte64@awful.systems 1 points 8 hours ago

Absolutely. It's amazing how many articles showcasing vibe coding is just people reinventing things like a password generator.

this post was submitted on 11 Apr 2026
225 points (90.6% liked)

Programming

26482 readers
336 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev



founded 2 years ago
MODERATORS