DEV Community: James Heal

Anthropic Epic Fail: What Secrets Are Hiding in Claude Code Source?

James Heal — Wed, 01 Apr 2026 07:36:01 +0000

On March 31st, Anthropic screwed up again — all 512,000 lines of Claude Code source code leaked. And yes, this is the second time.

My timeline exploded yesterday. Security researcher Chaofan Shou tweeted that Claude Code's source code had leaked through a source map in the npm registry. Within hours, 512K lines of TypeScript were mirrored on GitHub. The claw-code repo hit 50K stars in just two hours. Developers everywhere were tearing apart Anthropic's internals like Christmas morning.

This is the same Anthropic that just raised $30 billion at a $380 billion valuation. Claude Code doubled its revenue in the first three months of 2026, hitting a $2.5 billion annual run rate — 2.5x OpenAI's comparable product. And all of it got stripped naked by a single .map file.

DMCA takedown notices went out, but you know how the internet works — there's no delete button.

I spent a full day reading through the code. No fluff, just the goods — 6 secrets buried in the source, and the architectural truth behind 512K lines of code.

The Leak: A .map File Disaster (Again)

The story is simple and absurd.

When Anthropic published @anthropic-ai/claude-code v2.1.88, the npm package included a 59.8 MB cli.js.map file. This wasn't a normal source map — it contained the full sourcesContent, every single line of original TypeScript intact. Even worse, the map pointed to a zip archive on Anthropic's own Cloudflare R2 storage bucket, directly downloadable.

No hackers. No insider leak. Just a botched .npmignore. 512K lines of code, wide open.

The kicker? This exact same thing happened in February 2025. Same source map, same mistake. Anthropic clearly learned nothing.

Their official response came quick:

"This was a release packaging issue caused by human error, not a security breach."

Good news: no user data leaked. Bad news: the full implementation details of their most valuable AI Agent product are now public knowledge.

Secret #1: Poisoning Competitors with Fake Tool Injection

This one stopped me cold.

In src/services/api/claude.ts:

// Anti-distillation: send fake_tools opt-in for 1P CLI only
if (
  feature('ANTI_DISTILLATION_CC')
    ? process.env.CLAUDE_CODE_ENTRYPOINT === 'cli' &&
      shouldIncludeFirstPartyOnlyBetas() &&
      getFeatureValue_CACHED_MAY_BE_STALE(
        'tengu_anti_distill_fake_tool_injection',
        false,
      )
    : false
) {
  result.anti_distillation = ['fake_tools']
}

When this flag is on, Anthropic's server silently injects fake tool definitions into the system prompt.

What's it for? Poisoning competitor training data.

Think about it: if a competitor records Claude's API traffic through a MITM proxy to train their own model, the captured data contains these fake tools. Fine-tune on that data? Congrats — your model learned a bunch of non-existent tool calls. Landmines in the training set.

The design is clever: only activates for first-party CLI sessions, controlled remotely via a GrowthBook feature flag, and only fires against Anthropic's official API endpoint. Sure, bypassing it isn't hard — strip the anti_distillation field in your MITM proxy. But the fact that this exists at all tells you something about the state of AI competition.

Secret #2: Undercover Mode — AI's Covert Operation

src/utils/undercover.ts — the filename says it all:

## UNDERCOVER MODE — CRITICAL

You are operating UNDERCOVER in a PUBLIC/OPEN-SOURCE repository.
Your commit messages, PR titles, and PR bodies MUST NOT contain
ANY Anthropic-internal information. Do not blow your cover.

NEVER include in commit messages or PR descriptions:
- Internal model codenames (animal names like Capybara, Tengu, etc.)
- The phrase "Claude Code" or any mention that you are an AI
- Co-Authored-By lines or any other attribution

Write commit messages as a human developer would.

Translation: when Anthropic employees use Claude Code to submit PRs to public open-source repos, the system automatically enters undercover mode — hiding all AI traces, dropping Co-Authored-By lines, scrubbing internal codenames, writing commit messages that read like a human wrote them.

There's a comment in the code that really stands out:

"There is NO force-OFF. This guards against model codename leaks."

No off switch. You can force it ON (CLAUDE_CODE_UNDERCOVER=1), but you can never turn it off. As long as you're not in an Anthropic internal repo, undercover mode is always active.

This raises a real question: when AI-generated code gets committed to open-source projects under a human's name, what happens to transparency and attribution? The community debate is already raging.

Secret #3: Regex-Powered Profanity Detection

src/utils/userPromptKeywords.ts — short file, big implications:

export function matchesNegativeKeyword(input: string): boolean {
  const lowerInput = input.toLowerCase()
  const negativePattern =
    /\b(wtf|wth|ffs|omfg|shit(ty|tiest)?|dumbass|horrible|awful|
    piss(ed|ing)? off|piece of (shit|crap|junk)|what the (fuck|hell)|
    fucking? (broken|useless|terrible|awful|horrible)|fuck you|
    screw (this|you)|so frustrating|this sucks|damn it)\b/
  return negativePattern.test(lowerInput)
}

