What if you could merge 600 commits on a

single day and none of it was slopp?

This is what today's guest, Peter

Stainberger, the creator of Claudebot,

claims he's doing. Peter is a standout

developer who built PSP PDF kit, the PDF

framework used on more than 1 billion

devices. Then he burned out, sold his

shares, and disappeared from tech for 3

years. This year, he came back and how

he builds and what he's doing now looks

nothing like traditional software

development. In today's episode, we

cover why he no longer reads most of the

code he ships, and why that's not as

crazy as it sounds. How he is building

Clawbot, his wildly popular personal

assistant project, which feels like the

future of Siri, the closing the loop

principle that separates effective AI

assistant coding from frustrating vibe

coding. Why he says code reviews are

dead and PR should be called prompt

requests, and many more. If you're

interested in how the software engine

workflow could change in the coming

years thanks to AI, this episode is for

you. This episode is presented by

Statsig, the unified platform for flags,

analytics experiments, and more. Check

out the show notes to learn more about

them, the pragmatic summit on the 11th

February in San Francisco that I'm

hosting with them, and our other season

sponsors. Right, Pete, welcome to the

podcast.

>> Thanks for having me, Gay.

>> It is awesome to meet you in in person.

>> Yeah, and I almost messed it up.

>> Yeah. What what what what happened? You

lost track of time. Does that happen

often? And how how so? Um, not usually.

Not usually. Um, this is an interesting

time for me cuz I cuz my latest project

is is blowing up. Cloud, right?

>> Clawbot. Yeah,

>> Cloudbot.

>> I'm struggling a bit to get enough

sleep, but it's it's it's interesting. I

never I never had a community blowing up

so fast and it's just incredibly fun to

work with.

>> So, before we we get into Clubbot and

all the fun stuff you're doing, I wanted

to rewind all the way way back. You

create a PSPDF kit which is used I think

on more than 1 billion devices users. If

if you see a PDF render you probably see

that. But even before that how did you

get into tech? Oh my god. How did you

get into tech? So I'm from rural

Austria. Um always more being the

introvert.

So eventually I we always had like

summer guests and one of them one of

them was a was a computer nerd and then

I kind of got hooked with with like the

machine he had and begged my mom to buy

me one

and ever since then I this was in high

school or so.

>> I guess I was 14.

>> Yeah. And ever since I started

tinkering, like I can remember the

earliest thing was like I stole an old

DOS game from my school and then wrote a

copy protection for the floppy disc so I

could sell it.

It took like 2 minutes to load. I was

just always tinkering. Also playing a

lot of computer games of course, but

like building stuff almost feels like

playing a computer game. Like definitely

right now it feels better than Factorio.

Oh, when I started out, I I I I read

like

the equivalent of bash scripts for

Windows and then I did like websites.

So, I guess a little bit of JavaScript,

uh, even though I had no clue what I was

doing. And then the actual first

language where I I had to learn how to

build things is when I started

university.

And I never met my dad. And I come from

a from a poor family. So, I always had

to work. like I had to had to finance my

own studies, right? So when other people

were were having holiday, I just worked

full-time at a company. So the the first

real job I had was was in Vienna was

supposed to be 1 months and then they

kept me for 6 months. It was just a

bridge between military and and my

university. And I kept working there for

like I think 5 years. And I remember the

first day they they gave me this huge

book. maybe that huge and say Microsoft

MFC. Um I still have nightmares and I

got I got like I was like this is

terrible like for for the next win I

just I just silently used net I just

didn't tell them and like a few months

in I just told them yeah but the text I

I did a few modernizations but then it

was too late. I did this a few times in

this company. I don't know why they kept

me because because my worked. So uh

I did net and actually I actually

actually dig it.NET 2.0 had like

generics. It took insanely long for the

application to to to launch because like

everything was compiled at first start

and like your hard disk was like

if you remember

>> so so you you how did you stumble into

both iOS and where did the idea from

PSPDF

>> come from?

>> Not even yeah the first one the first

one wasn't even available in in in

Austria. That's true. Yeah.

>> A little time goes went on and I was at

university and a friend showed me the

iPhone and I I think I I touched it for

a minute and then immediately bought one

like like this like it it clicked when I

felt it and and to me this was like a

holy f moment cuz it was just like so

different and so much better. So I got I

got one. I was still not thinking about

building for it, you know. That was that

was

>> when was this 2009 10 something like

that.

>> Yeah. Yeah. And then I I used their

browser. I I can see the story. I was I

was literally driving in the subway.

>> Mhm.

>> And by the time I was using a gay dating

app and this was iPhone OS 2.

>> Yeah.

>> So So I I

>> long time ago

>> I typed this long message. I pressed

send and we were just going into a

tunnel and the JavaScript disabled the

send button and then an error message

came but there was no copy paste. There

was no screenshot. So I was just like

and I couldn't scroll anymore because

like scrolling was disabled. So like

this long message was like a little bit

emotional was gone and I was so mad. I

was so mad. I'm like what the hell? I

went home and I downloaded Xcode. That's

that's where that's where the window

came and I was like where is the ID?

So it was like like I was like this is

unacceptable. I basically hacked the

website. I used regular expressions to

like download uh to parse the HTML which

is like totally not something you should

do and I built an app and I used I used

iPhone OS3 beta with like core data in

beta regaxit light. I used a hacked

version of GCC that backported the

blocks compiler so I could use blocks in

iPhone OS3. It took me quite a while

until anything worked because like I had

no idea what I was doing and I was like

using all kind of like beta tech but

eventually I I got it to work and I I I

wrote that company was like hey I'm

making an app. What do you think about

it? Got no response of course. So I was

like let's just put it in the app store.

>> And this was for the dating app right?

>> Yeah.

>> So you just like you know you looked at

you saw their APIs you could just like

easily like build a client on top

>> API. It was HTML.

>> Oh

>> I was I was just literally parsing HTML.

>> Oh. So, so you kind of parse the HTML,

kind of turn it into your own, you know,

like you use it as an API. Oh, clever. I

mean, this was back in the day where no

one thought this this would happen, but

I made I put it in the app store. I

charged five bucks for it and I made

like 10k in the first month.

And I had no clue what I was doing. So,

and there was like so many complex tech

stuff. This was very early on where

there was a lot of weird forums on

Apple.

>> So, I just put in the the bank account

of my grandpa. And then one day my

grandpa called me, "Yeah, something is

weird. Like I got this huge payment from

Apple." I'm like, "This is mine. This is

mine. Don't touch it." But the the funny

thing was when I this blew off and I

remember I was in a club one day and

like I saw someone using my app and I

was so proud and I wanted to like tap

him on the shoulder and say I built this

and I thought like that would be really

weird. So I didn't. And then I I I went

to the company I worked for for 5 years

and told him like I'm going to pursue

this. This is this is really exciting.

And my boss was like mocking me.

>> Oh, really?

>> They're like, "Oh, you're making a

mistake. This is a fat. This will not

go." Blah, blah, blah, blah, blah. And

you know what that got me? That's what

you call a chip on your shoulder. I'm

like,

>> you know, one day I'm going to I'm going

to have a company that that's worth more

money than yours. Well, it took me eight

years. So, I I got hooked. Like, I I

worked

I I'm I'm a little bit of an addictive

personality. So which you see again

