Welcome to zcoder: A Control-First Production Coding Harness, in the Building

zcoder, an innovative, control-first production coding harness, parallel by design and built to compound.

Welcome to the building of zcoder and the practice of AI production coding.

I’m building zcoder completely in the open. Cherry-pick whatever you find useful along the way, and be among the first to try it when it is ready.

Yes, it is yet another coding harness, but definitely not a me-too harness.

What is zcoder?

zcoder is a control-first, vendor-agnostic production coding harness being built in Rust, parallel by design, built to compound, and shaped by years of experience using AI for production coding.

Here is a high-level representation of zcoder’s model.

At the conceptual level, the goal is to bring the full power of AI engineering while keeping engineering in control. In other words, engineering has been reshaped, but good engineering is still what matters.

The three core tenets of zcoder are:

1. control-first: Control first, magic second is key to keeping AI grounded, bounded, and outcome-centric. It’s all about surface exposure. Control can be divided into two categories.

   • Surface Control: This defines what AI can see and where it can write. zcoder gives users tight control over which surfaces are exposed or hidden, including working files, knowledge, data, and even program APIs. Different requests in the same project might even have different surfaces.

   • Execution Control: Through aiprog, a core runtime for AI programs, tool calling becomes program running, and calls are sandboxed and scoped accordingly to the workspace and other rules. There is no unrestricted rm -rf access, even if the AI begs for it. By default, programs run in an embedded Lua sandbox bound to zcoder’s Rust APIs.

2. parallel by design: True parallelism is more than just running agents in parallel. It is also a reliable way to share and grow assets and coordinate execution, not only within a project but also across projects, agents, content, and programs. Concurrency is central to zcoder’s design and spans multiple dimensions.

   • Within a Project: A workbench is a core zcoder construct and a managed unit of work. It supports scalable, reliable concurrency within a project, even in a single worktree, with a minimal set of rules. Workbenches can also move between worktrees or generate other workbenches.

   • Across Projects: The home base is zcoder’s central local server. It supports reliable concurrency across projects so they can safely share common assets, resource access, and custom AI program execution.

3. built to compound: And finally, the cornerstone. For effective AI Production Building, everything is about compounding. Every AI interaction should be an opportunity to augment reusable knowledge, expertise, data, and programs. zcoder has three top compounding axes.

   • Organic Knowledge: zcoder has the concept of a knowledge set, a special collection of assets that can be seeded and organically augmented as work progresses. It can begin with deep external or internal expertise, then grow in a direction tailored to a user or team.

   • Managed Data: For more external or static material, zcoder has the concept of data sets, which can be refreshed from sources such as Git repositories or S3. They can be used in many ways, from documentation to structured data and even as a seed for knowledge sets.

   • AI Programs: Another key aspect of zcoder is its aiprog capabilities, which allow AI to write sandboxed programs that are disposable or persistent and reusable across projects. This brings greater predictability and reliability to repeating tasks, rather than repeatedly going back and forth through tool calls, and can reduce token usage for those tasks.

So, how will zcoder be used? For now, here is the initial operating model.

• zc - In most cases, the intended workflow starts by running the zc CLI command from the project directory where we want to work. It creates a .zcoder/ folder, making the project a workspace.

• zc base - More importantly, every zc CLI instance is designed to ensure that one and only one zcoder home base daemon, the local server, is running locally. It does all of the work.

• Because home base performs work for every zc instance, it can safely coordinate concurrency across projects while storing per-project data as needed. Shared data, state, and configuration live in ~/.config/zcoder/, while workspace data remains in the project’s .zcoder/ folder.

• The roadmap also includes a local web interface at http://127.0.0.1:414141. Its initial focus is a dashboard for observing activity, with interaction added progressively.

• The longer-term direction includes a cloud.zcoder.run service where users and teams can store and share knowledge, data, configuration, AI programs, and more, potentially through a ZPack format.

• And finally, if all goes well, we will add remote control as well, so that you can tele-command your zcoder from claude or openai client apps, and who knows, perhaps one day of a dedicated app or mobile web frontend.

So, in short, think tmux in many ways.

Why yet another coding harness?

Because I do not think Claude Code is the be-all and end-all of coding harnesses.

And while Claude Code and other harnesses are very good at what they do, I believe this category has considerable room for innovation if we give ourselves the opportunity for a fresh start.

Now, none of this came out of a vacuum. Let me give some context.

For the last 15 years, my consulting firm, BriteSnow, has built big cloud applications with small teams for leading San Francisco Bay Area organizations of all sizes, with an obsession for both speed and quality of delivery.

Over the last few years, we have applied that experience of building big applications with small teams to engineering-first AI production workflows. Diametrically opposed to vibe coding, these workflows put control first and magic second, with a laser focus on an engineering-in-the-loop paradigm.

This work led me to build genai, one of the leading multi-provider generative AI libraries for Rust; create the custom agentic runtime AIPack and its pro@coder coding harness; and develop highly optimized AI programs and libraries, including a code mapper, automatic context, and AI-optimized unified-diff capabilities through udiffx.

That work has been transformative, not only in how we build these technologies, but also in how we work with our clients’ teams to build big applications using the same techniques.

One thing became obvious: AIPack and pro@coder are game changers for executing these workflows, but they also revealed an opportunity to go further. Crystallizing their paradigms into a familiar-feeling but fundamentally innovative coding harness could bring significant value to AI production building.

That has led me to build zcoder (zcoder.run), an innovative new coding harness that is yet another coding harness, but definitely not a me-too harness.

Building in the Open

zcoder is being built completely in the open. Beyond publishing the source code, we will share concepts, ideas, design considerations, and code samples. Whether or not you become a zcoder user, the public build should provide valuable information about production building with AI.

Here are the key aspects that will be open from the start.

• The zcoder harness and all of its utilities are being developed in the open for release under MIT and Apache-2.0 licenses.

• We share principles, code designs, libraries, and practical techniques early and openly, so developers can cherry-pick what they need for their own applications and specialized coding harnesses.

• It is being built primarily, if not entirely, in Rust for performance, scalable concurrency, and operating-system portability.

• Many key parts of the harness are being built as independently useful Rust components that developers can use without zcoder. We have already started with udiffx, which is relatively mature; markex, which is simple but powerful; and aiprog, which is still in its infancy but is a potentially transformative runtime that turns tool calling into program running.

• We will also share production-building best practices through the pro@coder pack for AIPack, where many of these innovative concepts have matured. We will obviously use pro@coder to build zcoder.

In many ways, pro@coder is the founding father of zcoder

The core philosophy is innovation first, traction second.

zcoder should earn adoption, but even if the harness does not gain traction, its concepts, designs, and libraries can still create value by finding their way into other projects and helping move AI production coding forward.

This is going to be an interesting journey.

Subscribe to this Substack to follow the public build of zcoder.