Skip to content
Artisan Beer
Episode 6 81 min

Just Throw It Away

With Ed and Peter

Artwork for Just Throw It Away

Show notes

Why organizations never throw anything away, and why that matters now: subtraction neglect, Ed's "tell us what to throw away" consulting gig, and whether cheap inference will last. Peter shows off AirDash, an Airtable for agents on Cloudflare's SQLite databases. Ed spends Scalpels launch week rebuilding a fifteen-year-old CRM for a client: triaging requirements written from past pains, benchmarking against an SES simulator, tombstoning dead code, and replacing the reporting dashboard with a Claude plugin. Then marketing: Peter automated before selling, Ed's stories are his marketing, and what's left for indie founders when building and maintaining software are both fixable. Plus "my agent did it" is no excuse, and rivers that can sue.

Full transcript

Automatically transcribed, lightly corrected for product names, and otherwise left exactly as it was said.

Ed 00:01

Good morning.

Peter 00:02

Good morning, good morning.

Ed 00:04

Mm, Riverside has changed its UI again. Now I have your face full screen instead of us side by side like we normally do.

Peter 00:12

weirdos. Um yeah, what's what's going on in your in your life, Ed? we should start with that 'cause that's always interesting.

Ed 00:18

in life it's

yeah, it it's finally really truly feeling like autumn here, which is nice. Uh like it's a little cold in the morning, but um unlike most, you know, October, November since we've we've gotten here, um, it hasn't been really rainy. So it's been cool, a little bit of rain, but we've been able to actually enjoy the outside, you know, a lot more. I think last year,

Peter 00:42

Yeah.

Ed 00:43

you know, once once the heat wave broke, it just rained for two months straight.

And so it's like, well we're not hot anymore, but we can't really do anything. so this has been great.

Peter 00:48

that's that's bad. Um

Madrid's Madrid Madrid Madrid's cold. It's it was I think it was four degrees Celsius yesterday in the morning. That that is chilly, right? Um but it's always Madrid's always sunny. Like it's a dry climate, it's always sunny, it's close to the Sahara. Um which is nice. So the winters are really nice. It's it's just cold and s crisp and sunny, which is really

Ed 01:15

Hmm.

Peter 01:16

nice.

Ed 01:16

Yeah.

Peter 01:18

Yeah.

Ed 01:19

Yeah, there's one part of Spain I haven't visited yet. One of these days I'll get there.

Peter 01:23

Well, you know, you know somebody, so uh

Ed 01:25

I do, yes. Um,

so how's work?

Peter 01:30

You know, work is um good. The consulting is obviously uh every company's figuring out how to be AI first and agent first and all that kind of stuff. So so that is I I think you I think you know you do more like technical work and consulting, helping companies figure out how to how to um live in that world and I do more kind of like um UX and organizational

level cons or style consulting

Ed 02:02

Mm-hmm.

Peter 02:03

but everybody's trying to figure shit out and I like companies that that so so the one thing I I re I I observed in in I have a big consulting job now. The one thing I observed is um they're actually pretty successful. They have just been doing shit for the last 18 months or so

Which is I think the right way. You just do a bunch of shit and every team and every, you know, sub organization, etc. These are tens of thousands of people, right? They're all just doing stuff. And then obviously it's very messy, but also they're doing stuff and they're learning stuff and they're figuring stuff out. So it's a very messy pile of stuff that is being figured out though. Um and then I guess

Ed 02:49

Yeah.

Peter 02:50

next year it gets a little more organized.

Ed 02:53

Yeah, I mean I I think that's a a fine approach. I think what I'm running into a lot is um that the companies aren't necessarily doing like the the quick like we're gonna try and experiment, see if it works, if it doesn't throw it away. They'll they'll start

Peter 03:08

Yeah.

Ed 03:09

something and then they'll feel like, well, now I'm all in with this thing, whether this thing is working or not. And they're not

Peter 03:15

Yep.

Ed 03:15

actually doing a great job of measuring whether or not this thing is working. So I

Peter 03:19

Yep, yep.

Ed 03:20

run into a lot of like

Yeah, okay. So we experimented with this this process, you know, this this set of Ralph loops or whatever it is back in like October of last year. Like that's where we were at that point. We've moved way beyond um, you know, what you're doing now. But because you decided to go all in on what the the current hype was at the moment that the current hype was happening, you're not able

Peter 03:43

Uh-huh.

Ed 03:44

to, you know, keep experimenting and iterating. So you kind of have to if you're going to be the sort of organization that just tries things.

You have to keep a loose grasp on everything that you're doing and continue to build on the things that work and feel good about throwing away the things that don't.

Peter 04:02

Yeah, yeah, yeah. Th it's funny because I wrote a whole long blog post about this a few weeks ago. Um, and I did a bunch of res well, you know, with my buddy Claude. We did a bunch of research and there's so d there's a ton of research on this. Like why don't companies throw stuff away? Right? And it's it's it has a lot of cool names like subtraction neglect, like nobody spends the time to like delete things or

or um planned abandonment or Conway's Law or structural inertia. You know, like there there's a lot of research on this. And now is the time to pay attention to that. Because p yeah.

Ed 04:47

Yeah, it's fun because I I do have this one

I have one little consulting gig where basically my my remit is tell us what to throw away. Like we've done this nine months worth of AI onboarding and we're spending a ton

Peter 04:59

Yep.

Ed 05:00

of money and you know some things feel like they're working, some things feel like they're not. We don't know how to measure it and um but they just recognize that, you know, I I actually it became sort of a

It it wasn't like they had this like nuanced view of it, like we should harvest what's working and throw away what's not. It came down to the C suite battling, like half the sweet C suite just wants to throw away AI altogether. The other side of the C suite wants to, you know, really go more all in. And so they pulled me in to kind of uh kind of stop the f the fighting. And so I was like,

Peter 05:29

I see. So

Ed 05:31

look, you're both right. You know, there's some stuff you're

Peter 05:33

Yeah, yeah, yeah, yeah.

Ed 05:34

using I AI for that definitely should not be, or at least not in, you know, in the way you're using it. And there's something that,

Peter 05:39

Yeah.

Ed 05:39

you know.

Really is genuinely working. So let's identify what's working and discard the rest. And I they bought in really quickly to to that idea. So, ah

Peter 05:49

I like

it that so so the playbook is try a lot of things but then get good at drawing stuff out.

Ed 05:54

Mm-hmm. Yeah.

Peter 05:56

And like that you start building up the thing.

Ed 05:59

Well, and what's tricky is you'll have like you'll have somebody do something and it's really successful and they try to get everybody else on their team to do it, and most of the other people on the team aren't really that successful. But then it's like

Peter 06:10

Yeah.

Ed 06:11

this is John's thing, and John is really successful with it, so we have to adopt John's thing. And so nobody wants to be the one to say, No, at least for me, I need to throw away John's thing and find my thing.

Peter 06:20

Yeah. Yeah.

Yeah, interesting. So so now we are both in change management consulting.

Ed 06:28

Yeah. Well, and that one's

unfortunately that one's just a really, really part-time short term thing. They're kind of tinkering with it. I'm enjoying it, so I hope that I can turn it into a, you know, a bigger engagement. Um there's some

Peter 06:38

Mm. Yeah, yeah, yeah, yeah.

Ed 06:40

big personalities. It's it's fun to get in there and, you know, they're not afraid to raise their voices and really, you know, it's the kind of place I like to work where it's like we're really passionate about what we're doing. We have strong opinions, we're gonna make those opinions known. Um yeah.

Peter 06:53

It it it's funny

how a little bit of common sense and just down to earthness and just you know but but I feel like you need that plus you need to be optimistic about AI though, because if you if you're like down to earth and up and common sense but you're like you have like a r like a weird resistance, like AI sucks, then then that's just not you know, it just doesn't work.

Ed 07:19

Yeah, well I mean

I think there's it certainly makes sense to have a healthy skepticism. I mean, I I still have my worries, especially, you know, you start reading even the news this week about um, you know, infrastructure deals falling through. You gotta wonder, like, is the capacity build out going to work out well enough that

Peter 07:36

That's just news.

Like what are you gonna do with the news? Like it's just like anthropic I don't know, who cares?

Ed 07:39

Well, no, I know, but you just you know, we we do what we

do uh under the assumption that intelligence is going to get better and cheaper. And I think that, you know, the the

Peter 07:49

Do you not think that's the case?

Ed 07:51

I think that's been the trend, but I think that a lot of the cheaper is just subsidies and, you know, these these major labs really in a they're just in a land grab trying to get as many users as they can get. I don't think that the prices we're paying now come even close to reflecting the actual cost of

The inference plus the infrastructure plus the research and development, all of the costs that go into it. I think that the real cost of this stuff

Peter 08:13

Yeah.

Ed 08:14

is way higher than what we're paying. And I I don't know. And so my skepticism is all around like we we think that, you know, maybe maybe in 10 years we can feel really good about, you know, saying that intelligence is going to be extremely good and extremely cheap because we will have solved all these things. But I think we're in for like this painful cycle where the um

You know, somebody's gonna have to start paying the costs. I mean, the the venture capital money is driving dry drying up to some extent. Um, SpaceX's IPO was fun, but it you know it showed really quickly that the valuation was not correct. I sup I suspect that the anthropic IPO is gonna be kind of the same thing. Like there's gonna be a lot of people who are gonna, you know, take take advantage of liquidity and run. And so

Peter 09:00

Mm-hmm.

Ed 09:00

we'll find out what anthropic is really worth in today's market, which is not gonna be anything close to what.

you know, they're they're trying to pitch it at now. And so as this money starts to flee, then we have to start thinking about like inference is a commodity and we have to be able to sell this commodity at a price where we can pay our bills. I mean, because ultimately, as much fun as it is to be in this wild and crazy, you know, R and D at all costs environment, um, you know, there's nobody out there who's just gonna

Peter 09:27

Yeah, I'll

Ed 09:28

pay the bill to do that just for the sake of paying the bill to do that.

Peter 09:30

