Agents in the workflow, people at the top

The workflow is the interesting part

Most conversations about AI agents are about the agent. Which model, which editor, which extension.

That is the least interesting part. An agent that writes good code and an agent that writes bad code are equally risky if nobody looks at the output before it reaches production.

The question that actually matters is where the agent sits in the workflow, and what has to happen before its work becomes real. At 1367 Studio the answer is the same as it is for content: the agent drafts, a person decides.

Coding with Claude Code

We use Claude Code for the work that is well defined and tedious.

Scaffolding a component from an existing pattern. Renaming a field across a codebase. Wiring a new schema type through the queries and the front end. Writing the first version of a test. Reading an unfamiliar part of a project and explaining what it does.

It is good at all of that, and it is fast. What it does not do is decide how a system should be built. Choosing the content model, deciding what belongs in a component and what belongs in a schema, knowing which shortcut will cost us in six months, those are calls we make before the agent starts typing.

The practical rule is that a task is a good fit for an agent when we can describe the outcome precisely and verify it quickly. If we cannot say what "done" looks like, we are not ready to delegate it.

Versioning is what makes it reviewable

The habits that make agent-assisted work safe are not new habits. They are the ones good teams already have.

Every change happens on a branch. Commits stay small enough to read. Work reaches main through a pull request on GitHub, and somebody reads the diff before it merges.

This is the part people skip when they get excited about speed. An agent can produce a large change in a few minutes, which makes it tempting to accept a large change in a few minutes. Version control is what turns that output into something you can inspect, question, and reverse.

A pull request is not bureaucracy. It is the checkpoint where a person takes responsibility for the code.

Preview deploys turn claims into something you can click

Code review tells you what changed. It does not tell you how it feels.

Vercel gives every branch a preview URL, so before anything merges we are looking at the actual thing: the spacing, the animation timing, the layout on a phone, the page speed. An agent can tell you a component is responsive. A preview deploy shows you whether it is.

This is also how clients stay in the loop. Instead of describing a change, we send a link.

Sanity does the same job for content

On the content side, Sanity gives us the same structure.

Agent-generated content lands as a draft or as staged changes, not as a live page. Someone opens it, reads it, edits what needs editing, and publishes. Content that is wrong stays unpublished rather than going out and getting corrected afterwards.

Structure is what makes this work. Because content is modeled into named fields and defined types, an agent can be asked to update one field across many documents instead of rewriting whole pages. Narrow changes are easier to review, and easier to reject.

The pattern underneath all four

Lay the four side by side and the same shape appears.

Claude Code produces a diff. GitHub turns the diff into a pull request. Vercel turns the pull request into a preview. Sanity turns generated content into a draft.

Four tools, one pattern: the agent produces a proposal, and a person approves it. Nothing in the chain can put itself in front of a user. That is the design, not a limitation we are working around.

The speed gain is real, and it is not where people assume. We are not writing code four times faster. We are spending less time on setup, boilerplate, migrations, and the mechanical parts of a project, which leaves more time for the decisions that actually determine whether the work is good.

Where the human stays

Some parts of this work do not delegate.

Architecture. How a system is structured, what the content model is, and which trade-offs we accept are decisions with consequences an agent cannot weigh.

Taste. Whether an interaction feels right, whether a page has the correct rhythm, whether a design is finished. There is no prompt for that.

Voice. An agent can match a tone it has been shown. Deciding what a brand sounds like is an editorial choice.

Accountability. When something ships, a person is answerable for it. That does not transfer to a tool.

Why we work this way

Agents removed a lot of the slow parts of building software. That is worth using, and we use it every day.

What they did not remove is judgment. Every workflow we have described here exists to keep judgment in the loop at the point where it matters: before the merge, before the deploy, before the publish.

Agents in the workflow. People at the top. If you are working out how to set that up on your own projects, that is a conversation we are happy to have.

* this post has been verified by our team before PUBLISHED