Here's a good heuristic for predicting the ability of a modern frontier LLM at any non-automatable task: Is it hugely overrepresented in their pre-training dataset (e.g. code), and were they specifically post-trained on it using reinforcement learning (e.g. coding)? If the answer to one or both is yes, you should expect them to be very good at it. Otherwise, you should expect them to be, at best, as good as an average human who's read a few books on the subject and is good at bullshitting.
I think this is true of any trained anything. It's the fish climbing a tree scenario. The teens on Ellen getting laughed at for not knowing how to fold a paper map.
There's infinite front end code to train on. Virtually infinite python and shell scripts too. As I've worked my way away from such domains, the LLM outputs have gotten worse. It just makes sense.
> If that's true, how do you explain the observable pattern of many consumer applications degrading in UI functionality and coherence after a certain point?
Most consumer software in developed under the assumption that features only have a cost when being built. Their maintenance cost, and the combinatorial complexity each new feature adds, is barely considered. As a result, software teams add complexity at a speed that exceeds the rate at which the team's size, and the volume of work it can handle, grows. Eventually this reaches a critical threshold and the quality of the software starts to decline. But this doesn't mean the software couldn't still be improved, just that there isn't the resource available to do so.
> Most consumer software in developed under the assumption that features only have a cost when being built. Their maintenance cost, and the combinatorial complexity each new feature adds, is barely considered.
I suppose that's true, but I don't see what it has to do with UI design from a usability standpoint.
> But this doesn't mean the software couldn't still be improved, just that there isn't the resource available to do so.
It's a push and pull from both sides, isn't it? The accretion of process complexity among the developers may increase over time, but so too does the completion of core features and solution of all of the low-hanging-fruit development tasks.
Pretty much every GUI application I've ever used seems to hit a point where the original purpose for which the software was devised is satisfied for essentially all common use cases, but the incentives of the dev team are to keep going, so they move more and more toward gimmicky features, unnecessary bells and whistles, visual changes to the UI, etc. because any real functional improvement is a big investment, but they still need to justify a new release.
UI churn is one of the most common failure modalities here: when you've already picked all of the low hanging fruit in functionality and performance, major UI changes can create the appearance of improvement and innovation without actually having to do any of the hard work to achieve real improvement.
So when I see unnecessary UI changes to an application that still basically does the same things in the same way, at this point I'm conditioned to assume that that application has hit the point of diminishing returns for actual functionality, and the development incentives are now going to be driving more and more churn. And that's when I consider the software "finished".
This is not a "concern", this is literally what happens. Even prior to AI vulnerability scanning, release notes and diffs for any normal release or security patch of popular software were analysed and used to develop exploits, which could then be applied against non-upgraded instances. Nowadays, AI is doing this en masse and automatically producing exploits. And, as has been demonstrated, nowadays even the rumour of a major security bug is enough for people to find it, as people will immediately burn huge volumes of tokens looking for it.
Nor can you just keep it quiet and smuggle it out in a regular release as you suggest. For one thing, changes in important software are be linked to commits and have pull requests, reviews, etc. Changes without these will immediately raise suspicion, as either a malicious change snuck into a release, or as a "quiet" fix to a major vulnerability, completely undermining the purpose of keeping it quiet in the first place. Moreover, major vulnerability fixes cannot be "quiet", because the whole point is to get as many people as possible to upgrade as quickly as possible. If PHP (or whoever) push out a release containing a major security fix, but don't make this clear, then many people will be in no rush to upgrade, and will get pwned.
> This is not a "concern", this is literally what happens.
Sorry, I should have been specific: the concern is that this will happen faster than even the more fastidious admins (or daily or even hourly automated checks) will spot and apply updates.
> nowadays even the rumour
I think a lot fewer people would have paid attention at all without the rumour. Some ne'er-do-wells might have scanned a larger update for security issues otherwise, but I suspect most of those spending tokens on PHP this week would not have bothered had there just been a standard maintenance release that may or may not have included changes for a security issue that may (but probably not) have been so globally significant.
That is, at least in part, why the question of how to manage the release of updates like this is not a settled debate.
> then many people will be in no rush to upgrade, and will get pwned.
The worst case that we may be heading towards is that for any services on public facing infrastructure we might have to automatically apply updates with little or no time to verify, just to try be ahead of the ne'er-do-wells, with even superficial updates not mentioning the changes until a short time after to avoid giving clues to those who will scan for security issues if any such is mentioned (or nothing is mentioned - saying nothing about a security-only update only works if you say nothing about all updates, and you don't want to hold off on security-only updates on a slow moving project that might not have a non-security patch for quite some time).
"90% of professional developers were using AI coding agents at work at least weekly in one form or another (local agents or remote cloud agents), with 68% using them daily."
Re. context:
"The Developer Ecosystem and AI Pulse surveys are localized into eight languages: English, Spanish, Chinese, Japanese, Korean, German, French, and Portuguese. We apply quotas on the required number of responses by region to help achieve accurate global representation. ... The Developer Ecosystem Survey has been statistically reweighted to better represent the global developer population by region, employment status, programming language, and familiarity with JetBrains products"
Fully unclear who, actually, is being surveyed. Developers generally through some industry-wide survey? Or JetBrains users?
(The survey was run on Jetbrains instagram page, apparently. I mean… that is a bit of selection and narrowing going on there)
Notice how half of them have heard about Jetbrains!? I don't know any developers I would be confident know about Jetbrains (even among AI-using developers)
(Also the graphs don't really support the idea that 90% are using them meaningfully for software development.)
I have subscriptions to both, one for personal and one for work use, and I haven't really come close to hitting the limits since the release of Opus 5.5 and GPT-Sol 6.1, and I'm no longer hitting any of the capability limits I used to experience when using the "mid" tier models, so I don't miss using Astra. It feels like limits at pretty much a solved problem right now, for my level of use.
I'm absolutely hitting the limits with 6.1. I'd say maybe hitting them a bit slower than before, but only because the model is dog slow, not because it's more efficient.
How is tracking a women’s world record discrimination or “bending the tournament”? It’s not as if women are being prevented from competing with men. Speedcubing competitions are open, single-category.
It’s not as if women are being prevented from competing with men - I don't know a lot about this, so I automatically assumed they are all segregated. If they aren't I have no problem, everyone is free.
Why is it that every one of these anti-AI screeds that gets upvoted on HN has been clearly written by AI?
Here is one of his posts from 2022:
"Since a long time now I was interested in learning computer graphics and “do stuff” with computer graphics APIs. I began to work on a very simple Game engine in Swift / Metal last year but I began to switch to a Windows machine a few months ago, and Swift / Metal is not compatible with Windows (and will never be I think)."
This is the same person who is apparently now writing:
"It is a transaction where you sell the part of you that was supposed to care. Do that often enough, and it does not come back. That is not burnout, but it is still a disease. Although, like every disease, it spreads: first to your team, then to your product, then to the people using it."
reply