right now. But I I worked a lot on this

app. I learned I learned in in high

speed and this was also the time where I

started Twitter and that was usually

hugely influential for my career. I made

this app actually quite good and then

one day I was at a party at at 3:00 a.m.

um slightly intoxicated and I got a call

from a US number. The guy on the phone

was like, "Yeah, hello. This is John

from Apple. Yeah, there's a problem with

your application. Like some people

reported pictures and that was it. That

was the end of my app. Um,

>> it was good until it lasted

>> and I was just I just quit my my job and

was like, well,

f you Apple.

>> I did freelance work. I was at dubdub.

I was introduced to

>> dubdubdubc.

>> Yes. Sorry for the insider terms. I was

introduced to someone as one of the best

iOS developers in Austria at a bar at 2

a.m. in San Francisco and then basically

got a job in the US and then I moved to

the US for a while and then I I went to

the Nokia development days. This is all

like stone age by now. My god. And then

someone came up to me and said, "Yeah,

they built this app somewhere in Eastern

Europe and it works but it crashes

sometimes and it was like was like a

magazine viewer, right? This was back

when the iPad just came out and Steve

Jobs hit that like this is the savior.

So everybody was building magazine apps

and I was like that sounds like an

interesting short-term gig. And I I was

like okay I I'll I'll I'll help you out.

And I opened the app and it was like oh

the worst code I've

ever seen in my life. It was literally

one file with like thousands of lines

>> of Objective C. Yes. Where they used

windows as tabs. I I didn't know this

worked. I was surprised this worked at

all, but it felt like a a house of

cards. And I I tried to I tried to

surgically fix things, but like as soon

as you would touch something, something

else would break. Um so I got it I got

it somewhat stabilized and I told him

like, "Look, this is this is like

madness. Um I'm going to rewite this for

you." Yeah. But it took half a year. I'm

going to do it in in a month. Well, it

took me two months. Um, I wasn't that

far off

and and then here I was working on a on

a PDF viewer. You know, on every

technical problem, the domain is is I

wouldn't say like completely

unimportant, but you can always find

interesting problems in every domain.

And there was a lot of interesting

problems because you had a C call that

would render a PDF that would maybe take

30 megabytes, but the whole system had

64 megabytes. So if you're not very

smart and like very careful what you do

in the background and when the OS would

just kill you. I got really fixated at

like making it good like when the

rotation is like that the page would

like animate and so so you know I I like

I like those details. I spent way too

much time on that. That's why I took two

months instead of one. But the end

result was it's good. Um and then I I I

worked with them for a while and then a

friend texted me up. He's like, "Yeah,

I'm working on this magazine app and

it's really hard." I'm like, "Yeah, no

way it's hard. I know." Oh, like I did

it.

>> You just built one.

>> And and he was like, "Can you can you

can you get me the code?" I'm like,

"Sure." So, I sold him like I extracted

the the part that was PDF from from this

magazine app. And I I made sure I made

sure like the other person was okay. And

then I sold him that. I was like, "Well,

if he's interested in that, why let's

not try to sell it to other people." I

used a a WordPress template and

mutilated it to run on GitHub pages and

then and then when you did the the fast

lane flow at the end you got a Dropbox

link to my personal Dropbox with a

source code sip and I put this on one

afternoon and I I tweeted it and and

then in that week three people bought it

and it was like I guess 200 bucks but

back then and for me this was like

amazing and not only I got like three

people who just bought it and like 10

emails who comp 10 people who complained

about

uh because they wanted it but it didn't

have the features they wanted. You know,

it's like I got nerd sniped. I was like,

"Oh, I didn't have text selection." Oh,

how hard can it be? 3 months later. Oh,

yeah. It's really hard.

Text selection in a PDF specifically.

>> Yeah. Yeah. Yeah. Yeah. You know the

saying the saying like uh the companies

are built by young people because they

don't know how hard it is.

>> Yes.

>> Yeah. Yeah. I had no idea what an insane

madness this file format is. Peter was

talking about how some problems look

deceptively simple. PDF rendering is a

good example. You look at it and think,

how hard could it be? And then you spend

months on edge cases that you didn't

even know existed. This looks easy until

you build it pattern shows up in other

places, too. Internal tooling for

feature flags and experimentation is a

classic example. Teams often

underestimate how much work it is to

build infrastructure around these tools.

There's a reason big tech companies like

Uber invested years into building

internal experimentation and feature

flagging systems. Which brings me to

Static, our presenting partner for the

season. Static gives you the complete

toolkit without building it yourself.

You get feature flags, experimentation,

and product analytics all in one

platform tied to the same underlying

user assignments and data. In practice,

it looks like this. You roll out a

change to 1% of users first. You see how

it moves the top pipeline metrics you

care about, conversion, retention,

whatever is relevant for the release. If

something goes wrong, instant roll back.

If it's working, you can confidently

scale it up. Companies like Notion went

from singledigit experiments per quarter

to over 300 experiments with static.

They shipped over 600 features behind

feature flags, moving fast while

protecting against metrics regression.

Microsoft, Atlassian, and Brex use

static for the same reason. It's the

infrastructure that enables both speed

and reliability at scale. Static has a

generous free tier to get started and

pro pricricing for teams starts at $150

per month. To learn more and get a

30-day enterprise trial, go to

stats.com/pragmatic.

And now, let's get back to Peter and why

rendering PDFs was a surprisingly hard

problem.

But now, I remember there was a few

weeks ago someone emailed me. They did

something PDF and they wanted my help.

And I just wrote them like, I'm sorry,

like I I did my deed. I I know more

about PDF than any any sane human person

ever should know. And I went I went to

therapy. Good luck.

But that took off and and I just I while

I was waiting for my visa, I I worked on

this project and and it just kept on

more people kept on buying it. And you

know, it was like it was like summer. I

was I was like lying at the lake and got

another email that someone bought it for

600 bucks, 800 bucks. I just up the

prices as it had more features. And by

the time I I went to San Francisco to

work at this company, it already made

more than what I made there. But my

whole life was I still I still thought

like I have to be there, you know.

>> So I I did it. And also interestingly at

this company, I had to

>> So what would you say that you moved to

San Francisco?

>> Yeah. And and of course also it ended up

being something where I had to build

build something with my framework at

that company too. But you know startups

are not like 8 hours. They're a little

more. And my personal project was also a

little more. So my sleep was a little

less. And then eventually after 3 months

uh Sabine my manager came over and said

this Peter are you okay? And they gave

me a choice uh to either keep working at

this company and drop my project or or

vice versa. And I had one week to

decide. The counter was one week to

stay there or leave the country because

I was on a on a complicated visa.

And well, the decision was quite easy.

It's like, yeah, I want to do my own

thing. And then and

>> and at this point, it was already taking

off. You already saw that this is

there's a big business here. It it will

probably pay you as much as your US job

would have paid. Ah,

>> it was never money driven either.

>> It was more about what what were you

driven by? I want to make stuff that

other people find amazing. Like I I I

love tweaking the details. I love those

little delights. It wasn't even that the

space there were competitors in the

space. But my angle was always like I

built something as if Apple would have

built it like like with with like all

the love and care and and polish and and

those little delights that

a lot of people in the industry don't

get. Uh, so even though we had

competitors that had way more features

and were around way longer, my company

