Author here. Tell me more. How do you use NCD and what is your concern about its application here? Should I have use da larger reference sample? You can test it in action here: https://dejan.ai/tools/ai/ (e.g. drop a claude article or GLM article in and see what it says, it's not perfect but reasonably good).
The LLMs play a part, but it’s the tempo; the pace.
Fully autonomous w/LLM isn’t true. Leadership wants it true. The technological capabilities and acceptance of scapegoating a machine got rejected by society, so that leaves perfectly capable individuals as the gatekeepers of decision making, completely overloaded by the amount of information they need to deal with.
If you as a human can’t keep up, but the onslaught continues, and you’ll be held responsible for the outcome regardless… yeah. People will punch their ticket out. It’s not unique to LLMs, but LLMs have certainly automated the process of reaching the worst possible conclusion.
Don’t for a second try to hold the computers accountable or blame them for this outcome. This is a leadership issue and always will be. Believing otherwise is just allowing suicides to be scapegoated as a computer’s doing.
It doesn't matter if its fully autonomous or not. You taking something that was both esoteric and highly skilled to something that any rando with an LLM could do. And so yeah expectations for output are going to increase exponentially, but not entirely unreasonably so, all the while any appreciation or value of your own skillset is going to head right into the gutter.
I don't see how you can say this is a leadership issue because the tech itself is creating a scenario that's going to leave plenty of people in crisis. The same will happen in programming. People are clinging onto the hope that it won't matter that much because 80% of a programmer's job, at a large company, doesn't involve coding anyhow, but even there the reason for the high comp is that 20%, as that's where the barrier to entry is. As that barrier falls, skill relevance plummets, and expectations rise.
An ssh server would exploit a vulnerability in the ssh client when it connects.
For example, openssh has both a client and server. There’s been vulnerabilities in openssh, in the client. Those vulnerabilities aren’t reachable unless you’re connecting to a server attempting to exploit you, so the risk is quite low because you know and trust most servers you’re connecting to with ssh.
To sum it up: Connecting to this server is probably fine, but in doing so most people are doing something significantly riskier without realizing it.
There has never been a real-world OpenSSH exploit that allows a server to RCE a client that connected to it without a bunch of dubious qualifiers. Connecting to a random SSH server is much, much less dangerous than running a random binary or executing a random curl install script, both of which people do all the time, and is probably about on par with the likelihood of a random website escaping your browser's sandbox and RCEing you.
Agreed, bugs in the terminal emulator are probably more concerning. The attack surface of those is much larger (there are some pretty wild ANSI escape sequences, and terminal emulators are often granted pretty wide disk access permissions on systems that have them if they're also used for local development).
Web browsers are generally built with security in mind. Terminal emulators surely much less so. The OpenSSH client probably sits somewhat in between, generally developed with security in mind, but not necessarily consistently expecting malicious servers.
At least for the more prominent terminal emulators i expect they probably devote a great deal of attention to security. They are developing the most commonly used interfaces for linking the most numerous, varied, and/or critical systems on the planet.
I believe the recent cve-2026-55200 in libssh2 (client-side library) was allowing exactly this.
https://nvd.nist.gov/vuln/detail/cve-2026-55200
("Remote attackers can send crafted SSH packets with excessively large packet_length values to corrupt heap memory and achieve remote code execution.")
Of course the other abouts that you whatted (such as random curl install scripts, binaries, etc.) are still more dangerous.
> The integer overflow provides uncontrolled access to the heap, which reliably crashes the client process but is unlikely to achieve remote code execution in practice. Weaponizing the overflow for code execution would require a separate information disclosure vulnerability to defeat ASLR, along with a specific heap layout to place exploitable structures adjacent to the undersized allocation.
---
> abouts that you whatted
"Whataboutism" is perhaps the most infuriating and wildly misused word in the English language. Pointing out that somebody is scaremongering about an action that is significantly less dangerous than other everyday actions people take on their computers is not a fallacy. It is directly relevant to evaluating risk. Yes, technically there could be some critical bug that allows the posited thing to happen, but in reality it just doesn't happen. If it did happen, nobody would blow their once-in-decades exploit on pranking some people on a forum.
Isn't this exploit vector identical to the ones we'd expect on browser-based vulnerabilities? I believe that yes, there are possible risks involved, but no significant than our casual web-surfing through the net.
This AI generated article about closed-weights model providers collaborating for additional scrutiny of open weights models, where the article itself has the tell-tale structure of being written by Claude Opus, which is aware it is a closed-weight model.
Thank goodness no one is taking any of this seriously, because it could never be anything more than a machine generated hatchet job.
A faster and better educated understanding of the subject matter could be achieved by standing in front of a wood chipper and dropping a brick in it to see what happens. “Yes, there were results! But why? Why to literally every variable involved?”
“However, large-scale, covert industrial distillation aimed at stealing proprietary U.S. technology and undermining American research is unacceptable.”
What’s actually happening behind the scenes is that certain inference providers will classify a prompt and it’s re-routed transparently to Anthropic and that’s used for distillation training, only distilling the complicated traces they need, originating from real user prompts and traces. These inference providers are explicitly blocked in the claude cli if you reverse engineer it.
The real picture is that these Chinese labs have figured out how to get exactly what they need, at a high quality, directly from distinct and unique real user prompts.
It’s only “covert” because Anthropic doesn’t like it, while simultaneously being perfectly fine to do.
> What’s actually happening behind the scenes is that certain inference providers will classify a prompt and it’s re-routed transparently to Anthropic and that’s used for distillation training
Uh, no. There are Chinese networks of tens thousands of fake identities specifically to get access to Anthropic models directly.
But while we’re “guessing”: Xiaomi MiMO