DEV Community: Richard MacManus

5 Trends That Defined AI Engineering at World’s Fair 2026

Richard MacManus — Tue, 14 Jul 2026 23:21:21 +0000

At this year's AIE World’s Fair, AI engineering entered a new phase: building systems around agents, rather than just building with agents.

swyx’s note: thanks to Richard for covering AIE while I was working on the conference itself! Make sure you have opted into the AINews feed to get our weekday updates. AIE next returns to NYC, Oct 12-14, with a heavy focus on AI in Finance this year.

AI engineering has come a long way in three years. When swyxcoined the term “AI engineer” in June 2023, he was giving a name to a new kind of developer emerging from the big bang of large language models. It seems like ancient history now, but remember when we called the intersection of AI and software development “prompt engineering”? That wasjust months before swyx’s reframing.

The latestAI Engineer World’s Fair showed just how much the field has matured. Whether or not “AI engineer” has become a formal job title everywhere is almost beside the point. The engineering practices that have developed around AI over the past three years — building coding agents, designing harnesses, managing context, evaluating model outputs, and orchestrating increasingly autonomous systems — are becoming part of mainstream software development.

Rather than focusing on individual announcements at AIEWF, this post will pick out five larger trends that show where AI engineering stands in 2026.

1: The focus shifts from agents to the systems around them

One of the clearest ways to see how AI engineering has evolved is to compare two essays by former OpenAI researcher, and now co-founder of Thinking Machines Lab, Lilian Weng. Her influential 2023 article,LLM Powered Autonomous Agents, described the anatomy of an LLM agent in terms of planning, memory and tool use. AutoGPT, BabyAGI and GPT-Engineer were among her examples — proof-of-concept systems that suggested autonomous agents might soon become practical.

Her new 2026 essay,Harness Engineering for Self-Improvement, takes a very different perspective. Rather than focusing on the agent itself, Weng argues that the system surrounding the model has become just as important: the harness that manages workflows, context, permissions, evaluation, persistent state and continuous improvement. In other words, AI engineering has moved beyond prompting models toward engineering reliable systems around them.

Coding agent loop; Image by Lilian Weng

This shift was very much top of mind at AIEWF. I don’t think AutoGPT — the buzzy autonomous agent project everyone was talking about in 2023 — was even mentioned this year. Instead, the conversation revolved around Claude Code, Codex, Gemini CLI, Cursor, Warp and all the infrastructure needed to make coding agents dependable in production.

I remember being turned off by the AutoGPT buzz at the 2023 event, mainly because all the discussions seemed to focus on removing humans from the equation. But over the past few years we’ve learned that complete agent autonomy is not only unreliable, it isn’t even desirable — especially at scale. So it was a relief that at AIEWF, agents were largely positioned as augmenting the AI engineer, rather than replacing them.

During the OpenAI keynote on day 2 at AIEWF, Romain Huet emphasized this point. Using tools like OpenAI’s Codex, Huet argued, engineers can more easily collaborate with agents. As he put it, “software ate the world, and then AI ate software, but now what we’re here to say is that the AI engineers are eating the world.”

Despite the growing power of AI engineers, there’s also a sense that even the frontier companies don’t fully understand how their models are evolving — and so how much control can engineers truly have over them? In a separate keynote, Anthropic’s Thariq Shihipar talked about how their latest model, Claude Fable, is like an organic system — “models are grown, not designed.” There’s a “capability overhead,” he said, where “Claude gets smarter in a spiky way.”

All the more reason to build systems for agentic development, so that we can evaluate and monitor the outputs.

2: Loop engineering is the new control layer

By the end ofthe first morning of keynotes at AIEWF, it was clear that “loops” was the buzzword du jour of the event. Overuse of the term aside, it did highlight a key point of tension around AI engineering: how much control should agents have, and where should humans remain in the loop?

OpenClaw creator Peter Steinberger advocating for better loops.

One approach a lot of leading engineers are now taking is putting themselves in an “outer loop” — to oversee the largely autonomous work being done by agents in an inner loop.

Roland Gavrilescu is co-founder and CEO of Introspection, a new company building infrastructure for deploying self-improving systems. Inan interview with Latent Space, he explained how the concept of “autoresearch” provides the necessary feedback structure for agent loops:

“You can think of the system as having an inner loop and an outer loop. The inner loop is the primary system interacting with users and performing the work. Autoresearch is more concerned with the outer loop: another system that studies and maintains the primary system.“

The outer loop can include feedback signals, evals and human input. So it might still be largely autonomous, but the point is it is a method of oversight for the primary agent loop. Former Google engineering leader Addy Osmani had a nice line relating to this, saying that “agents can run much more of the inner execution loop, but that outer loop is still engineering.”

The term “loop engineering” came up multiple times during AIEWF, suggesting that it’s the human AI engineer’s responsibility to build these loop systems. Even the “ClawFather” Peter Steinberger, creator of OpenClaw, makes a point of putting himself in the outer loop. In the OpenAI keynote, he explained that “the agent runs the inner execution loop; I set the direction and I make decisions in the outer loop.”

The Loop Debate at AIEWF.

