Eight agents walk into a software factory

During my sprint with veho.build, I had eight coding-agent sessions running at once. For a while, it felt like a superpower. Work that would normally happen in sequence was moving in parallel.

Then I started losing track of what each session was doing.

I would open one, reconstruct the context, figure out what it needed from me, and move to the next. The agents were producing code faster than I could review it or decide what should happen next. I remember that feeling more clearly than I remember the individual tasks.

It gave me an early look at the constraint we are all going to hit. AI is making code much cheaper and faster to produce. Engineering leverage is moving to the work around the code: giving agents the right context, teaching them judgment, testing that judgment, and redesigning the workflows that connect agents and people.

veho.build gave us a place to test this with an unusual user: someone who understands an operational problem deeply but does not know how software is built. They do not know there is a pull request. They may not know what Git is. They should not have to.

If we could help that person produce software that was not perfect but sufficiently good, we would learn something about the factory engineers will need too.

The builder sees the problem, not the machinery

When a builder changes an app in Claude Cowork, a software-development process starts behind the scenes. The builder never has to manage it.

A webhook starts an agent runner. A Staff Engineer agent reads the project specification, reviews the implementation, and produces a structured list of findings. The platform passes those findings back to Claude Cowork through MCP. Cowork fixes the code, saves a new version, and sends it through review again.

Underneath that experience are branches, commits, reviews, and repeated checks. The builder sees a plain-language conversation about what is wrong, what someone using the app would experience, and what needs a decision.

That translation matters. The Staff Engineer agent does not stop at, “This API route is missing an authorization check.” It explains that one user might see another user’s information. Cowork gets the technical detail required to fix the code. The builder gets the user and business impact required to make a judgment.

The review also catches less serious problems. A layout can be confusing. A button can appear to save something when it does not. A screen can work while making the user’s job harder. The builder should be able to decide whether those problems matter now without learning the vocabulary of software review first.

This was close to what I had wanted while juggling those eight sessions: agents that could understand the work, review it, keep moving when they could, and give me a clean digest when they needed me.

A ten-minute delay can become hours

Our first instinct was to block a build whenever the Staff Engineer agent found an issue it considered blocking. It sounded responsible. It also taught us that a technically correct gate can make the larger system worse.

When a review added less than ten minutes, builders usually stayed with it. Once the delay crossed ten minutes, it often became hours. The builder started another task, missed the next review, or never returned to approve the change. The code was waiting on a person whose attention had moved somewhere else.

We changed the balance. Authentication failures and bugs that could expose data to the wrong person still stop a build. We present many other findings, including cosmetic problems and some product gaps, as advice. The builder sees the problem and its impact, then decides whether it must be fixed now.

We are still tuning the Staff Engineer agent. I do not want to pretend we have found the perfect threshold. We are trying to distinguish a safety boundary from a judgment call the builder should own, without slowing the builder enough to break their flow.

These are the knobs in the title. An agentic software factory needs more than an on or off switch for review. It needs thresholds for severity, confidence, autonomy, and interruption. Set them too loosely and the system ships problems people cannot see. Set them too tightly and people work around it or stop using it.

Context has to change with the app

The review can only be as good as the agent’s understanding of what the app is supposed to do.

As part of the Staff Engineer work, we began creating a project summary from the builder’s original conversation and the app that was implemented. That summary becomes the project specification. Later agents can read it instead of reconstructing the app from a fresh chat.

This exposed another judgment call. What should happen when the original conversation and the implementation disagree?

At first, we treated the conversation as the authority. The reviewer blocked the change, and the builder had to update the specification before continuing. That produced accurate specifications, but it also interrupted people too often as they evolved their apps.

We made the mismatch advisory. The agent still points it out. If the implementation reflects what the builder now wants, they can update the specification and the warning stops appearing. The context stays current without forcing every feature through a requirements ceremony.

I now think of the project specification as a living contract. The phrase is imperfect because contracts sound rigid, and that is exactly what we learned to avoid. The specification should guide the next agent and record what the builder has decided. It should also be easy to correct.

We have seen what happens when context arrives too late. Some builders started apps independently in Claude and then tried to bring them into veho.build. One had accumulated so many assumptions that Cowork did not use the veho.build template at all. I tried to preserve what the builder had while satisfying the platform’s requirements. We ended up with a hodgepodge that is now being rewritten. A few times, we have asked builders to restart inside veho.build because retrofitting would take longer and produce a worse result.

