It's easy to just slab on a Skil saw, but 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.
> 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
How schema-enforced cells change the reliability equation as system complexity grows.
We ran four progressively complex benchmarks, each building on the previous one. The traditional approach achieved 100% test passage through V1 and V2, but the V1 shipping bug finally surfaced in V3 — causing 17 test failures after being latent for two full rounds of development.
| Benchmark | Subsystems | Tests | Traditional | Mycelium | Traditional LOC | Mycelium LOC |
|---|---|---|---|---|---|---|
| Checkout Pipeline | 3 | 8 / 39 assertions | 39/39 pass | 39/39 pass | ~130 | ~230 + manifest |
| Order Lifecycle V1 | 6 | 18 / 136 assertions | 136/136 pass | 136/136 pass | ~540 | ~590 + ~130 manifest |
| Order Lifecycle V2 | 11 | 30 / 235 assertions | 235/235 pass | 235/235 pass | ~722 | ~900 + ~360 manifest |
| Order Lifecycle V3 | 15 | 52 / 383 assertions | 366/383 pass | 383/383 pass | ~920 | ~1146 + ~440 manifest |
Scale: ~130 lines, 3 subsystems (discounts, tax/shipping, payment).
What it tests: A single linear pipeline -- items in, total out.
50.0 * 0.0725 = 3.6249... rounds to 3.62 instead of 3.63):on-error, undeclared data flow keys, dead-end graph routeBoth approaches work fine. The problem is small enough that an AI agent can hold
the entire system in context. The traditional approach is simpler and faster to
implement. Mycelium's overhead (100 extra lines + manifest) is proportionally
high (75%) and hard to justify for a problem this small.
Mycelium advantage: The structural validators caught 3 issues that would have been silent in the traditional approach (missing error handling, undeclared data flow, dead-end route). But at this scale, these issues are easy to catch through testing or code review.
Latent bugs: Traditional 0, Mycelium 0.
Scale: ~540 lines, 6 subsystems (item expansion, promotions with 5 stacking types, per-item tax with state exemptions, multi-warehouse shipping, split payment, loyalty points with tiered earning).
What it tests: Three interacting workflows (placement, returns, modification) that share data contracts. Returns must correctly reverse the forward calculation, including proportional discount distribution, per-item tax, and split payment reversal.
The traditional approach was built by 4 separate AI subagents:
:shipping-detail vs :shipping-groups -- Returns code destructures
:shipping-detail but placement outputs :shipping-groups. Gets nil,
silently produces $0 shipping refund for all defective returnsmodify-order calls place-order which
re-reserves inventory without releasing the original reservation:shipping-groups :any in its input schema,
making the key mismatch impossibleThis is the tipping point. The traditional approach has crossed the threshold where implicit contracts between components fail silently. Two independently competent AI agents (placement and returns) produced code that connects incorrectly through a key name mismatch. All tests pass because no test exercises the specific path (defective return of an item with non-zero shipping cost).
The key insight: The bug is not in any single agent's work. Each agent's code is internally correct. The bug is in the contract between agents -- a contract that exists only implicitly in the traditional approach and explicitly in the mycelium manifest.
Latent bugs: Traditional 2, Mycelium 0.
Scale: ~722 lines, 11 subsystems. Five new features added by 5 sequential AI subagents, each modifying the existing V1 codebase:
:shipping-detail vs :shipping-groups -- still present after 5 more agents touched the codecurrency-rates duplicated in 3 files (placement, returns, modification)gift-wrap-cost-per-item duplicated in 2 files (placement, returns)We ran a targeted scenario to prove the traditional bug produces wrong results:
Scenario: Return novel (defective) from headphones+novel order
East warehouse shipping cost: $6.39
Traditional shipping-refund: $0.00 (WRONG)
Mycelium shipping-refund: $6.39 (CORRECT)
The traditional approach silently loses $6.39 per affected refund. This is not a theoretical concern -- it's a financial calculation error that would affect real transactions.
The most striking finding: 5 additional AI agents worked on the traditional codebase and none detected or fixed the V1 bugs. Each agent:
This happens because each agent only reads enough context to complete its assigned
task. The :shipping-detail bug is invisible unless you specifically compare the
returns code's destructuring against the placement code's output keys -- a
cross-file analysis that agents skip when focused on adding a feature.
Latent bugs: Traditional 4, Mycelium 0.
The overhead ratio has shifted. Mycelium's manifest and structural code is ~360 lines on top of ~900 lines of implementation -- about 40% overhead. But the value delivered has grown faster:
Scale: ~920 lines traditional, ~1146 lines mycelium, 15 subsystems. Seven new cross-cutting features designed to create maximum interaction pressure:
These 7 features create a 48-cell interaction matrix of cross-cutting concerns.
:shipping-detail bugThe :shipping-detail vs :shipping-groups bug was introduced in V1, survived
V2 untouched, and finally causes test failures in V3. Here's why:
In V1 and V2, shipping was simple: flat rate or free (gold/platinum, subtotal >= $75). Most tested scenarios had free shipping, so the returns code's nil shipping-detail produced the accidentally-correct $0.00 refund. V3's tiered shipping with hazmat and oversized surcharges means most orders now have non-zero shipping costs. Defective returns must refund that shipping, and the nil lookup silently returns $0.
One root cause, 17 failures. The single wrong key name cascades:
| Test | Expected | Actual | Missing |
|---|---|---|---|
| T11 (laptop defective) | $1041.11 total refund | $1033.11 | -$8.00 |
| T17 (headphones defective) | $69.19 | $65.82 | -$3.37 |
| T24 (gift-wrapped laptop) | $1046.50 | $1038.50 | -$8.00 |
| T42 (warranty laptop) | $1095.10 | $1087.10 | -$8.00 |
| T49 (sub+warranty+wrap) | $945.53 | $937.53 | -$8.00 |
| T52 (bundle return) | $1040.09 | $1032.09 | -$8.00 |
In a production system, every defective return would silently under-refund the customer's shipping cost.
The traditional approach correctly implements all 7 V3 features for placement:
The failures are not from incompetence. They're from the structural impossibility of tracking key names across module boundaries without a contract system.
The V2 analysis predicted 8-12 latent bugs at 15 subsystems. The reality was
more interesting: rather than just accumulating more latent bugs, the existing
V1 bug detonated. V3's tiered shipping created enough non-zero shipping
scenarios that the :shipping-detail bug went from latent to catastrophic.
This is the time-bomb pattern: a bug introduced in round 1 of development explodes in round 3, when new features create paths through the code that previous tests never exercised. The codebase grew from 540 to 920 lines, 12 features were added across 2 rounds, and the bug was invisible to every test suite, code review, and AI agent that touched the code -- until it wasn't.
| Benchmark | Subsystems | Traditional Bugs | Test Failures | Mycelium Bugs |
|---|---|---|---|---|
| Checkout | 3 | 0 | 0 | 0 |
| V1 | 6 | 2 latent | 0 | 0 |
| V2 | 11 | 4 latent | 0 | 0 |
| V3 | 15 | 5 (1 surfaced) | 17 | 0 |
The traditional approach doesn't just accumulate bugs linearly -- the bugs interact with new features to create cascading failures. A latent bug that was harmless at 6 subsystems becomes a 17-assertion catastrophe at 15 subsystems because the new features create triggering conditions.
Mycelium stays at zero because every cross-component contract is explicit in
the manifest. A bug like :shipping-detail vs :shipping-groups cannot exist
when the manifest declares exactly which keys flow between cells.
| Benchmark | Traditional LOC | Mycelium Total LOC | Overhead % | Bugs Prevented |
|---|---|---|---|---|
| Checkout | 130 | 230 | 77% | 0 |
| V1 | 540 | 720 | 33% | 2 |
| V2 | 722 | 1260 | 74%* | 4 |
| V3 | 920 | 1586 | 72% | 5 + 17 test failures |
*Overhead percentage stabilizes around 70-75% at scale, but the value delivered grows superlinearly. At V3 scale, ~440 lines of manifest prevent 5 latent bugs and 17 test failures that would silently produce wrong financial calculations.
The overhead percentage isn't the right metric. The right metric is bugs prevented per line of manifest. At V3 scale, the manifest prevented the single bug that cascaded into 17 assertion failures across 8 test cases.
| Benchmark | Lines per module | Can agent hold full context? | Result |
|---|---|---|---|
| Checkout | 130 (1 file) | Yes | Both approaches work |
| V1 | 180 avg (3 files) | Mostly | Traditional: 2 cross-file bugs |
| V2 | 240 avg (3 files) | Strained | Traditional: 4 bugs, 0 fixed |
| V3 | 307 avg (3 files) | No | Traditional: 17 test failures |
The traditional approach degrades because agents must hold the full system in context to avoid cross-module mismatches. As the system grows, the agent's effective context becomes a shrinking fraction of the total codebase.
Mycelium cells are independently implementable. An agent implementing
:return/calc-restocking needs only:
[:returned-detail, :reason][:restocking-fee]It does not need to read placement code, other returns cells, or understand the full data flow. The schema is the complete specification for that unit of work.
All benchmarks through V2 achieve 100% test passage in both approaches. The latent bugs survive because:
Tests verify expected behavior, not contract compliance. A test for "return headphones, changed-mind" checks the refund amount. It doesn't check that the returns code reads the correct key from the placement output.
Test scenarios have accidental coverage gaps. Every defective-return test in V1 and V2 happens to involve items with free shipping (>$75 warehouse subtotal). No test returns a defective item where shipping was actually charged.
Agents write tests that match their implementation. When Agent 2 writes
returns code that uses :shipping-detail, it also writes tests that don't
exercise the :shipping-detail code path with non-zero shipping. The bug and
the test gap are correlated because they come from the same incomplete
understanding.
Passing tests create false confidence. After 30 tests pass, the natural conclusion is "the code is correct." The latent bugs only appear when you specifically probe for them with targeted scenarios.
New features can detonate old bugs. V3 proves that 100% test passage is a snapshot in time. V1's bug was harmless through V2 and catastrophic in V3. The bug didn't change -- the surrounding code did.
Schema validation is orthogonal to testing. It doesn't check business logic correctness -- tests do that. It checks structural correctness: "does the data flowing between components have the right shape?" This is precisely the category of bug that tests miss and that grows with system complexity.
Beyond preventing bugs, mycelium manifests address a practical problem in AI-assisted development: context compaction.
When an AI agent's conversation grows too long, earlier context gets compressed or dropped. The agent must rebuild its understanding by re-reading source files. In a traditional codebase, this means re-tracing data flow through hundreds of lines of imperative code to reconstruct which keys connect which modules, what the data shapes are, and how subsystems interact.
Mycelium manifests externalize this knowledge:
The manifest is a persistent context map. Reading placement.edn (~100
lines) gives the full DAG, every cell's input/output schema, and all
dependencies. That's the entire system architecture in one structured file.
In the traditional approach, reconstructing the same understanding requires
reading 920 lines across 3 files.
Schemas are contracts that survive compaction. The :shipping-groups key
name exists only in the agent's working memory in the traditional approach.
Once that memory is compacted, the contract is lost. In mycelium, it's
written in the manifest and survives any number of compactions.
Bounded context means less to rebuild. After compaction, an agent working
on :return/calc-warranty-refund reads the cell schema (5 lines) and knows
exactly what it receives and must produce. It doesn't need to re-read
placement code, shipping code, or understand the full pipeline.
The 48-cell interaction matrix is externalized. V3's 15 subsystems create 48 cross-cutting interactions. No agent can hold all 48 in context simultaneously. Mycelium doesn't require it -- each cell only needs its own schema boundary. The manifest encodes the global structure so the agent doesn't have to.
Context compaction puts the agent in the same position as a new developer joining the project. Mycelium manifests serve as onboarding documentation that is also executable contracts. The traditional approach has no equivalent.
Traditional codebases require global knowledge to avoid cross-module bugs. As the system grows, maintaining global knowledge becomes impossible for any single agent (or human). The V3 benchmark proves this: 15 subsystems and 48 interactions exceed what any agent can hold in context, and the result is a V1 bug that explodes into 17 test failures.
Mycelium requires only local knowledge (the cell's schema) to implement each component correctly. As the system grows, local knowledge stays constant per cell. The manifests encode the global structure, and the framework validates it automatically.
This is the same asymmetry that makes type systems valuable in large codebases: not because they help with small programs, but because they prevent the class of errors that grows fastest with system size.
The V3 results confirm the projection from V2: as complexity grows, the traditional approach's bug surface area grows combinatorially while mycelium's stays at zero. The only question was whether those bugs would remain latent or surface -- and V3 answered definitively.
They should try to fix technical debt before going to the next round. Of course Claude can probably also do this.
Again I don't know much about Clojure and I am too slow for functional programming in general.
> The vibes are not enough. Define what correct means. Then measure.
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.
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.
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.
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.
And how do you define correct feedback? If the output is correct?
It's really amazing, we've crossed a threshold, and I don't know what that means for our jobs.
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.
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.
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.
> 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.
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.
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?
point me towards something complex which llms have contributed towards signifucantly without massive oversight where they didnt fuck things up. I'll eat my words happily, with just a single example.
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.
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.
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.