In Vibe Coding Works Better With a Plan, I made the case for planning before prompting, using different AI tools for different jobs, and keeping the work in GitHub where it can survive the next model switch.
Now let's talk about what happens when you have more than one project.
You start repeating yourself. Again. That architecture decision you spent an afternoon debating? Your new AI conversation has never heard of it. The GitHub lesson you learned while fixing one application? Somehow you're teaching it again on the next. Your AI is ready to help, provided you can remember and explain everything you've already done. What a bargain.
I think there's a better way to build.
Better context engineering, not simply better prompting, is one of the next skills AI builders should develop.
We already give AI context. Just not always the useful stuff.
We paste details into chats, upload files, write custom instructions, create skills, and set up AI Projects. All useful. Each has a job.
But those tools don't necessarily connect the decisions, experiments, research, and lessons spread across everything we're building. A project might know plenty about that project while remaining clueless about a solution you already worked out somewhere else.
That's where a personal knowledge base gets interesting. Think notes, project briefs, decisions, experiments, and reusable instructions in a place you can maintain and let your AI tools consult.
The layers aren't a contest. Chat context, memory, skills, projects, and a personal knowledge base do different things. The opportunity is to make them work together.
Why the model might actually care
There's a technical reason this can work, and it isn't that models have a secret appetite for giant folders.
A model answers using what it learned during training and the information available to it for the current task. It doesn't automatically know why you rejected a design last month or which workshop materials already exist.
Retrieval-Augmented Generation (RAG) is one way to close that gap. A system searches your documents or other sources, retrieves relevant passages, and supplies them to the model. You can think of it as an open-book exam, except you still have to check whether the student opened the right book.
Connections matter too. Suppose you've documented a GitHub exercise, a chapter workshop idea, and a beginner learning roadmap. They're separate records, but together they suggest something useful: adapt the exercise into a workshop that helps beginners move through the roadmap. A model can reason across those sources if the relevant material is retrieved.
Then there's the humble decision log. I love a good decision log because it saves me from having the same argument with a different chatbot. Record what you chose, what you ruled out, and why. The next assistant can work from that history instead of confidently recommending the thing you already rejected.
Please don't upload your entire digital attic
More context isn't automatically better context.
Long inputs can bury the detail you actually need. Old notes may contradict new decisions. A pile of loosely related documents can distract the model rather than help it. Researchers have even described a lost-in-the-middle effect, where models can struggle to use information tucked away inside lengthy inputs.
The goal is context engineering: choosing, organizing, updating, and supplying the information that helps an AI complete a particular task.
For a bug fix, that might mean the relevant code, recent changes, and a couple of architectural decisions. Not every PDF you've downloaded since 2019.
A connected knowledge base is useful because it gives you something to retrieve from. Good retrieval is what makes it useful to the model.
Try it without building another app first
You don't need a fancy database or a new subscription to test the idea. A few Markdown files in GitHub, an Obsidian vault, or an organized Notion workspace can get you started.
Pick one project you're already working on. Write a short overview of what it does and where it stands. Add three decisions you don't want to revisit and one lesson that could apply to another project. Link to the actual code or source material.
Now start a fresh AI conversation and give it access to those notes, either through a supported connector or by supplying the relevant files. Ask it to summarize the project's current state, explain a decision, and suggest a next step. See what it gets right. More importantly, see what it invents.
Keep improving the notes and retrieval process until the assistant can reliably find the things that matter. And be careful about what you make accessible: a useful knowledge base still needs appropriate permissions and boundaries for sensitive information.
What if we did this together?
I'm experimenting with ways the GRC Engineering Club could take advantage of this idea collectively.
We already create learning materials, build projects, run workshops, and figure out solutions to problems other members are likely to encounter. What if those lessons were easier to connect and reuse? What if a beginner could start with a roadmap, discover an exercise that fits their next step, and understand the decisions behind a working example without waiting for someone to explain it all again?
I'm interested in whether a shared body of practical knowledge could help new learners develop faster while giving experienced builders a better starting point for the next experiment. That's an idea worth testing, not a claim that we've solved it.
The GRC Vibe Coder's Playbook is one place to begin building the skills. A connected knowledge base could help us keep the lessons from getting stranded in individual projects.
The next time your AI asks you to explain something you've already explained five times, consider whether the answer belongs in a prompt or in a place you can find again.
Your future self, and possibly your chapter, might appreciate it.