DЕV.ВG Community Day 2025

Ще еволюираме или ще изчезнем: Кариерно развитие за програмисти в ерата на AI? | Николай Стоицев

53:31 · 21 Jun 2025 · YouTube

About this talk

In this talk, the speaker discusses the evolution of stock exchanges, highlighting the transition from Open Out Cry systems to algorithmic trading. This shift, prompted by technology regulations and the rise of algorithmic trading in the early 2000s, dramatically changed the trading landscape, leading to fewer human brokers on the trading floor. The speaker then relates this evolution to the current state of software development, emphasizing the growing importance of tools like GitHub Copilot and Cursor that leverage AI to enhance programming practices. The discussion covers how developers can effectively use AI tools by understanding their principles, including language models and prompt engineering, to optimize their workflow and productivity. The speaker warns against over-reliance on AI, stressing the need for foundational knowledge and critical thinking in programming, while contemplating the future demand for software professionals as AI tools become prevalent.

Full transcript

Hello everyone. Will we evolve or will we disappear? That's what I want to talk about today. If you have any questions, this is the QR code. You can scan it so you can write them into the system and we 'll go over them again at the end. I'll let the slide sit for a little longer. And what I want to start with is a story about stock

exchanges. And this is the New York Stock Exchange. This photo was taken in 1986, 84, something like that. And as you can see, there are a lot of people who have some kind of computers. There are some computers there, but the main way that transactions happened was a system called Open Out Cry, which means shouting. You see something and call the relevant broker to execute the deal.

You're talking about so many shares at that price. Yelling is not very effective because it gets very noisy. And at some point, people invented a system of signs, with fingers. How can they communicate like that from a distance, and it's very noisy because there are thousands of people shouting at each other. So they made the deals with fingers, signs, and and they wore different jackets, they were

different, you know, they all wore suits, but on top of the suits they had different jackets, orange, yellow, that indicated something, and the broker knows that if someone with a red jacket makes a sign, it's more important than if someone without a jacket makes that sign. They basically have some priority. And then you imagine how trade happens in such a hall full of thousands of people shouting,

pointing fingers, looking at each other and understanding each other's emotions. You see that the other person from the other company is afraid of making any kind of deal. That tells you something. You see that some other group is panicking and you remember that this morning they took such and such a long position, they opened it. So, I don't want to keep this long position, something's going to

happen to it, I'll go see. You talk to people, you understand who has more tolerance for risk, who has less tolerance for risk. I sounded like the kind of profession that is very connected to people, very connected to critical judgment. You have to have a lot of domain knowledge about, right, how the exchange itself works , each group of people, what they do, what they specialize in.

It sounds like something that is very difficult to automate and back then people thought that yes, there's not that much human interaction between people there, so much intuition, so much knowledge you have to have about how the market works, how it has moved before, that computers can't possibly handle this situation. I will always have that profession. And a little later, this is what the stock exchange looks

like. There are still people, they are much fewer, looking at computers, working with computers. No one is shouting across the hall for someone to place an order. I want 100 shares of so-and-so, right? Quiet, it's quieter. And people are still talking, but less. And it's not so important that they know each other, look at computers and work with computers. And overall, it's quite a big change. And

if we look at what this is due to, not only the introduction of computers themselves, but also the fact that in the 90s the United States introduced regulations that say how electronic orders can be placed, then they started creating software and in the early 2000s algorithmic trading began to be imposed and little by little, little by little. You see, from 2003 onwards, in the beginning it was

15% of all trades were algorithmic trading and little by little, little by little. Despite people's belief that this industry is very human, communication, context, decisions have to be made very quickly, and it requires critical thinking. However, right, the further we go in time, the greater the percentage of trades become algorithmic trading. Clicked are transactions in which an algorithm makes a decision, not a human being who is

somehow involved. And eventually, this became the most common way to trade, and that's why exchanges look different today . And when this transition began, this transition from Open Out Cry to computers, then to algorithmic trading, there were people who felt it earlier. And you said, okay, computers will obviously start to enter, then algorithms will obviously start to enter, and they understood financial auctions, financial markets, they learned

