チェスエンジンは書けるのにチェスは指せない：AIコーディングとスキルの衰え（第317回）

Thank you for listening to Data Science at Home podcast with Francesco Gattoleta. You are about to get cutting-edge insights from the people who are reshaping the world of technology with machine learning, data science, and artificial intelligence. It's time for Data Science at Home. Welcome to the show. So when I was a student at Politecnico di Milano, I wrote a program that could beat most people at chess, right? Now, I can't still play chess, right? I don't even remember how the knights move. There are knights at chess, I guess, right? There is a queen, I remember. Jokes apart. I don't know the rules of chess that much because I never played. So keep this in mind because I think a lot of developers today are, you know, becoming exactly that, you know, people who can build the machine that plays the game and can no longer play the game. And here's today's thesis in one line. Developers who hand their coding to

artificial intelligence are slowly unlearning how to code. And of course, Junior may never learn that skill at all. Now, before all the angry comments on YouTube and LinkedIn or wherever this episode will be published. Let me tell you this. This is not an anti-AI episode as never on this show. I'm not anti-AI. I use AI. I'm anti-AI hype. That's for sure. I believe that these tools are useful. So pretending they're not is hype, in fact. It's its own kind of hype. And, you know, for those who know me, they know how much realistic I am towards these tools. So this is an episode about what happens to a skill when you stop using it, right? So I'm going to break down this episode in different parts. The first is, of course, telling you what the problem is.

Then some evidence from some surveys and studies that have been conducted in a very recent time. and then the strongest argument against me which I will because I will try to you know respond to myself playing a bit of the advocate you know and a set of concrete habits that I put together partially coming from my book The Mythical Token Month which you can find on Amazon and on mythicaltokenmonth.com and some other Easter eggs that I prefer to share here in an episode and hopefully make it useful for as many people as possible. All right, so let's get into the episode. This is going to be quite meaty. Well, let me start from the most, you know, conventional of the statements. Skills you don't use decay, right? And this is happening for, you know, this happens for everything. You know, you start playing piano.

I played piano back in the days when I was a kid. then I stopped doing that and I cannot play the piano anymore, right? Speaking a language that you don't talk, you just study at school, and you never, you know, use that language in everyday activities. And, well, after a few years, of course, you forget and you stop, you know, being good at that language and so on. And now, of course, AI coding removes exactly the daily repetitions that kept developers sharp. So, you know, writing code is a motor skill, pretty much like any other activities, for example, as mental skills. So, for example, remembering the syntax, remembering the API without opening the docs, or that instinct that tells you where the bug might be hiding or is hiding, all of it is maintained by repetition.

So you stop the repetition and it fades. Like, as I said, the language that you studied at school and never spoke again. There is another thing that I want to mention, that these daily repetitions kept developers sharp. And the code that you today you are using and you're generating is in fact given by the sharp developers who some of them committed, some of them without consent, got literally, you know, raped to use an euphemism because most of the code is code that people never consented to use, to be used as a training material for this model. So you have to look at large language models today as this massive search engine. We can think about their reasoning, they're not, they're not, by the way, but you get the point, like these are massive models that essentially are compressing information and this information is, of course,

information that has been created by developers in the case of coding or authors in the case of documents and books and etc. So there is, there has been human activity behind this data. This, you know, goes without saying. I just want to make sure that everybody is on the same page here. There's no magic, okay? There is data that comes from someone and that someone was pretty sharp, apparently. That's why this code is working. You know, the code that you generate is in fact working most of the time. Now, there is a shifting role here with AR because the developer that moves from author to approver. So this is what we are noticing. And this is kind of the trend that we expect developers going towards in the next few years, if not already. So you don't write code anymore, okay? That's the general statement that I can tell.

you look at it and say yeah, it looks fine, right? So approving of course is easier than authoring and that's the problem that I'm going to make along the entire episode. You can approve code you could have not written, okay? So there is game studios some game studios are the canary here they are adopting AI code generation fast, under crunch, under budget pressure because these are the companies companies and institutions that have indeed a huge budget pressure. And so that's where the effect shows up first, but not only in that sector. In many sectors, this is happening and this is going to happen. We talked about this in an episode on AI in game development a while ago, the hype versus the reality. But same industry, next chapter, right? I'm mentioning also the game studios factor because I'm building one and we're also building

