---
title: "What AI DevKit is: a control plane for AI coding agents - and where it stops"
description: "An architectural guide to AI DevKit: local-first CLI/TUI console, shared config, SQLite memory, and workflow skills for managing multiple coding agents."
pubDate: "2026-08-30"
lang: "en"
slug: "ai-devkit-explained"
url: "https://hoangyell.com/ai-devkit-explained/"
author: "HoangYell"
translation_vi: "https://hoangyell.com/vi/ai-devkit-explained/"
categories: ["AI & Agents"]
tags: ["ai", "ai-agents", "cli", "typescript", "developer-tools"]
heroImage: "https://raw.githubusercontent.com/HoangGeek/store/refs/heads/main/webp/ai-devkit-explained.webp"
---

Many people writing software with AI in 2026 do not use a single tool. Some run **Claude Code** in a terminal, **Cursor** or **Copilot** in the editor, plus **Codex CLI** or **Gemini CLI**, and try **Pi**, **Antigravity**, or **OpenCode**. Not everyone runs all of those at once - that is the fragmentation picture that READMEs for some “agent control plane” projects describe.

As the number of agents grows, common frictions (not always all at once) include: many terminal windows, copying logs between chats, duplicated instruction files (`CLAUDE.md`, `.cursor/rules`, `AGENTS.md`), and agents claiming done while tests still fail. The usual fix is still static rules plus human review. Another approach is an **operating layer** around the agents you already use.

