I tossed that number out as my experience, and it varies wildly task to task and language to language.

For C development, I'd imagine it's super accelerating, as there's so much boilerplate micro managing.

For python, less so as it's a bit less boilerplatey.

If wanting to make a variation on a fairly common pattern, really accelerated. If trying to work in a niche context, frequently more annoying than helpful if you try to prompt, but maybe decent at AI augmented code completion.

They already slop up excessive documentation. That's one of the issues is that a issue report or a pull request that might have formerly been to the point is now a big verbose essay. An issue might drone on about the history of string formatting and the various capabilities and the entire rationale of why hexadecimal is so useful in the context of computing and documenting how prevalent it is.

For a pull request that adds an argument to switch some numeric data to hexadecimal. Bonus points, instead of a refactor to shunt numbers over to a common format handler, it might duplicate the logic N number of times, depending on how things rolled that day. Especially CSS, vibe-coded frontend stuff loves to vomit up needless CSS...

The one line explanation suffices, but I see a wall of text and have no idea what they are on about because it's buried in there somewhere among fluff..

But that's my whole point, what you describe is the 20-50% faster scenario.

What is driving most of the annoyance with pull requests are the folks that just tell it to do something and then it spits out a bunch of plausible code, particularly if not testable.

One example:
https://lore.kernel.org/lkml/3...

The proposal was *probably* vibe coded and submitted to the kernel to get some attribution, and the code was fundamentally untestable, and constituted basically LLM guesses about what PCIe7 would look like. Structurally credible, but a volume of negative value crap because it's outright incorrect per people that actually know what it looks like and had to waste their time just in case it was a credible origin for this.

*This* is what responsible open source contributors are up against, not because the slop is viable, but just because the slop drowns out the better. Your AI generated code may be fine because you actually oversee it credibly, but by volume most GenAI output is slop, because of the humans feeding the prompt getting more volume if slop suffices for them.

GenAI rewards those that just don't give a crap and trust the output far more than it rewards people that want to make sure the generated output is actually what you want and done well.

So someone turning on the token hose to an agent that can create and comment on pull requests and all this stuff flood with useless crap. They are going to vomit up probably about 100x more "stuff" to the world than a traditional developer, and further it's a fad where there's probably 5x more people trying.

Someone that uses it to generate and curate the result, who would be able to likely contribute even without the agent, *might* be able to be significantly more productive with credible product. But we are talking about maybe 1.2x to 1.5x in the context of credibly shareable code that would be put into projects (a higher multiplier for throwaway single purpose stuff that won't need maintenance or is something like a basic site).

When 99% is slop, it's hard to imagine the 1% to be worth it.

Yeah, I think the big question is was Eclipse as unhinged as the blog posts suggests throughout, or was this unhinged state brought on by unreasonable treatment by Microsoft...

From some analysis, I think MS team became less competent and more bureaucratic, and probably struggled to understand whatever the hell Eclipse was getting at, and Eclipse was perhaps on top of confusing was also potentially offended that they failed to respond in what he thought was an appropriate amount of time.

So Eclipse obviously had real stuff, but maybe MSRC couldn't understand, and Eclipse took it gravely personally and here we are.

The other option is that MSRC engaged as described and drove Eclipse to be unhinged after trying to engage in a reasonable way.

My life experience is probably that the former is the scenario, that he was smart, but communicated poorly and took offense easily when faced with a boringly incompetent corp team and mistook their nature for malice initially. Things might have gotten heated on Microsoft's side, but I would guess Eclipse went off the rails first, based on his communication style on display in his blog...

Funny thing is that it's literally the opposite, it's the worst at stretching the imagination.

Just saw a claude commercial, and their pitch was "hey, you can use us to make a knock-off dropbox"

Their big stunt a while back was "we made a knock-off C compiler"

Everything is about making knock offs because that's what GenAI can do. It can certainly tailor the knock off in ways that were easier than what it formerly took, but roughly knock-off in their bread and butter

A generic site builder... Yeah that's pretty firmly in the reach of GenAI...

I largely agree with the sentiment that they are disconnected from the harsher reality, though I suspect it's largely knowingly, but even if 'true believers', it's a mismatch between their estimation of what it can do and what it can actually do. Nothing particularly new to 'tech bro' mindset that has been overestimating tech pretty much forever, however awesome the tech may be the tech bro thinks it's even better.

I would reserve "AI Psychosis" to people whose behavior resembles something like schizophrenia. The bcachefs guy, Kent Overstreet sincerely thinking his chatbot interactions represent dealing with a teenage girl. Richard Dawkins similarly believes Claude is sapient and is actually a woman so he renames it 'Claudia'. Then there's that case of the murder-suicide after LLM interaction amplified some schizoprhenic symptoms.

Problem is that ship sailed *years* ago, claim a bug is a 'vulnerability' and you'll probably get a CVE regardless of merit.

Given that the whole topic is *security* bugs then counting CVEs seems extremely apt, and is still grading on easy, as CVEs are actually a pretty low bar. E.g. a 'medium' CVE for ncurses exists (CVE-2023-50495). The tic compiler can segfault with malicious input. Fine, a bug, but... what is the security angle? It has a CVE despite not being a vulnerability. Then you have scenarios where someone finds a component with a bug and describes 6 different ways of making the bug misbehave and get 6 distinct CVEs for what is a common code fix. Example that comes to mind is that VIM had a bunch around it's script interpreter where malicious scripts can run arbitrary code (which is not pitched as a sandboxed environment and explicitly allows arbitrary commands already).

Also getting security researchers to agree something is a security problem is similarly easy. I have an 'advisory' here that tried and failed to get a CVE but a security company granted it a special advisory. Digging in the issue is, under certain circmstance, a person trying to make it misbehave actually *fails* to get permission to something they should have had permission to... Denying service *only* to the attacker... The deeper analysis shows this is the *only* way it could misbehave, it could only fail to acquire privilege under deliberate abuse. There's zero appetite in the industry for pushing back against pretty dumb "security" findings, so they err on the side of accepting everything could maybe be a security issue if someone says it could be.

The issue is an AI twist on a long standing problem particularly in the security industry: people standing on counts of CVEs and handing them out like candy resulting in 'vulnerability slop'. There are real issues out there, but you say 'advisory' or 'cve' and I'm not inclined to think one way or another until I look deeper, and I can't afford to look deeper into the sea of CVEs I already have to wade through.

This is true, but in part because a lot of 'security' reports are pretty bogus, even if they get CVEs and 'security researchers' call it a vulnerability, others may be inclined to roll their eyes. For example, the curl project had a write up:
https://daniel.haxx.se/blog/20...

So LLM findings I anticipate to be similar, but just a firehose of stuff to dig through to separate the real findings from the innocuous ones.

We likely will never have a grip on that, as it's generally easiest to patch the report and not think about whether it *really* was a security risk. The patch may confirm incorrect behavior being acknowledged, but not whether it was realistically a 'security' risk or not.

Yeah, I hate this in general about EV coverage. Everything fixates on 'time to charge to full' instead of 'miles replenished per time'.

To be useful, miles per minute of charge is a better figure.

The kernel isn't really worth keeping closed source.

They have to weigh the logistical burden of sharing source code they don't really care much about versus the very large and real technical burden of changing their technology stack.

I know, he didn't seem that human, but I'm pretty sure he is.

On the one hand, love seeing Musk lose, on the other hand, I hate seeing Altman win..