Notes on "AI Mistakes You're Probably Making" by Theo
A co-worker sent me a video link last week — just a “check it out.” I watched it twice and took notes, which is not something I do for most content. The video is “AI Mistakes You’re Probably Making” by Theo from t3.gg. If you’re a developer trying to use AI tools in a way that actually works in production, it’s worth your time.
What follows are my notes, with my own opinions mixed in. Theo and I don’t agree on everything, and I’ll say where.
Who Decides the Solution?
There’s a difference between asking AI how to solve a problem and knowing how to solve it yourself, then telling AI to execute. Theo is pretty firm that handing the decision to AI is a mistake. I think he’s mostly right, but I’d push back a little.
For hard engineering problems — architecture decisions, system design, something subtle breaking under load — you still need to be the engineer. The AI doesn’t know your tech debt, your team’s quirks, or why that one weird thing was built the way it was.
My approach has been shaped by HumanLayer’s agentic workflow: define the task, research the codebase, make an execution plan, implement, then code review. I stay heavily involved at the task definition and plan stages — that’s where I want to be the decider. After the plan is approved, I step back and don’t touch it again until code review.
But a straightforward bug? A simple integration? Letting Claude handle it end-to-end and reviewing the output is often faster than hovering over every step. You’re not checking out — you’re delegating execution and staying accountable for the result.
At work, we have an informal policy that engineers stay in the decision seat. In my personal projects, I give AI more rope. Both feel right in their respective contexts. The mistake is thinking one rule applies everywhere.
Context Is a Resource, Not a Gift
Too much context kills performance. Theo calls it “context rot.” It’s real. Dumping your entire repository into a session doesn’t make the AI smarter — it makes it worse. Same as it would for a human trying to absorb a thousand-page document before answering one question.
The video mentions Repomix, which packages your whole codebase into one file for AI to consume. It’s a clever idea — and a clear illustration of exactly the wrong approach. The point the video makes holds: too much context isn’t helpful, it’s just noise.
On CLAUDE.md: Theo defends it, and so do I. But he makes a point I’m taking personally — it should be intentionally curated, not auto-generated. I’ll be honest, I’ve been auto-generating mine. That’s changing. A good CLAUDE.md is the short list of things the AI genuinely can’t infer — how to run the test suite, what port the dev server uses, gotchas specific to this codebase. It shouldn’t be a dump of whatever the AI decided to write about itself.
One thing said in the video that I wholeheartedly agree with: if an agent needs to understand your entire codebase to fix one bug, that’s not an AI problem. That’s a complexity problem.
Your Environment Is Your Foundation
CLI-based AI tools like Claude Code are functionally stateless. Yes, there’s project memory and conversation history. But every session is a fresh start. If your environment is broken — a missing dependency, a misconfigured variable, a port conflict — the AI will hit that same wall every time. It’ll try to self-heal, but if the resolution never gets baked into your main branch, you’ll waste tokens and, more importantly, time, every time you fire it up.
Tools Should Earn Their Place
Theo’s position on MCP tools is basically: they all add noise, most aren’t worth it, run lean. I respect it. I don’t fully share it.
There are a couple I find useful — specifically Chrome MCP and Playwright MCP for browser automation. Having the agent actually use the browser instead of guessing at what renders is a real practical upgrade.
But the principle is right. Every tool you add expands the context window. Tools you’re not actively using still take up space. Adding an MCP integration because it seems cool is how you end up with a slow, confused setup.
Add a tool because it solves a specific, recurring friction point. Audit periodically. Remove what you’re not using.
We’re Not Being Replaced (for now) — We’re Transitioning
Developers still have a place. The planning, the architectural decisions, the judgment calls that require real understanding of a system — those aren’t going away (this week). What’s changing is the ratio of thinking to typing.
I think we’re transitioning into managers and orchestrators. That doesn’t have to be a downgrade. It’s a change in what good performance looks like. The engineers who will struggle are the ones who stay in execution mode when the competitive advantage has shifted to direction and oversight.
I’m still figuring out what that looks like in practice. But I’d rather be in that mess than pretending I have it figured out.
What about you — are you still the decider on every problem, or have you started letting AI own certain categories of work end-to-end? I’m curious where other developers are landing on this.