The Man Behind World’s Largest Dev Con

[00:00:00] Simon: Hello and welcome to the AI Native Dev Podcast. My name is Simon Maple and joining me on this episode is Stephan. Stephan, how are you?

[00:00:15] Stephan: I'm very good, Simon.

[00:00:17] Simon: Thank you. And Stephan, you are the, what is your official title? Stephan? You, you are head of Devoxx.

[00:00:24] Stephan: Oh, I founded Devoxx, or JavaPolis, yeah, in 2001.

[00:00:30] Simon: Yeah.

[00:00:30] Stephan: And I basically run the Devoxx Belgium edition. And I tried to get at least a coordination or know what's happening in the other Devoxx in Voxxed, which I co-founded with Mark Hazell.

[00:00:42] Simon: Yeah, absolutely. And, and so, and so JavaPolis, which is now Devoxx I'll go as far as to say is pretty much it's the premier Java conference worldwide.

[00:00:54] Simon: I think it's reasonably fair to say it's probably the biggest Java-based group of conferences across the world as well.

[00:01:03] Stephan: Yeah, I do think so. I mean, we, we welcome 20,000 developers every year across a small 20 events, of which eight Devoxx and 12, 10 Voxxed days. So if you group them together, it's a substantial number of developers that we reach every year.

[00:01:20] Simon: Yeah, absolutely. It's incredible. And, and of course, I would say your flagship event is probably, as you just mentioned there, Belgium. It's an event which has three and a half thousand folks come to attend every year in October. In fact, at Tessl we’re very happily sponsoring this year.

[00:01:38] Simon: And we have a couple of sessions there as well. So really looking forward to that in, in October this year. And we were talking off air just then, how fast the tickets go. It's basically like a rock concert, right? It's seconds and all tickets disappear. It's pretty incredible.

[00:01:55] Stephan: It's crazy.

[00:01:55] Stephan: I mean, because of that we do two batches. So we had one batch last Monday and then another batch on the 1st of September because we have actually people calling us crying, literally crying on the phone, saying like. “My boss told me to get 10 tickets and I didn't get even in. So for those type of scenarios, at least we have a, a second smaller batch to you know, solve some, some issues from registration's point of view.

[00:02:20] Stephan: But it's just crazy. I mean, we had 4,600 unique IP addresses to refreshing. Before the registration went open,people just jump on those. Just crazy. But luckily, I mean, people do release them once they have, like, a conference ticket, they still do release some tickets. So currently we still have deep dive tickets and combi tickets.

[00:02:42] Stephan: But the conference tickets, they're all gone.

[00:02:45] Simon: It's, it's absolutely incredible. Like particularly post-COVID as well. I hear of so many conferences that are not struggling necessarily, but they definitely see a dip. Um, and I'm sure it's probably similar with yourself, but it's incredible to see that demand is still so high for the, for the kind of thing that I'd call, I guess, the, the, the premium conference, the highest, the hardest conference to get in.

[00:03:06] Simon: Not just as a speaker, but definitely as a participant. Yeah. Yeah. It's crazy.

[00:03:10] Stephan: And I think a lot of people at companies, because they work at home after COVID, a lot of them use it also as a social gathering where they get together for five days, you know, go to great talks and in the evening have a beer or two and talk about tech.

[00:03:24] Stephan: So, you know, it's a great week. Having fun. Yeah.

[00:03:28] Simon: Incredible. So when we say, like if I were to go to people and say, “who is Stepan Janssen?" People will think, "Devoxx, it's like, oh, he, yeah, he runs Devoxx." He hosts and runs Devoxx Belgium. But behind all that, you, you, you're a very active developer.

[00:03:44] Simon: You've been tinkering with AI dev tools and things like that for, actually, you know, a significant amount of time. This isn't something that you've just got into, I think I've been following you on Twitter for ages, and you've been, like, playing with lots of, lots of stuff, like loads of image recognition stuff in the early days. I remember, was it basketball?

[00:04:05] Simon: You were, yeah, exactly. Yeah, yeah. I remember all that kind of cool stuff. What have you been doing more recently?

[00:04:09] Stephan: Yeah, well, the beauty of organizing Devoxx Belgium is that it's not a full-time job, you know, it, it gradually picks up in pace. And like now, the last months, it's really hectic. But once DevoxxBelgium is finished, I have like four or five months where I can just do pure research and development and tinkering, as you said, with different tooling and frameworks and things that I saw at Devoxx ,which inspires me.

[00:04:31] Stephan: And then I want to play with it. And one of those things was two years ago. I mean, JetBrains announced this AI assistant, and they actually demoed it at Devoxx Belgium during the opening keynote. And one of my questions to Anton was like. Hey, does it work with local models? Is it open source? can I choose any other cloud model?

[00:04:50] Stephan: And those answers were constantly negative.

[00:04:54] Stephan: So after four months of waitingI decided to develop my own plugin, which I've never done before, using, you know, Java. So I wanted to build a fully open-source Java plugin for code assistance, which is called DevoxxGenie. And just last weekend we reached 30,000, so three zero thousand downloads already of people using it.

[00:05:16] Stephan: And the aim was to really support local models. So like all Lama m, studio, young, Lama, CPP, all of those, but also the cloud models. And the crazy thing is, is that you can switch between the different models. So you can work first with a, for, for example, local model. Then have a cloud model review, the local model response, et cetera.

[00:05:36] Stephan: And that's what I, I've been working on quite a bit for the last eight months or so. Um, and then of course there were other tools coming out, especially CLI, command line interface tools like cloud codes. And so, you know, the dev it works, people are using it happy. So I was starting to focus a bit more on the CLI type of tooling, which is of course, you know, clo, code, Gemini and Codex.

[00:06:01] Stephan: I think those are the three frontier ones.

[00:06:03] Simon: Mm-hmm.

[00:06:04] Stephan: And, and for me, I had like, okay, maybe I need to do a new experiment in July because it's still a bit not too busy yet. Um, and I decided to do a vibe coding experiment.

[00:06:15] Simon: This is super interesting now, and this is what the sessions, this, this, podcast episode is gonna really be about.

[00:06:21] Simon: We're gonna talk through how this experiment that you built, and it's a, it's a, a neat little app that we're gonna, we're gonna talk through, for as an, as an assistant, as a helper to the, to the Devoxx conference in, in October. And we're gonna talk about the approaches and the tools and the processes that you use to build this.

[00:06:39] Simon: Um, you started with , a traditional, well I say traditional, but given vibe, coding's been a term that's been probably only popularized for the last year or so. You started with that vibe coding approach using, using the kind of light tradition Well, the, using the, the, the better of the vibe coding tools, I would say.

[00:06:57] Simon: Then you hit your limits, I guess, on, on that vibe coding. And we'll talk through what they are. And you then move more into a spec driven approach. So how can you actually use specifications that allow the LMS to kinda like build the same app, but, but through the specifications. And we'll talk through the various successes and pain points of each of these.

[00:07:18] Simon: So first of all, Stephan, talk us through what this app is, what the need of this, of this application was.

