# EP. 02 · Is the future of software engineering a factory?

- Show: After the Last Engineer (ATL/E)
- Guest: Patrick Debois, Tessl (https://tessl.io)
- Released: 2026-10-15
- Length: 49:17
- Watch: https://www.youtube.com/watch?v=FnCnv2tGsK0
- Listen: https://open.spotify.com/episode/2hMgKkh4giYXdn6kykZarc
- Page: https://atle-site.netlify.app/episodes/02-patrick-debois/

Tessl ran a hackathon and ended up with five or six factories. One of them took over the marketing board. Another morning, the factory had filed 15 tickets about improving itself, and nobody owned them.

About the guest: Gave the industry the word DevOps. Co-wrote the DevOps Handbook. Runs software factories at Tessl.

## Where they keep the lights on

Rooms lit: Factory owner. Darkness level L4.

> Now, can you do it without? Yes. But can you do it without ownership? No. [19:43]

## What broke

- [15:50] The factory created 15 tickets about improving itself. Nobody owned them.
- [14:39] It took over the marketing and sales board and started commenting on the website.
- [37:04] The worst case to plan for: an agent deletes the database.

## Quotes

Each quote matches the transcript at its timestamp.

- [18:22] "Here’s the tools. Engineering, figure it out."
- [14:39] "Oh, no, yeah, sorry, like we didn’t mean to."
- [37:04] "How fast can I restore it? What’s my window of data loss?"
- [39:03] "That’s basically automating disaster."
- [45:41] "I don’t care about the 100%."
- [46:38] "The decision is more and more about, like, what features should we not build."

## Transcript

Machine transcript from Descript. Speaker labels and words can be wrong. Quote from the Quotes list above, or check the timestamp in the video.

[0:00] **Patrick Debois** The factory created 15 tickets about improving itself. Who owns this?

[0:06] **Danail Arapkuliev** It always starts with the short promise.

[0:09] **Patrick Debois** What really opened the box was maintenance aspects, what nobody wanted to do, but it took over marketing and sales part as well. Oh, no. Yeah, sorry. Like, we didn't mean to.

[0:20] **Danail Arapkuliev** And when it breaks

[0:24] **Patrick Debois** What's the worst thing that can happen in production?

[0:26] You get your context right, you get your harness right, and so on, but I, I don't think it is enough to survive to production.

[0:33] **Vitaliy Filipov** Are we going to have a stable factory pattern, or this is just a flop?

[0:39] **Patrick Debois** I don't care about 100%. Maybe that's me retiring. Who knows? I think we're not there yet, sorry

[0:50] **Danail Arapkuliev** In 2009, he gave the first DevOpsDays. After that, he gave the word DevOps to the industry.

[0:58] **Patrick Debois** It's gonna take our jobs, right? There's always that fear. It was there with DevOps.

[1:02] **Danail Arapkuliev** He co-wrote the DevOps Handbook and then followed the same questions into security and now into AI. Today, he works in Tessl, and with his team, he didn't just create only one software factory.

[1:16] **Patrick Debois** So we ended up with five or six different factories.

[1:19] **Danail Arapkuliev** Whoa, 15 tickets, no name on them. Who should own the factory then?

[1:25] **Patrick Debois** A business organizational decision to put that team together. That's not often the case. A lot of the times in organization, they would just say, "Here's the tools. Engineering, figure it out."

[1:35] **Co-host** And you know the narrative, you- software development is not a factory. Like-

[1:40] **Patrick Debois** Engineering that engine still is a lot of engineering, right? Probably the decision is more and more about, like, what features should we not build. So what happens after the last engineer?

[1:57] **Danail Arapkuliev** Hello. We are here with Patrick Debois in, uh, our podcast After the Last Engineer. So Patrick, tell us your prediction. What will happen after the last engineer? What do you think?

[2:10] **Patrick Debois** After the last engineer? Um, well, maybe that's me retiring. Who knows? Um, no, I, I think we're not there yet. Sorry. Like, you can have, like, a long, long, long time until this podcast really ends, to be honest, so.

[2:28] **Danail Arapkuliev** Yeah. And how do you think the role will, will evolve, actually? Watching what happened with DevOps, it took, um, a lot of years. I think even some people still don't, don't do DevOps the right way, uh, even today. So would this take, like, I don't know, 40, 20, 40 years, uh, from now to have software factories, or the, like the, it's more near?

[2:56] **Patrick Debois** Okay. So, um, let me maybe... You know, I've, I've seen my fair share of automation cycles in software delivery over, you know, kind of many decades now. And, uh, what usually happens is- The first feeling is, um, I was doing A as a practice, uh, whether that was DevOps or mobile or anything, you know, you kinda name it.

[3:22] Um, when there's some kind of automation happening, people say, "Well, I think it's, you know, it's gonna take our jobs," right? There's always that fear. It was there with DevOps, it was there with cloud. It, it kind of is, is a very consistent pattern to it. Now, if I would, like, make the comparison with, um, photography, everybody has an iPhone, everybody can take pictures.

[3:47] Like, you... For that, you used to have to go to a place that actually, you know, was specialized, and the photographer had its own gear and had to do a lot of stuff. Now, it got commoditized, and so the number of kinda photographers went maybe down. Um, and there was a lot of more self-serving at building things.

[4:12] Now, whenever that happens, there's usually a next leap that happens with more and more complex things that you can do. So that same craft that felt like, hey, everything's going away, with the automation opens up new kind of layers of possibilities, more complex problems, and that's where then there is a new leap of almost, like, advancing the craft instead of making the craft die.

[4:43] With DevOps, that was, uh, doing things at a scale. It was not just managing one machine, but it was managing 10,000 machines, right? The scale was different. We needed to kind of change the way how monitoring observability worked at scale and so on. So that is usually something that happens, so the scale and complexity.

[5:06] And then on the other hand, what happens then is that there's usually a split of new things emerging that are then becoming professions on their own. Oh, we have a kiosk engineer who is, like, very much focused on this. We have an SRE very much focused on that. We have kinda, like, you name it. So that leads back to more specialization Towards that bigger kind of, kind of trend.

[5:34] Now, you cannot predict the future, and what's definitely different from any of, you know, previous changes that I've seen is that, um, AI, due to the fact that it lives kind of in that social, very well-connected world, the impact is almost instantly. One tweet can change and reach so many people now across the world.

[5:58] Couple of years, that was like that speed of like an impact of one thing kind of was way slower. So we feel kind of like it's changing while we're doing the stuff and kind of, you know, putting, uh, things, uh, away, uh, under our feet. Now, the feeling that, uh, is often expressed to engineers when first kind of we started using agentic coding, um, was like, well, am I now a glorified, uh, prompt engineer, basically, right?

[6:29] But then we learned that it was not just about the prompt. Uh, the prompt needed to work well with the coding agents. The coding agents were, were updated. We started having skills. They needed versioning. So you see there is like, you know, back... A new set of practices kind of emerging, uh, on that field. But still, for a lot of people that felt like we're glorified prompters, is this where we signed up for as a technology and a person kind of like really would dig into the technology, uh, as well.

[7:00] One escape for these people was to say almost like, but, you know, now that you're expressing what your intent is and less like how to do things, but your intent, why don't you sh- kind of move slowly toward product? You know, you get closer to the business, you do some stuff there. Uh, you are kind of more like translator, uh, kind of making sure that works, uh, and comes out.

[7:25] And, um, one of my earlier talks I, I explained that, so if your piece changes as a software developer... Think of what a senior developer was doing. Um, and even if you think, like, you know, a principal, a distinguished engineer. They were not coding anymore often. They were dealing with the business aspects of it.

[7:48] So the seniority could be seen as a way, like, you get closer to the business and now you understand both the business and the technology piece in there. Now, I think that, like, alleviates some folks. On the other hand, you have the pressure of the product people who say, "Well, now we can code." Like, so, uh, and now it's not a full stack, but now you have to be an AI product engineer, right?

[8:12] Like, one of the new terms and, and kind of they say, "Well, you know, what can we do?" Now we have a forward deployed engineer because you're dealing with customers and you're getting features and you're building them, and so... But not everybody loves kind of that closer relationship maybe to, um, maybe the business aspect as such.

[8:30] So for a long time they didn't have that much of an outlet.

[8:34] **Danail Arapkuliev** Do you really think, like, product people can, can code now? Can, could they ship code to production without anybody looking at the code?

[8:44] **Patrick Debois** Okay, I'll take that one first. So- ... um, when the whole vibe coding thing came, uh, obviously the product engineers could build more, uh, prototypes, and what was really helpful is not that they were in the past they had to wait for engineering to show up and actually have, like, people that could help them build a prototype.

[9:07] Um, they didn't have to wait for that anymore. And what's the important part is it's almost like exploratory testing. It's like exploring your product. So if I build it, I actually experience what works for me and what doesn't work for me while I'm building that product. So the learning phase there is actually very useful.

[9:29] Now, the tension was prototype was built, engineering said, like, "Ugh, this is really, really badly coded as such." I think what's happening right now is the better we get with context, harness, factory, where we encode actually good software practices in those pieces, one product builds a product or kind of a prototype or whatever, it's getting much more closely aligned to what actually is in your engineering want.

[10:00] So the handover, if they start using the same factory, at least that's what I've seen at Tessl, is that kind of... That immediately brings it on top of the product instead of it being a side project as such. So that brings, I think, can they write code? Maybe not in the sense as we are like, you know, thinking about classes and all that pieces, but given we put enough knowledge within the agents they're using, it-- the transition between kind of the two worlds becomes a lot smo-smoother.

[10:30] There's even products, uh, I think, uh, autonomous AI and stuff that actually are working to reduce that friction set, and it's not the vibe coding tools, it is actually making sure whatever the building is that they use the same kind of way of working as engineering does, a-as such. Does that make sense?

[10:50] **Vitaliy Filipov** It, it totally does, and I'm also a little bit curious because you mentioned Tessl. Can you share a little bit, uh, stories from the kitchen, like what works, what doesn't, and maybe your passion in all of this?

[11:05] **Patrick Debois** Sure, sure. Yeah. So, um, we have a roughly a two-year history of building a product and then pivoting and look-looking like as the industry is evolving, right?

[11:17] And, uh, we accumulated, uh, you know, we went, I think, to a s- a, a journey that a lot of companies have gone through. Oh, you know, first the prompt, then fix the context, then add the harness, then add the loop, and then eventually the factory. So we kind of matured ourselves internally towards that, and that in-internally has led to us building our internal factory for that.

[11:37] Now, I think, um, when the developers first started to build a factory, uh, within Tessl, um, they weren't maybe thinking of the usual things a developer would look like. And it was very ironic with my DevOps background that all of a sudden all these operational parts became important. Oh, we need to have a proxy, we need to have a sandbox, we need to have, you know, security scanning, we need to have all those pieces observability for the agent.

[12:07] So you started seeing them almost like relearning the ops part, like as a developer, but now for kind of the factory, uh, to do that. So that was, you know, maybe a journey that I saw, like, you know, they're kind of getting closer to those things. Now, there were definitely some hiccups in the way that they said like, "Well, you know, we're gonna put one machine, two machines," and then all of a sudden the agents start working and it explodes.

[12:31] So all the scaling, so again, all kind of operational aspects. So I'll, I'll leave that like into one piece. I think the other thing that came is that they, the factory started producing more and there was a lot of discussion about like, okay, should I use the full factory or when should I use my local kind of coding still?

[12:52] And it's still a little bit of a tension. Like on the one hand, we try to say like, "Everybody use the factory," and then there was a little bit of feeling if you weren't using the factory that it was kinda like bad practice. But on the other hand, if you're doing exploration, a factory is a slow, kind of slower moving thing compared to your local exploration as such.

[13:14] So that kind of is almost like I would say like your product work thinking about like very fast feedback and so on, still something you might do locally and then express better your intent and learn what you need to build, and then the factory starts building those pieces as well. So that was still, let's say, the traditional coder kinda like, you know, saying like, "I'm gonna delegate some tasks asynchronously, some things I'm, I'm still like very synchronously involved."

[13:42] What really opened the box was maintenance aspects, what nobody wanted to do. Uh, you know, who wants to fix things in Dependabot? Uh, okay. You know, it's a very obvious one of course, but it could be different things. "Hey, um, your classes are inconsistent with the other classes." You know, um, that was something multiple engineers working on the same code base, even though we had some skills, there was nothing kind of more, um, like forcing them.

[14:13] So we learned that more of our, more and more of our tests that we had in our context, that we started translating those into more deterministic checks, uh, linters, verifiers, stuff like that, to kind of almost like build the testing for the agent to know better of what it was doing, right? So instead of us commenting on tickets, so that was kind of a, a learning phase.

[14:39] One of the f- funny stories was, is that for some reason, I'm not calling names, actually I don't know the name, but the factory took over not only the engineering tickets in our linear board, but it took over marketing and sales board as well. So all of a sudden it started like commenting things in the marketing website and kind of like doing stuff, and while it was kind of ironic in a way that like, "Oh, no, yeah, sorry, like we didn't mean to," it did lead us on a path indeed like, but what if actually we're producing so many features, uh, GTM and sales can't keep up with their presentations, with their demos, with all those pieces as well.

[15:22] So that kind of led us to, um, the learning of like, "Hey, there's something there. Um, why don't we think about their pipeline of building stuff and kind of bringing that in?" So we moved the marketing website in. You know, we had to massage it a little bit because our first one was a monorepo, so we, we started thinking about, okay, well, not all projects are similar, so kind of scaling and kind of making sure that the, maybe the tooling is a little bit more, uh, abstracted away.

[15:50] And then coming back to that maintenance piece, one of the, you know, fun parts that I saw on Slack is, uh, you know, one morning I see the message like- The factory created, um, 15 tickets about improving itself. Who owns this? So, so kind of those learnings you get along the way, and they're, they're different from what you know.

[16:12] But it's different and it's not different. Um, in my previous job was VP engineering and I had to take on kind of a more, let's say, a l- a multiple year GitHub kind of organization, which means a lot of kind of demos, proof of concept, abandoned software, kinda like libraries that they were never touched for a while, and pieces like that.

[16:38] There were multiple restructurings happened in the engineering, but I wanted to move with those repos. So my first thing was like, I need to assign an owner because if I don't assign an owner, nothing's gonna happen here. Yes, I can maybe like, you know, lean in on a guild who are voluntary and maybe they do some stuff, but that ownership was a hard kind of thing because, hey, we're not the team that, that does A, but we still have A in the product.

[17:07] I'm gonna give it to you. Nobody like is happy of course that you kinda like push things to them, but that ownership is very similar to who owns the piece within your factory as well. So who owns the factory itself, and then who enables the people on top of the factory? So we did have an enablement team that helps people adopt and use the factory, but we didn't maybe have kind of the maintenance team or the ops team of the factory figured.

[17:35] You know, eventually they became the same, and I would say that's the pattern of a platform team, but now just for the software factory, maybe not your four-year cloud system as well. So, so it's new and it's not new, but you encounter those like things and then kind of make you reflect back like, hey, we already had it happen somewhere other in the history, uh, or kinda like, uh, do there.

[17:57] **Danail Arapkuliev** But yeah, what, what was the, like the structure of the team that operates the factory? This is very interesting because you, you mentioned that it's kind of ownership, so you need to put a, a team over the factory. But what, what is the difference between this team and any other like, I don't know, team, uh, that could, could manage a- another business without the factory, let's say?

[18:22] **Patrick Debois** Sure. Um- So I think first of all, uh, I wanna point out that there w- was, um, a business organizational decision to put that team together. That's not often the case. Like, a lot of the times in organization, they would just say, "Here's the tools. Engineering, figure it out." So it didn't happen until there was maybe more of a mandate, like, "Hey, you wanna put there."

[18:44] So similar to, "Hey, we wanna have a platform. We wanna have kind of, uh, developer experience team." So that kind of is important because otherwise, again, has no owner. So but that's kinda like driving and building the factory. Now, there wasn't, uh... I think there... The way it happened is that we, we said like, "Hey, um, whole organization, uh, let's everybody build a factory," right?

[19:11] So we ended up with five or six different factories just to understand the shape of a factory, basically. So think of this as the hackathon for factory work. Uh, and then we kind of saw, like, who was kinda like leaning to this more naturally, who was kinda like, you know, kind of making like more advanced thinking around that, and kind of that, like m- almost like organically brought like the right people interested in kind of like taking this to the next level, a- almost from their laptop to kind of the in the cloud.

[19:43] Now, can you do it without? Yes. But can you do it without ownership? No. So and that's a matter of focus. So if I give it to another business group, they have features to ship, and so they will likely very much prior- deprioritize those pieces. Now, you could say, "Do you need such a team?" Or, in the future, will every team build their own factory?

[20:11] Could be, right? So that's still, like, is it a shared, uh, component? Uh, much like your CI/CD is a component that you say, well, our factory which needs sandboxes, proxies, uh, maybe some context storage, a skills registry, you know, observability. Do you want every team to have this understanding of building this whole infrastructure piece or do we put that in that team?

[20:38] Now, you could also compare, like, the most popular known platform team is the cloud platform team, but in reality, when you would have a cloud platform team, that usually runs more of a core product team on top of that platform, which I would call, like, the core platform app team, right? And then they have something that the feature teams build on top of, and then usually one feature team, if APIs are exposed to the outside, they own the outside platform.

[21:13] So there's always kind of platform, but there is an ownership, and even a mobile team often in the whole organization is the mobile platform team because they share maybe the whole kind of infrastructure of running mobile, and the others just plug in their pieces into it. So I think it's what kind of- Um, profile do you need?

[21:37] People who understand software development and AI engineering. It, it's like w- otherwise you'll be struggling, and I, I think that's maybe also to be decided. Will it be the cloud platform team that typically doesn't touch code? Mm. Will it be the developer experience team that so far didn't touch AI maybe that much?

[21:59] Maybe it lands in those teams. Could be, if they kinda like, look, ramp up and do different things. Or it could be one piece that is just saying, "We're the factory team, and we're gonna be the driver to it, uh, to do that."

[22:13] **Vitaliy Filipov** That, that's so cool. I want to dive deeper, though, on the shape of the factory, because the shape of the team, I think it's, uh...

[22:22] Yeah, I guess, I guess people, they can basically figure it out depending on their business needs or their business flows and try to work it backwards. Uh, but what usually people struggle with, I think, uh, from what we also see in our practice, because we, for example, we run with team topologies. We have enabling teams, we have, uh, stream-aligned teams.

[22:46] Uh, and when we get into our service contracts in order to help other businesses, uh, to develop their own factories, we see that they lack... Not lack, but maybe they, they struggle with, with the imagination of what is possible. What type of- Mm ... tasks we can give it a factory. Uh, what is the shape of the factory?

[23:08] Is it like a UI that you prompt, or it's like a mobile app or something else? Um, do you have maybe some... This is like a, like what is your type of preference for a coffee? I mean, I guess in the, in the future people will, uh, just, uh, have different preferences for different factories the same way- Mm ... that we drink coffee now.

[23:29] Uh, but can you share what is hackathon experience and all that from what you have seen, what- Yeah ... Um, and we can go technical here even, like is it, uh, like agents with shared m- brain memory, or is it like a decentralized structure or what, what else?

[23:46] **Patrick Debois** Yeah. So I think it's, um- On the one hand, you feel if you're overlooking, like everybody's duplicating the work.

[23:55] Uh, but on the other hand, you wanna have, um, people express what they need. Uh, it was similar to the discussion about like, "Hey, uh, should a team use the shared components that the platform team is offering, or should they kind of be able to buy their kind of like whatever tool they need and that the team runs?"

[24:15] Now, if you look at it more maybe like, uh, through a VP engineering lens, you say like, "Well, if everybody uses a different tool, um, then hiring gets harder because, uh, like if I, I get a person in this team, how do I shift that to the other team?" Um, so that's more of like having experience with different tools.

[24:37] Um, maybe there's a security team that then needs to figure out the security for all the t- the different tools, right? So the, the big point is usually if you go bigger, you try to offer two, three paved roads for a solution, and I think that's very similar to building a factory. "Hey, we think this is the shape you could use.

[25:00] This is the shape you could use." Maybe that's Monterey both front end. I don't know what, what that is actually gonna be, but there is something that like fits, uh, in those pieces as well. Um, if you don't fall in that bucket, the whole thing about your platform is that it should be extensible, but the cost is on that team to build their own, and they should justify the cost that it actually is different from the others, and that it actually then they have to take on the burden of security, observability, whatever their tooling requires.

[25:31] So can they afford that in that team? So I'm, again, I'm looking now through a VP engineering. This is not a technical lens, but this is kind of like balancing everybody has their own factory to, "Hey, we're gonna standardize as much as we can," but we need to have some leeway of kind of like having people build their own kind of factories there as well, right?

[25:49] Now, on the product perspective, i- if I look at the industry, there is the There's the piece that says, um, I'm gonna have a SaaS factory and it will take for me orchestration, scheduling, um, registry, and again, all these are kind of infrastructural components that I can plug into. I don't have to do it myself.

[26:12] Uh, and I basically build workflows almost similar to GitHub actions. I'm gonna build workflows that I want, like, hey, I wanna have this reviewed by the agent. Maybe, uh, you know, the ship is not code, but in my case it could be like documentation and I need very much like a, a rule for documentation. So that kind of is also I want an agent for code, but I also need a generic agent in case I wanna go off.

[26:39] So kind of that is again, balancing. But I, I do think that the sequencing is likely something that the, the team will kind of work out. There are workflows that fits them best, but infrastructure is likely to be shared or in, in any form or shape. Uh, and if you are really looking for more multiplicator, um, value in your organization, because we talk a lot about the multiplier effect of agents doing our work.

[27:06] I think if the agents are doing the work and you have a piece of context and harness and something that fits into a factory that all the teams can reuse, you have a multiplicator effect, right? So I usually look for can we optimize the one pipeline and then can we see how much this can be shared across multiple teams?

[27:25] Because when I do an investment here, everybody kind of goes there. Now I'm gonna take the example of, let's say- Part of my factory uses skills. Just a simple example. Um, one of the common things we find with customers is that they say, "Well, we have a skills registry, we push skills," and what happens, uh, pretty much like on the internet, "Oh, we find like a very popular skill and it seems to work for us, and we're really great, uh, and we tend to use that."

[27:53] But then we need to change something, and it's almost like, well, am I gonna fork this skill now or am I gonna contribute upstream? Right? So much like software, what decision do I make, right? Um, and if the skill doesn't work, am I gonna try to understand how the skill works, or am I just gonna write my own because I, I don't want to have the whole complexity of the whole skill?

[28:20] I just need a small slice of this. Like, again, similar to libraries, do I need the whole library framework or can I just like write my own? Uh, kind of those are decisions much similar into a factory. Like, "Hey, um, I have a sandbox, but my sandbox is not fast enough or doesn't contain whatever access to this.

[28:42] Should I build my own?" Now, what we found is that building those shared components are software pieces. Um, so let's say you have a skill that you publish and you never test this with other people. They might just silently stop using it and stop, uh, start forking this, right? But if you start providing, let, let's say, evals or anything, and you say, "Well, it was tested on Claude.

[29:10] I, I have like a continuous maintenance person or owner of that piece. I update the documentation, I make sure it's current. I listen to you almost like a product person what you need in that skill," that's a different way of writing it, uh, uh, of driving this. But if you don't have that, the fallback is I'll just do my, my own.

[29:31] Now, the other reason why you wanna do it on your own is what some people refer to resume-driven development, and this is the perfect time. Of course, because if done it yourself, there is a learning aspect and there's some kind of new thing. But again, where's the kind of ownership? Where's the maintenance aspect to it?

[29:52] Like, what happens if I have like 15 skills that do the same? So one of the tools that Tessl provides is we look at your registry, how similar skills are, how much there are security scans, how much they're being used, but we also look at- The agency logs that use the skills. So if they are not happy using it or they kind of are missing pieces of context, that's a signal.

[30:20] It's almost like your observability of your factory component, right? So it means that, like, those need to be well-architected, but if you just write a prompt and you're happy with it, and you take the maintenance and all the costs, then you're on your own. And I, I think that's very similar. Uh, GitHub, uh, agent workflows is a great way to kind of like almost have macros to build your own workflow on GitHub actions.

[30:44] It kind of works. Uh, but then, yeah, is this the way you wanna go? Um, and then there's the whole thing like, no, no, well, it needs to work on our environment, so I can't use a SaaS, and I have my own way of working. I need to have a Kubernetes somewhere in the mix, and it needs to have, like, governance of data.

[31:02] Um, so that becomes a complexity, and that, that's again, uh, another differentiator. Now, in an ideal world, I could just say, like, "I don't care which language I'm coding in. I just download whatever best practices, and it's doing the thing. And like, you know, the factory is happy and doing it." I don't think we're there yet.

[31:19] We're, we're getting closer, but then- I do wonder whether we are actually self-inflicting to ourselves that we are still deciding that we need to... Our job is to decide how these things work. Uh, but like any new technology, uh, when cloud came out, when configuration management came out, everybody was building their own tools.

[31:42] And so it was good because everybody was learning, and then everyone was saying, "We're different." But in the end, nobody cared if there's one good enough that fits all. And, uh, uh, it's the difference between I wanna tune my Linux kernel on an AWS. Why, right? Like, why still bothering there, uh, because they have a team that does it.

[32:04] Uh, so I apologize that's maybe not too much in the factory depth, but in a, in a sense it is kind of the, the similar patterns that you're seeing, uh, in a factory. Uh, so what, what, what do you still care about? And I think in general, most teams won't worry about, like, the system that does prevent prompt injection.

[32:26] It just needs to be there. I don't care about, like, the logging being captured. I don't do these things. But I might care about, um, my application has a different risk appetite for auto merges compared to yours, and I want to be able to express that because that's different from my other team. So those will be more, like, higher up, uh, of deciders that, that probably a team should care of.

[32:55] **Co-host** Yeah. And, uh, I want to steer, uh, in a bit different direction. Uh, I'm really curious, like, recently I've been reading a lot about how... And you know the narrative y- you... Software development is not a factory. Like, a discovery process, uh, and iterative incremental, and I'm really curious to see, to hear your thoughts on this and, like, how does the dark factory process, uh, narrative maps onto that?

[33:29] **Patrick Debois** Yeah. So I think, I hope that my piece about, like, engineering that engine still is a lot of engineering, right? So that doesn't go away. But, hey, maybe you trust your site provider to do part of this for you. Um, what it usually comes down then is, um... And I know the narrative is almost like, um- We wanna go to the dark factory lights out, not just, you know, input spec.

[33:58] But, you know, I think the best way of looking at it is, is, is like a spectrum, right? Um, some people never done CI/CD to the fullest that it's, like, really continuous, but they've done pieces on it. Um, and what usually hinders them is maybe, you know, either risk appetite, that's one way of doing, or... And I, I think that's an under, uh, value thing, which is kind of architecture.

[34:25] Um, I had a conversation with somebody who said, "Well, well, I don't even... I will... I never look at the code anymore." Okay. So you get these kind of statements, like, you know, kind of very leading into a dark factory. Okay. So I asked them, "What do you have?" "Well, you know, we have, uh, our harness, our context, and we, we put in all the work."

[34:44] Uh, okay, that's, that's really good. Uh, "And then we have adversarial testing. Uh, we have, like, you know, very much agents looking at code and helping me to do the review." Okay, great. And he got it up to a level where he said, um, uh, you know, "Most of the time it's great." Right. Okay. Most of the time, what does that mean, right?

[35:05] Like, hmm. Okay. So we got into the discussion about risk. Uh, well, he says like, "Well, I flag when it touches my authentication system, an API, that part of the system." Um, and I said, "How do you know that it has those parts?" Like, how does it, like, determine is that, there's parts? And he said, "Well, actually I do DDD, and I split my code base in a way that it can easily detect whether my clause goes into this piece or that piece or that piece."

[35:34] So if he wouldn't have put the architecture on there, maybe the agent could have figured it out. But the fact this was a lot more easier, right? So a- again, this is one on the review. So imagine you have that and you kind of trust your deploy. Um, what's the worst thing that can happen in production? And that, again, is different for every company, right?

[36:02] So sometimes that's like getting bad press. Sometimes that feels like I had bad performance, so sales doesn't happen. I, I can't, like, usually say this, uh, that being down is probably not, like, a very common thing. But even then, in some businesses, it's okay to go down, right? Like batch processing. I, I can't really say that.

[36:23] Um, the, the point is, uh, let's say your agent somehow deletes your database, right? Like a very common theme. "Hey, you know, I had my agents and it, it, like, it tried to solve the problem, and instead of solving the problem, it removed everything." Okay. So what do I have in place to mitigate that? Do I have a limitation of rights?

[36:44] Okay, so maybe there's something to be said, but yeah, it needs to write to the database, so how can I kind of do that? Oh, I maybe put a limit on the number of changes it could do before kinda like it actually is allowed to do it. So a full delete, maybe yes, no. But imagine still like, you know, I, I, I've done that, and it still finds a way to kind of delete that.

[37:04] How fast can I restore it? What's my window of data loss? How did I architect the application to actually, you know, be able to do that? If I didn't ask the agent right now, it probably would not design it in a way that I would be able to recover data or at least have l- a lot less impact on going back. So it's almost that similar to, uh, you know, the architectural with DevOps, the, uh, the scaling, the, the failure, and kind of like that.

[37:34] I feel in DevOps we kind of did that for compute, but we never did that for data. So yes, I can spin up a new version, but maybe the customers are unhappy, so I do canary deploys. Uh, so y- you see, there's all kind of mitigations that you can put in place even if you have kind of had that risk within a factory that is a contro- more controlled way of dealing with your risk.

[37:57] And we already had the risk of the, a human doing this wrong, so we should have already put this in place. But now with agent, you know, it's doing and maybe trying this every time it does it, right? So that, that's why I think like architecture is underrated in dealing with the discussion about towards a factory.

[38:16] Yes, you know, you get your context right, you get your harness right and so on, but I don't think it is enough to survive to production. Um, and I think that's still a discussion to be had, uh, and that's still pretty much us putting that in, uh, and then having it verified and kind of dealing with that stuff.

[38:37] **Danail Arapkuliev** On which part do you think people should focus, like, uh, from what, what you just said? I mean, what, what is the missing pieces and what are the ones that are closer to, to, to get automated and autonomous?

[38:52] **Patrick Debois** So, so it... I get like more and more often question, "Oh, we wanna go the factory route," right? So I'll first try to assess what maturity you're in.

[39:03] Again, if you, you're only doing prompts and you're yoloing towards production, uh, I'm not gonna like advise you a factory be- because that's basically automating disaster to be happening, right? So like, uh, it's almost like on the one hand I, I'd like to advise people and say, "If you, if you're not satisfied with your local coding agent harness and your context, that most of the time is that it, it's okay.

[39:31] Don't even bother going directly to a factory." Now, on the other hand, I'm still torn between if I put all these kind of good practices in my factory, come on, because then I... You don't have to learn. I already have, have learned them and I s- can scale them to you, right? So, but, but, but I, I think that's the journey, uh, probably like, you know, try to make the first loop better first before automating the whole loop because, uh, you know, there was this usual joke, uh- Uh, you know, n- with, with DevOps, I automate it, um, you know, kind of like bringing not one machine down, but now 1,000 machine down with the same script.

[40:08] And, and it's quite similar to a factory, right, if you think about that. So, um, and then if you get that in place, then immediately start worrying about, like, verifiers, uh, uh, risk analysis, and pieces like that. And maybe then start thinking more around your optimization loop, uh, in there. Uh, so make it work, make it work reliably, and then kind of optimize on that.

[40:34] So I think that's probably the advice I would give, like, how do you start with this? Uh, but yeah, I'm still conflicting if, uh, it would make sense to have a person use a factory that's well-configured, because then from day one they actually get the good practices, which kind of like saves a step there.

[40:52] **Vitaliy Filipov** I really like how factories are actually amplifying all of the gaps that we have in your organization.

[40:59] And especially, uh, what caught my attention was, uh, your recent piece about, uh, context is the new code that actually caught fire. And, uh, yeah. Um, I think it, it should start with the context because usually this is something pretty messed up. Everybody in the organization, they have their own individual bit of, uh, reality that they actually want to advocate for.

[41:27] For example, sales, they want to close more leads because they believe they need to deliver this feature. Engineers, they want to fix technical debts. Like, everybody has different context. And, uh, the, the, s- all of the software factories, uh, that I see around, uh, they want to actually first, uh, merge this- Con- context repository between all of the stakeholders, and I'm curious about, like, the business aspect of it.

[41:56] Uh- Mm-hmm ... do you believe that this is even possible? And how, how actually, if I'm a, uh, an owner of a small or medium-sized business, how should I approach this? First to get buy-in from humans or just to establish a team and s- they figure out what is a software factory for us?

[42:15] **Patrick Debois** Mm-hmm. Yeah. I think the...

[42:18] Well, there, there's two kind of pulls, and I, I think I already mentioned that. One pull is, uh, people are inherently lazy, so they do wanna reuse somebody else's work and that they don't have to do the work. Uh, but for that, it needs to be reliable, you know, that, that needs to be trusted, and, and so on. So with that kind of is the maturing one there.

[42:38] Um, the other side is I w- I wanna do it myself, so, you know, I, I don't care about your skills, but leave that aside. Um, I don't know if you remember the times about, like, you know, before Agile, the big upfront design, having the one document that describes everything that, uh, you know, I want the system or whatever I'm gonna buy that, that needs it to do.

[43:00] Trying to get a consensus, um, is not, um, how do you say that? It's not a rational process. It's a process that like aches a little bit towards politics. Like which voice do I want like higher? Um, and I'm gonna take the, you know, the, the narrative. Um, is the product owner voice stronger than the, um, reliability, uh, owner and stronger than the security owner, right?

[43:31] So you could write the same context but with different like angles to it. Um, and, and that kind of, you know, the more you share in that doc, likely the more holes and conflicting things that happen. So that, that's probably what, what, what is a struggle, uh, the more you share. If there is a consensus, uh, but they usually then somebody vouches and says like, "I think this is the way," and then the others kinda like back down.

[43:58] Uh, but that's kinda like the, the consensus, consensus model. And if you don't like that, you're gonna write like your own piece, uh, in there. So on a business level, uh, I think it's great that, let's say, the marketing team, uh, would depend on the product team for terminology, right? You know, one source of truth terminology is like this.

[44:18] Uh, but maybe marketing can't sell your internal terminology or product terminology because the industry terminology is different. So they have to find a way of like translating between yours. So in the ideal world, we're all using the same language and s- kind of the same things, but that is kind of the struggle, uh, in there.

[44:40] Now I do think in, in GTM and marketing, we're underestimating maybe as engineers how much they're using skills and context and copying and pasting whatever things to find like, uh, you know, profiles on the internet and kind like they're, they're also kinda like doing, trying to automate their jobs. Uh, but I, I do think it's a little bit like let's everybody move to the factory is like, okay, let's drive these pieces are crucial to our business.

[45:07] Let's at least make these common. I'll put an owner, and your job is to find a consensus with your stakeholders, right? So, so that, that's probably how I would, uh, go about that.

[45:17] **Vitaliy Filipov** It's a pretty interesting conversation, um, but we probably also need to wrap it up. And I'm curious about your, uh, predictions of the future, where this will go.

[45:28] Do we, do-- Are we going to have a stable factory pattern, uh, or this is just a flop and, uh, next year everyone will go in another hype train or something like that?

[45:41] **Patrick Debois** Um, I think it's gonna be hard to turn the clock back because there is definitely, like, um, improvements in there. I think we might not get to the 100%.

[45:50] I don't care about the 100%. I, I see it more like architecting towards that, but not per se as the end goal. So it gives me a way of like, you know, uh, pressure myself to, to get there. I think there's a lot of things we haven't explored, like I say, uh, multiple pipelines in the company, sales Uh, marketing, legal, I don't know what.

[46:13] Like, you know, they all have triage. They all have, like, kinda like, uh, testing. They all have, like, things. So there's combinations there, and I think the one maybe that is currently underused is that we're still much in the code review, commit, deploy. Um, I definitely hope that research, uh, and exploring things will take the upper hand once maybe that kind of level...

[46:38] I was gonna say toil. It's not toil, but it, it's kinda like the... when the, those kind of components mature is that we can kind of, uh, start, um, doing more of that. And, uh, probably the decision is more and more about, like, what features should we not build. So that is also kinda like, uh, you know, making the bets on those things and figuring it out.

[46:57] And, uh, I've seen some things of people allowing their customers to vibe code on top of their application, uh, to understand what features customers actually are doing. So I, I think we're not done yet in the spectrum of, like, where this is gonna expand. Uh, I think there's probably already a lot of the technology pieces on the board, but not, like, the way, you know, where we can...

[47:22] And I, I agree with your comment earlier. I don't think we have yet enough imagination, uh, to kinda like, you know, see where this is going yet, so.

[47:31] **Co-host** Okay. Great. Uh, and, uh, yeah, can you... As a, as a wrap-up, can you share more about Tessl and the upcoming conference that, uh, that's going to be?

[47:43] **Patrick Debois** So Tessl helps you with, um, the process on top of, um, your coding, uh, environments and the coding agents.

[47:51] Um, and so we have work on, or also on the governance of your skills registry, uh, security, uh, and also helping you bootstrap and, uh, get ready for your factory, uh, both with, like, your context and your harness. Um, so you can go to the website, tessl.io. And on the side, uh, I also, uh, organize a conference called the AI Native DevCon.

[48:16] Uh, and, uh, the theme of this year is around, uh, software factories and anything to get there. Um, it is in New York, uh, and we'll have workshops on day one, and then two days of conference, and it will be the 2nd till the 4th of November, uh, in New York, so. And-

[48:34] **Danail Arapkuliev** Cool ...

[48:34] **Patrick Debois** most important, PATRICK50 as a discount code

[48:40] **Vitaliy Filipov** Amazing.

[48:40] Thank you

[48:42] **Danail Arapkuliev** Thank you so much for, for your time. It was really, really interesting. I think we can even go, like, for two more hours talking with you. Yeah,

[48:51] **Patrick Debois** yeah, yeah. It's super interesting. I, I'd love to, like, also, you know, listen to, uh, like, the stories you accumulated. I know the b- the, the posts are coming, but, you know, if, if you could share them- Yeah

[48:59] I'm, I'm also quite interested in the, those pieces as well.

[49:02] **Danail Arapkuliev** We, we will stay in touch, yeah. We can, we can, yeah, definitely discuss around use cases and stuff that we are also doing. So yeah, great. Cool. Thank you so much, Patrick.

[49:12] **Patrick Debois** Thanks. Have a great weekend. Thank you. Bye.

[49:14] **Co-host** Bye.

[49:15] **Danail Arapkuliev** Bye.