C++ programming, and they were at the foundation of these large companies that are not involved in trading. There were some people who profiled themselves, they told me okay, the whole market will obviously be taken over, but for now, the bonds, the computer doesn't handle bonds well. I'm going to specialize and be a Bond trader. Are there other people who started working in companies that dealt with algorithmic

trading? They became analysts, programmers, portfolio managers, and because they had connections with people who wanted to invest, that's another thing. But a large portion of people have found themselves having to find another profession, a completely different profession outside of finance, and something else to do. And nowadays, something similar seems to be happening in our industry, and this is the Stock Overflow Survey from 2014, end of December

. Do we use it in the development process? As you can see here, I think 60,000 people responded. 61% say yes and 13% say no, but I will start using it. If we do this survey now, there will probably be even more. That is, we are all starting to use these tools and they are changing the way we work. And what do I mean by these tools?

The main things that when I say tools in the context of programming, I'm basically talking about these three things, because there are a variety of GitHub Cops Wind Surf. And how many of you use some of these tools? Okay. And for the others, we'll do a little intro about what each of them does. Git po copil was the first tool that became so popular in the beginning.

He was doing a very clever competition. That's how it started. It was doing auto complete, but it was very smart. All functions were autocompleted. You could write a comment about what you want the function to do and it would automatically generate it for you. You want to write something and it finishes the line for you, right? In the beginning, that's how collate started and it was the

first thing that was more noticed as something that shook the market. There's a chat on the side where you can write some things, but even when you start writing code, it still starts offering you some things. And how many of you use Kopai? We raise it like this. Great. Quite a few people. And that's how it started, right now it's on par with, right, it's still one

of the leading tools, and it's recently become open source and is also a plugin that we can install to different ideas. For example, Eclipse, I think, recently released a plugin, and Jetbra products, I think, have plugins, and it's quite a plugin, but a pretty well-implemented plugin, and accordingly, a system for working with agents, for writing code. And the next thing, the next tool that I'm talking about

when I talk about tools, is a cursor. How many of you use a cursor? Okay, more or less. a little less than flexible they fall. And it seems to be the tool that is most needed for programmers to work with agents, right, for programming as an interface, you see that it is the same. On the side you have chat, and you can still write and compile, but

chat is basically the main thing that people usually work with. And then again, there are agents in it, you can tell him to do some complex task, he plans it, breaks it down into tasks, and carries it out. Oh, and the third, third, third tool I want to mention is Windsurf. Does anyone use Windsurf? I think only one person. Okay. And Winsor is the most pioneering. At

first they said we are just agents, agent first development, and the others, I think they saw the trend and started moving in that direction, too. Unsurf is a company that is currently rumored to be acquired by Open AI, which means it will be one of the leading players in the market and is generally quite pioneering. In general, it started with, right, so this whole approach with agents

became more necessary, with leaving, development environment to do something on its own. And yes, in general, as you can see, I'm not going into how the systems themselves work . I'm not telling you, there are such features here, there are such features there, because in January, when I wrote my proposal for the conference and that was one of the things I thought I would tell you about,

what are the different features, because it would be useful to people and so I said okay and I did it, I had written out the lecture and usually it is written out first so that I can make an abstract, right, the description and then so that I can give it to the conference organizers as a proposal. I had scheduled the lecture , but in February everyone started

getting agents. I had to scrap everything and rewrite it again and I would tell you about agents and how cool they are. Then came March, the context protocol model became very popular and I scratched everything again and said to myself no, I'm going to talk about the context protocol model and multi-agent orchestration, because right now it's a trend. This is what happens. This was March, April, and

this was the moment when I said to myself, "Okay, I guess I should wait until June because there's no point in redoing it every time." And in May-June, there were things that became open source. Many companies have released in-house models that where cursor and win have released in-house models that do various interesting things. There are already background agents that, without you doing anything, change the code themselves.

And yesterday, for example, Cursor released a very cool integration with Varnish. I don't know if it was yesterday. I clicked on it yesterday, but yes, they released it recently , where it happens to you that sometimes you ask someone, your colleagues at SLK, you see some code and say: "Well, do you think this code should work like this?" And someone says: "Well, no, it shouldn't work like

that. This is a bug or something, we should have refactored this, but we didn't get around to it." And there you can say flowerpot cursor, make a request for this thing. And in the background, right, it does it on request and says, here you go , I'm doing it on request. So background agents and this field in general is developing very quickly. There are constantly some big

