# OpenAI Says the Real Work in AI Coding Is Building the System Around It

> Source: <https://shiftmag.dev/openai-says-the-real-work-in-ai-coding-is-building-the-system-around-it-11976/>
> Published: 2026-09-14 10:59:32+00:00

# OpenAI Says the Real Work in AI Coding Is Building the System Around It

Luis Velasco, Forward Deployed Engineer at OpenAI, says we’re entering a new field: **meta software engineering**.

Instead of building software that follows a predefined sequence of operations, engineers now need to **build the systems around AI agents** giving them context, tools, skills, constraints, and ways to evaluate their work.

## The hardest part is always the context

Code is easier for AI agents to work with. A codebase is structured, and the results are easy to check because the code compiles and tests pass. Business workflows are a lot messier, Luis explains:

In business workflows, the context is fragmented and spread across people and systems. A Slack message may explain why a decision changed, a legacy application may hold the data state, and an experienced colleague knows the part nobody wrote down. The work item we’re trying to automate depends on all of that.

For an agent to perform that work, engineers first have to reconstruct the context in which the work happens. Velasco breaks this down into three elements: **data, processes and systems.**

Data gives the information and domain knowledge for decisions. Processes define the rules, exceptions, and timelines. Systems provide the apps and APIs that let the work get done, with the right permissions.

The agent needs a **context layer that stays current and gives it the information relevant to the task**. Processes can be turned into agent skills, while APIs and other systems give the agent the ability to execute the work. Velasco showed this with an insurance claims workflow: the agent read an email and attachments, checked information across multiple apps, verified the claim, calculated the settlement, and prepared the response in 22 seconds instead of 20 to 30 minutes.

## Everything works fine until it has to run at scale

Getting one agent to complete a workflow is only the beginning. The challenge changes when **that workflow needs to run a thousand or a million times**. Then agents have to work in parallel, workflows can become interconnected, and one agent’s result can become the input for another.

This can be handled with agents and sub-agents that share context, or with an independent environment where agents can read and write shared state. That state helps them recover what has already been done and figure out what needs to happen next.

That’s why **the infrastructure around the agent matters**: queues, worker processes, checkpoints, and an artifact store with results, evidence, and reports. The goal is a durable execution environment that can recover if something crashes and avoid doing the same task twice.

## Multi-agent systems need more than extra model calls

Velasco **showed what this looks like at a much larger scale** with an experiment focused on CPU design: a campaign controller spread goals, budgets, and work across different CPU domains, with 512 agents working on areas like arithmetic, memory ordering, and control flow.

The agents, he explained, had different roles: some looked for potential bugs, critic agents challenged their findings, and verification agents tried to reproduce them. The campaign ran for four days, used about 1.4 terabytes of data, and produced evidence that could be shared with verification engineers before a problem reached production.

It shows that multi-agent systems need more than extra model calls. They need **coordination**, **shared state**, **verification**, and a **way to manage work across many agents**.

## The system can learn without changing the model

Another important part of Velasco’s approach is that the model itself **doesn’t always need to get more capable for the whole system to improve**. He compared it to an experienced employee.

A senior employee may have the same basic intelligence as when they joined a company, but after years of experience they know the systems, common failure modes and small details that make them more effective.

For an agent, that experience lives in the system around the model.

Updated context can provide relevant knowledge, updated skills can refine how work is performed, and evaluations can check behaviours that need to be verified. The model weights may stay the same while the system around the model gets better through repeated execution.

Velasco said **successful runs, failures, and human corrections all help here**. Successful runs show what to reinforce, failures show what needs improvement, and human corrections reveal gaps in the agent’s skills. Over time, those patterns can update memory, context, skills, or evaluation sets.

He showed this with a tax preparation agent: it started by completing about 25% of the required fields, and after six weeks of repeated runs, evaluations, and skill updates, it reached nearly 90%.

## **Engineering will become meta software engineering**

This changes the engineer’s role. As more execution is delegated to agents, **engineers spend more time designing and improving the system doing the work**. But engineering doesn’t disappear, humans still set the goals, make the trade-offs, and decide where human intervention belongs. 

That leads to Velasco’s broader definition of what engineers are building in an AI-assisted environment:

The highest value software artifact that we may be creating is not the code base itself, but the system of intent, the constraint, and the evaluation from which code can be produced in a systematic and repeatable way.

He calls this emerging discipline **meta software engineering**: building the environment around AI so agents have the right context, tools, skills, coordination, and feedback to do the work and get better over time.

The next chapter of software engineering is about building the systems around the code.
