Patrick Debois: Why Your Job Is Shifting from Coding to Managing Agents

[music] >> So this picture, you know, a year and a half ago we would be really proud and say, "Can you guess was it generated with the AI? " Screw that, right? Of course it's generated with the AI.

Um there were like four horses and maybe you don't know why the reason there are four horses because unicorns do not exist. So that's the only thing that actually matters, like you're working maybe at a unicorn, but I don't think they really exist. So we all have to work hard and um I think they're slightly becoming a little bit more robotic.

Um the other undertone is they could be the four horses of the apocalypse. I have once said it right. So we don't know where we're headed.

It's a little bit misty, so I'm trying to bring a little light to the story. The slides are easy going. Um we have roughly, I think, 90 slides.

You don't know I have to take pictures just listening to the story. I assume you're all developers, right? That tab completion, I assume you're kind of using this in some form.

I was last week at a conference and I asked people, "Are you using any agentic stuff? " No, no, no, "We're not allowed to use that in our company. " "Do you use Copilot?

" Yes, yes, yes, of course. So very confusing to me. But they all learn how to copy and paste even if it's just ChatGPT to bring the code and then to generate that, right?

But then our IDEs kind of got more involved and it was not just a one line that was suggested, it was multiple lines that were suggested. It even now has a model that predicts where your next edit is, right? Okay, I changed this line.

No, you probably want to go there. So it's almost like nudging us on the what we need to do. Not just a few lines, multiple files became a reality, right?

Then it became really fun to do our work. Like, "Wait, where did it change things? " We can't really follow.

And it was looking at more stuff, right? Our terminal also kind of more AI and we can copy and paste things in the chat going from there. And our browser got AI.

Even that, right? Like looking at the errors completely directly in our IDE. And then it started to help us with the things we really like, generating tests.

Right? Uh and perfect test coverage. Okay, some new pieces came along the way, MCP servers.

I assume by now, you know, kind of several people have mentioned it in the conference and kind of one of those plugins that you put in there and they all of a sudden your agent has a bunch of tools uh they can do things for you. And I think for those who've ever seen that announcement of Devin, at the time it was announced it was like blasphemy, right? You cannot work.

Like there is, I don't know, how many millions got sold, but I think they were kind of the first one to visualize maybe in the product even though it might have been a fake video, kind of that continuous loop of kind of looking at the browser, going to the terminal, change the code, actually what a real developer does all the time. Then we got a new way, like you don't need an IDE. Let's go back to the terminal.

Hey, back to the '80s or the '70s or I don't even remember. Um uh you know, things get more complex and they did that. So for me as a summary and I'm actually not going to talk about code generation, so this was everything that I have on code generation.

But I do want to point out we're on this journey from, "Hey, we got an LLM to all the way up to we have a team of agents that have multiple LLMs, they have rag, they have the whole stack memory. " And eventually if they don't have the tool they need, they're just going to build the tool, right? So I figured from me personally, I'm just going to go there.

It's fun. Let's see what goes. I also in my job um I'm able to test a lot of tools in the software delivery and AI.

I try to bring those tools in kind of a CNCF-like landscape, but for specifically for AI and native dev tools. I started the year with 250 tools roughly. I think we're now over around 600 tools.

Just things popping up. Obviously tools disappear, they come, they go. It's the period of chaos and we've seen this before with cloud, with security tools, devsecops.

But it's kind of like, "Okay, we're trying to figure out what actually is working and what is not working. " So nice thing is nobody's really an expert, right? This is kind of the reality.

And uh I'm also not an expert, but you know, I put in the time, I play with it and I try to explain things to people. Um for those who might remember the DevOps handbook, that was me. So I also tried to make sense out of that world and now I'm trying to make sense about the AI-native development world.

But what is cloud-native? Oh, sorry, AI-native, I should say right now. Um so when we move things to the cloud, it's like, oh, let's ship the whole VM, right?

