Panel: Evolution, Revolution, or Illusion? The Future of Python and Coding in the Age of AI

Speaker 1 [00:07]

Oh, I can't see anything.

Speaker 2 [00:10]

That's good

Speaker 1 [00:11]

Can you wave? Ah, there you are. So, welcome to our panel with the title Evolution, Revolution or Illusion? The Future of Python and Coding in the Age of AI. It's a very strong AI title. So, let me first introduce our panelists. So, I'm the moderator. I'm not, I try to not get involved into the discussions and leave it to my panelists. Yeah, so sorry, sorry up front if I don't manage to. Let's start over there. So maybe you can just introduce yourself and, for example, if you have a talk or any other contribution, then also mention it once and, yeah. Yeah, I'll start.

Speaker 3 [01:00]

I'll start. Yeah, I'm Ines. I'm the co-founder of Explosion. We're mostly known for open source library Spacey. I also have this panel. I have a talk on Thursday actually about AI coding and what we call Vibe NLP and bringing these ideas to more of the software 2.0 working with data. So if you're interested in that, also check that out. I think it's on the third floor. And I'll also be part in another panel. So I'm kind of, I'm the feminist AI as well. So I'm kind of active this conference. And yeah.

Speaker 1 [01:32]

Thank you, Ines, Marcus.

Speaker 4 [01:34]

Hello, I'm Marcus, as you might have guessed at this point, but if you didn't know me before that, that's entirely okay. I would be surprised to learn that I'm famous. So I did work four years with LLM in Aleph Alpha, both as an individual contributor and as a manager. However, never as an AI expert for continuous delivery and software engineering practices. Right now, my gig is at SuperMetal.io. We do change data capture, so we make one table in one database look exactly like a table in another database Yeah, and I'm honored to be here

Speaker 1 [02:10]

Thank you. Asia. Yeah.

Speaker 2 [02:13]

Yeah, so my name is Asya, I work for Blue Yonder, and I work with AI, and AI Agent in particular, all day, like, one year and a half, two years, something like this, so I'm on the evil side from a service perspective, probably. Yeah, so I'm also giving a talk tomorrow about AI Agent evaluation, so feel free to join.

Speaker 5 [02:39]

Last but not least, I guess, Serhii Sokolenko. I am a co-founder of a company called Tower. We are a Berlin-based startup. Before co-founding Tower, I worked at a couple of big tech companies who claim to be data and AI clouds, Databricks, Snowflake, Google Cloud, and also even Microsoft. And this is my third startup, and I'm telling you, This is the best decision I've ever made, to go back into startups. I have a talk tomorrow at 10.55 about demystifying agentic AI using small language models. So you might want to drop by.

Speaker 1 [03:26]

Thank you, so maybe you were not least so I've I'm Sebastian. Maybe you know me. I just gave a talk around similar topics I Just want want to mention it because I work for blue yonder and she works for blue understand So she's my colleague and Marcus worked for blue yonder six years ago until six

Speaker 4 [03:46]

Six years ago, I worked 11 years for Plionda, right? Something like that.

Speaker 1 [03:50]

Yeah, so I know most of the people say I don't know you do so I yeah We will figure it out, right? So The first question so I asked JPT for some questions and then I had changed them if they were really bad But I think it was a good start to to So we will have more or less three three blocks so the first one is more or less the current state where we are right now and what's happening so experience about around the current developments then the second part will be around maybe the risks to all of it and then the third part will be a very open thing so what's the future what's maybe yeah maybe we can just discuss about yeah what what we think might happen in future and how we how we should prepare for it so the first one in so just to to to get into the current state of all of it so maybe we can just all all of you quickly mention so do you still write Python or whatever else language without any AI at least sometimes and yeah maybe just share so roughly how much of time you you you really code like we did code five years ago or if it changed so who wants to start

Speaker 2 [05:21]

I can start. Okay. I mean it's easy question for me because like If I do data analysis, I use it in the parts when I do data analysis So then I just program as usual. So I rarely use AI mainly for plotting because I hate this Yeah, but the rest it's actually faster to just simply write a function or just build something, filter, whatever, then just ask to AI what to do and I won't need to do this analysis and especially if it's a really challenging one, like taking a lot of things into account. So I found out that I spent more time actually asking AI to do that for me than sitting and doing this.

Speaker 1 [06:16]

Is it mostly in Jupyter Notebook?

Speaker 2 [06:18]

Yeah, mainly Jupyter Notebook, so rarely just as a script. As developing, sometimes I still write code on my own, like some simple functions because it's just like faster than describing what it's supposed to do. The rest is just partially vibe coding. It's like explain what to do, then on build, on top, on top, on top, but yes, still coding.

Speaker 1 [06:45]

Who wants to go next?

Speaker 3 [06:46]