On the final day, an on-stage debate was held to determine whether fully autonomous agents were capable of managing loops in reality. Dex Horthy from HumanLayer claimed that “the hype is outrunning the discipline.” He wasn’t against loops, per se, noting that Kubernetes is built on control loops — “but they’re deterministic loops.” Geoffrey Huntley, creator of the Ralph Loop, admitted that loops were “frontier thinking,” but he had a wonderful analogy for the audience to ponder:

“[We’re] kind of like locomotive engineers now. That’s our job: to keep the locomotive on the rails.”

3: AI engineering enters the enterprise

This way of working with AI tools is starting to make its way into enterprises, typically via a new role called a “forward deployed engineer” (FDE) — where engineers work directly with organizations to implement AI capabilities.

Natalie Meurer , who leads FDE at Sierra,told Latent Space that implementing AI into organizations typically requires a lot of orchestration. “Every enterprise we work with wants to know how it can maintain everything its agentic ecosystem is capable of doing,” she said. “It needs to manage all the integrations and all the teams that contribute to the agent.”

Cursor’s Pauline Brunet talking about FDEs in an AIEWF session.

In her session at AIEWF, Cursor’s Pauline Brunet spoke about what their FDEs look to achieve in each engagement:

“When [we] walk away at the end of the engagements — and we, in our case, have deployed cloud agents, long-running agents, automations, [and] we’ve built applications on top of our Cursor SDK — that when we walk away, it is a strict ROI for them. That means they’re not gonna turn things off when we leave. ”

Another term used regularly at the conference was “software factory.” At Cursor, “a software factory means long-running agents helping people throughout that entire process,” said Brunet. This is basically what her team of FDEs is responsible for implementing, sitting alongside their customers’ engineers.

Where human engineers fit into a software factory is a key issue for enterprises. Warp CEOZach Lloyd explained that organizations need to choose which parts of the lifecycle to automate, and where humans should be brought into the loop.

Warp’s Zach Lloyd on building the thing that builds the product.

“You choose your repositories, the parts of the software lifecycle you want to automate, and the points where humans should be brought into the loop ,” Lloyd told us, regarding his company’s new software factory platform, Oz. “Different organizations and codebases will have different preferences. Do you fully automate code review? Do you have humans review certain high-risk changes?”

Another concern for enterprises is managing their unique organizational data in AI systems. Prukalpa Sankar from Atlan spoke at the conference about “context engineering,” explaining in a tweet that it’s important to consider “how context flows from your business systems into a shared company brain, then out to agents , copilots, and apps through MCP, APIs, and retrieval.”

Finally, lest we think enterprises are all-in on agents, Cursor’s Brunet pointed out that enterprise adoption of AI “is still concentrated among early adopters.” So finding “the right champions inside an organization” is a challenge for FDEs at this stage.

4: Coding agents replace IDEs as the developer interface

Perhaps the biggest practical change since the first AI Engineer Summit is how developers interact with AI on a daily basis.

In 2023, AI-assisted programming largely meant GitHub Copilot completing the next few lines of code. Most developers were still writing almost everything themselves, using AI as an intelligent autocomplete. But now we have tools such as Claude Code, Codex, Gemini CLI, Cursor and Warp. These “coding agents” can typically understand a broader objective, explore a codebase, modify multiple files, run tests, debug failures and iterate on their own work before presenting it back to the developer.

In Barr Yaron’s AI engineering survey, coding agents was a key trend.

The trend of coding agents now extends to web development too — with the recent release of Vercel’s eve, which the company calls an “agent framework,” comparable to its popular open source React framework, Next.js.

Vercel’s Chief of Software, Andrew Qu,told Latent Space at AIEWF that agents are effectively a new type of software. “They [agents] are not as predictable as web applications,” he explained. “The infrastructure can look similar, but the interaction, interface and outputs are much more dynamic.”

Qu added that the job of building a framework for agent development is far from over. “A year ago, we did not know sandboxes would become so important, or how much demand there would be for secure code execution and long-running jobs,” he said. “As we learn more from production, there will be much more to build.”

A for agents? Andrew Qu flashes the Vercel triangle logo.

This brings us back to the software factory trend, when developers are managing multiple agents. Charlie Holtz , CEO of Conductor, reminded the AIEWF audience that regardless of the coding harness, human engineers should always remain in control.

“I don’t want the future to be built around factories,” Holtz said. “I want to feel like a human, I want to be in the flow, I want to be in front of an orchestra, waving my baton.”

There was a sense during the conference that AI engineers aren’t yet aligned on which term is more appropriate: software factories or orchestras? Even Geoffrey Huntley, a loopmaxxing advocate, cautions about getting ahead of ourselves when it comes to automation:

“My biggest concern is that this time next year at the conference, we’re going to see a whole bunch of folks saying, our factories failed, our loops failed. These are things that we are still yet to figure out. ”

5: Every agent platform is building around skills

One of the talking points of the conference was “skills,” a concept Anthropic popularized when it introduced “agent skills” to Claudelast October. To borrow Addy Osmani’s definition, skills “encode the workflows, quality gates, and best practices that senior engineers use when building software.”

