this post was submitted on 30 Sep 2025
1089 points (98.7% liked)

Technology

75682 readers
3207 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
1089
AI Coding Is Massively Overhyped, Report Finds (futurism.com)
submitted 1 day ago by SparroHawc@lemmy.zip to c/technology@lemmy.world
224 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
[–] sugar_in_your_tea@sh.itjust.works 2 points 1 day ago (1 children)

I really disagree here. If someone else is writing your unit tests, that means one of the following is true:

  • the tests are written after the code is merged - there will be gaps, and the second dev will be lazy in writing those tests
  • the tests are written before the code is worked on (TDD) - everything would take twice as long because each dev essentially needs to write the code again, and there's no way you're going to consistently cover everything the first time

Devs should write their tests, and reviewers should ensure the tests do a good job covering the logic. At the end of the day, the dev is responsible for the correctness of their code, so this makes the most sense to me.

[–] Nalivai@lemmy.world 1 points 17 hours ago (1 children)

the tests are written after the code is merged - there will be gaps, and the second dev will be lazy in writing those tests

I don't really see how this follows. Why do the second one necessary have to be lazy, and what stops the first one from being lazy as well.
The reason I like it to be different people is so there are two sets of eyes looking at the same problem without the need for doing a job twice. If you miss something while implementing, it's easier for you to miss it during test writing. It's very hard to switch to testing the concept and not the specific implementation, but if you weren't the one implementing it, you're not "married" to the code and it's easier for you to spot the gaps.

[–] sugar_in_your_tea@sh.itjust.works 1 points 9 hours ago

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. Looking at PRs by other devs when we do pushes for improving coverage, I'm not alone here. That's just human psychology, you care more about things you built than things you didn't.

I think testing should be an integral part of the dev process. I don't think any code should be merged until there are tests proving its correctness. Having someone else write the tests encourages handing tests to jr devs since they're "lower priority."