DEV Community: Amariah Kamau

Build an AI Agent That Actually Understands Your Codebase (Without Switching Editors)

Amariah Kamau — Mon, 18 May 2026 13:04:51 +0000

I use Neovim. I'm not switching.

But I also want an agent that can refactor across 50 files, run tests, debug failures, and come back with a working PR — not just suggest the next line.

The problem: every AI coding tool that does serious agentic work wants to be your editor. Cursor, Windsurf, GitHub Copilot Workspace — all VS Code. If you use anything else, you're a second-class citizen.

So I built something different. An agent that has its own workspace beside my editor, not inside it. I stay in Neovim. The agent gets a live map of the codebase, a terminal, file tools, and an approval queue.

This post walks through how it works, how to set it up, and what it actually looks like in practice.

The Core Problem with Raw Code Injection

Before getting into the setup, it's worth understanding why most agents struggle with large codebases.

The standard approach is to dump files into the context window:

Here is your codebase:
[file 1 - 500 lines]
[file 2 - 800 lines]
[file 3 - 1200 lines]
...

This works at small scale. At 20+ files it starts to break down. The model spends most of its reasoning budget reconstructing architecture from raw text instead of actually solving the problem.

The better approach: give the agent a structured map of the codebase and let it query specific parts on demand. Think of it like the difference between handing someone a stack of printed pages vs giving them a searchable database with a good schema.

That's the core idea behind Atlarix's Live Code Map — your repo gets parsed into a node/edge graph that the agent navigates instead of reading raw files linearly.

Setup

1. Download and Install

Grab the installer from atlarix.dev.

macOS: .dmg, notarized, installs to Applications
Linux: .AppImage (auto-updates), .deb, or .rpm
Windows: unsigned .exe (code signing coming)

2. Install the CLI

Open Atlarix → Settings → General → Install CLI.

This drops an atlarix binary into your PATH. After that:

# Open current directory as a workspace
atlarix .

# Open a specific path
atlarix ~/projects/my-api

Same muscle memory as code .. Atlarix opens in the background, your terminal returns immediately.

3. Connect a Model

Go to Settings → AI. You have two options:

BYOK (Bring Your Own Key) — paste in an API key for any of the supported providers:

OpenAI, Anthropic, Google Gemini, Groq, Together AI,
Mistral, xAI, OpenRouter, AWS Bedrock

Local models via Ollama or LM Studio — set the base URL and pick your model. No API key needed. Works on the free Solo tier.

Ollama base URL: http://localhost:11434
Model: qwen2.5-coder:7b

For local models I've had good results with qwen2.5-coder:7b and deepseek-coder-v2:16b on an M2 MacBook. The structured context from the code map means you don't need a massive model to get useful results.

Model Bridge (managed) — Atlarix's own managed tier (Speed/Standard/Deep) if you don't want to manage keys. Speed tier is included in the free Solo plan.

Opening a Workspace

cd ~/projects/my-saas-api
atlarix .

Atlarix opens and loads your workspace. The first thing it does is a lightweight repo scan via git ls-files — fast, respects your .gitignore, and doesn't run any heavy parsing upfront.

The Live Code Map is built on-demand when the agent first calls get_blueprint. You can also trigger it manually from the Blueprint tab in the right panel.

For a 500-file TypeScript repo, the initial parse takes 3–5 seconds. After that it's cached and incremental.

Your First Agent Task

Let's say I want to add rate limiting to my auth routes. Here's what that actually looks like.

Step 1: Start in Explore Mode

Pick Explore from the mode selector. This is read-only — the agent can query the code map, read files, and search, but can't write anything. Good for orientation.

Me: Map the auth flow. Where does a login request go from the 
    route handler to the database?

The agent calls get_blueprint to pull the architectural graph, then navigates from the auth route to the middleware stack to the database layer. It comes back with a precise answer and which files are involved — without reading every file in the codebase.

Step 2: Switch to Plan Mode

Now switch to Plan mode. The agent can now draft a plan but still can't execute writes.

Me: I want to add rate limiting to the login and registration 
    routes. Use express-rate-limit. Failed attempts should be 
    tracked by IP. After 5 failures in 10 minutes, lock out 
    for 30 minutes.

