I've known these things from the beginning.
Any extra restriction that still produces functional code ends up being great for LLMs to curb them deterministically.
I've explored Clojure after talking to Metabase about how it had benefited them. That said, it was years ago so I can't claim it influenced this work.
The framework was designed to be a language agnostic way of sharing best practices to bias agent behavior towards a more scalable end. I initially used it when I was working with a team to do some massive refactoring/clean up across the codebase. We didn't come to an acronym but similar principles and it was "testable" and easy to push back on PRs that weren't aligned with the principles.
That said, it may be interesting to see if I could replace all that context and just say -- "code it like you would with Clojure"
Have you tried that?
In fact, synthesis of pure Haskell powered by SAT/SMT (e.g. Hoogle, Djinn, and MagicHaskeller) was already of some utility prior to the advent of LLMs. Furthermore, pure functions are also easy to test given that type signatures can be used for property-based test generation.
I think once all these components (LLMs, SAT/SMT, and lightweight formal methods) get combined, some interesting ways to build new software with a human-in-the-loop might emerge, yielding higher quality artifacts and/or enhancing productivity.
Like they are trained on a LOT of js code -> good at js Way less functional code -> worse performance?
it’s not discussed in this post but in another right after I discuss the modeling I was doing on tech debt and finding the game to improve agent outcomes was reducing context.
functional programming accomplishes that. I can’t claim it’s the only way, but it’s one that’s well understood in the community
So why is "better for agents" distinct from "better for humans"?
There's nothing wrong with promoting functional programming, but the implication that all non-FP code is hard to test and/or uses global state is naive.
* TypeScript everywhere with extreme enforcement of the type system.
* No "as" casts, no "any" declarations, all code must understand the shape of its data
* All boundaries validated using a typed validation library. Many use zod, I prefer tjs. I also have strictly typed pg and express wrappers.
* No files longer than 300 lines
* All of these rules are enforced by an eslint configuration that runs in a pre commit hook.
Global state and classes could also be removed via eslint rules, that would be interesting, though I haven't found it to be an issue in practice once the types are strictly enforced.
midnight_eclair•3d ago
> what do you use for normative language to describe component boundary, function and cross-component interactions?
something i can feed into a deterministic system that will run a generative suite of tests (quickcheck/hypothesis/clojure.spec) that will either give me the confidence or give the agent the feedback.
cyrusradfar•3d ago
That said, I don't "vibe" because it creates great code I love reading, but I can monitor and move the same metrics I would if I was managing a team.
I also use code tours a bit, and one of my first tools I needed and built (intraview.ai) was to support this need to get deep in the code the Agents were claiming was ready to ship.