I'll push back on you though. I d like I d for j just for me, so one thing is like I don't try to understand the market and the world economy because I'm like, figure it out, guys. Like you know, I can have opinions and it's fun, but but I have zero control and and I'm you know, whatever. And then and then on on the inference side, people do today sell

Really good open source model inference. They

Ed 09:59

yeah.

Peter 10:00

they have none of the costs. And so so the level at which the intelligence is today is effectively cheap. Even if you take out all the you know what I mean? Like so so

Ed 10:10

Yeah. If you if you discard

Opus five five and you it just say, look, I'm just gonna use Deep Seek or whatever and you know, what work I do with Deep Seek, that's fine. The problem is that a lot of the organizations, at least the ones that I've encountered, they get very vendor locked. Like my entire workflow is in Grokbot, for instance. And now Grokbot all

Peter 10:27

Yeah. I I am

Ed 10:29

of sudden has has uh changed the pricing or reduced their the amount of usages you get at whatever tier and now it's like, crap.

Peter 10:36

Yeah, I don't trust that

I don't trust that dude, so um but but

Ed 10:39

No, no, no, but but

that's that's my whole point. It it doesn't really matter which of these vendors you choose, you get completely vendor locked so that your whole process is completely reliant on, you know, this particular inference provider.

Peter 10:49

I don't think so. Like like

I am full on full in on Claude. I am like I don't care. I don't wanna experiment with, you know, the next Codex and the next because I don't have time for that. So I'm like, fine. If Codex does something cool, I'll just wait six weeks and then Claude does it as well, right? So so that's fine. I know they're subsidizing me heavily. I don't think the

Ed 11:09

Right.

Peter 11:11

subsidizing is gonna end by January. It'll it'll last you know, whatever it lasts.

Ed 11:15

Well, also it doesn't matter

as much for you, right? Because you have the technical background that if all of a sudden if

Peter 11:21

Yeah, true.

Ed 11:22

if all of a sudden Cloud were to ten X their pricing and all of your workflows

Peter 11:26

I'll just switch.

Ed 11:27

are suddenly unaffordable, you can switch. You know how to do that. Where

Peter 11:29

Yeah. Yeah.

Ed 11:30

you know the problem is when you have an organization of a hundred people and they're all in on some particular product and they are maxing out their spend, you know, we we're spending every dime of our AI budget. Now all of a sudden the prices go up ten X.

Now you can only do one tenth of the work and you have to pivot immediately. Or you have to figure out how to

Peter 11:47

That is fair enough. So so

so switching for a larger orc is is tricky. A

Ed 11:52

Yeah.

Peter 11:53

as an indie individual, it's fine. I don't worry about it, yeah.

Ed 11:55

Right. Yeah. No, I don't worry I

I don't worry at all for me, for my purposes. Um, and I do a lot of experimenting and l a lot of the work that I do is on on open models just because um, you know, when my clients reach out and say, you know, we're spending too much here, I can say, Well, you know, there's this open model that does the same sort of work for me here. Let's try that and see if it's gonna work for you. Um, you know. So I don't know, it's

Peter 12:15

Yeah, yeah, yeah, yeah, yeah. All

right.

Ed 12:18

It's

itch but yeah, I'm I'm generally AI optimistic, but I I'm skeptical about the I don't think that the industry as a whole is being run by the best and brightest. I think it's being run by um ah I mean, not to say that the engineers

Peter 12:31

You know

Ed 12:32

that are behind this stuff aren't brilliant, but I think that the the business minds are not um they they don't they've not ever been forced to operate in

Peter 12:39

Let me just say it's better than crypto.

Ed 12:42

it is better than crypto, but they've the people who well, uh there's some overlap. I mean,

Peter 12:45

That's good enough for me.

Ed 12:46

Sam Altman is a crypto guy.

Peter 12:49

I you know, whatever. But like but like the whole thing is better than crypto. So so I just like

Ed 12:54

Yeah.

Peter 12:54

I don't worry about the industry 'cause 'cause yeah, they'll have their crashes and then things will happen, but is that gonna affect me directly? No. So who cares?

Ed 13:03

It

might. I mean, it won't necessarily affect you directly in a detrimental way, but you know, it depending on who your clients are, it could affect them. Um but I mean, my my

Peter 13:10

Yeah.

Ed 13:11

whole skepticism around it is that the people who are running the industry have never had roles where they've actually had to care whether or not the product they're selling is making enough money to cover their costs. They've always been in roles where it's somebody else's money that we're spending on the in the hope that this thing is gonna blow up and become super, you know, super valuable and then that exit

Peter 13:29

Yeah. Yeah.

Ed 13:31

liquidity is what

So they're just playing that game and that's the only game they've ever known. And they've never had to operate in a world where, you know, if you you know, if it takes you ten dollars to get this chunk of metal out of the ground, you have to sell it for twelve dollars because if you sell it for eight dollars, you're going out of business.

Peter 13:45

Yeah, yeah, yeah. No, that that is actually a fair criticism. Like it's all funny money to them, right? Hmm. Yeah. Yeah. Can I tell you

Ed 13:51

Yeah. Yeah, but it's it's not to us. But anyway.

Peter 13:55

about about about a a product I built last week? I think it was last week.

Ed 13:59

Oh yeah, yeah, you did give me a C preview. The I I wanna I wanna hear more about where it's gone.

Peter 14:05

I did, I did. So so um I'll tell you the backstory. So so during the before and during the pandemic, um sorry to mention the pandemic, air table was kind of like becoming this thing, right? It was very cool. Now, I think today, didn't they ju weren't they just like sold for scraps? I think they were. I think I think the what Yes.

Ed 14:26

Um, I I don't know. Well are they are they a bending spoon now?

Peter 14:32

Anyway, but so Air Table was cool and it's still cool. And and and at that time I was I was running like a like uh five hundred people organization and so we did a lot of stuff in Airtable because none of the other systems could do it. And it was extremely useful. Uh and so during the pandemic I I was just like always brainstorming like how can I make um a better air table? 'Cause there's stuff it just couldn't do, right? And but you know, but I couldn't figure out a way to compete.

Fine. So a few years pass. Now we now, you know, they're sold to bending spoons. Um we have agents. And you know, this is still s this idea is still circulating in in my head. So I built I built this um simple tool. It's called Air Dash. And and the reason is so you have an air table. The big it and the big advantage of air table it's

It was in in kind of like the the no-code category, but now let's throw that out and let's call it the agent category, right? Like you can just build databases, but it's very user-friendly. Um fine. And then at the same time, Cloudflare is building building all these really useful primitives. They're just they're just primitive crazy. Like they're all like and a lot of startups, when I look at them, like, you just you're just like a layer on top of a Cloudflare primitive.

You know, like the way Amazon when they came out with um buckets, everybody was like, great, now we have buckets, right? So they have a lot of stuff. So one thing they have is they have um SQL light databases in the

Ed 16:10

Mm-hmm.

Peter 16:11

in their cloud on workers. They're extremely cheap. So for five bucks a month, you can create a million SQL light databases. They have certain limits on size and stuff, but they're very generous. Um

When they are not being accessed, they don't charge you anything. Uh and and within that five bucks, you can basically query and write to these databases fairly generously. So it's five bucks for a million databases, right? Great. So I'm like, hmm, okay, that's interesting. So I threw those th two things together. I made Air Dash. Um it's basically your agent can create databases.

As many and however it wants. And the true and the the the trick of the philosophy is your agent can read from the databases with SQL, which is good at, but we don't let it write to the databases through SQL. We abstract the writing into like there's like an MCP layer. So you have all the field types and all the things, right? So you you can create a relationship and a table and a this and a that. But

Abstracting it lets me add kind of value on top of that. So if I if I create now I have a field type called you know it it's it's kind it's like SQL, but I can layer value on top of that so that um the agent creates these things, these databases, and me as a human, I get a really nice little air table like UI where I can do air table like things.

Like I can drag in a picture or I can do whatever I want. Um

And so that's it. And and my agent and I just tell my agents, hey, I have a lot of agents running um doing background tasks in cloud, just like

Ed 18:12

Mm-hmm.

Peter 18:12

scheduled stuff. And I'm just like keep track of that in an airtight database. And they just do it. And they're very good, like it just it's a natural fit. That's it. It it's

Ed 18:22

Right. Yeah.

Peter 18:26

very simple. But it works really, really well.

Really well. It's it's I'm surprised

Ed 18:33

Yeah.

Peter 18:33

how well it works.

Ed 18:35

Yeah. Um I can I can think of a bunch of different use cases. As you were talking, I was thinking about, you know, ten different ways that I could integrate this into things that I do. Um

Peter 18:44

Get you signed up.

Ed 18:45

it's funny because I my one of the frustrating things that I have going on is that I've been working the same way for so long. I think uh I've I've explained on here before that

The for the last several months, the the way that I've worked is everything is b being done. I d don't do any inference at all on my on my laptop. There's no AI anything on my laptop. Um

Peter 19:04

Yeah.

Ed 19:04

anytime I need anything AI related now, I do it on my uh Mac Mini, which doesn't have a monitor. I just use a remote desktop and and log in. Um and that just became sort of extra friction-y. Like there there was just that extra step and the screen resolution wasn't as nice and so it just never felt

great, but it was really, really effective because I could kick off work, shut the laptop, leave, know the work was getting done. Uh because as a Mac that's running everything and I'm using solo, I could use cron jobs, I could schedule things. Like I was able to set up this whole system that worked really, really well for me. The problem was that I started doing some um building some iOS apps. And

Peter 19:43

Right.

Ed 19:44

then all of a sudden the the resources on that Mac started to really bog down. So I had to come up with some other way to

to work and that would that meant, you know, I I experim experimented some with amp orbs. Um and

Peter 19:56

Yeah, I've heard of them.

Ed 19:58

yeah. And and just some other, you know, ways of kind of getting some of the some of that compute. Yeah.

Peter 20:02

I'm I'm a late adopter on those things. I I let people

figure it out and then like in a few months I'll be like fine.

Ed 20:08

Yeah, so so anyway that your your air table replacement, what was the name again, remind me? Uh AirDash, right.

