AI Engineer Code Summit 2026 Day 3 Morning: Ambition, the Software Atelier, and Factory Engineering

Day 3 of the AI Engineer Code Summit 2026 at the Hilton Union Square in San Francisco opened with three talks that look at the same question from different sides. Jason Liu of OpenAI asked what limits our ambition once execution becomes cheap. Armin Ronacher, CTO of Earendil, argued that we should learn to work well in a small workshop before we build a factory. Zach Lloyd, Founder and CEO of Warp, then described what that factory looks like and how an engineering team can run one. These are my notes from all three talks, together with photos of the slides and what I think the ideas mean for teams in the Philippines.

This post continues a series. My notes on the Day 2 afternoon sessions, the Day 2 morning keynotes, and the Day 1 workshops cover the earlier layers of the agentic coding stack.

Jason Liu on what limits ambition when execution is free

Jason Liu works on developer experience at OpenAI, and his talk was titled Ambition in AI. I did not take written notes during this session, so everything in this section comes from the photos I took of his slides.

His first slide, What we worked on this year, is a grid of nine cards that each pair a month and a product with an area of work. In my photo I can read eight of them. The Codex app in February covers coding, GPT-Rosalind in April covers biology, Sites in June covers web apps, Daybreak in June covers cybersecurity, GPT-Live in July covers voice, GPT-6 Astra in September covers computer use, an October entry covers physics, and a November entry covers 3D and simulation for engineering. The ninth card is hidden behind the lectern. I took the slide as a way of showing how quickly the range of work that models can take on has widened within a single year.

Three limits on ambition

The slide that I found most useful reads When execution is free, your ambition is limited by and then lists three things.

A later slide listed three fears that people bring to this shift: whether there will be more slop, whether AI will destroy our ability to think, and whether AI is going to replace us. His answer to those fears was a slide that asks what you do as an engineer.

The five cards read Use the thing, Notice where it breaks, Decide it needs another pass, No Great Work is one shot, and Iterate. Each card describes something a person does with the output of a model, which tells me that his answer to the fear of replacement is a description of the judgement that stays with the engineer.

The generator-discriminator gap

The last slide in this set was a chart titled The generator-discriminator gap. Its horizontal axis is time and its vertical axis is quality, and it draws three lines: your taste as a dashed line, model capability as a white line that rises in steps after each model launch, and the work itself as a blue line. A point on the chart is labelled Model catches up, and the red line of text underneath reads Failure: the model can generate far more than we can judge.

As I read the chart, the quality of the work climbs toward the level of our taste, and each step up in model capability lets the work rise further. The risk the slide names is that generation can run ahead of our ability to judge what was generated. I will come back to this idea because Armin’s talk, which followed immediately, describes the same constraint from the viewpoint of someone who writes software every day.

Armin Ronacher on building software like an atelier

Armin Ronacher’s talk, The Software Atelier, was the most reflective of the morning. An atelier is a small workshop where a craftsperson makes things with care, and he used the word as a contrast with the factory. Most of his examples came from Pi, the coding agent harness that Mario Zechner created and that Armin’s company, Earendil, now works on. Pi is a personal harness that provides the agentic loop and leaves you to add the rest on top. Armin’s talk reflected that philosophy, because every slide was deliberate and nothing in it was added for show.

Why the atelier comes before the factory

His thesis slide has three points. The first says that everyone is trying to build software factories. The second says that most of us, himself included, have not yet learned to use these tools well in the workshop. The third says that he cares about excellent software that aims higher than mass-produced slop. I find the second point generous, because it asks us to treat the skill of working with agents as something we are still learning. Zach Lloyd’s talk, which came next, argues for factories, so the two talks together made a useful pair.

The models improved while the harness stayed the same

The next section of the talk was titled Stable harness. Its slide, The machine got better, says that most prompting ideas were replaced by better models, that basic Pi did not change, and that he is much more capable today. In my notes, Pi stayed the same for a year while the models improved, and he now needs fewer corrections than he did with last year’s models.

A chart titled How far one prompt carries, by model puts numbers on this. It shows the minutes of agent work that follow one of his prompts and the number of tool calls in that stretch of work. The slide defines a run as the time from his prompt to the last agent event before his next prompt, and the footnote says the values are a percentile per prompt, grouped by the model that made most of the calls in the run. The exact percentile is hidden behind the lectern in my photo.

A second chart, Tool use by model, same harness, shows how the share of each kind of tool call differs between models. The GPT models spent between 30 and 38 percent of their calls on the read tool. Opus 5.5 spent only 6 percent on it and 43 percent on bash commands such as sed, cat, grep, and rg. A footnote explains that codemode, a feature I describe below, was not yet in Pi before the Opus 5.5 sessions. Because the harness was identical for every model, I think the chart is a fair look at the habits that each model brings to the same set of tools.

Human attention is the part that has not improved

