d

afternoon. All right, let's see

if we get this working here.

Yeah. So don't expect a regular

presentation here. My talk is

about build the thing that

builds the thing. I want to

inspire you a little bit. How

to approach building software

in the future. You know, it's

been not even a year since we

have coding agents. And it's

kind of like half a year since

they got good. And there's no

stopping done. So a lot of the

ways we build software in the

past, I feel are obsolete. And

we we haven't really figured it

out yet. I'm curious here, is

anyone here who maintains open

source? Yes. How are you

handling the pain? So. I kind

of stumbled into into open claw

people. I saw this all these

articles where people say, oh,

Peter made 43 projects that

failed. And then finally, like

one worked. And I had to laugh

at this because none of these

projects failed. All of these

projects are things I built for

myself to work faster to like.

Mostly actually to like help my

agents to work faster. Like

anytime you build software now

your job is no longer to, to

figure out how you build

software faster. Really your

job should be, what can I do to

help my agent to build software

faster and even more? So it's

all about closing the loop. You

know? Last year I built, I

spent a few months building a

SaaS. And the agent would write

code and then it would like,

tell me it's done. And then I

would look at the browser, I

would at the agent. It would

like go in a loop, it would fix

it. And then eventually we

would be there. And that was

until I figured out like, hey,

no, the agent just can't make a

screenshot, you know, just like

humans would like anything that

where you feel. This is

something I do repeatedly, you

should start thinking, how can

I automate this? How can I, how

can I help my agent to close

the loop? So when I guide you a

little bit through all my

failed projects. And give you a

little bit of the, the, the

thought process, I put on this

website a little bit. It's pure

slop, but I think it's kind of

nice for that. All the little

tools that we built to build

Opencore, and I don't think

it's even complete. So my, my

first problem was. That open

cloud client exploded. And then

the issues and PRS started

increasing. And I didn't know

that this number actually, once

it reaches five K, it stays at

five K and kind of masks it. At

some point we had like more

than 10,000 issues because

people don't they don't look,

they just like, oh, I mean,

people, the agents don't look,

you know, it's like, let's not

pretend any of that is written

by humans anymore. And I know a

lot of open source people get

really mad at all the slop

they're getting, but I feel.

You can't fight the world. You

have to figure out a way how to

deal with that. So I see

differently. Yes, there's a lot

of slop, but the real problem

is that it's still called pull

requests. I call it prompt

request because what you really

want is anytime someone opens

an issue, a PR, it's just a

signal that somebody is not

happy with what you built and

is asking for a change.

Actually, like these two things

are like interchangeable. Like

mostly doesn't matter if it's

an issue or PR. Sometimes an

issue is actually nicer because

I can work fresh if it's a pull

request. And like somebody used

Claude and like I, it's

probably takes me more time to

like make my agent read the

code and then like at the code

and then rewrite the code. But

the first thing, the first

thing I had to had to solve was

how do I get this number down?

And I tried, obviously you try

tools, right? I tried code

Revit, I tried, I tried a bunch

of tools and they were nice,

but they ultimately would just

give me a review. I wanted more

I reviews are nice, but I kind

of want something that

automatically groups and closes

the issues and I couldn't find

anything good. And in this day

and age you don't actually need

to wait anymore to like find

stuff. You can just build your

own stuff. So I built Cloud

Sweeper again, totally sloppy

website because the website

doesn't matter. But it's

actually really simple to build.

Like, I don't know what all

these tools were their motives

because ultimately, anytime

someone opens an issue or a

pull request, I just start a

codex in the cloud. We are a

GitHub action and have a nice

prompt that explains the codex.

Like what is, what's the goal

of the project? What's our

vision? I do this now for any

of my open source projects. I

have a vision.md, and part of

my standard prompt is that my

agent reads that file. And in

that file is kind of like what

stuff that yes, we totally want

what stuff that definitely we

don't want. And based on those

rules. Klaus Reaper will run.

And we'll just either comment

on the issue or close the issue.

And through that, I was able to