The agent knows the architecture from the previous explore session. It drafts a step-by-step plan:

Plan: Add rate limiting to auth routes

[ ] Install express-rate-limit
[ ] Create rate limiter config in src/middleware/rateLimiter.ts
[ ] Apply limiter to POST /auth/login in src/routes/auth.ts
[ ] Apply limiter to POST /auth/register in src/routes/auth.ts
[ ] Add error response handler for 429 status
[ ] Update integration tests in tests/auth.test.ts

Review the plan. If it looks right, switch to Build mode.

Step 3: Build — Approval Queue in Action

In Build mode, the agent starts executing. For every file write, you get an approval prompt:

Write: src/middleware/rateLimiter.ts

+ import rateLimit from 'express-rate-limit';
+
+ export const loginRateLimiter = rateLimit({
+   windowMs: 10 * 60 * 1000, // 10 minutes
+   max: 5,
+   message: { error: 'Too many login attempts. Try again later.' },
+   standardHeaders: true,
+   legacyHeaders: false,
+ });
+
+ export const registerRateLimiter = rateLimit({
+   windowMs: 60 * 60 * 1000, // 1 hour
+   max: 3,
+   message: { error: 'Too many registration attempts.' },
+   standardHeaders: true,
+   legacyHeaders: false,
+ });

[Approve] [Reject]

You approve. The file gets written. The agent continues through the plan.

For terminal commands:

Terminal: npm install express-rate-limit

[Approve] [Reject]

You approve. It runs, shows you the output, continues.

This isn't friction — it's the same review cycle as a PR, but live. You're watching the work happen and approving as it goes rather than reviewing after the fact.

Step 4: Review in Your Editor

The agent writes the files. You review them in Neovim, VS Code, IntelliJ, or wherever. The agent doesn't care what you're using to review — it just cares about the approval queue.

# Meanwhile in my terminal
nvim src/middleware/rateLimiter.ts
# Looks good, approve the rest in Atlarix

Step 5: Tests

If the agent runs tests as part of the plan and they fail, it reads the failure output and iterates. Self-correction is built in — up to a configurable number of retry attempts before it stops and asks you what to do.

Test run: npm test
FAIL tests/auth.test.ts
  ● Auth › POST /login › should return 429 after 5 attempts
    Expected: 429
    Received: 200

Diagnosing failure...

It reads the test, traces the failure to a missing @types/express-rate-limit dev dependency, installs it, re-runs. Pass.

Modes Reference

Mode	What the agent can do
Explore	Read files, query code map, search, web search. No writes.
Plan	Everything in Explore + draft plans, create `.atlarix/ATLARIX_PLAN.md`
Build	Full tool access — file writes, terminal, tests, MCP calls
Fix	Focused on diagnosing and fixing specific errors
Review	Read-only analysis, code quality feedback, architectural suggestions

You can switch modes mid-session. The agent's context persists across the switch.

What Works Well With Local Models

If you're running Ollama, here's what I've found works well and what doesn't:

Works great:

Explore mode — querying the code map, finding files, understanding architecture. Even a 7B model does this well when it has the graph.
Simple, scoped Build tasks — "add a field to this schema and update the related API endpoint"
Fix mode — diagnosing TypeScript errors with LSP output injected into context

Works better with larger models:

Multi-step autonomous plans across many files
Complex refactors with non-obvious dependency chains
Tasks that require reasoning about edge cases and side effects

The practical threshold I've found: for anything touching more than 10 files or involving significant architectural decisions, I switch from my local 7B to a Standard tier cloud model. For everything else, local is fast and free.

Tips

Use .atlarix/ATLARIX.md for persistent context. This file gets injected into every session for this workspace. Put your tech stack, conventions, and any context the agent should always know.

# Project Context

Stack: Node.js, Express, TypeScript, PostgreSQL, Prisma
Auth: JWT with refresh tokens, stored in httpOnly cookies
Testing: Jest + Supertest
Conventions: 
- All database queries go through service layer, never directly in routes
- Error handling via custom AppError class in src/lib/errors.ts

Start tasks in Explore mode. Even for tasks you think are simple, a quick explore turn first means the agent navigates correctly from the start rather than making wrong assumptions.

