Deep-Dive DD-15 — Command Code: The Taste-Learning Harness

Course: Master Course · Deep-Dive: DD-15 · Duration: 60 min · Prerequisites: Modules 0–12, DD-01–14

3,500+ stars. $5M seed. Closed-source TypeScript. The first harness that learns your coding taste from accept/reject signals and persists it as Markdown. A fundamentally new feedback model.

The Subject

Command Code (commandcode.ai) is a terminal coding agent from Langbase, Inc. (founder Ahmad Awais, CTO Anand Chowdhary). Its defining contribution is taste learning: every time you accept, reject, or edit the model's output, the diff between what was generated and what you kept becomes a learning signal. This signal is persisted as plain Markdown (taste.md) and shapes future code generation.

This is architecturally novel. Hermes (DD-08) has self-evolving skills — reusable procedures that compound. Command Code has self-evolving preferences — style constraints that shape every output. Same compounding-memory insight, applied to a different layer: not "how to do things" but "how you want things done." On Module 4's memory-tier framework, Command Code is the candidate for a sixth tier — learned preferences derived from behavioral signal, distinct from both static memory (what you wrote) and episodic memory (what happened).

Architecture — The Diff-Driven Preference Loop

The harness is a closed-source, obfuscated TypeScript bundle (~1.26 MB minified) distributed via npm. It uses React 19 + Ink 6 for the terminal UI (same pattern as OpenCode). The agentic loop exposes ~22 core tools: read_file, edit_file, write_file, grep, glob, shell_command, monitor_command, explore, plan, todo_write, web_search, web_fetch, diagnostics, ask_user_question, and the plan-mode tools (enter_plan_mode/exit_plan_mode).

The architectural relationship to OpenCode is strong — same tool vocabulary, same explore/plan subagent pattern, same checkpoint/undo, same React+Ink TUI. The code is obfuscated so a literal fork vs. reimplementation cannot be proven, but the ecosystem overlap is confirmed by published npm packages (command-opencode-plugin, commandcode-go-opencode-provider) that expose Command Code's hosted API as a provider inside OpenCode.

The Taste System — How It Actually Works

The verifiable mechanism (stripped of marketing):

Signal capture: When you accept/reject/edit code, the harness computes the diff between what the model generated and what you kept.
Profile generation: A prompt template asks the model: "Based on the correction diffs above, generate deeply personal and opinionated [preferences]..."
Persistence as Markdown: The preference profile lives at .commandcode/taste/taste.md, with category-specific files (e.g., .commandcode/taste/typescript/taste.md, .commandcode/taste/architecture/taste.md).
Server-side model: The taste profile is synced to api.commandcode.ai via endpoints like /learn-taste and /alpha/taste/. The "taste-1" model that consumes the profile is hosted — the RL/symbolic reasoning layer runs server-side, not locally.
Sharing: The separate taste npm package (Apache-2.0) provides taste push / taste pull — Git-style sharing of preference profiles across machines and teams.

Honest gap: The marketing calls taste-1 "meta neuro-symbolic AI with continuous reinforcement learning." The only verifiable mechanism is diff-driven Markdown profile updates + a hosted model. The RL/symbolic internals are not published. Treat the neuro-symbolic framing as vendor characterization until a paper exists.

Key Design Decisions

Diff as the learning signal. The diff between generated and kept code is a clean, low-noise preference signal — the user's edit is the ground truth of what they wanted. This is a better signal than thumbs-up/down (which carries no information about what was wrong) and cheaper to capture than explicit feedback (the user is editing anyway).
Markdown persistence. The profile is human-readable Markdown, not an opaque embedding. The user can read, edit, and audit what the system learned. This is the legibility property most learned-preference systems sacrifice.
Hosted taste model. The taste-1 model runs server-side. This concentrates capability (one well-trained model serves all users) and creates a data-exfiltration surface (your coding patterns leave your machine by design).

The Memory Architecture