like close around 15,000 issues.

I mean, yes, I also operate

under the assumption that have

infinite tokens. You could

definitely do this a little bit

more efficient, but we didn't

stop there. Once we had a

system that could close issues.

Of course, we also wanted to

review issues. And it's not a

static process right at our

scale. Any time a fixed lens on

main, there's a good chance

that I solved an issue that

I've never read because there's

like many thousand issues open.

So what we do is actually we

rerun Klaus Reaper on every

issue and pull request at least

once a week, depending on how

many tokens you want to spend.

You could do it every day. So

what regularly happens is, is

that I, I have an integration

on discord. And then and then

the report will tell me, hey,

close this issue from three

months ago that I've never seen

just because, because Codex

would run on that issue. And

then a person that wrote an

issue will get a, will get a

response. Hey, we fixed this on

main. And again, it's something

I don't have to deal with it. I

automated it, it solved the

problem. I also built a nice

dashboard. So see, right now

there's only 1818 Codex working

right now. And this is how it

looks. It's just one long

comment that explains what it

does. And it gives people array

of issues that that they need

to solve with typical stuff.

The next thing I, I had to

solve now, now the project

gained momentum. I added more

intainers and some people

turn out to be really good.

Some people, they kind of

showed up for a few days and

then disappeared. And I was

very liberal in the beginning

of adding people and I lost a

little bit overview. So I

wanted a dashboard. So I just

built a dashboard. So now we

have reports of open cloud.

This is not public for everyone

because it because you want a

little bit more data. Actually,

I'm not just looking at GitHub

issues. I also look at all our

discord stuff. So to me, being

a maintainer doesn't just mean

you push code. Domain also

means that you participate in

discussions, which we use

discord for that. So so this

system integrates all data from

discord. Now that brought me to

the next problem. How do I get

the data from discord? Well,

let's just build this crawl.

Like in this day and age, any

problem is just a prompt away.

Like building this thing is

never the hard thing.

Maintaining this thing is

actually the hard thing. But

again, even even on even now

when I, when I maintain stuff,

I don't think about the project

level anymore. I. It looks like

this. I basically, I go one

level beyond. I go into my

projects folder and ask Codex,

hey, let's triage. What are the

things that I should work on?

And it just finds a list of all

the, all my projects and open

issues. And then I basically

say, yes, do all of them

because I already have. My

slope is better than your slope.

No, I don't do all of them

because there's still sometimes

people report weird stuff and I

don't fully trust my agents. So

I want to I want to read that.

Right? So again, I'm a lazy

person. I could click on each

of those URLs, but it's kind of

like slow. So I built something

where you just select a text

and I built myself an issue

browser because again, it was

like, like there was like just

a few clicks too much. It

annoyed me a little bit too

much. And the critical, the

critical thing that you are is

like, your time is limited. So

you need to build the tools to

build the tools. So again, I

built this little slot, right

issue browser where I can copy

by now any format because it

turns out there's Clankers

given an almost unlimited

amount of versions, how to

format things. So I anytime

something didn't work, I just

fixed it to make it work. And

now I basically parses all the

formats that it ever seen. And

I can very quickly click

through this list. In many

cases, the agents are already

so good because I have this

vision in D file that the

selection is mostly right. And

I usually say, do those eight

don't do those two because I

know this needs actual time.

You know, anytime you work with

agents, you want to optimize

what they can do autonomously.

And it doesn't matter how long

it takes. You want to, you want

to really manage the focus time

where you want to be in the

loop for the things that are

important and all the things.

What is that even gmail draft

create? Yeah, that's probably a

nice feature. Oh yeah. Let's

look at this. This is a nice

feature on Gorg. Another thing

that I built because I got

annoyed that Google doesn't

have a CLI, and I want my

agents to access all my Google.

Yes, like Codex has gmail

integration and now. Calendar

integration, but only for one

account against an annoyed me.

So I just built a CLI that can

do everything anytime

something's missing because I,

I control the whole stack. My

agent controls the whole stack.