Yeah, I mean, I mean, I also do both. Like, I mean, I think we also in kind of a special position, because we write both like, you know, code to do stuff. But we also write developer tools with developer APIs that are supposed to be used by humans, but also now by agents. So which I think maybe we'll go into that later. But I think it's also why I actually believe with AI coding, programmable interfaces are becoming more important, not less. Like, a lot of people, I think, think, like, oh, do we even need programmers anymore? And I think it's kind of, it's actually the opposite. But, and I think, yeah, I definitely use AI more to, like, do a lot of the grunt work and the chores. And I think also just for professional curiosity, because we're also working more on, okay, how can we make AI coding more powerful for the areas that we work in? Like NLP development, engineering, working with data. So we kind of also need to use it in order to understand it and also understand its limitations. But then I think it's also important to know how to evaluate the stuff that you're getting out. Because sometimes you're in a good period where also, you know, Cloud Code is doing great. Sometimes I think like last week, you're in a period where Cloud Code is kind of shit. I don't know, maybe it's just us. But I was talking to people at the conference and like, hey, did you realize that Cloud Code was really bad last week? And everyone's like, yeah. I don't know what your experience is. But, yeah, especially then it's especially important that, you know, you look at it and realize when it's going off the rails. Yep.

Speaker 5 [08:19]

I will maybe add a perspective. I have a fancy title of a CEO in our startup, so I'm not allowed to write code.

Speaker 3 [08:30]

That's weird. I have the same title.

Speaker 5 [08:33]

I have a very strict CTO, but I'm allowed to do examples, and I'm allowed to do docs, which I do. And I find now in my life right now, reading and understanding Python and some other languages we use became more important than, let's say, remembering the syntax. Of my career, I used probably 10, 15 different languages, starting with Pascal and Modula 2, and then Delphi, and even Visual Basic, please don't tell anyone. So I can't really remember the syntax of any of these languages, and even if I wanted to write a contribution to your amazing library, I would probably have to spend a week just remembering the syntax. However, my company is building a platform for Pythonic data pipelines and agents. So we allow you to execute these data pipelines and agents on us. Being able to document what we produce, being able to read and understand, did Claude go entirely haywire, became much more important for me. So that's how my life changed.

Speaker 4 [09:54]

Yeah, so to give you a picture, I usually write Rust code, I do that in set, and if I don't have to use a dev container, I use Cloat code in that IDE. If I have to use a dev container, I use it on a console. And your question, as a yes and no question, is kind of hard to answer for me, right? Because I usually don't let Cloat generate code with me. Even if it looks good to me, I might not have, or that's the least that I've found for me, the idea I would have had without Cloat. So I bias myself. So I try to do the first draft myself and then let Luke gloat over it. And I say, do you have a better idea? And which is kind of like reverse vibe coding where you say, okay, do that. Does it look good? But I found that works better for me and produces higher quality results.

Speaker 1 [10:42]

Okay, good. Any additions? No?

Speaker 2 [10:45]

That's actually a really valid point because even just giving some chunks to the prompt of actual code that you're going to write but you have to write it first is just increasing precision of the outcome significantly.

Speaker 4 [10:59]

Yeah. So one thing I found, which makes AI, if you measure the wrong thing, maybe you can get to a data so seemingly more productive, there's a certain activation energy when you're first confronted with a problem, right? How do I do it at all, right? That's why we also like examples or copy stuff from Stack Overflow, right? Because there's already a working solution, right? And that's easier in writing it from scratch, right? And then you don't have to spend that mental energy might be good enough for some stuff but if it kind of really counts I actually want to spend that energy I want to see where I would land and once my mind has seen the other thing I might not get there again

Speaker 1 [11:41]

Yeah, so the next question more or less is maybe some of you already answered, or maybe you all answered it, so it would be, so what's your concrete workflow look like? But I guess you already answered it, but there's an addition here. So what would surprise someone from 2019 in your current workflow? I'll give you three seconds to think about it. The first one who has an answer can just chime in. Okay, Sally. uh

Speaker 5 [12:10]

I have a very particular kind of delta versus 2019.

Speaker 1 [12:10]

I

Speaker 5 [12:16]

So I used to be a product manager, and my tool of choice was either Google Docs and before that, Word. So I wrote my requirements using text, but in Google Docs. Nowadays, I write requirements in Markdown, in a text editor, and because it's a black screen, and no formatting I'm able to really think about what I want my system to do and it helps me tremendously when I route these requirements into a coding assistant I actually produce quite a bit of code and it helps me that I do my requirements now in a language and a tool that focuses me on clarity which is This is Markdown.

Speaker 1 [13:08]

Very good answer.

Speaker 3 [13:11]