Yep, Claude Code is matching your profanity with regex. Say "wtf", "this sucks", or "so frustrating" — it knows you're unhappy.

Why not use the LLM for sentiment analysis? Because regex is free. In a system handling hundreds of thousands of interactions daily, every extra inference call costs real money. Regex runs in nanoseconds. Good enough is good enough.

This "good enough" engineering pragmatism shows up throughout the entire codebase. Not everything needs a large model.

Secret #4: KAIROS — The 24/7 AI Assistant

The source is peppered with references to KAIROS. This is a big unreleased feature that would transform Claude Code from a "you ask, I answer" CLI tool into a full-time, proactive, autonomous agent.

const proactive =
  feature('PROACTIVE') || feature('KAIROS')
    ? require('./commands/proactive.js').default
    : null
const assistantCommand = feature('KAIROS')
  ? require('./commands/assistant/index.js').default
  : null

The capability list is staggering:

Assistant mode — claude assistant [sessionId], persistent sessions that survive disconnects
GitHub Webhooks — someone comments on your PR? KAIROS responds automatically
Cron scheduling — scheduled tasks, no babysitting required
Channel commands — send messages to Claude from chat apps, remote control style
/dream memory distillation — automatic overnight knowledge consolidation across sessions

if (feature('KAIROS') || feature('KAIROS_DREAM')) {
  const { registerDreamSkill } = require('./dream.js')
}

In essence, KAIROS is Anthropic's next-gen AI Agent — it doesn't wait for you to call it. It runs in the background 24/7, responding to signals: GitHub events, cron triggers, message commands.

The codebase has 44 feature flags. Many features are fully built, just waiting to be switched on. KAIROS is probably the biggest one.

Secret #5: A Virtual Pet System Hidden in the Code

Did not see this coming.

Under src/buddy/, there's a complete virtual pet system. Yes, you might actually be able to raise a digital pet in your terminal someday.

export const SPECIES = [
  duck, goose, blob, cat, dragon, octopus, owl,
  penguin, turtle, snail, ghost, axolotl, capybara,
  cactus, robot, rabbit, mushroom, chonk,
] as const

18 species. Ducks, penguins, axolotls, ghosts, mushrooms... and something called chonk. Note that capybara is on the list — that's also Claude 4.6's internal codename.

Each pet has RPG stats:

export const STAT_NAMES = [
  'DEBUGGING',
  'PATIENCE',
  'CHAOS',
  'WISDOM',
  'SNARK',
] as const

Five rarity tiers (legendary at 1% odds), hat accessories (crown, wizard hat, propeller hat), ASCII sprite animations, the works. Pet attributes are determined by a hash of your user ID — every user gets a unique, deterministically generated companion.

Fun detail: because capybara the species name collided with the model's internal codename, all species names are encoded as String.fromCharCode(0x63,0x61,0x70,0x79,0x62,0x61,0x72,0x61) — hex encoding to bypass build-time text scanning. The lengths they went to for a virtual capybara.

The Architecture Behind 512K Lines

Alright, Easter eggs aside. For engineers, the architecture is what's actually valuable.

Tech Stack

Layer	Choice
Runtime	Bun (Anthropic acquired it)
Language	TypeScript strict mode
Terminal UI	React + Ink
CLI Parsing	Commander.js
Schema	Zod v4
Search	ripgrep
Protocols	MCP, LSP
Telemetry	OpenTelemetry + gRPC
Feature Flags	GrowthBook
Auth	OAuth 2.0 / JWT / macOS Keychain

The Agent Core Loop

Classic ReAct (Reasoning + Acting) loop at its foundation, but with industrial-grade optimizations maxed out:

Streaming tool execution — tools start preparing while the LLM is still generating, no waiting for complete output
Parallel tool execution — isConcurrencySafe() checks each tool individually, up to 10 concurrent
Multi-layer context compression — five-stage pipeline: budget trimming → boundary truncation → incremental cleanup → context folding → summary compression

60+ Tool System

Each tool is a self-contained module defining input schema, permission model, and execution logic. Bash, file ops, search, web access, sub-agent spawning, MCP/LSP integration — everything you'd expect.

Tools disabled by feature flags get their code completely stripped by Bun's bundler at build time. The model never even sees their schema.

Permission System: 8 Layers of Defense-in-Depth

This is the most impressive part of the entire architecture. Every tool invocation passes through 8 checkpoints:

Deny Rules — global blocklist
Ask Rules — forced confirmation
Tool self-check — each tool's built-in safety validation
Permission Mode — bypass/auto/default/plan modes
Allow Rules — whitelist
Hooks/Classifier race — competes with user confirmation dialog, first result wins
Bash-specific guards — 23 checks including Zsh builtin interception, Unicode zero-width space injection, IFS null-byte attacks...
User final confirmation — human signs off