leaps forward and I was like, okay, I clearly shouldn't talk about features, because if I tell something now, next month something else will be the move. And that 's why I decided okay, we need to talk about principles. The environment itself is moving so fast that we should rather And yes, overall people are enjoying this GitHub survey, right? How do you feel about these agents? 23% say

it's great, they really enjoy it. 48% enjoy all the work with the AI tools that exist. And in general, we programmers like them and they make us better, and Google did a study that showed how long it takes for an AI task to close. Below is without AI. Google has launched, right? I can do such AB tests, because they have many teams, right? 30, 40, I don't

know how many thousand engineers work there. It could be hundreds of thousands. And they can do an experiment and measure. Apparently, we programmers enjoy them and they help us with our work. Apparently they help us do our tasks faster, our work faster. Ah, but how do we use these agents effectively? What are the principles behind it that we can take to enjoy it and help us do

our tasks more easily, and what are the things that when thinking about career development we should keep in mind, learn or pay attention to? So how can we use them effectively? That's it. If they help us and we enjoy them, obviously in order to develop well, we need to teach them to use these tools well. And the first is that we need to learn the basics of

LMs, of the big language models. We need to know what a token is, because it is a very common term. A token is a piece of text. The text is not broken down into words, it is broken down into tokens because there is a word root. Then you have, for example, a plural preposition. Not one word that is broken into two words with a hyphen. Well, tokens

aren't exactly words, but parts We need to know what a context window is as a term, that it is information that we can insert into an LM and it can work with it. We need to know that outputs, as stated in the APIs, are not facts. They are simple. Every time you ask LM something, it gives you back a few sample answers. It doesn't give you a

few facts. And we need to know what Retrieval Augmented generation is. The first lecture of the day, I imagine, paid a lot of attention to this, but this is the main approach that currently makes AI tools work. You write some kind of prompt, for example, I want to implement this feature in the background, and it finds relevant values ​​that need to be changed or that are somehow

semantically related to what you are asking. And what it gives to the LM is, it says, "Here's what the person asked. Here are the files. Here are some other things I found that might be relevant to get my work done. And what we ask is reasoned with all this context that the idea has brought out and gives to the LЛM, so that it can do its job.

This is the main tool, the main principle that makes these tools work and we need to be well acquainted with it. And besides it, there are other interesting moments like memory, shortterm memory, longterm memory, but again, these are part of this model. And what we need to know is that the whole thing comes down to prompts and context. What is in the context and what should we

give to the L- as prompts? How detailed should they be, how high-level should they be, should they make the agent do something, should they not do it? What context should we give it? We'll let the idea collect the files, so what files are collected or we will give context when we ask something and will there be additional information inside the project? All of this is something that

we have to think about, that we have to get used to. Writing prompts, thinking about context, right, is basically one of the basic things that we have to develop as programmers. It is very important that we give constraints to the LMs, because when we give them some constraints, they are much better directed towards the way in which we do not want to solve the problem and give

very good results. Because what we need to know about LMs is that they generate the most likely text. The most likely text is the one that occurs most often. And what they give us back is what they have most likely, most often seen in their training set, which may not be what we need. We need it in this direction or in that direction, it is not in

the general direction and we need to do exactly this guidance. How do we do it? By giving it by giving it information inside the prompts or the ideas themselves have mechanisms that we can give rules. So something happened with the screen to give And we can say use this framework, for example in the example here. Use fast API. We will write in Python. Use fast API. We

can give code standards. I want you to follow this or that pep standard or I want you to use this or that stal guard or something like that or the other way. I want there to always be dog strings. I want there to be no dog strings and yes there to be comments. If there are no comments, we have to give some standards for the code. It's

good to give some architectural patterns. For example, whenever we make a request externally, we put retry. So we have exponential backof. And every table in the database must have a column for multi-tenses, for example, and every request must read this multi-tenses parameter and work with it, right? We have to give such architectural patterns that we want it to follow, that are characteristic of our project. And we

have to tell it specifically how we want it to do what we want it to do with the errors. For example, log them everywhere, log them with this library, don't log them or just print them to standard output. And, there's a whole section here about handling in the example and we can tell it usability, put metrics everywhere, put a decorator like this in every function, all the

