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.

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.

Vibe coding actually works now

Guess you missed this:

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

Wouldn't make much sense if there are ASICs

Next in the repeat queue: I will not add scrolljacking to my website.

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.

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

A critical 9.2 CVE

Video of PoC: https://mastodon.social/@Viss/117475758985207443

At least they've fixed the tabs.

I get around this by only using optimised SVGs then inlining them.

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.

Why would you not reuse event pages for the next event?

How many times are you getting married? 😄

Let me fix that for you: How many times are people getting married?

The answer: Lots.

There are already wedding websites out there, in every variation possible.

Why reinvent the wheel when we have so many wheels that they're treated as disposable?

I’d expect that the code would be almost exactly the same as other code that already exists, in which case, why not use that code?

Uhm, because it’s not the same? Why would I vibe code an app that’s almost exactly the same as an existing one?

Because a vibecoded app is going to be a ripoff of its training data anyway. LLMs can't produce creative or novel works, all they can do is stochastically regurgitate what they've already seen in their training data. So why deal with risk of injection attacks hidden in the training data when you can just use the original source instead?

There’s not really any such thing as a one off web page.

Of course there is. What an absurd thing to say. A very obvious example is event websites, e.g. for weddings.

Why would you not reuse event pages for the next event?

Maybe it depends on the language but I’ve recently vibe coded two tools in Rust and I’ve skimmed the code and it’s perfectly good Rust. I would accept it in a PR - even if I was being as picky as I’d really like to be in reviews. I don’t think that would have been the case 3 months ago though.

I'd expect that the code would be almost exactly the same as other code that already exists, in which case, why not use that code?

I too love filling my code with things that silently reduce my understanding improving my code using stochastic prediction models trained on tainted data filled with hidden injection prompt attacks AI

You do realize that Photopea is JS running in your browser right, aka it’s slow.

Yes I realise it's running in a browser.

No it's not slow.

It's running 5mb of web assembly, so unless running regular photoshop is using more than 50% of your CPU, you're not going to notice any slowdowns.

The only time you're going to notice a slow down is if the thing you're doing would already be annoying slow in photoshop (e.g. opening >500mb non-raw files, in which case it being slow in a browser wouldn't matter since you'd be better off processing the files outside of photoshop anyway).

Reposting my relevant comment from yesterday on the Opensource board:

My opinion: this is pointless

LLMs are stochastic regurgitators, but software can already be copy/pasted without cost.

Why should we be interested in an LLM clone of photoshop when there are already clones of photoshop (e.g. https://photopea.com/)?

If I want to use photoshop (or something like it), then I’ll use photoshop (or something like it: i.e. photopea).

There’s literally no point in favour of using the LLM copy, it’s going to have less support and less security (since its training data will have also included prompt injection attacks).

It’s just more of the same, but worse. Even for the sake of argument: if it wasn’t worse, it’d still be more of the same.

I’m not interested in more of the same, I’m interested in things made by people that push the boundaries of what’s possible: (e.g. graphite).

Bruh, use photopea

If you have a browser, you have photoshop.

We don't need unsafe vibe coded clones, we have clones with actual development and support

I'd agree with you if the thing literally changing wasn't the placement of the goalposts.

For .one-off web page that is true

There's not really any such thing as a one off web page.

It's eventually going to need to be updated or reused for something else.

The only exceptions being if your company goes under, force majure, or if you have something with the same requirements but choose to make the same thing again from scratch for no real reason , which is just being inefficient and unreasonable.

Also the latest models don’t even make a mess any more.

Yeah.... I'm calling bullshit on that, all four projects I was handed was made by the latest models and it will continue being an issue for the foreseeable future. (see a previous comment of mine for reasoning: https://programming.dev/post/57569685/26398217)