I want to welcome everyone to another DevX event. Thanks, everyone, for coming. Before we start with the main event, I'm just going to give a few thank-yous. I want to thank Dynalink, who sponsored tonight's event. They do VoIP and telecommunications. They've been doing it since 1973, and they work a lot with devs because they do a ton of customization. They have a lot of on-prem and cloud, and they've been working a lot with devs. And I want to thank Ari, if he's here. I don't know if he's here. And everyone should use them if you want to do anything telephonic, telecommunications. And thank you for sponsoring. I want to talk about DevX for a second. So David Genger, he actually works with all the tech companies and employees, like people who are looking for jobs, and also companies looking for employees, and specifically in the tech space. So if you're looking for devs or you're looking for a job, definitely reach out to David. He's amazing. And his blog posts are the best. And since I'm hosting, I get to talk about my company for a second. I work for Omniverse, I'm the CTO here. And we basically build an operating system for doctors who work in nursing homes. So basically we run their entire workflows, but then we also put AI on top. So we run chat, and then filling out notes, and delivering patients to doctors based on rule sets, and all sorts of fun stuff like that. So if you do anything in the nursing home space, happy to talk. And the reason I wanted to host is because AI's been amazing in our workflow. Since the beginning of the year, we've been using Antigravity here like crazy, and it's unbelievably effective. So I really want to know what I'm going to be doing in the next, you know, year or two when it takes my job. Let me talk about Shimon. Shimon has been coding for 10 years, and he's the CTO at PDI, which does imaging — or he can correct me when he gets up. He also teaches new coders at Viewpoint Academy, and he's been doing that for five years now. So he has a lot of experience with new coders, so I'm assuming this topic comes up a lot. So without further ado, welcome Shimon, and we're very excited to hear what you have to say. Thank you for joining. First of all, I'll start with expressing gratitude to the sponsors and the hosts for today, and for David Genger from DevX for arranging this beautiful event. So what I like about this event is it's an opportunity for us to connect, network, and to learn from each other. Today, my presentation is not necessarily a lesson, I'm not preaching anything. I'm trying to open a conversation and share my insights and my opinions. My opinions are changing every day. I'm sure everyone's opinions change every day. So I'm just trying to share how I currently see things. So what I like about the DevX meeting specifically is to find people in my profession, but more importantly, like-minded people. Because I think what's unique about software engineering — I haven't been in any other profession, but I'm assuming — is that software engineering attracts a very particular type of people. It attracts people who have both sides, like the left brain and the right brain. Basically creative people from one end, and on the other end, very structured people. What we do in our life is we take real messy problems. We try to model them into predefined structured data structures, procedures. That's what we used to do. That's what we always do. That's what we're good at. And that's why we have been attracted to this field. For some people, software engineering is a philosophy of life. This is how we see things. We try to model things in life, try to model them into organization and structure. So that's basically the keyword for today: determinism. Computers, machines are by nature and by design deterministic machines, and that's the reason why we use computers. And what we like about computers is that if you design a function, two plus two is always going to be four, no matter how many times you're going to try to run the function again and again. We know that we can predict the results, and that's what we like about our profession. The problem is recently with the new technology, the LLMs that emerged recently, things have drastically changed. What happens is, unless you've been living under a rock, you are aware that Stack Overflow used to be a very popular site for developers. Today it's nothing more than a ghost town. — It was closed as a duplicate. It was closed as a duplicate. Yeah. So before I continue, what I would like to do is I would like to get a feel of the room. You know, everyone has a different level of adaptation with AI. So I would like to ask a few questions and see where we are at. So the first question is, is there anyone in the room here that still writes code by hand, doesn't use any AI at all? Please raise your hand. Thank you. Okay, we have one person. It'll be interesting to talk to you after this talk. — Depends on the product, right. Okay. Second question is, who still uses AI as a chatbot? Meaning do you just go to ChatGPT, Gemini, Claude, whatever it is. You ask a question, it generates code for you, and you copy-paste this code into your code editor. So does anyone do something like that? No one, okay. Oh, you do it that way? — Well, I ask AI what to ask AI. Oh, okay. Well, those AI models are against each other. Okay, third level, does anyone use AI as an autocomplete? Meaning you have, let's say, VS Code, you have installed some sort of agent in your code, and you start typing, and then you let the model autocomplete the code for you. Do you only use it for autocomplete? You raised your hand twice. — You're asking exclusively? Exclusively. — All right, well then the answer is all of the above. Oh, okay. And then next level is who uses an agent in your editor basically, which is a very popular setup. You have your VS Code, or any code editor for that matter, and then you use an extension, be it Claude, be it GitHub Copilot, whatever it is, to just write the code for you, but you're still watching the agent do this code generation in front of your eyes. Is there anyone? Okay, I've seen some hands being raised. Next — actually, I'm not necessarily saying this is the levels, but this is the way I try to organize it. Next question. Who is using Claude in the terminal, or in a desktop application? Or basically, the idea of what I'm trying to say is that you are prompting the model, and you're not seeing it live author the code. You're not really actually reading it authoring the code. But then at the end, you still review every single line of code, either as a pull request review or any other way. Okay. Then the next level is who does all these schemes through the pull request, meaning you're not literally re-reading every single line of code. And the last question is, who doesn't read the code at all? Oh, wow. Okay, that's... My job is secure. Okay. So I think the picture is clear — not very clear, but we see basically that most people are leaning towards the end, to the more progressive side. People adapted AI to one level or the other. Some people still read every single line of code, but I believe there are people who don't read every line of code, skim through, and we definitely saw some people who don't read the code at all. Like, they just literally let the AI generate code and merge the code for us. So what I would like to talk about today is just address the concerns and the ways how we can address everything that comes up together with this new AI adaptation. I'm not going to focus on the setup specifically, or which tools to use. We had, six months ago, a beautiful, amazing presentation by Moisia. And I think the main concepts are still relevant, and the minor concepts keep changing, so it's not relevant what I'm going to add. So what I want to focus on is, in general, how we go about it, and how we see our role. Like the title says, what is our role today with AI when AI changes? So first thing, let me just address the regular concerns. Most people, first thing they think about, is job security. People are worried that once we're going to have AI agents fully autonomously delivering software, they're basically going to be unnecessary. They're not going to be relevant anymore, and that's a legitimate concern. Second is lack of trust, which could mean you don't trust the models that they're going to deliver the quality of software that you expect, or more importantly, you don't trust them that they're going to leak your data or security or anything like that. And the third concern is comfort zone. People typically are used to doing things a particular way. Everyone has had their time. They learned how to do things. And now for years, we have done things one way, and now we have been asked to change completely our daily processes, basically. Everything has to be reevaluated and redone from scratch. And that's really something that could introduce a lot of chaos in a company. Specifically if you have a company that, you know, a lot of team members, you have a way how you do things. If you're going to every day try to adapt to new trends, what's going to happen is you're going to introduce a lot of chaos, and you're not going to have stability, and that is a problem. If you follow the technology news, you'll notice that we have every single day, or every single week, we have new things, new tools, new ideas, new concepts. And if you're going to try to take every single new concept that you learn and try to adapt it to your company, you'll find yourself living in a chaotic world. The fourth concern, and this is the most important one, is like I started, we are by nature people who like structure and organization and predictability. We like deterministic algorithms. We like to write things that we know we can predict, we can reason about. We know that if we write this function, what to expect. Now, if we start using probabilistic models — we have LLM models that by nature are probabilistic. They're very good next token predictors and they're getting better and better, meaning the likelihood that they'll generate good code is being raised by the day, but it's still nothing more than a probabilistic model, and that's not something that works for us as people who like structure and organization. It's something like a completely different profession to an extent. So now we've been asked to adapt, to change completely our way of thinking. We are being asked to change the way we approach the world, and that's a real problem. So I'm going to start by addressing these concerns, not necessarily in the right order. The first thing is job security, which I think the simple answer is that we can predict that there is going to be a higher demand — or there is already a higher demand — for quality software. And the reason is because now that we have these AI tools, and we can do AI-assisted programming, and we can deliver ten times or whatever amount of times faster than before, that allows us to reevaluate solutions that we wouldn't think that we could afford in the past. Let's say a mid-size or small company that in the past would use an off-the-shelf product that doesn't necessarily fit exactly their business model. Today, with AI-assisted programming, they would probably consider building their custom-tailored software, and it would make sense from a business perspective, and they will hire. If you are a freelancer or agency, you will probably most likely get a project after they try Base44 or Lovable, and they give up. The next thing is if you work in a company and there's a lot of technology projects involved. Usually in the past, there's always this project that would probably make the company's process way better, but it was neglected because it was always deprioritized. And now with AI-assisted programming, all of these neglected, hidden projects are coming back, and you're getting way more work than it used to be, and you're becoming way more relevant, or a key developer or key employee in the company. So I would not necessarily be concerned about job security, but what is important is that you need to make sure that you have leverage of using AI. Because if you're going to be a senior engineer but you're not going to use AI, I'm not sure you're going to win the battle against a vibe coder who's going to use AI. As bad as the vibe coder with AI is, it could still be better than you without AI. But instead, what you can do, you can be the senior engineer with AI, and then you're unbeatable. There's no way that the vibe coder is going to be better than you. So your job is actually, in fact, going to be secure if you're going to adapt and you're going to try to use AI. And so this is basically where the market is going, and I'll just share one example. My neighbor and friend Yossi shared with me — he's working for Hearst Media, which is, I guess, a popular, mainstream company, and they recently, and when I say recently, I mean literally this week, they introduced in the company a new application, a new process how they approach software engineering. And the way it works is basically there's a desktop application, and then the product person is going to file a feature request, or it's going to be a bug report or whatever it is. And then there's going to be an agent who's going to pick up that request and file in Jira a technical issue. And then there's going to be another agent implementing it, opening a pull request in GitHub or whatever they use. And then there's going to be another agent who's going to review that pull request and provide feedback, and then iterate again and again. And then finally they're going to deploy the feature on a feature branch, which is basically visible to the product person. And the software engineer is not involved at all in that process. So basically what this means is that we are getting to a point, or the market is going to a place, where we are going to try to get to a point where we have fully autonomous software engineering. The entire life cycle from beginning to end is going to be done by agents. So the question is, where are we as software engineers, how are we relevant for this entire cycle? There's actually two aspects of it when we're talking about AI. One aspect is AI-assisted programming, that I addressed until now, which is we use Claude Code or Codex or whatever you use to basically build deterministic models, to build software. But then there's also another aspect of using AI, which is you implement AI solutions into your software base. In the past, we were only able to solve problems within a certain domain. We could only process structured data. We could only work with predictable tools. Right now, what happens is we have in our toolbox problems that were not solvable before. We can use LLMs. And I'm not referring to actually developing your own model, which is a completely different profession. What I'm saying is you can take advantage of the latest models and integrate with them through API, through traditional HTTP. So basically, what this means is that we're getting divorced from the code. All of us who remember the dark ages when we used to write code by hand, we felt intimate with the code. I mean, most of us, we felt like we know every single line of code. We could sometimes have sleepless nights because one semicolon was missing, and all of this is irrelevant anymore. We basically gave our agent control of the code. And what it means is that once you gave over control, once you gave the agent control — and by design, agents are verbose — they will mess up your code in the sense that you are not going to recognize it anymore. You are not going to feel comfortable with it anymore. The only way to really adapt is if you start thinking of it as like in the past. In the beginning, we used to program computers in machine code. We used to write binary code, and then we came up with assembly, and then we came up with source code or high-level languages, and we came up with, we don't need garbage collection anymore, and that's how we adapted. And now we write in English. So basically what that means is we got to a point where we don't write code anymore in a structured language. We write code in a natural language. And the rationale behind it is because we can make an argument that the latest LLM models are at least as good as a senior software engineer. I wonder who agrees with that argument. Okay, not everyone. And most of the people do not agree with that. — You're asking the wrong crowd. No one wants to admit it. No one wants to admit it. Okay, that's it. So at least this is where the market is going, that we sort of recognize that the latest models, you know, like Fable 5 or whatever you use, are as good as senior engineers, and they are available twenty-four seven. There's no time zone barriers, and it's for a tiny fraction of the cost of a senior engineer. And most importantly, this is minus the attitude and the pushback that a regular senior engineer is going to give you. So then again, the question is, why are we needed? Where is the human and what is our responsibility? If we don't write code, what do we have to do? So the way I see it is, yes, LLM models are as good as senior engineers, but there are four pitfalls with that. First pitfall is there's no pushback. Same reason why we don't like senior engineers, that they push back. So we can fall in love with the LLMs. Whatever you're going to say, you can ask them to keep a session token in the URL. Yes, sure. Why not? Great idea. Whatever you're going to ask them, it's going to do for you. And it's going to come to a point where we're going to miss the senior engineers who used to give you judgment, used to give you attitude for your stupid questions. — Isn't that the job of the adversarial agent? Right. So okay, I'm going to address the pitfalls, and that's one of the things, yeah. So the way to address it is by bringing out the adversarial agent, and just first just going through the pitfalls. Pitfall number two is we're losing the review cycle. So basically the way I see it is, back in the days in 2022, in 2020, let's say you want to do a big refactor in the company. You want to move to a different technology. What used to happen is many people were involved. Ideally, many senior engineers, or just as many people as possible in the technology department. And people think fast. People's thoughts are going at the speed of light, but they don't implement as fast as they think. So what used to happen is that every time you were discussing, even if you didn't want to, every time you were thinking about this change, you were sort of going through in your head everything what you're going to do. And sometimes there are blind spots, hidden flaws, that you wouldn't think about the first time. And the only way you'll find out is just by thinking of it enough times. And the more times you are reviewing and rethinking about what you are about to implement, the higher is the likelihood that you're going to catch this blind spot, this hidden flaw. And sometimes it could just be discovered during a watercooler conversation with someone on the business side. Like, you're discussing what you're working on, and then you find out that they're doing it differently than you thought. Now you're going back to the drawing board, and you start doing everything again. As opposed to today, when we're just Claude-ing something. And just a disclaimer, I'm using Claude, but it obviously refers to every tool, any tool or model that people are using. Today that we are just doing things, even if Claude is as good as a software engineer, but just naturally, because it's going so fast, and because you're just doing it a few times, there's less review cycles. And then there is actually less chance for you to detect a problem that is going to happen. In fact, I actually had last week, we tried to develop blue-green deployment in our company, and basically went through the plan with Claude, how we're going to do it, and everything seemed fine. And then I was pair programming with my colleague, and then we were thinking, "Oh, okay. So we're going to do blue-green deployment. So what does that mean? That means that we're going to have two servers at the same time. Are we sure? Can we be sure that we're not going to have two servers doing the same background work at the same time?" And then we had to ask Claude about it, and Claude went, "Oh, yeah, you're right about it." But if you would not think about it, you'd probably have a huge mess-up in the company. You would have a lot of race conditions or duplicate work. I guess Claude was assuming that we don't have any background work, whether we're using pub/sub or whatever it is. But that's not always the case. And this is one of the pitfalls of using LLMs, is that you have way less chances to catch things that you would catch before. Pitfall number three, and that's a business problem, is the proof of concept trap. What happens very often is that you're being presented with a problem, I guess by stakeholders, by business people, and you just can Claude it. Within two hours you can create a proof of concept. You can create an artifact and send it to the requester. And then it's going to take you a nice amount of time until you actually implement it. Sometimes even non-technical people or semi-technical people in the organization are comfortable enough to use Claude Code and plain English and they're going to develop a nice application. It just needs a few touch-ups, and you're going to have to deal with it the next few months. There'll be "just a few touch-ups" and everyone's going to be frustrated. Why does it take so long? And the truth is that this was always a problem. It's called a last mile problem, but it's not like it used to be in the past. It used to happen, let's say you wanted to develop a project. You would start the first, let's say, year until you had a proof of concept or MVP. And then the next year, the last twenty percent or the last ten percent, you're going to spend another year perfecting. Today, with the new way how we do things, within two hours you can have a proof of concept, but then the last three months you're going to deal with the last mile. The truth is that it's still faster than it used to be. Even after the touch-ups, it's still faster. But the frustration, the expectation is way higher. The baseline, what we expect today from software, has been raised already. There was like an aha moment for me a few — it was like a month ago. I was asked by my neighbor to do something. He works for a company, he asked me, "Can you build me this app?" And obviously, in the past, I would politely reject. I don't have the capacity for that. But now that I have agents working for me, so I was thinking, "Okay, that's a good opportunity to test how far we can go." And I took the challenge. And after a day or two, without affecting my full-time job, I just came to him, and I was actually very impressed with the results. It was still a proof of concept, but I was actually very impressed. And I showed it to him, and he was like, "Can you make it look less vibe-coded?" And I was very disappointed because really I did not invest much time. I'm not a UI person, so I just let the UI stay the default, which looked very vibe-coded. But that was the realization for me, that the market and the regular non-technical people have high expectations now. You know, you can't impress them anymore with nice working functional software. You need to come up with way more than that. So basically, that's what happened. And in a sense, you can say that it doesn't necessarily translate for us that we can get higher salaries, or, even if you're not freelance, you can ask more for your products. But this is the reality. The reality on the ground is the market already priced in all of the advances, or most of it, with AI, so that now the expectation from you is to actually deliver faster and better results. Pitfall number four is the tendency to over-engineer. That's a very common thing with LLMs. By design, they are very verbose, and maybe because of the system prompts or the way the models are trained. And what happens is usually you're going to present them a problem, and they will try to over-engineer. I'm not talking about the insane amount of comments they're going to add to the code, but even just that they're going to try to cover edge cases and cases that are never really technically needed. And as we know, every line of code is a liability. And when you have a model writing unnecessary lines of code for you, you're basically introducing liability to your code base. So knowing these four pitfalls, this is where we as software engineers, this is where we come in. This is our time to shine. This is our relevance in the equation. We need to address these problems. First problem, like we mentioned, like Yossi said, in order to make sure that we're not dealing with a yes-man, we need to always hire an adversarial agent, basically, that you have another agent to review the code. And typically, as people say — I haven't tested it — you should use a different model. You shouldn't use the same model that does the code generation and the model that does the review. And most importantly, you have to make sure that you're introducing deterministic tools to the code base, basically. This is what we call a harness. Basically, to make sure that we're not relying on the LLM reasoning or the probabilistic models. We're relying on actual tests, type checking, permissions, monitoring, profiling, and all of this good stuff. In the past, it was very difficult to do it yourself. But now that you have AI, you can use AI for that as well. You can use AI to generate all of these tests. And when I say tests, I mean unit tests, integration tests, and end-to-end testing, all of those things. — You read the tests? Not only do you read the tests, some would say even you have to write the tests. So some would say that now the test is the most important part of your code base. I'll get back to it in a minute. — Then you just move the bottleneck of the company. If you write the test, then you become the bottleneck. I'm not saying you. You write the test descriptions, maybe. We'll get there. — If you're writing the code and you write the test, it's going to find the exact edge case to make the test pass. No, you let it make it pass. — So it will never make it pass. Yeah. So I'll talk about it in a moment. But first of all, the pushback. Like I said, if the model is not going to argue with you, you just have to appoint someone that will, and obviously, you're going to place a review agent. Every platform has a different way of doing it, different terminology for it, but the concept exists. And the truth is, it's not only about reviewing particular pull requests. Generally speaking, every release cycle, which today is basically every few hours maybe, you want to have an agent going through your code and trying to find code smells, trying to find things that don't make sense. But the most important part is you want to introduce deterministic tools. And what I mean by that is because, like I said, where we shine and our skills is deterministic tools. What we want to do, we make sure that every single LLM-generated line of code is tested. So type checking, obviously — even if you are using a dynamically typed language, now with AI, I think it's more useful, more safe to use a typed language. But more importantly, the tests, schemas, validations, and all of those things. Basically, your job is to make sure that you minimize the probabilistic nature of your code base, and you introduce as many deterministic tools as possible, and you want to verify everything. And when I say verify, I don't mean like reading the code, because we said, like, many people here are not actually reading the code. And reading the code is not — you're not guaranteed by reading the code that you're actually going to catch the bugs. Instead, what you're trying to do is make sure that you have checks and every single check passes, obviously. So basically, in short, you maximize deterministic, you minimize probabilistic, and you're trying to have as many checks as possible. And this is also relevant not only when it comes to building with AI. Same thing is when it comes to solving problems with AI. When you're trying to implement AI solutions into your software, there's a classic problem everyone knows, is the models — when you used to ask the models how many R's are in "strawberry," they were struggling with it. Today, they're better, but it doesn't really matter. The point is that you don't really ask an LLM model how many R's are in "strawberry." You can ask an LLM model to generate a formula for you that will count how many R's are in "strawberry." Because this is really what they're good at, and this is something you can actually measure. You can test it as many times as you want and see if it's actually checking out. So next is identify your bottlenecks. Because we're having this issue that we're moving so fast and code generation happens so fast, so everything in and around it is becoming basically a bottleneck. Like Yossi said, let's say writing tests could be a bottleneck. Release schedules could be a bottleneck, so we just solved it by doing blue-green deployment, which is obviously a good design. It was always a good design to have, but now more important than ever. Sometimes QA could be a bottleneck. But product design and all of those kinds of things — we're trying to identify the bottlenecks and see how you can streamline it, how you can make it keep up to the pace of the new development, the new speed. So basically bottom line, what you want to do is you want to minimize the probabilistic and you want to focus on testing. And when I say focus on testing, like I said, unit testing, integration testing, end-to-end testing. And one important thing to know is that a hundred percent coverage still doesn't mean that you are safe, because coverage only means that you actually covered every single line of code, but you don't know if you actually tested for every possible case. So therefore, you want to make sure that every bug that is being reported, you add a regression test. Even if those lines of code were actually already tested, you want to make sure that by fixing the bug, you are actually fixing it. So typically, I've seen Claude doing it by itself. They will create a test, apply a fix, try to run the test without the fix, make sure that the test fails, and then bring back the fix and make sure that the test passes, which is typical test-driven development. But now it's more important than it was ever. And you want to put this instruction in your agent instructions file, whatever file you're using, because you want to make sure that this is never being ignored. But then one thing to be aware about testing is there's a concept, overfitting, which is borrowed from machine learning. When you basically overfit the model to fit a particular constraint, a particular sample. To borrow it, in our case, when we're talking about software engineering, sometimes what can happen, if you're not really careful about the tests and you don't read the tests — even if you read the test descriptions, you don't read the test expectations — what could happen many times is that the agent is going to adjust the code to make sure that the test passes, and then you don't get anything because it doesn't actually address the intent of the test. It's just going to address, just make sure that they pass. Just to take a very simple example, let's say you have transactions and your intent is to make sure that every transaction that is less than zero, any negative transaction, let's say negative forty-five, should be counted as zero in the total, let's say, for whatever reason. And then you're adding tests for it, and then you create a particular test case for a transaction that is negative forty-five, and you check if it's actually counted as zero, and then the test is going to fail. But what the agent is going to do, is going to — maybe it's not optimal, but just to simplify it — it's going to write: if the transaction amount is negative forty-five, then it's going to be counted as zero. And obviously that wasn't your intent. So this is a simple example of overfitting, but you can apply it to more complex systems. But the idea is that you cannot trust the test blindly. You need to make sure that the intent of your test is actually being honored by the LLM. The next thing is security, which obviously was always a thing. As a software engineer, we're not security experts, but we always have to be aware about security. But now more than ever, it's relevant because the people on the offense, the hackers, actually have all the tools. They have the advantage. They have the leverage of using AI tools to hack. And if you had a system that you could afford in the past to have some vulnerabilities there, and you were not worried about it, now you have to worry more than in the past. And the good news is that you can use the same leverage. You can use the AI tools to address all vulnerabilities and security. And also, obviously, you want to expose the LLM to the context. You want to make sure — this goes without saying — your LLM has access to your code base, your knowledge base, your documentation. You want to have your documentation maintained as much as possible. Actually, this is almost like your source of truth. Some would say that the DRY principle does not apply to code anymore, but it applies to documentation. This is where you document the patterns, and this is where the agent is typically going to look for future implementations. — How do I explain to a client...? Let them fail and they'll pay you. So like I said, they'll come to you after trying Lovable and Base44. It's going to take them a few months or whatever time, they'll come to you then. Someone here shared before, they basically are a freelancer and he has a client that realized they can bypass the developer now. And instead of asking the developer to write him a report, he's going to ask Claude, and Claude told them a good idea: you can just create a user in MongoDB — you have MongoDB on the cloud, I guess — you can just create a read-only user, I think, I hope Claude told them that, and I will help you generate reports. So why do you have to pay whatever the hourly rate that you want to pay for the developer? So he decided, "Okay, good idea. Let me just do that." And he went to MongoDB, logged in, and he saw that there is already a user, so why do I have to create a new user? But the problem is he didn't know the password for that user. So he decided, "Let me reset the password for that user." What happened is that obviously, that user was used by the system, by the server itself, and the server crashed. And we're talking about a company that had, like, every hour, thousands of transactions, so he lost tens of thousands of dollars by trying to bypass a software engineer. So that was a good lesson. Hopefully, there are more like that. But the idea is that people think that they can bypass us, and we can let them fail, we can let them try. But back to the main point is that now your job is to steer it. And what it means, basically, you've been promoted from being a software engineer, you're now an engineering director. It means that you have now your agents, they are your software engineers. And what it means for the companies is that projects that you used to have a team of five people doing, now you have only one or maximum two people doing it, because they basically are the directors, and they have their agents working for them. And lastly, we're talking about the comfort zone. People are getting very stressed nowadays. Every day we learn new trends, and everyone thinks they need to know the latest thing. Take one step at a time. Don't think that you have to move as fast as technology. Technology moves fast, but humans don't move as fast. So you don't have to move to the next step until you're fully comfortable with the current step. I've seen on Twitter, lately known as X, that someone posted, he was very proud about a Claude setup, that he has sub-agents and multi-agents and whatever, and he was sharing his setup basically, and then someone replied, "Oh, really? This is so June 2026." And now it's September 2026. So we're getting to a point where people feel like every month makes a huge difference. But we're human, and we have to just go with the pace that we're comfortable with, and we're in it together. Thank you everyone for listening. Thank you to Yossi for sharing your experience, and to my colleagues at PDI and Viewpoint for helping me. Questions, feedback, comments? — Do you have any tips on designing adversarial workflows? So you're asking if I have any tips. To be honest, I don't believe in secret prompts. There are people who believe that if you add "please" before a prompt, or "I make no mistakes" at the end, you're getting better results. I don't believe in that. Let's say GitHub, when you go to GitHub, they give you the option to review. They give you the option to add a prompt. I typically leave it empty. That's my opinion. Whatever generic prompt you could give is already in the system design of GitHub, and I trust that. That's my opinion, but maybe some people disagree. — I say please to AI so when they take over, they remember me. Yeah, I've heard about that. Anyone else? — Somewhat on topic, you said you were also a teacher. How are you still teaching fundamentals? Oh, that's a very good question. Yeah, so we teach at Viewpoint Academy. We have new people joining the industry, and it is actually a challenge. It's something that we had to completely redesign our curriculum. But basically, the way how we decided to approach it is the first ten sessions we are teaching them as if AI does not exist, because we want them to get a feeling of how deterministic tools work, how syntax matters, how every single semicolon or character can make a drastic difference in the results. So that's what we did. But we also believe that in reality, the students are not going to write code by hand, and they need to have a broader — because like I said, they're becoming directors more than software engineers, so they need to have a broader understanding of technology than we used to have. Like in the past, it was enough if you know a programming language. You could just do a pull request, and your job is done. I believe today if you do just that, you're not good enough. So you need to know infrastructure, you need to know DevOps, you need to know everything around and everything a little bit. I think that has changed. — You need to know it, or you need to know how to direct AI to use it? So the way I see it is the only reason why you know what to ask is because you have had experiences in the past. — But what do you ask if you don't know what to ask? You know the concepts. — I don't know what a CNAME is. Do I have to know what a CNAME is? You don't have to know what a CNAME is, but you need to know what DNS is. — But to get a concept, you can also ask the AI. What's a CNAME? So that's what I'm saying. You have to be more horizontal than vertical. Like you need to know what DNS is, for example. You don't have to know CNAME to do that. But if in the past you could get away without knowing about DNS at all, you could be an engineer and just write code — this is probably something that's not going to work anymore. — They are pretty good teachers as well. Why do you think you're a better teacher than them? Why am I a better teacher than whom? Like I said, because they're not pushing back. So if you're going to ask them a stupid thing, they'll do it. — No, all the students from Viewpoint, why can't they ask the AI everything that you teach them? That question you could ask even before LLMs. You could ask why can't they just go online and listen to CS50? It wasn't the same. I think the reason why people learn in college is not because they are coming for knowledge. I think the reason they come is for structure and for organization. They're coming to get, you know, everything else. They're not coming for the knowledge itself. Knowledge is free today. It was always, even before LLMs, everything is available online. But you're coming for the actual curriculum and instructions and everything. — Thanks for the talk. I'm wondering, let's say your junior comes to you, you're the CTO, right? And they're like, "Something broke." And you're like, "Why did you write this?" And they're like, "I have no idea. The AI did it." What do you do now? Do you fire them on the spot? No, I don't fire. But I actually think that, like I think it was in the presentation somewhere, that you're not responsible for code anymore. — How is that possible? But the question is how did you test it and not catch it? — What test? They don't know what it does. They have no idea what it says. They can't even tell you what it says. What's the goal? Do they know the goal? — They know. They say, "The AI wrote it." — How did you hire this person? That's what I'm asking. So like I said, you're not responsible for the code. — What do you do when you have to hire someone like that? So again, if people adopted a new way of how we do things, they're not responsible for code anymore, but they're still responsible for the performance of the software, and they're just using different tools for that. And the tools are not writing code anymore.