At AIEWF, Vercel’s Andrew Qu said that skills were “useful as portable, on-demand knowledge.” Introspection co-founder Roland Gavrilescu declared that AI engineering has shifted “from agent tools to agent skills.”

// Detect dark theme var iframe = document.getElementById('tweet-2071735248472379573-512'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2071735248472379573&theme=dark" }

In a session on the main stage, Philipp Schmid from Google DeepMind showed how using skills (and other declarative Markdown files) allows developers to use “agents without code.” His main point was that skills reduce the need for orchestration code , which up till recently was typically done using Python. His conclusion:

“Agents are just files. We write markdown files to extend capabilities. Agents can learn from those, can create their own files.”

Paul Bakaus , who used to work for Google but now runs a company called Renaissance Geek, has created an entire project around agent skills. Impeccable is an open source design skills system that gives coding agents a vocabulary for improving interfaces. He even advocates for “skill engineering” as a discipline in its own right.

Paul Bakaus: “You can’t one-shot design.”

Inan interview with Latent Space, Bakaus argued that most skills — and indeed most models — are not very creative. “They converge in one direction, and if everybody uses the same skill to do frontend design work or something like that, everything ends up looking the same,” he said.

Apparently there’s also such a thing as “skills hell,” which Matt Pocock said is comparable to previous developer frustrations — like frameworks hell. In a virtual presentation, Pocock provided a detailed checklist for writing skills, which you can see in the video below. In a nutshell, he advises writing fewer and smaller skills, and putting more thought into structure.

In a closing keynote, Y Combinator president Garry Tan implored the audience to use skills and other “AI native” approaches at their own startups or employers. Talking about business functions like sales, support and finance, Tan said that “the AI native companies that I see inside YC encode all of that as skills, written procedures that their agents execute, and they hire engineers whose job it is to maintain those skills, to do the work the skills can’t do yet. ”

But again, there’s a danger in relying too much on what agents autonomously do. As AIEWF attendee Tyler Brown noted on X, “autonomy without structure creates as much slop as leverage.” One of his learnings from the conference was to “re-visit and re-implement your skills” :

“Each time there’s a new model release, it’s as if you have a kid that grows from middle school to high school. You have to change the curriculum for them to get the benefits of the new model.”

Agent engineering at scale

It’s been three full years since The Rise of the AI Engineer and the first AI Engineer Summit. Looking back, it really is striking how much the conversation has evolved. Three years ago, the focus was on proving that LLMs could act as autonomous agents at all (and the answer at that time was usually no). AutoGPT, prompt engineering, and early orchestration frameworks like Langchain dominated the discussion back then.

Now that agents not only work, but have proven they can scale, this year’s AI Engineer World’s Fair was able to concentrate on the bigger problems: building reliable systems, orchestrating teams of agents, managing context, evaluating outputs and integrating AI into production software.

Agents are everywhere now… even on the back of San Francisco buses.

The term “AI engineer” may have started life as a new job title, but at AIEWF 2026 it felt more like a description of where software engineering itself is heading. Whether developers call themselves AI engineers, software engineers or Forward Deployed Engineers, they’re increasingly working with the same set of ideas: coding agents, harness engineering, designing loops, and orchestration.

Ahmad Osman on why local AI is catching up

Richard MacManus — Thu, 02 Jul 2026 14:10:36 +0000

Ahmad Osman has been advocating for local AI — running models on your own computer, workstation or dedicated hardware — long before it became a major theme at this year’s AI Engineer World’s Fair. He is also the founder of Osmantic, a company building open source software for deploying and operating local AI systems.

One of the themes emerging from AIEWF is that open source LLMs are becoming increasingly credible alternatives to large, proprietary frontier models. Since most local AI systems depend on open models, that shift strengthens the case Osman has been making. As he told Latent Space, “the gap between open-source models and closed-frontier models keeps shrinking.”

Osman makes the argument even more explicitly on a website called Open Source AI Must Win, where he writes that “the ability to study, build, repair, deploy, audit, adapt, teach, preserve, and run intelligence systems without asking permission is of existential importance.”

At AIEWF, Osman ran a two-part workshop on local LLMs and workstation agents. The sessions showed how quickly the field is moving — from models running on phones and laptops, to dedicated GPU workstations and enterprise infrastructure.

The interest in Osman’s workshops was not limited to hardware hobbyists, either. Attendees ranged from students considering their first AI-capable machine to enterprise executives thinking about model routing, private infrastructure and control over company data.

In the following Q&A, Osman explains why local AI is attracting more attention, how the model and hardware landscape has changed, and why he expects more developers and enterprises to begin treating local AI as serious infrastructure.

Making Local AI Tangible

Latent Space: Can you summarize what the workshops were about and what attendees were looking for?

Ahmad Osman: It was a two-part workshop, and there was more demand than we had space for. Some people unfortunately had to be turned away.

I came in with a website we had prepared to demonstrate local AI. It was essentially a hardware arena where people could compare systems such as the DGX Spark, AMD Strix Halo machines and other devices. You could run them against one another, or compare them with a frontier cloud model, and see the performance, output quality, speed and latency for yourself.