So it can just fix itself like

so like you own the whole

universe. Anything is fixable.

And this is all these issues

are super nice because this

would eventually add a feature.

Codex can not only build it.

But also end to end verify it

because I of course have like a

demo account on GOG so it can

end to end test the whole

feature. And I basically have

to do nothing other than saying

yes, and I can ship it and I

can ship it with confidence

because it's end to end tested.

So then I built this role for

the maintainer reports. Turns

out this is like this solves a

much bigger problem because

when you do open source. And

you have multiple thousands of

issues, it's very hard to know

what's actually the thing that

I should work on. So now I, I

hooked up this crawl to Codex

and it will, it will go through

all my channels and I can

basically ask it, what are

people screaming the most

correlated to open issues and

PRS and find me the top five

things I should work on. It

should like match it with my

vision document, pick the stuff

that you can work autonomously,

and then basically it can run

off and work for doesn't matter

how many hours you can, you can

parallelize it. And then what

you always should know when you

build, even when you highly

automate with agents, is you

should have this. The you

should have the overview of

your system so you will know

which issues are like. Probably

fine, probably fine. Oh, this

is hairy. I need to look at

that more specifically. So I

built this crawl and then of

course all my maintenance

wanted this crawl. But again,

it there's no, there's no

public way to get all this data.

So I used a bot multi that was

in discord to like use him to

access all the data. But then

how do you distribute it to, to

the other maintainers. Well.

What's the, what's the simplest

backup system there is GitHub.

So, so all the, all the data

from our discord is not just in

some discord store, just in

some, some format that

serializes the database. And

anyone that uses discord can

just use this as an alternative

data server if they don't have

a bot token, because I didn't

want to give my bot token to

all the people, this is good

enough. Again. Problem solved.

Now, if you're like me and

you're maintaining a lot of

open source projects, what I

always wanted was a way to have

this little dashboard of like,

what actually needs my

attention? Where are the most

pull requests? Should I do

another release? But there

wasn't really anything good. So

I just built this bar and now I

can filter on this.

Specifically how many days

since the last release. So

whenever I do like my little

fixes and software, if you

don't constantly garden your

software, it's dead because

dependencies, everything needs

updating. Systems change. So

now I have a nice dashboard to

know when should I do another

release? And I can basically

filter on stuff that need

attention. And again, the

beauty of all these little, all

these little tools that you

build to help you build the

thing, they're not system

critical. So all these tools

are. Yes. I actually didn't

look at any of that code

because it doesn't matter, like

for, for stuff that a lot of

people run open claw, I read

more code than people would

think. But for all these little

helper tools. Vibe anyway, and

if maybe you use them a lot,

then you can iterate on them.

Maybe they don't work out and

no cost. Yeah, we talked about

a little browser here. There's

another thing now that I. I use

more and more to work on things

in parallel. I hit another

problem. There's only so many

GitHub tokens that you can use.

And because we have so many

issues, and I instructed my, my

agent to look at find related

issues, I always ran out of

tokens. And I know that I, I

don't know if the GitHub people

are here like they are good

friends and I have someone

literally clicking a button

once an hour to reset Peter's

rate limits. But the problem is

these people need sleep. It's

not clankers. So so when I was

working weird hours, like I

wasn't around, I couldn't ping

her to reset my tokens. Again.

I find being annoyed is the

very best way to solve problems.

So I built octopus and you're

like, my feelings were like

transported into this this

things feelings. But the

principle is the principle is

very, very easy. Octopus. Let's

see if this actually works. But

again, the principle is very

easy. You as a as an individual

have 5000 API tokens per hour.

But if you install a GitHub app,

it gives you 15,000 tokens per

hour. So I just built this

thing that shims GG and then

calls this thing on Cloudflare.

If it's a read only if it's if

it's a non mutating read only

action from a public repository,

it can use the GitHub app and

then use the token from the

GitHub app and not my token

only if it's something that's

mutating or it doesn't fit that

that match it will use my token.