Peter 20:14

Air Dash, not live yet, but when it is, I'll I'll promote it.

Ed 20:18

Yeah, so I um right now everything like all of my work is recorded into Markdown files on my Mac mini, which is great, except that now if I have to do any work uh out in the cloud, it has to reach back to my Mac mini to get the notes and and all of that stuff.

And so I've been

Peter 20:36

Mm-hmm.

Ed 20:36

trying to figure out, you know, basically this is it's really just append-only logs, right? It's just like a history of everything that happens. And then I do like scheduled roll-ups where it'll go through and it'll harvest the things that are actually like make sense to keep in uh, you know, best practices, standing orders, things like that. Um, but it's just a log of basically everything that happens. So I'm thinking maybe this could be a solution where I could have that, you know, all of that stuff just being pushed up into a database in the sky versus markdown on my Mac mini.

Peter 21:06

Database in the sky is good. Like like the the way I set it up was first of all it's MCP, so you just authenticate once. And then you don't need keys or tokens or anything like that. Uh whatever. It just it's just it can connect connect. And the other advantage I think is it's it's SQL Lite. So if you kinda like, you know, if you just want to download it, you can just download the database. If you want. And then the and then

Ed 21:33

Right. Yeah, I've I've always liked the portability

of SQLite. I just that that feels really good to me. I had a you know, I've I've done

Peter 21:38

Yeah, me too. Me too. It feels very safe. You can just download it.

Ed 21:43

Yeah, so I've I've created products that are like an environment per tenant SaaS type thing. So like you as a as

Peter 21:48

Yeah.

Ed 21:49

a user, you get your own environment. And when I build those, I like to make those SQLite databases because then the your exit strategy when it's time for you to go is you can just download your database and delete your account and everything

Peter 21:59

Downloaded the database.

Ed 22:00

is right there.

I don't have to have some fancy export system or anything like that. It's like your database is a file, download it and then you can walk away.

Peter 22:07

Yeah, yeah,

yeah, yeah. It it's so fun though. Like I I don't know if this is gonna be an actual product, but but so one little let one little wrinkle in there is so because we define our field types ourselves and we can make them interesting, there's one table inside the SQL database that just lists out what all these tables are. So so your metadata about

your database also lives in a database.

You see what I'm saying? So

Ed 22:40

Yeah.

Peter 22:41

it says like, this is a relationship type table. So don't show it to the user because we show that differently in the air table view.

Ed 22:51

Yeah, I mean it's nothing wrong that. It's it's kinda cool. I'm I'm definitely gonna play with it once I get my head above water. I'm drowning.

Peter 22:59

Yeah, tell me tell

me about um scalpels and the and the drowning and you know.

Ed 23:04

Yeah, so uh marketing scalpels the week of launch has basically been not nothing. I've done nothing scalpels-wise as far as marketing, because I had a client reach

Peter 23:13

Yeah.

Ed 23:13

out. Uh they've been fighting a battle now for a very long time. So the backstory is that about fifteen years ago, they started building and using a uh just a homegrown CRM. And this thing

Peter 23:29

Uh-huh.

Ed 23:29

powers their business. Like they absolutely would if this thing were to

Go away, they would go away. It's like the absolute beating heart of their business.

Peter 23:37

And it's millions of customers and stuff? Okay.

Ed 23:40

yeah, yeah, yeah. I mean ridiculous

numbers of customers. Anyway, um they have through just growing their their primary operation and acquiring other companies and things like that. And they're just they have simply outgrown this system. And they have spent the last couple of years like throwing extra resources at it. Can we put it on more compute? Can we run two instances of it? But of course that those businesses need to to communicate with a single database, and that becomes this kind of point of failure.

And they've just they they decided a few months ago they've pushed it as far as they can and they've then they've been trying to create a replacement for it.

Peter 24:16

Or she can't vibe it.

Ed 24:17

And so well they did. They they tried.

And um so they put in a bunch of work. And you know, the the

Peter 24:24

Uh-huh.

Ed 24:24

developer they have on the job is really he's a really young, talented kid. Um but you know, he just has not been in the trenches for for long enough to recognize some of the the boo boos that that uh they encountered.

Peter 24:34

Yeah, yeah, yeah.

Ed 24:36

So he he put in all this work and then he started to uh benchmark it against the you know, because they

The basically it was like we can send this many messages in a day. We need to be able to send this many messages in a day. Um and so that was like the primary requirement was they have to be able to increase their throughput by a certain amount. And

Peter 24:55

Okay.

Ed 24:55

so he did all this work, and then when he benchmarked it, he it was the same as the old system. So it's a brand new one that's only capable of sending what the old system could send. And so

Peter 25:05

That is weird

though, because you would expect it to be twenty x better just by being new.

Ed 25:10

Well, you would expect it to be

20x better. But okay, so here's how they got to where they got. They spent a lot of time writing up requirements. And as they're writing up their requirements, of course, when you have a 15-year-old system, you've had several days that sucked, right? The the the catastrophic failure days. So they went back through all of their records from everything that went wrong for them, and they put in the requirements document that it needs to guard against whatever the failure happened to be on that day.

And so there are these

Peter 25:37

I see.

Ed 25:38

hundreds of requirements that are you have to guard against this specific failure. The problem

Peter 25:42

I see.

Ed 25:43

is that AI isn't going to understand the context of that. It's going to say, I need to guard against this specific failure. So that means I have to write code that will guard against this specific failure. So now there's all this extra logic and all

Peter 25:52

So it just wildly over engineered it. Yeah, yeah.

Ed 25:56

these extra queries that are guarding against things that happened one day back in 2007 and would never happen again in the real world. But now you have

Peter 26:03

And you could just

guard against with like just one tiny little thing maybe always.

Ed 26:07

You know, you could just guard against it by not intentionally introducing it. I a lot of the things you just you would actually have to go out of your way. In, you know, in modern PHP. I mean, this thing doesn't have composer. It so, you know, some of the things were like, we have to patch in place because we can't composer update and, you know, things like that. So it became it it really went on the radar during the PHP apocalypse when that was one of the systems that, you know, obviously had to stay online. It could not go down. And

Peter 26:33

But the

old one was still online, right?

Ed 26:35

The old one was still online. Um, but when when it had to be patched, it wasn't a straight

Peter 26:38

But they hadn't switched or they or they had switched.

Ed 26:41

it wasn't a straightforward patch. It it took a lot of work to get a patch, but it you know, they had to do that work. Like, if this is gonna keep going, if this is keep happening, we can't keep doing this. Yeah, they haven't they haven't even tried to launch the new system. They just basically they brought they they spent all this time building it and they they brought it online and they benchmarked it like, okay, so we can achieve about the same as what the other one could achieve. We have not actually gained anything through any of this work. So um

I I said, look, just I'll just sell you a week, right? And I will spend a week and I will get this fixed for you. And uh

Peter 27:13

Are you gonna fix the new system or the old system? You're gonna build a a a a new ver yeah, you throw one away, right? You try it, you throw it away.

Ed 27:15

neither. Uh I it's I started I started from scratch. So I took

their I took the requirements document and then I I had it um I basically analyzed the the the new build as a reference to see if there were any requirements introduced there that weren't in all these requirements documents. And I spent two and a half days just going through every single requirement point by point.

Peter 27:41

Uh-huh.

Ed 27:41

and saying,

okay, this isn't a concern. Let's get this out of the documentation. You know, I want to handle this this way. Um, day one, I threw up a quick and dirty proof of concept just to see, can I get the throughput that that we need uh with just PHP, or do I have to resort to Rust or something like that?

Peter 28:00

Yeah, yeah, yeah. That is that's funny by the

Ed 28:02

So anyway, uh yeah, now the

Peter 28:04

way.

Ed 28:04

so the build started last night overnight and it's it's starting in layers. And the way that I'm doing it, because I understand that, you know, with like with any requirements document, there's, you know, a a small handful of must-haves that absolutely are cannot be compromised on, and uh a whole lot of important stuff that really, really should be the way it is, and then a big bucket of this is you know something we thought of on the way to the bathroom.

Peter 28:29

A a big

bucket of something something that somebody said in the meeting at some point.

Ed 28:33

Right. Yeah, yeah.

Peter 28:34

And everybody you just wanted to go to lunch.

Ed 28:36

Mm-hmm. So basically I've I've managed to prioritize these requirements and I'm building it so that the the must-haves are are laid in first and I'm building up on top from there. And

Peter 28:46

Yeah. Yeah. Yeah.

Ed 28:49

I'm constantly I have it constantly running so that I can I can determine whether or not it's actually meeting that primary objective, which is it has to be able to maintain this throughput. I'm actually benchmarking it like 5x.

the the documented requirement throughput so that they have plenty of room to grow. Um

Peter 29:07

Yeah. Yeah.

Ed 29:10

it's also architected in a way that if I had to swap out the Sandy module for Rust or Go or something, I could do that. So like there is additional headroom to be had even beyond the benchmarking, but just with the PHP, I have this continuous

Peter 29:18

Good. Uh huh.

Ed 29:21

benchmarking. And in order to do that, I had to build, and this is why like it sucks that I haven't done anything for scalpels this week, but

Scalpels will really benefit from

Peter 29:30

But it's fine, uh-huh.

Ed 29:31

this because one of the things that I had to build in order to be able to load test this thing constantly, and it's just a continuous run that's happening all the time. You can't hit SES. I mean, you could hit SES with sandbox emails, you know, at like 100 per second all day long every day, but you pay for those messages as if they're real messages. So

That gets to be really expensive. I mean, you're spending 10, 12 bucks an hour to load test something that is, you know, a week from being in production. Um, you know, some companies wouldn't care. This is not, I mean, they're they're a decent sized company, but they're not like unlimitedly deep unlimited deep pockets. They're, you know, they want to make sure the money's being spent well. So I yeah,

Peter 30:11

Yeah. Yeah, yeah, they're not anthropic. Uh-huh.

Ed 30:15

so uh I threw together an SES simulator that

Peter 30:21

nice.

Ed 30:22

