Can we start with the backstory of why

you decided to build Pi? I personally

like simple tools that are stable that I

can rely on even if they have

non-deterministic parts. So you can ask

Pi to modify itself. Pi doesn't have

MCP. People just ask Pi to build MCP

support into PI.

>> Non-engineers participating in

engineering process is a thing now.

>> You might have a PM who wants to try out

a feature without wasting time of an

engineer. Now you can do that. The

problem is that people are now so

focused on everybody can do everything

now that they forget that you still need

a process to guard rail all of that.

>> But you just recently wrote we all need

to slow the f down.

>> All the companies claiming that all of

their code is now written by agents.

Yes, we know the quality is garbage. We

feel it in our bones when we use your

product. It's garbage. Basically, I

think people need to

What if I told you that one of the most

influential AI coding agents of 2026 was

built by a single developer in Austria

who got frustrated with existing AI

coding agents. This is Pi, a minimalist

self-modifiable coding agent which has

quietly become the engine behind the

wildly popular personal AI assistant

OpenClaw. Mario Zner is the creator of

Pi and joining him today is Armen Roner,

the creator of Flask and now an early

adopter and contributor to Pi. In

today's episode, we cover the backstory

of Pi and why self-modifying software is

much easier to do with AI agents. What

Armen learned interviewing 30 plus

engineering teams about how AI agents

are changing how they work and why

software quality feels like it's

trending down, the case against MCP and

why CLI are becoming so popular and many

more. If you want to hear from two very

grounded voices in the industry honestly

talk about what's working and what isn't

and why we need to slow down as an

industry, this episode is for you. This

episode is presented by Statsig, the

unified platform for flags, analytics,

experiments, and more. This episode is

brought to you by Work OS. Engineers

love to build. Today's episode will be a

great example of this. We'll get into

why and how PI was built from the ground

up. But when you're shipping a product,

some problems are better solved with

trusted infrastructure built for scale.

Enterprise features like SAML, directory

sync, and audit logs are some of those.

Work gives you APIs to add them in days,

not in months. Ship faster without

reinventing the wheel. And now, let's

get into the episode.

>> Mario and Armen, it's so good to have

you here on the podcast.

>> Thanks for having us.

>> Thank you.

>> So, as a kickoff, Mario, how did you get

into tech and eventually into building

AI stuff?

>> Oh, well, that's a long story. How much

time do we have?

>> So, I'm a kid of the '9s, actually.

and uh got my first PC at 909 96. And

the trigger for that was that I loved

computer games. We were kind of working

poor, so we couldn't afford any of the

Game Boy and NES, Super NES stuff. But I

had an uncle who had an Amigga 500 and I

would go to his place every second day

and just play games there. And

eventually my my parents told me if you

work uh you can save up and buy yourself

a computer. And in reality, my dad would

do um what's he called? Schwartz of it.

>> Well, you're not necessarily paying the

taxes on your

>> Yeah. So, he would do his normal he

would do his normal job and after his

normal job, they would go fix cars and

work at construction sites and

>> Yeah. It's very common in Europe. Like I

know everyone did that.

>> And after two or three years or so, they

they just said, "It's time." And took me

to a computer shop in the nearby big

city and bought me a 486. And that's how

it started basically.

>> Pentium 486.

>> Yeah. an Intel 486DX40

MHz with turbo button and that's where I

started and I've always been into games

a lot um which also led to graphics

programming and through sheer luck I got

a job while I was studying at university

at um applied science organization who

was doing NLP stuff um machine learning

applied machine learning basically

taking research results and trying to

stuff them into industry applications

And that's where I learned the ropes of

machine learning. That was all before

deep learning became a thing. And I

actually quit that kind of domain in

2010 111ish because I joined a startup

in San Francisco.

And then later came back and joined

another startup with two friends in in

in Sweden where we did uh an ahead of

time compiler for jaw bite code to iOS

that got sold.

And since then I have a little bit more

time and I've always kept up with

machine learning stuff because obviously

super interesting. Uh and yeah and then

GPT happened and that's the story.

>> Yeah. And here we are. And then Armen

where were your roots?

>> So my roots are definitely not working

poor but I because my parents ran an

architectural office where they kind of

adopted computers for cat drawing. My

first computer was like old computers

that they recycled. So, my first

computer, even though I'm younger, was

in three. I'm

>> so sorry for you.

>> And and so, basically, none of the

computers that I ever had were capable

of playing computer games properly. Um,

because one, they used Windows NT, which

at the time didn't do anything. So, you

had to sort of like build your way

through it. And like the only way you

could actually get them to run was

because before it didn't know yet how to

get the Windows 95 or like Windows 311.

Um that was like before it booted into

either one of those you could boot it

into DOSs like really old DOSS games at

a time when you could already get better

stuff but but because it was sort of

this kind of thing I started toying

around with quick basic a lot um with to

Pascal I bought a bunch of books on that

um and I that that was my roots of of of

learning how these things work and it

just I wasn't ever really good at this

but I found it really interesting like

this this idea of like No, for sure.

Like I like I

>> We call it a tabler in Germans.

>> No, I I swear to you like I was when I

when I started dabbling with this, I

just really sucked. But like over time,

you like if you keep doing this, you get

better. Um and then in um 2002

or three, I I used I used to use Deli a

lot, which was like a visual version of

of Turbo Pascal.

>> Yeah. And in 2002 or 2003 someone uh

also showed me because I I I' I've got

this idea like I want to use Linux and

then um I del I didn't work on Linux and

then I found Python and through that I

started doing some Pyth programming and

there was a YUbuntu just came out in 204

and that was a venturebacked vehicle but

it they created all this like local

community. So there was this like Ubuntu

association. I together with a bunch of

friends we started the German Ubuntu

foundation uh not that foundation

association um and we ran this online

community called YUbuntu users for four

or five years and we and because Yubuntu

was popular the community grew and then

scaling problems came so like that's how

I got into web development um and then

for building this I just I wanted to

build a templating engine a web library

all of this and then eventually I

bundled that together and made this

flask frame work which got very popular

and even nowadays still is a thing that

clankers like to spit out.

>> That's hilarious.

>> Um h but I I left it and then in uh in

2013 14 or so I worked on computer games

for a couple of years in London but then

afterwards I went back to open source

and I I worked on Century for 10 years

and then left in April last year to try

something new.

>> So both of you are originally from

Austria. In fact you right now live in

Austria as well right? you were doing

games, you were working at Sentry, you

also did games before. Then the third

person who's not in the room but was on

this podcast just before is Peter

Stainberger also from Austria. Great

that the two of you meet where the three

of you meet cuz uh I I've I've recently

seen a bunch of photos especially before

Open Claw and Pi started you hanging out

uh the three of you experimenting

playing with AI.

>> I think the two of us met on on the

internet right on Reddit.

It depends because I definitely met you

once when I was at university.

>> All right.

>> So, but you didn't recognize me that

time and I was useless.

>> I was already famous.

>> Um, but yeah, we sort of abstractly met

on the internet,

>> but eventually we met up in Vienna. Um,

we were screaming a lot at each other,

but uh on the internet, but uh in a in a

very cute kind of way, in a very

non-confrontational kind of way. And

even though we might not think alike in

all areas of of of our lives, uh it was