things that are important to us, we have to tell it. Feature flags, every feature should have a flag. In general, every such context that we give to LM, it gets closer to writing code that works in our environment according to our quality standards, and our ecosystem that we have. And we also have to understand that 100 100% of the work 100% of the work was writing prompts

and context, 100% of the work is reviewing the code and validation. And, LM generates something for us, generates a lot of code for us, but we still have to read it, understand it, validate it. And the thing that agents do right now is test the code and if we write some simple script, it will say I wrote it, now I'll try it, maybe I'll try it. You

click on it to try it, it tries it, then it checks. I want to execute this command, to check the thing. We click on it to check it. When it's a larger web application it's more difficult. When it's a larger backend server that communicates with other servers it's more difficult. Now we have to do the validation in different ways and think about what LM didn't think of.

And we can tell it to add some tests, we can test things by hand , but it's not so much writing code, understanding it, reviewing and validating it and decomposing it. It's quite important. And to decompose things into smaller tasks. Right now this is necessary because of the context. As the previous lecturer said, 30 000 symbols, 30,000 tokens, that's how big the context is. When it gets

full, it starts to make up, it forgets some things, it starts to make up some things and we have to start over. So it's better to break it down, and to plan it. We say, "Okay, this is your assignment. How will you understand it in episodes, how will you understand it in tasks, each task some kind of prompt, what context will you need for it, what kind

of prompt will it be . And we do this initially so that we can plan our work. Here we can say that we can [ __ ] it up, as they say, right? We tell it to make me a system like this and it starts making this system and I don't know if you've tried it, but as programmers we know how software should work and when we

start writing ads, we write a lot of ads and sometimes it starts doing something and at some point it runs out of context and the coding dies. Many people who are into programming say, "It doesn't work." Yes, it doesn't work because you know what you want very well. You get annoyed that he doesn't read your mind and doesn't do that. You know very well what you need

to write and you get doesn't write it the way you would have written it, but on the face of it he writes it very quickly and breaks it down into tasks and then you try, right? And we have to think about this, right? As people who understand how software is made, how software is validated and how it is tested, the work is no longer so much about

code as about product management, right? Let's write a requirements document and then decompose it into tasks, prompts and start executing the prompts, validate the results of what the LM generates for us and see how they work. And the goal is to build intuition. There are some things that mites can do and some things they can't. And this intuition is characteristic of your environment in which you work

and the software you make. But if you do a lot of CRM software, the Llite training included a lot of code that was on CRM software and it works in one way. It's a way to fix LM, but for example, I'm part of Storp, at Storp we're building a distributed backend storage infrastructure, such a large distributed system, and an architecture that scales can process petabytes of data.

LM hasn't seen much software like this. It works on its own, it works very closely with the hardware. And 84% of the time the whole system works. As fast as physics can work, the whole system works. But he would n't have handled it in a completely different way. You will be successful at some things, you will not be successful at others. And here we are talking about,

it doesn't matter which model, there is just so much software, which topic this software can read much more CRM software than Distributed System storage software. And in one way we need to have one intuition, in the other software we need to have another intuition. And we may have very strict security requirements. To say our security records are nothing to do with them. They can't fix it, can

they? I've talked to people. Yes, maybe it is, but if you give the right rules, you still have to have intuition. That part of it won't happen because of who you are, but the other part might . We build this intuition by trying, trying, it doesn't work, trying, it does n't work and trying, more or less it works and we build with intuition and we need to

know that it's okay to leave the programming environment, we're programmers, we work with ideas, but just like we use Google, just like we use Stack Overflow, there are other such modern ways that replace this part of the work. And Perplex, for example, is very useful. That search engine, which when you ask it questions, reads you many pages, I give it to you. And the first one is

a more widespread product that does this thing and does a good job when we ask it for some architectural solutions. It won't work as well if we tell it what's wrong with this code, but rather what frameworks I can use to do this. And how can I implement this architectural pattern? And this is my code. What kind of a way can I do this? And it will

read many pages, it will gather information for you right now, it can gather information from scientific articles, it can gather information from social networks and financial data. Financial data isn't that interesting to us, but you say, "Use social networks, use newspapers, and you choose the information." And Google has a similar product with Gemini. deep research, where we go into domains, we can click deep research, it does

