Why context matters more than the model

ChatGPT, Claude and Codex — those are my daily drivers. I’ve covered ChatGPT. Claude and Codex serve fundamentally the same purpose for me, and the decisive difference, contrary to what the endless model debate suggests, is not the model. It is the skills I build on top of them.

The first step is always the same: I connect Codex or Claude to GitHub, usually through the GitHub CLI. From that moment the AI has access to my repository — and that changes everything. It knows the codebase. It can analyze the current state, read pull requests, search files, understand the architecture, recognize existing patterns, and explain technical dependencies. For the first time, real context exists.

This is the point where a general chatbot and a productive AI system part ways. A model without context can only average out everything it has ever read into something plausible. A model with access to my repository no longer answers about software in general, but about mine. That context is far more valuable than general AI knowledge — and the industry now has a name for producing it deliberately: context engineering. Standards like the Model Context Protocol exist for exactly this reason; they give models a clean way to reach into the systems where the real information lives, instead of copying it into a prompt.

On that foundation I build my own skills. And they don’t know some best practice from the internet — they know my way of working: my ticket structure, my coding conventions, the way requirements look on our team. A skill like that can write a Jira ticket based on the actual codebase. It can ask follow-up questions instead of simply accepting a half-formed requirement. It can structure requirements, produce technical documentation, and write new insights back into Obsidian afterward. A loop closes: what emerges is not just automation but, with every round, a better understanding of my own product. That is the difference between a tool that works through tasks and one that grows with the product.

Up to here I have described the tools separately. But none of them delivers the real value on its own. That only appears when you connect them — and at this point AI stops being a collection of individual tools for me and becomes something closer to an operating system for my working day.

The steps interlock. Fireflies records meetings automatically, transcribes them, and summarizes the key takeaways. That information moves into Obsidian on its own. What results is not just meeting documentation but lasting knowledge. Obsidian, in turn, stores everything that makes up a product over time: product decisions, meeting notes, project notes, technical insights, product knowledge, ideas. This knowledge keeps growing, week after week.

And now comes the part that makes the difference. Codex and Claude have access to Obsidian — and to GitHub at the same time. So they know both: the documentation and the current source code. Before, the AI had only the code. Now it has the why as well. For the first time a complete context exists, one that does not stop at the border between knowledge and software.

That context is exactly what makes AI dramatically more capable. It no longer understands only general knowledge about product development. It understands my product, my way of working, my documentation, the current software, and the decisions that got us there. That is the real insight behind the whole setup, and it cuts slightly against what the industry most likes to talk about: the biggest progress right now is not in the next, even larger model. It is in context. An average model with full access to my knowledge and my code is worth more to me than the best model in the world that doesn’t know my product. Retrieval-augmented generation, connected AI systems, knowledge graphs — at their core they are all about the same thing: giving the model not more intelligence, but more context.

What this complete context looks like in practice — from the first idea to a finished pull request — is the final part.