pSYoniK - Software, Hardware and Tech - In.That.Order.
All Your Projects Are Now Brownfield
So You Use LLMs to Generate Projects Eh?
I had a realization earlier on today while trying to get started on a new project I’ve been thinking about for some time. I considered the design of the application, the dependencies, how does an activity flow from the UI to the backend and how do we complete longer running tasks. What trade offs am I making and what will I be comfortable with and what will I struggle with in a month, a year, or five. It felt good and then I wrote my detailed prompt to codex and watched it chug along. And then I got depressed. If you have read my previous post on coding agents you know how I feel about them, but things have evolved since I wrote that, both in terms of technology and use cases. I now think “Do I want to work on someone else’s codebase even when it’s my personal project? Do I want to spend time understanding implementation details even in my free time?”. If you use LLMs you probably answered yes to both of those questions or you don’t care. If you are reticent about using them, it might be because you don’t want to do that or you care about understanding from first principles, so any speed up provided by LLMs is lost trying to understand its output.
What Is He Talking About? It’s a NEW Project, of Course It’s Greenfield
Let’s set the scene so we know you’re interested in this and can close the tab swiftly and move back to your scrolling through depressing news articles and rage-porn. I will assume you care about the code you write or even the code that gets generated by an LLM. I will assume you plan a new feature or that you thoughtfully work through the design considerations of the product. I will also assume that you considered multi-tenancy, styling, maintainability, deployment, and observability for this new pet project. You “know” what you are about to build quite intimately. If you don’t, you might not think or notice what I’m about to describe, so it’s important we are on the same page.
You’re now ready to prompt the LLM and you have carefully drafted your prompt(s), maybe even with the help of another LLM. You write it. You hit ‘Enter’ and off your helper goes.
What’s next? Running the project? Making a few tweaks? Checking the output? Prompting again?
Any of those things might come with unknowns despite your careful planning. Maybe the LLM decided to put all the components you carefully specified into one folder or one project or they are split across multiple files unnecessarily so. Maybe that component which you’ve carefully explained looks or feels a bit more bloated. All of these feelings, this slight unease, frustration at what you now need to do, which is understand the output, the subtle decisions, are similar to those you might have (I KNOW I have) when working on a brownfield project. It’s not yours, it’s not really new, it’s a mishmash you half understand and you half struggle to match to your mental model.
By the way, do you notice how when talking about something that is being sold to us as exact science, feelings tend to be the main ways of describing it? How we “vibe” code, how we develop “taste”, how we “intuit” when it’s drifting and “guide” the LLM back on track? It reminds me strongly of how Einstein “felt” he had developed a “taste” for relativity. He then “felt” his way through the physics of it and it culminated with a “tasteful” formula that we regurgitate with pride in our deep understanding of physics. But I digress.
You Misunderstand Greenfield
No. I don’t. Not for the purposes of this illustration. You’ll have to feel your way through this article, let the vibes set in.
Some, who are more machine than the machines they use, will stick to hard definitions and will yell loud and hard that any new project is by definition greenfield. You can close the article, subtlety is not your forte and if you insist on behaving like a machine, you should go ahead and read machine output.
The joy of a greenfield project or the joy of a personal project is, for me at least, grounded in understanding. Deep understanding. You start from scratch. You build out components, you make decisions, you read technical documentation and then you build the thing you wanted the way you wanted it. “Hey, this crashes when I give an input over 5!”, “Yes, I know, it’s on purpose, when I did X then I wanted to force a hard limit, hence the number.”. You understand why you chose a Channel over any other data structure. You understand why you chose to create an Interface for component X and why you decided to use record for that model. That understanding, that depth can of course...