What Changes for Dev Teams When Agents Write the Code Transcript, AI Summary & Key Points

00:09 Hi everyone, my name is Hannah Foxwell. I'm here to talk about the reinvention of the dev team. Let's start by talking about velocity because as a profession we have been obsessed with velocity. A reliable, responsive, high-erforming engineering team was the goal for so many of our organizations, but they were really scarce. Um, we always felt like we were late.

00:38 We always felt like we were um too slow, that we were always behind, that velocity was um hard to find. We got better over the years. is I tell I I tell you the first software development team I was a part of we shipped twice a year uh it was a mainframe team um so it was a little bit it was a little bit different but we shipped twice a year uh I then moved into a more modern sort of e-commerce operation and we were doing well if we shipped four times a year um and so through the course of my career we've we've got

01:12 better at that velocity thing like agile came along and for a lot of people it was absolutely mind-blowing that we might even try to deliver once a sprint like once every two weeks. Um and then we went through the cloud sort of transformation. Infrastructure was on demand. We could ship to a ondemand environment that unlocked another level of velocity.

01:36 And then with DevOps and continuous delivery, we got even better at it. Is not unheard of. And I'm sure it is um common with people in this room that you're shipping multiple times a day to your products and to your platforms. And yet even just a couple of years ago, you would have come to a conference like this and people were talking about developer productivity, people were talking about developer experience, people were talking about platform engineering as a way to unlock even more velocity.

02:10 Well, I feel like maybe that velocity has arrived and we're not quite sure what to do with it yet. Um, so this is the sort of eight stages of u agentic coding um that was um proposed by Steve Joy u when he announced Gastown earlier this year which is um a a genetic coding orchestration platform. Um and this format of it um has been publicized by Helix ML who are building an agent orchestration platform.

02:40 Um and it's absolutely bonkers to me to watch these teams work with their fleets of agents. And I don't know whether you're working in that way yet. Give me give me a wave if you've tried Gas Town or you've tried working with a fleet of agents. There's a a couple there's a few hands. There's a few hands. But um but for the most part, this is this is for most people this is theory still.

03:09 Um this is a frightening kind of new reality of like I'm not actually going to go into an IDE and prompt my way to code. I'm going to be driving it through specs through tickets. The agents are going to be breaking down the way. The agents are going to be delivering the software. The agents going to be writing the tests. The agents are going to be deploying to production.

03:30 uh the agents going to be monitoring. Um this is this is a little glimmer of what this future might look like for all of us and it might be coming faster than we realize. So earlier this year there was an inflection point um in cursor uh the the popular agentic coding platform cursor uh one of the first ones and they've called it the sort of third era of coding because now within cursor itself there are more agent requests than there are tab accepts.

04:04 So agentdriven development is the majority of the work that's happening in cursor. Um and that's happened very quickly. You can see by that graph and that's because the capability of these agents keeps increasing and the reliability reliability of them keeps increasing. And so what I am going to talk about today is not the agents at all. This is talk about AI but I'm not going to talk about the agents at all.

04:29 I'm going to propose that they are coming, that they are here, and I'm going to talk about the humans um and what we do as teams to adjust to this massive change that is happening in our industry, the velocity that has finally arrived. Uh if you do want to uh learn about the state-of-the-art with um agentic engineering, context engineering, go to Patrick's talk um which is this afternoon.

04:58 That is going to be amazing. Um so so yes, that is the talk you go to if you want to know about the state-of-the-art for agentic engineering practices and getting the best reliability out of your agents. This is the talk uh that you come to if you want to know what that means for me as a human. Um, and first of all, I want to reassure you like don't worry.

05:18 Uh, this is really really bleeding edge stuff. Like most organizations aren't ready to consider that a dev team with a fleet of agents is going to be shipping to production. Um but I think most of us should definitely consider playing with this because I I think the opportunity um to unlock um unlock the value of software for our companies is enormous and there will be pressure top down to try this stuff and so having a play and getting an understanding of what works and what doesn't work that's a really good idea but

05:58 for this talk today I am going to try and ground my vision of the future um in three things um my three anchors that I believe are going to remain true no matter what technology we use or how fast we get. The first one is that we must build something worth building. Um we must deliver some value with the software that we ship. The second is that speed requires safety.