Armin’s next point is the one I keep returning to. The machine got better, but the human did not, and we do not have more humans. Human attention is limited. Starting a piece of work became very fast, while finishing it and maintaining it did not. This is the same pressure that Jason’s chart described, since an agent that generates faster produces more for a person to judge.

He added that we are now taxing systems that were never taxed before, and he named GitHub, npm, and random third-party websites. I understood this to mean that a flood of agent-generated pull requests, packages, and page requests lands on shared services that were built for the pace of human work.

What the workshop needs from a person

For the workshop, he said the most valuable thing is the ability to say “not like this.” My note on this slide separates the true skill of a person from the skill of an agent. I read it as a reminder that an agent can have a skill file or a prompt, while a person has the judgement to recognize a result that is wrong. He also asked us to moderate our speed by our understanding, so that we only move as quickly as we can still follow what the agent is doing.

We should move only as fast as we can understand what the agent is doing.

Why resisting the urge to build your own helps everyone

The third section was titled The atelier, and its main slide is called Resist the temptation.

The slide says that building your own is sometimes bad for the ecosystem and that Wildwuchs, a German word that roughly means uncontrolled growth, harms interoperability. It adds that open protocols, specifications, and file formats are useful and that collaboration is human slow. His conclusion in my notes is that when agents handle the typing, we can spend that power on excellence, which he described as more software that is verified, fast, and written in memory-safe languages.

Where the harness can evolve

The last section covered three directions for the harness, and the first two concern how an agent behaves over time.

Jev is the model that Diogo Almeida presented on Day 2, and my notes on that talk explain why a calibrated score is something ordinary software can act on. It was encouraging to see a harness author arrive at the same pattern from the opposite direction.

Zach Lloyd on how software engineering becomes factory engineering

Zach Lloyd’s talk was titled Software Engineering Is Becoming Factory Engineering. His introduction slide describes him as a former principal engineer at Google who led work on Google Docs, with twenty years of engineering behind him, and as the founder of Warp. He began with a forecast that software factories are coming. Automation increases throughput, centralization makes it possible to measure and improve quality and cost, and the cloud is the place for security and governance.

What a software factory is

One slide listed four things that a software factory is not: a loose set of automations, a collection of AI teammates, a shared skills and MCP setup, and a personal agent swarm. The slide after it gives his definition.

I take the three qualities in that sentence one at a time. The system is code-defined, which means a team writes the factory down as files and can review changes to it. The loop is closed, which means the results of the work feed back into how the next piece of work is done. The thing being measured is the cloud coding agents themselves. In my notes, self-improvement is what closes the loop, and everything in the factory needs to be measured.

The diagram above shows the loop. A new product idea or a bug report enters at the top, and the work then moves through triage, spec, implement, verify, ship, and monitor before returning to the start. Dotted boxes mark three places where a person steps in: reviewing the spec, reviewing the code, and reviewing the product. I noticed that all three checkpoints are judgement calls, which matches what Armin said about attention. The factory spends human attention only where judgement is needed.

The factory engineering mindset

The mindset slide has two lines. The first says to measure everything yourself based on your own data, and the second says to continually improve. The toolbelt slide lists the instruments that support that mindset: blueprints, automations, evals, self-improvement, benchmarks, and A/B tests. A separate slide separates two kinds of work, where product engineering means building the product and factory engineering means improving the factory that builds the product.

A blue slide near the end summed up the shift with three lines. The first two, “Prompt your agents” and “Manage your agents,” were struck through, and the third read “Engineer your agents.”

The factories stack

The densest slide of the morning was The factories stack, which lays out seven layers from the bottom up. A bracket on the left marks the lower layers as either Warp hosted or customer hosted.

Two details in the table stood out to me. The orchestration layer lists Claude Code next to Warp’s own agent and Codex, which means the factory treats the agent as a replaceable part and puts the lasting value in the layers around it. The inference layer also lets a team bring its own inference through Bedrock or Vertex, which matters for organizations that must keep model traffic inside their own cloud account.

Measuring the factory with real numbers

Zach finished with a live look at a dashboard for a factory named eng-factory-slim over the last seven days.

The same dashboard breaks the cycle time into pieces. The median time from kickoff to a pull request is 20 minutes. A pull request then waits a median of 2.4 hours for its first human review, and 24 minutes pass between that review and the merge. The dashboard also reports 342 pull requests and splits the runs by agent type into Foreman, Custom, and Self-improvement. The longest wait in this factory is the wait for a person, so the figures show where the next improvement should come from.

What I am taking home

Read together, the three talks give a sequence for teams that want to adopt agents. Jason describes the limit, which is that generation can outrun our ability to judge. Armin describes how a single practitioner stays in control of that limit by keeping the harness small and moving only as fast as understanding allows. Zach describes how an organization applies the same discipline at scale, by measuring everything and putting people only at the checkpoints that need judgement. For most Philippine teams, I would suggest three first steps:

If you would like help designing the checkpoints, the measurements, and the agent workflow behind them, our Claude Professional Services team can work through it with you, starting from one workflow where a faster and better-measured cycle would make the biggest difference.