was more successful and my product was

more successful cuz developers tried the

the different ones and mine just felt

the best. I think software is all about

about how it feels much more so than the

than the feature set. Like why did we

buy Apple stuff? It has more features

than than Windows. Um, but it it feels

better. So, how did you go from like you

you left this company and you were

building this PDF component that started

to sell. At what point did you hire the

first person realizing, okay, there's

something more to this? when I went back

to Vienna then I was like okay I have to

go all in and that's where I I started

working with freelancers a little bit

and way too late to be honest also like

I I could have could have hired much

earlier but you know you know it's it's

it's a big step and that's kind of where

it it started having a life of its own

and I spent

pretty much 13 years of my career

um building this product with this weird

name that I never changed because I took

me like I thought like five minutes

about it and then stock PSPDF kit.

>> PSPDF.

>> They finally they finally did a rename,

but I wouldn't have I wouldn't have

renamed it. But now it it

>> it's it's a mouthful, but it's very

unique.

>> Well, you get it if you do Objective C

because it's just a name space.

>> Yes.

>> Um and by by the time it it made perfect

sense, my marketing my strategy for

marketing was always I only care about

the developer. Like I know like upper

management does the decisions but if I

can convince the people inside the

company they all do the marketing and

lobbying for me that worked really well.

We never did like cold cold emails or

aggressive. It was all inbound. All we

did was like make good stuff and write

insertful technical blog posts that and

I went to a lot of conferences like the

for me important it was okay if if

people understand that the people who

built this product are like know what

they do and and love what they do that

reflects on the product and that that

worked really well.

>> And then what was the text type behind

PSPDF kit? Was it objective C? Was it

later swift? Were there other

technologies like C or or anything else?

>> We eventually expanded to to all the

platforms. Um big shift was the switch

out renderer which was and is still

quite buggy to like a big C++ one that

when then we used across all the

frameworks. Um we we were we were really

early with web. We were one of the first

PDF frameworks that ran in web assembly.

And I I did the most clever thing that

it was in the very early days when Web

Assembly was just taking off and we

built a benchmark and that benchmark was

eventually used by by Google and

Microsoft and Apple and I basically had

all these companies like working really

hard on making my renderer faster cuz

cuz they used their benchmark as one of

their benchmarks and the benchmark was

just like rendering our stuff with our

>> Ah nice. And then a as as a company

grew, one thing that I remember about

PSPDF kit, you did write a lot of blogs

and one blog in 2019, so this was about

like I think you know year nine or 10 in

the company. It was about how the team

worked and you you mentioned things

there like every feature starts with a

proposal. You mentioned that you are

conservative because it's a it's a big

API that that people use. You want to be

careful things like the boy scout rule

such a factor. How how did you kind of

put together the the culture of of this

now this team which was now closer to 30

or 60 people?

>> We were actually 70 when when I sold my

shares and now it's almost 200. And I I

knew right from the get- go it's like

I'm not going to find the people that I

need in Vienna. So it was always just

like remote first and eventually we we

landed up with some kind of hybrid model

uh which made things a bit more

complicated. I learned a whole lot on

the go. Like I I never had the urge to

be CEO. I always was coding. I I brought

people in to people that that helped me

a lot with other other parts. Uh and on

the business side, I can do it and I I

think I think I'm I'm quite good at it,

but I just don't enjoy it. Like even on

sales calls where you like have to like

think of all the magic number how much

it would be worth because that's how

enterprise works. Gh worse. Peter just

said, "Ah, the worst about enterprise

sales. Because selling to large

companies, enterprises, is as tricky as

it gets." Not just because you need to

get pricing right, but because of all

the enterprise features that you need to

build. And this leads us nicely to our

season sponsor, Work OS. If you're

building with AI agents or automation

tools, here's a problem most teams don't

think about at first. Once an agent can

take actions on your behalf, you need to

control what it's allowed to do. And

traditional O just wasn't designed for

that. That's why work introduced MCP off

which gives teams a way to authenticate

AI agents with explicit permissions

auditability and enterprisegrade

security. Instead of sharing over scoped

API keys, you can define clear

boundaries for the data that agents can

access and the agents they can perform.

If you're building AI powered features

and want to share fast without

compromising security, check out

workeros.com/mcp.

And with this, let's get back to Peter

and enterprise pricing. But that's also

the only thing that that really works on

on a model like this.

>> Yeah. You mean enterprise sales

specifically, right?

>> Meaning custom pricing. So So can you

tell us for for for you know devs

listening who go to a vendor's website

and they're frustrated that there's no

price. It says call us or schedule

meeting. Why that is?

>> Oh, that's that's why because we going

to look at your company and then just

take the dice and and and think about

the number that you're probably willing

to pay. And that sounds horrible. But

also when you have a product where you

can't really tear it down to a specific

number like it it's it makes a

difference if uh a freelancer contacts

us or one of the big Fortune 500s. Let's

not say names

>> because the usage will be different. The

value they get out of it will be

different and charging the same. You

would either exclude one or the other.

If I if I if I go too low, they're going

to see this fishy. It's like uh

procurement for like 500 bucks. we're

not going to even start the process. And

if we we target it too high, we're going

to lose those people. So So as horrible

and unfair this process seems for some

kinds of products, it is the it's the

most fair way after all. You know, you

know, on software

there is I would say there's like four

axes. There's like easy and hard and

interesting and not interesting. We were

very much in the not interesting and

hard part. If you build something that

every developer wants to build, it's

going to be a hard cell. It's it's a

hard sell anyhow. Selling anything to

developers is a hard sell.

>> Yeah.

>> But if it's if it's too easy or too

interesting, good luck. But if it's

>> oh god, I don't want to do this and oh

my god, this is hard. That's a good spot

to be in. So So I found a really

interesting niche and there were just an

infinite number of complex problems.

>> You you you need to tell me tell me one

or two hard things about parsing PDF.

How hard could it be? There's a

specification. I'm an engineer. I know

specifications. I What's so hard about

it?

>> I mean, there was this one example

where, you know, like PDF has have

links. So, like there's like there's

like a table of contents and you click

on it and it goes to like page 37. So, I

built this whole model with the

assumption, oh yeah, maybe there's like

a 100 or 400 links in there.

>> And then we got this one customer who

like paid really good money. And then I

was like, oh, it takes 4 minutes to load

a PDF. What the heck, guys? And I looked

at it and it was like a 50,000 page text

bible from Canada and it had

>> 50,000 pages.

>> It had like more than 100 links per

page,

>> 500,000 links.

>> My data model completely exploded

because my assumptions were off by a

number of what 1,000. But by then you

have like a mature product with an API.

So like how do you how do you completely

redesign the internal part without

breaking things for everyone? like

suddenly everything has to be lazy where

where before parsing 100 one was easy

but now they were like this was like so

difficult to keep it working for people

um I think I spent like two months just

on that completely redesigning like the

internals and like making sure it's

still easy for people they don't have to

know what we what we load easy what we

load lazy or if you copy this thing it

it still has to like have to keep some

connection

>> it needs to keep the references and and

some of those things.

>> So, so I and I I love to do support and

I think that that that also a confining

factor why the company worked cuz if if

you send a ticket and then the the the

CEO replies and helps you out

um that has impact and my my strategy

was always like I always used to list in