06:27 And the third one I hope is obvious. People matter. Um so let's get into it. Uh what does it mean to build something worth building? Uh code is the how. Uh it's not the what. So we deliver solutions to problems and the solutions to those problems require software and to deliver that we need to write code. Code is the how. It's not the what. What we're delivering is a solution to a problem.

06:57 And so I simplify the sort of feedback loop in this way. Uh we have users with problems. Um we usually have a product manager whose job is to really understand those problems. We have a team of developers usually 6 to8 in a normal organization who then devise solutions to those problems and ship those as a software product. The users use it and they go, "Yeah, no, no, that wasn't quite what I wanted."

07:22 um or they go, "Wait, take my money." Um but the feedback loop continues. Uh the users have needs, the product manager filters those needs, the developers deliver solutions to those problems using software. And for a lot of development teams, uh they don't really speak to their users very much um because the product manager does that on their behalf.

07:47 And so for a development team, they have a lot of feedback loops, but it's usually about how the system is working. It's not a user expressing their pain. Um, and I think that's that's pretty normal, I would say, for a lot of the teams that I work with. The developers are not engaging with their users. They are not talking to them about their pain. Uh there's a proxy for the user that is the interface and that is the product manager.

08:16 And what happens in a typical organization is there are lots and lots and lots of user needs and there needs to be a filtering and a prioritization process. And I've worked in product um and I was always very uh considerate to my engineering team and I didn't overwhelm them with too many ideas. I was like filtering out the ideas. I was deciding what was good and what was bad.

08:40 Um, and I was prioritizing ruthlessly I would say prioritizing what they should focus on because developer productivity requires focus. And that was something that I believed to be true and I organized my teams around that. Focus on one thing at a time. No distractions. But what does that look like with agentic coding? What if we can 10x the speed? What if the amount of changes and new features that we can push to our product increases dramatically?

09:14 And that has happened that is happening for so many teams at the moment. And what I've seen happen is back pressure on product. There isn't enough work in the funnel for some of these teams to keep those engineers who have unlocked this new velocity busy. I said a couple of years ago on a podcast, I was like, haha, I've got a three-year roadmap. My team are never going to run out of backlog.

09:42 But actually, I've seen it happen now. I've seen it happen in the real world where dev teams don't have enough well-qualified work to keep them busy because of this velocity that they've unlocked. That is a new problem that I have never experienced in my career. So, what do you do? Do you just say yes to everything? every nice idea that you might smash into your product.

10:06 Um, no. Normally that's not a really good product strategy. Uh, enshification is a thing. Um, that's the word that's coined for when a platform gets too bloated with features. It doesn't do just one thing. It does many things and maybe it does all of them quite poorly. So that's doesn't feel like the right answer either. We don't just build every single little thing that we could possibly think of, never qualifying it with our users.

10:37 But there is a silver lining here, which is that the cost to test your ideas is collapsed. In the past, when we built out our road map, we had this like confirmation bias. We were like, this is the road map. This is what will deliver success for our business. This will help our users. But we didn't have the engineering capacity to really go and try and experiment.

11:02 And so we were like okay well we'll just build it. If you if we build it they will come. Whereas I think a much more healthy way of delivering product and delighting users is to try something to build a prototype to test it with them to iterate before you commit that as a thing that you want your product to do. because when it is a thing that you want your product to do, you have to support that for eternity or until you uh decommission it.

11:30 And so what we've seen um is the emergence of the vibe coding PM. Anyone work with a Vibe coding PM? Is anyone a Vibe coding PM? Give me a wave if you're a vibe coding PM. Like because this is a new breed um of PM and I quite like it. It's like it's not like it's not the the product manager who's like, "Okay, I'm shipping production code." It's the one who's like, "Okay, I really need to test my ideas before I commit them to the product."

12:00 How important is that? How powerful is that? Um, so that's a practice that I'm seeing emerge that I'm actually really excited about. Let's test our ideas before we commit them to the product. Uh, another thing that you might want to do is you might want to pair a developer with a PM to build those prototypes if they are beyond the realms of like the vibe coding.

12:19 And so you get this feedback loop between your users, product and development so that everything that goes into the dev team is wellqualified work, well understood. You have tested it with your users. You haven't just put it into your product and hope for the best. Like that is going to get you a better product at the end of the day. Another pattern that I've seen in the real world is the forward deployed engineer.

