…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.

  • Feyd ( Feyd@programming.dev ) deleted by creator
    link
    fedilink
    arrow-up
    125
    ·
    7 months ago

    producing subtly broken junk

    The difference between you and people that say it’s amazing is that you are capable of discerning this reality.

    • OwOarchist ( OwOarchist@pawb.social ) 
      link
      fedilink
      English
      arrow-up
      38
      ·
      7 months ago

      What I don’t get, though, is how the vibe code bros can’t discern this reality.

      How can they sit there and not see that their vibe-coded app just doesn’t do what they wanted it to do? Eventually, you’ve got to try actually running the app, right? And how do you keep drinking the AI kool-aid when you find out that the app doesn’t work?

      • Vibe code bros aren’t real programmers. They’re business people, not computer people. Even if they have a CS degree, they only got that because they think it’ll get them more money. They lack passion and they don’t care about understanding anything. They probably don’t even care about what they’re generating beyond its potential to be used in a grift.

        I graduated college not that long ago and my CS classes had quite a few former business majors. They switched because they think it’ll be more lucrative for them but since they only care about money they didn’t bother to actually learn the material especially since they could just vibe code through everything.

      • Feyd ( Feyd@programming.dev ) deleted by creator
        link
        fedilink
        arrow-up
        29
        ·
        7 months ago

        They’re the same people that copied code from stack overflow that you had to tell them how to actually fix every PR. The difference is the C suite types are backing them this time

      • tleb ( tleb@lemmy.ca ) 
        link
        fedilink
        arrow-up
        8
        ·
        7 months ago

        Eventually, you’ve got to try actually running the app, right?

        At least at my company, no, they just start selling it.

    • I wonder if it was even able to compile. I am a shitty hobby coder who just does it to make my embedded hardware projects function.

      I have yet to get compilable code out of any of the AI bots I have tried. Gemini, mistral, and chatGPT. I am not making an account lol.

      I have gotten some compilable python and VBA code for data analysis stuff at work, so I wonder if it is because embedded stuff uses specific SDKs that it can’t handle.

      Either way I have given up on it for anything besides bouncing ideas off of or debugging where electromagnetics issues could lie (though it has been completely wrong about that also even though it is using the wrong concepts, it just reminds me of concepts that I might have overlooked)

  • cecilkorik ( cecilkorik@lemmy.ca ) 
    link
    fedilink
    English
    arrow-up
    65
    ·
    7 months ago

    No, I think you do get it. That’s exactly right. Everything you described is absolutely valid.

    Maybe the only piece you’re missing is that “almost right, but critically broken in subtle ways” turns out to actually be more than good enough for many people and many purposes. You’re describing the “success” state.

    /s but also not /s because this is the unfortunate reality we live in now. We’re all going to eat slop and sooner or later we’re going to be forced to like it.

      • cecilkorik ( cecilkorik@lemmy.ca ) 
        link
        fedilink
        English
        arrow-up
        14
        ·
        7 months ago

        As a professional software developer, I truly hope that is the case (and I plan to charge at least 10x my current rate after the AI bubble pops when I’m looking for my next job as I expect there to be a massive shortage of people skilled enough to actually deal with the nightmare spaghetti AI code bases)

        Fun times ahead.

        • It will be interesting (read as: bad) times to get to that point and I agree. The Junior market is basically not existent ever since coding agents appeared, stripping the industry of its future Seniors. We will be chained to our desks.

    • “almost right, but critically broken in subtle ways” turns out to actually be more than good enough for many people and many purposes. You’re describing the “success” state.

      Exactly. The consequences are at worst a problem for “future me”, and at best “somebody else’s problem”.

      AI didn’t create this reality, but it’s certainly moved it into the spotlight and to “center stage.”

    • vga ( vga@sopuli.xyz ) BannedBanned
      link
      fedilink
      arrow-up
      2
      ·
      7 months ago

      Maybe the only piece you’re missing is that “almost right, but critically broken in subtle ways”

      Sure, but you have to note that it reaches that point in minutes. Sometimes on a task that would take humans a week. The power is not that it creates correct stuff, it’s that it creates almost correct stuff 100 times faster than human. Plus the typical machine benefits: it never gets tired, demotivated, etc.

      So then the challenge becomes being able to be that human, who can review stuff extremely well and rapidly, being natural in probing the stuff LLMs tend to be wrong about. Sort of like the same challenge that every tech lead had before LLMs too, but just subtly different, because LLMs don’t exactly think like we do.

  • Gsus4 ( Gsus4@mander.xyz ) 
    link
    fedilink
    arrow-up
    31
    ·
    7 months ago

    Their usual (crap) defense is:

    a) you’re not paying enough, so of course it is crap

    b) you’re not prompting right, you need to use detailed, precise language…

    c) that is just anecdotal evidence, you need to do an actual study, yadda yadda.

    d) it will improve…

    (any other anyone has noticed?)

  • athatet ( athatet@lemmy.zip ) 
    link
    fedilink
    arrow-up
    23
    ·
    7 months ago

    The reason you kept going around in circles and reintroducing bugs you already got rid of is because LLMs don’t remember things. Every time you tell it something it tells it the entire conversation again so it has all the parts. Eventually it runs out of room and starts cutting off the beginning of the convo and now the llm can’t ‘remember’ what it was you were even talking about.

  • Have you been coding professionally long?

    I find that the only time I can use these chatbots for a task I really need to already know what i’m doing so that I can read the output and fix the issues. This is like having junior devs on your team and being a code reviewer more than being a full time coder. They get a lot of things wrong but there’s so much usable that you can save a ton of time over doing everything yourself from scratch.

    Just like with junior devs, you can send them back to fix what you know is wrong and give them feedback to improve various things you would prefer done another way. There’s no emotions though, so you can just be blunt and concise with feedback.

    • pinball_wizard ( pinball_wizard@lemmy.zip ) 
      link
      fedilink
      arrow-up
      7
      ·
      edit-2
      7 months ago

      They get a lot of things wrong but there’s so much usable that you can save a ton of time over doing everything yourself from scratch.

      Your experience with Junior devs has been quite different from mine.

      I work with Junior devs because someday they will be senior devs who owe me a favor, even though they’ve always only costed me time.

      Edit: I also work with junior devs because sometimes a tiny corner of my job is both mind-numbingly boring, and also weirdly difficult to automate away.

      I assign that work to junior devs because I don’t want to do it.

      In doing so, I am wasting the boss’s money, since I could do it faster.

      But I consider it but just another part of the price of hiring me, because it keeps me happy.

  • sobchak ( sobchak@programming.dev ) 
    link
    fedilink
    arrow-up
    12
    ·
    7 months ago

    Key is having it write tests and have it iterate by itself, and also managing context in various ways. It only works on small projects in my experience. And it generates shit code that’s not worth manually working on, so it kind of locks your project in to being always dependent on AI. Being always dependant on AI, and AI hitting a brick wall eventually means you’ll reach a point where you can’t really improve the project anymore. I.e. AI tools are nearly useless.

  • I use my own brain to sketch out what I want to work and how. Before writing any code, I use the LLM to point out gaps and how to close them. Pros and cons of certain decisions. Things you would discuss with colleagues. Then, I come up with a plan for the order I want the code to be written in and how to fragment that into smaller, easy to handle modules. I supervise and review each chunk produced, adapt code mostly manually if required, write the edge case tests - most importantly, run it - and move to the next. This is how I use it successfully and get results much faster than the traditional way.

    At my job though I can witness how other people use it. I was asked to review a fully vibecoded fullstack app that contains every mistake possible. Unsanitizised input. Hardcoded tokens. Hardcoded credentials. 2500+ LoC classes and functions. Business logic orchestrators masquerading as service. Full table scans on each request. Cross-tenant data leaks. Loading whole tables into the memory. No test coverage for the most critical paths. Tests requiring external services to run. The list goes on. Now they want me to make it production ready in 8 weeks “because you have AI”.

    My point: This was an endorphine fueled vibecoding session by someone who has no experience as developer, asked the LLM to “just make it work”, lacking the ability to supervise the work that comes with experience. It was enough to make it rum locally and pitch a “system engineered w/o any developer” to management.

    Those systems need guidance just as a Junior would and I am strongly and loudly advocating to restrict access to this incredibly useful tool to people who know what they do. Nobody would allow a manager to use a laser cutter in a carpentry workshop without proper training, worst case is they will burn down the whole shack.

    I appreciate you having a open mind about it at least. I needed some time to adjust as well. I don’t even use Opus, most of the time my workflow consistently produces usable code with Sonnet. Maybe you can try what I explained initially? Just don’t try any language you’re not familiar with, that will not end well.

  • zbyte64 ( zbyte64@awful.systems ) 
    link
    fedilink
    arrow-up
    10
    ·
    edit-2
    7 months 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
  • .net runtime after 10 months of using and measuring where LLMs (including latest Claude models) shine reported a mindboggling success rate peaking at 75% (sic!) for changes of 1-50 LOC size - and it’s for an agentic model (so you give it a prompt, context, etc, and it can run the codebase, compile it, add tests, reason, repeat from any step, etc etc).

    Except it was clearly bullshit because it didn’t work.

    Welcome to the LLMs where everything is hallucinated and correctness doesn’t matter.

    Is anyone having success with these tools

    Define success.

    Is there a special way to prompt it?

    It gets better the more you use it, you will learn what works for you, and what does not. Right now the hot shit is “autonomous agent swarms” peddled by the token sellers as a way to output correct massive features. Do not touch that for now.

    What helps with Claude / llms 101:

    • when it tells you something about an API, using a tool or whatever, tell it tool version and order it to give you documentation page proving the solution is possible.

    • when it oneshots a working solution you will get a dopamine hit. Be aware of that, as it can be addictive or make you trust it. Do not trust it, it sucks long term.

    • it will alwyas default to below average solution. Know where your hotspots are, and be extra judgy there.

    • it will get lazy and lie to you, especially with tests

    • it will not propose code refactors on its own.

    • despite the token peddlers claims, no matter if your using the 1M token context window model, the shit degrades when the context window is over 20k-30k tokens - so switch context windows often for better outcomes, but that means you will be burning more money - which obviously benefits the token peddlers.

    • do not trust the hype - so far any and all tall claim of a breakthrough from the token peddlers were a lie (e.g. vibing working os that can run Doom, vibing a next.js 96% replacement in a week, vibing a browser, compiler, vibing a browser jailbreak via Mythos)

    Would I get better results during certain hours of the day?

    Afaik USA timezone has worse performance.

  • It’s not called “correct” coding for a reason.

    That’s why people are wrong so often: they feel like something is right, but don’t check. That’s how you get anti -vaxxers, manospere people, MAGA, QAnon, Brexit, etc.

  • Blackmist ( Blackmist@feddit.uk ) 
    link
    fedilink
    English
    arrow-up
    6
    ·
    7 months ago

    I think it’s mostly going to be useful for boilerplate generation, and effectiveness is going to vary wildly based on what language you’re using. JS or Python? It’ll probably do OK. Plenty of open source for it to “learn” from. Delphi? Forget it.

    Brief experimentation showed it liked to bullshit if it was wrong, rather than fix things.

  • zerofk ( zerofk@lemmy.zip ) 
    link
    fedilink
    arrow-up
    6
    ·
    7 months ago

    “Almost but not quite” is exactly my experience with Claude.

    The only time I’ve had real success is telling it to do a simple API change that touches a dozen files. It took a while and I’m not sure it was faster than doing it manually, but at least it was less boring.

    Possibly important context: I only started really using it a few weeks ago.