← All AI Engineer talks

AI Engineer Europe 2026

Dark Factory: OpenClaw Ships Faster Than You Can Read the Diff

Read the talk

Dark Factory: Engineering OpenClaw’s Agent Workflow

When agents generate changes faster than maintainers can read them, the engineering work shifts toward task allocation, regression signals, reusable skills, and human judgment.

From a talk by Vincent Koc

Before you start: Familiarity with Git, pull requests, automated tests, and coding agents will help you follow the workflow.

Waking up to another advancement

Wake up, discover a new technological advancement, repeat. The opening meme captures the problem facing OpenClaw’s maintainers: changes arrive so quickly that keeping up becomes work in itself. Vincent Koc, an OpenClaw core maintainer working alongside Peter and balancing the project with a day job, poses a practical question: what makes that shipping velocity possible? His answer begins with engineering the process, rather than attributing the pace to luck or agents looping indefinitely.

A cat with a lobster body sits between circular arrows linking “I wake up” and “there is a new technological advancement.”
The recurring cycle of waking up to a new technological advancement.
0:160:28
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

0:16 · section reference included

The cost of working at the frontier

Koc’s earlier encounter with frontier technology was an early VR headset in 2013. Its box warned him to use it for five minutes at a time. He instead played Team Fortress 2 for three hours, then spent three hours vomiting. The experience supplies a less glamorous counterpart to the excitement of rapid advancement: unfamiliar tools bring unfamiliar failure modes.

OpenClaw’s pace has its own rough edges. Koc describes a volume of activity that brings him up against GitHub rate limits on an hourly basis. Working at the edge means dealing with those constraints while the tools and operating practices are still taking shape.

1:051:25
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

1:05 · section reference included

From writing code to managing production

The industrial analogy starts with a change in production scale. Britain moved from hand production toward mills; software teams now face a corresponding question about how to organize work when much more can be produced. Practices designed around an individual writing code do not automatically fit agents working across repositories.

That transition creates a tension in Koc’s own work. His day job involves evaluations, structured telemetry, and carefully measured behavior. On OpenClaw, he describes placing considerable trust in the harness—the surrounding machinery that runs and checks agent work. Those two worlds are beginning to converge. Where the weaver’s hands once constrained production, engineers increasingly manage the production process, and Koc identifies taste as the emerging bottleneck: judgment about what should be built.

Four lines read “Engineers Writing Code in Editors,” “Agent Swarms on Repos,” “Engineers are Factory Managers,” and “Bottleneck: Engineers Taste.”
From engineers writing code to managing agent swarms, with taste as the bottleneck.
2:182:36
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

2:18 · section reference included

What the throughput figures mean

Koc compares autonomous-agent adoption with early ChatGPT use: public acknowledgment can lag private experimentation. He points to Anthropic’s C compiler project as a visible example. That work was a bounded Opus 4.6 experiment with human-designed tests and coordination infrastructure, with remaining GCC dependencies and correctness limitations. It illustrates substantial agent work, not a general guarantee of autonomous development.

Two further examples need their original scope preserved. Koc repeats, with qualification, a claim that Spotify developers were no longer writing code by hand; it should not be read as an established company-wide practice. He also invokes Steve Yegge’s Vibe Maintainer. Although Koc describes its PR volume as solo output, Yegge’s account concerns incoming contributor submissions across Beads and Gas Town. That distinction matters: maintaining a growing stream of contributions is different from personally authoring it.

Koc reports that OpenClaw peaked at 800 commits per day with roughly 10–15 core maintainers, all with day jobs. Separately, he reports close to 3,000 personal commits on March 15. These are differently scoped activity counts, not a common productivity benchmark or evidence of software quality. His own activity also stops when he sleeps; the example is not unattended, round-the-clock production.

The operational question survives those qualifications: if this volume becomes routine, how much of the traditional process of reading and reviewing every PR remains workable? More output creates a need for engineering around selection, supervision, and checking.

3:393:55
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

3:39 · section reference included

Beyond maximizing commits and tokens

