Most vibe coding retrospectives come from people building web apps. When their code is wrong, a page fails to render.
I work on IoT systems, where software ends up talking to hardware that physically moves — some of it on networks I can't reach from my desk. When my code is wrong, someone drives out to a site.
This is what I think in July 2026. My view on this has shifted roughly every month, so treat it accordingly.
The order of learning flipped
The old way: learn the language, then build with it.
For the past year I've done the opposite. Pick what I want to build. Skim the language just enough to know its temperament. Go straight to a working system. Then learn the language properly while refactoring it.
Understanding arrives during the refactor, not before the first line. I've picked up languages I'd never written this way, and I think I know them better than if I'd done the tutorials — every concept arrived attached to a problem I already had.
The first ceiling wasn't hallucination, it was repetition: the same structures re-derived every session, nothing accumulating. Long before skills existed as a feature, I built crude versions myself — reusable instruction blocks, deliberate token budgeting. That problem has largely receded since.
AI gives you the middle answer until you narrow it
This is the one I'd most want you to take away.
A while back I had to get software talking to an analog phone line. I described the problem carefully. For a long time I got answers that were reasonable and useless — SIP libraries, softphone stacks, audio routing. All correct for a problem that wasn't mine.
Then I stopped asking and went to read about the hardware itself. That's where I found two terms I hadn't known existed: FXO and FXS, the two sides of an analog telephone interface. My entire problem lived in that distinction, and I'd been describing it in words that never touched it.
I dropped those two terms in. The answers changed immediately.
The model didn't change. I finally had the word that pointed at my problem — and getting it meant going and learning something first.
AI doesn't teach me things I don't know. It finishes things I half-know. The half-knowing is still on me.
The corollary: the more standard the domain, the more the middle answer is the right answer. For web prototyping, one person with AI now beats a small team working conventionally, and it isn't close. For embedded, I have to narrow it myself every time.
The disaster that became a product
At some point I handed a spare Raspberry Pi's shell to the model and let it run. It went beautifully until it touched coreutils, and the machine was gone.
Losing a throwaway board cost nothing. What it cost was an assumption. Most of what the model did was reasonable. The failure was that nothing sat between a plausible command and an irreversible one. That's where the execution-safety layer in homebutler came from — a narrow set of tools an agent can call, instead of a shell it can do anything with.
People expect my rule to be a category — "never let AI touch the protocol parser." I don't have one. My line is blast radius. Twenty lines that change a log format and twenty lines that reach a device controller are not the same object, even though they look identical in a diff. Judging that requires knowing the system.
The bottleneck moved to me
Early on I refused to proceed until I fully understood everything produced. Then I noticed the obvious: generation was fast, my reading wasn't, and the gap was widening.
So I built a custom skill that walks the code and reports back in natural language — call paths, complexity, structure. I read the report instead of everything.
I'll be honest about what that is. I delegated verification to the same class of system that produced the thing being verified. That's a real weakness. I took it because the alternative made the speed gain meaningless. I haven't solved this; I've picked a tradeoff.
What I lost
I was asked to review a colleague's code recently. I saw the fix immediately — the whole shape was there in my head. Then I sat at the keyboard and couldn't write it, because I couldn't remember which function to reach for.
The design was intact. Getting it out of my head was not. A year ago it would have been.
I'm not going to pretend that's fine.
What I gained
The ability to connect ideas that live in different places.
Not depth at a single point — that's the gap AI closed fastest. If I need to go deep on one thing, I get there in an afternoon now. Depth got cheap.
What didn't get cheap is recognizing that the idea over here and the idea over there are the same idea in different clothes. Holding a system's whole shape in view and knowing where its seams are.
That's what the phone line problem actually was. Not technically hard — the answer just lived in a domain I hadn't connected to the one I was standing in.
And that connecting work is what decides the quality of what comes back. See the shape, and you can tell the model which connection matters. Don't, and you'll get the reasonable middle answer forever without knowing it.
Every ceiling was me
Line the year up and the pattern is hard to miss. Every limit above looks like a limit of the tool. None of them are.
The repetition wasn't the model failing to remember — I'd built no scaffolding. The middle answers weren't shallowness — I didn't own the word yet. The dead Pi wasn't recklessness — I'd built no layer between plausible and irreversible. The review bottleneck was me, by name.
The model got better at nearly everything this year. It didn't get better at knowing my system, and it won't — that isn't a skill, it's a place you have to have stood. The board on my desk. The constraint nobody wrote down because everyone already knew it. The failure I watched at 2am. None of it is in the training data because none of it was ever written down.
Everything I do got faster except one thing: deciding what connects to what. That decision is still mine, and it's attached to far more output than before. So the return on seeing how the pieces fit went up this year, not down. That's the opposite of what I expected.
So if you asked me what's worth building in myself right now, I wouldn't say a language, or a framework, or a better way to prompt. I'd say the ability to join one piece of knowledge to another. It's the one input the model can't supply, and it decides the quality of everything it gives back.
That's my answer after a year. Yours will be different — you're standing somewhere I've never stood.
Top comments (0)