Let's do that. So like what you see right now is people say, "Oh, we're now AI-native. " And it's they sprinkled a little bit of AI on top of their stuff and now they're AI-native.

Of course that's not true. And we're still figuring out what AI-native actually means, but that's the journey we're on. And so as a developer uh whenever a new technology comes in, there's some of our tasks who will kind of be removed and done by the technology way faster.

Some new tasks arrive and some will change. So kind of I I like that visualization of unbundling of our tasks and I know a lot of people say, "Oh, it's just a faster way of typing. " No, no, no, no.

Hang on. The things are changing the way we work. And some of my people say like, "Okay, what's the elephant in the room?

" Developers still there? Oh, I hit a sore spot. Sorry.

Um maybe there's new jobs. I'm I'm I'm joking a little bit. Maybe our job is to train the models and you see kind of these kind of things pop up.

I'm looking for coders that actually train the AI to say what's good and what's bad. So the model becomes better. Not saying this is the job for everybody, but what today what I want to talk about is we all know kind of that AI is changing and I assume you're kind of play with it and um the point of my talk is how is it changing things of our tasks that we are doing right now.

And I put that into four patterns. And the first pattern is usually the first that people kind of experience. They ask the AI to generate the code and now they're not doing the creation too much anymore, but they have to say what's good and what's bad.

So you, instead of being the producer of the code, you become the manager. So that's the first pattern that I want to highlight. Now code generation is exploding.

The challenge that I hear more and more from people being becoming more effective with those tools is actually the review. And I apologize that I don't have all the answers by heart, but I'm trying to highlight several subtle things in tools or other things that people are trying. So on the left, remember a multi-file diff?

Who likes to read them? Not me. By the way, I'm color blind, so red green gray as a color.

Uh I do not want to read all your chat views because I don't have time for that. And I know it's very subtle, the thing on the right and I think it was cursor cursor composer at the time, where the review actually showed me the code, but with comments in line. It was a little bit easier for me to understand what was happening, like a reduction, just, "Okay, this is the thing that changed in that.

" So it is just an example of we need to be looking at ways to reduce the cognitive load because the more it's producing, the more work time we're going to spend. So we solved this problem at more generation, now we need to solve that problem of review. Now nobody said that a review needs to be text.

Sometimes it makes more sense to do a review on a diagram. So kind of why is the diff maybe not adapting to the diagram? One example, company doesn't exist anymore.

It's one of those tools in my list, but the concept was interesting to show actually what the change was. Uh Google, they had this notebook LLM, kind of, you know, building podcasts or whatever. So Google said, "Hey, it's a good idea.

Why don't we make a code cast? Like we're just going to listen to the LM talking about all the awesome code changes in the in the morning. Probably not the best way, but I want to put it out like it doesn't need to be text.

Could be audio, could be any kind of fuse um in there. So the point that I I make is there's a like a website called the moldable development environment is that we saw the movement from IDE back to terminal. But I still use my IDE to do the review.

But what if my IDE actually becomes better at dealing with the review task? It's still early days, but I think that's where we see kind of new emerging ways of dealing with that code changes. And interestingly enough, we might also get more UI elements in our chats with MCP.

So kind of instead of just having text, maybe there's a widget that comes in there and kind of helps them similar to that image review. Now, what if we just auto commit? And we roll back when it's needed.

So we we kind of flip the table. You know, I was the first to say, "I'm just going to auto commit. If you don't like it, it's up to you to roll back.

" Interesting. When are we certain of that? And that's my biggest gripe with the faster we get at the code generation, these decisions will slow us down.

Right? So it's kind of some way that it puts the brakes on that evolution. Now, we started kind of creating more safe environments, you know, the agents are generating code and I can do rollbacks.

It was good until here. Right? So that kind of helps in a safe environment of auto committing, but still able to roll back similar to CICD system, but it's now happening in your IDE while the coding agent is doing everything on your laptop.