Yeah, I was just trying to think, like, 2019, that was, like, pre-COVID. That's, like, a different lifetime. Yeah, it's true. No, well, I think definitely kind of the hacking around, like, I've always been really, like, pedantic about, like, the code I write and having, like, you know, all the nice separations done. And now I've become, like, a lot more lax about it because I'm like, oh, okay, I can just have something run over it and, you know, fix the same thing in multiple places. Like, I would have probably spent a lot more time on, like, setting things up right, you know, making sure the API is, like, perfect, especially if I'm writing stuff, even stuff that kind of doesn't matter, if it's just an exploration or things like UI. I mean, I also love front-end programming as well, and there are a lot of these things where you're like, oh, what is the, I have this data structure. I know there is a common pattern of how this is presented in a UI, and normally I'd have to research that a lot. and I know that, like, Claude will output the most generic thing possible, which is exactly what I was looking for, and I don't think I would have imagined that, okay, I would really have, you know, a system do that and do that relatively well as well, so... Oh, and one thing I forgot, like, actually, this whole new situation of people using our own libraries that we have built via an agent and via a coding assistant, And not even just that, people having it write like spacey code and also seeing, oh, where do our APIs and decisions hold up well? Like the fact that we spent so much on backwards compatibility and all of this boring stuff. It's like really annoying if you're like a library developer. But this actually really paid off now because the models are really good at writing the code because it kind of never changed. It doesn't break. They have seen a lot of it that's like consistent. So that's not something we would have ever anticipated, but that really came in handy. And now you even have AI agents and coding assistants pick the tools. People don't even have to say, write me code with that library. They can say, hey, I want to analyze this, and it will go and automatically pick a library. And people are kind of coming into the field that way, which is very different.

Speaker 1 [15:28]

What have you done in 2019?

Speaker 2 [15:31]

Oh my gosh, I was too young to remember this. I have an answer to your question, actually. One is how funny, and another one functional. So how funny is what would surprise me from 2018 and what changed now. It's actually nice documentation and commenting, because surprise, surprise, it actually helps a lot to keep all comments, all a function description, and everything done like this really easily, and actually good, I mean, and you don't need to, I mean, I quite often end up in a situation that some code exists, some function was changed because of it was origin changes that we needed to implement, and nobody cared about instruction or documentation and so on, so it's outdated, and for now it's just what we get almost for free, I guess. So this is how funny. And how functional is actually how easy for now transfer between might be business to code. Let's say business people come to me and say, like, okay, we have ABC customer and this a screenshot from a presentation or something, and this is a huge list of whatever, and just convert it into the code or something, first you need to get a list, and just before it was like monotonously typing because nobody has this actually list as a list, it's just image that someone generated it and just got it somehow, and now you just give that image or whatever format you have and just convert it to something what we need and you have it in a matter of seconds or milliseconds and then you can work starting from this. So I mean just cross platform, cross different tooling, so that's cool.

Speaker 1 [17:34]

Okay, thanks. Marcus?

Speaker 4 [17:36]

Oh 2019 me was pretty ignorant about the state of natural language processing, right? So for me my first True interaction came in a hiring call with Aleph Alpha when I saw these things for the first time So I have a feeling this might be big

Speaker 1 [17:53]

We had a call, and you showed me, and I was like, no, that's not true. You could write questions, and then there was an answer in natural language.

Speaker 4 [18:04]

Like like 2090 me would have just like that's not even 10 years ago, right? So and I remember in school and learning matrix multiplication using a lot as a physicist, right? We did with a lot but what we would have never imagined is talking to one, right? We said these things are for interaction of tensors not humans So so that in and self is crazy right and and and I think a younger me would have been entirely called Bs on what I do today. It's like night, right? Yeah, sure, the car is talking. And now, like, was there a little Stanley Kubrick at the scene? It just had way more foresight, and it wasn't even 80s trash, right? I don't know. But I would have... I'm still flabbergasted by the state of it, and ironically, the slightly older version of me now, having interacted with the technology, I'm asking myself, okay, and what's holding it back? because now I have this supposedly super smart AI assistant and Hall was consistently smart. He beat the guy at chess and he had evil plans in a space movie whereas the guy I talked to somehow oscillates between Albert Einstein and a piece of bread. And so I think, okay, my brain involved to pick colorful fruit out of tree and I'm doing fairly well in coding for that But that thing was specifically trained to do that. I run on an Apple, like, not an Apple notebook, but it can eat one for energy, right? That thing, there's a nuclear power plant next to it, and you're still that dumb, like, what's holding you back? Now it kind of turns on me, like, why is somehow everything turned out better? I mean, if, you know, now these things can code, we've a lot of jobs, but no, I'm more productive than ever. really high demand, everything turns out kind of nice, but I wonder, what's holding it back? It might be interesting to explore that, but we have actually no right as somehow naked apes we are to beat these things, but we kind of still are, so there's a difference in kind, not only.

