# Why software factories fail without humans | HumanLayer, Warp & LinearB | Dev Interrupted Powered by LinearB

> HumanLayer CEO Dexter Horthy, Warp Head of Product Engineering Aloke Desai, and LinearB COO Dan Lines debate the viability of software factories and why autonomous pipelines stall without human oversight. They unpack nonnegotiable PR ownership, observability, and why incident management remains AI's final frontier.

_This is a markdown rendering of a live HTML page on linearb.io, generated for AI/LLM consumption — it is not a markdown-only site. To get the full HTML page instead, request this URL with an explicit `Accept: text/html` header (no wildcard, no markdown preference)._


```json
{
  "@context": "https://schema.org",
  "@type": "PodcastEpisode",
  "name": "Why software factories fail without humans | HumanLayer, Warp & LinearB",
  "description": "HumanLayer CEO Dexter Horthy, Warp Head of Product Engineering Aloke Desai, and LinearB COO Dan Lines debate the viability of software factories and why autonomous pipelines stall without human oversight. They unpack nonnegotiable PR ownership, observability, and why incident management remains AI's final frontier.",
  "url": "https://linearb.io/dev-interrupted/podcast/why-software-factories-fail-humanlayer-warp-linearb",
  "datePublished": "2026-09-01T12:00:00.000Z",
  "partOfSeries": {
    "@type": "PodcastSeries",
    "name": "Dev Interrupted",
    "url": "https://linearb.io/dev-interrupted/podcasts"
  },
  "actor": {
    "@type": "Person",
    "name": "Dex Horthy, Aloke Desai, Dan Lines",
    "jobTitle": "CEO, Head of Product Engineering, COO",
    "worksFor": {
      "@type": "Organization",
      "name": "HumanLayer, Warp, LinearB"
    }
  }
}
```

```json
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Home",
      "item": "https://linearb.io/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "Dev Interrupted - Podcasts",
      "item": "https://linearb.io/dev-interrupted/podcasts"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "Why software factories fail without humans | HumanLayer, Warp & LinearB",
      "item": "https://linearb.io/dev-interrupted/podcast/why-software-factories-fail-humanlayer-warp-linearb"
    }
  ]
}
```