Reject and explain, don't just reject. When you reject an approval queue item, add a reason. The agent uses it to replan. "Reject — use the existing AppError class for error handling, not a raw throw" gets you a better next attempt than a silent reject.

Check the Blueprint canvas on new codebases. The visual graph in the Blueprint tab is useful for understanding unfamiliar repos. Filter by file type, zoom into a module, and let the graph show you the dependency shape before you start prompting.

Free Tier Summary

Feature	Solo (Free)
Workspaces	1
Local models (Ollama, LM Studio)	✓ Unlimited
Model Bridge Speed tier	✓ Included usage
Core tools (file, terminal, search, blueprint)	✓
MCP marketplace	✗ (1 manual MCP)
Agent Behaviors marketplace	✗

For a solo developer using local models, the free tier is genuinely unlimited. No token caps on Ollama usage.

Getting Started

# 1. Download from atlarix.dev
# 2. Install CLI from Settings → General
# 3. Open your project
atlarix .

# 4. Connect Ollama (or paste an API key)
# 5. Start in Explore mode, describe your codebase
# 6. Switch to Build when you're ready to execute

The learning curve is less steep than it sounds. The hardest part is resisting the urge to jump straight into Build mode — a quick Explore turn first makes everything else go smoother.

atlarix.dev — macOS + Linux, free Solo tier

Open source: atlarix-skills · atlarix-mcps

Questions? Drop them in the comments — happy to go deep on any part of this.

How I reduced AI codebase context from 100K to 5K tokens using a graph-based RAG

Amariah Kamau — Thu, 30 Apr 2026 18:43:26 +0000

Most AI coding tools lie to you about context.

They say "I understand your codebase." What they actually do is dump as many files as possible into the context window and hope the model figures it out. That works on a 3-file project. It falls apart on anything real.

Here's the problem I kept hitting: a medium-sized production codebase hits ~100K tokens when you try to feed it to an LLM. That's expensive, slow, and surprisingly lossy — models start hallucinating relationships between files that don't exist, missing the ones that do.
So I built a different approach inside Atlarix. Here's exactly how it works.

Step 1: Parse the codebase into a typed graph (Round-Trip Engineering)

When you open a project in Atlarix, it runs a parser over every file using Tree-sitter AST. Instead of storing raw text, it extracts:

Every function, class, interface, and type
Import/export relationships between files
Call relationships between functions
File-level dependency edges

This gets stored as a typed node/edge graph in SQLite — what we call the Blueprint. One-time cost. Persistent across sessions.

Step 2: Query the graph, not the files

When you ask Atlarix something — "why is this API returning null?" or "add authentication to the user route" — it doesn't re-read your files. It queries the Blueprint graph.
We use BM25 scoring to rank nodes by relevance to the query. Only the top-scoring nodes get passed to the LLM. Everything else stays in SQLite.
Result: instead of ~100K tokens, the average query uses ~5K tokens. That's a 95% reduction.

Step 3: Hierarchical context for complex queries

For simple queries, BM25 node retrieval is enough. For complex ones — multi-file refactors, architecture questions — we use a three-layer hierarchy:

Mermaid diagram — a persistent high-level map of the whole codebase, always in context
BM25-scored Blueprint nodes — targeted retrieval for the specific query
Fast-model compression — if context hits 70% capacity, a fast model compresses the least relevant nodes before passing to the main model

This keeps context tight regardless of project size.

Step 4: Provider-agnostic by design

The Blueprint RAG layer sits beneath every AI provider. Whether you're using GPT-4o, Claude, Gemini, Groq, or a local Ollama model — the same 5K token context gets served. You're not paying for the model to re-read your whole codebase on every message.

Why this matters beyond token cost

The token reduction is the headline number. But the real win is accuracy.
When you give an LLM 100K tokens, it attends to all of it roughly equally. The file you actually care about is competing with 200 other files for attention. With 5K targeted tokens, the model is working with exactly what's relevant. Responses are more precise, edits land in the right place, and hallucinated file paths basically disappear.

What's next