The main idea was to make local AI feel real. There is still a perception of it that dates back to 2022, when the models were much less capable. But everything has improved substantially since then.

There is still a lag behind frontier models — perhaps four to eight months — but local and open models are catching up. We wanted people to interact with these systems rather than just hear a theoretical argument about them.

The software behind the demo is open source and available on GitHub. The second workshop went further into setting it up and showing the full system in action.

A Model Is Only One Part Of The System

Latent Space: What is missing when people think of local AI as simply running a model on their own machine?

Osman: There is a big misconception about products such as ChatGPT or Claude Code. They come with a complete infrastructure around the model and around the agent. It is not just one thing.

A friend of mine bought an RTX 5090 to run Qwen 3.5 locally. He connected Claude Code to the model and asked it to change the RGB lighting on the GPU, but it failed. He then used the hosted Claude Code service, and it worked.

I asked whether he had given the local model internet search access. He had not. The model’s training data had a cutoff date, while the software and documentation he needed had since changed.

Once we gave the local system access to a search endpoint, it was able to complete the task.

That is the point: when you use a hosted agent, you are not only using a model. You are using search, tools, infrastructure and other services around it.

With our open source deployment system, we are trying to provide the complete experience — from a chat interface and document ingestion to agents, harnesses and search tools. That end-to-end layer has been lacking in the local AI ecosystem.

Interest Spans Students, Enthusiasts And Enterprises

Latent Space: Who came to the workshop? Were they mainly hardware enthusiasts, or people trying to build privacy-based applications?

Osman: It was a very wide audience.

At the end of the second workshop, a student asked me what hardware she should buy before going to college. An executive from Intel asked how we could get the software running on Windows in a particular way to improve the user experience.

Some people were enthusiasts. Others had very enterprise-focused questions. The common thread was interest in running something they can control, whether that means a model on a MacBook, a GPU at home or a dedicated cluster of high-end enterprise hardware.

People asked about enterprise model routing, data collection, traces, agent sandboxing and latency. Others asked how many GPUs I have at home. The answer is 22 RTX 3090s.

The breadth of interest surprised me. This was my first AI workshop, and I was lucky enough to do two of them back to back.

You May Not Need To Buy A GPU

Latent Space: Do developers need to go out and buy GPUs to experiment with local AI?

Osman: It depends on the size of the model you want to use.

You can run a four-bit Qwen model on a MacBook. At the other extreme, a very large frontier-class open model might require several RTX Pro 6000 GPUs.

But the broader trend is that models are becoming much more efficient. On a modern phone, you can now run a model that outperforms systems people were using in the cloud only a couple of years ago, without using all of the device’s memory.

That shows how far model efficiency has come in a relatively short time.

Models And Hardware Are Improving Together

Latent Space: Is the progress mainly coming from better software and models, or from hardware as well?

Osman: The models have improved dramatically.

Architectures are becoming more efficient, and many small improvements compound. Once a frontier lab demonstrates that a capability is possible, the open source ecosystem can work backwards from that and find ways to reproduce it more efficiently.

We are seeing models with tens of billions of parameters deliver performance that would previously have required much larger systems. Some of those models can run on an RTX 3090 released in 2020. Two years ago, that level of capability on that hardware would not have been realistic.

This is still a very new field, and we do not know the end state. But we know the systems will continue to improve.

The Rise Of Hybrid And Sovereign AI

Latent Space: Do you expect more applications to combine local and cloud AI?

Osman: Yes. Edge models are going to become more popular, and this is not only about consumers.

Enterprises are increasingly aware that the models they depend on may not always remain available to them in the same form. Providers can change quality, pricing, access or policies.

That creates an incentive to move toward dedicated hardware and secure compute. It does not necessarily have to sit on premises. A company can use dedicated, colocated hardware that it controls.

The benefit is that the quality of the model does not unexpectedly change, access cannot simply be removed, and the company retains control over its intellectual property, data, privacy and compliance obligations.

Open source models are also continuing to close the gap with frontier proprietary systems. We have seen a rapid progression through Llama, Mistral, Qwen, DeepSeek, GLM and Kimi models. Each generation narrows the gap.

Specialized Models May Be The Real Opportunity

Latent Space: Where do you think this leads for businesses?

Osman: I have believed for some time that smaller, specialized models are the future for many business use cases.

An enterprise may begin with a general model and collect traces, messages and feedback from how employees use it. Over time, that data can support a more specialized model tuned to the company’s particular work.

That can improve performance, reduce costs and make the system more useful for the business.

I also think open source model companies may increasingly monetize through licensing for fine-tuning, reinforcement learning or specialized commercial deployments.

As more companies move away from relying entirely on cloud APIs and secure their own compute, these labs will have an incentive to keep releasing strong open models while capturing value when businesses adapt them for proprietary use cases.

The broader direction is toward greater sovereignty: companies and individuals controlling their models, compute and data, while still benefiting from the rapid progress of the open source ecosystem.

Warp CEO Zach Lloyd on why software factories are the next phase of coding

Richard MacManus — Wed, 01 Jul 2026 14:28:23 +0000