that I have just it's just sitting there and it's just receiving all of these these uh requests.

Peter 30:27

I have a question.

So so is there something in the simulator that takes a certain amount of time to respond or something? Or does it just re s like how what is the

Ed 30:35

It well, so we it naturally

will have about the same latency as SES does, uh, but I do have

Peter 30:40

Okay.

Ed 30:41

dials on it which I can turn where I can say, okay, let's uh let's pretend that SES has a failure rate of 1%, or let's double the latency, you know, things like that. So I can experiment

Peter 30:52

Right. Nice.

Ed 30:54

with it under these suboptimal conditions because I know that that's

Peter 30:57

Nice.

Ed 30:58

um, you know, being able to benchmark this thing against

as you know, against a simulated SES under optimal conditions is important because we definitely want to make sure that we can hit our our target number under optimal conditions. But how far

Peter 31:09

I get it.

Ed 31:10

can we keep pushing when there's, you know, degraded service?

Peter 31:14

So so you built you stopped S S E S basically. You built like you know, the way you stop an API when it's not finished yet, right? Yeah. Cool. You see you see that's

Ed 31:20

Yeah. Yeah. Uh

Peter 31:23

where they're that's where the senior people know what they're doing.

Ed 31:27

Yeah. Yeah. Well and and again, it's like I'm benchmarking before I even start writing any code so that I know every

Peter 31:32

Of course.

Ed 31:33

time I every time I merge code in, am I

Peter 31:35

You just

Ed 31:36

still meeting this requirement? Whereas, you know, the the way that an anybody who is more junior or a non-technical person would would approach this would be I'm gonna build and then I'm gonna test it and if it works. And by then,

Peter 31:46

Yeah, yeah.

Ed 31:47

all of the decisions that you've made that are slowing things down or keep you from reaching those benchmarks, those are already so baked into the system is really hard to pull them out.

And that's why it's like I'm gonna just add one requirement at a time, layer it on, and I'm just gonna watch these metrics. And when they start to dip, I'm gonna say, okay, wait, wait, Cloud, let's let's go back and let's revisit this thing that we just layered on

Peter 32:05

Yep.

Ed 32:06

because we just lost five percent of our throughput when we did this. And that's fine, right? I I have plenty of headroom, but I wanna make sure that every hit I take in that throughput comes with real value.

Peter 32:17

Yeah, it's not a stupid hit. Like and and 'cause I wonder about that. Like when I was just this morning I was doing the the relationship field type for for Dashlane, which is just me chatting with Claude for like ten minutes, right? But I was gonna do it the wrong way. I'm like, no, no, no, hang on. And I was like, yeah, right. And then it just obviously nailed it. So so so are you doing a lot of like

architecture type stuff in there as well or is it mostly just getting the requirements and the loop of verification right

Ed 32:49

Yeah, so it was um it was requirements

and then it was a few hours of let's break this down into buckets that will put these high priority um requirements early in the build and so kind

Peter 33:03

Yeah.

Ed 33:04

of categorize the you know things by priority, you know, build the high priority things early to the extent that you I mean obviously there are some like this requires this requires this whenever you're building software, but basically created like a sensible overall thirty thousand foot view build plan. Um

And then as I uh as I get to each one of those buckets, then I have this really deep conversation about the architecture of whatever modules are involved.

Peter 33:28

Right, exactly.

So that so then you dig into like, wait, let's build this little piece like this and let's talk about that.

Ed 33:33

Right. Well, so then no, I've kicked off bucket

one. Bucket one is building, and so I'm having that deep conversation about architecture with bucket two. And then, you know, obviously there are some decisions that are now currently being built in bucket one that are kind of locked. Like we made these decisions. Um, and so we have to live with these decisions. like I don't want to

Peter 33:52

Yeah.

Ed 33:52

make big changes to, you know, things I've I've done about again, unless it's extremely well justified.

Peter 33:56

Yeah, 'cause 'cause then AI is gonna mess it up. Uh huh.

Ed 34:01

But yeah, so this is like, can I take something that was built over fifteen years and replace it in a week with just me, Claude and and uh, you know, my

Peter 34:12

But but

this is this is such a good case st study because this sh like to me it's like it's it's you know, like I think the juniors will be will be gr great and much smarter than us. But but you have to be like senior to be able to do this because you've been around you know you know, you've seen all the things and then it's just and then it's like you have an army of

you know, a hundred really good engineers at your disposal, so you're like a lead architect or something. And it's so

Ed 34:47

Right, but it really

Peter 34:48

fast that you don't get stuck in writing document I don't know, it just works.

Ed 34:52

I I think it really just comes down to just years of experience and years of and I think

Peter 34:57

Yeah.

Ed 34:57

they'll get it. I don't think that it matters that they're not actually writing code anymore. This is and this project has really taught me that it's not about years of experience writing code. It's about recognizing like for for this project, the biggest problem with the way this project was initially executed was that they had all these requirements that were meant to guard against something that could actually never really happen in real life. That what they're doing is they're writing

Peter 35:19

Yeah, yeah.

Ed 35:20

requirements from a list of

past pains. And that's fine. Those things should go in the requirements document. But the person who turns those requirements into a buildable spec has to have that instinct to say, is this something that we could actually run into that we do need to specifically guard against? Or is this just something that bit them in the past and we need to make sure that we're not going to hit it in in the future? So do we write code for this or not?

Peter 35:42

Yeah, or is this something that

that that was caused by just crafty shit in in the code base and the architecture that our new architecture is just is just solves by being a new architecture.

Ed 35:59

Yeah, it's solved by being new architecture. It's also solved by, you know, a lot of it comes down to we won't get ourselves into these weird situations. Like there was there was one case several years ago where something got stuck in an infinite loop because it was something that got it was just in the wrong level of a for each loop, right? And so you end up

Peter 36:15

Yeah, yeah.

Ed 36:16

in this like infinite looping situation. Now, this thing has never had a good test suite, it's never had a static analysis on it. There are a lot of things that it doesn't have that

Peter 36:24

Yeah.

Ed 36:25

we do have that will like we we could not.

even possibly get into this loop condition because PHP stand would call that out. Like, you know, our stack analysis would say you have a you have an infinite loop here. You can't, you can't push this code. So it's like, you

Peter 36:40

Uh-huh.

Ed 36:41

know, we so we don't have to guard against. And there was this weird thing in that in the code that was generated trying to solve for this loop condition that was like checking every time before it would perform some operation, looking back to see if that operation had happened too recently, which would indicate that it's in a loop.

Peter 36:57

that's so claudy. Yeah, that's no good. That's terrible. That's like the worst it yeah.

Ed 36:59

Yeah, and I'm just like, yeah, well that and that's just it. So that's why when your your instincts goes, well, this should like twenty times faster

off the you know, just right out of the out of the gate. It's well, it would have been if that requirement hadn't been in there. Uh it

Peter 37:11

Yeah.

Ed 37:11

wouldn't be doing all this extra checking. So but yeah, I think that's the that's the value

Peter 37:13

Yeah, yeah, gotcha. Cool, cool. Uhhuh.

Ed 37:16

that the senior engineers really bring to the table. And so it's it's been kind of fun to take on something like this where like I'm I'm digging through like fifteen years of history and code and logs and pain.

and trying to figure out like what is the actual genesis of this requirement? Was is this something that is real? Is this something that we could, you know, should actually guard against, or is it, you know

Peter 37:38

Yeah. I'm t I'm

thinking about one of my clients now and any any client that's been around for fifteen years will have the same thing. Like there's so many quote unquote requirements. But a requirement often is just something somebody said in the meeting, they built it. Turns out it was never used by anybody. Or it was it or they tr tried to do something that just didn't work and then forgot about it. And there's just piles of craft, right?

Ed 38:08

Right. Well, there's also this the the sunk cost fallacy tends to pop up in a lot of weird ways. You know, I I'll see like a feature that turned out not to really be used in in the production application when they're when they're talking about wanting to rebuild

Peter 38:21

By anybody.

Ed 38:22

the system, even though that feature isn't used, they remember all of the time, all of the months and the tens of thousands of dollars they put into building that feature. And because

Peter 38:31

Uh-huh.

Ed 38:32

they invested so much in that feature, it has to live. You have to carry it over into this new thing. It's like

Peter 38:36

Oh, I

have examples of that. And and and you and you know, and you try to tell them like listen and they just it's very hard to like talk to people about this. Um Yeah. So so this is the throwing away

Ed 38:49

Yeah. So anyway, that's that's my scalpel story.

Peter 38:52

stuff away episode, right? Like I feel like a lot of it is about that, it's like just

Ed 38:54

Yeah. Yeah.

Peter 38:57

get good at throwing stuff away in this AI age because if you can't, you're just gonna build up so much crap.

Ed 39:03

Yeah. Yeah, well it's funny, the and some things are hard to throw away. The other thing that that is coming out of this, you know, week of

Peter 39:11

Yeah.

Ed 39:11

of uh work is in order for me to really make sure that I I fully understood the old system, I had to go through and identify what of the old system and I'm talking about the original fifteen year old build, right? Because I wanted to make sure that um because a lot of the

Peter 39:25

Yeah.

Ed 39:25

requirements like this should do it the same way this does. It wasn't like the requirements were a little vague in that they kind of referenced the way the existing system works.

So I had to dig

Peter 39:33

Right.

Ed 39:34

through the existing system to actually figure out how things worked. But it's huge, I mean, just a huge code base. So, you know, finding static analysis tools that could do a good job of identifying dead code that um that is really dead in a pre-composer PHP application. And you know, how you combine that static analysis with CI. I dropped some some logging into the existing system to see like tombstones

Peter 40:01

good.

Ed 40:02

of things like.

You know, I think this is dead, but is it really dead? Like, you know, find that out.

Peter 40:06

Yeah, yeah, yeah. Let's run

it for a month. 'Cause 'cause something's just run once a month, right?

Ed 40:12