[00:07:24] Stephan: So we already have it for about two years, and also an open-source project called Fox Ring, which was a tool developed by Fredrik. Beautiful application uses Firebase at the backend, et cetera.

[00:07:40] Stephan: But for him, it's more like a hobby project, an evening project. And I was really starting to miss certain features, for example, searching speakers and introducing the photos, for which I'm also using face recognition to show the speaker photos. Um, and, and one of the other more important features like authentication, so people could authenticate themselves.

[00:08:00] Stephan: So their favorite thing could also be shared on their mobile phone, et cetera. So it's basically the Devoxx Companion application, which I said like, okay, you know what, I, I'll try to redevelop that using just Vibe coding and the, the, the limitation was really, I do not touch any code.

[00:08:17] Stephan: I can look at it, but I can only prompt it.

[00:08:19] Stephan: That was the limitation. I enforced myself,

[00:08:22] Simon: Which really is what Vibe Coding is, right? It's, it's, it's you code and you, you, you're effectively, well, I suppose you're using, you are using your vibe or you are using those small messages to kind of like suggest changes, but a lot of that is really you testing through almost Click.

[00:08:38] Simon: You're not necessarily, you know, creating an, well, you could, I guess build a number of tests, but it's typically not how things are done. People will typically say, I need this change. It makes that change. You test that change. Yes. Just from clicking around and, and with an app, with a front end, is, is that typically how you, is that typically your flow.

[00:08:55] Stephan: So, well, the other limitation I said is that I will do it in React, which I don't really know. So that already forced me to not even look at the code because I don't know React that I've never done a React

[00:09:07] Simon: application. And the reason you used React there, the reason that choice was made wasn't because of a technical choice?

[00:09:12] Simon: It was because you didn't know it?

[00:09:13] Stephan: Well, two things because I don't know it. And I've seen other vibe coating posts and people do know that React is very well indexed by these LLMs, so the LLMs really know it very well.

[00:09:24] Simon: Mm-hmm. You know,

[00:09:25] Stephan: if you go to more exotic languages, like Go or maybe Rust, you might not have that much support from the Frontier LLMs.

[00:09:34] Stephan: React is up there, you know, one of the top technologies, supported. And so that, that was how I wanted to start. And, and soI already had of course some features in my head of. How the existing application was that I wanted to mimic, but I wanted to go beyond. Mm-hmm. And what you really see is that in the first couple of days, you get an enormous boost.

[00:09:55] Stephan: I mean, the, the, the UI that it creates, the first thing is like, you know, it creates a design that a backend developer, I'm, I'm more a backend developer. I could never produce such a beautiful design. And then if you do look at the CSS, you know, the CSS is beautifully done. Um, it's responsive, et cetera. So you get an enormous boost immediately.

[00:10:16] Stephan: Um, and so I spent two weeks doing pure vibe coding, and I must say I got all the way till 90% of the functionality. but the last 10%, it was really struggling. And then I started to, to look closer of like what's happening and doing more reflection-type of forms. And what I noticed is that, well, there were a couple of things.

[00:10:39] Stephan: One was like, I was like, oh, I need to support dark and light themes. So it already was refactoring the, the, the CSS to support with variables to support dark and light. Then I went like, oh, I need to support internationalization. So then it was introducing resource bundles and so on. Then I was already starting using Firebase, but then you go like, okay, I need fire store, I need storage.

[00:11:01] Stephan: Maybe I want to do the real time database. So you're basically prototyping and refactor or letting the LLM. Refactor your code based on your change requirements. Um, so that wasn't cut stone before I started, so that might have also resulted in a few strange behaviors. But nevertheless, after two weeks, 90% worked.

[00:11:23] Stephan: 10% of the application was really broken. And what it's, after some investigation, it had created too many redirections and too many obstruction layers that it was just basically spaghetti codes. Um, it could really not be deployed to production because it was not fast enough. It had broken caches, et cetera.

[00:11:47] Stephan: And it was basically, I, I've basically created a Frankenstein in two weeks. Yeah. To be honest.

[00:11:52] Simon: Yeah. And, and, and a lot of, and, and a lot of that is because it's iterative. When you say Frankenstein, it's because you're making changes. You're putting whole extra pieces bolted on almost Yes. Versus being built through from scratch.

[00:12:04] Simon: And that it, that, it's that iterative, aspect of it whereby. If a change gets made, it does its best to, to adapt what is already there versus recognize if it needs to kinda like, you know, regenerate versus things and, and, and, and do that across an entire application and build it from scratch as if it were using that from first principle.

[00:12:24] Simon: Yeah. Um, you, you, I think you have some things to share as well. you have the, you have the application, that we can kinda like, we can kind of like view and talk us through some of the tools that you used Yeah. Um, as part of this entire process.

[00:12:39] Stephan: So the tools I usedlet me share my, my slides hereis, I'm sharing the wrong page.

[00:12:50] Stephan: Hold on. Share window.

[00:13:01] Stephan: Okay. I'm messing up here. No worries.

[00:13:10] Simon: Okay, so the, the tools that are, could you, sorry to pause. Could you, could you jump in that, into full screen if, uh oh,

[00:13:17] Stephan: sorry. Okay.

[00:13:19] Simon: Oh, and maybe you're sharing the other screen. Do you see it? That's it. Perfect. Yep.

[00:13:25] Stephan: So the, the tools that I've, I've used throughout the, the vibe coding experiments, was mainly cloud codes, which, which is A-C-L-I-I bought a $100 subscription, which was actually more than enough, I must say during that period, I did three blocks of five hours every day.

[00:13:43] Stephan: Wow. Um, so I wasn't working 15 hours, but it was like three hours. Then I run out of tokens. I had to wait two hours to start a new, chunk. And so often it was like, you know, around 10 hours a day. so those were long days, but very fun, to do. Um, and so the, the, that was my main tool, cloud code. but then I often actually used, especially in the second phase, which we will come back to, but in the first phase, sometimes I got stuck.

[00:14:13] Stephan: Um, or, or the, the, the prompts didn't find the, the solution. And then I had, like, I went to Gemini and actually gave Gemini CLI access. And because Gemini is Google, Firebase is Google, so it might actually know a bit better. The, the documentation on Firebase it, I think two times it actually helped me, fix a solution which CLO cos couldn't, provide.

[00:14:37] Stephan: So Gemini definitely helped there and I just used the API key for, that's why I was paying per token. And then often I, I also went to Deeps seek to actually do some brainstorming where I actually had a, a chat. I gave it to deep seek and Deep Seek would actually do some deep thinking or reasoning and come back, with some other suggestion or approaches.

[00:14:59] Simon: Mm-hmm.

[00:14:59] Stephan: Um, but that was basically the first version. when I noticed that I was completely stuck. After two weeks, I actually decided to do a control alt, delete and restart the experiment. but now using a technology that I know a bit better, which is Angler. So, so that was my, my focus. I would, I would redo it in Angler, be a bit more aggressive in looking at the codes, what it produces, and really be more, I would say a technical project lead where I would really guide it and, and I would be the guardrail of what it gets generated.