reverse cuz if you if you send a ticket

and you get a reply within 5 minute

that's magical. If you wait one or two

days not much difference. Yeah.

>> So, yeah, this this was one of the

problems where I worked two months and I

finally got it down to almost like this.

>> Mhm. That must have been satisfying.

>> And and it was this was very satisfying.

>> And you were writing a lot a lot of the

code or you were involved in in in a

bunch of the code like obviously a big

big team was now here, but you were

still kind of overseeing it, right?

You're in the details. I mean, of

course, I had a a really great team and

and some parts I was more involved. I

was always more involved in mobile

because that's where my my heart was,

but I was always very deep in the tech

and and the the

marketing side, the business side. I had

like Jonathan's help, I had marketing

help. There was I I I found good people.

The the thing is if you like the

blogging and writing about how you solve

interesting hard problems will help you

hire interesting people that want to

solve interesting problems. This is what

I remember at PSP PDF kit that your blog

was every now and then it admitted it to

hacker news as well but it was just

interesting to read and I couldn't name

again I I'm not went into PDFs but if I

had to say something a PDF I would have

said PSPDF kit because they're the only

ones where I read interesting engineing

blogs about how you optimize your ship

is still there by the way I I I myself

also sometimes ask myself like hm

interesting do more companies not see

this or is is the question that you you

need to be a developer who's either the

CEO or or up there who just likes doing

this. And by the way, did did you ever

write this thinking this will be helpful

or you just wrote because you got

something out of it like putting out

that you solved this hard problem?

>> I like sharing and and and like

inspiring people. Um there was sometimes

even conflicts where we were like should

we write about this because it's like a

little bit of secret sauce

but I just never listen to those voices

too much. Um I just you know there's

also like when you when you write

something down there it's this principle

of like you understand it but then if

you want to teach it you really have to

understand it. So to to me it was also a

little bit like oh yeah I worked on this

really hard problem and now I want to

like preserve it and like help others.

So, so, so I I got I got a gig of it of

of course I liked the attention. Um, but

really it it was this

sometimes I just referenced a year later

to my own post like yeah this this is a

this is both company documentation. This

is like my own lookbook. It's helpful on

so many ways and a lot of those bigger

companies.

Oh, they put on too much red tape.

There's a lot of developers who don't

really like to write. So I I I forced

everyone once a month a full day just to

write a blog post.

>> But you gave them the time. You're like

that day you don't need to do any other

work but write something.

>> Yeah. You have Yeah. You have a day to

come up with a post. Ah a day is is

quite much actually. I mean when I'm

nowadays when I write posts it still

takes me

a few hours. I don't want to dwell too

much on like the I think the the the

starting time of the company is the most

interesting. the then the the growth

phase, you get more red tape, you get

more people. It's much more gardening

your product instead of like doing doing

wild hacks

>> um and more iterative. So, so, so it got

a little bit less interesting uh over

the years and there was like more people

drama cuz the more so the more people

you have, the more issues there are and

I didn't enjoy it that much and I was

really really burned out. What what

burnt you out, do you think?

>> I was just burning too hard. I was

working most weekends. I I I tried to

shuffle all my managerial needs. And you

know, as a CEO, you're basically the

waste bin cuz everything everything that

other people don't manage or or can do

or or mess up, you have to fix. And it's

also quite lonely because you you can't

openly talk about a lot of things. I

mean I I I I structured the company to

be quite open but still like you cannot

you cannot be negative. You have to even

if even if like even if like really bad

stuff happens. I know there was like

there was like one weekend where my my

co-founder called me at at 5:00 a.m. and

told me like yeah there's this big

airplane company and their planes are

down because our software is crashing.

That was a very interesting weekend

until I could like I disassembled their

their app and did proof that they messed

around with our source code to

triggering a triggering a license key

fall back. Uh that eventually like

caused issue they had. But that was like

a if they sus company's gone and more

moment. Um and that's just on top to all

the additional stress and there were

quite a few of those things. You can do

that for a while. And I I also believe

like burnout doesn't necessarily come

from working too much. It it comes more

from or at least for me when you when

you work on something but you don't

believe in it anymore or you have like

too many conflicts and and we also had a

we did fight a lot in the team uh with

like management team and by the time I I

made this mistake and I thought you have

to like lead a company more

democratically.

Um so that was also something that

burned me out. I wouldn't I wouldn't

want to miss it for a while, though.

>> Yeah. So, you know, from from the

outside, it seems you sold your shares,

you made enough money to not have to

work again, should you not choose. And

for a lot of people, like, you know,

people who are starting out their

business or or one day want to start a

business, this sounds like the absolute

dream. Like, this is I guess what we

know realistically that most people will

not make it, but if you make it, I mean,

you've kind of like I guess you know,

checkbox done. You're kind of it's a

little bit if you're like climbing on a

wall and you ring the bell, you're done.

And then what I noticed is from the

outside again on your blog, the blog

post completely stopped for several

years. What what did you do uh in in

this time uh and and what what what did

you learn in this time, you know, before

you came back to to where we are now?

>> I needed a lot of time to decompress. I

I catched up a lot on the things I

thought I missed. I I a lot. Um there

were months where I didn't even turn on

my computer. And for a while I was I

just didn't had this feeling of like

what should I do now? Like like I

definitely was like

why border? You know, you're not you're

not supposed to to retire so early or

like have so much have such a good exit

that you never have to work again. That

messed with my mind quite a bit. That

>> that was some that was some hard years.

And then in in April I was like

I there was this idea that I had years

ago and even a side project that I

started I was like oh yeah I want to I

want to continue on that and then after

after after more than 3 years I just sat

back to my computer and and started

hacking again. But the thing was this

was like a a Twitter analytics thing and

it was written in in Swift and Swift UI

and back then I already knew this would

have would be so much better if I would

build as a website.

>> So So was this an existing idea that you

kind of had at the back of your your

mind something something Twitter

analytic?

>> Yeah, it was just like something I

wanted to build for myself because uh

because it didn't exist and then

>> even three years later it didn't exist.

It still doesn't exist. Uh it it kind of

does but I got a bit sidetracked. So I I

went back and I I wanted to build it in

in with web tech. But web was really was

always even at the company the one thing

that I looked into the least because I

had I had someone really smart who took

care of of of that side in the company

that I brought in Martin. So I never had

to worry about it. That was one of the

>> You're not hands on with React or any of

that stuff.

>> Yeah. And when I came back, I was like,

what's a prop? You know, that that level

where you really where and you know,

this is like this is a a trap I see with

many developers. The the better you get

at one technology, the harder it is to

jump somewhere else. It's not that you

can't do it, but it hurts so much.

You're like like I can I can program in

in in in Apple stack. and program blind.

But then in that stack, I have to Google

the most mundane stuff and it it just

like it just hurts. You you you feel you

feel like an idiot again.

>> Yeah. And and I guess the more

experience you have, it it kind of sucks

feeling. I mean, I'm sure you say

embrace and and all that, but it's it's

not great. You're not as efficient. You

know that you could be faster, etc.

>> Yeah. So So I came back and I was like,

gosh, there has to be there has to be

what is this AI? What is this AI stuff

that every that that people are

dismissing? let's look into this. Yeah.

And in April, a lot of us were the

specific probably for rightfully so, but