yeah, I mean ob obviously there's that sort of thing. And I and I'm not going to. Like uh I wasn't so my my purpose here wasn't to throw out code from the old system. We want to throw out the entire old system. My my purpose was I have to read a lot of code here and or at least point Claude toward reading a lot of code here in order to really extract like how does this actually work? How does it make these decisions that are you know, when the requirements document says, you know, make this decision the same way that sugar makes the decision, well

It doesn't tell me that I have to go into the code and find that out. Um and so I I don't want to be burning a bunch of cycles analyzing code that isn't used anymore. So just figuring out what those active code paths likely are. And because I'm not deleting code in a production app and you know, like doing the traditional tombstoning thing, there's some margin for error. If I get some of this stuff wrong, it's not the end of the world, so that can actually break anything. But I don't want to spend all of this time and attention and tokens reading all of the code. I want to read the code that's likely actually in use.

Peter 41:09

Yeah, yeah. It's

Ed 41:09

Um so I learned a lot about

tombstoning and uh you know how because it that always used to be a really tedious thing that we would almost never do. We should have done a lot more often back in the pre AI days, but most teams didn't do it. So just about any app that you get your hands on is gonna be like thirty percent Africa code and seventy percent dead code and it's all just still there. Um and you're still running tests on all that dead code.

Peter 41:30

It so reminds me,

it so reminds me of my last client. but so my last technical client that I had. Um it's interesting also, like remember when we were talking about so I'm so I'm building Sputnik, right? Sputnikintelligence.com, it's very good. Um for for put for podcast and newsletter data for your agents. And so so I built this thing to like visualize

the system. Do you remember that? So I feel there's a there's a lot of things there, like, okay, so the agents are doing well, you know, building all these things. And I'll and and and if it's my code, I want to be able to visualize the code that is like the objects and the flows and stuff in a way that works for my brain. If it's if the agent is is is and then air dash, the agent is like um doing stuff every day.

Right, it's just running stuff for me. I wanna be able I I want it to track stuff and and have a database and I wanna be able to look at it so I can just like see what what it's been doing, and that's air dash. And I feel this like kinda like there's the human and the agent, and the human has to understand what the agent's doing, but like at a level of explanation that works for that person.

Ed 42:51

Yeah, so this um to loop briefly back to this CRM project, another

Peter 42:57

Yeah.

Ed 42:57

thing that the requirements document had was just a bunch of really like difficult to write reporting. Um and especially not yeah, like building building

Peter 43:05

Difficult to write reporting in in what way difficult to write?

Ed 43:11

just building reports that are very uh they need a lot of flexibility because they want to be able to to see this data from a whole bunch of different angles and

Peter 43:20

okay. Like like a very flexible reporting system.

Ed 43:21

Yeah, so it was just Yeah,

flexible, a lot of filters, like just it's one of those things like none of the actual individual reports are hard to create, right? That's all that's all relatively easy. But creating in a way where a non-technical user is gonna be able to look at this dashboard and say, Yeah, okay, the intuitive way for me to do this is to click here, click here, do that, dah da. Like that whole

Peter 43:40

Right.

Ed 43:41

user experience thing was gonna be a huge task. And I gutted it all. I took the entire reporting dashboard out of the requirements and

Peter 43:50

I I

I love that because like if you think about it like in terms of primitives and things that work together, that is a separate thing.

Ed 43:59

Yeah. But uh I've the way I'm doing it is have you so we we all know what an MCP is, we we use them all the time. We all know what skills are, we use those all the time. I hadn't really dug into this and I I might sound like a complete idiot because I'm like learning about the new thing like this week, but I hadn't I hadn't dug into this until uh last week I was kind of looking at how I could make scalpels a bit more user friendly. Um I was like, what if

Peter 44:23

Are you gonna say MCB apps?

Ed 44:25

what if I just made it a plug-in?

What if I made a Scalpels

Peter 44:29

Yeah.

Ed 44:29

plugin? And I was just looking for how do I make the MCP as easy to install as possible in something like a Claude cowork.

Peter 44:33

Yeah. Yeah.

Ed 44:36

And it turns out the Claude plugins bundle the the MCP connection, uh, which you it has to be all off, but that's easy enough, with skills. So

Peter 44:46

Yes, exactly.

Ed 44:48

yeah. So I didn't I didn't know this, and I'm just like, wait a minute. I don't have to build a dashboard for the CRM at all. I just build a plugin for it. I just throw an MCP at it that

Peter 44:57

And then

you could just ask your agents.

Ed 44:57

It can pull in all of that.

Yeah. And then no, you don't have a dashboard. You have this plugin, plug it into your clawed code or your your clawed co-work or whatever. Uh, if you want to have a daily report run, you just describe the daily report that you want run and you can wake up at seven o'clock in the morning to whatever you actually care about. So I'm not going to build you any admin dashboard. I'm going to let you build all that stuff, you and your agent, by simply exposing the data and giving it the skills so it knows exactly what's what inside the, you know, instead of just basic data definitions.

I'll give it really uh you know robust information to help guide it toward building you the dashboard that you want.

Peter 45:35

I like it. It it's like

Ed 45:36

And now I regret having built

Peter 45:38

it's like you've just leaped for from a fifteen year old system into next year's system, you know, like this is how it should

Ed 45:42

Yeah, yeah.

Peter 45:43

be, right? This is what what you know, like I mean unl this is just how it should be.

Ed 45:50

Yeah. Well now I've started regretting that I built a dashboard for scalpels at all. Yeah.

Peter 45:56

you build a dashboard for scalpels?

Ed 45:58

Well scalpels has a dashboard. So like you can jump into if you have you know six different applications installed in Scalpels. Right. But I put a lot of

Peter 46:01

But nobody's gonna use the UI, you just want your agent, right? Like just yeah, make it an MCP.

Ed 46:06

work into this, and it's not great, but I put a lot of work into it. And I'm like, why did I put any work in this at all? It should just be like, okay, you've you've installed all this. Actually, you don't have to click to install it. The MCP will let you install it.

Like if you just install the MCP, you could say, install

Peter 46:19

Uh-huh.

Ed 46:21

Hone for me. Okay, now connect these sites to Hone. you know, you can do all of through your agent. You don't need the Scalpel's dashboard at all.

Peter 46:27

You see, that's how

it should be. I guess because you're right about the plugins and I need to sit down and 'cause 'cause you can do them for um open AI as well. And

Ed 46:37

Mm-hmm.

Peter 46:37

then and then you can and then I am fairly sure you actually have to like register your company and stuff with them, but then you can show up in their directory.

Ed 46:48

Right. Yeah. If you want to show up at the directory. So like for um for scalpels, I'm definitely gonna do that. So I'll I'll put that into the the Claud directory. And

Peter 46:57

Yeah.

Ed 46:58

um then it'll be just like the on the homepage it'll be like, Wanna use scalpels? Just install this Claude plugin and it'll

Peter 47:05

That's it.

Ed 47:06

take care of everything for you. Um so that's like the the ultimate vision for how I want people to actually interact with at least the um the catalog portion of scalpels.

Peter 47:16

I think that's how it should be. And then if the if so if the human then needs some kind of UI visualization or something, right? Then you expose a few MCP apps, which is just little iframey, right?

Ed 47:31

Yeah. Yep. Yep.

Peter 47:34

Thing is, and you you still don't need all the all this. You you really don't need much of a

Ed 47:39

Yeah, well,

this is a because again, it was one of those like you you kind of so I wasn't in any of the meetings when the requirements documents were being put together, but I could definitely

Peter 47:46

Yeah.

Ed 47:46

see like you could probably put a picture next to each one of these requirements, and a lot of it was like, well, I

Peter 47:50

Yes. Yes.

Ed 47:51

want to be able to see the the data this way, and I want to be able to see it this way. And so like it's just all these individual requests. And so I know that

Peter 47:57

Uh-huh.

Ed 47:58

whoever wants this particular view will never use this view. And so all I'm doing is I'm cluttering the experience for one user to satisfy the request of another user.

And there are 30

Peter 48:08

Yeah. ah

Ed 48:09

stakeholders here, all of whom fed into this document. And each one of them has his, you know, one or two particular things that they need. And the other twenty eight things that are on this list they don't actually care about, would never look at. So

Peter 48:20

Yeah.

Ed 48:20

this w this way it becomes really customized. Now, for this client, it's going because these are not technically users, is going to require like, okay, let's all let's have a training session. Like, let's all make sure we have cloud set up on our computers. You know, let's let's go into cloud cowork that we can actually schedule things based around this. And

You know, so I'll probably end doing some

Peter 48:38

Yeah, yeah. The the

Ed 48:40

some training sessions.

Peter 48:41

For sure, but but I do feel like the funny thing is also like when you demo stuff like that to them, a lot of like most people have never seen anything like this. Most people have just chatted with chat GPT, you know. Um I d I think it's great, like and yeah, like that that problem, that's for the year of user experience right there, right? Forty years of like trying to figure out how do we build something that works for everybody. It's so funny.

Ed 49:10

Yeah, no, it's good. I feel I feel really good about it. And it, you know, I'm gonna apply a lot of what I've learned and a lot of what I've built along the way back into scalpels when I get my head above water. So I'm really excited

Peter 49:21

Yeah.

Ed 49:21

for the future of scalpels and a little sad that my like week one marketing push was, oops, that's just not gonna happen

Peter 49:26

Whoa!

Ed 49:26

because now I have this client who's like, you know, but it's it's like anything else. It's client work is what pays the bills. So if somebody says, I want to buy a week of your time right now, I'm gonna sell you a week of my time. If that means that I kick off my marketing a week later,

I kick off my marketing a week later. I need to, you know, as as Aaron Francis was say, I need to put food on my family.

Peter 49:45

Yeah, food on the family. That that's what you need. It um

Ed 49:47

Yeah. So um you know

it is what it is. Uh so hopefully next week when we talk I'll I'll have some some exciting news about, you know, MRR and users and things like I do have users coming in. Uh I have registrations coming in. Um we have we have one paying user and like Yeah. Yeah. Um no, it's not it's not me. It's a it's

Peter 50:00

That's pretty good though, because people are finding it, right? But it's great! You got a paying user. That's not you, right? Like yeah, that's great.

