https://pmc.ncbi.nlm.nih.gov/articles/PMC6414251/

I don't think we are biologically far enough removed from "Oh my god, run, bear/snake/lion!"

https://pmc.ncbi.nlm.nih.gov/articles/PMC1376114/

And we may not be built (biologically) for the level of comfort that the majority of us (more so here on hacker news) live in.

I think the doom and gloom serves a purpose for a lot of people.

They are NOT "em-proof" --- what they are is electronic warfare immune.

https://www.newscientist.com/article/2529849-fully-autonomou... Published this year, but talking about a trial 2 years ago.

Blocking any leading edge AI model changes nothing. We (humans) have a long history of determined attackers finding creative and unexpected solutions.

What the AI we have, the stuff that is already PUBLICLY AVAILABLE, is good enough to shrink the time for developing one of those creative solutions into a working tool/weapon.

Edit: https://www.pravda.com.ua/eng/news/2026/06/12/8038963/ They are using ai for terminal guidance on Russian logistics (red vs green reticle if you choose to watch the video). Considering the progress on YOLO (and running on sub watt processors) it being able to do this work "onboard" should be shocking to no one.

Anthropics guardrails are the TSA saying "take off your shoes" while failing every test. https://oversightdemocrats.house.gov/news/press-releases/new...

Anthropic owns the TOS... "If we think your involved in criminal activity were turning all your history over to the FBI/CIA/NSA/Local police". Then if their tooling was so good offering the same agency analysis tools to aid their experts in making some sort of decision.

But their detection isnt that good, and their analysis isnt either... this is pure theater, to create buzz (no such thing as bad press) and make their tool look far better than it is.

The reality is that, they arent even looking for the vectors that pose some of the largest risks in the modern era. And when someone uses it to do something terrible, they did not think of they are going to look dumb.

Except this was going on back in the 90's. https://www.latimes.com/archives/la-xpm-1990-05-27-ca-579-st...

Then it was an informal, local, criminal enterprise. Local promoters, would get tickets from management, to drop to local re-sellers (scalpers, and brokers) and make money on the back side (for management).

With the death of album sales, concerts became the main revenue driver for making money... Formalizing the old system, centralizing it, turning it into a business was just "cleaning up" the mess that used to be there. Look at the Altimont stabbing, and the Rolling Stones role in that (demanding even MORE money and upfront).

Live Nation / TicketMaster is "Bill Graham Presents"... it was his dream and he is a product of that era (go read up on how his partner got stabbed).

Is Live Nation awful... sure. But breaking them up wont change the economics or the system (sadly). Artists are just as much a part of the problem as any fan.

Not true, the C suite cares a LOT about security.

You need that human shield, that person to blame when it does go wrong...

I think what people ARENT doing is interesting.

Usability isn't even in your list, it is not something most people even think of.

The best thing you can do with a prototype is give it to (potential) users and observe what they do with it. Just because you think that you're clearly communicating the intent of your system does not mean you are.

Most people, given a nail gun, cant build a house, thats where the skill is...

Im not someone whose validation came from the lines of code, but from the resulting working system.

This is why there are a ton of corps running the open source models in house... Known costs, known performance, upgrade as you see fit. The consumer backlash against 4o was noted by a few orgs, and they saw the writing on the wall... they didnt want to develop against a platform built on quicksand (see openweb, apps on Facebook and a host of other examples).

There are people out there making smart AI business decisions, to have control over performance and costs.

From "scrum masters" to "planing poker" it's all very silly.

2003: Nvidia accused of cheating in 3DMark 03 https://www.gamespot.com/articles/nvidia-accused-of-cheating...

It's almost like the benchmarks were designed with zero understanding of the history of benchmark manipulation.

I like what LLM's are doing and providing. But the industry as a whole seems to live in a vacuum that ignores so much of the hard lessons that have been learned over the last 50 years of computing. It is doing itself a disservice.

SQS is dead simple, and if your in AWS (forever) it is "in the stack" with some easy to use features that may make sense to you (delay queue is a great one).

Kafka is... a lot. If you need what it provides, then it's great. You just have to be able to support it, and thats non trivial.

