Как ИИ меняет айти? / AI Product Engineer и системное мышление / Интервью с Байрамом Аннаковым

Phew. I haven't conducted an online interview in a long time, so it feels like the first time every time. >> Good. >> Let me try to introduce you a little. Although, I think, for most people you don't need an introduction, but nevertheless. What if someone doesn't know. Uh, I've figured out for myself, you've emphasized for yourself, that you are a serial entrepreneur first and foremost today. If anything is wrong, please correct me immediately. So, let's get to know each other better. Currently, you are the founder and CEO of the company onsaa. Sales processes, right? B2B. Yes, that's right. >> Before this, you've done a lot, I've seen many businesses of yours on LinkedIn. Probably one of the most prominent is Up in the Air. A flight planning platform. Yes. >> Yes. >> Right. In which you were also the founder and CEO. Well, and, essentially, largely, largely your track that I saw on LinkedIn is related to business. Although on your YouTube videos, you have a large channel, well, quite large for such a narrow topic, which I will link in the description, where you talk about the transformation of IT. In particular, you discuss management and even development a lot. And I saw that at the very beginning of your career, you had experience as a developer, despite having an economics education. Can you tell us a bit more about your journey from developer to businessman and to what you are doing now? >> Yes, let's. Well, first of all, my father had a big influence on me, because he was a programmer who worked at Gosplan, and they used to plan on large computers how the economy of the Soviet Union would develop. And we got a computer quite early, and he left there when perestroika began, and he started writing software for businesses, specifically for banks and accountants. And I think that's when it happened that I stopped, or rather never thought it needed to be separated. You know, in companies they classically say: "This is business, this is IT." But he always told me, for example: "If you want an accountant to talk to you, you need to know accounting." And that's why, when I was in my second year and went to work for an 1C franchise, to finish 1C for each client, I communicated with accountants and salespeople, and if I had used programmer terminology, they would have sent me away. So I had to learn accounting myself, just to talk to them. And anyone from the IT field who has touched accounting knows that it is super logical. It's the most logical thing. So, what am I trying to say? I think business can take a lot from IT. IT can take a lot from business. And since I grew up in such an environment, I probably always tried to embrace both. That's why I ended up at Bauman University in a faculty that, if there are any Bauman alumni here, tell me the faculty that is jokingly called "engineer without brains," because officially it's called "Engineering Business Management." And we essentially studied programming, and finance, banking, in particular, because the specialization was called "Automated Banking Systems." That's why I chose this faculty out of all the ones there, precisely because of this passion for business and technology. That's why for me, these are two inseparable things. Of course, thanks to the last two years of programming, it's becoming, well, classically I was a Java developer. Then, when I started my own business, I had to understand Python and Node.js. But I wouldn't say I wrote a lot of code. If we take the last 2 years, thanks to AI, of course, I generate code and correct it when it's inadequate. And here, of course, the main thing is to understand the business logic and have a basic understanding of programming technology, what caching is, that you shouldn't make some unnecessary requests, and so on. Sometimes LLMs won't do this themselves without specific instructions. Although you can ask. And it turns out that the role shifts towards a supervisor, but you must have this knowledge of what caching is, decoupling, and so on, because if you don't say it, it won't think for you and do it in most cases, for now, maybe it will get much better at it at some point.

Listen, so can we say that you are mostly a tech person with a business education, or a businessman with a technical education? I myself studied physics, physics-management. And our management was a very small part. Four years of higher education in physics and one year of accounting and everything else. >> I see. >> How about you? >> In terms of education, I would say yes, a businessman with a technical background. But in terms of mindset, I think I'm more of a tech person with a huge interest and love for business, which is why I went to get a second degree in pure management at Moscow State University, because I wanted to. They gave me a junior developer and said: "You're also responsible for him now." I was a senior Java developer then. And I became interested, what does it mean to manage a developer? What is management? And only one book answered me. And then it all started, and I ended up studying management. That's probably why I, the second one, well, I would say, a techie. >> Well, now it's clear why you are CEO and not CTO in companies, although it seems like you are the person who could combine these roles. But it's probably difficult. You know, now, due to circumstances, I have to combine these roles, but I'm not the CTO here. It's just that our CTO had a child, and well, he decided, well, it's hard in a startup with a small child, so he decided to go to an established company. And so I decided to do an experiment, since it happened, whether we can manage without a CTO. We've been without one since February or March. And our team is small, so we can afford it. And everyone is very independent. And that's why it's possible for now.

Tell us a little more, just a few minutes, about the team and current projects. >> Yes. So the main premise is that 70% of what CEOs do in B2B businesses can be automated. What does that mean? It's, for example, client search. You need to research, figure out where to find them, write to them, hook them. This can be done automatically. Now we do this for about eight or nine customers. Second is when an incoming request comes in, you need to check it. Well, in English, there's a word like "time-wasters," right, who just ask but will never buy. Never buy. And there's a process in sales called lead qualification, where you find all the information by email and name and do a check, whether they are yours or not, and then prioritize processing the request accordingly. This can also be done by AI with 90% plus accuracy. Preparation for an important call. I recently wrote a post about how I prepare for important calls now. I wrote about two recent calls. One I closed, meaning I signed the deal. The second, we moved to the next stage. I think I can't say for sure yet, but at least 50/50 on a small sample. But what I'm getting at is that meeting preparation can be automated. Recording meeting results in CRM can be automated. In general, there are many processes that AI already allows us to automate. And I think, except for meetings for very expensive contracts, everything else, I think, can be done by AI agents with varying degrees of accuracy at the current moment. >> Uh-huh. That's why I'm also implementing it into all pipelines, including your project pipelines, we'll talk a bit more later. Yes, and let's pause here for a bit, you know, on what? Regarding AI. Regarding AI. You were a developer, then you got an economics education, startups, companies, not startups, companies. A company related to flights. There doesn't seem to be any AI there. Selling AI bots. >> And also web3 somewhere. How did that happen? >> Let's start. First of all, I'm a fan of a guy, maybe you know him from the AI world, Ray Kurzweil. >> Of course. >> Yes, I'm a fan of his. And in 2015, when in 2010 or 2011, no, in 2009, I learned that he was launching Singularity University. >> I've wanted to get into Singularity University ever since. In 2015, I got into Singularity University. And the first thing that blew my mind on the very first day, there's an executive program, it only lasts 7 days. It's AI. If you look, there's a video of me at Strelka in Moscow in 2015 or 2016, where I talk about AI after returning from Singularity University. And that's when it started. So it became fundamentally interesting to me. What tasks did AI solve even in our business back then, when there were no LLMs? Everything was much more complicated than now. For example, look, every airline sends you a confirmation email for a purchase, right, for a booking. And each company has its own format. There's a lot of important data in it so that it automatically gets into our application, so that people, so that there's retention, so that people continue to use our product, because the booking will automatically appear in their email. And then we'll tell them when registration opens, register them for the flight, if they paid, we'll notify them about delays, postponements, all that. And if the flight is canceled or delayed, we'll even ask, if it was in Europe, for 500 euros, well, compensation, and bring it to our user. And for example, this process of extracting information from an email, where the email format can change dynamically, they put some advertising in it, a new requirement appeared, everything shifted. Some layouts don't even have a normal structure. And there, for example, you needed to use. Now with an LLM, it's done like this, but back then it was a whole pipeline. Its implementation. Then I made scripts to promote our app in the App Store. Well, what's called App Store Optimization. There were elements of machine learning. And there are many old videos of mine where I talk about how to use product analytics with machine learning to understand where you have problems, and so on and so forth. So you were inspired by Ray Kurzweil? >> Yes. Yes. 2015, right? And to this day, I have his latest book here, you know, he postponed it because of LLMs. He postponed it from '22 to '26 to finish it. And it came out in '24. I just can't finish reading it because his books are like this. And the first one I read was something about the mind, how our brain works. They essentially described a model that became the basis for the Transformer architecture. And I'm just reading it for a very long time because the level, the volume, of useful information per page is so high that, well, you have to savor it slowly. Before >> I mean, many consider Ray a strong futurist, even though most of his predictions come true, but he still gets flak for singularity. Although, who knows. >> And you seem to ground everything in practice and ground it very well. You know, they said the same about me when I came back from Singularity with these bright eyes and talked about AI left and right. Honestly, very, just one of my acquaintances from the venture industry, just said that you scared one guy. This guy is a famous entrepreneur. He was in Russia. Now he's left. And I understand why I scared him. I remember when he was there and what questions he asked. But globally, yes, he's a futurologist, he goes far, there are things that don't come true, but I believe he's one of the, thankfully, living geniuses that we should at least listen to. If they make mistakes in the timestamp, they definitely won't make mistakes in the direction. So, and I think we need to consider this perspective. As for grounding, well, yes, some things can be grounded, and some cannot, simply because you don't know how, you lack skills, and so on.

