At AI Engineer, seven companies share their hands-on practices

The two-day AI Engineer Summit felt like walking into a masterclass on startup life.

There were engineers, designers, and product leads — but they all shared one identity: Builders, people who get their hands dirty and build things themselves.

These frontline founders from around the world brought different facets of their entrepreneurial lives to the stage. Ryo, formerly of Cursor, spoke about his original love for design. The Manus team gave a detailed breakdown of their experience using mono to share context across the entire company.

In this masterclass, we picked up some fascinating findings. For instance, OpenClaw Foundation — with just five engineers — spent $1.27 million on testing alone in a single year. HeyGen now generates 15 million agent videos per month. Kimi K3.1 Pro enabled someone with zero experience to build a near-AAA game.

Here are seven teams' frontline practices.

Cursor / ryOS

Ryo didn't spend much time on technical details or design this time. He talked a lot about himself and his reflections on life.

He described moving back to Taipei from San Francisco, how his days suddenly opened up, how he was distanced from familiar rhythms, and how he began to rediscover the experience of living. On screen flashed photos he'd taken of green canopies on Taipei streets. He said a conversation, an untraveled road, a song played on repeat — all made him realize he still had the capacity to feel these things.

Tools have gotten more powerful, so why do we feel more anxious? A single sentence generates a website, a few minutes produces a feature, you wake up and the machine has done a night's work for you. But why does it always feel like you're falling behind?

It's as if everyone's gotten smarter, accomplishing more. Abilities that once took years to build up, now anyone can apparently acquire with a single sentence.

How do we preserve our own judgment, attitude, and way of living?

He opened a product interface on stage and asked the audience: mood score, streak count, daily reminders, weekly reports — if you had to remove one, which would it be?

For Ryo, he'd drop the streak count, daily reminders, and weekly reports. He didn't want to feel like he owed something just because he missed a day. He didn't want to add another assignment to life.

He also used a jazz ensemble as metaphor. In a jazz band, not everyone needs to play the most notes, not everyone needs to prove they're the best. Some play, some listen, leaving space to connect, unafraid of occasionally losing the rhythm.

Ryo said he chose to become a designer in the first place out of pure liking, curiosity, wanting to get closer, wanting to see if he could create that feeling too.

Manus

Fan Bin, Manus's head of agent engineering, shared the team's internal explorations and thinking around AI-native ways of working.

Tao Zhang, Manus's co-founder, opened his article "Ten Thousand Dollars in Tokens Per Capita: Using Manus to Rebuild Manus" by describing a common scene in the Manus office today: a product manager puts forward a requirement, and an engineer forwards that requirement verbatim to AI — maybe Manus, maybe Codex — which then completes the development end-to-end.

One engineer can handle 10–20 requirements simultaneously.

But early on, achieving end-to-end requirement development wasn't easy. The Manus team found that organizational context was scattered across different individuals, code repositories, and internal systems. Humans still had to gather this context before AI could get to work.

Which code repositories does a feature span across after several iterations? How to test after development? Which service to deploy first at launch?

To solve this, Manus tried putting context, tools, and tasks within reach of everyone.

First, a tool platform called Manus-mono, containing code repositories, knowledge bases, and internal tools. Second, making tasks public — team members can see each other's agent tasks and jump in to collaborate directly.

A new hire just needs to have Manus set up mono for them, and they can start developing right away.

With mono, product and design colleagues also began actively participating in development work. One particularly proactive product manager has already merged over 160 PRs.

Fan Bin shared another example. The company's internal permissions system had long been neglected, so he had Manus sort out everyone's roles and actual usage, identifying permissions that could be simplified.

Because mono was integrated with the company's internal systems, Manus quickly completed the audit, then sent private messages to colleagues one by one to confirm requirements, adjusting permissions based on feedback. The entire process took just two days.

Interestingly, these messages carried a "from Manus" tag. When Fan Bin checked colleagues' replies, he found that roughly 30% of the responses were also completed by Manus.

OpenClaw Foundation

At peak, testing alone cost them $1.27 million per year.

For a nonprofit foundation with only five or six engineers, this is an enormous expense.

But the "Little Crayfish" team wasn't just worried about compute costs.

As agents write more and more code, they also keep adding new tests. One might say, just remove the tests then. But without tests, how do you confirm the agent actually completed the work? And without removing them, how do you further speed up the entire process?

This involves a concept called Cycle Time, one of the metrics tracked by engineering effectiveness frameworks like DORA.

It applies to agents too. The team tracks agent Cycle Time — the time from when the first PR (Pull Request) is created to when it's finally merged into the codebase.

They want this number to keep dropping. Because the faster agents deliver code, the more agents can participate in the work, delivering more code — creating a compounding effect.

Today, OpenClaw Foundation's total testing costs have started to decline.

Previously, every 100 CI runs cost roughly $1,000. Now, that figure has dropped to around $200.

Kimi

Feihu Tang, Kimi research engineer and head of developer relations, opened with a "Grandma GTA" example.

The gameplay demo video racked up over 70 million views in just two days.

It started as roughly an 8-minute video. A week later, a Kimi community developer turned it into an actually playable game and open-sourced it on GitHub. Other developers could continue adding gameplay on top of it.