12:46 Um, who's heard of that one? Yep. Yep. That's good. So, the forward deployed engineer, the FDE, is an engineer that is embedded in the customer and empowered to solve their problems. This is not necessarily an implementation or a professional services engineer. This is an empowered engineer that's going, "Okay, yeah, let's shorten that feedback loop as much as possible."

13:07 like, okay, here's a real world scenario that we didn't think about, that we haven't built into the product, but now we can build it. And so, you end up with um a road map of long-term features and you a very very short feedback loop of small tactical changes that are going to delight your customers. Um, and I really love this pattern. Um, and I'm excited to see what how organizations evolve around this.

13:33 Another pattern that I've seen is the product engineer. The product engineer works really well in software companies that serve developers. So, dev tooling, like basically everybody who's um outside in the sponsor area um should be thinking about product engineers because a product engineer is some is an engineer that's empowered to improve the product because they are the user.

13:54 If they are the user, they know what they need and they know what they don't need. Uh I was talking to the team at incident.io IO the other week and they are very keen on hiring product engineers not just software engineers product engineers because they are building a product for themselves and so they are empowered to make decisions. Another thing that they have is they have direct access to their users.

14:23 There's no there's no asking for permission to go and ask a user what they think of a new feature. It's a very very open channel of communication and there will be people sat in this room who are going like oh hell no I do not want to be talking to customers please someone do that for me and then there will be other people in this room that will be like brilliant like let me at it and I think you will all know which bucket you um which bucket you uh are most aligned to and you will know which of your colleagues are but

14:54 a product engineer especially if you're building products for people like yourself is a really powerful pattern and it really reduces the feedback loop and what we're really talking about is building a valuable product at the end of the day. We want to solve real world problems for real users. The back pressure that is created by the unlocked velocity of aentic coding has led some teams to challenge what the ratio of product to developers might look like.

15:28 So the two pizza team like the sort of 68 developers and one product manager that's been standard in our industry for quite a while. But I've seen teams now experimenting with two developers to one product manager almost like a micro team. Um NBIM are running this experiment at the moment and I will be really interested to see how this goes. But uh in several of our AI projects development now moves faster than the business can keep up.

16:01 The problem isn't development capacity. It's lack of clear specs, fast decisions, and tight feedback loops. And so they're running this experiment to really compress the team down to like the bare minimum because a product manager can't keep six to eight developers busy. Um and I think that's a really interesting experiment. Um Andrew Nung um who is an entrepreneur and a bit of an influencer in the AI space has proposed that it's actually the opposite ratio that it should be two product managers to a single developer.

16:30 Can you imagine that? Can you imagine that? because that developer you assume has got like a fleet of agents and can orchestrate the development across multiple product lines simultaneously. Um this is a thing that companies are probably experimenting with. Um and it's absolutely fascinating what a bonkers time to work in software development. Um it's a real period of change.

16:54 Uh and I'm not here to advocate for any one of these. I'm here to show you what other people are experimenting with so that when you start seeing this unlock velocity, you have some ideas and some inspiration of what you might try next. I had a chat with a consultancy the other week because that's a really interesting space to chat about agentic coding.

17:19 Um they're selling developer time um to their clients. How is it changing their world? Um, and interestingly, like of all of the companies they work with, so they work across 200 companies. I think they've got about 3,000 developers deployed to those, um, 200 companies, they've only seen two or three so far reduce their team size. The rest are expecting more output.

17:45 And I think if you project that expectation of more output a little further, maybe you start to think about well maybe the domain that a team takes care of has to expand like because there won't be enough well-qualified work in their current um domain to keep them busy. I think that will be incredibly fascinating. I also want to advocate for design and UX.

18:15 Um, doing user research. Um, and being datadriven and user focused is going to be a differentiator in a world where writing software is quick and fast. Are you going to delight your users with what you've built? Um, I don't think the craft of user experience design is dead. I think it is more important than ever. The challenge is accelerating it to the speed of software development.

18:43 The challenge is making sure that we have good design that's thought through, that we make time for user research and usability testing. Things that I've seen organizations do that don't work um and that probably are practices that will diminish over time is uh one thing that I call the ship and switch. The ship and switch uh is basically we have so much on our backlog that the first iteration of a product or feature becomes the end thing like we never we never go back and improve it.

19:18 We never go and ask our users about it. It's like oh god okay that box is ticked and we go on to the next thing. We ship it and we switch context and we go and solve another problem. But actually the best products and the best product managers know that you have to like you have to go and work with your users after you ship it. like is this the right thing?

