My AI Development Workflow: Paseo, Graphify and Hindsight

Most articles in this series are about building AI features into a product. This one is different: it is the setup I use to build with AI agents every day.

Running coding agents straight from the terminal works, until it doesn't. Every session starts from zero. The agent re-reads files you explained an hour ago. The context you pasted dies with the terminal window. And when you step away from the desk, everything waits for you to come back.

Think of it this way:

A coding agent is like a contractor who is brilliant but gets amnesia every night, and who can only work while you stand on site.
Paseo is the site office: contractors check in there, the plans live there, and you can call in from anywhere.
Graphify is the blueprint archive, indexed so nobody rediscovers the building from scratch each morning.
Hindsight is the job diary every contractor reads before starting work.

Here is the whole setup in one picture:

Paseo: The Control Plane

Paseo is a self-hosted daemon that runs coding agents on your own machine, inside your full development environment: your repositories, your environment variables, your toolchain. It drives Claude Code, Codex, Copilot, OpenCode and Pi, and you connect to it from a phone, a desktop app, or the browser.

Why use a control plane instead of a pile of terminal tabs?

Agents run where the code is. They get your real machine, not a sandbox with a copy of the repo.
Work survives you. Sessions are not tied to a terminal window, so you can resume in-progress work later, or from another device.
Workspaces keep projects apart. Each project gets its own space, its own agents and its own state.
Schedules run without you. Recurring jobs fire on a schedule instead of waiting for you to remember.
The workspace is visible. Agent sessions, repository changes and transcripts stay together in the control plane.

A terminal tab holds one session. Paseo holds all of them, from any device you own.

The Harnesses: Claude Code, Codex and omp

The control plane supervises; the harnesses do the work. My daily drivers are Claude Code and Codex, driven through Paseo. For terminal-first sessions I use omp, a coding agent built by Stencil with subagents, plan mode, LSP and DAP integration, hashline edits and a native Rust engine doing the heavy lifting.

You do not need all three. That is the point of the pattern: the harness is replaceable. Pick the agent that suits the task and drive it the same way, through the control plane.

Graphify: Make the Codebase Queryable

The heaviest tax on any agent session is re-learning your codebase. Graphify removes it: the project turns a codebase, along with its docs, SQL schemas, configs and PDFs, into a queryable knowledge graph. It ships as a /graphify skill for Claude Code, Cursor, Codex and Gemini CLI.

The design choices are what make it useful:

Local and deterministic. Parsing happens on your machine with deterministic AST parsing. No vector store, so nothing drifts out of date while you sleep.
Every edge is explained. When the graph says two things are connected, you can ask why and get the reason, not a similarity score.
It indexes more than code. Docs, SQL schemas, configs and PDFs join the graph, and that is where half the real context of a project lives.

With the graph in place, the questions change shape:

> /graphify
> Which modules call formatDate, and what breaks if I add a timezone parameter?

The agent answers from the graph instead of grepping its way around the repository, and the answer carries the path it took through the code.

Hindsight: Memory That Outlives the Session

Hindsight is agent memory that learns. Agents retain what happened, recall it in later sessions, and reflect on it, so answers improve instead of resetting. Memory is organized into banks, it runs on Docker, pip or an embedded database, and it exposes a REST API and SDKs.

What goes in? The facts you keep re-explaining: this repo deploys with pnpm, never npm; the test suite is vitest; feature flags live in one config file; we chose Postgres over MongoDB for these two reasons. Retain them once and every session afterwards starts warm.

omp ships hindsight memory built in, so my terminal agent walks in already knowing the project. Other harnesses reach it through the API. Either way, the contractor with amnesia finally keeps a diary.

The Phone Test

Here is the test I use for a setup like this: can I drive it from my phone?

Mid-afternoon, away from the desk, something needs doing: a failing test, a small feature, a review someone asked for. I open Paseo on my phone, tunnel in to the machine on my desk, pick the workspace and send the task to an agent. The transcript streams while it works. Later I check the pull request separately in GitHub. The whole interaction is closer to sending a message than to running a build.

That is the point of the control plane. Supervision should not require your chair.

What This Buys You

Each piece removes exactly one tax:

Paseo removes the supervision tax: run and watch agents from anywhere, on your own hardware.
Graphify removes the re-learning tax: the codebase becomes a queryable graph with the reasoning attached.
Hindsight removes the forgetting tax: decisions and context outlive the session.
The harness stays swappable: Claude Code, Codex or omp, whichever fits the job.

If you want to try the pattern, start small. Set up Paseo first and get used to resuming sessions instead of losing them. Add /graphify when your codebase outgrows what one session can read. Add Hindsight when you catch yourself explaining the same thing a third time. The agents were already good. The workflow is what makes them dependable.

The Working Loop

The tools are useful individually, but the real gain comes from the loop they create:

Frame the problem. I give the agent an outcome, constraints and a definition of done, rather than dictating every edit.
Retrieve the context. Graphify answers questions about the repository; Hindsight supplies the decisions and conventions that are not obvious from the code.
Plan before changing. The agent proposes an approach, identifies the files and risks, and gives me a chance to correct its assumptions early.
Build and verify. The agent implements the change, runs tests and checks the result. For AI features, that also means checking retrieval quality, tool behaviour and failure modes.
Review the outcome. I inspect the diff, run the product and decide whether the result is correct, secure and maintainable. A green test suite is evidence, not approval.
Record what matters. Useful discoveries and decisions go back into memory so the next session starts from a better position.

This is the same loop I want from a good AI product: retrieve context, act, observe the result and improve the next attempt. Here, the thing being augmented is the development process.

Why Retrieval and Evaluation Belong in the Workflow

An agent with a large context window is not automatically an agent with good context. The important question is whether it can find the right information and explain why that information matters.

That is why I prefer queryable structure for repository knowledge and explicit memory for decisions. It is also why I treat tests, code review and evaluation as part of the same system. In a conventional application, a unit test checks a predictable function. In an AI application, an evaluation checks whether the system retrieved relevant context, used the right tool, answered in the right language and avoided inventing an answer.

The same principle applies to coding agents. I want to know not only that a change compiles, but also:

Did the agent understand the existing architecture?
Did it preserve the repository's conventions?
Did it test the important behaviour, including failure paths?
Did it make the smallest safe change?
Can another engineer understand and operate what it produced?

Those questions keep AI-assisted development anchored to engineering judgement instead of turning it into autocomplete with a longer transcript.

The Parts I Keep Human

I do not delegate responsibility just because I delegate implementation. I still choose the problem worth solving, set the constraints, decide what risk is acceptable and own the final change.

Agents are particularly good at exploring a codebase, producing a first implementation, writing repetitive tests, comparing alternatives and following a well-defined plan. They are less reliable at understanding unstated product priorities, recognising a sensitive security boundary or deciding when a technically elegant solution is the wrong trade-off.

The useful division of labour is therefore simple: let the agent do more of the mechanical work, while the engineer spends more time on intent, trade-offs and verification.

A Small Start

You do not need to build the whole stack on day one. Pick one repository and one recurring frustration:

losing a session when you close the terminal;
explaining the same architecture decision repeatedly;
watching an agent search the same files every morning;
manually checking the same output after every AI change.

Solve that one problem first. Add a control plane, a codebase index or persistent memory only when the next friction becomes obvious. The goal is not to surround yourself with more AI tools. It is to make the work more continuous, more observable and easier to trust.

The best agent workflow is not the one with the most automation. It is the one that lets you move faster without losing the context, judgement and accountability that make the software worth shipping.