Comment by layer8
11 hours ago
Maybe it’s useful to dig out the concept of modularization with a distinction between interface and implementation again, and construct agents that are able to make effective use of it.
In the case that interfaces remain unchanged, agents only need to look at the implementation of a single module at a time plus the interfaces it consumes and implements. And when changing interfaces, agents only need to look at the interfaces of the modules concerned, and at most a limited number of implementation considerations.
It’s the very reason why we humans invented modularization: so that we don’t have to hold the complete codebase in our heads (“context windows”) in order to reason about it and make changes to it in a robust and well-grounded way.
Blogged about modular code and LLMs few days ago
https://www.slater.dev/2026/02/relieve-your-context-anxiety-...
Maybe it could just measure the number of tokens for the examples (and then summarize what the examples show, under the assumption that that’s the actual functionality of the project). I’m 90% joking… but that last 10% makes me wonder…
functional programming get recked, OOP is back, baby!
This is orthogonal to that. Interfaces are types, implementations are lambda bodies. There you go.
Funny but an aim of FP is composable flow as well?
With even more suitable for LLM types and "contracts at the edges".