# AI Engineering Bottlenecks and the Dark Factory

**Podcast:** Dev Interrupted
**Published:** 2026-07-14

## Transcript

Welcome back to Dev Interrupted, brought to you by Linear B.
Quick note before we start.
My guest today is Cameron Ettezzati, CTO at LaunchDarkly.
He spent 30 years watching one pattern hold true.
And that's the moment you speed up engineering, the bottleneck moves somewhere else.
Writing code used to be the slow part, but it isn't anymore.
Now the pileup is in review and testing and everything downstream.
And this is the shift that Linear B pays attention to, and it's why they invest in this community through Dev Interrupted.
Because once your AI helps your developers write faster, the honest test is what happens after, when your teams review it and ship it.
That's where you find out whether AI is actually helping you deliver and find where the new bottlenecks live.
These are things that we circle around in our conversation today with Cameron, and I'm delighted to bring him on the show.
Cameron, the entire...
Software engineering world right now is obsessed with efficiency.
I feel like that's all we talk about here on the show.
People and all of their problems ultimately boil down to efficiency.
And we're getting a lot of finger pointing that vibe coding is the blame between some of the benefits and also the drawbacks of this efficiency problem.
And there's a lot of promise behind autonomous development loops that are falling short, that are getting plugged by makeshift solutions.
And we're all just engineering with duct tape sometimes.
Behind the hype, a lot of engineering leaders are noticing a quieter, more troubling trend in the systems they've relied on to build and deliver software for as long as they remember.
And the systems are feeling more fragile than ever.
And bugs are slipping through.
Things are coming apart at the seams.
And it feels like it's not meant for the volume of work we're doing these days.
And at LaunchDarkly, you argue that, you know, we're fundamentally misdiagnosing this problem for the most part.
And it's not that developers are getting lazy or they're unskilled with AI.
It's that the processes and guardrails and delivery mechanisms and pipelines that we built for the deterministic world of yesterday are simply breaking down in the probabilistic one of now.
And to move forward, organizations have to rethink their infrastructure to match the new pace and uncertainty that AI is bringing.
So I'm really excited to dive into all of this with you today.
I know you think about this a lot in your role.
Cameron, it's great to have you here.
It's really great to be here.
You know, you're hitting on things that have been near and dear to my heart in the 30 years I've been a professional software engineer.
I guess I get to say professional.
Some days it doesn't feel like it.
I feel like an amateur these days with the way things are changing so fast.
Well, I think you can claim it.
I'll try.
I'll try.
You know, but the fundamental thing for our company has always been decoupling deploy from release.
And I think that that is even more important in today's world with all the tremendous velocity of things coming into production.
I have a favorite book.
I have a couple of, well, a couple of favorite books of like the software and sort of operations management period of the last 30, 40 years.
It kind of started with Eli Goldratt's The Goal, which is quintessential B-School book on theory of constraints.
And, you know, Gene Kim did a brilliant job in the Phoenix Project.
of rewriting that for an IT space.
But to your point on efficiency, when you just move things around, there's just a new bottleneck in the process.
That bottleneck used to be writing code.
That was the slowest part.
It's just not anymore when you will it into existence by telling the mage behind the scenes what magic to wield and out spits a perfect file of Python or Go.
My sport is what obscure language can I get it to write in this week?
Can we do a web server in ML?
Oh, yes.
Should we do it in Haskell this week?
Because we love Haskell because we're masochists.
I don't know.
We use that as an opportunity to learn, too.
It's like, oh, can I really even use the language to do this?
Yeah.
I mean, let's be honest.
We all do it in Python or Go or hopefully something similar that is Ruby.
Not Ruby.
God, please not Ruby.
Not Ruby.
Don't bring us back to Ruby.
Rust.
Yes, either Rust or if you're in the web, then you're leaning into like, you're doing a React app and you kind of actually getting a lot of sanding away of, remember like in the web dev ecosystem of yore, where it's like there was a new framework every five days.
And if you were a web dev, you had to relearn how to write a website.
It felt like every few weeks.
But now it's like there's so much conformity.
Just because there's so much that's piled up in the training data, it's like we've invested into like what stick with these frameworks.
That's what they know.
Yeah, it's almost a regression to the mean in some ways of like the mono stack and the mono repo is kind of coming and rearing its head again.
But, you know, all these, what it really gets down to, though, is like all of these tools have pushed us to the point where, you know, the PRs are stacking up like crazy.
The PR volume is more than humans can get through.
The testing volume, the amount of tokens I spend on testing versus actually writing, it's borderline obscene.
You look and you see these frontier model companies that provide these coding agents.
And I just visualize Scrooge McDuck on that pile of gold swimming with a backflip and money squirting out of his mouth.
He's in the vault.
In the vault.
Yeah, totally.
He's in the vault.
Yeah, yeah.
Those parts of the process, though, are now where the bottleneck is.
And you have to find tools and technology that help you automate that, help you power through that, and help you do it without risk.
The calculus has also changed.
You brought up probabilistic and deterministic models.
We love determinism.
It's why I got into this business.
There's something about my psyche, and I think a lot of people in this business were like, you tell the computer, you do this.
The computer does exactly that, barring a hardware failure.
That doesn't exist anymore.
I ask the same question twice.
I get two different answers from the same model, let alone trying a competing model on this.
And that sits a little, I mean, it almost gives you a little bit of heartburn.
So people are looking for solutions that bring them back to a deterministic outcome in a probabilistic world.
That comes from guardrails and from controlling agents.
The corollary to that, too, is as you build these systems that use agentic or inference of some kind in production, the outputs can change even though the code hasn't changed.
Because you put a new model, it upgrades, it's slightly random.
And you have to be able to steer that back to the outcome you want at all times.
So things that tested perfectly in the lab...
used to work perfectly in production.
Scale and unknown unknowns notwithstanding, they don't anymore.
And that upends everything we've been taught, learned, and believe about building software and being good engineers.
The very long answer to that, but I think there's a lot of really cool points that you hit on that you can tell I have a deep passion for helping folks solve.
Yeah, I mean, it's a major problem right now because just like what you were describing, Like you don't get the same outputs.
And so all of the guardrails that we used to rely on now, it's even worse.
We still rely on them, but they're shaky before we relied on them, hopefully, and they were strong.
But now we have to rely on them, but they're still shaky.
So there's still some fundamental.
disconnect and a problem.
And then you get these engineers that get kind of caught in the crossfires that are underneath a lot of pressure and mandates and handed new tools and put in new environments.
And given all of the determinism of the way they used to work gets stripped away.
And now it's almost like they're herding a cat that is hopefully going to be deterministic.
And so then you get into, you know, what kind of guardrails.
to make that a more deterministic and predictable system.
So people like you can sleep a little better at night knowing that all the agents running and the tests that are passing and the evals that are collecting on them, they actually do align.
It even goes back to what we said a minute ago of like, you get all these other frameworks buffered away and a regression back to like this mean, you know, that kind of needs to happen in tests too.
You need to understand all this fuzzy noise.
Like, what do you need to not pay attention to?
And then what are the real core problems clobbering your loop every time it runs?
And that's like just a whole new set of problems to identify.
It's also a whole new set of deterministic guardrails to set in place.
And then you get massive systems, like some of the biggest companies we know that we all rely on to ship our software.
And we're watching them all lose the nines on their uptime board.
We're watching that as our own systems become less predictable.
So it's like, oh gosh, like they're falling apart at the seams too.
It's like visible everywhere.
I know you feel it too.
Like you log into all your tools Monday morning and you can feel the API rush on everything that you touch.
GitHub is shaking when you're trying to go check your repos, right?
And so like because of this, I think there's like a high compounding effect everywhere.
And so there's a lot of fragility in people's systems.
I mean, Andrew, you're a practicing engineer every day.
You're in the trenches.
How many times this week did you have trouble with GitHub or Slack, too?
Constantly.
Constantly.
Even systems that I feel like I've relied on and I've never even really seen like, oh, we're experiencing some slowness kind of error before.
And then I see it and I'm like, oh, I've never even, even this service is getting hit.
And my token use got throttled and I might as well.
The good news is I finally actually get a coffee break, you know, in that efficiency place where I'm, you know, now pressured to token max, right?
I get a coffee break because I just can't anymore.
Right, right.
And so then the tokens are becoming more expensive.
And then at the same time, the systems that we're using them on are breaking down.
People are maybe making the wrong bets.
And we've been making maybe those wrong bets for several months.
So now you have compounding effects of wrong bets, bringing systems to their knees.
And folks without the vocabulary to diagnose them, much less the skills to go and do so.
And so, like, in your role, you give back that determinism.
You help people decouple going as fast as possible from releasing things into the wild where they hit apps and phones and production and real-time surface areas.
And so, like, what have been some of the main...
Almost like things that you've had to focus on and building a product space now that accounts for this fragility across the board.
Great question.
Our company defined the segment for feature flags 11, 12 years ago now.
This was the core to our business, and I still believe that we do it better than anybody else on the planet through battle-tested systems that serve 60 trillion flags a day.
and do it with 200 milliseconds or less of worldwide latency through an incredible CDN and process, very high uptime and reliability.
And it's nice to have that because you can depend on that as a rock-solid foundation for the rest of the offerings that then build upon it, whether it's experimentation to figure out A-B testing or observability to see what's going on or guarded releases to put criteria in those releases to roll them back when things don't behave as expected.
The most exciting thing that we launched last week was our new agent control framework that it builds on all of this rock solid technology to optimize your agent pass.
So when you have these runtime non-deterministic actors in your environment, you can goal seek.
Can you find a chain of agents that's correct or yields the better outcome that you want?
And can you change the models to back those?
Can you change the prompts to back those and do it at runtime?
So it's runtime control for your agent fleet.
all based on the same principle.
So it's integrating to the same dashboards, the same tool chain, I would say the same UX experience, but we really care about is the same MCP server now because that is our UX.
The same pieces behind all of that to give you that level of determinism when you want it and keep things on the rails.
I don't want to put an agent on my website, for instance, that answers a chatbot and have somebody ask it to reverse a linked list in Python and blow through all my token budget.
like some well-known companies did in the last few months, wasn't intentional, right?
People are sometimes malicious, but I don't want to be footing the bill for that malice.
And I think that's critical here.
And so I'm really proud of these things we've released.
And then that carries into the next phase of our evolution, which is really about what we call a dark factory, where imagine a world.
where you use an agentic coding agent to build your code.
It checks it in as part of the PR.
It's automatically wrapped in a feature flag.
It's automatically instrumented for an experiment to make sure that it's doing what you say you want to do.
It's observed in production.
It's switched on or off.
And if it's successful over time, you get a second PR that removes the feature flagging because you don't need it anymore.
You don't want it cluttering up your environment.
That's the dream.
And we're close to that.
We've released pieces of it so far.
We'll continue to release pieces.
This is our mission, which is to take that vibe-coded or even, I didn't even say vibe-coded, that software, regardless of who wrote it, and make it operationalize it in production in a way that's safe, secure, reliable, self-healing, and let you get the ROI for the spend and the effort.
I fundamentally think engineering has changed, not as we move the bottleneck, but the folks that took Doritos and Mountain Dew and turned spec into execution, which was me in my early days, no longer exist.
They don't matter in that way.
But the engineering learnings that they did, the schooling, the ability to solve problems, that still matters.
You still have to tell the AI what to build.
And so you have to be the product manager as well as the engineer, as well as the designer.
all wrapped into one.
So your early career engineers need to be more strategic and less tactical than they've ever been in order to be successful.
That's right.
So many skills that used to be above the space where the developer would work are now pulled down into that developer space.
As that developer space itself moves up into natural language, they collide somewhere in the middle.
You get this new kind of fusion role of an engineer who has a very broad...
array of disciplines and they've kind of merged with what we maybe would call a product manager.
They're closer than ever to the customer because now the customer is what fuels their specs.
And so you get this like new kind of development loop with folks.
But there's a really insightful thing you called out in how LaunchDarkly is rising to meet the reality on the horizon, which are these dark factories, right?
We've talked about them actually extensively on the show.
and about how these systems are built and how they're coming.
We've talked about Gastown since it came into existence at the top of the year.
We've been covering how a lot of folks have been meeting the moment and creating these end-to-end agentic development lifecycle systems and ways of tracking them.
But there's a part in there that's really smart that you called out of, you know, you can't apply all of that deterministic mechanisms from before to that probabilistic system and expect to make sense of it.
You have to attack the probabilism with You're putting a type of agent, you have an agentic kind of system where you have a runtime layer for the agents that understands what's going on, what's moving in the systems.
Information is now as important in that IO as like the function calls and stuff as before.
And so now you have a control plane for that.
And that's important because it's like now, instead of having the squirrely tool loving agent in the cloud, touching all your data, it at least has a boss.
that can tell it it's doing wrong or can put it in timeout or take its tools away from it faster than you would ever notice.
And those are the kinds of ways of attacking the probabilism that I think will scale.
We've actually talked a lot about that on the show with folks who are building tooling around that kind of thing just because it's like probabilism becomes like a whack-a-mole.
So you got to get a big hammer and scare them away, I guess.
And there's another thing you said in there too that really resonated with me about, You know, you called it vibe coding, but then you kind of walked it back.
You hesitated a bit.
You're calling out something that, you know, we're noticing too.
And Simon Willison wrote about this recently, about how vibe coding and agentic engineering are getting like painfully, uncomfortably close and hard to tell apart sometimes.
And it really is causing this accelerated collapse between I have an idea and it's in my phone.
So all of these systems are marching us in the right direction.
Yeah, I think you're spot on with that.
There's nothing wrong with it inherently that they're coming together, but there's still some art to engineering that I don't know if the agents will ever catch up to.
My personal belief is there is no actual creativity in AI in the sense of its matrix multiplies, a lot of fancy math.
The type of courses we all sat through with a bit of a random number generator thrown in that turns into an incredibly good pattern matcher.
And on top of being able to match the corpus that it's been trained on, it has such a broad corpus compared to the average human mind, even the exceptional human mind for that matter.
It's got such a broad set of knowledge that the pattern matching is mistaken for creativity.
And I think...
That's the key thing here, which separates out the human in the loop from just purely let the systems go and self-improve.
There's still somebody providing the goal to seek.
The meta analysis of this is really interesting because these systems are essentially goal seekers at the end, find the most likely next token, whatever to spit out.
And there's also this process of, now that I've done that, here's the goal of what I want the behavior to be at the end.
Goal seek for that behavior by nudging along the way and finding that productivity.
To me, that's kind of cool.
Like that's, that's the math that, you know, I get excited about and I wake up with that twinkle in my eyes.
Everything becomes like you, if you can find a way to connect the loop together to itself.
When we talked to Jeffrey Huntley here, he talked about capturing the back pressure, find a way of capturing the back pressure to make it self-propelling.
And that can be really fun for a lot of projects and experiments that before were out of reach for like a determinism, a programming language weekend project.
But now if an idea pops in your head and you have the engineering chops to tackle it and to break down the problem into things that could be implemented, there's a lot of creative spaces that you can work with.
Where, again, the tool is an amplifier of things put into it.
So it amplifies your creativity.
And if you bring that idea to it, there's lots of things that you can learn from and just, you know, be having a lot of like new experiences with.
And I think that that's going to be like important for people to play around and figure out what's coming in the future.
And in the meantime, folks are going to be figuring out within like big companies and enterprises, how do I conform this wild, unmistakable, probabilistic thing to.
Whatever I provide to my customers, where's the value?
How do I make it reliable and tell my shareholders how we've wrangled AI for everybody else?
And so to do that, there's an incredible challenge within organizations to re-skill their engineering team, to realign them around what matters, to identify those early 10x, 100x, 1000x people and figure out what works and scale and distribute.
You know, what has worked at launch darkly?
We've heard a lot of approaches from leaders.
I'm curious what has what you've found momentum with.
We we found it in a lot of ways.
I have some fabulously talented engineers.
You know, I've been at the company six months now after going through an M&A with with the previous place I was at.
It was great exit, great engineers.
And by and large, I came here because I was a happy customer.
And I was impressed with the external view I had of the engineers.
And it's even more impressive when I'm internal.
I love the people I work with and who work in my teams.
They're fabulous.
Adoption's been quite good internally.
I'll give you some honest statistics.
We're at about 61% of all of our check-ins now being written by AI during the process.
100% of the people in the organization use it at least on a weekly basis in some way, shape, or form.
We've done this through a lot of of different mechanisms such as demonstrations, encouragement, metrics.
My goal isn't to tell people, you know, use more stuff, be faster.
It never works, number one.
It's not very helpful either.
You know, it's like, it's like when, you know, somebody tells you, you should be a better person.
What is, oh yeah, okay.
That's super helpful, right?
Yeah, thanks.
Yeah, thanks.
Yeah, be better.
Worst two words to hear.
It doesn't help.
What I like to do is a couple of things.
As a leader, I like to set goals that will be hard to achieve without adopting the tools.
There just aren't enough hours in the day and you can work 16 hours a day, 80 hour, 100 hour weeks for a while, but it's not sustainable over time.
And things that are hard, people will figure out a way to make them easier on them and remove the toil.
And so the tool adoption has been a great tool for this.
My favorite example, I'm not going to name her name, but when I got here, we were in the midst of performance reviews, which I know as engineers, like we all hate to write.
She wrote a tool that looked at all of her Slack, her emails, her check-ins over the last year.
Essentially wrote her performance review for her using an automated manner.
And I thought that was the coolest thing.
I'm like, you got rid of toil.
Who's not doing that?
Yeah, who's not doing that?
That is perfect.
You spent the tokens and you shipped faster.
Now leadership wants proof.
that your AI investment is driving business outcomes.
Linear B is the engineering productivity platform that measures AI impact at the pull request level so you can see exactly how AI is shaping speed, quality, and efficiency across every team and reinvest those gains back into your engineering organization.
Stop guessing at your AI ROI and start proving it.
See how at linearb.io.
So, you know, setting goals to encourage people to remove Toilo by their own volition.
We've done a lot of show and tell, lunch and lunch, whatever you call them type days.
I had a team of mine that got together.
They had an 18-month backlog of items.
And you can say, well, why would you keep something on a backlog for 18 months?
It's because it provides a high watermark.
What is better than that that should go on the backlog versus be just rejected out of hand?
They cleared a third of it in a day.
So the backlogs no longer become important.
What becomes important is the ROI.
And so we look at it and say, is it worth investing the time and the spend?
I have another project here that we rewrote oldest, gnarliest, nastiest part of our code base using Claude.
We did it.
I would have sold it to the board as a one-year project with a team of engineers, eight engineers to do it.
We all know that's a lie because that's really a two-year project if we ever actually got it done.
I've been through a few of these in my life.
I'm sure you have too.
And so you take the cost of eight engineers in Silicon Valley, run that for two years.
You're looking, let's just say conservatively, $5 million spend.
I had two engineers, a lot of tokens, and they did it in one quarter.
So not only did I do that for about a 13th, 14th of the cost, So, you know, 14X cheaper, basically.
But I also managed, and I spent a lot of tokens to do it.
I spent about the equivalent of their salary and tokens to do it for that period of time.
But now I have basically two years plus, a little less, a year and three quarters to get ROI from that project in the marketplace that I also would not have had.
So the real thing is I did it 20X cheaper because I'm now making money off of it.
So it forces us.
to become, to go from theoreticians who thought it was very expensive to build software, so we had to get it right when we put it out there to judge consumer response to it, into experimentalists where we just go, I don't want to say YOLO it, but YOLO it into production, test it, get immediate feedback, and immediately make that change.
And so you put a system like LaunchDarkly where we have experimentation and observability.
You can all of a sudden rapidly run these experiments, learn very quickly, get your product market fit and deliver extremely compelling experiences to your customer base in a lot less time.
But you have to be data-driven to do it.
The last bit of this, I know this is a long answer, but the last bit of this is, you know, 20 years ago, I worked at Amazon as an engineer.
There are 1,200 engineers in the whole company at that point.
And it was a very exciting place to be.
And the concept of two pizza teams had already been thrown around at that point in time.
I don't think we have two pizza teams anymore.
I think we have two slice teams where you can feed the entire engineering team that you need to get the job done with a bunch of agents with two slices of pizza.
But that forces every engineer to think like a frontline manager and direct work and not actually be the hands-on grind of, you know, code monkey is what we used to call ourselves in the old days, right?
We're no longer hiring code monkeys.
We're hiring frontline managers at every level.
It's just you're managing agents.
The great part of that, as somebody who's been in this industry, you don't have to have any EQ to manage agents.
They're going to look right at you and go, you're fabulous.
The smartest person I've ever seen.
What a great idea you've got.
Right?
They're going to tell you that no matter how much you abuse them.
I love the man who's going to come on the show and say you don't need an EQ to work with agents is also not going to give the agents pizza.
Wow, what a man I'm dealing with right now.
So I completely resonate with what you're talking about.
It has completely changed the math and what people should focus on.
And it's changed the economics of what I can build and how fast I can deliver it.
You're right that not only could you deliver faster and get the market value faster, but you did it.
earlier when tokens were cheaper.
So then you saved even more than the 20x that you're thinking of.
And when all of it is going to, you know, when all of the tokens fall, so to speak.
And another part of this too that really I loved is, like I said, I've been asking this question of a lot of folks who come on the show who are in your kind of similar position of how do they inspire the change and how did that change take shape within their organization?
You fall within the category of what I would call the Gordian knot leader, where you give them the impossible challenge, something that they just cannot solve with what they have available today, or is like an unattainably big goal.
You set it up on a high shelf and you're like, get something out of that cookie jar, right?
And so, and that kind of inspires an extraordinary creative new usage of the tools.
People find shortcuts and you realize that that road you were traveling is no longer one you need to trot on anymore.
And those are the kinds of transformations that I think get a lot of gain really quickly.
And other than being obviously putting everything together into an internal ecosystem, so folks are sharing skills, and MCP servers, which are the new UX for how all the departments talk to each other.
The sooner those get centralized, the better.
And so, like, it's all a strategy in terms of aligning those resources so that you can think like, oh, what kind of software can I deliver?
Because I have all these parts kind of like lined up now from how we're thinking about the true cost of creating software.
Because, you know, I'm just going to order one slice of pizza.
And a few engineers are going to eat it and none for the agents, apparently.
Well, it's good that they don't eat pizza, but they do seem to take up more energy than a pizza oven.
That is true.
So they are getting theirs.
You said something there I just wanted to pick up on that was, I think, very, very smart.
You said the MCP servers were the new UX between departments and teams.
That builds on something that the best companies have been doing now for the last five, 10 years, which is they've gotten away from data lakes.
They've gotten away from data warehouses, obviously.
Many of them built data swamps because that's what the lakes turned into.
But the best ones built data fabrics where data was vended internally between teams and data was thought of as a product.
Those companies, those people who thought that way are light years ahead because sticking an MCP server on top of that is a much easier problem.
And that's where the organizations get that 20x return that you were talking about, that speed.
Exactly.
We got to find all those fuzzy context areas that make our job really hard as engineers or as, you know, you called them, we used to be like the code monkeys, you know, like, but what really makes our job hard now is all of the messy context for meetings that we're dragged into and the focus time that we lose and the things that pile up on Asana and in our JIRA tickets and the half-completed PR reviews.
And so, like...
getting all of that into one space.
And MCP has been a great kind of like it solves for distribution.
Obviously, it helps with the uniformity.
If you have the composing layers that you need within it, you can get a lot of internal momentum really quickly.
And so like that's like a baseline change that happens between teams.
Now you get this wonderful MCP interchange between departments.
And behind those departments, the software and the technology that they're picking up and they're integrating into their technology and on your own engineering team, the software that you're buying or thinking about integrating or using to deliver your service to customers, like all of those now, every line item, and I know this is something that you're feeling as a CTO, becomes this build versus buy discussion of why did we buy this?
Do we need to buy this?
And every future thing that you pick up becomes, is it cheaper to buy, build this myself with tokens?
And that then kicks off, obviously, a series of questions about like...
Is this worth my time?
And where should I focus?
And how do you think about that as a leader right now?
It's very salient.
I think it's salient for us as an industry.
We've talked about the Sassiker or the Sasspocalypse.
Sasspocalypse.
We're covering that a lot here.
Yeah, I like Sassiker, but it just feels more brutal to me.
I think it's because the industry got painted with a broad brush because of this problem without doing the deeper dive.
And we're seeing that come back out.
Valuations are sort of starting to fix themselves where there are companies that deeply got beaten up in there and deservedly so.
There are companies that are in the middle that are tailwinds from this.
And there are companies that, of course, frontier model builders, those type of things.
I think the build versus buy decision calculus has definitely changed, but a lot of folks are still approaching it very naively, ignoring the operational costs of this.
I'll pick on something like LaunchDarkly.
If you ask an agent to do feature flags that are super simple, right?
Agent will put them in for you.
You have a config file.
Great.
I have to redeploy a config file every time I want to launch it.
It takes time because the physical speed of light, network bandwidth problem, you can't ship instantly.
You can't roll something out in 200 milliseconds.
It's physically impossible to do it.
But you can implement the basic functionality.
But when you start to look at...
I'm running a worldwide consumer brand that needs to do this in 200 milliseconds when something goes wrong before the damage gets excessive.
Then you start to see the value of the companies that have infrastructure and economies of scale to provide this.
And those don't go away with AI.
Those, if anything, are multiplied.
The second part of this is while the agents are very good, they still have context windows that are better spent on the things that matter.
Your code, your project, your business, and the things that aren't fundamental to that where somebody else can do it with the economies of scale still have tremendous value in the space.
And I think that will hold true for a long time.
I can't for the cost of what the average customer pays us even put an offshore engineer who can keep it up with the same level of reliability and definitely not at the speed that we deliver.
And so there's tremendous value to me in that.
I think.
I think though, as a CTO, you know, I am looking for things.
Are you just a tool that visualizes something?
You know, there are a lot of those in the marketplace.
I don't need a visualizer.
Are you just, are you a CRUD service that has my data that you're storing in a CRUD database because I track, you know, a project from A to B to C, right?
There's not a lot of value in that because it's small scale for me.
It's, it's very simple to implement.
It's very easy to replace.
And so we're looking.
I mean, we look ourselves at vendor consolidation as a very real thing.
Of course, the money still gets spent.
We're all just blowing it on tokens, right?
Right.
That's where it's all going.
But we are consolidating a lot of things behind the scenes where this is duplicative with something else except for this one feature.
Well, I can build that one feature and then use the vendor that provides most of it for us.
The last bit of this is as I look at a vendor, you know, the number of people who come and want to demo a UI to me, I don't care anymore.
Like none of us should care about the human UX other than the first setup and the help file because the MCP server and good sets of documentation about how it's supposed to behave, they all just get fed into my coding LLM.
I don't spend, you know, three weeks learning somebody else's SDK anymore.
I feed the, I put the docs, docs and clawed code and say, here's the docs.
Here's the other side of that.
Connect the two, please.
And I have an answer in 15 minutes.
Hopefully, hopefully I can one shot it.
If not, okay, I'll iterate a few times.
You're smart to call out how you should spend your tokens on things that are providing value to you and your customers that the economies of scale favor you to do.
fights the system that you're in in this regard.
And there are definitely going to be entities and organizations and technologies that are better aligned to serve that maybe particularly niche for you kind of business need way better, way more efficiently than you can build it.
Because just building, it's one side of it.
Then you also have to maintain it.
We all hate the cost of keeping the lights on.
Why would you want to magnify that cost for stuff that is falling so outside of your domain?
and what matters to your customers and what makes your engineering renowned, that it just becomes a distraction over time.
Don't bet on distractions because those distractions become more expensive as inference becomes harder to get.
And so it really kind of influences that decision.
It's kind of like an external pressure as well.
It's the same.
I mean, the business fundamentals haven't changed.
Focus on your core business.
Focus on the outcomes.
We're all outcome-focused now, which...
I don't think everybody was in the past.
We've all had to become outcome-focused, which means we're all now goal-seeking because that's how the tools function.
They're goal-seekers at the end of the day, and we all need to do our part for whatever business we're in to get to that outcome.
The tooling behind the scenes will fall into place.
So what are some of the problems you're thinking of solving in the future, maybe that your customers or users aren't even thinking about solving yet because you are on that forefront as the domain expert there?
Yeah, as I mentioned earlier, the two things that really stand out to me are the control of the indeterminate or the probabilistic runtimes where that agent control at runtime is important.
And it's not the agent framework.
There are a lot of really good ones out there.
Anthropic has theirs.
Amazon has AgentCore themselves, which is excellent.
There's some open source ones out there.
That's not so important as corralling the behavior to make sure that what's going on there manages to match what you want from your own strategy to achieve.
So we are determined to help customers through that and help them optimize their environments for that.
The second bit of that is the dark factory.
Regardless of what your dev tool chain is, we all have our favorites, whether you're GitHub or GitLab or Mercurial or whatever you like for source code, whether you're CircleCI or ArgoCD or whatever you like for a build system, GitHub Actions, whatever pieces you have along the way, the paradigm of a dark factory still applies.
You can look back to Henry Ford, for instance, getting away from everybody building a car single piece by single piece by single piece.
And change it into, we have the steering wheel expert, we have the tire expert, we have the welder.
Getting into that assembly line factory for producing factory, that assembly line looks different for every manufacturer.
But the fundamentals of mass production are universal.
And we aim to be the best provider of the instrumentation to help folks let their agents and let their agentic workflows run through the path.
of a dark factory.
If you speed up one part of the engineering lifecycle, the bottleneck just moves somewhere else.
Writing code used to be the slow part.
Now it's the pileup of pull requests waiting on review and the testing that has to clear before anything ships.
AI made your developers write faster, but turning that into faster delivery is the harder problem.
Linear B is the engineering productivity platform that reads the signals in your Git workflow to show exactly where AI velocity is getting stuck.
And then it automates the fix so that faster code means faster delivery.
See where your delivery slows down at linearb.io.
That's such a fascinating way to envision it as well because, you know, in the factory space, in the robotic space, that was the problem that they were fighting the whole time that we got to live in our nice, like, you know, we're in zeros and ones of space as computer scientists.
And if we want to engineer something new, it's ultimately just the same light on our...
you know, some rocks that we tricked into thinking, right?
But the people that are making factories, like they had to like, they got to lay down the conveyor belts.
They got to do all their sorts of stuff.
And when that next iPhone comes out next year, they got to tear down the whole thing and respect it and build it back out and figure out where all the people and parts go.
And you're right that like the science of that mass production doesn't change scale.
You get these incredible business scientist folks, like you go to a factory in Japan and...
like on the Ford or like on the Toyota assembly lines and they have the circles that are drawn on the ground and the person's supposed to stand there for like, you know, an hour.
And then someone comes back and says, like, what did you notice that was wrong?
And if they said nothing, they stand there another hour.
So like that in that world that they lived in.
allow them to produce at scale, create the physical world that we live in.
And now, because all of, we used to be that, you know, Ford assembly line where, oh, we're all going to hammer the one car together and build it.
And then voila, here's our product.
We're taking it to the market.
Now you're so right.
We have to think about how do we compartmentalize it, break it down into this virtual assembly line.
We have to think of it as like a factory where stuff is coming in and then coming out at one end.
in a finished route.
And as much of that in there is automated and has a clear process.
And when it's at this station, we know exactly what station it's going to next.
And I think that's going to be a big fight for folks that have really enjoyed living in the wild, wild west of software engineering.
So I think that's a big challenge to get people on board with.
I agree wholeheartedly.
I think, too, you know, we get to be the digital end-on cord.
To use your Toyota metaphor, which I love, you know, the end on cord is one of my favorite, favorite pastimes as is, as is Kanban, which, uh, and, and, and being able to look at these things.
I also think, you know, as, as we, as we come back, the, the dark factory is real.
We don't, when I go buy a car, uh, or, you know, whatever, I don't really think about how it's made.
Now I, I bought a car and I got from the manufacturer.
This is some years ago.
The manufacturer sent me a video of it going down the assembly line, like my car in particular, which was really cool.
As a nerd, it was super exciting to me.
Not going to lie on that one.
But I don't really think about it, to be honest.
I don't think about there are 17 steps in the paint-by process.
It doesn't matter to me.
And I want software for people to be like that, too.
I want to provide the systems that make it so ideas literally materialize.
And when they materialize, they're robust, reliable, scalable.
At the end of the day, that's what business is all about.
It's about solving a problem that exists for people in a way that they wouldn't have thought of themselves or couldn't do at cost themselves.
And that's how you create value.
That's what we believe we do for companies.
And our customer base seems to back it up.
And I think every business is in that space.
In that video that they sent you to, it's as fun as it is, it's like a token and a memorabilia of the thing you bought from them.
And, oh, I'm one of their customers, right?
If you think about it, it's also a flex because their engineering system is so well harmonized and the end and completely instrumented in a physical space that they're like, all right.
We can't at this point.
We're just champagne problems.
Can we get a video of every individual customer's car getting made and then create a marketing campaign to send it to them?
And the answer ended up being yes.
And that's like a perfect merge of an executive and a marketing and an engineering all on a very high level executing a goal that to you is just like, oh, it's this fun keepsake of when I bought my car.
But it actually sings to, it's a testament to the system.
that they've all built together.
The funny part about that, this sort of follow on that I wasn't going to share, but I'm going to anyway.
Now, three years later, I got a new car.
Same.
In fact, same company, same model, just three years newer.
I was leasing them at the time and, and the new, the newer model did not come with the video and I was crushed.
Crushed.
See, now they've set these unrealistic expectations and.
You see, they are dealing in the physical factory world.
So maybe when they had to tear the factory down to make that car model factory for three models later, they just couldn't get the camera up on the assembly.
I have no idea what went wrong.
I wasn't, I wasn't gonna, I still bought the car.
The video was not the make or break on that one.
All right.
Well, on unnamed video car executives, if you're listening to this and you've scrapped a video production system recently that goes to your customers, maybe revisit it because it's a special, you know, cherry on top.
You know, Cameron, this has been such a really fun conversation.
It's been insightful for me and really great to get kind of like in your head about how you're thinking about these problems.
I think the space in which like LaunchDarkly is working in order to keep our world from falling apart at the seams is so critical.
And it's great to hear and see how forward thinking that your team is.
And if folks want to get more engaged with what y'all are building, learn more about how you are putting guardrails on the probabilistic world that we live in now, where can folks go to learn about the latest and greatest?
Well, of course, please come to our website, launchdarkly.com.
And we're going to host a seminar in just a couple of weeks with replays available on our agent control platform.
We called it AI configs internally originally.
Agent Control Platform.
Those pesky names, they really stick.
Oh, don't let me leak the code names or I'll get sued for something, I'm sure.
But the Agent Control Framework has a wonderful set of demos.
I've got a great talk coming up that'll be broadcast with Edith Harbaugh, our CEO and founder on this, along with Marek Polis, who's our head of AI.
And the three of us discuss what it does with a great demo.
And I'm super excited about it.
I'm going to share the last little bit as we had a demo internally where we taught it to play SimAnt, which we all remember from the late 90s.
I love SimAnt.
And so we built agent fleets that could play the game and we used our control platform to optimize for the right outcome.
And it was a super cool internal demo.
a game that's as near and dear to me as Super Mario was on Nintendo.
No, seriously, you can't leave me on that note.
I'm like right here being like, oh, and me, I want to boot that up.
I want to play SimEarth now.
Okay, well, you're going to send me a GitHub repo when we get off this call, and I really want to learn more.
So thanks for sharing that.
And also to those listening, you know, we're going to make sure that we get all of these links in the show notes so you can go and learn about these resources, but also go and listen to Cameron and...
and learn more about what the leaders at LaunchDarkly and how they're thinking about the space.
It's great to be here.
Thank you for having me.
It's been a lot of fun.
It's been a blast for us too.
And just to wrap things up at the very end here for those listening, we also have a newsletter that comes out with this episode.
So if you're listening to us wherever you get your podcasts, be sure you pop over to LinkedIn or Substack so you can chat with us there.
Cameron and I are both on LinkedIn and we would love to hear from you.
as well as hear how you're building for the future.
So Cameron, yes, I had so much fun with you.
I can't wait to have you back on the show and best of luck at your upcoming talks.
I know you're going to crush it.
Thank you.
Thank you, Andrew.
It's been a pleasure.