the same thing, but in a different way, and you still have to try both and know when one works for you, when the other works for you. And there are some cases where we need to do something with the LMs, but it's very sensitive. Then we have OAM, which allows us, right, to run models locally on the machine, which are not very large, but they work, and

for some we want to do some analysis on some more sensitive things, to know how we will do it in the software or in some way it will affect our decision, and you just need to know that there is also this option to run a large language model locally and work with it. And there is a very cool project that we, as programmers, will really enjoy. This

is a prompt. And when we tell LM to do such a refactoring for me, it chooses the files itself, it chooses the context itself. But we understand programming, we understand how to make software. We want to know what's in your context, and what we're doing is putting it together by hand, right? Here, we give an error which files we want to include inside and we click which

folders we want and it tells us how many tokens there are. And you'll see that if you click on the project folder, it will tell you this is much more than 30,000 tokens and you can't put the whole sauce in one prompt. But you write the prompt, you choose exactly the files you want. You can take this example, drop it into your own idea or drop it

into some other LM to ask how to do the corresponding thing or how to solve a bug or how best to do some refactoring or it helps you. Repomp helps us collect context by hand. He tells us which files to put, he takes them, he gives us a prompt. We can then copy it very easily So, in general, right, but when we learn to work the slams

well, the work becomes much different. Challenging in another way, it's not as heavily coded and remembering in which library a method was called is different. And there are several ways in which our work becomes more enjoyable and in which AI tools make us better And the first is that we get into flow very easily . Flow is the state we are in. It 's not at all,

right, time goes by very quickly. We can sit and work, right, concentratedly for hours. The clock is ticking, we don't pay any attention. We work concentratedly, focusedly. The tools help us get into this flow much more easily, because there's no interruption like, "What was this method called?" Hey, where in the code was this thing? And how was this done in the language? I remember that in the

language I could do something like this , but how exactly was it done, right? It's precisely these moments that diminish them. And there are many others, right? We can think of many other things that are towards solving the problem, but not so much how to solve it. This is how we get into the low. It's faster to write code. The sheer amount of code we can produce

is much greater. And if we work with some technology that we are not very familiar with, it helps us. And for example, I have n't written functions in Excel in months. I always ask you to write me this function. I take the function and put it in. And if you don't know a technology, for example, but practices for one for one tool, and he decided to do

it with no, I haven't written in React for six years, I'm sure, and there was no problem, right? Okay, it gives some code there, I more or less understand it. I've written to RК before, I know what the principles are. Now I don't know the story of the last six years, but I got better. A generally unknown technology, but I solved my problem. And the other thing

that you allow us to do is we can prototype very quickly and we can experiment very quickly. In many companies, there is this trend where pro designers no longer make mockups in Figma that we can click on, but instead make software that is separate, doesn't use, isn't part of the project's codebase, but is working HTML CSS that we can click on and show exactly what patterns we

want to use. And this can be done by people who are not that much of a programmer. And it can be much easier for us as programmers to try three approaches, see which one we do better at, which one first, which one we do better at, and then which is the overall better approach. And something I notice is that we are much less attached to our code,

because it is very important how we write it, so that it is easy to change later, like refactoring it, and in the industry as a whole, we have many such patterns that allow us to set up separations of concerns, so that there can be different parts that change for different reasons. Yes, this may not be so valid anymore, it's not so much of a problem anymore. code

repetition. If we can re-invoice it very quickly, maybe it's not a problem. And the lemmas themselves are pushing us in that direction. They also do a lot of code repetition and allow us to prototype much faster, experiment much faster make decisions based on data much faster. For example, we're making a feature and I know this feature is used by this type of user. How many such users

do we have in our system? I want to know now, should I design it for 10 people who will use it today or 1 million people who will use it today? Very different, right, I would put in a much different effort and a much different approach from an architectural point of view, and for example, the feature would be written more in this case or read more from

the database. The "Ami"s give us different integrations. Through the MCP protocol, we can connect them to our database or our data warehouse and write using a tool that gives you access to the database or find out how many users there are who have this type of setup. It tells you how many users you are. Oh, it's good that you have to design it for so many users,