a video game without using AI. And more on that probably another time. Now, look at the aviation. Okay, this is one of the, you know, a very critical sector. It's not the most critical sector, but it's a very critical one. Pilots who rely heavily on autopilot lose their manual flying skills. And back in 2013, the FAA put out a safety alert about exactly this fact. And regulators now push airlines to give pilots deliberate hand-flying time, right? Software has no such regulator, at least not yet. So nobody's going to force you to, I don't know, hand-fly your code, right? And this is kind of a tricky part and kind of a silent one, because nobody notices the decay now, okay, not while everything works. You notice it when the artificial intelligence is wrong, is offline or out of its depth.

And, you know, that's the day the team discovers that nobody can debug, in fact, the system that they quote-unquote wrote, right? Now, the claim that I made in a very interesting episode, well, it's not an episode, it was an article that went viral on hackers news and many other places I will provide you the link in the show notes of this episode on datascience and of course on the YouTube description if you following from YouTube Seniors are losing a skill and juniors risk never forming it That was kind of the, you know, too long, didn't read version of that article. And that's a much bigger problem, if you think, for a simple reason. The reason that a senior has a reserve, okay, 10, 15, 20 years of handwritten code leaves a deep foundation, right? Of course, it erodes with time if you don't practice it, sure, but slowly.

And it can be rebuilt. If you have one of those crazy friends who know a lot of programming languages, and they know, for example, three, four, five languages, is learning the sixth one for these people is relatively easy, you know, because they know it's a matter of syntax, in fact, you know, knowing or learning a new language. Because many of the constructs and the mechanics of programming languages in general are already there, and they own this. They own the foundations. They know how computer architectures work. They know how memory management works. And so changing from language one to language two, it's going to be, you know, just like, okay, how do you do this? I just don't know the syntax, but I know what this thing is going to do behind the curtain, right? A junior has no reserve and skill forms through struggle, as we know. There's no shortcut to that. The hours stuck on a segmentation fault, for those who still know what a segmentation fault is.

the wrong abstraction you had to rip out or, you know, that's not wasted time. That is the learning. And AI, of course, removes the struggle and the learning goes with it. And then there's the apprenticeship. Junior roles were the place where people got paid to learn. And if AI does the junior work, well, you understand that the ladder loses the bottom rugs, right? Again, that comes from this article that went crazy on Aker's News, which brings us to the pipeline question. Every senior engineer of the future, let's say 2040, is a junior today, right? And so who reviews the ice code in 15 years if nobody learned to write it? Now you can say, yeah, sure, but in 15 years, we will definitely have a way earlier than that. we will definitely have machines that can write code perfectly.

Yes, they can write the code of the solutions of today, the code that solves the problems of today. But this stupid idea, in my opinion, is like that, yeah, in 10 years, we will have better artificial intelligence coding, much better at coding, and so we don't learn coding. True, but the problem is that you are making one big, big assumption, That is, the problems that we are solving in 10, 20 years are the same as today. And that's not the case. You know, if there is evolution, there is evolution in everything, even in the difficulty, in the challenges. Right. Otherwise, it's, you know, it's not fair to make that statement and that comparison. Like, of course, a Fibonacci series, a function that calculates Fibonacci numbers. Right. 20 years ago, optimizing that would have meant something. Today, we have so many templates for the Fibonacci function that it's a non-problem anymore, right? In 20 years, you know, you apply this Fibonacci example to many other problems that today are challenges,

and in 20 years, they're not. And they are using tools, you know, of new generation tools on old generation problems. That's what I see that statement from people kind of breaking. but with this said brain rot in seniors is a maintenance problem in juniors it's a construction problem and that's not just related to coding it's a general statement the building never goes up now let me tell you the story properly the story about the chess game because it really happened and it's the best way I know to explain all this and it happened to me and I'm the main character here now so let's put some framing Politecnico di Milano one of the best universities in engineering in Italy at least back in the days I think it still is Computer Engineering Faculty the Artificial Intelligence exam