I’ve been covering Warp for a couple of years now, and its rapid evolution from a command-line interface tool to a software factory platform has been fascinating to watch. The company began in the pre-ChatGPT days, in mid-2021, as a Rust-based terminal. Then when AI hit, it turned into a terminal with integrated coding agents.

But the competition among CLI tools has dramatically increased in recent years, including from Claude Code, Codex CLI, and Gemini CLI — three products backed by massive tech companies. This likely led to Warp’s decision to open-source its core CLI tool in April this year.

I’m a Warp user myself, finding it a much more sophisticated tool than my native Mac CLI. But I also admire the company’s ability to adapt to the times — a trait I spotted in CEO Zach Lloyd during my first interview with him a couple of years ago. So I was keen to catch up with him at the AI Engineer World’s Fair this week, where he presented a keynote session on software factories, the new term for orchestrating a team (ahem, a factory) of agents.

Warp has a new agent orchestration platform called Oz. It’s the company’s answer to what Lloyd believes is an industry transition, from engineers working interactively with agents to automated systems that continuously triage, implement, review, verify and monitor software changes. Oz is intended to connect multiple models and coding harnesses across local environments and isolated cloud sandboxes, while fitting into tools developers already use.

I spoke to Lloyd just after he made his presentation on-stage, which you can view on YouTube — it’s a good primer to what software factories are. In our one-on-one discussion, we get into the reasons Warp made its software factory pivot, how Lloyd came up with the term (independently, it seems, from similar companies — like Factory), and why he expects most significant software projects to operate some form of automated factory within the next year.

From individual agents to an automated development loop

Latent Space: When did you first come across the term “software factory,” and what attracted you to the concept?

Zach Lloyd: I can’t remember exactly when I started conceiving of it in those terms, but it was within the last six months, as the ability to automate software development became more complete.

We started with more one-off automation: run an agent in the cloud. A lot of platforms began there. Then it became: run an agent in the cloud on a timer.

The next question was, what is the most valuable loop to automate? The answer is basically the main loop of software engineering: triage, specification, implementation, review, verification, shipping and monitoring.

We began building toward this cloud-automation vision about a year ago, before we started building Oz. Over the past few months, the industry has also begun coalescing around the ‘factory’ term. There is an entire software-factory track at this conference.

It is literally what we are gearing our product around. In the next version of Oz, you will set up your factory, see what it looks like and manage the factory floor.

But I don’t care that much whether the term sticks. The essential shift is from interactive development to automated development. “Factory” is a useful metaphor for that.

Building the factory around existing workflows

Latent Space: In your presentation, you showed a software-factory stack containing several of your own products. Is Warp’s plan to provide the tools that make up that stack?

Lloyd: Yes. When you enter Oz, our cloud-agent platform, you will be walked through setting up a factory.

You choose your repositories, the parts of the software lifecycle you want to automate, and the points where humans should be brought into the loop. Different organizations and codebases will have different preferences. Do you fully automate code review? Do you have humans review certain high-risk changes?

The system then starts creating the loop. It might pull issues from Jira or Linear, let people submit them through Slack or Teams, and allow developers to redirect an agent from GitHub.

What is interesting from a product perspective is that most of the factory is not necessarily a new interface. It is an integration into people’s existing workflows. That is how we are conceiving it, at least.

Why Warp is moving beyond the terminal

Latent Space: When I first wrote about Warp, it was building a modern terminal. Code is still important now, but increasingly it is being produced by agents. It looks like Warp has broadened its product vision accordingly...

Lloyd: One hundred percent. A good way to think about it is that the company’s mission has stayed the same since we founded it. It has always been about empowering developers and companies to ship better software more quickly.

The product has evolved tremendously. It began as a modern version of the terminal, before the current AI wave. The next iteration was a terminal with agents built into it, which we are still investing in and which we have now open-sourced.

But the world keeps changing. The underlying AI improves so quickly that my view of the future is what I described in the talk: the interactive component is going to become less important.

As a company, you will want a central place where software gets built and where you can measure the efficiency of that process. I’m not afraid to redirect what the product becomes. As the underlying technology gets better, companies that do not adapt are going to be left behind.

Factory engineering as a new discipline

Latent Space: The word “factory” may be off-putting to some developers, given its connotations with mechanism and rote work. What feedback have you received from AI engineers about this pivot?

Lloyd: The concept resonates strongly with the economic buyer — the person running the engineering team.

For an individual engineer, it can sound mechanized and uncreative. They may think: “I enjoy coding. Why would I want to work in a factory?”

One point I tried to communicate in the talk is that this will become a new engineering discipline. I think it can be extremely interesting if you view the job as meta-engineering: building the system that builds the product.

It uses many of the same problem-solving skills. You are asking why an agent performs one task well and another poorly. How should you adjust its feedback? What context does it need? How should the workflow change?

But, for better or worse, the power of these systems and their ability to accelerate software development are so great that writing everything by hand is not going to make sense for much longer.

Where forward-deployed engineers fit

Latent Space: Another trend at the conference is forward-deployed engineering, which often combines aspects of product management, consulting and traditional engineering. How does that fit into the software-factory model?

Lloyd: Standing up a software factory potentially involves integrating with a large number of existing systems, depending on the company.

