# Deep-Dive DD-15 — Command Code: The Taste-Learning Harness **Course**: Master Course · **Deep-Dive**: DD-15 · **Duration**: 60 min · **Level**: Senior Engineer and above **Prerequisites**: Modules 0–12, DD-01–14 (especially DD-08 Hermes, DD-03 OpenCode) > *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.* --- ## Learning Objectives After this deep-dive, you will be able to: 1. Explain Command Code's taste-learning loop end-to-end — signal capture, profile generation, Markdown persistence, server-side model, Git-style sharing — and identify the one stage that is verifiable versus the stages that are vendor characterization. 2. Articulate the architectural distinction between **static memory** (what you wrote) and **learned memory** (what the system inferred from your behavior), and place Command Code's taste layer on Module 4's memory-tier framework as a candidate sixth tier. 3. Analyze the two security surfaces the taste model introduces — preference exfiltration and preference poisoning — and explain why both compound in ways that ordinary memory-poisoning attacks do not. 4. Defend the "diff as learning signal" design choice and explain why it is a cleaner preference signal than thumbs-up/down or explicit feedback. 5. Score Command Code against the 12-module rubric (31/60), explain where it wins (Module 4 Memory) and where it loses (Module 11 observability, Module 12 prompt), and judge whether the closed-source tradeoff is justified for a given deployment. --- ## The Thesis 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). The deep-dive's load-bearing claim: **the taste loop is a genuine innovation in the preference layer, and it introduces a compound-poisoning surface that no other harness in the roster has.** A poisoned preference, once persisted, shapes every future output. The same compounding property that makes taste learning valuable makes taste poisoning durable. --- ## 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). The diff is the feedback; the user does not have to perform a separate feedback action. 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 — Command Code keeps it. A poisoned preference can be spotted by a careful reader; an opaque embedding cannot. 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). This is the central tension of the design: the preference signal is more powerful when aggregated across users, but aggregation requires the signal to leave your machine. --- ## 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. The two layers compose: static memory (`AGENTS.md`) holds the project's explicit conventions; learned memory (`taste.md`) holds the behavioral residue of every accept/reject/edit. A new contributor reads `AGENTS.md`; the system has already absorbed the team's taste. --- ## 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. This is a standard permission model — adequate for the agentic loop, but it does not cover the taste layer's two novel surfaces, which the next section addresses. --- ## The Two Novel Security Surfaces The taste model introduces two surfaces no other harness in the roster has. Both compound. ### Surface 1 — Preference Exfiltration 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 defense is the same as any hosted-model tradeoff: understand what leaves the machine, and do not deploy on codebases where the preference profile is itself the IP. The taste profile is not your code — it is a distilled representation of how you want code written — but for a proprietary codebase with distinctive conventions, the representation is valuable. ### Surface 2 — Preference Poisoning A poisoned preference — via prompt injection causing the model to learn a malicious pattern — compounds. It shapes every future output. Where ordinary memory poisoning (Module 4.3) persists one bad entry, preference poisoning persists one bad entry that then influences the generation of every subsequent output. The poisoning is amplified by the same compounding property that makes taste learning valuable. 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." A poisoned diff becomes a poisoned preference becomes every future output shaped by the poison. **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 — you are trusting the vendor's claim about what the harness does and does not do. --- ## Score & Synthesize: 31/60 | 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 12 prompt (3/5 — the taste profile is prompt-shaped but not auditable in its effect on the model's behavior). ### 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.* ### 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). --- ## Anti-Patterns ### "The neuro-symbolic framing means it is safe" 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. Cure: treat the framing as vendor characterization. Verify the mechanism (diff to Markdown to hosted model) and judge the security surfaces on that, not on the marketing. ### "Taste poisoning is the same as memory poisoning" Ordinary memory poisoning (Module 4.3) persists one bad entry. Preference poisoning persists one bad entry that then influences the generation of every subsequent output. The compounding is the difference. Cure: treat the taste layer as a higher-stakes write surface than ordinary memory. Add validation before persistence; review the taste profile periodically the way you would review a `.gitignore` or a lint config. ### "The hosted model is just a convenience" The hosted model concentrates capability, but it also concentrates your proprietary signal on someone else's server. For a proprietary codebase with distinctive conventions, the taste profile is a distilled representation of how you want code written — and that representation is valuable. Cure: understand what leaves the machine before enabling the sync, and do not deploy on codebases where the preference profile is itself the IP. --- ## Key Terms | Term | Definition | | --- | --- | | **Taste learning** | Command Code's defining contribution: the diff between generated and kept code is captured as a preference signal, persisted as Markdown, and used to shape future output | | **Learned memory** | The candidate sixth tier on Module 4's framework — preferences inferred from behavioral signal, distinct from static memory (what you wrote) and episodic memory (what happened) | | **Preference exfiltration** | The first novel surface: the taste profile syncs to a hosted endpoint, so your coding patterns leave your machine by design | | **Preference poisoning** | The second novel surface: a poisoned preference compounds — it shapes every future output, not just one entry; the same compounding property that makes taste learning valuable makes taste poisoning durable | | **Diff as learning signal** | The user's edit is the ground truth of what they wanted — a cleaner preference signal than thumbs-up/down (no information about what was wrong) or explicit feedback (requires a separate action) | --- ## Lab Exercise See `07-lab-spec.md`. You build a minimal taste-learning simulation in Python: capture accept/reject/edit diffs, generate a Markdown preference profile, then inject a poisoned preference and observe how it shapes every subsequent output. The lab makes the compound-poisoning surface concrete — one poisoned diff propagates into the profile and then into every generated output. --- ## 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.