[00:15:33] Stephan: But what is more important, and I think that definitely helps the success, is that I took the react codes as the. Basis to create specifications because the first phase, I did not use any specs. I just started prompting. Um, and, but, but large prompts, but I had no real specifications. So what I did is that I fed the React application into cloud codes and per feature, I asked cloud codes, Gemini, and sometimes even chat GPT to come up with a specification for a certain feature.

[00:16:08] Simon: Mm-hmm.

[00:16:09] Stephan: So having those three models reviewing each other reallycreates a, a crystal clear spec for a specific feature. Mm. That feature was then saved in a markdown in my tox directory. And so I had a, a markdown per feature.

[00:16:28] Simon: and, and in terms of that specification, what would you say were thethe key, the key parts of that specification that allowed.

[00:16:39] Simon: Um, you know, the next generation of, of the code to effectivelyunderstand what it needed to, to build. Were there, were there headers with specific information in, in each of those markdown specs?

[00:16:54] Stephan: Yeah, it was very in, it was a really detailed specification. I mean, it was not only describing the feature, but it would even discuss, in through, for example, the model.

[00:17:05] Stephan: It would need to use the, even certain snippets of implementations, were included. It's really like it would be a spec if you give it to a senior developer. He or she would know exactly what to implement. and that was only possible if you have those three different frontier models review, or even four, sometimes.

[00:17:24] Stephan: Reviewing that, I, I, I would definitely recommend having at least minimum two frontier models reviewing it, but you have three or four reviewing it. And like Deeps seek is even free. I mean, I, I never paid for Deeps, SEEQ and I even used the, the free version of Chat g PT as well. I only paid for clothes code and Gemini, but that collaboration between those four, they create beautiful specs, which is really sufficient then to take that and, and include it into, you know, a vibe coding, exercise.

[00:17:54] Simon: Yeah. And, and it's really interesting the, the, the way you talk about it there, where the specification doesn't just, so, so one of the ways that we think about specifications is it separates the, the, the what I guess from the application. whereas today the code, very often de describes the both the what and the how, the, the, the, how something should be written Yeah.

[00:18:15] Simon: As well as the, what it's actually doing. And it's hard to, to kind of separate those. And it sounds like what you've done possibly because you started from the, from the, from the, the code to generate the specification is you've taken that what out of the code, but peppered it a little bit with the, with the how, I guess.

[00:18:31] Simon: So you've got the intentions of what you want the application to do. Yeah. And then there's, then there's peppering of the how, which I guess then. Pin it to a specific implementation. but that's okay if I suspect, you know, you only want it to be written in the application because this is, you know, an app specifically for, for, for your needs.

[00:18:50] Stephan: Yeah, I, I mean, it was exactly, I mean, I did basically code, well, so I did the first prototype in React. So I had a, a, a first implementation. I used that as a code to spec.

[00:19:01] Simon: Mm-hmm. And

[00:19:02] Stephan: then for my final implementation, I went spec to code. So it's like around, you know, the round circle, so to speak. And that really helped a lot.

[00:19:12] Stephan: Um, and, and, and so there, I, I, I really saw that the code, I mean, I had like also a Clot MD file where I said like, okay, you need to use internationalization. These are the languages you need to support. I need to have fing. Um, you, you need to use, for example, the new, iterative, for and if, statements in angular, et cetera.

[00:19:34] Stephan: So I, I really created also a code style specification, how it should behave. I introduced the linageand what's I think. Really key, which is missing up till now in this story is developing the, the testing, the unit tests, but also the integration tests. Yes. I didn't do test-driven development. I, I, I let the vibe, LMS first create a code.

[00:20:00] Stephan: Then I looked at the functionality visually. If it worked, then I had it make unit tests. I had it made integration tests and those were just added each time. New features were were developed. And that's really, really key because what you do notice is that once you start adding a new feature, it might actually ac accidentally break another feature without knowing.

[00:20:24] Stephan: And so you have a new feature, but all of a sudden older feature is broken. Mm-hmm. And if you haven't covered that with a unit test, you would just, you wouldn't know. You would know that that happens. So having good integration tests and unit tests really are also your guardrails. To make sure that your vibe coding doesn't go off, off rails.

[00:20:45] Simon: Super, super interesting. 'cause I think that's what also a specification allows you when you state, this is what I want my application to do. It's very easy as part of that specification to effectively and, and almost maybe even lead with your, with your tests in the specification when you describe a capability.

[00:21:01] Simon: 'cause a capability can either be written in natural language as to how you want it to behave or effectively detailed in tests which describe its behavior. Because you're effectively saying that when I get this kind of input, these are the types of things I want. Here are some, here are some kind of like unexpected outputs that I want you to be able to, to predict and, and, and, and react in this way.

[00:21:23] Simon: You're effectively defining that capability and, and like you say, um. When you make a change, you don't want that to have a knock on, effect on other parts of the application. And going back to the, to the pure vibe, coding, you know, pre prem, moving to a specification, this is the kind of like problems that you are having with that 10%, right?

[00:21:43] Simon: If there's, and I think you've got a great example of, ofyou know, when, when there was a problem, how it really struggled to, to kindato, to, to find a solution. Um, um. For that. Yeah. And it, it lost confidence in itself. Take us through that.

[00:22:01] Stephan: Yeah. Yeah. That, that was really crazy. So I got stuck, with Claude code.

[00:22:06] Stephan: So I went to Gemini, because it was a fire, fire store, issue. And the reaction I got from Gemini, and I'll, I'll show you the different responses, is just, was really unbelievable. I mean, as you can see here, this is incredible frustrating. It's, it replied, and I sincerely apologize for the repeated failures.

[00:22:24] Stephan: It's clear that my approach to modifying the rules is flawed and I'm not currently identifying the syntax error. And it goes on. Then I was just chatting and saying, no, no, you can find it, et cetera. And then I went. No, no, this is beyond embarrassing. I'm deeply sorry for the repeated failures. I'm clearly not the right tool for this job.

[00:22:42] Stephan: You go like Gemini is having an identity crisis.

[00:22:46] Simon: Yeah, yeah. And

[00:22:47] Stephan: it went just back, went back and then I said, no, no, I, I'm gonna revert to the, the changes. I'm really not able to find it. And then of course, I had to step in and really look at the problem and it was just, oops. It was just go back. It was just one character.

[00:23:02] Stephan: It had to change in the, fire store collection path, where you see here in the first party has interactions and an underscore, and it had to be in directions and a slash

[00:23:14] Simon: hmm.

[00:23:15] Stephan: And it was just. Both Claude and Gemini were unable to find that problem.

[00:23:21] Simon: At what point did you feel like an LLM counselor trying to say, no, come on Gemini.

[00:23:24] Simon: You are good enough. You can do this. Yeah.