Okay, thank you. Guys, I remind our listeners, you can ask questions in the chat contextually. If they don't fit the context, or if they're a bit stale, I'll save them for the end, and we'll ask them at the end. So don't worry, everything will be asked. Let's move on to IT directly. Our audience is mainly established engineers, top management, and technical management. And I'd like to talk a bit about management from the very beginning. >> Uh-huh. >> In many of your presentations and lectures, you talk about systems thinking, and even call yourself an evangelist of systems thinking. >> Uh-huh. >> Can you briefly tell us about your view on how systems thinking is used in IT management? And the next question is, how is it changing in the era of AI's arrival in management? Perhaps some new things are coming from systems thinking, from systems laws, including those that are already applicable in management in the AI era. >> I see. A good question, deep, and I'm very afraid of answering it superficially. Let's put it this way. I will answer it more or less superficially, but I will strongly recommend, first, one book to understand what I said more deeply. And second, perhaps there are some of my videos or others on this topic, to go deeper. But globally, systems thinking is divided into two parts. It's thinking as such, i.e., principles. I'll state a couple now. And there's applied application, which is when social systems are modeled. Well, business systems are part of social systems, where there are people. Therefore, this is modeled using a special language called system dynamics. This language is based on, whoever played The Sims, the Sims model of the system is one of the first system dynamics models of a city that was designed. I forgot the name of the inventor of The Sims, he mentioned somewhere that he was impressed by that model, he incorporated its principles into The Sims. So there are principles, and there's practical application. And in my fourth year, when I defended my bachelor's thesis, I did just that. I got acquainted with systems thinking, created a model of a business process that I automated as part of my bachelor's work, and presented it in the form of a system dynamics model. Who knows, well, such process modeling languages, damn, I've forgotten everything myself, BPMN, etc., but it's in that direction, but those languages usually describe, well, business analysts often describe processes for programmers using these languages. But this is a dynamic implementation. So you use a computer to play out this business process and see its bottlenecks. For example, that due to feedback loops, increasing the number of people on a project actually reduces the pace of the entire project, because the volume of communication that arises between people kills their productivity. Why do we need any communication processes at all? Because we are trying to reduce coordination costs as the number of coordinating entities grows. And in general, if we talk about systems thinking, there are a number of principles. The best book on this topic. I'll tell you one principle. I think everyone has experienced it at least once. The book is called >> The Systems Thinking Playbook. Don't be afraid. >> Yes, that's right. Thinking in Systems, it was translated into Russian. By the way, I tried to get this book published. I even bought the rights to publish it in Russia, but then Alpin Publishers messed up something with the rights, and I had to back out. But I'm glad it was eventually released, because it was more important to me that it be published. And the second one is called Systems Zoo, not Systems. Wait a second. Systems Zoo. Ah, I just forgot. Well, I'll write it down later if needed, >> Yes, I'll note it down later, remind myself if anything. I'll send it. >> This is a real Systems Bible. That's it, it's called Systems Bible. There are the laws. One of my favorite laws, which is very relevant to all of us, is that all complex systems that work originate from simple systems that work. So, you need to first create a simple system that works, and then layer on top. Trying to create a complex system immediately without this intermediate step always ends in disaster. How does this translate to, I think many people, when they immediately try to build a spaceship. We have this expression, right, it's like a spaceship. But most often, when they try to build a spaceship, it's a misunderstanding of the principles of system development, system evolution. But there's another one, for example, that any new system that solves a problem creates new problems. And we also know that every new piece of code that fixes bugs also adds other bugs to the system. The question is simply whether we want to fix them and so on. Therefore, Systems Bible is simply a treasure trove of such formulations. I just recommend reading it after Thinking in Systems, because it's a bit, I would say, daring. But globally, these principles, regarding system dynamics, the best thing to start with is Thinking in Systems, and the best is the Business Dynamics course, which is taught at MIT, where they teach you to model systems on a computer and simulate them over time. So, to summarize this long tirade, in general, yes, I am an adherent and try to promote it. I believe that the principles of systems thinking will be relevant in the AI world, well, in a world where AI will play a big role and some aspects will even become more complex. Because, for example, you know, in systems thinking, there's a counter-intuitive principle that accelerating a process doesn't always improve its efficiency. Well, business consultants often say: "This is working slowly for you, so we'll automate this, remove that, do this, and then the process will be faster, you'll get information faster, the feedback loop will work faster, you'll react faster, blah blah blah." And this leads to improved system efficiency. But in systems thinking, there's a counter-intuitive principle that it's not always the case, because sometimes an overly rapid reaction to events can worsen the situation. So some >> some events require time to settle. >> Exactly. Yes, let this paper lie for a bit. Something like that. Let this information. I'll give you a very simplified example, but if you need it, either in the book or... Look, imagine you sell beer, you have a beer kiosk, and you have a process for ordering. Well, you get beer delivered once a week from a wholesale market, you don't transport it yourself, or a distributor brings it to you, it doesn't matter how, but only once a week. And you, next to your kiosk, there's a rock concert on one day, and you have a spike in sales. You couldn't sell everything, and you think: "Oh, I'm doing great, I didn't know there was a rock concert, I'm doing great, and you start ordering a lot." Well, you usually sold 20, so you ordered 140 for the week, here you sold 100. So you think about ordering 700. But we both understand that there isn't a rock concert every day. And therefore, you need to calculate a moving average. Well, any forecaster knows that you need to calculate a moving average and gradually increase the order. Otherwise, it will be, well, in logistics it's called the bullwhip effect, when you, you know, sometimes there's not enough, and sometimes there's too much. It was like that during COVID, remember? >> Uh-huh. >> First there were not enough masks, and then there were too many. First there wasn't enough toilet paper, and then there was too much. This is when the reaction to the system is too fast, and this is sometimes bad.

How does AI influence all of this? That is, from what you've said, what resonated with me, for example, is process replication. That's a fairly understandable thing. Now, multi-agent systems, in fact, allow you to model the processes that are happening in a company. >> Yes. So, let's say, from the perspective of risks, the risks are understandable, right? But from the perspective of risks, I'll just mention a couple. Continuing this thought about too fast a reaction. We IT people understand well that highly coupled systems are more fragile, right? So the concept of microservices, right, architectures appeared. So, I believe that now there is a natural brake in our lives. It's us, people, a mental brake. Such. And this is often good, because it creates, I'll use a metaphor now, it will be completely clear. It creates natural buffer points. In systems thinking, there's the concept of buffer points. And these buffer points, they sort of amortize problems. Well, for example, imagine there are two implementation options. The first agent of one system directly works, communicates with the agent of another system, because AI has made this possible. And the second option, the agent of one system cannot communicate with another, but there is a person who, like a courier, takes the data from here, processes it in their head, maybe somehow pushes it, and then enters it into another system, perhaps in a processed form. This person, because they sleep, because they might forget to do it, might be lazy, is a natural shock absorber if a problem arises. Well, with viruses, everyone understands. Everyone understands that a tightly coupled system. The more coupled the system, the easier the problem will propagate throughout the system. Let me give you a metaphor, it will be immediately clear. COVID and international transportation. Until there was a very easy way to get from Africa, let's say COVID, not from Africa, but let's say, to fly out the same day, until symptoms of the disease appeared, or God forbid you died, until there was such a mode of transport, it couldn't spread so quickly. >> Spread. Uh-huh. >> Yes. And as soon as we had it, that's why they close borders first, right, they try, but think about this moment, it might sound scary, but think about it. In most cases, the most dangerous viruses kill a person quickly. Well, that's why they are the most dangerous. But if it travels on a ship for 2 weeks, it will die by then. >> Yes? With viruses, it's clear, on a plane it will fly and spread it to a large metropolis. >> Okay. >> But it seems like you're putting a lot of emphasis on the human here, but in engineering systems, a human is just an indispensable slip, a sleep timer, and that's it, it's mandatory in execution between agents. Because people will want, how will they want? They >> people will want faster, if they can do it faster. Yes. >> Yes. That's what no one, well, just didn't grasp for about three or four months, when Psyk appeared. If you remember, there was a big Twitter debate about whether cheaper AI would increase AI consumption or not. Uh-huh. I can tell you now that it's already visible that it does increase it. In economics, this is called Jevons Paradox, when increased efficiency in resource use increases the amount of resource consumed. Therefore, I think that as soon as people realize that systems can be linked to each other through AI, they will, and there are many benefits to this, and international transportation has many benefits. But this has very big risks that were previously unnoticed because of these shock absorbers. And in systems thinking, there's such a formulation. Every problem has a function. That is, if you consider a problem only as a problem to be eliminated, you lose sight of the fact that it has a useful function. Therefore, by eliminating the problem, what will you do? You will eliminate the useful function. >> Well. Uh-huh. Uh-huh. Okay. You've spoken in your presentations about forecasting, about how AI also helps us forecast all this. You, in particular, said that warehouses, for example, will not be needed in the future. Can't this same tactic be applied here? Let AI predict what will happen next. And if it's necessary to make this slip timer between agents, it will make this timer. Why do we need a human here? >> Ah, yes, I just gave a human as one example of a natural shock absorber. A human is not the only such shock absorber. For example, the impossibility of systems communicating with each other due to formats, well, due to communication protocols. This is also natural, but thanks to AI, this can be resolved, systems will be able to, because, as I said, you can read, since we couldn't connect directly to the airline system, we...