One possible response is simply to maximize commits. Koc connects that impulse to Ralph looping: hand an agent a task, let it burn tokens for eight or nine hours, and hope something useful emerges. The waiting is part of the problem. A long run consumes resources without assuring a useful result.

He jokingly proposes Bart looping as a more opinionated alternative, then asks the substantive question: what should the reward mechanism be? No new algorithm is specified here. The requirement is to give loops a better objective than continued execution. Token consumption and commit production are insufficient goals on their own.

5:285:40
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

5:28 · section reference included

Concurrent agents on a moving codebase

The concrete operating environment comes into view during a visit to NVIDIA to work on NemoClaw. Koc and Peter asked for external screens and settled into running multiple Codex sessions. Peter also connected over VPN to a Mac Studio at home. Koc estimates about 15 sessions for Peter and another 10–15 for himself, with perhaps 60–70 agents including subagents and roughly 15 foreground swim lanes. The estimates describe different layers of concurrent work, rather than one exact agent count.

While they worked on NemoClaw, another maintainer moved channel integrations, including Microsoft Teams and Slack, to a different location in the codebase. Work already in flight now had to accommodate that structural change. The challenge was no longer merely distributing tasks across agents: other maintainers could change the ground beneath those tasks.

6:126:23
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

6:12 · section reference included

The Great Refactor

The relocation became a catalyst for a larger architectural decision. Contributors wanted features, but accepting every feature would turn inexpensive code generation into expensive codebase bloat. The scarce decision was whom to refuse. Koc’s proposed response was to reduce the core and separate responsibilities through a plugin architecture. Provider code, for example, could become a distinct piece that OpenAI, Mistral, or Anthropic might own. That was an ownership possibility, not a claim that those vendors had already assumed it.

The team decided to undertake the wider refactor late at night. Koc reports roughly 2,700 commits, nearly one million lines changed, and 82% of the core codebase touched before plugins launched. The scale of the change also produced a moment of doubt: near the end, he was trying to go to sleep while tests still failed.

Slide titled “The Great Refactor,” subtitled “9 Days,” with the centered statement “Plugins Were Launched!”
The Great Refactor: plugins launched after nine days.

Recovery came through the team’s work and an unexpected asset: AI-generated unit tests that were tightly coupled to the existing implementation. Koc normally regarded that overfitting as a weakness. During a reconstruction of the codebase, however, those tests provided a concrete regression signal. Getting them green suggested that the rebuilt system was at least approaching the old behavior. Passing those tests supplied limited confidence, not proof of complete correctness.

7:337:43
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

7:33 · section reference included

Assigning attention across swim lanes

Koc’s factory consists of multiple Codex sessions organized into swim lanes. The number expands or contracts with the work. More consequential than the count is the division of responsibility: CI, features, and bugs can proceed separately, with different levels of human attention.

LanesWorkSupervision
1–2Refactor tests in a stable codebasePass tests, commit, and push
3–4Docker or messaging-channel featuresInvestigate and discuss findings
5New P0/P1 issuesMonitor and surface urgent work

The low-supervision lanes receive time to finish bounded work. Feature lanes involve a conversation: agents investigate, report back, and continue with Koc’s input. The urgent-issue lane watches sources such as GitHub. Agents in Discord also support releases by reporting developments from the preceding two hours. This partitions both the work and the maintainer’s attention.

At that scale, Koc finds raw compute and his own capacity to track sessions more constraining than tokens—while acknowledging that token constraints depend on whom you ask. Adding another lane therefore has a cost even when model usage is affordable: someone must still notice whether its work needs intervention.

9:229:34
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

9:22 · section reference included

When workspace isolation becomes overhead

Trusting the harness does not require an elaborate workflow, but isolation can become expensive. Koc created a Git worktree for each PR he touched, then ran into the resource demands of a heavy test harness spread across many workspaces. He reports roughly 70–80 active Git worktrees on his machine in a day. The accumulated test workload overwhelmed the machine.

He added custom Codex tooling for worktree awareness and recovery, mentioning sparse Git handling without detailing its implementation. In retrospect, he would have preferred the simpler arrangement used by Peter and others: several independent repository clones, each assigned to a session. This is a lesson from his workload, not a universal rule against worktrees. His ordinary task workflow remains conversational; he does not use plan or spec mode.