Atlarix v7 added parallel agents (Research, Architect, Builder, Reviewer, Debugger) on top of this foundation. Each agent uses the same Blueprint RAG layer — so even autonomous multi-agent builds stay within tight context budgets.
We also just shipped Windows support today — so Atlarix now runs on Mac, Windows, and Linux.
If you're building something where AI context management is a bottleneck, I'd love to compare notes. Try it at atlarix.dev or ask me anything in the comments

What two hackathons taught me about agent architecture — and how it's reshaping Atlarix

Amariah Kamau — Fri, 10 Apr 2026 18:05:45 +0000

I recently competed in two hackathons back to back: the Amazon Nova AI Hackathon (virtual, won the Bonus Blog Post Prize) and the Lua x Antler "Building Agent-First Businesses" event in Nairobi (physical). Both cracked open how I was thinking about agents in ways I didn't expect.

The Amazon Nova lesson: a model is only as powerful as its capabilities

The hackathon required building with Amazon Nova. My instinct going in was that model choice was the primary variable — pick the best model, get the best results. Wrong.

What actually moved the needle was what I wrapped around the model: the tools it could call, the context it had access to, how I structured the agent loop. Nova performed at a high level not because of raw benchmark numbers but because I gave it enough surface area to work with.

This directly influenced how I think about Atlarix's Compass tier system. Compass routes users to Fast / Balanced / Thinking model tiers via OpenRouter — but the tier is almost secondary to the tooling layer underneath. 57 tools, RTE codebase parsing into a SQLite knowledge graph, multi-agent coordination. That's the actual product. The model slot is interchangeable.

The Nairobi lesson: our definition of "agent" was too narrow
At the Lua x Antler event, I saw builders shipping agent-first products that weren't just "chat plus tools." These were autonomous systems designed around specific domains — deeply customized, operator-light, solving massive real-world use cases across the continent. The technical depth in that room reset my benchmark.
It pushed me to think harder about what "agent mode" actually means in Atlarix. Right now we have Ask / Plan / Build / Debug / Review. That's a good start. But the next version needs to think more seriously about customization depth — how specialized can an agent get for a specific codebase, workflow, or domain?

What's next for Atlarix
We're building the next version informed by both of these. The core thesis stays: Your Architecture. Your Model. Your Sovereignty. But we're pushing further into:

Deeper agent specialization per workflow
First-class support for African AI models as they come online
Keeping data local and sovereign by default

If you're building with agents or thinking about model-agnostic tooling, I'd love to compare notes. Atlarix is open for early access at atlarix.dev.

The Private Sovereign AI IDE — Why I built Atlarix differently

Amariah Kamau — Sun, 29 Mar 2026 19:13:08 +0000

There's an assumption baked into every major AI coding tool right now.

That you have a $20/month subscription to an American AI company. That you have a fast, stable connection. That the models worth using are the ones coming out of San Francisco.

I'm building software from Nairobi. That assumption doesn't hold.

So I built Atlarix differently — and after a year of building, v5.1.0 is the version that finally says out loud what it was always trying to be: The Private Sovereign AI IDE.

What that actually means

Sovereign doesn't mean offline-only or anti-cloud. It means you decide.

You decide which model runs your code.

You decide what context gets sent.

You decide whether your keys live on your machine or in a provider's system.

Atlarix is built around three ideas that most AI coding tools don't share:

1. Blueprint — your codebase as a living graph

Instead of sending files per query, Atlarix parses your codebase into a persistent node/edge graph stored locally in SQLite. That graph becomes the AI's long-term memory. It doesn't reset between sessions. It understands your architecture the way a colleague would — not by re-reading everything each time, but because it already knows.

2. Any model — genuinely

Cloud providers via BYOK. Local models via Ollama and LM Studio. And now Compass — three built-in model tiers (Fast, Balanced, Thinking) that work the moment you open the app. No API key. No configuration. Just open and build.

3. The tool carries the intelligence

This is the core thesis. Atlarix feeds the model exactly what it needs, when it needs it, scoped by your .atlarixignore and Blueprint context tiers. A lighter model with good context beats a frontier model flying blind. That's not a consolation prize — that's the architecture.

Work modes that mean something