a cultured exchange, I would say. So

that was nice. Uh and Peter I like 60°

of Peter Steinberger basically. Um I was

working at an office in my town and the

company that gave me free office space

in exchange for being like a mentor to

the CEO had some kind of business

dealings with Peter's company, PSPDF

Kid.

>> PSPDF Kid. Yeah. um and eventually came

to the office in Gratz and I think

that's where we met the first time and

then also the same year we met at the

conference in Istanbul and just hung out

for an entire night and that's basically

where it all started. Nice. And then how

did the both of you go from being

skeptical about AI when these tools came

out and again both of you have to at

that point and by 2022 you've been doing

a decade plus of building complex

software in different domains. what was

your first reaction to it and then

eventually how did you kind kind of come

across to the side of like well this

thing is actually really interesting

>> so for me it was I think in 2022 I think

co-pilot um GitHub copilot came out

before TPT

>> yes in 2021

>> yeah and through my previous startup

stuff I was working with Ned Friedman

and Miguel Daza from Samarine because

they acquired the company

>> with Samarine yeah they acquired the

company I talked about earlier the Java

compiler thing I I knew Ned Freriedman

from our early startup stuff and

eventually moved to GitHub and then was

in my DMs in 2022 I think and asked if I

wanted to have access to GitHub copilot

the tap tap tap autocomplete thingy and

I was like I I don't really care I don't

think this is going anywhere and he's

like no man it's the future got to try

it it's the future so I tried it and it

was absolutely horrible

but yeah after after when GPT came out

and especially when when they started

providing API access I did a lot of

projects just figuring out what works

and what doesn't work not necessarily in

the coding space but eventually once

they had tool calling that's when they

became very interesting or function

calling as openi called it back then um

but it took until 200 I would say 24 end

of 24 October or so for that to actually

be useful and that's where the coding

agents also became kind of interesting

and then 2025 um the cloud code team

came out with with cloud code and that

introduced the chanting search. So

basically just give the agent a way to

plow through your file system and read

all your files and it made the whole

difference actually

>> like all the things that came before

like cursor with indexing and and any

based stuff and and all of that that

just went away and I know that the CEO

of uh Chroma is probably mad at me for

saying this but that that was the

difference that it didn't it it wasn't

like a dense and sparse search thing

that the agent could could go through it

was just give it access to your files.

That that was it for me. That's where it

clicked for me.

>> I think my path was kind of similar. Um

because I think Copilot came out quite a

bit earlier, but I know that um there

was a program at GitHub that gave you

early access to Copilot at the time. Um

I think it was like this maintainers

group or something where I still was in

I got the feeling for Copilot that this

will actually be really interesting.

um but not in any way in which it is now

because I felt like oh I am in open

source for such a long time and now

they're doing like training in open

source data. It's like there is

something

at the very least this will be

controversial. I I didn't think about

like it being productive. I felt like oh

this is going to be um is going to be

like a controversial thing with like

training open source data and and and I

was I remember for like a time was like

I was trying to probe it like really um

>> whether there's flask in there. Then I I

was trying to probe it like really

adversarial. So one of the things that I

I probed on is like I probed on like

will it retail GPL code and I remember

at one point I got it to um spit out the

uh

>> carax inverse

>> carax inverse square root function which

is was very easy because also it was had

a very specific name. So like was very

easy to get the recall but I also found

like you can you can sort of tab in a

certain way then it would then continue

putting like license text on top of it.

It was completely wrong. it like came

from an open source GPL drop of of of

Doom originally I think. Um and so it

was like it would have been GBL code if

it would have done that but it actually

attributed like MIT license from a

random dude and I was like oh like Mr.

Cop that's the wrong thing and that

tweeted at the time got really really

popular and then sort of people started

like sharing with me like because I was

at a time not really exposed to how much

actual AI progress was being made in

those labs. Yeah,

>> like I I didn't come from this AI space

or ML space. So like I was I learned

about a university and like oh there's

AI winter and then nothing happens. But

through this tweet and some other things

I like other than I like I re recognized

that there was something there like

there's there's actually CEOs in certain

companies are convinced this will get

off and that's how I started like paying

attention to it and I was essentially I

was trying all kinds of stuff with the

API like can you do like bug fixing

things I got really interested in it but

it didn't at all feel like the world is

going to change until um cloud code

>> and you also changed your stance on the

whole oh my god this spitting out open

source code. It it memorized.

>> So, because like my like my shtick for

many years now has been that I really

I'm like a I want people to share stuff

like I I think like human progress comes

from like building on top of each other

and I I'm a huge supporter of the fact

that in the US you basically take

knowledge from one company to another

company that then no competes like I I

like this pirate kind of approach to

sharing.

>> Yeah. spread of knowledge.

>> Yeah. And so like I I was like my

optimal version is like copyrights don't

exist in a way or like very very like

limited kind of version of this. I was

like I really didn't care that it spits

out GPL code and doesn't attribute like

I was like oh maybe this will just

completely destroy copyrights and like

for me that was like oh this is I like

if if that's the outcome of like I'm I'm

fine with it. So it was but it was it

was an interesting kind of thing in the

beginning that it sort of like it sort

of creates this license violation like I

want to see like what what chaos will

emerge from it and so far I think mostly

what has emerged from it is like a

strong belief now that like the the

system in place for copyrights

has some presumptions assumptions in the

US about how it's supposed to work and

we're all kind of like ignoring that

right now because we want to create the

mess first and then reeregulate probably

because like at least in theory a lot of

the things that we're producing right

now are probably by historic readings of

the copyright interpretation actually

not copyrightable.

>> Yeah, that that's an interesting one.

But speaking of jumping jumping to today

so an interesting thing that you did

recently, we talked about it just before

is as part of your new startup is

building things on top of agents and you

talked to about 30 different engineering

teams saying hey how are you using

agents inside of your company inside of

your team? What did you learn from large

companies to startups?

>> I think the the a bunch of learnings

entirely unsurprising is that whenever

people had vacation, there was more time

spent on um trying these tools

>> and and just to be clear like you talk

with like folks at the likes of like

Meta Startups.

>> Yeah.

>> Like like a bunch bunch of different

people, right? So a bunch of different

people from like different like European

dinosaurs like

>> are you pointing at me?

>> Well I mean like the European dinosaur

would be someone like cementss.

>> Yeah.

>> Or I also talked to to companies which

are sort of in a critical space. And

what I mean like when

adoption happens when people have

vacation is that like when when your CEO

or your tech lead comes and says like

you got to use cursor now you got to use

cloud code now is actually you don't get

it in a way because you you need to

actually spend some time on like there's

a there's a it's like a two to three

week kind of thing until it really

clicks on you and so I I always felt

like with the people that I knew like I

had a lot of free time like I I left the

company in April until October. I was

like, I can dive into this and I I like

this is like how does nobody get this

and

>> a catnip for all of

>> it was it was crazy catnip. I didn't

sleep much all of this. But but what

happened within the company seemingly is

that when there was like Thanksgiving,

there was um for the Europeans a lot of

it was over summer and then at Christmas

a lot of people sort of and they also

get free credits during those times and

so like more and more people get

>> Oh, you mean the the companies often

give you generous

>> so and so more and more people went into