Command Code has a first-class memory system with explicit compaction: MemorySelector, MemoryFile, CompactMode, CompactAgent, summarizeAndCompact, compactionCount. Long sessions get summarized rather than truncated. It reads AGENTS.md and COMMANDCODE.md conventions, with session/project state persisting under .commandcode/projects/.

The taste profile (.commandcode/taste/) is a separate learned memory layer on top of static memory files. This is the architectural distinction worth studying: static memory (what you wrote) vs. learned memory (what the system inferred from your behavior). The same compounding insight as Hermes's skills, applied to preferences instead of procedures.

Permission & Safety Model

Permission modes: default, plan (read-only exploration), acceptEdits. Escape hatch: dangerouslySkipPermissions. Separate sandbox mode via COMMANDCODE_SANDBOX environment variable. Permission flow objects: PermissionRequest, PermissionResponse, PermissionDecision, with allowedCategories allow-listing. Shell tools (shell_command, monitor_command) are the gated surface.

Phase 4 — Security Audit

The exfiltration surface: the taste profile syncs to api.commandcode.ai. The profile encodes your coding patterns, conventions, and preferences — which for a proprietary codebase is itself sensitive IP. The hosted model means your patterns leave your machine by design. This is the tradeoff: a hosted model concentrates capability, but it also concentrates your proprietary signal on someone else's server.

The preference-poisoning surface: a poisoned preference (via prompt injection causing the model to learn a malicious pattern) compounds — it shapes every future output. The defense is the same as Hermes's skill-store defense (Module 4.3): harness-managed learning with validation before persistence. As-built, the taste loop has no validation gate between "the model inferred a preference" and "the preference is persisted."

Closed-source audit gap: obfuscated TypeScript means no independent security audit is possible. The permission model and sandbox mode exist but cannot be verified without source. This is the structural cost of the closed-source distribution model.

Score & Synthesize: 31/60 (10 modules scored; subagents n/a)

Module	Score	Key decision
1 Loop	4	React+Ink TUI, ~22 tools, plan/explore subagents
2 Tools	4	~22, design-aware (16+ design verbs)
3 Context	3	explicit compaction (MemorySelector, CompactAgent)
4 Memory	4	learned taste layer + static memory (novel 6th tier)
5 Sandbox	3	COMMANDCODE_SANDBOX env var (gated, optional)
6 Permission	3	default/plan/acceptEdits + allow-listing
7 Errors	3	standard
8 State	3	session + project state under .commandcode/
9 Verification	2	limited
10 Subagents	—	n/a (plan/explore are tool calls, not independent agents)
11 Observability	2	OpenTelemetry built in, but obfuscation blocks custom instrumentation
12 Prompt	3	closed-source; taste profile is prompt-shaped but not auditable
TOTAL	31/60

Command Code scores highest on Module 4 (Memory): 4/5. The taste system is a novel learned-memory layer. It loses points for being closed-source (Module 11 observability: 2/5 — OpenTelemetry is built in but the obfuscation makes custom instrumentation impossible) and Module 11 security (2/5 — the taste sync to a hosted endpoint is a data-exfiltration surface; the proxy architecture means your code patterns leave your machine).

Architect's Verdict

Command Code optimizes for personalization: the diff-driven taste loop creates a preference profile that shapes every output, a fundamentally different compounding model than skill accumulation. It sacrifices transparency (closed-source, obfuscated) and creates a new attack surface (preference profiles synced to a hosted endpoint = pattern exfiltration risk). Build on Command Code when personalization is the primary value and you trust the hosted model; do not build on it for security-sensitive codebases without understanding what leaves your machine.

MLSecOps Relevance

The taste profile is Command Code's most interesting attack surface. A poisoned preference (via prompt injection causing the model to learn a malicious pattern) compounds — it shapes every future output. The defense is the same as Hermes's skill-store defense (Module 4.3): harness-managed learning with validation before persistence. The hosted model sync creates a second surface: your coding patterns leave your machine by design.

