21–30 of 34 posts
I've been having good luck with fairly autonomous LLM coding with the following rules: * 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 * A…
Earlier quoted context omitted.
OP Here: 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
What makes is special about "agentic development" vs reducing context requirements, reducing cognitive burden, etc for human development too? "A human developer builds a mental model of a codebase over months"—yeah, that makes onboarding to a codebase very time consuming, expensive, and error-prone. So why is "better for agents" distinct from "better for humans"?
The article presents a function making use of global variables, declares it bad, and then proposes that the solution is functional programming. 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.
Earlier quoted context omitted.
What makes is special about "agentic development" vs reducing context requirements, reducing cognitive burden, etc for human development too? "A human developer builds a mental model of a codebase over months"—yeah, that makes onboarding to a codebase very time consuming, expensive, and error-prone. So why is "better for agents" distinct from "better for humans"?
Agents can simply be told to write code in a functional style. They won’t complain. Think of it like a constraint system or proofs system. The agent can better reason about the code and side effects. Etc. Agents are very good at following and validating constraints and hill climbing. This makes sense to me. Humans benefit too, but it is hard to get a bunch of humans to follow the style and maintain it over time.
Earlier quoted context omitted.
Agents can simply be told to write code in a functional style. They won’t complain. Think of it like a constraint system or proofs system. The agent can better reason about the code and side effects. Etc. Agents are very good at following and validating constraints and hill climbing. This makes sense to me. Humans benefit too, but it is hard to get a bunch of humans to follow the style and maintain it over time.
Agents are useful because they don't inherit context from their parent context. They're basically "compaction" at a small scale. They succeed because context pollution create greater indeterminancy. The fact that you can spin up many of them is not primary benefit of them.
The article presents a function making use of global variables, declares it bad, and then proposes that the solution is functional programming. 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.
You can even do it in .NET using dependency injection (which is a kind of an OOP) concept: just supply dependencies as constructor parameters and do not change state in the service/handler.
You can follow the same concepts with ease using Go and no one will argue Go is a functional programming language.
So, the idea is not to do straight functional programming but to apply some lessons from the functional programming.
And I find the article to be very logic and even if I did not apply the same rules as the author, I empirically observed that coding agents shine where they don't have to argue much about state, the more state there is to keep track of, change and reason about, the harder it is for both humans and coding agents to do changes without breaking things.
And since I like the author's ideas I am willing to spend some tokens and put them to the test.
The only things I would add on top of this is modularization, either by using Vertical Slice Architecture or by designing a modular monolith where each module is isolated and has its own contract. Because, the less source code an agent has to reason about, the better are the results.
So my next greenfield experimental project will feature: compound engineering, TDD, SUPER and SPIRALS (as in the article) and modularization.
Functional programming also helped get ride of bugs before, and still people used other paradigms. Why would we change now? How to know that functional programming is indeed better for vibe coding?
Because previously people had to write code themselves and they had personal preferences. Because the bugs were less when written by a human.
Now personal preferences doesn't matter as much since people won't change the code themselves too much. And because LLM can introduce lots of bugs and make a mess in the code unless you can restrict them somehow.
Earlier quoted context omitted.
Wouldnt a fair counter argument be, that llms have been trained on way less fu ctional code though? Like they are trained on a LOT of js code -> good at js Way less functional code -> worse performance?
You can write functional-style code in many languages, as I have in JS and occasionally Python to great benefit.
Functional programming also helped get ride of bugs before, and still people used other paradigms. Why would we change now? How to know that functional programming is indeed better for vibe coding?
OP Here: 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
I think modularization will further reduce context. I am planning to play with your SUPER and SPIRALS idea and use modularization on top via Vertical Slice Architecture or modular monolith where each module is isolated and has a contract.