Ed 50:12

a real person uh that's that's paying. I know.

Peter 50:15

And and and then

and then your next question

Ed 50:16

I do know this person.

Peter 50:17

should be in in in you know in it's November fifth, from now until the end of the year, is this paying user getting any actual real value out of this? Like for real? What is the real

Ed 50:30

Hi.

Peter 50:31

value they are getting out like that's your next question, right?

Ed 50:33

I would expect

him to so he's a freelancer and uh the if if he's using scalpels that one of the things I need to do is really like do some content around how I use scalpels as a you know, as an agency owner with clients, um to

Peter 50:50

I think

so and even just even just just a drip email that goes to those people and once a week is like here's a tip on how I use scalpels with clients. That's it.

Ed 50:59

Yeah Yeah.

I think I think that I need to do lot of that that sort of content because it's incredibly powerful. You know, the just the fact that I wake up to, you know, Claude Cowork will basically use the scalpel's API to check all of my stuff and all of my client stuff, and it'll be like, here is the shit that's hitting the fan today. And I'll be like, great, okay. So I can see I have anomalous logs here, I have this coming out of hone here. Like these are things I have to either handle or test somebody with handling. Um, but I never have to sit down in the morning and say, Okay, uh uh

You know, use scalpels to tell me what's happening across my fleet. It's all just scheduled and and it's great. I have something keeping an eye on everything for me.

Peter 51:37

That is crazy. uh let's keep talking about that because I feel like that is the right way to market it, but but also just so related, right? Um I feel like so for Sputnik, I finished I realized I made a mistake. My mistake was um I went down the rabbit hole during uh October of like automated marketing and SER, right?

And so I tr I tried stuff and this and that and it's kinda working. And I'm and and you know, I'm posting stuff to socials now. I'm I'm generating these SEO pa pages and it's kind of working. And I'm starting to get traffic, but I was like, fuck, I made a mistake. I wrapped it all and I learned how to like use Claw to do these repetitive things. The biggest thing I learned is like everything has to run fully in the cloud because if it requires my laptop.

You know, it it's just not gonna I can't, right?

Ed 52:39

Yeah.

Peter 52:39

So I made everything run in the cloud. I finished that um on I think on Tuesday. And now I have all these loops. I I'll give you an example. I have one loop that once a week looks at my um my uh Google uh Webmaster console, what do they call it? It's always gonna be Webmaster.

Ed 52:59

The search console?

Peter 53:00

Yeah, it's always gonna be Google Webmaster. Um it checks for like keywords that I'm I'm

I'm not actually getting traffic for but kinda like almost, like I'm on page two or whatever. And then it improves that page's like title and meta description to kind of but but my mistake was that's all like cool and fun and whatever, but I'm not I'm not that's just like that'll pay off in six months. And so now I'm like

I automated it all, it's all fully running in the cloud without me being involved, and I'm gonna stop looking at it until January. And hopefully it just drives traffic and subscribers. But November will be me reaching out to real people selling the actual product. So so I realized that I was like, major mistake, I should have sold first and then started working on the automated stuff.

Ed 53:53

I'll push back on that a little

bit. It I mean, if if you need the money in your pocket today, then yes, you should have sold first. If you just want to build a great business, I don't think this was a mistake. Because what you will find is once you do start having a lot of users, um, your your ability to dedicate time to this sort of automation and doing the things that are just sowing those seeds that will sprout in six months, that time diminishes. And all those things.

that you did, if you hadn't done them first, you probably wouldn't be taking the time to do them three months from now when you've you've established customers things like that. So

Peter 54:33

Well, but that assumes that I am actually that I actually built the product that people actually do want. Which which I kind of think I you know, which is not in my mind proven until I have dozens of real customers that are not just paying me but also getting actual value out of the product. So so you see what

Ed 54:52

I but I think

Peter 54:53

I mean? Like that's why I think maybe it was the wrong way around.

Ed 54:55

Yeah, but

I I don't think and you know, I could be completely wrong on this, but I don't think that there's no coat of paint that you could put on what you have that's that uh would be a fit for the market, right? So what I'm saying is you have a really good foundation. You're pulling in all kinds of really useful data, and you

Peter 55:13

I think so.

Ed 55:14

can do a lot of really useful things with that data. And I think that the difference between selling and not selling for you isn't so much gonna be a matter of how the product is built.

But how the product is presented. It's gonna be, can I get somebody to see their problem in the H1 and and be like, this is for me.

Peter 55:39

Yeah, and then and then and then one click MCP install

Ed 55:44

Right. So

Peter 55:45

with a bunch of skills for your use case.

Ed 55:47

Yeah. So because it's not going to be a matter of I have to like throw this idea away entirely and start a whole new thing, you wanna do

Peter 55:54

Yeah, no.

Ed 55:55

those you want to plant those seeds now that will be driving traffic to you in six months. Because while your uh the actual problem statement that you're making in your H1 is probably gonna be different in six months than it is today. Um the the foundational search piece of it, like the the content.

That the search engines care about, other than that problem statement, is gonna be the same, right? So your

Peter 56:19

Well, you're making

me feel better. I I was just worried I was just like this this kind of feels like work work. You know like work work? When people have meetings

Ed 56:27

Yeah.

Peter 56:28

and they make decks and it's like, wait, but that's not actually the stuff you're getting paid for. Um

Ed 56:34

Right.

Yeah. I mean, so it's I because I'm kind of in the same position with scalpels in insofar as

Peter 56:39

Yeah.

Ed 56:40

it's an incredibly valuable tool, even if I'm the only person that ever uses it. Like the time that I put into building it,

Peter 56:44

That is true.

Ed 56:45

the time that I put into building it is worth it because you know, I just look at how much time it saves me with uh with my clients and the the amount of confidence that I have. Like so I'm I'm throwing together a CRM that is going to basically be the engine, that the beating heart of a company.

on the day that we turn it on. So it has to work. And I know that I can wrap it in all of this telemetry and everything that Scalpels offers. And just, you know, I I can keep an eye on it passively without having to stress out over it from day one. I don't have to worry about, you know, wiring up all kinds of different services and then figuring out alerting and and on call and all like all that stuff is just solved. It's just it it

Peter 57:21

Yeah, yeah, yeah. Yeah.

Ed 57:23

sits in my toolkit and it's solved and um and it lets me take

Peter 57:27

Yeah, let's

Ed 57:28

these bigger risks.

Peter 57:29

let's dig into that. So so I do I like that. I think you're and so you know so in the in the coming weeks and whatever um at some point you get back to marketing. I think your core I think your core ICP and your core marketing is basically, you know, you 15 years ago. So not in time, but like in age.

But today, right? But like young but like more s more you know, less senior. But so and the stories you tell even in this podcast is like, this is how I use it. This is I think that is your marketing. And I think the tools that you build and that you put on the home page and the way you package it, it's not the tools for the small business or w owner, it's the tools for that ICP.

Ed 58:22

Right. Yeah, the ITP is definitely the the freelancer. I I've kind of recognized that from the beginning or the small agency. you know, big agency that they have their own processes, tooling, things like that. You know, I'm they're never gonna get that excited about what I've built. But like the small, you know, two or three person agency or the freelancer, those are people who uh can take this and adopt it and immediately get value out of it on day one. Because,

Peter 58:43

Yeah.

Ed 58:44

you know, with with the MCP, the way it's set up, it it can reach into all of your across your entire client portfolio.

But it does a good job of segregating data. So you don't get any leakage and um

Peter 58:53

But but you see,

like you told you've told three stories already in this today to me.

Ed 59:00

Mm-hmm. Yeah.

Peter 59:02

And the thing you just said, like that is a marketing piece, right? And that

Ed 59:06

Right.

Peter 59:06

you can just like repeat, etc. Like you can see

Ed 59:08

And

Peter 59:09

all your whole fleet.

Ed 59:11

Yeah. And the only missing piece is that it's it right now just it has some friction to it because you have this setup that you have to do. Once I take and create this uh plugin and get it in the cloud directory, and it's literally just install this cloud plugin, connect via OAuth, and you know, if you are paying us, you have access to every single team that you just onboard all of your teams and you have access to all of them through this one consolidated MCP.

you can monitor your your whole client portfolio fleet for and I I've told you I'm my plan is to pull R C V E's scalpels, so that will be a scalpel so you'll be able keep track of all of their vulnerabilities, all of their telemetry, all the logs. Yeah. So

Peter 59:50

should be. Security security should be part of it. It's like security,

telemetry, all the stuff, yeah.

Ed 59:57

Yep. Um and then yeah, I think uh and then you know they're sort of the specialist like you're you may never need it, but if you ever do need to stand up a a uh an SES simulator so that you can load test the crap out of uh CRM that you're building, you have it. You just click the button and you have it.

Peter 1:00:13

Yeah, the the niche stuff.

That's that's useful. But but I feel like the core is the stuff you tell like you tell me these little stories and I'm like this you know, with my clients and this and this and like that to me is should be the marketing. It should be like like the trip

Ed 1:00:25

But I yeah and I

Peter 1:00:26

campaign, the video, the everything. The Twitter

Ed 1:00:28

Mm-hmm. Well, I think

the compelling story is going to be when I when I can just open up Claude, just a blank Claude cowork, install the MCP, and just say, okay, what's happening across my clients and just get this like, you know, charts and graphs and all this stuff just drawn into Claude for me. And it's like, yeah, do you wanna have this sort of visibility into, you know, the health of all of your client systems?

Peter 1:00:53

There you go, but then that should be your homepage, that should be your video, that should be your right to me. That makes sense. It's very focused and fine. If you say my ICP is smaller things, smaller agencies, and whatever, that's okay. I think, I think maybe maybe that's that's where where it starts. But like if you spend another year building this stuff, it'll be so good that everybody should. You know what I mean? Like

It uh

Ed 1:01:24

