DEV Community: Jens Reynders

The meta-repo as AI multiplier

Jens Reynders — Mon, 27 Jul 2026 11:50:58 +0000

When I introduced the meta-repo to the team, the goal was a true agentic coding setup: a shared doc set, shared skills, shared rules, all loaded automatically no matter which platform repo you had open. Onboarding got easier and setup went from three commands to one as a side effect of that.

Several months later, that's still true — structuring a codebase for AI context turns out to be a different problem than structuring it for human developers.

This isn't a pattern we roll out on every project. It's what this specific project needed, given a constraint most codebases don't have: three mature repos that couldn't be merged into one.

The setup

The platform I work on has three repos: shared Kotlin Multiplatform code, an iOS presentation layer, an Android presentation layer. They were set up 4–5 years ago, well before AI assistants were part of anyone's toolchain. Three separate git histories, three separate CI pipelines, three sets of conventions. That's just how multi-platform mobile worked on this project — it's not a universal N5 setup, just how this particular client's codebase evolved.

When AI coding tools became serious, the obvious answer would have been a monorepo. One folder, full context, done. We raised it. The client team pushed back. Reasonable objections: independent release cycles, existing CI setup, git history. Migrating three mature repos into a monorepo isn't a weekend project, and it wasn't worth the disruption.

So the meta-repo is the answer to a constraint: how do you give AI assistants full cross-platform context without moving everyone to a monorepo?

It sits on top of the three platform repos. It contains no app code. What it contains is three things: a .ai/ directory with shared skills and agents, a docs/ folder with shared architecture knowledge, and a setup script. Via symlinks, every tool and every platform repo points back to .ai/:

meta-repo/
├── .ai/            ← single source of truth
│   └── skills/
├── docs/           ← shared architecture docs, ADRs, diagrams
├── .cursor/skills  → ../.ai/skills
├── .claude/skills  → ../.ai/skills
│
├── ios-app/
│   └── .claude/skills → ../../.ai/skills
├── android-app/
│   └── .claude/skills → ../../.ai/skills
└── shared-kmp/
    └── .claude/skills → ../../.ai/skills

Skills

Skills are multi-step workflows encoded as files. Some are basic and used daily by everyone — commit, which writes a properly formatted commit message from the staged diff, branch, which creates a new branch following our naming convention, worktree, which sets up a git worktree for parallel work on a ticket. Others are heavier — multi-platform-search, which runs parallel agents against iOS, Android, and KMP simultaneously, or dependency-audit, which compares pinned versions against latest across all three codebases at once. They live in .ai/skills/ and get symlinked into every tool config and every platform repo.

Write a skill once, it goes through code review like any other change, and every teammate gets it on next pull.

The scoping matters too. Engineers don't have to work from the meta-repo root. Open ios-app/ directly and you get iOS-scoped context without Android or KMP noise, useful for a focused bug fix or a platform-specific feature. Either way, the full skill library is available. An Android developer who rarely touches iOS can work entirely out of android-app/ and get a clean, platform-focused experience, with access to cross-platform skills when a ticket touches the shared layer. The scoping is intentional, not a limitation.

Documentation

docs/ serves three purposes at once: documentation for future teammates who need to understand how the system works, a record of architectural decisions so the reasoning behind past choices doesn't get lost, and direct context for agents. When a skill or agent needs to answer a question about how something works, it reads from docs/ rather than scanning the codebase from scratch every time. The documentation isn't just for humans anymore — it's fuel.

Onboarding

Before the meta-repo, getting a new developer up and running meant cloning three separate repos, finding the scattered docs, figuring out which branch conventions applied where, and hoping someone remembered to mention the CI quirks. AI context was whatever they managed to assemble themselves.

Now it's one command:

git clone <meta-repo> meta
cd meta
./setup.sh

The setup script clones the three platform repos into the right folder structure, creates all the symlinks, and verifies each one resolves correctly. It's idempotent — safe to run again if something gets out of sync. When it finishes, the developer has the full workspace: all three platform repos, the shared docs/, the skills, and the AI configuration wired up and ready.

The practical consequence is that a new engineer gets the exact same AI-assisted environment as someone who's been on the project for a year. The rules, the skills, the documented context: it's all there from day one, not something you accumulate gradually. That matters more than it might seem: the AI context is only as useful as it is consistent across the team.

What it actually unlocks

When a developer opens android-app/, the AI already knows the module structure, the branch conventions, the testing approach, the CI pipeline, the documented pitfalls, how the Android layer relates to shared KMP code. None of that gets explained in the prompt — it's loaded automatically. You just ask the question.

Here's what that makes possible, broken into three tiers:

Low-key wins — living code docs, test generation, consistent branch and commit conventions across all three platforms. These work because the rules files exist and because every teammate's AI assistant loads the same rules. No one has to remember to explain the conventions.

Medium wins — cross-platform search, contextual implementation lookup, technical approach preparation. The multi-platform-search skill runs parallel agents against iOS, Android, and KMP simultaneously. That used to take 30–60 minutes of manual repo-hopping. It now takes 2–5 minutes. This skill only exists once, in .ai/skills/, and is available in every context via the symlink chain.

Big impact — parallel implementation across multiple tickets in flight simultaneously, POC speed, bridging expertise gaps. At one point I needed to improve build times in the Kotlin/Gradle setup — not my primary area. With full project context already loaded, the AI could apply optimization knowledge I didn't have. We landed a 25% build time improvement. I wouldn't have known where to start.

Some concrete numbers from running this way for several months:

MR description writing: 15–20 min → under 2 min
Dependency audit across three codebases: half a day → 15–20 min
Jira ticket triage with written functional analysis and technical approach: 1–2 hours → 15–30 min

The compounding is real. On a typical working day I have several tickets in parallel flight: different stages, each in its own git worktree, one waiting on product clarification, one in implementation, one in review. The AI setup is consistent across all of them. Same rules, same skills, same memory of project conventions. Switching context between loops costs almost nothing because the AI doesn't need to be re-briefed.

(My colleague Mats wrote about the worktree approach in depth on the November Five engineering blog: How I stopped working in serial — Claude combined with worktrees.)

Closing thoughts

Codebases are structured for human readers: clear folder names, good naming conventions, inline comments. These help humans navigate.

AI assistants benefit from all of that, but they also need explicit, aggregated context that humans don't, because humans ask colleagues and remember from last time. A rule file that says "our testing approach for this module is X" or "don't do Y because of Z" is context a human would carry from experience. The AI needs it written down, in a place where it's loaded by default.

Treating .ai/ as a first-class directory in the codebase, something you maintain, review, and extend like any other part of the project, is the shift. Not a folder that accumulates random prompt snippets, but a structured layer you care about keeping accurate.

The meta-repo makes that layer possible across a multi-platform project without duplication. One edit to a rule propagates to every tool, every platform, every developer on next pull.

That's the multiplier. Not the prompts. The substrate.

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.