DEV Community: Niclas

Teaching an AI Coding Agent to Review Its Own Work with Code Meridian

Niclas — Fri, 19 Jun 2026 08:31:38 +0000

Here I am refactoring:

Feedback from evaluation:

Suggestion for improving the tool:

Code Meridian is an open-source context tool for AI coding agents. It indexes a project into a graph so agents can reason about relationships in the codebase instead of only reading isolated files.

https://github.com/Driftya/code-meridian

Learn more:
https://driftya.com/content/how-codemeridian-helps-me-work-on-driftya

I updated CodeMeridian’s positioning: local graph memory for AI coding agents. It indexes your repo into Neo4j and exposes precise context through MCP, helping agents understand what matters before editing.

Niclas — Wed, 10 Jun 2026 13:59:09 +0000

CodeMeridian: Giving AI Coding Agents a Project Map Before They Edit

Niclas — Tue, 09 Jun 2026 09:58:20 +0000

AI coding agents feel sharp when a project is small.

They can scan a few files, understand the shape, and make useful changes. In that phase, the project still fits inside the agent’s short-term memory. The architecture is obvious. The dangerous files are nearby. The blast radius is small.

But something changes when a project reaches MVP size.

The agent still sounds confident, but it starts guessing.

It finds a nearby file and assumes it is the right one.
It trusts stale documentation.
It misses hidden callers.
It forgets architecture boundaries.
It edits something that was not really part of the task.

I kept running into that problem while building larger projects.

Source-level guardrails help. A CONTRIBUTING.md, AGENTS.md, or project instruction file can tell the agent how to behave.

But those are still instructions.

They are not facts.

That is where the idea for CodeMeridian came from.

What CodeMeridian is

CodeMeridian is a local code knowledge graph for AI coding tools.

It indexes a codebase into Neo4j and exposes that graph through MCP, so tools like GitHub Copilot, Claude Code, Codex-style agents, or other MCP-compatible clients can ask better questions before editing.

The basic idea is:

The assistant is the AI.
CodeMeridian is the project map.

It does not replace the coding assistant. It gives the assistant a structured way to ask about the codebase.

Examples:

What calls this method?
What tests cover this area?
What files are likely in scope for this feature?
Is the graph stale before I trust it?
How is this frontend component connected to backend code?

Why a graph?

Code is already a graph.

Methods call methods.
Classes implement interfaces.
Tests cover production paths.
Frontend components call API clients.
API handlers touch services.
Services use repositories.
Docs mention symbols.
Projects depend on other projects.

A normal file search can find text.

A graph can answer relationship questions.

That matters because many AI coding mistakes are relationship mistakes.

The agent edits a method but misses its callers.
It changes an interface without checking implementations.
It deletes code that looks unused but is actually an entry point.
It trusts documentation that no longer matches the code.

CodeMeridian tries to make those relationships visible before the edit happens.

A red line before the agent touches the code.

What it currently indexes

CodeMeridian currently supports:

C# through a Roslyn-based indexer
TypeScript / TSX through a frontend indexer
README and documentation files
diagnostics
optional embeddings for semantic similarity

The graph is stored locally in Neo4j.

There is no CodeMeridian cloud service.

No LLM API key is required for CodeMeridian itself. The AI assistant you use may have its own requirements, but the knowledge graph belongs to you.

What the MCP tools can do

The current toolset is focused on helping an agent understand impact, context, and risk.

Some examples:

find_impact

Finds callers and transitive dependents before changing something.

build_minimal_context

Builds a bounded context pack for a target node, including callers, callees, likely files, tests, coverage gaps, token estimate, and model guidance.

find_implementation_surface

Ranks the files, classes, and methods most likely to be relevant for a feature goal.

check_graph_freshness

Reports whether the indexed graph looks trustworthy enough for exact implementation work.

find_graph_drift

Checks if the graph may be stale and whether re-indexing is recommended.

find_stale_knowledge

Looks for stale docs, unresolved mentions, orphaned concepts, and code references that no longer resolve.

The goal is not to flood the agent with more text.

The goal is to return the smallest useful architecture slice.

The workflow I want

The ideal workflow looks something like this:

Use CodeMeridian before editing.
Goal:
Add unread reply notifications.
Steps:

Find the likely implementation surface.
Resolve exact symbols where possible.
Check graph freshness.
Build a minimal context pack.
Identify related tests.
Make the smallest safe change.
Verify with tests.

That is very different from:

Search around and hope the right files are nearby.

The first workflow gives the agent a map.

The second gives it a flashlight and a haunted repo.