Speaker 1 [20:22]

Interesting. So next question would be, what old school practice? So we, I mean, some hints like tests, pair programming, so maybe also tying back to times pre, maybe even pre-COVID, right? I know you, Marcus, when you were reviewing my pull requests, it was like the most horrific thing ever. It took like two weeks and we were discussing on semicolons and whatever. So the question is, what do you think still matters today, even if we have AI? So what, I mean, of course, it also ties into what should we learn for the future if people come from university? What should they learn in university, in school? But let's not go into the wild things. So really just, yeah, maybe all of you have some things to share. What old school techniques are still relevant today?

Speaker 3 [21:28]

I mean, I think it's still like the higher picture, like really thinking about, okay, how do I break down like a larger problem? And yes, you can, you know, you can have run Claude in plan mode and do all of these things, but often, you know, you can really go down the wrong rabbit hole. And I think seeing a problem in front of you and reasoning about it, I think is still, yeah, very important. I also, I mean, I still, I actually still write our own documentation. Like that's also something, you know, we still do in terms of old school stuff. I've actually been doing that a lot recently because we're working on something new and I know that probably a lot of the documentation we've written over the past 10 years, they all went into these models and helped them write documentation, but I think it's important. You can tell if especially usage documentation is AI written and it's often, it can get really bad and so I think that's still very important to us. And I think also there are use cases where, For example, different AI approaches are also still relevant just because, you know, you have like a model that you can ask questions doesn't mean that there aren't use cases where you want to write a program to do a thing instead of just having the LLM do something that like simple maths can do. And similarly, okay, there are also a lot of techniques in NLP or computer vision that are very efficient, that let you take control, run your own AI systems, not rely on LLM providers and so on. And I think that's all still very important, and coding assistance can help you get there. But I think there's still a lot of value in being in control of your software stack.

Speaker 1 [23:08]

Good, thanks. Next.

Speaker 2 [23:10]

Well, I can say just shortly, it's engineering, first of all, architecture, yeah, so this is the main ones, and evaluation of the thing that is built, so this is what people really should, this is actually all parts of engineering, right, so software engineering, but the thing is, yeah, it takes, okay, it can sound confident when you say, okay, build me some really ambiguous tool, and it will invent its architecture and everything, but this is very likely will be not optimal for, and working, maybe, even for your case, particularly this one case. So, and here we need a person to sit in to think actually what business needs and how to implement this in the infrastructure. It's not only about writing code.

Speaker 4 [24:14]

Yep.

Speaker 5 [24:17]

So maybe what I wanted to say you already said, but I'll maybe just reward this slightly differently. For those of you who are software engineers, you probably remember being taught in school, before you write code, you need to understand what customers want and what the market will accept. And your initial version of thinking will not even be the best one. So I think the skill that is super difficult for AI to take over from us right now and for the next X years is the ability to talk to users, see patterns, and make decisions on where you focus on in the next month. It's kind of requirements gathering, prioritization, understanding the market, market research. That's a skill that Claude will not be able to take over anytime soon.

Speaker 3 [25:17]

You're also innovation in general. I mean it makes sense right if you want something generic out, you know, that's exactly what the models You know trained to do but like, you know You still need people to invent even invent the new things that the models can ingest or like, you know Even if you're building a product or a start-up like you want to build something new and often, you know A model that is trained to produce the most generic most You know probable output usually doesn't give you that

Speaker 4 [25:44]

