Here's a situation that will feel familiar. You're debugging a production issue. The AI assistant helps you trace it to a specific module. You ask why the module works this way. It can't tell you — because the answer is in a Notion doc from Q3, referenced by a comment in a git commit, explained in more detail in a Confluence page that was written during a post-mortem nobody remembers. The code is just the artifact. The knowledge that produced it is somewhere else.
This is the actual problem with AI-assisted development today. It's not a retrieval problem. It's a relationship problem.
Developer knowledge is inherently distributed. Code lives in GitHub. Architectural decisions live in Notion or Confluence or, more often than anyone admits, in a 47-message Slack thread that nobody bookmarked. Tribal knowledge lives in individual engineers' heads, sometimes partially written down in Obsidian or a local notes folder. Git commits carry intent if you're disciplined about messages, which most teams aren't consistently. Pull request comments contain entire debates about trade-offs that never made it anywhere permanent.
Your AI coding assistant sees the file that's open in your editor. Maybe, with some setup, it sees adjacent files. It does not see the decision log. It does not see the post-mortem. It does not know that you chose Approach B over Approach A six months ago because Approach A had a performance cliff you only discovered in staging.
This means your AI is operating on a deliberately partial picture. It will make suggestions that are locally correct and systemically uninformed. It will recommend patterns you've already tried and rejected. It will miss the fact that a module is structured the way it is because of a constraint that's no longer encoded anywhere in the code itself.
The teams that will win at AI-assisted development are not the ones with the best prompt engineering. They're the ones whose AI understands their knowledge in relationship — code to decision, decision to outcome, outcome to constraint.
This is what Pyckle is building. Not another search box, not another plugin that ingests your repo. A unified context layer that understands your codebase in the context of everything else your team knows about it. Architecture decisions linked to the modules they shaped. Post-mortems indexed alongside the services they describe. Notes and documentation treated as first-class signals, not afterthoughts.
The technical challenge here is non-trivial. Relationship-aware retrieval across heterogeneous sources requires more than plugging different data connectors into a vector store. You need to understand provenance — where a piece of knowledge came from, how old it is, what it was written in response to, and how it relates to code that may have changed since.
Most tools treat this as a search problem because search is easier to build and easier to demo. Pyckle treats it as a knowledge graph problem, because that's what your actual codebase is.
The practical payoff is an AI that can answer questions that currently require a 20-minute archaeology expedition through four different tools. And over time, one that can proactively surface the relationships you didn't know to ask about.
Your knowledge is already in multiple places. Your AI should be able to see all of them, together.