this and and especially after Christmas

I would guess like in more than half the

companies I talked to after Christmas it

really exploded um and and it it

exploded in And so in all the ways we

would expect it where like all of the

sudden the quality drops and and and and

it doesn't necessarily drop because like

people want to make worse code but

because it actually takes some effort to

to stay within this and we we have seen

this in the startup ecosystem already in

the summer last year like if you if you

pay attention to like the the YC

startups a lot of them some of them have

their stuff on GitHub or for some period

of time on gith when you can look at it

and like at the time because of like

plan MD files checked in and like

everything attributed to CLA. So like

that vibe coding kind of thing was was

for like prototypes and whatever like

that built that out. that was already

out there to see. But then gradually a

small version of this has like been code

bases with a little bit of vibe slop on

top. And an interesting sort of part of

this was like

how engineering teams and companies are

now responding to that um with all kinds

of like different findings. But but a

lot of it has been challenge to review

PRs. They're getting larger and larger

and they're becoming like more

psychological

>> and engineers specifically are having a

hard time keeping up with the the longer

PRs that they're more frequent.

>> Yeah. And there also there a lot of the

code in those PRs is how an engineer

wouldn't do it because as an engineer

you sort of get a really bad feeling

committing certain code because you

think of your future self and the agent

really does not care. This is I I will

retell this story over and over, but

like I I worked uh for an Xbox One game

at the time um right around the Xbox One

launch. So that was like a fixed date.

It has to release on that day. So I

worked on um uh the Halo Master Chief

Collection and there was a game where

you had like a matchmaking component and

you had to like start this thing and

whatever. And it was like it was an all

hands-on deck kind of situation where

people had to go in and unslop the

humanmade slop that was the matchmaker.

And it was like it was it was a system

with like way too many states. We call

it an emergence state machine because it

was like 16 bulls on one massive thing

and like in theory there were only six

valid states but in reality it was a

geometric explosion of possible states.

And that's how a centi code feels like

where it really should only be like a

very clearly defined system but in all

reality they're like oh we can config

doesn't load let's catch it down and

load the default config. So instead of

actually failing, it now recovers. But

now your code is way more complex than

it should be because instead of failing

properly, it is now recovering and

entering these many more failure states.

And that makes it much harder to work

with this code because you can also not

really ask the agent to refactor

applications like oh yeah, this could be

possible. So we need to maintain this

variant. I think it's kind of even worse

than what you described about your

humanmade complex system because there

are moments of brilliance in agents

where they spit out perfectly fine

simple code exactly the amount and type

of code you didn't need for that

specific thing and you as the steering

engineer looking at that like wow this

is amazing I can just sit back and not

care because it's obviously doing the

thing like two minutes later you have

another agent running in this window and

it spits out the worst horrible garbage

suppose but you might not notice because

now you have fallen into automation bias

and think your your your agent is doing

the job well. Do you think this might be

our bit of a human bias because because

you know like typically like onboarding

a new engineer uh you have when you join

a new grad you review their code and if

it's terrible code you will review the

next one thoroughly until they get to

the point that oh it writes the code

that I do and then it typically takes

you know 6 months or a year or something

like that but then you know I can trust

this person. Yes, but you don't have

anything like that with agents. Like

agents don't learn. You can put as much

stuff in the agents and do you build a

memory system, but that's not the same

type of learning than u a human does.

Obviously, humans are failable as well.

No, no, no matter. But they have some

capability of learning

>> and retaining that learning, right?

>> Yes. And they also feel pain. And I

think that's one of the defining things

about humans. It's kind of ties back to

what you said. Eventually, if the pain

gets too big, you as a human are incent

incentivized to fix the cause of your

pain. And in a codebase, the cause is

usually terrible interfaces, terrible

complexity that you want to get rid of

because you can no longer maintain that

system. Isn't this why just holding on

to that, you know, like senior engineers

are always in demand because from the

CEO sees a senior engineer as like they

just get it done, but in reality, a

senior engineer, most senior engineers

who are effective, they've had battle

scars. They've been burned. They felt

the pain. You they saw what happened

when they left tech def spiral. So they

now make all these decisions that they

know they they will help avoid. And of

course through this uh progress goes

faster. I personally think and your

mileage may vary. But a a good engineer

is an engineer that says no a lot and I

don't need this a lot.

>> Mhm.

>> Because that keeps complexity down. If

you're using agents, the exact opposite

happens. You say yes, I want this and

that. I want this and I want this and I

want this because I don't have to type

it myself. I don't have to think about

it. I just give the little machine a

prompt and it will spit out something

that kind of looks like the thing I

wanted. Good enough. And that's where

all the problems start.

>> And one thing that I also think is like

good engineering is all about knowing

the trade-offs that you have to make.

And there's sometimes the right solution

is actually

if you were to sort of like sit at

university and learn about it, you kind

of learn that you shouldn't be doing

this in a way. I think Kell Henderson

had this once where he said like you you

do the dumbest solution first until it

doesn't work anymore because the the

actual problem is there's so much stuff

that you need to do that if you actually

do the right solution the correct

solutions all of this it is it you're

creating the kind of complexity that

kills you at scale and the engineer

learns that but also like if you if if

you don't have that battle scar it's

actually very hard for you to argue

correctly because it is it is this

learning process that gives you the

authority to then convince other

engineers in the engineering org that

you should be doing it this way. That is

part of it. You learn that. But the

other thing is also that the agents give

you now world knowledge access. And one

of the other things that I learned

through interviewing engineering teams

now is that the senior person says no

knowing something and then 48 hours

later the junior comes by and said like

I talked to the agent and I already had

this inkling but now I have all the

evidence of why we shouldn't be doing it

this way because like previously you

really didn't have that readymade access

to

>> someone who can tell you a senior off.

>> Yeah. Ex and and this this is creates

other stresses now that were previously

like not every team has that because

it's like people going to the doctor

with a jetp print out and saying this is

what the machine said you better do

that. Is it fair to say that we are

based on what you're seeing and talking

we might face a thing where it's very

hard for experienced engineers to it's

harder just for them to say no uh in

spite of the product manager or a junior

engineer saying

>> it's much worse because the product

management comes in sends pull requests

and autom should them

>> yeah that's another thing like

non-engineers participating in

engineering processes is is a thing now

>> ask how that works

Ask him how does it work?

>> How how does it work Armen?

>> Well, it's hard because if because on

the one hand like it's well intended,

right? If someone who's like

>> what what is your experience? Is this

your your company talking with other

other people?

>> So, first of all, like like we have a

little bit of this air like we're small

and so um like like my co-ounder for

instance sometimes has like a pork on

the website. I talked to people that

have that at scale where like the

marketing team all of a sudden does

stuff on a website and and the sales

team like creates ever more elaborate

like sales demos that sort of land up on

a GitHub or partially at this one one of

the most funniest one was like where the

sales demo built a feature that didn't

exist but nobody noticed right so this

this is all like this is new right

because like previously none of that

happened.

>> But I think it's empowering like if your

entire

>> empowering it's like there's a good

thing to it in too

>> if your entire or if everybody in your

or can participate in in in in the

creation of software in some form right

previously people couldn't do that like

you had a designer who could figure

something out in Figma but they might

not be able to kind of put it into a