Why local-first matters

For this kind of tool, I wanted the graph to be local.

The code structure, documentation, diagnostics, and remembered project knowledge should not need to live in someone else’s hosted service.

Neo4j runs locally.
The MCP server runs locally.
The indexer runs locally.

If you use a hosted assistant, that assistant still has its own data handling rules. But CodeMeridian itself is not a cloud knowledge store.

What this is not

CodeMeridian is not an AI model.

It is not a replacement for tests.

It is not a replacement for code review.

It is not magic.

It is a project memory layer for AI-assisted coding.

The agent can still make mistakes. But with a graph, at least it can ask better questions first.

Where I want to take it next

The current version is early but usable.

The next improvements I am thinking about are more workflow-focused:

better usage prompts
troubleshooting docs
a small UI for reviewing frontend/backend link suggestions
background graph enrichment
test shield summaries
change-session memory
better Docker image publishing and install flow

One feature I am especially interested in is a manual relationship workbench:

The indexer could suggest possible frontend-to-backend links, such as:

CreateNoteForm.tsx -> POST /api/notes -> NoteEndpoints.CreateAsync

Then a developer could confirm or reject those links in a small UI.

That would turn CodeMeridian from a passive index into a curated system map.

Repo

The project is here:

Driftya / code-meridian

A persistent code knowledge graph that gives GitHub Copilot a grounded, structural understanding of your codebase. It acts as the deterministic context layer — so Copilot doesn't drift or forget your architecture when working on large projects.

CodeMeridian

CodeMeridian is a persistent code knowledge graph for AI coding tools. It indexes your codebase into Neo4j and exposes that structure through MCP, so GitHub Copilot, Codex, Claude Code, and other MCP-compatible clients can ask precise questions before editing instead of guessing from open files.

It is built to be the deterministic context layer for large codebases: callers, dependencies, tests, documentation, hotspots, dead code, and cross-project relationships stay available across sessions.

No LLM API key required. The assistant is the AI; CodeMeridian is the knowledge engine.

Why CodeMeridian?

Copilot can still read files beyond what is already open, but it has to spend context to discover them and the relationships do not persist. CodeMeridian makes that discovery explicit, cheaper, and reusable.

The graph is yours. CodeMeridian stores indexed code structure, documentation, diagnostics, and remembered project knowledge in your Neo4j instance. Nothing is sent to a CodeMeridian cloud service. If…

View on GitHub

Designing respectful notifications in a social platform.

Niclas — Tue, 03 Mar 2026 15:36:33 +0000

Most social platforms treat notifications as engagement drivers. The more you return, the better it is for the system. Notifications become a lever to pull people back in, often regardless of whether they have shown recent activity.

Questioning that assumption while building a small social platform. If a user has not interacted with the app in days or weeks, does it really make sense to keep sending notifications? At some point, reminders stop being helpful and start feeling like spam.

The idea I settled on was simple: notifications should respond to user activity, not just system events.

Instead of sending a notification for every qualifying action, the system allows only one notification per user activity window. If the user has already received a notification but has not returned to the platform, additional notifications are suppressed. In other words, inactivity acts as a natural brake.

Technically, this is implemented using Redis as a persistent cache layer. When a notification is sent, a suppression key is written with a configurable expiration time. As long as that key exists, further notifications of that type are not delivered. If the user returns and interacts with the platform, the key can be cleared or reset. If they remain inactive, the suppression window eventually expires on its own.

The expiration time is configurable per notification type. Some events are more time-sensitive than others, and the system allows different reset periods. In my current setup, the default window is seven days, but this can be adjusted without changing the core logic.

This approach does introduce tradeoffs. A user who cares but checks the platform infrequently might miss intermediate updates. However, the design assumption is that meaningful engagement should restart when the user actively returns. Notifications are not meant to accumulate in the background; they are meant to signal something new once the user has shown interest again.

The broader goal is to make notifications feel respectful. Instead of optimizing for frequency or return rate, the system optimizes for restraint. If someone is inactive, the platform should not keep tapping them on the shoulder.

Designing notifications this way shifts the focus slightly. It moves away from maximizing engagement and toward minimizing unnecessary interruption. It is a small change technically, but it significantly changes the tone of the product.

I am still refining the definition of “inactive” and exploring edge cases where suppression might hide something important. But the core principle remains the same: activity should trigger notifications, not the absence of it.

How important is Web Accessibility?

Niclas — Sun, 15 Feb 2026 01:06:13 +0000