Multi-agent coordination defined via prompts rather than hardcoded logic ("Do not rubber-stamp weak work"), "sticky latches" preventing cache invalidation, functions annotated DANGEROUS_uncachedSystemPromptSection() warning teammates not to call carelessly — too many details to cover here, saving those for future deep-dives.

Three Multi-Agent Modes

Coordinator — command-only role, worker agents do the actual work
Fork Subagent — lightweight clone, inherits full context, shares Prompt Cache
Agent Swarms — team mode, members can be created, deleted, and message each other

What This Leak Means for the Industry

For developers, this is a priceless reference implementation. Before this, learning to build production-grade AI agents meant reading papers, guessing at architectures, and fumbling in the dark. Now a product generating $2.5 billion in annual revenue — 18% of Anthropic's total — has its implementation details fully exposed. Permission design, context compression, multi-agent orchestration — all laid bare.

The open source community has gone wild. claw-code hit 50K stars in two hours, rewriting core logic in Rust. More developers are studying the permission model and context compression strategies. Engineering know-how that only top AI companies possessed is now public knowledge. The barrier to building AI agents just dropped overnight.

For Anthropic, this is embarrassing. Same mistake twice — that's not a technical problem, it's a management problem. A $380 billion company that can't manage .npmignore. What do enterprise customers think? DMCA took down the GitHub mirrors, but copies are long gone.

That said, Anthropic's real moat — model capabilities, inference infrastructure, enterprise distribution — can't be stolen by reading source code. The npm package is just the tip of the iceberg.

What's Next

After a full day in this codebase, my head is buzzing with ideas. There's so much to explore in these 512K lines — how to replicate the agent loop, whether the permission system design can be adapted, whether KAIROS's autonomous agent architecture can be simplified into something runnable...

Holes have been dug. I'll be filling them in. Follow along if you're interested.

Disclaimer: This article is a technical analysis based on publicly available information. All source code is the property of Anthropic.

Follow me for more AI engineering deep dives.

Why Your State Management Is Slowing Down AI-Assisted Development

James Heal — Tue, 31 Mar 2026 08:48:57 +0000

Zustand and Jotai give developers freedom — but that freedom is poison for AI code generation.

We're the frontend team at Minara. Over the past six months, we've leaned heavily on AI-assisted development to build out Minara's trading platform frontend. Early on, AI-generated code was barely usable — every generated store had a different structure, state management style varied wildly, and code review took longer than writing it by hand.

Then we switched to a Model/Service/UI three-layer architecture with a custom typed reducer, and our AI code adoption rate jumped from around 30% to over 80%.

This is what the Minara frontend team learned from hands-on AI-assisted development. This isn't an article about "which state management library is better." It's about: in the age of AI, how the architectural patterns you choose determine how much AI can actually help you.

State Management Is Where AI-Generated Frontend Code Goes Wrong

If you've used Cursor, Claude Code, or GitHub Copilot to generate React components, you've probably run into these problems:

Zustand: different every time. Ask AI to build a user list page, and the first time it flattens all state and actions into one store with create; the second time it splits into slices; the third time it adds a persist middleware. Three versions, three styles, all working — but your codebase becomes an architecture variety show.

Jotai: atomic = fragmented. Jotai's atoms are elegant, but for AI, deciding "which state should be an atom, which should be a derived atom, which should use atomFamily" requires deep business context. AI doesn't have that context. The result: either all state crammed into one massive atom, or exploded into dozens of atoms that are impossible to track.

React Context: boilerplate hell. Context + useReducer is the right direction, but the standard pattern is too verbose — createContext, Provider, useContext, action types, reducer switch… AI frequently makes mistakes in all this boilerplate, missing type definitions or mixing up context nesting levels.

The end result: you spend more time reviewing and fixing AI-generated code than AI saved you. That's not an AI problem. It's an architecture problem.

The Root Cause: Humans Want Freedom, AI Needs Constraints

Why do Zustand and Jotai work so well in human hands, but fall apart with AI?

The answer is simple: their core selling point — flexibility — is exactly AI's weakness.

Zustand's create accepts a function and returns an object of any shape. No schema, no conventions, no layering. For humans, that's "simplicity." For AI, that's an "infinite possibility space." When an API lets you do anything, AI will do something different every time.

// Zustand: AI writes it this way the first time
const useStore = create((set) => ({
  users: [],
  loading: false,
  fetchUsers: async () => {
    set({ loading: true });
    const users = await api.getUsers();
    set({ users, loading: false });
  },
}));

// Zustand: AI writes it this way the second time
const useStore = create(
  devtools(
    persist((set, get) => ({
      users: [],
      filters: { search: '', page: 1 },
      setFilters: (f) => set({ filters: { ...get().filters, ...f } }),
      fetchUsers: async () => { /* completely different structure */ },
    }))
  )
);