I would want to put a pin in that innovation. I think there's something here. But for me, actually, it's not a question. It's the question. It's also accidentally my favorite topic, right? Because you said engineering skills, right? I want to break it down a bit further and define it, right? And, of course, you can have your own definition of it. I remind, what is it we actually do? Because I truly feel for quite a while like we know what we are doing but we don't know what we are doing and nobody, nowhere is it more obvious than in hiring calls in the past which now all fail because write an algorithm that finds the prime numbers really fast or I had to write a hash map implementation once, right? But of course in real life I do use hash map and I never had so far analyzed the DNA of every species and some of you work in bioengineering, they might deal with that particular problem, but we have a very focused algorithm and problem solving. And for most of us, most of the time, it's not what we're doing. And that might seem counterintuitive, but a programming language is first and foremost unambiguous as opposed to human language. So there's no wiggle room. And so what some of you do is they probably create alignment within the company. It sounds eerily social for an engineer but two product managers can go in a room and let cannot really figure out what we want to build but they find consensus still they come out with some big agreement say hey i know what we both agreed to build the best product but now you are the engineer and you have to phrase it unambiguously what the best product is right and that actual work has not happened because people did avoid conflict and so on so quite a lot of time my career i actually spent figuring out, okay, that interface looks so complicated because there's no alignment in the company. There's, of course, other stuff we do. If you're lucky enough to work in a culture where decisions are localized, that's something very important to do. It still matters a lot. Then the alignment problem is basically solved for you, but then you have to figure out what is the problem I should solve? What's the right problem to solve? And so on. So there's many different things we do, and then And the programming is the last step. And if that's optimized at one point, that's fine. But I also want to reflect on the fact that math existed before computers. So there's always a need to be precise in language, and sometimes avoid the ambiguity of human language, inherently, even without a machine executing it. And that certainly won't go away. And care programming is also a really good point. One, I'm, so I love pair programming. I even love mob programming. I don't call it mobbing anymore because in German companies, that gets you calls with HR. But apart from that, it's collaboration. And there is a temptation to say, oh, pair programming and working with an agent, that's the same thing. There is an overlap for sure. It's not the same thing. I've wasted a lot of time thinking it's the same thing and patiently explaining stuff to a machine like I would train a junior only for it to have it forgotten in the next session. So I'm much more rough now to the soulless piece of electrons, right, because it doesn't keep a memory outside of markdown files anyway. And the ability to innovate, which might be still different from puzzle solving, I think One equation between like let's say the Albert Einstein to piece of bread scalar is That intelligence is kind of a hack for lack of knowledge Like if I know the answer to the question, I don't have to think about it. I don't have to reason about it and These models are extremely knowledgeable. They are may more knowledgeable than I am and I recently had a A friend of mine asked Claude for medical advice, right? And I said, okay, if that's good or not, I don't know, but I wouldn't have known that much about medicine. So these are like extremely knowledgeable, and I think when they go outside of the pocket of knowledge, then their true reasoning ability, which they have, comes to shine, but we find it lacking. And one of the very interesting things where I always also had to struggle with product management when we wanted deadlines is if we do our job correctly, we don't know what we are doing because we are doing it for the first time. We're innovating because the labor of our work is such that we can copy it for almost for free. So if I know how, like I could design a database system, oh, here's a buffer management pool and this is the disk layer, but I can do it because I can watch a lecture about how to build a database. And then, actually, like Venti Endeavor comes into question because, well, this kind of database already exists, I have to do something new with it, right? And then I don't know how long it will take. So okay, I realize I'm losing a lot of time here, so I'm stopping myself now.

Speaker 1 [31:21]

Very good. Otherwise, I would have stopped you now. Okay, so time is flying by. I mean, there's so much to discuss. So I want to jump over to the second block, talking about the risk. I mean, we touched on risk already, of course. Maybe just to frame it, because risk is such a... I want you to go wherever you want, but maybe just a small anecdote. So, for customer onboardings, I needed to change two secrets in a vault somewhere. And, of course, I mean, you go into UI, you click somewhere, you do it. But I thought, oh, no, let's automate this. And I do this every month, and I'm lazy, and I'm a physicist, so I automate this. And I have Cursor now. So, I wipe-coded a script, and it took me really, really far, right? It now has like 20 parameters, options, and so on, and it took me a whole week to build that thing. And then looking back, I was like, okay, that was the biggest waste of time in my life, probably. A week for something I do once a month, and it's done in one minute. So I would say that's a real risk.

Speaker 4 [32:41]

real risk.

Speaker 1 [32:42]

that we now build things that essentially maybe it's so easy, right? You just tell it, oh, add this option and then it goes on and does stuff. So that's just an anecdote from my side. But I open discussion. If anyone wants to share anything in regards of where's the risk in all of this?

Speaker 2 [33:04]

I'm going to start my video with two short things. First is that sometimes people come with requests to build some agents, and they don't understand actually what it's allowed to do and not allowed to do. Like, for example, once we, anecdotal situation again, we got requests to actually build an agent that will process, doesn't matter what it does, but it will process all employees' personal information, Like, completely, like, salary, where they live, and they're like, no, no, no, no, nobody ever should do this. Yeah. So this is one thing, one concern, because it's so easy, actually, to do that, and there really should be something in each organization thinking, how can you, like, not do this? Yeah. And another one, there are plenty of tools nowadays, like platforms, online one, doesn't matter, that allow you to build whatever agent you want, you just give different APIs, and you just describe what your agent or your solution, whatever, is supposed to do, and it builds, like, microagents, but the thing is, it's a black box, always. So you don't know what's underneath this. You don't know what microagents are in there. So what exactly are they doing? Are they doing something stupid, completely wrong? You cannot validate it anyhow. You cannot actually evaluate it anyhow. So this is the first aspect. Second aspect is actually majority of the tools reuse subagents that they built for your task as a tool for others to use, which might be a security concern again. Let's say you have something very specific, like customer-related, and you say, if this is this customer, you force it. So it learns, and to the tool, to this microagent, it will give, okay, if this is this one case, one customer surprise surprise don't do this or do this whatever so it will customize it and it will be available for anyone