and I and I and I like and I to a degree

I I credit those three years where I

basically didn't turn on my computer

because in those years you guys checked

out AI and learned that it's crap.

>> Yeah. the the people who like I was

about to say so you missed out on you

didn't do the beta of GitHub copilot you

know glorified autocomplete which is

GPC3 or or maybe not even there was then

of course 3.5 which is a big jump and it

it got incrementally better than GPT4

and so by the time you came back what

tool did you first use when you cuz you

missed out on like two years of like

like devs us devs using dismissing

finding some niche use cases for it

>> oh cloud code so you start with cloud

mode that I think came out.

>> It just came out It came out in May, but

there was a beta beforehand.

>> Yeah. Yeah. I think they had something

Didn't they have something in February

already?

>> They had a beta from February. Correct.

>> Yeah. So, so

>> so clock was your first you you come

back after like a you know hiatus and

you immediately turned on clock code and

you missed everything else before. and

and and you know, you know, it was like

I I remember I took this big messy site

project that I built and I have this

browser extension where that that

converts a GitHub repository into one

big markdown that was like a 1.3

megabyte markdown file and I dragged it

into into Google's CI studio with

Geminina 2.5 or two to something and I

typed write me a spec and it generated

those 400 lines of spec And I dragged

this back into cloud code

and I was like build and then I continue

continue continue and while I was like

working on other stuff, you know, um and

eventually told me like it's 100%

production ready and I started it and it

crashed. I'm sure we can all relate to

the story of the AI saying the code is

production ready then crashing. This is

a pretty funny and innocent story, but I

personally don't trust code that AI

generates without verifying it. And this

leads us nicely to our season sponsor,

Sonar. So, let's look at some data. A

new report from Sonar, the state of code

developer survey report, found that 82%

of developers believe they can code

faster with AI. But here's what's

interesting. In the same survey, 96% of

developers said they do not highly trust

the accuracy of AI code. This checks out

for me as well. While I write the code

faster with AI agents, I don't exactly

trust the code it produces. This really

becomes a problem at the code review

stage where all this AI generated code

must be regularly verified for security,

reliability, and maintainability. Sonar

cube is precisely built to solve this

code verification issue. Sonar has been

the leader in the automated code

analysis business for over 17 years,

analyzing 750 billion lines of code

daily. That's over 8 million lines of

code per second. I actually first came

across Sonar 13 years ago in 2013 when I

was working at Microsoft Skype and a

bunch of teams already use Sonar Cube to

improve the quality of their code. I've

been a fan since. Sonar provides an

essential and independent verification

layer. It's the automated guardrail that

analyzes all code whether it's developer

or AI agent generated, ensuring it meets

your quality and security standards

before it ever reaches production. To

get started for free, head to

sonarsource.com/pragmatic.

With this, let's get back to Peter and

how AI agents cannot exactly be trusted.

>> Then I had then I added added an MCP so

it could use the browser. I think the

player with MCP was already there and it

looped a few more hours and then I had a

I had a Twitter login page and it it did

something. I It was not great, but it

did something. And to me to me this was

my holy mind-blowing moment.

>> Yeah.

>> This and this was like in April or May

this year, right?

>> Yeah. It was it was it was just good

enough that I could see the potential

and I I understood it's like

>> yeah this is this is where it's going

and and from that moment on I I had a

few months where I had really trouble

sleeping and I in

>> I I remember because once on Twitter I

sent you a direct message. I was up

early for valid reasons, you know, my my

kids or something like that. But it was

5:00 a.m. and I I sent you a message on

Twitter and you replied immediately. And

I was like, "Why are you up?" And he's

like, "Oh, this is usual. Like I I

usually I'm still usually awake." And

and I asked like, "Why?" And you said

like, "Oh, I'm I'm just like using

Claude and it's really really

addictive." And I was like, "Really?"

And you're like, "Yeah, I'm not joking.

Like it's really good." And I think that

was the thing. You said something or

wrote something like just one more

prompt. like you told me how like what

what made it so addictive or or what

what still makes it so addictive?

>> Oh, it's the same economics as as you go

to a casino. That's that's it's my

little slot machines, you know? You you

you press the trigger and ding ding ding

ding ding and it's like nope. you you

type in the prompt and it it will like

and it does it does crap or it does

something that actually blows your mind

and it's this

>> and and you're saying it it blows your

mind as like you're a really experienced

developer like it's it's not easy to

blow your mind, right? Like you you

you've seen good code you can

differentiate like crap code, decent

code, good enough code like you have a

bar, right? It's so funny, you know, in

my company, I used to obsess over every

detail, every spacing, every new line,

the naming. I spend so much time bike

shedding. And in retrospect, I'm like,

what the heck? Why did I do that? Like,

what's the point that the customer

doesn't see the insights of of course

like it has to meet certain certain

standards. It has to work. It has to be

fast. It should be secure, but like how

much did that bike there is like

stupid.

>> You say that, but then you also just

said that people loved PSPDF kit because

it was the most polished. It worked the

best. Do you not think that that that

amount of caring bike shedding as you

call it? Being obsessed. It sound like

you were keeping tech depth at bay, you

know, like being obsessed with white

spaces is is not going to be messy. And

we know it's not just the white spaces.

we know you're going to care about

testing and all that. Like it sounds to

me that PSPDF kit like you know like

what I see is you were not just building

a product that was great UX but you

built something that had a really good

hygiene and that's how it could be high

performance and all that is how do you

think about it?

>> Yeah. Yeah. Yeah. To a degree. Yes. And

and even now like I I I mean like my my

last blog post was a confession that I I

ship code on read and

>> yeah we have to talk about that

>> and at the same time I spent so much

time to like restructuring

I mean I mean like even even today like

I I really wanted to get this PR in

where it was like 15,000 line change

where in my I moved everything over to a

plug-in architecture where I was so

excited about and I care a lot about the

structure. Did I read all the code? No,

because a lot of code really is just

boring plumbing. Well, what are most

apps? Like data comes in from an API in

one form. You like you parse it, you

package into a different form. Hey, you

store it into database and it's a

different form. It comes out again into

a different form. Then it's like HTML or

whatever. And you type in something it's

a different form again. And all you do

is like you're massaging data in

different forms throughout your app.

This is what most apps are. We are

pretty chasing printers. And the and the

the really the hard part is solved by

Postgress 30 years ago by some neck

birds. Uh that's that's really what a

lot of software is like. There's always

some interesting parts, but I don't have

to care how this button is aligned or

which tailwind class is used or or like

many details are boring and many other

details are interesting. But it I think

it's much more about system architecture

than having to read every single line.

>> Right now jumping forward, what is your

workflow like? Like like when you're

working on on cloud bot, are you using a

terminal, multiple terminals, which

which tools and and how are you you know

like you said you're not you're kind of

like not reviewing the the code, but

you're still thinking about

architecture. Like what does your

average day look like in terms of

tooling? You know, you have to explain

to a developer who might join the team.

you know, at at one point you didn't get

like what does it look like?

>> It's interesting. Let's let's let's go a

little bit. We were we were in in in

April with Cloud Code and then I got

really hooked and then I did some I had

a phase where I did cursor and then I

did I I used Gemini 2.5 a bit. Then we

had this phase with Opus 4. I hooked up

a lot of my friends like I know I know