The labor-planning app is the counterexample. It is at least as complex, but the builder started inside veho.build and worked methodically. He built a small piece, used it, then added another feature. He did not begin with a broad prompt and spend the next several rounds removing what he did not need. A clear problem definition probably helped him more than anything else. Each iteration gave the next one better context, and the result so far has been strong.

The software factory cannot be added at the end. It has to shape the work from the first conversation.

Engineers have to teach agents judgment

A generic code reviewer can find generic problems. That will not be enough for the next software factory.

Our Staff Engineer agent carries Veho-specific context. It knows how authentication works in veho.build apps. It reads the app’s product intent, not only the changed code. It looks for cases where a screen presents sample data as live, where a save button does not persist anything, or where the implementation runs but does not deliver what the builder asked for.

For apps that may become accessible outside Veho, we add a separate Legal review. We worked with our Legal team to express its policy as ladders of risk an agent can apply. The agent can inspect what an app collects, whether it has the right notices and consent, how long it retains information, and whether public access requires a different review.

We are also building a risk agent that will advise Claude Cowork while an app is being built. We want to prevent avoidable risk earlier, instead of only reporting it at the end. We have not solved this yet. Legal has produced a policy the agent can process. Now we need evals that show whether it applies that policy correctly.

The evals should resemble the mistakes we care about. Does the agent catch an authentication bypass? Does it recognize that a safety-intake form should not follow the normal path for a public app? Can it tell a static public page from a form that collects personal information? Does it flag a fake privacy link or a retention promise the code does not honor?

When an agent gets one of those cases wrong, correcting that answer is not enough. The miss should become a test. Then we improve the policy, the agent’s instructions, or the context it receives and run the eval again. The pieces improve in a loop.

That is high-leverage engineering work. Engineers will still write code, but more of their impact will come from creating conditions in which agents make good decisions repeatedly.

We are building an agent platform to make this repeatable, and I will share more about it soon. The lesson from veho.build is simpler: a capable agent is only part of the system. Its output depends on the context around it, the judgment people teach it, the tests that challenge it, and the decisions people keep for themselves.

Code volume changes the bottleneck

We already have a glimpse of what happens when technical users work this way. One Veho engineer, working as a single engineer, has shipped more than 1,000 pull requests with meaningful code contributions to production in less than six months.

That changes the engineering problem. When one person can produce that much deployed work, code generation is no longer the scarce resource. Review is the first bottleneck we have to get right.

Context and memory are close behind. Agents fail when they reason from the wrong history, carry an outdated assumption forward, or misunderstand how one part of the system constrains another. Faster code generation makes those errors arrive faster too.

Most engineering workflows were designed for changes produced at human speed. A pull request enters a queue. Someone reviews it. Tests run. The change merges and deploys. Feedback comes later. Automating individual steps will help, but it will not be enough when the number of changes multiplies.

We will have to redesign review, testing, CI, merging, deployment, and feedback around agent speed. Agents should keep moving inside known boundaries. They should stop when they reach a decision about architecture, product scope, data access, security, or a constraint that materially hurts the user. When they stop, they should produce a digest with the tradeoffs and approvals required, not hand a person five chat transcripts and ask them to reconstruct the situation.

That is the system I wanted when I had eight sessions open. I wanted agents to continue until they reached a boundary they should not cross, then bring me the decisions in a form I could process. I would still review and approve the important parts. I would no longer have to route every intermediate step myself. That will then allow us to test where that boundary should be.

What veho.build taught me about the factory

veho.build began as a way for people closest to an operational problem to build the tool they needed. It has also become a practical experiment in how software gets made when AI writes much of the code.

Let’s look at the labor-planner built by one of our Builders. The builder had a clear problem and worked incrementally. The Staff Engineer agent had product and platform context. Legal turned its policy into risk levels an agent could apply. Evals give us a way to test whether the agent applies that judgment. The review loop keeps the engineering machinery out of the builder’s way while returning important decisions in plain language.

None of this is perfect. We are still tuning which findings should block, how quickly reviews return, how the specification changes, and how far agents should go before asking for approval. I expect that work to continue because the balance changes as the agents improve and people trust them with more consequential work.

AI is making code abundant. The advantage will come from the context, judgment, evals, and workflows that help agents produce the right software without losing the human along the way.

This is the final article in the veho.build series. The next question is larger than veho.build. If agents can plan, build, review, test, and deploy at this speed, what should software engineering become? What roles should product and design play?

That is the journey we are on in our engineering and data science teams. The craft of engineering and data science is evolving and snapping to different boundaries. The roles we are used to working with in delivering software are being redefined around us. It is our job to help shape that frontier. More on this in a future series…