Forem: Hari Venkata Krishna Kotha

RTK, Model Routing, and the Community Tools That Actually Work With Claude Code

Hari Venkata Krishna Kotha — Tue, 07 Apr 2026 13:00:22 +0000

This is Part 2 of a series on getting more out of Claude Code. Part 1 covered the 50,000 token overhead problem, the 44% reduction fix, and the memory/lessons.md system.

In Part 1, I mentioned RTK saved me 60-90% on tool output tokens. This post goes deeper: how RTK actually works under the hood, the difference between Unix and Windows installations, model routing for subagents, environment variables for cost control, and 7 community tools I tested (most of which I didn't end up using).

RTK: How It Actually Works

RTK (Rust Token Killer) is a Rust-based CLI proxy that intercepts shell commands, runs them, and compresses the output before it reaches your AI tool's context window. It supports 10+ AI coding tools including Claude Code, GitHub Copilot, Cursor, Gemini CLI, Codex, Windsurf, Cline, and OpenCode, but this post focuses on Claude Code.

Version note: RTK is actively developed. The latest release is v0.35.0 (April 6, 2026), which expanded AWS CLI filters. I'm running v0.34.2 in this post — features and exact command output may differ slightly in newer versions.

RTK applies four optimization strategies to every CLI command output before it enters your context window:

Raw Output (5,000 tokens)
    ↓
Smart Filtering (remove ANSI codes, spinner artifacts, progress bars)
    ↓
Grouping (consolidate related output lines, collapse repeated patterns)
    ↓
Deduplication (deduplicate repeated patterns like passing tests)
    ↓
Truncation (keep errors/warnings, trim verbose success output)
    ↓
Filtered Output (500-2,000 tokens)

Why This Matters More Than You Think: The Re-Read Tax

This is the concept that changed how I think about Claude Code optimization.

When Claude runs a command, the output stays in context. On the next turn, Claude re-reads ALL prior context, including every command output from earlier in the session. Then on the turn after that, it re-reads everything again.

Here's the math. Say you run git diff and it produces 2,000 tokens of output. Over a 10-turn conversation after that command:

Turn 1: 2,000 tokens read
Turn 2: 2,000 tokens re-read
Turn 3: 2,000 tokens re-read
...
Turn 10: 2,000 tokens re-read
Total: 20,000 tokens consumed from one command

With RTK compressing that diff to 800 tokens (59% reduction):

Total: 8,000 tokens instead of 20,000
Savings: 12,000 tokens from a single command

Now multiply across 80+ commands in a real coding session. From my actual work building a .NET 10 Blazor application: 80 RTK commands, 152K input tokens, 39K output tokens, 113.6K tokens saved at 74.6% efficiency. The re-read savings compound on top of that — each saved token gets re-read on every subsequent turn, so the actual context reduction is a multiple of the direct savings.

Unix vs Windows: Two Different Integration Models

This is something the README doesn't make obvious. RTK works fundamentally differently depending on your OS.

Unix (macOS/Linux) uses Hook Mode:

How it works:
1. RTK installs a PreToolUse hook in Claude Code's hooks system
2. When Claude runs any Bash command, the hook rewrites the command BEFORE execution
   (e.g., git status becomes rtk git status)
3. RTK filters the output transparently
4. Claude doesn't know RTK exists

Token overhead: 0
Setup: rtk init -g --hook-only

The --hook-only flag is important. Without it, RTK also creates an RTK.md file with instructions for Claude. But since the hook works transparently (Claude doesn't need to know about RTK), that file adds unnecessary per-turn overhead for zero benefit.

Windows uses CLAUDE.md Mode (the only option on Windows):

How it works:
1. RTK adds instructions to ~/.claude/CLAUDE.md
2. These instructions tell Claude: "prefix all Bash commands with rtk"
3. Claude reads the instructions every turn and writes: rtk git status
4. RTK binary filters the output

Token overhead: the CLAUDE.md instructions add some per-turn overhead
Setup: rtk init -g --claude-md

Windows can't use hook mode. When you run rtk init -g on Windows, RTK explicitly tells you "Hook-based mode requires Unix (macOS/Linux)" and falls back to --claude-md automatically. Note that --claude-md is now labeled "legacy mode" in the latest RTK help text (v0.34+), but on Windows it remains the only working option.

Is the CLAUDE.md overhead worth it on Windows?

Yes. A single rtk git diff typically saves more tokens than the instructions cost. A single rtk pytest can save thousands of tokens. The overhead pays for itself on your first filtered command, and every command after that is pure savings.

Installing RTK on Windows: Step by Step

This is what I actually did. Recording it because several things aren't obvious from the docs:

# Step 1: Install RTK
# Option A: Homebrew (macOS)
brew install rtk

# Option B: Curl installer (macOS/Linux)
curl -fsSL https://raw.githubusercontent.com/rtk-ai/rtk/refs/heads/master/install.sh | sh

# Option C: Cargo (Windows — use Git Bash, not PowerShell)
cargo install --git https://github.com/rtk-ai/rtk

# Step 2: Find where cargo put the binary (Windows only)
# Usually: C:\Users\<username>\.cargo\bin\rtk.exe
# Add this to your system PATH if it's not already

# Step 3: Initialize for Claude Code
rtk init -g --claude-md

# Step 4: Verify it works
rtk --version
rtk git status

Things that tripped me up:

cargo install rtk (without the git URL) installs the wrong package (Rust Type Kit, a completely different tool). Always use the full git URL.
Run from Git Bash, not native PowerShell. Some RTK shell integrations assume bash.
If you use VS Code's integrated terminal, make sure it's set to Git Bash, not PowerShell.
The binary path needs to be in your PATH environment variable for Claude Code to find it.

RTK Configuration

RTK stores config at:

Windows: %APPDATA%\rtk\config.toml (or ~/.config/rtk/config.toml in Git Bash)
macOS/Linux: ~/.config/rtk/config.toml

Two settings worth knowing:

# Exclude specific commands from filtering
# (if RTK strips output you actually need to see)
[hooks]
exclude = ["some-command-that-needs-raw-output"]

# Tee: saves raw output when commands fail
# Your safety net if RTK strips a critical error message
[tee]
enabled = true
rotation_limit = 5

The tee feature is like a flight recorder on an airplane. During normal operation, you never need it. But if RTK strips a critical error and Claude misses a bug, you can recover the unfiltered output.

Measuring Your Savings

# Cumulative savings across all sessions
rtk gain

# Per-command breakdown
rtk gain --history

# Find commands you ran WITHOUT rtk that could have been filtered
rtk discover

Here's the actual rtk gain output from my work laptop while building a .NET 10 Blazor application:

74.6% efficiency across 80 commands. 113,600 tokens saved. The rtk dotnet test filter alone saved 108K tokens across 19 runs. dotnet test output is verbose by default (test discovery, build output, individual test results, summary), and RTK strips it down to just failures and counts.

The rtk discover command is the most useful when starting out. It scans your session logs and shows commands you ran without the rtk prefix that could have been filtered. Basically shows you your missed savings.

Commands Worth Knowing

A few commands that aren't in the basic README but are useful:

# Show your RTK adoption across recent Claude Code sessions
rtk session

# Claude Code spending vs RTK savings analysis
rtk cc-economics

# Filter for .NET commands (build, test, restore, format)
rtk dotnet test
rtk dotnet build

# Learn CLI corrections from your error history
rtk learn

The rtk dotnet filter is the one that produced 99% savings on my tests. If you're a .NET developer, that filter alone justifies the install. There are similar specialized filters for Cargo, Vitest, Pytest, Playwright, Prettier, Prisma, Next.js, ESLint, TypeScript, Docker, kubectl, and around 100+ commands total.

When RTK Shines vs When It Doesn't

This is the most important thing to understand about RTK, and nobody talks about it: RTK only intercepts Bash commands. Claude Code's built-in tools (Read, Write, Edit, Grep, Glob, WebFetch, WebSearch) bypass Bash entirely and never touch RTK.

In a typical Claude Code session, you might run 5-10 Bash commands vs 50-100 dedicated tool calls. If your session is mostly Read/Edit/Grep operations, RTK savings will be minimal — not because RTK is broken, but because there's nothing for it to intercept.

RTK shines in sessions where Bash is heavily used:

Running builds: rtk dotnet build, rtk cargo build, rtk next build
Running tests: rtk dotnet test, rtk vitest run, rtk pytest, rtk playwright test
Git operations: rtk git diff, rtk git log, rtk git status
Package managers: rtk pnpm install, rtk npm run build
Docker/K8s: rtk docker ps, rtk kubectl get pods

This is exactly what my work data showed: 80 commands, 74.6% efficiency, and the biggest savings came from rtk dotnet test (99% reduction across 19 runs). When I'm building features and running test suites repeatedly, RTK saves real tokens. When I'm in a code review session reading files and editing inline, RTK has nothing to do.

Sessions where RTK savings are minimal:

Conversation-heavy sessions (design discussions, explanations)
Code review sessions (mostly Read/Edit dedicated tools)
File search and exploration (Grep/Glob dedicated tools)
Very short sessions (1-3 turns) — the re-read tax hasn't compounded yet

This isn't a bug. It's a fundamental architecture choice. If you're optimizing token usage, install RTK AND make sure you're using dedicated tools instead of cat/head/find/grep via Bash. Both matter.

Model Routing: Stop Burning Opus Tokens on File Searches

If you're on Opus (or even Sonnet), every subagent Claude spawns runs on the same model by default. That means when Claude kicks off a code-reviewer agent, an exploration search, or a simple git status check through a subagent, it burns your most expensive tokens.

The fix is adding model routing rules to your global rules files. I created a performance.md in ~/.claude/rules/common/ with explicit model assignments:

Use Haiku for:

File search, grep, glob, codebase exploration
Summarizing search results or documentation
Simple formatting, renaming, mechanical edits
Reading and reporting file contents
Git status checks, log summaries

Use Sonnet for:

Code generation, implementation, refactoring
Code review
Test writing
Build error fixing
Planning and documentation

Use Opus only for:

Architecture decisions requiring multi-system reasoning
Deep debugging across 5+ files with complex interactions
Multi-dimensional analysis tasks

The rule file sets the default subagent model to Sonnet and lists specific overrides. Claude Code reads this on every session and applies the routing automatically when spawning subagents with the model parameter.

This doesn't change your main conversation model. It only affects subagents. But subagents can account for a significant portion of token usage in complex sessions, especially when Claude spawns multiple exploration or review agents.

Environment Variable Worth Setting

One variable that gives you cost control without changing your workflow:

# Cap extended thinking tokens (default is 31,999 which can be excessive)
export MAX_THINKING_TOKENS=10000

# These go in your shell profile (~/.bashrc, ~/.zshrc,
# or Windows environment variables)

MAX_THINKING_TOKENS is the most impactful. Claude's extended thinking can use up to 32K tokens of internal reasoning before responding. For most tasks, 10K is more than enough. The default is generous and burns tokens on over-analysis.

7 Community Tools I Tested (And Why I Kept Only 2)

I deep-researched seven community tools that claim to enhance Claude Code. Here's the honest breakdown:

Tools I Kept

1. RTK (Rust Token Killer) — Already covered above. The single most impactful optimization tool.

2. lessons.md Pattern (from CCO/Claude Code Optimization) — Not really a "tool," but a methodology. Keep a lessons.md file in each project, write a rule every time you correct Claude. Simple, effective, zero overhead. Covered in Part 1.

Tools I Evaluated and Skipped

3. claude-mem (Memory Manager)
Promises persistent memory across sessions via an embedded vector database. Sounds great in theory. Concerns I found during evaluation:

Has reported Windows compatibility issues including a multi-GB ONNX model download requirement
The built-in memory system in ~/.claude/projects/<project>/memory/ already handles persistent memory with simple markdown files, no vector DB needed
Verdict: Skip on Windows. Linux/Mac users may have a smoother experience.

4. CCO (Claude Code Optimizer)
A package of configuration files (skills, rules, agents) designed for Claude Code. The self-improvement loop pattern (lessons.md) is genuinely useful and I adopted it. But the rest of the configuration overlapped heavily with what I already had from Everything Claude Code.

Verdict: Adopt the lessons.md pattern. Skip the rest if you already have ECC.

5. Superinterface / CLine / Similar IDE Extensions
Various tools that wrap Claude Code with additional UI. The problem: Claude Code already works well in the terminal and VS Code. Adding another layer introduces latency, potential conflicts, and more things that can break.

Verdict: Unnecessary complexity for most workflows.

6. Custom MCP Servers for Token Tracking
Some community members built MCP servers that track token usage per conversation. Interesting idea, but RTK's rtk gain command already gives you this data without the setup overhead.

Verdict: RTK covers this use case.

7. Automated Session Management Tools
Tools that auto-compact, auto-checkpoint, or auto-restart sessions. The problem is they make assumptions about when you want to compact or restart. Claude Code's built-in compaction (with the strategic-compact skill nudging you at good breakpoints) worked better for me than automated approaches.

Verdict: Use the strategic-compact skill instead.

The Pattern

Most community tools try to solve problems that Claude Code already handles, just not obviously. Before installing any third-party tool, check if there's a built-in feature, a rule file, or a skill that does the same thing with less overhead.

The Complete Optimization Stack

Here's everything I run, in priority order:

#	What	Token Impact	Setup Time
1	RTK	60-90% tool output savings	30 seconds
2	Environment variables (MAX_THINKING_TOKENS)	Caps runaway thinking	10 seconds
3	Skills audit (global vs project-level)	Frees 74% of skill overhead	15 minutes
4	Model routing rules	Routes subagents to cheaper models	10 minutes
5	Memory system (user + feedback files)	Smarter responses across sessions	10 minutes
6	lessons.md file	Permanent mistake prevention	30 seconds to create

Total setup time: under 30 minutes. The compound savings across a week of coding sessions add up fast.

Part 1 covered the token overhead problem and the 44% fix. Parts 3 and 4 (Skills.sh ecosystem guide and curated skills by category) are in the works.

How I cut Claude Code's token overhead by 44% and stopped hitting usage limits mid-session.

Hari Venkata Krishna Kotha — Tue, 24 Mar 2026 13:41:55 +0000

I'm on a paid Claude Code plan. A few weeks ago, I noticed my usage limits were hitting way faster than expected. I wasn't doing anything unusual, just regular development work. But Claude kept running out of context mid-conversation, forgetting things I'd said 10 messages ago, and compacting earlier than it should. (Compaction is when Claude Code summarizes earlier messages to free up context space. When it happens too early, you lose nuance and detail from earlier in the conversation.)

I went looking for answers. LinkedIn, Dev.to, Instagram, Reddit. Most articles said the same things, and honestly, half of them were copies of each other. Token reduction tips, useful skills lists, prompt tricks. I decided to stop bookmarking and start testing. Tried every method I came across, measured the results, and kept what actually worked.

Here's what I found.

The 50,000 Token Problem You Don't Know You Have

When you install skills in Claude Code, their metadata loads into your context window on every single message. And when a skill's trigger matches your prompt, the full content loads too. The more skills you have installed, the more metadata overhead you carry per turn, and the more likely full skill content gets pulled in during a busy session.

I came across the Everything Claude Code repository and was honestly amazed. Skills, agents, commands, rules, all packaged together. So I did what most people would do: installed everything globally.

That was a mistake.

Here's what my setup looked like before I realized the problem:

Component          Size       Estimated Tokens
Skills (global)    196KB      ~50,000
Agent definitions  58KB       ~15,000
Command files      142KB      ~36,000
Rule files         9KB        ~2,000
TOTAL              405KB      ~103,000 tokens

(Rough estimate: 1KB of text ≈ 250 tokens. Not all of this loads on every turn because skills use progressive disclosure, loading only metadata first and full content when triggered. But the potential overhead is still massive, and in practice, a busy session triggers many of them.)

Over 100,000 tokens of potential overhead sitting in my setup. That's a significant chunk of Claude's context window spent on instructions, most of which weren't relevant to what I was doing at that moment.

No wonder my conversations were getting compacted early. No wonder Claude was "forgetting" things. There wasn't enough room left for the actual work.

How to Check Your Own Overhead

Before you do anything else, run this in your terminal (Windows users: use Git Bash, not PowerShell):

du -sh ~/.claude/skills/ ~/.claude/agents/ ~/.claude/commands/ ~/.claude/rules/

Reading your results:

Each line shows the size of a directory. Add them up for your total overhead.

Example output:

144K    /Users/you/.claude/skills/
76K     /Users/you/.claude/agents/
172K    /Users/you/.claude/commands/
9K      /Users/you/.claude/rules/

That's 401KB total. To estimate tokens, multiply your total KB by 250 (1KB ≈ 250 tokens). So 401KB ≈ 100,000 tokens of potential overhead. Not all of it loads every turn (skills use progressive disclosure), but the more skills you have, the more likely multiple will trigger and load fully during a session.

If your skills directory alone is over 100KB, you're almost certainly carrying skills you don't use in most projects.

For context, my setup was 405KB before I touched anything. After moving domain-specific skills to project level and cleaning up unused agents, it dropped to 232KB. Same capabilities, 44% less overhead.

The Fix: 44% Reduction in One Afternoon

The principle is simple: only keep things globally that you use in 80%+ of your projects. Everything else goes to project level, where it only loads when you're working in that specific project.

I went from 20 global skills down to 6. The other 14 moved to the projects that actually needed them.

Component          Before     After      Saved
Skills (global)    196KB      51KB       145KB (74% reduction)
Agent definitions  58KB       52KB       6KB
Command files      142KB      120KB      22KB
Rule files         9KB        9KB        0KB (modified, not reduced)
TOTAL              405KB      232KB      173KB (~44% reduction)

What I kept globally (the skills I use in every project):

Coding standards (applies to every language)
Security review (should check this everywhere)
TDD workflow (I practice TDD daily)
Verification loop (prevents claiming things are done before checking)
Strategic compaction (suggests when to compact context manually)
Continuous learning (tracks patterns across sessions)

What I moved to project level:
Docker patterns, Python patterns, React patterns, e2e testing, eval harness, iterative retrieval, full-stack patterns, and several others. These are useful but only in specific projects. Loading Docker patterns while I'm writing documentation is pure waste.

The difference was immediate. Conversations lasted longer before compaction. Claude held context from earlier in the session. Fewer "I don't have context on that" moments.

The Tool Output Problem Nobody Talks About

Most optimization advice focuses on what's loaded at the start of a conversation: skills, rules, CLAUDE.md. But there's another source of token waste that's just as big, and almost nobody mentions it.

Every time Claude runs a CLI command (git status, npm test, a build command), the raw output gets dumped into the context window. And here's the thing most people miss: that output gets re-read on every subsequent turn. It doesn't disappear.

Think about it this way. You ask Claude to run your test suite. The output is 5,000 tokens. 4,950 of those tokens are passing tests. 50 tokens are the actual failures you care about. But all 5,000 tokens sit in context and get re-read on turn 2, turn 3, turn 4, and every turn after.

Over a 20-turn session with 50 tool calls, you can easily accumulate 100,000+ tokens of tool output. Most of it noise.

RTK: The Token Saver That Actually Made a Difference

RTK (Rust Token Killer) is an open-source tool that filters CLI output before it enters Claude's context window. It applies four optimization passes: smart filtering (removes noise), grouping (aggregates similar items like errors by type), truncation (keeps relevant context, cuts redundancy), and deduplication (collapses repeated log lines with counts).

Real savings from my sessions:

Command Category	Example Commands	Token Savings
Build output	cargo build, tsc, next build	80-90%
Test output	vitest, pytest, playwright	90-99%
Git operations	git status, git diff, git log	59-80%
File listings	ls, find, grep	60-75%

The way I explain it to people: imagine you ask a librarian to check something. Without RTK, the librarian carries back the entire bookshelf, drops it on your desk, and says "the answer is on page 47." With RTK, the librarian comes back with just page 47, highlighted. Same answer. But your desk isn't buried anymore.

Installing RTK

# macOS/Linux (recommended)
brew install rtk

# Or via Cargo (IMPORTANT: do NOT run "cargo install rtk" without
# the git URL — that installs "Rust Type Kit", a completely
# different package. If "rtk gain" fails, you have the wrong one.)
cargo install --git https://github.com/rtk-ai/rtk

# Or via quick-install script
curl -fsSL https://raw.githubusercontent.com/rtk-ai/rtk/refs/heads/master/install.sh | sh

# Then add to Claude Code globally
rtk init -g

On Unix (macOS/Linux), RTK installs as a PostToolUse hook. It works transparently. Claude doesn't even know it's there. Zero token overhead.

On Windows, it works through Git Bash. The hook and RTK.md get installed the same way. If you're using Claude Code with Git Bash as your shell (which most Windows developers do), the experience is identical to macOS/Linux. The RTK.md file that gets created adds about 1,200 tokens of instructions, but a single filtered git diff saves more than that. Net positive after your first tool call.

Windows-specific tips:

Download the pre-built binary from the releases page (rtk-x86_64-pc-windows-msvc.zip), or install via cargo install --git https://github.com/rtk-ai/rtk in Git Bash
Make sure the binary path is in your system PATH
Run rtk init -g the same as on Unix
Run from Git Bash, not native PowerShell (some shell integrations assume bash)

Measuring Your Savings

RTK has built-in analytics:

# See your cumulative savings
rtk gain

# See savings per command type
rtk gain --history

# Find commands you ran WITHOUT rtk that could have been optimized
rtk discover

The rtk discover command is the most useful one when you're starting out. It scans your Claude Code session logs and shows you exactly which commands you could have filtered but didn't.

The Memory System That Stops Claude From Asking the Same Questions

The last piece that made a real difference wasn't about reducing tokens. It was about making Claude smarter across sessions.

Claude Code has a file-based memory system at ~/.claude/projects/<project>/memory/. You create markdown files with frontmatter and Claude reads them at the start of every session.

I use four types:

User memories: Who I am, my tech stack, my preferences. Instead of explaining my setup every session, Claude already knows.

Feedback memories: Every time I correct Claude, the correction gets saved. "Use plain text in forms, not bullets." "Don't suggest tools I haven't used." Claude stops repeating the same mistakes.

Project memories: Current state of work. Deadlines, decisions, context that would otherwise be lost between sessions.

Reference memories: Where to find things in external systems. "Bug tracking is in Linear project X." Saves the "where is that tracked?" conversation every time.

lessons.md: One File That Changes Everything

This is the simplest thing I did and possibly the most impactful. I keep a lessons.md file in every project's .claude/ directory. Every time I correct Claude on something, it writes a rule:

## 2026-03-15 - Don't add error handling for impossible cases

**Rule:** Only add try-catch blocks at system boundaries (user input,
API calls, file I/O). Don't wrap internal function calls that can't
realistically fail.
**Why:** Added defensive error handling around a pure math function.
User said "this function takes two integers and adds them, it can't
throw. You're adding complexity for nothing."
**Applies when:** Writing or reviewing error handling in any codebase.

Claude reads this file at the start of every session. The correction sticks permanently. Over a few weeks, the file becomes a precise set of rules that make Claude work exactly the way you need.

The principle is simple: never correct the same mistake twice. The first correction is a lesson. The second one means the system failed.

The Priority Order

If you're starting from scratch, here's what I'd do in order:

Priority	What	Effort	Impact
1	Install RTK	30 seconds	60-90% tool output savings
2	Audit global skills, move domain-specific to project level	15 minutes	Free up context window
3	Set up basic memory files (user profile + 2-3 feedback entries)	10 minutes	Smarter responses, fewer repeated mistakes
4	Start a lessons.md file	30 seconds to create, 30 seconds per correction	Permanent mistake prevention
5	Set MAX_THINKING_TOKENS env variable	10 seconds	Cap runaway thinking, save tokens on over-analysis
6	Add model routing rules for subagents	10 minutes	Route exploration/search subagents to cheaper models

None of this is complicated. Most of it takes less than 15 minutes. But the compound effect of doing all six is significant: longer sessions, better context retention, fewer repeated mistakes, and lower token bills.

The tools are there. Most people just don't know they exist, or don't realize how much overhead they're carrying.

This is Part 1 of a series on getting more out of Claude Code. Part 2 covers RTK in depth, including Windows setup, configuration, subagent behavior, and community tools that complement it.

The Full Audit: What a 9-Project Microservices Platform Looks Like When 78% of the Code is AI-Generated

Hari Venkata Krishna Kotha — Thu, 12 Feb 2026 14:01:39 +0000

I spent 7 weeks building ... then several more weeks auditing, documenting, and hardening DesiCorner - a production-grade Indian restaurant e-commerce platform with 9 .NET and Angular projects, 5 databases, and a full Angular frontend. Claude Code wrote 78% of the code. I wrote 9%. Auto-generated tooling (EF Core migrations, Angular CLI scaffolding, package configs) handled the remaining 13%.

I tracked everything. Every commit, every bug, every file. This is the full audit.

What I Built

DesiCorner is an Indian restaurant ordering platform. Not a tutorial project - a full-featured e-commerce system with authenticated and guest checkout, Stripe payments, an admin dashboard with analytics, product reviews with voting, coupon management, and delivery/pickup order types.

The tech stack:

Backend: ASP.NET Core 8 across 8 .NET projects - AuthServer (OpenIddict OAuth 2.0), API Gateway (YARP), ProductAPI, CartAPI, OrderAPI, PaymentAPI (Stripe), a shared Contracts library (41 DTOs across 9 subdomains), and a MessageBus abstraction layer (Redis caching, Azure Service Bus scaffolded).

Frontend: Angular 20 with standalone components, NgRx state management, OAuth 2.0 Authorization Code + PKCE flow, and Stripe Elements for PCI-compliant payment forms.

Infrastructure: 5 separate SQL Server databases (one per service), Redis for distributed caching/sessions/rate limiting, and a branch-per-feature Git workflow with 68 commits across 15 branches and 22 merged PRs.

The architecture:

Every project has its own README with Mermaid diagrams documenting the actual API flows verified against source code. Each microservice gets its own database and responsibility boundary.

Authentication uses OAuth 2.0 Authorization Code + PKCE - the Angular SPA never touches a client secret:

No client secret in the browser. No password sent to the token endpoint. The code_verifier proves the token request came from the same client that started the flow.

The Numbers

Here's the part that matters. I audited the entire codebase commit-by-commit and produced a file-level attribution of who wrote what:

Category	Me	Claude
Project vision and concept	100%	0%
Architecture decisions	70%	30%
Technology selection	100%	0%
Backend model definitions (field choices)	60%	40%
Backend service/controller code	10%	90%
Angular scaffold and components	5%	95%
Configuration values (appsettings)	100%	0%
Bug identification	90%	10%
Bug resolution code	40%	60%
Security management	100%	0%
Git workflow (branching, PRs)	100%	0%
Testing and validation	100%	0%
Product images and assets	100%	0%
Documentation (READMEs, diagrams)	30%	70%

By raw line count: Claude generated roughly 38,000 lines (78%), I wrote about 4,500 lines (9%), and auto-generated tooling produced roughly 6,000 lines (13%).

The attribution methodology: commits with thousands of well-structured lines in a single commit strongly suggest AI generation. Small, targeted 2-10 line fixes with debugging context suggest human authorship. The .claude/settings.local.json file first appeared on Dec 5, 2025, confirming Claude Code usage from that date. Earlier attributions are inferred from these patterns.

Look at where the 100%-me rows cluster: vision, technology selection, configuration, security, git workflow, testing. Now look at where Claude dominates: service code, Angular components, documentation generation. The pattern is clear - I was the architect and Claude was the builder.

The Bugs That Proved the Point

Twelve bugs emerged during development. I identified eleven of them. Here are the three that taught me the most.

Bug 1: The JWT Remaster (November 12-13, 2025)

JWT tokens from the AuthServer were being rejected by ProductAPI when routed through the Gateway. Everything looked correct on the surface. It took two days to untangle three separate issues hiding behind the same 401 response.

Here's the token flow -- every arrow was a potential failure point:

Audience mismatch. The AuthServer issued tokens with audience desicorner-api, but ProductAPI validated against DesiCorner.ProductAPI. Different strings, same intent, total failure. Fix: align JwtSettings:Audience across all services.

Signing key conflict. ProductAPI was doing manual symmetric key validation, but the AuthServer was using OpenIddict's ephemeral signing keys. They'd never match. Fix: switch ProductAPI from hardcoded key validation to auto-fetching JWKS from the AuthServer's discovery endpoint.

CORS trailing slash. The Gateway's CORS policy name was "Angular" in one place and "desicorner-angular" in another. URLs had inconsistent trailing slashes between services. Fix: standardize naming and URL formats.

Three bugs, three different root causes, one symptom. I diagnosed all three through token validation logs and systematic elimination. Claude helped implement the JWKS auto-fetch after I identified what needed to change.

This is the kind of debugging where you can't just paste an error message into an AI and get an answer. The error message was the same for all three issues: 401 Unauthorized. The diagnosis required understanding how tokens flow across service boundaries, which configuration values matter at each hop, and the difference between OpenIddict's signing behavior and standard symmetric JWT validation.

Bug 2: Stripe Secret Key Exposure (December 5, 2025)

During the Stripe payment integration, I committed a live Stripe secret key to source control. I caught it within minutes, reverted the commit immediately, and re-committed with placeholder values.

The lesson isn't that I made the mistake - everyone has committed a secret at some point. The lesson is that security awareness during development is a human responsibility. You have to know what a secret key looks like, understand the implications of exposure, and react immediately. Yes, tools like GitGuardian and GitHub's push protection can catch these automatically - but the instinct to check before pushing, and the speed to react when something slips through, still matters.

Bug 3: The Admin Dashboard Cascade (December 18-23, 2025)

Every single admin dashboard API call returned 401 or 403. The first fix attempt on Dec 19 adjusted auth attributes - it didn't fully resolve the issue. The final fix on Dec 23 touched 23 files across 3 services because the root cause was actually four interrelated problems:

Admin role claim wasn't properly included in JWT tokens from the AuthServer
CartAPI was completely missing JWT validation configuration
The Order model was missing an OrderType field, causing analytics queries to fail
Delivery address fields were required but should be optional for pickup orders

I identified all four root causes through systematic debugging. Claude implemented the fixes after I mapped out what was broken and why. This is the kind of multi-service cascade failure where you need to understand how the entire system connects - not just the service throwing the error.

The FinTrack Contrast

To test the other end of the spectrum, I also had Claude Code build a completely separate project: a 5,597-line single-file HTML personal finance tracker. I provided product requirements and feature specs. Claude wrote all the code in about a week.

It ran. It looked right. But features had subtle issues I had to catch and send back for correction. The same pattern happened repeatedly on DesiCorner - AI-generated code that works on the surface but needs a human to validate the actual behavior against the intended requirements.

The difference between the two projects: I can defend every architectural decision in DesiCorner. I can explain why YARP instead of Ocelot, why OpenIddict instead of IdentityServer, why separate databases per microservice instead of a shared database. I can walk through every bug and explain how I traced the root cause.

For FinTrack, I can explain what it does and what the requirements were. But I can't defend the code decisions because I didn't make them. That's the difference between being an engineer and being a product manager who uses AI tools.

What I Learned

The skills that carried this project:

Architecture - deciding which services to build, how they communicate, which technologies fit, and where the boundaries should be. Claude could suggest options when asked. But evaluating tradeoffs against my specific requirements and committing to a direction - that was mine.

Debugging distributed systems - tracing failures across service boundaries, reading token validation logs, understanding how configuration values propagate through a microservices system. The JWT Remaster bug would have been trivial in a monolith. In a distributed system with an API Gateway, an AuthServer, and downstream services each with their own JWT validation config, it required understanding the full request lifecycle.

Security awareness - knowing what credentials look like, reacting to exposure, managing secrets across 5+ configuration files, understanding OAuth 2.0 flows well enough to spot misconfiguration.

Validation - not trusting that "it runs" means "it's correct." This applies equally to AI-generated code and to your own code, but the failure mode is different with AI. AI-generated code often fails in ways that look right at first glance.

Domain knowledge - knowing that an Indian restaurant platform needs dietary flags (vegetarian, vegan, gluten-free), spice levels, allergen tracking, and that pickup orders shouldn't require a delivery address. Claude couldn't infer these requirements. I had to specify them:

// Product.cs - domain fields I specified, Claude implemented
public bool IsVegetarian { get; set; }
public bool IsVegan { get; set; }
public bool IsSpicy { get; set; }
public int SpiceLevel { get; set; }        // 0-5 heat scale
public string? Allergens { get; set; }      // nuts, dairy, gluten
public int PreparationTime { get; set; }    // minutes

These six fields represent domain knowledge that no AI would infer from "build an Indian restaurant platform." The SpiceLevel scale, the nullable Allergens as a comma-separated string, the PreparationTime default of 15 minutes - every field choice came from understanding the domain.

The Full Report

I wrote a 2,000-line development report that documents every commit, every file-level attribution, every bug with its resolution, and the complete contribution breakdown. Full transparency on who wrote what and why.

The repo, including 10 per-project READMEs with Mermaid architecture diagrams:

github.com/HariVenkataKrishnaKotha/DesiCorner

The Takeaway

AI wrote 78% of this project's code. That percentage will probably go higher on my next project. The question isn't whether AI can generate code - it obviously can, at scale, and it's getting better.

The question is whether you can architect a system, debug it when it breaks across service boundaries, catch what the AI missed, and take ownership of decisions that have downstream consequences. Those skills aren't about typing speed. They're about engineering judgment.

The value isn't in the code anymore. It's in everything around the code.

What's been your experience with AI coding tools on non-trivial projects? I'm especially curious about debugging stories - the moments where AI-generated code failed in ways that required real engineering to fix. Drop a comment or find me on LinkedIn.