both Armen and and Mario from Vinner.

They got they got AI pill because I I

was addictive. You know, my my enem was

like confusing them and then they tried

it out and then and then eventually they

also were up at 5:00 a.m. and I called

it like the black eye club. I mean,

there's a reason like I I I I started a

meet up in London that I called called

uh Cloud Code Anonymous because because

it's it's a little bit like a drug

because it's so it's so much fun. Like

to to me what what what blew my mind so

much was this realization that I can

build everything now. Before you had to

really pick which side project you build

because software is hard. Yeah, it's

still hard. But now like I I am this

this friction that I talked about where

I'm so good at this at this technology

and I'm like so bad at this and I'm like

oh let's make the CLI in Go. I have no

clue about Go. But I have I have a good

system understanding and once you have

that is like you you develop a feeling

what's right what's wrong like it's it

it is a skill in itself. I remember

there was this tweet where someone said,

"Oh, when you write the code, you you

feel the friction and that's why that's

how you make good architecture." I feel

the same friction when I prompt because

I I see the code flying by. I see how

long it takes. I see if like the agent

pushes back. Um I see if what it creates

looks like messy or like makes sense.

When I prompt, I I have a hint already

how long it's going to take. If it takes

much longer, I understand that I messed

up somewhere.

>> You kind of feel the model. you you know

you know

>> yeah usually it's like this or if it

runs

>> I I feel it's very much a symbiosis like

I I learn to to talk

>> may I even say dare or that language

more so it's like my my knowledge how to

use those things improved and also the

models improved and then and then like

over the time between between April and

now I would say yeah the inflection

point was summer where it just got so

good that you could you create software

without actually writing code by hand.

But the real that change that like sold

it for me is was

again GBD 5.2 that was again I think

it's underrated. I don't know I don't

know why why all these people still use

cloud code. I I I kind of get it. It's

it's a different way of working but

whatever OpenAI cook there is insanely

good. pretty much every prompt I type

gives me the result I want which is

insane like like on on on cloudbot the

my latest product I use

between five and 10 agents in parallel

if you're very much cloud code build you

have to forget quite a lot of the

the silliness that the things that you

have to do to create good output with

cloud code I mean I also met that team

and and they created a whole new

category. Like cloud code is is is a

category defining product and it is

amazing for general purpose computer

work and it is is really good for coding

and I I I I still use it almost every

day. But for writing code in complex

applications, Codex is just so much

better because it it it takes 10 times

longer. um Claude would

read three files and then be confident

enough to just like create code and then

you really have to steer it and push it

so it reads more code so it gets it sees

a bigger picture of your codebase so

that it it it weaves in new features

better and Codex will just like be

silent and just read files for 10

minutes and if you if you only work on

one terminal I completely understand how

you how you find this unbearable

But I rather have something where it's

also you don't tell it what to do. You

know this is this is also something that

people don't get like I have a

conversation with the model. It's like

oh let's look at this what what what

what options do we have for this

structure? Did you consider this

feature? It's like because every every

session is like the model starts from

having no understanding about your

product and you have and and sometimes

you have to just give it a little bit of

pointers. What about this and this? So

it explores different directions and you

don't need plan mode like I'm just

having a conversation until I say build

this it will not build this. There's

some trigger words because it it is they

all are a little trigger hungry but as

soon as I say let's discuss or give me

options they will not build things until

I say build.

>> So so a lot of a lot would you say a lot

of your prompting or a good part of it

is this conversation where you are

pretty much planning together with the

agent.

>> Yeah. It's like what about like I say

okay then you remind them it's like okay

we need documentation what would be a

good spot it would like give me some

recommendations I say no this should

really be its own page do we need a

configuration how how does this fit into

this other feature it's like I am

designing the system because I have this

I have this system understanding about

how how is my my product how are the

shapes looking I don't have a line by

line code understanding that's that's

what Codex does for me but I'm the

architect you

It sounds a little bit like you're

almost, you know, for

years back this this totally came got

out of style. But there was this idea

that you would have the architect with a

capital A who used to be a software

developer, but they're not hands-on

anymore because they spend a lot of time

understanding the business and they have

these developers working underneath

them. And some companies still kind of

work a little bit like this, but most

modern companies don't. But some banks,

etc. I met people there who are capital

architects. They do the system plan.

They talk with fellow architects. They

have the blueprint and then they

literally pass it down to the team and

everyone hates this model obviously

because you know again like I I think as

people you kind of want more. The

architect is never on call for for this

stuff and so it just kind of breaks down

in practice and a lot of large companies

just move to the staff engineer model

where you're kind of all working

together. Of course, there's people who

make who might have more input, but

sounds like it's almost like this world

where you are the architect who kind of,

you know, you have your little agents

who who do the code, except in this

case, you are of course fully

responsible because you're still an

individual contributor. You're not

you're not like a okay, you might say

you're a manager of agents or whatnot,

but the code is is yours. It's your

responsibility. You're going to be on

call. If you know, if you push out code

that takes down CloudBot, which it did

just recently, you're on the hook for

it, right? like and I think the the

difference in this system when when it

was in companies it was the architect

was kind of shielded from the output of

their work because there's so much

people and so much process etc. Well, I

wouldn't say architecture. I I like the

word builder.

>> Builder. Yeah.

>> And and and I think also that's there's

a few categories that I see for people

that are highly successful using using

AI and people who really struggle.

>> I care more about the outcome, the

product. I very much care about how it

feels and everything, but how the

plumbing works underneath.

>> I care structurally, but you know, not

to the not the biggest detail. And then

there are people who really love to to

code on hard problems like think about

algorithms don't really like the I'm

building a product with like all the

marketing all the they they more like

they like to solve hard problems and

those are the people who really struggle

and and and often reject AI or get

really sad because that's exactly the

job where that AI does like it solves

the hard problems. Now sometimes I give

it some pointers but many times I

learned I learned more this year than

last five years around around software

architecture and designing. I the

there's so much inside those monsters um

on knowledge and everything is just a

question away but you have to know what

question to ask. Of course I also built

this Twitter thing and it's still not

done and I and I I really hope I I'll

get back to it at one one time.

everything worked but if I used it more

at some point things got really laggy

and weird and then it worked again and I

just couldn't figure it out and it was

like really difficult to debug because

it was not easy to reproduce. It was

just like you use it more and things get

really slow. I basically had like

software in in in in Psql like in

Postgress that would be triggered when

certain inserts were were doing and then

the database would would get really busy

and the model couldn't see it because it

was it was it was so far abstracted from

all the you know like those those models

are really good at tracing through but

this was a side effect that was so hard

to see because it was only in this one

file

a function that had no connection to

anything else. um with a name that was

not easy grabbable. I just never asked

the right question until I was like do

we have any side effects for this and

this and I found it and I fixed it and

it's like but I everything is just the

right question away.

>> Yeah. But you you need to have like

knowledge, expertise.

>> Yeah. You experience

>> you you I mean so so so these are the

people who rejected and then the people

who who care a bit less about how it's

being plumbed internally but are just

excited to build things. They're really

successful. And one thing that also

helped me is, you know, when you run a

company and then you hire people, you

can't breathe on everyone's neck and

like make them have the line of code

exactly that way. And there's a lot of

people who who didn't manage a team,

they didn't had this experience how to