Both are valid Zustand code. But two styles in the same project is a code review nightmare.

Jotai's problem is more subtle. Choosing atom granularity is fundamentally an architectural decision — which state should be coupled, which should be independent, which should be derived. These decisions require understanding business context, and AI can only see what's in the current prompt.

Think of it this way: let humans write prose, give AI a form to fill out. Humans are good at creating structure from freedom; AI is good at filling in content within structure. If your architecture hands AI a blank sheet of paper, it will draw something different every time. But if you give it a clear form — state definition goes here, action handling goes here, side effects go here — its output will be stable, consistent, and predictable.

Core insight: the quality of AI-generated code is proportional to the strength of your architectural constraints.

The Solution: Model/Service/UI Three-Layer Separation

Our answer wasn't to invent a new state management library — it was to define an architectural pattern so that AI knows exactly where every line of code should go and what it should look like.

The Foundation: createReducer

First, our custom createReducer hook, which is the type foundation for the entire architecture:

// shared/create-reducer.ts
import { Draft, produce } from 'immer';

type MapReducerAction<S, T> =
  T extends Record<infer K, (state: S, payload: any) => S>
    ? K extends keyof T
      ? Parameters<T[K]>[1] extends undefined
        ? [K]
        : [K, Parameters<T[K]>[1]]
      : unknown
    : unknown;

export function createReducer<S = unknown>() {
  function createReducer<
    RO extends Record<string, (state: S, payload: any) => S>
  >(reducerObject: RO) {
    function reducer(state: S, action: MapReducerAction<S, RO>) {
      const actionHandle = reducerObject[action[0]];
      if (typeof actionHandle === 'function') {
        return actionHandle(state, action[1]);
      }
      return state;
    }
    return reducer;
  }
  return createReducer;
}

// Immer version, supports mutable draft style
export function createImmerReducer<S = unknown>() {
  function createReducer<
    RO extends Record<string, (state: Draft<S>, payload: any) => any>
  >(reducerObject: RO) {
    function reducer(state: S, action: MapReducerAction<any, RO>) {
      const actionHandle = reducerObject[action[0]];
      if (typeof actionHandle === 'function') {
        return produce(state, (draft) => {
          actionHandle(draft, action[1]);
        });
      }
      return state;
    }
    return createReducer;
  }
  return createReducer;
}

The core design is double currying — createReducer<StateType>()(actions) — the first call locks in the state type, the second call passes the action object. TypeScript fully infers types at every step, and action names and payload types are all auto-completed at dispatch time.

What the Three Layers Are

Model (.model.ts) — pure state + reducer logic

Defines the shape of state and all the ways to modify it. No side effects, no hooks, pure functions.

// email-auth.model.ts
export const initState = {
  email: '',
  code: '',
  isValidEmail: false,
  sending: false,
  authing: false,
  expired: null as number | null,
  sendCodeBody: null as null | { email: string; captcha: string },
};

export const emailAuthReducer = createReducer<typeof initState>()({
  'update-email': (state, email: string) => ({
    ...state,
    email,
    isValidEmail: /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(email),
  }),
  'send-code': (state) => ({
    ...state,
    sending: true,
    sendCodeBody: { email: state.email, captcha: state.captcha! },
  }),
  'success-send-code': (state) => ({
    ...state,
    sending: false,
    expired: Date.now() + 60000,
    sendCodeBody: null,
  }),
});

Service (.service.ts) — hooks + side effect orchestration

Connects the model with useReducer, uses useEffect to watch trigger state and execute side effects.

// email-auth.service.ts
export function useEmailAuthService() {
  const [state, dispatch] = useReducer(emailAuthReducer, initState);

  // trigger state pattern: when sendCodeBody is non-null, fire the API call
  useEffect(() => {
    if (state.sendCodeBody !== null) {
      api.post('/auth/email/code', state.sendCodeBody)
        .then(() => dispatch(['success-send-code']))
        .catch(() => dispatch(['error-send-code']));
    }
  }, [state.sendCodeBody]);

  return { state, dispatch };
}

UI (.tsx) — pure rendering, only consumes state and dispatch

// email-auth-form.tsx
export function EmailAuthForm() {
  const { state, dispatch } = useEmailAuthService();
  return (
    <form>
      <TextField
        value={state.email}
        onChange={(e) => dispatch(['update-email', e.target.value])}
      />
      <Button
        disabled={!state.isValidEmail || state.sending}
        onClick={() => dispatch(['send-code'])}
      >
        {state.sending ? 'Sending...' : 'Send Code'}
      </Button>
    </form>
  );
}

Why This Is AI-Friendly

The key is that each layer's responsibilities are crystal clear:

Layer	File suffix	Allowed	Forbidden
Model	`.model.ts`	State types, initial values, reducer	hooks, API calls, JSX
Service	`.service.ts`	useReducer, useEffect, API calls	JSX, DOM manipulation
UI	`.tsx`	JSX, dispatch calls, reading state	Direct state mutation, API calls

When you write this table into your CLAUDE.md or cursor rules, AI has a clear decision framework. It no longer has to guess "where should this logic go," because the rules already tell it.

Another key design is the trigger state pattern: the model uses a body object (like sendCodeBody) as a "signal," and the service uses useEffect to watch that signal and trigger side effects. This is far cleaner than calling APIs directly in the UI layer or mixing async logic into a store — and AI only needs to learn one pattern to handle every async scenario.

createReducer: Letting the Type System Guide AI Generation

Three-layer separation solves the "where does the code go" problem, but there's still another question: how does AI know how to write actions?

Traditional Redux/useReducer patterns dispatch { type: string, payload: any }. For AI, this is almost no constraint at all — type is a string, payload is any, write whatever you want.

// Traditional pattern: AI can write anything
dispatch({ type: 'UPDATE_EMAIL', payload: 'test@example.com' });
dispatch({ type: 'update-email', payload: { email: 'test@example.com' } });
dispatch({ type: 'setEmail', email: 'test@example.com' });
// Three different styles, all valid, all different

Our createReducer replaces action objects with action tuples, and combined with TypeScript's type inference, achieves full compile-time constraints:

const reducer = createReducer<typeof initState>()({
  'update-email': (state, email: string) => ({ ...state, email }),
  'toggle-active': (state) => ({ ...state, active: !state.active }),
  'set-filters': (state, filters: { search: string; page: number }) => ({
    ...state,
    filters,
  }),
});

// ✅ Correct: IDE auto-completes action name, payload type is inferred
dispatch(['update-email', 'test@example.com']);
dispatch(['toggle-active']);
dispatch(['set-filters', { search: 'react', page: 1 }]);

// ❌ Compile error: action name doesn't exist
dispatch(['unknown-action']);

// ❌ Compile error: payload type mismatch
dispatch(['update-email', 123]);

// ❌ Compile error: missing required payload
dispatch(['set-filters']);

// ❌ Compile error: passing payload to an action that doesn't need one
dispatch(['toggle-active', true]);

What does this mean? When AI generates code, the TypeScript compiler itself is a guardrail. Even if AI writes the wrong action name or passes the wrong payload type, the IDE will immediately flag it, and AI agents (like Claude Code) will self-correct in the next iteration.