Ask — read-only. No code changes, no terminal. Research, explore, understand.
Plan — map out what needs to happen before anything gets written.
Build — full tools, explicit approval queue before execution.
Debug — focused on what's broken and why.
Review — read your code the way a reviewer would.

Each mode binds to a Blueprint context tier. The AI isn't just switching personality — it's switching what it knows and what it's allowed to do.

Why sovereignty matters right now

AI coding tools are becoming infrastructure. The question of which model runs your code, who sees your prompts, and whether you can switch providers without rebuilding your workflow — these are not small questions.

Atlarix's answer: your architecture, your model, your sovereignty.

v5.1.0 is live. Free to start. Native desktop — Mac, Windows, Linux.

👉 atlarix.dev

I built this from Nairobi. If you try it, tell me honestly what's missing. That feedback is worth more than any press right now.

Atlarix v3.7 is live — now Apple Notarized

Amariah Kamau — Fri, 06 Mar 2026 15:12:43 +0000

After months of building, testing, and waiting on
Apple's notarization process — Atlarix v3.7 is
officially live and Apple Verified.

What is Atlarix?
An AI coding copilot that actually understands your
entire codebase. Not just the open file.
The whole thing — visually.

Here's what makes it different:

Blueprint + RTE Parsing
Atlarix parses your project once using Round-Trip
Engineering. It builds a live architecture diagram
(Blueprint) and uses it as a RAG knowledge base.
Every AI response comes from the graph — not from
scanning 100K tokens of raw files.

8 AI Providers + Local Models
Claude, GPT-4, Gemini, Groq, Mistral, xAI,
OpenRouter, Together AI. Plus Ollama and LM Studio
for fully offline, private coding.

Agent System
Research, Architect, Builder, Reviewer —
each with dedicated tools and structured delegation.

v3.7 specifically:

Apple Notarized and code-signed (Mac)
Sentry error monitoring
PostHog optional analytics (consent-based)
Two-stage auto router
Blueprint enricher

This couldn't have been possible without every
person who downloaded and used Atlarix before it
was polished. To all our active users —
to many more achievements 🥳

Free to try → https://atlarix.dev

devtools #buildinpublic #AI #MacOS

I Got Tired of Re-Explaining My Codebase to AI Every Single Session

Amariah Kamau — Wed, 18 Feb 2026 19:57:09 +0000

There's a specific frustration every developer using AI coding tools knows.

You open a project you've been on for months. You ask the AI something reasonable — "how does our auth flow connect to the user service?" — and it either makes something up, asks you to paste files, or tells you it doesn't have access to your codebase.

So you paste the files. You explain the structure. You give it context. It helps. You close the laptop.

Next session: same thing. From scratch. Every time.

That's what pushed me to build Atlarix. Not to make another AI chat interface, but to fix this specific problem — the AI having no real, persistent understanding of your project.

The Root Issue: Code Isn't a List of Files

Every tool that tries to "understand your codebase" by dumping raw files into context is solving the wrong problem.

Your codebase isn't a flat list of files. It's a graph. Functions call functions. API routes hit services. Services write to databases. Webhooks trigger workers. A class inherits from a base that three other classes also inherit from.

When a senior engineer who's been on a project for a year answers a question, they're not re-reading files. They're querying a mental graph they've built up. The question I kept asking myself was: what if the AI had that graph too?

What I Built: Parse Once, Query Forever

Here's what Atlarix actually does when you open a project.

It runs a parser across your codebase — TypeScript and Python right now, more coming — and extracts every meaningful node: API endpoints, functions, classes, database operations, webhooks, scheduled jobs, third-party calls. Each node gets typed and tagged. Then it builds a graph from those nodes and their relationships, and caches it as a Blueprint at ~/.atlarix/blueprints/{projectHash}/.

Full parse on most projects: under 30 seconds.

After that, when you ask the AI something, it doesn't scan files. It queries the graph. Finds the relevant nodes. Injects only those into context. We're talking ~5K tokens instead of 100K. A file watcher updates affected nodes on save, so the graph stays current without you doing anything.

The practical difference:

Before: Ask question → AI scans everything → 100K tokens → slow, expensive, confused
After:  Ask question → Query graph → inject relevant nodes → 5K tokens → fast, accurate