how to relax a little bit and understand

that yes, this maybe is not exactly that

code that I want, but it will get me

closer to my goal. And for anything that

is like

not perfect, we can always make it

better and like put more time into it. I

very much believe into this iterative

improvement. I had to learn to let go a

little bit at my company. So, so, so

then when I when I had cloud code, it

kind of felt like I have like I have

like imperfect, sometimes silly, but

sometimes very brilliant engineers that

I have to steer and where we where we

work together on a common goal. It felt

a lot like being the boss again.

>> Yeah. And and interesting now you know

you you built kind of software I guess

the traditional way you know pre AI for

15 years or even more than 15 years and

you got really good at being also

leading a team and then how to have high

standards. You really cared about the

the craft there as well. You've now kind

of been I guess vibe coding or working

with agents for a year. You're comparing

the two. What do you think? What do you

think really really changed? And what do

you think are things that kind of stayed

the same despite all

>> First of all, I don't like I don't like

the term VIP code.

>> All right. How should we call it?

>> I I think I think I think VIP coding is

by now almost a I I call it I tell

people I do what I do is agending

engineering with a little star. VIP

coding starts at 3:00 a.m.

>> Now like because all the the mundane

stuff of writing code is automated away,

I can move so much faster. But also

means like I have to sing so much more.

I'm still very much in the flow. Like it

is it is completely the same feeling as

for me as as I I very much get in this

flow state but it is mentally even more

taxing because I have I don't have one

employee that I manage. I have like five

or 10 that all work on things and I

switch from this one part to this other

part to this other part to this other

part. mostly because of I'm designing

this new subsystem or like this feature

and then I know that it will probably

take Codex like 40 minutes or or one

hour to build. So like I want to like

have the plan right and then I build it

and then I'll I'll move on to something

else but then this is cooking and then I

work on this and then this is cooking

and then this is cooking and then at

some point this is cooking and then this

is cooking and then I go back to this

one. So like I I I I switch around a lot

in my head. I wish I wouldn't have to do

that. Like I'm sure this is a

transitionary problem and at some point

we have we have models and and systems

that are so fast that that I can

paralyze a little less. But to stay in

the float flow state I need to massively

parallelize. So that that's that's how

it work. I go back to there and and

maybe tweak it a little bit more. But

usually just like try it out and maybe

then this is ready because this only

took like 20 minutes. So like I

constantly jump around. Usually there's

there's one main project that has my

focus and I have like some satellite

projects that also need attention but

where I can make maybe I spend 5 minutes

it does something for half an hour and

and and I try it and it doesn't need uh

so much capacity up there.

>> This almost sounds you know like two

things come to mind. One is there's

these like games where you have to

manage a kitchen with the employee and

and you see like the recipes or

something come out and you need to jump

and do it again.

>> It's like Starcraft, you know, you have

like your main base and you have like

your side bases. They give you

resources.

>> That as well. And also one thing that

just came to mind as you said like I go

there and I watch this and I make a

decision is when I see the chess grand

masters play multiple boards at once.

You see see sometimes they 20 boards and

they always all you they go there they

kind of you can see that they just like

see what's on that board. they make a

decision and for some boards they stop

for longer I guess better players or

better opponents. It feels, you know,

both they're occupying 100% of of their

brain. You're occupying your bay and

you're you're kind of scaling yourself

as long as you can context switch. The

difference the difference was up until

with with cloud code I you have to work

a little different because it is much

faster but then the output often doesn't

work on the first try. So like it makes

something but then it forgot to update

three other things. it crashes or you

give it

the good thing how to be effective with

coding agent is always like you have to

close the loop. It needs to be able to

debug and test itself. That's the big

secret. Um that's also something I I

think that's part of why it got so much

more effective. Um but yeah, with with

with clock code you I often had to go

back and like fix up the stuff

um or it just takes a lot of iterations.

So in the end it's not that much faster.

It's just more interactive.

And and these days with Cordex it just

almost always gets it right. My my

general strategy is always I I build a

feature of course you and and of course

you always let it write tests and you

make sure that it runs it.

>> It runs them. Yes.

So even even when I write a MAC app, I

don't know like I I just yesterday I

debuged this feature where

the MAC app couldn't find a a remote

gateway but like the the same code in

Typescript could but makeup is kind of

annoying to debug because like it builds

it you have to start it you have to look

at it you have to like say no this is

not working. So now I just said it like

you know you're going to build a CLI

just for debugging that invokes all the

same code path that you can call

yourself and then you just iterate and

you fix it yourself and then it will

just cook and it just cooked for an hour

and it was done and it told me like

there was a race condition here and here

and like a misconfiguration blah blah

blah and like yeah it sounds sensible. I

don't need to I don't need to see that

code. It's like but but you don't need

to see it because you set up the

validation loops and you trust that

because it ran it. I mean this is I

guess I guess it's not too dissimilar to

like sometimes when you work on a large

project in a large company when all the

tests pass I mean it doesn't mean 100%

it's there but it's it's a pretty good

and and all the new new code has test as

well you know someone thought about it

and tested it and and all that. So even

even on my on the very latest project we

always had bugs

but like anti-gravity has like a certain

a certain weirdness with how it takes

tool calls in the loop in the in the

format. So you have to do like some

filtering.

>> Yeah.

>> And that broke a bunch. And it actually

took me way too long to realize like

what am I doing here? I just need to

automate this. So I was just going to

codeex. like design life tests that spin

up a Docker container, install the whole

thing, spin up a loop, use my API keys

from this and this file

and then you tell the model to

read an image, create an image before

and then look into the image and see

what it sees. So I I don't not just tell

the loop, I still tell tool calling,

make it work

and then it solved itself. It took

forever, but it it it it tested all my

API keys like from from Entropic over

SEI over GLM like everything and it

fixed all those little indicies where

where sometimes the tool calling didn't

work or the ordering was wrong because I

closed the loop and and that's that's

>> and closing the loop you mean just have

a way to to have have the agent be able

to validate its work?

>> Yeah, that's why that's the whole reason

why why those models that we currently

have are so good at coding. But like

sometimes mediocre good at writing

creative because there's no easy way to

validate right but code I can compile I

can lint I can execute I can verify the

output if you design it the right way

you have a perfect loop like even now

even now for for websites I built the

core in a way that can be run via a CLI

so it's like I have this I have this

perfect uh execution loop because the

the browser loop is insanely slow you

want something that that loops fast. So

it sounds like one thing that is not

really changing from like before is we

had this before like backend or business

logic heavy he heavy thing could easily

be or more easily be verified that it's

correct.

>> Surprise actually using aentic coding

makes you a better coder because you

have to have to think harder about your

your your architecture so that it's

easier verifiable because verifying is

the way how to make things good. Well,

then remember back back even before AI

for complex systems like once you got

someone who built these things before

what they started with how do we make it

testable right like you you need to

design interfaces classes testable you

need to think about like am I going to

fake things will I use mocks will I use

end toend testing which will be long etc

but these are like really hard

architectural decisions and once you

make them they're I guess harder to

change in your in your word you know

like the model would cook a lot longer

if you asked it to make a massive

refactor acture and you know if you have

test it'll get it right but you know now

these we we still have these trade-offs

>> yeah it's still it's still software it's

it's I I would say I write better code

now that I don't write code myself