And then we enter another firm firm realm is what is the AI actually allowed to touch in my code bits? So all of a sudden we become like a a user management and access manager. It wasn't complex enough that, you know, AWS had to invent IAM.

Like it's now happening right in our kind of editor. We become who says like you're allowed access to that and not that. And then here we have to worry about costs because the agents keep running.

Okay, yeah, I want to look at my bill. Annoying, right? Uh I I want to use it, but on the other hand, you know, kind of people or companies started to have that max plan and then people made an abuse of that max plan and they rolled back to kind of like, "Oh, there's a limit for 4 hours and you have to wait.

" So kind of cost management is a little bit of FinOps right there in our kind of IDE. And I would say we're all ops now, right? We're all are reviewing the code somebody else's built.

We are responsible for that code when we put it into production. If somebody is happening at night, the agents will likely not help us, but we'll have to deal with it. So this is the current like the probably the transition in kind of that manager role, worrying about cost, worrying about my agent, telling them what to do and going from there.

So if I bring kind of the analogy with DevOps, we were really kind of happy with infrastructure as code. Great automation. I can now delete all systems at once.

Great. But then we kind of brought in the same safety, CICD systems, more testing and so on. But then we realized we still have to do this in production and the IDEs are still very thin on putting something in production.

An auto commit is one thing and auto push to production still far away. So kind of that um resilience engineering might help us rethink the way we build applications with the risks that AI brings us in there. And then we had observability.

And much like it's it's a very common thing like uh well, if we're not uh kind of producing the kind of code anymore and you become a manager, right? Uh how do you know what good looks like because you're not doing anymore? Chaos engineering was very similar.

We started to introduce faults so we can keep training and be on our toes when things fail. So maybe that's kind of our, you know, new profession is becoming the fireman when things fail and we have to take care of that. Obviously, this is going to be the fun if something happens, which agent did what, who's responsible for what?

I don't know. So we all became managers, right? That's probably from the reviewer to becoming more responsible, dealing with and actually being responsible to do that.

Now, that assumes that we are still kind of very tightly telling the AI what to do and we're kind of in that pair mode. But what if you can kind of just give like, "Here's a bunch of requirements. " Agent code up.

And then we do the review when we are responsible. So I'm now heading to a step before kind of doing that. Now, telling people what to do, I assume there's some architects in the room, raise your hand.

Don't be scared. Right? You're very good at it, right?

Uh I assume. >> [snorts] >> Or QA people, they they test things, right? They they kind of know what to look for and go from there.

So in this pattern, I'm going to explain that we want to express our intent and then the coding is being done by the agents, but we actually worry a little bit less on very detailed things like the actual implementation. As long as our tests pass, as long as our requirements pass, we're okay. It's a little bit of a pipe dream still, but it gets you in the mindset of kind of maybe I go there.

Now, in a very very crude way, cursor rules are a way of already setting a bit of requirements to our agents. I tell it how I like my code, how I want things done. Now, we have more standardization in the industry by an agent SMD where we kind of not are reliant on like where every tool's put it, but we can reuse SMD across multiple tools.

Progress. And then what you saw people do is not just put like, "Hey, the technical requirements, how our team works. " But they start reusing the specification for functional requirements.

Instead of doing the prompt, they just say like, "Let me write everything in a markdown file and pass that in the prompt. " A very very crude way, but you saw kind of people building that up. And so we're like this is a from GitHub is we're not kind of in that in their chat loop anymore, but we just say, "Hey, I got a task.

I write a spec. The agent plans it and rolls it out. " And they even kind of experimented when they're like what should that natural language look like and I think the debate is still out what is the format of that kind of spec.

Most people just use markdown and I think the LLMs are kind of like roughly enough understands how to do that. And they brought recently spec it. Right?

Spec-driven development, spec kind of go from there. It's a little bit experimental, but it gets the idea across. OpenAI as well has been talking about specs, but they do it for another reason.

