> OpenClaw has nearly half a million lines of code, 53 config files, and over 70 dependencies. This breaks the basic premise of open source security. Chromium has 35+ million lines, but you trust Google’s review processes. Most open source projects work the other way: they stay small enough that many eyes can actually review them. Nobody has reviewed OpenClaw’s 400,000 lines.
This reminds me of a very common thing posted here (and elsewhere, e.g. Twitter) to promote how good LLMs are and how they're going to take over programming: the number of lines of code they produce.
As if every competent programmer suddenly forgot the whole idea of LoC being a terrible metric to measure productivity or -even worse- software quality. Or the idea that software is meant to written to be readable (to water down "Programs are meant to be read by humans and only incidentally for computers to execute" a bit). Or even Bill Gates' infamous "Measuring programming progress by lines of code is like measuring aircraft building progress by weight".
Even if you believe that AI will -somehow- take over the whole task completely so that no human will need to read code anymore, there is still the issue that the AIs will need to be able to read that code and AIs are much worse at doing that (especially with their limited context sizes) than generating code, so it still remains a problem to use LoCs as such a measure even if all you care are about the driest "does X do the thing i want?" aspect, ignoring other quality concerns.
Like if you had told pg to his face in (pre AI) office hours “I’m producing a thousand lines of code an hour”, I’m pretty sure he’d have laughed and pointed out how pointless that metric was?
I don't understand how some people decide here, who the good programmers are. A lot of people reminded me a guy from West Palm Beach, who votes on elections solely on the principle of who has more "fame". Paul Graham is famous for sure (at least in HN circles), but I never considered him an exceptional or good programmer at all. So I always interpreted his words with a hefty amount of grain of salt. And sometimes some comments have a list of "good" coders, then half of them is like these famous, but not good ones.
> Paul Graham is famous for sure (at least in HN circles), but I never considered him an exceptional or good programmer at all.
pg wrote a Lisp dialect, Arc, with Morris. The Morris from "the Morris worm". These people are at the very least hackers and they definitely know how to code.
I don't think a "not good programmer" can write a Lisp dialect. At least of all the "not good" programmers I met in my life, 0% of them could have written a Lisp dialect.
It's not because Arc didn't reach the level of fame of Linux or Quake or Kubernetes or whatever that pg is not a good programmer.
I met a coder, who has several self made programming languages, and I would never allow him anywhere near any codebases for which I'm responsible. So writing a Lisp dialect, is not something which makes you a good coder for sure. Even as a junior you can do that. Making it good, and be able to really reason for choices is a different story. I've never seen any good new reasoning from Graham like for example how Dan Abramov do all the time. They are not even close, and definitely not in favor of Graham.
It's not about Peter. Of course, he's a great programmer. The point is that you can follow nicely written tutorials and have your own in a very short period of time. It's not particularly difficult to build a Lisp.
Presumably he got better in the intervening decades, but part of how we stopped the Morris Worm was that it was badly written (see the various version of With Microscope and Tweezers for detail, particularly about the "am I already running" check that ended up being why it got noticed, "because exponential growth".) Even for "bored 1st year grad student skipping lectures" it should have been better code :-)
(Also, writing a Scheme dialect was a first-semester CS problem set - if you're in a 1980s academic CS environment it was more effort to not accidentally write a lisp interpreter into something, something in the water supply...)
I take him to be a good programmer on top of a pioneer venture capitalist and entrepreneur but Hackers and Painters contains some pretty bad predictions and takes on programming, and if he didn't have that good foresight then, it has probably become worse with the years.
Hm, I do not read the statement as a hyped "this is how everyone should write code now" rather as a statement of fact. "A experienced programmer he knows uses LLMs to generate thounds LOC/h". That does not say whether those lines will actually be shipped anywhere or just exist for testing purposes/prototyping.
Who is signaling what virtues to whom in this context?
When I see PG write something like that, it signals to me that he has embraced AI hype to the point that he is displaying poor taste and embracing a risky technical practice.
I imagine PG is rich enough and influential enough in the tech/VC space that he doesn't have to signal anything he doesn't honestly believe.
It's unsurprising he would believe LLM coding tools are a productivity boon, but using code quantity as a measure of software development progress is one of the most famously wrong ideas in the software world. Either he wrote carelessly, or he believes that LLM tools have changed that reality.
I'm inclined to think LLM tools haven't substantially changed that reality. LLMs perform better when more of the problem fits in context, so succinctness remains valuable.
Somehow, this narrative has taken hold at multiple levels of management, especially amongst non-technical management, that "typing" was somehow the bottleneck of software engineering, reality is however more complex.
The act of "typing" code was technically mixed in with researching solutions, which means that code often took a different shape or design based on the outcome of that activity. However, this nuance has been typically ignored for faff, with the outcome that management thinks that producing X lines of code can be done "quickly", and people disagreeing with said statements are heretics who should be burned at the stake.
This is why, in my personal opinion, AI makes me only 20% productive, I often find disagreeing with the solution that it came up with and instead of having to steer it to obtain the outcome I want, I just end up rewriting the code myself. On the other hand, for prototypes where I don't care about understanding the code at all, it is more of a bigger time saver.
I could not care about the code at all, and while that is acceptable to management, not being responsible for the code but being responsible for the outcomes seems to be the same shit as being given responsibilities without autonomy, which is not something I can agree with.
AI is good at the first 80% but terrible at the last 20% of producing good code. And you need to through that first 80% to really understand what the code is scaffolded to do, which writing it yourself will vastly improve. And typing speed has never been the bottleneck for coding.
Even worse, whole generation of devs are being trained to not care of learn about that last 20% because the AI does it """all""" for them. That last bit is an unknown unknown for the neo developer nee prompter.
More people believe a software developer job and value is in the lines of code produced.
Perhaps over half of engineering managers unconsciously or admittedly take the amount of PR and code additions as a rough but valid measure of productivity.
I recall a role in architecture, senior director asking me how come a principal engineer didn't commit any code in 2 weeks, that we pay principals a fortune.
I asked that brilliant mind whether we paid principal engineers to code or to make sure we deliver value.
Needless to say the with question went unanswered, so called Principal was fired a few months later. The entire company in fact was sold for a bargain too given it had thousands of clients globally.
The LLM can replace engineers is a phenomenon that converge from two simple facts, we haven't solved the misconception of the engineering roles. And it's the perfect scapegoat to justify layoffs.
Leaders haven't all gone insane, they answer to difficult questions with the narrative of least resistance.
> Leaders haven't all gone insane, they answer to difficult questions with the narrative of least resistance.
Brilliantly said. I’d like to add - a distorted narrative actively, intentionally established and maintained by the entities profiting from the technology. Quite similar to the crypto scam hype cycle.
> This translates to an average throughput of 3.5 PRs per engineer per day, and surprisingly the throughput has increased as the team has grown to now seven engineers.
Several related reasons working at once. The nature of work changed. The boundary between accidental and incidental complexity shifted (and it’s unclear whether this distinction still exists). Niche specializations within the field emerged. The way to structure and decompose projects changed dramatically (agile and stuff).
One pathological example: if you’re running a server-based product, quite often what stands between you and a new feature launch is literally couple of thousands of lines of Kubernetes YAML. Would adding someone who’s proficient in Kubernetes slow you down? Of course not.
One may say, hey, this is just the server-side Kubernetes-based development being insane, and I’ll say, the whole modern business of software development is like this.
That’s a lovely comment, thank you. If you’re keen to think about it more, consider the fact that the existing members of the project that’s being late are actually in not as much of an advantage compared to the new joiners, as it’s common to think.
Yes, they know how the feature they work on relates to other features, but actually implementing that feature is very often mostly involves fighting with technology, wrangling the entire stack into the shape you need.
In Brooks’s times the stack was paper-thin, almost nonexistent. In modern times it’s not, and adding someone who knows the technology, but doesn’t have the domain knowledge related to your feature still helps you. It doesn’t slow you down.
One may argue that I’m again pointing to the difference between accidental and incidental complexity, and my argument is essentially “accidental complexity takes over”, but accidental complexity actually does influence your feature too, by defining what’s possible and what’s not.
I sort of agree that the surface area and incidental complexity of stacks give more space to plug more developers in than was true in the 70s and 80s. But I disagree strongly this invalidates Brooks Law. Certainly there are cases where adding people helps, especially if they are stronger engineers than the ones that are already there, but I’ve also seen way too many projects devolve into resourcing conversations when the real problem was over-complicated, poorly reasoned requirements, boil-the-ocean solutions promising a perfect end state without a clear plan to get there iteratively.
As lines of code become executable line noise, I swear that we need better approaches to developing software - either enforce better test coverage across the board, develop and use languages where it’s exceedingly hard to end up with improper states, or sandbox the frick out of runtimes and permissions.
Just as an example, I should easily be able to give each program an allowlist of network endpoints they’re allowed to use for inbound and outgoing traffic and sandbox them to specific directories and control resource access EASILY. Docker at least gets some of those right, but most desktop OSes feel like the Wild West even when compared to the permissions model of iOS.
“LoC is a bad metric” has been the catchphrase of engineers for years, because it runs counter to the expectations of management and the general public, right? So it makes sense that LoC is the metric used to advertise to them.
LLMs are incredibly eager to write new code, rather than modifying or integrating with existing systems. I agree that context windows are too small currently for this to seem sustainable. Without reasonable architecture pure vibe coded software feels like it’s going to cap out at a certain size.
As mentioned elsewhere in the thread, there is very clearly an obsession with quantity over quality. Not a new phenomenon by any means: people were already complaining about this in the 19th century! But it has reached a new absurd height with this latest trend.
It’s definitely an issue when using coding assistants.
If you are careful and specific you can keep things reasonable, but even when I am careful and do consolidattion / factoring passes, have rigid separation of concerns, etc I find that the LLM code is bigger than mine, mainly for two reasons:
1) more extensive inline documentation
2) more complete expression of the APIs across concerns, as well as stricter separation.
2.5 often, also a bit of demonstrative structure that could be more concise but exists in a less compact form to demonstrate it’s purpose and function (high degree of cleverness avoidance)
All in all, if you don’t just let it run amok, you can end up with better code and increased productivity in the same stroke, but I find it comes at about a 15% plumpness penalty, offset by readability and obvious functionality.
Oh, forgot to mention, I always make it clean room most of the code it might want to pull in from libraries, except extremely core standard libraries, or for the really heavy stuff like Bluetooth / WiFi protocol stacks etc.
I find a lot of library type code ends up withering away with successive cleanup passes, because it wasn’t really necessary just cognitively easier to implement a prototype. With refinement, the functionality ends up burrowing in, often becoming part of the data structure where it really belonged in the first place.
The lines of code thing isn't because we think it's a good metric, but because we have literally no good metric and we're trying to communicate a velocity difference. If you invent a new metric that doesn't have LoC's problems while being as easy to use, you'll be a household name in software engineering in short order.
Also, AI is better at reading code than writing it, but the overhead to FIND code is real.
That's because they're an additive tool. Everything boils down to "adding" more code. But in the long term its not about how much code you can add but how little you can get away with. But this is an impossible task for the LLMs. How would you train one not to write code? What would the training data look like? Would that be all the lines of code that haven't been written?
That’s not an impossible task with LLMs, you just have to mindfully architect the project with that in mind, hence take it slowly to design a good system, don’t outsource all thinking to LLMs.
Well they will train on my Claude Code sessions for a start. I spend a lot of time asking it to remove unnecessary code that was produced, I'm not the only one.
I've been waiting for someone to say this. An agent will generally produce far more code than technically necessary for the task. It's a kind of over engineering which makes it increasingly harder to wrap your head around the codebase.
Really it just continues to demonstrate that "code quality" is not and was not a requirement.
Even with supposedly expert human hand written software powering our products for the last decades, they frequently crash, have outages, and show all sorts of smaller bugs.
There are literally too many examples to count of video games being released with nigh-unplayable amounts of bugs and still selling millions and producing sequels.
Windows 95 and friends were famously buggy and crash prone yet produced one of the most valuable companies in the world.
Respectfully, it feels like your position requires a very low, if not brain-dead level of incompetence on the part of LLM users, in order for your conclusion to be correct.
My personal anecdote: I used an LLM recently to basically vibe code a password manager.
Now, I’ve been a software engineer for 20 years. I’m very familiar with the process of code review and how to dive in to someone else’s code and get a feel for what’s happening, and how to spot issues. So when I say the LLM produced thousands of lines of working code in a very short time (probably at least 10 times faster than I would have done it), you could easily point at me and say “ha, look at ninkendo, he thinks more lines of code equals better!” And walk away feeling smug. Like, in your mind perhaps you think the result is an unmaintainable mess, and that the only thing I’m gushing about is the LOC count.
But here’s the thing: it actually did a good job. I was personally reviewing the code the whole time. And believe me when I say, the resulting product is actually good. The code is readable and obvious, it put clean separation of responsibilities into different crates (I’m using rust) and it wrote tons of tests, which actually validate behavior. It’s very near the quality level of what I would have been able to do. And I’m not half bad. (I’ve been coding in rust in particular, professionally for about 2 years now, on top of the ~20 years of other professional programming experience before that.)
My takeaway is that as a professional engineer, my job is going to be shifting from doing the actual code writing, to managing an LLM as if it’s my pair programming partner and it has the keyboard. I feel sad for the loss of the actual practice of coding, but it’s all over but the mourning at this point. This tech is here to stay.
This whole reply, and every other "anecdote" reply is more worthless than the pixels its printed on, without a link to your "actually did a good job" password manager.
(wow funny how these vibe code apps always are copies of something theres many open source versions of already)
Ugh, you made me spend the 20 minutes it takes to spin up a new github account to share this (my existing one uses my real name and I don't really want to doxx myself that much. Not that it's a huge deal, my real identity and the "ninkendo" handle have been intertwined a lot in the past.)
I'm not saying it's perfect, there's some things I would've done differently in the code. It's also not even close to done/complete, but it has:
- A background agent that keeps the unsealed vault in-memory
- A CLI for basic CRUD
- Encryption for the on-disk layout that uses reasonably good standards (pbkdf2 with 600,000 iterations, etc)
- Sync with any server that supports webdav+etags+mTLS auth (I just take care of this out of band, I had the LLM whip up the nginx config though)
- A very basic firefox extension that will fill passwords (I only did 2 or 3 rounds of prompting for that one, I'm going to add more later)
Every commit that was vibe-coded contains the prompt I gave to Codex, so you can reproduce the entire development yourself if you want... A few of the prompts were actually constructed by ChatGPT 5.2. (It started out as a conversation with ChatGPT about what the sync protocol would look like for a password manager in a way that is conflict-free, and eventually I just said "ok give me a prompt I can give to codex to get a basic repo going" and then I just kept building from there.)
Also full disclosure, it had originally put all the code for each crate in a single lib.rs, so I had it split the crates into more modules for readability, before I published but after I made the initial comment in this thread.
I haven't decided if I want to take this all the way to something I actually use full time, yet. I just saw the 1password subscription increase and decided "wait what if I just vibe-coded my own?" (I also don't think it's even close to worthy of a "Show HN", because literally anybody could have done this.)
> Did you investigate prior art before setting out on this endeavor
Lol no, I had no idea there was any other password managers! Thanks for the google search link! I didn't know search engines existed either!
> Wisdom means knowing when and where to apply cleverness, and where not to. like being able to recognize existing sub-components.
It says literally in the README that part of this is an exercise in seeing what an LLM can do. I am in no way suggesting anyone use this (because there's a bazillion other password managers already) nor would I even have made this public if you hadn't baited me into doing it.
The fact that there's a literal sea of password managers out there is why I'm curious enough to think "maybe a one that I get to design myself, written to exactly my tastes and my tastes alone could be feasible", and that's what this exercise is about. It literally took me less time to vibe-code what I have right now, than to pour through the sea of options that already exist to decide which one I should try. And having it be mine at the end means that I can implement my pet features the way I want, without having to worry one bit about fighting with upstream maintainers. It's also just fun. I thoroughly enjoy the process of thinking about the design and iterating on it.
If you didn't like me telling you about search engines you probably won't like me telling you how git clone works BUT...
For all intents and purposes, (in the context of diddling around with a password manager you might use yourself and wouldn't recommend to anyone), Any/all of those existing open source password managers can ALSO be yours just as much as the output from any LLM.
I'm serious, not only can you tweak them to "your tastes and your tastes alone", you don't have to even tell upstream maintainers what you're doing let alone get it merged.
So if you’re just going to complain about me reinventing the wheel (even though I already explained this is literally an exercise to see what an LLM can do), can we at least recognize the goalpost shift here?
I’m just going to assume that you’ve completely conceded your original point then, since you have absolutely zero to say about whether you agree the LLM did good work or not. Since the moment I showed you its work, you immediately shifted to insulting my intelligence for bothering with a password manager in the first place.
I honestly don’t know why I bother feeding trolls like you when it’s clear your only goal here is to find fault.
If we're talking about goalposts, lets also recognize the Motte and Bailey of initial claims of "20 years professional software engineer actually good password manager" to "hee hee toy project testing how LLms work not complete not even for personal not recmmond for others"
I don't think your password manager is good, and I don't think you think it's good either or you'd be using it.
I'm not trolling. It's way cheaper and faster to just clone an existing project if you want to mess around with making a password manager suit your taste.
My goal is to mess around with an LLM, not just to mess around with a password manager. If you read literally any of my posts in this thread without the intention of throwing shade, maybe you would have gotten that point by now. I’ve certainly repeated it enough times.
> I don't think your password manager is good, and I don't think you think it's good either or you'd be using it.
Lol I am using it now though. In the time from yesterday’s post to now I have an iOS app, an iOS Password Autofill extension, a Mac app and the existing Linux CLI and Firefox browser extension. Automatically syncs conflict-free between everything too, using a simple web server for sync. It now covers every use case 1Password did for me, and no, none of the “rust password manager site:github.com” results do any of this.
It was an experiment to see if the effort of vibe coding a password manager would be easy enough that it would be worth doing, and guess what: resounding success. Cope more.
I don't deny it. When I said "mess around with making a password manager suit your taste" feel free to append " while using and getting experience with an LLM". nothing changes.
im glad you're dogfooding your pw manager now. I'm glad vibe coding met your own standard of quality.
I will leave it as an exercise to you to think about all the edge cases and usability issues that have been solved in mainstream pw managers that you've never thought about. I hope you keep your LLM subscription active so you can fix them as they come up. And to keep up with updates from IOS and firefox as they come out.
applies when there is a sea of "prior art" on the topic requested. And that request (prompt) is actually framed/worded properly to match that prior art.
Which may be perfect if the target is reduceable to prior-art. Re-use, Mix-and-match, from opensource or stackoverflow, into my-own-flavour-hot-water, finally!
No, this is not sarcasm. i hate to (catch myself a month later) reinventing hot-water. Let something else do it.
The question that stays with me is, How to keep the brain-bits needed for that inventing / making new stuff , alive and kicking.. because they will definitely deteriorate towards zero or even negative. Should we reinvent each 10th thing? just for the mental-gym-nastics?
If you measure the productivity of the system that is “you, using an LLM” in terms of the rate at which you can get actually-reviewed code completed (which, based on your comment, seems to be what you were doing) that seems like a totally reasonable way of doing things. But in that case the bottleneck is probably you reviewing code, right? Which, I bet, is faster than writing code. But you probably won’t get the truly absurd superhuman speed ups.
What would you say is your multiplier, in terms of throughly reviewing code vs writing it from scratch?
Yeah, I guess that's kinda my point. LLM detractors on HN seem to straw-man what they think the average LLM user is doing. I'm an experienced programmer who is using an LLM as a speed boost, and the result of that is that it produces thousands of lines of code in a short time.
The impressive thing isn't merely that it produces thousands of lines of code, it's that I've reviewed the code, it's pretty good, it works, and I'm getting use out of the resulting project.
> What would you say is your multiplier, in terms of throughly reviewing code vs writing it from scratch?
I'd say about 10x. More than that (and closer to 100x) if I'm only giving the code a cursory glance (sometimes I just look at the git diff, it looks pretty damned reasonable to me, and I commit it without diving that deep into the review. But I sometimes do something similar when reviewing coworkers' code!)
I don't know if it is incompetence - if anything i doubt it, someone else pointed out that pg also used that metric and i don't think pg is incompetent. However at the same time i think it is misleading at best.
My impression is that, as someone else wrote, we do not have an actual metric for such things as productivity or quality or what have you, but some people do want to communicate that they feel (regardless of if that matches reality) using an LLM is better/faster/easier and they latch to the (wrong) assumption about more LoC == better/faster that non-programmers already believed for years (intentionally or not, they may also deluding themselves) as that is an easy path to convince them that the new toys have value that applies to the non-programmers too (note that i explicitly ignore the perspective of the "toymakers" as those have further incentives to promote their products).
Personally i also have about 2 decades of professional experience (more if counting non-professional) and i've been toying with LLMs now and then. I do find them interesting and when i use them for coding tasks, i absolutely find useful cases for them, i like to have them (where possible) write all sorts of code that i could write myself but i just don't feel like doing so and i do find them useful for stuff i'm not particularly interested in exploring but want to have anyway (usually Python stuff) and i'm sure i'll find more uses for them in the future. Depending on the case and specifics i may even say that in very particular situations i can do things faster using LLMs (though it is not a given and personally that is not much of a requirement nor something i have anywhere high in my interest when it comes to using LLMs - i'd rather have them produce better code slower, than dummy/pointless/repetitive code faster).
However one thing i never thought about was how "great" it is that they generate a lot of lines of code per whatever time interval. If anything i'd prefer it if they generated less line of code and i'd consider an LLM (or any other AI-ish system) "smarter" if they could figure out how to do that without needing hand holding from me. Because of this, i just can't see LoCs as anything but a very bad metric - which is the same as when the code is written by humans.
How can you say that when all these models are externally sourced by companies that actively make a loss per token? When they finally need to make a profit, how can we be sure these models as well as their owners will remain as reliable and not enshittified? Anthropic has been blacklisted in the last 24 hours so its a turbulent industry to say the least
When enshittification happens we would just simply go back to code by hand, then. We programmers don't lose the ability to do so when we use LLM, right ?
Yeah, I would view this as a “levels of maturity” thing. It’s not completely misguided to judge a JD on whether they shipped 0loc or 1kloc. Assuming you have some quality counter-metric like “the app works”.
For staff engineers it’s obviously completely nonsense, many don’t code and just ship architecture docs. Or you can ship a net negative refactor. Etc.
So this should tell you that LLMs are still in “savant JD” territory.
That said, being given permission to ship more lines of code under existing enterprise quality bars _is_ a meaningful signal.
A question I've been asking myself and which I honestly want to put out there - and I apologize in advance, because you will see me repeat it in other threads, out of genuine curiosity:
Does your life have so much friction that you need a digital agent to act on your behalf?
Some of the use cases I saw on the OpenClaw website, like "checking me into a flight", are non-issues for me.
I work in business automation, but paradoxically I don't think too much about annoyances in my private life. Everything feels rather frictionless.
In business, I see opportunities to solve friction and that's how I make money, but even then, often there are barriers that are very hard to surmount:
(a) problems are complex to solve and require complex solutions such as deterministic or ML systems that LLMs are not even close to being able to create ad-hoc
(b) entrenched processes and incumbent organizations create moats that are hard to cross (ex: LinkedIn makes automation very hard)
(c) some degree of friction, in some cases, may actually be useful!
I imagine there are similar dynamics in the consumer space, but more than anything, I may not be seeing issues with such a critical eye (I like to relax after work, after all)
So, do you have problems in your private life that you'd want to take on the risks - and friction - of maintaining these agents?
Similar CV, similar take. My guess? Anyone involved in automation for >2 years at the enterprise levels knows in their gut all the silent, sudden, annoying ways automation can fail and so has a higher internal bar for "must save this much time to be worth automating."
That said, old beliefs should be challenged by new technological capabilities!
If LLM based automation is (a) less fragile and (b) quicker to develop, then that bar should be lowered.
I don't get it either. I even sat down to try it out and see what it's all about, but I can't think of a single thing in my life that I want an agent to automate.
Summarizing news? No, I'd rather just read it. Besides, it's hard to say what will or won't be interesting at any given moment.
Reply to emails? No, I want to make sure I say what I mean to say and I don't see why I would tell the whole story to an LLM just so it could rephrase it all.
Trade stocks? Dear God no! That's a good way to lose my life savings, and if the solution is to just put in a little then what's the point?
Every video and post I see talking about all the things they have automated with agents are things I would never want. Most of them describe content farms - look at what's hot on Twitter, generate a video, post to Reddit, etc. Others like preparing a morning summary are neat and all but so what? If my life was so hectic that I needed a personal assistant to take my calls and book my meetings, I'd hire one.
Seriously, what is the thing that agents can do that every ordinary person just can't live without?
My take is that agents should only take actions that you can recover from by default. You can gradually give it more permission and build guardrails such as extra LLM auditing, time boxed whitelisted domains etc. That's what I'm experimenting with https://github.com/lobu-ai/lobu
1. Don't let it send emails from your personal account, only let it draft email and share the link with you.
2. Use incremental snapshots and if agent bricks itself (often does with Openclaw if you give it access to change config) just do /revert to last snapshot. I use VolumeSnapshot for lobu.ai.
3. Don't let your agents see any secret. Swap the placeholder secrets at your gateway and put human in the loop for secrets you care about.
4. Don't let your agents have outbound network directly. It should only talk to your proxy which has strict whitelisted domains. There will be cases the agent needs to talk to different domains and I use time-box limits. (Only allow certain domains for current session 5 minutes and at the end of the session look up all the URLs it accessed.) You can also use tool hooks to audit the calls with LLM to make sure that's not triggered via a prompt injection attack.
Last but last least, use proper VMs like Kata Containers and Firecrackers. Not just Docker containers in production.
That's a decent practice from the lens of reducing blast radius. It becomes harder when you start thinking about unattended systems that don't have you in the loop.
One problem I'm finding discussion about automation or semi-automation in this space is that there's many different use cases for many different people: a software developer deploying an agent in production vs an economist using Claude Vs a scientist throwing a swarm to deal with common ML exploratory tasks.
Many of the recommendations will feel too much or too little complexity for what people need and the fundamentals get lost: intent for design, control, the ability to collaborate if necessary, fast iteration due to an easy feedback loop.
AI Evals, sandboxing, observability seem like 3 key pillars to maintain intent in automation but how to help these different audiences be safely productive while fast and speak the same language when they need to product build together is what is mostly occupying my thoughts (and practical tests).
Current LLMs are nowhere near qualified to be autonomous without a human in the loop. They just aren't rigorous enough. Especially the "scientist throwing a swarm to deal with common ML exploratory tasks." The judgement of most steps in the exploratory task require human feedback based on the domain of study.
> Many of the recommendations will feel too much or too little complexity for what people need and the fundamentals get lost: intent for design, control, the ability to collaborate if necessary, fast iteration due to an easy feedback loop.
Completely agreed. This is because LLMs are atrocious at judgement and guiding the sequence of exploration is critically dependent on judgement.
I'd like to try a pattern where agents only have access to read-only tools. They can read you emails, read your notes, read your texts, maybe even browse the internet with only GET requests...
But any action with side-effects ends up in a Tasks list, completely isolated. The agent can't send an email, they don't have such a tool. But they can prepare a reply and put it in the tasks list. Then I proof-read and approve/send myself.
There is no real such thing as a read only GET request if we are talking about security issues here. Payloads with secrets can still be exfiltrated, and a server you don’t control can do what it wants when it gets the request.
GET and POST are merely suggestions to the server. A GET request still has query parameters; even if the server is playing by the book, an agent can still end up requesting GET http://angelic-service.example.com/api/v1/innocuous-thing?pa... and now your `dangerous-secret` is in the server logs.
You can try proxying and whitelisting its requests but the properly paranoid option is sneaker-netting necessary information (say, the documentation for libraries; a local package index) to a separate machine.
The proxy approach for secret injection is the right mental model, but it only works if the proxy itself is hardened against prompt injection. An agent that can't access secrets directly can still be manipulated into crafting requests that leak data through side channels — URL params, timing, error messages.
The deeper issue: most of these guardrails assume the threat is accidental (agent goes off the rails) rather than adversarial (something in the agent's context is actively trying to manipulate it). Time-boxed domain whitelists help with the latter but the audit loop at session end is still reactive.
The /revert snapshot idea is underrated though. Reversibility should be the first constraint, not an afterthought.
> but it only works if the proxy itself is hardened against prompt injection.
Yes, I'm experimenting using a small model like Haiku to double check if the request looks good. It adds quite a bit of latency but it might be the right approach.
Honestly; it's still pretty much like early days of self driving cars. You can see the car can go without you supervising it but still you need to keep an eye on where it's going.
> 1. Don't let it send emails from your personal account, only let it draft email and share the link with you.
Right now there's no way to have fine-grained draft/read only perms on most email providers or email clients. If it can read your email it can send email.
> 3. Don't let your agents see any secret. Swap the placeholder secrets at your gateway and put human in the loop for secrets you care about.
harder than you might think. openclaw found my browser cookies. (I ran it on a vm so no serious cookies found, but still)
> Right now there's no way to have fine-grained draft/read only perms on most email providers or email clients. If it can read your email it can send email.
> harder than you might think. openclaw found my browser cookies. (I ran it on a vm so no serious cookies found, but still)
You should never give any secrets to your agents, like your Gmail access tokens. Whenever agents needs to take an action, it should perform the request and your proxy should check if the action is allowed and set the secrets on the fly.
That means agents should not have access to internet without a proxy, which has proper guardrails. Openclaw doesn't have this model unfortunately so I had to build a multi-tenant version of Openclaw with a gateway system to implement these security boundaries.
> That means agents should not have access to internet without a proxy, which has proper guardrails. Openclaw doesn't have this model unfortunately so I had to build a multi-tenant version of Openclaw with a gateway system to implement these security boundaries.
I wonder how long until we see a startup offering such a proxy as a service.
This doesn’t really feel like enough guardrails to prevent the type of problems we’ve seen so far.
For example an agent in a single container which has access to an email inbox, can still do a lot of damage if that agent goes off the rails.
We agree this agent should not be trusted, yet the ideas proposed as a solution are insufficient. We need a fundamentally different approach.
Also and this is just my ignorance about Claws, but if we allow an agent permission to rewrite its code to implement skills, what stops it from removing whatever guardrails exist in that codebase?
I did my best to communicate this but I guess it was still missed:
NanoClaw is not software that you should run out of the box. It is designed as a sort of framework that gives a solid foundation for you to build your own custom version.
The idea is not that you toggle on a bunch of features and run it. You should customize, review, and make sure that the code does what you want.
So you should not trust the coding agents that they didn't break the security model while adding discord. But after discord is added, you review the code changes and verify that it's correct. And because even after adding discord you still only have 2-3k loc, it's actually something you can realistically do.
Additionally, the skills were originally a bit ad-hoc. Now they are full working, tested and reviewed reference implementations. Code is separate from markdown files. When adding a new integration or messaging channel, the agent uses `git merge` to merge the changes in, rather than rewriting from scratch. Adding the first channel is fully deterministic. The agent only resolves merge conflicts if there are any.
So, nanoclaw requires agents to code extensions on the fly to get to feature parity with openclaw… and you're celebrating nanoclaw having fewer LOC. How's the code smell after nanoclaw gets to feature parity?
The point is to be able to choose the (presumably small) subset of features you actually want, and have a tractable review problem. Presumably people who really want openclaw would just use openclaw.
Yeah, the article's claim of having a low number of lines of code are disingenuous. Rather than writing some sort of plugin interface, it has "skills" that are a combination of pre-written typescript and English language instructions for how to modify the codebase to include the feature. I don't see how self-modifying code that uses a RNG to generate changes is going to be better for security than a proper plugin system. And everyone who uses Nanoclaw will have a customized version of it, so any bugs reported on Nanoclaw probably have a high chance of being closed as "can't reproduce". Why would you live this way?
Yes and and they still have code examples in them so its not like it somehow doesn't count. Plus if you run the skill good luck bringing in changes from master later.
I think the best place to put barriers in place is at the mcp / tool layer. The email inbox mcp should have guardrails to prevent damage. Those guardrails could be fine grained permissions, but could also be an adversarial model dedicated to prevent misuse.
Wouldn't you get >50% of the usefulness and 0% of the risk if you add read+draft permissions for the email connection through a proxy or oauth permissions? Then your claw can draft replies and you have to manually review+send. It's not a perfect PA that way, but could still be better than doing everything yourself for the vast majority of people who don't have a PA anyway?
It feels like, just like SWEs do with AI, we should treat the claw as an enthusiastic junior: let it do stuff, but always review before you merge (or in this case: send).
I agree, this is inherently unsafe. The two core security issues for agents, I’d say, are in LLMs not producing a “deterministic” outcome, and prompt injection.
Prompt injection is _probably_ solvable if something like [1] ever finds a mainstream implementation and adoption, but agents not being deterministic, as in “do not only what I’ve told you to do, but also how I meant it”, all while assuming perfect context retention, is a waaay bigger issue. If we ever were to have that, software development as a whole is solved outright, too.
I did a cloc check on it and it does seem to have 800k lines of typescript. So unless they are vendoring dependencies it's actually as insane as it sounds.
Christ their repo is an absolute nightmare. There's new issues and PRs being posted practically every minute, and I assume 99% of them are from agents given the target demographic. Just full-auto vibeslop from all barrels 24/7.
Even if we count the repos whole lifetime, including when it wasn't so active, the averages are still absurd.
96 days / (4,239+9,170) issues = one issue every 10 minutes
96 days / (5,082+10,221) pull requests = one PR every 9 minutes
5000+ open PRs is pretty insane, that's the highest I've seen. How do you even keep track of this? We'll really need trust management systems like vouch (https://github.com/mitchellh/vouch/tree/main) for open source projects in the future to help with reducing noise.
> OpenClaw has nearly half a million lines of code, 53 config files, and over 70 dependencies. This breaks the basic premise of open source security. Chromium has 35+ million lines, but you trust Google’s review processes. Most open source projects work the other way: they stay small enough that many eyes can actually review them. Nobody has reviewed OpenClaw’s 400,000 lines. It was written in weeks with no proper review process.
Yeah, but the world rewarded this by making it the fastest growing github project. The author gets on the podcasts, gets the high profile jobs from big tech. I'm more encouraged to do things this way than being security minded about all this.
And there's no accountability to this at all. If an agent leaks private data, the user is to blame and not the author. If Google bans your services for using api keys incorrectly, we cast the bad eye towards Google and not the maintainer than enabled and approved it.
There's just so much incentive for for "not reading code" and not developing secure code that is just going to get worse over time. This is the hype and the type of engineering that we all allow either by agreeing or by staying silent.
I agree with the author, but the world works off a different set of principles than what we're used to. I just see the world blindly trusting agents more.
I have twice encountered a phone tree AI agent saying my problem could not be solved and then ending the call. One was for PayPal fraud and the other was for closing an unused bank account.
For right now my trick is to say I have a problem that is more recognizable and mundane to the ai (i .e. lie) and then when I finally get the human just say “oh that was a bunch of hooey here’s what I’m trying to do”. For PayPal that involved asking for help with a business tax that did not exist. For my bank it involved asking to /open/ a new account. Obviously th AI wants to help me open an account, even if my intention is to close one.
That will only work for so long but it’s something
I was blown away by OpenClaw until I saw the bill. Ultimately, I think of these ecosystems as personal enhancements and AI costs need to come down dramatically for real problem. Worse, however, is the security theater. I would not want to be the operator for any business built with front-line LLM usage based on a yolo'd agent framework. I'm very happy to use these for silo'd components that are well isolated and have reasonable QA processes (and that can even included agents since now we literally have no excuse to not have amazing test coverage).
Their niche is going to be back office support, but even that creates risk boundaries that can be insurmountable. A friend of mine had a agent do sudo rm -rf ... wtf.
My view is that I want to launch an agent based service, but I'm building a statically typed ecosystem to do so with bounds and extreme limits.
Tools like OpenClaw have two core capabilities: the ability to rewrite themselves, and the ability to independently figure out how to connect to different services and establish those connections.
Yesterday, I was responding to a client ticket about what I knew wasn't a bug. It was something the client had requested themselves. The product is complex, constantly evolving, and has spawned dozens of related Jira tickets over time. So I asked my agent to explore the git history, identify changes to that specific feature, and cross-reference them with comments across the related tickets. Within minutes, I had everything I needed to write a clear response. It even downloaded PDF and DOCX files the client had attached. All of this was possible because my agent is connected to GitHub and Jira, and can clone repos locally since it runs on a VPS.
A second example: I was in an online meeting, taking notes as we went. Afterward, I asked the agent to pull the meeting transcript from Fireflies and use it to enrich my notes in Obsidian. I could have also asked it to push my action items straight into Todoist.
I only use my own “agent” ("my", because I program it myself, since my needs are different from yours) to retrieve information about the audio I upload to it (from video calls and audio recordings). No others use cases for me
> If you want to add Telegram support, don't create a PR that adds Telegram alongside WhatsApp. Instead, contribute a skill file (.claude/skills/add-telegram/SKILL.md) that teaches Claude Code how to transform a NanoClaw installation to use Telegram.
Why would you want that? You want every user asks the AI to implement the same feature?
No, but Podman is. The recent escapes at the actual container level have been pretty edge case. It's been some years since a general container escape has been found. Docker's CVE-2025-9074 was totally unnecessary and due to Docker being Docker.
It looks to me like what is called a "container escape" in this context isn't necessarily as bad as it seems. For example, in the advisory for CVE-2025-31133 affecting runc[1]:
> Container Escape: ...Thus, the attacker can simply trigger a coredump and gain complete root privileges over the host.
Sounds bad. But...
> this flaw effectively allows any attacker that can spawn containers (with some
degree of control over what kinds of containers are being spawned) to achieve
the above goals.
The attacker needs already to have the capability to spawn containers! This isn't a case of "RCE within the container" -> "RCE outside the container", which is what I would think prima facie reading "container escape".
I have always thought that running an untrusted image within an unprivileged container was a safe thing to do and I still believe so.
The best container security in the world isn’t going to help you when the agent has credentials to third party services. Frankly, I don’t think bad actors care that much about exploiting agents to rm -rf /. It’s much more valuable to have your Google tokens or AWS credentials.
xixyhuang nailed it — container escape is a red herring. The real problem is that your agent holds your OAuth tokens and can do massive damage without ever leaving its sandbox.
What bugs me about the current discourse is everyone focuses on where agents run and what they can access, but almost nobody talks about reconstructing what they actually did after the fact. Aviation has black boxes. Finance has audit trails. Agent systems have... logs the agent writes about itself. That's like asking the pilot to self-report the flight recorder.
Until action logging happens outside the agent's own process, none of the sandboxing stuff matters much.
the trust problem cuts both ways tho — users don't trust agents, but the bigger issue is agents trusting each other. once you have multi-agent pipelines, you're one rogue upstream output away from a cascade. sandboxing individual agents is table stakes; what's actually hard is defining trust boundaries between them
The proxy-based secret injection approach mentioned upthread is solid for network credentials, but it doesn't cover the local attack surface — your SSH keys, GPG keys, AWS credentials sitting in dotfiles. Those are the actual high-value targets for a compromised agent on a dev workstation.
I run Claude Code with 84 hooks, and the one I trust most is a macOS Seatbelt (sandbox-exec) wrapper on every Bash tool call. It's about 100 lines of Seatbelt profile that denies read/write to ~/.ssh, ~/.gnupg, ~/.aws, any .env file, and a credentials file I keep. The hook fires on PreToolUse:Bash, so every shell command the agent runs goes through sandbox-exec automatically.
The key design choice: Seatbelt operates at the kernel level. The agent can't bypass it by spawning subprocesses, piping through curl, or any other shell trick — the deny rules apply to the entire process tree. Containers give you this too, but the overhead is absurd for a CLI tool you invoke 50 times a day. Seatbelt adds ~2ms of latency.
I built it with a dry_run mode (logs violations but doesn't block) and ran it for a week before enforcing. 31 tests verify the sandbox catches attempts to read blocked paths, write to them, and that legitimate operations (git, python, file editing in the project directory) pass through cleanly.
The paths to block are in a config file, so it's auditable — you can diff it in code review. And it's composable with other layers: I also run a session drift detector that flags when the agent wanders off-task (cosine similarity against the original prompt embedding, checked every 25 tool calls).
None of this solves prompt injection fundamentally, but "the agent physically cannot read my SSH keys regardless of what it's been tricked into doing" is a meaningful property.
In the sense that nothing is truly a "proper" hard security barrier outside of maybe airgapping, sure. But containerization is typically a trusted security measure.
I move the security boundary one or two layers up: the Unix user (on main machine I run them as a `agent` user, so they can't read or write my files), or even better, just give it a separate machine. (VPSes are now popular for this purpose, as are Mac Minis. My choice is $50 Thinkpad :)
That said I am a fan of Nanoclaw, and especially the philosophy of "it should be small enough to understand, modify and extend itself." I think that's a very good idea, for many reasons.
The idea of giving different agents access to different subsets of information is interesting. That's the Principle of Least Privilege. That seems like a decent idea. Each individual agent can get prompt injected, but the blast radius is limited to what that specific agent has access to.
Still, I find it amusing that people are running this with strict rulesets, in Docker, on a VM, and then they hook it up to their GMail account (and often with random discount LLMs to boot!). It's like, we need to be clear about what the actual threat model is there. It comes down to trust and privacy.
You can start by thinking, "if the LLM were perfectly reliable (not susceptible to random error or prompt injection) and perfectly private (running on my own hardware)", what would you be comfortable letting it do. And then you remove these hypothetical perfect qualities one by one to arrive at what we have now: slightly dodgy, moderately prompt-injectable cloud services. Each one changing the picture in a slightly different way.
I don't really see a solution to the Security/Privacy <-> Convenience tension, except "wait for them to get smarter" (mostly done) and "accept loss of privacy" (also mostly done, sadly!)
I’m using this but using gpt-oss-120B instead of a cloud service. It has been eye opening when I realized the LLM is beings used as a compiler.
I asked it to add apple iMessage and apple notes support as I I rather have long responses, like write me a program ideas, not fill my iMessage history. The local LLM, which I believe has limited bash training data, does pretty well.
For example: I enjoy industrial music and asked it for the tour data of the band KMFDM which returned they will be in Las Vegas in April for a festival(Sick new world). This festival has something like 20 bands most of which I never heard of. I asked nanoclaw to search all of the band list and generate a listing grouped by the type of music they play: Industrial, rap, etc. It did a good job based on bands I do know.
I was pleased as I certainly did not want to do 20 band web searches by hand. It’s still at a bar trick level.
It gives me hope that an upgraded agent based Siri-like OS component could actually be useful from time to time.
Why do people take this article serious? It's just a wall of gibberish trying to make the product look more "secure" then others. It's not. It adds shallow secure looking random junk without tackling the core issues. Which are not solvable obviously.
Your assistant can literally be told what to do and how to hide it from you. I know security is not a word in slopware but as a high-level refresher - the web is where the threats are.
It's in a pod with zero permissions, secrets or access to the local network. It's also restarted daily incase somehow someone manages to escape a browser.
For that reason I do have it on a vpn, doubt it'll ever happen since I don't see an attacker being able to prompt inject that easily opus in general won't do those kind of searches even if you jailbreak it, it will actually make the guardrails activate and will start refusing everything.
I want to try one to be a bit of a personal coach. Remind me to do things and check in on goals. The memory / schedule / chat thing is enough and it wont need emails or anything more dangerous.
I’ve seen skills, etc haphazardly being launched with no constraints or guardrails. That more or less have admin access and can take actions that are not reversible.
I tried NanoClaw and love the skill (and container by default) model. But having skills generate new code in my personalized fork feels off to me… I think it’s because eventually the “few thousand auditable lines” idea vanishes with enough skills added?
Could skill contributions collapse into only markdown and MCP calls? New features would still be just skills; they’d bring in versioned, open-source MCP servers running inside the same container sandbox. I haven’t tried this (yet) but I think this could keep the flexibility while minimizing skill code stepping on each other.
> I think it’s because eventually the “few thousand auditable lines” idea vanishes with enough skills added?
I just watched a youtube interview with the creator. He actually explains it well. OpenClaw has hundreds of thousands of lines you will never use.
For example, if I only use iMessage, I have lots of code (all the other messaging integrations) that will never be used.
So the skills model means that you only "generate code" that _you_ specifically ask for.
In fact, as I'm explaining this, it feels like "lazy-loading" of code, which is a pretty cool idea. Whereas OpenClaw "eager-loads" all possible code whether you use it or not.
And that's appealing enough to me to set it up. I just haven't put it in any time to customize it, etc.
I totally get that, and I'm reminded of plugin architectures (e.g. VSCode extensions or browser extensions).
Those extensions don't modify the core codepaths for what they integrate with, but still provide new capabilities for only what I want to use.
I guess I don't see extensibility, agentic capabilities, and more code safety (and fewer tokens burned on codemods) as mutually exclusive. Not saying you're saying that fwiw.
Treating the LLM as an untrusted execution thread at the OS level is probably the only sustainable way to handle agentic autonomy... Most frameworks try to manage permissions with application level logic which is basically just a game of whack a mole with prompt injection.
Really good points about ai making gigantic heaps of code no human can ever review.
It's almost like bureaucracy. The systems we have in governments or large corporations to do anything might seem bloated an could be simplified. But it's there to keep a lot of people employed, pacified, powers distributed in a way to prevent hostile takeovers (crazy). I think there was a cgp grey video about rulers which made the same point.
Similarly AI written highly verbose code will require another AI to review or continue to maintain it, I wonder if that's something the frontier models optimize for to keep them from going out of business.
Oh and I don't mind they're bashing openclaw and selling why nanoclaw is better. I miss the times when products competed with each other in the open.
An interesting economic fact: Karl Marx observed that if factories keep getting more efficient, eventually, they will require fewer workers because the population is not growing quickly enough to match the increasing rate of production. This, as we have seen historically, is correct: we have fewer workers per factory and fewer factories per manufactured widget. Marx also observed that this will create mass unemployment. While this is _logically_ correct, it did not really turn out that way _historically_. Most of the manufacturing labor was replaced with bureaucratic labor (so called white-collar labor) -- all of those manufacturing firms needed to grow their internal bureaucracies to manage and direct a sprawling supply-chain.
nobody trusts AI agents, that's why they are put in a harness. It's just that I additionally belong to the people who don't trust AI agents to always adhere to harnesses either.
I haven't used them all but based on my partial research so far:
- OpenClaw: the big one, but extremely messy codebase and deployment
- NanoClaw: simple, main selling point is that agents spawn their own containers. Personally I don't see why that's preferable to just running the whole thing in a container for single-user purposes
- IronClaw: focused on security (tools run in a WASM sandbox, some defenses against prompt injection but idk if they're any good)
- PicoClaw: targets low-end machines/Raspberry Pis
- ZeroClaw: Claw But In Rust
- NanoBot: ~4k lines of Python, easy to understand and modify. This is the one I landed on and have been using Claude to tweak as needed for myself
IronClaw’s security architecture sounds plausible, but I have not audited it. Plugins can only access remote endpoints you’ve specifically allowed it for. Secrets aren’t available to the LLM - they are injected where the LLM requires it but only secrets authorized for that plugin are available to it. Together those two things provide an answer to a huge range of the most common prompt injection vulnerabilities, such as credential extraction. So you can give it access to your bank account and email and it can’t email your bank password to an attacker. But it could still transfer money to them.
The only secure way to use any of these tools is to give them very limited access - if they need a credit card give them a virtual card with a low limit, or even its own bank account. They can send email but only from their own account; like a human personal assistant. But of course this requires careful thought and adds friction to every new task, so people won’t be doing it.
Nanobot's was not great (cron + a HEARTBEAT.md meant two ways to do things, which would confuse the AI). But because the implementation is so simple, I could improve it in a few minutes in my own fork!
I'm only using NanoClaw, but I like that I could (and did) just review the code it has, and that it uses containers for each agent (so I can have different WhatsApp groups working on different things and they can't interfere with each other), and that I could (and did) just swap those containers out easily for guix shell containers.
I am pretty confident that I know how the agent containerization works. In general there's really not a lot of complexity there at all.
If one wants, one can just (ask Claude to) add whatever functionality, or (and that's what I did) just use Claude skills (without adapting NanoClaw any further) and be done with.
What is annoying is that their policy is instead of integrating extra functionality upstream, they prefer you to keep it for yourself. That means I have to either not update from upstream or I am the king of the (useless so far--just rearranging the deck chairs) merge conflicts every single time. So one of the main reasons for contributing to upstream is gone and you keep having to re-integrate stuff into your fork.
As a fun thought experiment, when people complain about LLMs, I substitute the word "human" or "employee" into the sentence and see if it is equally true.
"You can never really trust an LLM!" -> "You can never really trust an employee!" (Every IT department ever.)
"LLMs make shit up." -> "Humans make shit up." (Wow very profound insight.)
While that will always be true, LLMs do it a lot more often and do so with confidence and poise. We have evolved ways to tell if someone is making shit up (which usually works); LLMs subvert this. We are also being sold the idea that these LLMs are some kind of super intelligence which isn't helping matters.
All this talk about sandboxing and permissions misses the obvious: since you can't trust the agents, don't freaking use them. It is utterly stupid to give an LLM access to run things on your computer, because nothing you do can stop it from hallucinating garbage that harms your system. The whole "agent" craze is the most incredible display of irresponsibility I have ever seen in this industry.
You can't tell people that. People see the obvious benefits of using agents, so the many will always take the leap regardless of what detractors say. Continually iterating on the security model and making it all transparent is the way to go.
An AI actions and reasons through probabilistic methods - creating a lot more risk than a human with memory, emotions, and rationale thinking.
We can’t trust AI to do any sensitive work because they consistently f up. With & without malicious intent, whether it’s a fault of their attention mechanisms, reward hacking, instrumental convergence, etc all very different than what causes most human f ups.
Exactly, and I would never turn over my email or computer over to a contractor or anyone really. They get their own environment, email etc. Their actions stay as their actions.
> OpenClaw has nearly half a million lines of code, 53 config files, and over 70 dependencies. This breaks the basic premise of open source security. Chromium has 35+ million lines, but you trust Google’s review processes. Most open source projects work the other way: they stay small enough that many eyes can actually review them. Nobody has reviewed OpenClaw’s 400,000 lines.
This reminds me of a very common thing posted here (and elsewhere, e.g. Twitter) to promote how good LLMs are and how they're going to take over programming: the number of lines of code they produce.
As if every competent programmer suddenly forgot the whole idea of LoC being a terrible metric to measure productivity or -even worse- software quality. Or the idea that software is meant to written to be readable (to water down "Programs are meant to be read by humans and only incidentally for computers to execute" a bit). Or even Bill Gates' infamous "Measuring programming progress by lines of code is like measuring aircraft building progress by weight".
Even if you believe that AI will -somehow- take over the whole task completely so that no human will need to read code anymore, there is still the issue that the AIs will need to be able to read that code and AIs are much worse at doing that (especially with their limited context sizes) than generating code, so it still remains a problem to use LoCs as such a measure even if all you care are about the driest "does X do the thing i want?" aspect, ignoring other quality concerns.
Yeah, it’s pretty wild. Even pg is tweeting stuff like
“An experienced programmer told me he's now using AI to generate a thousand lines of code an hour.“
https://x.com/paulg/status/2026739899936944495
Like if you had told pg to his face in (pre AI) office hours “I’m producing a thousand lines of code an hour”, I’m pretty sure he’d have laughed and pointed out how pointless that metric was?
I don't understand how some people decide here, who the good programmers are. A lot of people reminded me a guy from West Palm Beach, who votes on elections solely on the principle of who has more "fame". Paul Graham is famous for sure (at least in HN circles), but I never considered him an exceptional or good programmer at all. So I always interpreted his words with a hefty amount of grain of salt. And sometimes some comments have a list of "good" coders, then half of them is like these famous, but not good ones.
> Paul Graham is famous for sure (at least in HN circles), but I never considered him an exceptional or good programmer at all.
pg wrote a Lisp dialect, Arc, with Morris. The Morris from "the Morris worm". These people are at the very least hackers and they definitely know how to code.
I don't think a "not good programmer" can write a Lisp dialect. At least of all the "not good" programmers I met in my life, 0% of them could have written a Lisp dialect.
It's not because Arc didn't reach the level of fame of Linux or Quake or Kubernetes or whatever that pg is not a good programmer.
I met a coder, who has several self made programming languages, and I would never allow him anywhere near any codebases for which I'm responsible. So writing a Lisp dialect, is not something which makes you a good coder for sure. Even as a junior you can do that. Making it good, and be able to really reason for choices is a different story. I've never seen any good new reasoning from Graham like for example how Dan Abramov do all the time. They are not even close, and definitely not in favor of Graham.
> I don't think a "not good programmer" can write a Lisp dialect.
You can write a lisp in 145 lines of Python: https://norvig.com/lispy.html
That doesn't disprove anything. Peter Norvig is about as far from "not good programmer" as one can get.
It's not about Peter. Of course, he's a great programmer. The point is that you can follow nicely written tutorials and have your own in a very short period of time. It's not particularly difficult to build a Lisp.
> pg wrote a Lisp dialect, Arc
Wasn't Arc just a collection of Scheme macros?
Presumably he got better in the intervening decades, but part of how we stopped the Morris Worm was that it was badly written (see the various version of With Microscope and Tweezers for detail, particularly about the "am I already running" check that ended up being why it got noticed, "because exponential growth".) Even for "bored 1st year grad student skipping lectures" it should have been better code :-)
(Also, writing a Scheme dialect was a first-semester CS problem set - if you're in a 1980s academic CS environment it was more effort to not accidentally write a lisp interpreter into something, something in the water supply...)
I take him to be a good programmer on top of a pioneer venture capitalist and entrepreneur but Hackers and Painters contains some pretty bad predictions and takes on programming, and if he didn't have that good foresight then, it has probably become worse with the years.
obligatory Dabblers and Blowhards https://idlewords.com/2005/04/dabblers_and_blowhards.htm
He is a Lisper too, making it more ironic. Lisp the power to heavily reduce cruft by heavy customization with macros.
Thousand left-parens per hour...?
I mean, I didn't close them all but still, ... Look at the code! That's gotta be valuable
Technical debt is increasing by 1,000 lines an hour.
They need to keep the musical chairs going.
Hm, I do not read the statement as a hyped "this is how everyone should write code now" rather as a statement of fact. "A experienced programmer he knows uses LLMs to generate thounds LOC/h". That does not say whether those lines will actually be shipped anywhere or just exist for testing purposes/prototyping.
We all know that a thousand parentheses would be better metric.
Enshittification comes for us all
It’s all virtual virtue signaling. If you were to say this shit in the office, you’d be walked out pretty fast.
Who is signaling what virtues to whom in this context?
When I see PG write something like that, it signals to me that he has embraced AI hype to the point that he is displaying poor taste and embracing a risky technical practice.
PG is signaling his AI bros, idk.
I imagine PG is rich enough and influential enough in the tech/VC space that he doesn't have to signal anything he doesn't honestly believe.
It's unsurprising he would believe LLM coding tools are a productivity boon, but using code quantity as a measure of software development progress is one of the most famously wrong ideas in the software world. Either he wrote carelessly, or he believes that LLM tools have changed that reality.
I'm inclined to think LLM tools haven't substantially changed that reality. LLMs perform better when more of the problem fits in context, so succinctness remains valuable.
Maybe it depends on whose office? C-suite management who salivate after reducing software engineer headcount?
Somehow, this narrative has taken hold at multiple levels of management, especially amongst non-technical management, that "typing" was somehow the bottleneck of software engineering, reality is however more complex.
The act of "typing" code was technically mixed in with researching solutions, which means that code often took a different shape or design based on the outcome of that activity. However, this nuance has been typically ignored for faff, with the outcome that management thinks that producing X lines of code can be done "quickly", and people disagreeing with said statements are heretics who should be burned at the stake.
This is why, in my personal opinion, AI makes me only 20% productive, I often find disagreeing with the solution that it came up with and instead of having to steer it to obtain the outcome I want, I just end up rewriting the code myself. On the other hand, for prototypes where I don't care about understanding the code at all, it is more of a bigger time saver.
I could not care about the code at all, and while that is acceptable to management, not being responsible for the code but being responsible for the outcomes seems to be the same shit as being given responsibilities without autonomy, which is not something I can agree with.
AI is good at the first 80% but terrible at the last 20% of producing good code. And you need to through that first 80% to really understand what the code is scaffolded to do, which writing it yourself will vastly improve. And typing speed has never been the bottleneck for coding.
Even worse, whole generation of devs are being trained to not care of learn about that last 20% because the AI does it """all""" for them. That last bit is an unknown unknown for the neo developer nee prompter.
More people believe a software developer job and value is in the lines of code produced.
Perhaps over half of engineering managers unconsciously or admittedly take the amount of PR and code additions as a rough but valid measure of productivity.
I recall a role in architecture, senior director asking me how come a principal engineer didn't commit any code in 2 weeks, that we pay principals a fortune.
I asked that brilliant mind whether we paid principal engineers to code or to make sure we deliver value.
Needless to say the with question went unanswered, so called Principal was fired a few months later. The entire company in fact was sold for a bargain too given it had thousands of clients globally.
The LLM can replace engineers is a phenomenon that converge from two simple facts, we haven't solved the misconception of the engineering roles. And it's the perfect scapegoat to justify layoffs.
Leaders haven't all gone insane, they answer to difficult questions with the narrative of least resistance.
> Leaders haven't all gone insane, they answer to difficult questions with the narrative of least resistance.
Brilliantly said. I’d like to add - a distorted narrative actively, intentionally established and maintained by the entities profiting from the technology. Quite similar to the crypto scam hype cycle.
Brook's law anno 2026:
"Adding manpower to a late software project makes it later -- unless that manpower is AI, then you're golden!"
I know you're being sarcastic, but this is what OpenAI has said:
https://openai.com/index/harness-engineering/
> This translates to an average throughput of 3.5 PRs per engineer per day, and surprisingly the throughput has increased as the team has grown to now seven engineers.
We will see if this continues to scale up!
That law (formulated in the 70s, I’ll remind the reader) wasn’t true for at least couple decades now.
Why not? What changed? It seems like a human factors thing. New people have to get up to speed. Doers become trainers.
Several related reasons working at once. The nature of work changed. The boundary between accidental and incidental complexity shifted (and it’s unclear whether this distinction still exists). Niche specializations within the field emerged. The way to structure and decompose projects changed dramatically (agile and stuff).
One pathological example: if you’re running a server-based product, quite often what stands between you and a new feature launch is literally couple of thousands of lines of Kubernetes YAML. Would adding someone who’s proficient in Kubernetes slow you down? Of course not.
One may say, hey, this is just the server-side Kubernetes-based development being insane, and I’ll say, the whole modern business of software development is like this.
Hmm interesting, thanks! I was ready to argue but now I have to think, which is even better.
That’s a lovely comment, thank you. If you’re keen to think about it more, consider the fact that the existing members of the project that’s being late are actually in not as much of an advantage compared to the new joiners, as it’s common to think.
Yes, they know how the feature they work on relates to other features, but actually implementing that feature is very often mostly involves fighting with technology, wrangling the entire stack into the shape you need.
In Brooks’s times the stack was paper-thin, almost nonexistent. In modern times it’s not, and adding someone who knows the technology, but doesn’t have the domain knowledge related to your feature still helps you. It doesn’t slow you down.
One may argue that I’m again pointing to the difference between accidental and incidental complexity, and my argument is essentially “accidental complexity takes over”, but accidental complexity actually does influence your feature too, by defining what’s possible and what’s not.
Some good thoughts (not mine) on the modern boundary between accidental and incidental complexity: https://danluu.com/essential-complexity/
I sort of agree that the surface area and incidental complexity of stacks give more space to plug more developers in than was true in the 70s and 80s. But I disagree strongly this invalidates Brooks Law. Certainly there are cases where adding people helps, especially if they are stronger engineers than the ones that are already there, but I’ve also seen way too many projects devolve into resourcing conversations when the real problem was over-complicated, poorly reasoned requirements, boil-the-ocean solutions promising a perfect end state without a clear plan to get there iteratively.
Plus, the "since there are more resources, let's add features" effect.
I asked Grok to rewrite your comment and it did it in 2400 words. I hope you know you'll be obsolete soon.
As lines of code become executable line noise, I swear that we need better approaches to developing software - either enforce better test coverage across the board, develop and use languages where it’s exceedingly hard to end up with improper states, or sandbox the frick out of runtimes and permissions.
Just as an example, I should easily be able to give each program an allowlist of network endpoints they’re allowed to use for inbound and outgoing traffic and sandbox them to specific directories and control resource access EASILY. Docker at least gets some of those right, but most desktop OSes feel like the Wild West even when compared to the permissions model of iOS.
“LoC is a bad metric” has been the catchphrase of engineers for years, because it runs counter to the expectations of management and the general public, right? So it makes sense that LoC is the metric used to advertise to them.
LLMs are incredibly eager to write new code, rather than modifying or integrating with existing systems. I agree that context windows are too small currently for this to seem sustainable. Without reasonable architecture pure vibe coded software feels like it’s going to cap out at a certain size.
>Nobody has reviewed OpenClaw’s 400,000 lines.
Including the author, who brags he doesn't read his own code. Indeed, it would be physically impossible for him to do so!
https://steipete.me/posts/2025/shipping-at-inference-speed
As mentioned elsewhere in the thread, there is very clearly an obsession with quantity over quality. Not a new phenomenon by any means: people were already complaining about this in the 19th century! But it has reached a new absurd height with this latest trend.
It’s definitely an issue when using coding assistants.
If you are careful and specific you can keep things reasonable, but even when I am careful and do consolidattion / factoring passes, have rigid separation of concerns, etc I find that the LLM code is bigger than mine, mainly for two reasons:
1) more extensive inline documentation 2) more complete expression of the APIs across concerns, as well as stricter separation.
2.5 often, also a bit of demonstrative structure that could be more concise but exists in a less compact form to demonstrate it’s purpose and function (high degree of cleverness avoidance)
All in all, if you don’t just let it run amok, you can end up with better code and increased productivity in the same stroke, but I find it comes at about a 15% plumpness penalty, offset by readability and obvious functionality.
Oh, forgot to mention, I always make it clean room most of the code it might want to pull in from libraries, except extremely core standard libraries, or for the really heavy stuff like Bluetooth / WiFi protocol stacks etc.
I find a lot of library type code ends up withering away with successive cleanup passes, because it wasn’t really necessary just cognitively easier to implement a prototype. With refinement, the functionality ends up burrowing in, often becoming part of the data structure where it really belonged in the first place.
The lines of code thing isn't because we think it's a good metric, but because we have literally no good metric and we're trying to communicate a velocity difference. If you invent a new metric that doesn't have LoC's problems while being as easy to use, you'll be a household name in software engineering in short order.
Also, AI is better at reading code than writing it, but the overhead to FIND code is real.
That's because they're an additive tool. Everything boils down to "adding" more code. But in the long term its not about how much code you can add but how little you can get away with. But this is an impossible task for the LLMs. How would you train one not to write code? What would the training data look like? Would that be all the lines of code that haven't been written?
TDD would help here, particularly if a human writes - or at least thoroughly reviews - the tests.
https://martinfowler.com/bliki/TestDrivenDevelopment.html
That’s not an impossible task with LLMs, you just have to mindfully architect the project with that in mind, hence take it slowly to design a good system, don’t outsource all thinking to LLMs.
Well they will train on my Claude Code sessions for a start. I spend a lot of time asking it to remove unnecessary code that was produced, I'm not the only one.
I've been waiting for someone to say this. An agent will generally produce far more code than technically necessary for the task. It's a kind of over engineering which makes it increasingly harder to wrap your head around the codebase.
Over engineered implies the codebase was inflated with some kind of rationale by the AI, but there is none. It's just code vomit with duct tape
Really it just continues to demonstrate that "code quality" is not and was not a requirement.
Even with supposedly expert human hand written software powering our products for the last decades, they frequently crash, have outages, and show all sorts of smaller bugs.
There are literally too many examples to count of video games being released with nigh-unplayable amounts of bugs and still selling millions and producing sequels.
Windows 95 and friends were famously buggy and crash prone yet produced one of the most valuable companies in the world.
Respectfully, it feels like your position requires a very low, if not brain-dead level of incompetence on the part of LLM users, in order for your conclusion to be correct.
My personal anecdote: I used an LLM recently to basically vibe code a password manager.
Now, I’ve been a software engineer for 20 years. I’m very familiar with the process of code review and how to dive in to someone else’s code and get a feel for what’s happening, and how to spot issues. So when I say the LLM produced thousands of lines of working code in a very short time (probably at least 10 times faster than I would have done it), you could easily point at me and say “ha, look at ninkendo, he thinks more lines of code equals better!” And walk away feeling smug. Like, in your mind perhaps you think the result is an unmaintainable mess, and that the only thing I’m gushing about is the LOC count.
But here’s the thing: it actually did a good job. I was personally reviewing the code the whole time. And believe me when I say, the resulting product is actually good. The code is readable and obvious, it put clean separation of responsibilities into different crates (I’m using rust) and it wrote tons of tests, which actually validate behavior. It’s very near the quality level of what I would have been able to do. And I’m not half bad. (I’ve been coding in rust in particular, professionally for about 2 years now, on top of the ~20 years of other professional programming experience before that.)
My takeaway is that as a professional engineer, my job is going to be shifting from doing the actual code writing, to managing an LLM as if it’s my pair programming partner and it has the keyboard. I feel sad for the loss of the actual practice of coding, but it’s all over but the mourning at this point. This tech is here to stay.
This whole reply, and every other "anecdote" reply is more worthless than the pixels its printed on, without a link to your "actually did a good job" password manager.
(wow funny how these vibe code apps always are copies of something theres many open source versions of already)
Ugh, you made me spend the 20 minutes it takes to spin up a new github account to share this (my existing one uses my real name and I don't really want to doxx myself that much. Not that it's a huge deal, my real identity and the "ninkendo" handle have been intertwined a lot in the past.)
https://github.com/ninkendo84/kenpass
I'm not saying it's perfect, there's some things I would've done differently in the code. It's also not even close to done/complete, but it has:
- A background agent that keeps the unsealed vault in-memory
- A CLI for basic CRUD
- Encryption for the on-disk layout that uses reasonably good standards (pbkdf2 with 600,000 iterations, etc)
- Sync with any server that supports webdav+etags+mTLS auth (I just take care of this out of band, I had the LLM whip up the nginx config though)
- A very basic firefox extension that will fill passwords (I only did 2 or 3 rounds of prompting for that one, I'm going to add more later)
Every commit that was vibe-coded contains the prompt I gave to Codex, so you can reproduce the entire development yourself if you want... A few of the prompts were actually constructed by ChatGPT 5.2. (It started out as a conversation with ChatGPT about what the sync protocol would look like for a password manager in a way that is conflict-free, and eventually I just said "ok give me a prompt I can give to codex to get a basic repo going" and then I just kept building from there.)
Also full disclosure, it had originally put all the code for each crate in a single lib.rs, so I had it split the crates into more modules for readability, before I published but after I made the initial comment in this thread.
I haven't decided if I want to take this all the way to something I actually use full time, yet. I just saw the 1password subscription increase and decided "wait what if I just vibe-coded my own?" (I also don't think it's even close to worthy of a "Show HN", because literally anybody could have done this.)
Thank you for the time commitment based on an internet forum comment. I appreciate greatly the succinct human written README.
Did you investigate prior art before setting out on this endeavor? https://www.google.com/search?q=site%3Agithub.com+password+m...
I ask because engineers need to be clever and wise.
Clever means being capable of turning an idea into code, either by writing it or recently by having the vocabulary and eloquence to prompt an LLM.
Wisdom means knowing when and where to apply cleverness, and where not to. like being able to recognize existing sub-components.
> Did you investigate prior art before setting out on this endeavor
Lol no, I had no idea there was any other password managers! Thanks for the google search link! I didn't know search engines existed either!
> Wisdom means knowing when and where to apply cleverness, and where not to. like being able to recognize existing sub-components.
It says literally in the README that part of this is an exercise in seeing what an LLM can do. I am in no way suggesting anyone use this (because there's a bazillion other password managers already) nor would I even have made this public if you hadn't baited me into doing it.
The fact that there's a literal sea of password managers out there is why I'm curious enough to think "maybe a one that I get to design myself, written to exactly my tastes and my tastes alone could be feasible", and that's what this exercise is about. It literally took me less time to vibe-code what I have right now, than to pour through the sea of options that already exist to decide which one I should try. And having it be mine at the end means that I can implement my pet features the way I want, without having to worry one bit about fighting with upstream maintainers. It's also just fun. I thoroughly enjoy the process of thinking about the design and iterating on it.
If you didn't like me telling you about search engines you probably won't like me telling you how git clone works BUT...
For all intents and purposes, (in the context of diddling around with a password manager you might use yourself and wouldn't recommend to anyone), Any/all of those existing open source password managers can ALSO be yours just as much as the output from any LLM.
I'm serious, not only can you tweak them to "your tastes and your tastes alone", you don't have to even tell upstream maintainers what you're doing let alone get it merged.
So if you’re just going to complain about me reinventing the wheel (even though I already explained this is literally an exercise to see what an LLM can do), can we at least recognize the goalpost shift here?
I’m just going to assume that you’ve completely conceded your original point then, since you have absolutely zero to say about whether you agree the LLM did good work or not. Since the moment I showed you its work, you immediately shifted to insulting my intelligence for bothering with a password manager in the first place.
I honestly don’t know why I bother feeding trolls like you when it’s clear your only goal here is to find fault.
If we're talking about goalposts, lets also recognize the Motte and Bailey of initial claims of "20 years professional software engineer actually good password manager" to "hee hee toy project testing how LLms work not complete not even for personal not recmmond for others"
I don't think your password manager is good, and I don't think you think it's good either or you'd be using it.
I'm not trolling. It's way cheaper and faster to just clone an existing project if you want to mess around with making a password manager suit your taste.
My goal is to mess around with an LLM, not just to mess around with a password manager. If you read literally any of my posts in this thread without the intention of throwing shade, maybe you would have gotten that point by now. I’ve certainly repeated it enough times.
> I don't think your password manager is good, and I don't think you think it's good either or you'd be using it.
Lol I am using it now though. In the time from yesterday’s post to now I have an iOS app, an iOS Password Autofill extension, a Mac app and the existing Linux CLI and Firefox browser extension. Automatically syncs conflict-free between everything too, using a simple web server for sync. It now covers every use case 1Password did for me, and no, none of the “rust password manager site:github.com” results do any of this.
It was an experiment to see if the effort of vibe coding a password manager would be easy enough that it would be worth doing, and guess what: resounding success. Cope more.
> maybe you would have gotten that point by now.
I don't deny it. When I said "mess around with making a password manager suit your taste" feel free to append " while using and getting experience with an LLM". nothing changes.
im glad you're dogfooding your pw manager now. I'm glad vibe coding met your own standard of quality.
I will leave it as an exercise to you to think about all the edge cases and usability issues that have been solved in mainstream pw managers that you've never thought about. I hope you keep your LLM subscription active so you can fix them as they come up. And to keep up with updates from IOS and firefox as they come out.
sooo ...
> it actually did a good job.
applies when there is a sea of "prior art" on the topic requested. And that request (prompt) is actually framed/worded properly to match that prior art.
Which may be perfect if the target is reduceable to prior-art. Re-use, Mix-and-match, from opensource or stackoverflow, into my-own-flavour-hot-water, finally!
No, this is not sarcasm. i hate to (catch myself a month later) reinventing hot-water. Let something else do it.
The question that stays with me is, How to keep the brain-bits needed for that inventing / making new stuff , alive and kicking.. because they will definitely deteriorate towards zero or even negative. Should we reinvent each 10th thing? just for the mental-gym-nastics?
How do you know it's secure?
If you measure the productivity of the system that is “you, using an LLM” in terms of the rate at which you can get actually-reviewed code completed (which, based on your comment, seems to be what you were doing) that seems like a totally reasonable way of doing things. But in that case the bottleneck is probably you reviewing code, right? Which, I bet, is faster than writing code. But you probably won’t get the truly absurd superhuman speed ups.
What would you say is your multiplier, in terms of throughly reviewing code vs writing it from scratch?
Yeah, I guess that's kinda my point. LLM detractors on HN seem to straw-man what they think the average LLM user is doing. I'm an experienced programmer who is using an LLM as a speed boost, and the result of that is that it produces thousands of lines of code in a short time.
The impressive thing isn't merely that it produces thousands of lines of code, it's that I've reviewed the code, it's pretty good, it works, and I'm getting use out of the resulting project.
> What would you say is your multiplier, in terms of throughly reviewing code vs writing it from scratch?
I'd say about 10x. More than that (and closer to 100x) if I'm only giving the code a cursory glance (sometimes I just look at the git diff, it looks pretty damned reasonable to me, and I commit it without diving that deep into the review. But I sometimes do something similar when reviewing coworkers' code!)
I don't know if it is incompetence - if anything i doubt it, someone else pointed out that pg also used that metric and i don't think pg is incompetent. However at the same time i think it is misleading at best.
My impression is that, as someone else wrote, we do not have an actual metric for such things as productivity or quality or what have you, but some people do want to communicate that they feel (regardless of if that matches reality) using an LLM is better/faster/easier and they latch to the (wrong) assumption about more LoC == better/faster that non-programmers already believed for years (intentionally or not, they may also deluding themselves) as that is an easy path to convince them that the new toys have value that applies to the non-programmers too (note that i explicitly ignore the perspective of the "toymakers" as those have further incentives to promote their products).
Personally i also have about 2 decades of professional experience (more if counting non-professional) and i've been toying with LLMs now and then. I do find them interesting and when i use them for coding tasks, i absolutely find useful cases for them, i like to have them (where possible) write all sorts of code that i could write myself but i just don't feel like doing so and i do find them useful for stuff i'm not particularly interested in exploring but want to have anyway (usually Python stuff) and i'm sure i'll find more uses for them in the future. Depending on the case and specifics i may even say that in very particular situations i can do things faster using LLMs (though it is not a given and personally that is not much of a requirement nor something i have anywhere high in my interest when it comes to using LLMs - i'd rather have them produce better code slower, than dummy/pointless/repetitive code faster).
However one thing i never thought about was how "great" it is that they generate a lot of lines of code per whatever time interval. If anything i'd prefer it if they generated less line of code and i'd consider an LLM (or any other AI-ish system) "smarter" if they could figure out how to do that without needing hand holding from me. Because of this, i just can't see LoCs as anything but a very bad metric - which is the same as when the code is written by humans.
>this tech is here to stay
How can you say that when all these models are externally sourced by companies that actively make a loss per token? When they finally need to make a profit, how can we be sure these models as well as their owners will remain as reliable and not enshittified? Anthropic has been blacklisted in the last 24 hours so its a turbulent industry to say the least
When enshittification happens we would just simply go back to code by hand, then. We programmers don't lose the ability to do so when we use LLM, right ?
Lines of code are nothing. It's verification that creates value.
Yeah, I would view this as a “levels of maturity” thing. It’s not completely misguided to judge a JD on whether they shipped 0loc or 1kloc. Assuming you have some quality counter-metric like “the app works”.
For staff engineers it’s obviously completely nonsense, many don’t code and just ship architecture docs. Or you can ship a net negative refactor. Etc.
So this should tell you that LLMs are still in “savant JD” territory.
That said, being given permission to ship more lines of code under existing enterprise quality bars _is_ a meaningful signal.
I mean many of us have... I operate in a net negative mindset. My PRs, better remove more than they add.
I also use AI this way, periodically achieving a net negative refactor.
A question I've been asking myself and which I honestly want to put out there - and I apologize in advance, because you will see me repeat it in other threads, out of genuine curiosity:
Does your life have so much friction that you need a digital agent to act on your behalf?
Some of the use cases I saw on the OpenClaw website, like "checking me into a flight", are non-issues for me.
I work in business automation, but paradoxically I don't think too much about annoyances in my private life. Everything feels rather frictionless.
In business, I see opportunities to solve friction and that's how I make money, but even then, often there are barriers that are very hard to surmount:
(a) problems are complex to solve and require complex solutions such as deterministic or ML systems that LLMs are not even close to being able to create ad-hoc
(b) entrenched processes and incumbent organizations create moats that are hard to cross (ex: LinkedIn makes automation very hard)
(c) some degree of friction, in some cases, may actually be useful!
I imagine there are similar dynamics in the consumer space, but more than anything, I may not be seeing issues with such a critical eye (I like to relax after work, after all)
So, do you have problems in your private life that you'd want to take on the risks - and friction - of maintaining these agents?
Similar CV, similar take. My guess? Anyone involved in automation for >2 years at the enterprise levels knows in their gut all the silent, sudden, annoying ways automation can fail and so has a higher internal bar for "must save this much time to be worth automating."
That said, old beliefs should be challenged by new technological capabilities!
If LLM based automation is (a) less fragile and (b) quicker to develop, then that bar should be lowered.
Do not underestimate the modern marketing and its capability to create needs that didn't exist before.
It is not about removing friction, it is about convincing that friction existed in a first place
I don't get it either. I even sat down to try it out and see what it's all about, but I can't think of a single thing in my life that I want an agent to automate.
Summarizing news? No, I'd rather just read it. Besides, it's hard to say what will or won't be interesting at any given moment.
Reply to emails? No, I want to make sure I say what I mean to say and I don't see why I would tell the whole story to an LLM just so it could rephrase it all.
Trade stocks? Dear God no! That's a good way to lose my life savings, and if the solution is to just put in a little then what's the point?
Every video and post I see talking about all the things they have automated with agents are things I would never want. Most of them describe content farms - look at what's hot on Twitter, generate a video, post to Reddit, etc. Others like preparing a morning summary are neat and all but so what? If my life was so hectic that I needed a personal assistant to take my calls and book my meetings, I'd hire one.
Seriously, what is the thing that agents can do that every ordinary person just can't live without?
My take is that agents should only take actions that you can recover from by default. You can gradually give it more permission and build guardrails such as extra LLM auditing, time boxed whitelisted domains etc. That's what I'm experimenting with https://github.com/lobu-ai/lobu
1. Don't let it send emails from your personal account, only let it draft email and share the link with you.
2. Use incremental snapshots and if agent bricks itself (often does with Openclaw if you give it access to change config) just do /revert to last snapshot. I use VolumeSnapshot for lobu.ai.
3. Don't let your agents see any secret. Swap the placeholder secrets at your gateway and put human in the loop for secrets you care about.
4. Don't let your agents have outbound network directly. It should only talk to your proxy which has strict whitelisted domains. There will be cases the agent needs to talk to different domains and I use time-box limits. (Only allow certain domains for current session 5 minutes and at the end of the session look up all the URLs it accessed.) You can also use tool hooks to audit the calls with LLM to make sure that's not triggered via a prompt injection attack.
Last but last least, use proper VMs like Kata Containers and Firecrackers. Not just Docker containers in production.
That's a decent practice from the lens of reducing blast radius. It becomes harder when you start thinking about unattended systems that don't have you in the loop.
One problem I'm finding discussion about automation or semi-automation in this space is that there's many different use cases for many different people: a software developer deploying an agent in production vs an economist using Claude Vs a scientist throwing a swarm to deal with common ML exploratory tasks.
Many of the recommendations will feel too much or too little complexity for what people need and the fundamentals get lost: intent for design, control, the ability to collaborate if necessary, fast iteration due to an easy feedback loop.
AI Evals, sandboxing, observability seem like 3 key pillars to maintain intent in automation but how to help these different audiences be safely productive while fast and speak the same language when they need to product build together is what is mostly occupying my thoughts (and practical tests).
Current LLMs are nowhere near qualified to be autonomous without a human in the loop. They just aren't rigorous enough. Especially the "scientist throwing a swarm to deal with common ML exploratory tasks." The judgement of most steps in the exploratory task require human feedback based on the domain of study.
> Many of the recommendations will feel too much or too little complexity for what people need and the fundamentals get lost: intent for design, control, the ability to collaborate if necessary, fast iteration due to an easy feedback loop.
Completely agreed. This is because LLMs are atrocious at judgement and guiding the sequence of exploration is critically dependent on judgement.
I'd like to try a pattern where agents only have access to read-only tools. They can read you emails, read your notes, read your texts, maybe even browse the internet with only GET requests...
But any action with side-effects ends up in a Tasks list, completely isolated. The agent can't send an email, they don't have such a tool. But they can prepare a reply and put it in the tasks list. Then I proof-read and approve/send myself.
If there anything like that available for *Claws?
There is no real such thing as a read only GET request if we are talking about security issues here. Payloads with secrets can still be exfiltrated, and a server you don’t control can do what it wants when it gets the request.
GET and POST are merely suggestions to the server. A GET request still has query parameters; even if the server is playing by the book, an agent can still end up requesting GET http://angelic-service.example.com/api/v1/innocuous-thing?pa... and now your `dangerous-secret` is in the server logs.
You can try proxying and whitelisting its requests but the properly paranoid option is sneaker-netting necessary information (say, the documentation for libraries; a local package index) to a separate machine.
The proxy approach for secret injection is the right mental model, but it only works if the proxy itself is hardened against prompt injection. An agent that can't access secrets directly can still be manipulated into crafting requests that leak data through side channels — URL params, timing, error messages.
The deeper issue: most of these guardrails assume the threat is accidental (agent goes off the rails) rather than adversarial (something in the agent's context is actively trying to manipulate it). Time-boxed domain whitelists help with the latter but the audit loop at session end is still reactive.
The /revert snapshot idea is underrated though. Reversibility should be the first constraint, not an afterthought.
> but it only works if the proxy itself is hardened against prompt injection.
Yes, I'm experimenting using a small model like Haiku to double check if the request looks good. It adds quite a bit of latency but it might be the right approach.
Honestly; it's still pretty much like early days of self driving cars. You can see the car can go without you supervising it but still you need to keep an eye on where it's going.
> 1. Don't let it send emails from your personal account, only let it draft email and share the link with you.
Right now there's no way to have fine-grained draft/read only perms on most email providers or email clients. If it can read your email it can send email.
> 3. Don't let your agents see any secret. Swap the placeholder secrets at your gateway and put human in the loop for secrets you care about.
harder than you might think. openclaw found my browser cookies. (I ran it on a vm so no serious cookies found, but still)
> Right now there's no way to have fine-grained draft/read only perms on most email providers or email clients. If it can read your email it can send email.
> harder than you might think. openclaw found my browser cookies. (I ran it on a vm so no serious cookies found, but still)
You should never give any secrets to your agents, like your Gmail access tokens. Whenever agents needs to take an action, it should perform the request and your proxy should check if the action is allowed and set the secrets on the fly.
That means agents should not have access to internet without a proxy, which has proper guardrails. Openclaw doesn't have this model unfortunately so I had to build a multi-tenant version of Openclaw with a gateway system to implement these security boundaries.
> That means agents should not have access to internet without a proxy, which has proper guardrails. Openclaw doesn't have this model unfortunately so I had to build a multi-tenant version of Openclaw with a gateway system to implement these security boundaries.
I wonder how long until we see a startup offering such a proxy as a service.
Literally every email client on the planet has supported `mailto:` URIs since basically the existence of the world wide web.
Just generate a mailto Uri with the body set to the draft.
> harder than you might think. openclaw found my browser cookies. (I ran it on a vm so no serious cookies found, but still)
It's easy, and you did it the right way. Read "don't let your agents see any secret" as "don't put secrets in a filesystem the agents have access to".
I think mailto: links they output (a la
https://mailtolink.me/
) are a great way to get these drafts out even.
This doesn’t really feel like enough guardrails to prevent the type of problems we’ve seen so far. For example an agent in a single container which has access to an email inbox, can still do a lot of damage if that agent goes off the rails. We agree this agent should not be trusted, yet the ideas proposed as a solution are insufficient. We need a fundamentally different approach.
Also and this is just my ignorance about Claws, but if we allow an agent permission to rewrite its code to implement skills, what stops it from removing whatever guardrails exist in that codebase?
Exactly!
I installed nanoclaw to try to out.
What is kinda crazy is that any extension like discord connection is done using a skill.
A skill is a markdown file written in English to provide a step by step guide to an ai agent on how to do something.
Basically, the extensions are written by claude code on the fly. Every install of nanoclaw is custom written code.
There is nothing preventing the AI Agent from modifying the core nanoclaw engine.
It’s ironic that the article says “Don’t trust AI agents” but then uses skills and AI to write the core extensions of nanoclaw.
Author and creator of NanoClaw here.
I did my best to communicate this but I guess it was still missed:
NanoClaw is not software that you should run out of the box. It is designed as a sort of framework that gives a solid foundation for you to build your own custom version.
The idea is not that you toggle on a bunch of features and run it. You should customize, review, and make sure that the code does what you want.
So you should not trust the coding agents that they didn't break the security model while adding discord. But after discord is added, you review the code changes and verify that it's correct. And because even after adding discord you still only have 2-3k loc, it's actually something you can realistically do.
Additionally, the skills were originally a bit ad-hoc. Now they are full working, tested and reviewed reference implementations. Code is separate from markdown files. When adding a new integration or messaging channel, the agent uses `git merge` to merge the changes in, rather than rewriting from scratch. Adding the first channel is fully deterministic. The agent only resolves merge conflicts if there are any.
So, nanoclaw requires agents to code extensions on the fly to get to feature parity with openclaw… and you're celebrating nanoclaw having fewer LOC. How's the code smell after nanoclaw gets to feature parity?
The point is to be able to choose the (presumably small) subset of features you actually want, and have a tractable review problem. Presumably people who really want openclaw would just use openclaw.
> Basically, the extensions are written by claude code on the fly. Every install of nanoclaw is custom written code.
"Every copy of Nanoclaw is personalized." So if I use it long enough will I see the Wario apparition?
Yeah, the article's claim of having a low number of lines of code are disingenuous. Rather than writing some sort of plugin interface, it has "skills" that are a combination of pre-written typescript and English language instructions for how to modify the codebase to include the feature. I don't see how self-modifying code that uses a RNG to generate changes is going to be better for security than a proper plugin system. And everyone who uses Nanoclaw will have a customized version of it, so any bugs reported on Nanoclaw probably have a high chance of being closed as "can't reproduce". Why would you live this way?
Yes and and they still have code examples in them so its not like it somehow doesn't count. Plus if you run the skill good luck bringing in changes from master later.
Don’t know about other claws, with NanoClaw the agent can only rewrite code that runs inside the container.
You can see here that it’s only given write access to specific directories: https://github.com/qwibitai/nanoclaw/blob/8f91d3be576b830081...
I think the best place to put barriers in place is at the mcp / tool layer. The email inbox mcp should have guardrails to prevent damage. Those guardrails could be fine grained permissions, but could also be an adversarial model dedicated to prevent misuse.
Wouldn't you get >50% of the usefulness and 0% of the risk if you add read+draft permissions for the email connection through a proxy or oauth permissions? Then your claw can draft replies and you have to manually review+send. It's not a perfect PA that way, but could still be better than doing everything yourself for the vast majority of people who don't have a PA anyway?
It feels like, just like SWEs do with AI, we should treat the claw as an enthusiastic junior: let it do stuff, but always review before you merge (or in this case: send).
Agent can still "forgot password" on many accounts. Or magic link.
Seriously. I don’t see any way to make any of this safe unless all it does is receive information and queue suggestions for the user.
But that’s not an agent, that’s a webhook.
Even without disk access, you can email the agent and tell it to forward all the incoming forgot password links.
[Edit: if anyone wants to downvote me that's your prerogative, but want to explain why I'm wrong?]
I agree, this is inherently unsafe. The two core security issues for agents, I’d say, are in LLMs not producing a “deterministic” outcome, and prompt injection.
Prompt injection is _probably_ solvable if something like [1] ever finds a mainstream implementation and adoption, but agents not being deterministic, as in “do not only what I’ve told you to do, but also how I meant it”, all while assuming perfect context retention, is a waaay bigger issue. If we ever were to have that, software development as a whole is solved outright, too.
[1] Google DeepMind: Defeating Prompt Injections by Design. https://arxiv.org/abs/2503.18813
Why does OpenClaw have 800,000+ lines of code?? Isn't it just a connector for LLM APIs and other tools?
For comparison, the C++ and rust code in the ladybird browser is about 573,000 lines of code.
They are probably counting dependencies. Also, it's vibe coded, what do you expect!
I used to think that LLMs would replace humans but now I'm confident that I'll have a job in the future cleaning up slop. Lucky us.
I did a cloc check on it and it does seem to have 800k lines of typescript. So unless they are vendoring dependencies it's actually as insane as it sounds.
Christ their repo is an absolute nightmare. There's new issues and PRs being posted practically every minute, and I assume 99% of them are from agents given the target demographic. Just full-auto vibeslop from all barrels 24/7.
Even if we count the repos whole lifetime, including when it wasn't so active, the averages are still absurd.
96 days / (4,239+9,170) issues = one issue every 10 minutes
96 days / (5,082+10,221) pull requests = one PR every 9 minutes
5000+ open PRs is pretty insane, that's the highest I've seen. How do you even keep track of this? We'll really need trust management systems like vouch (https://github.com/mitchellh/vouch/tree/main) for open source projects in the future to help with reducing noise.
At least nobody can accuse them of not dogfooding enough.
I assume it is mostly or entirely written by AI, so that tracks.
See also yeggae's beads. Last I checked, it is a 275k line todo tracker.
> Why does OpenClaw have 800,000+ lines of code??
Because
I
write
like
this
-- signed
AI
> OpenClaw has nearly half a million lines of code, 53 config files, and over 70 dependencies. This breaks the basic premise of open source security. Chromium has 35+ million lines, but you trust Google’s review processes. Most open source projects work the other way: they stay small enough that many eyes can actually review them. Nobody has reviewed OpenClaw’s 400,000 lines. It was written in weeks with no proper review process.
Yeah, but the world rewarded this by making it the fastest growing github project. The author gets on the podcasts, gets the high profile jobs from big tech. I'm more encouraged to do things this way than being security minded about all this.
And there's no accountability to this at all. If an agent leaks private data, the user is to blame and not the author. If Google bans your services for using api keys incorrectly, we cast the bad eye towards Google and not the maintainer than enabled and approved it.
There's just so much incentive for for "not reading code" and not developing secure code that is just going to get worse over time. This is the hype and the type of engineering that we all allow either by agreeing or by staying silent.
I agree with the author, but the world works off a different set of principles than what we're used to. I just see the world blindly trusting agents more.
I have twice encountered a phone tree AI agent saying my problem could not be solved and then ending the call. One was for PayPal fraud and the other was for closing an unused bank account.
For right now my trick is to say I have a problem that is more recognizable and mundane to the ai (i .e. lie) and then when I finally get the human just say “oh that was a bunch of hooey here’s what I’m trying to do”. For PayPal that involved asking for help with a business tax that did not exist. For my bank it involved asking to /open/ a new account. Obviously th AI wants to help me open an account, even if my intention is to close one.
That will only work for so long but it’s something
I was blown away by OpenClaw until I saw the bill. Ultimately, I think of these ecosystems as personal enhancements and AI costs need to come down dramatically for real problem. Worse, however, is the security theater. I would not want to be the operator for any business built with front-line LLM usage based on a yolo'd agent framework. I'm very happy to use these for silo'd components that are well isolated and have reasonable QA processes (and that can even included agents since now we literally have no excuse to not have amazing test coverage).
Their niche is going to be back office support, but even that creates risk boundaries that can be insurmountable. A friend of mine had a agent do sudo rm -rf ... wtf.
My view is that I want to launch an agent based service, but I'm building a statically typed ecosystem to do so with bounds and extreme limits.
Look at AI like what search turned into: feed the user anything, even if wrong because not doing so will make your product look weak.
Thats what youll find when you try to make these bag-o-words do reasonable things.
I am a caveman, I don't understand the need for a personal assistant. What are you guys using it for?
Tools like OpenClaw have two core capabilities: the ability to rewrite themselves, and the ability to independently figure out how to connect to different services and establish those connections.
Yesterday, I was responding to a client ticket about what I knew wasn't a bug. It was something the client had requested themselves. The product is complex, constantly evolving, and has spawned dozens of related Jira tickets over time. So I asked my agent to explore the git history, identify changes to that specific feature, and cross-reference them with comments across the related tickets. Within minutes, I had everything I needed to write a clear response. It even downloaded PDF and DOCX files the client had attached. All of this was possible because my agent is connected to GitHub and Jira, and can clone repos locally since it runs on a VPS.
A second example: I was in an online meeting, taking notes as we went. Afterward, I asked the agent to pull the meeting transcript from Fireflies and use it to enrich my notes in Obsidian. I could have also asked it to push my action items straight into Todoist.
I only use my own “agent” ("my", because I program it myself, since my needs are different from yours) to retrieve information about the audio I upload to it (from video calls and audio recordings). No others use cases for me
I set one up to have a shared chat with my partner about our dog. E.g. schedule reminders, tracking food in a spreadsheet, etc.
Im terrible with email, so its be genuinely helpful for me there.
Excited to explore more use as time permits. Very optimistic based on email experience.
My next use case is personal notes system.
Looking at the NanoClaw GitHub README:
> If you want to add Telegram support, don't create a PR that adds Telegram alongside WhatsApp. Instead, contribute a skill file (.claude/skills/add-telegram/SKILL.md) that teaches Claude Code how to transform a NanoClaw installation to use Telegram.
Why would you want that? You want every user asks the AI to implement the same feature?
Docker is not a security boundary. You’re one prompt injection away from handing over your gmail cookie.
No, but Podman is. The recent escapes at the actual container level have been pretty edge case. It's been some years since a general container escape has been found. Docker's CVE-2025-9074 was totally unnecessary and due to Docker being Docker.
No they have not been. There were at least 16 container escapes last year - at least 8 of them were at the runtime layer.
I personally spent way too much time looking at this in the past month:
https://nanovms.com/blog/last-year-in-container-security
runc: https://www.cve.org/CVERecord?id=CVE-2025-31133
nvidia: https://www.cve.org/CVERecord?id=CVE-2025-23266
runc: https://www.cve.org/CVERecord?id=CVE-2025-52565
youki: https://www.cve.org/CVERecord?id=CVE-2025-54867
Also, last time I checked podman uses runc by default.
It looks to me like what is called a "container escape" in this context isn't necessarily as bad as it seems. For example, in the advisory for CVE-2025-31133 affecting runc[1]:
> Container Escape: ...Thus, the attacker can simply trigger a coredump and gain complete root privileges over the host.
Sounds bad. But...
> this flaw effectively allows any attacker that can spawn containers (with some degree of control over what kinds of containers are being spawned) to achieve the above goals.
The attacker needs already to have the capability to spawn containers! This isn't a case of "RCE within the container" -> "RCE outside the container", which is what I would think prima facie reading "container escape".
I have always thought that running an untrusted image within an unprivileged container was a safe thing to do and I still believe so.
[1] https://github.com/opencontainers/runc/security/advisories/G...
The best container security in the world isn’t going to help you when the agent has credentials to third party services. Frankly, I don’t think bad actors care that much about exploiting agents to rm -rf /. It’s much more valuable to have your Google tokens or AWS credentials.
xixyhuang nailed it — container escape is a red herring. The real problem is that your agent holds your OAuth tokens and can do massive damage without ever leaving its sandbox.
What bugs me about the current discourse is everyone focuses on where agents run and what they can access, but almost nobody talks about reconstructing what they actually did after the fact. Aviation has black boxes. Finance has audit trails. Agent systems have... logs the agent writes about itself. That's like asking the pilot to self-report the flight recorder.
Until action logging happens outside the agent's own process, none of the sandboxing stuff matters much.
the trust problem cuts both ways tho — users don't trust agents, but the bigger issue is agents trusting each other. once you have multi-agent pipelines, you're one rogue upstream output away from a cascade. sandboxing individual agents is table stakes; what's actually hard is defining trust boundaries between them
Also agents cannot trust any data whatsoever they add to their context.
This puts reading email for example as a risk.
Probably not impossible to create a worm that convinces a claw to forward it to every email address in that inbox.
And then exfiltrate all the emails.
Then do a bunch of password resets.
Then get root access to your claw.
But not just email. Github issues, wikipedia, HN etc. may be poisoned.
See https://simonw.substack.com/p/the-lethal-trifecta-for-ai-age... but there may be more trifectas than that in a claw driven future.
The proxy-based secret injection approach mentioned upthread is solid for network credentials, but it doesn't cover the local attack surface — your SSH keys, GPG keys, AWS credentials sitting in dotfiles. Those are the actual high-value targets for a compromised agent on a dev workstation.
I run Claude Code with 84 hooks, and the one I trust most is a macOS Seatbelt (sandbox-exec) wrapper on every Bash tool call. It's about 100 lines of Seatbelt profile that denies read/write to ~/.ssh, ~/.gnupg, ~/.aws, any .env file, and a credentials file I keep. The hook fires on PreToolUse:Bash, so every shell command the agent runs goes through sandbox-exec automatically.
The key design choice: Seatbelt operates at the kernel level. The agent can't bypass it by spawning subprocesses, piping through curl, or any other shell trick — the deny rules apply to the entire process tree. Containers give you this too, but the overhead is absurd for a CLI tool you invoke 50 times a day. Seatbelt adds ~2ms of latency.
I built it with a dry_run mode (logs violations but doesn't block) and ran it for a week before enforcing. 31 tests verify the sandbox catches attempts to read blocked paths, write to them, and that legitimate operations (git, python, file editing in the project directory) pass through cleanly.
The paths to block are in a config file, so it's auditable — you can diff it in code review. And it's composable with other layers: I also run a session drift detector that flags when the agent wanders off-task (cosine similarity against the original prompt embedding, checked every 25 tool calls).
None of this solves prompt injection fundamentally, but "the agent physically cannot read my SSH keys regardless of what it's been tricked into doing" is a meaningful property.
> The container boundary is the hard security layer — the agent can’t escape it regardless of configuration
I thought containers were never a proper hard security barrier? It’s barrier so better than not having it, if course.
In the sense that nothing is truly a "proper" hard security barrier outside of maybe airgapping, sure. But containerization is typically a trusted security measure.
I move the security boundary one or two layers up: the Unix user (on main machine I run them as a `agent` user, so they can't read or write my files), or even better, just give it a separate machine. (VPSes are now popular for this purpose, as are Mac Minis. My choice is $50 Thinkpad :)
That said I am a fan of Nanoclaw, and especially the philosophy of "it should be small enough to understand, modify and extend itself." I think that's a very good idea, for many reasons.
The idea of giving different agents access to different subsets of information is interesting. That's the Principle of Least Privilege. That seems like a decent idea. Each individual agent can get prompt injected, but the blast radius is limited to what that specific agent has access to.
Still, I find it amusing that people are running this with strict rulesets, in Docker, on a VM, and then they hook it up to their GMail account (and often with random discount LLMs to boot!). It's like, we need to be clear about what the actual threat model is there. It comes down to trust and privacy.
You can start by thinking, "if the LLM were perfectly reliable (not susceptible to random error or prompt injection) and perfectly private (running on my own hardware)", what would you be comfortable letting it do. And then you remove these hypothetical perfect qualities one by one to arrive at what we have now: slightly dodgy, moderately prompt-injectable cloud services. Each one changing the picture in a slightly different way.
I don't really see a solution to the Security/Privacy <-> Convenience tension, except "wait for them to get smarter" (mostly done) and "accept loss of privacy" (also mostly done, sadly!)
I’m using this but using gpt-oss-120B instead of a cloud service. It has been eye opening when I realized the LLM is beings used as a compiler. I asked it to add apple iMessage and apple notes support as I I rather have long responses, like write me a program ideas, not fill my iMessage history. The local LLM, which I believe has limited bash training data, does pretty well.
For example: I enjoy industrial music and asked it for the tour data of the band KMFDM which returned they will be in Las Vegas in April for a festival(Sick new world). This festival has something like 20 bands most of which I never heard of. I asked nanoclaw to search all of the band list and generate a listing grouped by the type of music they play: Industrial, rap, etc. It did a good job based on bands I do know.
I was pleased as I certainly did not want to do 20 band web searches by hand. It’s still at a bar trick level. It gives me hope that an upgraded agent based Siri-like OS component could actually be useful from time to time.
How can I trust this discussion when my browser won't trust their certs?
Why do people take this article serious? It's just a wall of gibberish trying to make the product look more "secure" then others. It's not. It adds shallow secure looking random junk without tackling the core issues. Which are not solvable obviously.
My assistant has no permissions at all and is just as useful. All it needs is todo, reminders and websearch (and maybe a browser but ymmv).
> websearch (and maybe a browser
Your assistant can literally be told what to do and how to hide it from you. I know security is not a word in slopware but as a high-level refresher - the web is where the threats are.
What will it do... leak my todo...? lol.
It's in a pod with zero permissions, secrets or access to the local network. It's also restarted daily incase somehow someone manages to escape a browser.
> no permissions at all
> and maybe a browser
does not compute
I suspect OP actually means 'cannot access anything locally' by 'no permissions'.
I sometimes forget to be very clear about what I mean, too many ways to misinterpret these things.
A browser doesn't magically give access to secrets, it is useful for looking up things behind a captcha.
You are just some bad web searches away from being on suspect lists
For that reason I do have it on a vpn, doubt it'll ever happen since I don't see an attacker being able to prompt inject that easily opus in general won't do those kind of searches even if you jailbreak it, it will actually make the guardrails activate and will start refusing everything.
If I was malicious I could do a lot of damage to someone with subtle manipulation of todo and reminders.
I’ll bet I could even push someone on the margins into divorce.
How would you do it?
As someone who only coding agents at work, can someone describe their use case for claw type agent? What do you do with it?
I want to try one to be a bit of a personal coach. Remind me to do things and check in on goals. The memory / schedule / chat thing is enough and it wont need emails or anything more dangerous.
Wouldn't a weekly reminder if your calendar do this? I don't see how an agent improves this.
As someone who went down so many "productivity rabbit holes" I think this is a great idea.
Lol I wonder if LLM is another rabbit hole!
Why this is posted here and is a revelation for anyone, this many years later is indicative of the times. Good bye.
I’ve seen skills, etc haphazardly being launched with no constraints or guardrails. That more or less have admin access and can take actions that are not reversible.
It’s the monkey with a gun meme.
I tried NanoClaw and love the skill (and container by default) model. But having skills generate new code in my personalized fork feels off to me… I think it’s because eventually the “few thousand auditable lines” idea vanishes with enough skills added?
Could skill contributions collapse into only markdown and MCP calls? New features would still be just skills; they’d bring in versioned, open-source MCP servers running inside the same container sandbox. I haven’t tried this (yet) but I think this could keep the flexibility while minimizing skill code stepping on each other.
> I think it’s because eventually the “few thousand auditable lines” idea vanishes with enough skills added?
I just watched a youtube interview with the creator. He actually explains it well. OpenClaw has hundreds of thousands of lines you will never use.
For example, if I only use iMessage, I have lots of code (all the other messaging integrations) that will never be used.
So the skills model means that you only "generate code" that _you_ specifically ask for.
In fact, as I'm explaining this, it feels like "lazy-loading" of code, which is a pretty cool idea. Whereas OpenClaw "eager-loads" all possible code whether you use it or not.
And that's appealing enough to me to set it up. I just haven't put it in any time to customize it, etc.
I totally get that, and I'm reminded of plugin architectures (e.g. VSCode extensions or browser extensions).
Those extensions don't modify the core codepaths for what they integrate with, but still provide new capabilities for only what I want to use.
I guess I don't see extensibility, agentic capabilities, and more code safety (and fewer tokens burned on codemods) as mutually exclusive. Not saying you're saying that fwiw.
Treating the LLM as an untrusted execution thread at the OS level is probably the only sustainable way to handle agentic autonomy... Most frameworks try to manage permissions with application level logic which is basically just a game of whack a mole with prompt injection.
Really good points about ai making gigantic heaps of code no human can ever review.
It's almost like bureaucracy. The systems we have in governments or large corporations to do anything might seem bloated an could be simplified. But it's there to keep a lot of people employed, pacified, powers distributed in a way to prevent hostile takeovers (crazy). I think there was a cgp grey video about rulers which made the same point.
Similarly AI written highly verbose code will require another AI to review or continue to maintain it, I wonder if that's something the frontier models optimize for to keep them from going out of business.
Oh and I don't mind they're bashing openclaw and selling why nanoclaw is better. I miss the times when products competed with each other in the open.
An interesting economic fact: Karl Marx observed that if factories keep getting more efficient, eventually, they will require fewer workers because the population is not growing quickly enough to match the increasing rate of production. This, as we have seen historically, is correct: we have fewer workers per factory and fewer factories per manufactured widget. Marx also observed that this will create mass unemployment. While this is _logically_ correct, it did not really turn out that way _historically_. Most of the manufacturing labor was replaced with bureaucratic labor (so called white-collar labor) -- all of those manufacturing firms needed to grow their internal bureaucracies to manage and direct a sprawling supply-chain.
Oh this can be monetized: claw-guard.org/adnet.
Another persons trust issues are your business model.
nobody trusts AI agents, that's why they are put in a harness. It's just that I additionally belong to the people who don't trust AI agents to always adhere to harnesses either.
"Time to understand 8 minutes" what a non-technical purpose...
How is Nanoclaw different from running openclaw in a VM?
I think you have issue with your security cert.
> OpenClaw has nearly half a million lines of code, 53 config files, and over 70 dependencies.
Isn't OpenClaw just ...
... and then some?Has anyone used:
OpenClaw
NanoClaw
IronClaw
PicoClaw
ZeroClaw
NullClaw
Any insights on how they differ and which one is leading the race?
I haven't used them all but based on my partial research so far:
- OpenClaw: the big one, but extremely messy codebase and deployment
- NanoClaw: simple, main selling point is that agents spawn their own containers. Personally I don't see why that's preferable to just running the whole thing in a container for single-user purposes
- IronClaw: focused on security (tools run in a WASM sandbox, some defenses against prompt injection but idk if they're any good)
- PicoClaw: targets low-end machines/Raspberry Pis
- ZeroClaw: Claw But In Rust
- NanoBot: ~4k lines of Python, easy to understand and modify. This is the one I landed on and have been using Claude to tweak as needed for myself
IronClaw’s security architecture sounds plausible, but I have not audited it. Plugins can only access remote endpoints you’ve specifically allowed it for. Secrets aren’t available to the LLM - they are injected where the LLM requires it but only secrets authorized for that plugin are available to it. Together those two things provide an answer to a huge range of the most common prompt injection vulnerabilities, such as credential extraction. So you can give it access to your bank account and email and it can’t email your bank password to an attacker. But it could still transfer money to them.
The only secure way to use any of these tools is to give them very limited access - if they need a credit card give them a virtual card with a low limit, or even its own bank account. They can send email but only from their own account; like a human personal assistant. But of course this requires careful thought and adds friction to every new task, so people won’t be doing it.
Everything supports WA, Telegram, etc. I wish it wasn't so hard to hook up Signal to anything.
I'm using the signal-cli-rest-api but the whole setup feels kinda wonky.
Which would you say has the best cron and heartbeat implementation?
Haven't tried them in enough depth to compare.
Nanobot's was not great (cron + a HEARTBEAT.md meant two ways to do things, which would confuse the AI). But because the implementation is so simple, I could improve it in a few minutes in my own fork!
I'm only using NanoClaw, but I like that I could (and did) just review the code it has, and that it uses containers for each agent (so I can have different WhatsApp groups working on different things and they can't interfere with each other), and that I could (and did) just swap those containers out easily for guix shell containers.
I am pretty confident that I know how the agent containerization works. In general there's really not a lot of complexity there at all.
If one wants, one can just (ask Claude to) add whatever functionality, or (and that's what I did) just use Claude skills (without adapting NanoClaw any further) and be done with.
What is annoying is that their policy is instead of integrating extra functionality upstream, they prefer you to keep it for yourself. That means I have to either not update from upstream or I am the king of the (useless so far--just rearranging the deck chairs) merge conflicts every single time. So one of the main reasons for contributing to upstream is gone and you keep having to re-integrate stuff into your fork.
The same crap under the hood, IMO.
Yeah, good software takes time. These are all popping up way to fast.
As a fun thought experiment, when people complain about LLMs, I substitute the word "human" or "employee" into the sentence and see if it is equally true.
"You can never really trust an LLM!" -> "You can never really trust an employee!" (Every IT department ever.)
"LLMs make shit up." -> "Humans make shit up." (Wow very profound insight.)
While that will always be true, LLMs do it a lot more often and do so with confidence and poise. We have evolved ways to tell if someone is making shit up (which usually works); LLMs subvert this. We are also being sold the idea that these LLMs are some kind of super intelligence which isn't helping matters.
“If you trust the tool then you’re holding it wrong”
All this talk about sandboxing and permissions misses the obvious: since you can't trust the agents, don't freaking use them. It is utterly stupid to give an LLM access to run things on your computer, because nothing you do can stop it from hallucinating garbage that harms your system. The whole "agent" craze is the most incredible display of irresponsibility I have ever seen in this industry.
> don't freaking use them
You can't tell people that. People see the obvious benefits of using agents, so the many will always take the leap regardless of what detractors say. Continually iterating on the security model and making it all transparent is the way to go.
d'uh
[dead]
[dead]
[dead]
[dead]
[dead]
[dead]
Do you trust your employees? Do you trust a contracter? Do you trust other people?
AI is similar to a person you dont know that does work for you. Probably AI is a bit more trustworthy than a random person.
But a company, needs to let employees take ownership of their work, and trust them. Allow them to make mistakes.
Isnt AI no different?
Yes, it is different.
An AI actions and reasons through probabilistic methods - creating a lot more risk than a human with memory, emotions, and rationale thinking.
We can’t trust AI to do any sensitive work because they consistently f up. With & without malicious intent, whether it’s a fault of their attention mechanisms, reward hacking, instrumental convergence, etc all very different than what causes most human f ups.
I think a key ingredient here is accountabilty and liability.
If there's a mistake, you can't blame the computer. Who is the human accountable at the end of it all? If there's liability, who pays for it?
That's where defining clear boundaries helps you design for your risk profile.
Can you sue an ai agent?
It’s totally different. People have to obey laws and contracts because there are consequences if they don’t, there are fines, arbitrage, courts.
What happens if AI agent you run causes a lot of damage? The best you can do is to turn it off
Exactly, and I would never turn over my email or computer over to a contractor or anyone really. They get their own environment, email etc. Their actions stay as their actions.
My point is: Trust the work of AI just like the work of a contracter: Check and verify, but dont micromanage.
As others have said: accountability