Yeah, but the guy writing the article seems to be bad at math and thinking.
Can I imagine a venue kicking out 2% of their former clients on some criteria? Absolutely yes.
Kicking out 2% of website visitors may still be totally reasonable if the cost to serve them is meaningful, or if they are less than 2% of revenue.
His defense for 98% being bad is that some CSS thing people were arguing about only had 70% coverage on his website.
Our b2b dashboard didn't support Safari for a while at all and it was entirely not an issue because everyone had a simple workaround to just use Chrome and the dashboard wasn't really the main product.
I think the problem being solved here is largely one of waste.
USPS hides 9bn of unfunded pension obligations every year and underserves urban areas to subsidize rural areas.
Mail volume is also generally falling as everything moves to email, so it is getting both less profitable and less critical.
The US is a rich country, we can afford to waste a lot of money and not notice, and of course one person's waste is another person's easier job or subsidized service, but given the ongoing decline in the importance of mail (vs package) delivery, it's not clear that this is a particularly important utility for the government to maintain any more.
The biggest problem with obviously AI driven projects right now is that nobody knows how much expertise you have in this area (seems low given you don't know about systems that do very similar things), nor how carefully you thought about the problem and the implementation.
If I look at a project like Verus I know that experts thought about how to structure the system and it's concrete guarantees and semantics as well as the actual implementation.
So the result is that I trust Verus and I don't trust this.
You description of "design, then use goal and loop prompts to RALPH a feature" makes me even more convinced that this is slop because it sounds like you haven't thought deeply about every line of code and have delegated it to an AI that we all know makes mistakes. Thinking about the design is not really a substitute for thinking about the implementation.
People keep making AI OSS projects and expecting the same reaction as people had to OSS projects before AI, but pre-AI OSS came with a bunch of implicit promises about quality and effort and care that AI projects do not have.
I've interviewed several "I just read design docs and delegate all the actual thinking/analysis to the AI" engineers recently, and they are not grounded enough in reality to know when the AI is telling them something true or false and so confidently show me huge piles of code that purports to do things that I know are just nonsense. At some point I know these folks were good engineers, but they just drank too much of the kool aid.
To be clear, I have some of my own 100% slop projects where I have only vague ideas of what is going on beyond the high level design. But I have that currently put in a containment zone where I can easily verify the outputs or don't care about reliability (it's mostly UIs) and the scale of the damage they can do is minimal. Everything else, while basically still 100% AI generated at this point, is still reviewed and often repeatedly re-prompted to do precisely what I want the code to do, because if you let the coding agents make decisions for you, they still make bad decisions.
See, this goes back to the, all software engineers besides me are wrong, because I see this list and do not think it is anywhere close to a sufficient list for good quality software. The thing about all these criteria is that sometimes they are important, sometimes they are not.
This "standard" exists for the sake of code analysis vendors to be able to have some sort of shared taxonomy, but also provide a fig leaf of standardization to their products.
Most engineers are wrong (I obviously am the true arbiter of taste), but that doesn't mean there isn't better and worse code.
"Does it work" glosses over a bunch of things: is it fast, cheap, secure, reliable, easy to understand, easy to modify? And that's just for server software where you've nailed down all the functional requirements. Determining what the functional requirements is it's own question.
And all these other non-happy path requirements are somewhat in tension with each other, so what is ideal in one environment is not necessarily ideal in another.
And in particular, "easy to understand/modify" is truly subjective. Different people have different ideas of what easy to understand means. Even if we get to a world where AI is writing all our code, "easy to understand/modify for the AI" is still an important question. We've probably all seen prototypes that collapse under their own weight of slop by now.
Iirc Google's solution to this was to make the top of page shopping panel something companies could bid on and then conduct arms length auctions where Google Shopping and its competitors get to bid.
Presumably Google Shopping will be better at matching users to items and be able to big more than most on average, but 3rd parties can still develop an edge in some niches.
Anyway, the EU wasn't satisfied and fined them another 7bn. And obviously competitors like free traffic, not having to pay Google.
I think they have since started removing rich units for things like Flights/Hotels and trying to figure out what product they are allowed to actually provide in the EU.
But in general, they are just going to keep getting sued forever because they have a strong incentive to find the line on how to monetize search and obviously other aggregators do not like this and have the EU on their side.
In general, operating in the EU seems like a mine field where you have to accept that you're going to get shaken down regularly and do the best you can to thread the needle profitably.
Honestly, I don't really know AutoGluon, if this does xgboost tuning that's good.
I do still think ELO scores are still a way to obscure results though. For all we know this is like 0.1% better than a "normal" approach on like 70% of tasks and a tire fire on others.
I have no idea what's going wrong inside Google/Meta, they certainly have capital. But when you need this much cash, not many people are going to be able to have a shot on goal. It would not surprise me if Meta threw in the towel. Microsoft and Apple aren't even trying.
I think the bigger issue is the ever increasing capital requirements, which may cause even the closed weight companies to fall away from the frontier, e.g. Google & Meta are barely hanging on. For Google it feels a bit existential to remain at the frontier, but even then they're barely there.
I hope that we find ways of continuing to improve these models besides continuing to exponentially increase capex spend until all but one of your competitors falls away.
I don't know the legal situation, so maybe they felt like they had to do this to not face liability of some sort, but this feels like the wrong outcome vs e.g. having engineers rewrite it from scratch or move it to a less obviously google affiliated place.
You shouldn't use your employer's branding for unsanctioned projects, so Google is certainly well within their rights, but I think this is unnecessarily conservative vs someone who was trying to promote the employer's mission/products.
I think people are more rational than given credit for. Their decisions are not necessarily rational for the company, but they are often pretty rational for themselves.
And some bureaucracy is often necessary to evaluate security, data protection agreements, etc.
Some companies are not efficiently allocating resources and so projects sit in legal/security review for longer than is reasonable, but it makes sense that individual developers don't have unilateral authority to use 3rd party vendors.