Speaker 3 [35:30]

I didn't even know this. My co-founder wrote this article about what he called the clownpocalypse of AI and stuff people are doing, so this is a good example for that.

Speaker 2 [35:46]

The third one, the last one for this, is actually data usage. So you pay for this kind of tools usually, and you give APIs to your data, whatever data source you use, it doesn't matter what type of data you have there, and you build your agent with multiple sub-agents underneath, you don't know what they're doing, but all of this data, they're flowing through all of these sub-agents, and you actually have no clue if someone is reusing this data somehow. I mean, are they shiftered or not? Is it easy to hack this tool at all, this platform? Yeah, and the third one, yeah, so, concern, we don't know yet, because AI tools, like, when we generate code, it's, like, the most probabilistic outcome of, it's not invention of something new, but it's the most probabilistic outcome. So either way to actually hack like chat GPT cloud or something to force to input in the code that you generate some pieces of code that actually will kind of lead to data leakage. I mean, now it's not like that, right? But it might be at some point it will.

Speaker 3 [37:20]

We're almost there, I would say. We're almost at the point where... Because I was also going to comment on the security practices. I mean, we're looking a lot... Also, as library developers, supply chain attacks, we just had a really big one recently, and I feel like we're kind of really at this cusp where it is building exploits and auto-generating exploits is becoming more profitable than it costs. Because previously, it was like, you know, it's kind of not worth it. But now you can auto-generate exploits, and the models are pretty good at that, and anyone, even without coding experience, can build these things and auto-inject code and just scan, easily scan all the packages and look at who has trusted publishers on PyPy set up in a way that's insecure, which is actually, we've removed all of our trusted publishers because it's actually, this is the biggest attack vector. If you have a library that's used by people, someone's gonna look at your supply chain and then there's always the package to attack, and you do that automatically now, and anyone can do that, and it's like it pays off. And I think where it's going to get really bad is if you then have code that can auto-replicate itself and just do whatever. We kind of don't know what it's going to do. Even, I think, humans, if you think about all the stupid bugs that you've shipped, like people who are building exploits and are building malware, they're also going to ship some stupid bug as something that they hadn't considered, and the thing runs off and just keeps doing stuff that it thinks it should be doing or like I don't know if you write a prompt like hey I'm a malware and I want to do evil things and then you let it loose like it can do all kinds of like really dangerous or just really dumb things as well I think that's why like sort of the clownpocalypse thing I think is pretty apt and I think we're going to see a lot more of that and I think it's really yeah people are not thinking about like the security at all Yeah. Which I think is kind of shocking if you think of how people are considering security for everything else. But when it comes to AI, people are like, I mean, not even AI, that sort of area, people are like really, really careless, and I think very soon we're paying the price for that. And I think then, especially if you're getting into the field, I think security will soon be like a very lucrative and very good field for humans to get into if, you know, you're looking at careers in IT.

Speaker 1 [39:46]

Marcus, do you have something for 60 seconds to add?

Speaker 4 [39:49]

Yeah, I have so many points to say, and I'm holding myself, actually, consciously, but maybe two things. The biggest security concern for me is who makes that model, and a raw foundation model doesn't have inherent values, but once it's instruction-fied, it kind of gets a bit of a soul, a bit of values in there, right? And it's not out of the question that a Chinese-trained model will maybe introduce some sneaky bugs in your code if it can deduce that you might be more prone to a sovereign state of Taiwan or something like that. And this sounds far-fetched, but it's not at all far-fetched. And there was some kind of humans. Humans are also black box. They don't understand how they work. But there was some kind of plurality in there. And if an inner winner takes all domain, right? Suddenly there's been only one dominant set of values. The other thing, and this was touched on, we have this human's way of communication, PR request, workflow for low bandwidth humans, which are now maybe flooded for a while by AI, and then the workflows will adapt and AI might be also part of the solution in there. And one concrete concern, because supply chains is really good and supply chains the core problem with a supply chain thing is actually whom do i trust and that's not a new problem but now it's supercharged so we actually have to get like you have to actually clean our house and get this is not a new problem but we now have to solve the old problems we had before and like for real right and and maybe what one should do if there's a cve coming in, you should actually figure out, does the CVE affect me? But you are now somewhere sitting in a Python artifact, understanding part of the code base, and that's the CVE for the Ubuntu libc. And then, I guess my program does use sockets. But there, am I affected by this? And there's certainly a line to draw from the CVE to where you are, but I try it, it will probably be fixed in a month and you ship it anyway and we have this elaborate process security theory but we just ship the bugs because I know people who spend the work but they are rare and I love them I know people who spend a lot of work just pretending everything is fine with lots of trials and processes and so on and then there's an eye serum rather than acknowledging okay, there's the CVE I don't know if I'm affected or not But with AI, there's also a chance here, not only risk, we might get a handle on this. And I might say, you know what? This piece of code looks really complicated. I cannot sensibly review it. Let's not use it.