clickable dummy demo whatever or you

might have a PM who who wants to try out

a feature without kind of wasting time

of an engineer. Now you can do that. The

problem is that people are now so

focused on everybody can do everything

now that they forget that you still need

a process to kind of guard rail off all

of that.

>> And the integration part is the hard

thing. It's like that Peter

gave this idea of like the prompt

request, but I'm actually really warming

up to this idea like once you've

demonstrated it,

>> I no longer need your code. And and just

just to recap, the prompt request was

him saying that he doesn't like to get

pull requests. and said he would rather

see the prompt because he will run the

prompt or he will tweak it and it will

generate it in the style that

>> for me it's less about like I want to

see the prompt as it like what is it

supposed to be doing and now that we

understand because like actually in many

ways I think like the interesting part

is like often you don't really fully

know what you wanted to do in the first

place and so like the act of creating

clarifies what you really want to do and

so like that part is highly valuable

often the approach and the code that

comes out of it is not what an engineer

there with sufficient seniority would

have done. So it's not like I want your

prompt so that I can reclank my clanker

so that it does it slightly better, but

more like now that we know what we

wanted to build, it's probably faster

for me to start.

>> Yeah. And I also kind of disagree with

Peter on I just need your prompt. I

actually value seeing a terrible

implementation of something. Um like if

I get a pull request and most of the

pull requests we get on the Pi

repository are made by agents without a

lot of human touch. let's say then I

immediately know okay this is going to

be garbage but it's valuable garbage um

because someone has put in at least a

minimum amount of thought instructing

their agent to create this pull request

and I get to see how a shitty

implementation of what they wanted to

build looks like and I get to I I don't

need to waste my own time on trying that

out. So somebody else tried it out

already that the naive dumb agent do the

thing do no mistakes uh version and that

saves me time. I'm not saying I like

pull requests by agents because they

they're terrible and they autoc close

them now,

>> but they have value. It's it's not just

a prompt. It's uh on an exponential rate

sigmoid eventually always because ser

dynamics, but uh I think we're going to

find out way earlier than in previous

cycles that this is a bad idea.

>> That's good news. What I think is going

to be interesting and I don't know the

answer to this but uh I read this

fascinating retelling of the British

industrial revolution and how it it

changed the textile industry.

>> The industrial reind industrial. Yeah.

>> Yeah. And so the the the the the general

thesis on that article was like every

time something at the head of the

pipeline got optimized. It created an

incentive downstream of the whole thing

to create something right. is like in

the beginning like if you can weave the

thing faster then eventually you need to

have Garn that can be weaved at faster

speeds then eventually you need to

everything sort of turned a bottleneck

all the way down and like ultimately the

biggest bottleneck in the entire thing

turned out to be what I think like is

actually the the next bottleneck we're

hitting in engineering which is like at

one point you made a shirt and if you

didn't like the shirt you went back to

the person that made it and they fix it

up for you and so the actual thing was

like if if the shirt is bad nobody cares

about anywhere who destroyed fur in the

process. Is it just going to get a new

one? Right? Like the the responsibility

actually went from anyone in this chain

to the entire factory as a whole doesn't

have to care responsibility anymore

because we have we've commoditized the

whole thing so much that that you don't

you don't have to do this. And if you

take the engineering approach of it,

it's like a pretty significant part of

running a company and running a service

is like running it reliably. And so you

have these postmortems on incidents to

figure out like what went wrong in the

process

>> and you go back and fix the the shirt.

>> Yeah. And and and the thing is like we

we we we are running all on this idea

that every engineer that sort of is in

this creation process that ultimately

let up carries some responsibility and

that we're going to that person and not

saying like to blame that person but

like to figure out like why why did you

do wrong here? And so like if you do if

like the machine now produces stuff at

like 10 times the speed the

responsibility thing does not scale in

the same way because a machine cannot

yet be responsible. And I don't actually

know if there is a future where you can

abstract away human failure so much in

in how we run engineering that now the

entire company now no longer cares about

who signed off on a poll request or

something like that. We that we automate

it in the same way I think as we are

sort of automating t-shirt creation. I I

just don't yet see that. But

>> so here's the thing. I think one thing

we software engineers or or IT people

underestimate is just how freaking

complex the world is and how much human

squishiness is in each little nook and

and granny and and corner, right? So we

we thinking, oh, we could we were now

able to automate that thing. Uh now we

can automate everything like every bit

of knowledge work. But but we as

software engineers are so bad at

becoming domain experts that we don't

see all the non-machine parts that go

into a workflow and we running through

the same fallacy here again. We we

seeing models doing incredible things.

I'm not disputing that. Like this is for

me this is like w basically all my

research in the 2000s is now null and

void because transformers can do all the

things. But we are overextending that to

to everything like we always do in

software like like we did in edtech.

Yeah. We have tablets in classrooms now.

Sure. Now it's solved. Education is

solved because we have now computers. Um

>> well, in fact, I've heard I don't know

which country it was, but they're now

rolling back in Sweden. They're they're

taking the tablets out from the

classroom.

>> It turns out if you do some scientific

investigations into the tactics and

effects on pupils, if you do just throw

a bunch of tablets into a classroom,

close it and hope for the best. Turns

out the best is terrible.

Um, so yeah, I'm that for me I think the

biggest takeaway from the past two to

three years is the hype is terrible

because it's dehumanizes everything and

I want to not be part of that circus.

>> Well, speaking of not wanting to be part

of the circus, let's talk about Pi,

which is a which is a very popular

>> Let me get my clown nose

>> and also minimalist coding agent. C can

we start with the the backstory of why

you decided to build PI at a time where

there were already uh agent harnesses

around right because they were

suboptimal.

>> Tell me more.

>> Yeah, sure. I so I I was a a believer in

cloud code just because they kind of

created that whole genre through the

invention of a gentic search. I mean

inventions. There were precursors to

that and shows of giants and so on, but

they were the first that packaged it up

in a really compelling package. And at

the time that fit my workflow really

well. It was simply it was predictive.

So the LLM um uristic nature or stoastic

nature of of being kind of

unpredictable, but everything around the

LLM was kind of nice and tidy and easy

to understand.

>> So were you were a happy user of claw

code, right?

>> I was super happy. I was proitizing it.

But eventually the team started dog

fooding and getting more and more tokens

I guess and kind of increased velocity

and team size. And with that came more

features and much much much more bucks.

And I personally like simple tools that

are stable um that I can rely on even if

they have non-deterministic parts. But

all the deterministic parts should be as

stable as possible. And that was just

not the experience with cloud code

around summer 2025.

>> Mhm. So I kind of soured on that real

hard.

>> Was it was it bugs? Was it unexpected

behavior?

>> Like so they take away your control of

the context. They would inject stuff

behind your back which is bad. And then

your workflows that used to work stop

working because there's now a system

reminder that you don't even see in the

UI. Um that will modify the behavior of

the model. They would also do this to

the system prompt. I I I reverse

engineered. I mean, I wouldn't call

opening an offiscated JavaScript file

and unoffiscating it reverse engineering

coming from a more low-level background,

but I reverse engineered cloud code

during the summer of 2025 and build a

little service where I can track the

progression or evolution of the system

prop and tool definitions in cloud code

and it's like every release it was like