They do it for training the models. But you can obviously reuse those specs as requirements to actually also implement things. And then Cural from AWS was probably one of the first IDEs that made it serious in their editor.

They say, "Do you want to write code or you want to code with specs? " Like very clear in there. And they use the pattern um similar like it feels a little bit BDD kind of style uh to do that.

That's all good, but there's even another place where I got a bunch of code, whether that's legacy or something I did manually, and I also want to put that into my specification spec. So there's like a bidirectional piece when you're writing specs as well. Because you still want to go into the code and sometimes it's way faster to go in that code.

Now, I work at Tessal and one of the things we do is we try to figure out how we can keep both in sync, right? We keep your requirements in the markdown and we link that to a file. So when your test file changes, we can say, "Please update the spec.

" and go in both directions in there. Now, when you write specs, surprisingly enough, you just have to talk about good engineering practices. Right?

So don't write big prompts because nobody will read them. It's the same with your AI. Like do smaller pieces.

Um modular code bases. Don't put everything in one file, which the LLMs really want to do and they will keep writing that one big file, but you tell them it's not a good idea. If your documentation is up-to-date, that also is helpful for both the AI and the humans.

And if your coding um style is inconsistent in various pieces of your coding, the AI trips up like any human would do. So, there's kind of advantages of those things. And then including tests, if the AI changes, you want to see what changed and what.

So, what happened now a few times and I actually explained that and then the team says it's like, "Oh, we're going to do that. " Like, "Why didn't you do that before? " Right?

Well, now for AI, okay. Well, for whatever reason, it's a good practice, so please do it. And the other kind of benefit of writing things down is that it actually aligns not only the agents with your ID, but there is actually a team conversation aligning the humans of what it should be in there.

So, somebody visualizes like this and I like that. Like, you know, had prompt engineering and that was all okay, can we get that better context? And then eventually it was intent engineering.

"Are we there yet? " There's a lot of people ask me. So, I write all my requirements and I kind of, you know, back port my legacy code into requirements and I and I just changed the word uh COBOL to whatever language today.

Done. No, we're not there yet, right? Because there's a planning phase, there's a certain iterative thing like humans do as well.

But it gets the idea across is where we are heading in that space. And so, it can actually also solve a little bit of those loops, right? The better specifications have, if you keep your requirements in your kind of um projects, the AI doesn't go in like multiple loops.

It it forgets less, it actually doesn't hallucinate that much because you have your documentation and all that stuff there. Um it might know of the more recent documentation and versions of stuff um and so on and you you keep kind of more of that context and you know, I encourage you to watch that video of spec driven development. So, pattern number two was figure out like we're going to better at requirements writing.

And then once we've written the requirements, we delegate that and then we are the manager to review that stuff. But what do we know to actually decide what goes into the requirements? Well, that's typically the product owner who says like, "Ah, I've talked to a lot of users.

I think we did some research and kind of that's what we put in there as well. " They love the new vibe coding. Right?

In the past, they had to wait for a couple of days, weeks until they got a developer. Now they're playing with it. And as you're all professional developers, you're like, "Huh, you know, vibe coding.

" You know, they got to learn what they actually want by exploring what they need. It's like exploratory testing, but on requirements. So, it's really helpful for them.

And since this tweet about vibe coding, right? Um by the way, does anybody know where kind of the the word vibe coding comes from? So, in the AI engineering, when people release new models, they're like, "Huh, it it feels better.

It has a good vibe. " And then they transposed this actually to vibe coding as well. So, that's where the word vibe coding But you kind of say, "Oh, you know, the vibe coders, they're like putting things in production.

They don't have to. " Like, I do vibe coding maybe for one or two days and then I actually understand my problem better. That's how I use that.

So, it has a use even if it's not about putting things directly into production. For example, another thing that's really great is I can now ask three variations of the same thing with relatively low cost and I can pick the best one the vibe coding. And so, I'm learning what I actually want.

