# AI SaaS Strategy: Build vs Buy and Trust

**Podcast:** Dev Interrupted
**Published:** 2026-06-05

## Transcript

So I don't know, Angie, what do you think?
Everyone's freaking out about the AI SaaS apocalypse.
It seems to be ongoing.
We're all wondering, are we going to have a job next year or next six months from now?
I don't know.
What do you think, Angie?
Is it officially here?
Like is AI taking everyone's, you know, are we all just going to vibe code SaaS from now on and just never buy anything again?
I know there's a few tools I want to do that too.
Wow.
Immediately kicking us off on like the existential end of the discussion.
I love it.
So.
Yeah.
Are you talking about all the talk of build versus buy and the AI SaaS apocalypse?
That's like a giant Godzilla stomping around through the city, it feels like.
And it's like, is it going to step on your office next?
And, you know, I feel like we've gotten a lot of feedback, too, from our community.
Everyone's kind of feeling this kind of pressure right now, especially in the middle of the year, as well as when people's like product and finance cycles tend to be like in a...
major time of transition.
People are planning for the rest of the year.
And I think this conversation is happening all across the place.
You know, where are the places that you've been seeing us talk about this, Ben?
Because I know that folks have been coming back to us with feedback about how this is kind of being discussed in their own companies as well.
Yeah.
Well, if you haven't seen it, we just published an article to the Dev Interrupted Substack into our LinkedIn newsletter where we talk about the AI SaaSpocalypse and how we think it's a mirage.
You know, we reached out to some people from our community.
We did our own experiments of trying to use an agentic orchestrator to replicate core capabilities within the Linear B platform, you know, something that we know extremely well.
And then we got the insights from like friends of the show, like Rob Zuber and Tatiana Mamout and I think a few other people as well.
Sorry if I'm forgetting who else might have contributed to that.
as well as a lot of discussion that's been happening out on social media around this topic.
And, you know, I think the TLDR of it is that, you know, it's never been easier to experiment and to learn about something new and to like have it like an AI agent or just an AI chat that you really helps you develop and challenge your ideas.
That part of the like DIY side of it is actually immensely valuable.
But the reality is that the equation I feel like really hasn't changed.
You know, it's...
If it's something that adds a core competency to your organization to build it yourself, that you need to deliver value to your customers, like that's the stuff you should be building.
But if it's something that is just going to help you do your job better, you know, there's usually domain experts out there that can build a much better product for that.
So, yeah, you know, there's a lot of hype, I think, on both sides of the equation.
I think I'm definitely falling into the equation that, yeah, maybe some types of companies or services are at risk of, of AI disruption.
I mean, disruption is certainly happening, but the reality is that, you know, I don't see AI just building everything for us in the near term.
You know, maybe it's still a ways off, but in the near term, we still need experts to build software for us.
Who would have thought?
The great part about this is that, you know, the experts in our community made that article possible when we reached out to them and got their feedback on this kind of prevailing topic right now for a lot of us SaaS leaders.
And what you just said a moment ago, it really directly is aligned and rooted with what Rob Zubair, the CTO at CircleCI said to us.
He's a past guest on the show and he made his decisions anchored in, does it provide value to my customer?
Does it?
double down on our specific domain expertise of what we bring to the market.
And I think that's the critical pivot for any build versus buy discussion is understanding, is this intimately connected with the mechanics of me delivering value?
Or is this something external supporting that operation?
And then that discussion often becomes a lot easier to navigate as well.
Yeah, well, welcome to the Friday Deploy brought to you by Linear B, the engineering productivity platform that helps you wrangle the agentic SDLC.
I'm your host, Ben Lloyd Pearson.
And I'm your host, Andrew Ziegler.
And this week, we are covering Microsoft's entry into foundation models, Kent Beck's Trust Factory, Mathematicians vs.
AI, and Stanford's AI rulebook for engineers.
Andrew, let's start with the mathematicians.
What do you think?
Let's talk about the battle that's going on between a group of mathematicians and AI.
Okay, so there's probably an XKCD comic for this somewhere.
But right now, mathematicians are shaking their heads and their hands in a revolt against AI.
And the way that it's flooding the academic research around math with unsubstantiated papers and proofs and operations that are coming from commercial entities from, let's say, the tech sector, conveniently timed with things like press releases and model drops of, oh, look, our model.
can solve this really complex, long, unsolved math equation.
And the mathematicians are throwing their hands up in a revolt, not because the AI is beating them to the answer, but because these proofs are often lacking in a fundamental way of provability and replicability, that members of the community can't even respond to them because they're not fully substantiated pieces of research.
And this is flooding mathematicians' ability to...
do their job.
It's something that I think is happening in a lot of places.
It makes me think immediately of things like in our SDLC, like the code review and how the code reprocess has become so drowned out and inundated with noise, both from the end of the code producer, but then also from tooling and things in your CICD, like AI code review tools and such.
So it's never been noisier.
Mathematicians are apparently feeling it too.
Yeah.
Yeah.
That's exactly where my, my mind went to, you know, Just like AI is generating more code and stuffing it into your review queues, the same thing I think is really happening in engineering.
And one of the things that this article pointed out, companies like OpenAI will claim that their model has solved some sort of problem that has existed in math for a long time that's been unsolved.
And it'll be timed with like a fundraising round or looking for new investors.
And the amount of time it takes to validate that math behinds that isn't going to catch up to those investment or it lags behind those investment rounds.
So, you know, it's definitely a big challenge that I think is hitting, you know, there's a lot of disruption like this that is happening out there.
And, you know, just to tout our own research a little bit too, you know, our own data backs this up.
You know, we've seen that, you know, when AI generates code, for example.
It takes about five times longer to get through the review process, you know, and part of this is like a lack of ownership.
You know, you don't really have a human at the, or you don't always have a human who has like complete ownership over that, that code.
But beyond that, there's this, this real risk of AI being used ways, used in ways that are extremely difficult for humans to validate, whether that's math or software engineering.
Particularly when you consider that AI often still struggles with very basic things, like just referencing real sources, for example, rather than making things up when it can't find an answer.
And as we adopt AI to extend our capabilities, we always need to be aware of where those deterministic checks need to be in place to make sure that it's behaving in a predictable and consistent manner, and that we're transparent about where AI is being used versus where it's not, and how much of that has actually been validated.
by a human.
So, you know, yeah, this article has a lot of just really interesting information about how the disruptions are hitting the field of mathematics.
But I really think engineering leaders should read it too, because there's a lot of parallels to what we're all experiencing.
And, you know, and I think a lot of it just comes down to like, a lot of us are struggling to understand where AI is having a positive impact versus a negative impact.
And how big is that impact?
And what teams or individuals do we need to learn from so that we can enable others?
And, you know, at the end of the day, we want to know what the impact of AI is on real outcomes.
So, yeah, we've been covering this like messy middle of AI adoption here at Dev Interrupted.
And I really think this is just another great example of a group of people that are being impacted by that messy middle.
All right, Andrew, let's move on and talk about Microsoft's new AI announcement.
So I know I want to get into this model announcement, but what else do we need to have on our radar from these announcements?
So Microsoft had their Build 2026 event this week.
And at this, they unveiled, yes, a new flagship family of pioneer foundation models across a wide spectrum of use cases that we're going to talk about in a moment.
But really what this meant is Microsoft is finally entering.
the game here on their own terms with their own technology rooted in their own platform and the unique bets that Microsoft has made on keeping and retaining and providing a kind of walled garden enterprise experience for its customers.
This represented the next step into allowing those same customers that have deeply invested their time and company and their data into the Microsoft ecosystem to now further use it with models and ways.
that rival, you know, what we would think of before as Google's penetration into the workspaces and tool spaces that we all use.
Because, you know, I think we talk on this show constantly about Claude versus ChatGPT and really how Claude has emerged.
But then, of course, none of us can deny the ubiquity of Gemini being in all of our devices, being in our Gmail and in our docs.
And for many people, this is the case.
But for a large swath of folks.
who have in this whole time been inside the walled garden of Microsoft.
You know, they've been using technology that maybe was missing some of these parts of personalization, customization, and access to their data.
So it's finally arriving.
And what this really represents too is them taking a step back from their deeply partnered partnership.
with OpenAI, which has really brought them to this point.
Everyone knows the trademark initial kickoff of the AI hype and the scaling wars was Microsoft immediately butting up with OpenAI and getting access to those models really early in the game.
So this represents like a pivot away from that initial strategy.
Yeah.
And, you know, releasing their own foundation model is absolutely not a surprise whatsoever to me.
I feel like this was pretty much inevitable at some point, particularly given that, you know, there's things like the recent changes to GitHub co-pilot pricing where they went from seat based to usage based because they were, you know, costs were getting out of control.
So, you know, it's clear that Microsoft understands that they are probably behind the game on this and that they need to do some catch up here.
And, you know, in some of the comparisons that they published, you know, it seems comparable in terms of benchmarking to like Sonnet 4.6, you know, which kind of feels like ancient history to me at this point.
But at the same time, like a year ago, I would have been like very happy to have Sonnet 4.6.
So like catching up that quickly is, you know, pretty interesting.
But they certainly still have some ground to gain.
You know, it's clear that they want to have deeper integrations into their ecosystem of tools.
We're seeing this with other companies like Google.
And, you know, just given how the initial launch of Microsoft Copilot went, it does kind of seem like OpenAI hasn't been meeting the needs that they have for their use case.
But there was one thing that was really interesting to me in the announcement they made about making their models more subservient to humans and focus on supporting people rather than replacing them.
which is a pretty interesting take, you know.
So I'd like to watch that one like as it develops more, like to understand why that was an important aspect of this.
But then beyond that, I'm also really interested in cost information.
You know, I think there's a real chance that Microsoft could catch up to the leaders in this market.
But I think there's a lot of room for somebody to come in that just had a very efficient cost for these types of things.
So, yeah, I don't I don't see a whole lot of differentiators for this model yet beyond integrations with the Microsoft ecosystem.
So I'm just kind of wondering what their what their future plans are around that.
And they really entered the scene with with everything they need to equip.
their users with all of their use cases.
Because we've got a thinking model, we've got a flash model, which is a smaller version that can run for more simple tasks.
So you have your deep thinking model that you can work with on really hard stuff.
You have your lower cost model that's faster that you can delegate stuff to on the edge.
You have things for text to understanding voice and as well as image generation.
So they really gave you the whole surface area right off the...
right off the gate which is really uh i think going to be helpful for teams that are going to start to build and explore with these models.
I'm curious to see how their behaviors compare to flagship models and then also to about how they ultimately change or conform to the IQ of the company that they're working with based upon all of the data there.
I think we'll all probably learn a lot about how we can partner our own AI deeper with our own orgs data.
So it's interesting to see what will happen.
All right.
I want to talk about these AI agent guidelines at this Stanford class.
So this comes out of Stanford's CS336 course, where they've published on the formal guidelines for how AI coding assistants should behave when helping students with the assignment contained in that repo.
And it essentially constrains tools like Copilot and Claude to act more as like a Socratic tutor rather than something that generates solutions for the students.
So it does things like drawing this hard line between like what's acceptable to give to the student, like explaining concepts, reviewing code that is written by the students, you know, giving guiding questions that help them go find the answer on their own versus like off-limit behaviors like writing code or completing to-dos or refactoring code.
And, you know, so this comes from a course at Stanford that's, you know, really about large language models and how, you know, they're a central component of a lot of engineering systems now.
And it's designed to really help students understand the core capabilities of models.
And so I think it's a really cool thing that, you know, I actually do think there's a lot of ways to apply this outside of coursework, but I wanted to hear what you thought about it, Andrew.
I love the idea of constraining and using the harness to kind of invoke a teaching or a question-based approach for working with a student to get to a level of understanding.
This actually takes me right back to when I did the hackathon earlier this year with The Atlantic because I created a virtual classroom experience and within that bounded experience there was a Socratic AI that I had.
put there that you could work with and ask questions about the articles you're reading and about the essay you're writing.
And I gave it a lot of really strict criteria about what it could and couldn't do and its role in guiding them to an answer, not providing it.
And for me, it was a really interesting flip on the whole experience of using AI because I think we're typically more transactional in our usage, but there's so much power in harnessing it for an education kind of use case.
So I really love this.
visualization of the Claude and agent configs to kind of create a teaching environment.
And I, you know, hope as well that the students stuck with it instead of just, you know, maybe altering.
those files because yes, remember these aren't true guardrails.
A true guardrail would be a closed system that they're accessing and those, maybe they have to log into this server on the institution, right?
And in there the teachers scoped out the learning module and they don't have permissions to modify the actual agent configs.
Like we could really go old school in terms of like actually utilizing Linux technology to bound people in these learning environments.
But I don't think we're ready for that conversation yet.
Yeah, that's an interesting take.
Well, you know, I think this is one of the most underrated usages of AI, like using it as a Socratic teacher.
You know, I feel like we're all aware it's possible, but we just want to get to the answer.
We don't want to, like, challenge ourselves all the time.
Totally.
Yeah, but you know, and because of that, there's a lot of people out there saying that like AI is causing society to lose like depth of knowledge.
You know, like we don't think as deep as we used to when we're using AI.
And I absolutely think that's a valid concern.
But part of the solution to this is forcing AI to be more Socratic and to question you and to guide you on a journey to learn for yourself rather than giving you all the answers.
So it's really cool to see this showing up in like Stanford coursework.
And I think everyone should be doing this.
So, you know, you can have your own Socratic Challenger like built within to your code base so that anytime a developer contributes to it or works with it, it encourages them to make sure that, you know, the human that's running that agent is doing the right things.
Right.
And in particular, you know, here at Linear B, we've been talking a lot about, you know, the challenge of sharing skills.
which are essentially actions that we've turned into a repeatable AI capability.
And we've even been looking at how do we best connect Linear B itself to these skills so that people can use us as a part of their daily workflows, just ingrained into what they're doing.
It's actually pretty amazing how you can change the behavior of an autonomous or semi-autonomous agent by just giving it some guidance on how to challenge the situation.
you know, yeah, you can cheat and go around it.
But, you know, most people, most developers in particular, just look for the easiest path.
And if you just give them the thing that, you know, helps them go down that easiest path in the most natural way, you know, that's a really powerful thing that you can give to your team.
I got to say too as well for this one that...
This is a really learning-focused kind of article.
And if this catches your interest at all, make sure that you check out our episode we had earlier this week.
We had Karthik Ramgopal, a distinguished engineer from LinkedIn, talking exactly about how to build this kind of learning culture within your engineering org.
He gives a lot of really great tips because he and his team have shipped a lot of really foundational, agentic layers.
So be sure to check that one out.
All right, let's move on to the Trust Factory, a new article from Kent Beck, who, by the way, I just feel like Mr.
Beck has been just doing, like the AI era has been like the biggest validation of his approach to software engineering.
Like he's just doing Victory Labs telling everyone that he told us this was coming.
But in this article, Kent Beck argues that AI-assisted development is creating this dangerous imbalance where teams are generating code faster.
then they're building trust.
And that mismatch is unstable and unsustainable with a painful correction likely coming from any organizations.
And as a part of this, he went back to some classics like extreme programming to make the case that the practices from that, like paired programming, continuous integration, automated testing, observability, you know, those weren't just like productivity tools.
They were a factory that you built that built trust in your software delivery lifecycle.
And they incentivize trustworthy behavior as well.
So, you know, we're in this era of like vibe coding.
He called it like single player AI development model, where, you know, this is really undermining trust on multiple fronts because AI at the end of the day is optimized to satisfy a prompt rather than to address real world correctness.
The point that I think he's trying to make in this article is it's time to really like deliberately slow down with AI assisted development to ensure that you're verifying correctness, improving structure, maintaining that human collaboration feedback loop and reinforcing like the long term purpose of your engineering organization.
So, you know, this is this is opinion driven.
It's very philosophical, but I feel like he's really addressing core challenges that.
just about every engineering leader out there is feeling right now.
Yeah.
And I'll say the actionable point that you can take away from this, if you're listening and wondering, how can I introduce these deliberate reviews and slowdowns to my processes to first start by using the same things that you're using to go fast, to introduce some new, what I call them speed bumps.
So with my skills, for example, that I use to do development.
I have a skill called scrutinize.
And scrutinize is a general kind of adversarial prompt that comes in and tries to deeply understand and...
basically poke holes in current approaches and things that it sees things doing.
And it operates with a level of blindness because you don't want to contaminate it with all of the work that you've been doing up until that point because you wanted to come in with fresh eyes and give a new perspective.
And specifically, you're telling it to make me slow down, find problems.
What am I missing?
Where are the gaps?
Because ultimately, when you're going with these skills, you're going to be running really fast and making calls along the way.
your harness is probably going to be presenting some options and you're going to be picking them and you're going to feel like you're in control.
But at the end of the day, you're being guided down what could be the wrong path.
And so occasionally stopping before you get too deep and using this kind of targeted, um, look, let's look, let's review what we've been doing and find problems with it approach.
And then like writing that down in some capacity, uh, and then seeing what the original session even considers about those arguments and those points.
Now you're having a dialogue about what could be better and what could be worse.
And it really actually helps you be more deliberate about the code that you're writing and reviewing.
It helps you have a more foundational review process because now you need a place for all of this back and forth to live.
And guess what?
Now you're back in PR reviews.
And maybe it's two agents talking at each other in a PR review.
But chances are that's a really great artifact for you to have moving forward.
So these are some of the things you should be thinking about to reintroduce this deliberation, this preparation into your process.
Yeah.
And I think the reason this is so important is that there's this, if you have this tight collaboration between the human and their code and their AI around it, you know, you're able to make iterative improvements as you go along the way.
And those iterations compound over time.
So yeah, I really like this core argument.
You have to have this trust factory within your organization and think about what you're doing to systematically establish better trust across your engineering team.
So this is like having the visibility into your processes, into your systems, into the things that are impacting productivity and developer experience and taking action on those things to make those systems better.
All right, Andrew, tell me why I don't love SystemD timers enough.
I love this article, but I also felt very targeted when I saw this in our lineup because I'm like, our producer knows me too well.
He knows I'm going to go off on this massive rant about system D timers or launch D if you're listening to us from a Mac device.
I really love this exploration back into some Linux primitives about technology that's sitting right under our nose, right in the command line, that's in everyone's base machine, that we're just not taking advantage of enough.
And instead, we reach for these new shiny AI branded tools and CLIs.
And this is just a good reminder that sometimes all you need is a good Linux kernel.
So this is a dive into systemd timers, which you can use to set up lots of workflow kind of on your machine.
automated fashion and it has a lot of sophistication actually built in to prevent things like thundering herd and accidentally kicking off a bunch of workflows at the same time.
And it also helps you understand recovery and keep logs that actually rotate instead of just filling up on your hard drive.
It's almost as if the people who created Linux thought that we might need to create logs and run stuff for a long time on the machines.
And so there's stuff there to do it.
So again, this is just a good old reminder that there's something better out there than the cron tab.
And this is a will point you in the right direction.
It's been a long time since I've looked at cron configurations, but if I ever have to go back to it, I'm sure I'll consider this.
All right.
Well, that's a wrap on today's episode.
So thank you for spending part of your week with us.
Your time matters.
And we're really glad that you decided to spend some of it here.
We're Linear B and we help engineering teams solve productivity challenges every day.
Everything we got into today comes back to one tension a lot of teams are wrestling with.
AI is writing code faster than ever and your SDLC is struggling to keep up.
Linear B is an engineering productivity platform that shows you where AI speeds delivery and where it stalls.
It automates the bottlenecks so you ship faster with confidence.
If today's conversation about building a trust factory landed with you, Come see what we do over at linearb.io.
And if you got something out of this episode, the best thing that you can do is rate our show or give us a thumbs up wherever you're listening.
You know, those ratings help more engineering leaders find us and hear the great word that we share with them and of our community.
So let's keep that conversation going.
Find us on LinkedIn, on Substack.
You know, we love to go deeper into these conversations with our community.
So thanks again for listening.
We'll see you next time.
See you next time.
Are you looking for a trusted way to evaluate engineering productivity platforms in the AI era?
Gartner just released the first ever Magic Quadrant for developer productivity insight platforms, and Linear B was named a leader.
As AI changes how software gets built, engineering leaders need better visibility into productivity, bottlenecks, and AI ROI.
Download your complimentary copy of the Magic Quadrant to see why this category matters now, how the market is evolving, and why Linear B is recognized for its vision, execution, and workflow automation.
Check the show notes for the link.