messing with stuff. CC history. Mario.at

if you want to see that. And uh yeah,

that that just messed with my workflows

and I don't appreciate that. If I commit

to a development tool, I want it to be a

stable, reliable thing like a hammer. I

don't want my hammer to break at a

different spot every day.

>> Yeah,

>> that's terrible. So, that's what

happened with Claude. But again, I'm

this is not like I'm not roasting the

team. I think they're some of them are

really nice people I got to know on the

internet. They're just dog fooding and

that's perfectly fine. We need somebody

who like goes the the full velocity kind

of way. I But I don't want to work with

a tool like that.

>> Yep.

>> Because I can't get work done.

>> It sounds like the move fast and break

things. to break things was not for you.

>> No.

>> And uh then I looked into alternatives

and AMP and Droid came out around that

time. I think

>> pretty early in 2025.

>> I don't remember.

>> Was early was very early. I think they

they sort of spun off from the same

experience of taking because I think AMP

was around when Clo came out. I'm pretty

sure around that time. Yeah.

>> Yeah. In any case, I looked into those

harnesses and they were super good. um

they were just super expensive as well

because none of them could basically use

what made cloud code enticing on top of

it being a cool tool um the subscription

and that works in an enterprise setting

where you're paying by token anyways um

but it doesn't work for the small

tinkerer in the garage while I'm not a

small tinkerer in the garage in the

financial sense anymore I kind of still

relate to that community and I would

like to use my subscription with

something so I looked into open source

alternatives and found open code. But

while that kind of wipes me with my OSS

roots, um it too did stuff to the

context I didn't appreciate behind my

back. Um pruning tool results after a

certain amount of uh uh tool result

token output or asking an LSB server

after every single edit the model makes

uh if there is an error. Yes, there will

be an error because the model isn't done

yet with its work. So the code doesn't

compile. So the LSP server will

>> so like reaching out to LSP. The

language um

>> language server protocol server. Yes. So

um when you go into VS code and you type

some TypeScript you have like in the

bottom some error diagnostics and that

comes from an LSP server for TypeScript

>> and Open Code runs an LSP server on your

behalf in the background and feeds the

model with uh diagnostics from that

server on every edit. We as programmers

how do we work right? We go into one or

more more files. We added line after

line after line and only then look at

the errors that resulted from that. In

open code's case or in other harnesses

cases that also support LSP, the model

calls an edit tool to change lines and

they would inject the diagnostics after

every edit call and that's just not

smart because now you're confusing the

model with you have an error, you have

an error, you have an error on the model

like yeah I know I know I'm not done

yet. Oh, it's not Yeah, it's not great.

Anyways, TLDDR uh open code wasn't for

me um either. It was also I had to fork

it to modify it which I don't think

should be necessary. So then I just

thought how hard can it be? I built my

own little thing.

>> And then your own little thing is pretty

minimalistic. What does it use? What's

the basics of of PI?

>> The basics of PI are um my own

abstraction over all the LM provider

APIs because I didn't like the VCEL SDK,

the VCELI SDK for various reasons. Armen

kind of wrote a blog post eventually

about that as well. It's obviously good

to use. Lots of people use it. It just

didn't fit my old man um sense of

abstraction.

>> But this is the beauty of software and

open especially open source. You can

build your own always.

>> Yeah. And now with agents you can even

do it faster and produce terrible

complex software. No. So I built an

abstraction over that. Then I built a

little abstraction for generalized agent

loop with tool calling and streaming all

of that. I built a bespoke little tool

that doesn't flicker or not a lot. And

then I tied that all together into a

coding agent that looks like clot code

or codeex or whatever you have. Um

that's it. And the extent ability comes

from the fact that this minimal core has

so many hook points uh that you can

basically hook into with a simple

TypeScript module um that gets loaded

into the same node process and that

allows you to do things like provide the

LLM with custom tools uh do your own

compaction implementation uh fully

revamp the TUI itself. You can modify

everything in the TUI. So if you have a

special

>> the terminal UI exactly

>> if you want the TUI to behave

differently for a specific workflow you

have like say you're non techy uh you

can change the toy to become whatever

you need as a non techy and I have a

couple of nonty friends that did that

because they don't need to know how to

build this they can just ask pi to build

it and pi will modify itself oh so this

is a thing right so you can ask pi to

modify itself because of the extension

points and it can write code that

extends itself and it's trivial, but

it's a big unlock.

>> Is this what you meant when you said

that? For open code, you needed to fork

it to to modify it. It doesn't have

this.

>> It does have a plug-in system, but

there's not a lot of extension points

and was very rigid. I think they changed

it recently. I think it's much more open

now. Um I I haven't kept up with it, but

might be better now.

>> So, I guess Pi Star has this very

minimalistic thing. As I understand the

the tools it has is read, write,

>> read, write, edit, bash. It's all you

need. That's it. And and then you can

actually like start to make it your own

like okay like at at what are examples

that people would add. Pi doesn't have

MCP. People just ask Pi to build MCP

support into PI. Pi doesn't have a plan

mode. Armening goes and my plan mode

must be fantastic bespoke and super.

>> I don't have a plan mode.

>> Yeah. But he has like five

implementations of a plan mode until he

realized plan mode is entirely useless.

Other people just like messing with the

UI and making it their own, like a

different visual style of the editor box

where you enter your prompts, stuff like

trivial stuff, more cosmetic stuff. Um,

other people have re-triggered it for

fullblown RL environment for open

weights models where they use pi as the

agent that does that part of the RL

execution environment. So it's you can

do anything really. What drew me to it

beyond like actually using the library

abstraction was was in fact the the

custom tools part because um one moment

for me was um over Christmas again like

many people had some time and I tried to

build other things and I and Peter was

talking to me in in November that he's

like vibing without looking at code more

or less. I don't know exactly how he

said like but like he's like he can do

this now like okay I I want to build a

thing where I don't look at the code. I

wanted it to not look like slop. I

wanted I wanted a version of it where

like afterwards like even though I don't

really look at the code it should look

like what I would have written and so

and I wanted to make a game and so then

I I basically

started the whole experience with like a

just basic pie like we want to build a

game but actually before we build a game

I want you to set up the codebase in a

way that you can validate the changes

that you're making but also I can see

them like like a like a twoprong kind of

approach like I wanted to be in the loop

but also O have the agent be able to

validate itself and and what what sort

of emerged out of that was well first of

all like it built itself some debugging

tools into the game so it can make

screenshots and like run a simulation

and sort of dump out state and read it

again but also pi can can show images in

a TUI and and and I added so a bunch of

like I talked with the twanker to figure

out like what would be interesting

things to do but we we ended up having

like a all the screenshots I can tap

through quickly in the UI or I can pull

Alo this great feature it can reverse to

an earlier state in the conversation and

then it can branch within the

conversation to build a bunch of stuff

around that because like these the

sessions especially with screenshots and

it become very token inefficient very

quickly. It was actually one of the

other things that pi was rather quickly

rather good at was having a lot of

screenshots in it

>> because open claw people had a lot of

screenshots in their chats and open claw

is using pi. Yeah. So yeah,

>> but but having this like it it felt

really magical for me to actually treat

the problem as I don't know what the

right way of engineering here is but

very clearly part of it is like I should

