Skip to content

AI harness

Nano Harness

A small local-first desktop app for understanding AI coding workflows.

View on GitHubOpen source · MIT

The small version makes the architecture visible

Nano Harness is a personal, pre-release Electron app for working with AI providers under controlled autonomy. It connects provider adapters, workspace tools, approvals, runs, persistence, and inspectable evidence in one local desktop experiment.

I built it as a learning project rather than a product to compete with mature coding tools. I stopped before turning it into a complete product, but the code remains a useful reference for the architecture and tradeoffs behind an AI harness.

How it works

The runtime is organized around a run: a bounded attempt to satisfy one request. Electron owns the desktop shell, core owns orchestration and policy, infra owns providers and side effects, and shared owns contracts.

Electron desktop
  ↓
Preload bridge
  ↓
Core runtime
(runs, policy, approvals)
  ↓
Infra
(providers, actions, SQLite)
  ↓
Shared contracts

Start here

Install it where you work.

This is a pre-release source project, not a packaged product. Configure a provider in the desktop app or point it at a local llama.cpp or MLX OpenAI-compatible server before running a real session.

git clone https://github.com/joacod/nano-harness.git
cd nano-harness
pnpm install

Use it

Run the desktop experiment

Start the development app, choose Plan, Build, or Review, and use Advanced to inspect messages, tool calls, approvals, events, and validation output:

pnpm dev
pnpm test
pnpm typecheck && pnpm lint

A wrapped-up learning project

Nano is intentionally pre-release and unfinished. The visible workflow stays focused on basic chat, while larger ideas such as specs, skills, MCP, memory, and session compaction remain deferred behind feature flags. That boundary is part of the lesson, not a promise of a complete platform.

What it makes visible

  • A run is a bounded attempt to satisfy one user request.
  • Tool calls are contracts, execution boundaries, policy decisions, and results.
  • Risky actions stay behind approvals and workspace boundaries.
  • Local-first does not mean production-ready; provider configuration and external tools still define trust boundaries.