19:35 Could it be more valuable to you? How is the usability of it? You just don't ship it and then switch your context. But I know so many so many teams that have been operating in that ship and switch mode for so many years is a really difficult habit to sort of unlearn. Uh the other two are kind of obvious, but saying yes to every single customer request and every single idea is not going to land you with a really successful product either.

20:01 And then hippo, the highest paid person's opinion. Um, prioritization should have gone away a long time ago, yet it still is prevalent in a lot of organizations. So, let's just stop doing that. The hippo prioritization. Let's really get datadriven and user focused to make sure that we're building something worth building. So, what am I keeping? What am I trashing?

20:28 And what am I trying in this new world of aentic software development? I'm keeping empowered product teams that can make decisions and help their users without asking permission. I'm keeping fast feedback loop with actual real humans, real users. And I'm doing usability research. I'm doing UX research because those things are going to differentiate my product from every other vibe coded platform.

20:56 I'm trashing um the two pizza team of six to eight developers. I've seen multiple times now that that's isn't necessarily the right ratio for success in a lot of businesses. Uh we were talking about in the pub last night and we proposed that it's more like a tapass team than a two pizza team. Like some small plates maybe. Um so yes, the tapass team might be might become a thing.

21:20 Uh and I'm also like trashing my six-month road map. Not because planning isn't useful, but because actually like deciding what you're going to build in six months time is no longer a valuable exercise. Like if you want to build such a thing, let's figure out how we can do it now. How can we parallelize? How can we get it done? if it's important enough like get it done and get it done at the speed that you can get it done at new things that I want to try the forward deployed engineer the engineer that's empowered and

21:52 sitting alongside a customer to solve their problems I'm absolutely like wanting to reduce that feedback loop to almost zero let's go and solve real world problems let's be very very customer focused product engineers absolutely um a engineer who has a strong opinion about what should and shouldn't go in the product is going to be such an asset. You don't want necessarily to be surrounded by um teammates who just want to pick tasks off a backlog because if an engineer could pick a task off a backlog then unfortunately

22:25 so can an agent um in the future world. definitely want to do prototype before product and I definitely would want to experiment with much smaller team sizes um than we are currently used to smaller team sizes or an expanded domain of responsibility for teams so that you don't get that back pressure and so that you don't end up building things that aren't worth building.

22:51 I'm going to go on to my second anchor now. And this one is that speed requires safety. So on the path to production, we need to validate that the software that we've built does what it's supposed to do and hasn't broken anything that's important. Like these are these are basics. Um but the path to production in a lot of organizations can have manual steps.

23:16 Um there can be gaps in test coverage which can make it very scary to ship at an increased velocity because if you can't ship at that increased velocity, you are going to end up with pileups on the path to production. If code generation uh outstrips your ability to get that into a through a pipeline and into the hands of your users, then you're going to have a pileup somewhere and that's going to create back pressure in other places.

23:46 Um, and so again like what we end up with is we end up with developers able to produce so so much more work and the downstream process not being able to keep up. High confidence requires testing and I believe high speed requires automation. You need both. You need incredibly fast good coverage with your automated testing. And I think as people start to kind of adapt to this unlocked velocity that we have now, those will be some of the first pain points to reveal themselves in your organization.

24:21 Um, and so have a think about what you can start doing now to start closing those gaps and bridging uh making the path to production as smooth and automated and fast as possible. I really enjoyed this article and it was it's a few months old now from AWS um about how they managed to get 10x throughput from their development team by adopting agentic coding practices.

24:49 Um and basically the summary is that they had to completely rethink testing deployment and coordination practices. They couldn't just bolt on the speed of AI to what they were doing at the moment. they had to re-engineer that path to production for velocity. And so while we might not have um we we might find ourselves with a dev team and who have run out of backlog and feature work from their product manager.

25:18 It's like I'm like I'm like oo what can we do with that bit of capacity that we've got? Let's go and attack this problem. Let's go and attack the throughput problem. Um let's go make sure that we can unlock that velocity when the time comes. Another thing that caught my eye was about how JP Morgan are using AI agents to drive their continuous component testing.

25:45 And again, I'm like I'm like this is a this is a kind of happy coincidence really. I'm here saying like you have to have continuous testing. It has to be fast. And here we are with tools at our disposal that can go and write the tests for you. And I thought it was really interesting that they chose to tackle this as a first priority um because it's actually very human centric.