that was the project of the year we were asked to do a list of things among which I chose a program that plays chess Now, the point, of course, was not chess The point was to study search algorithms from the inside Think about Minimax, Alphabet Pruning, A-star, you know, the classics And it worked, you know, with enough compute And I'm talking about 20 years ago It could beat people who actually play chess, right? Of course, not grandmasters, let's be serious But real players Now, did that make me a chess player? But absolutely not. I'm terrible at chess. I don't even remember the rules, for real. I simply cannot play because I never played. And, you know, I wrote the thing that plays, but I myself never did. And this is the difference because I knew chess as a search problem, okay? States, moves, evolution functions.

I never knew it as a game, you know, the openings, the intuition, the feel of a position the poker face when you are when you understand you didn't stake and you hope that your opponent didn't notice and so on okay that's mastery now take the AI assisted developer right they know their code base as a prompting problem right they describe they generate they accept describe generate accept and so on for hours burning tokens and money and slowly what they stop doing well, they stop knowing it as code, right? And this is the major difference. In my case, that was perfectly fine, because nobody ever needed me to play chess as a profession. A developer is paid to play the game. You get my point? So, when the engine fails, they are the one at the board. That's the difference, right?

Okay, now you can say, is this me just being nostalgic? Well, let's check. I want to give you some, you know, real numbers here. The early evidence points one way. Delegating to AI lowers comprehension. It hits debugging artists and developers misjudge their own productivity. Antropic, January 2026, the AI company, yes, Antropic Cloud, A randomized controlled trial called How AI Impacts Skill Formation. There were 52 developers. It's a very small sample, of course. 52 developers, mostly junior, learning TRIO. TRIO is a Python library for async programming. Half with an AI assistant, half without. That was the study. And then a quiz at the end of the experiment. Now, the AI group scored 50%. The hand coders scored 67%.

So the biggest gap was on debugging. And the speed gain from using AI, not statistically significant. Think about this again. Okay? So they learned less and they weren't meaningfully faster. Right? So the caveats here, because I always give you the caveats, small sample, and they measured right after the task, not six months later. But it was published by a company that actually sells AI, which makes the whole thing much more interesting than not, right? The second case is METR, meter, July 2025. You have heard this one on the show before and the one before that. 16 experienced open source maintainers 246 tasks on their own repositories With AI they were 19 slower and they believed AI had made them 20 faster so felt faster, measured slower the caveat, early 2025 tools

and many of them were new to cursor third case, Microsoft Research and Carnegie Mellon 2025, a survey of 319 knowledge workers the more people trusted the AI the less critical thinking effort they put in, the caveat, self-reported and not specific to coding. Now, the detail that matters most for this episode in particular, back to the anthropic study, how people used the AI decided the outcome, right? The pure delegators, and this is from the study I'm quoting, the pure delegators, you know, the one who said, write it for me and paste it and went out for a coffee, scored under 40%. Well, the people who asked for explanations or only asked conceptual questions, they scored 65% or more, right? Close to the group with no AI at all, if you look at the numbers. This episode is supported by OutShift, Cisco's incubation engine for frontier technology.

Multi-agent AI is in pretty much every enterprise roadmap right now, but there is a problem with that, and we are all facing it. Agents can pass messages, but they cannot think together. So these systems silently underperform through cognitive failures, things like misreadings, unverified claims, and of course, false consensus. You know, all the stuff that conventional monitoring cannot detect. OutShift by Cisco is building this fix, the Internet of Cognition, which is an open source foundation for building multi-agent systems from design to production, with shared contacts, shared memory, and guardrails to drive the results that we actually expect from artificial intelligence. So, read the paper, experience the demo, grab the code from outshift.com. That's O-U-T-S-H-I-F-T dot com. So, what does this mean?

This means that the tool, per se, doesn't rot your brain, okay? The way you use it does, like many things in life, right? Second detail, the authors point out their setup was a chat assistant in a sidebar, and that's the mild version. They expect the effects to be stronger with agentic coding tools, the ones, you know, that go off and write old features on their own. and that's exactly where game studios and startups are moving right now. That's why I mentioned that. So let's watch the numbers and let's keep them in mind and let's see what happens because these are alerts that I'm giving and of course, if you want to listen, whoever wants to listen can do and whoever wants to ignore and surf the hype can also do. We'll meet, time will tell. now let me argue against myself and this is you know the final part of this episode

