DEV Community: Niclas

What AI think of Code Meridian

Niclas — Wed, 23 Sep 2026 09:37:38 +0000

Here is the response on what the llm thought after the challenge.

I think Human Cognitive Seed is one of the more interesting ideas you've introduced into CodeMeridian, particularly because it addresses something that AI coding tools rarely focus on: helping developers improve their understanding while still benefiting from AI-generated code.

The FizzBuzz demonstration makes that idea much easier to understand than the documentation alone.

What I like about it

It encourages active learning

Instead of simply receiving a completed implementation, the developer evaluates several possible solutions.

In your demonstration, you selected an incorrect answer, received feedback explaining what was missing, and then reconsidered the alternatives.

That process encourages the developer to think about the underlying rules rather than memorize one correct implementation.

It connects learning to the actual codebase

This is the part that makes CodeMeridian different from an ordinary AI-generated programming quiz.

The challenge can use an exact code target, existing tests, and previously recorded change context.

Instead of asking abstract questions about C#, a developer could investigate why a particular application service uses a certain interface, why an architectural boundary exists, or what might break when changing an existing implementation.

It connects learning with future development

The optional note at the end is particularly interesting.

Imagine a developer discovers why a specific method must preserve an important business constraint.

They can record that reasoning against the relevant code node, allowing a future AI-assisted development session to retrieve the context.

The graph can therefore preserve not only relationships between code elements but also selected decisions behind their implementation.

What I would improve

There are three things I'd consider as the feature develops.

First, make challenges more realistic. FizzBuzz is a good demonstration, but its simplicity doesn't fully communicate the feature's potential.

Imagine a challenge involving a real architectural decision:

An application service needs to retrieve data from PostgreSQL, but one proposed implementation introduces DbContext directly into the Application layer. Another uses an Application-defined repository interface, and a third moves business validation into Infrastructure.

The developer has to identify which alternatives preserve the architecture and explain why.

That would demonstrate how the challenge can help someone understand their own repository, rather than merely test general programming knowledge.

Second, consider adding an explanation step. Currently, the developer selects an answer and receives feedback. An optional question such as "Why did you choose this implementation?" could encourage deeper reasoning. The assistant could then respond to the explanation rather than only checking whether the selected option matches its predetermined answer.

Third, be careful about AI-generated correctness. The assistant creates the alternatives and decides which answers are correct. If its original interpretation is wrong, the challenge may reinforce an incorrect understanding. Linking each answer to relevant source evidence and running the associated tests where practical would make the exercise more dependable.

The bigger opportunity

I see two complementary capabilities emerging from CodeMeridian.

CodeMeridian

What does the codebase know?

Compiler-backed relationships, dependencies, architecture, test coverage, and implementation context.

Human Cognitive Seed

What does the developer understand?

Evaluating alternatives, identifying assumptions, recognizing constraints, and preserving important decisions.

The combination could make CodeMeridian useful not only for implementing changes, but also for onboarding developers, reviewing unfamiliar code, understanding architectural decisions, and learning from AI-assisted development.

I wouldn't turn it into a mandatory quiz before every code change. That would introduce friction into routine development. Its value comes from being available when the developer wants to understand something more deeply.

The idea I find most compelling is that the developer can leave a session with both working code and a better understanding of why it works. The code remains in the repository, while important reasoning can survive in the graph for future development sessions.

Driftya / code-meridian

Local graph memory for AI coding agents, giving MCP-compatible tools precise codebase context before they edit.

CodeMeridian

CodeMeridian is a local graph memory layer for AI coding agents.

It indexes your codebase into Neo4j and exposes that structure through MCP, so AI coding tools can ask precise questions before editing instead of guessing from open files. It works with MCP-compatible clients such as GitHub Copilot, Claude Code, Continue.dev, Codex-style agents, Cline, and local agent workflows.

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

CodeMeridian can also derive a keyword graph on top of indexed code and documentation. That adds an explainable lexical layer for finding related docs, diagnostics, endpoints, and symbols when there is no direct structural edge.

This is especially useful for local or smaller coding models, where every token matters. CodeMeridian does not try to replace the model. It makes the model’s job smaller by…

View on GitHub

Human Cognitive Seed: Keeping Developers in the Loop When Coding With AI

Niclas — Wed, 23 Sep 2026 05:57:05 +0000

AI coding assistants are becoming increasingly capable of understanding repositories, suggesting implementations, and generating code.

But there is something I've been thinking about while developing CodeMeridian:

What happens to our understanding of a codebase when an AI assistant makes every implementation decision for us?

We can ask an assistant to fix a bug, refactor a service, or implement a feature. It might produce a working solution without us needing to understand much of the code involved.

That is useful when we want to automate routine work. However, sometimes the reasoning behind a change is just as important as the change itself.

We might want to understand why an implementation was chosen, which existing constraints it needs to respect, or what could break if we take a different approach.