be in the loop so we can figure out like

how to specifically for the problem at

hand do that and and it turned out like

for web project and computer games and

some of the other things I tried they're

kind of different but very many of them

are sort of come down to a similar thing

where

The agent interacts now with my program

and it should do the most optimal way

and I want to interact with it in

conjunction with it interacting with the

program and the entire experience should

be as little confusing as possible to

both me as a human and to the agent. And

I found it very very fascinating just to

see how that emerges where like your

tool all of a sudden when you launch it

in this program looks and feels

different than if you launch it in the

other program.

>> I really like this point. Arma made just

a few seconds ago that AI works best

when the engineer stays in the loop and

the system can actually validate what

changed. And this is a great time to

mention our season sponsor Sonar. AI can

now generate code faster than you can

verify it. Sonar, the makers of Sonar

Cube, sees this leading to serious gap

in verification. With the rise of coding

agents autonomously writing code,

verification is no longer a nice to

have. While the latest coding models are

extremely intelligent, they also are

errorprone and they don't fully

understand your code base and your

context or your objectives. This is why

verification must be mandatory in

agentic workflows. Sonarq provides a

zerorust multi-layered approach to code

verification that is consistent and

repeatable. It analyzes semantic syntax,

data flows, and architectural boundaries

at agent speed acting as a critical

trust and verification layer before any

code reaches production. Covering 40

plus languages and 7500 issue types,

Sonar Cube is the most comprehensive

code verification platform available.

And with easy integration via MCP, CLI,

and hooks, it fits right into your

existing AI tool chain. Let agents move

fast and have Sonar Cube as the

independent multi-layered verification

for safe, reliable, and auditable

agentic development. Head to

sonarsource.com/pragmatic

to start verifying your agentic workflow

today. I'd also like to talk about our

presenting sponsor, Statsig. Static

build a unified platform that enables

both experimentation and continuous

shipping. Built-in experimentation means

that every roll out automatically

becomes a learning opportunity with

proper statistical analysis showing you

exactly how features impact your

metrics. Feature flags let you ship

continuously with confidence. And

because it's all in one platform with

the same product data, teams across your

organization can collaborate and make

datadriven decisions. To learn more,

head to stats.com/pragmatic.

With this, let's get back to the episode

and to the topic of general versus

purpose-made tools.

>> Yeah, I mean, I spend a lot of my youth

on construction sites to earn money. And

you don't use a hammer for all your

problems at a construction site. You

have a screwdriver, you have your

hammer, you have your drill, you have

whatever. And I think in engineering,

it's kind of the same. Um, I'm not using

the same tool for every task I do as an

engineer. So now, if I use an agent, I

don't want a general agent for every

task, per se. I want a specialized thing

where I know the performance will be

topnotch for that specific task because

we built the harness in the way that the

agent can be most effective at this this

task just because of the construction of

the way the the harness is constructed

and that's what I wanted to enable with

PI. That said, I'm probably the person

that has the least amount of

modifications in Pi. I have like two

extensions that I use and they're

trivial. They're basically just if you

see a URL that looks like a GitHub issue

or pull request thing, pull down the

details via the GitHub API and display

me a small little widget on top of the

editor that gives me the issue title,

the author account, uh, and a link to

the issue. That's basically all I do.

>> Well, but it might work for you as a

minimalist.

>> Yeah, I mean, that's how I work on the

on the Pyon repository because I might

have two or three of of sessions open in

which I process an issue or pull

request. That way I I remember what s

what the session was about.

>> But sounds like you also made your Pi

for that for working on the Pi monor

repo a specific one. And if you if you

were working on a if you went back to

building games, you'd probably have a I

never thought of the fact that you might

want a different harness for a different

task. I guess we just kind of assume

that most developers you work on your

main thing at work. You might have a

side project and just experime

experiment with whatever. But this this

I wonder if this is a new new thing that

we we could never have. We could never

have custom tools for a project. That

that just sounds crazy, you know. Here's

here's the like my intuition is this. I

think where we are going is software

that modifies itself on behalf of the

users's wishes and needs and the agents

can do that now if you give them enough

rope to modify themselves. And I think

with Pi that is my first foray into this

kind of selfmodifiable malleable thing.

um just for the coding agent sector but

I think this this this actually can be

extended to all kind of knowledge work

to a degree for specific tests within

the broader set of knowledge work

obviously the humanization and so on you

know but yeah um the next plan here is

actually to have an alternative user

interface to the TUI because the TUI is

obviously limited and the best

alternative stack is obviously the web

because it works everywhere and can do

anything so once I have that built out

that then it really becomes was

interesting because then you're not

limited anymore to the line based

rendering of a terminal. Now you can do

really really interesting stuff. And so

yeah, we'll see how that works out.

>> And one reason that I learned about Pi

before I I knew that it was this

minimalist interface is how OpenClaw is

using Pi. How did that come? And we were

hanging out and and reviewing each

other's blog posts and and just throwing

ideas at each other. And in October, I

started building out Pi and Peter

started be building out V relay, his

little WhatsApp assistant, so to speak.

>> Oh, that's how it started.

>> Yeah. And he was in search of a a gent

or copy. I think it started out by him

taking Pi and cloning it and calling it

towel and then modifying it. But

eventually he got tired of having to

maintain that. So he just said, I'm

going to use your stuff. And that's how

it ended up being. Pi wouldn't have

compaction if it weren't for open call.

>> No,

>> I specifically built that because Peter

was crying in the in chat and I need

compaction. Okay, you get compaction,

but I'm going to tell all my users,

don't use compaction. It's bad for you.

Yeah, but that's I guess the beauty of

of building on top of open software one

another, right?

>> I mean, it has pros and cons. Yes, I'm

now get to enjoy all the openclaw

instances that think bugs in open claw

are actually pi bugs. So they

autonomously send me a gazillion issues

and pull requests without the users

probably even knowing and I get to deal

with that in my open source. So that's

not that's a negative side effect.

>> Well, so you're you're really on the

receiving end of this I guess.

>> I mean just just like open call itself

is which is much more exposed to this

problem. I mean they have tens of

thousands of issues now and there's no

way they can get a good uh grip on that.

But but how are you dealing with the

fact that you now have open claw just AI

autonomously opening uh things on your

repo as a maintainer? Do you build tools

to battle this and try to close them out

or

>> build a tool for open claw ones which

embeds issue and pull requests into a 3D

space so I can see the clusters of

similar things that agents would have

sent to the repository and then I can

bulk select things and close them out in

in

>> Oh really? So you actually have a 3D

like visualization.

>> Yeah. open for context at I think it's

less crazy now but end of December to I

think midFebruary

I mean it was exploding obviously but

like this explosion almost like directly

translated to I I I was on this repo

refreshing pull request and the number

went up

>> we we actually tried to contri

contribute and help out Peter a little

bit but I immediately gave up

>> I didn't know how to do anything useful

there was looking at this I was

This is a type of software engineing I'm

just not used to.

>> Yeah, I I I would fix two things and

spend an hour on them and then five

minutes after I committed and pushed it,

some clanker comes along and just

reverts my fixes and this is not how I

>> Okay. Can we talk about the name of the

name Clanker?

>> Oh, sure. Um, so Clone Wars, Star Wars,