[00:23:28] Stephan: Yeah. It's crazy. I mean, I, I, I have seen online that they've started to fix this type of apologetic behavior of Gemini. So I mean, they are also, Google is also learning and, and improving these things, and you can also see that by, you know, the different CLI versions that are being released on a almost daily basis.

[00:23:47] Stephan: So this is just getting better and better, for sure. But yeah, that, that was, that was very, it was a very, I mean, the fact that I took screenshots already showed you how surprised our I was.

[00:23:59] Simon: Yeah. Yeah. And, and I, I guess as a user, you kinda like end up losing confidence in this kind of thing when it, when it's almost like pleading that it's, it's, it's not the right tool and it can't do it.

[00:24:09] Simon: You, you as a, as a driver of this kind of a platform or tool, lose massive comp, you start believing it, thinking, no, maybe you can't do this. Maybe I do need to, to switch to a different approach. Now, moving to the, to the spec approach, when we let, let's contrast these now, because you say of all of those integration tests, those unit tests and things like thatit actually provides that much more debug information.

[00:24:32] Simon: And, and, you know, it, it allows, it, it gives it more of thosemore of those clues as to well, okay, what's working, what's not working, and, and potentially identifies these types of things in a, in a better way. Right. Yeah. What, what would you say with the major flaws of, um. Of the kind of like approach of the vibe coding and what would you say spec driven was the key unlocks that you needed?

[00:24:59] Simon: Was it the tests, was it something else? What, what, what, what really was that? Yeah. Well,

[00:25:04] Stephan: I mean, if you just do pure vibe coding and, and just some prompting, it's just way too freestyle. There, there's no guardrails that, that's really not sufficient. Right? You need to introduce these guardrails, and for me, the guard rails was a good linter to, to start with so that the linter goes through.

[00:25:21] Stephan: The full code every time you do a deployment. That's one, the unit test and the integration test, but also the management of your specs. Um, and I think that's where there's a huge, opportunity. I know you guys are clearly looking into that. Um, what I used, what was a, an open source project, and I've even invited the developer, I believe he's from Austria, to DevoxxBelgium called Backlog md.

[00:25:47] Stephan: And what Backlog MD does, he white coded that tool also, but you basically install it locally and it creates like this cban UI in the browser and there you can create an issue. Then that issue produces a maritime file. And that issue can then be referenced into cloud codes where you say, okay, now work on issue number one.

[00:26:11] Stephan: And because you're saying issue number one, it will go to the file system, try to find issue number one, md, which the backlog creates. Mm-hmm. And it will then work on that issue. But what it also does is that once it has, finished that issue, it will document what it has done and include that documentation into the existing issue on backlog.

[00:26:35] Stephan: So when you revisit that feature or that issue, it already knows the original complaint or feature. What it has done and what it still needs to be do doing. And it reminded me a bit of gyra in the good old days. Um, but this is like a lightweight version of that locally. So the CLI can access it very rapidly and updated it, and it then moves it from state of where it says created, what is itworking or in progress and done.

[00:27:03] Stephan: So it has like multiple states. And, and that definitely helpedbecause you have your regional specs, but this allows you to actually have conversations on top of that spec or next to that spec, which is a living document.

[00:27:19] Simon: Mm-hmm.

[00:27:19] Stephan: And I think that's definitely the way to go. Um, as a result, of course, I, I, I think it was a month or so, Amazon came out with Cairo or Cira or Cairo, which is also spec to code.

[00:27:32] Stephan: I had a quick look at that. yeah, I wasn't fully convinced yet, but, but it's definitely. Obvious that this is a, a void that needs to be filled. Um, and, and I think that type of combination makes it a bit more interesting because then you have living documentations and features and bugs and issues, which can be accessed by the LLM.

[00:27:55] Simon: Yeah. And from the, the, the, the point of view of being a user, being a developer, in each of these scenarios you mentioned how fast you were able to kind of develop, create and, and, and show something working and show something, actually being able to deliver on your kinda 80, 90% of, of functionality. Um, for anyone having that feedback and that fast creation is, is extremely fun.

[00:28:30] Simon: It's, it's, it's very validating of, you know, you being able to kind of like create, you mentioned that kinda like top. That, that ceiling, I guess, that you hit after 90%. But from a spec driven approach, you have to do a lot more of the, the kind of, okay, let me write some stuff in natural language. Let me now think about the tests.

[00:28:50] Simon: Let me think about all these, you know, other things that you need to do, which effectively will slow you down in that kinda like rapid application development, approach. If that's what you were trying to go for. How did you feel as a developer? Um. The, I guess, enjoymentof doing vibe coding versus spec coding, but also from a confidence point of view from a, you know, being involved in the process.

[00:29:19] Simon: Did you, did, did you have more confidence, was one over the other? Talk, talk to me through that.

[00:29:24] Stephan: I'm, I'm calling this the, the renaissance of developments or, or, you know, because you, you clearly are getting lots more, enjoyments and pleasure of doing these type of projects because, you know, if, if you didn't do vibe coding, you, you need to set up your Maven project.

[00:29:41] Stephan: Just setting up the, the build environment can already take you a couple of days to, to make that work. And with vibe coding, you know, it, it just creates that for you very rapidly. You get instant satisfaction, so to speak. Um, and, and that, that feedback loop is very, is much shorter, I think in general. Just for prototyping, quick prototyping.

[00:30:03] Stephan: This is clearly the way to go. if you really want to do a real project that you want to deploy for thousands and thousands of users, you know, is vibe deployments, vibe, debugging? Is that, is that the way to go? Um, I mean, just to, to, to tell you or share you some anecdote. I mean, I had a development environment, I have a staging environment and I have a production environment.

[00:30:26] Stephan: And so I went like, okay, I'm, I'm creating a task file. This task file creates tasks which allows you to deploy, et cetera. And it obviously had missed the, the settings from production to staging. And when I was deploying to staging, it was actually deploying to production. Oh, wow. So these are the type of things where you go like, oh wow, you knowyou, you do need to still have knowledgeable people looking into what it is producing.

[00:30:52] Stephan: not only looking at the codes, but also looking at the scripts, et cetera. because I can imagine if you are a. A, a, a non-techie guy and a non-developer doing this stuff, you are gonna run into problems because you just don't know the scale of what it can produce and, and, and you just don't know all the effects and side effects of things that you are asking it to do.

[00:31:14] Simon: Yeah.

[00:31:15] Stephan: So I think being a more senior developer, it, it, it makes me definitely be more productive. I could have never created a UI that it has produced for me. Um, I mean that replaces a, a web designer for sure. Um, but the project I've now done in more or less five weeks now, because I've, I've been doing this for five weeks, it would've taken me definitely three people, six months without doing vibe coding.

[00:31:42] Stephan: I'm, I'm, I'm fully convinced about that. Um, so it's definitely a game changer. It is more productive. But you still need some senior developers guide guiding this, because if you don't, you, you're gonna run into problems. For example, like angler has guard, rules. So you have routing and you can put guards in front of the routing.