The factory will work most effectively when it has context from those systems and is integrated throughout the organization’s workflow. A lot of forward-deployed engineering work in this area is effectively a transformation project.

It requires real engineering from someone who understands how to configure and deploy one of these systems. We do some of that, and some of our competitors do as well.

I don’t know what the final state will look like. Warp is approaching it more as a platform business than a services business. But there is certainly a business today in sending smart people into a company to transform its workflow using these products.

Warp as the test bed for Oz

Latent Space: I use Warp as my terminal, including for some coding tasks. What happens to the original Warp CLI product in the software-factory era?

Lloyd: When we open-sourced Warp, we put the repository under the control of Oz. We built a software factory around the open-source project, using our own factory platform.

We are still trying to improve Warp as much as possible. We are doing it with the community, and we are doing a lot of it with agents. In that sense, Warp is a test bed for the factory concept.

But it is also a product used by almost a million developers, many of whom rely on it as their primary development environment. We use it constantly ourselves, and we still have internal engineers whose job is to improve it. We are simply approaching that work with a factory mindset.

Gradual automation, not an overnight replacement

Latent Space: What do you expect the next year to look like, in terms of adoption of software factories?

Lloyd: This will not happen all at once. Engineers are not going to wake up one morning and discover that a software factory has replaced their jobs.

Companies will start with specific use cases, certain types of issues or lower-risk repositories. Those are places where they may be comfortable not having a human review every single line of code.

They will see how it performs. Then the engineering challenge becomes: instead of merging 20% of pull requests automatically, can we get to 30%, 40%, 50% or 60%?

There will still be a remaining percentage of work done by people because it is too difficult, ambiguous or dependent on greenfield thinking.

But I think this shift will happen over the next year. My prediction is that every significant software project will have some engine of code — something resembling a factory — continuously driving it forward.

It will become similar to GitHub or CI/CD: a standard part of how serious software projects operate. I would be surprised if that did not happen.

Start by automating the annoying parts

Latent Space: There are thousands of AI engineers at this conference. What should they do to prepare for this shift?

Lloyd: Instead of only building the product directly, try building some automation toward a factory and see what it feels like.

Suppose you want an agent to implement incoming user issues automatically. What is involved in making that work? What prevents you from adopting it?

Perhaps code review is the bottleneck. Perhaps the agent is making changes, but you cannot clearly see what it did. You only discover those problems by trying to build the loop.

Get out of the mindset of building everything by hand. Find an annoying part of your job and try to create a loop that handles it for you using a factory approach.

AIEWF Daily Dispatch: Loops, Software Factories & Forward Deployed Engineers

Richard MacManus — Wed, 01 Jul 2026 04:46:21 +0000

Agents are here to serve you in the software factory.

Loops, loops and more loops. That word, loop, dominated conversations on day 2 of the AI Engineer World’s Fair — the first full day of keynotes and sessions. Perhaps knowing in advance what everyone would be talking about, AIEWF cofounder swyx titled his opening talk, “Loopcraft: The Art of Stacking Loops.”

@swyx began by commenting on the evolution of AI engineering from 2022: from chat, to tools, to goals. “These days, we’re all about automations,” he added. “We’re all about cron jobs and loops.”

Allie Howe, a member of technical staff for Keycard, then introduced the main stage track for the day: Software Factories. She referenced Geoffrey Huntley’s influential article, “everything is a ralph loop,” a theory about turning an AI coding agent into a persistent worker by repeatedly restarting it against the same spec.

Pablo Castro from Microsoft then talked about Foundry, the company’s “AI app and agent factory.” He claimed that a “learning loop” occurs when people and agents work together.

OpenAI’s Alexander Embiricos and Romain Huet were next on, and they focused a lot on Codex, the company’s coding agent. One point they made was that using multiple agents via loops can result in enhanced productivity.

“There will be a lot of talk today about loops,” Embiricos said. “And if you can connect the agent to not only the work that you have to do, but why it has to be done, that’s how you can get the agent to start to begin much more work. And then if you can connect it to what you do afterwards, review and deploy, that’s how you help it land much more work.”

This segued to a presentation by Peter Steinberger, the “ClawFather” of OpenClaw, now working for OpenAI. He too was all-in on loops, noting that he designs loops to manage agents. He added that deciding what to pay attention to is his main challenge nowadays — and that the future is “better loops” to help solve this issue.

Software factories

All this talk of looping led naturally to the concept of “software factories,” the subject of a presentation by Tereza Tížková from a company called Factory. She defined a software factory as “the whole loop, the whole lifecycle of developing software with autonomy.” She added that this doesn’t mean just coding, but also “collecting all the signals, reacting to user feedback [and] to logs, prioritizing what’s important, then orchestrating it all.”

Zach Lloyd from Warp also spoke about software factories; in fact, his thesis was that “software engineering will become factory engineering.” Loops in Lloyd’s framing were about improving the system.

In both Tížková and Lloyd’s talks, the emphasis was on having the agents doing the building for you. “You’ll be building the thing that builds the product,” was how Lloyd put it.

