Earlier today I was watching a few videos about AI coding tools, and one line from one of those videos stuck with me. The person said something along the lines of: “Skills that aren’t in these files aren’t as relevant as you think.”
That statement made me pause for a moment because it connects to something I’ve been thinking about for a while. There’s a common narrative in tech right now that AI will make it easy for anyone to build software. In reality, a lot of the tools being built around AI are simply wrappers around existing models.
That’s not necessarily a bad thing. I’ve built my own share of wrappers, and I’ll probably build more. Wrappers can add real value if they provide better workflows, integrations, or interfaces. But the challenge is that a wrapper alone isn’t much of a moat.
Many startups today are essentially building interfaces around large models. One tool might wrap Gemini, another might wrap ChatGPT, and another might wrap Claude. They add dashboards, prompt templates, and a bit of automation, and suddenly it’s a product.
The problem is that the companies providing the underlying models are constantly improving their own platforms. If the core model provider decides to add the same workflow features directly into their product, the wrapper loses much of its advantage.
Companies like Google and Dropbox are clearly thinking about this. They’re not just building AI features; they’re trying to build ecosystems where the model is integrated directly into the platform people already use. If you control the storage layer, the identity layer, and the application environment, you can bundle AI in ways that standalone tools can’t easily compete with.
But while thinking about all this, I started realizing something else. The specific model you use may not matter as much as people think.
That might sound like a controversial statement, but in my daily workflow I’ve noticed something interesting. When a model fails to produce the result I want, the problem is often not the model itself. More often than not, the problem is the prompt.
If you’ve been working with an AI agent for a while and you ask it to change something on a page, it usually understands the context of what you mean. If you tell it to change a color, it can often infer which element you’re referring to because it has seen the surrounding conversation and code.
But if you start a fresh conversation and say “change the color,” the model has no idea what you’re talking about. The context is missing. The same model that performed well before suddenly appears incompetent, even though the only thing that changed was the amount of information you provided.
This is the classic “garbage in, garbage out” principle. If the prompt is vague or incomplete, the output will be poor regardless of how advanced the model is.
That’s where the idea of “skills not in the files” becomes relevant. If the reasoning behind your system isn’t written somewhere—whether in code, documentation, or prompts—the model can’t access it. From the perspective of the AI, knowledge that isn’t included in the context effectively doesn’t exist.
This realization has changed how I think about development. Documentation and structure are becoming even more important, not just for humans but for machines as well. The better you define the context around your code, the more useful AI tools become.
Another thing I’ve been experimenting with is building tools that analyze my own codebase. For example, I’ve been setting up small systems that scan repositories for potential issues. In a home lab environment, I might run these checks using smaller models where some degree of error is acceptable.
But this kind of experimentation quickly reveals a different challenge: cost and signal-to-noise ratio. If you scan every pull request indiscriminately, you end up burning a lot of tokens while generating very little useful insight. Many of the files haven’t changed, and scanning them again adds little value.
A better approach is to focus on changes. Instead of scanning everything, you analyze the files that were modified and evaluate them in context. That dramatically reduces cost while increasing the relevance of the results.
This reminds me of problems we’ve seen before in infrastructure and monitoring systems. Early versions of monitoring tools often generated huge volumes of alerts because they tried to watch everything. Eventually, teams realized that more data doesn’t always mean more insight. The key is filtering and focusing on meaningful signals.
I suspect we’ll see a similar pattern with AI-assisted development tools. The first generation of systems will try to analyze everything, but the more mature systems will be selective, analyzing the right pieces of context at the right time.
Another idea I’ve been thinking about is the assumption that AI will lead to a universal tool that solves every development problem. I’m skeptical of that. Every organization has its own workflows, its own constraints, and its own engineering culture. A one-size-fits-all solution rarely works well in practice.
In the end, the most valuable systems will probably be the ones that integrate AI into existing workflows in thoughtful ways. Instead of trying to automate everything, they’ll focus on the areas where AI can genuinely augment human decision-making.
When I step back and think about all of this, the conclusion I keep coming back to is that the model itself is becoming less important over time. The real differentiators are context, clarity, and system design. If you provide a model with clear instructions, relevant files, and well-structured information, even a moderately capable model can produce impressive results.
But if the context is weak, even the most advanced model will struggle.
In other words, the real skill isn’t just choosing the best model. It’s learning how to structure problems in a way that machines can actually understand.