The poster probably hopes (as many of us do) that people will absorb the sentiment and post less of this junk in the future.

Not by the analogy laid out in the article.

I'm curious, who/what is operating the frontier LLM in this scenario?

The rest of the article is equally incoherent.

From what I can tell, LLMs know/use patterns above the syntax and idioms of specific languages and the syntax and idioms of specific languages and how to apply the former to the latter.

The bottleneck isn't what languages the LLM can handle, but what I can handle coming out of the LLM. The general advice, then, is to use the language (and related setup/environment) you're familiar with.

The search infrastructure you're talking about is a natural part of that, but, like any infrastructure, it scales the organization it's supporting. Kagi is tiny so their "original infrastructure" contributions are tiny.

Put another way, you essentially were investing in infrastructure, but you were hoping for major infrastructure and what is happening is small infrastructure. Kagi would probably need to get much bigger to be able to do the infrastructure you're talking about. (And if they were much bigger, it should be natural -- at a certain scale it will make more sense to do your own than work with someone else's.)

It wouldn't surprise me if AMD is scaling back their free offerings due to the impact on support.

I suppose all the money floating around AI helps dummify everything, as people glom on to narratives, regardless of merit, that might position them to partake.

What we actually have now is the ability to bang out decent quality code really fast and cheaply.

This is massive, a huge change, one which upends numerous assumptions about the business of software development.

...and it only leaves us to work through every other aspect of software development.

The approach this article advocates is to essentially pretend none of this exists. Simple, but will rarely produce anything of value.

This paragraph from the post gives you the gist of it:

> ...we need to remove humans-in-the-loop, reduce coordination, friction, bureaucracy, and gate-keeping. We need a virtually infinite supply of requirements, engineers acting as pseudo-product designers, owning entire streams of work, with the purview to make autonomous decisions. Rework is almost free so we shouldn’t make an effort to prevent incorrect work from happening.

As if the only reason we ever had POs or designers or business teams, or built consensus between multiple people, or communicated with others, or reviewed designs and code, or tested software, was because it took individual engineers too long to bang out decent code.

AI has just gotten people completely lost. Or I guess just made it apparent they were lost the whole time?

Someone would have to do a bunch of work to establish these things.

It's pretty clearly a type of argument called an "appeal to authority", where an authority is cited to add credibility to a position. It's usually considered a pretty weak form of argument, but it can be effective. So the credibility of the cited authority is relevant.

I don't think many would say the same for LLMs.

Maybe vibe bun is just as good or better than old bun, but how would we know at this point?

> ...we couldn’t have known if the author of a piece of software was proceeding with rigor...we didn’t judge someone’s software by inspecting their methodology...

That's not true. First, some people do directly check whether a project has a level of rigor they are comfortable with before adopting it (or when deciding whether to continue using it). I personally do it, where it matters. Many more use reputation signals, which, while certainly not perfect, correlate, may be good enough, and are a lot easier than direct, manual reviews.

When deciding to support a given thing, you have to make a determination as to whether it's worth the effort or not.

You don't simply ignore unknowns. That effectively means assigning the unknowns zero cost, which is unlikely to turn out to be true. Generally, the more unknowns, the higher the risk, and the higher the risk, the higher the estimated cost.

There are a lot of unknowns about vibe bun right now.

One effective strategy for dealing with unknowns is to turn them into knowns if you can. Here, that probably means waiting to see how vibe bun turns out.

If it turns out to be stable and highly compatible, at some point in the future, they can always pick up support then.

AI has real benefits, that are game-changing in some areas, even if AI never improve from their current capabilities.

People are claiming (whether they truly believe it or not) that AI has incredible capabilities and benefits that they don't currently have, and may never have.

There's plenty of scamming going on. The fact that AI has real game-changing capabilities just makes the scams harder to detect. People tend to like to see things as more black-and-white than they actually are, and scammers take advantage of that.

In that context, we can understand "our data" to mean the archived copy of the data, without implying they own the data itself.

Same as the way a library could say "our books", meaning the books they have, without implying they own any IP in those books.

"Ironic" probably isn't the right word. I think there's just some confusion about context here. Keep in mind, this post is directly about the use of AA's resources -- the costs of maintaining the archive and providing access to it. This is valuable to the training of models.

I'm not exactly going to get outraged at the NYT's rhetorical tactics against vaping.

Yes, and that's not uncommon, IME. There's generally a lot of logging that's at least potentially available, and it gets turned on, and the logs shared when there's a problem that needs to be fixed (especially when it needs to be fixed quickly, which is usual).

This is going to make more sense for "enterprise"-type deployments, where there's a significant distinction between the people who might have access to request logs at times, and the people who can push code to production.

Hashing client-side is a good idea. You must also hash server-side, for storage/comparison.

Otherwise, an insider may be able to harvest the original password, from logs, proxies, load balancers, etc. that requests pass through after the end of the TLS connection, on the way to the db.

They can then try the credentials on other, perhaps more lucrative sites. That's what the brothers are accused of doing here, so client-side hashing (or just simple encryption) may have been the missing piece of security that would have thwarted the credential stealing.

Otherwise, there's a hole, between the end of the TLS connection and where the server-side encryption happens, where the password is in plain text. Think logs and load-balancers and proxies.

While the client-side hashing doesn't help protect your site a lot (as you say, the hashed value the client sends effectively becomes the password), it helps protect the users who use the same password across multiple sites.

Notice in this case, that's exactly what the brothers are accused of doing: using credentials harvested from their site to log into other, potentially more lucrative accounts.

I didn't see if that's the hole the brothers exploited but it very well could have been.

The client-side encryption may have been all that was missing in this case.

I guess someone will be selling enterprises something that lets them say, "We're doing AI too!" Might as well be gitlab?

Why not stop there?

You've got some awareness that there's something other people know that you don't.

Better to ask a question than express an opinion based on ignorance, right?