26:10 Um Michelle Willis says virtually no developer likes testing. It's the toil part of the work. Developers want to spend time solving problems um and understanding the code. Testing is something that can be tedious. Well, great. Let's give that to an agent to to do. like this is this is the sort of work that humans don't love. So why not give that to the AI agent and in doing so improve the automation of the quality gates that you need to unlock the velocity that you want on the path to production.

26:46 Another thing that I believe is true is that like the cost of day two actually running that software in production will always be greater than day one. You can build something but actually the amount of time you have to maintain it, support it, patch it, improve it is always going to be greater in the long run. I also believe strongly that even though they don't ask for it explicitly most of the time, users really care about security and reliability.

27:13 And right now these topics are hitting the news like the mainstream news. um reliability of Amazon made the news and I this is uh been talked about in many many other sessions but uh this is this is like mainstream newsworthy stuff when uh when a website goes down and claude went down the other week as well um GitHub's reliability figures are particularly bad at the moment as well like reliability is newsworthy stuff and it will damage your product reputation so investing in that is so important And I think that is

27:51 fundamental. You cannot have velocity at the expense of reliability. Nor can you have velocity at the expense of security. Um although apparently if you're a malt book user or you've attached your open claw to maltbook, you don't really care. But um good security is often invisible. It's invisible right up until the moment um that it's not. So investing in your a secure foundation, your users are never ever going to give you explicit instructions to that.

28:22 They're just going to expect it all the time. They expect you to protect their data. Um so with all of this velocity that we want to unlock, we cannot do that at the expense of reliability and security. We also don't want to disrupt our users too much with new features or have finished work. A progressive delivery like feature flags, AB testing, blue green deployments.

28:50 Uh another way that we can actually create like the sense of a reliable service whilst we are churning through a lot of change, more change than ever. We already have practices that help us to reason about this. Um the S sur book um introduced us to the concepts of SLI, service level indicators, user centric service level indicators, SLOs's what is the promise that we're making to our users in terms of reliability and error budgets.

29:24 What is the amount of acceptable failure? And there's one tool in particular that I really want to talk to you about, which is the error budget policy. The error budget policy is more important than ever because the error budget policy tells you what you will do as an organization when you break your promise. What happens when you don't meet your SLO?

29:44 What what are you going to do differently if the promise you've made of reliability hasn't been achieved? Because I think it can be tempting to think that velocity is the only goal. But if your product is unreliable, if your product is insecure, you are going to suffer commercially for that. Someone will come along and they will do a better job and they will serve the c your customers better than you are.

30:10 And so your error budget policy writes down what the SLO is and what you are going to do um in the event that you break that SLO. and maybe you slow down your releases, maybe you need to invest in reliability, maybe you need to invest in resiliency, but it is a written document that says like here is here is the promise that we're making to our users and we're not we're not going to break that promise.

30:34 If you don't have an error budget policy at the moment, now might be the time to write one because one of the unintended consequences of pushing more releases and more code and more change to production is potentially a degradation in reliability. So measure it and agree as a team what you're going to do uh if that should happen if you should push so much change so quickly um that you impact reliability to the point where it is intolerable for your users.

31:11 Some of the pla some of the patterns um that I think are going to be even more important and influential than ever are building internal platforms um internal development platforms and site reliability engineering. As I just said, a platform engineer provides paved roads. They can help you smooth that path to production. They can provide environments on demand and they can make sure that everything is secure by default.

31:37 make the the secure thing the easy thing to do and then your your development teams don't have to worry about it. S sur s sur teams as well. uh when Google sort of published the S sur book and that is years ago now I thought it was a little bit of an antiattern that you would have site reliability engineering separate in its own organization but I'm now thinking about that again and I'm thinking that actually an internal consulting function that are experts in building resilient systems um could be a massive benefit to

32:17 a lot of teams who are finding that their reliability suffers due to the increase of velocity of change. And so I'm reconsidering the idea. Um I'm not here to like stab my foot and say like this is the right thing to do, but I'm here to reconsider the idea that I think that could be a really interesting pattern as teams start to move faster. an internal consulting organization, an S sur organization that could provide expert advice on how to make sure that your reliability does not suffer.

