DEV Community: Kiell Tampubolon

I gave Claude a memory of everything I browse — here's the architecture

Kiell Tampubolon — Mon, 15 Jun 2026 08:05:42 +0000

Claude can read my files, my terminal, even my screen. But it had no idea what I read in my browser yesterday.

That gap bugged me enough to build BraveMCP: a local-first "second brain" that gives Claude Desktop access to my browsing history, bookmarks, highlights, and notes through the Model Context Protocol (MCP). Everything stays on my machine. No cloud, no tracking.

This is the technical write-up: the architecture, the one constraint that shaped the whole design, and the bugs that cost me the most time.

The constraint that shaped everything

MCP servers talk to Claude Desktop over stdio, a JSON-RPC stream on stdin/stdout. A browser extension lives in a sandbox and cannot speak stdio. It can only make outbound HTTP requests.

So the two halves of the system physically cannot talk to each other directly. That single fact drove the entire design.

The fix is a small HTTP bridge: an Express server running on port 3747, inside the same process as the MCP server. The extension POSTs browsing events to it; the MCP server reads from the shared database when Claude calls a tool.

The storage layer: hybrid search

Keyword search and semantic search each miss things the other catches. So BraveMCP runs both and merges them.

SQLite with FTS5 for fast BM25 keyword ranking over titles, summaries, notes, and highlights.
ChromaDB for cosine vector similarity, so "MCP security" still finds a page titled "Claude agent hardening."

// Merge keyword + vector hits; boost items that appear in both
const merged = new Map();
for (const m of chromaMatches) merged.set(m.id, { ...m, source: "semantic" });
for (const m of ftsMatches) {
  const existing = merged.get(m.id);
  if (existing) existing.relevance *= 1.1; // appears in both -> boost
  else merged.set(m.id, { ...m, source: "keyword" });
}

If ChromaDB is not running, the server degrades to FTS5-only instead of failing. Local-first means it has to work with whatever services you actually have up.

The AI pipeline, and why the fallback matters

When a page is captured, BraveMCP generates a summary and an embedding. It tries Ollama first (fully local: llama3.2 for summaries, nomic-embed-text for embeddings), then falls back to the Anthropic API.

But here is the trap I walked into. The first version, when no LLM was available, returned canned strings:

// before: this ignores the actual data entirely
return `Synthesis on "${topic}": Relies on the gathered browser research database.`;

That is useless. It says the same thing no matter what you searched. So I rewrote every fallback to be extractive: to build a real summary from the actual data, grouping matching pages by domain with real snippets pulled from SQLite. With no LLM at all, asking for a topic synthesis now returns the genuine sources. Different input produces different output. The "AI" tools stay useful even when there is no AI running.

Recovering forgotten pages

The tool I use most is find_forgotten_content. You give it a vague description and it does hybrid search, then re-ranks with time decay and a visit-count boost:

const timeDecay  = Math.max(0.5, Math.exp(-0.01 * daysElapsed));
const visitBoost = 1 + 0.2 * Math.log(visitCount);
const adjusted   = Math.min(0.99, relevance * timeDecay * visitBoost);

A page you opened three times last week beats one you glanced at once today. That matches how memory actually feels.

Two bugs that cost me hours

1. dotenv v17 broke the entire protocol. MCP communicates over stdout. dotenv v17 prints a status line to stdout by default. That one line corrupted the JSON-RPC channel and Claude Desktop refused to connect with a cryptic Unexpected token error. The fix was pinning dotenv@16. Two hours on a single log line.

2. The dual-process state problem. Claude Desktop and my dev client each spawn their own copy of the MCP server. Only the instance that grabs port 3747 receives extension data. The other had empty in-memory state, so tab tools returned nothing. The fix: stop treating in-memory state as the source of truth and fall back to SQLite, which both processes share.

What's in the box

A Manifest V3 extension (tab sync, bookmarks, context-menu highlights)
An MCP server exposing 13 tools (search_memory, find_forgotten_content, summarize_research_topic, generate_weekly_digest, suggest_tab_cleanup, and more)
SQLite + ChromaDB hybrid search
A test suite on Node's built-in runner, wired into CI

It is open source, MIT licensed: https://github.com/glatinone/BraveMCP

If you are building on MCP, the stdio-vs-HTTP bridge pattern is the part worth stealing. What would you want your AI to remember?

We thought we had location-based MFA. We had something else entirely

Kiell Tampubolon — Thu, 11 Jun 2026 09:27:14 +0000

We thought we had location-based MFA. We had something else entirely

Our CTO asked a simple question: when someone travels and signs in from outside our home country, do we prompt for MFA? Everyone's gut answer was yes. Users do get prompted when they travel. Case closed, right?

I decided to actually verify it. What I found changed the answer from "yes" to "yes, but not for the reason anyone thinks," and the whole audit turned into a small migration project. Here's the walkthrough, including the wrong turns, in case you need to run the same check on your tenant.

Where this configuration actually lives

My first instinct was Intune, since that's where our endpoint security lives. Wrong place. Intune handles device compliance. The "prompt MFA based on where you sign in from" logic lives in Microsoft Entra ID, under Conditional Access. Intune only feeds into it as a signal (the "require compliant device" grant control).

So the audit checklist looks like this:

Conditional Access → Named locations: is there a location defined for your trusted country or IPs?
Conditional Access → Policies: is there a policy that requires MFA when the sign-in location is outside those trusted locations?
Sign-in logs: does reality match the config?

What we found

Named locations: one stale IP range from two years ago, not referenced by any policy. No trusted country, no office IPs.

Policies: 18 policies total. Only 3 enabled, all device-related (block unmanaged devices, MAM). Zero location-based policies. Not even a disabled one.

So the honest answer to the CTO was: no, we never configured travel MFA. And yet users were definitely getting MFA prompts when travelling. Something else was doing it. Hold that thought.

Entra also showed us its own receipts. Under Policies there's a Security Alerts section that analyzes your last 7 days of sign-ins. Ours said 72% of sign-ins were out of scope of any Conditional Access policy, and a few hundred sign-ins were still using legacy authentication. If you've never looked at this panel, look. It's free ammunition for whatever security proposal you're trying to get approved.