Bam! Again. Problem solved. And.

All the tools are so good now,

especially especially

Cloudflare, I didn't have, I

just explained the agent what I

want. And then with the

combination of really smart

models, browser use, you don't

have to do anything anymore.

Like literally, you could

configure Cloudflare itself.

You probably still want to have

a look at it because you want

to review if it actually

doesn't mess up your security

settings. But the idea is any

time, any time you feel you

feel pain, think of go, go, go,

go out and think about what,

what can I do to like get rid

of that pain? And then usually

it will not only help you, it

will help your whole team. And

it's, it's a and it compounds

all the little tools are built.

Help me to build faster.

Another, another problem I had.

How are we on time? Actually, I,

I think we're good. Who here

had this problem? Who's crazy

enough to run like more than,

let's say ten coding sessions

except for two? Yeah. You guys

need to level up. So. The

project grew. It kind of

exploded. The code and the

features grew. People reported

bugs, our test case grew and

the tests were becoming more

and more pain. You know, that's

that's the stuff kind of creeps

in. It takes like, it took like

10s and it took 30s and took a

minute. Then it took two

minutes, then it took five

minutes. Then I optimized it

for my Mac studio to work in

one minute. And everybody

complained that that like,

their computers were melting

because they didn't have like

40 cores. So we had this shared

painting again. And around that

time, I saw that. Oops, I saw

that. What's it called?

Blacksmiths. They, they started

something. Test box concept. So

the idea is. Your computer

power is limited. So you want

to give the agent a little box

where it can run the tests or

do whatever it needs to be CPU

intensive. And what's beautiful

for a while. But the problem

was their stuff was very new

and it was like. It was down

for at least two hours a day.

And by then, our team was so

dependent on it that like,

nothing would get done anymore

in those two hours because CI

would break down and then the

test would break down. So I was

like, this is fine. I'll just

build something that wraps it

with alternatives. And that's

how Crab Box was born, because

you have to keep it with the

weird crustacean names. Again,

very simple, a very simple

concept. You spin up a little

infernal machine in the cloud,

and then it syncs your changes

in there. Your reports are

already checked out. It runs

the tests in there, and then

you pay the all the CPU stuff

that you would need to run the

test on your machine. You can

use really beefy hardware. You

can massively parallelize.

Everyone's happy. And then this,

this tool quickly became like

universally loved because it

would it would use our main

provider. And if that runs down,

it would just use AWS or Azure.

And then people started making

pull requests. And now it

supports like 20 providers. But

it didn't stop there because I

recognized this is actually way

more useful because oftentimes

we have bugs where, oh yeah, on,

on windows there is a Eprom

issue, even though we use node

and it should be cross-platform,

there's like always little

weird details where

cross-platform is a lie. And

then in the past, I would just

sometimes just like wipe it

because I'm too lazy to spin up

my windows computer, I could

spin up a VM, but then how do I

get it into the VM? And then

kind of like have to do get

cortex into the VM because I

can't, I can do git anymore

without an agent because it's 3

a.m. and I'm tired. You know,

you have to fight friction like,

like ultimately we are being

lazy is good. So I noticed that

I'm, I'm pushing slop because

I'm too lazy to come up with a

good testing system. So I added

cross-platform support to grab

box. And now anytime there's

something that's hairy, I just

tell my agent, hey, test it on

all the races. And it will not

just create one box, it will

create three boxes. Or maybe,

maybe there's a weird issue

that's only on Red hat. Sorry,

Sally, I love Red hat and it

will spin up four boxes and you

can like, you can scale it

infinitum and like increase

your confidence that your code

actually works. And it can do

that in parallel, which is

really amazing. And then once I

built that got me thinking like.

I have this bug, but it's like

actually only on windows on

this browser. So I kind of need

UI for that. People already

solved that. Just add VNC into

it. So now I have a crap box

that like can recreate exact

scenario, and then my agent

opens a browser with VNC and in

there there's already a browser

waiting in a terminal and maybe

telegram or whatever I need so