I can point to more than a hand full of Kafka project that exist because it was clear that someone wanted it on their resume. I dont think any one is doing that with SQS, it is just (a fairly good utility). However if you want to leave (or branch out from) AWS and you're reliant on it, good luck.

ZScalar No PE

Palo Alto Networks Inc (PANW) 86 PE

Fortinet : (FTNT) 31.63 PE

That last one, didn't get hit at all by the Mythos announcement, because at some level it has at least some grounding in fiscal reality.

Your argument for host os, virtual os, container is the very point im making. Rather than solve for security and installablity, we built more tooling, more layers of abstraction. Each have overhead, security surface and complexity.

Rather than solve Rusts performance (at build time), switch to a language that is faster but has more overhead, more security surface, more complexity.

You have broken down the stack of turtles that we have built to avoid solving the problem, at the base level...

SABRE, what the article is discussing, is the polar opposite of this, it gives us a hint that more layers of abstraction arent always the path to solutions.

How many banks and ERP's, how many accounting systems are still running COBOL scripts? (A lot).

Think about modern web infrastructure and how we deploy...

cpu -> hypervisor -> vm -> container -> run time -> library code -> your code

Do we really need to stack all these turtles (abstractions) just to get instructions to a CPU?

Every one of those layers has offshoots to other abstractions, tools and functionality that only adds to the complexity and convolution. Languages like Rust and Go compiling down to an executable are a step, revisiting how we deploy (the container layer) is probably on the table next... The use case for "serverless" is there (and edge compute), but the costs are still backwards because the software hasn't caught up yet.

Payment processing, is better than it was in 2000, but still not good.

Micropayments: this is obnoxiously expensive to do.

Discovery, and discoverability: again here we have better but not good solutions (and many of the ones that were once good are enshitified).

Pricing: this is a problem everywhere, and frankly we need the law to change in a way that is pro consumer. Publishing prices, disclosure of fees, in both services and for payment processing (that 3 percent back from visa looks a lot less attractive when it's part of a 5 percent mark up).

Customer service: well there are already companies promoting models where they cut you off and send you into a black hole (google is a prime example). Good customer service will become a differentiator, and maybe a "paid for" service as well.

> We are creating not only a new kind of Git client,

Nope, not going to be the tool of the future.

The fundamental problem is it is still based on git.

Till this addresses submodules and makes them a first class citizen it's just tooling on top of a VCS that still ONLY supports single project thinking.

Im saying that in the before time, complexity emerged over time (staff changes, feature creep). AI coding (and its volume) is just speed running this issue.

Time, feature changes, bugs, emergent needs of the system all drive these sorts of changes.

No amount of "clean code" is going to eliminate these problems in the long term.

All AI is doing is speed running your code base into a legacy system (like the one you describe).

It's leaning in a good direction, but the author clearly lacks the language and understanding to articulate the actual problem, or a solution. They simply dont know what they dont know.

> Human effort is still a moat.

Also slightly off the mark. If I sat one down with all the equipment and supplies to make a pair of pants, the majority of you (by a massive margin) are going to produce a terrible pair of pants.

Thats not due to lack of effort, rather lack of skill.

> judgement is as important as ever,

Not important, critical. And it is a product of skill and experience.

Usability (a word often unused), cost, utility, are all the things that people want in a product. Reliability is a requirement: to quote the social network "we dont crash". And if you want to keep pace, maintainability.

> issue devs would run into before AI - the codebase becomes an incoherent mess

The big ball of mud (https://www.laputan.org/mud/ ) is 27 years old, and still applies. But all code bases have a tendency to acquire cruft (from edge cases) that don't have good in line explanations, that lack durable artifacts. Find me an old code base and I bet you that we can find a comment referencing a bug number in a system that no longer exists.

We might as an industry need to be honest that we need to be better librarians and archivists as well.

That having been said, the article should get credit, it is at least trying to start to have the conversations that we should be having and are not.

I think a "clean" and "contemporary" version of this would look amazing as well:

Along the lines of: https://www.modustrialmaker.com/blog/2018/8/14/making-an-imp...

Maybe with: (for weight) https://en.wikipedia.org/wiki/Foam_concrete (there are plenty of DIY versions of this: https://www.youtube.com/watch?v=z4_GxPHwqkA