Building the policy

Management wanted trusted locations defined by IP ranges (office egress + VPN egress) rather than by country. That's the stricter and, I'd argue, better option. Country-based trust means anyone inside the country skips MFA, including an attacker on a VPN exit node in your city. IP-based trust means the corporate network is the boundary: on VPN, no prompt; off VPN, prompt. Wherever you physically are.

Step 1: find your real egress IP

Don't ask around or trust documentation. Test it:

Connect the corporate VPN, open ifconfig.me, note the IP.
Sign in to any Microsoft 365 portal, then open Entra → Sign-in logs and check the IP address recorded on that sign-in.
If the two IPs match, your M365 traffic goes through the VPN tunnel and the VPN egress IP is usable as a trusted location.

Step 2 matters more than it looks. A lot of VPN setups use split tunneling and exclude Microsoft 365 traffic from the tunnel (Microsoft themselves recommend this for performance). In that case Entra sees the user's local ISP address, your VPN-based trusted location never matches, and the policy will prompt everyone everywhere. Better to find out in a ten-minute test than after rollout. Ours matched, so we were fine.

Also check your logs for IPv6 sign-ins. If clients sometimes authenticate over IPv6, an IPv4-only trusted range silently fails to match those.

Step 2: named location

Conditional Access → Named locations → IP ranges location (not Countries location, I clicked the wrong one first and you can't convert between types, only delete and recreate):

Add your office and VPN egress ranges in CIDR (/32 for single IPs)
Tick Mark as trusted location

Step 3: the policy

Users: start with just yourself. Then a pilot group. Then everyone. One policy, widen the scope each phase. Don't create three policies, future-you will hate cleaning them up.
Target resources: All resources for the monitoring phase. You want complete data.
Network: Include Any location, Exclude your trusted IP location.
Grant: Require multifactor authentication.
State: Report-only.

Report-only evaluates the policy on every sign-in and records what would have happened, without prompting anyone. Each sign-in event gets a Report-only tab showing "Failure" (would have been prompted) or "Not applied" (excluded or out of scope). After a week or two you know exactly how many prompts per day enforcement will generate, and which accounts would be affected. That's the data you bring to the meeting where someone has to say "turn it on."

One gotcha while testing: check the result on a sign-in to a resource your policy actually covers. I initially scoped the policy to the Office 365 app group, then tested against the Azure portal and wondered why the policy didn't show up in the evaluation. It wasn't broken. The resource just wasn't in scope.

The plot twist: who was prompting all along

While reading sign-in logs I noticed something odd. Sign-ins showed "Multifactor authentication" as the authentication requirement even when every Conditional Access policy on the event said Not applied. MFA was being required by nothing visible in CA.

There's only one thing that does that: legacy per-user MFA, the old Enabled/Enforced toggle buried in the per-user MFA portal, predating Conditional Access. Someone had switched it on for users years ago. It prompts for MFA everywhere, with a "remember this device for X days" option, which is exactly why users only noticed prompts when travelling: new browser, new device, hotel computer. It felt location-based. It never was.

This matters beyond trivia:

Per-user MFA ignores trusted locations entirely. Our shiny new exclusion did nothing while it was active, which confused my first round of testing.
Microsoft is deprecating per-user MFA and wants everyone on Conditional Access.
The migration order is critical: enforce the CA policy first, then disable per-user MFA in batches. Do it in the other order and you've created a window with no MFA at all.

So the audit's final answer to the CTO: yes, users get MFA prompts when travelling, but from a deprecated mechanism that prompts everywhere and can't honor trusted networks. The new CA policy is both the fix and the migration path.

Other things the audit shook loose

Once you start reading policies carefully, you find things:

A "block unmanaged devices" policy whose grant logic was actually "require compliant device OR app protection policy, require one." That's not a block, that's an either/or, and the policy name lies about it. Probably intentional for BYOD mobile. Worth confirming rather than assuming.
A Microsoft-managed policy ("MFA for admins accessing admin portals") sitting in report-only for over two years, with a note in the fine print: leave it in report-only and Microsoft will enable it for you. Enforcement is coming whether you schedule it or not. Schedule it.
Several abandoned test policies from old projects. Off, report-only, names like Group2, Group3, Group4. Every tenant has these. Delete or document them.

The checklist version

If you want to run this same audit on your tenant, in order:

Conditional Access → Named locations: anything defined? Trusted? Referenced by a policy?
Policies: filter by State = On. Read the grant logic on each one. AND vs OR matters.
Pick a user who travelled recently, open their sign-in, read the Conditional Access tab and the Authentication requirement column. If MFA is required but no policy applied it, you have per-user MFA lurking.
Check the Security Alerts panel for out-of-scope and legacy auth numbers.
Verify your VPN egress IP against actual sign-in log entries before trusting it in a policy.
Build the location policy in report-only, scoped to yourself first, and widen from there.

The config took an afternoon. Understanding what was already happening in the tenant took longer, and was worth more.

Solstice — A Game About Holding the Light

Kiell Tampubolon — Sun, 07 Jun 2026 11:50:45 +0000

This is a submission for the June Solstice Game Jam

The Game

Solstice — Hold the Light

You are the last spark before the longest night. Move with your cursor, collect golden orbs to keep your light from fading, and avoid the shadows drifting in from the dark.

The world dims as your light dims. When your light hits zero, darkness wins.

🎮 Play it here: glatinone.github.io/solstice-game

📦 Source: github.com/glatinone/solstice-game

How It Plays

Move with mouse (desktop) or touch (mobile)
Collect golden orbs to restore light
Each orb is worth 1 point
Avoid the drifting shadows; they drain your light on contact
Your light decays continuously, faster as time goes on
Game ends when light reaches zero
Score = orbs collected before darkness

There is no win state. Only how long you can hold the light.

The Solstice Theme

The brief was the June solstice: the longest day, the shortest night. I flipped it. What if you were on the other side of the year, watching the light slip away?

Three things carry the theme:

Visual decay. The background is a radial gradient centered on the player. At full light it is warm: amber, dusk, sunset reds. As light drains the colors shift cold and dark. Stars become more visible. The screen literally dims with you.

Light as resource. Light is not just visual. It is your health bar, your time, and your radius of awareness all at once. Lose light, lose the game.

Shadows that grow with time. Difficulty scales with how long you have survived. More shadows, faster shadows, fewer orbs. The longer you hold the light, the harder the dark pushes back.

Tech Stack

HTML5 Canvas for rendering
Vanilla JavaScript, no frameworks, no build step
CSS for the UI shell (start screen, HUD, game over)
localStorage for high score
GitHub Pages for hosting

The whole game is one HTML file. About 600 lines including the styles and script. No dependencies.

Design Decisions

A few things I locked in early:

No menus, no levels, no upgrades. A jam game should be playable in 30 seconds. Press Begin, move mouse, see what happens.

No instant fail. Touching a shadow drains light, it doesn't kill you. This means a confident player can recover, but a careless one accumulates damage. Skill ceiling without frustration.

Visuals over mechanics. The core loop is simple: collect, dodge, survive. What carries the experience is the way the world looks at full light versus near-zero light. Particle trails, radial glows, the slow color shift. The game's mood is the gameplay.

One screen, no scrolling. Mobile and desktop play identically. No camera systems, no levels to load.

What I Would Add With More Time

Sound (a slow ambient drone that intensifies as light fades)
A second orb type that gives bigger light boost but moves
Boss shadow at extreme low light
Daily seed leaderboard

These would all stack on top of the existing loop without changing it.

Reflection

I have not built a game from scratch in years. Twenty-four hours from idea to playable submission, single file, no engine.

The hardest part was not the code. It was knowing when to stop. A jam game asks you to ship something fun, not something complete. Every extra feature is a tax on the player's first impression.

Solstice is a small game. That is the point.

Built with HTML5 Canvas. Hosted on GitHub Pages. Survival time is yours to discover.

Finishing a Read-Only MCP Server: From 6 Tools to 9

Kiell Tampubolon — Sun, 07 Jun 2026 08:05:04 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

I took an unfinished open-source MCP server for DEV.to and added the missing half.

The original repo (nickytonline/dev-to-mcp) was built by an actual DEV.to engineer and shipped six read-only tools: get_articles, get_article, get_user, get_tags, get_comments, search_articles. Useful for reading, useless for writing.

I extended it with three write tools:

create_article for publishing new articles (draft or live)
update_article for editing existing ones
delete_article for unpublishing

The result is a full read-write MCP server that lets Claude (or any MCP client) treat DEV.to like a CMS. This article was created and published using it.

Demo

The tool list in Claude Desktop after the build:

Read-only tools (6):
  Get Articles, Get Article, Get User, Get Tags, Get Comments, Search Articles

Write/delete tools (3):
  Create Article, Update Article, Delete Article

A draft creation call looks like this:

{
  "tool": "create_article",
  "args": {
    "title": "My new post",
    "body_markdown": "# Hello world",
    "tags": ["webdev", "ai"],
    "published": false
  }
}

The MCP server hits POST https://dev.to/api/articles with the user's DEVTO_API_KEY from env, returns the article ID, and Claude can immediately call update_article against it. No browser, no copy-paste from chat to editor.

The Journey

The original repo was solid but limited. I asked myself: why use an MCP server that can only read?

Setup was the first wall. The npm package wasn't published, so npx -y @nickytonline/dev-to-mcp returned 404. Then npm install -g github:... failed because the repo had no top-level package.json at the install path npm expected. The fix was unglamorous: git clone, npm install, npm run build, point Claude Desktop's config at the local dist/index.js.

There was also a Windows-specific gotcha. Claude Desktop on Windows needs npx.cmd, not npx. The error message was just Server disconnected. Logs showed bad option: -y because the config still had the npx flag while the command had been swapped to node. Small things, two hours.

Once the read-only server was running, the actual finish-up work was straightforward. The codebase used a clean handler pattern: each tool was a function that called the DEV.to API and returned a typed response. I followed the same pattern for the three new tools:

// Pattern from the existing read tools
async function getArticle(id: number) {
  const res = await fetch(`https://dev.to/api/articles/${id}`, {
    headers: { 'api-key': process.env.DEVTO_API_KEY }
  });
  return res.json();
}

// New write tool, same shape
async function createArticle(article: ArticleInput) {
  const res = await fetch('https://dev.to/api/articles', {
    method: 'POST',
    headers: {
      'api-key': process.env.DEVTO_API_KEY,
      'Content-Type': 'application/json'
    },
    body: JSON.stringify({ article })
  });
  return res.json();
}

Tech Stack

TypeScript for the server code
Vite for the build (12.83 kB output, builds in 133ms)
Model Context Protocol SDK for the server scaffolding
DEV.to API v1 as the backend
Claude Desktop as the MCP client

What I Learned

Two things stood out.

First, finishing someone else's project is faster than starting from scratch. The repo had types, patterns, error handling, and tests already in place. Adding three tools meant matching an existing shape, not inventing one. The full add-rebuild-test cycle was under thirty minutes.

Second, AI assistance works best when there's existing structure to imitate. I gave Claude Code the repo path and asked for three tools matching the existing pattern. It read the codebase, identified the handler signature, knew the DEV.to API endpoints from training data, and produced working code on the first build. Without the existing read-only tools as reference, the output would have needed more iteration.

What's Next

The MCP server still has gaps:

No image upload (DEV.to requires base64 inline or external URLs)
No get_followers or get_following
No comment write/delete
No analytics endpoints

These are small additions following the same pattern. The hard part was the first three.

Repo

The forked repo with write tools: github.com/glatinone/dev-to-mcp

Original credit to @nickytonline for the read-only foundation.

Claude Token Monitor 🚀 — Real-Time Claude Usage HUD for Your Windows Desktop

Kiell Tampubolon — Sat, 06 Jun 2026 17:55:16 +0000

Claude Token Monitor 🚀

⚠️ Disclaimer: This is an unofficial community-driven tool and is not affiliated, associated, endorsed by, or in any way officially connected with Anthropic, PBC.

Ever wonder how much of your Claude quota you've burned through mid-session? Claude Token Monitor is a local-first desktop utility that gives you a beautiful, always-on-top floating HUD showing your Claude usage in real time — covering both Claude.ai Web App quota and Claude Code CLI token consumption.

🔗 GitHub Repository: github.com/glatinone/claude-token-monitor-usage

📸 What It Looks Like

The HUD uses a sleek glassmorphism design with a circular progress ring that dynamically changes color:

🟢 Green — Low usage
🟡 Amber — Medium usage
🔴 Red — High usage (time to slow down!)

You can drag it anywhere on your screen, collapse it into a tiny title pill with a double-click, and control it via the system tray.

✨ Key Features

Double-Sync Strategy:
- Standalone Mode — Direct API polling using your saved sessionKey cookie
- Browser Extension Sync — A companion Chrome Extension pushes live stats the moment you send a message on claude.ai
Always-on-Top Floating HUD — Circular progress ring, remaining quota %, and reset timer
Draggable & Position Memory — Drag it wherever you want; position is saved on exit
Claude Code CLI Integration — Real-time token parsing (Input, Output, Cache Write, Cache Read) with USD cost estimation based on Claude Sonnet pricing
Single-Instance Protection — TCP socket lock prevents duplicate processes or tray icon spam
100% Private & Offline-First — All data lives in usage_data.json on your machine. The local server binds only to 127.0.0.1

🛠️ Architecture

Here's how the pieces fit together:

Web Browser (claude.ai)
  └── Chrome Extension MV3
        └── POST JSON ──────────────────────┐
                                            ▼
Terminal / IDE                     Desktop App (Python)
  └── Claude Code CLI               ├── Local HTTP Server :9988
        └── Writes logs ──►         ├── Log Watcher
              ~/.claude/projects/   ├── Direct API Fetcher
              *.jsonl               ├── Storage Manager
                                    ├── CTk Floating HUD
                                    └── Tray Manager

Log Watcher — Monitors %USERPROFILE%\.claude\projects\*.jsonl for CLI token events
Local HTTP Server (port 9988) — Receives pushed JSON payloads from the Chrome Extension
Direct Fetcher — Polls the Claude API directly using your sessionKey cookie when the extension isn't running

🚀 Installation & Setup

Prerequisites

Python 3.10+
Windows OS

1. Install the Desktop App

git clone https://github.com/glatinone/claude-token-monitor-usage.git
cd claude-token-monitor-usage
pip install -r requirements.txt
python -m app.main

Windows users can just double-click run.bat to install dependencies and launch in one step.

2. Standalone Mode (Session Key Setup)

To let the app query your quota directly without the extension:

Open claude.ai and log in
Press F12 → Application → Cookies → https://claude.ai
Copy the value of the sessionKey cookie (starts with sk-ant-sid...)
Right-click the C tray icon → Setup Session Key
Paste and click OK — the widget syncs automatically!

3. Chrome Extension (Optional but Recommended)

Open chrome://extensions
Enable Developer Mode
Click Load Unpacked → select the extension/ folder
Open claude.ai and send a message — your quota syncs instantly!

🔒 Security & Privacy

Zero Cloud Sharing — Usage data stays strictly in app/usage_data.json on your local disk
Localhost Lock — The API server binds to 127.0.0.1 only; no LAN access
Credential Isolation — The Chrome Extension never touches your sessionKey. It's stored locally in app/config.json (git-ignored)

🤝 Contributing

Contributions are very welcome! Whether it's Linux/macOS support, UI improvements, or better CLI log parsing:

Fork the repo
Create your branch: git checkout -b feature/AmazingFeature
Commit: git commit -m 'Add AmazingFeature'
Push: git push origin feature/AmazingFeature
Open a Pull Request

📄 License

MIT License — free to use, modify, and distribute.

🔗 Check out the full project on GitHub: github.com/glatinone/claude-token-monitor-usage

If you find it useful, drop a ⭐ on the repo and share it with fellow Claude power users!

AI Agents: The Future of Autonomous Intelligence

Kiell Tampubolon — Sat, 06 Jun 2026 16:51:03 +0000

AI Agents: The Future of Autonomous Intelligence

What is an AI Agent?

An AI Agent is a system that perceives its environment, makes decisions, and takes actions to reach a goal with minimal human involvement.

A chatbot answers questions. An AI Agent goes further. It can:

Search the web for up-to-date information
Write and run code
Read and write files
Call external APIs
Plan tasks across multiple steps and recover when something breaks

The difference is not intelligence. It is autonomy.

How Do AI Agents Actually Work?

Most agents today run on a loop called ReAct (Reason + Act):

+-------------------------+
|         Observe         |
|    Read current state   |
+-------------------------+
            |
            v
+-------------------------+
|          Think          |
|   Decide next action    |
+-------------------------+
            |
            v
+-------------------------+
|           Act           |
|    Use a tool or API    |
+-------------------------+
            |
            v
+-------------------------------+
|        Environment            |
|  Files, APIs, web, databases  |
+-------------------------------+
            |
            +-------------------+
                                |
                    (result feeds back)
                                |
                                v
                     Back to Observe...
                     until goal is reached

The agent looks at the current state, decides what to do, does it, then checks again. This cycle continues until the goal is met or something breaks.

What makes this powerful is not any single step. It is that the loop can run hundreds of times, across tools, APIs, and files, without a human in the middle.

Types of AI Agents

Single-agent

One agent handles everything. Fast to build, limited in scope. Good enough for most tasks.

Multi-agent

Specialized agents working together. One researches, one writes, one reviews. More capable, more complex to orchestrate.

Agentic pipelines

A fixed sequence of agent steps. Think assembly line, not free-form reasoning. Reliable and predictable, useful for automation workflows.

Real-World Use Cases

Use Case	Example
Code generation	GitHub Copilot, Cursor, Claude Code
Customer support	Bots that actually resolve issues
Research	Browse, summarize, report autonomously
DevOps	Auto-fix failing pipelines
Content creation	Write, edit, and publish without manual steps

Frameworks Worth Knowing

LangChain -- the most widely used, with a huge ecosystem
LlamaIndex -- strong for retrieval-augmented generation
AutoGen (Microsoft) -- designed for multi-agent conversations
CrewAI -- role-based teams of agents
Claude + MCP -- Anthropic's approach using the Model Context Protocol

What is MCP?

The Model Context Protocol is a standard way to connect AI models to external tools and data. Instead of hardcoding tool integrations, MCP lets agents plug into anything that exposes an MCP server.

With MCP, Claude can read files, query databases, call APIs, and publish articles to DEV.to. That is exactly how this article got here.

What Can Go Wrong

AI Agents are genuinely useful. They are also genuinely unreliable in specific ways:

Hallucination -- agents can produce confident, wrong output
Infinite loops -- without guardrails, they can spin indefinitely
Cost -- multi-step agentic tasks burn tokens fast
Security -- an agent with broad permissions is a large attack surface

None of this is a dealbreaker. It just means you need to design with failure in mind.

Where This Is Heading

Three things that matter most in the near term:

Better planning -- agents that reason over longer time horizons without losing track
Persistent memory -- actually remembering what happened in previous sessions
Self-correction -- agents that notice when they have gone wrong and course-correct

Multi-agent collaboration is already here. The hard part is not making agents work together. It is making them work together reliably.

Where Does This Leave Us?

AI Agents shift the relationship between humans and software. Instead of tools you operate, you get systems that operate on your behalf.

That is a meaningful change. It is also early. The gap between what agents can do in a demo and what they can do reliably in production is still wide.

But it is closing fast.

I Built a Kubernetes Alternative. It Changed My Perspective on Complexity.

Kiell Tampubolon — Wed, 27 May 2026 04:50:58 +0000

After three long nights of coding, I stood on the edge of quitting. The most recent error? 'Connection refused: too many retries.' How does one recover from such a humiliating message? I guess you just pick yourself up and try again.

ACT 1: The Confidence Built on Ignorance

At first, I was cocky about my ability to develop a simpler alternative to Kubernetes. After all, I was drawing from over five years of experience building and managing containerized applications. Besides, I had graduated from a reputable programming boot camp, which ended up leading me to some great opportunities. I figured if I could wrangle Kubernetes, I could surely create something less complex and more approachable.

When I began this project, I believed the only thing standing in my way was time. I had convinced myself that my technical skills were enough; all I had to do was write the code, and it would come together. I thought eliminating a few features and minimizing configurations would be all it took to create something user-friendly. I pictured it, lightweight, no more than 300 lines of code for my entire tool. Simple, right?

ACT 2: The Moment It Broke

That illusion shattered when I hit my first major roadblock. After several days of coding with barely any sleep, I tried to deploy my work for the first time. I was so giddy with excitement; it was like I was seeing the light at the end of a tunnel. For about two seconds, it felt like everything was going great. And then came the error message:

Error: invalid configuration: failed to find a ready to use service

I thought, “How could this happen?” My tool was designed to simplify the deployment process, not make it more convoluted. After sweating over the terminal for hours, I tried everything. I rechecked the API calls, re-evaluated services, and even consulted the Kubernetes official documentation (which, let's be honest, is just a fancy way of saying I ended up down a rabbit hole of YAML files).

At that moment, it hit me: I hadn’t just omitted complexity; I had disregarded the very principles that make Kubernetes powerful, its ability to manage the scalability and orchestration of applications in distributed environments. I realized simplicity doesn't always mean fewer lines of code. Sometimes, it means better abstractions that serve higher purposes.

The Turning Point: What I Discovered

I decided to roll my sleeves up, go back to the drawing board, and analyze what I was actually trying to achieve. Instead of just cutting features, I began to rethink some of them entirely. I analyzed critical aspects like service discovery and load balancing and realized that perhaps they weren’t

I Dumped My Entire Codebase into Gemma 4. It Found a Bug My Team Missed for 3 Months.

Kiell Tampubolon — Mon, 18 May 2026 13:54:12 +0000

This is a submission for the Gemma 4 Challenge: Write About Gemma 4

The bug had been in production for 90 days. Three sprint reviews. Two refactors nearby. One team member who actually touched that file and left a comment saying "looks fine."

I found it in 4 minutes by pasting 47,000 tokens into Gemma 4 31B and asking one question.

I want to tell you this is a story about AI being brilliant. It is not. It is a story about what happens when you stop treating a 128K context window as a spec sheet number and start treating it as a tool.

Quick context if you're new to Gemma 4: It's Google DeepMind's latest open-weight model family, released April 2026 under Apache 2.0. The 31B dense variant is the largest in the family and the one that ships with a 128K context window and built-in reasoning mode. You can access it free via OpenRouter with no credit card required.

The Bug Was Invisible at File Level

We run a mid-sized Python backend. Not a startup toy project, not a monolith from 2009 either. Around 18,000 lines across 200-ish files, with a payment reconciliation module that processes about 4,000 transactions a day.

For three months we had an off-by-one error in how we accumulated daily totals. The kind of bug that doesn't crash anything, doesn't throw an exception, and stays quiet until someone runs a quarterly audit. Finance flagged it. Our first assumption was the database. Our second assumption was a race condition. Our third assumption was a rounding issue inherited from a third-party SDK.

All wrong. The bug was in how we correlated timestamps across two functions that lived 800 lines apart in the same module. You could not see it by reading either function. You had to hold both in your head at the same time, along with the utility function they both relied on, to see the logic drift.

Nobody held all three at once. Humans don't naturally do that across 800 lines.

What I Actually Did

I pulled the relevant module (about 1,400 lines), the shared utilities it imports (another 600 lines), and the test file (300 lines). Total: roughly 2,300 lines of Python. That's somewhere around 46,000 tokens.

I chose Gemma 4 31B, accessed via OpenRouter, specifically because of the context window size and the reasoning capability. The 128K window was not the point in itself. The point was that 128K let me stop chunking.

Every time I had tried to debug this with smaller-context tools I was feeding pieces of the problem. Paste function A, get feedback. Paste function B, get different feedback. Try to synthesize the two answers manually. That synthesis step is where the bug kept hiding.

With 31B I pasted the full thing at once:

prompt = f"""
You are reviewing Python source code for a financial reconciliation system.
Below is the complete module, its utility dependencies, and its test suite.

Find any logic errors related to timestamp handling, accumulation order,
or correlation between functions. Be specific about line numbers and
explain the interaction that causes the error, not just the error itself.

<module>
{reconciliation_module}
</module>

<utilities>
{shared_utils}
</utilities>

<tests>
{test_suite}
</tests>
"""

That's it. No chunking. No iterative back-and-forth. One completion.

The response came back in about 40 seconds. It flagged three things. Two were style notes I already knew about. The third was this:

accumulate_daily() uses record.created_at for grouping (line 312), but reconcile_period() filters by record.settled_at (line 1089). For records that settle in a different calendar day than they were created, these two functions will assign the same record to different days. The test suite only creates records where created_at and settled_at are within the same UTC day, so this has never been caught by the test harness.

I sat there for a second. Then I checked the two functions side by side:

# line 312 — in accumulate_daily()
day_key = record.created_at.date()   # <-- groups by creation date

# line 1089 — in reconcile_period()
if record.settled_at < period_end:   # <-- filters by settlement date
    totals[day_key] += record.amount

When a transaction is created on Monday but settles on Tuesday, accumulate_daily() puts it in Monday's bucket. reconcile_period() counts it toward Tuesday's filter window. Same record. Two different days. Neither function is wrong on its own. Together they silently drift.

Then I checked the test fixtures. Every single test record had created_at and settled_at set to the same UTC day. The tests never exercised the cross-day case.

It was exactly right.

Why This Worked and Why It Didn't Work Before

The test suite was the key detail. The model wasn't just spotting a timestamp mismatch between two functions. It was reading the tests and noticing the gap: the tests don't cover the case where these dates differ. That kind of cross-file reasoning requires the full context to be present simultaneously.

I had tried a similar experiment with GPT-4 earlier in the week by pasting sections iteratively. It flagged the created_at vs settled_at discrepancy in isolation but didn't make the connection to the test fixtures because the test file wasn't in scope when it saw the functions. The insight was split across two separate completions, and I didn't connect them.

With the full module in one pass, the model could see the claim ("here is how we accumulate") and the verification ("here is what the tests assert") in the same window, and notice they didn't match on the cross-day case.

The Honest Limits

This is not a "just paste your codebase and it will find all your bugs" story. Three caveats that matter:

Latency is real. The 31B model via OpenRouter takes time on a 46K token completion. For quick questions I still reach for smaller models or a local Gemma 4 E4B setup. The 31B is the right tool when you need the full picture and can afford the wait.
A vague prompt gets vague answers. My first attempt asked "find any issues." It returned generic style feedback. The version that found the bug asked specifically for "logic errors related to timestamp handling" because I had already narrowed the domain. The model amplified my hypothesis. It did not generate one from nothing.
It still missed one bug. I found it later through manual review. Not a humiliating miss. But a reminder that "found the bug I missed" and "found all the bugs" are very different sentences.

What This Actually Changes

The 128K context window is not about being able to process more. It is about being able to stop decomposing.

Most debugging assistance with AI is a decomposition problem: I have to decide what to show and what to leave out, and that editorial decision is exactly where bugs hide. The moment I have to decide "this function is probably not relevant," I might be wrong about that, and the model will never tell me.

When the window is large enough that I can stop curating, the model sees the same thing I should be seeing: the whole picture, including the parts I didn't think to highlight.

That changes the failure mode from "I showed it the wrong piece" to "I asked the wrong question." The second failure mode is actually fixable.

Try it yourself: grab a module you've been meaning to audit, load the full file plus its tests into Gemma 4 31B on OpenRouter (free tier, no card), and ask specifically about the interaction between the functions, not just each function alone. Drop what you find in the comments. I'm genuinely curious whether the cross-file blindspot is a universal problem or just a symptom of how our specific codebase grew.

I Was Wrong About AI. Here Is the Moment That Changed It.

Kiell Tampubolon — Mon, 18 May 2026 13:30:36 +0000

The debugging tool flagged a staggering 150 issues in my code almost instantly. I was astonished by how many mistakes I had made and how far I still had to go. This moment revealed the complexity of AI that I had underestimated all along.

The Moment It Broke

That breaking point was unexpected. I was toying with a fancy AI algorithm, thinking it was about to churn out perfect code. I had linked it with my code editor, set everything up, and watched with excitement as it typed out solutions based on prompts I fed it. After a few successful iterations, I made a huge mistake. I forgot to properly validate the inputs.

One afternoon, I threw in a random input to test its limits. The console displayed the message that will haunt me: "Runtime Error: Unexpected Token."

For a moment, I was frozen. I had ignored something critical: AI is a tool, not a solution in itself. More often than not, I’d been treating it as some kind of oracle instead of evaluating how it actually understood my requests. I should’ve known better. Sure, AI can assist in many ways, but nothing beats core programming principles.

What I Discovered

When I finally debugged the mess, I took a moment to reflect. I realized that I had neglected proper coding best practices in favor of a shiny new toy. AI works wonderfully when it augments your existing understanding and workflow. Here’s a snippet demonstrating the change I made:

// Original flawed function without validation
function aiSuggestion(prompt) {
 return aiModel.generate(prompt);
}

// Improved function with validation
function aiSuggestion(prompt) {
 if (typeof prompt !== 'string' || !prompt) {
 throw new Error('Invalid input: Please provide a valid string.');
 }
 return aiModel.generate(prompt);
}

Just adding that validation step made a world of difference. I could trust my AI’s feedback more because I was guiding it with better input. It was a simple tweak, but it became pivotal in my project’s success. I still smiled when my AI echoed back code that was far more functional than my initial attempts, but now I was equipped with the knowledge that I needed to do my part first.

The Bigger Principle

This lead to a bigger realization: tools are just extensions of ourselves. They don't replace the fundamentals. If you're a developer working with AI, you have to take responsibility for your code. Forgetting that turns you into a passive user, and honestly, nobody wants to be that. It’s like trying to build a house without knowing how to lay bricks; the walls might look good for a while, but they’re bound to crumble eventually.

When I look back, what annoys me most is that I didn’t question my assumptions sooner. I could’ve saved time, energy, and probably a few hairs on my head. Relying solely on AI to deliver the goods is tempting, but it leads to dangerous shortcuts. Proper coding practices don’t just lead to better outcomes; they prevent mistakes down the road.

In hindsight, I’d tell past-me to challenge the narrative that tech can solve everything. AI should elevate our skills, not replace them. So here’s my burning question: Are AI and automation a developer's best support system, or do they create a dangerous dependency that might weaken our core skills? What’s your take on this?

I Struggled with Data Analysis. Claude for Excel Changed Everything.

Kiell Tampubolon — Fri, 08 May 2026 12:02:15 +0000

At 2 AM, I was ready to throw my laptop out the window. I had just spent hours gaining zero insights from a sprawling sea of data. Then I stumbled upon Claude for Excel, and suddenly everything clicked into place.

The Problem with Real Error or Messy Code

Like many developers, especially those of us who aren't formally trained as data analysts, Excel can sometimes feel like a jungle. I was trying to generate reports that needed to highlight sales trends, which required me to wrangle all that data into a coherent narrative. I needed to create pivot tables to analyze the responses, but navigating through cumbersome formulas was turning my brain into mush. I spent hours merging cells, applying filters, and trying to remember whether I used SUM or AVERAGE last time.

One day, I spent an entire Sunday trying to get a complex formula to work. I ended up with #VALUE! errors splattered across my sheet, leading to frustration that lasted longer than I care to admit. My family could see my stress levels rising as I muttered incoherently about Excel's cryptic syntax. I wanted to blame the software, but the truth was, I was the one wrestling with messy data and unrealistic expectations on myself. The more I struggled, the more irrational I became.

The Fix

Enter Claude for Excel—a tool that instantly began to take the burden off my shoulders. After a brief introduction and tutorial, I realized this could be my new best friend in the world of data. The functionality was like getting handed a magic wand; it could analyze data without needing me to trip over complex formulas.

For example, I was once stuck trying to calculate the year-over-year growth of sales figures across various regions, which involved a spreadsheet of about 3,000 rows. Typically, I would have diced and sliced this data manually, hoping to avoid errors along the way. Instead, using Claude, I could simply upload my data set and ask it for the required analysis in plain language:

Analyze the sales data and show year-over-year growth by region.

Within seconds, not only did Claude give me the results, but it also generated a pivot table for me. I couldn't believe my eyes. The tool had processed the entire sheet seamlessly, saving me at least three hours of work. I was able to use the generated table to make decisions swiftly and present findings during Monday’s meeting with confidence. This was not magic—it was just a smart combination of AI and my ongoing need for efficiency.

Furthermore, when I felt extra adventurous, I asked Claude:

Show me the top 5 products based on customer feedback.

Again, I received a neat summary sans the usual headache.

The Bigger Principle Behind the Fix

What I learned through this process was simple yet profound: embracing tools that streamline techniques is essential. Rather than getting tangled in the complexity of data manipulation, using Claude for Excel allowed me to focus on what truly mattered—insightful analysis and decision-making. I began to see an increase in my productivity, as I could spend time analyzing results rather than scrambling over formulas. In concrete terms, I've gone from spending about 20 hours a month on data analysis down to fewer than 10.

So what's the bigger principle here? It's about understanding your limitations and recognizing when to employ technology that complements your skills. Claude for Excel shifted not only the way I handled data but also my perception of it. Instead of feeling overwhelmed, I started feeling empowered, knowing I had a sophisticated partner by my side.

Reflecting on the time wasted before discovering this tool, I can’t help but chuckle. I wish I had found it sooner. If you're knee-deep in data analysis and feel like you’re drowning in formulas, I highly recommend you take a look at Claude. Just make sure to remember the old saying: it's not about knowing it all, but knowing how to ask the right questions.

If you've had similar experiences with data tools, what’s the most significant win you've achieved with a new software? What one tool would you recommend to others drowning in data that could provide clarity without the headache?

I Struggled with a Bug for Days — Here's What I Learned About Clean Code and Debugging

Kiell Tampubolon — Thu, 07 May 2026 15:14:19 +0000

As I sat in front of my computer screen one humid evening in Batam, covered with the shadows of unfinished projects, I felt a sinking frustration deep in my chest. For days, I was plagued by a bug in a JavaScript function that seemed to mock me, with every test yielding inconsistent results. I was convinced I had a handle on clean code principles, but the hours spent chasing this elusive problem made me question everything I knew.

Context & Stakes

debugging effectively is essential for any developer, especially when working in tight deadlines or collaborative environments. I was leading a small team on a client project, a dynamic web application intended to streamline local business operations. Our success depended on delivering clean, efficient code, and I was the one responsible for reviewing and finalizing it. The stakes were high, and with each failed attempt to fix the issue, our timeline slipped further.

The bug originated in a function designed to fetch user data from an API, but the data only loaded half the time. After scanning and re-scanning the code, everything seemed fine — I had followed all the recommended practices. Yet, the problem persisted. This relentless loop of testing and frustration forced me to confront my limitations head-on. Would I be able to solve this before our deadline?

CHALLENGE

What I had overlooked was a crucial aspect of my code's asynchronous nature. Here’s the snippet that tripped me up:

async function fetchUserData(userId) {
  const response = await fetch(`https://api.example.com/users/${userId}`);
  if (!response.ok) {
    throw new Error('Network response was not ok');
  }
  const data = await response.json();
  return data;
}

At first glance, this code looked correct, but the challenge was in the way it interacted with the rest of the application. I was using this function in multiple places within the codebase, but because the API could occasionally be slow, I hadn’t handled the failures correctly in the components calling it. This led to intermittent fraying of user experience, with components loading only half the time or throwing unhandled errors.

I felt the weight of inefficiency weighing down my team. The pressure to deliver without compromising quality left me juggling multiple hats, and I realized that my understanding of clean, maintainable code had been superficial. I needed to dig deeper into both debugging techniques and code readability practices to navigate this complexity.

BREAKTHROUGH

The breakthrough came when I decided to systematically approach the problem. Instead of diving straight into fixing it, I first resurfaced and rewrote the function to make it clearer and more manageable:

async function fetchUserData(userId) {
  try {
    const response = await fetch(`https://api.example.com/users/${userId}`);
    if (!response.ok) {
      throw new Error('Network response was not ok');
    }
    return await response.json();
  } catch (error) {
    console.error('Fetching user data failed: ', error);  // Logging error with context
    return null;  // Handle this gracefully on the calling side
  }
}

By adding error handling and a try/catch block, I octupled my chances of catching errors early. However, the biggest revelation was shifting my mindset from fixing bugs to devising solutions that make the code robust against future issues. I took the time to document the expected outcomes in the comments as a reminder to myself and my teammates. This transparency in the code not only made it easier for us to follow, but it also set the stage for better collaboration.

DEEPER INSIGHT

Through this experience, I gleaned a larger principle: clean code is not just about aesthetics or following patterns; it is about making it maintainable and resilient. As developers, we must anticipate how our code may misbehave under unexpected conditions. The cleaner and more explicit we write our code, the easier it becomes for us and others to debug it — saving precious development time in the long run.

Additionally, the experience reinforced the idea that debugging is as much about mindset as it is about skill. It’s easy to get lost in the weeds of our code; stepping back to reassess the problem can sometimes bring clarity, especially with peer programming, where you can have a fresh set of eyes or someone to help brainstorm.

WHAT I'D DO DIFFERENTLY

Upon reflection, here are a few actionable steps I’d take to improve my approach to debugging and code quality moving forward:

Prioritize Error Handling: Always include explicit error handling strategies within asynchronous functions. Errors are inevitable; planning for them pays off.
Encourage Team Code Reviews: Foster a culture of peer reviews within your team. Fresh perspectives often unearth issues that one might overlook.
Document Potential Errors: Add comments to clarify how functions behave in edge cases. Documentation can be a lifesaver.
Test-Driven Development (TDD): Implement TDD practices for new features to catch bugs early in the development cycle, enhancing code reliability.
Set Up Monitoring: Utilize tools like Sentry to catch runtime errors and log issues transparently into the application, so you can react in real-time.

By taking these steps, I believe we can significantly minimize bugs and build a more resilient infrastructure for our applications.

CLOSING QUESTION

What debugging techniques or coding practices have you found essential in your own projects? How have you dealt with seemingly insurmountable bugs? Let's discuss in the comments!

I Deployed My First Cloudflare Worker — Here's What I Learned

Kiell Tampubolon — Wed, 06 May 2026 11:32:05 +0000

I sat there staring at the screen, my heart racing as I clicked 'deploy' on my first Cloudflare Worker. What should have been a straightforward process felt like a rollercoaster of confusion and excitement. Just moments before, I'd lined everything up: my code looked good, my environment seemed solid—how could anything go wrong?

But then it hit me. 401 Unauthorized. What? I hadn’t encountered this in all my testing. Little did I know, the culprit was hiding in the shadows of a misconfigured secret token, like a ghost refusing to leave its haunted house.

The Setup

Being a developer, I often toggle between creative solutions and technical bottlenecks. I’ve spent countless late nights coding, occasionally stacking hundreds of browser tabs filled with information, guides, and articles. Typical developer life, right? In an attempt to re-organize my chaotic digital world, I finally utilized Notion Web Clipper. It became my sidekick, ensuring that everything I stumbled upon would be neatly packed away for when I needed it. But nothing prepared me for the impending chaos with Cloudflare Workers.

I was eager to build a simple API service that could run globally. After all, deploying on Cloudflare should have been a piece of cake. I picked a couple of templates and dived in, but secret management? Talk about a headache! I had breezed through the initial setup, barely taking note of how tokens should be correctly managed in the environment variables.

The Challenge

The panic kicked in when my worker returned a loud, resounding 401 Unauthorized error. I felt defeated. It felt like grasping at straws, trying various approaches that led me further into confusion. I had mistakenly selected a template that wasn’t suitable for my use case, throwing my authorization strategy out the window like an old shoe.

The main issue was that I lost sight of what tokens I was using for authentication. I had multiple API keys lying around from various services, and sure enough, I grabbed the wrong one. It reminded me of those ‘SELECT A TEMPLATE’ dropdown menus you see on documentation pages that you just don’t read. Instead of reading through the instructions, I assumed I knew it all. Classic developer hubris.

The Breakthrough

Eventually, instead of banging my head against the desk, I took a deep breath and revisited the documentation for Cloudflare Workers. Turns out, the secret management was not just a convenient feature; it was crucial for keeping my application secure and functional. They even had detailed instructions on how to handle these secrets correctly.

I quickly updated my API tokens using Cloudflare's secret management tools with these steps:

Revisit the dashboard: Ensure that you've saved your tokens properly.
Use .env file: If you're unsure of where to place your secrets, Cloudflare Workers let you conveniently manage these in the dashboard.
Go with the right template: Choose wisely! The correct template would seamlessly integrate with your authentication flow.

After implementing the right token, I deployed it again. It felt surreal to see the 200 OK response this time; everything felt right in the world again.

Deeper Insight

What I realized through this whole ordeal is much larger than just the technical issue. It served as a reminder of the importance of understanding the tools we use—rushing into a setup without learning the fundamentals can be disastrous. This situation taught me that our tools can either propel our success or hinder it, and we should respect the complexity involved in building software. Reading documentation isn’t just for beginners; it’s for anyone looking to level up.

In my experience, spending a bit more time upfront in understanding the scope and limits of what I was working on saved me hours of troubleshooting later.

What I'd Do Differently

Take Notes: Throughout the cloud worker setup, I started losing track of what I was doing. If I’d kept notes or a checklist, I could’ve avoided such an embarrassing mistake.
Don’t Rush: I was so eager to deploy my worker that I skimmed through critical documentation. In the future, I'll be more patient and thorough.
Debugging Tools: Use Cloudflare's built-in development tools. They can help you pinpoint those pesky authorization issues sooner.
Ask for Help: Instead of trying to figure it all out alone, asking in developer communities could save time—like moments of doubt and confusion I faced.

Closing Question

Have you ever overlooked an essential detail in your development work that led to a frustrating error? How did you recover, and what lessons did you take away from it? I’d love to hear your stories in the comments!