I can recreate the issue end to

end and test it. That was

amazing. But still, like I had

to click myself. Oh, you know,

like laziness is good. So that

got us the idea. Wouldn't it be

cool if the Clanker could do it?

Of course they can do it. They

have computer vision models

could really good. So so now

Crap box also has a little

little tools for screenshot and

click and type. And now I can

actually, my agent can have its

own little box with UI that it

can use computer automation in

to control the UI. I was still

not good enough. Like I don't

want to watch the clanker. I

just want to see video. So what

we built next was mantis, where

now we have an agent that I can

ping on a, on a pull request

that'll spin up boxes, make a

video of the bug, fix it, make

a video of the fix and actually

look at the video and verify it.

And then all I get, I can

basically see an issue. I can

ping Klaus to fix it, and it'll

create the PR mantis will do

the visual verification, and

all I have to do is like, look

at the video and press merge.

And that's all built based on

me being annoyed. The next

thing I noticed. Like you would,

you would use Codex, you would

like do the prompt and then you

would do slash review because

you're like, you're kind of

unsure. Maybe maybe I should

review it. And then Codex would

find three issues and they're

like, damn, they're like, all

of them sound real. SI fix it

and run off for ten, 20 minutes,

run all the tests again, and

you're like, oh, is it really

all fixed? Let's just let's

review again and will run for

ten minutes. It would find two

new issues because it can't

show me all the issues at once.

It's just like, I can't do it.

You type fix again, you wait 20

minutes, you do something else,

go back and like, yeah, but is

it really fixed this? Let's

review again. It would run for

20 minutes, 30 minutes. It

would find another issue. And I

don't know, have you done this?

Like I did this. And then there

was one time I did this ten

times. It was the whole day.

Like I added support for line.

I don't even use line, but like

somebody was very passionate

about it. I wanted to get it in.

And then all day I did this

review and I was like, is it

enough? Is enough? Like, like,

I feel like I'm the clanker. So

I built auto review and in the

beginning I thought, oh, this

is kind of annoying. I probably

need hooks or like, maybe I for

Codex because Codex is open

source. I could totally do that.

But that turns out it's

actually way easier than that

because agents are really good

at following instructions for

last at least 4 or 5 months. So

now there is one line in my

agents.md that says, before you

commit or land a PR, if you

haven't done auto review it,

run auto review. And again, you

know, review. Some people say,

look at the code with fresh

eyes. Yeah, good luck with that.

You know, like context doesn't

really work that way. But. But

you can just call. I don't know

if you find the but you get the

idea. You can just call the

agent that you use as CLI with

the commands you should do. So

you get a fresh context, but

just calling like I Codex calls

Codex to like run auto review.

There was a bug sometimes.

Sometimes Codex was calling

Codex, calling codex and

calling colleagues. And it took

very long. I fixed that, but

now I have a very reliable

system that automatically runs

many rounds of review and. I

also tuned the file to explain

the agent. Not every review

thing is valid. You know,

sometimes. They would find very

weird edge cases. So it's a

little bit up to you to explain

the agent, the, the, the, the

conditions, what you think is

valid running, for example, in

our case, we don't expect that

you randomly edit plugin files

while the system is running.

The agent doesn't know that. So

like by default it would write

very defensive code to like

deal with all of those things.

So, so it's always a good idea

to write all these invariants

into your agent file. That's a

good idea in general because

you know that, but the clanker

doesn't. And every time you

start a new session, Clanker

memory is pretty much gone. So

you the more you tell it about

your project, the better the

time you'll have. I went all in

from very long agent files to

like very short ones, and now

mine are kind of long again,

but with meaningful stuff.

Every time you do that, it's

also don't don't write the text

yourself. You know, none of

this is written yourself. You

don't know how to write to the

client in a way that Clanker

writes to a clanker. So like

you're going to explain what

you want from the agent, and

the agent will write it in its

own words. And then every once

in a while, go into meta mode

and just ask the agent, hey, is

there anything that's confusing

in your agent file? And then