Afterwards, I went down to Warp’s booth in the AIEWF expo hall and spoke to Lloyd about software factories. I particularly wanted to know why Warp, which began as a CLI tool for developers, has pivoted into a ‘software factory’ platform where developers aren’t supposed to do coding anymore.

“The way to think of the factory is, like, pick your repos, pick the parts of the lifecycle that you want to automate, pick the ways in which you want humans to be brought into the loop,” Lloyd told me. “And different organizations [and] code bases will have different preferences for, like, do you fully automate code review [or] do you have humans do hard coding, stuff like that.”

I noted that the term “factory” might be offputting to many developers, since it implies mechanized rote work — much different from the creative era of coding we’ve just come from. Lloyd recognizes this is a challenge, but he argues software factories will become a new discipline of engineering — and that it still requires problem solving.

“For better or worse, the power of these systems is so great and the ability to accelerate is so strong that just writing stuff by hand...I don’t think it’s going to make sense for very much longer,” he said.

(For more from Zach Lloyd on software factories, stay tuned for a Latent Space interview to publish shortly.)

Forward Deployed Engineers

Related to loops and software factories, another theme from AIEWF today was the trendy new role of Forward Deployed Engineers. In an interview with Natalie Meurer, Head of Agent Engineering at Sierra, I established that FDEs are also sometimes called “agent engineers.” The main point is to help organizations adapt to agents, from a development perspective.

Meurer pointed out that a lot of the work of integrating AI into companies these days is in orchestrating agents.

“In practice, most customer-specific work takes place at the orchestration layer rather than in the models themselves,” she told me.

Cursor’s VP of Forward Deployed Engineering, Pauline Brunet, also ran a session today at AIEWF, in which she positioned FDE as part of the shift to software factories. “We partner with your organization to co-design and co-build your AI software factory,” she said. “We transform how you design, develop, and maintain software across your entire life cycle.”

(More insights from Brunet coming in an upcoming Q&A.)

Open Source AI

Another key theme from AIEWF today was the rise of open source AI. Zixuan Li, the head of intriguing new Chinese company Z.ai, was due to make an appearance at the conference. Because of travel issues, he couldn’t make it in person. He did make a virtual presentation, though, focusing on the company’s groundbreaking open LLM, GLM-5.2 — its “flagship model for long-horizon tasks.”

He also introduced ZCode, a harness that “supports all frontier models.” Li compared it specifically to OpenAI’s Codex.

HuggingFace’s Thomas Wolf then interviewed Olive Song from Chinese company MiniMax, which recently released its latest open-weight model, M3.

Open source AI is a big reason why local AI is becoming more popular. Ahmad Osman is the founder of Osmantic, a company building open source software for deploying and operating local AI systems. He spoke to us today and noted that open models have improved dramatically in recent times.

“Architectures are becoming more efficient, and many small improvements compound,” he said. “Once a frontier lab demonstrates that a capability is possible, the open source ecosystem can work backwards from that and find ways to reproduce it more efficiently.”

Conclusion

Those were the big trends from day 2 of the AI Engineer World’s Fair. I’ll be back tomorrow with all the action and analysis from day 3. Don’t forget to tune into the keynotes on YouTube if you’re following from work or home.

Forward Deployed Engineers and the future of software engineering

Richard MacManus — Wed, 01 Jul 2026 00:20:18 +0000

Cover Image: Sierra’s Natalie Meurer at the AI Engineer World’s Fair today.

Natalie Meurer is Head of Agent Engineering at Sierra, where she leads a global team of more than 120 engineers building conversational AI agents for enterprise customer service. Before joining Sierra, she worked in technology policy, taught herself to code and spent five years at Palantir.

Forward deployed engineering (FDE) was one of the tracks running at today’s AI Engineer World’s Fair. As Meurer explained to Latent Space before the session she presented, FDE began as a model for placing highly technical employees close to customers. But the title now covers a wide range of roles across the AI industry — including what Sierra calls the agent engineer : an engineer who combines systems integration and agent development with an understanding of customer operations, product, and the end-user experience.

In this Q&A, Meurer argues that FDE is defined more by accountability than by a particular skill set, adding that product and customer-facing engineering may be starting to converge.

Defining forward deployed engineering

Latent Space: What is your definition of a forward deployed engineer?

Natalie Meurer: That is really the point of my session: the role lacks a consistent definition.

If you look at its historical trajectory through to the present, it is more clearly defined by accountability to customers than by the shape of the role or the work you are doing.

There is power in having that accountability. But the range of associated skill sets has become so broad that it can almost become nonsensical.

Latent Space: How did you get into this kind of role?

Meurer: I began in technology policy. I was a policy nerd who learned to code on the side, which earned me a role as an engineer on the privacy team at Palantir.

I spent about five years there, working across law enforcement, defence and infrastructure engineering. I then went to business school because I wanted to bring the business dimension into the mix. After that, I joined Sierra and founded the agent engineering function.

Why Sierra calls them agent engineers

Latent Space: Did Palantir’s forward deployed engineering model influence the role at Sierra?

Meurer: Somewhat, although we intentionally called the role agent engineer , rather than forward deployed engineer.

