this post was submitted on 30 Sep 2025
1164 points (98.6% liked)

Technology

76274 readers
2932 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
L3s@lemmy.world
enu@lemmy.world
technopagan@lemmy.world
L4s@lemmy.world
L3s@hackingne.ws
L4s@hackingne.ws
1164
AI Coding Is Massively Overhyped, Report Finds (futurism.com)
submitted 3 weeks ago by SparroHawc@lemmy.zip to c/technology@lemmy.world
236 comments fedilink hide all child comments
 

"No Duh," say senior developers everywhere.

The article explains that vibe code often is close, but not quite, functional, requiring developers to go in and find where the problems are - resulting in a net slowdown of development rather than productivity gains.

you are viewing a single comment's thread
view the rest of the comments
[–] Nalivai@lemmy.world 1 points 3 days ago (3 children)

Devs are more invested in code they wrote themselves. When I'm writing tests for something I didn't write, I'm less personally invested in it.

This, I think, is a very bad part of the problem and shouldn't be happening regardless

[–] sugar_in_your_tea@sh.itjust.works 1 points 3 days ago (2 children)

It shouldn't, but it does. The person who writes the code cares more about its correctness, so I trust them to write better tests.

[–] Nalivai@lemmy.world 1 points 2 days ago (1 children)

I absolutely don't. Since we're talking about bad cases anyway, I don't trust a developer to be diligent in finding bugs in their code more than I believe they will try to make all the tests pass. And it's easier and better for the ego to achieve that if you write shit tests that only cover cases that you know will work.

[–] sugar_in_your_tea@sh.itjust.works 1 points 2 days ago* (last edited 2 days ago)

Unit tests aren't intended to find bugs, they're intended to prove correctness. There should be a separate QA process for finding bugs, which involves integration testing. When QA inevitably finds a bug, the unit tests get updated with that case (and any similar cases).

only cover cases that you know will work

And that's what code reviews are for. If your tests don't sufficiently cover the logic, the change should be rejected until they do. It's a lot easier to verify the tests cover the logic if the tests are submitted w/ the logic changes.