this post was submitted on 15 Aug 2025
327 points (96.8% liked)

Technology

74324 readers
3642 users here now

This is a most excellent place for technology news and articles.


Our Rules


  1. Follow the lemmy.world rules.
  2. Only tech related news or articles.
  3. Be excellent to each other!
  4. Mod approved content bots can post up to 10 articles per day.
  5. Threads asking for personal tech support may be deleted.
  6. Politics threads may be removed.
  7. No memes allowed as posts, OK to post as comments.
  8. Only approved bots from the list below, this includes using AI responses and summaries. To ask if your bot can be added please contact a mod.
  9. Check for duplicates before posting, duplicates may be removed
  10. Accounts 7 days and younger will have their posts automatically removed.

Approved Bots


founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] frezik@lemmy.blahaj.zone 33 points 1 week ago (10 children)

To those who have played around with LLM code generation more than me, how are they at debugging?

I'm thinking of Kernighan's Law: "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." If vibe coding reduces the complexity of writing code by 10x, but debugging remains just as difficult as before, then Kernighan's Law needs to be updated to say debugging is 20x as hard as vibe coding. Vibe coders have no hope of bridging that gap.

[–] frog_brawler@lemmy.world 1 points 6 days ago

How are they at debugging? In a silo, they’re shit.

I’ve been using one LLM to debug the other this past week for a personal project, and it can be a bit tedious sometimes, but it eventually does a decent enough job. I’m pretty much vibe coding things that are a bit out of my immediate knowledge and skill set, but I know how they’re supposed to work. For example, I’ve got some python scripts using rekognition to scan photos for porn or other explicit stuff before they get sent to an s3 bucket. After that happens, there’s now a dashboard that’s going to give me results on how many images were scanned and then marked as either acceptable or flagged as inappropriate. After a threshold of too many inappropriate images being sent in, it’ll shadowban them from sending any more dick pics in.

For someone that’s never taken a coding course, I’m relatively happy with the results I’m getting so far. Granted, this may be small potatoes for someone with an actual development background; but as someone that’s been working adjacent to those folks for several years, I’m happy with the output.

[–] sobchak@programming.dev 0 points 5 days ago

I've used AI by just pasting code, then asking if there's anything wrong with it. It would find things wrong with it, but would also say some things were wrong when it was actually fine.

I've used it in an agentic-AI (Cursor), and it's not good at debugging any slightly-complex code. It would often get "stuck" on errors that were obvious to me, but making wrong, sometimes nonsensical changes.

[–] demizerone@lemmy.world 0 points 6 days ago

I am working at a big AI company on llm generating code for automation. I've had cursor solve a bug that was occuring in prod after prompting and asking questions of the responses. It took a few rounds but it found a really obscure interaction with the app and the host, and it thanked me for the insight. 😀. I deployed the fix and it worked.

The problem I have is I member it solving this bug, and I remember being impressed, but I don't remember the bug. I took a screenshot of it, but currently don't have access to those. I am disconnected from the code that the llm has generated, but I am very aware of how the app works and what it should do very intently because I had to write requirements and design doc.

[–] Ledivin@lemmy.world 26 points 1 week ago (1 children)

They're not good at debugging. The article is pretty spot on, IMO - they're great at doing the work; but you are still the brain. You're still deciding what to do, and maybe 50% of the time how to do it, you're just not executing the lowest level anymore. Similar for debugging - this is not an exercise at the lowest level, and needs you to run it.

[–] hisao@ani.social 8 points 1 week ago

deciding what to do, and maybe 50% of the time how to do it, you’re just not executing the lowest level anymore

And that's exactly what I want. And I don't get it why people want more. Having more means you have less and less control or influence on the result. What I want is that in other fields it becomes like it is in programming now, so that you micromanage every step and have great control over the result.

[–] very_well_lost@lemmy.world 15 points 1 week ago* (last edited 1 week ago) (3 children)

The company I work for has recently mandated that we must start using AI tools in our workflow and is tracking our usage, so I've been experimenting with it a lot lately.

In my experience, it's worse than useless when it comes to debugging code. The class of errors that it can solve is generally simple stuff like typos and syntax errors — the sort of thing that a human would solve in 30 seconds by looking at a stack trace. The much more important class of problem, errors in the business logic, it really really sucks at solving.

For those problems, it very confidently identifies the wrong answer about 95% of the time. And if you're a dev who's desperate enough to ask AI for help debugging something, you probably don't know what's wrong either, so it won't be immediately clear if the AI just gave you garbage or if its suggestion has any real merit. So you go check and manually confirm that the LLM is full of shit which costs you time... then you go back to the LLM with more context and ask it to try again. It's second suggestion will sound even more confident than the first, ("Aha! I see the real cause of the issue now!") but it will still be nonsense. You go waste more time to rule out the second suggestion, then go back to the AI to scold it for being wrong again.