they will usually tell you,

yeah, well, this is confusing

because here it says this and

here it says this and then

cleaned it up. Clean up any

confusion because that's just

token burner. And we'll build a,

we'll give you a worse results.

But I think if, if you only

take about two ideas from this

talk, try auto review and try

grab box. It totally

revolutionized how we build

software like my, my trust in

in. Prompting and shipping is

much, much higher with that

stuff. There's another thing

when we get PRS. I would love

to know how people came to that

PR like. The good and the bad

thing with agents is like a one

line prompt can create ten

lines, ten, ten, ten pages of

content. And you don't always

know how much, how much work

was put in. So very early on in

our contributor guidelines, I

asked people to please send me

the prompts and nobody would do

it because there was just no

good system. You know, I was

fighting against people's

laziness. Of course they will

not do it. That one took me a

long time to figure out, but

now I built a skill. If you use

open claw and you contribute,

you send a pull request to open

claw. Your agent will ask you,

hey, do you want to send a a

privacy filtered version of the

prompt? If you do that, we will

look at your PR faster and then

the user can type yes. And then

the agent will upload, will,

will, will look on the disk,

will find its own transcript,

will cut the transcript to the

interesting parts, and then

we'll add those transcript to

the pull request. And suddenly

I have a much more interesting

data point about how much

effort was put in, because

that's ultimately what you're

after. Like I can, somebody can

say, fix issue number and send

PR and it's like four words,

five tokens. And or somebody

could actually spend a few

hours and like have an actual

discussion and you don't always

know. So this has been

extremely helpful in, in, in

figuring out what's total slop

and what's kind of good slop.

And again, like, I could have

done this half a year ago, just,

I just didn't come to mind that

actually it's that easy.

Oftentimes we're not limited

anymore by. By intelligence.

The models are good enough now.

Everything that we are limited

of is our own imagination. How

what you do with it and how to

build things. Now, I built auto

review and I was like, oh, this

is amazing. And it made me

really bad. I felt really bad

for all the code that I

committed without review. Now

that I, I saw how much stuff

the agent finds each time and I

saw GPT five is good, but and

yes, it is really good, but

still, there's so many boo boos

like the. Especially on large.

There's just mistakes and like

difficult things. The agent

will only find. After doing

multiple rounds of reviews. So

it got me worried like, oh, I

wish I had done this earlier,

but you can't really. There's

no slash review for a project

that has a million lines of

code. There's too much like

what should the agent focus on?

There's too much for, for. The

context. It annoyed me. You

know what, what, what happens

when I'm annoyed? So I built

cloud Patch. And the principle

is very simple. Like, oh, you

have a big project. Let's take

it apart into like 50 little

sub things, subsections by

feature or whatever, whatever

else you can, like, you can

separate it and then have the

agent review each of those

things separately. And then you

can, you can download this, run

this on, on your project. And I

guarantee you you'll find a lot

of interesting things. It's not,

it's not quite as perfect as

paired change because you would

have to probably scale it up to

thousands of code sessions,

even with unlimited token.

That's a problem. But it's

really good at like cleaning up

code bases. This is something

that's not fully finished yet.

But, you know, I got I was so

into crap box. The more I

worked with the team, the more

did you had this where you ask

your teammate and your teammate

will pass stuff from your from

the agent into chat. And then

you would you would comment on

it and then they would pass

stuff into into the coding

agent and they would pass stuff

back into the chat. I'm like, I

don't like, like, like I,

you're just intermediary. I

want to talk to your clanker.

So, so that's the last thing I

built this, this crap fleet,

which is basically we already

have crap box where the tests

run. Couldn't Codex run in

there as well. Turns out, yes,

it can. And then you have

multiplayer codecs. So so so

now if I work on something and

I want a second opinion, I can

just send a link to one of my,

my maintainers and like, he can

look at the session, talk to

the session, take over the

session. It's like multiplayer

clanking. There's more stuff.

We kind of rebuild slack. Yeah,

I don't know what happened