And if you take that to the extreme, and I found this an interesting example, imagine your end user would be able to vibe code a user interface on top of your kind of actual product to actually build what they actually want. Right? And don't have to wait for you to release it.

I know it's the extreme, but it gets the idea across. There is value in kind of those things and learning from that phase. Now, that kind of parallelism of multiple IDs, um you can do that for the variations.

Like, I I want to have, you know, three layouts of the screen. But I could can also do this like I want you to implement this in three different algorithms. I want you to implement this in Rust, in something else or using that library.

So, variations are also exploratory. So, think of that when you're vibe coding. Now, the other reason to do things more in parallel is obviously multitasking.

Like, I have a backlog of things and I just delegate that to kind of multiple developers. But you understand that that decomposition of you get to do that, you get to do that, we need to separate it a little bit because otherwise you're tripping over the changes and you become like merge conflicts and there's a lot of discussion. But those are kind of two things on exploring things.

And for those who don't know, like one of the very common techniques to have multiple versions of your code base on your same laptop with the agents kind of parallel working is a concept uh using Git work trees. Or if you really like to run everything in a container like me and I I like because I don't trust systems that like like could randomly change things on my whole file systems even if they tell me not to do. This is a kind of an MCP service that allows you to spin up multiple containers, variations, and then it gets merged back uh if you want that to merge in your code base.

And then one thing that I I use myself quite often is I while I'm coding, I'm not just using the Git commit, but I also have used Juju for almost like my local uh versioning and then I pick the best one for the commit. So, I have like multiple commits locally uh and then I only push what I want to my Git on the variation. Now, I mentioned that, you know, here's the big legacy app, change it from whatever language to Rust, I don't know.

That's not going to work. So, you need to do that deep composition and very similar like tools are now emerging like backlog MD that kind of help with the planning mode. They put like acceptance criteria on the different steps and they kind of move that along with your agents.

And then you see a new set of tools emerging which are the orchestrators. Right? Now, I'm not managing one agent, I'm managing a fleet of agents and they're all implementing different stuff to do that.

What's called is one of them. And so, what's useful is that kind of almost like that flow with Devin again, you can say, "Hey, you know, just give me a bunch of options. Come back to me in the morning.

Code as you want. " It's a very convenient way to kind of explore things as well. So, I hope that gave you an idea that we're focusing less on the like the complete delivery because you know, we have good pipelines, I assume, right?

Um but the discovery of IDs on what to build is very valuable to actually bring the money in the bank. Now, the last one is while we're doing all that stuff, we want to capture actually that knowledge, right? Much as we want to do that capturing of knowledge in our companies.

Where does knowledge exist? Documentation? Yeah, maybe I can bring in some files, some Jira tickets.

It's kind of all context that you typically pass along in your coding generation. Maybe I have some other knowledge like, okay, like back stories for agents that I want to have that I want to reuse. Uh okay, that's also knowledge.

Um one things we do is we kind of take open source libraries and convert those into specs. Like, not just the documentation, but the documentation and the code. So, we mix that with examples and bring that in as well as part of the knowledge into your system.

And your your change log and changes on APIs and things like that, they're also feedback, right? That people are bringing in. So, things you can bring into your context as well.

What about your kind of incident responses? Would be ideal if you're not repeating the same problem again in your next project, right? They're all knowledge that is flying around that you can reuse.

And then the more we kind of gather, the more we can actually turn those LLM systems not just about generating code, but us training us as developers or new people and turn those into lessons from all the knowledge that we're gathering. Interestingly enough, Claude Code for those using it now has a learning mode, right? You can ask it questions instead of it generating the code.

So, interesting um evolution there. And then it this brings, do we still need to understand the code, right? What if it's just like the two agents talk gibberish to each other and we don't My argument is you are responsible, right?