This is the core of what we call RTE + RAG — Round-Trip Engineering to build the graph, Retrieval-Augmented Generation to query it.

The Part I'm Most Proud Of: Project Memory That Actually Persists

The RAG system solves the "understanding" problem. But there's a second problem — remembering decisions.

Why did you choose this database? Why is that service structured that way? What's the rule about how auth tokens are handled?

Atlarix writes to .atlarix/memory.md automatically during context compaction (when a conversation gets long). When you start a new session, the AI reads it first. It's just a markdown file — you can edit it manually, version control it, whatever you want.

There's also .atlarix/spec.md — a model-created task breakdown the AI generates for complex features. Both are inspired by how Claude Code handles project memory. Simple idea, makes a huge quality-of-life difference in practice.

Building Visually: The Blueprint Canvas

The graph isn't just for the AI to query. It's also the foundation of a visual architecture designer.

In Blueprint mode, you get a React Flow canvas. You can design your system visually — drag in containers (Auth API, Worker Service, DB Layer), add beacons inside them (specific routes, functions, handlers), draw edges between them. It looks like an actual system diagram because it's meant to be one.

The workflow I use for new features:

Design the architecture in Blueprint
Click "Generate Plan" — the AI compares Blueprint (desired) to Live (actual code), generates ATLARIX_PLAN.md
AI implements one task per message, waits for review before the next
Approve, iterate, ship

It's architecture-first development. Design before you code. The AI implements what you designed, not what it guesses you want.

The Agent System (and Why I Separated Permissions from Modes)

One decision I made early that I think was right: separate agent mode from permission mode.

Modes are about delegation:

Direct — just you and the model, no agents
Guided — orchestrator delegates flat to specialists (Research, Architect, Builder, Reviewer)
Autonomous — agents can spawn sub-agents for complex multi-step work

Permissions are about what the AI can touch:

Ask — read-only tools only
Build — can write files and run commands

