What is it like to build with Hermes across terminal, chat, and desktop?

The distinctive part is continuity. You can start a change in your terminal, ask a follow-up question
from a chat window, and pick it up again later without re-explaining what you are building. That
matters most on the second and third weeks of a project, when the codebase has grown past what fits
in one conversation and the expensive thing is no longer writing code but re-establishing context.

What it does not change is the need for that context to be written down somewhere the agent can read.

## Continuity is not a substitute for a guide file

This is the trap worth naming early.

When an agent remembers your project, it is tempting to stop writing anything down and just tell it
things. That works until the moment it does not: a new session, a different surface, a teammate, or
simply a conversation long enough that the early part stops mattering.

A written guide file is different from remembered context in one important way: it is the same for
every session, and you can review it. If the rule "every query is scoped to the account" lives only
in a conversation, you cannot audit it, and you will not notice when it stops being followed.

So use the continuity for what it is good at, which is the running state of what you are building,
and keep the invariants in a file.

## The setup

Same as everywhere, and short:

1. **A guide file** stating the rules that must hold no matter what.
2. **A worked example** of the shape you want copied.
3. **One command that verifies**, so "done" is checkable.

With those in place, a session that starts from any surface begins in roughly the same position.

## What a session looks like

The request is ordinary:

```
Add a waitlist: an email address, a source, and a timestamp.
Free feature, not behind the paywall.
```

Two things are doing work in that prompt. "Free feature, not behind the paywall" is a product
decision the agent cannot infer, so you supply it. Everything else it can find: that a waitlist entry
belongs to an account, that queries go through the current account, that a resource ships with tests,
all of that is in the codebase already.

The output is the same shape as any other feature here: model, migration, permission policy,
controller, screens, route, tests. You review the migration and the policy carefully and the rest
quickly.

## Where the continuity actually pays

Three places, concretely.

**The second feature.** When you ask for something that relates to what you built last week, it
already knows the shape you chose and does not propose a different one.

**Debugging across sessions.** "That thing we changed on Tuesday broke sign-in" is a usable sentence
rather than a research project.

**Asking from wherever you are.** The most common real use is not building at all, it is asking a
question about your own codebase from a phone. "What decides whether an account can use the paid
feature?" is a question with an answer, and getting it without opening a laptop is genuinely useful.

## Where it goes wrong

**Remembered context drifts.** Something true in week one stops being true in week three, and unless
you correct it, it keeps being applied. Periodically re-state the important invariants and, better,
put them in the guide file where they cannot rot silently.

**Convenience encourages vagueness.** Because asking is easy, requests get shorter, and short
requests are ambiguous requests. The agent fills ambiguity with reasonable defaults, and reasonable
defaults are how you end up with a feature nobody asked for.

**Verification is easy to skip from a chat surface.** Running the test suite from a terminal is
natural. Remembering to run it after a change you made from a message thread is less so. Decide that
nothing counts as done until the checks pass, regardless of where the change came from.

## What it does not change

None of the [four categories where generated code is plausibly
wrong](/blog/what-your-agent-should-not-build) get safer because the agent remembers your project.
Sign-in, payments, email deliverability, and customer data separation are best handled by already
having them, tested, before the first prompt. That is [the argument for starting from a
kit](/blog/what-a-starter-kit-is).

The same loop with other agents: [Claude Code](/blog/building-with-claude-code),
[Codex](/blog/building-with-codex), [Cursor](/blog/building-in-cursor), and
[OpenClaw](/blog/building-with-openclaw).