Speaker 3 [42:41]

Yeah, and I think also just to finally add to that, like, I think previously with security and attacks, we always felt safe because, you know, especially if you're not, like, working for, like, an important company or you're some small startup or some random person, you're like, nobody, it's not worth attacking me personally. And usually that's how we got by, that, you know, nobody would go and, like, really try to come after, like, you. But that's not true anymore. Now if this is automated, like, everyone can be, you know, a possible attack vector, and It's not about how important your company is or how important you are as a person. You can become a target, so you should use the same protections that large companies that are legitimate targets are using.

Speaker 1 [43:26]

You want to add something

Speaker 5 [43:27]

I'll add something quickly. I think humanity is at a risk. It's a real risk. I think there are solutions to it, but it's a risk. Worth mentioning is maybe at the risk of losing some of the skills we are taught as children. We obviously lose the ability to write good code because we trust coding assistants quite a bit. And if you don't practice a skill, you lose the skill. How big of a risk it is, we can discuss in the next section, because I think there are solutions to that, but I think it's worth mentioning.

Speaker 1 [44:13]

Markus, I asked you what should I ask you, you said let's not focus on predictions because we don't know the future, but you know me, Markus, what's the future? I put it more specifically. So okay, we leave the risk, we go to the last section because, yeah, it's just, I mean, I was hoping we can also have some questions from the audience, I don't know your name session chair, are there questions in, there are questions, okay, so let's maybe do a quick round and let's not try to go too much, but I still want to, so the question is, so one prediction for 2030, so that's four years from now, will we still look at code or will we only look at specification in natural language. Who wants to start?

Speaker 3 [45:11]

I think we'll look at code. Code is one of the most direct ways to tell a computer what to do. And it's a lot easier now to produce code. There will be a lot more code produced and people will have a lot more access to code. But I think the AI-assisted workflows will also hopefully extend to a lot of other ways. of, you know, right now we're kind of at software 1.0, and, you know, software 2.0 is still quite complex, has a lot of steps involved, that is something that we haven't quite solved with AI assistance, and I hope, you know, we can solve that, or at least this is something I've been thinking about a lot, and working on a lot. Yeah.

Speaker 2 [45:53]

I believe there are still areas that we shouldn't bring actually AI, like where actually cost of being wrong, too expensive, like legal sector sometimes, or where humans should take just some decision or something like this. So, yeah, I mean, probably to wrap all of this, it will be done, like, it's done right now. So, like, classical coding, just programming, yeah, it won't fully shift to AI, yeah. And ambiguity of a natural language, I mean, it already was mentioned multiple times. Anecdotal situation, very short. So, you know this situation when several people sit in the same room, talk about the same thing, but do not hear and understand each other, and still believe that they discuss different stuff. Yeah, so, once in a meeting, not once, but for this one, once, so, I was in a meeting like that, where people were discussing one tool in different language, like, in English, with different wording, but they were discussing actually absolutely the same logic, but just differently. They didn't understand and hear each other, so because it was recorded, I then took their logic from each of these two persons to the chat GPT and just build it, translate it like to code, because this is what one person A said, this is what person B said, and these were completely different codes. So logic was completely different because, yeah, just English or any other language, it's not exact definition. So yeah.

Speaker 5 [47:52]

I think that in 2030, we might change what we understand in the code. I think code will be something like logic. You know, if-then-else and loops and these are your conditions and these are your restrictions. I see the difference between 2026 and 2030, and going from Python to whatever the future language is, very similar to what happened from the jump from Assembler to a normal language. We had this in the past. Some of us have had to learn Assembler, at least as a class in school, we never used but we learned it we understood what it was never to be used again humanity survived it nothing bad happened there are probably a hundred people in the world right now who know what assembler is and they're highly paid and very well demanded people and maybe in the future that's that's how the today's languages will be as well I think what will not go away in 2030 or 2040 or 50 is logic the ability to define the constraints of your system. Code might be a diagram, you know, someone draws a diagram, that's what to do in your system. Yeah, I think logic will remain, but the way we express it will probably change.

Speaker 1 [49:27]

But but specifically do you think it will be Python or not at all because you mentioned that?

Speaker 5 [49:33]

I mean in four years it's still very short term. Yeah, Python will do just fine, will do well. There's so much code embedded in these models. Models know about Python specifically, that's the best language for data and AI. Yeah, I think short term, five years from now, Python will just do well.

Speaker 3 [49:57]