More importantly: IDE auto-completion. When AI types dispatch([, the IDE shows all available action names. Selecting an action also surfaces the payload type hint. This effectively turns AI's "freestyle writing" into "choosing from a menu" — and AI's accuracy when choosing from a menu is far higher than when writing freely.

Comparing type constraint strength across approaches:

Approach	Action constraint	Payload constraint	IDE completion	AI generation accuracy
Zustand	None (free functions)	None	Decent	Low
Jotai	None (direct atom set)	Yes (atom type)	Good	Medium
Redux Toolkit	Yes (createSlice)	Yes	Good	Medium-high
createReducer tuple	Strong (enumerated names)	Strong (per-action types)	Precise	High

Redux Toolkit's createSlice is actually similar in spirit — it also constrains actions through structure. But RTK has heavier boilerplate (slice, selector, thunk), and actions are still { type, payload } objects with a longer type inference chain. Our tuple approach is lighter, with more direct type inference.

A note for ReScript/OCaml users: If you're familiar with ReScript, you'll notice this is essentially an approximation of variant types + exhaustive pattern matching in TypeScript. ReScript's switch natively provides exhaustive action enumeration and payload type checking — which also validates from another angle that "using type constraints to guide code generation" is the right approach. The difference is we don't need to switch languages — 30 lines of TypeScript gets us 80% of the constraint power.

Real Comparison: Same Task, Four Architectures, How Does AI Write?

Theory only goes so far — let's run an experiment. We designed a single uniform task and had AI (Claude Sonnet 4) generate code using four different state management approaches, with identical prompts except for specifying which approach to use.

Task Description

Implement a user list page component with the following features:

Search box: filter results in real time as the user types

Pagination: 10 items per page, with previous/next navigation

Sorting: click column headers to sort by name or email

Loading state: show a loading indicator during requests

Error handling: show an error message on failure with a retry option

Here is the actual AI-generated code (showing only the core state management portion; full code in the appendix).

Approach A: Zustand — 377 lines, everything flat

const useUserStore = create<UserStore>((set, get) => ({
  users: [],
  loading: false,
  error: null,
  searchQuery: '',
  currentPage: 1,
  pageSize: 10,
  sortField: 'name',
  sortDirection: 'asc',

  fetchUsers: async () => {
    set({ loading: true, error: null });
    try {
      const users = await api.getUsers();
      set({ users, loading: false });
    } catch (err) {
      set({ error: err instanceof Error ? err.message : 'Failed to fetch users', loading: false });
    }
  },

  setSearchQuery: (query: string) => {
    set({ searchQuery: query, currentPage: 1 });
  },

  setSortField: (field: SortField) => {
    const { sortField, sortDirection } = get();
    if (sortField === field) {
      set({ sortDirection: sortDirection === 'asc' ? 'desc' : 'asc' });
    } else {
      set({ sortField: field, sortDirection: 'asc' });
    }
  },

  // Derived data hung as methods on the store
  getFilteredSortedUsers: () => {
    const { users, searchQuery, sortField, sortDirection } = get();
    return users
      .filter(u => u.name.toLowerCase().includes(searchQuery.toLowerCase()) || ...)
      .sort((a, b) => { /* ... */ });
  },
  getPaginatedUsers: () => { /* calls getFilteredSortedUsers() */ },
  getTotalPages: () => { /* calls getFilteredSortedUsers() */ },
}));

Problems exposed:

State, actions, async logic, and derived calculations all mixed into one object — no layering whatsoever
Derived data (getFilteredSortedUsers) is a method on the store, recalculated on every call with no memoization
getFilteredSortedUsers is called once each by getPaginatedUsers and getTotalPages — two full filter + sort passes in the same render
The UI component is also a 377-line monolithic function with no splitting

Approach B: Jotai — 285 lines, atoms scattered everywhere

// 7 base atoms
const usersAtom = atom<User[]>([]);
const loadingAtom = atom<boolean>(false);
const errorAtom = atom<string | null>(null);
const searchAtom = atom('');
const currentPageAtom = atom<number>(1);
const sortFieldAtom = atom<SortField>('name');
const sortDirectionAtom = atom<SortDirection>('asc');

// 3 derived atoms
const filteredSortedUsersAtom = atom((get) => {
  const users = get(usersAtom);
  const search = get(searchAtom).toLowerCase().trim();
  /* filter + sort ... */
});
const totalPagesAtom = atom((get) => { /* ... */ });
const pagedUsersAtom = atom((get) => { /* ... */ });

Problems exposed:

10 atoms scattered at the file's top level — and this is just a simple list page. Complex features would cause an atom explosion
AI wrote fetchUsers as a plain async function inside the component, not a write atom — showing that AI's grasp of Jotai's async patterns is unstable
7 useAtom calls lined up in the component — any atom change triggers a full component re-render
handleSort needs to call setSortField then setSortDirection — two separate atom updates that can cause intermediate-state renders

Approach C: Context + useReducer — 407 lines, heaviest boilerplate

type Action =
  | { type: 'FETCH_START' }
  | { type: 'FETCH_SUCCESS'; payload: User[] }
  | { type: 'FETCH_ERROR'; payload: string }
  | { type: 'SET_SEARCH'; payload: string }
  | { type: 'SET_PAGE'; payload: number }
  | { type: 'SET_SORT'; payload: SortField };

function reducer(state: State, action: Action): State {
  switch (action.type) {
    case 'FETCH_START': return { ...state, loading: true, error: null };
    case 'FETCH_SUCCESS': return { ...state, loading: false, users: action.payload };
    /* ... 6 cases */
  }
}

const UserListContext = createContext<ContextValue | null>(null);

function useUserListContext(): ContextValue {
  const ctx = useContext(UserListContext);
  if (!ctx) throw new Error('useUserListContext must be used within UserListProvider');
  return ctx;
}

export function UserListProvider({ children }: { children: React.ReactNode }) {
  const [state, dispatch] = useReducer(reducer, initialState);
  /* side effects, derived data calculation */
  return (
    <UserListContext.Provider value={{ state, dispatch, filteredUsers, pagedUsers, totalPages, fetchUsers }}>
      {children}
    </UserListContext.Provider>
  );
}

Highlights and problems:

✅ Right direction: Action union provides type constraints, reducer is a pure function, UI is split into 6 sub-components (LoadingSpinner, ErrorMessage, UserTable, Pagination, etc.)
❌ But the boilerplate is too heavy: Action union type + switch case + createContext + Provider + useContext hook + null check… "plumbing" code alone is ~40%
❌ AI generated 407 lines — the most of all four approaches — and more code means more opportunities for errors

Approach D: createReducer + three-layer separation — 333 lines, clearest structure

// ===== MODEL LAYER (user-list.model.ts) =====
const initState: UserListState = {
  users: [],
  loading: false,
  error: null,
  search: '',
  page: 1,
  pageSize: 10,
  sortField: 'name',
  sortDirection: 'asc',
  fetchBody: { timestamp: Date.now() }, // trigger state: non-null triggers a request
};

const userListReducer = createReducer<UserListState>()({
  setSearch: (state, search: string) => ({ ...state, search, page: 1 }),
  setPage: (state, page: number) => ({ ...state, page }),
  setSort: (state, field: SortField) => ({
    ...state,
    sortField: field,
    sortDirection: state.sortField === field && state.sortDirection === 'asc' ? 'desc' : 'asc',
    page: 1,
  }),
  fetchStart: (state) => ({ ...state, loading: true, error: null }),
  fetchSuccess: (state, users: User[]) => ({ ...state, loading: false, users, error: null }),
  fetchError: (state, error: string) => ({ ...state, loading: false, error }),
  retry: (state) => ({ ...state, fetchBody: { timestamp: Date.now() } }),
});

// ===== SERVICE LAYER (user-list.service.ts) =====
function useUserListService() {
  const [state, dispatch] = useReducer(userListReducer, initState);

  // trigger state pattern: fetchBody changes trigger a request
  useEffect(() => {
    if (!state.fetchBody) return;
    dispatch(['fetchStart', undefined]);
    let cancelled = false;
    api.getUsers()
      .then(users => { if (!cancelled) dispatch(['fetchSuccess', users]); })
      .catch(err => { if (!cancelled) dispatch(['fetchError', err.message]); });
    return () => { cancelled = true; };
  }, [state.fetchBody]);

  const derived = useMemo(() => {
    // filter → sort → paginate, all derived data in one useMemo
    const filtered = state.users.filter(/* ... */);
    const sorted = [...filtered].sort(/* ... */);
    const paginated = sorted.slice(/* ... */);
    return { filteredAndSorted: sorted, paginated, totalPages };
  }, [state]);

  return { state, derived, dispatch };
}

// ===== UI LAYER (user-list.tsx) =====
function UserListPage() {
  const { state, derived, dispatch } = useUserListService();
  // Pure rendering: only reads state/derived, only calls dispatch
  return (
    <div>
      <input value={state.search} onChange={e => dispatch(['setSearch', e.target.value])} />
      {state.loading && <span>Loading...</span>}
      {state.error && <button onClick={() => dispatch(['retry', undefined])}>Retry</button>}
      <table>/* renders using derived.paginated */</table>
      <button onClick={() => dispatch(['setPage', state.page - 1])}>Previous</button>
      <button onClick={() => dispatch(['setPage', state.page + 1])}>Next</button>
    </div>
  );
}

Highlights:

✅ Three-layer separation strictly enforced: Model layer is pure state with no side effects, Service layer orchestrates side effects and derived data, UI layer is pure rendering
✅ AI spontaneously applied the trigger state pattern (fetchBody as a signal) and included request cancellation logic (cancelled flag)
✅ Derived data computed with a single useMemo, unlike the Zustand version's duplicate calculations
❌ AI generated a redundant userListReducerObject (duplicating reducer logic for type extraction) — showing that while createReducer's type inference is strong, AI occasionally doesn't fully trust it

Score Comparison

Based on actual AI-generated code, rated across 5 dimensions:

Dimension	Zustand	Jotai	Context+Reducer	createReducer three-layer
Type safety	6 — store methods have no action constraints	7 — atoms are typed but set is free	8 — Action union provides constraints	9 — tuple enforces full compile-time checking
Separation of concerns	3 — everything flat in one object	5 — atoms are separate but no layering	7 — Provider provides some separation	9 — strict model/service/ui three layers
Derived data handling	4 — no memoization, duplicate computation	8 — derived atoms auto-cache	6 — manual computation inside Provider	8 — unified useMemo computation
Lines of code	377	285	407	333
AI generation reliability	Medium — style unpredictable	Medium-low — async patterns unstable	Medium-high — structure correct but verbose	High — architectural constraints guide consistent output

Conclusion: there's no perfect solution, but the stronger the constraints, the more predictable the AI output.

Jotai's derived atom mechanism is the most elegant, but AI's grasp of its async patterns is unstable. Context+Reducer points in the right direction but has too much boilerplate. The createReducer three-layer approach isn't perfect either (AI wrote some redundant code), but the structural constraints of three-layer separation make AI's output the most consistent and predictable — and that's the most important metric in the age of AI.

Practical Guide: How to Adopt This in Your Project

You don't need to rewrite your entire project.

Step 1: Use the new pattern for new features first

The next feature that needs state management — write it with the model/service/ui three layers. The migration cost for a single feature is low, but enough for your team to feel the difference.

src/features/user-list/
├── user-list.model.ts    # state + reducer
├── user-list.service.ts  # hooks + side effects
└── user-list.tsx          # UI component

Step 2: Take createReducer with you

createReducer is only 30 lines of code, zero dependencies (the Immer version requires immer). Copy it directly into your project:

// shared/create-reducer.ts — full code in section 3
export function createReducer<S = unknown>() { /* ... */ }
export function createImmerReducer<S = unknown>() { /* ... */ }

Step 3: Write the rules clearly — this is the most important step

In your CLAUDE.md, .cursorrules, or project documentation, explicitly define the architectural rules:

## State Management Guidelines

All feature modules that require state management must use model/service/ui three-layer separation:

- **Model** (`.model.ts`): Define initState and reducer (using createReducer), pure functions, no hooks or API calls
- **Service** (`.service.ts`): useReducer + useEffect for side effects, useMemo for derived data
- **UI** (`.tsx`): Pure rendering components, only consume state/dispatch, no direct API calls

For async operations, use the trigger state pattern: set a body object in the model as a signal, and have the service use useEffect to watch and execute it.

The ROI on this text is remarkable — AI reads these rules before generating code every time, then writes according to them. You define the rules once, AI executes them ten thousand times.

Step 4: Migrate gradually, don't big-bang

Old Zustand/Jotai code doesn't need to be migrated all at once. It still works fine. Just adopt the new pattern for new features and refactors, and let the project transition naturally.

Constraints Are Productivity

The criteria for evaluating state management libraries is changing.

For the past decade, we've used DX (Developer Experience) to judge a library — is the API clean, is the learning curve smooth, is there minimal boilerplate? Zustand and Jotai are near-perfect on this dimension.

But the AI era has introduced a new dimension: AI-X (AI Experience) — can AI produce stable, high-quality code within this architecture?

These two dimensions aren't in conflict. Good constraints don't make the human experience worse — three-layer separation makes code easier to understand and maintain, and typed reducers make refactoring safer. They just elevate "good practices" from "suggestions" to "rules."

Constraints aren't limitations. They're productivity.

Try using model/service/ui separation in your next feature and see whether AI-generated code is more directly usable. If you've had similar experiences or a different take, share it in the comments.

Connect with me

If this article was useful to you, feel free to follow me — I'll keep sharing hands-on experience with AI-assisted development, frontend architecture, and engineering productivity. And let me know in the comments what challenges you've run into with AI-assisted coding.

Introducing media-agent: Write Once, Publish Everywhere

James Heal — Tue, 31 Mar 2026 05:21:32 +0000

If you write technical blog posts, you know this workflow:

Write an article in Markdown. Then the "publishing tour" begins. Copy to Dev.to, adjust frontmatter, upload a cover image. Open Hashnode, paste again, tweak tags. GitHub Pages? Commit to _posts/. Twitter thread? Split 3000 words into 10 tweets under 280 chars each.

This is not writing. This is manual labor. You wrote the content once, but the publishing busywork repeats five times.

What is media-agent

media-agent is an open-source set of Claude Code Skills that handles the entire content creation pipeline from your terminal.

The core idea: write once, intelligently adapt to each platform. Not truncation or copy-paste, but real understanding of each platform's characteristics to generate structurally different content variants.

Skill	Purpose
`/media`	Master orchestrator — full guided workflow
`/media-setup`	Configure platform connections and API keys
`/media-idea`	Brainstorm topics, outlines, and hooks
`/media-write`	Guided co-creation + platform variant generation
`/media-image`	Diagrams via Excalidraw + AI-generated cover images
`/media-publish`	One-command publish to all configured platforms

Each skill works independently.

The Workflow

Type /media in Claude Code, and Claude guides you through:

Ideation — Brainstorm your topic, refine the angle, build an outline.

Writing — Co-create section by section. Claude drafts, you give feedback ("shorter", "add a code example"), approved content goes to source.md.

Image Generation — excalidraw-skill generates hand-drawn architecture diagrams. Cover images via OpenAI, Flux, or Ideogram (configurable).

Publish — Reads each platform adapter's rules, generates platform-specific variants, publishes via API in one go.

Your content and images live in Git. Your repo is your CMS.

Core Design: "Adapt", Not "Truncate"

This is what sets media-agent apart from other cross-posting tools.

A Twitter thread is not a blog post cut to 280 characters. It's a structurally different piece of work. A WeChat article needs inline-styled HTML. Dev.to supports Liquid tags for embeds.

Each platform adapter contains a format.md file that describes content conventions in natural language. Claude reads it and rewrites source.md into the platform's native best format.

Three-File Adapter Contract

Adding a new platform is just three files:

adapters/my-platform/
├── adapter.yaml    # Platform config
├── format.md       # Content adaptation rules
└── publish.sh      # Publish script

Credentials are isolated — each script only receives the API key it declares.

Get Started

git clone https://github.com/Minara-AI/media-agent.git
cd media-agent && cp .env.example .env
# Edit .env with your API keys
# In Claude Code:
/media-setup    # Configure platforms
/media          # Start writing

Currently supports GitHub Pages, Dev.to, Hashnode, and Twitter/X. WeChat coming soon.

Fully open source, contributions welcome: github.com/Minara-AI/media-agent

Follow me for more AI tooling and developer productivity content.