Since I learned web programming I always thought just like security is somethings we should never skip I also think of web accessibility in the same regards for public sites but I also try to always implement it on internal tools as well.

I am using this great tool from WAVE Web Accessibility Evaluation Tools (https://wave.webaim.org/), does anyone else use it? I wonder if there are any alternatives that is better.

IndexNow: Struggle with implementation (C#)

Niclas — Thu, 12 Feb 2026 16:12:37 +0000

Some days ago I have been struggling with implementing IndexNow, I did almost exactly as mentioned here in this tutorial https://www.bing.com/indexnow/getstarted#implementation, but it did not work.

The payload was correct and the data and the endpoint was right but I got bad request, I had no clue what to fix.

The error:

{\"code\":\"InvalidRequestParameters\",\"message\":\"Given request parameters are null or invalid\"}

After finding https://stackoverflow.com/questions/72629964/given-request-parameters-are-null-or-invalid-when-using-curl-to-submit-urls-wi on stackoverflow I changed endpoint to "https://www.bing.com/IndexNow" I finally found the cause.

IndexNow submission failed with status LengthRequired.

The whole issue has been the http version all along which I never thought of as I have never had any reasons before to set that manually.

The solution to fix the issue:

            var request = new HttpRequestMessage(HttpMethod.Post, endpoint)
            {
                Version = HttpVersion.Version11,
                VersionPolicy = HttpVersionPolicy.RequestVersionExact,
                Content = new StringContent(
                    JsonSerializer.Serialize(payload, JsonSerializerOptions.Web),
                    Encoding.UTF8,
                    "application/json")
            };

I hope it help someone who may struggle with the same issue.
A small note, the correct endpoint is https://api.indexnow.org/indexnow.

Remember what you vibe?

Niclas — Tue, 03 Feb 2026 07:43:00 +0000

Hello,

I recently started vibe coding and yes the output is fast but I feel personally the long term memory for knowing your project is declining.

When I did commit and pullrequests I read the code and understand what it did and if it required any changes, but in long term I needed to go back again to remember the details.

Writing my code myself it was much easier to remember the details. So how did I solve it?

What I did, first make sure the agent follow the SOLID principle and KISS as much as possible, iterate over the code and extract all methods as much as possible (A lesson from Uncle Bob). Then I writes unit test myself, this make me remember the code much better when doing vibe coding.

I am curious on how you solved it. Any Ideas?

Reasonable security baseline for self-hosted services 2026?

Niclas — Sun, 01 Feb 2026 01:06:05 +0000

Running a hobby project on a self-hosted server and wanted a quick sanity check on whether this counts as a reasonable minimum security baseline in 2026.

High-level setup:

Linux host
Dockerized services
Only 80/443 exposed publicly
Reverse proxy terminating TLS (HTTPS enforced)
ASP.NET (.NET 10) with built-in Identity + OAuth
EF Core/ORM only (no raw SQL)
auto-encoding, no user HTML rendering
Basic security headers (CSP, HSTS, nosniff, referrer, permissions)
Host firewall enabled (default deny incoming)
Regular security updates (OS + container rebuilds, unattended upgrades)
Rate limiting policies

This isn’t meant to be enterprise-grade, just sensible for a hobby app.
Does this sound like a reasonable baseline?

Any common blind spots people usually miss at this stage (ops, maintenance, or process-wise)?

Vibe coding before writing code?

Niclas — Fri, 30 Jan 2026 11:32:55 +0000

Before I wrote much code on my current project, I wrote documents.

The idea started after some frustration with social media. I spent time comparing different platforms and noticed how similar they all felt in practice. Most of them optimize for quick reactions and passive engagement. I kept wondering what kind of interaction would actually feel satisfying to respond to, where the creator might genuinely care about the reply, and where responding felt better than just clicking a like.

I gave the idea space by discussing it back and forth with different AI models. Over time this turned into a large, unstructured dataset of thoughts, constraints, and possibilities. Instead of trying to code from that directly, I treated it as raw material that needed processing.

Before doing that processing, I focused on orientation. As a programmer, what felt important to me was defining a Table of Contents in a README, writing a CONTRIBUTING guide, and creating an Agent.md file as an explicit entry point for prompting and discussion. These weren’t meant to lock decisions, but to give the project a shared mental baseline, even if that baseline was only for myself.

I wrote down best practices, architectural boundaries, coding rules, and style decisions as early constraints. I then refined those documents iteratively, again using AI models, before moving deeper into implementation.

These were the first steps I took before I could really start building.
I’m curious how others approach this phase. Do you do something similar, or are there other practices you’ve found useful early on?