New Engineering Model

The engineering team is not a developer working with an AI coding assistant, nor a collection of autonomous agents operating without supervision (obviously).

It's an Optimizely SME working directly with the client, directing a set of specialist AI agents that build and test the work.

The agents provide the execution capacity. The SME provides the context, specification, technical judgment and quality control. Every change is held to the same standard the SME would apply if they were building it themselves, and decisions that require judgment remain with the human.

The result is a different unit of software delivery: one expert can direct substantially more execution capacity while retaining control of the decisions that determine quality.

How the work actually flows

The process does not start with an agent writing code. It starts with specification.

Most of the human effort goes into the specification.

Before an agent starts work, an SME builds the context required to define it properly: the client, the technology, the objective behind the requirement, the existing architecture, and the systems and integrations it needs to work with.

From that context, we produce a detailed specification that defines the required outcome, the engineering standards that apply, and the tests the work must pass to be considered complete.

A specification agent helps turn this into unambiguous, agent-ready tickets, with the requirements, constraints, standards and acceptance tests explicitly defined.

This is deliberately where we concentrate human effort. Agents are extremely effective at executing well-defined work. They are equally capable of executing an ambiguous requirement quickly and incorrectly.

The quality of the specification therefore determines much of the quality of what follows.

Then the agents execute.

Specialist build and test agents pick up the agent-ready tickets and work against the specification, engineering standards and acceptance tests already defined.

They execute continuously and at machine speed, moving the work through build and test without requiring a human to initiate each step.

The important point is that the agents are not deciding what good looks like as they work. That has already been defined.

Then it comes back to a human. Always.

An SME reviews the completed work in context: the code, the architecture, the infrastructure, the integrations and the original objective.

By this point, the defined tests have already established whether the work meets the specification. The human review is therefore focused on the things that are harder to encode as tests: technical judgment, appropriateness, maintainability and whether the solution makes sense within the wider system.

Nothing is considered complete until an SME has reviewed and approved it.

Every review also improves the system.

When an SME identifies a problem, we do not only correct the work. We determine whether the failure should also result in a change to the agent, its instructions, the specification process, the tests or the engineering standards it works against.

This creates a continuous feedback loop between human review and agent execution. Recurring mistakes can be removed from the system rather than repeatedly identified and corrected by people.

The same process applies as Optimizely changes. New platform capabilities, engineering patterns and changes in best practice are incorporated into the agents and the standards they operate against.

Over time, the delivery system accumulates the engineering knowledge and judgment of the SMEs directing it.

One system for humans and agents

This model requires humans and agents to work from the same system.

We use a single real-time engineering board where SMEs and agents work on the same tickets. Agents claim work, move it through build and test, report their progress and escalate when human input is required. SMEs can review the work, provide direction and intervene at any point.

There is no separate agent workflow running behind the engineering process. Humans and agents operate against the same specification, the same tickets and the same definition of done.

The board is therefore more than a record of the work. It is the operating environment for the delivery system.

The tooling has to support the model

Traditional project-management tools were designed around humans assigning work to other humans. Agentic delivery requires something different.

We use Linear because agents can operate as participants in the same workflow as the SMEs directing them.

Before work starts, an agent checks each ticket against the standards required for agent-ready work. Once those requirements are satisfied, the ticket can enter execution. An agent can then claim it, perform the work, move it through the workflow and escalate where human input is required.

This removes the need to copy work between systems or manually initiate each stage of the process.

The distinction matters. An AI-native engineering model cannot depend on AI being added around the edges of a conventional human workflow.

The workflow itself has to be designed for humans and agents to work together.

This is the engineering model we believe emerges when AI is treated as part of the delivery system, rather than simply another tool used by developers.