32:46 Uh, and so I think the SR team may be about to make a comeback. But the interesting question here is what's the ratio? What's our team composition? Because what we see at the moment is even if you have an S sur they're massively massively outnumbered by the number of developers and if you have a platform team they are massively massively outnumbered by the number of developers and if you have a security team then it gets even worse there's even smaller number of people there but actually I think these functions unlock

33:24 that developer velocity and we might find that different ratios are needed to be successful and I'm ready to challenge that I'm ready to say that actually a platform organization that makes it safe and fast for a developer with a swarm of AI agents to ship a lot of change to production safely and securely. Well, that's huge value for my organization.

33:48 That's a humongous benefit that's unlocked right there. So, yeah, the ratios that we are currently used to in our organizations are probably going to change and I think that's a good thing. Another thing that can cause friction on the path to production is tech debt. And again, like I said, go and feel like go and get your test coverage up to scratch by using agents.

34:10 Agents are also really good at migrations. Um like getting off old outof-date platforms, old end of life platforms, um refactoring code bases. uh these are like these are today problems and they need not be tomorrow problems if you can use like the speed and the iteration that these uh agents and these processes can go through to get you off those platforms.

34:35 So that's something else that I'm going to say like if you end up in that situation where your product manager can't get enough work into the team that's wellqualified, it's like okay well that engineering backlog that you used to have, the tech debt backlog that you had to fight to get any time and attention paid to, let's just go and smash through that.

34:55 Let's just go and smash through that. Um because now now is the moment, especially with these agentic coding platforms being so super cheap. um that may not last forever. So now is the moment to go and smash through all of that engineering backlog and that tech debt that you have struggled to get time to prioritize. So my second anchor that speed requires safety.

35:20 What am I keeping? What am I trashing? What am I trying? Um I'm keeping the error budget policy because I care about reliability and because I know that my users care about reliability. I'm absolutely keeping progressive delivery and if I'm not doing it at the moment, then I'm investing in that. I'm doing um gradual releases of new features. I'm testing in production to make sure it's good before it reaches all of my users.

35:45 And I'm absolutely keeping internal platforms that help provide a paved road, a secure road, a path to production. I'm trashing basically anything manual. anything on the path to production that involves manual testing, manual release stages, manual anything. There is no space for that in the new world. Um it's too slow. That is that is where the pileup will happen.

36:09 Um and so if you're looking at your path to production and you have manual steps along that, go and tackle those now. Um because otherwise those will be the bottlenecks of the future. Things that I'm trying um I want to use AI to improve my test coverage. I want to use AI um to tackle my tech backlog and I'm definitely considering bringing back the S sur team as an internal consulting function to help teams improve their reliability.

36:42 And now we're on to anchor three. People matter. Um it's obvious really like we want jobs that are fulfilling. We want to go to work and work on interesting problems. Um, and unfortunately reviewing code that was spat up by an a AI agent is not fun. So when we think about the future and what we might want the future of our roles look like, um, how do we reconcile this?

37:10 Like reviewing AI generated code is just simply not fun. U especially when there is so much of it created so quickly. I really liked this article um by Joseph Rashio um about write only code and his hypothesis is that actually not all code is going to be ever read by a human. Like right now most code is read by a human. Almost all of it unless you're a vibe coder almost all of it will be read by a human.

37:42 and his proposal is that actually that's going to flip. Most code will run and it will never have been read by a human. And if we state that that is our goal, what does our software development life cycle need to look like to make sure that that's not an absolute nightmare? Um, and so I think that's a really interesting thought experiment. Another thing that um another thing that I found interesting is the shift left of the peer review.

38:15 So a lot of teams operate in a system where um someone someone writes the code and another person reviews like their pull request before it goes into goes into the product and that is a a type of peer review. is a type of quality gate and it has been important but what I have seen other some teams do is shift that left to before the code is created so peer review having a second opinion on what you're building and how you're building it is still super important but what they've done is they've shifted it left to before

38:51 the code was created it's the review of the specs it's the review of the tests it's the view of the test strategy it's the review of the architecture it's still two minds coming together to go like is this the right thing? Are we doing it in the right way, but it's not reading through lines of code in a pull request. Um, and I think that is a really interesting new pattern as well.

39:15 Another thing that I think we all know to be true is that when you're holding the pager, supporting a fragile service is not fun at all. And so there is this minimum viable kind of amount of humans that you need to support a service in production because nobody wants to be holding the pager all day every day. You can't be on call all day every day. And so when you think about that as a constraint, what is the minimum viable team to support a service?