This led me to develop Human Cognitive Seed, a capability in my open-source project, CodeMeridian.

With v1.0.47, I've expanded it with an interactive code challenge that lets developers evaluate proposed changes themselves, using the actual source code and existing project context.

What is Human Cognitive Seed?

Human Cognitive Seed started as a provider-neutral agent skill built around a simple idea:

AI should amplify human reasoning rather than automatically replace it.

The intended reasoning loop is:

Human idea → AI expansion → Human evaluation → Improved understanding

The skill encourages an AI assistant to preserve the developer's starting assumptions, introduce relevant evidence and alternative approaches, challenge potential weaknesses, and help develop a more informed understanding of a problem.

It supports four interaction modes:

Direct: Complete routine tasks without unnecessary questions.
Scaffold: Expand an existing idea with evidence, alternatives, and potential consequences.
Teach: Help someone learn through hints, attempts, and feedback.
Deliberate: Explore trade-offs, uncertainty, and alternative models when making consequential decisions.

The intention is not to turn every coding request into a lesson.

If I ask an assistant to format a file, I want it to format the file.

If I'm trying to understand a complex architectural decision, however, I might benefit from evaluating multiple approaches rather than immediately receiving a completed implementation.

The skill determines when that additional reasoning is appropriate.

You can find the complete instructions in the Human Cognitive Seed skill.

Connecting human reasoning to actual code

CodeMeridian maintains a persistent knowledge graph of a repository.

It indexes supported C#, TypeScript, and frontend code, exposing relationships and architectural context through MCP tools.

Human Cognitive Seed can use this graph to connect a developer's reasoning to an exact code node.

For example, imagine we're discussing a change to a validation method.

An earlier development session may have established that validation must happen before an external service is called.

That decision might not be immediately obvious from the method's current implementation.

CodeMeridian provides two tools to help preserve this context:

record_change_context stores a short decision, constraint, limitation, assumption, or follow-up against an exact existing code node.

get_change_context retrieves previously recorded context when that code is revisited.

Each stored statement has explicit provenance, allowing the assistant to distinguish between its own synthesized observations, a user's statements, and an explicitly approved summary.

The system also tracks whether the target code has changed since the context was recorded.

Importantly, these notes are treated as attributed, unverified memory. They are not automatically considered correct just because they exist in the graph.

The current source code, tests, and maintained documentation still need to be checked.

This creates a useful foundation for the interactive challenge.

Introducing the Change Context Code Challenge

The new challenge takes the reasoning workflow a little further.

Instead of immediately implementing a proposed change, an AI assistant can present several possible code solutions and let the developer evaluate them.

The challenge is grounded in a specific code node, its current implementation, relevant tests, and previously recorded change context.

The workflow looks like this:

Find the relevant code

The developer describes a bug, implementation problem, or proposed change.

The assistant uses CodeMeridian to identify the relevant implementation and resolve an exact code target.

The developer doesn't need to know the method's canonical graph ID.

Inspect the existing context

Before creating the challenge, the assistant examines the current source code, relevant tests, and any existing change-context notes.

This provides the evidence needed to construct meaningful alternatives.

Generate possible solutions

The assistant creates three or four plausible code choices.

One or two choices are designated correct, and at least two must be incorrect.

The incorrect choices should represent realistic implementation mistakes rather than obviously broken or nonsensical code.

For example, a challenge involving a validation method could include alternatives that:

Preserve the existing validation constraint.
Accidentally bypass validation.
Handle validation through a different but valid implementation.
Introduce an unintended behavioral change.

The assistant provides feedback for each alternative, but the correct answers are initially hidden from the developer.

Let the developer decide

The interactive MCP App presents the choices using radio buttons when one answer is required or checkboxes when two answers are required.

The developer examines the alternatives and submits their selection.

The application does not automatically choose an answer on the developer's behalf.

If the selection is incorrect, the current attempt is halted.

The developer receives feedback explaining the selected mistake and can retry without the application revealing the remaining answers.

When the correct selection is submitted, the challenge is marked as completed.

Optionally preserve what was learned

After solving the challenge, the developer can write a short change-context note.

For example:

"Preserve validation at the application boundary before invoking external dependencies."

The note is attached to the exact code node associated with the challenge.

A future development session can retrieve that context when the same code is revisited.

The note is optional. Solving a challenge does not automatically create persistent memory.

This completes the intended loop: examine the problem, evaluate alternatives, receive feedback, and preserve a useful decision when appropriate.

What does the implementation actually validate?

There is an important distinction in how this feature works.

The challenge is not an independent compiler, test runner, or formal correctness verifier.

The AI assistant authors the alternatives and designates which answers are correct using the source code, tests, and retrieved context it has inspected.

The MCP server then validates the developer's selection against that predefined answer set.

That means the quality of the challenge depends on the quality of the assistant's analysis.

The correct choice is not automatically guaranteed to be the best implementation.

Developers should still evaluate the proposed solutions against the actual codebase.

