Discovery is the “find” half, and it’s the piece I’m happiest with architecturally.

A provider is about as small as an interface gets. It answers one question, given a directory: which files here are importable? It also has to be a cheap check that cannot fail.

type DiscoveryProvider interface {
    Name() string
    Imports(dir string) []string
}

It returns file paths, not executables. Turning a file into executables is Flow’s job (or, for the formats Flow doesn’t know about, a parser on Mochi’s side). Nine providers ship today: Makefile, package.json, docker-compose, loose shell scripts, Justfile, Taskfile, GitHub Actions, Dockerfile, and Cargo. The first four are parsed by Flow itself; the rest are Mochi’s. Registration order matters. The first provider to claim a file wins, which is how conflicts get resolved without a merge policy.

Nothing is written to disk

The important design decision: discovered executables are generated at read time, not imported into your repo.

Mochi decorates Flow’s executable cache. Discovery persists only a selection of importable files per workspace, and the decorator regenerates their executables on every read, so they appear identically in the desktop, in mochi run, and in flow browse, while your repo stays exactly as it was. Generation happens against a virtual flow file that only ever exists in memory; its directory is the only thing that matters, because that’s what imports resolve relative to.

Failures degrade to nothing rather than propagating, so a bad provider can never break the cache it’s wrapping. Repeat scans are cheap: state stores file modification times as a fingerprint and short-circuits when nothing has changed.

Attribution has a constraint worth mentioning, because it shaped the design. Flow doesn’t inherit flow-file annotations into generated executables, and a slashed namespace would break its reference parser. Discovered executables get a single namespace plus a per-executable annotation naming the provider that found them.

The desktop app holds no business logic. Every operation is a Tauri command that shells out to the bundled mochi binary and parses its JSON output. Same binary, two surfaces.

A few details that turned out to matter more than expected:

It goes through a shell. A GUI app on macOS doesn’t inherit a login shell’s environment, so invocations source the user’s profile first. Arguments are POSIX-quoted, which matters because executable references contain a space. validate flow/ns:name has to survive the round trip as one token instead of being split into two.

Runs are tagged with their origin. Every spawned process gets FLOW_RUN_SOURCE=desktop. Without it, a run started by clicking Execute is indistinguishable from one typed into a terminal. Both would record cli, because that’s what Flow assumes when nothing says otherwise. The desktop is its own origin, and history should say so.

Secrets reach providers through the environment, never argv. Arguments are visible to every process on the machine; a child process’s environment is not.

Type Safety Across Three Languages

Mochi is Go, TypeScript, and Rust in one repo. JSON Schemas are the contract, vendored from Flow, which owns them. TypeScript types and the raw schema modules are generated for the frontend; Rust types are generated for the Tauri backend; Go gets the same types by importing Flow as a library rather than by generating them.

That’s a better arrangement than it sounds like: the schema is what keeps the Rust and TypeScript mirrors honest against the Go types they’re shadowing. Generation is orchestrated by Flow executables (of course), and CI fails if generated code is out of date.

This is the “remember” pillar, and it’s the reason Mochi exists at all. Agents run a lot of commands on your behalf. The transcript is ephemeral and unstructured, there one moment and gone the next. Mochi keeps the record: what ran, how long it took, whether it failed, and why.

Almost none of that storage is Mochi’s. Flow already records every execution to a shared embedded datastore, with a record that carries the reference, timing, status, exit code, process ID, log archive, and the useful part, provenance: source (cli, desktop, or mcp), clientName (claude-code, cursor), sessionId, and workingDir. Records are lifecycle-aware: they appear as running the moment a run starts and update in place when it finishes.

Two of those fields have justifications I like. workingDir exists because the workspace is already recoverable from the reference but the path is not, and it’s the only thing separating two checkouts of the same repo. sessionId exists so one assistant’s related runs stay grouped.

Mochi’s contribution is aggregation. A single pass over history rolls executions up per executable and per workspace, keyed by executable ID rather than by reference so that verb aliases like run, exec, and start of the same thing all collapse into one bucket. That same rollup feeds both search ranking and the dashboard, so history gets swept once per invocation rather than once per feature.

The dashboard turns it into four purpose-built views rather than one generic screen: Welcome for first-run setup, Pulse for health and what’s happening now, Launch for getting back to work, and Insights for activity over time. Insights surfaces the busiest, least reliable, and slowest workflows, plus recommendations. Those are plain heuristics today, a reliability rule and a duration rule, with stable IDs so that dismissing one survives regeneration. They are deliberately built as the seam that model-generated insights will later plug into.

