← All writing

What is it like to build an app with Hermes?

Hermes keeps context as you go and runs the same core wherever you drive it from. Here is what that changes about a build session, and what to set up first.

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 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.

The same loop with other agents: Claude Code, Codex, Cursor, and OpenClaw.

Keep reading

agents

What is it like to build an app in Cursor?

Cursor puts the agent in your editor, with multi-file edits and a diff for everything. Here is how that changes the loop, and what to have set up first.

· 4 min read