I I actually never watched it. Um, but

uh kids of friends of mine watched it a

lot while we were visiting them. So I

kind of through osmosis got the lore and

there is an army of robot robots and the

Jedi would call them clankers or people

who call them clankers because when they

move they clank clank clank. Yeah,

that's the origin of that. Yeah. So an

AI a droid. Yeah. Exactly. Yeah. But

coming back to the how do you deal with

the influx of agentic pull requests and

issues? I just auto close every pull

request. A human agent doesn't matter.

Um, what I do is if I haven't had

contact with you previously, my GitHub

workflow knows about this because if you

had, you're in a file in my Git

repository, your account name. So if

you're not in there and you send me a

pull request, your pull request gets

autoc closed.

>> Mhm.

>> And then my little workflow posts a

comment under your pull request that

says, "Hey, thanks so much for

contributing. Really appreciate it.

Could you please open an issue in a

human voice? uh no longer than a

screen's worth of text and uh if I like

it I type looks good to me and then that

account name gets put into the file and

the next time they send a pull request

they pass and it turns out agents don't

see the comment my GitHub workflow posts

underneath the pull requests. So this is

a great filter for filtering out agents

and keeping the humans safe more or less

from

>> this this is interesting. I wonder if

this might be the like an unavoidable

future where like we just need we need a

way to separate is this coming from a a

human with an intent or an AI.

>> I don't necessarily care if if if it

were actually a good PR then if it came

from a machine it's it's it's actually

fineish. I think what's interesting in

PI is like and and open CL even more so

is like it it accumulates pull requests

well actually there was no

intentionality behind it at all and so

the the person that dispatched the

machine didn't actually care that much

about it

>> but didn't even know about it

>> or didn't even know about it and I've

done open source for many years and

there was also there was a there was a

big difference between someone send a

pull request up or like an issue and

like hey please fix this but actually

didn't care enough

to even reply to questions anymore. Like

this not uncommon. And then you don't

actually have to fix that, but you have

to close it out because like maybe it's

it's still useful input, but like it

clearly that person wasn't caring

enough. And with the pull request, it's

even worse now because they come in so

quickly that many of them cannot be

merged anyways without manual resolution

of the conflict. And there's a there's a

lack of back pressure mechanism because

even I as a human if I see there's like

500 pull requests open like I probably

will not contribute to this thing now

because at the worst I will make it

worse. Yeah.

>> And and I think previously in open

source you had the people who would just

send issues and be very entitled and say

you're the worst person on the planet if

you don't fix my little issue. But

that's fine that can be handled. And

pull requests were kind of special

because it needed a human to invest

quite a bit of time to produce them and

you don't have that anymore. You just

have people, oh this this should be

easy. Uh agent, please do this thing.

Make no mistake, send it to this

repository and that's just not going to

happen. So basically what we need are

bottlenecks. I'm not necessarily I don't

necessarily need human verification or a

verification that you're human. I just

need a bottleneck that allows me to

process the amount of incoming things as

a human because in order for Pi to not

dtoriate into a pile of garbage, I still

believe that it needs me and other

capable people reviewing at least the

important code and for that I need

bottlenecks because otherwise I can't

deal with.

>> It's it's a second law of

thermodynamics, right? It's like

everything degrades towards chaos and

you have to put extra energy in to to

keep it away from this uh from this

outcome and we don't see and feel like

the pain of the codebase anymore if we

stop looking at it and people don't feel

the pain or like they feel no restraint

anymore and and it's the issues are also

interesting because on the one hand it

is something great about someone doing

an investigation and sending you a

description of that that can be good and

can be bad, but they look very similar.

Like it takes quite a bit of energy to

tell apart a good and a bad AI generated

issue request. And unfortunately, like

most of them are not great, but some of

them are actually good and that's also

kind of it's weird like all of it is

weird. I I really don't know what the

future of open source is in many ways

because like the a lot of open source

really worked because people piled out

on hard problems and so they congregated

around it and said like now we need to

have a good database so we're going to

put all this energy on building a good

database and the the value of open

source came from there's some hard

problems and we're going to our energy

together and we're trying to figure out

how to solve it and and now it feels

like open source is all about like

growing stuff up. What what really

grinded me so mad was people

particularly like a lot of Atlantic

engineering right now is like building

more stuff for Atic engineering. So it's

like it's yuborous or yuborous or what I

call it and and I I see this tweet and

it's like oh I solved problem XYC and

here is my solution for it and you click

on this thing it's like it's 48 hours

old that person probably never used the

thing that they built. I would like to

suggest to the viewership to look at

Arvin's GitHub account over the last

year and what happened there.

>> Yeah, I built a lot of the stuff, but I

don't then go on Twitter say like, "Hey,

I solved the problem, right?" is like I

I have a [ __ ] ton of VIP slop on my

GitHub account and I wish I could mark

it differently because like maybe

there's some utility in it, but unless

you're going to actually have that

codebase still be there a year, a year

and a half from now and someone is still

using it, the utility of that is

actually not validated in a way. And

there's so many markers and and metrics

you can look at now for GitHub that

really demonstrate this this explosive

growth of it.

But if you were to then maybe find some

other number to see like how many of the

things that are being created are

actually turning into like really

fundamental pieces that can sustain open

source communities that can that can

actually deliver this value that scales

amazingly. We haven't actually created

many VIP engineered projects that have

become that. But I I like how you

mentioned energy and how open- source

always worked. If we just think preai

again, let's say Linux, the most

successful or or widely used open source

project, it has both an energy and a

structure. You know, people come in with

intent that they want to add something.

They have a process where it goes

through. There's human trust at every

level. There's a little pyramid and in

the end it all goes back. Each change

request goes up one level and in the end

Lionus uh does the cut. But there's a

lot of energy. There's a lot of intent.

uh there

>> there's a lot of humans

>> there there's a lot of humans and it was

always about human energy and now we

suddenly have this AI which it's just

tokens right now they're who knows how

much they're subsidized or or not or

it's just machines doing and then

suddenly you know they create plausible

things that that look like human energy

and it's hard to differentiate and

suddenly just like there was this wrench

>> actually disagree I don't think a lot

has changed to open source

>> okay

>> um

>> the volume has changed

>> no yes uh But that's just a number. Uh

the the amount of as you said the amount

of actually useful and maintained

projects has probably not changed a lot.

>> So you're saying that the ones that were

there, they're still useful and

maintained.

>> Not even the ones that were there, there

might I mean there's a specific rate of

new open source project that survive

longer than two weeks.

>> Mhm.

>> That's always been the case, right?

>> Mhm.

>> So now we just have more projects that

die after two days than before. But we

still have the same amount of projects

that will have a long-term viability

just because there are humans that

actually care to maintain the thing over

a long time. Build a community of humans

that support the entire thing. Build an

ecosystem around the entire open source

project. That makes

>> you say not you're not believer into

mold book.

>> No, I mean good job meta putting that

up. Super useful. Um, no. I I I think at

the end of the day we we're kind of

freaking out when we don't actually need

to because apart from the fact that I

personally can now generate code faster

speed of light for me building an open

source project and that entails not just

the code but the community around it the

spirit around it the ecosystem around it

nothing changed um what changed is

mechanical parts I I need the