and not only online, but also internally within the company, finding information is much easier and we can use data and make decisions much more easily. And the other cool thing is that everyone can program, and one is VIP coding, where on Twitter you can find many examples of people who say: "I don't know anything about programming and I sat down and coded this site and now I

make €10,000 a month and it's great." Yes, there are stories like that, but there are other stories as well. For example, there's a really cool story about a guy who lives in a small African country, Malawi, which is next to Tanzania, and he created a chatbot with SMS, which speaks the local language there, which is Chiche Chicheva, and helps farmers when they have a problem, to ask,

to send an SMS, to ask this chatbot about something. something and he should give them a solution. And this has helped the local population a lot, right, to grow food better, which is an example, right, because if this has to be an old-fashioned software project, there has to be someone who understands programming, someone who understands guts, someone who understands agriculture in this part of Africa, and three

or three people have to be a team, and this team, right, what will this product be that will make it so that there is revenue from it, so that it makes sense for such a company to exist. And it will start to happen, because everyone can program, that many problems that are important to people, but do not fall under the sway of the IT ecosystem as it

currently exists, can be solved. And despite all the cool things about artificial intelligence, there are also many things that cause us problems. The first is that they are not very accurate and if we ask programmers do you believe them, they will say, I don't believe them. And that's because they're not very accurate. First, they hallucinate, they make up things, second, they run out of context and they

don't tell themselves that they've run out of context and start making things up again. If their logic doesn't work, they can't realize that what they're currently writing as code doesn't make sense. Or if you ask them to do something pointless, they will do something pointless, without even asking themselves if it makes sense. And it has happened to me that I start a new project, right, to program

and it downloads some depdns and last night a new version of the library was released that artificial intelligence wants to use to solve the problem and nothing works and throws errors. He starts trying to fix them and can't figure out how to use the new version because there's some kind of breaking change in the API and this experiment fails. We were unable to solve this problem with

artificial intelligence. And there are many security vulnerabilities that, through prompt injection, through attacks on pipelines, introduce things that shouldn't be there. And the other bad thing is that our skills don't atrophy when we use artificial intelligence. There are studies that show that the more we use artificial intelligence, the more our thinking capacity decreases. So, critical thinking is a pervasive skill and this is something we need to

keep in mind. Yes, we will use artificial intelligence and in fact we will clearly become dumber from it and we need to do something about it, right? When we talk about sustainable development, we need to keep that in mind. To avoid being overwhelmed, we need to do something about it. And the other thing is that it's very easy not to understand things. It's very easy to ask

him to please fix this thing. Please fix it another way. Try again, before we delve deeper, let's open Google in the usual way, let's start reading what this error is, where it comes from. This is a much, much more difficult thing, and we have to keep in mind that it's very easy to miss the point. It's very easy to just tell him okay, hack him somehow. I

don't want to open the library documentation to read exactly what this method is called. I want to move forward. this affects us in a negative way, we do n't understand the code as much and we don't develop as much. And if we take the crystal ball like that, the answer that was there a moment ago in the previous presentation, will we need fewer programmers in the future?

There is AI, it writes code If there are that many programmers, they will produce a lot of code, will there be that many programmers left or will there be fewer programmers? And if we look at the announcements, we are at the lowest level in the last five years in terms of the number of announcements in the industry and okay, are we starting to because there is more

AI? But we wonder why there are fewer ads? All because of artificial intelligence and the answer seems to be no. And before, it was very unprofitable for investors to keep money in banks. There was much more investment in the technology sector, with new initiatives, in startups, and these zero interest rates, right, zero leverage, made the money go somewhere else. Now they are not zero at the moment.

There is less and less money in circulation. for risky investments, for new capital, for venture capital. And this is something that has quite an impact. The other thing is that all companies currently have one focus, all stakes, all startups. How we adopt AI is important , and if we are the CEO or head of a company, it is very clear to us where the focus should be.

people in AI. And these other features that we used to pursue or verticals that we used to pursue, they won't be as viable. We need to be focused on this thing. Everyone has a focus and things that we've tried before, will it go here, will it go there, will it go here, no. The company does it less because there is one vertical that has taken off a

lot and everyone is focused there. The other thing is that there are a lot of news stories that say a certain company is laying off people because of artificial intelligence, and you think that it has started using artificial intelligence and has become more productive and doesn't need as many people anymore, and you read the article or the company's history, and it turns out that it doesn't. They

