Key Takeaways

  • Command Code's "Taste" system, a meta-neuro-symbolic model, automatically infers a developer's specific "micro decisions" and repeatable coding behaviors. Amadou Wace cites an example: learning someone prefers pnpm for installs but npm global link for local CLI setup, going beyond explicit rules.
  • These learned preferences manifest as transparent taste files stored directly within your Git repository. This ensures they are version-controlled, always current, and reviewable in every pull request, solving the common problem of stale skill sets found in external models.
  • The system filters out information an LLM already knows by using a KL divergence loop, adding only truly unique preferences to the taste file. This keeps the guidance sharp, concise, and avoids redundant prompts.
  • Founders can use powerful, expensive models like Claude Opus or GPT 5.5 to "teach" an initial taste file on one project. Then, they can deploy "super cheap models" to continuously build on that foundation, maintaining high-quality, personalized output at a fraction of the cost, as Wace explains.
  • This approach is encapsulated in Command Code's Meta-Neuro-Symbolic Taste Learning System, which fundamentally changes how AI coding agents adapt to individual and team styles.

The Command Code's Meta-Neuro-Symbolic Taste Learning System

Here's how Command Code's Taste system works to personalize your AI coding agents:

  • Automatic Preference Learning: The Taste engine continuously observes user interactions, edits, and code merges to infer repeatable preferences and 'micro decisions' (e.g., preferred tools like Vitest or Meow, specific workflow steps like rebasing on main for PRs). It focuses on implicit patterns rather than grandiose rules.
  • Dynamic Skill/Taste File Generation: Learned preferences are translated into a taste file (a markdown file similar to skill files) which is stored directly within the Git repository, alongside the code. This ensures transparency, version control, and team reviewability.
  • Stale Context Avoidance: Utilizes a KL divergence loop to prevent the inclusion of information already known by the LLM into the taste file, ensuring only truly unique and valuable preferences are captured.
  • Manual Override and Augmentation: Users can manually edit the taste file to add explicit rules or correct learned preferences, assigning a 'confidence score' of one for human-authored instructions.
  • Taste Compliance for LLMs: Any coding agent (open or commercial) can be instructed to 'follow my taste' using the generated taste file, ensuring consistent adherence to project-specific or personal coding styles and workflows.

When This Works (and When It Doesn't)

This system is particularly effective for developers building multiple similar projects or teams maintaining consistent coding standards, as Amadou Wace points out, because it continuously adapts and compounds over time. It allows cheaper LLMs to achieve high-quality output by leveraging taste files built with more capable, expensive models. Think of it as investing in a high-fidelity blueprint once, then mass-producing consistent results with commodity tools.

However, this system isn't a silver bullet. It might struggle in highly experimental or greenfield projects where preferences and tooling change daily, as the continuous learning might introduce noise before stable patterns emerge. It also requires a certain volume of interaction to infer meaningful 'taste.' If you're a solo founder coding for an hour a week with wildly inconsistent habits, the taste file might lack enough robust data to be truly helpful. The value scales with consistent use and a well-defined coding environment.

What to Do With This

This week, apply the Taste framework to streamline your team's project setup and consistency. Pick a new microservice or feature development task. As your team (or you, if solo) codes, intentionally use a powerful LLM (like Claude Opus, as Wace mentions) for initial code generation. Then, consciously edit the generated code to your team's exact, implicit style—for instance, always using pnpm for installs, Vitest for testing, and ensuring PRs rebase on main before merging. Don't just accept the AI's first pass. These edits are the Automatic Preference Learning in action. Ensure these changes are committed, because the system stores your taste file directly in the repo, making it part of your version control and reviewable in PRs. Then, for your next coding task, try using a significantly cheaper LLM, feeding it the taste file that was generated and refined from the first project. Observe if the cheaper agent now adheres to your preferred micro decisions, demonstrating Taste Compliance and closing the quality gap at a lower cost.