[Home](https://linearb.io/)

/

[Podcast](https://linearb.io/dev-interrupted/podcasts)

/

Why software factories fail without humans | HumanLayer, Warp & LinearB

# Why software factories fail without humans | HumanLayer, Warp & LinearB

By Dex Horthy, Aloke Desai, Dan Lines

|

September 1, 2026

![Blog_Comprehensive_DORA_Guide_2400x1256_80_84a60586cc](https://assets.linearb.io/image/upload/c_limit,w_3840/f_auto/q_auto/v1/Blog_Comprehensive_DORA_Guide_2400x1256_80_84a60586cc?_a=BAVMn6ID0)

In this special episode, Andrew hosts HumanLayer CEO Dexter Horthy, Warp Head of Product Engineering Aloke Desai, and LinearB COO Dan Lines. They debate why human ownership of pull requests remains nonnegotiable and how to implement "night vision" observability across automated workflows. The panel also explores why incident management is the final frontier for AI and how to get your team excited about building the factory instead of fighting it.

### Show Notes

* HumanLayer: Explore Dex's multiplayer coding agent workspace at [humanlayer.dev](https://humanlayer.dev/).
* Warp Factories: Learn more about building your own open infrastructure software factory at [warp.dev/factories](https://docs.warp.dev/factories/).
* LinearB: Get night vision for your software factory and improve your team's predictability at [linearb.io](http://linearb.io).
* Follow Dex: [LinkedIn](https://www.linkedin.com/in/dexterihorthy/)|[X](https://x.com/dexhorthy)
* FollowAloke: [LinkedIn](https://www.linkedin.com/in/aloke-desai/)

### Transcript 

_(Disclaimer: may contain unintentionally confusing, inaccurate and/or amusing transcription errors)_

\[00:00:00\] **Andrew Zigler:** So without further ado, let's go ahead and get started here on the Software Factory Roundtable, brought to you by Dev Interrupted from LinearB. And today we're gonna start by talking about the software factory is here, and maybe we're not using that language yet in our own teams, but we're certainly using many parts of it.

\[00:00:21\] **Andrew Zigler:** And we're gonna do intros for our amazing guests that we have here. And I pulled out some questions just from the industry about, uh, what people are asking, uh, their leaders and each other about a factory and what makes it successful. If we have some time at the end, I'd love to pull some Q&A out of the audience, so please be dropping questions, please be chatting with each other.

\[00:00:43\] **Andrew Zigler:** This is a software factory safe space for us to nerd out, share resources, so would love to just see lots of activity in the chat while we're blabbing away. So while we dive in here, just before we do intros, we're gonna, uh, run a poll, 'cause I would love to know just from folks that are here \[00:01:00\] where you currently are in your software factory journey.

\[00:01:03\] **Andrew Zigler:** So how much of your SDLC already runs like a factory? So you're gonna get a pop-up now. This is a, a Zoom poll, and if you can just go ahead and flag for us just generally where you think you fall in the software factory story. Uh, and I'll ask my panelists here with me today, maybe look at the question too and think about what your own answer might be, and we can use that to kick off with our introductions.

\[00:01:28\] **Andrew Zigler:** So s- folks, just go ahead and answer the poll. Uh, again, just taking a, a, a temperature check on how much of your SDLC is already running like a factory. And now that we have that running, I'm gonna go ahead and jump into our introductions for the day. So I'm gonna just start in the top left and hand it over to each of them to introduce themselves, tell them a little bit about what they're working on, maybe even answer the question.

\[00:01:50\] **Andrew Zigler:** About 90 seconds each for a ph- each other, so I'm gonna start with Alok. Alok, would you like to introduce yourself?

\[00:01:56\] **Aloke Desai:** Of course. Thanks for having me. So my name's Alok. I'm Warp's Founding \[00:02:00\] Engineer and Head of Product Engineering. Uh, I've been at Warp at, at Warp for a long time, six years. Been battling agents for, for quite a while now.

\[00:02:07\] **Aloke Desai:** Um, it really started with, with interactive agents, as we all did, and now I spend all of my time building software factories and really helping companies, uh, build factories where they can show and demonstrate ROI, really help them improve it over time, whether that's quality, cost, or some combination of both.

\[00:02:24\] **Aloke Desai:** Super psyched for this discussion.

\[00:02:25\] **Andrew Zigler:** Amazing. And Dan, I'm gonna hand it over to you next

\[00:02:29\] **Dan Lines:** Awesome. So I'm Dan Lines. I'm LinearB, uh, founder and COO. Uh, before that I was a VP of engineering. Now I spend a lot of time at LinearB. I'm working with CTOs, VPs of engineering. Obviously software factories is, like, the hot topic, so we talk about it a lot.

\[00:02:50\] **Dan Lines:** And, uh, I would say there's a wide range of what I'm seeing out there right now of where everything stands with software factories, even though it's, like, a terminology that's \[00:03:00\] probably been around for, like, 50, 60 years now. So thanks for having me on the panel, and I think we're gonna have a awesome discussion.

\[00:03:07\] **Dan Lines:** Let's go.

\[00:03:08\] **Andrew Zigler:** Amazing. I know the results popped up, and, uh, we're gonna get to those in just a moment, but Dex, I wanna hand it to you to go and introduce yourself

\[00:03:18\] **Dex Horthy:** Let me get off mute. Uh, what's up, y'all? I'm Dex, uh, CEO and co-founder of a company called HumanLayer. We build a multiplayer coding agent workspace.

\[00:03:25\] **Dex Horthy:** It's got building blocks for software factories. We spend a lot of time working with teams, uh Solving hard problems in complex code bases, so hundreds of repos, hundreds of engineers, you know, five, 10, 15-year-old code bases, um, and how can we raise the floor, make sure that everybody on the team is able to leverage agents for the things that agents are good at.

\[00:03:47\] **Dex Horthy:** And as the name might, uh, imply, uh, ensure humans are still installed at the right points of the workflow in a very high-leverage way where, um, we can get the most out of AI while maintaining a really high quality bar and maintaining commitments we've \[00:04:00\] made to our users and our customers and our customers' customers.

\[00:04:03\] **Dex Horthy:** And of course, we do plenty of software factory building and experimenting, uh, and trying to push what the frontier of what works and what's hype internally.

\[00:04:11\] **Andrew Zigler:** Amazing. Well, as y'all can tell, we have some amazing panelists here for you. And one thing that really resonates across all of them and stood out to me is how much they really care about software, making it great and secure and at scale, and I think that's what we're gonna be talking about today.

\[00:04:25\] **Andrew Zigler:** But we're also gonna be addressing some of the pains and confusions and uncertainties of that world. That way we can all get on the, the same page. 'Cause I can see here, uh, just on the poll, uh, results that have popped up, I believe all of y'all are seeing this as well. In the distribution, it looks like most folks fall around a step or two of their SDLC running without a human involved.

\[00:04:46\] **Andrew Zigler:** That means that some part of it, maybe it's code gen, maybe it's a review process, maybe it's something in between, uh, there's just not a, a, a human in, in the loop there currently. And you can see as well that there's many folks that are interested in pushing that \[00:05:00\] further, like they're, they're testing w- how far can we take this kind of automation across the SDLC?

\[00:05:05\] **Andrew Zigler:** And to those of you that are just starting to look at it, don't worry, you're nowhere near behind on this journey. In fact, I would say that you're way, way, way far ahead from most folks, just because this is a really early topic, and you're just in, like, a, a, a bubble right now of folks that are really nerding out about it.

\[00:05:20\] **Andrew Zigler:** And just the last one here is myself, Andrew Zigler. I'm our host at Dev Interrupted. I'm also Go-To-Market Engineer here at LinearB. So again, we just kind of recapped, uh, the idea of where everyone is on running a software factory. Are you calling it that? Do we have parts of it within our own world? And as we saw from the poll, the reality of that is, yeah, there are many parts of this that we're acknowledging now are more like a factory.

\[00:05:43\] **Andrew Zigler:** So today we're gonna be diving into how do you talk about success and the impact of that factory? Because many engineering leaders, I know that y'all here in the audience are, are, are really, uh, like y- you're, you're trying to optimize and build for the future, but you \[00:06:00\] also have to answer to budgets, and you have to be able to convey to leaders who are non-technical why we're doing this and how we're actually making progress over time.

\[00:06:10\] **Andrew Zigler:** So with that, I would really love to start with our first question, and this is about how do you measure successful outcomes in a software factory? So I'm actually gonna stop sharing so that we can see each other's faces and have a nice, lovely discussion with this. And, uh, Alok, I'd love to hand this to you first to go ahead and open us up about soft- uh, uh, successful outcomes in a software factory

\[00:06:33\] **Aloke Desai:** For sure.

\[00:06:34\] **Aloke Desai:** Well, I think if you think about a factory, regardless of the domain, there's kind of two things people are optimizing for, right? Whether that's code or product, building a car, building whatever. It's really like, what is your input? How much product are you making? And what is your cost per item? And I think that's true in the fact-- in software factory world just as much as it's true in any other, uh, factory.

\[00:06:56\] **Aloke Desai:** And so when I think about successful outcomes, it's really like, can you measure \[00:07:00\] and demonstrate that you're increasing throughput and maintaining reducing cost per item? And where cost per item here is like, what's your cost to build product and ultimately cost per PR. And throughput is how much product are you shipping and how many PRs are you shipping.

\[00:07:14\] **Aloke Desai:** So when I think about success, I think about those two metrics, and I think there's a lot of kind of downstream metrics that are better proxies of, of actually tracking that than maybe those, those two top-line ones. Um, and then also just general quality of, of product as well. Um, I think the mistake that using a software factory can have if you do it, um, poorly, is you start shipping a bunch of really, really low-quality code, uh, that has a bunch of rollbacks or just doesn't work reliably.

\[00:07:45\] **Aloke Desai:** And so to me, the, like, what does success looks like is being able to automate more and more development that continues to maintain kind of high quality in terms of the product and the actual code that backs it

\[00:07:59\] **Andrew Zigler:** Amazing. \[00:08:00\] Dan, would you like to respond to that? I saw you come off mute

\[00:08:03\] **Dan Lines:** No, yeah, of course.

\[00:08:04\] **Dan Lines:** Like, uh, I'm happy that we started here, right? How do you measure? That's, that's actually the first place to start. So when, when I'm working with like CTOs, VPEs, usually they have a lot of pressure coming from their business. It sounds something like this: "Hey, this AI thing is happening. All these other, uh, companies, maybe even our competitors, they say they're moving way faster now.

\[00:08:28\] **Dan Lines:** What are you gonna do about it?" And so I think the first thing on the measurement side, and this is what the business wants, it's our all-around business impact. You gotta have some type of measurement so you can go back to your business to say, "Hey, we actually are providing more value to customers faster."

\[00:08:46\] **Dan Lines:** So at LinearB, and you can choose what it is, but at LinearB, we always start with predictable delivery. Are you delivering customer value on time more often than you were before? And then there's the \[00:09:00\] capacity side, which is how much of that value are you able to deliver? And of course, we track that with, you know, you can do stories, you can do tasks, you...

\[00:09:09\] **Dan Lines:** all the project delivery stuff. And once you get past that, 'cause that's a conversation that you're having with your business, I'll add on to what Alok was saying. Now you can actually look at leading indicators for your factory. Now, we have a framework around this. Our framework's called Apex, but I'll just like rattle some of the leading indicators off that I like to use.

\[00:09:31\] **Dan Lines:** Cost per effective PR merge, gotta track it, right? That's showing, hey, is this, uh, AI actually effective for us or not? Then I like to look at merge rate per developer. Then we look at rework rate. Then we look at assisted PR. So there's kind of all these leading indicators, okay, that we track that show are you actually moving to, you know, a factory or a dark factory?

\[00:09:56\] **Dan Lines:** I'm sure we'll get into that kind of stuff. \[00:10:00\] Um, and that's what we like to track, but at the end of the day, your business is gonna come to you and say, "Hey, is there business impact? Is our customers getting more value?" So we like to balance it with both and, and that's usually like where I go and what I see as like most effective.

\[00:10:15\] **Andrew Zigler:** Dex, anything you wanna add about successful outcomes?

\[00:10:18\] **Dex Horthy:** Yeah, I, I think it makes a lot of sense. I think, I think measuring business outcomes for customers is like really, really hard, and the teams that do this well are like cleaning up. Um, one, one team I know that is like very, uh, well-known for focusing a lot and doing the like product engineering thing of like, "Hey, we don't give developers tickets, we don't give them stories, we give them customer problems," is, uh, is, is GitLab.

\[00:10:44\] **Dex Horthy:** Um, I used to work with a bunch of ex-GitLab people, and it was very much like, "Hey, I don't care how many lines of code you shipped. I don't care how many PRs you ship. I don't care how many Linear tickets you ship." Like none of the... or whatever, whatever, whatever your system is, uh, probably GitLab issues in that case.

\[00:10:58\] **Dex Horthy:** Uh, but, \[00:11:00\] uh, it's like- Cool. Can you measure the impact? Did you make a workflow that used to take 20 minutes, now it takes 10 minutes? Great. That's what we care about. It's not quite the, like, top level KPI of, like, is the business growing? Are we closing new logos? Are we making more money? But, like, how do we measure customer outcomes?

\[00:11:18\] **Dex Horthy:** Um, I think the, like, there's, like, this whole hierarchy of, like, hey, if you can't measure customer outcomes, then maybe measure, like, number of feature ships, output, throughput. Uh, if you can't measure number of PRs or whatever, for whatever reason, measure lines of code. If you can't measure lines of code, measure the amount of tokens shipped.

\[00:11:35\] **Dex Horthy:** But again, like, the amount of tokens spent. Um, and since we're talking about factories, uh, I will, I will mention a book that I loved from the '70s called "The Goal," which was about optimizing, like, physical factories, uh, and basically tackling this problem that we had, uh, in every single factory in the US is you would bring in a bunch of MBAs, and you would optimize, like, one particular...

\[00:11:56\] **Dex Horthy:** E- they would each optimize, like, one particular station in the \[00:12:00\] factory of, like, hey, the thing that stamps the steel things, like, I'm gonna make that as fast as possible, and there was, like, less emphasis on the overall throughput. And I think we're seeing examples of that now in modern software factory building where people are like, "Cool, how do we make sure we're spending as many tokens as possible?

\[00:12:16\] **Dex Horthy:** How do we make sure, like, the review thing is, like, super optimized without zooming out to the overall throughput?" Um, so I think, like, a lot of rediscovery of, like, problems we've had before, and obviously we've applied this to software factories since before AI because this... The, the term software factory is as old as 1968 or something.

\[00:12:35\] **Dex Horthy:** Um, the one thing I think is interesting in that metaphor of, like, software factory versus, like, physical factory is in a physical factory you're making parts or you're making cars or you're making golf clubs or whatever it is, but the, the thing is, like, once the thing is done and on the truck and leaves the factory, it no longer impacts future work.

\[00:12:57\] **Dex Horthy:** And when we're building software, every \[00:13:00\] change that comes out of the factory is compounded into and impacts every future change. So if you ship a bunch of slop six months ago, that is going to-- or bad code or whatever, things that are hard to maintain, that is going to impact every future thing you do until you fix it.

\[00:13:15\] **Dex Horthy:** So that's, I, I think, a really important thing to highlight beyond just, like, the throughput today, but is, like, how does the way you're approaching solving problems today impact your ability to solve problems in a month, in three months, in six months?

\[00:13:29\] **Andrew Zigler:** Someone in the chat is chanting, "Slop loop, slop loop."

\[00:13:33\] **Andrew Zigler:** So I, I total- I, I think that's a really smart call-out is that if you compound the slop on the slop, you're gonna make more problems for yourself later. And it's about having that, like, rigid attention to detail, not just on the individual stations, but on the how the whole thing is moving. Uh, so I think that's, that's a really sharp insight.

\[00:13:49\] **Andrew Zigler:** I also, uh, I would be remiss to not call out that we've almost made it through without bringing up the phenomenon of token maxing, which is just something that I feel like I've covered in every conversation I've had in the last two \[00:14:00\] months. And what's fascinating is you mentioned, Vex, that, like, if you can't measure so-and-so, measure this, if you can't measure that, measure this, and then you end up on tokens.

\[00:14:07\] **Andrew Zigler:** And what we've found is that, like, so many orgs decided to really latch onto that as the first, like, rung of a ladder is a really great way that I've heard that put recently. Um, there was this really great op-ed from Luis Morales, he's the head of AI at super.com. He posted last week, and he talked about exactly this, about how most, uh, orgs, they stepped up to like, "Oh, we'll just measure how many tokens we use," right?

\[00:14:29\] **Andrew Zigler:** And then they didn't actually step further up the ladder of, like, how do we then measure the successful, um, outputs? And then from there, how do we measure the successful outcomes? Like, he sees it as a three-rung ladder. So I think we're all, uh, definitely circling around the same idea here. So I'm gonna just, uh, go ahead and share my screen again and move us into the next question, 'cause this one's juicy.

\[00:14:49\] **Andrew Zigler:** This one is something that's constantly top of mind for me, uh, and it's about ownership. Because in a software factory, by definition, a large part of it is that au- automations are \[00:15:00\] creating and driving the code. And as we know, a PR, up until very recently, was a very deeply human process of, like, you wrote your code, and you opened your PR, and you went, you found your coworker, and you Slacked them or something and said, "Please review my code."

\[00:15:14\] **Andrew Zigler:** And then they said, "Looks good to me," and everyone was happy, and it got shipped, right? It was like a deeply, like, camaraderie experience. But now that's been so fully abstracted, um, that code review has just ended up in a really weird position in the modern SDLC, and I'd love for us to talk about it and about who owns the kind of code, uh, in this world.

\[00:15:31\] **Andrew Zigler:** So I just wanna open this up to whoever, uh, maybe wants to take this one first if they have a strong, strong leading thought I can, I'll, I'll take it Or I can call on it. Go on. Yeah, go for it, Dan

\[00:15:42\] **Dan Lines:** Yeah. It's, it's so-- Uh, like I, I think you're probably pressing on a pain point here. Maybe like the question behind the question like, uh, hey, this area of the process is maybe seeing a lot of, uh, pain as it's like super easy to generate code \[00:16:00\] and all of that now.

\[00:16:00\] **Dan Lines:** Okay, what's the next step in the process? Probably this PR area. I have like a data point here. This came from the LinearB benchmarking, our benchmark report that we did. So 37% of agentic PRs, uh, get merged if your organization is classified as like less mature in the ADLC. So it's like a super low number.

\[00:16:27\] **Dan Lines:** These are, uh, PRs that are like fully created by an agent, and it presses on this pain point, what's the reason that they're not getting merged? Well, probably no one knows who owns them anymore. Kinda like what you just said, Andrew. Am I responsible for it? Whose agent is this? Who's the reviewer, and that type of thing.

\[00:16:46\] **Dan Lines:** So here, here I'll just try to give like some tips around what, what I'm seeing. As you get into the AI DLC or the ADLC, have a plan. Like again, the best CTOs or VPs that I'm \[00:17:00\] talking to, they actually have a plan of intentionality of how are we gonna handle these agentic PRs now that humans are like less in the loop, let's say.

\[00:17:10\] **Dan Lines:** And the other thing that I, I see them do is say, "Hey, the volume of PRs is like increasing like crazy." Like, as you get more into that software factory, it's easy to create codes. There's so many more PRs. Let's not overlap or like overload our developers, have a plan for that. So I can just like I'll spit out like a few things that I, I see our customers doing and we'll see where the conversation goes from there.

\[00:17:37\] **Dan Lines:** Decide on an ownership plan. Maybe have it automated. With LinearB, we do it with git stream. Automatically assigns ownership. It could be based on like code base area, it could be based on, uh, like feature requests, what area of the product. Just make sure that you have a policy and you have governance around it, like do something.

\[00:17:59\] **Dan Lines:** And then the \[00:18:00\] second thing, I'll just say like a few things. Think about workload reduction. There's so many more PRs now, so what's the plan in place to reduce the workload on the reviewer? Like obviously have an AI code review, but I would say, hey, what I'm hearing, not all PRs are created equally. There's some that are very high risk, there's some that are very low risk.

\[00:18:21\] **Dan Lines:** There's someone somewhere in between. Have governance. Identify, hey, this PR, super high risk. Let's make sure there's a human reviewer. Another PR, like documentation only change, let's not waste time. Human time is like, uh, super valuable now. So like, uh, my overall thing here is like- uh, takeaway from this question, make sure you have a plan.

\[00:18:43\] **Dan Lines:** That's the number one thing, 'cause if you don't PRs aren't gonna get merged and all of that AI stuff you're doing, it's not gonna be effective. It's gonna cost you a lot of money

\[00:18:53\] **Aloke Desai:** I, I think the thing that Dan is circling on is that humans are the ones who still own PRs. \[00:19:00\] I just wanna make that, like, super explicit.

\[00:19:02\] **Aloke Desai:** Uh, I think there's kind of a misconception that when you have a software factory, it's a fully dark factory, and it's going from linear issue to PR merge with no human in the loop at any part. That's not what I think of as a, a software factory, and that's not the only way of deploying a software factory.

\[00:19:19\] **Aloke Desai:** It's like in my mind, I think a factory where an agent realizes it needs a spec, it needs a human to review the spec, or an agent assigns a PR to a human to review is a feature, not a bug. That's how you're gonna get better outcomes as opposed to an agent kind of ripping and writing code that no human reviews until the very end, and then a human has to be like, "This is completely wrong, and now I need to go spend a bunch of time to course-correct it."

\[00:19:45\] **Aloke Desai:** I think when you think about it in those term, those terms, it gets engineers to kind of think of themselves as like developer productivity engineers who are maintaining a factory as opposed to, uh, having to get an influx of PRs that are just \[00:20:00\] sprayed on them where they have no context on what to do.

\[00:20:02\] **Aloke Desai:** And I think that's very, very exciting for engineers as opposed to kind of like, I don't know, demoralizing. Um, and so what I would suggest is make... Like, figure out the right steps or human gates in your factory where you wanna pull in humans. At, at Warp, like, our opinion on software factories is that a spec, and you can define the criteria of, like, ambiguity that requires a spec, should pull in a human upfront and kind of grill them around, uh, what are some of the ambiguity points and how can I resolve them before it writes a formal spec for a human to review, similar with, with code.

\[00:20:35\] **Aloke Desai:** Uh, and then humans are responsible for reviewing that code, but also, like, continuing to improve the factory when you get a PR that's really low quality or you realize p- uh, code just merged that was, like, terrible for whatever reason. And that im- obviously means, like, directly addressing the problem, but thinking about it more from a systems perspective.

\[00:20:52\] **Aloke Desai:** What are the skills you need to, to write to resolve it? Was there a change in model? Like, whatever you need to do at a high level to continuously \[00:21:00\] improve the factory is something that is explicitly, in my opinion, the responsibility of humans, and I think that's how you can get more and more people excited about working this way.

\[00:21:07\] **Dex Horthy:** Yeah, I, I think I, I totally agree that every piece of work needs a human owner. Um, I think, uh, one thing, uh, Dax, the co-founder of OpenCode, had this post a while ago, which is like you will have a bunch of engineers. If you have a large team, you probably have some engineers on your team that are using AI to do the same amount of work with way less effort, and they are slinging piles of slop and then just waiting for se- like put- shifting the whole burden of, like, your entire job, which is to create good working software, onto the senior engineers, uh, which is gonna burn them out really, really quickly.

\[00:21:44\] **Dex Horthy:** Um, and the people who actually do care about the craft of software, if you allow this to go on, will burn out and leave and go find a place where everybody cares about creating good things Um, my kind of like soundbite on this is everyone who says, "Oh, we have too many PRs. We have to solve the too many \[00:22:00\] PRs problem," is like you probably don't have too many PRs.

\[00:22:03\] **Dex Horthy:** If you have this as a pain point, you probably have too many bad PRs because a good PR is a joy to review. If something needs like less than 5% rework, that means that like I'm reading through it and I'm like whether I wrote the spec and the agent wrote the code or someone else wrote the spec and I reviewed it with them or just like they did a good job of steering the agent so that the output code or even like polishing it before they send it to anybody else and I'm reading through, I'm like, "Yep, this makes sense.

\[00:22:29\] **Dex Horthy:** This follows our patterns. This is what we agreed on. You've headed off all of the tendencies of agents to cut corners and do things that don't work very well." Like that's great. I would re-review 1,000 PRs like that and it's not painful. What's painful is I'm reading a bad PR and in my head I'm thinking like, "Oh God, okay, this is gonna have to change and if a human is owning it, then I'm gonna have to talk to them," and they already put in all this time and effort to polish it, whether they read the code or not, but they put in time to make sure it's working and it kind of like solves the problem on the surface.

\[00:22:59\] **Dex Horthy:** \[00:23:00\] And, uh, like that is just a huge both emotional and elect- intellectual burden on the reviewer and if there's a human behind it on the, on the submitter as well to receive that feedback and react to it and realize like, "Oh, it's not done. I gotta go fix it." So I don't know. The, the only other point I'll make there and then I'll, I'll, I'll, I'll hand it back is I have talked to, uh, three CTOs here in San Francisco all working on like, you know, I think it was like 100 plus person team, maybe like 30, 40 engineers, uh, who have found this weird interesting thing where they created a very tight gate of what can be auto-merged.

\[00:23:37\] **Dex Horthy:** So it's like, okay, if it doesn't touch any of these parts of the code base and it's less than this particular size and a couple other criteria that can kind of be determined deterministically or maybe with a small model of just doing a classifier, then it's allowed to be auto-merged. If the checks pass, you don't need a review.

\[00:23:52\] **Dex Horthy:** And that actually was what they found was like It kind of solved the bad PRs problem, but it also caused people to \[00:24:00\] change their behavior. When engineers realized that, okay, if I follow these patterns for, like, what is an auto-mergable PR, the PR numbers went way up because people stopped just, like, lobbing giant piles of slop up.

\[00:24:13\] **Dex Horthy:** And they're like, "Okay, if I can keep this under 200 lines, and I can solve it in a way where it's like it's not-- I don't need to modify the critical core systems, then all of a sudden my job gets like the... My least favorite part of my job, which is waiting for someone else to read my thing and pick it apart, like, doesn't exist."

\[00:24:29\] **Dex Horthy:** Um, and so there's like, we'll see how the risk and the, the, the downside there of things that make the code base harder to work in slipping through despite those rules. But it, uh, it seemed to me like a really interesting lever. If you wanna change people's behavior, you create the right incentives, and the, and those incentives are aligned with the incentives of the business, which is like keep the code base high quality and avoid downtime and incidents, and also, like, the incentives of the developer, which is like, "Okay, cool.

\[00:24:55\] **Dex Horthy:** I wanna ship. I wanna just keep moving, and I wanna produce value."

\[00:24:59\] **Dan Lines:** Yeah, I would double \[00:25:00\] down on that. Like, I, I would say our most-- what I would consider our most advanced customers are maybe, like, the ones running the most autonomously. They have... I mean, policy's kind of a lame, lame word, but whatever word you wanna use, they have a policy, just like you said, Dex, in place.

\[00:25:17\] **Dan Lines:** It gives good incentives back to the development team. Hey, if you wanna get your stuff merged, you have a way, uh, like auto merge, you have a way to get there. Small PRs, low risks, not, uh, not much, we'll call it, I don't know, PR churn or however, however you wanna say it. Um, it kinda gives like a path to that, uh, hey, I can move fast.

\[00:25:39\] **Dan Lines:** You get good dopamine hits, get your work done, that type of thing. Like, I've seen it work super well. And the only other thing that I would say, like shout out to the panelists here, I'm happy that we're able to talk about quality. I think we're, you know, the terminology is slop now, but yeah, if I'm just, like, producing a bunch of junk, uh, nobody wants that.

\[00:25:59\] **Dan Lines:** \[00:26:00\] The other metric that I see our customers sometimes use is, uh, PR maturity So the PR maturity score is basically, hey, when you open up a PR, how many times did we have to go back and forth on it? Was it, like, in good shape, or did we actually... Yeah, you opened, you know, or the agent opened a PR, a human opened a PR, and it's super immature, and it actually took us more time on the PR than actually, like, doing other stuff.

\[00:26:27\] **Dan Lines:** I think the PR maturity metric is a, is a one that I would say is on the rise, and I think it's 'cause of everything that we're talking about here. Let's remember quality matters after we got super excited that it's easy to build code now. You know, m- make sure you're on top of it. Yeah.

\[00:26:45\] **Andrew Zigler:** Yeah. Amazing. I'm gonna move us into the next question here because we're already starting to chew at the corners of this.

\[00:26:51\] **Andrew Zigler:** I think Alok even mentioned it this moment ago, and now y'all are both chatting about it. So I, you know, this really brings us to the next natural point of we talk about the ownership. \[00:27:00\] Obviously, humans still own the responsibility of the code and the decisions that are happening within the factory. The responsibility is not truly getting abstracted.

\[00:27:08\] **Andrew Zigler:** The ritualistic format in which we used to do it is just getting changed, but the real reality of owning that isn't any different. But once you acknowledge that the ownership from humans is definitely still in the picture, there's still an opportunity here to identify which parts of this can we create machinery and mechanics around identifying and safely operating at scale with automations, creating things like these auto merge gates, which really kinda gamify a golden path.

\[00:27:39\] **Andrew Zigler:** We tell them we want, you know, it be this m- number line of codes and this kind of, uh, uh, changes across these kinds of files. Always de-prioritize a refactor over new code, and you create these kinds of, uh, um, uh, really kind of like r- uh, like a, a rubric, like a grading system basically. And by really acknowledging that there's criteria for everything that you're merging, you can \[00:28:00\] start to create these unique gates for different types of security, uh, and, and automated reviews around, like, things like docs that don't need a person, right?

\[00:28:08\] **Andrew Zigler:** So, like, in this world of a software factory, how do you think as a software leader about identifying what in here can actually run in the dark? And when I say in the dark, I mean no humans involved from beginning to end. Maybe you wanna squeeze and squish that definition a little bit, and maybe I'll let you, but if you have a strong idea on it, definitely please lead the way.

\[00:28:30\] **Andrew Zigler:** Uh, who would like to go first?

\[00:28:34\] **Aloke Desai:** I, I can tell you how we measure it at Warp at least, which is we don't think about it as dark versus not dark. Just to e- like echo what I said earlier, to us it's more about how well is the factory running and when does a human have to step in to handhold an agent that's kind of gone awry.

\[00:28:52\] **Aloke Desai:** And I think that's a better metric to track. So we m- call that autonomy, and for, at Warp it's like we have like a 80% autonomy score, \[00:29:00\] which is for 80% of work that goes through the factory, a human never has to kind of step in and commit code themselves or with like another agent to get something past the finish line.

\[00:29:09\] **Aloke Desai:** I think that's more valuable than measuring dark for the sake of dark, because at the end of the day, what you care about right now is like high quality product, and that's, that's right, that is high quality code. And that means to some extent you have humans in the loop at the, in the right places. Uh, and then as an engineering leader, it's like on you to define when do you want a human in the loop and like to some extent that's, that's gonna be fudgeable in like a, a ton of different dimensions.

\[00:29:37\] **Aloke Desai:** Like what's your stack? A lot of our code is written in Rust, so it's not something that, uh, an agent can very easily, um, test locally, for example. Or at least, uh, we don't have hot reloading, a lot of like key pieces, uh, for an agent to test it. Uh, but when we have a code right on the front end, it's obviously like pretty high level, very, very easy to change.

\[00:29:59\] **Aloke Desai:** Uh, and \[00:30:00\] so the kind of like bar for fully automated development, uh, is much lower. So again, for us, I think I think about it much more of like dark versus not dark and more about when does a human have to step in, because I think there are human gates that are deeply valuable, and I think of that as part of a good software factory deployment, not a kind of failure of a software factory.

\[00:30:22\] **Dex Horthy:** That's so crazy. I have the exact-- At least as far as, like, front end versus, like, Rust code, I have the exact opposite opinion, which is like- Ooh ... agents are, I think, I think agents are really good at... Well, let, let me restate what you said and you, you can tell me if I got it right, which is like for certain things like, uh, Rust code and, and, and back end things, it's a little bit harder to verify, but like front end is a little bit lower stakes and, and is easier for agents to check.

\[00:30:48\] **Dex Horthy:** Is, is that what you're s- I don't wanna put words in your mouth, but that was what I heard. Maybe I-

\[00:30:52\] **Aloke Desai:** Well, so I think there's two, two different pieces of verification. There's like, Rust is a strongly typed language where it's very easy for an agent to verify because the \[00:31:00\] compiler is incredible. That, that part of Rust is great.

\[00:31:04\] **Aloke Desai:** Yeah. You get much higher quality code when an agent writes Rust because it's, most of Rust is like written in the past six, seven years. The language hasn't evolved that much, and an agent can obviously iterate and, uh, validate its changes. What I mean more is like, I think about it as kind of like where does the code live in terms of high, how high in the stack or low in the stack?

\[00:31:25\] **Aloke Desai:** 'Cause obviously the deeper in the stack it is, the harder it is to change. And at Warp- I see ... like parts of our code base that are deeper in the stack are written in Rust, and thus it's like more important that-

\[00:31:36\] **Dex Horthy:** Yeah ...

\[00:31:37\] **Aloke Desai:** uh, it's correct.

\[00:31:37\] **Dex Horthy:** Okay.

\[00:31:38\] **Aloke Desai:** When you, something that's like really high in the stack where it's like front end that is like JavaScript, CSS, really, really cheap to change, it's like the bar for having an agent go ham, show me a video of it working correctly with the understanding that I could change it pretty cheap in the future, is like something that's like great to me.

\[00:31:54\] **Dex Horthy:** Okay. So I, I definitely agree with the, like, the deeper in the stack you are, the more critical, the \[00:32:00\] more core it tends to be. And actually, um, another founder I spent a lot of time with is this guy Ben Swerdlow, who builds-- They're building a, like, sandbox cloud platform thing for, like, really fast. They're building their own, like, kernel drivers and stuff because the virtual memory that comes with the Linux kernel wasn't good enough for them or something.

\[00:32:16\] **Dex Horthy:** Anyway, super cracked guys, but they, they have this policy of, like, you basically have two zones of your code base. And I've talked to other, like, principal engineers at larger teams that have come to similar conclusions, is, like, you have your, like, core, which is built by engineers who are good at architecting systems and understand how to make good libraries.

\[00:32:33\] **Dex Horthy:** And then you have, like, your, like, sort of pragmatic part of the code base, which is, you know, solve an actual problem. You can import stuff from the core. You can depend on stuff from the core, and there's a little bit lower bar for the code quality, for how, what level of review needs to happen and, like, uh, th- it's like where-- it's like the slop, slop allowed, not, not encouraged, but slop tolerated zones of your code base.

\[00:32:55\] **Dex Horthy:** And the rule that makes that work is that those, \[00:33:00\] like, areas are not allowed to import from each other or depend on each other. If you need to create shared functionality, it has to be pulled out of one of those into the core and be subject to a higher standard of quality before other parts of the code base.

\[00:33:14\] **Dex Horthy:** 'Cause otherwise you get this tangled web of spaghetti where all these things depend on each other, and it's really hard to pull back apart. Um, but my last take that I will disagree with you on is actually, like, front end is one of the places where agents are probably the most unreliable, um, bec- especially, like, in React world.

\[00:33:34\] **Dex Horthy:** Uh, the render model and the way, like, the, the render loop runs in React, we've just found, and talking to a lot of customers, like, over and over again, that agents are really bad at, like, reasoning over, like, okay, I have six useEffects over here and effects over here, and the Factory, the Factory AI guys actually wrote a post on this as well, is how they banned useEffect from their code base because agents are really bad at, like, building the mental model of this stuff.

\[00:33:58\] **Dex Horthy:** And this was among \[00:34:00\] three or four reasons why back in November we actually decided to take our-- We ran a lights off Factory for, like, four or five months, um, with kind of best in class, like, prompting and harness on, on, like, Opus 4.1, uh, and realized, like, oh, this has become so tangled and messy, the front end and other parts of it as well, that it will be faster to kind of rebuild this from scratch on really good patterns and, and, and design principles than, so, than, uh, than to just try to iterate and evolve it to the right place.

\[00:34:29\] **Dex Horthy:** So I will, I will humbly disagree that front end is a safe place for slop, uh, especially if you're building... I mean, if you're doing charts and tables, like, great, fine, go, go for it. But if you're building, like, complex UIs, we build an IDE, so there's a lot of state and, like, interconnectedness between all the different things in the UI.

\[00:34:45\] **Dex Horthy:** So I, uh, that, that would, that would be where I would, I would maybe disagree a little bit.

\[00:34:52\] **Andrew Zigler:** Amazing. W- the, in, in the chat they're, they're banning use effects. They're all talking about it. So I, I think the, the, the React uncertainties are, are definitely resonating with the \[00:35:00\] crew. Dan, anything you wanna add here before we move on to our next

\[00:35:01\] **Dan Lines:** question?

\[00:35:01\] **Dan Lines:** Well, I'll just say I love the, the passion. I, I guess it was a really, really good question. Uh, but I, I'll, I'll, I'll, uh, maybe take it somewhere else. So- This concept of like a dark factory, right? It comes from manufacturing. All of this software factory stuff is like from manufacturing. When I was doing some research, I saw like back in the day, manufacturing companies were bragging about if they were a dark factory.

\[00:35:28\] **Dan Lines:** What does a dark factory mean? It means that you have all these machines and they can literally run without the lights on in the factory. Like we don't pay for lights 'cause we don't have humans that need to like monitor it and all. Like that's where it comes from. And so I'll just tell like a, a quick funny, uh, story as fa- fast as I can.

\[00:35:50\] **Dan Lines:** Outside of just like software, like for me, I ask myself, okay, uh, when I'm mowing the lawn, mowing the lawn, do I do it during the day or do I do \[00:36:00\] it in the dark at night? Trick quest- or trick question and answer. I do it at night because I have an AI robot lawnmower. Uh, so that's like in dark mode for me.

\[00:36:12\] **Dan Lines:** And I think maybe like the spirit behind the question is companies are trying to get more and more in the dark because it means probably that you're more agentic and that type of thing, and I can like brag about that. But, uh, the place that I was gonna take it to give you like an ops- uh, like a opposite answer, I think it's about having night vision.

\[00:36:36\] **Dan Lines:** You still, okay, everything's in the dark, but we can all still see. Why can you all s- still see? You have the visibility. You're monitoring. You're able to see that we're not getting the slop. The quality's still good. Hey, there was an incident in production. Let me feed that context back to the agents. We got an incident going on right now.

\[00:36:57\] **Dan Lines:** Agents, change your behavior. I think it's more \[00:37:00\] of like that night vision or another way to like say it if you don't like the night vision thing. I think it sounds cool. The lights are getting dimmed, so let's get more and more in the dark, but let's- Oh ... you know, make sure that we're monitoring the qualities there, like that type of stuff.

\[00:37:15\] **Dan Lines:** And I gave you a little intro. I gave- Night vision is way cooler than,

\[00:37:17\] **Andrew Zigler:** than

\[00:37:18\] **Dan Lines:** moon vision. I gave you a little intro into my, my life. I like, I like robots and AI stuff, otherword.

\[00:37:23\] **Dex Horthy:** I, I absolutely love the night vision thing. Actually, like it is a perfect description for I think what a lot of us are working on.

\[00:37:30\] **Dex Horthy:** I published a skill like two weeks ago called /showme, which is literally like, okay, I don't wanna read that whole diff. Like use an AI to distill it into very high quality, like human readable, like code snippets, diffs, diagrams, whatever it is. I mean, I know AI code review bots have been doing things like this, but like this is a thing that I think is gonna become really important is like we need to develop new technologies and new ways of seeing so that we can maximize the bandwidth of understanding of like the, you can, you \[00:38:00\] cannot outsource the thinking and like you cannot outsource the understanding.

\[00:38:03\] **Dex Horthy:** If you lose touch with what, what is happening in your code base, whether you're like- skimming the PRs or not. Like, the, the faster you can understand what's happening, uh, the better, and I think there's a lot of opportunity for tools and skills and prompts and software and, uh, thing, things that help make that easier.

\[00:38:20\] **Dex Horthy:** So I love that.

\[00:38:22\] **Andrew Zigler:** I love that too. It's so fun. And with that, I think that's a great, uh, segue to move into our capstone question here that I prepared for us. Because really, I, the analogy of the night vision is really, really clever, because you still need to, like, understand everything that's moving through this, but it's just, like, our touch points, and like I said earlier, like our, our, the rituals, like PRs and stuff, they're all just going to transform, and we're gonna find new shapes.

\[00:38:47\] **Andrew Zigler:** There needs to be new tooling and new observ- levels of observability and visibility into our tools. And, and also something that I've been learning and really embracing a lot lately is that, like, the true state of your product \[00:39:00\] exists more in a production state now, to where you need to have the constant feedbacks of observability and how things are actually behaving in the wild, because it's a complex system that creates everything.

\[00:39:09\] **Andrew Zigler:** And a lot of this means abandoning and changing things that we've just taken for granted or have put on top of our SDLC to make it work over the last several decades. So I wanna turn this over, uh, to y'all. What part of today's SDLC is least prepared, in your opinion, for what we're calling the factory?

\[00:39:29\] **Andrew Zigler:** And how do you think we'll fix it, or what do you think will break first? I'm curious to get your viewpoint on the SDLC pain points right now.

\[00:39:37\] **Aloke Desai:** Okay, so I have something that maybe is a common take, maybe is controversial. I'm actually not sure, and that's a great way to start. I, I think it's incident management, because it's like, it's really easy to have an agent observe that there's a problem and, like, come up with a proposed solution.

\[00:39:53\] **Aloke Desai:** It's much harder to get an agent to actually fix that reliably. Like, the reason that you \[00:40:00\] w- there are problems with that is, one, permissions, right? W- what permissions are you giving an agent such that it can touch any arbitrary part of your production stack to fix it? Two, it's like- Classic, to per our discussion earlier, like the, the way an agent works, it tests a change and it works in a loop, right?

\[00:40:16\] **Aloke Desai:** What does that mean when your server is down and you need to try a bunch of random crap to get it to work, right? So that's very, very scary. And three, it's like very latency sensitive, right? You're, you get paged in the middle of the night and ma- in order of minutes you want to get your service back up and running, depending on obviously like the severity of, of the incident.

\[00:40:38\] **Aloke Desai:** And so to me, incident management, it's like very easy to have an agent do some initial triage, give you some suggestions of next steps and like I think that's great as kind of the first stab at a, um, I don't know, lights on version of incident management, if you wanna call it that. Um, to get to a part where we're like night \[00:41:00\] vision, mood lighting version of, of incident management is much, much harder.

\[00:41:04\] **Aloke Desai:** Uh, I think that's the one that's really a sticking point, especially when you think about permissions.

\[00:41:09\] **Dan Lines:** Yeah. To- totally ma- makes sense to me. Like, uh, what I, what I'm hearing from customers, at least like, uh, on the LinearB side, it's wherever they have the least amount of trust. It's like, where are you most afraid?

\[00:41:23\] **Dan Lines:** Now, for the customers that are just, I don't know, starting out on this AI journey, usually it is in merging PRs because they're scared. "Hey, all this code is AI generated. I don't know if I trust it." Uh, it could be there. Alok, it could be where you're saying. Some of the ones I think are a little more like mature that, that I see, yeah, it's in the incident area.

\[00:41:43\] **Dan Lines:** That's the area that I'm most afraid. Like it's in freaking production. Oh my God, I don't have trust there. Like I want, you know, full human time. It could, it could be there too. Um, so it, so it kind of varies. Just think about like, uh, where the, where \[00:42:00\] the trust is least. That's probably the, uh, answer. The only other thing that I would say of like some solutions, I kind of said it before, but I think e- everyone knows now it's all about context, right?

\[00:42:10\] **Dan Lines:** Can I get the best context to my agents so that I trust them more, so that they know everything that a human knows? And I can see what some of the customers are, are doing. This is the part that I mentioned before is Let the agents know if there's an incident going on in production right now. Let them know if there's a particular area, uh, of the code that could be at risk that's being mer- uh, worked on.

\[00:42:37\] **Dan Lines:** Maybe pause the merge or, like, change, um, how you're doing your risk assessment in real time. Like, that's the type of stuff that I see, uh, gaining trust, I guess you, you can call it that. And, uh, I guess the la- the last thing that I, uh, I would repeat, do that thing where you're doing the automated policy risk assessment.

\[00:42:59\] **Dan Lines:** If \[00:43:00\] you're afraid, like afraid, that's a way to, to not be afraid. Okay, now I know I have a mechanism in place. And then it will move your lack of trust probably to the next area. Start with the PRs and then maybe the incidents. So kind of on a case by case basis is what I see.

\[00:43:15\] **Aloke Desai:** So incident management is like the end of the funnel.

\[00:43:19\] **Dan Lines:** Yeah.

\[00:43:19\] **Aloke Desai:** Let's not lose sight of the top of the funnel too, which is what to build. That is not necessarily... And I just want, like I, this is obvious, right? But it's actually important to call out. It's like a dark factory also means, uh, the factory is the one who's like looking at us- I put it into quotes 'cause it's like crazy if I, if you think about it.

\[00:43:37\] **Aloke Desai:** It's like, it's looking at user feedback and deciding when to build. That's the one right now that I don't think is like- Well set up to feed into the factory because that requires identifying the problem, which an agent sometimes is good at, but it's really, like, the thinking to come up with the right product solution and then distill that into something that the- should just g- you go build.

\[00:43:59\] **Aloke Desai:** And that's \[00:44:00\] something where humans are still deeply, deeply in the loop, and they should be. That, that is the thinking.

\[00:44:04\] **Dex Horthy:** I like it. Um, I agree with everything that everybody just said. Um, I wanna call out a comment from the chat from, uh, Brian Cripe. What's up, Brian? Um, unified observability across SDLC is missing.

\[00:44:17\] **Dex Horthy:** Don't treat all the phases as independent in different tools. Um, I think back in the day, like, it was very normal for a product manager to understand the product and the UI and the surface of it, and not really need to understand the code and how it's shaped to make decisions, to make proposals, to say, "Hey, our customers have this problem.

\[00:44:37\] **Dex Horthy:** I sat with a designer and we figured out how to do it. Here's a Google Doc or a Confluence page or a Figma board or whatever it is." Um, actually, Andrew, can I, can I share my screen? Is it gonna let me do that? Let's try.

\[00:44:49\] **Andrew Zigler:** Maybe you could screen share. You could certainly

\[00:44:51\] **Dex Horthy:** try. Let me try. Okay. So the way I kind of think about, like, the, the, the SDLC and, like, how forges work is, like, before GitHub, and I know Linus \[00:45:00\] still does this, but most projects do not email git patches around on email lists and rely on the maintainer to, like, assemble the build and build it and publish it.

\[00:45:09\] **Dex Horthy:** Um, but this was how, like, we used to use, like, distributed version control is, like, it was just, like, sending things around and, and it was very chaotic and, like, thank God there were a lot of really smart people who could own this and be in charge of it. And then we got GitHub, where you have this kind of like, yes, it's a decentralized protocol, but everything is kind of streamlined in one place, and it kind of flows and, you know, at any point as a, as a project owner, I know I can check this thing out and build my project, and it is the state of truth for, like, what is our main branch.

\[00:45:36\] **Dex Horthy:** Make sense?

\[00:45:38\] **Andrew Zigler:** Oh, it makes perfect sense. I'm obsessed with this. Yeah. This is like you- So- ... you must have been a classroom teacher in a past life.

\[00:45:45\] **Dex Horthy:** I just like to draw things, and I'm bad at explaining, so, uh, we, we fall back to the drawings. Uh, what we have now, or, like, it's not, like, a problem, it's just, like, an inefficiency and an opportunity, which is, like, our Git patches are all centralized, \[00:46:00\] but our plans and our session traces and, like, there's a lot of people trying to bolt session trace, like, attribution onto Git history.

\[00:46:07\] **Dex Horthy:** Um, stuff still lives in Figma, stuff still lives in Google Docs and Notion. And the, the weirdest one, the closest one to this is, like, I see all the time of people being like, "Here's what my Claude said," paste it into Slack, ping another engineer, be like, "Hey," like, "what do you think of this?" And then that engineer takes the message, pastes it into their, like, coding agent session, gets a response, pastes it back into Slack, and then the other user pastes that into their coding agent session.

\[00:46:33\] **Dex Horthy:** Like, this happens all the time, and this is, like, the metaphor of, like, emailing Git patches around. And so, like, my take is, like, the, the, the tool that really enables an entict- agentic devel- development across the whole SDLC will kind of combine all of these things in a very, like, you know, a native way where they all have, like, a very specialized relationships between each other, between product specs and designs and code \[00:47:00\] and prompts and agent sessions and plans, and it all kinds of comes together in one place.

\[00:47:05\] **Dex Horthy:** This is kind of my vision for how this space is going to evolve. Um, HumanLayer will play some part in that. I don't know which one, but, like, this is, I think, the most interesting opport- Like, it's, it's not a problem. We've shipped software like this for years and decades. But with AI, I think it becomes way more valuable, and there's a huge opportunity to put this all in one place.

\[00:47:24\] **Andrew Zigler:** I love this, and also chat loved it too, so make sure you go back and get all of your, your love from everybody about the diagrams you just showed us. Oh my God. It's like I, I just throw this question in the air, like, "What do you think is, like, broken?" Or, "What do you think the current problems are?" And you're just like, "Well, let me just get out this giant board, and I actually have the future mapped out," so that we all just got, like, a great preview of where this kind of stuff is going, only from the mind of Dex.

\[00:47:45\] **Andrew Zigler:** I love that. And we're coming up to, uh, near the end of the top of the hour, but I do wanna pull a question out of the chat that I saw earlier that really resonated with me. I really loved it because so far we've been talking about the factory itself and all of the different minutiae of knowing if it's \[00:48:00\] good or not and how to not stumble over yourself.

\[00:48:02\] **Andrew Zigler:** But at no point have we really doubled down on talking about, like, how do we get developers aligned around this idea of the software factory and get them on board and excited about what their roles are to play? I'm curious what, how y'all are thinking about if we're gonna s- take this step forward into this factory model, what do you think the role is for engineers based upon the stuff that we've talked about and covered here today about how there's still so much work to be done?

\[00:48:27\] **Dan Lines:** All right, I'll bail you out, Andrew, from your Thank you. No, no. I, I, I just-- You know what? There-- I think there's different types of developers, so you gotta find, like, who's passionate about what. But I'll say, like, the type that I was, if you told me, "Hey, we're going into, like, a full factory mode. It's gonna be this dark factory.

\[00:48:47\] **Dan Lines:** A lot of this work is gonna be now, like, automated and a- agentic," uh, what I would want to hear is, "Hey, Dan, that means that you can do more product value now. I know you really \[00:49:00\] like being with customers. You wish you could go end to end and do all the product stuff and the, the, the development stuff." Like, that's what I would've liked to hear.

\[00:49:08\] **Dan Lines:** I know there's, like, a, a group of engineers out there that just wanna build awesome stuff, and, like, that would kinda be where I would look to take them. "Hey, let me get you more product responsibility. Own this area end to end. All this other stuff's gonna be automated for you. Like, go do, like, your innovative stuff, kinda your entrepreneurship within your role."

\[00:49:30\] **Dan Lines:** Like, I, I, I think that is, uh, kickass. So for that group of developers, that's what I would say.

\[00:49:39\] **Aloke Desai:** Yeah, I think the mistake is saying you want a dark factory and not trying to think about getting alignment with your team. Like, that's the first order of business. The way I would do that is really emphasize how a factory, one, still has humans in the loop in the right place, and two, \[00:50:00\] lets them focus on the parts or the thinking of, um software development that excites them, right?

\[00:50:08\] **Aloke Desai:** So as part of working the factory, you may not be writing all the code, but you're still thinking at a systems level on a product and technically, right? What are the things to build high level? What is the architecture? You may use an agent to do that, but you're the one still thinking, and that's, like, the most important thing that most engineers are very excited by.

\[00:50:25\] **Aloke Desai:** The other thing is, like, I think the, the shift of we are all dev prod engineers, we're all the ones who maintain the factory, has been really motivating for a lot of the team at Warp, and I would really, really try to get people in that mindset. So it's not me against the factory. It's I maintain the factory.

\[00:50:42\] **Aloke Desai:** I'm on the hook for improving it. And it's really exciting. It's really energizing. And I think as an engineering leader, you need to model that and maintain the factory and get other people on your team to maintain and improve the factory as well.

\[00:50:55\] **Dex Horthy:** Yeah. And I totally agree. I love that. Yeah. I, I think this has been true since before AI \[00:51:00\] is like, "Hey, if CI is slow and bad, like, go fix it.

\[00:51:03\] **Dex Horthy:** Don't complain or throw stuff over the wall. Like, we're all in this together." Um, and I, I liked your other point as well as, like, the, the, there are things that, like, humans are uniquely good at, um, that we haven't figured out how to RL into AI because, like, AI, we have not figured out how to replicate the experience that human engineers have that teaches them lessons, which is like, "Oh yeah, I've been up at 3:00 in the morning debugging this problem before, and I'm never allowing a PR that exhibits that problem to go into the code base again because I don't want me or anybody on my team to get stuck with that."

\[00:51:35\] **Dex Horthy:** And we haven't figured out how to turn, put that shape of lesson into the weights of the model. Uh, and, and we may eventually, but right now today, like, I think the, the, the number one thing is, like, you as a human engineer, whether you have 2 years of experience or 20 years of experience, you have intuitions around things that will cause you pain in the future, uh, and cause your users pain in the future.

\[00:51:58\] **Dex Horthy:** And, uh, you owe it to your \[00:52:00\] team and to your users and to your customers and to the, like, industry to keep learning and keep applying that intuition and knowledge and keep building it.

\[00:52:09\] **Andrew Zigler:** Amazing. I'm gonna go ahead and share my screen again. So I just wanna give us a few moments just to go, um, at, and, and start wrapping up here for our panel.

\[00:52:17\] **Andrew Zigler:** So, uh, first I just wanna move into a slide for each of our panelists today. I would love for y'all to listen a little about what they're building in terms of this problem. And I also just wanna let people know that we're gonna be sending out resources regarding this as well. So there will be a link to the, uh, video of everything that we've discussed as well as a guide that goes in deeper on some of this stuff, 'cause I've been nerding out about this software factory stuff.

\[00:52:37\] **Andrew Zigler:** Dex and, and many of the folks at Warp have been feeding me amazing quotes and ideas about where this is all going. So don't be s- don't miss out on all of the stuff you're gonna get afterwards. But first I'd love to hand it over, uh, to Dan to go ahead and, and talk about LinearB. I'm just gonna give you about two minutes here to talk about how you think LinearB fits into the story around software factories

\[00:52:56\] **Dan Lines:** Well, listen, first of all, thanks for having me on the panel.

\[00:52:59\] **Dan Lines:** If you all \[00:53:00\] wanna chat with me more, like f- feel free to hit me up on LinkedIn or however you wanna find me. Happy to continue the conversation Yeah, well, I mean, with LinearB, listen, come get your, uh, night vision for your software fa- factory. That's where we start with. Show you what, what's going on end to end.

\[00:53:17\] **Dan Lines:** That's where most, you know, I think, uh, software organizations are. Come and get that. We'll, we'll give you the, the night vision. And then after that, it's all about improvement. Know where you're gonna improve, what you're gonna, uh, improve. You probably heard me talk about it a lot, but I really like what we do with git stream, the policies, the making sure that you can really get, uh, fully autonomous.

\[00:53:42\] **Dan Lines:** And, uh, yeah, we'll just be pumped to have you all check out LinearB. And like I said, if you wanna chat with me one-on-one, hit me up. I'm happy to do so. And, uh, that, that'll be it for me. I don't need the two minutes. Thanks, Andrew.

\[00:53:54\] **Andrew Zigler:** Amazing. I'm gonna hand it over to Aloke to talk to us about Warp Factories.

\[00:53:58\] **Aloke Desai:** For sure. So, so Warp \[00:54:00\] Factories is open infrastructure for you to build your own software factory. So what that looks like is we have a kind of opinionated default factory that lives in code, so you can extend it in any way. You can add the agents that make sense for you. You can add skills. Uh, you can change, use whatever model harness you want.

\[00:54:19\] **Aloke Desai:** Uh, and it's fully built with the right integrations that you need, and it's built to help demonstrate ROI upfront. So it has self-improvement built in, so it improves over time and will send you PRs back to your own factory definition to improve your factory, and also has metrics to actually show here's how you're improving, uh, throughput over time.

\[00:54:40\] **Aloke Desai:** So the high level vision is like you have full control over your factory, but you shouldn't have to spend all the time building every small piece of it. Focus on, similar to all the other discussion we had, focus on the high level pieces of what makes sense for a factory, uh, and then deploy it really quickly with Warp Factories.

\[00:54:58\] **Aloke Desai:** This, we launched this last week, so it's \[00:55:00\] really, really early. If you're interested, uh, hit us up at warp.dev/factories, or just email me, aloke@warp.dev, A-L-O-K-E @warp.dev. Would love to chat more about it. I'm, like, super, super excited about Warp Factories.

\[00:55:11\] **Andrew Zigler:** Amazing. I'm excited to see what people build with it. And Dax, I'm gonna hand this over to you.

\[00:55:15\] **Andrew Zigler:** I got some slides in here, and I also pulled some really amazing screenshots from your, your podcast with HighBov. I'd just love to give you an opportunity to talk about some of the stuff you share every week.

\[00:55:23\] **Dex Horthy:** Oh, yeah. Nice. Um, yeah, so again, like HumanLayer, we're building a multiplayer coding agent workspace, building blocks for software factories.

\[00:55:29\] **Dex Horthy:** What does the orchestration layer look like, and what does it, what does it look like to kind of build an ecosystem of building blocks that allow, you know, you can bring your own compute or you can shell it out, you can buy or build the harness, the dev environment, the orchestration layer. Um, and just really looking at, like, how can we, how can we build workflows in your factory that, uh, put humans in at the right place, uh, and give you the most leverage, as we say?

\[00:55:52\] **Dex Horthy:** How can we save you three hours of PR review time by spending 20 minutes reviewing a spec with a coworker? And then, yeah, I, I, \[00:56:00\] I, I'm talked with, uh, another founder of HighBov, uh- who is, uh, one of the best engineers I know, one of the best AI engineers I know, and we do a podcast every Tuesday at 10:15 Pacific.

\[00:56:10\] **Dex Horthy:** Uh, there's a, there's a, uh, Luma... If you go to luma.com/baml, you can sign up for the next one, and, uh, you can catch us live. We just stream them live on Twitter, so x.com/dexhorty, D-E-X-H-O-R-T-H-Y. And, uh, we'll be posting those there, and, uh, try to help people cut through the hype and build AI systems that work.

\[00:56:31\] **Andrew Zigler:** Amazing, and we're gonna include links to all of the stuff for all of our presenters today, and post stuff, and afterwards. And like Dan and others said, be sure to come find us online. Come pick a fight with us on LinkedIn or X or wherever about something we said today. I would love for us to continue this conversation beyond here.

\[00:56:47\] **Andrew Zigler:** And if this is your first time coming into a webinar like this, we have events around this kind of stuff all the time, and if you're not reading Dev Interrupted, then you might just be one step behind. So be sure to subscribe to our, uh, weekly newsletter and \[00:57:00\] podcast as well, and we get quotes from all of these amazing leaders you hear about today.

\[00:57:04\] **Andrew Zigler:** But you'll also stay ahead for the future of what the software factory looks like, because we're not abandoning this narrative anytime soon. So thanks for giving us your hour. We had a blast, and we'll see you at the next one. Take care, everybody.

\[00:57:17\] **Aloke Desai:** Thanks. See you.

## Real conversations with top engineering leaders

Find us on

[](https://www.linkedin.com/showcase/dev-interrupted/)
[](https://devinterrupted.substack.com/)

## Your next listen

[![Cover image for Build fences not sandboxes, earn the currency of trust, and share the cognitive burden of agents across engineers](https://assets.linearb.io/image/upload/c_limit,w_3840/f_auto/q_auto/v1/building_trust_with_ai_agents_cebc111498?_a=BAVMn6ID0)](https://linearb.io/dev-interrupted/podcast/ai-agent-fences-ox-alpha-trust-software-factories)

Dev Interrupted

[Build fences not sandboxes, earn the currency of trust, and share the cognitive burden of agents across engineers](https://linearb.io/dev-interrupted/podcast/ai-agent-fences-ox-alpha-trust-software-factories)

This week on the Friday Deploy, Ben and Andrew evaluate the arrival of Ox Alpha and unpack the security risks surrounding black-box AI tools. They examine why...

[![Cover image for Can agents keep a secret? We asked 1Password’s CTO Nancy Wang](https://assets.linearb.io/image/upload/c_limit,w_3840/f_auto/q_auto/v1/Blog_Comprehensive_DORA_Guide_2400x1256_78_8ed56543e1?_a=BAVMn6ID0)](https://linearb.io/dev-interrupted/podcast/1password-nancy-wang-agentic-security-secrets)

Dev Interrupted

[Can agents keep a secret? We asked 1Password’s CTO Nancy Wang](https://linearb.io/dev-interrupted/podcast/1password-nancy-wang-agentic-security-secrets)

1Password CTO Nancy Wang joins the show to break down the golden path for agentic security, explaining how just-in-time secrets provide autonomous AI with...

[![Cover image for The battle to replace Github, building assembly lines for software, and why no one finishes projects anymore](https://assets.linearb.io/image/upload/c_limit,w_3840/f_auto/q_auto/v1/the_battle_to_replace_github_building_assembly_lines_for_software_and_why_no_one_finishes_projects_anymore_cbbc64ca4a?_a=BAVMn6ID0)](https://linearb.io/dev-interrupted/podcast/github-outages-software-factories-agentic-assembly-lines)

Dev Interrupted

[The battle to replace Github, building assembly lines for software, and why no one finishes projects anymore](https://linearb.io/dev-interrupted/podcast/github-outages-software-factories-agentic-assembly-lines)

This week on the Friday Deploy, Ben and Andrew unpack how surging agentic code volume and persistent GitHub outages are challenging traditional code hosting....

## Structured data

_Machine-readable metadata (JSON-LD) embedded in the page for search/AI context — not content rendered on the page itself._

```json
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "LinearB",
  "url": "https://linearb.io/",
  "logo": "https://assets.linearb.io/image/upload/v1715628027/logo-mark-lg.svg",
  "description": "LinearB is the engineering productivity platform that helps engineering leaders prove AI is improving throughput without sacrificing delivery confidence, flow efficiency, or developer experience.",
  "sameAs": [
    "https://www.linkedin.com/company/linearb"
  ],
  "award": [
    {
      "@type": "Award",
      "name": "LinearB is a Leader in the 2026 Gartner® Magic Quadrant™ for Developer Productivity Insight Platforms",
      "dateAwarded": "2026",
      "awardedBy": {
        "@type": "Organization",
        "name": "Gartner®"
      }
    },
    {
      "@type": "Award",
      "name": "Great Place to Work Certification",
      "dateAwarded": "2025-2027",
      "awardedBy": {
        "@type": "Organization",
        "name": "Great Place to Work"
      }
    },
    {
      "@type": "Award",
      "name": "America's Best Startup Employers 2025",
      "dateAwarded": "2025",
      "awardedBy": {
        "@type": "Organization",
        "name": "Forbes Magazine"
      }
    }
  ],
  "hasCertification": [
    {
      "@type": "Certification",
      "name": "SOC 1 Type 2"
    },
    {
      "@type": "Certification",
      "name": "SOC 2 Type 2"
    },
    {
      "@type": "Certification",
      "name": "GDPR Compliance certification"
    },
    {
      "@type": "Certification",
      "name": "ISO 27001"
    }
  ]
}
```

## More on linearb.io

### Top navigation

- [Book a Demo](https://linearb.io/book-a-demo)
- [AI Code Reviews — Catch security risks, bugs, and spec mismatches](https://linearb.io/platform/ai-code-reviews)
- [AI & Productivity Insights — See how AI tools affect cycle time and delivery speed](https://linearb.io/platform/ai-developer-productivity-insights)
- [Measure AI Impact — Track AI adoption and tie it to delivery outcomes](https://linearb.io/use-case/measure-ai-impact)
- [MCP Server — Chat with your data to spot patterns and boost output](https://linearb.io/platform/mcp-server)
- [Resource Allocation — Cost initiatives and shape your investment strategy](https://linearb.io/platform/resource-allocation)
- [Cost Capitalization — Capitalize engineering costs with audit-ready reports](https://linearb.io/platform/cost-capitalization)
- [Dev Team Management — Set targets and tie throughput to business outcomes](https://linearb.io/platform/goals-and-reporting)
- [DevOps Workflow Automation — Policy-based PR routing, approvals, and tests](https://linearb.io/platform/ai-workflow-governance)
- [AI Powered Support — Unify AI and human code delivery in one clear view](https://linearb.io/use-case/ai-powered-support)
- [Optimization — Surface friction with feedback and MCP insights](https://linearb.io/platform/developer-experience)
- [Reporting — Spot what's working and what needs attention](https://linearb.io/use-case/measuring-developer-experience)
- [Surveys — Turn developer feedback into actionable signals](https://linearb.io/platform/developer-surveys)
- [Platform overview](https://linearb.io/platform/overview)
- [Watch now](https://linearb.io/resources/the-great-software-factory-debate)
- [Customers](https://linearb.io/customers)
- [Pricing](https://linearb.io/pricing)
- [Why choose LinearB — Explore your data. Measure performance. Act to improve it.](https://linearb.io/why-linearb)
- [APEX framework — The operating model for AI-era engineering teams](https://linearb.io/resources/apex-framework)
- [Anti-FAQ — The questions other vendors won't answer](https://linearb.io/why-linearb/anti-faq)
- [Security — Enterprise-grade compliance and zero code access](https://linearb.io/security)
- [Build vs. buy — The hidden cost of building it yourself](https://linearb.io/resources/build-vs-buy)
- [Dev Interrupted Podcast — Conversations with engineering leaders](https://linearb.io/dev-interrupted/podcasts)
- [Reports & Guides — Deep dives on productivity and delivery](https://linearb.io/resources)
- [Webinars — Expert sessions on productivity and AI](https://linearb.io/resources?category=workshops)
- [Metrics Benchmarks — See how your engineering org stacks up](https://linearb.io/resources/software-engineering-benchmarks-report)
- [Blog — Product updates and practical insights](https://linearb.io/blog)
- [Help Center — Documentation, setup, and support](https://linearb.helpdocs.io)
- [API Docs](https://docs.linearb.io/api-overview)
- [Status](https://www.linearbstatus.com/)
- [Integrations](https://linearb.io/integrations)
- [LinearB Library](https://linearb.io/library)
- [Engineering metrics](https://linearb.io/library/engineering-metrics)
- [Platform engineering](https://linearb.io/library/platform-engineering)
- [Engineering glossary](https://linearb.io/library/engineering-glossary)
- [Developer productivity](https://linearb.io/library/developer-productivity)
- [AI in software development](https://linearb.io/library/ai-in-software-development)
- [Engineering management](https://linearb.io/library/engineering-management)
- [Developer experience](https://linearb.io/library/developer-experience)
- [DevOps](https://linearb.io/library/devops)
- [Engineering operations and the context layer](https://linearb.io/library/engineering-operations)
- [Engineering efficiency](https://linearb.io/library/engineering-efficiency)
- [Software delivery](https://linearb.io/library/software-delivery)
- [Research and data](https://linearb.io/library/engineering-benchmarks-and-research)
- [LinearB is a Leader in the 2026 Gartner® Magic Quadrant™ for Developer Productivity Insight Platforms](https://linearb.io/resources/gartner-magic-quadrant-dpi-platforms-2026)
- [Sign in](https://app.linearb.io/login)
- [Enterprise](https://linearb.io/solutions/enterprise)
- [Contact](https://linearb.io/contact-us)
- [About us](https://linearb.io/about-us)
- [Careers](https://linearb.io/careers)
- [Service agreement](https://linearb.io/services-agreement)
- [Privacy policy](https://linearb.io/privacy-policy)
- [DPA](https://linearb.io/data-processing-agreement)
- [Security FAQ](https://linearb.io/security-faq)
- [Substack](https://devinterrupted.substack.com/)

### Footer

_Additional links from the site footer, not repeated from the top navigation above._

- [GitHub](https://github.com/linear-b)
- [LinkedIn](https://www.linkedin.com/company/linearb)
- [Twitter](https://twitter.com/LinearB_Inc)