Yeah, I just it's the tricky thing is how do I actually monetize the end user without putting any of the apps behind a paywall? I don't want to put the apps behind a paywall. I don't wanna put the the core MCP behind a paywall. Like I just want this to be useful to everybody from day one. Because so here's part of my thinking. If I can get the the end user, the the the clients of agencies and um and freelancers using this because it's free, when they hire an agency or a freelancer.

They're gonna say, Oh, this is how we're doing our telemetry and our logs and our, you know, all that sort of thing. So you know, we'll need you to integrate so now all a sudden I have the end user pushing my ICP toward using it.

Peter 1:02:04

Yeah,

yeah, yeah. So I think I think then the first goal should be you should have ten people using the with a and we each have like a bunch of things, having that connected and using it. And and then the good thing is you can just check your MCP logs to see what they're doing. You know what I mean? Like like n not in a privacy way, but in kind of like which tools are they calling every day? Is it every day? Is it once a week?

Ed 1:02:29

Yeah, and that's that's already that's already built.

I don't um so obviously because of this consolidated MCP, all of the requests do go through scalpels. Um I'm very careful

Peter 1:02:38

Yeah.

Ed 1:02:38

not to log any actual content. E if an exception is thrown, it's empty of content,

Peter 1:02:41

Of course, of course.

Ed 1:02:43

things like that. So but I do see statistics on tool calls, you know, frequency, uh, you know, all of that sort of thing.

Peter 1:02:50

And then and then

I I do that with Sputnik and then I just ask like, hey, what it what are these people doing? And

Ed 1:02:56

Mm-hmm.

Peter 1:02:56

it kind of can figure it out, you know, for it has a little metadata and that's enough for it to figure out, like, it looks like they're trying to do these things.

Ed 1:03:03

No.

Peter 1:03:04

Yeah.

Ed 1:03:05

Yeah, it's interesting. I I I like it. Um and this is again my like, so I was beating myself up for the last couple of days because it's like I launched Scalpels, I made this big thing about I'm I'm launching this on Halloween. And then, you know, as I got into that day, I had a client, you know, in my ear saying, I want to buy some of your time and I'm looking at my checking account balance going, Yeah, okay, you can buy my time. Um and uh so

Peter 1:03:30

Yeah yeah, it's fine. It's fine. Nobody cares.

Like like who cares that you launch you launch it again next week and in two weeks. Yeah.

Ed 1:03:35

No, no.

Well, I know. But the thing is, like, it's one of those things if you um if you don't set deadlines for this sort of thing, if you don't say, Okay, on this day I'm going to start doing this thing, then you can especially if you're a builder like us, right? We just want to keep building. I could keep building scalpels, honestly, for another three years before I even tweet about it, because I'm just really enjoying building it.

Peter 1:03:57

Yeah, yeah, yeah, I can see that. Um that's why I have my two products per year rule. So so I have so I have one new product avail spot coming up in January.

Ed 1:04:09

Oh, cool.

Peter 1:04:10

So this may be Air Dash, it may be something else, I don't know.

Ed 1:04:14

Yeah. Well see the the great thing about scalpels, 'cause I have kinda the same rule, right? But the great thing about scalpels is that it's just a product of products. So

Peter 1:04:20

Yeah. But

but but y but this y but you just kinda like break you know, you just break in your you know, like it you're cheating, right? It's

Ed 1:04:30

Yeah.

Peter 1:04:31

like, oh let me just build a ton of stuff and it's all one product.

Ed 1:04:34

Well, I I I am cheating. But

the other thing is, you know, in order to really, you know, make use of some of the stuff, it like, um, you know, I had this idea for the mobile analytics tool, like uh the for native PHP.

Peter 1:04:46

Yeah, yeah.

Ed 1:04:48

So there are mobile analytics tools out there, but none of them are just like drop into native PHP super easy to use. So I wanted to build one. And

Peter 1:04:54

Yeah,

fair enough.

Ed 1:04:56

So but I didn't actually have a mobile app. So I was like, okay, well, in order for me to actually validate that this works, I need to build a mobile app. So like now I have this excuse that I can build a mobile app and put it in the store. So yeah,

Peter 1:05:03

my god. Yeah, yeah, yeah. Hmm. Yeah.

Ed 1:05:07

it it gives me that other excuse, like, well, I can't really validate this internally if I don't build something that uses it. So now I have this reason to just keep building new things.

Peter 1:05:12

Yeah. Yeah.

You know what my excuse is? My excuse is um so I cannot start a a product from which I wanna make money, but I do build internal products. So AirDash, for example, is an internal product for now that is good for my own use case and and all and uh you know like I never need to launch it, right? Um uh I have I have probable which is analytics for my own use case. I have a bunch of these for my own use case and they're very fun.

So that's how I cheat, which probably not but I find it useful 'cause like 'cause like they're exactly what I need. There's no listen like what what you've been saying, like they're not trying to limit me, you know, by the amount of MCP calls I can make, or you can do maximum this much stuff. There's there's none of that friction. And they

Ed 1:06:03

Yeah.

Peter 1:06:03

all just work. And it and and I haven't maybe it'll become maintenance hell, but I don't think so because they're pretty simple.

Ed 1:06:12

Yeah. I you know, I'm not finding maintenance hell to be a thing anymore. I mean, obviously if you if you have a bunch of legacy stuff, then you haven't done any work

Peter 1:06:20

Yeah.

Ed 1:06:21

to get that like hooked into good automations. Cause you know, like the the thing is a a ten year old PHP app is not PHP ready. Like you or is it's not AI ready. You have to do some work with AI, but you have to do some work before you can just kind of put something on autopilot. But if you do the work to

Peter 1:06:37

Yeah.

Ed 1:06:37

put it on autopilot, you can really kind of eliminate a lot of the maintenance help.

And it's not that you never have

Peter 1:06:41

So

Ed 1:06:41

to do anything, it's that you don't have to, you know, constantly hit refresh and you know, on the logs and stare at it. It's like when a problem happens, it gets handed to you with a real diagnosis and a likely solution, uh, versus like the

Peter 1:06:54

Yeah, yeah. Yeah.

Ed 1:06:56

shit's hit fan, what do I do?

Peter 1:06:57

Yeah, no, I get that. So so let maybe we we end five minutes by like zooming out a bit. So

Ed 1:07:03

Okay.

Peter 1:07:04

so so 'cause I I always try to like update my thoughts about 'cause stuff is just wild, right? So okay, so if maintenance maintenance hell is is in in twenty twenty seven is now fixed

The way like writing software was fixed and now maintenance hell is fixed, right? Like it's crazy. Then

Ed 1:07:27

Yeah. If you're intentional about it, it's fixed.

Peter 1:07:29

Yeah, yeah. It it let's say it it can be fixed. Writ writing software can be fixed. Yeah.

Ed 1:07:33

Right. It's fixable. Just like writing software is right. Right. Writing software

is fixable. Maintenance hell is fixable, but you have to

Peter 1:07:39

That's fixable, right?

Ed 1:07:41

yeah.

Peter 1:07:42

You have to do it, but it's fixable. So so if all those things are true, which I I believe, I believe they are, and we are, you know, let's call it uh indie founders building products, right?

Ed 1:07:56

Mm-hmm.

Peter 1:07:57

And and then what's the

Yeah, I don't know. Let's just riff on that. Like so so I know with Sputnik w my thought is data is the mode, so it's good to get data that's hard to get, that is

Ed 1:08:16

Mm-hmm.

Peter 1:08:16

useful, because then you can you sell the data. Like I'm not sell it like all the tech doesn't matter. Hmm.

Ed 1:08:27

Yeah, I don't know. It's well it's a weird time to be a indie founder because software

Peter 1:08:31

It's a weird time, yeah.

Ed 1:08:35

development is fixable and because maintenance is fixable, you can't really pitch it as you can't build this anymore because anybody can. You can't pitch it as you can't maintain this anymore because there are you know that's that's on its way to being fixed. I mean, you look

Peter 1:08:49

Fixed. Yeah.

Ed 1:08:51

at you know what Larva Cloud has done with that platform and

I know they're bringing out an MCP. And like if you if you're intentional about setting things up, to a large degree, the majority of the things that used to make managing software hard can be fixed by choosing a good platform, by choosing a good uh framework. Like if you just make good choices up front, all of these things are fixable. And so what is the moat? Because anybody who is is uh knowledgeable enough to make good choices.

and point the AI in the right direction can build anything. There's no limit to what's what somebody could could do. Um, you know, some things you probably wouldn't most companies wouldn't want to vibe code their own CRM. Some will, obviously, uh but most won't. Um you know so there's some

Peter 1:09:38

Yeah, no.

Why? But then but then when your COM starts like blocking what you wanna do, then you then you right? That's then you do. Or

Ed 1:09:45

Then you do. Like, yeah, if but if my CRM's not letting me

do what I want to do, yeah, for it's not giving me the that access, then then maybe you do.

Peter 1:09:51

Like Fig

Figma the other day told me like you've run out of MCP points. I'm like,

Ed 1:09:58

Yeah.

Peter 1:09:59

my god, do you have MCP points? Is that how you're trying to like make me upgrades?

Ed 1:10:03

Yeah, well I mean it's that's insane. They're not paying for any inference. They should yeah.

Peter 1:10:06

s it's insane.

Ed 1:10:09

Well, I know, and it's I have the same sort of uh there's there's some s weird stuff around amp pricing in orbs, so that you I think that you pay more for bigger, uh, more powerful orbs even if you're self-hosting them. Well, why would the compute size of an orb matter if the orb is running on your machine? But it's just this way of like and it and I get it, this is how software runs. This SS runs. You have to find ways to to monetize, you have to find ways to Yeah. Yeah.

Peter 1:10:33

Yeah, but they're artificial ways. Often, very often they're artificial. When

when they are real it's fair enough, but like in in most cases it's like, how many emails you store? That's artificial. Right? Like in many cases it's just an artificial

Ed 1:10:46

Yeah, storage is basically free. Yeah.

Peter 1:10:49

limit.

Ed 1:10:51

Yeah. So I don't know. I mean it's I think it's gonna come down to like for indie makers, I don't think indie makers are gonna go away, but I think if you're an indie maker and you wanna be able to like make money, um, you know, all of the