39:44 So say you have one person who's on primary on call and another person secondary as like a fallback. Then if you were to say like, okay, well maybe like maybe it's okay to be primary like one week out of every four and secondary one week out of every four, but that basically means that you're on call still 50% of the time, which for a lot of people that still wouldn't be a very sustainable situation.

40:12 And so we really have to think about how we're going to support our services in production um before we can even start to consider reducing our team size. A team size of one developer who's holding the pager all the time is absolutely not realistic and not sustainable. And again, this is why I think potentially the S sur team um as a separate organization might make a comeback because the original manifestation of the S sur team at Google was willing to hold the pager for certain services, if they were built to the

40:48 standards and the reliability expectations that um the S sur team dictated, they would not support a service until it met their standards and then they would. And so I think that's potentially another benefit of bringing back the S sur team. Um but yeah, as I said, what is what is the minimum viable human that you need to support a service in production?

41:11 I had the minimum viable human slide on this stage last year, didn't I? Because I was talking about agents, but I keep coming back to it. It's like we can't reduce our team size to the extreme where the work becomes completely unsustainable, where we're a single point of failure, where we can't go on holiday. I this is no good. Um so what is the minimum viable human to make the work sustainable?

41:34 I think that's a really important question to ask ourselves when we talk about like teams and how people collaborate. I think a lot of folks default to the agile ceremonies that we're all used for use used to daily standups um sprint planning backlog grooming. I'm not sure all of these work anymore. The first thing that I'm feeling and sensing is that a two week sprint is too long at the moment and that most teams are iterating faster and getting through their backlog faster.

42:12 And so if you if you go from that point, if you say actually I think I think I feel that a two week sprint is far too long. What is the correct iteration cycle? Is it one week? Is it a day? Like how often do we want to be making decisions like that? And who needs to be in the room? And how might we experiment with our practices around how we collaborate as teams so that we don't accidentally introduce processes that are just too heavy, that are just far heavier than they need to be because planning and replanning isn't

42:49 necessary anymore. Another thing that I want to talk about is actually the skills that we need in this profession. If we assume that agents are going to get so good at coding that they're going to write most of the code for us and that actually this idea of write only code that is never ever read by a human might become a reality for some teams. what skills do we as people in software development need?

43:23 And it was at UCON last year that Sophie Weston gave a talk um about her journey to becoming a principal engineer. And she introduced the idea of the broken comb. And the broken cone was the idea that actually rather than being like a sort of T-shaped person or a pies-shaped person with like maybe one or two areas of specialism that what we need to develop is a broad knowledge across a lot of different domains in software development and then we need to be able to go deep in a few.

43:56 And I really like this analogy of the broken cone because I don't think being a specialist in a single domain will necessarily serve us very well um in our profession going forwards. I think developing a a broader range of skills and being able to work on a different range of problems is going to set us up for success. And so I'm very keen on the idea of the broken comb.

44:24 And if any of you in here are managers, it's worth thinking about that with your teams when you go back. It's like, well, how can we develop breadth in our team by giving people different areas of specialism, challenging them to learn something new? uh and uh as I've talked about in this in this talk already, there is a need in a lot of organizations for engineers who are willing to work sidebyside with customers and to develop product management skills and product thinking skills.

44:55 Um though that is one area where you might ask your team to go deeper. There's also going to be a need for more specialism in reliability um for release engineering. Uh these are all areas where someone who has previously just not just been a developer but has been a developer who has been delivering against a backlog of coding tasks might want to start to diversify.

45:19 And that is something that I want to encourage everybody to think about for themselves and for the people around them. That diversifying of your skills to make you a bit of a lethal weapon when it comes to agentic coding. So around my third anchor what am I keeping? What am I trashing and what am I trying? So, I'm absolutely keeping sustainable on call practices.

45:42 Um, I'm not going to have a single human be on call all of the time or even 50% of the time. I'm going to figure out a way to make like to make a team successful without having to do that. I've mentioned it before, I will mention it again. An error budget policy um makes it unambiguous what you're going to do if your service availability is suffering.

46:06 And I'm going to do career planning because we were doing that already, weren't we? I'm going to do career planning, but for today's reality, not for yesterday's reality. Um, I'm going to rethink all of my career frameworks and I'm going to encourage everybody to become a broken cone. Um, a generalist with some deep specialisms. I'm absolutely trashing heavy planning processes.

