LLMs Aren't Replacing Developers.They're Multiplying Them.
The execution is easier. The problem hasn't changed—you still need to know how to provide context.
The real problem hasn't changed
Before LLMs, after LLMs—it's always been about context
Pre-LLM Work
An efficient workflow realized that developers are the most expensive part of the pipeline. Teams that understood this put effort into digesting content so the context devs received was optimal.
That was the happy flow.
But what usually happens, even in great teams? Pressure. We must deliver. Fast.
So the product manager cuts a corner, that propagates to the designer, and suddenly the developer has questions because stuff doesn't make sense.
Set up a meeting. At least 3 people trying to figure out what went wrong. Classic.
The Issue Was Always There
The Context.
For me, as a developer, to accomplish the mission, I need to understand:
- The problem
- What tools I've got
- How rotten the codebase is (every codebase is rotten, by definition)
- What I don't know I don't know
The more I know, the quicker and better the execution.
So why do we treat LLMs any differently?
What changed with LLMs
The Explosion
Tools like Cursor, Lovable, Bolt exploded onto the scene. Suddenly, normal people could "build" stuff.
But many found out really quickly that a product is not just saying "I want an app that does..."
They realized the LLM, without proper context, doesn't work well.
But How Do You Provide Context?
THAT'S where our expertise comes in.
We know how to provide context.
We know what a developer needs to know to accomplish the job.
Same issue whether you use LLMs or not—the real problem is how good you are at translating vision to execution.
Now, with LLMs, execution is easier. But you still need to give proper context.
How to actually get shit done
Models like DDD are awesome in theory, but in practice you need to know what you're doing AND enforce it in real life.
Foundation: Define the Business
Today, with LLMs, the execution is way simpler.
I ask the LLM to ask me the right questions. We define the business clearly. Through that process, we uncover things we might not have considered.
The output of this document is the foundation of the codebase.
Architecture: How We're Building It
A proper definition of how the app works is the next critical step.
- Where things should be placed
- How files are structured
- How components interact
Once everything is laid out—"what we're building" & "how we're building it"—we can start developing features.
Working on a Feature
TDD + LLM = 💋
When I start a new feature:
- I describe it
- The LLM knows what to ask me
- We build a plan and break it down
- We work on writing tests
- Transforming our conversation to tests is extremely easy
What's left? Tell it "Go, Go, Go!"
Why this approach works
Context is Everything
LLMs are only as good as the context you provide. We know exactly what context they need.
Faster Execution
With proper setup, LLMs multiply development speed. Features that took weeks now take days.
Better Quality
TDD with LLMs means test coverage from day one. Your features are validated before they're built.
Clear Architecture
Documentation that's actually useful. The LLM and your team both understand where things go.
Team Scalability
New developers (human or AI) can onboard quickly because the context is documented and accessible.
Future-Proof
As LLMs improve, your system gets better automatically because the foundation is solid.
I've been working with LLMs for years
From the initial beta version of Copilot to today's advanced models. I'm no expert—just someone with experience who figured out what works.
The Bottom Line
LLMs are tools. Like any tool, you need to learn how to use them.
The possibilities are pretty much endless—but only if you know how to provide the right context.
That's what I do. I know how to make LLMs work for you.