New Friction 10: Why Zero Tech Debt Is the Real AI Engineering Unlock

Yeah, 100%.

And the reality is, this is another place where your SDLC can kind of protect you.

And you start down this path of... how do we kind of streamline and improve these processes? And like, I think, you know, the first order thing that I see a lot of organizations do is how do we just get more efficient at the kind of things we already know how to do? And that's, you know, that's the right place to start.

How do we take those things and turn them up? But then you start to develop whole new ways of working that are really just different ways of applying the same tools.

Like, related to what you're, you know, when you talk about the stakes, like, you know, it used to be that it was pretty expensive, took a lot of time, took a lot of human effort, you know, dollars to pay salaries to go really build out a feature to the point where you could actually, you know, Really kick the tires on it and try it.

That's it's it's no longer the case.

And, you know, a couple of companies that I'm pretty close with who I've seen, you know, who are really kind of trying to be on the cutting edge of this have moved to a model where everyone in the company is encouraged to contribute.

to contribute their ideas, their features to the code base in the form of pull requests.

Now, that's not to say that we don't need software engineers and that organization is not one, you know, the company that I'm thinking of here would not, you know, they have actually a lot of guardrails in place around this.

The idea is when the CEO has an idea that he wants to implement, he is totally empowered to open up Cloud Code have a conversation with Claude, work through to the point of having something that works and like works well enough in the actual company's code base where you can start it up, click on it, actually execute the feature, even deploy it off to a shared environment if you want.

The key is, and by the way, the company took some, there were cultural bumps here, right? There was definitely some, this person has no business, and this PR is going to, you know, the same kind of complaints we had earlier about the PR.

But if you reframe your thinking to, the idea isn't this is a pull request ready to be accepted, merged, and go to production.

The idea is, this is fundamentally better in every way than a vague idea that then has to go through a design sprint and a designer designing an interaction and an engineer thinking about how it might get built before we can even talk about does this, you know, does this thing work? Like you've short circuited from the idea that's in the senior leader's brain that he wants to get into the world to something that provably works and sits inside of the application And now we can take that and do anything we want with it.

Now we can go put it through all those other steps.

Okay, now let's have a proper UX person think through a better interaction pattern.

Let's go actually make it look the way that fits in our design system.

Let's go actually re-engineer the bits.

But there's nothing, there's no better spec than a PR that literally works inside of our piece of software and can work.

And you can throw the whole thing away and retain none of the code.

It's still a valuable mode of thinking and working.

Yeah, it's essentially taking the prototyping culture way further than we've ever gone in the past, right? I've also seen organizations creating test harnesses and prototyping harnesses that are kind of idiosyncratic to their environment.

I'm thinking of one organization right now that is building out a fairly complex new feature that allows you to, I would say, customize and extend the capabilities of their product.

And so it's one of those things that sometimes you really need those use cases for that sort of thing to come alive and to imagine that.

How much capability should they build into that sandbox? Because they don't want to just build an entire dev kit to build anything, right? They've got to have really good primitives, and they've got to think about how is it connected to other data sources and this sort of thing.

And so being able to dream up use cases and see how that actually functions in the real world is really important.

Yeah, 100%.

And the reality is, this is another place where your SDLC can kind of protect you.

And you start down this path of... how do we kind of streamline and improve these processes? And like, I think, you know, the first order thing that I see a lot of organizations do is how do we just get more efficient at the kind of things we already know how to do? And that's, you know, that's the right place to start.

How do we take those things and turn them up? But then you start to develop whole new ways of working that are really just different ways of applying the same tools.

Like, related to what you're, you know, when you talk about the stakes, like, you know, it used to be that it was pretty expensive, took a lot of time, took a lot of human effort, you know, dollars to pay salaries to go really build out a feature to the point where you could actually, you know, Really kick the tires on it and try it.

That's it's it's no longer the case.

And, you know, a couple of companies that I'm pretty close with who I've seen, you know, who are really kind of trying to be on the cutting edge of this have moved to a model where everyone in the company is encouraged to contribute.

to contribute their ideas, their features to the code base in the form of pull requests.

Now, that's not to say that we don't need software engineers and that organization is not one, you know, the company that I'm thinking of here would not, you know, they have actually a lot of guardrails in place around this.

The idea is when the CEO has an idea that he wants to implement, he is totally empowered to open up Cloud Code have a conversation with Claude, work through to the point of having something that works and like works well enough in the actual company's code base where you can start it up, click on it, actually execute the feature, even deploy it off to a shared environment if you want.

The key is, and by the way, the company took some, there were cultural bumps here, right? There was definitely some, this person has no business, and this PR is going to, you know, the same kind of complaints we had earlier about the PR.

But if you reframe your thinking to, the idea isn't this is a pull request ready to be accepted, merged, and go to production.

The idea is, this is fundamentally better in every way than a vague idea that then has to go through a design sprint and a designer designing an interaction and an engineer thinking about how it might get built before we can even talk about does this, you know, does this thing work? Like you've short circuited from the idea that's in the senior leader's brain that he wants to get into the world to something that provably works and sits inside of the application And now we can take that and do anything we want with it.

Now we can go put it through all those other steps.

Okay, now let's have a proper UX person think through a better interaction pattern.

Let's go actually make it look the way that fits in our design system.

Let's go actually re-engineer the bits.

But there's nothing, there's no better spec than a PR that literally works inside of our piece of software and can work.

And you can throw the whole thing away and retain none of the code.

It's still a valuable mode of thinking and working.

Yeah, it's essentially taking the prototyping culture way further than we've ever gone in the past, right? I've also seen organizations creating test harnesses and prototyping harnesses that are kind of idiosyncratic to their environment.

I'm thinking of one organization right now that is building out a fairly complex new feature that allows you to, I would say, customize and extend the capabilities of their product.

And so it's one of those things that sometimes you really need those use cases for that sort of thing to come alive and to imagine that.

How much capability should they build into that sandbox? Because they don't want to just build an entire dev kit to build anything, right? They've got to have really good primitives, and they've got to think about how is it connected to other data sources and this sort of thing.

And so being able to dream up use cases and see how that actually functions in the real world is really important.