want to reduce costs so they can invest that money in AI development, which means we need money to buy hardware, we need money to buy electricity, we need money to pay higher salaries to AI researchers, because they have a lot of money. I haven't seen a news story yet that says the Hicks company is cross-breeding people because it's more productive for that particular thing. Most big companies,

right, if you consider exactly why they're stealing people and actually investing in AI, which means hardware, other roles. It's not that there are any gains, that so many people are and the other thing is, it may sound stupid, but there are more taxes, there are various changes in the States, there are the main venture capital companies, there are the main technology companies, I raised the tax rate

for software development a lot, and that's a stupid reason, but overall, with the development of the field, the price of software development will go down, it will become cheaper and cheaper to develop software. That's clear, right? Because if we become more productive, we have less time to do our tasks, and we, as programmers, will learn to use them more effectively. We'll start producing more and the price

of this thing will start to fall. It seems so. Now the question is what will happen. I was a little hasty. The question is what will happen. The price will go up. And that will make it cheaper. Does this mean that we will need fewer people to pay lower wages to, which could perhaps happen, right? If we look at the original analogy, which is with traders, not

all traders continued to work as traders. The people who shouted, right, at the New York Stock Exchange, not all of them continued to do it. There are some people who had to retrain. It will become cheaper if the demand remains the same. If the demand remains the same for this software and it is easier to produce, yes, the price will go down and fewer people will be

needed. But there's something called Jevons' paradox, which emerged at the beginning of the last century, when more efficient turbines, steam generators, steam turbines started to appear. Then everyone can say to themselves, " Steam turbines are getting cheaper, and I can't, with the same amount of coal, you can get the same field of greater efficiency." That means we will need less coal to run the current trains. We

will need less coal to run the current trains . So, right, less coal will last overall, which means we'll need fewer people to work in the mines, and most likely because steam engines are becoming more efficient, we 'll need fewer people in the mines. But in fact, it turned out that it wasn't. More efficient steam engines with people saying: "Hey, how cool, we need more trains, more

cars, more stuff , right, that runs on these engines. In fact, we need more coal, because you see this thing starting to be used everywhere, and the opinion of economists right now is that when you talk about technological innovation, making a given technology doesn't make it less necessary. On the contrary, the need for and the need for the corresponding thing increases, right? That is, many more people

will start producing software. This software will need a lot more infrastructure on which it runs. This infrastructure will need a lot more software to be orchestrated. Many more security trades will appear. We will need a lot more security software to make this much more software more secure. It should probably happen automatically somehow other people who haven't used the software will start using and changing it. They they

will need some help. And a lot of software that doesn't exist right now because there's no need for it will start to exist. 'll probably need them, right? The number of programmers that will be needed won't drop. The fact that a lot of people will be able to program and there will be a need for new software means that there will be a lot of software needed

to make this software work and exist, maintain it, and there will have to be people who understand things at a lower level, which may need to be more, because there will be a lot more people who will want to take advantage of such an ecosystem, of tools that work at a lower level. Um, but the work will certainly change. And first of all, what was the question,

what will happen to the juniors? Well, yes, the job for juniors will be very difficult to find or very difficult to find at the beginning, and you have to focus on fundamental knowledge, because you have to understand and do reviews of the code that AI writes. You have to understand what it does. You have to understand how computers work, how memory works, how the network works, how

the operating system works, how processes are scheduled, what types of scheduling there are, and how to debug history leaks, how to debug performance problems, right, a person should have a lot of such computer science fundamental knowledge . We have to learn with understanding not only artificial intelligence wrote us some code. Well okay, what does this code do now? And the good thing is that artificial intelligences are

good artificial intelligences are good at writing some code and you can ask it why this is so, why the other one is so? Oh and it's important to have days when you turn off the AI, right, as juniors you have to have days when you write everything by hand the old way. we read the documentation, we read ST Overfall, there must be days like that and you

have to find a mentor, because very quickly you how it works software, how software is made , what are the processes and much better when someone gives you information on the questions you have live, than if you have to learn everything yourself and the work of the seniors will change, right? They even more need to understand system and architect. They need to be the people who say:

"Hey, that's how it works." Inside there are such course files, right, such context files that set the architectural parameters. These things work, these things don't work. I experimented with this, this is how it happened. And even more they need to explain to the other people in the team and remind them, you have to understand what is written, yay. Don't just release it like that for reviews. And

check it, validate it. And domain expertise will be very important, and understanding the field you work in. Healthcare, finance, gйing, right, you need to understand your domain very well and everything is based on taste. Something that is there to be able to change people's taste. Something that doesn't seem cool or it doesn't seem cool to us. This is subjective and work on. Ah, but this could still

be a whole lecture. What does taste mean? But keep it in mind, read what taste means, how taste is acquired. And it's not going to change that we have to give some direction. We have to say solve this problem, because this is the important thing right now and this is something that we need to solve and it's also not going to change how creative the problem is

that we want to solve. whether we want to solve something, but we want to solve it in a better way, we have some idea and that creativity will not be able to replace artificial intelligence. There will not come a time when we will tell it to do this, it will say to you: "Do you want us to do it more creatively like this?" And we are quite

far from there and in general we are far from the moment when cloud, right there cursor version N can write cursor version N + 1. We have new tools, we have to learn to use them. World peace, world hunger, are not solved problems. We will be able to use these tools to be more productive, to solve more interesting problems. So everything is ahead of us. It depends

on us to learn to use them well, to direct them in the right direction. Thank you very much and I will move on to the questions. So. Here. So. There will be a decline in open positions for IT with the massive use of agents. Yes, according to the paradox, there should not be and according to the opinion of most economists, there should not be a decline, because

the greater existence of software. There should be more other software that can work alongside it. And the greater accessibility does not mean it is demand. What will be the new professions related to AI that will replace the current ones in the IT field? rather, everyone, it is the opposite, there will hardly be new professions, rather, every profession will have to learn to use AI. And for example,

we, like writing code, so far we have talked about agents for writing code, right, such systems we will have to learn to use. the previous presentation we saw tools for marketing, for sales. Obviously this will also have to change how people work. And so it will not be no maybe there will not be new, but the current ones will change, so that people in them will be

using tools. And there will be other skills that are required. For example, someone who is stuck in AI from automation with other people, but again this should be the senior engineers in the teams, as before the senior engineers are the people who see the good standards, the good practices. This must continue. They should be the people who say, and this is the architectural context for AI. Here

are these tools we use in this way. he does a code review, he doesn't do a code review, he writes tests, he doesn't write tests, he writes this type of test, but we write the other type of test , right? All these things we have to experiment with, learn to work with them. And is it an assistant or a substitute? Have we lost the ability to think

independently? Yes, there are many studies, not only in programming, in different fields, that say that the more people more their cognitive skills decrease. And we have to keep that in mind and we have to do something about it. For example, having a day when we don't use it is a good time. To be more critical of the things it does. A good time, right? We have to

see what works for us, but yes, it gets dull and we learn less, as I told you from the beginning. We take some things for granted. It's much easier not to understand how to use the library, how to use the language, right? Okay, it offers us something. It works. It's much easier to move on to the next thing. We also have to keep that in mind and

these two things are a fact. That's how it will happen. So we have to live with these two things, because the alternative is not to use artificial intelligence. For example, a person who was a little while ago, right, he said in my company, who doesn't use AI, right, you've found a place elsewhere. There are other companies that you can see that are following this trend, right, like

Shopify, there's a very famous meme on the CO where it also says, right, and how much AI they use will be part of your performance reviews. You have to write it down like a 360 FB, how many of your colleagues use AI. We won't open a position until the team proves to me that the work that the new person wants to do can't be done with AI.

Right? There's a whole other layer of things that not all companies are that extreme. It's just that the people who use use such tools, and they'll start living in a different ecosystem, which if we fall out of it, we fall out of the industry. With so much with so much use of AI, won't there be a lack of basic knowledge in the new young programmers with a

lack of this basic knowledge how will they achieve quality created growth? Yes, that's right not to delve into things and What I advise people to do is to use artificial intelligence again, by writing some code to explain to them why, what the alternatives are. And again, you have to have an opinion that he could be hallucinating and have a better way to do something, but he doesn't

know it. And you, since you don't have intuition about things, still shouldn't it occur to you that there is a better way to do something. Thank you once again for being so comprehensive and helpful.