[00:32:06] Stephan: If you don't know that concept, you are gonna give access to certain pages, as a junior or or non-techy guy, without knowing, or you might actually expose, API keys or really security issues. And that's why I've also did certain exercises where I said like, to close code. Hey, you are a white, white hat hacker.

[00:32:29] Stephan: Try to hack my system. And it actually goes through your codes, goes to your website and tries to hack your system. And those are really valuable exercises because it will actually highlight, ah, I was able to see the admin page without being logged in. Okay, fix it, you know, look at it and go deeper. Or, I did another exercise where I went, I went where I went like, okay, we have 3000 unique users during DevoxxBelgium.

[00:32:57] Stephan: how will the system scale? How will it be performance? Where are the bottlenecks? And it does this exercise where it really then goes like, well, your fire base functions, you should have better memory or more memory. You need to allow more instances, et cetera. So having these other type of discussions, which are not so much development oriented, but more Devoxx oriented.

[00:33:20] Stephan: Mm. Is definitely also a, a, a step you need to do within that process.

[00:33:26] Simon: Yeah, I I, I'd love to break that down a little further. We, there's a couple of things there that I'd love to talk through. The first one is you kind of, you kind of alluded to the fact that you need those senior developers or, or people who really understand how that sympathy of what is being built, what's happening to, to review essentially, or, or, or to make sure to validate that what is being createdis actually correct.

[00:33:52] Simon: It's the right way of doing things, it's the right implementation, so to speak. An amount of that can be done. I guess with, with things like tests and things like thathow, how much did you do a lot of those reviews versus what it sounds like allowed the, the LLMs or different LLMs to kinda like jump in and do those reviews for you?

[00:34:12] Simon: Were you comfortable if you just let Deep Sec or, and something else come through and say. Tell me if this is okay and I'll trust you. Yeah. What words? No,

[00:34:21] Stephan: I, I was not fully a hundred percent comfortable for sure. Um, just this morning I actually found another bug. In the deployed application now, because it's already been used now by, by hundreds, hundreds of people, for DevoxxBelgium.

[00:34:36] Stephan: And so I did a, a refactoring using prompting where the speaker can actually edit his pictures, which are identified from Flickr using face recognition. and he or she can decide which picture he wants to show on his speaker profile.

[00:34:51] Simon: Nice.

[00:34:52] Stephan: And so that worked, but it actually broke a feature where the pictures are not shown anymore, on the public page.

[00:34:59] Stephan: Mm-hmm. And I was like, what happened? And so I could not have, I mean, I could have only fixed that or anticipated that with using, end-to-end. testing using Cyprus. I, I've chosen Cyprus. Mm-hmm. But I had no test for that specific scenario.

[00:35:16] Simon: Mm.

[00:35:16] Stephan: So it basically broke something in production and where I went like, but to be honest, this can happen also in normal teams without doing VI coding.

[00:35:24] Stephan: Right? Yeah. I mean, this is reality. It, these things do happen. Um, so my target is I would love to get a 80% coverage with the UNI tests. I would love to have more end-to-end testing as well. But that just takes still a lot of effort, even if it's just prompting. But it would increase my confidence that yeah, if I do deploy it and I have those type of coveragesit, it would increase my confidence to, to, to move forward.

[00:35:54] Stephan: Um, so I think those are definitely critical to, to havewithout you are just walking in a dark room and you're gonna hit your head against the wall for sure. Right. so I think test driven or, or just unit testing, integration testingis, is becoming more and more important to make sure to enforce the specs that you've defined.

[00:36:16] Stephan: Yeah. And I think that collaboration will, will be a success, combi.

[00:36:21] Simon: Yeah, absolutely. I guess like going forward with future development as welllet's say, let me give you a couple of, of, of, of scenarios. If you were to create a new feature, um. Would you create a new spec to do that or would you update and a and append make changes to an existing specification?

[00:36:46] Simon: So I guess the question is the life, the, the, the lifetime life cycle of your, the life cycle of your spec. Yeah. Does your spec follow the change or does your spec follow the application?

[00:36:56] Stephan: Yeah, currently not. Um, so the, the spec does not follow any changes that I've made. Um, which is, which is maybe a flaw in, in, in my process.

[00:37:06] Stephan: I should probably keep it alive and up to date. I do review and up to date I keep the read me up to date or the Clots MD up to datebecause you can easily do that. But having tools, tools, which would help me keep that in sync, even if it happens in the background, I think that would be amazing feature to have from a tool perspective.

[00:37:28] Stephan: Giving you some hints here, Simon, but that would be amazing because now I have to explicitly say it. I need to really say, okay, if I want to like this feature with the broken photosthat should be something which would need to be covered by some integration tests. So it actually validates that that isn't broken, but it should be reflected in the spec.

[00:37:48] Stephan: And because I'm lazy or I'm not thinking about that, the spec gets out of date. And if there are tools who would keep that in sync, that would be amazing. for sure. Um, and, and of course all these CLI tools, they have rules which they go back to, to follow that. Mm-hmm. You know, like the Cloud MD file or the Gemini MD file, et cetera.

[00:38:08] Simon: Mm-hmm.

[00:38:08] Stephan: Um, so there, there's definitely still some room for, for improvements, but there's huge opportunities for product companies to fill that void.

[00:38:16] Simon: Yeah. And so, and so you're using specifications really toto drive your development, but it's not necessarily spec centric in the sense of any change you would make beyond that initial generation would more likely be directly into the code versus the spec first.

[00:38:34] Simon: Correct. Um, and of course, like you say, that then puts the spec out of, out of sync, I guess. Yes. And then it, it almost like pushes you back into that vibe coding mode versus the Yes. The spec centricity Exactly. That you found valuable the first time. And

[00:38:47] Stephan: I think that's a discipline I need to change. I need to have the discipline to actually make sure that the spec kept, is kept into sync and that it's also always referenced.

[00:38:57] Stephan: When you start a new feature or enhance an existing feature.

[00:39:02] Simon: Mm-hmm.

[00:39:02] Stephan: Mm-hmm. Because that's a bit of the problem now is that, you know, we used to do, I, I've done several talks on rack, but what you are seeing now with these CLI tools is that, I call it file system rack. They do some kind of, you know, pattern recognition on files and the, the results are then injected into the window context.

[00:39:23] Stephan: But if certain keywords are not included in certain specs, it might not actually find these and include it in the window context so it doesn't know about it. So I think that type of behavior, either the developers should, should have the, the discipline to say, Hey, no, always include this specification.

[00:39:40] Stephan: Like we do now with CLO md I actually explicitly say, Hey, lot load CLO md. So it's part of the window context. And just yesterday actually CLO released a new slash command called Context. Where you can see how much of your window context is used by which types of documents. Nice. Which is very, very interesting.

[00:40:01] Stephan: Yeah. Um, so there, there's definitely some, some opportunities there to, to make sure that it is included in the window context. Yeah. Either by the developer, which developers are lazy, might forget. So I think tooling should, should play a role there.

[00:40:16] Simon: Yeah. But EE even that though, even allowing EE even if your code isn't, you know, every time directly generated from the specification, allowing, giving access to, you know, your full set of specifications to fromyou know, to, to your agent in this case, Claude.