bottlenecks to deal with the influx of

exponentially growing uh agents pull

requests whatever um GitHub itself is

under immense pressure Because now it's

not just humans hammering their infra,

it's now billions or millions of Open

Claw instances hammering their infra.

>> Yeah,

>> everybody complains about GitHub going

down. I actually think they're doing a

pretty good job. Like that's a lot of

traffic that's coming their way since

basically Christmas. It's basically open

call. So yeah, I I I would be a little

bit more optimistic. We're just indeed

messing around and finding outstage at

the moment and everybody wants tokens to

be a KPI just like lines of code used to

be a KPI. We've seen this speaking

around of of things that don't change

and messing around and finding out. You

you wrote a a tweet or or you wrote

somewhere that your biggest enemy is

complexity. It's also your agent's

biggest enemy. Can we talk about that?

>> Very simple. If I have a 600 lines of

code code bis and my agent can at best

be affecting effective up to a context

window size of around 200,000 tokens,

how much of the code can the agency see?

A third, right? Great. Um, if you manage

to get all the relevant code for a task

into that context window, you're

probably okay. Although that is a

separate project an information

retrieval pro uh problem which is not

solved and which agentic search also

doesn't solve that is does are you sure

that the agent finds all the relevant

code it needs to find to to fulfill a

thing that's also where all the garbage

code comes from because it doesn't see

all the thing it needs to see in this

case let's assume the best case

information retrieval is solved

everything fits into a context agent

does a good job okay that's not the

reality we're living in because now the

agent spit out so much code they

themselves cannot possibly read into

their context on a new task anymore. You

know what what I mean?

>> Yep. They develop their own context

window.

>> Yeah. Exactly. The complexity they add

is their own worst enemy because

eventually the code base will be so big

and so complicated and so interconnected

um that the agent has absolutely no way

on a technical level to ingest all the

context it needs to do the new task. And

I would like to point out that the agent

has learned all of this garbage from the

internet and from us because on the

internet there's all our old code. While

there are some pearls, uh there's also a

lot of swine.

um because we have a gazillion GitHub

projects from the olden days where we

just tried out things and because

instances like Linux or any other really

well-maintained and well-ritten open

source project are minuscule in compared

to all the rest of the garbage and a

machine learning model will kind of

converge towards not the well simplified

to the mean right and what is the mean

then it's it's not the handful

comparatively of excellently engineered

projects it's all the garbage on the

internet all the cargo culting all the

trend type of the day kind of stuff and

that's what we get when we let the

agents do all the things for us.

>> Yeah. So we have this problem of things

are getting more complex which slows

agents down which will in fact impact

quality which we were just talking about

but Armen now that you're you're

building your own startup

you two of you're building your startup

now how are are you and you're working

with agents right and they they will

have these things how are you dealing

with generating code building products

balancing quality tech complexity

>> I'm dealing with that

>> badly look I think that

>> we're coping. We're not dealing.

>> I don't know if I wrote this in the

blog. I definitely have it on my slides

for for the for a conference here. It

was um I enjoyed the time from from

April to about October immensely because

it felt like I can do so much but also

like there was no heightened expectation

like the world has not yet gotten used

to this idea that everything has to now

also move at 10 times the speed. And

there was a there was a moment of time

where I felt like like we we worked in

this vibe tunnel thing in the beginning

and it was like it felt so much fun

because like I I have time now to play

with the kids and I just prompted a

little bit on my phone and like it felt

>> VIP tunnel was where you could set up

with your phone talking with your

machine where it wasn't that easy

>> terminal basically.

>> Yeah. And it's not that we did much with

it, but like I it it it had this like

happy vibe and like I know that I spent

too much time on the computer, but like

it didn't I didn't feel any pressure.

But now it's like this like we're

collectively feeling like everything has

to ship faster. It has to like iterate

faster like the the the baseline that we

want to achieve in terms of fidelity and

everything has to be higher. And so now

it feels very stressful

>> even in your own startup.

>> Yeah. Because like to some degree you

cannot like

>> you can be the most stoic person in the

world and it's still going to get at you

in a way that I'm slowly learning to

work with my own emotions in a way on on

like on dealing with this. is I I find

it very very hard in a way to because

like I was I was used to things working

a certain way and and I I I knew how I

do some stuff and and then I fell a

little bit too much in the trap of like

giving into the machine and actually

doing things in a way that I normally

wouldn't have done things

>> that you regret.

>> It's definitely a gentic regret.

>> Gentic regret. Yeah. And so like the

quite frankly the answer is like I I I

feel like now with a little bit of power

of hindsight um learned some things that

I wish I would have learned probably in

November.

>> Tell us.

>> Well I mean like a lot of it is like

really the recognition that if you

there's no back channel to the to me or

to any other engineer when under normal

circumstances there was a back channel.

was this this this feeling of like

things are not quite right in the

codebase like there was this now the

change is harder and like the complexity

like do you sort of see then the

complexity of the pull request getting

higher but like if you rubber stamp it

then like what's what's the back channel

there and so like this this mechanism

this back pressure this friction in the

codebase you don't feel when you work

with the agent

>> I think there's a way to kind of measure

it and um like if I scan through my

sessions on a project from start to

current date. I think the frequency of

curse words increases because the agent

starts messing up more because it itself

cannot deal with the complexity of the

add to the project. And I would be

actually really interested in whether

this measurable because I feel it uh in

most of my projects now it occurs a lot

more.

>> But you you mentioned friction in the

software. You didn't say tech depth. You

didn't say complexity. What what what is

this friction? cuz I I don't remember us

talking about this pre- AI at all.

>> So, I found this ironically kind of

funny and it it's kind of sad, but so I

will not name any names, but uh there

was a what I what I assumed was an

incident related at least in part to

achieve engineering on on a company uh

where they they shipped out a

configuration change that ultimately

result in a security issue and look

things happen. But the link that I saw

on this had the social preview of that

company's tagline and the tagline was

ship without friction. And that g that

get me really gave me pause because like

you I I know as an engineer like we used

to talk about like you got to get rid of

like all the things in the way so that

you feel happy shipping stuff. But there

there always were changes where you

really wanted to think like do you want

to drop the database like do you want to

merge this migration which might take a

table lock that could potentially take

you down. Right? is like there's there's

this this moments every once in a while

where you really you were really

supposed to think and and you and people

created checklists or people created um

like like mechanical gates that would

where you would have to confirm

something like there's there's certain

things that we used to put particularly

if you run a SAS company did you put

stuff in so to slow things down or and

in in some of the best engineering teams

in order to mature a service you have to

define an SLO you have to define um like

yeah expectations and like if if your

service is supposed to be critical but

like there's some other stuff that

unlocks on this sort of tree of of

requirements that you and and and like a

lot of engineers be like a this is also

this bureaucracy but like the reality is

like if you do this correctly then it

saves you time and it like it makes you

happier. You're not waking up at 3:00 in

the morning like all of this is useful.

>> It's like friction injected to

deliberately slow things down. I guess

the easiest example in any decentsized

company you have services based on tier

based on criticality. the highest tier

uh software now needs to have let's say

two or three code reviews or an approval

from a director to do a configuration

change which again all slows down but

it's kind of like we know this is on

purpose like by adding this friction we