11:0411:16
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

11:04 · section reference included

Recognizing a session that needs intervention

Koc reaches for The Matrix to describe watching streams of agent activity: after enough exposure, patterns become recognizable. His warning signal is often the way an agent explains its work. It rambles, becomes incoherent, or seems unable to account for what it is doing. This is an assessment of visible explanations, not access to a model’s internal reasoning or a substitute for checking the result.

The response resembles managing a colleague whose account no longer makes sense: ask what is going on, and reconsider the assignment. Koc may terminate the session, leave that code area to another maintainer, or return to it several days later. Continuing the run is not automatically the best use of resources. He attributes this judgment to extensive agent use over the preceding year.

12:0612:17
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

12:06 · section reference included

Maintaining the agent development environment

The repeatable part of this practice lives in what Koc calls an agent development environment. He manages .skills much as he manages dotfiles: a maintained collection of reusable working instructions. Some skills are public, others private. His technical-documentation skills, for example, were developed with other engineers rather than treated as disposable prompts.

Skill improvement can use a skills gym or GEPA, to which Koc says he contributes. His more direct alternative is a feedback loop grounded in actual work:

  1. Ask Codex to inspect session logs from the preceding two weeks of using a skill.
  2. Use those sessions to identify and make improvements to the skill.
  3. Deploy the revised skill into OpenClaw or the personal development environment.

He mentions skills.sh as part of moving skills through that loop, and adds that he has testing around the maintenance process. Distribution and testing play different roles: making a revised skill available does not by itself establish that it improved.

Under “The ADE Loop,” bidirectional arrows connect “Agent Development Environment (ADE),” a central “.skills registry,” and “Skills Gym.”
The ADE loop connects an agent development environment, a .skills registry, and a skills gym.
13:2113:33
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

13:21 · section reference included

Selecting work and checking integrated behavior

The same engineering attention applies to incoming work. Koc jokes that each new maintainer tries to solve the overwhelming PR backlog by clustering it. During the talk, an initial figure of 6,000 is corrected in the room to 60,000; the exchange does not establish whether that means open PRs or a broader cumulative count. The operational problem is clearer than the denominator: many contributors submit their own versions of the same issue or fix.

Koc’s approach uses vector embeddings and a semantic graph over GitHub material to inspect related submissions. Connections around a PR expose duplication that would otherwise arrive as separate items demanding attention. Deduplication also helps identify demand: repeated submissions around the same problem can indicate that it deserves a maintainer’s time. This is a way to decide what to consume and address, even without calling it a roadmap.

After the refactor, the team also built a fake Slack-like environment using both synthetic and real models. Evaluation loops check whether providers and channels work together. This adds an integrated behavioral check alongside the unit-test signal used during reconstruction; Koc supplies no evaluation scores or pass thresholds.

14:2814:34
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

14:28 · section reference included

Managing the factory without wasting tokens

Asked recently how he manages more than ten agents, Koc replied by asking how the questioner would manage more than ten staff. His experience leading large AI teams made parts of the transition familiar. The relevant soft skills include asking for status, noticing when an explanation is unreliable, and coordinating work across people—or sessions—with different assignments.

The process becomes the central engineering concern. Model and agent choice still sit inside a workflow that must direct work, question its progress, and decide where attention belongs. Koc closes by contrasting 2025’s token maximization with a 2026 priority of not wasting tokens: token efficiency, with the agent in the loop. The factory manager’s job is to make the work worth running.

15:3715:45
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

15:37 · section reference included

Resources

From the talk

Updates since the talk