where I try to break my own observations or opinions because you know the best objection deserves a real answer and what I prepared partially from the book and partially from this episode was essentially is a list of hints that I personally give about how to use AI properly without rotting your brain. Now, let me argue against myself, because, you know, the best objection always deserves a real answer. And I'm trying to play, you know, advocates here, devil's advocates, as they say. I've heard a lot of people telling me, hey, but nobody writes assembly anymore. You know, for those who don't know, Assembly is the lowest level programming language that you can write. That we were used to write back in the 90s, even though in the 90s many people were already writing C. But writing in Assembly was essentially skipping the compiler and sending instructions directly to the CPU.

So that was like very hardcore activity. when we had compilers what happened is that people could start writing high level programming languages like C, C++, Java whatever and then there was a compiler that translated that code into machine code for the architecture that you were developing so Intel or RISC or whatever now compilers made assembly skills rare and software got better sure maybe prompting is just the next layer and I'm the old guy complaining about compilers could very much be so here is my answer a compiler is deterministic and verified you can trust a compiler without reading its output I don't read the assembly my compiler produces and neither do you and please don't do that because it's a mess an LLM is probabilistic it's wrong in new ways every time

So, someone has to read the output. And abstraction works when you can stop looking. And this one requires you to keep looking. So, that's the major difference between, you know, to all the people that tell you, yeah, this is the regular evolution of things, and now it's called LLM, but back in the days it was called compilers. No, you know, that's a wrong statement, because compilers, as I said, you don't need to look at what the compiler is telling you. The second statement that I kept hearing around is, calculators didn't kill math. True, but we still teach arithmetic before we hand out to calculators. And the danger is juniors getting the calculator on day one. Again, it's not the tool, it's how you use the tool, and especially when you use the tool. Skipping knowledge doesn't make you faster. it seems that it makes you faster in the very beginning

but then at some point it will crash against a wall where you don't own the basics the foundations of arithmetic and you always have to rely on that machine or on that algorithm or on that tool to continue whatever you're doing so in the long term it slows you down and the third statement chess engines made humans better than chess and I like this one because I can use it you know, I can use my own story against itself. Top players today are stronger than ever. That's undeniable. Because they train with engines, okay? But look at how. They use the engine to understand positions, not to have the engine play for them, right? That's the highest scoring group from the Anthropic study. Same pattern, different game. And an honest concession for throwaway scripts, prototypes, boilerplate. Losing the skill may not matter at all, In fact, the problem is production systems in critical domains. Anywhere someone has to own the failure.

That's, you know, no free lunch. So, the fix is not less AI, okay? The fix is keeping a human in the loop who can still read, debug, and write the code or understand it and putting a ceiling on generation. This is something that I keep saying. and here I prepared I think eight lines there are essentially eight hints that I give partially from my book The Mythical Token Month and I partially prepared and put together for this very episode I hope you find them useful and of course let me know if you have objections or if you think I'm wrong or if you think I can do better they can be improved I'm always open to discuss with you on Discord, on YouTube comments and whatever you want to find me. So let me start from this. The number one is read every line that gets generated, right?

So that's the baseline. If it ships under your name, you read it, all right? Number two, review days. And this is my rule personally I personally adopt this at home So you block one or two days a week depending of course on your workload to re the code that you generated okay By yourself. No AI. It does two things. The first is that it trains code reading, which is the skill that you need most when your job is supervising an artificial intelligence. And by the way, it's a very powerful skill because you will start, you know, even by skimming people's screens, and even yourself, you start spotting things when you get, you know, that level of mastery. And the second side effect, let's say, of this is that it caps generation, you know. If you produce more code than you can read in those days, in those one or two days per week, it's a clear signal that you are overusing AI. Simple as that.