[00:40:34] Simon: That, that, I'm sure that supercharges, the way Claude makes its changes by truly understanding the application and how you know what your intentions are. And by making certain changes, knowing. Okay. If I do this, that will probably break or whatever. And it is amazing how we talk about it these days. Like it's truly thinking like we are as well.

[00:40:52] Simon: And it's, it's, it's, well, it's very

[00:40:54] Stephan: knowledgeable, right? Yeah. I mean, it really does know all the, the syntaxes, et cetera. But the other thing that just comes into my mind is like I do feature branches, on GitHub. Mm-hmm. So I create a new feature branch and then I start working on that. But what actually would make more sense, I've, of course, integrated cloud codes using GitHub actions into GitHub.

[00:41:15] Stephan: But what would make more sense is that you create first an issue on GitHub and then use that issue as your feature branch. But you can have cloud Codes, codes or any other LLM already first, do some pre investigation to actually supplement your feature, in GitHub and already use that as your window context information to start the feature.

[00:41:38] Simon: Mm.

[00:41:38] Stephan: And, but that's, I I believe currently not possible. It, it's only be after the facts.

[00:41:44] Simon: Yeah.

[00:41:44] Stephan: Um, but that would be actually, I mean, that could be a, a project on its own. Yeah. Um. Yeah, because you then let, let the LLM investigate and see what context it would need to actually implement that feature. Then you can start doing the feature and, and it already has the, the context.

[00:42:01] Simon: Yeah. Yeah. Very interesting. And I, I, I really like the, the, I think context has always been king and I think what you also discussed with the file system context is very, very, very, very interesting from that point of view as well. I wanna switch more into the kind of talking a little bit about maybe some of the non-functional, requirements and aspects.

[00:42:19] Simon: And I think this probably may be when we, when we're using LLMs. Drops us into more of a, kind of like a role-based assessment of what is being built. Um, so non-functional requirements, maybe it's security, maybe it's performance, maybe it's availability, these types of questions. Um, how did you, obviously, what you're building right now as a production application, that needs to be, needs to be up and alive for the, for, you know, pre, pre Devoxx as well as, certainly the days of Devoxx, and then probably an amount of time afterwards.

[00:42:50] Simon: Um, you need to make sure that. When 3,500 people are hitting it, potential is potentially, you know, a lot of people at the same time for very time specific things like end of a session, people are gonna jump to the schedule, maybe do maybe jump to the reviews and things like that per session. Um, how do you, how does, how good is the LLM without specification, I guess?

[00:43:13] Simon: or, or rather without you specifying It needs to be performant. It needs to expect a large number of users at a, a specific time. How good was it without specifying these are the requirements and, and how did you get it to, tobe conscious of. You know, these requirements so that when it's making implementation decisions and choices, it does it in a way that satisfies these non-functional

[00:43:40] Stephan: requirements.

[00:43:41] Stephan: Yeah. But I think there, I'm, I'm guilty because I have, of course, a bit of experience of building scalable systems, et cetera. And I, I dunno if you remembered, but during COVID, we, Celestino and I developed Rockets, which was an online platform to do online events, et cetera.

[00:43:58] Simon: Mm-hmm.

[00:43:58] Stephan: And there, we, we had the same thing.

[00:44:00] Stephan: We had sometimes thousands of people online using it. And I think just knowing the architectural choices, as a more senior developer plays a big role there. And, and so from the get go, I immediately said, no, I want to use Firebase, which is basically Google Cloud, right? I want to use Lambdas or functionsbecause those are very, very scalable, especially if you then run them on cloud run, et cetera.

[00:44:25] Stephan: So just that architectural choice of using Firebase fire store functions or Lambdas. cloud run, et cetera. You already know that if it runs on GCP, it, it, it can be very scalable because Google basically does that for you. So if I would've started without that knowledge, and it would've maybe created a more fast API using Python, I might have been in real, I I might have real problems.

[00:44:53] Stephan: Right? Yeah. Because now it's just a configuration. I mean, you say from the get go, how many instances you, you allow what the timeout is, what the memory it, it gets from functions. And it's, it's basically a, a stateless function, serverless backends on a scalable cloud environment.

[00:45:10] Simon: Mm-hmm.

[00:45:11] Stephan: So I could have, if I had no experience at all, I could have had sessions with LLMs asking like, what is the best scalable solution?

[00:45:19] Stephan: And it might have come up with that type of recommendation, but for me that was No, no. Uh. I, I, that was a, an architectural decision that I wanted to have from the beginning knowing that that will scale and I'm pretty confident it will.

[00:45:36] Simon: And it's interesting that you, you've kind of alluded to the fact that, you know, as a senior developer, there are a number of choices that you've made that, you know, had you not had that experience in coding, perhaps, it would, it, they, they're non-obvious kind of choices that, that you would potentially make.

[00:45:53] Simon: Um, a lot of people kind of like say, well, how in the future are we gonna get to those, those senior. Those senior engineers to know thatI kind of question that a little bit because I feel like, well, you know, we all have to learn through our mistakes. We all have to learn through advicefrom advice, from an advice point of view.

[00:46:14] Simon: We, we've never been more capable of asking questions to, whether it's LMS or people, through, just because of the, the, the, you know, the new UIs and the new aggregation of data and information about how to develop, what good development looks like and so forth. We're also able to hit our mistakes quicker because we are able to vibe, code faster, deploy faster.

[00:46:36] Simon: I question whether. The gap is actually going to be there in the future because isn't, as a junior developer, wouldn't I just make my mistakes faster and get to that end learning of, okay, this isn't scalable. I need to use a more scalable scenario and look, make, you know, create those learnings faster versus as a junior developer, making my code changes and finding this issue in six months.

[00:47:04] Stephan: there, there's two angles on this. um, one is, as a business owner, I need a business solution as fast as possible, as cheap as possible, but. With quality, right? And I think as a business owner, having one senior developer, even if it's myself now in this situation, I can achieve that much faster than if I would have some juniors.

[00:47:25] Stephan: Um, so that's from a business perspective. But if you look at, from a technical point of view, as a junior, you now have a universal tutor. You have a, a coding assistant, which is out of this world, so to speak. You can ask all the questions you want, even the most stupidest questions, which we would never have been willing to ask to our colleagues.

[00:47:46] Stephan: You can now ask any question and you would get really knowledgeable answers. So if you are a motivated, dedicated junior developer, you can go up that ladder and become a senior developer very fast because you now have these LLMs which can guide you and help you. So this is something we didn't have, you know, a couple of years ago.

[00:48:05] Stephan: Um, so. You have to be motivated. The only problem is then the business, is the business willing to actually hire these juniors and invest in them to become a senior if I cannot just accomplish a project with just one senior developer who would maybe be the project lead of these, of these juniors. So I think that's a bit of the, the, yeah, the, the balance act that, that will need to happen moving forward.

