Smol Developer
Seems like the wrong approach in the long term.<p>Realistically, a large code base LLM generation tool is going to look something like old-school C code.<p>An initial pass will generate an architecture and a series of independent code unit definitions (.h files) and then a &#x27;detail pass&#x27; will generate the code for (.c files) for each header file.<p>The header files will be &#x27;relatively independent&#x27; and small, so they fit inside the context for the LLM, and because the function definition and comments &#x27;define&#x27; what a function is, the LLM will generate consistent multi-file code.<p>The anti-patterns we see at the moment in this type of project are:<p>1) The entire code is passed to the LLM as context using a huge number of tokens meaninglessly. (you only need the function signature)<p>2) 1-page spaghetti definition files are stupid and unmaintainable (just read prompt.md if you don&#x27;t believe me).<p>3) No way of verifying the &#x27;plan&#x27; before you go and generate the code that implements it (expensive and a waste of time; you should generate function signatures <i>first</i> and then verify they are correct before generating the code for them).<p>4) Generating unit tests for full functions instead of just the function signatures (leaks implementation details).<p>It&#x27;s interesting to me that modern language try to move all of these domains (header, implementation, tests) into a single place (or even a single <i>file</i>, look at rust), but passing <i>all</i> of that to an LLM is wrong.<p>It&#x27;s <i>architecturally</i> wrong in a way that won&#x27;t scale.<p>Even an LLM with 1000k tokens that <i>could</i> process a code base like this will be prohibitively slow and expensive to do so.<p>I suspect we&#x27;ll see a class &#x27;generative languages&#x27; emerge in the future that walk the other direction so they are easier to use with LLM and code-gen.