@Aaron Klein thanks appreciate the feedback

They overlap a bit, but they’re optimized for different jobs. VSCode treats files mostly as code/project assets. It’s great when the folder structure maps to a repo, app, config, scripts, docs, etc. The editor is built around development: search, git, terminals, extensions, refactors, debugging. Obsidian treats files as a knowledge base. The files are still just Markdown in folders, but Obsidian adds things like backlinks, graph view, tags, embedded notes, daily notes, templates, and a writing/thinking workflow around them. So the simple version is: VSCode = best when the files are part of something you’re building. Obsidian = best when the files are part of something you’re understanding, documenting, or connecting. I use both on the same folder if it’s plain Markdown. I do think the difference becomes clearer once you start linking notes together in Obsidian instead of only organizing them by folders. Shorter Version They can use the same files, especially Markdown, but the mindset is different. VSCode is built around projects/code: git, terminal, search, debugging, extensions. Obsidian is built around knowledge, meaning backlinks, tags, graph view, templates, daily notes, and connecting ideas. So folders may look the same, but Obsidian gives you a layer for thinking and linking, while VSCode gives you a layer for building and editing projects.

Congrats on launching VektorGeist. Getting a marketplace + operator network live is a big step, especially in a space where most platforms end up being either just listings or just another feed. One thing I’d be curious about as you grow it: how are you thinking about trust and quality control for tools/services? For AI operators, the hard part is usually not finding “more tools,” it’s knowing which ones are actually maintained, useful, and safe enough to bring into client work. Happy to check it out and give feedback from the builder/operator side. We’re also building in the AI automation space, so I’m always interested in places where serious builders can connect without it turning into pure spam. Shorter Version Congrats on the launch. I like the angle of combining marketplace + operator network instead of making it just another tool directory. Curious how you’re thinking about quality control/trust signals as more tools and services get listed. That feels like the thing AI operators will care about most if they’re using it for real client work. Happy to check it out and share feedback from the builder side.

We are thinking about a similar problem, although more from the knowledge/context side than the coding-agent side. My feeling is that the hard part is not generating the tickets, it is maintaining reliable state between tickets. Once the work spans multiple days, the orchestrator needs to know what is done, what is blocked, what changed in the codebase, what context the next agent actually needs, and what should not be touched yet. I would probably keep GitHub Issues as the source of truth and make the orchestration layer as thin and boring as possible: ticket order, prerequisites, assignment, status, test results, and logs. I would not let the LLM fully “own” the queue. Let it execute or propose next steps, but have a deterministic layer decide what is eligible to run next. We have seen a similar pattern with company knowledge bases: the AI layer is useful, but without structure, permissions, and context control, it gets messy fast. For dev orchestration, I imagine the same thing applies: the queue and state machine matter more than the model. Curious if you are planning to keep the orchestrator inside GitHub, or as a separate layer that reads/writes to GitHub Issues.

I run a document automation startup. We help automate complex enterprise processes, mainly in financial services such as banking, insurance, and asset management. From our experience, one of the most painful manual processes is managing documents between different departments and clients.