AI is no longer a side tool in my development workflow. Codex is the day-to-day driver.

I currently run it with GPT-5.6 Sol. Most implementation work starts there: understanding a repository, tracing behavior, making changes, running checks, and explaining what changed.

But the model is only one part of the system. The workflow around it matters more than any single prompt.

My setup is intentionally small:

  • Codex drives implementation.
  • Herdr holds the agent sessions.
  • Zed is where I read and inspect the code.
  • Git worktrees isolate each task.
  • Loops handles work that benefits from bounded repetition and external verification.

The goal is not to remove myself from engineering. It is to separate execution from judgment and give each one a better environment.

The stack

Herdr is my terminal multiplexer for agent work. I can keep separate Codex sessions in separate panes, see which one is working or blocked, detach, and return later without losing the shape of the work.

Codex is the worker inside those sessions. GPT-5.6 Sol gives me a strong default for tasks that require repository-scale reasoning, implementation, and verification.

Zed stays open next to it. I use it to read unfamiliar code, inspect the diff, follow references, make small manual corrections, and decide whether the result actually belongs in the codebase.

These tools have different jobs. Herdr owns the sessions. Codex executes. Zed helps me understand and judge the result.

Start with a boundary

I do not begin by asking an agent to “build the feature.”

I begin by defining the boundary:

  • What outcome should exist?
  • Which repository or package owns it?
  • What must not change?
  • What evidence will prove the task is complete?
  • Which checks should fail if the implementation is wrong?

This usually becomes a compact task brief with acceptance criteria and verification commands. The clearer this boundary is, the less time I spend correcting work that was technically valid but aimed at the wrong outcome.

The prompt matters, but the acceptance boundary matters more.

One task, one worktree

Every meaningful task gets its own Git worktree.

I built shrubby to make that workflow cheap. It creates, lists, opens, copies, removes, and cleans up worktrees without making me remember paths or manually manage the surrounding directories.

The practical workflow is simple: create a worktree for the branch, open it, start a Codex session there, and leave the main checkout alone.

Isolation changes how I work with agents. I can run multiple tasks without mixing uncommitted changes. I can pause one branch while another continues. I can inspect or delete a failed experiment without disturbing the work I trust.

A worktree is not a security boundary. It is an ownership boundary for change.

Codex drives execution

Once the worktree and task boundary exist, Codex takes the implementation path.

I expect it to inspect the repository before editing, understand the local conventions, make the smallest coherent change, run the relevant checks, and summarize the evidence. For longer work, I want progress updates and explicit blockers instead of silent guessing.

GPT-5.6 Sol is useful here because the work is rarely just code generation. The agent has to keep the product request, repository structure, current diff, tool results, and verification state connected across the task.

I still review the reasoning through the artifacts it leaves behind: the diff, tests, command output, and final explanation. I do not treat model confidence as evidence.

Herdr holds the sessions

When several agents are active, terminal organization becomes part of the engineering system.

Herdr gives each task a durable pane. I can see which sessions are working, idle, or waiting for input. I can split the terminal, move between tasks, detach, and return without rebuilding the entire context in my head.

This matters more than it sounds. Parallel agent work becomes noisy very quickly when every session is another anonymous terminal window. A multiplexer turns those sessions into a visible workspace.

I do not use it to maximize the number of agents. I use it to keep a small number of active tasks legible.

Zed is for reading

Zed is where I slow the workflow down.

After Codex makes a meaningful change, I read the affected path in the editor. I look at the surrounding code, not only the diff. I check whether the new abstraction fits the existing system, whether names communicate the right ownership, and whether a passing test is proving the behavior I care about.

Some fixes go back to Codex with better instructions. Some are faster to make directly. The important thing is that the review step is deliberate.

AI makes producing code cheaper. It does not make reading code optional.

Loops add verification

Some tasks are too uncertain for a single implementation pass but structured enough to repeat safely. That is where I use Loops.

Loops creates or reuses an isolated worktree, asks a coding agent to implement the task, runs verification gates, and feeds failures into the next attempt. A run succeeds only when the agent exits successfully and every gate passes. Limits on iterations, time, output, and lack of progress keep the process bounded.

The verification gates are the important part. Deterministic commands can run tests, builds, linting, type checks, or schema validation. A read-only agent gate can review semantics, architecture, UX, or security after those commands have passed.

This is different from telling an agent to keep trying until it feels done. The loop has an external definition of success.

I use Loops when:

  • The task has clear acceptance criteria.
  • Failures can be turned into useful feedback.
  • Verification is cheaper than supervising every attempt.
  • The work can stay inside an isolated worktree.

I do not use it for vague product decisions or architecture questions that still need human framing.

The daily cycle

The full workflow usually looks like this:

  1. Frame the outcome and the evidence required.
  2. Create an isolated worktree with shrubby.
  3. Start Codex in a Herdr pane using GPT-5.6 Sol.
  4. Let the agent inspect, implement, and run checks.
  5. Read the result in Zed and tighten the task if necessary.
  6. Move the work into Loops when repeated, gated attempts are useful.
  7. Integrate only after the diff and verification evidence make sense.

Not every task needs every step. A small fix may move from Codex to Zed to commit in a few minutes. A larger migration may use several worktrees, multiple Herdr panes, and a bounded loop with command and review gates.

The workflow scales by adding isolation and evidence, not by removing control.

What stays human

I still own the parts that determine whether the software is worth shipping:

  • Product intent.
  • System boundaries.
  • Risk and tradeoffs.
  • The definition of done.
  • Final review and integration.

Codex can do a large amount of the execution. Loops can repeat that execution against explicit gates. Herdr can keep the sessions alive. shrubby can keep their branches separated. Zed can make the result easier to inspect.

None of those tools decides what the product should become.

That is the balance I want from day-to-day AI development: the agent drives the work forward, while I remain responsible for the direction, the evidence, and the final decision.