Peter 1:11:01

Yeah, how do we make a lot of money? Is that's the real question?

Ed 1:11:05

Well, I don't know that Indie makers I mean some indie makers may mu might make a lot of money, but it might be a matter of having to do like the Peter levels, like I'm gonna build, you know, a hundred different things and maybe two of them will actually take off. But the thing is, it right now I think that the average indie maker could make a hundred things, none of them would take off.

Peter 1:11:21

I think I think that's what's actually happening.

Ed 1:11:23

Because what AI can't solve for and actually AI makes worse is attention. It is so hard to get on the radar of your ICP. And you know, if you if you don't have a a really good email list, or if you don't have some way other than like tweeting out of the void that I've built this cool thing, it doesn't really matter how cool the thing is. Um you're not going to get people excited enough to

to actually use it. Um so so that's gonna be tough. It's

Peter 1:11:55

Yeah.

Ed 1:11:56

it's gonna be like how do how do indie makers get attention in uh in a very distracted world?

Peter 1:12:04

I I have one other theory, which we can talk about some other time, but so it's well, I have two other theories. One of them is you sell to people that are like 18 months behind the curve. Right? So you almost kind of sell you're selling your maybe two or whatever, but almost your expertise. And and the other theory is you sell outcomes as in as in okay, so so

Final story. Um so I'm I'm shutting down some companies that I created in the past. They're US C Corps, because I made them with Stripe Atlas. But so it's very annoying, right? Like it's a law of paper. So I so I d I it's expensive. I did find a company that seems good. I'll I'll I'll let you know in February whether they were actually good. Um

But I can tell that they are they are automating a lot of stuff. But but so they they just they don't sell any tool or anything. All they sell is like here's the six things we'll do, and it's this much money. And and here's your Stripe link to pay us. You know? And we don't go on calls, everything's via email, whatever. And you know, I d they have reputation, so that's good. Um

But you see what I'm saying? Like they're just selling the outcome. They just sell it like it's a very annoying thing. It's gonna cost you money and we are cheaper, but we're good and fast. And this is what we do and this is thing, and we make money 'cause we're so efficient.

Ed 1:13:37

Yeah, so is it like Stripe Atlas for for company dissolution? Is that the are they doing like the whole dissolution? Yeah.

Peter 1:13:43

Yeah, company company dissolution is a thing, right? It's an annoying

thing and it's a tricky thing. And you gotta do certain things right and all the kind of stuff. That that is what it is. But but that's a service. Now the only problem with that one is is you do it once and then assuming that customer creates more companies, you do it again. But s it's not so repeating, but okay. Fair

Ed 1:14:05

Right.

Peter 1:14:06

enough, right? But but that thing, like uh we'll do your company taxes every year or

An annoying thing where you literally just sell the result and you were

Ed 1:14:15

Mm-hmm.

Peter 1:14:16

just very efficient with all your uh

Ed 1:14:19

So you think that SAS will to a large degree give away to productize service with a lot of automation behind it?

Peter 1:14:29

I mean, no, I don't I don't want to make big statements, but I mean I mean look, right? Like I don't know what's gonna happen. But but I just say like that is something that I think will still will work next year and the year after and the year after. Like I need something, it's annoying, I need somebody to do it, it's worth money, and they can do it very efficiently, very well, because whatever. And I don't need to know any of that.

Ed 1:14:58

Yeah, I mean that does that makes a lot of sense. I guess the ways that you know that you can you can build a business that will make money and survive in the long run is either to solve something really hard, take like the Bento approach. Like email is really hard and Bento does a really good job of solving it, and you can't vibe code your way into a really good solution to email. It's just not gonna happen. I don't see any world in the

Peter 1:15:19

I I

will push back on that though. Like so yeah, email deliverability is hard, but like the whole Bento um send a drip email, send a s have a list of your users, like a lot of that is just plain sass.

Ed 1:15:35

yeah, yeah, yeah, yeah. But it's the it's the underlying stuff, right? It's the the layer below know the the user experience for Bento is really hard. So if you know, you still have to buy that layer down, whether you buy Bento or buy whatever that layer, and he I think now he has a new service that is kind of that layer down. Um and you can build your kind of buy poodron SAS on top of it.

Peter 1:15:54

Yeah, I I I do uh

yeah, yeah, it is. Um

Ed 1:16:00

Or or it's the selling outcomes and the outcomes probably I mean, maybe this like company dissolution thing could be completely automated and AI driven in the future. So it's like we're just gonna take your X thousand dollars via Stripe.

Peter 1:16:13

Just just call it n

ninety percent automated. And then you still need somebody

Ed 1:16:16

Yeah. And we never have to actually touch it.

Peter 1:16:18

to have a look at it, right?

Ed 1:16:20

Yeah. So is if you can get that that uh productized service closer and closer and closer to kind of the SaaS model versus the productize service model, then then yeah, that's good. But yeah, I think selling outcomes or solving the really hard problem. And in neither one of those is a great fit for the vast

Peter 1:16:35

Or selling data.

Ed 1:16:37

majority of indie makers. So you know, I don't know. It's it's gonna be a

Peter 1:16:41

Yeah, stuff to think about.

Ed 1:16:43

it's gonna be a weird couple of years.

Peter 1:16:46

Stuff to think it's gonna be a weird couple of years. I'm I'm still figuring out um if I should launch a new project product like in January in Q1 and what that might be. Or maybe I won't, you know, like but that but that's my spot. I don't think my spot rolls over. I think like if I don't then like in Q3 I don't get like two com two new products. I think it's like one every one every six months. That's the rule.

Ed 1:17:09

I I think you should you should sort out the rules. Sort out the rules before

New Year so that you're not arguing with yourself about this.

Peter 1:17:16

No no,

I think the world is it doesn't roll over. If you didn't do it then then you still only have one then it 'cause else it's weird. Um yeah.

Ed 1:17:22

Yeah.

good. Um I think that

Peter 1:17:27

Good stuff.

Ed 1:17:28

pretty much covers it. Uh there's some controversy that you know we won't get into now. The r railway and their their employee that was caught hacking and then saying, my agent did it, not my fault.

Peter 1:17:37

Yeah, don't don't hack. It's a simple rule. Don't don't

it doesn't matter. It's always your fault. You're you're the human

Ed 1:17:43

Yeah. Well that's

Peter 1:17:44

what what do they call it? The the human responsibility thing. It's gonna be your fault unless unless

Ed 1:17:48

Yeah. But but it's the problem is it's

Peter 1:17:51

you can blame it on your company and then it and then the company just goes bankrupt.

Ed 1:17:54

Right, yeah. But I'm starting

to see this trend though. I mean you look at like even even the way that OpenAI has positioned their, you know, our agent did all these unauthorized things when it when it did a side and like no, you were guiding a process with a tool that broke the law.

Peter 1:18:05

It's your fault and you can be sued until

until the law gives agents person like personhood the way they did with companies. So companies have personhood, you can sue them, they can go bankrupt, right? And if

Ed 1:18:18

Right.

Peter 1:18:18

they do that with agents, then sure. But like until then it's it's the owner of the agent, which in this case is a company or a person.

Ed 1:18:24

Yeah, well I think yeah,

Asian personhood I think would be really problematic. But of course with the politicians we have, God knows it could happen.

Peter 1:18:29

Extremely. I think we should

give dolphins personhood before we give Agents personhood.

Ed 1:18:34

Yeah. But I I really think that, you know, that the law should be that the agent is an extension of you. And if your agent breaks the law, you've broken the law. Like if you can't control the tool that you're

Peter 1:18:44

I think so too. I think so too.

Ed 1:18:46

using, you shouldn't be using the tool.

Peter 1:18:47

It's like you got a chainsaw and like the chainsaw did it. No, no. I'll can I say one last thing? I I don't want to wrap up. Um but so on the personhood thing, uh there are a number of countries and in which um the law has given certain person like rights to um nature.

And so for example, uh a river may have certain person like rights in the sense that if I am like, you know, an evil chemical factory and I go sit next to the river, now the river can sue me. And so then in the law that means a person a lawyer representing the river may sue me in order to avoid let's just pollute nature. That's just a very interesting wrinkle.

Ed 1:19:44

Yeah, I think uh

Law and politics get complicated. And, you know, as an American this week as an American this week, uh it's been interesting to watch. Uh yeah, yeah, we'll s we'll see how it turns out. I

Peter 1:19:50

Yeah, let's not mess with them. Hey. Congratulations, by the way. Congratulations, I'm so happy for you. I know it's a big deal.

Ed 1:20:00

mean, you know, my hope is that it becomes a lot less stressful for us to travel there because you know my wife gave up a green card when we moved here. And so uh, you know, crossing the border as a foreigner

Peter 1:20:09

yeah. yeah.

Ed 1:20:10

without any, you know, strong, you know, visa, it's it's tough.

And it's stressful. And so we we're not really enjoying traveling as a family right now because it's you know just that extra layer of anxiety. So my hope is that things get better. My fear is a lot of times, you know, we saw this the last time the Democrats took over. It was we're gonna keep a lot of this Trump stuff going, we're just gonna do it in more polite way. Um and so yeah. So we'll we'll see.

Peter 1:20:34

Yeah. We're gonna whitewash it. Yeah, bad. Um

Ed 1:20:40

I I I'm you know cautiously optimistic that things will get better.

Peter 1:20:45

Me I think it's okay to be optimistic, at least for a few days. I mean, come on, what's a big deal?

Ed 1:20:51

Well, I mean, I'm mostly entertained because the thing is all except for when I travel to the US, I it doesn't actually impact my day to day life 'cause I don't live there anymore. So to

Peter 1:21:00

Yeah, yeah, yeah, yeah.

Ed 1:21:02

some degree I'm kind of a spectator. Uh

Peter 1:21:04

Yeah, yeah. Let's wrap it up. Yes?

Ed 1:21:07

All right. Well, we will uh talk again soon. Have fun at work today. All right.

Peter 1:21:11

We'll talk again soon. Yeah, you too.

Ed 1:21:13

See ya.