Unfortunately that is not what they proposed. To stretch the automotive analogy too far, you could say: if you invite a carjacker in, their seatbelt is not going to stop them from carjacking you.
Virtual machines are still the best design and has been for something like 20 years
Containers are good, as long as they all share the same purpose (read: same application, no multi-tenant)
We all know that multi-users systems (and thus, containers) have a very wide attack surface, while VM attack surface is very limited ..
This is why I am totally convinced that:
- redhat and friends are a terrible idea (licencing forces collocation which reduces segmentation)
- per-instance pricing (read: cloud public, but not only that) are terrible: for the same reason. Paying per consumed CPU/ram is sane, paying per VM unit is damageful
Linux 2.2 or 2.4 or so (possibly only Suse Linux) even had a kernel startup message "Unix compliance testing by UNIFIX" or something, back when Unix was considered more prestigious than Linux. It is / was by some official definition "a Unix", though not "UNIX the trademark by AT&T".
It's not hard to see ways to escape the container with a cache write primative. I suspect the copy.fail team have held back on releasing a POC because of the disruption it could cause.
It's not a cache write primitive though; it's a write-to-readable-mappings primitive. At least the way I understood it is, you need to be able to get a (read) file descriptor to the target in order to throw it into the splice() syscall.
Now, there are some "funky" no-fs things that could be opened and are mmap'able/spliceable (some stuff in /proc/*, no idea what exactly though), but it's not immediately obvious to me how this is a generic container escape.
You could probably truncate the weights to be much smaller and it would just cause a runtime error. Or replace it with mostly zeros. Unlikely that they checksum the file. But ultimately it is a losing battle -- in browser LLM is coming, and future APIs will expose it to js, and it will become essential.
Great guidance hidden in here for making it expensive for agents to navigate your website. Move elements on screen as the mouse moves, force natural mouse movement to make the UI work, change the button labels in the JS to be randomly named every visit, force scrolling to the bottom of the screen to check for hidden extra tasks...
Hang on, that sounds like common corporate SaaS apps.
It's really weird, I'm seeing across the board that people who never believed in them before are suddenly all into good software eng practices (starting with writing a spec) because of AI.
It's kind of fascinating that we never were willing to do these things for humans but now that AI needs it ... we are all in. A bit depressing in the sense that I think mostly the reason we happy to do it for AI is that we perceive it will benefit us personally rather than some abstract future human.
> It's really weird, I'm seeing across the board that people who never believed in them before are suddenly all into good software eng practices (starting with writing a spec) because of AI.
> It's kind of fascinating that we never were willing to do these things for humans but now that AI needs it ... we are all in. A bit depressing in the sense that I think mostly the reason we happy to do it for AI is that we perceive it will benefit us personally rather than some abstract future human.
I don't think that's the reason.
I think it's because they take time, and few people were willing to put in time for "maybe it'll make writing the actual code faster" gains when the code was going to take a few times longer to write itself.
You also can get faster feedback to iterate on your spec now, which improves the probability of it helping future-you.
So combine that with the fact that the llms are more likely to get lost if you don't spec stuff in advance, and the value of up-front work is higher (whereas a human is more likely to land on the right track, just more slowly than otherwise, making the value harder to quantify).
The problem with up front spec writing was that it created this long, very high risk period where there was no code, no prototype, no hard limits.
So you're arguing back and forth about exactly which fields should be collected where and meanwhile the world is changing around you. The person who insisted on an absolutely minimal signup page has changed jobs, the new hire prioritizes complete data even if it means more signup bounces.
Weeks and months are going by and there's nothing to click on and still nothing to tether the project to reality or limit the scope of debate. High functioning teams can avoid this, but they don't always control who inserts themselves into the conversation.
And of course as soon as coding starts the spec is out of date unless you absolutely nailed it which I've never seen happen in 15 years. Once a user sees the software and gives feedback it probably needs to be rewritten. Maintaining the spec (pre-LLM) was not that much less work than maintaining the software itself. All this time the world around the software is changing and the spec needs to be updated to reflect that.
And while the spec helps in understanding the system, ultimately you still need to understand the code and it.
But now the time between spec and working code is greatly reduced and spec updating can be automated to an extent. The cost is greatly reduced and the benefits have increased, so people like specs now.
What I hated is when you come into an old project. The spec says one thing and the code contradicts it. WTF do you do? I felt more like an archeologist than a programmer.
Yeah I think a lot of pushback to best practices is basic cost/benefit; I like writing documentation, but I'm also often feeling a bit depressed that nobody will actually read it in as much detail as I wrote it. But LLMs do / can.
Actually there's a lot of projection there too; I don't read documentation in detail. And nowadays, I point an LLM at documentation so that it can find the details I would otherwise skip over.
The destruction of the millennial attention span is real, and it's worse in the younger generations, lmao.
Well it's also just that you have a list of 20 features to add, and if it works, you want to ship it, and someone might even get mad if you spend a day dawdling on best practices and documentation and so on. Corporate cultures generally don't have the same long term thinking about reusability and legibility and fault-tolerance that an individual coder may have about the code they want to write once and forget. (Neither do LLMs, for that matter).
My friend at a faang was talking about the "massive overhauls to make everything ready for ai". I asked for an example. He said "basically just documenting the shit out of everything"
I guess that just never occurred to anybody before.
The CEO of Uber made the same comment on Diary of a CEO recently. I think it was for their customer service team if I'm not mistaken, they threw their existing docs at an LLM and it was all over the place because policies were poorly documented and defined. The team is now documenting everything from scratch, focusing on outcomes rather than process - TBD if it works out.
Yeah, someone made the point in a popular post here recently that all the firings are reducing institutional knowledge. IMHO, replacing that knowledge with LLM-written documentation is even more potentially catastrophic. Just from organizations I've worked in, a lot of the useful human knowledge is in knowing how to handle either undocumented edge cases or situations where the documents are outdated or wrong. Working with LLMs and reminding them to update those docs every time? Good luck. And if it's something where the docs touch actual real world operations, that's an area where only human operators with hands-on experience are going to recognize the potential conflicts or cognitive dissonance.
I'm in favor of better documentation generally, and if LLM use does remain pervasive in software I'm sure we'll all live in a new normal where most of the job is documentation of the product and test scenarios. If they ever become cheap enough, I'd expect it to be pretty common to run smoke testing of sorts, pointing the LLM at specs and having it click around to look for discrepancies.
Companies really want to use AI because they can cut the workforce. But today's AI is generally not able to fill in the gaps in processes and documentation a human could. Hence the renewed focus on formalizing everything properly because it's the only way it will work.
Having the humans document the code seems backward (maybe that's not what they're doing, but "make everything ready for ai" sound manual). And hopefully there aren't that many scary surprises that humans need to manually document.
One of the best parts of LLMs is that you can use them to bootstrap your documentation, or scan for outdated things, etc, far more quickly than ever before.
Don't just throw a mountain at it and ask it to get it right, but use a targeted process to identify inconsistencies, duplicates, etc, and then resolve those.
And then you have better onboarding material for the next human OR llm...
Oddly enough, asking an AI to add docs to a classfile explaining "what it does, why it needs to exist, and what uses it" is a great way to include some of the "why". I know it's not ALL the why, but it does a pretty good job of finding the reasons that someone new to the code wouldn't be aware of.
Somewhat by definition, AI-generated docs would only include information that could be obtained elsewhere in the codebase. That can be valuable, but far more valuable is the information you got from debugging all the failed alternative designs that were never committed, etc. Information and context that goes beyond the actual code being read.
My experience is that most people fail to capture this ultra-valuable documentation, but AI never does.
> Having the humans document the code seems backward (maybe that's not what they're doing, but "make everything ready for ai" sound manual).
No, that's forward. Any documentation an AI can make, another AI can regenerate. If an LLM didn't write the code, it shouldn't document it either. You don't want to bake in slop to throw off the next LLM (or person).
We used to document things. Apple had a series of beautiful books documenting ‘Inside Macintosh’. Visual C++ used to come with 14 inches of decent books.
Then books gave way to the web and there was no longer a publishing deadline or copy editor and we just kinda stopped caring. The users still cared, but many producers stopped.
We had an art and we gave it up. Not completely, but substantially.
It would / should / can, but there's big efforts in reducing token consumption now, so AI will likely try to skim and pick documentation just like real humans.
There was a recent effort at work to make it possible for agents to provide up-to-date help on how to do various admin/setup tasks. A very sensible goal: We already have lots of documentation, the problem is that it's scattered everywhere and mostly out of date. Turns out the new solution amounted to someone manually going through it all and painstakingly preparing some Markdown files for consumption by said agent.
Somebody pointed out that those Markdown files might be helpful for people to read directly. Bit of an Emperor's new clothes moment. (I wanted to slap a : rolling_on_the_floor_laughing: reaction on it, but sadly it turns out I'm actually too chickenshit to do that in today's job market.)
My manager just told me that after 12 years of trying to get one of the founders to understand the difference between dev docs and user docs, they tried getting Claude to do it and he finally got it that they are different. He'd been saying this whole time that customer could just read the dev docs. If they could they wouldn't need our software.
I see variations on this too. It's fascinating that there is a class of people who were uninterested in expressive, natural language communication when it was only a way to speak to other people, but who are now super interested in it because it is a way to speak to machines. I worry about the wellbeing of these people -- they seem like prime candidates to slide into AI-induced psychosis.
How firm is the boundary between a dev doc and a user doc in your opinion? I have found that the overlap can be quite large if the users are also technically proficient. Right now I'm trying to balance "how X works so you can use the app better" with "how X works so you can contribute or build your own plugin". DeepWiki really helps as a backstop for anything not already covered though it's not without its own caveats of course.
Not OP but I think you have the right intuition in making a difference between using the app / contribute to the app. You may want to read https://diataxis.fr/ which elaborate on this idea and add another dimension (action / cognition) to this.
Had similar discussion around prompting. Spend years clearly outlining required data inputs, creating forms to dummy proof communication from users. Now that AI is in the picture, users are willing to learn to write elaborate Shakespearean-scale prompts. They are more willing to learn how to communicate to a computer more than how to clearly communicate to a human.
I always knew the dev world leaned more toward interesting technical challenges and interoperability than maximizing the benefit to humanity- it’s why I switched to design. However, I didn’t realize the intensity of that preference until the entire industry got ridiculously AI-pilled.
It’s an interesting psychological phenomenon. It’s like the way I keep my house way tidier since I got a robot vacuum. Pick things up off the floor for aesthetics’ sake? Nah. Pick them up because the vacuum will attempt to eat them and might get sick? Of course!
The trick is that you make it something that humans want to do. Using [0] as an example, the interactive elements move, with context-dependent environment interactions.
I view it more through the lens of serving the right content to the right audience. Markdown is great for agents (and some humans), it is not great for many humans. And it _certainly_ isn't acceptable to some humans that have the job title "designer" ;)
If you want to take the stance that those designers (and people who don't want to consume plain text web) are wrong, sure I guess. But I prefer to take the stance that people and agents should receive content in their desired format.
I had one project where a desktop application deliberately hid the contents of all grid controls from Windows accessibility APIs, took measures to ensure checkbox and radio button selections made through accessibility APIs did not register, and all functions that allowed data to be exported were protected by CAPTCHAs.
Generative AI wasn't a thing at the time, but I had to resort to a combination of OCR, simulated user input, and print capture to drive the application and export data.
Had the developers been aware of the Windows DRM APIs that block screen capture, or the fact that text is easily recoverable from PostScript files with minimal formatting, I don't know what I would have done.
The irony is that the process this replaced involved giving cheap offshore labor full read-only remote access to all data in the system, which was by any measure a far more serious security risk than otherwise authorized employees using tools running locally with no network access provided by established, trustworthy vendors to automate their work.
I think you're right, you can get agents to do what we do -- learn how a website works. Then expose that model as a simple API. There will still be some vision tasks for navigation but they will be just vision tasks, no thinking required.
If you have tool calling complex enough that it necessitates a higher reasoning level, and you would otherwise have reasoning set to "none", this can easily come out to 500ms.
reply