[HN Gopher] Don't trust AI agents
___________________________________________________________________
Don't trust AI agents
Author : gronky_
Score : 293 points
Date : 2026-02-28 12:39 UTC (10 hours ago)
(HTM) web link (nanoclaw.dev)
(TXT) w3m dump (nanoclaw.dev)
| formerly_proven wrote:
| d'uh
| smallpipe wrote:
| Docker is not a security boundary. You're one prompt injection
| away from handing over your gmail cookie.
| benatkin wrote:
| 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.
| eyberg wrote:
| 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.
| jrpear wrote:
| 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/advisor
| ies/G...
| xienze wrote:
| 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.
| himata4113 wrote:
| 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).
| piker wrote:
| > no permissions at all
|
| > and maybe a browser
|
| does not compute
| yyyk wrote:
| I suspect OP actually means 'cannot access anything locally'
| by 'no permissions'.
| isodev wrote:
| > 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.
| croes wrote:
| You are just some bad web searches away from being on suspect
| lists
| sarchertech wrote:
| 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.
| VladVladikoff wrote:
| 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?
| gronky_ wrote:
| 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...
| float4 wrote:
| 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).
| jrecyclebin wrote:
| Agent can still "forgot password" on many accounts. Or magic
| link.
| coffeefirst wrote:
| 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?]
| msdz wrote:
| 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
| drujensen wrote:
| 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.
| sanex wrote:
| 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.
| MarkSweep wrote:
| 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?
| jimminyx wrote:
| 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.
| solfox wrote:
| 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?
| bitwize wrote:
| > 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?
| fvdessen wrote:
| 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.
| adithyassekhar wrote:
| 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.
| nz wrote:
| 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.
| shich wrote:
| 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
| medi8r wrote:
| 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.
| lucrbvi wrote:
| Why does OpenClaw have 800,000+ lines of code?? Isn't it just a
| connector for LLM APIs and other tools?
| zarzavat wrote:
| 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.
| scandinavian wrote:
| 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.
| jsheard wrote:
| 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
| CrazyStat wrote:
| At least nobody can accuse them of not dogfooding enough.
| mihaelm wrote:
| 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.
| cap11235 wrote:
| See also yeggae's beads. Last I checked, it is a 275k line todo
| tracker.
| marginalia_nu wrote:
| For comparison, the C++ and rust code in the ladybird browser
| is about 573,000 lines of code.
| re-thc wrote:
| > Why does OpenClaw have 800,000+ lines of code??
|
| Because
|
| I
|
| write
|
| like
|
| this
|
| -- signed
|
| AI
| paxys wrote:
| I assume it is mostly or entirely written by AI, so that
| tracks.
| buremba wrote:
| 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.
| alexhans wrote:
| 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).
| daveguy wrote:
| 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.
| fnord77 wrote:
| > 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)
| buremba wrote:
| > 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.
| zahlman wrote:
| > 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.
| arianvanp wrote:
| 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.
| zahlman wrote:
| > 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".
| livestories wrote:
| I think mailto: links they output (a la
|
| https://mailtolink.me/
|
| ) are a great way to get these drafts out even.
| Doublon wrote:
| 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?
| swid wrote:
| 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.
| zahlman wrote:
| 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.
| shich wrote:
| 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.
| buremba wrote:
| > 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.
| rdtsc wrote:
| > 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.
| rco8786 wrote:
| 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.
| TeeWEE wrote:
| 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?
| TeeWEE wrote:
| My point is: Trust the work of AI just like the work of a
| contracter: Check and verify, but dont micromanage.
| adam12 wrote:
| Can you sue an ai agent?
| alexhans wrote:
| 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.
| arnvald wrote:
| 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
| ramoz wrote:
| 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.
| juggle-anyhow wrote:
| 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.
| dimitri-vs wrote:
| As others have said: accountability
| ed_mercer wrote:
| How is Nanoclaw different from running openclaw in a VM?
| xrd wrote:
| How can I trust this discussion when my browser won't trust their
| certs?
| badsectoracula wrote:
| > 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.
| gyomu wrote:
| 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?
| ElProlactin wrote:
| Enshittification comes for us all
| medi8r wrote:
| He is a Lisper too, making it more ironic. Lisp the power to
| heavily reduce cruft by heavy customization with macros.
| saltcured wrote:
| Thousand left-parens per hour...?
| ball_of_lint wrote:
| I mean, I didn't close them all but still, ... Look at
| the code! That's gotta be valuable
| wiseowise wrote:
| It's all virtual virtue signaling. If you were to say this
| shit in the office, you'd be walked out pretty fast.
| Zak wrote:
| 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.
| wiseowise wrote:
| PG is signaling his AI bros, idk.
| Zak wrote:
| 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.
| andrei_says_ wrote:
| Maybe it depends on whose office? C-suite management who
| salivate after reducing software engineer headcount?
| amelius wrote:
| Technical debt is increasing by 1,000 lines an hour.
| manoDev wrote:
| They need to keep the musical chairs going.
| steve1977 wrote:
| We all know that a thousand parentheses would be better
| metric.
| ruszki wrote:
| 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.
| TacticalCoder wrote:
| > 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.
| ruszki wrote:
| 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.
| aerhardt wrote:
| 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.
| KerrAvon wrote:
| obligatory Dabblers and Blowhards
| https://idlewords.com/2005/04/dabblers_and_blowhards.htm
| eichin wrote:
| 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...)
| steveklabnik wrote:
| > 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
| tasuki wrote:
| That doesn't disprove anything. Peter Norvig is about as
| far from "not good programmer" as one can get.
| steveklabnik wrote:
| 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.
| anonnon wrote:
| > pg wrote a Lisp dialect, Arc
|
| Wasn't Arc just a collection of Scheme macros?
| lukan wrote:
| 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.
| MadxX79 wrote:
| Brook's law anno 2026:
|
| "Adding manpower to a late software project makes it later --
| unless that manpower is AI, then you're golden!"
| smikhanov wrote:
| That law (formulated in the 70s, I'll remind the reader)
| wasn't true for at least couple decades now.
| medi8r wrote:
| Why not? What changed? It seems like a human factors thing.
| New people have to get up to speed. Doers become trainers.
| smikhanov wrote:
| 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.
| medi8r wrote:
| Hmm interesting, thanks! I was ready to argue but now I
| have to think, which is even better.
| smikhanov wrote:
| 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/
| dasil003 wrote:
| 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.
| ldng wrote:
| Plus, the "since there are more resources, let's add
| features" effect.
| steveklabnik wrote:
| 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!
| spacecadet wrote:
| 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.
| sd9 wrote:
| 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.
| tdeck wrote:
| I asked Grok to rewrite your comment and it did it in 2400
| words. I hope you know you'll be obsolete soon.
| hirako2000 wrote:
| 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.
| andrei_says_ wrote:
| > 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.
| inciampati wrote:
| Lines of code are nothing. It's verification that creates
| value.
| supriyo-biswas wrote:
| 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.
| jorvi wrote:
| 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.
| wredcoll wrote:
| 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.
| ninkendo wrote:
| 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.
| bee_rider wrote:
| 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?
| ninkendo wrote:
| 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!)
| FEELmyAGI wrote:
| 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)
| ninkendo wrote:
| 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.)
| FEELmyAGI wrote:
| 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.c
| om+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.
| ninkendo wrote:
| > 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.
| svilen_dobrev wrote:
| 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?
| badsectoracula wrote:
| 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.
| halnine9000 wrote:
| >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
| KronisLV wrote:
| 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.
| CuriouslyC wrote:
| 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.
| bee_rider wrote:
| "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.
| theptip wrote:
| 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.
| K0balt wrote:
| 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.
| samiv wrote:
| 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?
| tartoran wrote:
| 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.
| skeledrew wrote:
| TDD would help here, particularly if a human writes - or at
| least thoroughly reviews - the tests.
|
| https://martinfowler.com/bliki/TestDrivenDevelopment.html
| simgt wrote:
| 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.
| danjc wrote:
| 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.
| truthbe wrote:
| 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
| andai wrote:
| >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.
| nemo44x wrote:
| 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.
| nkzd wrote:
| As someone who only coding agents at work, can someone describe
| their use case for claw type agent? What do you do with it?
| medi8r wrote:
| 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.
| nkzd wrote:
| As someone who went down so many "productivity rabbit holes"
| I think this is a great idea.
| medi8r wrote:
| Lol I wonder if LLM is another rabbit hole!
| theturtletalks wrote:
| Has anyone used:
|
| OpenClaw
|
| NanoClaw
|
| IronClaw
|
| PicoClaw
|
| ZeroClaw
|
| NullClaw
|
| Any insights on how they differ and which one is leading the
| race?
| huqedato wrote:
| The same crap under the hood, IMO.
| redman25 wrote:
| Yeah, good software takes time. These are all popping up way
| to fast.
| tao_oat wrote:
| 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
| theturtletalks wrote:
| Which would you say has the best cron and heartbeat
| implementation?
| tao_oat wrote:
| 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!
| barbazoo wrote:
| 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.
| jeremyjh wrote:
| 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.
| dannymi wrote:
| 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.
| echoangle wrote:
| 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?
| spacecadet wrote:
| Why this is posted here and is a revelation for anyone, this many
| years later is indicative of the times. Good bye.
| Sytten wrote:
| I am a caveman, I don't understand the need for a personal
| assistant. What are you guys using it for?
| vitto_gioda wrote:
| 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
| ramoz wrote:
| 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.
| andrew_eu wrote:
| 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.
| rubslopes wrote:
| 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.
| vitto_gioda wrote:
| "Time to understand 8 minutes" what a non-technical purpose...
| gmerc wrote:
| Oh this can be monetized: claw-guard.org/adnet.
|
| Another persons trust issues are your business model.
| Yokohiii wrote:
| 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.
| justonceokay wrote:
| 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
| Kiboneu wrote:
| "If you trust the tool then you're holding it wrong"
| mathgladiator wrote:
| 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.
| cyanydeez wrote:
| 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.
| nickdirienzo wrote:
| 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.
| atonse wrote:
| > 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.
| nickdirienzo wrote:
| 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.
| desireco42 wrote:
| I think you have issue with your security cert.
| bigstrat2003 wrote:
| 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.
| skeledrew wrote:
| > 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.
| Eggpants wrote:
| 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.
| raffael_de wrote:
| > OpenClaw has nearly half a million lines of code, 53 config
| files, and over 70 dependencies.
|
| Isn't OpenClaw just ... while(true) { in
| = read_input(); if(in) { async relay_2_llm(in);
| } sleep(1.0); }
|
| ... and then some?
| simon_void wrote:
| 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.
| aerhardt wrote:
| 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?
| andai wrote:
| 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!)
| jswelker wrote:
| 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.)
___________________________________________________________________
(page generated 2026-02-28 23:01 UTC)