They might might might talk to each other in gibberish, but when there's an issue, they have to talk to you in something you understand. So, you still have to understand what good looks like with the tools. And so, what's the motivation for a young person to learn?

A question that comes up a lot. Why do people want to enter the profession if a lot of it's done by the AI? Now, this is usually um told to me by senior people.

The young people, they don't know how to learn anymore. They didn't get all the scars that we have. Let me show you my tattoos of whatever language.

Um the young people just say, "You know what? The agent is always there explaining me things. It's always helping me learn things.

Like you did not have that. You probably had to do 15 years to get good. I have something that helps me all day to get better.

And I can learn faster. So, the jury's out, right? So, it's not that they cannot learn that as we do.

So, reviewing is still a skill in demand. And while a few people said, "Okay, you know, we don't need the reviews anymore. " Right?

Remember we don't need the testers anymore. We need don't need the architects anymore. Reviewing is going to be a skill in demand because you have to understand what good looks like.

And what we don't know is will we have uh smaller teams? Yes and no, because a typical multi-disciplinary team of front end, back end, and I know there's like full stack, but then we need somebody from the data, somebody from the AI, somebody from DevOps, and we don't know. Maybe an AI has a lot, so I can be with a smaller team and smaller groups and get things done faster.

But, you will be only be able to do either by saying, "I understand what it's telling me to do. " and I say, "Yes. " Or I don't know.

I I just say, "Yes. " Right? [laughter] So, probably somewhere in between.

Onboarding new developers that come into the company, really useful, right? The kind of specs and knowledge is there. And so, much like we think about UX learning stuff, you can now think about EX, agentic UX.

And like how can the systems while we're doing our jobs, while we're doing our coding, actually learn? How can they kind of look at the specs is maybe one way that somewhere else a language in between, but there are like various other ways, right? Um for those who are using bun as the kind of npm equivalent, you would see that there is like cloud code equals one, which changes a little bit of the behavior to be optimized to actually for an agent in there.

And then the more we kind of, you know, assimilate all that knowledge, it could be keeping track of all the features that we tried, that we did. I don't know in how many companies anymore, but like a year later, they try the same feature as a year ago because the people left and they think it's a good idea again. So, maybe that can solve some of that.

So, another piece is that that the AI can actually help us save that knowledge while we're doing this. So, while you're asking the chat, this is an example of kind of again Devin, uh they might have been all fake these things, but still the idea is it will ask us while we're asking it to do certain thing, "I think this is important. Should we save this as knowledge?

Yes, let's do it. " So, it's kind of like in the flow. And when something is not correct, it would say, "Well, I based myself on these documentations.

Do you want me to update that that documentation? " So, it's kind of in our flow to save that knowledge. And I've already told you it's not one agent, it's multiple agents.

And multiple agents with different context. And multiple agents being used by multiple people in your company. So, what if they kind of all can learn from there as well.

And then you see concepts like hive coding, swarm coding, they're coming together as a bunch of things. I am absolutely fascinated by the idea, but I'm absolutely scared about reviewing their code. >> [laughter] >> Right?

So, I'm not sure where that's headed. But the knowledge can also be used by agents to help actually humans on their PRs or you forgot this or maybe you should that. So, knowledge has multiple ways.

So, I hope I gave you kind of an overview of different like patterns that are moving with like people who are trying things. It's not to polish things and I I would say the order that I gave it to you is probably also the order of maturity, right? So, yes, that review section is ramping up and requirements and specs is heating up in the space, but then kind of parallelization is just peeking around and knowledge is still far off because we don't know exactly where that is headed in there.

Um I I tried to make a a visual out of that. It was part of a blog post where I say, "Okay, we're managing the intent. That's our our kind of uh backlog that we're doing.

That gets breaking down by one of the agents into planning mode. Ultimately, that gets into parallel coding. Um and then they review kind of and they kind of get merged back.