Read the complete timestamped transcript
  1. 0:00

    [upbeat music] They've got it?

  2. 0:16

    Cool. Amazing. So welcome, everyone. I'm Vincent. Uh, what do I do? I'm one of the core maintainers at OpenClaw, working with Peter. And as you've heard before, I have a day job as well.

  3. 0:28

    Same as Peter, he has a day job at OpenAI. Um, but you know, it's an open source project. Amazing things have been happening. I'm gonna talk about what I call dark factories, and how OpenClaw ships faster than you can read a diff.

  4. 0:40

    Um, this meme is absolutely hilarious. So I think Peter posted this, uh, a week or two ago. "I wake up." "There's a new technological advancement." "I wake up." It's this, this joke that we're shipping at insane speed, and the velocity is just absolutely phenomenal.

  5. 0:54

    And some of you might think, oh, this is some luck or we're just, like, Ralph looping to the max. Um, I think there's actual engineering work here, and I'm gonna talk about that.

  6. 1:05

    Now, as I mentioned, I'm Vincent. I'm your friendly clanker. Uh, this is me using VR goggles back in 2013. So despite my accent that sounds somewhat [REDACTED:origin], I was born and raised in [REDACTED:location], not far from here.

  7. 1:17

    I actually went to, to college just down the road in Westminster, and yeah, at some point decided to live in Australia, and my accent changed. But I used to love technology.

  8. 1:25

    I used to love being at the edge of technology, and this was like one of the first few sort of early, um, VR goggles that came out. It came in this big box with a big warning sign on it saying, "Hey, use for five minutes at a time," 'cause it didn't have like the anti-motion sickness built into

  9. 1:39

    it. And the funny thing with this one here was that I didn't use it for five minutes, I used it for three hours. And I played Team Fortress 2, had an absolute blast, and then I vomited for three hours after that 'cause my vision turned into bvisions.

  10. 1:53

    Um, the... What I'm trying to say here is that like anything on the edge is gonna be janky, it's gonna be f- horbi- ho- horrific, it's gonna be, uh, uncharted territory.

  11. 2:04

    And working on OpenClaw and being part of the team that ships probably, you know, an insane velocity of commits to a point where I get rate limited by GitHub on an hourly basis, uh, is an interesting experience.

  12. 2:18

    And this experience Britain's gone through before. Um, we had the Industrial Revolution when mills and cotton were being produced at extreme amounts of volume, and there's a lot of history here around production and productionization at scale, uh, in the UK and in Europe.

  13. 2:36

    And I feel like we're going through this moment again. Uh, we're going through this moment of how do we build at scale? And the ways we used to work before just don't work anymore.

  14. 2:46

    And it's kind of strange because in my day job, I kind of work in the space of evals, which everything is sort of structured, and there's telemetry, and it has to be all perfect.

  15. 2:58

    And I work on a project where I'm-- I have this blind faith in the harness, and it's this kind of two worlds, but they're starting to come together.

  16. 3:08

    We used to have handlooms in cottages, uh, centralized mills everywhere. Uh, craftsmen were the factory workers, but the bottleneck was the weaver's hands. We're now switching to a world where engineers writing code in editors, not so much, uh, swarms across repos.

  17. 3:28

    Uh, engineers are becoming factory managers, which I'm gonna talk to, and the bottleneck becomes taste. You know, that lovely word. Uh, [laughs] [REDACTED:origin] mother's hands. Yes.

  18. 3:39

    So in, in context, like what does this mean? Like, are you talking absolute nonsense of people building things at absolute scale? They are. What happened was, um, very similar to the ChatGPT era, where everyone denied it at scale that they were using ChatGPT.

  19. 3:55

    Everyone was in this absolute fear-mongering sort of world. But what the reality was that everyone was using it. Everyone in secret was just like, "Oh my God, what's going on?

  20. 4:03

    I need to talk to it." And the same thing is happening with these autonomous agents at scale. Some organizations have openly come out with it, so for example, Anthropic, uh, with their recent work they did on building a new C compiler.

  21. 4:16

    Uh, we had Spotify saying they're, they're no longer writing code by hand, supposedly. Um, Steve Yegge, which I absolutely love, uh, saying he pushes about fifty PRs a day total solo.

  22. 4:28

    He calls himself a vibe maintainer. I can kind of relate to that. And OpenClaw, where we're pushing... At the peak, we were doing eight hundred commits a day. And realistically, like there's about ten to fifteen core maintainers all with day jobs.

  23. 4:43

    It's kinda astronomical in terms of scale. And for me, this was March 15. Um, what was that? Like two, three weeks ago? Where I hit close to three thousand commits per day.

  24. 4:56

    And if you actually chook-- look, my commits actually stop when I go to sleep. So if you, if you wanna see when I go to sleep and when I wake up and how many hours of sleep I have, you can just take a look at my commit history.

  25. 5:07

    Yeah, it's astronomical. But the thing is, this is gonna become the norm everywhere else. Like this is, this is like a me telling you you need to wake up that, you know, that this scale of velocity is gonna be normal.

  26. 5:17

    And trying to review PRs and go through all this nonsense may not work. But somewhere in the mix is engineering. There is a form of engineering that's gonna happen.

  27. 5:28

    So we did commit maxing. You know? Let's just go out there, smash as many commits as we can. And this reminds me of Ralph looping, right? This like, this, this, this, this guy where you're like, "Hey, I'm just gonna like give you a task.

  28. 5:40

    I'm gonna burn tokens for like eight to nine hours." And you're waiting, you know? Uh, you're waiting, you're hoping something happens. Maybe something happens. I don't know. Um, but what if we had a bit more of an opinionated ap- uh, approach to this?

  29. 5:53

    Um, what if we call it Bart looping? I don't know. Uh, one of the other maintainers gave me this idea. Maybe we'll coin it. Do we- Do we need more than just tokens?

  30. 6:02

    Uh, what does that reward mechanism look like? How do we get a bit more opinionated? Yes, let's run loops, but let's be a bit more smart about how we do this.

  31. 6:12

    So, um, right about the time you saw those three thousand commits, uh, this was the day before. I was at NVIDIA with Peter, and the gentleman you see on the left is, is one of the other, uh, NVIDIA gentlemen.

  32. 6:23

    And they were like, "Hey, we're building NeMo claw." I'm like, "What? What's going on?" And, uh, let's help you build it. And I was in the room. I was like, "I can't work on a laptop for like hours on end.

  33. 6:33

    Can you bring me a screen?" They brought me a screen. Um, Peter didn't have a screen, so that's his laptop on the left. He asked for a screen, so they gave him an even bigger screen than mine 'cause, you know, why not?

  34. 6:45

    And [chuckles] we just got to work. So he's running about maybe fifteen codec sessions, and he's got his Mac Studio at home he's VPN'd into. I'm running another like ten or fifteen.

  35. 6:54

    And between, collectively between us, we're probably running with subagents included, maybe up to sixty, seventy agents. Um, but on the foreground maybe fifteen s- uh, swim lanes, if you wanna call it that.

  36. 7:03

    And we're just, just going for it. Funny thing is, we're working on NeMo claw one side, but one maintainer decided, "I'm gonna move some stuff around. I'm gonna move a couple of folders around."

  37. 7:13

    And that was moving entire channels. So like all our conversations with like MS Teams and Slack ended up moving to another location in the code base.

  38. 7:22

    And we were like, "Oh my goodness, we're gonna have to change stuff." Um, and I found a really nice, uh, place to put my drink as well. [laughs] The NVIDIA people didn't like this.

  39. 7:33

    So what ended up happening is what we call the Great Refactor, um, essentially where we were like, "Hey, we have lots of people raising PRs, and what they actually want is to build features."

  40. 7:43

    The thing is, we don't wanna give everyone every single feature that they want, in which case it becomes bloat. Uh, you heard Peter say earlier on the challenge becomes who do I say no to?

  41. 7:53

    It's not about saying yes. In a world where tokens are cheap, I can just say yes to absolutely everyone and merge everything in, but that's gonna turn this code base into an absolute fire dump.

  42. 8:02

    So the vision was actually we need to cut this code base down. We need to, we need to rip it into pieces. And a plugin architecture somewhat made sense.

  43. 8:12

    Imagine if you're OpenAI or Mistral or Anthropic, what if you owned that piece of the provider code and it was handed to you and it was separate from everything else?

  44. 8:22

    So this code change that occurred was like a catalyst for us. It was two in the morning, we're tired. We thought, "Why not refactor the entire code base? Sounds like a splendid idea."

  45. 8:33

    So two thousand seven hundred commits later, uh, close to a million lines of code change, uh, touching eighty-two percent of the core code base, plugins were launched. Um, the night before, I think it was like one in the morning, I'm trying to go to sleep, and the tests are not passing.

  46. 8:51

    And I was like, was I Icarus and did I fly too close to the sun? Um, as we like to call it, did I, did I vibe too hard?

  47. 8:57

    I, I actually generally thought I vibed too hard. But as a team we managed, we managed to bring this code base back together again. But the saving grace was these awful sort of unit tests that AI code loves to generate that actually ended up overfitting on our code.

  48. 9:13

    So when we completely ripped everything out, we still had these tests that were like extremely overfitting, and as long as they would go green, we knew we were kind of somewhat close.

  49. 9:22

    Um, so how do we do this, you know? Um, in my case, I call it my factory. It's many codec sessions. Everyone asks me like, "What's this magic sauce?

  50. 9:34

    Like how, how do you do this? Like what's this crazy, insane thing? Like how are you guys building this?" Very simple. I have swim lanes. Um, it could be five, it could be ten, it could be twenty.

  51. 9:44

    But traditionally, they kind of cut themselves up into different pieces. So like if I... Does this work, the laser? You can't really see it. But imagine you're a factory manager and you have a production line below.

  52. 9:56

    Essentially, you might have a case where you have, uh, let's just say CI to one side, you might have features in one side, you might have bugs in another.

  53. 10:05

    So when I'm refactoring and doing stuff, um, right now the code base is quite stable. I wanna refactor some tests. Well, that might be swim lanes one and two.

  54. 10:13

    I don't need to really babysit them too much. I just tell them, "Take your time, make sure the tests pass. Just commit. Just, just push them through." Whereas with three and four, I might be looking at specific features and issues around, say, Docker or, um, one of our messaging channel- channels.

  55. 10:28

    In which case I'm having a conversation with those agents. They're going off investigating, doing the work, coming back. And then maybe five is actually, um, looking at new P0s and P1s.

  56. 10:38

    Um, that might be using other data. It might be using GitHub. Uh, we have agents that run inside of a Discord channel, so when we do a release, we might be like, "Hey, what's happened in the last two hours that I need to be paying attention to?"

  57. 10:49

    And this will scale up and down. But what ends up becoming quite interesting is tokens are no longer the problem. Um, depends who you ask. What really ends up becoming the problem is just raw compute and my brain space in order to sort of keep an eye on all of these sessions.

  58. 11:04

    So in harness we trust. What ends up happening is I don't have this really insanely complicated process. The one thing I have complicated in my life is adopting Git worktrees, and I kinda wish I hadn't.

  59. 11:16

    The only reason why I say this is when you're running an extremely heavy test harness, it ended up completely nuking my machine 'cause I ended up running like every PR I touch ends up becoming a new Git worktree.

  60. 11:29

    I end up with like some- close to like seventy or eighty active Git worktrees in any given day on my machine, and that's kinda hell. Um, so I had to actually build some like magic sauce around my, my codec session, so my codecs is aware of Git worktrees.

  61. 11:42

    If I hit the escape key, it crashes. It will self-heal, self-recover, Git, you know, sparse stuff. But realistically, I should have adopted what Peter and other people do and just like clone the repo ten times and point ten different, you know, codec sessions to each one.

  62. 11:56

    But the trick here is that like I haven't done any magical sauce. I don't use plan mode or spec mode. I have a conversation with the agent, and we work through it, and we find a way to make it work.

  63. 12:06

    So realistically, it looks a little bit like this from The Matrix. Um, and people go, "Oh, Vincent, like, how do you know it's kinda working?" And this is gonna sound somewhat a little bit lunatic.

  64. 12:17

    It, it-- If, if anyone's watched The Matrix and seen the scene where Neo goes over, he's like, "How do you know? How do you read the text?" And the guy's like, "Oh, you know, I've been doing this for a while, so I can see, like, woman in red dress or guy walking dog."

  65. 12:29

    And you start to have this, like, relationship where you can feel the reasoning tokens. I know it sounds somewhat ludicrous, but there's times where I'm looking at the swim lane, I'm like, "This sounds off."

  66. 12:40

    It doesn't sound off because of what it's doing, it sounds off because of how it's explaining itself to me. It's waffling. It's not making n- sense. It doesn't seem to know what it's doing.

  67. 12:51

    And this feels a lot like how I would manage people. Um, if I had someone working for me and they started downright bullshitting, I'd be like: Wait a minute.

  68. 12:59

    What's going on? So in these cases, I might just nuke the session and go, "You know what? I'm not gonna deal with this section of code. I'm gonna leave that to another maintainer," or I might come back to it four or five days later.

  69. 13:08

    But that experience feels very much like intuitive. And building that intuition, I've been able to get to because of the sheer volume of token maxing I've had to go through in the previous year.

  70. 13:21

    So there is engineering work. Uh, I call this the agent development environment. Um, essentially, the process goes, I have skills. I call it .skills, similar to dot, um,

  71. 13:33

    .files. Both of my .skills and .files is available on GitHub. It's all open source. Go for it. Some of my skills are private, but there's skills in there for, like, writing technical documentation, for example, um, that I've co-created with other, um, developer experience and other engineers in the market.

  72. 13:49

    Um, you can use a skills gym, something like a, a Gepa, which I'm also a contributor to, and... Or you could just say, "Go Codex." I've been using this skill in my last, uh, two weeks.

  73. 14:00

    Go through the Codex sessions, read the logs, make improvements to the skill. Um, I would then take that skill and deploy that into my OpenClaw or take that into my, you know, personal environment, and I'll use something like Vercel skills.sh as like a mechanism to loop this.

  74. 14:16

    I've added some other testing and other elements on top of this, but there's a process to how I manage and maintain my skills as an engineer. The way we manage PRs has some level of engineering work to it.

  75. 14:28

    Um, there's this kind of running joke that every maintainer that joins the project decides to try and tackle, like, "Oh my God, we have six thousand PRs. How are we gonna solve it?

  76. 14:34

    I'm gonna cluster everything and, like, figure this out." So the- Sixty K. How many? Sixty K. There you go. There you go. Honor. Thank you very much. So this was my flavor of, like, trying to solve this.

  77. 14:44

    This is, like, a semantic graphing, uh, vector embedding on the entire GitHub stuff. This is one PR. Has seventy-three edge, uh, one hundred and six edges. What ends up happening is that everyone else has the same problem, so they decide to, to send their flavor of the PR issue.

  78. 14:58

    Becomes u- utter noise. So there is even process around, like, how we even consume what we're gonna work on. We might not call it a roadmap, but we have a way of kinda de-duplicating and seeing what's out there.

  79. 15:10

    This might be a signal for me to say, "Okay, if there's enough pressure coming on one issue, it must be big enough that all these other clankers decided it's a big problem.

  80. 15:19

    Maybe I should go and address it." There is evals, surprisingly. Um, after all this refactoring work, we decided to make a fake Slack of sorts with both synthetic models and real models, so we can run evaluation loops to check that each of the providers and the channels work.

  81. 15:37

    And this question was asked of me recently: How do you manage ten plus agents? And this is something that you're thinking. I s- asked them back, "How do you manage ten plus staff?"

  82. 15:45

    And they had no answer for me. I'd worked in large organizations like airlines and other places like that, managing large AI teams. I had experience managing up to thirty, forty people plus.

  83. 15:55

    So for me, it was not like a, a, a new paradigm. But I think for engineers and people working with these coding agents at scale, it's the soft skills that matter.

  84. 16:05

    It's how do you ask your agent what's going on? How do you know when they're not bullshitting you, and how do you run that factory? So it's no longer about the model or the agent, it's about the process.

  85. 16:15

    Uh, twenty twenty-five was about token maxing, twenty twenty-six is about not wasting them. It's about token efficiency. It's about agent in the loop. Thank you. [audience applauding] [upbeat music]