When we first started, it was I want to become a billion dollar company. When we got to a billion, it was okay, let's become a $10 billion company. When we went public, we wanted to become a hundred billion dollar company. We dropped 92% in the first 18 months of being public. That dream seemed very, very far away, but post Axon 2, we recovered and now we're hundred billion dollar company.
Once we able to make prediction more accurate, advertisers see better returns and our business grow. I don't want our engineer to see it next to AI. I want our engineer to see it on top of AI. Our team was elevated by AI. So we were able to manage the same size of the team while we were solving more challenging problems. I would attribute the success of Axon largely to what we decide not to do, not actually what we did.
How are we going to become aware of...
Adam and Gio, welcome to Sorcery.
Well, thank you for having me at Applovin's HQ. We're out here in Palo Alto. This is Palo Alto, right?
Okay, cool. So, Gio, you are the CTO. Adam, you're the CEO. But I wanted to do something a little bit different. I'd listened to a bunch of the podcasts you had before, and it's very apparent you guys have an amazing underdog story. There was one that I caught and it was towards the end of the interview when you started to reveal the guts and the machine, the engine of what started to propel Applovin to become one of the most efficient, well-performing companies out there. You guys have great margins, you're very profitable, all this awesome stuff. But it started when someone started to ask you hard questions. And Gio, you were that person. So you joined the company in November 2022. What was it like when you first joined Applovin? Like what were your first impressions?
So my first feeling when I joined Applovin was definitely a mixture of excitement and the sense of responsibility. So in the beginning first of all it was like a breeze of fresh air. So I came from big tech companies. The process there was much heavier. So I joined Applovin and I saw the team here is very lean. Both Adam and CTO Basel at that time they were deeply involved into the day-to-day decisions and executions and it was easy to work directly with them. They're super approachable. So that feeling was refreshing. But on the other side, soon I realized you know in the company, the company was small, a lot of things—the models, the infrastructure, people's mindset, the way they handle iterations—had a lot of room to grow. And more importantly I feel the biggest problem at that time I observed was the junior people in this company was not elevated, they were not given opportunity to understand the business.
So they were given a lot of low-level tasks without the ability to have their own ideas and raise questions, right? But the good thing is that time I didn't you know take this thing with negativity. I wasn't frustrated. I wasn't disappointed. I saw it as opportunities and that's why I joined Applovin. And I was also glad to see that the whole team at that time has very open mind and when I brought a lot of feedback to the team and new ideas and people were very willing to work together so we took that as opportunity and started to improve, like make changes and improve.
So going back to Gio's hiring, in the interview process because the old CTO and myself both interviewed him. We were at that point somewhere around a $5.5 billion company when we started talking to Gio and we had a model that powered our advertising business, Axon 1 model, and it was written on outdated machine learning techniques. And so we were looking for a researcher to come in and help us architect the Axon 2 model which we released I don't know probably five six months after Gio joined and he was the architect behind it. But so we liked Gio a lot in the interview and both of us gave him the hard pitch on joining and then so he was excited to join and I go do my this was November 22 earnings call and he's supposed to join I think it was like a couple days later, stock went down 30% that day. And I'm like damn we might not get him. I don't know why he joined us, but he's one of the weird people who say, "Huh, it went down 30%, so I'm going to get more equity. Now I have more upside in this thing. I should join, I should even join quicker." And so I don't know, we were lucky that you ended up joining us at that moment.
I wasn't thinking that way, but you know, I was in big tech. If I just wanted to stay on the winning team, I would have not chosen to leave. I wanted to find a place where I see opportunities and I can actually make a difference.
So what were some of the big questions that you started to ask?
I mean I guess I didn't start asking questions. I know what my position is when I joined right, I saw all those gaps and there were not a great model at the time but before training the model you need to have the right infrastructure for it. So my first month here I actually just started writing code. It was very easy. I was working directly with Basel. We did not have a lot of meetings which by the way in the beginning I was not very used to it. I asked Basel set up weekly one-on-one meeting with me and he didn't understand what that was because it's not a thing here in Applovin. But as soon we cancelled that meeting because we communicated with each other mostly with code and that was much more efficient.
Yeah. From I guess taking it back to like when you start a business teams are always small and you try to build something that has product market fit and scale up a company and so when we started I mean the company was probably 10 people at the beginning and then maybe for the first 3-4 years max 50 people so we always ran really lean. And an advertising company, if you can't make money then you probably shouldn't be in business, doesn't make any sense because you're trying to deliver value to advertisers. You get paid for the value you deliver and in theory that should generate you something more than what your costs are. And so we were profitable really really early. We had difficulty raising too so we had to be profitable really early but the leanness of the culture came from the beginning.
Now the types of people that we hired back then, Basel the CTO was the first lead engineer and then promoted to CTO four or five years later but his mindset was I'm just going to do and he would just write code to solve every single problem and up until when Gio joined, Basel probably wrote I don't know 60% of the code of the company like himself and the mentality was always individual contributors can help us succeed in this very very competitive field and so we never built this framework of like one-on-ones and meetings and process.
And so I think that was what appealed to Gio when he came in. One of the challenges with that style though is that when you don't have like a team constructed to actually like go through challenges and solve problems as a group. And he can talk about like as we've gone over the last three years in his tenure, he's really developed that muscle. But my own view just being an individual contributor myself was always hire a bunch of great people, let them solve problems. If they need help, they can come to us and we'll give them help. But otherwise, it's sort of like just off to the races. And that was what Gio stepped into.
How big was the engineering team when you joined?
It's probably same size as now.
How big was the organization?
Company. So, back then we had gaming businesses too that we've since sold off. So not including those and not including Adjust, which is a software as a service company we bought, never integrated. I'd say the company's been around 400 people for a while. And about two to three years ago, we probably cut it down from 600 to 400 and we haven't really changed all that much since and people come and go, but that's what you get.
The other I think interesting thing for Gio when he joined was he came in and we created the Slack room and it was Basel, Gio, and myself and we talked through the problems and it was like just real-time feedback. And then I don't know if him and Basel even saw sun for those five six months because they were just coding and racing against each other. But the dynamic was like okay well this is a new path so we're effectively rebuilding the engine of the company. We don't really care about what exists. Everything else that has been built, the data platform, the software tools for developers called mediation service, all these things that we had as assets were separate. But this core engine, this algorithm, they were completely rebuilding. So they basically went in to I don't know where they worked out of. I know where Basel worked out of. I don't know where Gio worked out of, but they just went in and just started coding against each other and racing to like get to a direction that they thought was the right place to go.
And it was cool for me to see, I think it was different for Gio to see because he was used to much bigger processes around what engineers could and couldn't do at companies. And one of the first things I told Basel when we first started developing this company was technology moves really fast and you got to be humble about what you have and know that if technology goes faster than what you've developed, you got to throw away what you have and rearchitect, rebuild it. And it's probably going to happen every couple years or even faster in the future. And that was always one of the core things that we believed on engineering is who cares about what we built? Let's always make sure we're on something that's current or innovative or cutting edge.
So you have a lean team. It's about 100 people on the engineering side. Everybody's quote unquote an individual contributor. What was the process like for architecting Axon 2?
So when Axon 2 was being architected the team at that time was very different to today, right? So I'm going to explain what happened that time. When I talk to interviews a lot of time people are very curious about how I did to change Applovin but very rarely people ask how Applovin changed me.
Actually when I joined Applovin that was a change for me as well because the moment I saw how Adam and Basel work, it just like gave me a new definition. What does it mean to be hands-on? I used to be hands-on. I loved writing code but joining Applovin just saw a totally different level. So initially when I joined Applovin I actually planned to join two months later than my original date and Basel and Adam were trying to convince me to join first. And I said I already have a planned trip to Europe for a month for the Christmas. I wouldn't have much time to work during that month anyways. How about I join after that? But Basel insisted that you can just join for a week, do a week of work and you go on your vacation. And I say okay fine. But that week fundamentally changed me because after that week I decided not to cancel my vacation but to work through my vacation.
And I still remember what happened that time. It was the moment that ChatGPT 3.0 just came out but it was definitely not enough to write code for you at that time. So we still have to write code in the traditional way. I was on my flight to Italy and it's like 12 hours of flight and I had to continue to code at that time. You know people still know how to code without agents. I don't think you can still do that without internet today. So I was on the flight, there was no internet, I was coding the Exon 2.0. At that time I was building the training infrastructure and at a certain point I need to check a document, I need to Google search some information about the tool I was using but I was on the flight I have no access to internet and I had to force myself. Luckily on my SSD I had access to the source code of all the libraries I was using so I had to go deep into the source code try to understand how things work. That was a pretty interesting experience.
At that time I was asking myself like a man is giving infinite amount of time because I was literally trapped on the flight, you know the time was infinite but I have no access to external help. But I just keep coding and when I was in Italy during that amount of vacation I kept coding. My in-law, she's a lovely Italian lady, she couldn't understand like why anyone has to work that hard during that vacation. She kept asking me, "Hey Giovanni are you okay? Are you losing your job?" I said no no no I'm just very very passionate about what I'm doing. So surprisingly you know, initially I thought I was actually starting working at Applovin in 2023, but by the time I came back from the vacation we were already ready for the infrastructure part of Exon 2.0. The moment I came back we started training the first generation of model.
Oh wow. So that was a big reset for you.
Yeah it was a reset. I feel like that kind of philosophy is already there in me and I definitely love that at the most. But just prior to joining Applovin I didn't have a chance to experience that kind of working mode and that month just made me feel this is a place I love to work here.
So big tech is very different.
It was very different. Yeah.
Damn. And then in terms of rearchitecting the actual algorithm and building out this algorithm because it was a huge major inflection point for Applovin, what was that like for you?
So let me go a little bit deep about what Axon 2.0 actually is. You know the problem that a recommendation system is trying to solve is actually you have many many users and you have many many items and the combination of each user and each item is enormous and the recommendation system has to study the relationship of each combination.
Before, the last generation model tried to model this by clustering those combinations into different clusters and build this tree-based model that's basically a huge set like hundreds of thousands of if-else branches and then each cluster of user-item combination sits on the end of this if-else branch. But obviously as you can see the real world is so complicated and the relationship changes dynamically as time changes, as the weather changes, as there are like promotion events, holidays, all the things are changing and these tree-based models are not able to accurately model this dynamic relationship between user and items.
Axon 2 uses an approach that uses this concept. Nowadays people are very familiar with this thanks to the language model. It's called the semantic embedding. So basically we use the learnable embedding tables to encode those IDs, like item ID, user ID that otherwise would make no meaning. We encode these IDs into semantically meaningful embeddings and it carries statistical information and then we pass those information through deep neural network that allows us to study this complicated interactions between user and items.
The result of this kind of model is it is much more powerful in recognizing the patterns and it's also powerful in extrapolating these patterns to unseen data and unseen user-item pairs. And once we built this, our model is able to make more accurate predictions. It was actually also cheaper in terms of infrastructure. So once we able to make prediction more accurate, advertisers see better returns and our business grow.
This just has to do with some details of how the model is being inferenced. The neural network, the benefit of neural network is it's made up of a lot of standard GMM, basically a general matrix multiplication which you know is famous, the GPU is highly optimized for this kind of operation. But the selection tree, the old generation selection trees has a structure that is very hard to optimize on a GPU machine. So the new generation model is very very powerful and efficient with a modern GPU architecture.
So you're not token maxing.
We're not—token maxing is a concept in large language model. It's a different term.
I, every time I hear Gio talk I have to put in LLM. Translate what Gio said for me.
So Adam, can you translate what he just said?
I'm not smart enough unfortunately.
But I'm really curious. Okay. So as you're talking about deeper infrastructure and the deep learning that occurs within the model and the tree and that kind of thing. Okay. You pull out what are the main categories of data that you're trying to build patterns off of?
Basically the type of data, the most important data is the user interaction with the ads because every ad we choose to user is a important feedback data point for us. User either reacts to it or not react to it. If you collect those information that builds a very powerful prediction machine for the user next section.
It's also important to understand our ads and in this context we're not like just a static native or banner ad, the ads inside games are much more similar to what television is but specifically for games you have somewhere around 60 seconds that people sit on an ad and they're not just sitting there doing nothing they're playing mini games that we serve them so they're engaging in something that is representative of what they can go download and there's tons of interaction data that comes from that.
So if you think about average time spent on most websites that are really successful user spends call it 40 minutes a day on a really successful social property. If a user sees 10 ads on our platform a day that's 10 minutes of engagement with the website effectively that's like a mini-game serving website. Tons of data is able to be extracted out of those engagements.
What is more data that you have behind those ads? Because you serve to effectively like a billion people. I see this on your website. And they sit there for 60 seconds and they get served this ad. So what is the typical click-through? Like how do you determine that?
Well, you have the engagement. So you have how they're playing, what they're engaging with. Then you follow them through a conversion funnel, right? So we serve the ad, user engages with the ad, user goes to install or doesn't install. Sometimes people will just say, I don't want to engage with this ad at all. I'm not going to click anything on my device other than skip the ad. And so, that person just really doesn't like that ad. And on the other side of the extreme, someone might follow the ad all the way through the app store, go download an app. So, now you know, okay, this is pretty warm. They're interested in it. But just a download for us means nothing. We're trying to deliver to the advertiser engagement and revenue. So to get really hot, the user then has to engage very regularly and has to go generate revenue, whether ad revenue or in-app purchasing revenue for the customer.
The benefit of doing what we do is that we can serve the beginning of the conversion funnel and then close the loop all the way at the end. And the advertiser gives us data to help close that loop. And then the system can then take all of this data which across our business is a ton and put it all into this model to then determine okay now I've got one thing that this person's really hot on, what other users are like this person, what should I start predicting for that person.
What I thought was interesting learning more about Applovin is the business model is predicated on performance but it's advertising to make people more money so it's like can you explain like was it always like that. Were you always making advertising so someone could just build their business and like create this reinforcement system to put more money in it, get more money out, build their business, that kind of thing.
Yeah. Totally. It's—we want an advertiser to be able to spend money on our platform, measure it, and know that they end up getting more revenue and profit from the money that they spend. If you can give them a user and they make profit on it, then they'll scale pretty large numbers. You don't have to sell that through. And the reason why originally that was our goal as a company is that I realized I don't have an ability to sell all that well. Don't have the patience to go really build up a traditionally large salesforce. And this is what most advertising companies do is they just scale out the go-to-market team when they have anything that works.
And what we wanted was a system where the company on the other side just knows it works. So therefore, they want to put money in and we're delivering so much value that they're really desperate to work with us, not the other way around. We're not really selling anything through other than they're getting the user, they're getting profit, they're happy. What makes it cool to do that is that the platform ends up becoming much more catered to businesses that you almost have never heard of before. We get companies of scale on our platform that are small businesses to most, but have very large P&Ls, and they're able to do that because of a solution like ours. That always made us feel really good. It also fit the DNA of the company well.
When did you feel comfortable enough to switch not just on gaming ads but also extend into e-commerce?
It was about a year after we scaled the Exon 2.0.
I think at that time we realized the model architecture we had would work beyond just gaming, right. Of course there are new things we have to build—the new business, the new pipeline, the new product flows—but we felt that the core technology should be general enough to support different verticals.
Yeah. I mean, I think when Gio built and architected Axon 2, he knew that this was going to function for any vertical, but we always got the push back from anyone who's covering the business, whether analyst, investor, someone scrutinizing the business of, well, you only have gaming data, so how could it work? Well, one thing that people lose sight of is that it's a billion people on the other side, not a billion just people who are only playing games and doing nothing else. So, if you understand the person, then you can actually deliver value to them outside of just a game-to-game scenario. And you can only do that with a very sophisticated model.
The other piece of that is that you're getting advertisers sharing you data. This is what powers a lot of what Facebook was able to build over the years is originally when they went public there was this notion that you couldn't monetize the social network like how could you monetize this blank canvas. Well they have a lot of people and you start understanding the behaviors of those people through what people were doing on advertiser properties, you pixel websites, you get data. And so we took the same approach, started pixeling websites, started getting data, understood the user more than just their game behavior.
The user does a lot more and the people who were playing mobile casual games turn out to be a lot of heads of households. It skews slightly female, but it is this sort of 30 to 50 year old age group that's the heavy mobile casual gamer. And so we had this really good user. They're engaged with a really immersive advertisement and we started collecting the data that the model could interpret to make these recommendations and it just started working. But I think Gio had a sense that was very doable because he understood that the architecture isn't just looking at one vertical. It's not a verticalized model.
Yeah. And I think another important thing of having a great engineering team, the value of having a great engineering team is a lot of times you don't have to guess. These kind of things at the time we did analysis and discussions, the reasons to support why this is going to work, there are reasons that tell us why this might not work. So our solution was we just quickly build the prototype and it took us like a few months to launch the first model with some testing advertisers. The result was overwhelmingly good and that gave us this confidence that this is going to work and we started building.
What's your process for testing for testing the e-commerce?
Yeah. So in the beginning it was building not really testing, right? The building story was also fascinating. I think at that time the CTO Basel and there were some other senior leaders in the company were attending a Google conference in Vegas and on that morning we're having breakfast and we're discussing how do we build the first data flow engine for this new product and we're waiting for our menu to come and there was no paper so we just found a napkin and we started discussing and Gio designed on the napkin.
You probably did—do you know this story?
Did I never tell you the story?
Okay, you should talk more. Hang out more with us.
So, and then we were having this discussion and by the time the food arrived, we already have a pretty good design and then we all went back to our hotel room. Before we arrived in San Francisco, we actually had the first prototype for that data engine. And then it took us about a couple months to build up the data, the model, the infrastructure. And we recruited a few advertisers. I think it was the business team who found the advertisers for us and we put them online. Initially the model has very limited data. So the model was very premature but even with very premature model we're able to see people were making a purchase. The ROI, the ROAS was decent and we're like okay this is going to work.
What's cool about this story, which I'd never heard before, is that one of the cultural philosophies we had is almost no product management and have engineers that are competent enough about business problems to just write their own architecture, write their own product to solve business problems that maybe not even a business team knew existed. And so here, you're not hearing about a product manager that's talking to clients, that's writing a spec, that's handing engineers a spec, that's having them write code to spec. None of that happened.
You have engineers that didn't even talk to a business person sitting down together at breakfast on a napkin writing out a solution to a problem that we never even discussed and then something that could become a big business. And so I think the team still is constructed that way where I don't know how many product managers are on Gio's team but it's probably sub handful and the rest of it is engineers who are competent enough to know what they're going to go develop.
This episode is brought to you by Brex. You become what you spend your time on. And I refuse to spend my time on work that shouldn't exist. Expense reports, receipt chasing, and manual closes. The companies building what's next from Vercel, OpenAI, Anthropic, Granola, and Deepgram all made the same call. They all run on Brex. Brex is the intelligent finance platform that combines cards, expenses, and banking into a single stack with Agentic Finance built in. AI agents that handle expenses automatically, enforce policy before spend happens, and close your books in minutes. That's why Sorcery runs on Brex so I can spend time on building and not busy work. It's time to get Brex AF. Learn more at brex.com/sorcery.
Turing is training the next generation of AI with tasks that require real expertise and real-world judgment. That's why companies like Nvidia, Anthropic, Salesforce, and Gemini partner with Turing. Turing builds realistic reinforcement learning environments and data systems based on real operational traces, the kind of infrastructure frontier labs need to train super intelligence. Visit turing.com/sorcery.
So are you then working directly with the advertisers on tweaking it or making sure that it's working, not going to another team to ask how they're handling their relationship with that person to know whether it's going well or not?
So the communication with advertisers still through the business team but all the data and decisions, our engineers understand what a business needs, right?
Our engineers, you know, we have to talk to advertisers right, sometimes you have to schedule a call, a meeting. I think that's not a great way to scale our engineering team. We leverage the business team but engineers understand what is important for the product.
It's also like if you're delivering something like an audience to advertisers it's sort of hand-wavy on the result. There's no measurement of what actually occurred. And with engineers, to give them a path, you got to give them pretty clear metrics on is it working or is it not working. If you're living in a revenue based world, a return on ad spend based world, there's not much of a debate with the advertisers. Either they're going to put more money in because the return on ad spend is good or the return on ad spend is not good.
If someone's selling lipstick and the lipstick costs 10 bucks and it costs five bucks for them and they're going to have a $5 spread, well, they can't spend more than $5 on selling the lipstick. Otherwise, they're in the red. It's really easy to then put that into a formula and say, "Engineering, here's where we're at. We're either good or we're bad, and we need you to be here for this to be scalable."
Did you always have that intuition, or was that also built up?
I think that's definitely built up. Before joining Applovin, in my previous job I already carried both the engineering part and the product part of the work. As I shared in the beginning of the podcast, when I joined Applovin I saw that the engineers were kind of disconnected from business. So one part of my job was try to help our engineers to understand the full context right instead of assigning tasks to them and tell them to do exactly what they have to do. I show them how their work is impacting the business and because our engineers are very talented, once they are provided with that kind of context they have a much better sense of what to build.
What do you think the biggest mistakes are that people do when they hire on new talent and try to onboard them into these teams?
The biggest mistake? Yeah, I wouldn't be able to comment in general but I think on our team I think few mistakes could be, first of all not setting them the right context. I feel people usually will assume the junior people need hand-holding and therefore they only provide very granular tasks for them. But I think this is not the great way of helping them to grow. So I think that's one type of mistake. The other mistake, this is something that I recently learned is actually exactly the opposite. I feel sometimes when a junior team member does a good job, now we tend to give them too much encouragement without providing continuous challenging to them and then sometimes the ego will grow and then they will lose their humility and they stop questioning themselves. They'll become a problem for their early growth.
How do you continuously challenge each other internally?
Let me cover that prior question too and then we'll get to that one in a second. But I think the big mistake I've seen is people really handhold new talent and bring them along slowly. So one of the things that's a little unique is like whether Gio is an intern or a full-time employee just started maybe even right out of school, they can push code within the first week of being here.
And so one of the—I mean, end of the day, we're an advertising company. So, if we went to a really high IQ graduate out of one of the top universities and said, "You're going to build ads." It's probably not easy to go get them excited about this opportunity versus all the other opportunities they have in front of them, especially in the field of AI. And like here, they come in and intersection of math and engineering and they're building models or data and plumbing to support the infrastructure that we need to run the models that we have. They come in and they just get to deploy code. So, they get hands-on experience.
There's no process in front of them. There's a lot of controls in place to make sure their code doesn't blow up the whole system. But there's no process in front of them where it's go through all of this training and review this and this and talk to these 15 people who will bring you along in over 6 months and then now you get to be a little bit hands-on and year and a half later okay now you can push your first test here. Within a week they can push some test, they start getting results.
That moment is a pretty substantial dopamine hit. They get something that they developed or thought to develop quickly into production reaching a ton of users and they get real world feedback loop around it. And this isn't just engineering. It's on the business side too. We don't have the traditional training processes to bring people along. There's no training manual. There's no come in and someone's going to tell you what to do. It's we want people to come in and be very curious and learn for themselves. And at least my own experience in learning is like when I was told what to learn, I never retained anything. But when you're hands-on, you can retain.
And now in the world of AI, it's even more powerful if someone can come in and say, "Look, there's no training manual, but I'm going to sort of build my own training manual and prompt AI and start asking the questions they need, and if they ever hit a roadblock in learning, they go to someone on the team." Not only are they able to use their own curiosity to educate themselves and bring themselves along faster than others, they're able to say, "Look, I'm willing to raise my hand and speak up in an organization I'm new in." And we found by enabling that we're able to bring people along much faster than we otherwise could.
You've—sorry for interrupting there.
No, I mean that was a great answer.
You've been really hardcore on making sure that your team is AI active or AI enabled and AI first, whatever you want to call it. How do you evaluate people on that? How do you make sure that they're continuously upgrading themselves and upgrading their skills?
So for people of course I think the works differently in the business team comparing to the engineering team. I can speak about the engineering team. So AI has been evolving very rapidly in the last few years and but there's still a boundary of what AI is good at and what AI is not yet good at. For example, even today AI is extremely good at answering questions, writing code, probably also is good at doing research and helping you to shape your opinions. But still AI is not good at doing long horizon planning. A lot of work that we have to do today requires long horizon planning. So then we still need human to be involved. Maybe one day AI would be better at that.
So the way I see the relationship between AI and our employee, our engineer is I don't want our engineer to see it next to AI. I want our engineer to see it on top of AI. So as AI is improving there's a boundary between AI and a human is also moving. Previously AI was only useful for correcting the syntax errors when they are coding and then AI become better. AI can complete the whole phrase, the whole paragraph for your coding. And nowadays AI, you know, can just give it an idea and AI can write an entire PR. But as AI is improving, human just sits on top of it and focus on what AI is not good at. So because of this, I think almost every engineer's output and productivity has been dramatically multiplied in the last few years. And as AI is advancing, I believe the output efficiency of our engineers will just keep growing.
I asked Max Levchin this question because he's a hands-on CTO, CEO type, and he's super technical. I asked him, do you still think people need to learn how to code?
I think at this moment, yes.
But I'm not sure that my answer will keep the same in the future. Right. At this moment I think AI still make very often still make bad decisions or coding decisions. If our engineers are not capable of coding themselves they will not be able to judge and correct that mistake.
