DEV Community: Jens Reynders

The vault is the memory, not the tool

Jens Reynders — Mon, 13 Jul 2026 06:27:18 +0000

An AI assistant is only as useful as what it can remember, and chat history doesn't count. Close the window and it's gone. The actual fix isn't a smarter prompt, it's giving the assistant a place to keep things: a folder of plain markdown files I own, structured on purpose, that any model can read.

I know a lot has been written about Obsidian already, this is not about that. I use it on top of the vault, not because Obsidian is special (it's a solid markdown editor with backlinks), but because the vault underneath is just files on disk, organized the way my actual job needs it to be organized.

Structure built for being a Tech Lead, not for the AI

I organize the vault loosely on PARA: projects, areas, resources, archive. The folders doing the real work exist for the files, not for the AI: meetings/ and people/ sit at the top level because leading a team needs them, and every meeting note links back to the people in it, so each person's file builds itself out of backlinks with no separate log to maintain.

50-writing/ gets the same treatment: it could have lived under areas as one more ongoing responsibility, but it runs on its own pipeline, seeds to drafts to published, and burying that a level deep would have hidden it. It earned a root folder. 00-inbox/ is the other exception, the one folder with no rule about what belongs there. A quick-capture skill drops a thought in with one line, no folder decision required in the moment, and I triage it into the right place later.

What the AI does is help me uphold that structure. When I open a 1:1 prep, it already has the last five meetings and the running context on that person, because the structure surfaces it without being asked. And when I'm not sure where something belongs, it tells me, keeping a new note from drifting into the wrong folder just because that was faster in the moment.

One file, _claude/conventions.md, documents the layout and naming rules. Every project's instructions tell the assistant to read it first. That single habit is what makes the assistant behave the same way across sessions and even across different projects: I run separate Cowork projects for Tech Lead, PDP, and Writing, each scoped to its own slice of the vault, and switching projects is switching hats.

Why not wherever the knowledge already lives

The obvious move is to plug the assistant into wherever the team already keeps things: Notion, Confluence, whatever. I tried that instinct and dropped it.

Markdown wasn't a new habit for me. I used to keep notes in Bear, plain markdown there too. Moving to a vault was the same habit with a folder on disk instead of an app's database behind it.

That's the real angle: owning something, in a format basic enough that nothing can lock it up. Notion doesn't store a page as text, it stores it as a tree of proprietary "blocks" you can only get to through Notion's app or API. Confluence does something similar. Markdown has no such lock-in, so the assistant just reads the file, no translation layer in between. Tools don't last, files do. Notion could change its API tomorrow, Claude could stop existing next year. A folder of .md files survives all of it.

It also travels. Obsidian's git plugin commits and pushes the vault on its own, so backup and version history come free, no extra service to pay for or trust. I write on a second machine sometimes, and it's a git pull away: same files, same conventions.md, same context the assistant reads first, on either machine.

Building this took a few hours: folder structure, the conventions file, one project's instructions. It paid for itself the first time the assistant nailed a task because it had read the right file instead of guessing. The side effect is a personal knowledge base that's better structured than any note system I've had before, because the assistant enforces the structure instead of letting me get lazy about it. It doesn't need Obsidian, or Cowork, or any specific tool. It needs a folder, a rulebook file, and the discipline to make the assistant read the rulebook before it does anything else.

Pushing My Own Boundaries: Using AI to Start the Day Already Briefed

Jens Reynders — Wed, 01 Jul 2026 12:57:38 +0000

The goal is to start the day already briefed — not to spend the first hour becoming briefed. What follows isn't groundbreaking. It's just what pushing my own boundaries looks like in practice.

The problem

As a Tech Lead of a larger team, my mornings used to look something like this: open email, skim through multiple newsletters I subscribed to for staying current on AI and dev topics, switch to Slack, scroll through everything I missed, try to figure out what actually needs my attention, then check what code went into the repo in the last 24 hours. By the time I was done "catching up," a good chunk of the morning was gone.

I knew there had to be a better way.

Starting with Claude Cowork

Claude's desktop app has a feature called Cowork, and within that, you can set up Scheduled tasks — automated tasks that run on a schedule. I set up two that run every morning:

Newsletter digest: This one pulls in all the newsletters I received the day before and summarizes them for me, grouped by topic — AI-related first, then dev, then everything else. Instead of opening each email and scanning for what's relevant, I get a curated briefing in seconds.

Slack summary: This gives me a full summary of yesterday's Slack conversations across channels, and more importantly, flags what actually needs my attention. No more scrolling through hundreds of messages trying to separate signal from noise.

The only downside? The Claude desktop app needs to be open and running for these to kick in. It's not a dealbreaker, but worth knowing.

I'll be honest — the idea wasn't entirely mine. When you set up a new Scheduled task in Cowork, a Daily Brief is literally the example they suggest. I just happened to already be poking around with something similar. A lucky coincidence.

Taking it a step further with Claude Code

One of the hardest parts of leading a larger team is keeping tabs on everything that changes in code. PRs get merged, features get shipped, bugs get fixed — and it's nearly impossible to review it all manually without it becoming a full-time job.

So I set up a Routine in Claude Code — that's what they call scheduled automated runs — that kicks in every weekday morning at 09:30. It runs headless, no window required. It scans the develop branches across all three of our repos, picks up everything that merged since yesterday (or since Friday on Mondays), and produces an HTML report I can open straight away.

It's not just a list of commits. It reads the actual diffs for anything non-trivial, scores complexity, flags risky patterns — broad refactors, missing tests, pre-release SDK pins landing where they shouldn't — and calls out when the same feature landed across multiple repos as a coordinated rollout. It's like having a reviewer who never sleeps and never skips a merge.

The bigger picture

None of this is Claude-specific. Most major AI platforms have some form of scheduling now — ChatGPT just launched theirs — and the rest won't be far behind.

But scheduling isn't even the most important part. The real work is building the prompt — deciding what you want surfaced, how it should be structured, what noise to filter out. Once you have that, the platform doing the running almost doesn't matter. Any agent that can read your data and write a file can produce a digest you open in a browser. Local HTML works everywhere. No dashboard, no extra subscription.

And if scheduling isn't an option where you are, just run it manually. It still takes thirty seconds. It still saves you the fifteen minutes of scrolling. The automation is convenient; the prompt is the thing.

I'm not pushing the boundaries of what's possible with AI — someone else has almost certainly done all of this and more. But I am pushing my own boundaries, and that's what matters to me.

Hi, I'm Jens

Jens Reynders — Mon, 29 Jun 2026 07:23:30 +0000

Hi, I'm Jens

I'm a cross-platform mobile engineer and Tech Lead at November Five. Day to day that means leading a team of four to six engineers and a QA, staying close to the codebase, and thinking about how we build things well — across iOS, Android, and Kotlin Multiplatform.

I've been in mobile since 2014, starting as an iOS engineer and gradually expanding from there. React Native, some frontend web, then Kotlin Multiplatform. Android isn't my native ground, but I can navigate the codebase when needed. Before that, I did a Master's in Electronics-ICT with a focus on ICT, graduating in 2013. My thesis was on machine learning — building a model to recognise sounds in a home environment. An early interest in AI, back when it was purely ML.

AI has become part of how I work: how I plan, how I write code, how I lead a team. I've been experimenting with that seriously since fall 2025, and this is where I write about it — not as finished thinking, but as a working log from someone doing it in a real context.

Outside of work: I spend time with my fiancée and our cat. I cycle, I lift, and occasionally show up to a CrossFit class. I also do photography — mostly landscapes, the kind that require a hike to get to.

That's the short version. The rest is in the posts.