We read from the mail, extracted data. And the better we learn to do this, the, uh, the higher the probability that it will generate new problems. >> Uh-huh. >> But we don't know which ones. And what needs to be done is to look at these problem eliminations, that they will generate new problems according to the law, and for them, businesses need to be developed that will solve them, because people, as soon as they learn about this problem, will start running around with their asses on fire and looking for a solution to this problem. >> Valid. Valid. Let's move on to management. Uh, a question. You talk about a future where a person, supposedly a conductor, manages multi-agent systems and other people. If it's still okay with multi-agent systems, we've more or less gotten used to talking about it in the community, but the fact that these will be systems mixed with people and managers will manage them, that's something unusual. Can you tell us more about how this will work? >> Uh, in short, I think about this a lot. For the last month and a half, probably. What do we see in implementation? At least for now, yes, we understand that we are still at the starting point of this whole movement. We see that, uh, firstly, people want to control AI, there is no trust yet. Trust is a function of time, just like with new people in general, right? So we don't immediately, well, clothes are met by their appearance, we know, we know, >> yes, something like that. That's why, uh, it turns out that when we create these systems and implement them into the business processes of our customers, then, uh, people want to participate in, uh, in this, well, in this process. They want to be what is called human in the loop, right? But often it's not one person, but several, because they are different. Let me give an example. I recently participated in a hackathon and I was creating a system that shows a real case for our customer, where several people and agents need to interact. Look, we have an agent who qualifies a potential client based on a website inquiry, collects information about them from Google, LinkedIn, Crunchbase, blah, blah, blah, qualifies them, and, uh, says, for example, this client is a priority on a five-point scale, let's say three, but one of the people says: "Oh, I met them last week at a conference." He told me that they actually have a budget for this system, so the rating should be five, but the agent didn't have this context, he didn't go to that conference, didn't chat with them. And it turns out that contexts are added, as it would be in a real company. You, for example, are the head of sales, I'm a sales rep, a new lead comes in, you say, "Let's not take this one for now, it's a three." I say: "Oh, I met them." That is, the context is not, not, in short, agents don't get a large portion of the context that exists in business processes. And people will play this role. This is role number one, adding context. The second role is, well, long-term memory. For now, it's research, but I think it will be solved someday, but still, a person will play such a long-term, uh, very unreliable memory. Well, and the third is physical actions, especially when interacting with interfaces where a person is absolutely necessary. Well, conditionally, to get a passport. I can't do it online here, right, in the USA. I have to go to the DMV in person, well, not the DMV, but the relevant authority, and show myself, because it's easy to forge, right? Sam Altman and his team are making World ID and so on and so forth. >> Uh-huh. >> Yes, orbs, but globally not yet. In general, there will be interfaces. Uh, interfaces in a broad sense, not UI, uh, interaction with other people, organizations, the state, which will require this physical presence. And I see when an agent can pay a person to perform some offline action or add context and then better complete their task. I paid a person to perform a physical action. Yes, >> that's cool. That's cool. >> Tell me, can AI assistants in the form of some wearable device that would share this human context solve some of these problems? Well, these pins, what else did we have, a bunch of wearable devices. >> Absolutely. Yes, last year, I regularly attend hackathons to prototype new ideas and try new frameworks. And last year, the guys are now called Omi, and if you can see, uh, these, uh, now they have beautiful ones, but then it was called friend. And it was ugly, I opened it up, you can see, I studied how it works, uh, what hack I made and got a prize from them. >> It's always listening to you. And then when you ask it, uh, I think I had, uh, you're listening to a generated podcast, and in the podcast, uh, they talk about a book that you, like, talked about with your friend before, and it was recorded. And the podcast host, the generated podcast, says: "Remember you discussed this book with Lyokha yesterday? Well, this is exactly that book, you understand, right? It embeds context into the generated content." So, yes, these pins and the like will definitely solve part of this work, yes. And robots too, uh, a certain part. >> Robots, when, when can we expect robots? So, top performers. >> Listen, what I don't know, I don't know. I, uh, guys, >> you mean not robots, but buddyment, obviously. I still, yes, yes, yes, yes. Well, what I already see from what exists, well, Figure, uh, that Tesla's, and I forgot, Unni 3, I think, a cool Chinese one, yes. It's very impressive already, but I haven't ordered one for myself yet. I will order, uh, an open-source arm has appeared. I don't know, have you seen, uh, that Hugging Face project. I will order it for myself. I want to play with the software part, so I will assemble a pre-assembled one, order parts, and will be programming it. I want to figure this out. When, I don't know, I'm not deeply into this topic. So I don't have any insight. >> Okay, let's get back to IT. We talked about management. This is a smooth transition for me to one big topic. The second part of this transition is the developer. How, in your opinion, are developers' approaches to product creation changing or already changing? For a long time, we had a problem in companies that developers didn't associate themselves with the business at all. I'm just writing abstract code in a vacuum, and that's it. You said no, you need to bring in the business side. Well, those who are older, more experienced, but it didn't really catch on. Does this mean that with the advent of AI and all these things, developers, whether they like it or not, will have to delve deeper into business? >> I really hope so. I, in general, maybe it will sound a bit offensive, but I classify developers into two categories: coders and developers. I understand that it sounds almost like I said something absurd, but I'll explain. No, it's a clear topic. Well, I'll explain, yes, in general, yes. >> Therefore, I believe that all, uh, uh, well, developers, will become developers, not coders. I understand that not everyone may be interested in this. I've worked with such guys, they usually become architects, that is, they follow this track, yes, career-wise, >> yes, yes. And I understand that perfectly. Therefore, I want to say the following: that architecture also implies a very good understanding of the business conditions of system operation, because it imposes constraints. There is, uh, this, what's his name, Ul, who wrote the best book for engineering leads. Ul >> I'll do it later. Okay. Okay. Maybe he'll suggest it in the chat, write it down. >> Yes. Yes. >> And, accordingly, he, by the way, also talks about systemic thinking, about system dynamics in this book. Uh, maybe that's why I like it so much, maybe that's my bias. But he quite rightly says that any architecture dances from business conditions, among other things. >> Therefore, uh, we, uh, well, an architect especially will also need it, and I think it's right. I didn't like the separation of IT and business. We started with that. And, you know, it reminded me of how at some point in science, it happened in Ancient Greece, science was divided into applied, uh, like geometry, a very applied science. to divide a piece of land equally among the warriors who conquered it. I'm exaggerating, but I think you understood, Pythagoras was doing what? He was measuring how far it was to a ship sailing on the Nile. Well, in short, geometry was a very applied science, but, for example, philosophy, uh, it, although, well, algebra to some extent, people consider it a more abstract science. Well, in short, in Ancient Greece, a division occurred between abstract and applied branches of science. >> It seems to me that, in the same way, a division between business and IT occurred incorrectly, especially in the current world, when IT is the backbone of almost any business. And the largest companies in the world are companies where IT is a key competence. >> You know, I think that this is probably a disease of post-CIS countries, our space, because we were not particularly taught business thinking in school, not at all. We didn't have such a business, and everyone from the post-Soviet space came out of poverty after the collapse >> our generation especially. And >> and therefore IT at some point became a refuge for introverts who really just loved to delve first into hardware, and then into software. Well, naturally, where would a love for business come from if these were diametrically opposite things? >> Yes. Yes. Along with this. That is, I completely agree. The connotation that an entrepreneur is bad. It still exists with the older generation. So, you know, when you say you're an entrepreneur, acquaintances with a girl's parents think you're a loafer, a black marketeer, and so on. Well, I don't blame them for that. But, if we, at least, I don't know about the audience, you, me, I like programming because I create something, that is, as it were, but creating something is a fundamental skill of an entrepreneur. Well, that is, if you enjoy creating something, you are essentially an entrepreneur, an inventor, an innovator. And I don't understand why, as it were, these are separated, I think they are related things. >> I know that many stumble over communication. At some point, you create, and then you have to sell it, talk about it, and you're like: "Yes, thank you, I'll sit in my room, >> find myself an SEO and an SEO for decades to handle communications." >> Very good point. If you had seen me the first year, when I moved from Ashgabat to study in Moscow. I arrived in 2000. And if you had seen me, I was shy about everything. I liked supermarkets where you pick up food yourself, because you pick up food yourself. You don't have to go up to a woman and say: "I want that, and she might scold you or something else." I must have had some trauma. And I didn't like interacting with people. And the internet, chat rooms, that's how I lived. But in my second year, my first job was selling a translator called Socrates, I think. I don't remember anymore. And I had to overcome, in short, this fear, the fear of communication. Unfortunately, or fortunately. In general, at some point, you have to do it. And it's a big leap over yourself, but which then helps in life a lot. >> Uh-huh. Let's return to development. Okay. We've figured out that, no, it's probably not necessary to separate development and business. It's better to combine them. In any case, at some level of development, if you want to develop, you will come to the point where you need to know the business domain and the business part. But with the advent of AI, it seems that even an average developer has encountered, well, not business, but at least management, in which one needs to understand the product. Because at least you are managing a tool that generates code for you. >> This is an obvious example of the business part, the management part, coming into development. Are there any other things that await us developers in the near future? In your opinion? >> I think that, look, all AI-native products face the fact that, by their nature, this technology is unreliable. And each time with the same input, there can be a different output. This makes the system very unreliable. And many programmers are used to, well, what we like about programming is that the same input and algorithm means the same output. And it's not like that here. And this breaks the mental model, the paradigm, at first. And as a result, new processes appear, very similar to processes in managing people. People also, with the same input, the same person at two different moments gives a different output. And what do you, as a manager, start to do? You start to invent procedures so that they don't go left or right. You invent metrics to measure their stability and so on. That is, management has four functions: planning, organization, motivation, control. Uh, well, different classifications. I took one of the classifications. So you essentially start doing the same thing for agents. That's what everyone is talking about now, evaluation development, right, when you have to design evaluations, run them with every little thing and so on, that's planning and control. That's why I think that, due to the probabilistic nature of this technology, they are closer to people and to the problems we have with people. And therefore, the processes that we invented for people begin to have some analogy in such systems. And we, as developers, have to, uh, this, well, for example, yes, one of the prompts that we can write, which, if, well, not prompts, but guardrails that we can write for an AI-native system, is that if we, for example, qualify an incoming lead, uh, by some, classify them, I apologize, probabilistically, then the sum of probabilities should equal one. It's better to write this in deterministic code, like a guardrail for a probabilistic system that will perform the previous steps. And if not, then send it feedback and say: "Hey, you made a mistake. Let's make it one." Because even if you wrote it in the prompt, it could still give you more than one, like my classmate on an exam in probability theory. So, yes, there are many analogies, and, honestly, I don't even know all the analogies yet. We are probably all collectively developing them now. >> I mixed things up a bit incorrectly in my previous question. I mixed business and management. AI brings more management to development. Now >> if you're going to work with AI, please study the approaches and principles of management, because you have a partner at hand, and soon not just one. >> Yes. >> In your videos, in your presentations, you often talk about the transformation of product managers, and you even have a role called product engineer. >> Yes, yes, yes. >> Can you elaborate a bit? It's clear that one needs to watch the videos to fully understand the concept, but still, if possible, briefly explain what a product engineer is. >> And how similar is this product engineer to a project engineer? That is, an engineer who became a project manager, not a product manager. It seems like they work without much business. >> Understood. Okay. Look, let me give three examples where this is very relevant. For example, from the perspective of a developer who wants to start a startup. Okay. Then I'll do it. I'm a developer, I'm creating a product according to a technical specification. >> And the third, let's take. I'm a product manager, I don't have a developer. Here are three such cases. If they are interesting, I will give these three perspectives. First perspective. I have a product idea. I need the product myself. So I'm sitting and building it. But I have no idea how to calculate profitability, whether anyone needs it or not, how to promote the product. And I can't go and study for 4 years to become a marketer or something else right now. I need it right here, right now. >> AI, which has the internet, but can tailor all that knowledge to your specific case on the fly with varying degrees of accuracy, can explain to you, for example, how to calculate economics. Or one of the lectures I'll post, excerpts of which I posted the other day, is what we're doing there? We're doing a pre-test of an idea, a business idea. Someone wrote that an entrepreneur does what people need. Absolutely, >> correct. But what are we doing there? We're prompting different user segments with an LLM and organizing a virtual user board, which is called a user board, where a marketer interviews real people and says: "And we're doing it with an LLM." Because in LLMs, there are guys from Reddit, guys from Twitter. If you correctly prompt a persona, you'll get 70% of the insights. Or, >> you need to prepare a presentation for an investor. >> We're launching deprsearch too, in one of the YouTube channels. Watch it, I show how to do it there. You can calculate the market or ask. >> Because in the initial formulation, the idea is almost useless to anyone. You need to modify it, but you shouldn't forget that, of course, there can be mistakes, including due to hallucinations and so on, but it's cool and simple. I once said that I don't understand why VCs still ask for pitch decks, because, in principle, a pitch deck is made in deprsearch, and I don't understand why to spend time on it and so on. So here's from the perspective: I'm a developer, I want to make a product, but I don't have a CEO or a designer, right? We are now seeing how design as a function is also quite good. I just took a screenshot of an interface I liked at a hackathon and told him: "I want these same styles." In short, >> so this is how it is. Let's move on. I was given a technical specification that needs to be implemented. Often, a business analyst, if I worked in custom development, then I know a little about how it can be for some of you, a business analyst or the client directly formulates the technical specification, and you have to implement it. But very often you have questions about it, and some questions are stupid. Stupid in the sense for someone who is in that industry, but unknown to you, because you've never encountered, I don't know, how VAT is calculated, for example, and you can ask to explain something to you in a normal language. >> in a language understandable to you, not to the client, because the business analyst writes in a language understandable to the client first, right? Then there's architectural, functional design, and so on, right? Requirements, but my key point is that this process, you, >> and second, you can skip the business analyst altogether. You can communicate directly with the client and resolve these misunderstandings with AI as a facilitator of this work. >> We are now doing, for example, such an agent that sits in Zoom and suggests what you forgot to ask. Or if you're talking to someone with an accent you don't understand well, it will help you, or it goes into the CRM and pulls out information, understanding what you're talking about from the context, and suggests it to you like a teleprompter. >> Very familiar. I have a pet project that prompts me in my ear during interviews about what questions to ask. But it's still very basic. >> Exactly. Yes. >> So all of this, this is for someone doing according to a technical specification. And the third, a product manager. Well, here we have no-code, I think everyone is familiar with it to some extent. >> Well, what happens is the same as what happened with the internet with, well, with, uh, with HTML with websites, when WordPress started appearing, CMSs. Remember when a website used to cost $10,000 to order? That's what, uh, Takovinin essentially built AMCRM on. They initially did custom websites, >> but then WordPress appeared. Who remembers, there were geocities.com, narod.ru, and so on, blogs, blog platforms. So the same thing is happening, but with a deeper level of complexity in the capabilities of these products or websites. >> Yes, >> there's a small comment here. It needs clarification. The first two cases, when I'm a developer, I want to start a startup or have a technical specification, >> yes, >> some will say that they are exalting developers, because in the first case, we replace designers, SEO, everyone else, and it turns out that they are so easily replaceable? You can just go online, read with an LLM and that's it. The second case, you replace business analysts, you unload the product owner a bit, as it were, you put development at the forefront. Well, let's say in the third case, you say, for no-code, the option of no-coding remains, but in my opinion, with no-coding, without technical knowledge, you won't even get an MVP of a moderately serious product. But without a designer, without SEO, without a business analyst, being a developer, you will get a decent MVP and everything will work. So isn't this leading to discrimination against everyone except developers? >> No, now, I think it will be a mutual parallel process. Remember when you said that you still need a supervisor who is technically savvy, well, for AI, because he has to ask it to do caching, ask it to do decoupling, and so on and so forth. >> And this is indeed the case. So such a person is needed, and therefore developers will be needed. But if we are talking about the idea testing stage, I am currently running a course for non-technical people. If you want, I can open it later. Yesterday I posted another one of my no-code projects. We are doing it as part of the course. I'll show you. You'll say that for a prototype, it's quite good. >> Because it's not a static prototype. It has a backend, well, a backend in the form of a function that calls OpenAI and a Superbase database. And it all >> and the product manager without a technical background worked with the AI, with Superbase and >> su Well, there's just a function on Superbase, >> but he no-coded all of it, >> you understand this lecture that someone mentioned about from idea to prototype in 2 hours. There I show a static prototype in the end, but now in the second one, I just taught them how to connect Superbase. And this Saturday I will show how to call an LLM to give intelligence to the prototype. And this is already an MVP. What I'm getting at is that at a certain stage, the idea verification stage, you don't yet need architectural skills to create a stable system that can withstand loads, cache, not make unnecessary requests to OpenAI, and so on, save tokens. But at the idea verification stage, it's okay. And if you reach the money, and that's the hardest part, then energy appears either from use or from payment. I don't know where else to get it. External energy for you to do a project or product. >> So, to reach that point, no-code is already of decent quality. And I see how it is rapidly improving. >> I have a slight gap in understanding your theses here. I will try to reproduce these theses, and you can clarify, maybe how you see it. On the one hand, you talk about a product engineer, when you talk about a product engineer, you explicitly say, I can find a link if needed, that it's probably better to be an engineer and then get product skills. This will be the ideal product engineer who will bring everything to completion. On the other hand, you advocate for AI and show with your examples that it is now more important to shorten the path from idea to MVP to find money, and then, if necessary, we will get architects and everyone else. And in this paradigm, a product engineer with product engineering skills is more useful, because they will clearly bring the project from idea to MVP faster. >> I am not contrasting, my key thesis is that >> this is the merging of what was previously considered different skills, they are getting closer and closer to each other. There is this, like, famous designer who wrote a great book about Simplicity. He had a great presentation. If you remind me later, I'll send it. >> About how the roles of designer, product manager, engineer, and QA are simply starting to, well, merge into one. And whoever