With Video-to-Game Skill, creators can reference visuals and mechanics from videos to generate genuinely playable games.

Another game was showcased live: The Little Prince: Journey of Stars. Kimi design ambassador Sac spent 16 days on the initial version, turning the interstellar travel from The Little Prince into a freely explorable 3D game, accumulating nearly 3 million views across platforms.

A Kimi team colleague with no game development background, not even an engineer, built a near-AAA game using Kimi K3.1 Pro. Tang also showed off his own island-catching game, where players sail along a world map and explore different cities.

AI can already help developers port games from Switch to iPhone. Taking Diablo II as an example, the game not only runs on mobile, but the Kimi team also redesigned the gameplay for touchscreens.

Large models are lowering the time and cost to validate ideas.

Now, you too can build your own game.

HeyGen

"Agentic video is HTML."

Bin, HeyGen's VP of engineering, demonstrated a video he made with a prompt. It featured himself on camera, product highlights, and smooth dynamic effects. He'd never used Premiere or After Effects, yet completed the video like an engineer writing code — the result rivaling professionally produced product launch videos.

HeyGen believes video is one of the best communication tools. Most people would rather watch a one-minute video than read a five-page document.

Inside HeyGen, the team has already replaced large amounts of documentation with video.

But historically, HeyGen's video editor was built on complex data structures, with thousands or even tens of thousands of lines of data at the bottom layer. The most intuitive approach to building agents was to have them write directly in this existing data format.

The problem: while agents are good at generating data, they struggle to understand the final visual effect from data alone. Two sets of perfectly valid data could render completely differently — one normally laid out, the other with invisible text. If agents can only see the data itself, they can't recognize what's gone wrong.

So the HeyGen team started wondering: what if we had agents write what they're best at — code?

They completely abandoned their original data format and had agents write HTML directly. In April this year, HeyGen open-sourced HyperFrame, allowing agents to use HTML, CSS, and JavaScript, with a framework rendering the code into video.

Imagine a constantly changing webpage — text flying in and out, flipping, all kinds of animation effects. Agents just need to write frontend code to generate such videos.

A core insight at HeyGen: agents are exceptionally good at writing code, and this capability will only keep improving. More and more AI products are starting to generate content from code — documents, designs, slides — all undergoing similar shifts.

As of end-October, HyperFrame generates over 500,000 videos per day, reaching 15 million per month.

DYNA

Assume a model updates once per week, iterating for 24 consecutive weeks — that means the model team has at least 24 opportunities to adjust and try new ideas. But in the same timeframe, hardware might only go through one or two major iterations.

In traditional product development, even when hardware and software teams iterate at different speeds, both sides can usually lock down product requirements before the project starts. But for general-purpose robots, this is much harder. Because robots face such diverse application scenarios, it's difficult to define a set of product requirements that remain stable long-term.

To solve this, the DYNA team wanted to establish hardware design standards clear enough to remain applicable through years of model iterations.

Their answer: Predictable Hardware.

Hardware needs sufficient durability and cost advantages, but also needs to be a stable physical platform that rapidly evolving models can keep reusing.

Specifically, hardware design can be divided into two aspects:

First, Motion. The physical movement and response of hardware must be predictable to the model. In other words, when the model issues a command, the robot should execute actions in a predictable manner.

Second, Sensing. Hardware needs to provide reliable perceptual feedback, accurately reflecting physical states in the real world, so the model can trust this information and make decisions based on it.

Ultimately, the team hopes to narrow the Sim-to-Real gap through hardware design.

Making hardware's motion performance predictable and accurately modelable, while providing physical feedback that models can trust. Only then can hardware become a sufficiently stable physical platform that supports rapidly evolving models long-term.

Weilai Buyuan

Weilai Buyuan CTO Hao Zheng brought the newly released Self-Evolving WAM (World Action Model). Currently, WAM uses roughly 10,000 hours of first-person data and about 30,000 hours of real-robot data from first- and second-generation robots.

This year, Weilai Buyuan's first appearance with F2 at WAIC and WRC won favor from numerous household users.

WAM addresses two problems: first, when encountering a new task, how should the robot judge and act? Second, after executing an action, what changes occur to the manipulated object and surrounding environment?

First, it needs to receive visual observations, robot body state, and task goals.

Body state includes positions and constraints of each joint. Weilai Buyuan's latest-generation robot F2 has over 1,500 components, 21 degrees of freedom, and 22 sensors.

Zheng hopes that when receiving a task, the model can simultaneously simulate multiple completion methods. For instance, to pick up an object, humans typically think of several approaches, then compare which is more effortless or faster. The model can similarly generate multiple candidate action trajectories, evaluate them, and select one to execute.

Unexecuted candidate trajectories are also saved as training material for subsequent rounds. Successful task completion experiences, effective corrections during execution — all can be used for the next training round; failure data helps the model identify approaches to avoid.

Weilai Buyuan selected four tasks to observe model iteration effects: folding clothes, hanging clothes, making pasta, and stir-fried pork with peppers. First-round average task success rate was 45.4%; after 30 iterations, average success rate improved to 86.6% — a 41.2 percentage point gain.

Weilai Buyuan has already deployed robots in over 500 households for actual use, with cumulative working hours exceeding 50,000 hours.