anymore and I wrote really good code but

but like even back at the company

sometimes testing was so tedious and you

come up with all those edge cases and

and and the branching

>> I mean outside of Ken Debbec who I

deeply respect and he was on the podcast

and we We we we talk like he he still

writes test first and he tells me that

he's not mad at me for not writing it

but if you want to write like you know

poor quality code it's on you. Uh but I

don't know many developers myself

included I never liked writing tests and

even even when I pretended that I did I

I just never did. It's a little bit like

writing documentation and writing tests

to me it was never a creative

expression. It is so good now like I I

would say for my last project I have

really good documentation and I didn't

write a single line myself like no I

don't write the test I don't write

documentation I explain the model the

trade-off so like why we did something

like this and then tell it like like

write that write the entrance section

beginner friendly and then add more

technical detail at the end and it is so

good I never had a project with that

good documentation just by every time I

design a feature this is a part of this

a part of the process And also like

testing I was like okay we built this

how are we going to test this? Yeah we

could do this and this and this. What if

we build it this way and oh yeah then we

can test it better. So it's like this is

now part of my singing because I I

always think like how do I close the

loop? How do I the model always needs to

be able to verify the work itself

um which automatically steers me to

better architecture. So why do you think

there's, you know, a bunch of like

experienced devs who are still pushing

quite a bit back on on just like the

idea that AI can do a lot of this?

>> That was a week ago. I I stumbled over a

a blog post by Nala Coco with love that

I deeply respect and learned a lot from.

And this blog post was just was a

dissing of the current way how models

work. And and what he did was he he

tested like five or six models including

some that make no sense like the the

Open EI 120 billion open- source one

that is not good enough to write good

code you know it's like and he just he

he wrote a prompt as far as I understand

it there was there was not a lot of

information on the website but to me it

sounded like he wrote a prompt he put it

on claude web and and he pressed send

and And then he took the output and ran

it and it didn't compile and he was

disappointed. But he's like, "Of course

it will not work. Do you think I can

write buck-free code on the first

attempt?" And those little those

models are ghosts of our collective

human knowledge. They work very similar

in many ways. Of course, you don't get

it right the first time. Like there will

be mistakes. That's why you have to

close the feedback loop. And also you

don't just send a prompt to the model,

you start a conversation. Hey, this is

what I want to build. It's like you he

complained that it used old API. Yeah,

you didn't specify the Mac OS version.

So it so so it made an assumption to

default to like old API because that

information was missing and it is it is

trained on a lot of data, not just the

last two years and there's just more old

data than new data. So this is like the

more you understand how those little

beasts think, the the better you get at

prompting. Um and then and then and then

he he spent maybe I don't know a day or

so on on playing with it and then just

decided that this technology is still

not really good. But to be effective you

have to spend significantly more time.

You know, it's it's like it's like you

know how to play guitar and I put you on

the piano and you tried a bit. It's

like, "Oh, this sucks. I go back to my

guitar." No. No. It's like it's it's a

different way of building. It's a

different way of thinking. You have no

idea how often I screamed at like 3:00

a.m. to cloud code because it did

something silly. I slowly started to

understand why those things do what they

do with like exactly the way I tell it

to do things. And sometimes you can

literally ask you can even even last

year like I for this project I the last

project like clotboard I feel like a

human merge button because the community

is like blowing off and all I do is like

reviewing PRs. I I I I have very little

time to actually write code myself

anymore.

>> And in the beginning it would often like

just cherrypick things and would close

the PR and I was like so annoyed. So was

I'm like why are you doing this? Yeah.

When you say this and this I interpret

this this and this. It was like ah like

I I learned the language of the machine

a little bit more. I tweaked my my

prompting and now I get exactly what I

want because it's it's a skill like any

other skill.

>> Yeah. And this is like Simon Wilson has

been saying the same thing even though

he's been using it for for years and I

think everyone I think once I start to

use it I also realize like I'm not I'm

okay at it but I I I I could do better.

What if we put this to a real test? cuz

I think it's fair to say that right now

you're building CloudBot which is a you

know it's not something that generates

revenue there's a lot of users and it's

blowing up and it's it's a really cool

tool but it's not PSPDF kit which is a

business that it's a lot of revenue is

hinging over it if today you know we

just wiped PSPF kit does not exist you

need to rebuild PSPDF kit you now have

these agents how differently would it

look how much would you trust it what

would you delegate what you would you

validate and and when you know you built

up a team around it because now it's a

profitable business at the very least

you need to hire sales people whatot how

do you think the team would look

different today with that same product

cuz you you know exactly what it took to

build it and you also know what these

tools can do today

>> I could easily run a company with

30% of the people it would probably be

quite difficult to find people

on that level but you you you want you

want to have really senior engineers

that really understand what they build

but that are also comfortable in in in

delegating and know which parts are

actually important to to work on and

which parts

I can vibe. That's still something I

don't see. I don't see a lot like like

especially in the AI world, there is so

much crap on Twitter, there's there's so

many people that are loud but clearly

have no clue what they're doing. There's

there's so many there's so many dumb

concepts around like I'm sorry, but the

Ralph Wigum one gh like this is again

another another silliness people use to

work around

uh model limitations of of of of Opus

that you don't even need when you use

Codex. There's there's maybe a few cases

where you have a really long list of

individual tasks that can be automated,

but that's usually not how software

building works. So there's these people

who I see so many people building up

this elaborated orchestration layers and

then you have like beats that

automatically creates tickets and then

your agent does tickets and then your

agent emails the other agent and then

you build up this this elaborate mess.

What for? Oh yeah, they did they design

the the spec for like a few hours and

then you just like the machine builds it

in the whole day. I don't I don't

believe this works. Like like this is

this is this is the waterfall model of

software building. This we learned long

ago that this doesn't work. Like

yes, people work differently and maybe

it does work for some. I just I just I

don't see how this

how this could work for me. Like I I

have to start

with an idea and often I purposefully

underprompt the agent so it would do

something

that would give me new ideas. You like

maybe like 80% of the things I assumed

were like crap but like there were like

two things like oh I didn't think about

that way.

>> Mhm.

>> And then I I I iterate and and and shape

the project and I have to I have to

click it. I have to like I have to feel

it. I feel I feel to make good software

I you know one thing those those things

often lack is taste. I have to feel like

how does this feature feel and and the

beauty now is that features are so easy

I can just like throw it away or like

reprompt it. My building model is

usually very much forward. It's very

rarely that I actually revert and have

to go back. It's just like okay no then

let's change this. No let's do this.

It's like it's like shaping. I I love

how this like you start with a rock and

then you like sisle away at it and like

pick different areas and and and then

slowly like this statue emerges out of

out of marble. That's that's how I see

that's how I see building something. I I

guess reflecting on how software engine

is changing. This seems like a change

because before before we had AI or any

of these agents, upfront planning did

make a difference. you know, writing at

PSPDF could you insisted I think to have

a proposal where people put a lot of

thought up front to specify and do all

because it was expensive to I guess to

to build to to do you think this is

changing because of the the cost of just

writing code is is going down or

>> I mean I still I still I still plan and

I but

>> you still do yes

>> but I don't put as much into it because

I it's now so much easier to just like

try and look at the results and then see

if oh yeah this this shape could work or

no we have to like the tweaking and even