There will be more than one background, so they will be better at this, someone else. But they, uh, you see, in the second stage, they still need to interact. Therefore, I do not discriminate. I believe that this is a mutual, reciprocal movement of merging these two. >> That is, it is a movement along different paths from different starting points into something new, a new profession, if you will. >> Yes. Yes. So I think that this is a profession, I call it AI Product Engineer for now, because it has both product and engineer. >> Uh-huh. Okay. So, good. Let's move on. Uh, we've more or less figured out development. I have a question for you, someone who sees how this all happens in development and in business. Uh, how do you see what a technical leader in a team should do, well, a project manager, maybe even a product manager somewhere, so that the team uses the available tools effectively and doesn't just get hooked on them, you know, just take a cursor, use everything. And then the developers stop their development, thinking that they are the pinnacle of creation. But they somehow need to run forward, they need a lot of other things. Yes, >> to throw in. How, how is this, how is this solved? How can management influence developers' desire to put up with all this and learn? >> Let's start with the freshest example, and then a more abstract answer. >> So, I, maybe you saw, I wrote a post about Claude-Code, how I spent my weekend with Claude-Code. It's very important what mental blocks I had myself. That is, I have the same problems. I wrote this post, forwarded it to our internal group chat and said: "Guys, be sure to try Claude-Code, it blows away Cursor. Here are my impressions." Immediately, one of the developers says: "And how is it better than Cursor?" That's the standard question. No, he means: "And for what tasks did you use it?" I wrote, he says: "And how is this one better?" I say: "It's written in the post." He says: "Well, I don't know, I'm writing." to everyone. Uh, I know it's paid. Uh, don't even bother, we cover it. In general, just before our call with him and one more, there was a call. He comes out and says: "Can I talk for 5 minutes? Compared to Claude-Code, Cursor is some kind of underdeveloped guy." But I needed, first of all, to push myself later, well, to trigger, to throw in, and so on. So. And I think that for this, but along with this, it's important that the person wants it, yes, something new. And if we can do the first thing as managers, yes, we can even increase the desire to do something. So, maybe some of you felt a desire to delve into systems thinking when I started talking. That is, there is a function, communication, maybe and some motivation, but internal motivation is still important. Internal motivation to try. And yes, in some cases, our task is, you know, there's a framework in psychology that's used in products, that for a person to develop a habit, a combination of three factors is needed: motivation, ease of following the habit, and reminders. But the key point in this is the captain of obviousness. The key point is that you can compensate for the lack of one with an excess of another component. That is, if I have super motivation, even if it's very difficult, I still do it. But if I don't have enough motivation, if I make following the habit very easy, there's a chance it will become a habit. It's like, you know, two different cases with a gym. It's a challenge for everyone. I had a challenge. That's what I understood critically from this framework. If you have a gym in your apartment complex, you are much more likely to go there regularly than if it's even across the street. >> Yes. That's why I bought a barbell for home six months ago. >> Ah, well, >> I finally started exercising, for the first time in 35 years. >> Yes. So, here too, we, as managers and tech leads, can simplify the adoption of a new habit, I'll pay for your, uh, Claude, or motivate with additional messages, remind. Look what I've made with Claude-code. But we won't solve internal motivation, because, well, I deeply believe. And this is already a hiring issue. That is, what kind of team are we building, what kind of people do we want. And believe me, one of my big projects was that we had to continue supporting Netscape 4.76 in 2005, simply because the organization had to, because there were old computers and so on. You know, that was the most unmotivating job in the world for me, but I found people who didn't want anything new. 4.76, okay, I'll optimize the layout for this browser, you understand? So there are different people for different functions. You know, as I often like to say: "I wouldn't want a person who likes people at my border. Because someone will come, cry to him, uh, appeal to his pity, and he'll let them in. And it could be, you know, a criminal. That's why I'd want guys like, you know, not allowed, you know, like tough ones, because they won't let them through, even if they cry or whatever else." And so, each person with their character, yes, has their place. And the tech lead's task, among other things, is to assign tasks according to their character. If you want a person, >> we also face problems in teams here. Well, I also consult development teams on implementing development pipeline tools. And we encounter a problem that people reject them, well, some for religious reasons, so to speak, yes. >> But there are objective things. For example, a person says: "Why should I perform two, three, four times faster now? In your opinion, different people have different estimates. For the same salary, or: "Why should I not close tasks during working hours, and they'll blame me for everything, miss deadlines, and learn this tool?" It worked fine before. >> And is the only answer that if you don't keep up, you'll simply be replaced by someone else in the next hire. >> Ah, well, I think that >> that's one of the answers. But look, let's divide two things. This is sincere misunderstanding of opportunity >> and sabotage. It seems to me these are two fundamentally, you know. >> Well, with sabotage, it's clear, here, you know, dismissal went further. No, >> I mean that sabotage happens, well, maybe it's too strong a word. Uh, you know, I might not want something new because I don't have the information that shows how much better the new thing is. >> Uh-huh. Uh-huh. >> Status quo. That's the first. And sabotage is when you give me rational arguments that you're doing competitions, let's sit down. I just have one of my friends, acquaintances, did something like this, they just sat down and had a competition. Because they were tired of this. Yes, I'm faster, yes, I'm just, you know, let's do it in parallel, one sits with Cursor, the other with the old way, and we do the same task that neither team knows. There, there are no questions left. It's But even after that, there will be those who say: "No, this is a degenerate case, you designed it specifically." With these people, I don't know what to do. But there is, I think, our goal is to convince those who are hesitant, through people who sincerely believe and have already realized or simply believe in the opportunity, to give them information, motivation, energy, but not to engage in. You know, when they put those turnstiles at the entrance of the bus, I was in Ashgabat then. >> Yes, yes, yes, yes. >> And everyone said, journalists: "Oh, they'll still jump over or go under." Yes, but 20% will, but 60% will start paying. Those who didn't pay before, when there were no turnstiles. This turnstile. Therefore, our task is not everyone, but those who are in between, >> to nudge. And here >> Yes, I understand, I understand what you're talking about. You're mostly talking from a business perspective, and that's quite understandable. I'll just clarify that I'm speaking from the perspective of, probably, hired workers now. >> Cool. You understood that it speeds you up. You saw examples, you were inspired, you went to work. After all, why do we go to work? Not us. But why do many people use tools to either relieve themselves and >> meet deadlines, for example. That's great. >> Possibly to take on more interesting tasks. >> Yes, >> that's great, yes. >> And some just do it to, well, get the job done in less time, yes, and for the rest of the time, well, they'll find something to do. We're all remote now, >> yes. Yes. And and it seems to me that the latter guys, in the sense of the last guys, there are quite a lot of them. >> Understood? >> And their point is valid. Like, we'll learn to work faster now, the business will see that we've all learned to work faster, and they'll come and force us to do twice as many tasks in the same amount of time for the same money. Why are we digging our own grave? I often encounter this argument. >> All right, I think two points. The first is what you initially formulated, which is that guys who are with this tool will simply come, you know, through competition, you know, you're not alone in the field, Vasya Pupkin will come who knows it and they'll hire him instead of you. >> Well, that means the business's tough whip comes into play, like, dude, we're running, and you just have to run with everyone. >> That's the first. And the second, it seems to me, is sometimes about, uh, making your work more pleasant, because I have such a problem, I don't know if you do, you know, if I know how to do a task, I'm so lazy to do it. If I know it in my head. And that's why I really like all these copilots, because again, to take, again, SQL database, again, to write data access objects, all of that, you know it, you know how, you know what needs to be done, and you want to give the task, leave, and you'll do more pleasant work in the meantime. Forever, this work is for you in the same company, if there is one. >> That is, you relieve yourself of unpleasant routine and take on more pleasant things, and everything is great. >> So, we sell AI like this. We tell them, for example, they need to fill out the CRM after a call or meeting. We say: "We'll fill it out for you." You know how happy they are, because all salespeople hate filling out CRMs. But accurate data in the CRM is important for sales forecasting, for understanding what's happening with the business, and so on. And there's also, you know, a problem that they are, well, we are salespeople, you know, we are very optimistic, we sometimes say on a call that no one said there's a budget for this project, but we write, there are budgets. Therefore, AI also starts to play a role of, you know, reducing realism, with a reference to part of the transcript. So yes, selling through doing more interesting work. >> They're writing in the chat that there might also be a question about trust in management and transparency in decision-making. >> That's indeed true. And here, unfortunately, that is, uh, look, there's such an economic paper, I mentioned it in one of the first updates on GNI, which is on YouTube. In general, uh, that according to the history of technological development in society, in business, I apologize, specifically capitalist, capitalist systems, not socialist ones. Usually two from the code, I'll explain it to you now and it will all become clear immediately. So, technology can work in two modes. The mode of so-called automation, when we replace a person with an automaton, and the mode of so-called augmentation, when we improve the abilities of a person who uses these tools. And the essence, at least until AI, according to the history of economics, is that if it systematizes, then a significant portion of the value achieved by this, I'll give an example now, it will be clear, the value achieved by this tool, goes to the employee themselves. For example, all the pit diggers who retrained as excavator operators, their salaries increased for everyone. That's it. But there became fewer of them. That is, like, my point, or rather, the point of this paper, is that when augmentation happens, and so far, in the mode in which digging works, this is augmentation of the engineer's capabilities, >> noticeably, because, well, I think there are those here who work on a couple of jobs in parallel. I have such, >> yes. And I also have a friend, she also writes books, because now you can write books, you know. In general, you understand. Uh, but there is, uh, uh, when technology plays a replacement role, then all the value goes to the capitalist, that is, the investor, in general, the owner of capital. And the conclusion of this paper is that the task of regulation, that is, the state, is to ensure [music] favorable conditions for augmentation and to complicate it through taxes, yes, uh, this. That's why Bill Gates has been saying for at least 10 years that taxes should be levied on robots, because he understands this, this, uh, process. Or Sam Altman says that a universal basic income is needed. I don't really like the idea, but I understand for what segment of people this can become a very important moment. We'll see. >> Uh-huh. Good. Damn, so many topics, actually, that go off in different directions, I want to ask, but time is limited. >> Let's get back to development. The question is a bit, well, tied to what we discussed. In general, the developer is more likely to move into developing skills for multiplying systems, managing systems based on agents, on people. >> So he becomes a conductor of a large orchestra. Won't this lead to the degradation of fundamental engineering skills for the new generation? And how should they be trained, how should they work, when they have never written themselves what they are supposed to control and debug? >> That's a very good question, to which I don't have an answer yet. And I understand that a lot of experience comes not like, you know, there's such an economist Hayek. That's why I recommend studying economics, there's so much about our lives. So, he distinguishes two types of knowledge. One, I don't remember what it's called, let's say explicit, or let's put it this way. Codified knowledge, that is, knowledge described in some form, in a form detached from the source of knowledge. For example, uh, the Pythagorean theorem, yes? That's one type, and there's so-called tacit knowledge, that is, internal knowledge that is informal, not there, but it's like, you know, on your fingers, in muscle memory. And its key central principle is that capitalist systems are better than socialist ones due to the huge share of tacit knowledge. But in our case, in the question you asked, it's about the same. I understand how many things I learned only because I had huge failures, like, uh, I didn't batch requests to the database, and therefore in a loop it took several days to execute. Well, agree, it's probably written somewhere, but until you, you know, hit your forehead, you won't remember it for life and you won't ask Claude-code or your favorite assistant to do batching, because it's not guaranteed to do it by default. And how will this codification of this, >> well, acquisition of skills, skills, >> yes, yes. >> happen and be codified? That's a good question, for which I don't have an answer yet. Different ideas are proposed, for example, virtual worlds. That is, the main problem for robots is that if there's a whole internet for LLMs, then a robot doesn't have that much data, and it needs this experience. And therefore, Nvidia is going down the path of creating, well, simulations, that is, simulations, synthetic data, that is, synthetic data. Yes, yes, I've heard of such things, >> yes, yes. And therefore, perhaps one of the ways, but >> how to transfer this to people? That is, you put on a VR headset and spend 3 years in some university of the future watching how to crash a database, so to speak, in controlled conditions. Uh, so, first, let's say this. If simulations cover the entire possible spectrum of human experience, then, well, we won't have any tacit knowledge left. But it seems that it's quite a way off, especially where experience is gained over a long period and there are natural forms of regulation or time deceleration. I understand that it's a bit abstract. I'll give an example now, it will be clear. In general, they like to give this example, that you wouldn't go to any surgeon who learned to remove an appendix from paper, because some tacit knowledge appears. At the same time, we know how long doctors are trained, including to gain tacit knowledge, and so, and the price of error is very high, yes, death, well, human life. Therefore, there will be industries where regulation will not allow acquiring these, but there will be others where it will, especially if it's an industry where the validity of the result is easily checked. That is, >> that's why LLMs are good at coding, because, well, at least the first code you write, check that it compiles, at least, yes? That's already good, because how many tasks are there with an open correct answer? That is, it's impossible to know the correct answer in advance. The system is too complex. And so, I would probably say that you can try, I don't have this in my head, to formulate criteria for which experience is easily gained in a virtual environment and not easily. And try to classify according to these two principles and fear replacement where it's easy, where there are verifiable ways to check the correct answer, let's call it that, and the price of error is not so high, and other systems, other areas of our lives. That's probably it. But it's a cool task for a beer session to try to formulate these criteria, that is, classification criteria. A good task, probably. Someone already, maybe today I'll launch a search and listen to a podcast about what they think about it. It's cool. >> Good, thank you. If we dig a little deeper into this question and, well, a bit into more down-to-earth things that are already happening today. Juniors, juniors, juniors. We're replacing juniors with AI, well, not exactly replacing, but in a team, you can reduce five juniors to one, transfer some tasks to a senior, train them to do it. >> Everything is going very well with LLMs. And the question is: >> where will juniors come from, if we have no confidence that >> the current ceiling for juniors, which is hitting LLMs, a junior takes an LLM in hand, and their maximum knowledge is the maximum of today's models. >> How, how can they remain in demand in the market today? Or can this class even go extinct? Maybe in 5 years, we won't need juniors, middles, or seniors anymore, will multimodal orchestral agent systems do everything? I think the risk is definitely there. I don't know how to deal with this risk. I understand that a system should be created, now I'm thinking out loud, okay? I don't know the answer to your question. A system for transferring this experience from people to people, that is, from seniors to juniors, should be developed to train juniors. And this system could facilitate well. I'll give a couple of examples now. And let's, in general, if I were to create a programming course for juniors now, I wouldn't teach them syntax. I would teach them what batch processing is and why it's needed, yes? Just like the database case. But it would be great to teach them this in a safe environment, by designing an experiment in such a way that they, well, most likely, would encounter this problem. I'll give you an example of how I did it when I taught business. And it's, you know, well, when I was studying at Moscow State University, there was business, and I needed to come up with some form. Yes, I taught, well, I gave some lectures. And I liked it when, based on presentations, I tried to come up with some cool exercises. In general, one exercise I came up with, which actually teaches a very important skill to analysts, and not business analysts, but analysts in the consulting sphere, in management, teaches understanding. And you know what it was, I come and say: "Look, I'm a restaurant owner, I have a problem. The restaurant opposite is further from the metro. It has the same seating capacity. But it generates twice as much revenue. Ask me any questions you want, and then give a diagnosis, as is done in the Harvard method, and, well, in medicine and in jurisprudence. And the most important thing is that I didn't answer clearly to the questions asked, because your people in consulting projects don't answer. You asked one thing, and at that moment someone entered his office or he got a text message, and he starts. Do you even know how to cook pilaf correctly? That is, an analyst asks me a question, and I just know that in real life people don't answer you. And what could be done, I think, AI, to help design these simulation environments, to transfer this experience that the senior should formulate, to transfer it to juniors, so that juniors come to the company at a higher level, with, well, with a different set of knowledge, come to the company. But these are just thoughts out loud as we go, so not well thought out. >> No, very fresh. Very fresh. Cool. There's something to think about. Thank you. We're moving on to the final questions. They're a bit out of context for me. Well, >> let's, >> although no, not out of context. People asked us in advance, how do you separate hype from bullshit regarding AI projects, news, and everything else? Do you have any filters, developed processes? >> A very good question. I think that, well, as it seems to me, you asked the question in context, because it's essentially what we talked about in the previous step. You need to gain your own experience. Remember, I said I go to hackathons to try things out? Well, two weeks ago, I won. Excuse me. >> Yes, it happens. Yes, yes, yes, yes. From time to time. Yes. I generally, maybe it sounds awkward from the outside, but I approach hackathons very specifically, like, I don't participate in them just like that. That is, I go with a specific goal. In general, and there was a hackathon about memory. Now many people say that memory is the missing step to AI. I wanted to understand, first of all, what memory is, how it's implemented, why, where it provides an increase, and so on. As a user, I feel it a little, but as a product developer, no. And you know, the first revelation, although it sounds easy in hindsight, but believe me, it only occurred to me at the hackathon, is that all memory systems that are currently implemented are cancer. It's just a vector database that does it. And the main challenge is to understand what to store and where. That is, not how it works, but it's about prompt engineering, it's about understanding the business, well, for example, you understand that if it's a General Assistant, and I told it that yesterday I read a book on system dynamics, that's one fact. But if it's an AI assistant that teaches me system thinking, then that's a different fact in terms of importance and value. And it turns out that our prompts, our pipelines, we should spend time not on implementing this backend, but on deciding what information to store, for how long, and how effectively, how to rephrase different parts of the workflow, so that exactly those facts are extracted from this vector database, so that the context is adequate. Exactly. Context, then, >> yes, management and storage. And a very good question that we discussed with a PhD student, he's working on this at Stanford. We discussed with him the question: "Should such a system forget?" >> That is, we forget, how to make a decision about forgetting? And this is actually a very good question. He had the position: "No, we'll use the pipeline" to separate the wheat from the chaff. My position should be some kind of decay process, that is, when your memory gradually fades, as if, yes, so that there aren't too many candidates in vector search, yes? >> Understood. Right. And in principle, because in certain systems, for example, CRM data analysis, the lifespan of this fact is very important. And in some systems, it's not so important. And it turns out that,