And then while they're all working, they kind of share things on the knowledge kind of management layer to do that stuff. What's what's fascinating to me is that we're almost building the CICD workflow back on our laptops now, right? Um it's doing stuff Well, it literally it might not be running on your laptop somewhere in the cloud, but it's like the commit is kind of different.

And a lot of people ask me, "Okay, what's the future of DevOps? " and they come with a story about AI ops and observability. And I say, "Okay, that's great uses of AI in that space and you can optimize your CICD workflow.

" But for me, it isn't until this workflow is settled that we're going to see the impact how the other workflow of the CICD will work will change. So, that's why I'm like a more focused on this than kind of seeing like where can we locally optimize the current workflow uh in that space. And then we got into, "Okay, now we have to monitor all those agents.

" Told you, observability is coming. All right? Um tracking what agent one is doing.

Uh somebody actually created like uh put voices to it and he was like listening to the background what the agents were doing. It's like, "Oh, no. Now I need to get to my keyboard.

" Interesting. Like changes in our behavior there. And then we have to rethink what are actually coding metrics.

We don't know anymore, right? It's as easy to generate like so many files. Um is it one of the quality things is the number of like times we have to tell AI that it's wrong is a metric.

All right? So, the number And I know it will say, uh of course I can fix this. Yes, I understand your feedback.

Let me fix that for you. But it is how good we are actually at context management, intent, and then actually the coding tools themselves to do that. Now, there is obviously a few of the kind of analysts and kind of companies in the world that say, "Uh you know what?

I can just copy all the softwares now. I give them all the specs. Here's the existing application.

Crawl it. Use it. Like build me a similar thing.

" The one thing they forget, somebody needs to be responsible. Somebody needs to do the bug changes. Somebody needs to actually see that there's no security.

Like good luck with that. All right? So, I think we're still far off.

It doesn't mean the changes are not interesting and heading in a certain direction. Another way of looking at it is this is a the company booking. com and they're on their AI journey.

And I think the way that I look at that is not like, "Okay, how many how efficient was the AI? " But imagine you had like con continuous testing, right? Continuous delivery of how fast can I kind of actually put something to production?

How fast can I switch a new technology into my stack or a new idea or a new concept? And that's for them that's tech modernization, but it could be product modernization. And kind of how much can we actually kind of deal with that piece?

And maybe that's another more valuable way of looking at like how fast we can like reiterate on our choices with all the knowledge that we've built up while we're doing that. I'm also running conference. It is in New York, but we are live streaming.

Uh but you know, you'll see it loosely aligned to kind of generate, review, learn knowledge in there. So, if that is of interest, um please kind of like have a look and maybe see you in New York. And if you're interested in keeping track of the news, so I also curate some content in the AI native dev.

If you want to play a little bit with the specs driven development with Tesla or you want to watch like all my talks on YouTube. Um you can find me. And if you'd like actually the slides, I know there's a lot of them and a lot of links to pursue, uh send me a message on LinkedIn and I'll happily share the slides to you.

Sure. What about cost? As a developer, do you see like, okay, now we don't pay that much for running different option, different, but is that really sustainable money-wise?

You know, using the AI, whether that's like cost-wise or Yep. Yeah. Um I do see the, you know, in general the LLM costs go down.

Like infrastructural work kind of improve. So, there was a lot of inefficiency like, you know, one GPU could only load one model or it wasn't optimized for certain like um CPU or GPU levels. Uh so, there's been a lot of work done.

Um whether that is actually sustainable, yes or no. That that is something that's really hard to see from the cost of the provider side, which I don't have enough things. But, I do know they're kind of like probably paying through their nose right now, all right?

[snorts] Which is the money bleeding. So, I don't have it yet for the environment bleeding, but there is certain piece in that. But, I think it's for me personally, um you can worry about the security, environmental, and stuff like that.

Um me personally, I like to see where first the functionality is and how we're getting that. And if you nail that, we can actually better judge whether the return on investment is right. But, it you will have to kind of do both right now.