Forward deployed engineering can mean so many things. We thought the title should capture the shape of the technical work, rather than only the customer-obsession element. That is why we chose agent engineer.

I see agent engineering as either a subset of, or adjacent to, forward deployed engineering. It describes a more specific form of customer-facing engineering focused on developing agents.

What an agent engineer does

Latent Space: What does your team do when working with a customer?

Meurer: Sierra builds conversational AI agents for inbound and outbound customer service. Our work includes integrating customer systems with low-latency voice and chat agents, as well as agents that operate over email.

The role requires technical skills such as data integration, but it also requires taste. You need to understand what sounds good and what will feel human when you are designing a voice agent. That element is particular to agent engineering.

Latent Space: Does an engagement begin with a defined use case, or do you help the customer decide what to build?

Meurer: We conduct discovery with our customers. We try to find the intersection between problems that are genuinely difficult — because we are good at difficult problems — and problems that will have a meaningful business impact.

In financial services, for example, that might begin with dispute processing. It is complex and needs to be done correctly, but it is also a high-emotional-intelligence interaction. If somebody sees a fraudulent charge on their credit card statement, they may be frightened, and the agent needs to calm them down.

Almost every Sierra customer is also somewhere on the trajectory towards using an agent as its front-door interactive voice response system: the first entity that answers when a customer calls.

The hard work is often above the model layer

Latent Space: How much of the work involves the underlying AI models?

Meurer: We think of our agents as an orchestrated constellation of models. Internally, we are constantly evaluating the best model for a particular job, and we bring the best of that work to our customers.

In practice, most customer-specific work takes place at the orchestration layer rather than in the models themselves. We sometimes integrate with a customer’s own models, and we also help customers use the platform and build agents themselves.

A lot of the work involves helping them apply their internal knowledge and context.

Custom deployments and reusable patterns

Latent Space: How much of the work is customer-specific, and how much can be reused?

Meurer: It is a mixture of both.

Every customer is building an agent that is intentionally specific to its organization. It should represent the best possible interaction with that particular brand.

Other capabilities are more reproducible. Answering questions from a knowledge base, for example, is a fairly universal problem. We also have industry experts across financial services, healthcare, travel and hospitality, and retail who bring domain knowledge and best practices.

But the fundamental appeal of what we are selling is something custom. We have seen large organizations across industries reach production in as little as 40 to 60 days.

Each agent is still customized around the customer’s APIs, systems, standard operating procedures, brand and tone.

Agents as enterprise systems

Latent Space: Is agent development becoming primarily an orchestration problem?

Meurer: There are many different flavours of multi-agent architecture. The term “agent” can refer to the entity that answers the phone, but it can also refer to a sub-agent or even a single prompt equipped with tools.

Every enterprise we work with wants to know how it can maintain everything its agentic ecosystem is capable of doing. It needs to manage all the integrations and all the teams that contribute to the agent.

Part of that is a change-management problem.

At Sierra, we tend to think of a single agent as managing the entire customer interaction, regardless of the particular subtask involved. We call those subtasks journeys.

Enterprises nevertheless need a way for hundreds or thousands of people to contribute to these systems, understand what is changing and follow a discrete release process.

Product engineering and FDE are converging

Latent Space: As companies develop more internal expertise, how will the FDE role evolve?

Meurer: I think it will remain customer-facing. But when code becomes cheap to author, it also becomes easier to translate customer insights directly into a product.

Product engineering and forward deployed engineering are therefore converging in some respects — at least among the best people in each role.

If you are a product engineer, you should be talking to customers. If you are a forward deployed engineer, you should be building the product. I think that is new.

Being customer-facing will remain important. Even if you had an AGI-like reasoning model that could work out how to perform a process each time, you would still need to encode that process appropriately.

You do not want the system independently figuring out how to handle an order return for the 100,000th time that week. You want a consistent process that it follows.

That makes customer service different from some other agentic use cases. A coding agent is often trying to solve a new problem for the first time. In customer service, you are solving essentially the same problem, framed slightly differently, perhaps 100,000 times a week.

That creates a different need for both the platform and the partner helping the customer encode its rules. Agents will become easier to build, but there will always be a place for people who can work with customers and translate what they learn into the product.

Why generalists may become more valuable

Latent Space: Will developers increasingly need product and customer-facing skills?

Meurer: That is my belief. I think the best developers will develop those skills.

Many people are asking what the engineering role will look like in one or two years. One view is that specialists will become even more important because they possess knowledge that is not readily available to an agent.

The other view, which I lean towards, is that generalists will become more valuable.

Forward deployed engineering has historically been the classic generalist role because it combines engineering with the customer-facing nature of the job.

Forward deployed engineers — or agent engineers — therefore inhabit one of the most forward-looking areas in AI and engineering.

Latent Space: Could “agent engineer” eventually become the default term?

Meurer: I am not sure. I expect engineering as a whole to move towards a more holistic definition, one that may incorporate more of what we currently call forward deployed engineering.

The market currently has go-to-market engineers, forward deployed engineers, agent engineers and AI engineers.

I think all of those will become different parts of the engineering craft. We will also discover entirely new jobs for engineers to do.