The AI layer is provider-agnostic behind a two-method interface. Features depend on that interface rather than on a concrete client, which keeps where the tokens come from a resolution-time decision.

You bring your own key: OpenAI, Anthropic, Gemini, Ollama, or any OpenAI-compatible endpoint. Keys are never stored in Mochi’s config. The config file holds only a pointer to a vault entry, and the secret itself lives in the Flow vault. Each provider gets its own slot, so you can hold an OpenAI key and an Anthropic key at once and flip between them without re-entering anything.

Reaching the vault involved a small workaround. Mochi’s AI package can’t import Flow’s vault resolution, since it’s internal to Flow and off-limits the same way it is to the Rust layer. Instead it shells out to its own binary’s inherited secret command, exactly as the desktop does. Vault access always goes through Flow’s real implementation rather than a reimplementation of it.

The agent loop is bounded rather than trusted to stop on its own: a round budget and a wall-clock timeout, sized for analyzing a whole workspace while still stopping well short of a runaway. Tools come from Mochi’s own MCP server behind a three-tier permission policy, and every call is recorded as an audit entry. Confirmation is designed to cross a process boundary. If no confirmation handler is set, the loop returns a pending request rather than blocking, so the desktop can ask the user and resume.

Usage is logged locally as one JSON line per generation, with age and size retention, so you can see what your own key is being spent on.

Creative work you experience once. Development work you live in. That difference changes what you need from a partner.

The Bench

When I was at Recurse Center last summer, I started integrating AI more intentionally into how I build. Not for speed, for learning. I wanted to experiment with architectures I wouldn’t normally try, undo decisions cheaply, and see what held up. Flow was the natural workbench. It’s my own tool and I know every corner of it.

Over the last few months I’ve been building Flow Desktop and refactoring pieces of the core CLI with AI doing a lot of the implementation work. The experience has been different from vibe coding in ways that matter. In the HGSE projects, I was optimizing for something working. Here, I’m optimizing for something I can read six weeks later, find when I need it, and build on without second-guessing what’s underneath.

That changes what I actually delegate.

The Delegation Model

The architectural decisions stay with me. What the data model looks like, how executables get resolved, where state lives. What I hand off is the implementation of decisions I’ve already made. I describe the shape of what I want, review what comes back against that shape, and merge when it aligns. When it doesn’t, I say so explicitly.

A concrete example: I’ve been building an AI proxy backed by Cloudflare AI Gateway that sits across all of my tools. I decided on the architecture, what the proxy needs to do, how it integrates with the Cloudflare platform, what observability I want. AI implemented it. The Cloudflare MCP server made the feedback loop tight enough that I could test and iterate without switching contexts.

What makes this work is having a single place to see everything. Everything I’ve configured, discoverable from one surface.

One of the real risks of AI-assisted development is ending up with code you can’t navigate. Outputs that don’t connect to anything, a project that sprawls in ways you can’t audit. The workspace model keeps that from happening. I know where things live because I designed where they live.

I’ve also started using AI to enrich Flow itself, generating executable metadata, adding descriptions and tags, making the library more useful as it grows. Flow has an MCP server, so AI tools can interact with it directly. Watching an AI tool work with Flow rather than just producing files has been one of the more interesting parts of this.

Licklider’s framing from the last post still holds here. Set the goals, determine the criteria, perform the evaluations. That’s still your job. What’s changed is my confidence in what I can hand off once those things are set.

What It Produced

The review and iterate phase is where the real work happens. AI gets you to a first draft faster. Whether that draft is right is still a judgment call only you can make.

A few months of this produced Flow v2 and something I’ve been sitting on: Mochi. Development workflows have a way of becoming invisible. They exist, they’re just not anywhere you can see them. It’s a local-first dev ops dashboard built on Flow. Point it at a directory and it finds your development scripts and automations, turns them into a unified, AI-enriched dashboard. No cloud, no accounts, works with whatever you’re already running.

Executables view. Everything Mochi found across my workspaces, tagged and filterable.

Still early. If it sounds useful, the waitlist is at mochiexec.io.

I’m more convinced than I was last fall that the gap worth closing isn’t between what AI can produce and what you can prompt. It’s between what AI produces and what you actually understand. Building in a system you designed is one way to stay honest about that.