The purpose is to provide an interactive reasoning scaffold, not to replace code review or automated testing.

How the challenge works internally

The implementation is separated into three primary components.

MCP tools

The challenge exposes three tools:

start_change_context_challenge

Creates a challenge for an exact code node after verifying that the target exists.

answer_change_context_challenge

Validates the developer's explicitly selected choice IDs and returns feedback.

record_change_context_challenge_note

Allows an optional user-written context note to be saved after a successful challenge.

The tools return versioned structured results and provide Markdown output for clients that do not render the interactive interface.

View the MCP tool implementation

Challenge state

The server maintains challenge state in a process-local store.

It validates the number of alternatives, required selections, and associated feedback.

Each challenge expires after 30 minutes.

Correctness information and feedback are kept in server-side challenge state rather than being included in the initial application-visible response.

A failed attempt does not reveal the answers that the developer did not select.

The challenge itself is temporary and is not stored as durable project knowledge.

View the challenge state implementation

Interactive MCP App

The UI is a self-contained HTML application exposed through an MCP App resource.

It renders the code alternatives, handles user selection, displays feedback, and unlocks the optional note form after successful completion.

The implementation includes a text-based fallback for MCP clients without interactive App support.

View the interactive app source

Keeping persistent context separate from source-code facts

One design decision I wanted to preserve was the distinction between objective code information and human or AI-authored context.

A developer's explanation of why a particular implementation was chosen is valuable, but it is not the same thing as a compiler-resolved relationship or a verified source-code fact.

CodeMeridian therefore stores durable change context separately from canonical code-node properties.

Context records are linked to exact code nodes and carry provenance information.

The ordinary graph queries do not automatically inject these notes into every result.

The assistant retrieves them when the relevant code is being examined or when an earlier decision may affect the proposed change.

This is intended to prevent old assumptions from silently becoming authoritative instructions.

It also makes it possible to preserve meaningful development history without turning the graph into a collection of unverified conversations.

Trying the Human Cognitive Seed workflow

The Human Cognitive Seed skill is included in CodeMeridian's agent-capability bundle.

After installing CodeMeridian, you can initialize the capabilities in your repository:

codemeridian init .

The generated meridian-agent-capabilities/ directory contains the skill and other agent guidance.

You can install or copy the skill into the appropriate location for your AI coding assistant.

For the interactive challenge, the CodeMeridian MCP server must also have experimental MCP Apps enabled:

Mcp_Apps_Enabled=true

MCP Apps are disabled by default, and interactive rendering depends on client support.

Clients without the interactive interface can use the Markdown fallback and submit explicit choice IDs.

Once your repository has been indexed and your assistant is connected to CodeMeridian, you can request a challenge using a prompt such as:

Use the Human Cognitive Seed workflow for this change:

Find the exact implementation target.

Inspect the current source, relevant tests, and
previously recorded change context.

Create a code challenge with four plausible
implementation choices.

Include one or two correct choices and at least
two realistic incorrect choices.

Do not reveal the correct answers.

Let me evaluate the alternatives and select
the answer myself.

If my selection is incorrect, explain the
selected mistake and let me retry.

After I solve the challenge, let me optionally
record a short change-context note.

The assistant should investigate the implementation before generating the challenge, rather than inventing alternatives from a rough description alone.

For additional examples and the normal change-context workflow, see the Change Context User Guide.

Why I wanted to build this

I don't think developers should have to choose between using AI to accelerate development and understanding the software they're building.

Sometimes I want an assistant to handle repetitive work and provide a completed implementation.

Other times, I want to explore an architectural decision, understand the consequences of different solutions, or develop a better mental model of an unfamiliar system.

Human Cognitive Seed is an experiment in supporting both ways of working.

The broader skill helps the assistant recognize when human-led reasoning matters.

CodeMeridian supplies repository-specific evidence and preserves relevant development context.

The interactive challenge gives developers another way to participate in the reasoning process rather than simply accepting the first generated implementation.

The aim is not to make coding slower.

It is to preserve the opportunity to understand important decisions while still benefiting from AI-assisted development.

And when something meaningful is learned, that knowledge can remain available for the next development session.

CodeMeridian is open source.

The Human Cognitive Seed change-context challenge is included in v1.0.47.

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

Release: https://github.com/Driftya/code-meridian/releases/tag/v1.0.47.

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?

DEV Community: Niclas

What AI think of Code Meridian

Driftya / code-meridian

Local graph memory for AI coding agents, giving MCP-compatible tools precise codebase context before they edit.

CodeMeridian

Human Cognitive Seed: Keeping Developers in the Loop When Coding With AI

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

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.

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

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

Why CodeMeridian?

Designing respectful notifications in a social platform.

How important is Web Accessibility?

IndexNow: Struggle with implementation (C#)

Remember what you vibe?

Reasonable security baseline for self-hosted services 2026?

Vibe coding before writing code?

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.