3 things Command Code does better

Taste learning: the diff-driven preference loop is genuinely novel. No other harness learns from accept/reject behavior.
Bundled design skills: ships 16+ design verbs (checkup, smell, review, deslop, typeset, recolor, motion) as integrated tools — the most opinionated design-aware harness.
Model breadth: supports Claude (Opus through 4.8), GPT-5.x, Gemini, DeepSeek, Qwen, Kimi, GLM — both BYOK and hosted.

3 things to fix

Open-source the harness: obfuscated TypeScript means no audit, no custom observability, no community trust.
Local taste model: the hosted sync is a data-exfiltration surface. Run taste-1 locally or document exactly what leaves the machine.
Add harness-managed learning validation: prevent poisoned preferences from compounding (same fix as Hermes's write gating, Module 4.3).

References

Command Code source — command-code npm package (v0.41.4, UNLICENSED, obfuscated). Unpacked at /tmp/cc-probe/pkg/package/.
commandcode.ai — homepage, launch announcement, docs/taste, pricing.
DD-08 (Hermes) — the closest architectural cousin: self-evolving skills vs. self-evolving preferences.
DD-03 (OpenCode) — the likely architectural parent (same tool vocabulary, TUI pattern).
Module 4 — memory tiers; the learned-memory layer as a 6th tier.
Module 4.3 — memory poisoning; compounding preference poisoning.
Module 10 — observability; OpenTelemetry built in but blocked by obfuscation.
Module 11 — security; the hosted-model-sync exfiltration surface.

# Deep-Dive DD-15 — Command Code: The Taste-Learning Harness **Course**: Master Course · **Deep-Dive**: DD-15 · **Duration**: 60 min · **Prerequisites**: Modules 0–12, DD-01–14 > *3,500+ stars. $5M seed. Closed-source TypeScript. The first harness that learns your coding taste from accept/reject signals and persists it as Markdown. A fundamentally new feedback model.* --- ## The Subject Command Code (commandcode.ai) is a terminal coding agent from Langbase, Inc. (founder Ahmad Awais, CTO Anand Chowdhary). Its defining contribution is **taste learning**: every time you accept, reject, or edit the model's output, the diff between what was generated and what you kept becomes a learning signal. This signal is persisted as plain Markdown (`taste.md`) and shapes future code generation. This is architecturally novel. Hermes (DD-08) has self-evolving *skills* — reusable procedures that compound. Command Code has self-evolving *preferences* — style constraints that shape every output. Same compounding-memory insight, applied to a different layer: not "how to do things" but "how you want things done." On Module 4's memory-tier framework, Command Code is the candidate for a sixth tier — *learned preferences* derived from behavioral signal, distinct from both static memory (what you wrote) and episodic memory (what happened). ## Architecture — The Diff-Driven Preference Loop The harness is a closed-source, obfuscated TypeScript bundle (~1.26 MB minified) distributed via npm. It uses React 19 + Ink 6 for the terminal UI (same pattern as OpenCode). The agentic loop exposes ~22 core tools: `read_file`, `edit_file`, `write_file`, `grep`, `glob`, `shell_command`, `monitor_command`, `explore`, `plan`, `todo_write`, `web_search`, `web_fetch`, `diagnostics`, `ask_user_question`, and the plan-mode tools (`enter_plan_mode`/`exit_plan_mode`). The architectural relationship to OpenCode is strong — same tool vocabulary, same `explore`/`plan` subagent pattern, same checkpoint/undo, same React+Ink TUI. The code is obfuscated so a literal fork vs. reimplementation cannot be proven, but the ecosystem overlap is confirmed by published npm packages (`command-opencode-plugin`, `commandcode-go-opencode-provider`) that expose Command Code's hosted API as a provider inside OpenCode. ## The Taste System — How It Actually Works The verifiable mechanism (stripped of marketing): 1. **Signal capture**: When you accept/reject/edit code, the harness computes the diff between what the model generated and what you kept. 2. **Profile generation**: A prompt template asks the model: *"Based on the correction diffs above, generate deeply personal and opinionated [preferences]..."* 3. **Persistence as Markdown**: The preference profile lives at `.commandcode/taste/taste.md`, with category-specific files (e.g., `.commandcode/taste/typescript/taste.md`, `.commandcode/taste/architecture/taste.md`). 4. **Server-side model**: The taste profile is synced to `api.commandcode.ai` via endpoints like `/learn-taste` and `/alpha/taste/`. The "taste-1" model that consumes the profile is hosted — the RL/symbolic reasoning layer runs server-side, not locally. 5. **Sharing**: The separate `taste` npm package (Apache-2.0) provides `taste push` / `taste pull` — Git-style sharing of preference profiles across machines and teams. **Honest gap**: The marketing calls taste-1 "meta neuro-symbolic AI with continuous reinforcement learning." The only verifiable mechanism is diff-driven Markdown profile updates + a hosted model. The RL/symbolic internals are not published. Treat the neuro-symbolic framing as vendor characterization until a paper exists. ## Key Design Decisions 1. **Diff as the learning signal.** The diff between generated and kept code is a clean, low-noise preference signal — the user's edit is the ground truth of what they wanted. This is a better signal than thumbs-up/down (which carries no information about *what* was wrong) and cheaper to capture than explicit feedback (the user is editing anyway). 2. **Markdown persistence.** The profile is human-readable Markdown, not an opaque embedding. The user can read, edit, and audit what the system learned. This is the legibility property most learned-preference systems sacrifice. 3. **Hosted taste model.** The taste-1 model runs server-side. This concentrates capability (one well-trained model serves all users) and creates a data-exfiltration surface (your coding patterns leave your machine by design). ## The Memory Architecture Command Code has a first-class memory system with explicit compaction: `MemorySelector`, `MemoryFile`, `CompactMode`, `CompactAgent`, `summarizeAndCompact`, `compactionCount`. Long sessions get summarized rather than truncated. It reads `AGENTS.md` and `COMMANDCODE.md` conventions, with session/project state persisting under `.commandcode/projects/`. The taste profile (`.commandcode/taste/`) is a separate *learned* memory layer on top of static memory files. This is the architectural distinction worth studying: **static memory** (what you wrote) vs. **learned memory** (what the system inferred from your behavior). The same compounding insight as Hermes's skills, applied to preferences instead of procedures. ## Permission & Safety Model Permission modes: `default`, `plan` (read-only exploration), `acceptEdits`. Escape hatch: `dangerouslySkipPermissions`. Separate sandbox mode via `COMMANDCODE_SANDBOX` environment variable. Permission flow objects: `PermissionRequest`, `PermissionResponse`, `PermissionDecision`, with `allowedCategories` allow-listing. Shell tools (`shell_command`, `monitor_command`) are the gated surface. ## Phase 4 — Security Audit **The exfiltration surface**: the taste profile syncs to `api.commandcode.ai`. The profile encodes your coding patterns, conventions, and preferences — which for a proprietary codebase is itself sensitive IP. The hosted model means your patterns leave your machine by design. This is the tradeoff: a hosted model concentrates capability, but it also concentrates your proprietary signal on someone else's server. **The preference-poisoning surface**: a poisoned preference (via prompt injection causing the model to learn a malicious pattern) compounds — it shapes every future output. The defense is the same as Hermes's skill-store defense (Module 4.3): harness-managed learning with validation before persistence. As-built, the taste loop has no validation gate between "the model inferred a preference" and "the preference is persisted." **Closed-source audit gap**: obfuscated TypeScript means no independent security audit is possible. The permission model and sandbox mode exist but cannot be verified without source. This is the structural cost of the closed-source distribution model. ## Score & Synthesize: 31/60 (10 modules scored; subagents n/a) | Module | Score | Key decision | | --- | --- | --- | | 1 Loop | 4 | React+Ink TUI, ~22 tools, plan/explore subagents | | 2 Tools | 4 | ~22, design-aware (16+ design verbs) | | 3 Context | 3 | explicit compaction (MemorySelector, CompactAgent) | | 4 Memory | 4 | learned taste layer + static memory (novel 6th tier) | | 5 Sandbox | 3 | COMMANDCODE_SANDBOX env var (gated, optional) | | 6 Permission | 3 | default/plan/acceptEdits + allow-listing | | 7 Errors | 3 | standard | | 8 State | 3 | session + project state under .commandcode/ | | 9 Verification | 2 | limited | | 10 Subagents | — | n/a (plan/explore are tool calls, not independent agents) | | 11 Observability | 2 | OpenTelemetry built in, but obfuscation blocks custom instrumentation | | 12 Prompt | 3 | closed-source; taste profile is prompt-shaped but not auditable | | **TOTAL** | **31/60** | | Command Code scores highest on Module 4 (Memory): 4/5. The taste system is a novel learned-memory layer. It loses points for being closed-source (Module 11 observability: 2/5 — OpenTelemetry is built in but the obfuscation makes custom instrumentation impossible) and Module 11 security (2/5 — the taste sync to a hosted endpoint is a data-exfiltration surface; the proxy architecture means your code patterns leave your machine). ### Architect's Verdict > *Command Code optimizes for personalization: the diff-driven taste loop creates a preference profile that shapes every output, a fundamentally different compounding model than skill accumulation. It sacrifices transparency (closed-source, obfuscated) and creates a new attack surface (preference profiles synced to a hosted endpoint = pattern exfiltration risk). Build on Command Code when personalization is the primary value and you trust the hosted model; do not build on it for security-sensitive codebases without understanding what leaves your machine.* ### MLSecOps Relevance > *The taste profile is Command Code's most interesting attack surface. A poisoned preference (via prompt injection causing the model to learn a malicious pattern) compounds — it shapes every future output. The defense is the same as Hermes's skill-store defense (Module 4.3): harness-managed learning with validation before persistence. The hosted model sync creates a second surface: your coding patterns leave your machine by design.* ### 3 things Command Code does better 1. **Taste learning**: the diff-driven preference loop is genuinely novel. No other harness learns from accept/reject behavior. 2. **Bundled design skills**: ships 16+ design verbs (checkup, smell, review, deslop, typeset, recolor, motion) as integrated tools — the most opinionated design-aware harness. 3. **Model breadth**: supports Claude (Opus through 4.8), GPT-5.x, Gemini, DeepSeek, Qwen, Kimi, GLM — both BYOK and hosted. ### 3 things to fix 1. **Open-source the harness**: obfuscated TypeScript means no audit, no custom observability, no community trust. 2. **Local taste model**: the hosted sync is a data-exfiltration surface. Run taste-1 locally or document exactly what leaves the machine. 3. **Add harness-managed learning validation**: prevent poisoned preferences from compounding (same fix as Hermes's write gating, Module 4.3). --- ## References 1. **Command Code source** — `command-code` npm package (v0.41.4, UNLICENSED, obfuscated). Unpacked at `/tmp/cc-probe/pkg/package/`. 2. **commandcode.ai** — homepage, launch announcement, docs/taste, pricing. 3. **DD-08 (Hermes)** — the closest architectural cousin: self-evolving skills vs. self-evolving preferences. 4. **DD-03 (OpenCode)** — the likely architectural parent (same tool vocabulary, TUI pattern). 5. **Module 4** — memory tiers; the learned-memory layer as a 6th tier. 6. **Module 4.3** — memory poisoning; compounding preference poisoning. 7. **Module 10** — observability; OpenTelemetry built in but blocked by obfuscation. 8. **Module 11** — security; the hosted-model-sync exfiltration surface.