There's a V2EX post that's been sitting in my head since I read it. A developer admitted that after enough vibe coding, they went lazy in a very specific way. The knowledge they cared about moved from the "semantic layer" (how do I implement this) up to the "abstraction layer" (convention and taste). They stopped asking the model *how* to build something and started only asking whether it was buildable inside a chosen stack and set of constraints. They stopped memorizing reusable details. When something needed to be changed repeatedly, they just had the agent write a doc and re-read that doc every time instead.
That last sentence is the whole thing. Most people read that post as a confession about getting lazy. I read it as a design pattern that nobody persisted properly.
The shift is real, but the storage is an afterthought
The interesting part isn't that the person became a "manager" of agents instead of a programmer. That framing is everywhere now. The interesting part is *why* the shift happened: tech stacks multiply faster than you can learn them the old way. One app is Electron, the next one hits an unfixable wall in Electron and has to be Tauri, the one after that is Python or Go, and under each of those is a pile of libraries. You physically cannot study all of it the ancient way and still ship. So the durable skill becomes picking the stack, setting the conventions, and knowing which layer to adjust when something breaks.
Here's the friction, though. If your conventions and decisions only live in a chat thread or a Markdown file you ask the agent to re-read, they're fragile. They scatter across sessions. They don't survive a stack change. They get re-explained, re-argued, and slowly drift. The same forum is full of people solving *fragments* of this problem without naming it. Someone built a browser extension just to pull valuable AI conversations out of chat history and commit them to a GitHub repo, because "过几天想翻出来" — a few days later you want it back and can't find it. Someone else built Rim, a layer between git and the agent, because slop code and throwaway branches were burying the few decisions that actually mattered.
Different tools, same underlying ache: the valuable, reusable *judgment* has no home. It keeps leaking.
What's actually worth persisting
If you're going to operate at the convention layer, the thing you save is not code. Code is cheap now; the agent regenerates it. What's expensive is the accumulated taste:
- Which stack you chose for which class of problem, and the constraint that forced it (the Electron-to-Tauri lesson is a perfect example).
- The conventions you want every project to follow — naming, structure, error handling, the stuff you'd otherwise retype into a prompt forever.
- Post-mortems: this problem happened because of X, it lives at Y layer, here's how we adjusted.
- The "don't do this again" list, which is really the most valuable file you own.
None of that is tied to a language. That's the point. It should outlive any single stack, because the whole reason you went up a layer was that the stacks keep changing underneath you.
Build the store your agent queries first
So instead of a flat doc the agent re-reads top to bottom, make it retrievable. When a convention or a past decision is relevant, the agent should be able to *pull the specific pieces* rather than reload everything or, worse, forget it exists.
This is a concrete, buildable project on VicroCode, and it maps cleanly onto what the platform actually does. You stand up a LanceDB knowledge base as the memory: your conventions, decisions, and post-mortems go in as entries the agent can retrieve by relevance instead of by scrolling. A bit of online Python handles ingesting new notes and chunking them, so adding a decision is a small, repeatable action rather than a formatting chore. You then wrap retrieval behind an API endpoint hosted in-platform, and connect that to your agent through AI agent development so the agent consults the store *before* it writes, not after it's already guessed.
A practical shape for it:
- **Capture.** A simple input path — a Python-backed endpoint — where you drop a new decision or convention. Keep it low-friction, because the browser-extension story proves that if saving is annoying, the knowledge just doesn't get saved.
- **Store.** The decision goes into the LanceDB knowledge base for semantic retrieval, with a small SQLite table alongside for the structured fields you'll want to filter on — stack, project, date, status. SQLite and database editing are in-platform, so you're not standing up external infrastructure for this.
- **Retrieve.** The hosted endpoint takes the agent's current task context and returns the handful of relevant conventions and prior decisions.
- **Consult-then-build.** Your agent calls that endpoint as its first move on any task, so taste and constraints are injected at the start instead of re-litigated every session.
One boundary worth stating plainly: the original developer's workflow jumps across Electron, Tauri, Go, and whatever's next, and those are build targets you'd run in their own environments. VicroCode's execution and hosting here cover HTML web apps and Python — so the knowledge *store*, the retrieval API, and the agent orchestration live on the platform, but the Go or Tauri binary itself gets built wherever that toolchain lives. The decision layer is portable; the compile step stays with the stack. That's actually the correct separation, because the store's whole value is that it doesn't care which stack you're targeting this week.
Why this beats the "re-read a doc" habit
A doc you re-read is linear and it rots. A queryable store does three things the doc can't. It scales — you can accumulate hundreds of decisions without the agent choking on context, because it only pulls what's relevant. It survives stack changes — the conventions aren't buried inside a project folder that gets deleted when you pivot. And it's auditable — when the agent makes a call you disagree with, you can trace it back to the entry that informed it and fix the entry, not the vibe.
If you want to sharpen the retrieval and agent-wiring side before you build, the AI coding material is a reasonable place to ground the mechanics. But honestly the hard part isn't technical. It's the discipline of writing the decision down the moment you make it, while you still remember the constraint that forced it.
I'll be straight about what I can't claim. I haven't measured how much time this saves, and I'd treat any "10x fewer repeated mistakes" number as unverified until you run it on your own work. The forum evidence tells us the *need* is real and currently being patched with duct tape — export extensions, git middle-layers, scattered docs. It doesn't tell us the payoff size. What it does tell you is the move: stop treating your conventions as something you re-explain, and start treating them as a store your agent reads first. The taste is the asset. Give it a home.