Where in the Stack Should You Build?
At one point I had created a library of over 50 SQL and Opensearch template queries I used each week to wrangle up data for ML training.
This was back before LLM tools became mainstream.
The queries weren’t sophisticated, but they handled my use cases well. They were also easy to understand and troubleshoot if something didn’t seem to be working.
I learned to write these – passably. Enough to pull data, join tables, answer a question without waiting for an engineer.
Once I reached a good enough level - I deliberately never got much better at it than that.
Every hour I could have spent becoming a stronger SQL writer was an hour I wasn’t doing the thing I was actually better at: figuring out which query mattered, what the data meant, and what it implied for the product. Where the models seemed to be doing well, where they needed to improve, and where we had no idea.
I could always find someone to write better queries. I couldn’t always find someone who knew what to ask.
That wasn’t laziness. It was a judgment about where my time compounded.
I’ve been thinking about that decision a lot since starting to build with AI tools in earnest — first the financial planning work I wrote about in Article 1, then the nature access map in Article 4. The more I build, the more I notice that the most consequential decisions aren’t about how to build something. They’re about where in the process your leverage actually lives.
The Stack Has Layers — And They’re Not Equal
When people talk about “building with AI,” they’re usually collapsing several genuinely different things into one.
At the foundation, there’s training foundational models — the work Anthropic, OpenAI, and Google do. Enormous compute, proprietary data, specialized research teams. Almost no one reading this should be operating here.
One level up: fine-tuning and domain adaptation. Taking an existing model and adjusting it for a specific task or dataset. Still technical, but accessible to a much wider group — though the relevant question increasingly is whether the base model already does what you need, because often it does.
Above that: building AI-powered applications. Connecting LLMs to data, interfaces, and logic to make something useful. This is where most of the interesting work is happening right now, and where the barrier to entry has dropped most dramatically.
And above that: using AI-powered tools to create things that aren’t primarily engineering at all — writing, analysis, structured research, products where the judgment and domain knowledge are the core value, and the code is just the vehicle.
These are genuinely different layers. Which one you should work at isn’t obvious, and “I can build this now” doesn’t answer it.
The Right Level of Abstraction Is the Same Question
In a previous article, I wrote about how judgment was always the bottleneck — that vibe coding made it visible, not new. This piece is about a related but distinct question: given that you have judgment, and given that you can now build things you couldn’t before, where should you be building?
This is a question I’ve been trying to answer for myself.
There’s a useful frame from computer science education that I found clarifying here. When I first learned to code, I started with a site that abstracted away almost everything — you typed commands, things ran, but you had no idea why. Then I took a more rigorous introductory class that went deeper. Then, eventually, a course that started just above the transistor level — actual hardware, zeros and ones, how you get from electricity to software. Each level of abstraction revealed something the previous one had hidden.
The lesson wasn’t “always go to the lowest level.” Going down to the physics of transistors was helpful for understanding how computers work. It wasn’t necessary for building a web application. The insight was that the right level of abstraction depends on what you’re trying to do — and choosing wrong in either direction creates problems.
Too high: you can’t diagnose what breaks. This is what happened when I hit the rendering bug during the nature access map build. Claude kept proposing fixes that introduced new problems, and we went in circles until I suggested using browser dev tools to surface actual error information. Abstracting away all understanding of the underlying system meant I was stuck the moment something went wrong.
Too low: you’re spending your time on infrastructure that isn’t your actual problem. If I’d tried to build a more capable machine learning pipeline from scratch for the nature access scoring, instead of using public data and simpler distance calculations, I’d have spent months on something that wasn’t what the app was focused on.
Choosing where in the stack to build is the same decision as choosing the right level of abstraction. The mistake is treating it as fixed.
The Chef Doesn’t Make the Spatula
Here’s the underlying principle: being capable of doing something and that being a good use of your time are different things.
A skilled chef could, in principle, forge their own knives, mill their own flour, build their own oven. They might have enough mechanical intuition to figure it out. But that’s not where their differentiation lives, and spending time there means spending less time on the cooking — which is where they’re actually hard to replace.
The question for anyone building now is the same one I was asking about SQL years ago: where does my time compound? Where is the gap between what I can do and what most people can do actually widest?
During the ten years I’ve spent in legaltech, the honest answer was never “write better ML code.” It was understanding what types of contract data matter to attorneys, salespeople, and finance teams — and how to structure and surface it in a way that was most useful to them.
That meant understanding what clause types mattered to an M&A attorney under what conditions, how to translate a 91% accuracy rate into something meaningful for a lawyer managing risk, which edge cases would surface in exactly the situations that mattered most. Those were judgment calls that required domain knowledge I’d spent years building. Better tooling wouldn’t have made them easier — it would have made the engineering around them cheaper, which is a different thing.
That calculus hasn’t changed. What’s changed is that the floor of “good enough building” is now much higher, which means more people can reach it — and that makes the question of where you’re actually differentiated more urgent to answer explicitly. Before LLMs, if you couldn’t write the code, the question was moot. Now it isn’t, and that’s mostly a good thing. It just means the “where should I build?” question is no longer optional.
So Where Does Your Time Compound?
Building toward something of my own has sharpened this question more than anything else. If I can build more easily than before, what should I actually build? At which layer?
The honest version of the question isn’t “can I do this?” It’s: where is my specific combination of domain knowledge, judgment, and taste producing something that isn’t easily replicated by someone working adjacent to me?
For some people, that points toward a lower layer — they have genuine ML depth, or systems architecture intuition, or infrastructure knowledge that’s still genuinely hard to replicate. For most of us building on top of these models, the answer points up: toward the quality of the problem being solved, the specificity of the insight, the understanding of the user, the design of the experience.
This doesn’t mean the engineering disappears. As I wrote in Judgment Was Always the Bottleneck, engineering judgment — knowing when a latency issue will create a UX crisis under load, knowing when a context window limitation will cap what’s possible, knowing when something technically works but creates maintenance debt that isn’t worth it — that’s still judgment, just expressed through technical decisions. The stack doesn’t have a clean separation between “engineering” and “everything else.”
What it means is that for most people who came to technology laterally — through law, finance, a domain specialty, a problem they needed to solve — the differentiation probably isn’t at the foundational layer. It’s in knowing what to build that’s actually worth building.
The spatula is cheaper now. The chef is still the chef.
This is Article 6 in a series on building with AI tools as a non-native technologist — covering what actually changes when someone without an engineering background starts building products. Previous articles covered financial planning with Claude Code, a framework for city selection, evaluating LLM tools, building the Seattle Nature Access Map, and why judgment was always the bottleneck.