These are independent. You can run Autonomous mode in Ask permission (agents can plan and research but can't write anything) or Direct mode in Build permission (full write access, no delegation). Mixing them any way you want.

The reason this matters: a Reviewer shouldn't be writing code. A Research agent shouldn't be executing commands. The separation of concerns in the tool sets prevents the agents from stepping on each other's work.

What v3.0 Changed

The big v3.0 changes were less glamorous than the earlier features but genuinely important for daily use:

Workspace storage and path resolution were reworked and now just work correctly
The .atlarix/ folder system is solid — memory.md and spec.md reliably persist across sessions
Relative paths in create_directory and file tools resolve correctly to the workspace root

Sometimes the most important release is the one that makes the existing stuff reliable.

What I'd Do Differently

A few honest things I'd change if I were starting over:

Start with SQLite sooner. The Blueprint is currently JSON-cached. Full ANTLR4 parsing with SQLite persistence is on the roadmap (PIVOT), and I should have committed to that architecture earlier.

Fewer providers at launch. Supporting 8 cloud providers + AWS Bedrock + Ollama + LM Studio sounds like a feature. In practice, it's a lot of surface area to maintain. I'd have launched with 3 and expanded.

The permission UI took longer than expected. Getting the approve/reject flow right — where the AI proposes every file change and you see a diff before anything runs — was worth it, but it was the part I most underestimated.

Website: https://atlarix.dev

If you've hit the same wall with AI coding tools — re-explaining your project every session, blowing token budgets on raw context, wishing the AI actually understood your architecture — I'd love to hear if this solves it for you.

And if you've built something similar or tackled the codebase-as-graph problem differently, genuinely curious how you approached it. Drop it in the comments.

Cursor vs Windsurf vs Atlarix: Which AI Coding Assistant Should You Choose in 2026?

Amariah Kamau — Tue, 10 Feb 2026 17:41:25 +0000

Cursor vs Windsurf vs Atlarix: Which AI Coding Assistant Should You Choose in 2026?

The AI coding assistant market exploded in 2024-2025. If you're a developer trying to pick between Cursor, Windsurf, and newer alternatives like Atlarix, this comparison breaks down what each tool does best—and where they fall short.

Quick Comparison Table

Feature	Cursor	Windsurf	Atlarix
Core Strength	Chat + autocomplete	Agentic flows	Visual architecture + AI
Pricing	$20/mo	$10-15/mo	Free (BYOK) / $19/mo Pro
IDE	VS Code fork	Custom	Standalone desktop app
Architecture View	❌	❌	✅ Visual blueprints
Agent System	Basic	Advanced	3-tier (Research/Architect/Builder/Review)
Local Models	❌	Limited	✅ Full Ollama + LM Studio
Multi-Provider	OpenAI + Anthropic	Limited	8+ providers
BYOK Support	❌	❌	✅ Bring your own API keys

Cursor: The Chat-First Powerhouse

What it does well:

Excellent autocomplete (Tab to accept)
@-mentions for codebase context
Smooth VS Code integration
Fast inline edits

Where it struggles:

No architecture visualization
Expensive at $20/mo (no BYOK option)
Limited to OpenAI/Anthropic models
Can't see the "big picture" of your project

Best for: Developers who live in VS Code and want premium autocomplete with AI chat.

Windsurf: The Agentic Coder

What it does well:

Multi-step agentic workflows ("Cascade" mode)
Can plan and execute complex tasks
Lower price point than Cursor
Good at refactoring

Where it struggles:

Custom IDE (learning curve)
No visual architecture tools
Limited model choices
Still scanning your entire codebase each time

Best for: Developers comfortable with a new IDE who want autonomous coding agents.

Atlarix: The Blueprint-First Alternative

What makes it different:
Atlarix takes a fundamentally different approach: you design your app's architecture visually, and the AI uses that blueprint as persistent memory.

How it works:

Visual Blueprint Mode - Design your app structure with rooms (services) and functions (APIs, webhooks, features)
3-Tier Agent System - Research agent finds patterns, Architect plans changes, Builder implements, Reviewer checks quality
Code Generation - Generate stub code from blueprints, AI fills in logic
Persistent Memory (v2.2) - AI "remembers" your architecture across sessions instead of re-scanning

What it does well:

See your entire architecture at a glance (Mermaid diagrams)
BYOK - use your own API keys from 8+ providers
Full local model support (Ollama, LM Studio)
Free tier with full features (1 workspace)
Works as standalone app (not tied to specific IDE)
Activity stream shows exactly what agents are doing

Where it struggles:

Newer product (smaller community)
Blueprint system has learning curve
Not integrated into existing IDE (separate app)
v2.2 Blueprint Intelligence still in development

Best for: Developers working on complex multi-service architectures who want visual clarity + AI assistance. Also great for privacy-focused devs using local models.

Real-World Use Cases

Use Cursor if:

You want the smoothest autocomplete experience
You're happy paying $20/mo
You primarily use OpenAI/Anthropic models
You live in VS Code and don't want to switch

Use Windsurf if:

You want autonomous agents to handle multi-step tasks
You're comfortable learning a new IDE
You want a middle-ground price point

Use Atlarix if:

You're building complex apps with multiple services
You want to see and design architecture visually
You prefer BYOK or local models (privacy/cost control)
You like the idea of AI having "persistent memory" of your project structure

The Cost Breakdown

Monthly cost comparison (assuming 100k tokens/day usage):

Cursor: $20/mo (flat rate, no BYOK)

Windsurf: ~$10-15/mo (varies by plan)

Atlarix:

Free tier: $0 (BYOK - you pay your provider directly)
With OpenAI API (BYOK): ~$5-10/mo depending on usage
Pro plan: $19/mo (unlimited workspaces)

If you're a heavy user with your own API keys, Atlarix can save you significant money.

My Take

All three are solid tools. Your choice depends on your workflow:

Cursor = Best in-editor experience, premium price
Windsurf = Best autonomous agents, custom IDE
Atlarix = Best for architecture-first development, most flexible pricing

I'd suggest trying all three (they all have free tiers or trials). Personally, I use Atlarix for planning/architecture and Cursor for autocomplete - they complement each other well.

Try Them Out

Cursor: cursor.com (2-week trial)
Windsurf: codeium.com/windsurf (free tier)
Atlarix: atlarix.dev (free tier with BYOK)

What's your experience with these tools? Drop a comment below - I'd love to hear which workflow works best for you.

Disclosure: I'm building Atlarix, but I've used Cursor and Windsurf extensively and genuinely respect what they're doing. This comparison is based on real hands-on experience with all three tools.

Why I Built a Local-First AI Coding Agent Instead of Another Chat Assistant

Amariah Kamau — Sat, 17 Jan 2026 13:19:54 +0000

Most AI coding tools today stop at suggestions.

They generate code, explain snippets, maybe autocomplete — and then hand everything back to you. The moment something breaks, you’re copy-pasting logs, errors, and screenshots into a chat box.

I wanted something different.

I wanted an AI that lives inside my actual development environment.

That’s why I built Atlarix — a desktop-native, privacy-first AI coding agent.

The problem with cloud-first AI assistants

Most assistants today:

Run in the cloud
Don’t see your real file system
Don’t run your code
Can’t observe build errors directly

They’re helpful, but they’re disconnected from reality.

As developers, our workflow isn’t text — it’s terminals, servers, logs, broken builds, and iteration loops.

What “agentic” actually means in practice

Atlarix isn’t a chat assistant. It’s an agent.

That means it can:

Run terminal commands
Read compiler and runtime errors
Spin up real dev servers (Vite, Next.js, Python, Go)
Fix issues in loops without you pasting stack traces

It sees what you see — and acts on it.

Local-first by default

Privacy wasn’t an afterthought.

Atlarix runs on your machine and uses BYOK (Bring Your Own Keys):

OpenAI / Anthropic
OpenRouter
Or fully local models via Ollama / LM Studio

Your code stays yours.

Why a desktop app (not a VS Code extension)

I didn’t want to be constrained by editor sandboxes.

A native desktop app can:

Control the terminal
Access the file system
Orchestrate multiple tools at once
Run longer agentic workflows safely

That freedom matters if you want AI to do real work.

Shipping v1.0

Atlarix v1.0 is live.

I’m less interested in hype and more interested in feedback — especially from developers who actually ship and care about privacy, control, and workflow realism.

You can explore it here:

👉 https://www.atlarix.dev/

If you try it, I’d love to hear:

What feels magical
What feels off
What breaks immediately

That’s how better tools get built.

Code smart. Stay authentic.

I’ll see you in the next one 🚀

🟩 commit-checker v0.6.1 – Track GitHub streaks, TIL logs, and unlock CLI achievements

Amariah Kamau — Mon, 28 Jul 2025 14:11:01 +0000

If you’ve ever wanted to keep your GitHub streak alive without needing internet or tokens, or if you’ve just wanted to make your terminal feel a little more fun — this tool might be for you.

I just released commit-checker v0.6.1, a fully offline terminal app that lets you:

✅ Track your GitHub commit streak across all local repos

📚 Save “Today I Learned” entries from the terminal

📈 View detailed commit trends and language stats

🎮 Unlock ASCII achievements and gamified levels

💻 Works on macOS, Linux, and Windows — no tokens, no login

🔧 What’s New in v0.6.1

Clean uninstall now fully nukes all files + config
Smarter wizard input validation (no more broken setups)
Fixed duplicate repo bugs and improved path detection
Now supports all features even when installed via curl

🎬 Demo Video (1min 54s)

I made a short setup + usage demo : https://youtu.be/1b3yN4mYpGY

🚀 Quick Install

curl -s https://raw.githubusercontent.com/AmariahAK/commit-checker/main/install.sh | bash

📁 GitHub
All the code, issues, and feature roadmap are on GitHub:
🔗 https://github.com/AmariahAK/commit-checker

🙌 Why I Made This
I built commit-checker to help me stay consistent with my GitHub commits and to make the terminal a bit more fun.

Instead of needing GitHub tokens or relying on the website’s activity chart, it tracks commits directly from your local repos.

It also includes a “TIL” feature to save quick learnings, and I plan to expand it with export options, themes, and plugin support.

💭 I’d Love Feedback
Try it out, let me know what you think, and feel free to open issues or collab if you’re into CLI tools or gamified productivity.
Let’s build cool stuff offline! 🔥