Perhaps, simply a lifetime parameter, how much time has passed since the fact, this is, well, not such a correct parameter, because your name does not change, well, for most people throughout their lives. Even if you said it in the first interaction session, after a billion sessions, it should continue to remember. >> So, time does not always influence the most influential factor. Absolutely >> interesting. For different, in short, contexts, workflows, business domains, it is a much more important factor for making decisions about the importance and speed of fact obsolescence, if you want. And returning to your question, that's how it is. So, I try to feel it out first, to understand what's there, how it works under the hood, what's there at all, and second, to ground it in my specific, understandable problem. Why do I need memory for my automated sales agent? And when I answered these two questions, I returned to the team. They are not in the US, and I was just talking with saliva, because I finally understood how to use it. Before that, memory, okay, like, well, where is the breakthrough, and where is this, uh, perhaps, the experience of trying to ground something is one of the ways to hype reality perfectly. >> They are writing in the chat that all of this is similar, again, to the human structure of the human brain, in part. >> Yes, yes, only, Alexander, uh, uh, a person has an emotional coloring. That is, if this is proven by psychologists, that if it was emotional, I just wrote a book, uh, well, we wrote a book in the company on memory development, just for that and training. And I can specifically make you remember certain information, if I color it this time, for example, at this moment when I am talking to you, this information, in a second or in parallel, I will hit you. And you will have, in short, an emotional connection about this. And even if you don't use this fact, you will still return to it because of the emotional coloring. Therefore, yes, a person, in principle, is very similar, but there was a five-panel discussion, five people from Princeton, Stanford, they said that they are a little afraid of direct analogies with human memory, because human memory has its downsides. And again, it's a problem or a function, right? It's good that we forget some things, otherwise traumas would haunt us all our lives, right? So maybe it's good. And they are a little afraid. I'm not a researcher here, I can't say anything >> but there are analogies. That's for sure. >> Okay. One more question came in. It's a bit off-topic, completely off-topic, but I'm interested to hear your opinion. You surely know who Geoffrey Hinton and Eliezer Yudkowsky are. Of course, of course >> it seems like you position yourself as more of an optimist. Maybe I'm wrong. Closer, closer to an optimist, yes? So, if on this, what's it called, continuum, if on one side is Sam Altman, and on the other side is Eliezer, then I am closer to Sam Altman than to Eliezer. Uh, or >> Yes, yes. Uh, I didn't just call them technomancers, guys, prominent representatives. Moreover, Geoffrey, it's not like he's been in technomancy for a long time, but >> how much do you, as someone close to AI, to AI developments, take seriously the questions of, firstly, the danger of using these systems in the future, and secondly, the innovative, new ethical questions. Not the ethical questions of what to do when grandma ran over the car, but the ethical questions of what to do when we have AI and it's already a full-fledged >> member of this system, should we issue some new citizenship, love with AI, these kinds of questions. Do you think about this at all, or does it pass you by? For now >> I think about it a lot and consider it very important. I have this part in my regular updates on AI. Let me answer this in two leaps. First, 2015, Singularity University. We had such an exercise: a robot sued because the company that invented it released a new firmware and wants to erase its previous version and install a new one. It believes that it will be killed, and therefore it sued. You are the prosecutor, you are the lawyer, you are the jury. Let's go. >> Wow. >> This is what we discussed in fifteen with the input of Kurzweil and others. Imagine that. We were already thinking about, well, we weren't thinking, we were forced to. And I'm very glad for this experience, because now, when Eliezer or Hinton says something, it doesn't sound like, I understand the reasons why they or, for example, autonomous means of destruction, right? Should weapons make their own decision to kill someone? This is also huge. We also decided these things, actually. And there's another cool one, and then I'll answer. >> A very cool case. I just liked it so much. A robot that was supposed to look after an elderly parent did what the elderly parent asked it to do. And because of this, the elderly parent died. The children sued the robot manufacturer, claiming that it killed their father or mother because it did not follow instructions, but followed their instructions, not the instructions to preserve its life. >> Well, it seems that if the robot had subjectivity in this world, then all this would be very easily resolved. By a person, like legislation and everything else. >> We are approaching the very question about the boundaries of subjectivity, about what PTS, yes, with PTS we have responsibility for PTS. If our PT bit someone, I am sued, respectively, will it be like PTS or like a subject? My bet is that it will be like PTS, my bet. But I don't rule out that there will be communities, maybe countries, but communities for sure, that will consider it subjectivity and that they need to be given rights, and there will be huge opposition to this. Therefore, I say that perhaps it will simply appear as separate communities, you know, like the crypto community exists, right, that does things. I spent a month in Network State, in Malaysia, so I don't rule out that there will be such communities, but globally I'm more inclined to think that it will be like PTS, legislation, because, well, it will be a form, an attempt to protect humanity from the risks that may arise in connection with this. But I understand, well, for example, Larry Page and Brin, well, Page more so, that they are actually pushing more. Well, if it's a new evolution of humanity, then maybe it should be. I am still closer here to the philosophy and the central principle of the value of human life. That is, I am closer not to the utilitarian current of philosophy, but specifically to the fact that any human life is super valuable. Any, that is, but these are ethical positions, well, we will still see debates on these topics in some distant future, I think. >> Yes. Yes. But returning to that question, yes, in short, for me it's like this, a very important question, I think about them. And I follow what they write in model cards when releasing a model, and so on. I listen to podcasts about it, but I still remain on the sidelines, well, closer to the pole of optimists. >> Uh-huh. Okay. So, well, we should have ended with this question, but we still had literally two more questions at the very beginning that remained unanswered. They relate to >> your company, more to your experience in the company. They asked if it's possible to automate procurement and sell automation of sales to some, and automation of procurement to others, so that there is interaction between AI. AI? >> Is this your ultimate dream then? >> Well, not a dream, but I'm moving towards it, it's just that you can't embrace the unembracable. That is, we can't do this now, but I see how it's going. We even implemented something, you know? At a hackathon with a friend, in short, an anti-spam system, where, in short, AI determines if it's spam or not, depending on your preferences, memory, knowing you, like your double. And if it's spam, it says, pay then I'll read it, I'll forward the message further. We didn't win anything, but it was so funny to design this system. And everyone wanted it when we presented it. But when we were doing this, I seriously thought. And when Telegram announced now that if you want to write to a paying user, but you are not a paying user, pay, I think, something like that, right? And in the channel, I have it, I enabled it so that, like, direct messages, but paid. Why do I like all this? Because I like mechanism design, it's a direction in economics where you regulate human behavior through monetary means. For example, parking, the cost of parking is different at different hours, because you regulate the desire to park in different places at different times. Therefore, actually, I think that, well, such a, like, I lost my train of thought a bit, but, in short, globally, we made such a cool system that, yes, buyers, agents communicated with sellers, agents, and then, when they agreed, people already, well, they make the final approval, I believe in that. And I really love my, not mine, in the sense, to mention this anecdote about the old and young Vizier. Maybe you know it, when, uh, the young Vizier, well, yes, I'll tell it very briefly, you can google it later. In short, the young Vizier comes to the Sultan and says: "I want to be the chief Vizier. I can already do this and that." He says: "The Sultan listened," he says, "there's a caravan going there, find out what they're carrying." He rode off, came back in an hour and said: "They're carrying silk." He said: "And where to?" He rode off again, then found out and said: "To such and such a place." He said: "And for how much?" And in general, he went like this, because he didn't gather all the information at once and ran or rode quickly. But the old Vizier slowly reached it on a donkey, found out everything and comes to the Sultan and says: "Sultan, in short, there's a caravan going there, they're carrying silk from China to Venice. They're ready to sell it for 50 cents. I persuaded them for 30. We're buying it, understand? Yes. And I think these buyers, and sellers, they'll chat, and then they'll come, in short, we'll sell to one, and buy for the other, in short, and we'll give recommendations, like people. That is, I believe that systems can be created in this direction. Yes, >> well, they are already being created, unfortunately, perhaps unfortunately, more for military purposes. And there, decision-making systems are everywhere, >> yes, and drones, we know, fly themselves, and people make decisions. These are cutting-edge technologies. Well >> we'll see how it develops further. So, and there was one more question at the beginning. What mistakes do beginners most often make when automating with AI, particularly in B2C? You are close to B2C now. In short, I don't know B2C well enough, but I would say one mistake in B2B that seems relevant to B2C. It's the belief that the technology works very well. In general, the absence of Human in the Loop. That is, all implementations, I immediately say, like, the customer even wants everything super cool. I say: "Let's first put a person, so that after we see that the system is improving, when the metrics show that almost all the emails it suggests to write and messages are satisfactory, we will reach that figure." We will have 99.9, and we will weigh the cost of error and, and the opportunity. And if it's the cost of life, we can't. Even if it's 99.9. And if it's that we write the wrong email to someone, we can afford 70% accuracy, because, well, okay, we'll spam someone. Well, I understand, well, the idea, I think you understand. Therefore, I would say, this is definitely mistake number one. Second is to stuff the agent with context, in short, lack of decomposition. Uh-huh. >> In general, the LLM dies when there are too many tools in the context that are semantically similar, and it starts to confuse them. And this is just a mess. Therefore, decomposition, as they taught in IT system design. Reducing the context dependency of LLMs. Normal, >> yes? Yes, yes. There was a cool paper recently, from the LangChain guys. That even the names of the tools should be written differently. That is, like >> we encounter this in practice, yes? Similar tool names and that's it, your cursor is already falling when you connect similar APIs. >> Yes, yes, yes, yes. Fortunately, they now have the ability to disable only the necessary tools. But yes. And this second one, >> uh, and, probably, this is important, too early delegation of the workflow to the LLM. That is, you know, yes, we can build a graph on, say, LangChain and deterministically switch execution paths. Or we can >> stuff tools, yes? So, too premature delegation. This is from some immediate things, but there are more. 100. >> Well, this is about building this ship we talked about at the beginning, instead of doing it in small working chunks. Including. But I think it's also about not understanding the nature of stochastic systems. >> Uh-huh. >> and expecting higher reliability from them where they cannot guarantee it. And this, I think, is important. That is, you can make this mistake subconsciously, because you are an optimist and so on. I like it, we have a developer in our team, he, Lesha, he's always like this, Bayram, let's go deterministically, let's go. That is, he grounds it, because, well, sometimes we can really, uh, this, but at the same time he can lag behind. And therefore, it's good when there is, well, we call it a black hat and a green hat. Black is let's go slower, green is let's go forward. And, like, when there are both, you can, well, somehow reduce the probability that we will mess things up. Hackathons are cool. You can mess things up at hackathons, in short. >> Yes, I agree. Okay, thank you very much. Exactly on time, we finished. I will post all links to the Telegram channel, to Bayram Anakov's YouTube channel in the description as well. All links, Bayram, if you need any additional ones, send them too. I'll put everything in. >> Yes, agreed. Yes, >> thank you all very much. Everyone, bye and good luck. Bye. >> Thank you for watching and listening to this interview. If something from it was unclear to you and you have this imposter syndrome in this era of AI, then join the Code Evolution club. It was within its framework that this interview with Bayram Anakov was released. And in the club, together with over 700 other programmers, we learn how to be effective in AI and how to be in demand in the market. There is basic information, basic courses. There are many workshops, there are also interviews, there are two-week calls, I do constant news digests in text and podcast form. Well, and a very active community of people. We discuss all the latest news, use cases of AI application. In short, if you are looking for a place where you can find all the information related to AI development in one place, I am waiting for you in Code Evolution. I assure you, it will be the best investment you make to improve yourself. See you there. [music]