i think i'm actually a little bit further along than than you guys in terms of i would say i don't do code review and i think my response to some of the things that you've been saying is that while i think a lot of the things you mentioned is true in terms of complexity spirals in terms of um specification there's another factor at play that i think In my view, you're both underweighting.
And I think it depends what stage you're at, but all three of us are at early stage startups.
And so I think at an early stage, something that is also different than before AI is what I would call the malleability of a code base.
It used to be that rewriting and refactoring was expensive, and now it is cheap and getting cheaper.
in some sense, safer or from a business point of view to take what used to be prototype code into production, right? And if it is useful, then you can just rewrite it, right? Like if you're like, oh, okay, this thing's inefficient.
But with one really important caveat, right? The code base is more malleable than ever.
And so one of the questions I'm asking when I'm looking at how much review do I need, is this stateful? If it's a React widget and I push it out and people hate it or it's got a bug in it and they tell me about it, with an agent I can probably replace that whole thing and ship a new version in a couple of minutes.
If I ship something that crops all the data on my database, I'm going to have a pretty bad time.
Or if it injects data that is really hard to untangle and later breaks some of the assumptions I wanted to make of the schema of the data, that just becomes a more expensive operation to unwind.
And that's... a little bit from from recent lived experience uh so i'm starting to apply a little bit of a sliding scale where fun and code features things that are stateless i'm much more happy to put out there with very very cursory or no review anything that touches the database i think still needs a little bit of a stronger lens
In this very bounded way, which is, hey, code, whose behavior that you can bound, is essentially free.
Who cares? If you've locked it down with an end-to-end test, and you have a very, very healthy set of end-to-end tests, you can just go, oh, whoops.
i think i'm actually a little bit further along than than you guys in terms of i would say i don't do code review and i think my response to some of the things that you've been saying is that while i think a lot of the things you mentioned is true in terms of complexity spirals in terms of um specification there's another factor at play that i think In my view, you're both underweighting.
And I think it depends what stage you're at, but all three of us are at early stage startups.
And so I think at an early stage, something that is also different than before AI is what I would call the malleability of a code base.
It used to be that rewriting and refactoring was expensive, and now it is cheap and getting cheaper.
in some sense, safer or from a business point of view to take what used to be prototype code into production, right? And if it is useful, then you can just rewrite it, right? Like if you're like, oh, okay, this thing's inefficient.
But with one really important caveat, right? The code base is more malleable than ever.
And so one of the questions I'm asking when I'm looking at how much review do I need, is this stateful? If it's a React widget and I push it out and people hate it or it's got a bug in it and they tell me about it, with an agent I can probably replace that whole thing and ship a new version in a couple of minutes.
If I ship something that crops all the data on my database, I'm going to have a pretty bad time.
Or if it injects data that is really hard to untangle and later breaks some of the assumptions I wanted to make of the schema of the data, that just becomes a more expensive operation to unwind.
And that's... a little bit from from recent lived experience uh so i'm starting to apply a little bit of a sliding scale where fun and code features things that are stateless i'm much more happy to put out there with very very cursory or no review anything that touches the database i think still needs a little bit of a stronger lens
In this very bounded way, which is, hey, code, whose behavior that you can bound, is essentially free.
Who cares? If you've locked it down with an end-to-end test, and you have a very, very healthy set of end-to-end tests, you can just go, oh, whoops.
The rest of this transcript — segmented and speaker-labeled, so you land on the exact moment something was said
Search every transcript — by keyword, by phrase, or by meaning, across every show Radar indexes
Trends — what is surging across podcasts, measured against its own baseline
Alerts — when a name you follow appears in a newly indexed episode
No account is needed to search Radar.