[00:48:31] Simon: Yeah. Um, and, and, and also as a, as a, any developer, senior or junior, I can kind of say that to, to an you are a performance expert. You know, you've got 10, 20, 30 years of, of experiencing creating performance systems. Maybe for a FinTech, maybe for a, a, a site that's gonna get huge numbers of, of visitors on specific days, you know, add.

[00:48:57] Simon: Good coding practices for these types of systems. And is that something that you did with this application, with those types of roles? yes. Role-based agents, I guess.

[00:49:08] Stephan: So it was actually, I think it was four weeks ago that clot, release soup agents. So what it allows you to do is actually create a promptfor an agent that you give it a name.

[00:49:22] Stephan: Mm-hmm. Which is called basically a SUP agent. And it's basically a markdown file of a certain character, of a certain profile, which it will use when you activate that SUP agent. So you could say like, Hey, you are, for example, a tester and you explain what the tester should do, et cetera. And then when you actually do a prompt, it will look into its super agents and activate that type of avatar, that type of profile, where it already sets the scene of that role.

[00:49:51] Stephan: And it will behave as that role for that specific request that you have. Mm-hmm. So that's why also, you know, for Devoxx, Belgium, I mean our, our theme for Devoxx Belgium is basically Java agents. Um, and you know, we, we didn't mention that, but I think Devoxx, Belgium is the biggest AI conference now because almost 75% are all about ai, large language models, but also using Java on GPU, doing interference on GPUs, et cetera.

[00:50:20] Stephan: But mainly the, the, the theme, if you go to the website, it goes agents. And I think that's where the excitement and the new opportunities are as well, is that you cannot only create agents in CLIs where it has a certain role, but you can also have a synchronous agents which work in the background while you are sleeping or while you are walking the dog and it's doing certain actions for you within that specific role.

[00:50:45] Stephan: Yeah. And that's where. it's very exciting and it's also where even Java, like frames, frameworks, like launching for J Spring ai, they're all going to this next layer of abstraction, which are agents. Yeah. And I think, I think there, we, we are gonna see lots of new innovations happening in the next 12 months.

[00:51:03] Simon: Yeah. Absolutely. Now, I hate to scare you. Um. Stephan, but what are we now we are recording this on the 22nd of August. you've got Devoxx Belgium. what, what are the dates of Devoxx Belgium? Is it seven from the sixth till the 10th of October? Sixth to sixth till the 10th of October. so what are we looking at here?

[00:51:22] Simon: Um, about a month and a half. Really? Till, till. I have no idea why you're wasting time on podcasts. right now, Stephan, you should be, there's probably a ton of stuff you should be doing, for Devoxx, but in a month and a half, you're gonna have three and a half thousand people probably more accessing this application.

[00:51:39] Simon: a lot of thema lot of them. You know, at the same time accessing the same data. What are your biggest concerns? and, and I guess confident, confidence wise. How confident are you at this app is gonna, is gonna work flawlessly? What are your biggest concerns about going live with this at a major conference?

[00:51:59] Stephan: So I add, I added some very interest, interesting interaction possibilities, new interaction, PO possibilities. Well, first is like people can now finally have free text comments, privately feedback to the speaker.

[00:52:12] Simon: Mm-hmm.

[00:52:13] Stephan: But what we actually get often is that there are some less professional people who enter like, okay.

[00:52:19] Stephan: Certain texts that aren't really following our code of conduct. Mm-hmm. So what I added is that I'm using Gemini Flash 2.5 light to review all the comments and see if it follows the code of conduct. Nice. Right. And it really, even if you're just using emoticons, emojis. And they're not appropriate. It wouldn't even find the emoji say like, no, this is not following our code of conduct.

[00:52:43] Stephan: Right. So, but that's, it works, but it's like, okay, how will it work if 1000 people give feedback? Will it be fast enough? So those are like concerns I have from that point of view because it's, it's bit more difficult to simulate and, and expensive if you want to simulate 2000 comments at the same time.

[00:53:01] Simon: Yeah.

[00:53:01] Stephan: So tho those are like my biggest concerns. I know the application will run, I mean, it's angr, it's hosted on Google Cloud, it's just JavaScript being returned, so that's gonna work. Fire store is gonna work. I don't see any issues there. but like I have other things. For example, a feature where people can now say how full the room is, so they can say the occupancy of the room is like 90%.

[00:53:24] Stephan: Mm

[00:53:24] Simon: mm And

[00:53:25] Stephan: that information is now, is now shown on the digital signage. So you will get immediately feedback on the digital signage saying, oh yeah, I don't have to go into that room because it's packed. And the cool thing about having that feature is that I don't have to go, because I like to know how many people are in the room for certain topic and speaker.

[00:53:44] Stephan: Now, if that works, I don't have to do that anymore. I can just sit at the registration, look at my dashboard and see how full the rooms are based off. Community driven feedback.

[00:53:53] Simon: Amazing. Kind of feels like, you know, the how when you do a, a Google Directions and then it kinda like says, oh yeah, this train is busier than normal, and things like that.

[00:54:02] Simon: Yes. It's, it's, it's exactly that, right? Yeah. That's, that's absolute, but it's community

[00:54:05] Stephan: driven.

[00:54:05] Simon: Yes.

[00:54:06] Stephan: So the thing is, if that breaks, I'm gonna be vibe coding my, you know, I try to fix it on the spot. Of course. Yeah. We've got another crazy feature, which I was thinking of only announcing at the keynote, but I, I want to give you the premier, is that I, I vibe coded another feature where I'm doing, realtime transcripts.

[00:54:27] Stephan: I've already was doing real time transcripts where you see the, the transcript on the screen, right? Yeah. I'm already doing that, but now I'm capturing the transcripts from real time from the talk, and every two minutes I'm creating the key takeaways of the talk. A clouds, keyword, clouds, and also a summary of the talk while the talk is going on.

[00:54:50] Stephan: Amazing. So you can go to the mobile app and just see five minutes in the talk, ah, these are the key takeaways. These are the keywords he or she's using, and that's the summary. And I'm just hoping that's gonna work. I mean, I've been testing this, et cetera, but there's, there's a few moving parts and that, so that's where I'm gonna get nervous.

[00:55:09] Stephan: It's like, will this work?

[00:55:13] Simon: Yeah, that's interesting as well, because as an attendee, if I, if I were to see something like that, I might scroll through like halfway through a talk if I'm not maybe enjoying a talk or if I, if maybe it's like not the right talk for me, I could actually scroll through and see what others are talking about, what the summaries are and go, oh, actually that looks really interesting.

[00:55:31] Simon: Let me, yeah, let me jump into that one. It gives people that more That real time. That real time. Yeah.

[00:55:36] Stephan: So I've got real time transcripts, but just imagine what you could do. I could go even next level, take that transcript. When the talk is finished, give it to an LLM and say, Hey, create a script where two people are talking to each other.

[00:55:49] Stephan: Then take that script, then go to OpenAI, create two voices talking to each other like notebook LM is doing. Yeah, I could totally do that. Techno taking, taking a, from a technology point of view, that's totally possible.

