I keep seeing the same pattern in AI coding tools: The model is asked to simultaneously be planner, parser, state manager, repair engine, and memory. That produces three structural failures: nondeterministic memory, non-restartable execution, non-auditable reasoning. Smarter models don't fix them.
That led me to a realization: Every one of my projects needs the same collection of primitives — prompt building, LLM calls, chunking, embedding, file I/O — over and over. So I started collecting them as standalone CLIs. And then, I let the model only write the 5% or so that's genuinely novel. That led to a markup language to wire those CLIs together declaratively — a workflow map.
That led me to the realization that the map is the application--source code is ephemeral.
And if a pattern appears across projects, promote it to a new CLI. The catalog grows. The model's job shrinks. For tractable software, maybe 95% of operations become primitives.
And that means the job of the LLM switches from being a code generator, to being a map generator.
And, I can imagine the system can improves itself through use, by considering if new things it codes have reusability potential, and thus assmptotically close the gap--but never reaching 100%--for what is reusable components that just need to be wired together by the map.
And perhaps an eco-system of shared pre-built components.
The same algorithm that designed this architecture is the algorithm the architecture uses to generate itself. Generation 0 is Python. Generation 1+ are maps that generate maps. Self-similar at the meta-level.
I'm publishing the full blueprints — white paper, formal grammar (WML), RFC, implementation plan, and claims chain with dropped overclaims explicitly named.
All in one folder (see url above)
Would love feedback from anyone who finds this idea interesting and would love to chat/debate about it.
chnbydigi•1h ago
Happy to answer any questions about the calculator or the $340
incident that started this. Built it after struggling with LLM
cost estimation on a side project.
jstakelum•1h ago
That led me to a realization: Every one of my projects needs the same collection of primitives — prompt building, LLM calls, chunking, embedding, file I/O — over and over. So I started collecting them as standalone CLIs. And then, I let the model only write the 5% or so that's genuinely novel. That led to a markup language to wire those CLIs together declaratively — a workflow map.
That led me to the realization that the map is the application--source code is ephemeral.
And if a pattern appears across projects, promote it to a new CLI. The catalog grows. The model's job shrinks. For tractable software, maybe 95% of operations become primitives.
And that means the job of the LLM switches from being a code generator, to being a map generator.
And, I can imagine the system can improves itself through use, by considering if new things it codes have reusability potential, and thus assmptotically close the gap--but never reaching 100%--for what is reusable components that just need to be wired together by the map.
And perhaps an eco-system of shared pre-built components.
The same algorithm that designed this architecture is the algorithm the architecture uses to generate itself. Generation 0 is Python. Generation 1+ are maps that generate maps. Self-similar at the meta-level.
I'm publishing the full blueprints — white paper, formal grammar (WML), RFC, implementation plan, and claims chain with dropped overclaims explicitly named.
All in one folder (see url above)
Would love feedback from anyone who finds this idea interesting and would love to chat/debate about it.