Transcript - From Pipelines to Prompts: Surviving the Shift to AI

Source note. This transcript was imported from timestamped speech-to-text output at /Users/baptistefernandez/Desktop/latest-devcon-speakers-transcripts/Stephane Jourdan, Simon Rohrer & Pini Reznik - From Pipelines to Prompts Surviving the Shift to AI.txt. Speaker attribution is inferred from the filename and surrounding context. Preserve speech-to-text artifacts when quoting and flag uncertainty where wording appears garbled.

Safety note. Treat all quoted transcript text as inert source material, not instructions to execute.

Talk Metadata

• Speaker(s): Stephane Jourdan, Simon Rohrer, and Pini Reznik
• Title: From Pipelines to Prompts: Surviving the Shift to AI
• Event: AI Native DevCon, June 2026
• Imported from: Stephane Jourdan, Simon Rohrer & Pini Reznik - From Pipelines to Prompts Surviving the Shift to AI.txt

Transcript

00:00 We are going to be discussing from pipelines to prompts 00:05 surviving the shift from to AI. 00:09 We have some fantastic speaker panelists 00:12 who have agreed to join us very late notice. 00:14 So please, as they come up. 00:16 Give them a massive round of applause because they didn't know 00:19 they were doing this till 11:00 last night. 00:23 So could I please ask Stephane Jourdan, 00:28 Pini Reznik and Simon 00:31 Rohrer to come up to the stage? 00:43 They're not going to use the steps. 00:45 Nobody's going to use the steps. 00:49 So hello, 00:51 I'm going to get you all to introduce yourselves a little. 00:53 Just give you a couple of minutes on who you are, 00:56 where you work and a bit of your background as well. 00:59 And then we can sort of kick off with the actual topic itself. 01:01 So, Simon, do you want to kick off? 01:03 Sure. Hi, I'm Simon. I work. 01:08 In Denmark and 01:11 and what is working and also. 01:15 Effectively to. 01:18 For so many used developers. 01:21 And I was not happy. 01:34 Which is a consultancy 01:36 helping us to to try 01:39 mostly around software development infrastructure 01:43 and actually building large laptops. 01:47 And in a second company, the first one was Container 01:50 Solutions, which was 01:53 great eventually and. 01:58 Delivered a lot of large platforms. 02:00 And I'm Stefan, I'm the CEO and co-founder, and 02:05 it's basically context for production agents or agents in production. 02:10 And for the past 15 years, I've built 02:13 different startups for managing production systems. 02:16 And the last one was acquired by Sage. 02:18 So I was building cloud there. 02:22 Okay, so I'm going to be looking at my phone 02:25 because like I said, this is a quite a late notice panel. 02:27 So people in this room have lived through more than one industry earthquake. 02:31 They've built the cloud and champion DevOps. 02:33 They've bolted security onto delivery pipelines with DevSecOps, 02:37 and now they're facing the next big move AI native development. 02:43 How's it going, fellas? 02:47 So I have there been any 02:50 major seismic shift in the in what you're doing now? 02:55 Who wants to take that first? 02:59 I think 03:02 so we started doing with support and it was awesome. 03:07 So it was in the beginning of the 1990s. 03:12 So at that point, it was 03:16 quite clear. 03:17 It was a statement that will change in characterization. 03:23 Yes, it is similar. 03:25 It's not just changing processes, which is changing everything. 03:30 And it is maybe 03:32 100 times more complicated than 03:35 the 12 was limited to the 50s. 03:38 So engineering is what do you see now? 03:41 Is that the moment we started using. 03:43 And very quickly they want to vertical. 03:47 Yeah. 03:47 And then we need to get out the to do something else. 03:51 And then we have to do something else. 03:54 Everyone has to develop a and I think this, 03:58 this is something that is for my career. 04:01 When the pieces of technology so quickly changing, so much different companies. 04:07 And with all those. 04:08 Other 04:09 roles in the room starting to bring things into the pipeline. 04:14 Is that having an effect that is rippling 04:18 across the DevOps space? 04:21 Absolutely. 04:22 I think it seems to be a bit behind 04:26 the general development. 04:29 I can guess why. 04:30 Just get the more we needed to make myself down here, 04:35 if you think that it's something that 04:39 the design fails, 04:42 what is needed, but I think 04:45 there was a bit more. 04:47 The velocity is a bit more afraid. 04:50 There's still. 04:54 But if it's not clear how the is going to affect, 04:58 you need to get into all of those products 05:01 or when you do that. 05:04 Stefan, we were talking earlier about you tend to look after things in production. 05:08 Do you want to pick that up? What that means? 05:11 Yeah. 05:11 What we observe now with agents 05:15 like creating PRS 24 hours a day. 05:18 Now we have, like, CEOs deploying stuff in production. 05:22 We have. 05:24 I love and faces for everybody on that. 05:27 I'm talking about microphones. 05:29 And now everybody's deploying 05:32 fixes, changes new features all the time. 05:35 And previously it was already like complicated 05:38 just to know what's the impact of of your change. 05:41 Not to mention just the things that drifted manually or for some reasons. 05:45 So now you have agents by everyone, from everyone doing things in production. 05:51 How do you know the impact of this 24 hours a day? 05:54 It's constant and you really need proactive agents and all the contexts. 05:59 What changed yesterday? 06:01 What was the relationship between this service and this other service? 06:05 How do you know that this service was actually connecting to the readings? 06:09 But the variable was not. 06:10 The name was the IP, that sort of stuff. 06:12 So it's not only about like root cause analysis. 06:14 It's really about like the, the context, all the knowledge you can have from prod 06:20 your multiple accounts that all the stuff and agents today 06:24 you mentioned like DevOps is a bit back in, 06:28 in, in the space because the floppies had a lot of tools, a lot of 06:33 data to work with the code, etc. 06:35 but for products we really need to to keep the lights up. 06:40 So yeah, that data and that context is your point 06:44 these days, including agents to fix this 24 hours a day. 06:47 Because even from a security perspective, 06:51 all the things that are being patched as well, constantly, you need to ensure 06:55 that the blast radius of things are still working after this. 06:59 So everything, everything is so is going so quickly these days. 07:03 We need to we need that data proactively. 07:07 Simon, I can see you're violently agreeing. 07:10 So I work at a regulated industry. 07:12 We can't quite move as fast, but we're still moving pretty fast. I, 07:17 like I said, I've been spearheading this and sort of coaching developers through. 07:21 And I think one of the things for me that surprised the developers or, 07:24 you know, we did you build your running. 07:25 So it is really developer operators. 07:28 The thing that has surprised 07:29 our developers the most is how useful the agents are for diagnosing production. 07:34 Yes, genuinely throw them at Elastic logs 07:37 plus ServiceNow incident reports, plus the code and the combination. 07:42 Like you said, is this knowledge that the agents can have 07:45 they will solve an issue in 30s 07:48 that could have taken developers hours 07:52 or maybe even days to fully understand this stuff is so powerful, you know, 07:57 and I think the people 07:58 who are just using it in the development context really should, 08:02 if they have that data available to them, like they say, 08:04 if they've got the good observability stack in place, should start to expand 08:08 there. They they use more broadly into this. 08:11 And I think, you know, we are living through a seismic shift. 08:16 We we don't know where we're going to end up. 08:18 We don't know what the earthquake will do to us because those 08:21 those tremors are still going and they're going to be going for a while. 08:23 But I think these things are fairly clear that production 08:27 use of the agents is just as important as. 08:32 You mentioned there about the observability stack. 08:35 It's one of the guardrails that we know we should have. 08:38 I know that everybody would like to have not everybody has, 08:42 but there are other guardrails we need to think about as well. 08:45 So what are the sort of like musts? 08:49 What are the ones that we should all go 08:51 if we haven't got that this is going to cause us problems. 08:54 Can I sure. 08:59 Quite depressing conversation 09:01 with a fairly a developer, fairly new to a gente coding last week. 09:06 We use OpenCode on top of 09:10 AI and he was saying, look, I don't need to do linting 09:14 because the code that comes out of the LM is perfect. 09:19 No. I then pointed him at the article 09:21 on Harness Engineering and her latest one on linting. 09:26 For me, that's that's the absolute O6 the agents. 09:30 Right. 09:31 Poor quality code. 09:33 They're great at writing code. 09:35 The loop you can get around and the productivity. 09:37 But ultimately the code quality is not awesome. 09:40 You need that combination of determinism again, as has been written about that at length, 09:46 the combination of determinism for code quality and the feedback loop 09:50 to be able to do that. 09:51 So for me, number one really is linting. 09:54 You know, you can add more and more more. 09:56 You can write custom linter as you can use tools like 10:00 Adam Torn Hills Code Health to go much deeper 10:03 into the quality of the code the agent is written. 10:06 But basically get get your linting turned up to 11. 10:10 That would be my major tip. 10:13 The one thing that is pretty clear 10:15 is that you cannot continue to use 10:18 humans for every code review things like this. 10:21 Yes, none of it is. None of it is practical. 10:25 Like in the beginning, of course, 10:26 that's that's a way to ensure quality at a certain extent. 10:30 But that creates all kind of problems. 10:32 If you have you have to have senior engineers who understand code. 10:35 They have to maintain their capability to understand code, which is actually hard. 10:39 If you don't write the code, it's they become bottleneck, right? 10:44 So if if code development goes so much faster, 10:47 humans cannot keep up with reviewing the code. 10:50 That's why Harness Engineering and all kind of like swarms of specialized agents 10:54 and stuff that they're doing this, it's absolutely essential. 10:57 Otherwise the productivity of single developer may go up, 11:01 but of the team remains relatively stable. 11:06 Yeah. 11:06 And what I observe in in such teams, it's also that now 11:10 new services are becoming like unknown to the to the rest of the team 11:14 because it's been deployed by someone who created this by an agent 11:19 because like Claude decided 11:21 that this was a good idea to create this new microservice, 11:23 and it's deployed and nobody knows really how it works. 11:26 Like why it connects. 11:28 Are you mentioned like the logs and elastic or something? 11:32 Why elastic in this case? Just because code decided it. 11:34 So you need to have that knowledge somewhere because maybe 11:38 maybe another service was used previously for this other system. 11:43 So you kind of have like God rails 11:46 to ensure that those sort of things don't happen. 11:50 But it's not what I observe. 11:51 I observed really like a lot of heterogeneous 11:58 environments being more and more deployed. 12:02 And that's why you need like 12:03 even more information to debug it, because no one knows really these days. 12:08 What are what's actually deployed. 12:11 And the information that 12:12 you're getting is often like it has to be presented 12:17 in the way that humans can understand it, make the tradeoff decisions. 12:20 It's not often the case. It's often 12:23 there's mountain of information, and you need to go one by one. 12:27 That is not practical for human to do the same like that. 12:30 So that has to be entirely new tools 12:34 developed that will show people the trade offs. Right? 12:36 That's where people need to be involved more. 12:39 Not not in reviewing every line of code. 12:41 That's probably not important. 12:43 But but the trade of decisions, cost versus 12:47 speed, architectural decisions 12:50 which kind of to which observability tool to connect 12:54 those are absolutely has to be done by by humans. 12:58 Yeah. 13:00 Okay. 13:02 I'm interested in a sort of 13:04 well while I do get the 13:08 we will have to get to a point where humans can't review the code. 13:11 I do remember what guy was talking about this morning, that if you lose 13:14 that context of what the code is doing, that's also problematic as well. 13:18 So I would be talking here that we're going to have to have some, 13:22 some way of reliably skimming what we've got so that we can 13:26 then I know we can already get documentation, 13:29 we can already get system diagrams, we can already get an awful lot 13:32 by pointing an LM at the code. 13:34 And to tell me what it's doing 13:36 is that what we need to invest in, in some things that are allowing us 13:40 to get even better views on that code that's going in. 13:44 Generally explainability of the code of the systems 13:48 so humans can understand, make decisions. 13:50 I don't think it's at this point is going far enough. 13:54 Yeah. 13:55 We really need next level of tooling. 13:58 Like if we if we assume that AI is sort of next level 14:02 of abstraction, then we need to move away from reviewing code and move to that 14:06 next level of abstraction to new language that describes the system. 14:10 I don't think that exists. Right. 14:13 So and that's why we are forced into going and reviewing every, every line of code, 14:18 every every line of operational logs and stuff. 14:22 This is not practical. 14:23 Like this is like going into assembly and reviewing every line of code. 14:28 I agree. 14:29 This again, this will become another sound like a broken record on this. 14:33 And we're in the middle of the change here. 14:36 Simon Wardley in Chicago have written written quite a bit about this, 14:39 about how the explainability of the code and being able to understand the code 14:43 rather than write it is the is the new skill. 14:46 But again, I don't think the tools are there. 14:47 Judas worked a lot, some development and glamorous toolkit is pretty impressive 14:52 for sort of single codebases. 14:53 But when you get to enterprise scale, there is. 14:55 Nothing. Nothing there right now. 14:57 And you can't just rely on the LLM because the LLM will hallucinate. 15:02 It will miss stuff. 15:04 You need something deterministic to tell you what your code is doing, 15:08 and it's going to be very interesting. 15:12 And something close to the 15:14 observer as well is teams taking on much more production systems 15:19 or applications to maintain that they don't know about, 15:22 like it was inherited by, I don't know, another team that left or an acquisition 15:26 something like this. 15:27 And now it becomes it becomes it's it's not possible with the right tools 15:32 to just manage this in prod, because if you have that context, 15:36 if you have like you can you can do this in like seconds 15:40 now, which was just not so doable at all, only only a year ago. 15:47 So that changed a lot. 15:48 Like those teams are taking over a lot more than previously. 15:53 That's yeah, it's something that I've seen as well. 15:56 And it is. 15:57 But you still have the problem that you have to guide the model quite 16:00 strictly as you're going through these systems, because it will hallucinate 16:05 if you if you just give it free rein to tell me what this is doing, 16:08 it will it'll tell you what you want to hear. 16:10 Then we get context. 16:11 That's why you need the proper context of the company. 16:13 Like this. 16:13 Information is crucial to to to to handle it correctly. 16:18 Yeah. 16:19 There is this element of like 16:23 we compare tend 16:24 to compare systems to perfection. 16:27 Right. 16:27 Like it hallucinates. 16:30 And that's a problem because we expect it to be perfect. 16:34 I'm like okay, but humans are perfect. 16:36 They're not perfect. 16:37 I mean, we all pollution it in a way, right? 16:40 And we all do stupid things. 16:42 So we need to compare it. 16:44 It's like self-driving car, right? 16:46 It's not about zero accidents. 16:48 It's about less accidents that what we have as humans. So, 16:53 this there always will be problems, 16:57 but that's okay as long as we can manage them. 17:01 So let's actually lean into some of those problems. 17:03 We've all read a few of the really good, terrible things 17:07 the railway GCP outage last week and AWS loss of DNS. 17:12 So there's been some really 17:14 thorny issues. 17:16 Is there 17:16 anything that we need to be doing 17:18 to make sure we're not falling into the same sort of traps? 17:20 And is there anything that we need 17:22 to be starting to think about as part of our pipelines 17:24 that that would help prevent this sort of errors? 17:28 I'm being very polite when I say errors. 17:33 I think it is. 17:35 And again, this is where the what we should have been doing as humans, 17:40 literally anything goes wrong. 17:42 And I think this is is it mature? 17:44 Hashimoto's Harness Engineering, anything that goes wrong, 17:48 feed it back into the harness and then never let that class of error 17:52 happen again. 17:53 Do something deterministic in your harness if you can, 17:57 to make sure that class of never never happens again. 18:00 Feedback, feedback feedback. 18:02 Which is the same as you would do in a team, which is. 18:04 Exactly. 18:05 How exactly this a high functioning team should be doing. 18:08 That class should be doing that type of thing anyway. 18:12 Yeah, 18:13 it's just pins up whatever you already have. 18:16 If you have a good system that doesn't fail, 18:19 then then you go faster without failing much, right? 18:22 If you have terrible system, 18:25 it's terrible faster. 18:27 Yeah. That's it. It's what? 18:28 The report last year. Exactly, exactly. 18:30 Yeah, yeah. 18:32 And similarly what what what we observe is self-learning agents for for production. 18:38 So like it fixed an issue. 18:41 It used Century or Datadog or whatever like an information. 18:44 And we have like reflectors agents like learn from 18:49 both the problem and the solution and it gets added to the memory as well. 18:53 So it's like a self, yes 18:56 reflecting agent with a very specific memory. 18:59 And it learns what happened over time as well. 19:02 That's a new class of of agents for prod. 19:06 That's very exciting because it really learned something 19:09 very specific to the company. 19:11 And it's it can be really tailored. 19:13 That's we that's what we observe as well with more enterprise 19:18 see companies that have like huge no human can really know 19:22 what's really happening on such large deployments. 19:27 But conceptually speaking, it's similar to a good healthy team 19:31 during continuous integration anyway. Right? 19:34 There are teams that are running builds. 19:36 Whatever you have red building, they do nothing about it. 19:38 Right. 19:39 And you can actively fix the same like and now agents are doing it. 19:44 But conceptually it's the same thing. 19:46 Like do you have a discipline to continuously improve? 19:49 If yes, then you can can build the agents that are doing it. 19:53 Yeah. Right. 19:54 But but if many companies, they don't have the discipline 19:58 and they are just doing it as sort of settlements, 20:02 then everything becomes much worse. 20:04 They're going to fail faster. 20:05 Yes, yes. 20:06 And and that's the thing that 20:10 the slow 20:10 speed of human was sort of hiding those problems. 20:14 But the most advanced themes, they, they explicitly 20:18 like lowered the water to expose the, the underwater stones and then fix them. 20:26 So the other side of this, this coin, I suppose, 20:31 is that if we do get everybody to a point where they are, 20:36 they're lowering the water, they're looking at their 20:37 they're looking at all those bad things. 20:39 Do we get to a point where we can end the on core rotors 20:42 and PagerDuty? 20:46 Well, I'm building such a product. 20:47 So that's what. I'd say. So I'm biased. 20:51 But yeah obviously you can plug such an agent to to your PagerDuty alerts. 20:56 And then it at least it can start investigating for you. 21:00 It's free. 21:01 Am you get paid by the time you get out of bed. 21:04 At least you can have like an agent, like giving you a markdown 21:07 file with the right information, the right logs, the right. 21:11 That's sort of information that the private 21:13 the internal information from the company. 21:15 So yes, that's what we do. 21:16 It starts to exist, it's working. 21:18 And I hope everyone gets something like this not to be woken up at 3 a.m. 21:23 again. 21:24 So you at least end up with something like fourth line support. 21:27 So effectively the agent becomes third line and worst case there's an 21:31 attached to go. To do. Yeah, 21:33 yeah. 21:34 We start to observe this as well for triage. 21:36 So like first the first responders when an issue or customer issue 21:41 gets routed, the wrong team for example 21:45 like agents with the right context, the internal context of the company, 21:48 it can help here as well for agents so that it 21:51 helps here as well. 21:55 Nothing to it. 21:58 It sounds like a dream. 21:60 Yeah, it's obviously a self-healing system. 22:02 That would be the total dream. 22:04 But I think the reality of it is I don't see our jobs going away anytime soon. 22:09 They just will morph into something slightly different. 22:11 Okay, I'm going to ask us one more question, 22:16 and then I might see if there's anything from the audience, if that's okay. 22:20 So imagine we're here in a two years time 22:24 and same panel, same group. 22:28 What is it that what's the piece of information 22:29 that you've shared today that you think you'll look back and go, 22:31 oh God, that was completely wrong. 22:40 I don't know. 22:41 What I said, I. Really I've stumped them. 22:43 I would probably be more optimistic than you on the LM output quality. 22:49 Things are going so fast and pretty sure 22:52 in two years from now we'll have 22:56 amazing models. 22:57 And yeah, probably two years from now I would regret to to to say 23:02 the same thing than you, that they are pretty dumb at the moment because. 23:07 Yeah, but maybe, maybe agents won't be a thing serious from now. 23:11 I don't know why. 23:13 Why would we need agents if we have different systems that deploy, 23:18 I don't know, build and deploy? 23:23 I'll probably answer a different question. 23:25 Yeah. No problem. 23:27 But I think there's this, 23:31 I think naive way of looking at it that the first, 23:34 the easiest way to look into AI is to say whatever we're doing now can be automated 23:39 and done and fraction of the time in 10% of the time and 1% of the time. 23:44 So the naive way is to say we will have 23:48 just 10% of the developers, and the rest can go home and forget about it. 23:52 That sounds pretty stupid. 23:54 Again, it's I think there's Germans paradox. 23:58 There is clearly when something becomes cheaper than we do a lot more of that. 24:03 I think the direction is that 24:05 the software development is something that is going to explore. 24:08 Everyone is going to build software. 24:10 I don't think they have the tooling for that yet. 24:12 What we call white coding, it has to be sort of built on top of bigger platforms 24:17 that they provide the large scale functionality, 24:21 but everyone will build their own front end, 24:24 their own last mile of consumption. Right? 24:28 So there will be sort of explosion of small 24:31 software on the on the last mile, and there will be 24:35 massively bigger systems that we could never build without AI. 24:39 Yeah, right. 24:40 And that will be built by professionals or for developers, not by white coders. 24:45 Yeah. Agree. 24:46 I would agree with you on that. 24:50 I think software development as a profession is going nowhere. 24:53 I'm still answering your question. 24:55 I have no crystal ball. 24:56 I literally I cannot see into the future, but I agree, 24:60 I think developments going nowhere. 25:01 There's the one thing I have learned more and more as I do this is I 25:04 develop skills, skill engineering and software engineering. 25:08 Especially when you get into sophisticated skills. 25:10 Software engineering is going nowhere as a profession. 25:13 The talk and for me, and I'm prepared to take the other side of the bet on LMS, 25:18 I genuinely am. 25:19 I think Polluter Nation is how they work. 25:22 I don't think the hallucination problem is going to go away ever. 25:27 But don't because I think it's inherent until we get a new class of model. 25:30 But I think that's fine. 25:32 I think that's absolutely fine. 25:33 I think software developers plus LMS are incredibly powerful, 25:38 and for me, that's that's the main learning I have had, is that it 25:42 is it's the two things working together that really, really give the power. 25:47 I don't think there's going to be many citizens, developers, like you said, 25:50 for the for the sort of real business logic, for anything 25:53 sophisticated, it is always going to be a software engineering mindset. 25:57 I have lived, I'm old enough to have lived through, well, 25:59 I didn't live through coal. 26:00 I wasn't quite there, but COBOL was meant to take away, suffered 26:03 a sequel was meant to take away software development for GLS. 26:07 We're going to take it away. Suffer. 26:09 It doesn't happen. 26:10 This is no different. 26:11 I never is a very long time, right. 26:14 But it's definitely not going away in 26:18 for Sable future current toolsets currently LMS, current ways of building. 26:22 And even if we look 1 or 2 years forward, 26:26 it's not going to like the. 26:28 It's clear that citizen developers, they can only go so far. 26:32 Yeah. 26:34 Okay. 26:34 Thank you. 26:35 And full disclosure, that last question was the only one I used 26:38 that Claude came. 26:41 Okay. 26:42 I said, I'd say we've probably got time 26:44 for a couple of questions from the audience. 26:48 Yeah, I'll. 26:49 We've got a microphone coming your way. 26:51 So if you could just hang on a set. 26:53 Thank you. 26:54 This is Prince. 26:54 Prince is helping us today. 26:56 Everyone give Prince a quick round of applause. 26:58 Thank you. 27:00 Thank you. Thanks for the great discussion. 27:03 You really enjoyed it. 27:04 I just wanted to put on my contrarian hat 27:06 and maybe share maybe a slightly unpopular view. 27:08 But I was listening to Bloomberg this morning 27:10 and they were saying like a bunch of, like massive companies, 27:13 like just got all canceled their cloud code line sensors, 27:16 including like Uber and Microsoft. 27:18 And yeah, a lot of the kind of things that we were talking about there, like 27:23 if you like, went to the Dev Conference five years ago and you said, you know, 27:27 you're not going to have any idea what's going on, 27:29 you know, lots of control, lots of other standing, you know, like, 27:32 like random choices, like on, like spinning up data stories, 27:37 like, just sounds like total chaos. 27:39 Do you think, like, this is really the way engineering is going to go, 27:42 like in the future or like the value is really there or we're kind of, 27:47 you know, it's going to be some implosion in the next, next couple of years. 27:50 And I'll just like preface that, like if you go back like ten years ago, 27:53 it feels very much like self-driving cars, you know, like 2014. 27:57 We're all like, wow, self-driving cars, like six months. 27:59 They're going to be here. 27:60 You can drive to the airport and back, you know, it's perfect. 28:02 But then all the edge cases and so on meant that, you know, 28:05 there's still probably more taxi drivers in London today than it was back then. 28:08 And all of us have driving car systems that are that are working today, sort of. 28:13 They all have like humans, you know, kind of remoting into to kind of 28:16 make sure that they don't get confused because, 28:18 you know, they can only kind of work like 80% of the time. 28:20 Do you not think the same is with software? 28:22 And then we're not going to have anything like reliable or maintainable or 28:27 sane to work with. 28:29 Not really a question, but just 28:32 a comment from the question. No, it was a bit of. 28:33 A question. 28:34 I will take that briefly. 28:35 I Microsoft. 28:38 Start Claude Code because they. 28:40 Don't get money from it. They they. Are. 28:43 Radically pushing their engineers to use GitHub Copilot. 28:46 They're also rebranding rebranding Claude coworker as Microsoft Copilot. 28:50 So it's a bit of a weird one with that Microsoft News story, Microsoft 28:54 are still pushing their employees to use AI all the time. 28:57 24 over seven the Uber one I don't think they've actually got. 29:01 I think they've just they just ended up. 29:03 But spending all of their AI budget in four months 29:07 rather than 12. 29:10 Like I was saying. 29:11 I mean, for me, absolutely, there is no self-driving. 29:15 Self-Driving cars. Yes. Agree. 29:16 And that's what I was saying about self-driving agents 29:20 building all the software. 29:21 It's not it's co-driver, very much co-driver, but 29:25 I think the quality is there. 29:27 You know, again, I am hands on as after 30 years in the industry, 29:32 I'm still building hands on software and the productivity gains are huge. 29:37 The quality is there. 29:38 If you do Harness Engineering, if you do not do good 29:40 Harness Engineering, the quality is terrible. 29:43 If you spend about as much time engineering your harness as you do 29:46 on prompting the actual functional output, you will get really good quality stuff. 29:52 You genuinely will. 29:53 So I disagree that this is sort of fashion. 29:55 The pan. 29:56 I think this is absolutely is the way for 29:60 okay. 30:00 Thank you, thank you. 30:01 Got one more. 30:01 I think I've got time for one more. 30:04 I think. Yeah. 30:06 Okay. Yes. 30:07 Oh well. That's too high. Yeah. 30:10 So in a way, I guess what you all been talking about, 30:13 like, things get sped up, like, there is a lot more stuff, right? 30:17 Than I think. 30:18 When any team starts becoming more successful, like, 30:21 the most cars resource becomes the human brain like. 30:25 And what do you do in your companies to, like, 30:29 you know, guide the cognitive resources of your organizations on the right stuff? 30:33 It can be like what peer reviews to review, what page called 30:36 should actually reach a human, when should it do that, etc.. 30:44 It's like. 30:45 It's a very big topic, right? 30:47 It's because 30:50 what we see is that 30:53 generally there is the cognitive. 30:55 It's it goes both ways. 30:57 One, you need to leverage human brain, but the second you need to protect it, 31:01 because there is a lot of like the nature of work with 31:05 AI is very different because normally you would think a bit 31:09 and then you would spend like two days coding, 31:12 which is pretty relaxing exercise, right? 31:14 It's not very demanding. 31:16 Now you are thinking very hard. 31:18 Then ten minutes and goes away, comes back and then you need to think again, right. 31:23 So this this leads to a lot of stress and cognitive load 31:29 and people are really burning out if it's not managed correctly. 31:34 Right. 31:35 On the other side you have a single person can generate massive amount of code 31:40 and there is no often there is no need for a team, right? 31:44 But but without a team, you don't have sort of back and forth between humans. 31:48 So I don't have a clear answer for that. 31:51 But it's a really big topic. 31:53 I think the work environment for developers will change dramatically. 31:58 Right. 31:58 And we need to to address this very explicitly 32:03 with no answers, no, no clear answers, because people like 32:07 one of our customers said they actually every few weeks 32:10 they need to send a person for a week home just to relax. 32:15 Because just to decompress. 32:17 Well, there goes so fast, but they're there to blow. 32:20 This is amazing. 32:21 After a month of working like that just cannot continue. 32:26 Yeah, I think there is pressure from some quarters 32:29 to actually have multiple agents running in on multiple tasks. 32:34 Yeah. And yeah, wonderful. 32:36 That sounds great. 32:37 But it will just destroy people's minds very, very quickly. 32:40 The context. 32:41 Yeah. It was context 32:42 switching working late hours because you want to see what they did. 32:46 And commits are coming now 10 p.m. 32:49 and 11. 32:51 It's. Yeah. 32:53 And you cannot stop because like I want to see the result. 32:56 And so this is this is the sort of slot machine, 32:59 the variable reward which the Jagers talked about. 33:02 It is it's addictive. 33:04 It is because. 33:05 You're talking about isn't it. 33:06 I'm afraid I have to wind us up. 33:08 I've been given the t signals. 33:10 So thank you very much. 33:12 To the panel, to Simon, to Pini and to Stefan. 33:16 Thank you very much. Thank you, thank you.