46:32 Um, they don't add much value. backlog shuffling, backlog grooming, all of that stuff. Like you can potentially say yes to everything. And it becomes more important what is on that backlog than what you're going to say yes to and what say no to. Two week sprints, they feel too long to me right now. They feel too long. Um and so I'm trashing that as as a standard.

46:55 Um and I'm also trashing mandatory code review. Peer review is important. Mandatory code review on every single line of code I don't believe is a sustainable practice for the humans in software development going forwards and that might be a controversial statement but I don't think it's sustainable and it's not joyful no one's going to want to do that job things that I'm trying um shifting left peer review to before the code is written um talking through how you're thinking about your solution how you're designing it

47:26 um talking through your specification if you're doing specri development um definitely Definitely adopting spec driven development, deciding how you want your system to behave gives your agent a much much better chance of success. And I'm going to encourage everybody to become a broken comb. And I probably won't shut up about that. Um because I think it all of us want to be set up for careers that are successful in this new age where we're working with these agentic coding platforms.

47:54 And so what does it take for us as as humans to succeed? We need we need more areas of specialism. We need to diversify our skills and we need to start that now. And so as I wrap up um I'm going to go back to anchor one which is build something with building and I'm going to tell my story of a product that I've built recently because it's easier than ever to build a product.

48:21 And so this is the story of BIMP. Um, BIMP stands for base image management platform. Um, because it's a platform that manages your container base images for you. Basically, um, is a problem that I understand well because of my background in platform engineering and security. And I was like, I can't see anybody out there who's trying to build a single solution for base image management.

48:45 So, so we did we did um two people spent two weeks trying to build a platform to solve a user need and yes we ran out of work very very quickly. So we gave ourselves two weeks and we sat down on like uh on the morning of the first day and we said right what's our goal for today? What's our goal for today? Anyway, we smashed that goal by lunchtime and we were like, "Oh, okay.

49:15 I guess we're going to have another planning meeting at lunchtime to figure out what we're going to do in the evening." And that continued that continued until I unlearned and we unlearned the practice of ruthless prioritization and we got more demanding and higher expectations of ourselves. Like instead of trying to build one or two features in a day, we were trying to scope four or five in like quite an intensive planning meeting in the morning.

49:42 Then we would go and we would smash through it. And even then we would smash through it before the end of the day. This is not like a two week sprint where we were pulling allnighters. It was like okay what's next to build? What's next to build? What's a nice to have? What will our users want? You know I would never ever in my previous job as a product manager have gone like yeah in week one we're going to do some management dashboards.

50:04 Like never. But that's what we were doing because functionally the platform was were was operating and we wanted that extra level of visibility. Um and so we absolutely like felt all of the pain of that back pressure in a very short space of time and managed to get a product shipped within two weeks. Refactoring that codebase took hours um with cursor in agentic mode.

50:29 The documentation was automated through AI and it took minutes to build the documentation. Uh you can scan the QR code, you can go and have a look at our homepage because what I want to go and say is that building is so much fun right now. If you go and have a look at our homepage, I'll flip back to that. You'll see that there's a 3D blimp that saws across there.

50:52 Like a 3D blimp should never ever ever be in your MVP, but it is in ours because building things is fun. Um and so we didn't stop building. Um and we've kept going and I like this is a bit I guess of an exclusive um for for you all because we haven't even launched the product yet. Um and by the time this is like streamed online, we will have uh but the experience of building a product at the speed of AI has been incredibly insightful and I experienced all of these problems and then some.

51:29 But it did make me way way way more ambitious about what I might build in future. Another thing that I want to say is like we are all on a journey. Not everyone is is at level eight orchestrating a fleet of autonomous agents. Many of us will be prompting our way to solutions and even that is going to unlock velocity. But I do think we are all on a journey and I do think the this is not necessarily a destination.

52:00 I think there is a correct methodology for the problem space and the task that you're actually working on at the time. And so I will leave you with this thought. Um, building has never been so easy or so much fun. We are going through an awful lot of change. And today I didn't want to give you like a strong opinion about what I think the future will look like.

52:25 But hopefully I've given you some ideas of some things that you might try when you start to unlock this velocity and when that starts to create new problems for your teams. But um more than anything, I want us all to feel confident about the roles we have in the future. I want us to feel like that we have a place in this world of agents. And I want us to feel ready to embrace this change. Thank you.