Introducing MendCode: a terminal-native runtime for AI coding

AI coding has outgrown the chat box. The work now crosses files, shells, browsers, package managers, background agents, memory, permissions, and review. A single prompt pane can start the work, but it cannot be the whole operating surface.

MendCode is built around a different assumption: the terminal is not a fallback. It is the runtime. It is where real projects already have their scripts, secrets, git state, tools, logs, and sharp edges. The agent should meet the developer there, with enough structure to stay useful and enough restraint to stay inspectable.

A harness, not another chat skin

The important part of an AI coding product is no longer the text field. It is the harness around the model: what context gets loaded, what tools are allowed, how risky actions are approved, which model handles which job, how parallel work is delegated, and how the user can audit what happened after the excitement fades.

MendCode treats that harness as the product. Model roles, subagents, skills, permissions, memory gates, TUI profiles, worktrees, packages, usage insight, and release flow all belong in one workflow instead of scattered across dotfiles and tribal habits.

Local-first by default

Your project state is not an abstract cloud object. It is a working tree with real scripts, generated files, ignored secrets, local caches, and half-finished ideas. MendCode starts from that reality. It reads what is in front of it, uses the commands you already run, and keeps the developer close to the blast radius.

Local-first does not mean anti-cloud. It means the default source of truth is visible. If an agent edits files, asks for permissions, proposes memory, or generates a handoff, that activity should be inspectable where the work actually happened.

Agents need reviewable memory

Memory is powerful when it helps an agent remember the right thing. It is dangerous when it silently becomes lore. MendCode pushes memory through review gates: proposals before persistence, project scope before global scope, and side-chat context for explaining what should or should not be saved.

The goal is not to make the agent feel mystical. The goal is to make it boringly reliable. If a preference, pattern, or architectural decision matters, it should have a visible path from evidence to approval.

The surface should be yours

Teams eventually want the coding surface to feel like their product. Not as decoration, but because workflow is identity. A fintech team, an IoT team, and a framework maintainer do not need the same home screen, status row, prompt chrome, or shortcuts.

MendCode profiles let the terminal carry that identity without forking the runtime. The surface can be branded, focused, or minimal while the underlying harness stays stable.

What comes next

This blog is where we will write the product notes that do not fit into docs or changelog entries: why a feature exists, how it should be used, and what trade-offs shaped it.

• How TUI profiles make the coding terminal feel like a product surface.
• How Memory Center keeps agent memory reviewable.
• How Usage Insights reads local evidence without becoming surveillance.
• How packages and skills make workflows shareable instead of copy-pasted.
• How permissions become part of the coding interface, not a modal afterthought.

MendCode is for developers who want the speed of agents without giving up the discipline of a real engineering workflow. Fast is good. Reviewable is better. The point is to get both.