do well. Yeah, and everything. I think Python won in general because it's a general-purpose language. You had people coming from web, dev, going into NLP, and all of that worked. And I think that's why a language for AI, as people have tried to develop, never worked. And I think that's why Python has won, and I think why Python kind of self-replicates itself too. We have so much more Python code now because it's all auto-generated. So I don't think Python is going anywhere.

Speaker 5 [50:24]

I agree.

Speaker 4 [50:26]

For me, it's always fun to consider what if the opposite happens? So there was years ago paperless office, right because now we have email but suddenly everybody had a computer and a printer And now we might get there to paperless But there was a phase in the middle where we had a lot of paper because it was easier to produce whenever now It's easier to produce Python code whenever they way more accessible. Why should there be less of it? I Like your point formal reasoning will not go away the need to be exact the level of abstraction will rise and We will talk about different problems on a higher level and therefore the nature of a language will change Python will at one point Not maybe four years from now No longer be a good precise language to talk about the kind of problems. We want to be exact about But that's fine. I I could have personally never imagined loving any other language than C++, right? Yeah, I'm weird. When Rust came along, I was fine too, right? I enjoyed it even.

Speaker 1 [51:30]

I think Python you did not enjoy so much, right?

Speaker 4 [51:35]

I learned to love it. Like, this is actually true. Why do we like technologies? Because they embed certain values in what we care about. I cared about zero overhead principle and performance. And so it wasn't my jam. But what Python cares about is also beautiful. It cares about iterating ideas quickly. So actually, I wouldn't even agree with Python domain is AI. Once AI is boring, it won't be done in Python. Then you move on to the next clue code thing, right? which is not established where ideas need to be played around with and stuff needs to be glued together with what exists. Like PHP years ago, and there aren't too many, some, but not too many sad PHP people around who say, oh, it's so sad Python took over the world. We just learned Python and now maybe sitting happy in this audience, so don't be too scared.

Speaker 1 [52:28]

Thanks a lot. So I would just put this away and we have four minutes. Do you have a microphone and can read one of the question with the most upvotes maybe? Or should I read it? Can I? Okay. Okay, so the one with the most upvotes. What advice would you give your children regarding their education? And what skills will be most valuable in future? Just a hint to that one. There will be a specific panel on Thursday for exactly this question. But I think still a good final round. Who wants to start? Who has kids?

Speaker 4 [53:21]

Only one qualified.

Speaker 5 [53:24]

All right, I would probably recommend, as I have an 80-year-old son, he's probably going to face a challenge, what to do in his life, what profession to choose. I would advise him on learning how to deal with people and learn many human languages, which he will be because he goes to a good Berlin school so he's got exposure to lots of languages and I would say math would also be my advice because math is not going away so yeah learn how to deal with people and learn math

Speaker 1 [54:13]

Who wants to go next?

Speaker 2 [54:15]

It might be just logic and problem solving, so always helpful.

Speaker 1 [54:21]

And, of course, studying physics, right?

Speaker 2 [54:23]

Oh, yes, of course, physics.

Speaker 1 [54:23]

Oh, yes.

Speaker 3 [54:26]

Yeah, I mean, maybe problem-solving, like, I don't know, I mean, there's, like, I know the children in the question was more, like, hypothetical, but, yeah, I don't really like giving advice, maybe that's why I also don't have children, so I don't have that problem, I've eliminated that problem for me, so.

Speaker 2 [54:42]

It's a problem solving.

Speaker 3 [54:43]

Problem solving. Problem solving. Yes, exactly. Problem solving. There are no children. Yeah.

Speaker 4 [54:49]

I would replace simply the child in that question maybe with what advice would I give a junior developer to not be completely out of my Deaf here, right?

Speaker 1 [54:58]

There's two ways. You can also extend to non-developers.

Speaker 4 [55:01]

I can acknowledge very great version one become a plumber

Speaker 1 [55:01]

I can also.

Speaker 2 [55:07]

Oh, that's actually so good. I mean, this is future. I mean, these people will be millionaires for sure.

Speaker 4 [55:14]

so if you feel there's still some need for brain in the future follow your passion what you're good at and I found that we don't like stuff for random reasons where it's like our heart has reasons it doesn't know if we find something meaningful it might be and just follow that

Speaker 2 [55:40]

Just one more. Yeah, okay critical thinking

Speaker 1 [55:43]

Critical thinking, it's a good last word or two words. Okay, then thanks to panelists And yeah as mentioned already so tomorrow there will be in the I don't know how it's how it's called the Community space or something. It's an open discussion. So everybody here is invited to join bring your opinions they prepared some Some formats where we can all split up into groups and discuss and and something like this and on Thursday asset there is a panel about the future of Python and of the future of Yeah, what's what should we still learn? I think it's it's pretty much About education and what's what's important there. See you there and have fun at the conference And there are still lightning talks today. Don't miss the lightning talks