So, probably right now, probably not right now on your question, but it's it's hard to predict. My question is, if we're going to be managing the one that produces code and we have someone that is managing us, what how much overlap you see like who's going to be left with no work in the end, you know? Uh spec it the the thing about the spec it is that you are inputting what they gave to you, Yeah.

so what do you see or how do you see this? Um maybe I extrapolate that a little bit from traditional manager, you know, away from even kind of coding or something. There's a certain attention span that a user or a manager can have.

And I don't mean that they only have their attention span of over a minute to listen to you in the elevator. But, I I think um as the complexity grows of what you're built, they cannot be kind of understanding all the pieces, even though they get access to all the data. And it's a common thing like the CEO cannot keep track and hold all the moving pieces in their head.

So, I think they might have access and maybe they can create a dashboard if they really want to dig in, but in general it will still be like a scaled out uh system to manage that, in my opinion. But, who knows? I don't know if it's so much of a question or maybe just a question for comments or comment from you.

I would say that you talked a lot about jumping from the one who produces to the one who's just reviewing, but I would say that what makes me a very effective reviewer is having a deep understanding of the code, how how it works, the internals, because I've written it, I've written parts of the system. And you said that AI can generate with some ways teach material, but from knowing how we all usually learn, learn about something, it's through doing it, through working on it, repetition. That's why we don't just read books.

So, how do we say what you actually build up if you have like a fully vibe coded or spec coded um application and now have to review a merge request, how do you actually evaluate Yeah. um just beyond just the functional requirements if this is a good solution or not? Correct.

Yeah, so you can do a better review if you've done the job before, you actually understand the job. I think I made a few illusions to it and with the chaos engineering, you still have to train for that, right? So, maybe instead of, you know, doing the coding, we have to invest as a company way more in training people and kind of do side projects or something to keep up to date.

Um we have to uh kind of share that knowledge across uh multiple team members. So, I didn't say that the training will go away. Actually, the opposite.

I believe that whatever we're saving right now in the time coding, we'll probably in the future have to invest in kind of keeping people up to date on what they're doing. Whether that's net a positive sum, I don't know. Yeah.

Yeah, correct. So, but like any new kind of wave is shoveling complexity, right? In some form.

Um you touched on the topic of junior developers using coding agents saying, "Look, the agent tells me that I can learn. " I've used cloud code. In my experience, the cloud code gets stuck often enough or produces stuff that doesn't work that I think my experience and my knowledge helps me um to decide whether that's a good idea or not.

Junior developers, I think, may not have that knowledge or that experience. So, if they use an agent, they cannot they may not be able to tell whether that is a good idea or not. So, do you think that's just a temporary restriction because the coding agents aren't good enough or is that something that will stay Mhm.

with us? Good question. So, I um I experience the way that I express it in the in the industry is as long as we throw enough money at it, it will be solved.

And I make the parallel actually with self-driving cars, >> [snorts] >> right? And in some situations, the self-driving car is a perfect thing, but you kind of have to understand what the limitations are and the constraints that you put it in. And I assume um you know, in DevOps, there was often a narrative, if you have good enough tests and your test hardness is good like your junior can come in, push code on day one, and they will be stopped, right?

So, even though they're experimenting, they will be kind of stopped in that way. If you give them all the access and they're rewriting everything and you have zero tests, that's not what I'm advocating. So, that kind of is still a certain thing.

And and the other piece is coming back to the training and learning and and having them a safe environment. So, but maybe now we actually spend more time mentoring our juniors instead of kind of like do all the stuff. So, again, it's shifting complexity.

I'm not saying this is kind of completely solving and our jobs are irrelevant. I hope I kind of proved the the opposite with the talk. Uh but there is a certain thing about being always available to ask questions.

And maybe you get it wrong, but the other times it did get it right and they did learn something. So, that's about creating a fail-safe uh learning environment for people, I think.