[–] 0 points 4 hours ago*

AI development tools are not going away. They are massive productivity enhancers, FOR PEOPLE WHO KNOW HOW TO USE THEM PROPERLY.

It depends.

To be more specific, they are massive productivity enhancers over the short term with the trade off being lost productivity over the long term. If your scope is going to be over the long term then using LLM tools is going to be a net negative benefit.

A single small scope disposable project however might be more productive to be vibecoded as the negative effects to the coder (e.g. cognitive debt, skill atrophy, etc...) can be overcome by paying off that debt and reinforcing acquired skills in the next project with thinking through challenging problems and hand coding a larger project.

But you need to take care to make sure it's a one off, otherwise you open yourself up to compounding those negative effects. The real danger is the productivity boost from one small scoped disposable project is psychologically seductive and you risk yourself falling into a cognitive surrender / death-spiral. We already know it uses the same pathways as those found in gambling and drug addiction so caution is definitely warranted.

Rather than banning AI tools in development, the correct approach is to change how submissions are handled in open source projects. Maybe we should move away from treating all submissions equally.

For large projects like the Linux Kernel, you or your organization should go through a qualification process. Alternatives you can look at a referral based qualification. If you submit junk quality code frequently, you lose standing.

Yes, that’s more work, but it’s worth it for the benefits of AI tooling while retaining the best minds on the project. Arguably large open source projects need this anyway.

This can work, but it's easy to get it wrong.

Online competitive gaming suffers a similar problem: If all your opponents are bots or cheaters, then the game is no longer fun and players leave.

The best solution we have for that is shadowbanning. When a user is found to have been cheating, only match them with other cheaters, and don't tell them. But that doesn't work in source forges where bad users can tell they can't communicate with everyone.

The next best solution is to make it expensive to be a bad actor. Make it so that to participate, you need a paid account (usually a small $5 fee). Bad actor's accounts are banned and to participate again, you need to jump through the hoops of purchasing a new account. This is used in gaming with purchasing subscriptions (where the credit card number is blacklisted), or by tying a phone number to the account which is sent a validation text message (where the number is blacklisted). This is also used by phone app stores to combat spam app submissions.

It's not a perfect solution, but it's effective.

  • source
  • parent
  • context
  • I'd doubt they'd be using it past simply testing the technology and simple translation of customer support messages in spoken languages that they aren't able to converse in.

    They're not beholden to shareholders, so they're not incentivised to chase short term gains over long term sustainable profits, so they're not pushed to use AI and rot out their own understanding of their own codebases from underneath themselves.

  • source
  • parent
  • context
  • Egalitarian PoW don’t work better on custom hardware.

    I mean it could... Even for Egalitarian PoW. You'd have to make the ASIC specifically for the exact PoW you're trying to target, and you're going to end up with something pretty exotic that's going to be easy enough to invalidate by altering the PoW. But, you could...

  • source
  • parent
  • context
  • [–] 11 points 1 week ago

    Interesting comments from lobste.rs IMHO:

    1. 19 upvotes link

      Relevant issue: https://codeberg.org/ziglang/zig/issues/37402

      Pending PR: https://codeberg.org/ziglang/zig/pulls/37417

    2. 6 upvotes link

      Hate to say it, but LLM code review certainly would have caught such an obvious "accidentally quadratic" bug.

      23 upvote response link

      And we would have missed the community showing up, and having fun working together on a fix.

      I think this is acceptable in a pre-1.0 language.

  • source
  • [–] 3 points 2 weeks ago

    You're not going to be good at it, at first. It probably takes a good 6-12 months to do it all correctly and most developers don't actually learn how to do it all properly.

    But here's my cheatsheet if you actually want to spend the time to get really good at code review. Save this comment so you can keep coming back to it.


    First, you need to relearn the programming side, making code in a specific way that has the capacity to be reviewed correctly. Don't think about code made to accomplish a goal because you should already be able to do that. Instead make sure you understand what makes code easy to review by someone else.

    Why: You may have been stuck in an environment where someone else was either fixing your mistakes for you (depriving you of your opportunity to get better at writing reviewable code), or you may have been in an environment where you were getting the wrong feedback.

    How: Read this link: https://mtlynch.io/code-review-love, then read it again next week, and again the following week. Once you intuitively can make reviewable code, it'll be easier for you to teach others how to make reviewable code (which makes your reviews easier to perform correctly).


    Second: Learn how to actually give feedback in a way that gets things fixed.

    How: Read this: https://mtlynch.io/human-code-reviews-1/.


    Third: Don't try to write or correct documentation before you understand the "Grand unified theory of documentation" Link: https://docs.divio.com/documentation-system/. TL;DR: Most programmers don't understand that there's actually four different types of documentation and assume that the kind that they right is what's actually needed.

    That goes into technical writing, which is another skill you need to develop but makes projects better as a whole, which makes it easier to review code.


    Fourth (bonus reading material): antirez (the guy who made redis) went through his whole project and did a kind of census/retrospective on all the comments inside. It sort of accidentally turned into a good practical advisory on writing comments that actually mean something. Link here: https://antirez.com/news/124

  • source
  • [–] 1 point 4 weeks ago

    Maybe you want your wedding website to look different to other people’s?

    Unless you're drawing a massive illustration or specifically going with a non-wedding themed wedding, there's only so many variations you're going to end up with.

    Dude it’s 2026 not 2024. I know things are changing rapidly but that has been very obviously not true for at least 6 months.

    Since this is such a cookie cutter argument, see last week's response about the same thing: https://programming.dev/post/57569685/26396986.

    You’re going to be shocked.

    I'm constantly shocked at the bad code I get from other using the latest models. See one of my parent comments in the same linked comment, each of the four projects came from people using the latest models.

  • source
  • parent
  • context
  • view more: next ›