2 ms·

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

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

zihotki 7mo ago
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.
4b11b4 7mo ago
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
yogthos 7mo ago
I agree with everything you're saying here, and I'm not arguing the approach eliminates the need for the human to be in the loop. That's not the goal. What I'm trying to do is to create hard context boundaries which help both the human and the agent understand what the code is doing. With Mycelium, you have a graph expressing the top level logic, so you have a declarative workflow that you can review. With traditional code this is mixed in together with the implementation details, and you have to tease out the business logic by reading through the code. Mycelium creates a hard boundary between implementation details which live in the cells, and the high level business logic of the application. You can set up a workflow manifest which declares what you're doing. Then you can go an implement each step in form of a cell. And then you can review it and test it in isolation without having to consider the entire application. This is the part that reduces the cognitive load and makes it easier to ensure that the code is doing what's intended. As a note, I'm not arguing that I invented anything fundamentally new here. Workflow engines have been around for a while. I'm simply applying the idea directly in the context of coding agents.

zihotki 7mo ago

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.

4b11b4 7mo ago

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

yogthos 7mo ago

I agree with everything you're saying here, and I'm not arguing the approach eliminates the need for the human to be in the loop. That's not the goal. What I'm trying to do is to create hard context boundaries which help both the human and the agent understand what the code is doing. With Mycelium, you have a graph expressing the top level logic, so you have a declarative workflow that you can review. With traditional code this is mixed in together with the implementation details, and you have to tease out the business logic by reading through the code. Mycelium creates a hard boundary between implementation details which live in the cells, and the high level business logic of the application. You can set up a workflow manifest which declares what you're doing. Then you can go an implement each step in form of a cell. And then you can review it and test it in isolation without having to consider the entire application. This is the part that reduces the cognitive load and makes it easier to ensure that the code is doing what's intended. As a note, I'm not arguing that I invented anything fundamentally new here. Workflow engines have been around for a while. I'm simply applying the idea directly in the context of coding agents.