The Enso Method Get started

HumanLayer · HumanLayer (Dex Horthy) · as of September 30, 2026

HumanLayer tried not reading the code. Its method is built on reading every line.

Tests can show that code works today. Nothing yet tells an agent whether that code will still be easy to change in six months, so HumanLayer puts a person in charge of that, and spends half an hour on alignment up front so the reading goes fast.

This guide is written by EnsoDynamics, which makes the Enso Method. We compare our method with others as fairly as we can, and we recommend another method when it fits you better.

Two philosophies at a glance

HumanLayer

Models can’t yet keep code easy to change, so align with the agent on the design, down to the code’s shape, and read every line it writes.

The Enso Method

Define the whole body of work in documents kept true for the life of the system, let the agent build it, and prove every requirement against real systems.

Where they differ

  • Specs serve one change Specs live as long as the system HumanLayer sits at the “Specs serve one change” end; the Enso Method sits at the “Specs live as long as the system” end.
  • Stops and asks Decides, records it, keeps going HumanLayer sits at the “Stops and asks” end; the Enso Method sits at the “Decides, records it, keeps going” end.
  • One change at a time The whole body of work up front HumanLayer sits at the “One change at a time” end; the Enso Method sits at the “The whole body of work up front” end.
  • Built to be watched Built to run unattended HumanLayer sits at the “Built to be watched” end; the Enso Method sits at the “Built to run unattended” end.

What they share

  • Built for one person Built for a team HumanLayer sits at the “Built for a team” end; the Enso Method sits toward “Built for a team”.
  • Light, few gates Heavy: roles and approvals HumanLayer sits toward “Light, few gates”; the Enso Method sits in the middle.

Neither end of a line is the right one. Every comparison uses the same lines, so you can compare across methods.

For now, the judge is you

“For now, the judge is you -- so we’re gonna put the code review back.” That line is the turning point of HumanLayer’s 2026 essay, “Why Software Factories Fail”.

The argument runs like this. Coding models are trained to make tests pass, and “there is no penalty for eroding codebase maintainability.” The cost of a bad design shows up “weeks, months, maybe even years” later, too slowly to train a model against. More review agents “raise the floor”, but they “don’t move the ceiling”: good design is the thing nobody yet knows how to train into a model.

HumanLayer learned this first-hand. In July 2025 it stopped reading its agents’ code. By November, one system was “easier to rewrite from scratch.”

So it spends human attention where it goes furthest. The agent builds in minutes, but review still takes hours, so the decisions come first: “30 minutes of planning saves hours of review.”

Settle the shape, then read every slice

  1. Pick a workflow. Oneshot for small, clear changes (about 40% of tasks); Research-Plan-Implement (RPI, shown on its homepage as QRSPI) by default; PRD-Oriented for big features.
  2. Questions, then research. The agent turns the ticket into questions about today’s code. A separate session answers them without seeing the ticket, so the research holds facts, not opinions.
  3. Design. A design discussion where “each decision stays open until you give a clear answer.” Big features split it in two: a product requirements document with mockups, then a technical design approved twice, for the system and for the code’s shape: types, signatures, call paths.
  4. Structure outline. The design becomes vertical slices, each ending with “something a person can run, see, or query.”
  5. Implement and review. The agent builds a slice, runs its checks and waits while you review it. Then a pull request.

In its founder’s words: “I’ll send off a model to do 1-3 slices at a time, and review the code as I go.”

Built for teams that will live in the code

HumanLayer fits senior engineers, and teams of them, changing a large existing codebase they will maintain for years. It promises to “move 2-3x faster, safely”, not tenfold, and the person who will review the pull request can help shape the design first.

It asks for your attention at every checkpoint and for reading the code. It runs in HumanLayer’s app with your own Claude Code or Codex subscription.

It suits you less if you want agents to run for hours unattended, if you’re building a throwaway prototype (“please, go on vibing”), or if you’d rather not read code.

Where the Enso Method made a different call

Both write down what they’re building before any code, research today’s code before designing, and build in thin vertical slices. They part ways on three things.

Who owns the inside of the code

HumanLayer

You do. On larger work you approve the types, signatures and call paths before the agent writes them, and on all work you read every slice.

The Enso Method

The agent does. The design stops at interfaces and data models; every requirement needs a test, against real systems wherever they exist, and you can read the diff before you commit.

Choose by situation: they guard different things. HumanLayer guards whether the code will still be easy to change next year. The Enso Method guards whether every requirement is proven when you aren’t watching.

How much planning a change deserves

HumanLayer

“Use the shortest path that controls the main risk.” Many tasks go straight to code.

The Enso Method

The whole body of work first: requirements and a design before the build, amended before each meaningful change.

Choose by situation: a stream of tickets in a product you know suits HumanLayer; a defined body of work for someone else, like a new system, suits the Enso Method.

Where the truth lives

HumanLayer

In the code. “For questions about current behavior, the live code beats any document.”

The Enso Method

In the requirements and design, kept current for the life of the system.

Choose by situation: HumanLayer keeps no standing spec to drift, which suits engineers who read code. The Enso Method keeps a record for people who don’t: stakeholders, auditors, the next team.

Where HumanLayer shines

  • A person owns the code’s shape. Approving it before code settles what you’d otherwise argue about in code review, “at the most expensive possible time to change your mind.” The Enso Method has no step where a person approves the code’s internal shape before it’s written.
  • Research without opinions. The researcher doesn’t see the ticket unless you name it, so it can’t steer toward its first idea. The Enso Method’s refinement loop hands its researcher the proposed answer.
  • Planning in proportion. A clear rule, and a workflow, for how much planning each change deserves.
  • Built for a team. Reviewers comment on the design before code, and agents act on their comments.

How the Enso Method differs, and why

No test yet shows whether code will stay easy to change, so HumanLayer keeps engineers in charge of it: they settle the design with the agent before it writes and read the code as it is written. The Enso Method leaves the code’s shape to the agent and proves each requirement with tests against real systems, so the build can run without anyone watching, and it keeps the requirements current for the people who decide, who may never read the code.

How the Enso Method works Compare all the methods

Get started

HumanLayer is a proprietary app and cloud (macOS, or Linux and Windows through a remote daemon), free for up to three people and 200 sessions a month, then $100 per user per month; you bring your own model subscription. Its current prompts aren’t published, so this page is written from its essays and documentation; start at docs.humanlayer.com.