**[AI DevKit](https://github.com/codeaholicguy/ai-devkit)** is an MIT-licensed open-source project by Hoang Nguyen (Codeaholicguy) / [@codeaholicguy](https://github.com/codeaholicguy). The repo positions itself as a local-first **control plane**: one config, a session console, SQLite memory, prompts routed to running agents, and workflow skills (`dev-lifecycle`, `verify`, and others). This article summarizes the architecture from the project's documentation, distinguishes **software mechanisms** from **instructions an agent can ignore**, and notes when setup cost usually outweighs the benefit.

This is **not** an independent source audit or a benchmark. Commands and files follow the repo README/docs (around version 0.56). Real behavior depends on whether the agent loads and follows skills/MCP.

***

## TL;DR

![Image](https://raw.githubusercontent.com/HoangGeek/store/refs/heads/main/webp/ai-devkit-explained-gallery-01.webp)

- **What it is:** A CLI (plus TUI) that runs on your machine and wraps coding agents you already have. Not a new LLM. Not a hosted cloud product as the project describes it (memory is local SQLite; the project states no telemetry).
- **What it aims to solve:** Config drift across tools, no shared view of running sessions, stuffing rules into every prompt, and “jump to code / claim done” workflows - *as framed in the README*.
- **Hard vs soft:** Config files, the CLI, SQLite, and MCP are real software. Skills such as `verify` and `dev-lifecycle` are **process/instructions** attached to agents - not a kernel or mandatory CI. The model can skip them if skills are not loaded or not followed.
- **Who it fits in practice:** People already using **two or more agent environments** (for example Cursor + Claude Code + a CLI), or who want the same skills/MCP across them. People who mostly chat in one IDE are usually fine with in-repo rules.
- **Cloning source ≠ using the tool:** `git clone` + `npm install` + `npm run build` only builds the repo for development. To *use* it, the docs split two commands: `setup` (once per machine: global hooks/skills) and `init` (once per project: writes files into that repo).

***

## Beginner Map

![Image](https://raw.githubusercontent.com/HoangGeek/store/refs/heads/main/webp/ai-devkit-explained-gallery-02.webp)

AI DevKit is not a chatbot or a model. It is closer to **ops tooling for agents**: generate/sync config files, an optional session dashboard, a local knowledge store, and markdown/agent skills that *encourage* a lifecycle.

1. **Mental model:** An analogy (not an equation) between freelancers with no shared process and a team with a lead and checklists. The analogy overreaches: Cursor alone plus `AGENTS.md` is not “five soundproof rooms.”
2. **Mechanism:** The Markdy diagram below shows the **architecture the project claims** - config, console, SQLite, skills - not a measured result on every machine.
3. **Five common frictions:** context bloat, done-claims without evidence, drifting rule files, coding before a plan, hard-to-track sessions. AI DevKit *targets* those; how much it “fixes” depends on the agent and how you use it.
4. **Trying it:** To test on a real repo, run `setup` then `init` - do not confuse that with cloning GitHub.

| Term | Meaning in the project's docs | Caveat |
|:---|:---|:---|
| `.ai-devkit.json` | Project config; `init` uses it to write rules/skills/MCP for chosen agents. | Still a git-tracked file; conflicts and review like any other config. |
| `setup` | Once per machine: detect agents that have been launched, install hooks/trackers and global skills. | Agents never launched yet may be skipped. |
| `init` | Once per project: wizard creates `.ai-devkit.json`, agent folders, often `docs/ai/`. | Writes many files into the repo; not “npm install again.” |
| `agent console` / `agent list` | TUI/CLI to list and inspect local sessions the layer can see. | Cursor (per the README matrix) is mainly **setup**, not full remote control like some CLIs. |
| `agent send` | Send a prompt or stdin into a running session, for agents with remote support. | Not uniform across every IDE in the support table. |
| `@ai-devkit/memory` | Local SQLite; store/search; agents read via MCP when wired up. | Retrieval only happens if MCP/skills load and the agent calls the tool. |
| `dev-lifecycle` | Skill: requirements → design → plan → implement → test → review, often with `docs/ai/`. | Documentation overhead; usually excessive for tiny edits. |
| `verify` | Skill: do not claim done without fresh test/build output. | Does **not** replace GitHub CI; cannot lock the model at runtime. |

### Three operations people mix up

```bash
# A. Developing AI DevKit itself (contributors) - skip if you only want to use it
# git clone … && npm install && npm run build

# B. Once per machine (docs: detect agents + global skills)
npx ai-devkit@latest setup

# C. Once in each repo you want wired up
cd /path/to/your-project
npx ai-devkit@latest init
```

`npx ai-devkit@latest` pulls the CLI from npm. Cloning source is only needed if you are changing the toolkit itself.

Memory example (after the CLI is available, typically in a project that already ran `init`):

```bash
npx ai-devkit@latest memory store \
  --title "Repository pattern convention" \
  --content "Controllers must not call Prisma directly; inject a Repository interface." \
  --tags "architecture,backend"

npx ai-devkit@latest memory search --query "controller database access"
```

The convention lives in local SQLite. An agent **may** read it via MCP - it is not stuffed into every prompt, and there is no guarantee every session searches before coding.

***

## Part 1: Mental model (and the analogy’s limits)

![Image](https://raw.githubusercontent.com/HoangGeek/store/refs/heads/main/webp/ai-devkit-explained-gallery-03.webp)

The README uses talented developers in soundproof rooms: no tech lead, no task board, no shared architecture, no CI. That is **storytelling** to explain a control plane, not a statistical portrait of every AI developer.

The more common setup is one IDE, a few rule files, and a human reviewing the diff. “Multi-agent” friction shows up when you **actually** run Claude Code / Codex / Gemini / Cursor in parallel and want one shared skill-MCP set.

The project's stated principle (paraphrased, not a law): do not only lengthen the system prompt; add observation (list/console), retrieval (memory), and checklists (skills). Matching weakness: a checklist is not a compiler; observability depends on each vendor adapter.

```
Model the project describes (abridged):

  Without this layer (one scenario):
    Agent A  →  its own code / prompt
    Agent B  →  a different rule file
    Agent C  →  claims done; tests may still fail

  With AI DevKit (claimed architecture):
    Developer → CLI / console / .ai-devkit.json / SQLite
                    ↓
         Agents you initialized (Claude, Cursor, Codex, …)
                    ↓
         Skills (dev-lifecycle, verify, …) if the agent loads and follows them
                    ↓
         Codebase - verify does not replace the repo’s CI pipeline
```

***

## Part 2: Architecture as documented by the project

![Image](https://raw.githubusercontent.com/HoangGeek/store/refs/heads/main/webp/ai-devkit-explained-gallery-04.webp)

Four pillars the README/docs emphasize:

1. **Multi-environment config:** `init` creates `.ai-devkit.json` then writes templates into agent folders (`.claude/`, `.cursor/`, …) based on the wizard. “Single source of truth” here means *generating files from one config*, not magically lock-stepping every tool on the internet.
2. **SQLite memory + MCP:** Knowledge (conventions, decisions) is stored locally; agents query when skills/MCP are attached. That differs from markdown rules that always sit in context.
3. **Sessions + messaging:** `agent list` / `agent console` / `agent send` (and Telegram/Slack channels if enabled). The README matrix splits **Setup** and **Remote control**; Cursor/Copilot are listed for setup, with remote control marked limited or absent - check the current table before expecting `agent send` into Cursor.
4. **Skills:** `dev-lifecycle` steers the agent to write `docs/ai/{requirements,design,planning,implementation,testing}/` before (or alongside) code; `verify` asks for command evidence. This is a **soft contract** with the agent, not a CI test gate.

```markdy
scene width=1440 height=800
theme: light=doodle dark=nebula
layout auto

user Dev "Developer"
cli CLI "ai-devkit CLI"
service Console "TUI Console"
service Router "Agent Router"
database SQLite "Local SQLite Memory"
client Claude "Claude Code"
client Cursor "Cursor"
client Pi "Pi / Gemini CLI"
module Lifecycle "dev-lifecycle"
module Verify "verify gate"
module TDD "tdd & debug"
repo Codebase "Codebase & Tests"

group controlPlane "AI DevKit Control Plane": Console Router SQLite
group activeAgents "Configured Agents": Claude Cursor Pi
group skillSuite "Engineering Skills": Lifecycle Verify TDD

beat reveal "System Overview":
    show $nodes stagger=40ms

beat configMemory "Unified Config & Memory Retrieval":
    frame Dev CLI controlPlane zoom=1.15
    Dev -> CLI "npx ai-devkit init"
    CLI -> SQLite "store reusable rules"
    CLI -> Console "initialize dashboard"
    glow SQLite color=#10b981

beat routing "Live Supervision & Inter-Agent Dispatch":
    frame controlPlane activeAgents zoom=1.12
    Console -> Router "agent send --group reviewers"
    Router -> Claude "assign requirements phase"
    Router -> Cursor "assign backend implementation"
    Router -> Pi "pipe failing test logs"
    SQLite -> Claude "MCP query: auth rules"
    glow Router color=#38bdf8

beat execution "Lifecycle Phasing & Verification Gate":
    frame activeAgents skillSuite Codebase zoom=1.12
    Claude -> Lifecycle "draft docs/ai/design.md"
    Cursor -> TDD "write failing unit test"
    Cursor -> Codebase "implement feature"
    Cursor -> Verify "execute test suite"
    Verify -> Codebase "check exit code 0"
    glow Verify color=#10b981

beat fullSystem "The Coordinated Engineering Engine":
    frame $nodes zoom=1.05
    glow controlPlane color=#38bdf8

player:
    playback:
      loop true
    controls:
      gif true
      theme true
    interaction:
      zoom true
      pan true
      click_to_play true

player:
    playback:
      loop true
    controls:
      speed true
      speeds "0.25"
      fullscreen true
      gif true
      theme true
    interaction:
      zoom true
      pan true
      click_to_play true
      double_click_to_reset true
      keyboard false
    chrome:
      badge true
      progress none
```

***

## Part 3: Five frictions - claims and conditions

![Image](https://raw.githubusercontent.com/HoangGeek/store/refs/heads/main/webp/ai-devkit-explained-gallery-05.webp)

These are not “five fatal bugs of every coding agent.” They are five problems the README ties to the product.

### 1. Context bloat vs. on-demand memory
- **Real problem:** Long rules/docs in every prompt cost tokens and dilute signal.
- **DevKit’s approach:** SQLite + search/MCP.
- **Conditions:** The agent must have memory MCP and *choose* to query. Otherwise you can still dump rules as before. Local memory also does not sync to the cloud or to teammates on other machines unless you share the DB file (usually a bad idea).

### 2. Fake-done vs. the `verify` skill
- **Real problem:** Models often claim completion without a verifying command.
- **DevKit’s approach:** A skill tells the agent to run tests/builds and read the output.
- **Conditions:** Not a substitute for GitHub Actions/Jenkins. If the agent does not load the skill, or ignores it, there is no gate. “Exit code 0” in a skill is not the team’s merge policy.

### 3. Coding before a plan vs. `dev-lifecycle`
- **Problem:** Large features get opportunistic file edits.
- **Approach:** Skills push (softly) for phased `docs/ai/` writing.
- **Conditions:** Documentation cost. For a typo or CSS tweak, the lifecycle is usually overkill - the README itself does not require skills on every edit. The repo also accumulates workflow markdown if the team never reads or reviews those files.

### 4. Config drift across tools
- **Problem:** You edit `CLAUDE.md` and forget `.cursor/rules`.
- **Approach:** Edit `.ai-devkit.json` and let `init`/reconcile rewrite.
- **Conditions:** Only agents the wizard supports. Unknown tools or hand-written rules outside the flow still drift. Generated files still need a diff review.

### 5. Many terminals
- **Problem:** Hard to see which sessions are still alive.
- **Approach:** `agent console`, `agent send --stdin`.
- **Conditions:** An adapter must recognize the process/session. IDEs like Cursor were not in the README’s “remote control: yes” group at the time of writing - recheck current docs.

```bash
npm test 2>&1 | npx ai-devkit@latest agent send --id backend-agent --stdin
```

(`--id` must be a session the layer can see.)

***

## Part 4: Rollout, cost, and when to skip

![Image](https://raw.githubusercontent.com/HoangGeek/store/refs/heads/main/webp/ai-devkit-explained-gallery-06.webp)

Official docs split **machine** and **project**:

```bash
npx ai-devkit@latest setup          # machine: hooks + global skills for detected agents
cd your-project && npx ai-devkit@latest init   # project: .ai-devkit.json + agent files + docs/ai
```

A “senior engineer” template (if you use it) pulls extra skills from registries (Anthropic, Vercel, and others per the README) - more surface area, not just the built-in skills. A Telegram channel is optional (bot token, daemon, prompt-injection surface from a phone - assess before enabling).

```bash
npx ai-devkit@latest init --template senior-engineer   # per README; verify the flag on the current CLI
npx ai-devkit@latest agent console
# optional: npx ai-devkit@latest channel start telegram --agent <name> --daemon
```

### When it is usually worth trying / not

| Situation | Practical suggestion | Why |
|:---|:---|:---|
| Two+ CLI/IDE agents, want shared skills + MCP | Reasonable to try `setup` + `init` | Matches the “one config” problem. |
| Long sessions, need list/send (remotely supported agents) | Try `agent list` / `console` | Observability value; does not upgrade the model. |
| Large feature, team agrees to write `docs/ai/` | Can enable `dev-lifecycle` | Process leaves reviewable artifacts; costs writing time. |
| Solo, mostly Cursor | Usually **skip** | Rules/skills under `.cursor` are enough; a control plane adds files and habits. |
| Small fixes, prototypes, throwaway scripts | Skip the lifecycle | Doc overhead is not worth it. |
| “Block merge if tests are red” | Use **CI**, not the `verify` skill | A skill is not a policy server. |

Other tradeoffs: more process dependency (wizard, MCP, SQLite, global skills on the machine). `init` may `git init` if the directory is not already a repo (per getting-started). Read the diff before committing.

The README’s own limits (worth keeping in view): it does not make LLMs smarter; it does not replace Claude/Cursor/Codex; it is not a “write the feature for me” button; it is local-first, not a SaaS that runs your agents for you.

***

## Final Take

AI DevKit is **ops tooling** around coding agents: config, CLI/TUI, local memory, workflow skills. The software can observe and generate files; the “engineering discipline” part mostly depends on the agent **following skills** - unlike CI, unlike a compiler, unlike using one IDE with `AGENTS.md`.

There is no “install it today” conclusion. If your stack is already one editor plus a few rules, `setup`/`init` cost usually dominates. If you truly coordinate many sessions/CLIs, read the [docs](https://ai-devkit.com/docs/) and the current agent matrix, then try it on **one** side repo before rolling it out.

### Student First Assignment: Inspecting Control Plane Mechanics (30-45 Mins)

1. **Spin up a sandbox repository:** Create a scratch test directory: `mkdir /tmp/agent-control-plane && cd /tmp/agent-control-plane && git init`.
2. **Run initialization:** Execute `npx ai-devkit@latest init` to inspect the created `.ai-devkit/` configuration, SQLite database, and generated agent rule files.
3. **Audit the context footprint:** Measure the token overhead of all injected control plane files compared to a lightweight, single-file `AGENTS.md`.
4. **Test the enforcement boundary:** Command an AI agent to write code with an intentional failing unit test. Observe whether the agent strictly invokes the `verify` skill or declares victory prematurely.

***
*Author: [HoangYell](https://hoangyell.com). Product description source: [codeaholicguy/ai-devkit](https://github.com/codeaholicguy/ai-devkit). Architecture explainer, not an endorsement.*