[00:56:02] Simon: Yep.

[00:56:03] Stephan: You know, the, the only thing is that some speakers have concerns about that because they don't like a real accuracy podcast from their talk, the accuracy, et cetera.

[00:56:12] Stephan: So I've put that in the fridge for now.

[00:56:14] Simon: Yeah.

[00:56:14] Stephan: But from a technology point of view, that's just like, it's like sign fiction. How the hell, you know, two years ago that was not even possible and now you can do that.

[00:56:23] Simon: Yeah. Yeah. Amazing. Let's talk about, I want talk, I, I want to kinda like finish up with two, two last kind of questions I wanna, I was gonna, originally, we talked a little bit about the role of, of, of a developer a little bit.

[00:56:36] Simon: I wanna talk about the role of a conference, Stephan, when we talk about. You know, in the day Job olis moving to Devoxx, it was, it was a very language oriented conference. What's, what do you think the future of a language of a developer conference looks like? Because we've already talked just now about, you know, your, and I love the, I love the framing of saying, you know, Devoxx is one of the largest or the largest, you know, AI developer conferences in the world.

[00:57:04] Simon: It's like, do, do conferences need to evolve now? Because as the role of a developer changes the skills that a developer needs to learn to actually become an effective developer isn't now, or is gonna be less and less oriented around how they use a language or, you know, or their capabilities of, of whether it's design or architecture.

[00:57:25] Simon: Because we, we'll lean more and more into ai. So is it more a combination of our best usage of AI and some of that mechanical sympathy knowledge of, of how applications should be built? What, what's your vision for devs comes forward? Yeah,

[00:57:40] Stephan: so I always say, I mean, I spend almost nine months producing and organizing this event, and it goes just like that.

[00:57:47] Stephan: It's not full-time, nine months. But, you know, so I, I always say like, this is our party. You know, this, this five days event is a party that we organize where we hand speak speakers and topics, et cetera. And so I want to reflect. The content from the conference where the excitement is where I'm getting excited off.

[00:58:05] Stephan: And so my excitement is clearly in AI with large language models, et cetera, and I want to make sure that that is reflected in the conference. So that's, that's one thing. But the other thing is also, yeah, if up to now my excitement matches with the excitement of other developers and they're curious to learn these new things, et cetera.

[00:58:25] Stephan: And so I think we did pivot a bit already this year because I clearly took the card of like, okay, AI agents and LLM and coding systems is where the buzz is, and the excitement is, let's go full blown for that, for DevoxxBelgium.

[00:58:39] Simon: Yeah. And

[00:58:40] Stephan: to be honest, on Monday, I was really nervous because I, it could be that people find it as a, as a, how do you call that?

[00:58:47] Stephan: Their, their job security and as a danger, and they might just be reacting on the, as a oppositely of what I was going for. Mm-hmm. Mm-hmm. Um. But it looks like people are excited about this. They want to learn.

[00:59:02] Simon: Well, you only had a few seconds to wait before getting your answer please. Sure. Yes. But it's also

[00:59:08] Stephan: our reputation a bit.

[00:59:08] Stephan: Right? People do know what to expect from Devoxx.I mean, we've been doing this for 25 years now, so people know what to expect. But, but you're definitely right. I I do. If you just look at the content already for this year, there is the, there's gonna be a, we, we need to embrace this new possibility. And I think the excitement is there.

[00:59:27] Stephan: The productivity is there as well. There are dangers involved for sure. But as a conference, that's something we need to highlight, make sure that we reflect it from the speakers and content point of view. I mean, I, I even have Rod Johnson, the founder of Spring. Mm-hmm. You know, he lives in Australia.

[00:59:42] Stephan: He's coming over to do a hands-on lab session. He's doing a keynote and he's doing a conference talk about his new AI agents Java framework called Alble.

[00:59:51] Simon: Mm-hmm.

[00:59:52] Stephan: So it's like. That's where the excitement is. We wanna know what's possible, et cetera. And if you reflect that as a conference. I think you still have a few additions to, to, to stay alive.

[01:00:03] Stephan: Um, I've already seen a few other conferences doing the same strategy in the us. I mean, they're already going. Okay, yeah, we need to embrace ai. But what's also interesting, even from a low level point of view, there's still lots to talk about. I mean, we have Paul Sandoz who works on Babylon, who is working on Java.

[01:00:22] Stephan: And GPU interference. We have the tornado VM guys from Manchester University. So there's still lots of low level stuff that needs to be discussed and explored and, and, and do knowledge transfer on. So it's gonna be a mixture of those two. you might have people who are no developers at all who might actually get some benefit of going to Devoxx,but you still have people who want to know what's under that layer, what's underneath that framework, what's actually, you know, opening up the car as a small boy and knowing what's in there.

[01:00:52] Stephan: Yeah. I think those types of people need to be addressed as a conference.

[01:00:55] Simon: Yeah.

[01:00:56] Stephan: And if you do greatI need to stay excited and, and have fun organizing it. If that stops, then Devoxx,Belgium will stop for me as well because it's like, I, I don't have to do this. Right. Um, and the, the only thing I really hate is that you create this great party.

[01:01:14] Stephan: But I can't really enjoy my own party because I'm running around like a headless chicken, chicken, like from one fire to the other, making sure everything runs smoothly. Um, and so that's the biggest disappointment is that I can't enjoy the conference as a normal at attendee, which, which is a bit of a shame.

[01:01:30] Stephan: But luckily we record everything so I can see it online.

[01:01:33] Simon: And I think that's the, that's the joy of it, right?

[01:01:44] Stephan: And if that stops, it stops. I mean, I mean, I would be totally fine to have a few sabbatical years.

[01:01:51] Stephan: but I don't think we we're at that point yet.

[01:01:54] Simon: Stephan, I'm sorry to inform you. I think it's actually gonna, I think it's gonna grow from here. So you, you know, your job is well safe and, and, and, yeah. Sorry to add more to your plate, but, absolutely. Yeah. Cool. Stephan, this has, this has been, this has been brilliant anda real insight into kind of like how youryour approach, needed to change, from, from developing an application, going from kind of more of a, a vibe coding to a spec driven approach.

[01:02:22] Simon: And, and. Fingers crossed, Devoxx, and, and, and I'm sure it will go well. It'll be another amazing conference. I'm looking forward to being there again. I've been there many years and, and looking forward to, to, to, to seeing you in person again and, and, and being there in October. So all the best for Devoxx, for those thank you, for those who want check it out more.

[01:02:43] Simon: Devoxxbe, I think, right?

[01:02:45] Stephan: Correct.

[01:02:46] Simon: Devoxxbe, andand yeah, all the best. Thanks very much, Stephan. It's been a, it's been a joy to chat with you.

[01:02:51] Stephan: Thank you for the opportunity. I'm looking forward to your, the Tessl product, being released, in the near future.

[01:02:57] Simon: Thank you very much, Stephan. And, thanks very much for listening.

[01:03:01] Simon: Tune into the next episode. See you soon.