there, but we ran into this

issue where we had all these

model message channels, and you

often want to test it end to

end, but there was sometimes

features are very difficult to

understand with all the complex

API. You kind of want to see

see it in the UI. And I built

this automation, but man,

anytime I logged in, there was

like a Cloudflare capture or

like, like all these, all these

companies really don't like it

if you spin up something in a

box, especially not if it's

Linux based and there's nobody

logged in and it just feels

like it feels like someone's

trying to hack the system.

We're just trying to like make

it work. But I can see why

people don't like it or why

their systems would freak out.

So we just built our own

messaging platform to like test

to like, have real end to end

tests with something that we

have under control. And it got

a little bit out of hand. And

now we kind of have a backup

chat system that works.

Whenever our team is down, it's

called click clock. There's so

much more. Where were we? I

think I showed you, I showed

you a good part. Yes, there's

of course there's way more

crawlers. But my, my big, my

big takeaway for this is listen

to your listen to your body.

Listen when you're annoyed.

Annoyance is an amazing signal

for. We can automate this. And

then anytime you automate

something, it compounds all

these little tools. They're

working together, right? I, I

can only do the reports because

I use disk crawl and I could

only use crab fleet because I

have crab box. Even though all

of these are weird names, they

are incredibly helpful in

helping us ship a massive

codebase with a very small team.

And with that, I do think we

have a few minutes of Q&A.

There is a microphone. There's

a microphone here, so should.

As you're building. So. It's

making some noise. Is it

working? Yes. There we go.

Sorry. As you're building this

ecosystem and becoming more

like enterprise, quote unquote,

like, do you feel that there

are times where you want to

build something, but the

dependency on the other things

get in the way of you improving?

Hasn't happened so far yet.

It's less dependencies. It's

more like all those little

tools compound and make

building new tools faster in

many ways. Sometimes I use one

tool in another tool many other

times, and that's a general

trick. When you work with

agents, if you've sold

something once, you can just

tell the agent, look there, I

already solved this there. They

are really good at pattern

matching. So I would actually

say it really compounds.

Sometimes something doesn't

work out, but then you learn

from it like, like the the

token thing. Where was it? Too

many things. The token thing,

the first version I built was

just on my machine. That was

really awkward with the GitHub

app. So I iterated a bunch on

it, and eventually it was like,

I ripped it all out and I just

told my agent, remove this

feature here, rebuild this with

this new idea, but take that

part from that tool and like

push it into your tool. And

then like, basically you save

the prompting, right? Because

you already, you can just tell

the agent, look around this,

look at the git history.

They're very smart at figuring

out the context. Even better,

if you just press the, the, the

button and you just like, you

just talk about it sometimes.

Sometimes we just talk in the

team about it and I just press

the button and Codex will just

listen in on the conversation

and just start building while

we've been discussing, even

though there's like side

chatter and blah blah, but like

it's clever enough to

understand like, oh, this

comment was a joke and this is

important. So you just like.

You can just do stuff. Thank

you. All right. Hi, Peter, this

is Divya. My biggest question

is this is awesome. But imagine

you have a billion things on

your plate as a solutions

engineer. And I love the

concept of building my own

agents, but I simply don't have

the time to actually go ahead

and build tools to help me be

more efficient and save time.

Do you notice, do you notice

meme and like Stone age where

they had this car with

rectangular. And and then the

guy comes along with like the

round one and they're like, oh,

we don't have time. We're so

busy. So, so the beauty is all

these tools, they can be

massive slop. It's like you can

literally, you can really tell

your cortex, hey, look at this

session and see the pain that I

had to do. Build me a tool that

reduces the pain. This is the

rough idea. You don't even have

to give it a programing

language. Nothing matters for

like those little tools like I

use go. I don't even like go.

Like I know, I know that my

agents are fast and go, so who

cares? And then just like, do

it on the side, you know, it's

like there's always space

somewhere in the corner for a

little window for like

experiments. And it also takes

a fun a little bit back. And

then it, it really compounds