I've used the analogy of a circular saw before ("it's not really sawing, because you can't feel the wood...")
It's easy to just slab on a Skil saw, cut through the beam and it'll be somewhat straight. But when every manual stroke counts, there's enough time on a human time scale to correct every little mistake. It's definitely possible to become skilled at using the circular saw, but it takes effort that it feels like you don't need at first.
This is similar. LLMs are so powerful for writing code that it's easy to become complacent and forget your role as the engineer using the tool: guaranteeing correctness, security, safety and performance of the end result. When you're not invested in every if-statement, forgetting to check edge cases is really easy to do. And as much as I like Claude writing test cases for me, I also have to ensure the coverage is decent, that the implicit assumptions made about external library code is correct, etc. It takes a lot of effort to do it right. I don't know why Mycelium thinks they invented interfaces for module boundaries, but I'm pretty sure they are still as suceptible to that "0" not behaving as you'd expect, or the empty string being interpreted as "missing." Or the CSG algorithm working, except if your hole edges are incident with some boundary edges.
I've been thinking like a CNC. It can be made, but the edges are rough, needs sanding. OR - you accept that the edges are borderline dangerous. Also, some complex joints can't be built with a CNC
> Mycelium structures applications as directed graphs of pure data transformations. Each node (cell) has explicit input/output schemas. Cells are developed and tested in complete isolation, then composed into workflows that are validated at compile time. Routing between cells is determined by dispatch predicates defined at the workflow level — handlers compute data, the graph decides where it goes.
No still don't understand
> Mycelium uses Maestro state machines and Malli contracts to define "The Law of the Graph," providing a high-integrity environment where humans architect and AI agents implement.
I have the same problem. The "What It Is" section starts with "Mycelium is a Clojure workflow framework built on Maestro" and that's a bit generic. Maybe something to test some AI generated code and then test if the tests are tested enough using Closure, but I'm not entirely sure.
The main question that is not obvious, is what should I use it for?
I don't understand why the poster (which is the author) links us to a slop report of a test for their library. It would be much more effective to cover part of this info into the README where we get the context of what they want to achieve (where there is a very clear "Why?" section), and then link to it instead. I have flagged it as AI slop.
I don't understand LISP or Clojure, but it seems to be some kind of library for making web services out of LISP, which has some separate components that are somehow well defined. And somehow it's all related to AI.
Again I don't know much about Clojure and I am too slow for functional programming in general.
The top-level README gives a bit better idea. Armed with that the explanation might sound a bit more understandable.
I'm not familiar with the project (or Clojure), but let me try to explain!
> Mycelium structures applications as directed graphs of pure data transformations.
There is a graph that describes how the data flows in the system. `fn(x) -> x + 1` in a hypothetical language would be a node that takes in a value and outputs a value. The graph would then arrange that function to be called as a result of a previous node computing the parameter x for it.
> Each node (cell) has explicit input/output schemas.
Input and output of a node must comply to a defined schema, which I presume is checked at runtime, as Clojure is a dynamically typed language. So functions (aka nodes) have input and output types and presumably they should try to be pure. My guess is there should be nodes dedicated for side effects.
> Cells are developed and tested in complete isolation, then composed into workflows that are validated at compile time.
Sounds like they are pure functions. Workflows are validated at compile time, even if the nodes themselves are in Clojure.
> Routing between cells is determined by dispatch predicates defined at the workflow level — handlers compute data, the graph decides where it goes.
When the graph is built, you don't just need to travel all outgoing edges from a node to the next, but you can place predicates on those edges. The aforementioned nodes do not have these predicates, so I suppose suppose the predicates would be their own small pure-ish functions with the same as input data as a node would get, but their output value is only a boolean.
> to define "The Law of the Graph," providing a high-integrity environment where humans architect and AI agents implement.
Well, beats me. I don't know what is "The Law of the Graph" and Internet doesn't seem to know either. I suppose it tries to say how you can from the processing graph to see that given input data to the ingress of the graph you have high confidence that you will get expected data at the final egress from the graph.
I do think these kind of guardrails can be beneficial for AI agents developing code. I feel that for that application some additional level of redundancy can improve code quality, even if the guards are generated by the AI code to begin with.
The people using these programs are generating massive amounts of code, and you won't convince me they're actually carefully understanding most of it, if they even read it all. And it bypasses the first verification step where you are actively typing in the code that will be run.
I didn't downvote you, but I've noticed recently a trend on HN that just asking a normal question (possibly to start a discussion) gets downvoted for no apparent reason and without any explanation. Not good etiquette, in my opinion.
I think it's all the angry people who were wrong about AI. Every week they come on HN and say AI is utter crap and useless, and every week AI becomes more and more part of the developer work flow.
I would be pissed off too if I was a hypocrite who was so sure AI was total garbage and was now at the same time needing to use claude on a daily basis.
A lot of developers are going through an identity crisis where their skills are becoming more and more useless and they need to attack comments like the above in a desperate but futile attempt to make themselves matter.
You chosen AI agent can and will plan as far ahead as you tell it to plan. If you tell it to do things in iteration 1 that might block it in iteration 3 then you should have told it more about where you want to go back in iteration 1.
At some point I have to describe what I need with such a level of detail and precision, that if I had chosen to wrote it in my language of interest I'd have had the code I wanted long before i finish writing all the boundry conditions, safe guards, long term pitfalls etc. Thats if the system even respects all of those things, it might just lose track of some instruction at some point or make some bs placeholder and now we're back to bug hunting, only i'm now wading through code that is best described as slop.
You're saying that projects need to be waterfall rather than Agile in order to avoid making architecture mistakes you'll regret later.
The problem with that is that as you build you learn things, and that changes the plan. Consequently those mistakes are inevitable. What you should do is an approach where you have a high level plan up front, and detailed plans about the specific features as you need them. Mistakes will still happen but you'll be able to see them, and correct them, faster.
No, I am saying that you are trading what you spend effort on when using LLM's. Do you give up the effort of writing for the effort of review? Weather you should and if you will benefit really depends on your expertise and skill set.
If you're a novice, or even intermediate, use AI in a feedback kind of way, see if it can pinpoint and explain problems with your current code and offer feedback/recommendations. Not code, but dot point human language feedback like you'd get from a senior dev.
If the AI is writing code that is beyond what you could produce yourself, you have no business trusting the code the AI produces. This is because, as anyone who can produce high level code will tell you, AI is wrong too frequently to blindly trust. You have to engage critically with output. Full auto is a disaster waiting to happen.
The problem is, for many, good looking but fundamentally flawed code is indistinguishable from the real deal, and so they simply outsource their ability to critically think to a thing that simply cannot. This is a big problem and the evidence for this claim is littered throughout this comment section.
It's starting to become obvious that if you can't effectively use AI to build systems it is a skill issue. At the moment it is a mysterious, occasionally fickle, tool - but if you provide the correct feedback mechanisms and provide small tweaks and context at idiosyncrasies, it's possible to get agents to reliably build very complex systems.
> At the moment it is a mysterious, occasionally fickle, tool - but if you provide the correct feedback mechanisms and provide small tweaks and context at idiosyncrasies, it's possible to get agents to reliably build very complex.
This sounds like arguing you can use these models to beat a game of whack-a-mole if you just know all the unknown unknowns and prompt it correctly about them.
This is an assertion that is impossible to prove or disprove.
No it's more like if you knew how to build it before - LLM agents help you build it faster. There's really no useful analogy I can think of, but it fits my current role perfectly because my work is constantly interrupted by prod support, coordination, planning, context switching between issues etc.
I rarely have blocks of "flow time" to do focused work. With LLMs I can keep progressing in parallel and then when I get to the block of time where I can actually dive deep it's review and guidance again - focus on high impact stuff instead of the noise.
I don't think I'm any faster with this than my theoretical speed (LLMs spend a lot of time rebuilding context between steps, I have a feeling current level of agents is terrible at maintaining context for larger tasks, and also I'm guessing the model context length is white a lie - they might support working with 100k tokens but agents keep reloading stuff to context because old stuff is ignored).
In practice I can get more done because I can get into the flow and back onto the task a lot faster. Will see how this pans out long term, but in current role I don't think there are alternatives, my performance would be shit otherwise.
You could probably replace LLM with "junior engineer" here as it sounds like you're basically a manager now. The big negative that LLMs have in comparison with junior engineers is that they can't learn and internalise new information based on feedback.
I don't like that analogy. If I had to work with a Claude like junior I would ask for them to get removed from my team - inability to learn stuff, completely unexpected/unrelatable faliure modes and performance.
On the other hand Claudes tenacity, stamina and sustained speed is superhuman. The more capable models become the more valuable this is.
The assertion was "if you really know how to prompt, give feedback, do small corrections and fix LLM errors, then everything works fine".
It is impossible to prove or disprove because if everything DOES NOT work fine you can always say that the prompts were bad, the agent was not configured correctly, the model was old, etc. And if it DOES work, then all of the previous was done correctly, but without any decent definition of what correct means.
>And if it DOES work, then all of the previous was done correctly, but without any decent definition of what correct means.
If a program works, it means it's correct. If we know it's correct, it means we have a definition of what correct means otherwise how can we classify anything as "correct" or "incorrect". Then we can look at the prompts and see what was done in those prompts and those would be a "correct" way of prompting the LLM.
You don’t know it works. That you so glibly speak about products working is proof that your engineering judgment is impaired. You can’t infer the exact contents of a black box merely by looking at outside behavior.
The fundamental fallacy you are exhibiting here is similar to saying that rolling a six sided die and getting a “6” means that you will always get a 6 any time you roll it. And that if you get a 6 and wanted a 6, you must have therefore rolled those dice “correctly” and had you not gotten a 6 that would have meant you rolled them “wrong.”
>You don’t know it works. That you so glibly speak about products working is proof that your engineering judgment is impaired. You can’t infer the exact contents of a black box merely by looking at outside behavior.
I don't know the exact internals of a car. But I can infer my car works by driving it.
>The fundamental fallacy you are exhibiting here is similar to saying that rolling a six sided die and getting a “6” means that you will always get a 6 any time you roll it. And that if you get a 6 and wanted a 6, you must have therefore rolled those dice “correctly” and had you not gotten a 6 that would have meant you rolled them “wrong.”
Bro we rolled that dice MULTIPLE times. It's not a one time thing. And the "rolling" of the die is done with a CHAIN of MULTIPLE qureries strung together. This is not one roll. It's multitudes of data points. Yes results can be inconsistent from a technical standpoint, but the general result converges on a singular trend.
We know that much is true: a statistic and that is at most all we can say about reality as we know it as science formalized can only give a statistic as an answer.
"I don't know the exact internals of a car. But I can infer my car works by driving it."
No, you can't infer that it "works." Only that it CAN work. The car may be poisoning you with carbon monoxide. Your rear brakes may have become disconnected (happened to me). The antilock braking system may have a faulty sensor that only fails at very low speed, leading to them engaging when making a normal stop, but also preventing the mechanic from seeing the problem, because he didn't listen to your bug report and instead tried to repro the effect with high speed panic stops (also happened to me).
If I use a product and have a good experience, I can conclude that SOMETHING must be going well, but not that EVERYTHING is going well.
>No, you can't infer that it "works." Only that it CAN work. The car may be poisoning you with carbon monoxide. Your rear brakes may have become disconnected (happened to me). The antilock braking system may have a faulty sensor that only fails at very low speed, leading to them engaging when making a normal stop, but also preventing the mechanic from seeing the problem, because he didn't listen to your bug report and instead tried to repro the effect with high speed panic stops (also happened to me).
This is called pedantitic reasoning. You look like a drowning person trying to stay afloat.
Say i buy into your mysticism based take, is it a useful tool if it blows up in damn well near every professionals face?
lets say i accept you and you alone have the deep majiks required to use this tool correctly, when major platform devs could not so far, what makes this tool useful? Billions of dollars and environment ruining levels of worth it?
I'd say the only real use for these tools to date has been mass surveillance, and sometimes semi useful boilerplate.
> is it a useful tool if it blows up in damn well near every professionals face
It doesn't, that's ego-preserving cope. Saying that this stuff doesn't work for "damn well near every professional" because it doesn't work for you is like a thief saying "Everybody else steals, why are you picking on me"? It's not true, it's something you believe to protect your own self-image.
It works fine for me, because I don't trust to to do anything more than line changes, self-contained prototypes or minor updates. I've seen what happens when people give llms full control over authoring, and it has never worked out. Just look at the dumpster fire spotify has become. Its a buggy mess that barely works and is openly touted as being primarily llm developed at present.
point me towards something complex which llms have contributed towards significantly without massive oversight where they didnt fuck things up. I'll eat my words happily, with just a single example.
Honestly people are in such a weird place with this shit. I'm not saying don't read the fucking code - but I managed to get my setup to write 100k lines of indistinguishable SWE code in a week or so. The main limitation was my reading speed. This is something like a 10x speedup for me.
How does one verify 100k lines in a week? Let alone evaluate it to being SWE equivallent? That's super human. I like to think I am pretty good at what I do, but really critically engaging with 100k lines in a week is beyond even 10 of me. Forgive my skepticism, but I'm going to hazard the guess that you don't know what the fuck you're doing. You've lost your goddamn mind if you think you're doing anything other than skim read at a rate of 42 lines a minute for your entire work day without a break.
You have a fair perspective and I'm not going to try to move you from it. You have my exact opinion as of 3 months ago. I will just suggest you earnestly try it yourself.
I have, hence my perspective. For boiler plate and solved problems, it can do ok. However, anytime it needs to do something novel it will be hit and miss, usually miss. If it needs to do something where best practice has changed but training data overwhelmingly does bad / dated practice, you'll get that if you don't specify. Loads of issues like that. So, without giving small isolated and well framed tasks the output of which is then critically engaged with, you'll get increasingly opaque and unstable code.
On Saturday I had claude generate ~10k of lines of Lua code which uses the libASS subtitle format to build up nearly two dozen GUI widgets from subtitle drawing primitives, including nestable scrollable containers with clipping, drop down menus, animated tab bars, and everything else I could think of. I read probably about 100 lines of code myself that day, I "verified" the code only by testing out the demo claude was updating through the process.
Then on Sunday I woke up and had claude bang out a series of half a dozen projects each using this GUI library. First, a script that simply offers to loop a video when the end is reached. Updated several of my old scripts that just print text without any graphical formatting. Then more adventurous, a playlist visualizer with support for drag to reorder. Another that gives a nice little control overlay for TTS reading normal media subtitles. Another that let's people select clips from whatever they're watching, reorder them and write out an edit decision list, maybe I'll turn this one into a complete NLE today when I get home from work.
Reading every line of code? Why? The shit works, if I notice a bug I go back to claude and demand a "thoughtful and well reasoned" fix, without even caring what the fix will be so long as it works.
The concepts and building blocks used for all of this is shit I've learned myself the hard way, but to do it all myself would take weeks and I would certainly take many shortcuts, like certainly skipping animations and only implementing the bare minimum. The reason I could make that stuff work fast is because I already broadly knew the problem space, I've probably read the mpv manpage a thousand times before, so when the agent says its going to bind to shift+wheel for horizonal scrolling, I can tell it no, mpv has WHEEL_LEFT and RIGHT, use those. I can tell it to pump its brakes and stop planning to load a PNG overlay, because mpv will only load raw pixel data that way. I can tell it that dragging UI elements without simultaneously dragging the whole window certainly must be possible, because the first party OSC supports it so it should go read that mess of code and figure it out, which it dutifully does. If you know the problem space, you can get a whole lot done very fast, in a way that demonstrably works. Does it have bugs? I'd eat a hat if it doesn't. They'll get fixed if/when I find them. I'm not worried about it. Reading every line of code is for people writing airliner autopilots, not cheeky little desktop programs.
right, but we're not talking cheeky desktop personal programs here. Who cares what you do for your own devices and in your own time? Absolutely no one gets to tell you what to do there, so why discuss it? Live your life, do your thing, great! But that isn't what is being discussed here.
We're talking about the capabilities of the technology. I would not even think about using LLM output in life critical roles, but we're not talking about only such scenarios. I'm addressing your claim that these
> blows up in damn well near every professionals face
If you know how to use the tools, and know their limitations, you can generate vast quantities of useful code very quickly. If you can't manage this, its PEBKAC. You're saying you don't trust these to make more than minor changes, which might make sense if your code could kill people buy otherwise you're being overcautious or severely underestimating what these can do.
Useful is relative. Silly little toy aps? Sure go full auto, heck, i personally do. However, these will fail catastrophically or have failures that should never even have happened.
So, in professional environments, full auto is negligent to a point i hope it becomes a fireable offense. Like trusting lane-assist and adaptive-cruise in a car to handle full auto driving. It might even seem like it can, until the leading car disappears, until it hits a t intersection. You get me? Modern llms are lane assist and adaptive cruise, not full self driving. It frees up some of your headspace and attention but not all, in fact not even most of it.
Partially agree, but I think "skill issue" undersells the genuine reliability problem the original post is describing.
The skill part is real — giving the agent the right context, breaking tasks into the right size, knowing when to intervene. Most people aren't doing that well and their results reflect it.
But the latent bug problem isn't really a skill issue. It's a property of how these systems work: the agent optimises for making the current test pass, not for building something that stays correct as requirements change. Round 1 decisions get baked in as assumptions that round 3 never questions — and no amount of better prompting fixes that.
The fix isn't better prompting. It's treating agent-generated code with the same scepticism you'd apply to code from a contractor who won't be around to maintain it — more tests, explicit invariants, and not letting the agent touch the architecture without a human reviewing the design first.
> It's starting to become obvious that if you can't effectively use AI to build systems it is a skill issue.
I think it's fair to say that you can get a long way with Claude very quickly if you're an individual or part of a very small team working on a greenfield project. Certainly at project sizes up to around 100k lines of code, it's pretty great.
But I've been working startups off and on since 2024.
My last "big" job was with a company that had a codebase well into the millions of lines of code. And whilst I keep in contact with a bunch of the team there, and I know they do use Claude and other similar tools, I don't get the vibe it's having quite the same impact. And these are very talented engineers, so I don't think it's a skill either.
I think it's entirely possible that Claude is a great tool for bootstrapping and/or for solo devs or very small teams, but becomes considerably less effective when scaled across very large codebases, multiple teams, etc.
For me, on that last point, the jury is out. Hopefully the company I'm working with now grows to a point where that becomes a problem I need to worry about but, in the meantime, Claude is doing great for us.
Would definitely tend to agree. Whenever I read complaints about accuracy of LLMs with complex systems, it has generally been from those that aren't thinking very critically about how they're using them in the first place. If you were to replace that LLM with a real human junior, would you really walk away for a few weeks and then assume the solution given was correct by default when you got it back? Obviously not. So you identify and gatekeep the most critical parts ahead of time, make error correction part of the process, and chunk the Giant, Complex Thing into Smaller, Achievable, Verifiable Things.
LLMs are proving to be very much force multipliers of the kind of developer you already are, and of those who report a 10x increase in productivity they're probably all being genuine. Whether that 10x is of careful, thoughtful choices or reckless rough-shod slop though is really an artifact of the developers themselves. I've been saying from the beginning that your effectiveness with LLMs is roughly equivalent to your ability to get effective results out of a real team of human contractors.
I don't know if you deliberately cut-off the full point, but for the benefit of those with tired eyes I said 'feedback mechanisms', i.e. feedback in the control system sense.
We are still in early days and I'm sure this isn't the best way to approach this but here is what I do.
1. Agent context with platform/system idiosyncrasies, how to access tools, this is actually kept pretty minimal - and a line directing it to the plan document.
2. A plan document on how to make changes to the repo and work that needs to be done. This is a living document pruned by the orchestrating agent. Included in this document is a directive written by you to use, update the document after ever run. Here also is a guide on benchmarking, regression, unit tests that need to be performed every time.
2a. When an agent has a code change it is then analyzed by a council of subagents, each focused on a different area, some examples, security, maintainability, system architect, business domain expert. I encourage these to be adversarial "red team". We sit in the core loop until the code changes pass through the council.
2b. Additional subagents to create documentation, build architecture diagrams etc.
2c. A suggested workflow is created on how to independently invoke testing, and subagent, etc.
I'd agree, I've been building a personal assistant (https://github.com/skorokithakis/stavrobot) and I'm amazed that, for the first time ever, LLMs manage to build reliably, with much fewer bugs than I'd expect from a human, and without the repo devolving to unmaintainability after a few cycles.
It's really amazing, we've crossed a threshold, and I don't know what that means for our jobs.
No bugs means nothing if bugs get hidden and llms are great at hiding bugs and will absolutely fail to find some fairly critical ones. Your own repo, which is slop at best, fails to meet its core premise
> Another AI agent. This one is awesome, though, and very secure.
it isn't secure. It took me less than three minutes to find a vulnerability. Start engaging with your own code, it isn't as good as you think it is.
edit: i had kimi "red team" it out of curiosity, it found the main critical vulnerability i did and several others
Medium - 3 - DoS, Information Disclosure, Injection
You need to sit down and really think about what people who do know what they're doing are saying. You're going to get yourself into deep trouble with this. I'm not a security specialist, i take a recreational interest in security, and llm's are by no means expert. A human with skill and intent would, i would gamble, be able fuck your shit up in a major way.
it sure can help, but it shouldn't be considered solved. Realistically you should treat it as vulnerable until it's received some attention from natural human folks who do know what they're doing. LLM's are great but they're not experts in any field as of yet.
Right yeah, thanks for the constructive comment. Mind filing those vulnerabilities, or are you just making a point?
How do you know these are actual vulnerabilities? You just ran an LLM and it told you something and you came back to dunk on me, with zero context on the project.
Maybe you need to sit down and really think that you have no idea who you're talking to or what the project does. Next time you make a "omg this code is so shit" comment, include something more than "well my LLM says your LLM is bad" so we can have a discussion with facts rather than LLM-aided trashtalk.
EDIT: Out of curiosity, I've ran Kimi K2.5 on the codebase, and all the things it found are invalid, or explicit design decisions. So, next time you decide to tell someone their project "is slop" by running an LLM and relaying its verdict, consider a) the irony of what you're doing, and b) that the other person might know more than you about their own project that you spent "three minutes" running an LLM on.
The three minutes was my own time. There are thousands of projects like yours, why would i sink serious time into yours over another? I found one myself in three minutes, then ran kimi to see if it finds more. Someone being able to hijack your agent to run arbitrary code on your device seems like an odd design decision. The constructive feedbakc here is to take it seriously and engage with your codebase. Give a man a fish /Teach a man fish, you know?
Yeah except you didn't actually find a vulnerability, you just searched for a pattern, found it, and thought "vulnerability" because you aren't a security researcher and don't realize that context is important.
You should educate yourself more before you go around slandering people.
This can be done via a signal/telegram message, via compromised plug-ins, via file uploads etc. At no stage does there appear to be, as far as I can tell, any attempt to mitigate or limit attack surface. That's just one of the problems. If that's by design, my bad, you do you king.
Look, perhaps I've been to hard on you. Maybe you have an intellectual disability or something, I don't know you or your situation, my bad. I get that you're proud of your project, and I don't want to take that from you. By all means, explore, tinker, hack around and explore, these are great traits/qualities. Just don't tell people what you're offering is safe, or worse, safer than alternative offerings. That claim simply isn't true. To be direct with you, the 'how' of an attack isn't a riddle, it's a documented reality of the modern threat landscape.
You're hyper-focused on the front door, asking how an attacker would even message the bot, but you're ignoring the fact that modern attackers don't bother knocking. Read cloudflare's 2026 threat report, it's eye opening. Between automated session cloning and browser-based info-stealers (among many other modern headaches), the 'whitelisted user' is no longer a static, trusted entity. If a user on your list has their session token scraped via a malicious browser extension or a hijacked desktop app, the attacker effectively becomes that user. At that point, your bot doesn't see an intruder; it sees a 'trusted' account and hands them a loaded gun in the form of arbitrary SQL execution. Now, the problem is you aren't the only one with access to LLM's and obscurity never really was security, even less so now. An llm with credentials could easily probe its way through your bot's capabilities and connected data and exfiltrate everything.
So, the reason I'm calling into question your claims of having a 'safer' personal agent/bot/whatever is a matter of blast radius. A standard bot usually interacts with a restricted API or a set of hard-coded functions, so even if the account is compromised, the damage is capped. By giving an LLM the keys to the entire database, you've created a single point of failure that can result in total data exfiltration or a complete 'drop table' wipe, among any number of other nasty things. That's just _one_ issue in this project.
If you actually want this to live up to the 'safer than average' description, you have to move past the idea that a whitelist is a firewall. You need to distinguish between authentication and authorisation and implement defense-in-depth, starting with a database user that has zero permissions beyond simple 'Select' queries. You should be using a proxy that intercepts the LLM's generated SQL and kills any string containing 'Drop', 'Update', or 'Delete' before it ever touches your server, without some form of parsing/checking. Right now, you’ve built a powerful engine with no brakes, and telling people it’s safer just because it's on Signal is a dangerous misunderstanding of how modern exploits actually work.
Alternatively, fix how the project is described to be more accurate/honest than it is now.
which would be fine / legal, but brings us back to a question many turns ago, why invest time in this particular project? There's a sea of similar projects, what makes yours stand out as worth investing in? The claims made don't stack up, and there's no indication this is anything other than LLM output, which means there's nothing here that can't be re-created quickly to a similar level of quality, however you define that. If we start rewarding everyone who posts mediocre repos to HN with attention, the entire platform will get drowned in no time. Show some personal effort first, then I'll invest mine. Discourse on a public central page like HN at least benefits public discourse. Engaging with your repo? no real benefits as far as I can tell.
I've used the analogy of a circular saw before ("it's not really sawing, because you can't feel the wood...")
It's easy to just slab on a Skil saw, cut through the beam and it'll be somewhat straight. But when every manual stroke counts, there's enough time on a human time scale to correct every little mistake. It's definitely possible to become skilled at using the circular saw, but it takes effort that it feels like you don't need at first.
This is similar. LLMs are so powerful for writing code that it's easy to become complacent and forget your role as the engineer using the tool: guaranteeing correctness, security, safety and performance of the end result. When you're not invested in every if-statement, forgetting to check edge cases is really easy to do. And as much as I like Claude writing test cases for me, I also have to ensure the coverage is decent, that the implicit assumptions made about external library code is correct, etc. It takes a lot of effort to do it right. I don't know why Mycelium thinks they invented interfaces for module boundaries, but I'm pretty sure they are still as suceptible to that "0" not behaving as you'd expect, or the empty string being interpreted as "missing." Or the CSG algorithm working, except if your hole edges are incident with some boundary edges.
Edit: spelling
Your analogy with a Skil saw is genius! You can cut much faster but it's also much more dangerous. Just like the AI indeed.
I've been thinking like a CNC. It can be made, but the edges are rough, needs sanding. OR - you accept that the edges are borderline dangerous. Also, some complex joints can't be built with a CNC
I have no idea what am I reading
> Mycelium structures applications as directed graphs of pure data transformations. Each node (cell) has explicit input/output schemas. Cells are developed and tested in complete isolation, then composed into workflows that are validated at compile time. Routing between cells is determined by dispatch predicates defined at the workflow level — handlers compute data, the graph decides where it goes.
No still don't understand
> Mycelium uses Maestro state machines and Malli contracts to define "The Law of the Graph," providing a high-integrity environment where humans architect and AI agents implement.
Nope, still don't
I have the same problem. The "What It Is" section starts with "Mycelium is a Clojure workflow framework built on Maestro" and that's a bit generic. Maybe something to test some AI generated code and then test if the tests are tested enough using Closure, but I'm not entirely sure.
The main question that is not obvious, is what should I use it for?
I don't understand why the poster (which is the author) links us to a slop report of a test for their library. It would be much more effective to cover part of this info into the README where we get the context of what they want to achieve (where there is a very clear "Why?" section), and then link to it instead. I have flagged it as AI slop.
I don't understand LISP or Clojure, but it seems to be some kind of library for making web services out of LISP, which has some separate components that are somehow well defined. And somehow it's all related to AI.
Again I don't know much about Clojure and I am too slow for functional programming in general.
The top-level README gives a bit better idea. Armed with that the explanation might sound a bit more understandable.
I'm not familiar with the project (or Clojure), but let me try to explain!
> Mycelium structures applications as directed graphs of pure data transformations.
There is a graph that describes how the data flows in the system. `fn(x) -> x + 1` in a hypothetical language would be a node that takes in a value and outputs a value. The graph would then arrange that function to be called as a result of a previous node computing the parameter x for it.
> Each node (cell) has explicit input/output schemas.
Input and output of a node must comply to a defined schema, which I presume is checked at runtime, as Clojure is a dynamically typed language. So functions (aka nodes) have input and output types and presumably they should try to be pure. My guess is there should be nodes dedicated for side effects.
> Cells are developed and tested in complete isolation, then composed into workflows that are validated at compile time.
Sounds like they are pure functions. Workflows are validated at compile time, even if the nodes themselves are in Clojure.
> Routing between cells is determined by dispatch predicates defined at the workflow level — handlers compute data, the graph decides where it goes.
When the graph is built, you don't just need to travel all outgoing edges from a node to the next, but you can place predicates on those edges. The aforementioned nodes do not have these predicates, so I suppose suppose the predicates would be their own small pure-ish functions with the same as input data as a node would get, but their output value is only a boolean.
> Mycelium uses Maestro state machines and
Maestro is a Clojure library for Finite State Machines: https://github.com/yogthos/maestro
> Malli contracts
Malli looks like a parsing/data structure specification EDSL for Clojure: https://github.com/metosin/malli
> to define "The Law of the Graph," providing a high-integrity environment where humans architect and AI agents implement.
Well, beats me. I don't know what is "The Law of the Graph" and Internet doesn't seem to know either. I suppose it tries to say how you can from the processing graph to see that given input data to the ingress of the graph you have high confidence that you will get expected data at the final egress from the graph.
I do think these kind of guardrails can be beneficial for AI agents developing code. I feel that for that application some additional level of redundancy can improve code quality, even if the guards are generated by the AI code to begin with.
Yeah it reads very Time Cube...
"Too Many requests" message. Hug of death?
How is that different compared to a human dev that would miss bugs?
The people using these programs are generating massive amounts of code, and you won't convince me they're actually carefully understanding most of it, if they even read it all. And it bypasses the first verification step where you are actively typing in the code that will be run.
Yes, this is simply 'technical debt'.
They should try to fix technical debt before going to the next round. Of course Claude can probably also do this.
I didn't downvote you, but I've noticed recently a trend on HN that just asking a normal question (possibly to start a discussion) gets downvoted for no apparent reason and without any explanation. Not good etiquette, in my opinion.
I think it's all the angry people who were wrong about AI. Every week they come on HN and say AI is utter crap and useless, and every week AI becomes more and more part of the developer work flow.
I would be pissed off too if I was a hypocrite who was so sure AI was total garbage and was now at the same time needing to use claude on a daily basis.
A lot of developers are going through an identity crisis where their skills are becoming more and more useless and they need to attack comments like the above in a desperate but futile attempt to make themselves matter.
The ability to plan long term and anticipate flow on errors.
You chosen AI agent can and will plan as far ahead as you tell it to plan. If you tell it to do things in iteration 1 that might block it in iteration 3 then you should have told it more about where you want to go back in iteration 1.
At some point I have to describe what I need with such a level of detail and precision, that if I had chosen to wrote it in my language of interest I'd have had the code I wanted long before i finish writing all the boundry conditions, safe guards, long term pitfalls etc. Thats if the system even respects all of those things, it might just lose track of some instruction at some point or make some bs placeholder and now we're back to bug hunting, only i'm now wading through code that is best described as slop.
You're saying that projects need to be waterfall rather than Agile in order to avoid making architecture mistakes you'll regret later.
The problem with that is that as you build you learn things, and that changes the plan. Consequently those mistakes are inevitable. What you should do is an approach where you have a high level plan up front, and detailed plans about the specific features as you need them. Mistakes will still happen but you'll be able to see them, and correct them, faster.
No, I am saying that you are trading what you spend effort on when using LLM's. Do you give up the effort of writing for the effort of review? Weather you should and if you will benefit really depends on your expertise and skill set.
If you're a novice, or even intermediate, use AI in a feedback kind of way, see if it can pinpoint and explain problems with your current code and offer feedback/recommendations. Not code, but dot point human language feedback like you'd get from a senior dev.
If the AI is writing code that is beyond what you could produce yourself, you have no business trusting the code the AI produces. This is because, as anyone who can produce high level code will tell you, AI is wrong too frequently to blindly trust. You have to engage critically with output. Full auto is a disaster waiting to happen.
The problem is, for many, good looking but fundamentally flawed code is indistinguishable from the real deal, and so they simply outsource their ability to critically think to a thing that simply cannot. This is a big problem and the evidence for this claim is littered throughout this comment section.
[dead]
It's starting to become obvious that if you can't effectively use AI to build systems it is a skill issue. At the moment it is a mysterious, occasionally fickle, tool - but if you provide the correct feedback mechanisms and provide small tweaks and context at idiosyncrasies, it's possible to get agents to reliably build very complex systems.
> At the moment it is a mysterious, occasionally fickle, tool - but if you provide the correct feedback mechanisms and provide small tweaks and context at idiosyncrasies, it's possible to get agents to reliably build very complex.
This sounds like arguing you can use these models to beat a game of whack-a-mole if you just know all the unknown unknowns and prompt it correctly about them.
This is an assertion that is impossible to prove or disprove.
No it's more like if you knew how to build it before - LLM agents help you build it faster. There's really no useful analogy I can think of, but it fits my current role perfectly because my work is constantly interrupted by prod support, coordination, planning, context switching between issues etc.
I rarely have blocks of "flow time" to do focused work. With LLMs I can keep progressing in parallel and then when I get to the block of time where I can actually dive deep it's review and guidance again - focus on high impact stuff instead of the noise.
I don't think I'm any faster with this than my theoretical speed (LLMs spend a lot of time rebuilding context between steps, I have a feeling current level of agents is terrible at maintaining context for larger tasks, and also I'm guessing the model context length is white a lie - they might support working with 100k tokens but agents keep reloading stuff to context because old stuff is ignored).
In practice I can get more done because I can get into the flow and back onto the task a lot faster. Will see how this pans out long term, but in current role I don't think there are alternatives, my performance would be shit otherwise.
You could probably replace LLM with "junior engineer" here as it sounds like you're basically a manager now. The big negative that LLMs have in comparison with junior engineers is that they can't learn and internalise new information based on feedback.
"The big negative that LLMs have in comparison with junior engineers is that they can't learn and internalise new information based on feedback."
No, but they can take "notes" and can load those notes into context. That does work, but is of course not so easy as it is with humans.
It is all about cleaning up and maintaining a tidy context.
I don't like that analogy. If I had to work with a Claude like junior I would ask for them to get removed from my team - inability to learn stuff, completely unexpected/unrelatable faliure modes and performance.
On the other hand Claudes tenacity, stamina and sustained speed is superhuman. The more capable models become the more valuable this is.
The same is true with human engineers - isn't this just what engineering is?
>This is an assertion that is impossible to prove or disprove.
This is a joke right? There are complex systems that exist today that are built exclusively via AI. Is that not obvious?
The existence of such complex systems IS proof. I don't understand how people walk around claiming there's no proof? Really?
The assertion was "if you really know how to prompt, give feedback, do small corrections and fix LLM errors, then everything works fine".
It is impossible to prove or disprove because if everything DOES NOT work fine you can always say that the prompts were bad, the agent was not configured correctly, the model was old, etc. And if it DOES work, then all of the previous was done correctly, but without any decent definition of what correct means.
>And if it DOES work, then all of the previous was done correctly, but without any decent definition of what correct means.
If a program works, it means it's correct. If we know it's correct, it means we have a definition of what correct means otherwise how can we classify anything as "correct" or "incorrect". Then we can look at the prompts and see what was done in those prompts and those would be a "correct" way of prompting the LLM.
You don’t know it works. That you so glibly speak about products working is proof that your engineering judgment is impaired. You can’t infer the exact contents of a black box merely by looking at outside behavior.
The fundamental fallacy you are exhibiting here is similar to saying that rolling a six sided die and getting a “6” means that you will always get a 6 any time you roll it. And that if you get a 6 and wanted a 6, you must have therefore rolled those dice “correctly” and had you not gotten a 6 that would have meant you rolled them “wrong.”
You know that is not true.
>You don’t know it works. That you so glibly speak about products working is proof that your engineering judgment is impaired. You can’t infer the exact contents of a black box merely by looking at outside behavior.
I don't know the exact internals of a car. But I can infer my car works by driving it.
>The fundamental fallacy you are exhibiting here is similar to saying that rolling a six sided die and getting a “6” means that you will always get a 6 any time you roll it. And that if you get a 6 and wanted a 6, you must have therefore rolled those dice “correctly” and had you not gotten a 6 that would have meant you rolled them “wrong.”
Bro we rolled that dice MULTIPLE times. It's not a one time thing. And the "rolling" of the die is done with a CHAIN of MULTIPLE qureries strung together. This is not one roll. It's multitudes of data points. Yes results can be inconsistent from a technical standpoint, but the general result converges on a singular trend.
We know that much is true: a statistic and that is at most all we can say about reality as we know it as science formalized can only give a statistic as an answer.
"I don't know the exact internals of a car. But I can infer my car works by driving it."
No, you can't infer that it "works." Only that it CAN work. The car may be poisoning you with carbon monoxide. Your rear brakes may have become disconnected (happened to me). The antilock braking system may have a faulty sensor that only fails at very low speed, leading to them engaging when making a normal stop, but also preventing the mechanic from seeing the problem, because he didn't listen to your bug report and instead tried to repro the effect with high speed panic stops (also happened to me).
If I use a product and have a good experience, I can conclude that SOMETHING must be going well, but not that EVERYTHING is going well.
This is reasoning about evidence 101.
>No, you can't infer that it "works." Only that it CAN work. The car may be poisoning you with carbon monoxide. Your rear brakes may have become disconnected (happened to me). The antilock braking system may have a faulty sensor that only fails at very low speed, leading to them engaging when making a normal stop, but also preventing the mechanic from seeing the problem, because he didn't listen to your bug report and instead tried to repro the effect with high speed panic stops (also happened to me).
This is called pedantitic reasoning. You look like a drowning person trying to stay afloat.
Say i buy into your mysticism based take, is it a useful tool if it blows up in damn well near every professionals face?
lets say i accept you and you alone have the deep majiks required to use this tool correctly, when major platform devs could not so far, what makes this tool useful? Billions of dollars and environment ruining levels of worth it?
I'd say the only real use for these tools to date has been mass surveillance, and sometimes semi useful boilerplate.
> is it a useful tool if it blows up in damn well near every professionals face
It doesn't, that's ego-preserving cope. Saying that this stuff doesn't work for "damn well near every professional" because it doesn't work for you is like a thief saying "Everybody else steals, why are you picking on me"? It's not true, it's something you believe to protect your own self-image.
It works fine for me, because I don't trust to to do anything more than line changes, self-contained prototypes or minor updates. I've seen what happens when people give llms full control over authoring, and it has never worked out. Just look at the dumpster fire spotify has become. Its a buggy mess that barely works and is openly touted as being primarily llm developed at present.
point me towards something complex which llms have contributed towards significantly without massive oversight where they didnt fuck things up. I'll eat my words happily, with just a single example.
Honestly people are in such a weird place with this shit. I'm not saying don't read the fucking code - but I managed to get my setup to write 100k lines of indistinguishable SWE code in a week or so. The main limitation was my reading speed. This is something like a 10x speedup for me.
How does one verify 100k lines in a week? Let alone evaluate it to being SWE equivallent? That's super human. I like to think I am pretty good at what I do, but really critically engaging with 100k lines in a week is beyond even 10 of me. Forgive my skepticism, but I'm going to hazard the guess that you don't know what the fuck you're doing. You've lost your goddamn mind if you think you're doing anything other than skim read at a rate of 42 lines a minute for your entire work day without a break.
The answer is they don't. They don't verify or care about it. They're only interested in "shipping" as fast as possible.
You have a fair perspective and I'm not going to try to move you from it. You have my exact opinion as of 3 months ago. I will just suggest you earnestly try it yourself.
I have, hence my perspective. For boiler plate and solved problems, it can do ok. However, anytime it needs to do something novel it will be hit and miss, usually miss. If it needs to do something where best practice has changed but training data overwhelmingly does bad / dated practice, you'll get that if you don't specify. Loads of issues like that. So, without giving small isolated and well framed tasks the output of which is then critically engaged with, you'll get increasingly opaque and unstable code.
On Saturday I had claude generate ~10k of lines of Lua code which uses the libASS subtitle format to build up nearly two dozen GUI widgets from subtitle drawing primitives, including nestable scrollable containers with clipping, drop down menus, animated tab bars, and everything else I could think of. I read probably about 100 lines of code myself that day, I "verified" the code only by testing out the demo claude was updating through the process.
Then on Sunday I woke up and had claude bang out a series of half a dozen projects each using this GUI library. First, a script that simply offers to loop a video when the end is reached. Updated several of my old scripts that just print text without any graphical formatting. Then more adventurous, a playlist visualizer with support for drag to reorder. Another that gives a nice little control overlay for TTS reading normal media subtitles. Another that let's people select clips from whatever they're watching, reorder them and write out an edit decision list, maybe I'll turn this one into a complete NLE today when I get home from work.
Reading every line of code? Why? The shit works, if I notice a bug I go back to claude and demand a "thoughtful and well reasoned" fix, without even caring what the fix will be so long as it works.
The concepts and building blocks used for all of this is shit I've learned myself the hard way, but to do it all myself would take weeks and I would certainly take many shortcuts, like certainly skipping animations and only implementing the bare minimum. The reason I could make that stuff work fast is because I already broadly knew the problem space, I've probably read the mpv manpage a thousand times before, so when the agent says its going to bind to shift+wheel for horizonal scrolling, I can tell it no, mpv has WHEEL_LEFT and RIGHT, use those. I can tell it to pump its brakes and stop planning to load a PNG overlay, because mpv will only load raw pixel data that way. I can tell it that dragging UI elements without simultaneously dragging the whole window certainly must be possible, because the first party OSC supports it so it should go read that mess of code and figure it out, which it dutifully does. If you know the problem space, you can get a whole lot done very fast, in a way that demonstrably works. Does it have bugs? I'd eat a hat if it doesn't. They'll get fixed if/when I find them. I'm not worried about it. Reading every line of code is for people writing airliner autopilots, not cheeky little desktop programs.
right, but we're not talking cheeky desktop personal programs here. Who cares what you do for your own devices and in your own time? Absolutely no one gets to tell you what to do there, so why discuss it? Live your life, do your thing, great! But that isn't what is being discussed here.
We're talking about the capabilities of the technology. I would not even think about using LLM output in life critical roles, but we're not talking about only such scenarios. I'm addressing your claim that these
> blows up in damn well near every professionals face
If you know how to use the tools, and know their limitations, you can generate vast quantities of useful code very quickly. If you can't manage this, its PEBKAC. You're saying you don't trust these to make more than minor changes, which might make sense if your code could kill people buy otherwise you're being overcautious or severely underestimating what these can do.
Useful is relative. Silly little toy aps? Sure go full auto, heck, i personally do. However, these will fail catastrophically or have failures that should never even have happened.
So, in professional environments, full auto is negligent to a point i hope it becomes a fireable offense. Like trusting lane-assist and adaptive-cruise in a car to handle full auto driving. It might even seem like it can, until the leading car disappears, until it hits a t intersection. You get me? Modern llms are lane assist and adaptive cruise, not full self driving. It frees up some of your headspace and attention but not all, in fact not even most of it.
Partially agree, but I think "skill issue" undersells the genuine reliability problem the original post is describing.
The skill part is real — giving the agent the right context, breaking tasks into the right size, knowing when to intervene. Most people aren't doing that well and their results reflect it.
But the latent bug problem isn't really a skill issue. It's a property of how these systems work: the agent optimises for making the current test pass, not for building something that stays correct as requirements change. Round 1 decisions get baked in as assumptions that round 3 never questions — and no amount of better prompting fixes that.
The fix isn't better prompting. It's treating agent-generated code with the same scepticism you'd apply to code from a contractor who won't be around to maintain it — more tests, explicit invariants, and not letting the agent touch the architecture without a human reviewing the design first.
> It's starting to become obvious that if you can't effectively use AI to build systems it is a skill issue.
I think it's fair to say that you can get a long way with Claude very quickly if you're an individual or part of a very small team working on a greenfield project. Certainly at project sizes up to around 100k lines of code, it's pretty great.
But I've been working startups off and on since 2024.
My last "big" job was with a company that had a codebase well into the millions of lines of code. And whilst I keep in contact with a bunch of the team there, and I know they do use Claude and other similar tools, I don't get the vibe it's having quite the same impact. And these are very talented engineers, so I don't think it's a skill either.
I think it's entirely possible that Claude is a great tool for bootstrapping and/or for solo devs or very small teams, but becomes considerably less effective when scaled across very large codebases, multiple teams, etc.
For me, on that last point, the jury is out. Hopefully the company I'm working with now grows to a point where that becomes a problem I need to worry about but, in the meantime, Claude is doing great for us.
According to the https://blog.katanaquant.com/p/your-llm-doesnt-write-correct... previously discussed on HN, it may be at least partially true:
> The vibes are not enough. Define what correct means. Then measure.
Would definitely tend to agree. Whenever I read complaints about accuracy of LLMs with complex systems, it has generally been from those that aren't thinking very critically about how they're using them in the first place. If you were to replace that LLM with a real human junior, would you really walk away for a few weeks and then assume the solution given was correct by default when you got it back? Obviously not. So you identify and gatekeep the most critical parts ahead of time, make error correction part of the process, and chunk the Giant, Complex Thing into Smaller, Achievable, Verifiable Things.
LLMs are proving to be very much force multipliers of the kind of developer you already are, and of those who report a 10x increase in productivity they're probably all being genuine. Whether that 10x is of careful, thoughtful choices or reckless rough-shod slop though is really an artifact of the developers themselves. I've been saying from the beginning that your effectiveness with LLMs is roughly equivalent to your ability to get effective results out of a real team of human contractors.
> if you provide the correct feedback
And how do you define correct feedback? If the output is correct?
I don't know if you deliberately cut-off the full point, but for the benefit of those with tired eyes I said 'feedback mechanisms', i.e. feedback in the control system sense.
The cut-off was not intended but what is the correct one? Is it wrong as soon the result is wrong?
We are still in early days and I'm sure this isn't the best way to approach this but here is what I do.
1. Agent context with platform/system idiosyncrasies, how to access tools, this is actually kept pretty minimal - and a line directing it to the plan document.
2. A plan document on how to make changes to the repo and work that needs to be done. This is a living document pruned by the orchestrating agent. Included in this document is a directive written by you to use, update the document after ever run. Here also is a guide on benchmarking, regression, unit tests that need to be performed every time.
2a. When an agent has a code change it is then analyzed by a council of subagents, each focused on a different area, some examples, security, maintainability, system architect, business domain expert. I encourage these to be adversarial "red team". We sit in the core loop until the code changes pass through the council.
2b. Additional subagents to create documentation, build architecture diagrams etc.
2c. A suggested workflow is created on how to independently invoke testing, and subagent, etc.
Truth Nuke
[dead]
I'd agree, I've been building a personal assistant (https://github.com/skorokithakis/stavrobot) and I'm amazed that, for the first time ever, LLMs manage to build reliably, with much fewer bugs than I'd expect from a human, and without the repo devolving to unmaintainability after a few cycles.
It's really amazing, we've crossed a threshold, and I don't know what that means for our jobs.
No bugs means nothing if bugs get hidden and llms are great at hiding bugs and will absolutely fail to find some fairly critical ones. Your own repo, which is slop at best, fails to meet its core premise
> Another AI agent. This one is awesome, though, and very secure.
it isn't secure. It took me less than three minutes to find a vulnerability. Start engaging with your own code, it isn't as good as you think it is.
edit: i had kimi "red team" it out of curiosity, it found the main critical vulnerability i did and several others
Severity - Count - Categories
Critical - 2 - SQL Injection, Path Traversal
High - 4 - SSRF, Auth Bypass, Privilege Escalation, Secret Exposure
Medium - 3 - DoS, Information Disclosure, Injection
You need to sit down and really think about what people who do know what they're doing are saying. You're going to get yourself into deep trouble with this. I'm not a security specialist, i take a recreational interest in security, and llm's are by no means expert. A human with skill and intent would, i would gamble, be able fuck your shit up in a major way.
Build a redteam into your feedback mechanism. Seriously. You've identified the problem and even solved it. Now automate it.
it sure can help, but it shouldn't be considered solved. Realistically you should treat it as vulnerable until it's received some attention from natural human folks who do know what they're doing. LLM's are great but they're not experts in any field as of yet.
Right yeah, thanks for the constructive comment. Mind filing those vulnerabilities, or are you just making a point?
How do you know these are actual vulnerabilities? You just ran an LLM and it told you something and you came back to dunk on me, with zero context on the project.
Maybe you need to sit down and really think that you have no idea who you're talking to or what the project does. Next time you make a "omg this code is so shit" comment, include something more than "well my LLM says your LLM is bad" so we can have a discussion with facts rather than LLM-aided trashtalk.
EDIT: Out of curiosity, I've ran Kimi K2.5 on the codebase, and all the things it found are invalid, or explicit design decisions. So, next time you decide to tell someone their project "is slop" by running an LLM and relaying its verdict, consider a) the irony of what you're doing, and b) that the other person might know more than you about their own project that you spent "three minutes" running an LLM on.
The three minutes was my own time. There are thousands of projects like yours, why would i sink serious time into yours over another? I found one myself in three minutes, then ran kimi to see if it finds more. Someone being able to hijack your agent to run arbitrary code on your device seems like an odd design decision. The constructive feedbakc here is to take it seriously and engage with your codebase. Give a man a fish /Teach a man fish, you know?
Yeah except you didn't actually find a vulnerability, you just searched for a pattern, found it, and thought "vulnerability" because you aren't a security researcher and don't realize that context is important.
You should educate yourself more before you go around slandering people.
Attacker payload -> Message to bot -> LLM processes -> arbitrary execute_sql triggered
This can be done via a signal/telegram message, via compromised plug-ins, via file uploads etc. At no stage does there appear to be, as far as I can tell, any attempt to mitigate or limit attack surface. That's just one of the problems. If that's by design, my bad, you do you king.
Seriously? Your attack vector is "trusted user tells bot with access to SQL to run SQL"?
How is the attacker going to message the bot, genius? Do riddle me that.
Look, perhaps I've been to hard on you. Maybe you have an intellectual disability or something, I don't know you or your situation, my bad. I get that you're proud of your project, and I don't want to take that from you. By all means, explore, tinker, hack around and explore, these are great traits/qualities. Just don't tell people what you're offering is safe, or worse, safer than alternative offerings. That claim simply isn't true. To be direct with you, the 'how' of an attack isn't a riddle, it's a documented reality of the modern threat landscape.
You're hyper-focused on the front door, asking how an attacker would even message the bot, but you're ignoring the fact that modern attackers don't bother knocking. Read cloudflare's 2026 threat report, it's eye opening. Between automated session cloning and browser-based info-stealers (among many other modern headaches), the 'whitelisted user' is no longer a static, trusted entity. If a user on your list has their session token scraped via a malicious browser extension or a hijacked desktop app, the attacker effectively becomes that user. At that point, your bot doesn't see an intruder; it sees a 'trusted' account and hands them a loaded gun in the form of arbitrary SQL execution. Now, the problem is you aren't the only one with access to LLM's and obscurity never really was security, even less so now. An llm with credentials could easily probe its way through your bot's capabilities and connected data and exfiltrate everything.
So, the reason I'm calling into question your claims of having a 'safer' personal agent/bot/whatever is a matter of blast radius. A standard bot usually interacts with a restricted API or a set of hard-coded functions, so even if the account is compromised, the damage is capped. By giving an LLM the keys to the entire database, you've created a single point of failure that can result in total data exfiltration or a complete 'drop table' wipe, among any number of other nasty things. That's just _one_ issue in this project.
If you actually want this to live up to the 'safer than average' description, you have to move past the idea that a whitelist is a firewall. You need to distinguish between authentication and authorisation and implement defense-in-depth, starting with a database user that has zero permissions beyond simple 'Select' queries. You should be using a proxy that intercepts the LLM's generated SQL and kills any string containing 'Drop', 'Update', or 'Delete' before it ever touches your server, without some form of parsing/checking. Right now, you’ve built a powerful engine with no brakes, and telling people it’s safer just because it's on Signal is a dangerous misunderstanding of how modern exploits actually work.
Alternatively, fix how the project is described to be more accurate/honest than it is now.
Yeah whatever, either show me an actual attack vector or go learn some more actual skills instead of trolling people here.
without posting something illegal here, I cannot make it more plain than the last comment, I am sorry.
Disclosing vulnerabilities isn't illegal, and you can use the project's bug tracker.
which would be fine / legal, but brings us back to a question many turns ago, why invest time in this particular project? There's a sea of similar projects, what makes yours stand out as worth investing in? The claims made don't stack up, and there's no indication this is anything other than LLM output, which means there's nothing here that can't be re-created quickly to a similar level of quality, however you define that. If we start rewarding everyone who posts mediocre repos to HN with attention, the entire platform will get drowned in no time. Show some personal effort first, then I'll invest mine. Discourse on a public central page like HN at least benefits public discourse. Engaging with your repo? no real benefits as far as I can tell.
No, it's definitely valid to want to spend just enough time to spread inaccuracies but not enough time to figure out why they're inaccurate.