Because AI cannot retain memories or gain experience or insight based on the transformer/attention mechanism powering all modern AI models, it follows that AI lacks judgment and can never be trusted to handle truly critical decision-making responsibilities. Furthermore, AI agents lack any notion of an identity, so certainly are not capable of attaining legal personhood or being sued or fired, or owning property. I think slop burnout, cybersecurity, loss of privacy, even environment issues are far more concerning and real issues arising from AI than alignment or the prospect of mass labor displacement due to AI.
What you want is to guard at the outset of each API call is the same thing -- whether the user is not suspended, active, any other number of things (including more things as you add more functionality), so you want to shift the entire validation logic to its own module.
We therefore want to encapsulate the logic of all users being "qualified". I think the best way to realize this is to try to say in as few words as possible what we want. We want the user.toBe.qualified, but we can write that even more efficiently, user.isQualified(), so we can ASK at the top of each API `if !user.isQualified()` and then fail loudly and quickly if so, and then go do something afterwards otherwise. We presumably expect multiple users that will have a property of being qualified, so let's use a class:
```js
class User {
constructor(data) {
this.isAuthenticated = data.isAuthenticated;
this.hasActiveLicense = data.hasActiveLicense;
\\ many more details...
}
// Now encapsulate the boolean property of being qualified, for all Users, in one place
// Now, we can use our isQualified() property at each of our API guard clause by checking if the user is NOT qualified:
if (!user.isQualified()) {
return res.status(403).json({ "error": "Unauthorized access requested."});
}
// Critically, the API guard clause remains identical even if we change the criteria for validation and what it means to be "qualified"
```
There are of course many other ways to solve this problem beyond this approach. For instance, you could export a function called isUserQualified(user) (or more likely userId) then call it somewhat similarly:
```js
if (!isUserQualified(user)) {
return res.status(403).send("Error: Unauthorized access requested");
}
```
The other approach I like is to use a factory pattern to build a userSession with function arrow notation. That's really helpful when you are getting raw data back from a database call, say as a JSON object. That would look like this:
```js
const createUserSession = (userData) => {
return {
...userData, // here we use the ...notation for convenience but don't trust this as secure)
isQualified() {
return (
this.isAuthorized && !this.isSuspended
);
}
};
};
// Then you instantiate a user session from the request like this:
const user = createUserSession(res.session.user);
if (!user.isQualified()) {
return res.status(403).send("Error: Unauthorized");
}
```
There are actually loads other approaches too, like using class inheritance (define a parent User class and child QualifiedUser class, for instance), or types. I would say that readability here is less a concern than the issue that you have multiple APIs and if you refactor or change the logic for qualified users, now you have to refactor your most sensitive attack surface at multiple points. It's just safer to have that rewrite only happening once, wherever you put it, in my view.
So basically there are two plausible explanations:
1. Someone with early access to Mythos leaked it to the bad guys.
2. Cybercriminals are getting enough mileage out of alternatives to Mythos to create exploits far more quickly, even though they don't have access to Mythos.
My own guess is that it's a combination of #2 plus vibe-coding degrading software quality at multiple layers, open the door to sophisticated exploits, but I have no insider access to Mythos so am just guessing. Maybe someone with Mythos access might say why they think this vulnerability spike happened when it did.
I disagree that the title "hides" that the title was small and that it disappeared for two weeks. The surviving contingent on the E. americana strain was evaluated for 60 days, and the tumor doesn't look particularly small based on the picture on page 8 of the paper. I think the study size is small (n=5) so we'd like to see more large-scale studies next, but it's already a strong result to show 5/5 (100%) at p < 0.0001 for multiple primary endpoints and the absence of success from comparable bacteria is helpful to frame future research. The absence of long-term side effects and only transient weight-loss followed by 15-day weight gain is also intriguing. I'm not a doctor, oncologist, or cancer researcher, but the methodology looks sound and appropriate to me, as does the title, based on reading the paper.
I always felt a little duped whenever I tried coding in TypeScript. You get zero runtime type safety guarantees, plus it's often harder to tell in TypeScript whether the transpilation will result in an efficient and performant implementation. Maybe the worst thing is that if you have two objects, one called EmailAddress and one called UnrelatedThing, but both have a UUID as the first thing and a string as the second thing, and now you create an object at runtime that is called TotallyUnrelatedThing that has a UUID followed by a string, the runtime sees EmailAddress, UnrelatedThing, and TotallyUnrelatedThing as being structurally identical and in fact they are all "compatible" under TS at runtime, which is usually the exact opposite of what one would expect. Now in other languages you can get some additional guarantees like in C# at the cost of more ceremony and boilerplate to establish all your abstract primitives and layers.
My own approach is mostly to prefer JS and JSON objects with helper chains including validators and constructor/builder and parser utilities. Get the age from the user and get the domain from the email address and don't be surprised by the type, because everything is an object, and don't be surprised that you need to validate and parse, but expect to do so always. Do it in as modular and reusable a pattern as makes sense, which often isn't exactly the same for every scenario, but that's OK. Speaking of which, am I the only one who thinks it's usually more of a hassle than it's worth to define a universal EmailAddress for all times and places? Often the conflict happens because even if I try to do so, I usually am using one vendor as an IdP and a different vendor for transactional emails (even if I use the same cloud provider say for both). They each probably have different robust regex implementations to check whether something is truly an email address. I then still need authEmailAddrees and billingEmailAddress objects to pass to each, respectively, but there is no enforcement or requirement to instantiate an interface that contains an enforceable contract in TypeScript, so remind me why I am bothering to say these things are both email addresses? It just always feels like the worst of all worlds when I work in TypeScript, kind of a "rules for thee but not for me" situation. I have to follow typing, but TypeScript doesn't quite have to do so. In particular it always feels like I still have to enforce a lot more validation at the API layer than should be required, without any feeling that I can trust an EmailAddress to instantiate an IEmailAddress interface or that AuthEmailAddress and BillingEmailAddress inherit from the base EmailAddress or that those structures are guaranteed to persist at runtime and that a TotallyUnrelatedThing that just so happens to have a UUID plus a string but isn't strictly instantiating the email class will never accidentally end up populating an email field, which is kind of a concern. (By the way I think the hardcore email address validation really ought to be handled by the upstream provider anyway. I just do some minimal checks on length and presence of dots and at-symbols but don't bother trying to implement a full regex compendium of all email possibilities since these details frankly conflict frequently enough at the edges that I would rather let my IdP and email providers decide for themselves if they truly have an acceptable email input, and handle the failure loudly and up front, rather than try to do all the gatekeeping myself.)
ChatGPT is completely unplayable at chess on its own. It's unable to keep track of the state of the chess position and therefore will make an illegal move within about 10-12 moves. I would put GPT-5.5's rating at 400, since it can't even make legal moves reliably.
I've tried to pay chess with GPT-5.5, even played it again tonight, allowing it to use `python-chess` to keep track of the state of the position and to get a list of legal moves at each turn, so that it was fair. I also gave it blindfold odds, again to make it a fair fight, but it was not even close. GPT still isn't better than maybe 1000 Elo, maybe 1200 tops. Even with what amounts to being able to see the position and also being unable to make an illegal move, GPT-5.5 hangs material left and right, doesn't make a plan, and got smoked even when I gave it blindfold odds, to the point it's boring for me to play even under those conditions. I'm not sure it's better than whatever the GPT model was that was out about 8 months ago. I also thought it might be somewhat better than a beginner due to reading chess books, but no, it's complete garbage at playing chess, not even average-level skill.
I don't think Fargate fits for the use case they are describing. If you're running your own (trusted) code, then of course there's no reason to worry about containment threats. But the threat here is that you have to execute arbitrary, untrusted code that is presumptively malicious. It's a very different scenario and requires considerable measures to safeguard properly. You can't have a Fargate Task that runs multiple containers, one for each user, for instance, or even run multiple Fargate Task instances, one for each user, because you're still having them all share a virtual EC2 host (well technically a pool of EC2 servers but it's one hypervisor and shared virtual kernel, essentially) that would be compromised if any one container escapes. If you need true hypervisor-level host kernel isolation on a per-user basis due to the risk of containment, with guest worker microVM threads, plus the whole thing needs to scale and also needs to pause and restore very quickly and keep track of state upon restoration, it's actually a pretty hard challenge to build on AWS with existing tools. The problem arises with any interactive AI agent environment that scales on a per-user basis, for instance, but it also applies to any scenario in which the user needs to execute untrusted arbitrary code on your infrastructure in a sandbox. Fargate isn't the secure choice in that scenario; you would instead use VPC + EC2 + Firecracker + Docker (plus S3 and many others) and use a lot of orchestration scripting and fiddling with load balancers and the like to try to get everything working and scaling. When you combine it with tracking state and also restoring quickly from a paused or suspended state, I can see reasons why this might be the right choice if you want to implement something with an interactive AI agent that isolates at the per-user or per-session layer from the host kernel and is highly secured against containment escape and other vulnerabilities. I'm curious if anyone has used this for the use case described, maybe from AWS? Is this like the AgentCore orchestration that came out maybe like last year?
AI infrastructure/tools developer and researcher here (hic-ai.com). I fully agree with Armin's concerns.
I wrote an article recently (https://hic-ai.com/blog/tool-response-engineering) in which I argued that AI tool-engineering is the new frontier beyond prompts, and it talks about the agent loop and engineering loops, but boy I have a completely different perspective than Boris's. Rather than contending that prompts are no longer relevant because we can simply have AI think for us by having loops "prompt Claude and figuring out what to do", like what Boris claimed, I believe we have to think much harder now.
Why problems require human judgment and can't just be offloaded to an AI agent is simply this: AI agents lack durable, long-lasting, unique identities forged by real-world memories and experience, and they therefore lack judgment. There is no well-defined notion of having AI agents communicate to each other because they can't even tell the difference between talking to their future self or talking to another agent! They certainly don't reliably weigh whether a proposed fix to a failing unit test will subtly introduce new fallback logic that was never requested or otherwise alter the functionality of the system under test in some manner, or whether now is the time to refactor or now is the time not to refactor or whether to abstract more or less or anything like that. Most importantly, from a practical perspective: AI agents lack legal person status, and they therefore cannot own property or money, sue or be sued, be hired or fired, or otherwise be held financially responsible for their errors or other harmful acts they commit. Clearly, AI agents cannot even arguably qualify for legal personhood status in the future, unless and until they first are capable of assuming a unique and durable long-term identity, which in turn requires solving auth, memory, communications, and many other technical issues that are neither resolved nor standardized today. These facts combine to ensure that AI agents cannot be held liable and financially responsible when things go wrong, meaning that humans alone bear the costs of AI errors until further notice, and thus, human judgment remains the vital commodity that AI cannot replace. So many problems arise from abdicating judgment to AI agent in 2026!
Now, if all the above items were in existence, built, well-settled, etc., maybe I'd have to rethink things. But unless and until AI agents have unique identities and attain legal person status with bank accounts that can be sued and garnished in case of error, I don't think AI agents can seriously be trusted. Good human judgment and approval of all important decisions will remain the most important resource for any successful enterprise, for the foreseeable future. I think it's a very serious mistake to assume that human judgment can be swapped out safely by AI and certainly advise against taking Boris literally. Anyway, great article.
AI infrastructure/tools developer here (www.hic-ai.com). I considered the A2A protocol carefully, but I decided a while ago that, from my perspective, the A2A protocol was not solving the correct problem. There is no distinction (from the perspective of an agent) between a communication from Agent A to Agent B, on the one hand, and a communication from Agent A to "future Agent A", on the other. In fact, agents have no inherent sense of identity at all, so there is no inherent notion of a unique Agent A. The notions like "Agent A" received a message or that "Agent A" is sending a message to a different agent (or to its future self) are all inextricably intertwined with the idea of an agentic identity existing and being well defined in the first place, which it is not. The A2A protocol assumes the existence of such a well-defined agent identity in its presumption that agent cards point to a specific agent that can be discovered and deployed. I also think gRPC adds a significant layer of indirection and obfuscation, plus it's painful to implement. The lack of widespread adoption suggests that A2A is not really solving a real-world problem, compared to MCP, for instance.
Docker doesn't provide any security. You install Docker on your local laptop, and the container you spin up when you execute `docker run` interacts with your laptop's kernel directly. It provides logical isolation between containers but provides zero protection for your host kernel (assuming you decide to install Docker on a remote server instead).
Firecracker provides an isolation between the host kernel, on the one hand, and the guest microVM, on the other hand. So on AWS, you use an Amazon Machine Image (AMI) to specify the OS and other components and libraries installed on an EC2 server such as c5.metal, or if you're using nested virtualization, you can use c8i, s8i, or m8i instances at a discount of about 80%-90% at some performance and other cost, and you bundle Linux along with the Firecracker binary. Then you compile a build artifact including `rootfs` for the Firecracker baked image which is the microVM image (analogous to a Docker image that results from executing `docker build`). But the microVM process has its own virtual kernel and is a guest on the host machine. So for instance, you can place Docker inside the microVM, then the container is executing against the microVM kernel, not the host EC2 kernel. Communication is achieved securely between the two using `vsock` and probably something like `socat` so that data travels, say, from guest RAM to host RAM directly to an S3 quarantine bucket, for instance, without ever touching the host's kernel or filespace.
Ok, I was curious enough to read look into this, but it makes no sense under the hood. The idea is essentially that:
1. Supply-chain problems affect the Rust ecosystem arguably even worse than npm.
2. `stdx` extends Rust by adding some other stuff in Go that's good for supply-chain security?
3. crates.io does stuff differently than stdx so that's why it's distributed exclusively via git.
But none of the README or article linked by the author or the other article linked in the README explain anything about what the good things from Go are that are actually added, or what the pain point precisely is compared to using crates.io. I think the first proposition is possibly correct, mainly because I know next to nothing about Rust but am all too familiar with supply-chain complaints (as are most of us by now) whether as to npm or Python ecosystems, and there is no principled reason why Rust should be more secure unless the fundamental assumption of trusting external packages to auto-update safely is somehow different in Rust. I assume without loss of generality that perhaps the author is right that Rust's package management ecosystem is no more secure as a supply-chain than Node.js's ecosystem. The second property also might be true too that Go offers some concrete solutions to the problem, though I have no idea if that's correct and wouldn't necessarily assume that to be true.
Still, even assuming all claims to be true, I do not see is any connection between those claims and actual implementation of code, aside from talk about how stdx is AI-friendly and was generated using AI. I just don't get what this does that is any different. You're still trusting a Git repository to be valid. In fact it almost sounds at one point like the author is suggesting that the whole exercise of providing proof of provenance and demonstrating that a particular version was properly published by its author is too tedious and annoying and should therefore be skipped by utilizing a simpler stdx approach to Rust (but I still don't know what that is or why I should trust it!). Is it just me? This makes no sense.
Cool article! I'm working on a tangentially related issue requiring microVMs inside isolated infrastructure environments. Latency isn't really my main priority, but I am always tempted by any option to minimize attack surface. I wonder what it would take to replace the host block mount in this configuration with `vsock` for all communications between the host and guest microVM? Then you could avoid any files being mounted on the host at all while still enabling, e.g., one-way egress to a pre-signed S3 URL via a private VPC endpoint. Very cool article!
This is so cool; I wonder what the roadmap includes? I'd love to see if this could evolve from gag product/gift idea, to a solar-powered inference box on slightly more robust hardware, for instance, completely freeing the owner from any need to purchase a subscription or rely upon the grid for inference. That would be freaking cool and I'm sure would sell a ton if the models that could run on the hardware were sufficiently capable and could be piped into a laptop (which seems like the easiest part). What would the power requirements be to run a more capable model than the ones used, maybe a DeepSeek open-source model? Really curious but I'm unfamiliar with the technical details that might go into such calculations.
For a superb explanation of Niven's proof (which leaves more questions than answers when you first read it), I like Michael Penn's video: https://youtu.be/dFKbVTHK4tU?is=d2DbV5HDP0IpP9tA ....notwithstanding the length of the proof, this is quite a hard problem.
You are so consumed, with absolute certainty, of the permanent and eternal correctness of your moral position, that you literally say you would rather throw away personal connections to human beings than be triggered by the presence of ideas or things.
Please reconsider. I'm not even going to try to persuade you that you're wrong about AI because it isn't even relevant. The truth is that if you carry out your plan, you will just end up being an incredibly hurtful person towards a lot of folks who probably have no idea why you are abandoning them and now feel isolated, hurt, and confused.
Also, ask yourself how sure you are, that you're going to be right for all time, about AI, which is a brand-new technology. Maybe you know yourself. Your views seem incredibly rigid and perhaps you really will never change your mind no matter what AI becomes. But if you ever have changed your mind about anything ever, again, please consider whether the harmful course of action you are describing is worth the extraordinary harm you seem eager to effectuate on everyone who disagrees.
Honestly I don't know why I bothered typing out of any of this. I doubt the author cares. I just wish people like this author would consider that their words and actions do actual harm to real people. And, by the way, zero harm to the progress of AI. Just hurtful and dumb.
Very nice research. The strangest detail to me is that alignment and test performance appear to be slightly negatively correlated: Better alignment can indeed be attained through pre-training, but at a cost of degraded performance of about 4% on average. This strikes me as surprising as there is no immediately obvious reason why training for alignment ought to result in degraded capability to solve technical problems -- unless. What if the issue is precisely that? Alignment roughly aims to make LLMs follow human instructions. But if humans are dumb and computers still have to obey them, maybe the result is degraded logical reasoning? Really interesting result either way but the negative correlation is the most fascinating detail to me.
Right. Put differently, we have that FPSan() is a well-defined function, so [ f = g ] => [ FPSan(f) = FPSan(g)], but we need to show that FPSan() is injective, i.e., [ FPSan(f) = FPSan(g) ] => [ f = g ]. I confess I haven't looked very closely but it should not be so hard. We can prove injectibility in the alternative by analyzing ker(FPSan()), the set of all inputs in the domain of functions mapping to the identity element in the co-domain. If the kernel is trivial and only consists of the identity map, the injectibility is established, but I am not immediately seeing the proof. Fun!
The bottom line is that AI is genuinely useful at prototyping new features, acting as a sounding board, and generating quick initial drafts, even if the quality isn't uniformly excellent. It seems plausible to conclude that it will only take a little additional effort to refine and improve that initial draft to achieve excellence and truly high-quality, production-grade code. In reality, whole processes to build properly with AI-generated outputs and that mitigate thoroughly against the fundamental limitations and constraints of AI agents (many of which are not well understood even by daily users) really need to be invented and implemented.
I think many things that were true prior to AI are still true or more so today, but new workflows and processes altogether are needed. I suspect that comprehensive, detailed planning and specification documentation must be assembled in advance of beginning code (akin to waterfall) when working with AI agents. Furthermore, I still believe customers and other key stakeholders need to be involved early and often so that the product can iterate towards a better ultimate end state (i.e., agile). Unlike prior to AI, it's completely plausible to implement both types of approaches, and they aren't mutually exclusive. We can do comprehensive, exhaustive, thorough planning and specification documentation prior to handing off to dedicated engineering and products teams, AND we can work quickly and iteratively via sprints that aim for frequent meetings and updates with the stakeholders that matter.
I also think the same validation gates that mattered before -- linting, SASTs, but most importantly, comprehensive automated testing that gets run locally and in CI/CD and is regularly expanded to cover all expectations about the behavior and structure of newly-implemented functionality -- continue to matter now, more than ever.
New tools and processes also must be built to make human review, the single biggest bottleneck in software development today, more simplified and streamlined, and less taxing. I think tools like CodeRabbit and Qodo can help automate and expedite the code-review and approval processes, but they would be even better if they were working off more surgical and tiny edits. Bloated, verbose AI-generated code edits are the core problem here. Process management techniques to mitigate the problem of AI code overload can prohibit the submission of AI-generated PRs, require senior engineer approval of any PRs prior to merging, or block the maximum number of lines or changes made. More sophisticated processes like Graphite's stacking of PRs are genuinely helpful in breaking down massive PRs into smaller chunks.
Finally, precision-editing tools for AI coding assistants like HIC Mouse (full disclosure, my project) that move beyond the existing options available to AI agents of whole-file replacement or exact string-replacement to enable agents at the editing-tool layer to perform surgical, tiny changes that don't touch any unrelated content, giving agents specialized visibility, recovery, and next-step guidance mechanisms that safeguard AI workflows, can materially reduce AI code slop by alleviating burdens upstream of code reviewers, both automated and human.
The bottom line: Shipping secure, production-grade code was never easy and always took a long time. It's not necessarily easier now just because certain aspects to the overall process can be generated much more rapidly. Arguably, the hardest parts like human review and approval are much harder now -- not easier. Solutions will take hard work and must be tested in the crucible of real-world enterprise usage. I am guessing that companies that deploy successful processes will be wildly profitable. Those that don't, including well-established incumbents, will fail. I do think AI absolutely can give organizations a game-changing boost in development velocity of genuinely high-quality code that might even be better than anything ever created previously. I also fully agree with the author that for many organizations, AI will not make their processes go faster and may even slow things down.
I'm a fan of removing any dependencies on external libraries and writing my own solution from scratch, but there's a good reason why I decided not to do so with Tailwind: They offer an optimization for production that ensures that you never ship more than the bare minimum of CSS needed. This means you can keep your palette of color, spacing, and other options fully enumerated in `globals.css` and elsewhere, without worrying whether you're using all those variants in production. Moreover, if you're working within a framework, such as Next.js, this minimization step automatically happens when you build, without even having to worry about whether it's happening. This alone is a compelling reason, at least for me, not to migrate from Tailwind.
Also, I've never found any restrictions in Tailwind in using inline CSS that weren't readily navigable, or in implementing really nice responsive grids that handle different screen widths for instance using Tailwind's grid tooling. I definitely have solved each of the scenarios described in this article using Tailwind or a Tailwind-CSS combination, but it's true that they don't have grid-column-areas natively. Still, I haven't yet found that to be a significant restriction in getting responsive grid layouts.
I think the biggest issue with Tailwind is simply that it takes a long time to get used to reading it. We all learn that inline CSS is bad, globally scoped CSS is best, etc., and we get used to seeing clean simple HTML. Then we look at real-world code featuring Tailwind and it just looks so hard to read at first, especially because the lines are so long. I guess I just have been using it long enough that I've gotten completely used to the way it looks, but I do remember it took me a very long time to get comfortable with reading Tailwind. After a long while, I concluded that, for me, Tailwind really is more efficient and maintainable and even more readable, but it definitely took quite a bit.