The budget writes itself, lines generated per week, less than or equal to your reading speed, okay, times, of course, your review hours. that's a very simple formula it's right there keep that in mind when you generate a million lines of code it's totally fine if you can read at least a million lines of code a week which I don't believe you can right three or third well explain it or don't merge it some of my colleagues know this very well they got a lot of rejections on those pull requests so before you merge explain the diff out loud or write even a PR description by hand without the eye if you can't you don't own it yet right number four hand flying hours borrow from the pilots one task a week with the eye switched off entirely completely noia pick something real not a toy

and do it you know just with something that you like you know something that you would like to challenge yourself with for which you accept no AI intervention. I think that's a very good exercise to, you know, to keep trained. That's the reason why people play Sudoku and crosswords, you know. It's to kill time with something they entertain themselves and keep the brain, you know, active in that particular skill. Number six, I don't know why it's five, but actually it's number five. debug first, ask second. Give yourself 20 to 30 minutes on a bug before you ask the model, right? That goes without saying. You know, debugging is where the gap was largest in pretty much every survey and every experiment or trial that they had so far. So that's where you protect the skill, debugging.

Plus, debugging is extremely important because it implicitly requires that you can read, that you can reason about the code that you are reading, and that you can understand the background and whatever. Spotting bugs is a full-time job, and it's a very complex one, by the way. So it requires a lot of skills. So, improving that debugging skill improves all the others, in fact. Number six, interrogate, don't delegate. What does that mean? Well, use AI as a tutor, right? The new folks, you know, the new generation have access to very powerful tools that I wish I had when I was a kid. Use that with, you know, with reason. use AI as a tutor ask the why, ask for the concept

ask what would break learning and explanatory modes exist for exactly this very statement and the data says that this is the way of working that keeps the skill and of course prevents the brain from rotting and seven for juniors especially write first, compare second What does that mean? Write your own attempt. And then ask the AI for its version and study the difference. The struggle is the learning. So keep that, right? And finally, number eight, for teams and studios, three things, in fact. Stop measuring AI adoption or lines shipped. That never worked, folks. I mean, seriously. Lines of code don't represent anything, especially these days. Those metrics reward exactly the delegation that erodes skill. Make code review ask why question and not just does it pass.

That's something that I've seen over and over in many of my clients. Does it pass? What does that mean? I can make a test that passes all the time, even without AI. You know, a tautologic test always true. Then what? What do you have? you have a nice green flag and a thumb up every day or every commit good for you another thing, the third still for teams and studios keep hiring juniors folks, give them a protected struggle budget without juniors today there are no seniors in 2014 I'm telling you in 2014 I hope I'm going to be retired so that's a non-problem for me it will be a problem for you we need the juniors of today to become the seniors of tomorrow there's no free lunch either so yeah these are my two cents

now back to the board let me end where we started so I wrote a chess engine and I cannot play chess and that was fine because nobody ever asked me to sit at the board nobody ever asked me to be a chess player as a profession you as the developer will be asked to be a developer or to deal with code or to deal with features or to deal with projects and IT stuff, if IT is still something. The data model is wrong or is down or out of its depth, you are the one at the board, so be that and prepare for that. So read your code, give yourself review days, and if you are generating more than you can read, that's not productivity, that's the machine playing and you're watching, right? So build the engine if you want but keep playing the game, right? In Rust, there is this meme about there are more game engines than games building with Rust

probably I'm being too nerdy now but that's happening pretty much everywhere because it's so easy to generate stuff and people, you know, without understanding it's so easy, you know you're one click away from building pretty much everything that's not progress folks that's a trap right now I want to hear from you and so get in touch comment, share and come on discord let's have a conversation or just let me know on the YouTube comments how do you keep your skills sharp is there anything that you want to share with the community or with the other folks and does your team measure AI adoption or understanding or how does your team measure productivity? These are all questions that I would definitely be eager to know from you. And so, yeah, get in touch and let me know. Take care. Hey, quick one. I wrote a book, The Mythical Token Month. Here's the idea.

AI coding agents feel like magic, but they don't remove the hard part of building software. You know, they just clear out the busy world around it, as we all know. what's left is indeed the actual thinking now I have to say that no AI wrote a word of this book I have to say that it's a self-claim but you have to believe me it's out now as an e-book, NoDRM the website mythicaltokenmonth.com links in the show notes thank you Facebook or visit our website at