Rinse and repeat this cycle enough times until your manager is happy you've hit the desired usage metrics, then go open your debugging tool of choice and do the actual work.

[–] HubertManne@piefed.social 10 points 1 week ago (2 children)

maybe its just me but I find typos to be the most difficult because my brain and easily see it as correct so the whole code looks correct. Its like the way you can take the vowels out of sentences and people can still immediately read it.

[–] ganryuu@lemmy.ca 2 points 6 days ago

Probably why they talked about looking at a stack trace, you'll see immediately that you made a typo in a variable's name or language keyword when compiling or executing.

[–] wols@lemmy.zip 1 points 6 days ago (1 children)

The nastiest typos are autocompleted similarly named (and correctly typed) variables, functions, or types. Which is why it's a good idea to avoid such name clashes in the first place. If this is impossible or not practical, at least put the part that differs at the start of the name.

[–] HubertManne@piefed.social 1 points 6 days ago (1 children)

Thing is that having the differ part at the end is nicer for sorting.

[–] wols@lemmy.zip 1 points 5 days ago (1 children)

What do you mean? For what purpose would you sort variables or functions?

[–] HubertManne@piefed.social 2 points 5 days ago

Sorry. I was thinking hostnames or other endpoints and was thinking that way back with typos. dev78usc03 instead of dev78usc02 or such.

[–] HarkMahlberg@kbin.earth 8 points 1 week ago (1 children)

we must start using AI tools in our workflow and is tracking our usage

Reads to me as "Please help us justify the very expensive license we just purchased and all the talented engineers we just laid off."

I know the pain. Leadership's desperation is so thick you can smell it. They got FOMO'd, now they're humiliated, so they start lashing out.

[–] frog_brawler@lemmy.world 2 points 6 days ago* (last edited 6 days ago)

Funny enough, the AI shift is really just covering for the over-hiring mistakes in 2021. They can’t admit they fucked up in hiring too many people during Covid, so they’re using AI as the scapegoat. We all know it’s not able to actually replace people yet; but that’s happening anyway.

There won’t be any immediate ramifications, we’ll start to see that in probably 12-18 months or so. It’s just another form of kicking the can down the road.

[–] trublu@lemmy.dbzer0.com 7 points 1 week ago

As it seems to be the case in all of these situations, AI fails hard at tasks when compared to tools specifically designed for that task. I use Ruff in all my Python projects because it formats my code and finds (and often fixes) the kind of low complexity/high probability problems that are likely to pop up as a result of human imperfection. It does it with great accuracy, incredible speed, using very little computing resources, and provides levels of safety in automating fixes. I can run it as an automation step when someone proposes code changes, adding all of 3 or 4 seconds to the runtime. I can run it on my local machine to instantly resolve my ID10T errors. If AI can't solve these problems as quickly, and if it can't solve anything more complicated reliably, I don't understand why it would be a tool I would use.

[–] Pechente@feddit.org 14 points 1 week ago (1 children)

Definitely not good. Sometimes they can solve issues but you gotta point them in the direction of the issue. Other times they write hacky workarounds that do the job for the moment but crash catastrophically with the next major dependency update.

[–] HarkMahlberg@kbin.earth 12 points 1 week ago (1 children)

I saw an LLM override the casting operator in C#. An evangelist would say "genius! what a novel solution!" I said "nobody at this company is going to know what this code is doing 6 months from now."

It didn't even solve our problem.

[–] hisao@ani.social 5 points 1 week ago

My first level of debugging is logging things to console. LLMs here do a decent job at "reading your mind" and autocompleting "pri" into something like "println!("i = {}, x = {}, y = {}", i, x, y);" with very good context awareness of what and how exactly it makes most sense to debug print in the current location in code.

[–] 0x01@lemmy.ml 4 points 1 week ago

I use it extensively daily.

It cannot step through code right now, so true debugging is not something you use it for. Most of the time the llm will take the junior engineer approach of "guess and check" unless you explicitly give it better guidance.

My process is generally to start with unit tests and type definitions, then a large multipage prompt for every segment of the app the llm will be tasked with. Then I'll make a snapshot of the code, give the tool access to the markdown prompt, and validate its work. When there are failures and the project has extensive unit tests it generally follows the same pattern of "I see that this failure should be added to the unit tests" which it does and then re-executes them during iterative development.

If tests are not available or if it is not something directly accessible to the tool then it will generally rely on logs either directly generated or provided by the user.

My role these days is to provide long well thought out prompts, verify the integrity of the code after every commit, and generally just kind of treat the llm as a reckless junior dev. Sometimes junior devs can surprise you, like yesterday I was very surprised by a one shot result: asking for a mobile rn app for taking my rambling voice recordings and summarize them into prompts, it was immediately remarkably successful and now I've been walking around mic'd up to generate prompts.