We're at an interesting point with Large Language Models. The engine has just been invented, and it's getting better every few months.
What I keep seeing: people are building entire cars, adding air conditioning, fitting stereos, and some are already attaching wings and calling it the future of transport.
Meanwhile, they've never actually felt the wind.
The problem with abstraction layers
When you wrap LLMs in multiple abstraction layers, frameworks, and tooling, you lose something important: direct contact with what the model can actually do.
Models are improving constantly. What works today might not work tomorrow. More importantly, the workarounds you built for yesterday's limitations might actually reduce the performance of newer models.
That hack you wrote to get around a hallucination issue? The new model might handle it natively, but your abstraction layer is still doing the old dance and holding the new engine back.
Every 3-6 months, we're seeing meaningful improvements. If you're building thick layers between yourself and the model, you're missing out on those gains.
What I think we actually need right now
Imagine the engine was just invented. What's the minimum you need to really understand what it can do?
- An engine
- A basic frame
- Wheels
- A steering wheel
- A seat
That's it. You want a front row seat to feel how this thing performs. When a new engine comes out, you swap it in and immediately know: did they fix that issue? Is it faster? Does it handle differently?
Even with this minimal setup, you're still getting from A to B significantly faster than walking.
Yes, there are bumps on the road. Yes, you'll run out of fuel a few times. Yes, you'll have to restart the engine more often than you'd like.
But you're still covering ground at a pace that wasn't possible before. The discomfort is temporary. The speed advantage is real.
Bertha Benz understood this
In August 1888, Bertha Benz took her husband's Patent-Motorwagen (essentially a three-wheeled motorised carriage) and drove 106 kilometres from Mannheim to Pforzheim. It was the first long-distance automobile journey in history.
There were no petrol stations. No garages. No infrastructure at all.
Along the way, she:
- Bought fuel from pharmacies (petroleum solvent was sold there)
- Used her hatpin to unclog a blocked fuel line
- Got a blacksmith to repair a chain
- Used her garter as insulation to fix an ignition wire
- Had a cobbler nail leather onto worn brake blocks, essentially inventing brake pads on the spot
The vehicle was about as minimal as it gets. Three wheels, an engine, a seat. No abstraction layers. No comfort features. Just direct contact with what the machine could do.
She made it. And she proved the technology worked.
That's where we are with LLMs right now. The infrastructure isn't fully built yet. You'll hit problems nobody has documented. You'll improvise solutions. Sometimes you'll be buying fuel from the equivalent of a pharmacy because that's just how early we are.
But you'll get there faster than walking. And you'll understand the engine in a way that people waiting for the luxury model never will.
Three problems I keep seeing
1. People don't understand how the engine works
When someone adds extras to the car (stereo, navigation, climate control), the experience changes. But if something goes wrong, you can't tell whether it's the engine or the accessories causing the problem.
The technology is still being developed. If your results are disappointing, is that the model's limitation or something in your tooling chain?
This misunderstanding runs deep. People treat LLMs like magical fairy technology. They think putting multiple "agents" together creates digital colleagues collaborating like humans.
In reality, agents are for damage control and focusing attention. They exist to work around context window limitations and prevent context rot. Miss that, and you're building on false assumptions.
2. Wild imagination syndrome
Some people take these engines and immediately try putting them into something with wings. They call it "the future flying car" and chase attention.
The engine was designed for roads. Maybe it'll power flight one day, but we're not there yet, and pretending otherwise creates unrealistic expectations.
3. Lost opportunities to learn
The real cost is that when people skip straight to someone else's flying car, they never learn how to work with the technology effectively.
Context windows. Context engineering. Tool calling. These things take time and effort to understand properly.
But if someone says "just use my flying car, it works for me," a lot of people take that shortcut. They never see what's actually under the hood.
Then when they crash, they blame the engine.
Watch what the engine makers are doing
Pay attention to where the labs are investing their time.
There's a reason Anthropic, OpenAI, and Google aren't bolting complex abstraction layers onto their own products. Look at Claude Code, one of the most capable general agents available right now. It's an incredibly simple design.
The people who built the engine are keeping their vehicles minimal. Take the hint.
When the labs pivot, pivot with them
The landscape shifts quickly. Local MCP servers were the answer to STDIO requirements. Then everyone realised remote MCP servers provide most of the value, and local ones started getting replaced.
Today, major labs are collectively converging on certain standards:
- SKILLS.md files
- The MCP protocol
- Common patterns for agent interaction
Follow that trend. If they're investing time into something, it means they've identified it as the road to better model performance. Their gains become our gains.
Your work feeds the next generation
This doesn't get discussed enough: the more we use this technology well, the better it gets for everyone.
When we build MCP servers that work, when we create SKILLS files that are effective, when we share open source code that actually solves problems: all of that becomes training data.
Models improve based on human feedback, and that feedback comes in the form of artifacts: the working code, the successful patterns, the solutions people actually use.
What people build is a reflection of where the value is (and where the bugs and problems are). When we stay close to the engine and solve real problems cleanly, we're not just helping ourselves. We're contributing to the next generation of models.
Keep it simple. Stay close to the metal.
I'm not saying never build abstractions. At some point, we'll need them. But right now, while the technology is changing this fast, there's real value in staying close to the model itself.
Build the minimum viable frame. Swap engines when new ones arrive. Feel the wind.
You'll understand the technology better. You'll spot improvements faster. And when something goes wrong, you'll know exactly where to look.
Be like Bertha. Take the minimal vehicle. Figure it out along the way. Get there first.