# The Root Cause of Wanting to Learn > Source: > Published: 2026-06-21 08:53:28+00:00 # The Root Cause of Wanting to Learn ### How we can combat Learning Debt by staying present and mindful In this episode of Root Cause we sit down with Ia Mg - seasoned engineer, former CS and digital literacy teacher at the Free University of Tbilisi, and the author of the blog Bits Complicated - to get to the root cause of learning itself, and whether the machines we've built are about to make us better at it or worse. We dig into why everyone should understand technology even if they never write code, why domain knowledge has always mattered more than programmers wanted to admit, and what happens to learning when the answer is always one prompt away. Along the way: tech debt as a tax instead of a failure ("legacy as a service"), the "learning debt" that builds every time you accept a ready-made answer, why conversation-based coding is a process problem and not just an output problem, and why learning might be the most rebellious thing you can still do for yourself. **Below you’ll find the text version of this episode, for those, who prefer reading :)** *Guest: Ia Mg — Seasoned Engineer, former computer science and technology teacher, and writer of the blog Bits Complicated* ## Why everyone should understand technology **Nune:** You taught coding to non-developers at the Free University of Tbilisi. Did you have to reframe the way you think about programming concepts in order to teach them to non-coders? **Ia:** That’s an interesting thing to reflect on. I started out at a computer science faculty, so there are already so many new things you get confronted with when you start teaching. The course I taught was introduced as a mandatory course for technology and design, and part of why I got involved is that they already knew **I like to yap about technology** — I always come in with “anyone can understand it, and it’s so beautiful.” The thing I had to confront the most was **adjusting how much I could expect as an outcome**. I had to scale down a bit on the speed of the course. But I also found how much better the outcome was — how much better the materials were understood. **Nune:** You said you can yap about programming all the time and how cool it is. Do you think everybody should learn programming — and can everybody learn it? **Ia:** Yes and yes — but not because everyone needs to know programming. A few things happen during this process. First and foremost, not everyone needs to know how to code, but **I strongly believe everyone should understand technology — even has a responsibility to understand it**, whether it’s relevant to their field or just to society. Because of how the education system is set up, many people are shy and reserved about developing their tech skills. They feel like being tech-friendly is something innate, something you’re either drawn to or not — and so they deprive themselves of developing **digital literacy** and gaining a lot more power in whatever they’re doing. Even if we don’t use it for our career, we use technology every single hour. It’s a fundamental human responsibility to understand the thing that’s so intertwined with our life. **Nune:** People might not realize they’re using technology every day — the Instagram algorithm is responsible for what they see and how they interact with everything around them. That’s what you mean by literacy? **Ia:** Exactly. And the legislation, too. There’s basically no legislation now that isn’t related to technology, because it’s so involved — citizens have a responsibility to understand what laws are being passed, and so do the politicians. So tech literacy is something everyone really needs. The second thing that happens during this process gets mentioned a lot: you should learn programming because **it develops your problem-solving skills**. That’s true, but there’s nothing special about developing problem-solving skills — there are lots of things you can do that develop them, and no one goes about their day not solving problems. What’s different about coding is that **it’s a much more rapid feedback cycle**. You’re confronted with exactly how you think, very quickly, and you can’t blame the mistake on anyone else. **Nune:** No external circumstances. **Ia:** Your code crashes — it’s you. There’s no one else who could have done this. You’re very confronted about your shortcomings in problem-solving, and you do it very, very quickly. There are very few other environments that let you test your reasoning that fast. **It’s also very accessible** — you don’t even need to download anything anymore. You can go to a website and start developing the skill immediately. **Nune:** I had a doctor in my team who practiced medicine and then switched to programming. You’re right — he already had problem-solving skills, because he’d had to use them as a doctor. The only difference was that I sometimes assumed certain concepts were known to him from a math or computer science background, and they weren’t. But because of that, he developed a different set of abstractions and mental models. He went on to teach Python to other non-programmers, and they found a common language. So you’re not talking just about functions and modules — you’re talking about the way of thinking, and how programming can make you aware of how you think. **Ia:** Exactly. **My classes are famous for writing very little code.** It’ll be 35 minutes in, we’ve discussed so many things, approached the problem, the description — and the students are like, “When are we going to write code?” And I’m like, **this is not about code, guys.** This is not about code, guys. ## “Everyone can be a programmer” — and why domain knowledge wins **Nune:** There’s a sentiment going around because everyone’s talking about AI: that nowadays everyone can be a programmer — you just take AI. And further, that you don’t even need to *be* a programmer to program; you need to be a domain expert. Once you’re good at a specific field, you take AI and voilà, you have a product tailored to that industry. What do you think about that? **Ia:** I understand the negative sentiment around “everyone can be a programmer.” For me, it’s a positive statement — and one we’ve been hearing for a long time. When I started out, it was “now everyone can learn programming because the modern languages are so easy.” Then “everyone can build a web server because we have so many frameworks.” Then “everyone can be a cloud engineer because Docker made it easier.” I don’t know why people get angry that things become easier to do. Of course, some difficulty is lost, and some skill and responsibility goes with it. But you mentioned something important: the domain-knowledge part. **I’m convinced programmers were not doing well on that.** When they’d come onto a project, they didn’t understand how important domain knowledge is, separate from programming. And **the domain knowledge is what determines whether what you create will be valuable.** You might build a great system — but what’s the purpose of it? Because I had this weird set of domains, I learned this directly. I started at a sound research institute and had to take music classes just so I could be productive in meetings and understand the words being used. Then at Exscientia I had to learn how a microscope works, how imaging works, how fluorescent markers work. I can do a lot of things, but that doesn’t matter if I’m not doing the things you actually need. I think programmers get a **false confidence** that they’re very skilled and valuable and know something most people can’t do — and then they underestimate how important domain knowledge is. This whole situation is a direct demonstration that sometimes domain knowledge matters more than specific programming skills. I’m all for it. I know people are angry, but for me it’s “bring it on” — I think this was long overdue. The domain knowledge is what determines whether what you create will be valuable. **Nune:** The democratization of programming has been going for a while, and it’s not the problem. The problem is understating how difficult it still is — it’s not just about taking the tool and asking it to write what you want. The way you had to learn music concepts, I think anyone with good domain knowledge who wants to program in that domain also has to learn some basic programming concepts. **Ia:** That’s fair. For me, the products created with AI are valuable not because of their code, but because of the **prototyping and proof-of-concept** action. I don’t think the product should immediately be built upon. But now a lot of people who never had a chance to demonstrate that something they wanted to do would be valuable — they get that chance. Within programming, “anyone can be a programmer” is more of a problem inside the domain, because **seniority in software engineering was always about having more skills than just coding** — the hard skills of engineering, design, architecture decisions, diagramming, documentation, and also the social parts. What I don’t like is that with AI, anyone can produce a very good-looking document, a very good-looking diagram, a lot of documentation. I’m not sure what the impact of that is. It’s disorienting, because now **everyone kind of sounds senior**. I’m interested to see where that goes. **Nune:** Maybe now is the time the industry figures out what it actually takes to *be* senior — not just to sound like it. Like being able to work and decide things in an atmosphere of uncertainty, because business never has exact answers. The more senior you are, the easier it is to navigate uncertainty, and you can only learn that by having seen more situations and thought them through yourself. If AI thought instead of you, you probably didn’t build the connections in your head that help you navigate the next situation. **Ia:** Yeah — and **being stuck for a bit**. Spending some time in the stuck situation. **Nune:** Suffering is part of being senior. Setting aside whether AI can *write* programs — as someone who has taught programming, do you think AI is a good *teacher* of programming? ## Can a machine teach? **Ia:** Teaching is very tied to storytelling, and it’s very personal. My own teaching core: I didn’t start out in computer science. I was studying business and marketing, and I thought, “If I want to create something, I’ll have to rely on developers — and what if I can’t find them?” So I started learning to code with the idea I’d build some website. Then **I fell in love** and made the very scary switch to computer science, and fell in love even more. Every time I teach, I’ve never lost that gratitude for giving that opportunity to myself — how beautiful it was to understand concepts I thought I’d never be capable of understanding. That part is very hard to replace. Teaching is very person-specific, very human. I don’t think the teacher can be replaced — but even before AI, I was confident that students should get more help from technology. I really liked Khan Academy; I even volunteered to translate it, and worked at a nonprofit translating it and supporting them on social media before I switched to computer science. I liked the mix: the student gets to **independently watch the videos, pause, rewatch**, then do exercises tailored to them. Because that’s not the main value of the teacher. **The main value of the teacher is to control the process, to understand the pupils** — and teachers also have a responsibility to be good. I volunteer now at Stanford’s program Code in Place, because I missed the framework — I worked at a university in Vienna some time ago and don’t have that chance anymore, so I volunteer whenever I can. I was surprised that after every section you hold with students, you get **AI feedback**. Before the section, you get feedback on what the students have done in the exercises — what they struggle with most, what they understand well. That’s very helpful, because I go in knowing exactly what’s missing, what to cover in the first few minutes, and where to tell them, “It’s okay if you don’t understand this.” After the section I get statistics on how long I was talking versus how long the students were talking. As a teacher you should get feedback — I shouldn’t have to remember the whole class to target the areas that will have the most impact. The main value of the teacher is to control the process, to understand the students. **Nune:** So it’s a good tool, and it should be used as a tool — but there will always be aspects that are human and can’t be replaced. I really like your attitude: “If I don’t know something, I’ll learn it and then apply it.” A lot of the DevOps movement was developers who cared about infrastructure and operations — they didn’t only want to write code, they wanted to understand how it would be deployed and run in production. What you’re saying about product work and understanding the domain is another step: it’s not only about programming something well for production, it’s about programming something the end users actually need. So of course I need to understand the business domain too. And if a non-programmer can say “I don’t understand programming concepts, I should learn them,” then it should go the other way around — if a programmer joins a domain they don’t know, it’s fair to say they need to learn that part themselves. **Ia:** Right — **having the ability to code or engineer is not the most valuable skill on the team.** It was positioned as such because it had a very long barrier to entry — others couldn’t even participate in the discussion. It was gate-kept. I think AI is having the most impact at the borders of the discipline: how much input you can get. Now a product manager can code up a prototype proving what they’re aiming for is possible, or good, or valuable. That might be annoying to receive as the person who said “no, this won’t work” — but ultimately it’s for the better. **Nune:** At least it’s a better way to communicate your ideas. ## The trouble with trusting what AI tells you **Nune:** One thing that bothers me about learning anything with AI is that I can’t always evaluate whether the answer was correct — unless I know it upfront, at least approximately. If I know programming and I ask AI to evaluate paths A, B, and C with pros and cons, I can validate the result against my own mental model. But if I switch to a domain I don’t know and ask for some paths, I have no idea whether they’re right. People argue you can ask follow-up questions — say I ask about chemistry, don’t understand the answer, and say “break it down simpler and simpler until I get to high-school terminology.” The problem is that with every response there’s more uncertainty in me that some part was hallucinated or outdated. So my uncertainty in the answer *grows* with every turn. Translating that to people learning programming with AI — how can they do it without knowing it upfront? **Ia:** When you ask AI about things you *do* know, you see how biased the responses are and how much nuance they miss — even nuance that’s relevant for beginners. Sometimes it frames things that should never be framed: **if you ask the wrong question, you receive an answer, instead of being told “that’s the wrong question to ask.”** And as the conversation goes on, you bring in more non-knowledge about the domain, and the answers depend on what you ask and what you follow up on. **It’s the answer that was created by you.** Ultimately, the answers you create, you create based on your input — so you don’t have an independent evaluation of anything. What I like AI for is “Hey, what is this thing called?” — so I can go and search for it. Because before, there were certain terminologies you couldn’t Google your way into. But for a high-level explanation of a topic I’m unfamiliar with, I’d trust a human, or at least accept that what I’m getting might be completely wrong. Ultimately, the answers you create, you create based on your input — so you don’t have an independent evaluation of anything. **Nune:** That’s a good point. The other day I couldn’t remember the name of a movie — sometimes it’s a book — and I asked AI with a high-level description of what I remembered of the plot, and it came back with the answer. *That’s* where AI is helpful. If you don’t know what something is called, you can’t Google it, so the use case you mentioned is a really valid one. **Ia:** And then you Google it and you get the AI response now anyway. I use Ecosia and others — they have an AI response too, but at least it’s less pushed. **Nune:** There’s probably a way to disable that, like an ad blocker for AI answers. But so much content is now AI-generated that it’s getting harder and harder to differentiate. ## Are we raising a worse generation? **Nune:** Which brings me to: are you worried about the next generation? There was a report — don’t quote me on this — that this is the first generation with lower IQ test results. I don’t think IQ tests are a good measure of human knowledge, but there’s obviously a shift. Are you worried, or do you think they’ll find their way? **Ia:** That study was one of those times when I was like, “Okay, what are the sources? Who decided that? How did they measure?” For me, that kind of shift is more representative of the **social, political, and economic situation** the world is in than of AI or short-form content specifically — though we know short-form is harmful, and the outcomes we’re seeing are in line with that. But ultimately it’s the next generation’s problem. We can’t understand it, we can’t solve it. We can only create a world where they feel empowered to face it. Sometimes on the weekends I go to the library to remove myself from distractions — get a coffee — and I see students still sitting with books, or studying with their laptops open. When I did exercises, I also had the solutions at the back of the book. I just wasn’t looking, because I understood: **I’m learning, I’m practicing. I wasn’t interested in the answer, I was interested in development.** So I think they’ll be fine. The new generation of programmers will be fine. **It’s just not the same fine that we think is fine.** I wasn’t interested in the answer. I was interested in development. **Nune:** The endorphins you get when you finally understand something yourself are so powerful that they’ll drive people to keep learning, instead of just taking ready-made answers. **Ia:** Exactly. Even with this AI coding craze, people are very excited — but they’re also very aggressively **burning themselves out**. It’s not sustainable to spend 18 hours a day building things and arguing with a chatbot. At some point people will say, “This is exhausting, this isn’t rewarding,” and go back to wanting a more sustainable way to build. ## Just another abstraction? **Nune:** You mentioned the recurring sentiment that programming keeps getting “easy” — because of higher-order languages, then frameworks. Now people say AI, or LLMs, are just another level of abstraction: we had assembler, then higher-order languages, and now LLMs — so what’s the big fuss? Do you agree with that analogy? **Ia:** I don’t see it yet. It *is* an abstraction, but even if it becomes another layer, this is not how it will look. It’s hard for me to engage with the argument, because my gut feeling is that **the output isn’t equivalent to what the other abstraction layers output** — though maybe that can be solved. So my take is: I don’t like the statement, but I can’t fully elaborate. **Nune:** A lot of people say the difference is **determinism** — with higher-order languages, your expectations of what the program will do match reality. But maybe that can be pushed back with enough tests, to make the LLM’s output reliable. Although you had an article about how LLMs aren’t that good at writing tests — they over-mock — and how people need to learn about this. What did you call it? The testing pyramid? **Ia:** The testing pyramid, yes. I’m a test-driven-development, best-practices person — I have very strong opinions about tests. And we simply **don’t have enough good tests to train AIs on**. A lot of tests are over-engineered at the wrong abstraction level, testing wrongly designed units — and that’s what’s been fed to AI, so the AI generates exactly that. For smaller things, I usually get my units straight before handing over to the AI, and then I can say, “This is too many mocks.” But who is responsible for defining the tests, or making sure they’re implemented correctly? There are a lot of **green checkmarks** you can get. Everyone sees that AI says, “Yeah, complete.” It is *not* complete. Something’s been deleted in the process; what you asked for is the opposite of what’s implemented. Because of that, I don’t have confidence yet in the output. **Nune:** Here are 1,400 tests and they’re all green — but the value of it isn’t high. Here are 1,400 tests and they’re all green — but the value of it isn’t high. **Nune:** Something I keep going back and forth on, even in a single day, is **conversation-based development**. At first I was very much against it — how can you develop something through a conversation that’s so unreliable and unpredictable? If I have that conversation it gives one result; if you have it, another. But then sometimes I think it’s wonderful that I can adjust things while I talk, and new things come out of the conversation. So what do you think about coding through chat, versus building a pipeline that creates code? **Ia:** I can’t wait for the next way we’ll do this. I’m fine with chats, but right now it’s *just* chat. For me it looks a bit different: there’s chat, then something gets determined, then something else happens. We know that as the chat goes on, performance degrades. My approach now: **if I have to correct too many things, I don’t move forward.** For me that’s a failure — not an outcome failure, a **process failure**. Something in my setup, my prompt, or my skills isn’t working the way I want, so I go and adjust *that* instead of chatting along. I try to keep the chats short, because if you don’t have a reliable process and you have to interfere all the time, it’s not a good process. **Nune:** You’re so right. I wrote an article about getting myself *out* of the conversation — controlling every step instead: spec generation, then spec to plan, then plan to code. Even though it sometimes doesn’t feel as productive as the conversation, it’s a workflow that’s controllable and improvable, because you have artifacts at the end of each step to iterate on. If you don’t get the answer right, that’s your chance to improve your process — not just to get the end result. It’s all about patience. **Ia:** When I discovered that, it was one of the first times I warmed up to using AI in development, because then I could say, “Okay, this is the hard part — if that happens, I have to stop, start over, and improve.” Because **in the chat you don’t start over, you don’t improve — you just keep asking it to make no mistake.** When I saw there was something I could engineer about that, it was one of the first things that hyped me up. Before, I was like, “Yeah, I can create things, but what do I actually *do* in that process? Just type things out?” In the chat you don’t start over, you don’t improve — you just keep asking it to make no mistake. ## Tech debt is a tax — and so is learning debt **Nune:** Every conversation turn adds to the tech debt. I know you wrote about tech debt, that you don’t like the term, and that we should call it a tax. Can you say a bit about why? **Ia:** AI does generate a lot of tech debt — I call it **legacy as a service**. Have you ever wanted legacy right away that no one understands? I’m not saying that’s not how we’ll code; we’ll just accept it and work around it. But in general, tech debt is sometimes discussed as something separate that exists because someone didn’t do a good job and needs its own time allocated to be fixed. **I don’t think tech debt should be looked at as a failure. It’s part of the process** — just the passage of time and changing requirements. Even though it’s important to tackle, I usually don’t push for standalone initiatives to address tech debt, because how do you know the time you’re putting in is worth it? That’s why, if you look at it as a **fee**, you can tie the fee into tasks. If there’s a module everyone forgets how to work with because it’s complicated, and you have a task where you spend three days just orienting yourself around it again, now it makes sense to address the tech debt a bit — maybe an extra day or two — because you’ll save time on the next iteration. But you can’t just say, “Now I’ll spend some time getting rid of tech debt.” **You don’t get rid of it. It’s just a fee.** Have you ever wanted legacy right away that no one understands? **Nune:** I hated those sprints that were “let’s just address tech debt this sprint,” because, as you said, every ticket is about bringing business value. It takes a lot of awareness on both the business and engineering sides to say, “This is a business ticket, it sounds easy, but underneath there’s a module nobody wants to touch — so let’s estimate it an eight instead of a five.” Do they still estimate things in Fibonacci numbers, or am I behind? **Ia:** I remember a very funny conversation — a planning meeting or retro. The engineers said, “We can’t go on like this if we don’t allocate time to address tech debt.” And the product manager said, **“Are you not doing that already? Is that not included in the estimation? Why do I have to think about your tech debt?”** Which is very true. **Nune:** As long as it has an explanation. The engineer shouldn’t underestimate the intellect of business people — if you explain the tech debt and why you need the time, they’ll understand. They’re not your enemies. We’re all in the same boat, driving toward one goal. **Ia:** Many won’t even need much explanation, because a lot of product managers have that **trust in the process** — “the engineer knows how much tech debt needs addressing.” That puts the responsibility on us not to overuse those resources. So there has to be a better way to assess and address these topics. **Nune:** Besides tech debt, there’s something I call **learning debt** that’s emerging. Every time you want a ready-made answer, you ask AI and you’re satisfied with it — instead of double, triple, quadruple-checking it, and by checking it, developing the mental connections that help you next time. Do you feel this way too, and how do you address it? **Ia:** There are so many different ways to use AI. You can use it for something you already know; you can use it to help learn something you’re learning; and you can use it to *not* learn something and just get the productivity. For me it’s enough to be clear about which act I’m engaging in. It can be very useful for giving you basic vocabulary in a topic, to get common ground without putting in weeks. But if I want to *learn* something — **I never get the illusion that I learned it just because AI explained it and I understood.** As long as you keep that clear, you get all the benefits without the false sense. When I’m learning a new framework or language, I write the code myself. I don’t even set up the second monitor — I explicitly look at what’s written, go back to mine, and try to write it out, because I’m developing a specific skill. If I ask AI to write it, I won’t have the understanding of why everything is there. I never get the illusion that I learned something just because AI explained it and I understood. **Nune:** It’s still about being aware. As long as you know you’re engaging in the act of getting a ready-made answer and not learning — fine. But don’t mindlessly use tools. **Ia:** Plus, because these answers come so quickly now, the brain gets **rewarded for asking an interesting question and getting an interesting answer** — and then it generates more useless questions. Things you’d never have spent time exploring, that you’d have moved on without knowing — now it’s “and what about this? and what about that?” So now I sometimes restrict that time: “Today I’ll have *that* much.” **Nune:** Compare talking with AI to social media — one more reel, one more interaction. It’s the same very quick satisfaction. **Ia:** Curiosity is so widely understood as positive that you don’t think you need to control it. **Nune:** Same with what used to be called **feature creep** — creating too many features. Now with AI it’s tripled, because the AI itself says, “Why don’t you also implement this and that, it’ll only take a day” — when in fact it won’t; it’ll bring you more bugs and more integration work. So you have to control even your feature-building now, to not go wild. **Ia:** A lot of people are raising that. I look forward to this push of “we can do more features” leading to **a wave of minimalism** — I’m just sitting back and waiting for it. There’s no reason to resist the cycle. We’re getting so many learnings we’ll apply later, even if what’s happening now doesn’t look elegant. It’s a necessary step — but I hope it’ll be understood that it wasn’t *more features* that were missing from technology. ## Embracing the chaos **Nune:** You’re the third guest on this podcast to say “embrace the chaos instead of fighting it” — embrace the hype. You can’t stop it, you can only watch and learn from it and wait for it to calm down. And because you had a reflective mind during it, you’ll be ahead of others. **Ia:** Even — and especially — for the more “responsible” engineers, in air quotes, because you can perceive yourself as a responsible engineer and think everything everyone else is doing is irresponsible. But the people on the cutting edge, coming up with the most interesting uses, are insecure. You open your eyes when you hear what they’re doing — “how, why would you do that?” — but they’re the ones pushing the limits right now. So maybe it’s just **not the time to be responsible**. You can wait until we get enough knowledge to be responsible again. **Nune:** Like children — it’s playtime now, and then we’ll learn. There’s always this question in my head: is programming a craft, or is it art? A lot of people get satisfaction from both sides. Do you think AI is taking away that joy, because we’re not writing code anymore? **Ia:** Depending on what was bringing you joy, it might take it away or bring more. I heard it somewhere: **if you liked the ****building**** part, it’s a bit disorienting; if you liked the ****creating**** part, this is Disneyland.** So it depends which end you’re on. Even though I’m very outcome-oriented, I had a special attachment to the process, because I spent a lot of time and effort making sure I was good at it. So when this appeared, I was like, “I can click yes, then check if it’s correct” — and that didn’t sound like engineering to me. If you liked the building part, it’s a bit disorienting. If you liked the creating part, this is Disneyland. But as the ecosystem develops, there are a lot of different things you can engineer now. And eventually the mandatory token usage will settle to something reasonable, so you’re encouraged to be smarter about what you do. Then you’ll start seeing again that **there are those who can do this better and those who can’t, because they didn’t put the time into the process.** That’s what people were insecure about in the beginning: how do you prove you’re better than someone just using AI? It’s a bunch of markdown files everyone installs — “what am I supposed to be proud of?” But slowly we’ll get an ecosystem where you can be proud again of something you engineered. **Nune:** There’s a bit of **sunk-cost fallacy** in this. I was talking with a colleague I worked with 20 years ago — fresh out of university, all we did was write unit tests and mocking frameworks. Looking back with AI now, it felt like, “Did I waste all those years?” Part of us feels we invested so much that we can’t let it go. But you’re right that even with AI, we’re getting to things that are truly difficult — and those truly difficult parts AI can’t handle are the ones that’ll give us satisfaction to solve. **Ia:** And for me — if I can’t have a good enough edge based on my skills, because everyone can look like an architect now, **I’ll just go study something else and do something else. I like learning, so who cares?** I’ll just go study something else. I like learning, so who cares? **Nune:** As long as you know how to learn. Once in your life, once you’ve solved a particular problem — and honestly, also the problem of making money — solving it once gives you the confidence you can solve it a second and third time. As long as you have that confidence, you’ll be fine. Maybe you won’t be a millionaire, but you’ll be fine. **Ia:** And the skills aren’t lost — they’ll be visible, they already are, and they’ll be even more visible. Every time I switched domains — when I switched to programming and computer science — what I brought was an appreciation for communication, because I’d spent time learning it. Initially, what gave me an edge wasn’t that I was a better coder, but that I was better at communication, or understood its value. So whatever changes in the environment, you can always add more skills and knowledge and use your **interdisciplinary** background as an advantage. **Nune:** I got a question I think you can help me answer, as a teacher: “How can I get into cloud engineering?” I’m a bit worried, because companies hiring demand more and more. First you were good if you knew Python; then you had to know thousands of frameworks; then containers; then be an expert in at least one cloud; and now you also need to be “AI-native,” whatever that means. What do you advise people who want to become an engineer, or switch from one engineering discipline to another? **Ia:** That kind of **words creep** was already getting bad before the current situation. I love when a job listing asks you to know multiple *competing* frameworks or tools — “and also know the alternative, be an expert, just for good measure.” It’s so discouraging, especially for a junior browsing these roles. The problem with these HR ads is they always get *edited* — things get added, not deleted. They have a template that started 10 years ago, and every time they need someone they ask “what should we add here?” Nobody says “remove this.” They just add more word soup. Now everyone needs a good interdisciplinary competitive advantage. I don’t see how someone can prove, very quickly, that they’re a better engineer than someone else — because a quick look isn’t enough anymore. Anyone can learn the words, have projects on GitHub, buy stars. It’s hard to stand out even if you’re genuinely better. At the junior level it’s not about being the best — **a junior is the company’s responsibility to take in, train, and develop.** A lot of people ask me, “Should I learn programming?” For the benefits — yes. As a profession — maybe, if you know where to apply it. Before, it was “if you’re a programmer *and* you have domain knowledge, you have a competitive advantage.” Now people can flip it: “I have domain knowledge, and I’m using programming as a familiarity that lets me use these tools better.” In the current job market you need to be way more strategic, more targeted — understand where you want to get to, and really go beyond just the skills. **Nune:** So, back to domain knowledge: unless you want to work on the frontier, building new models and frameworks — where pure programming is what you need — you’ll probably be safer if you love a specific domain and, on top of that, learn programming so you can work with that domain better. **Ia:** I think that’s true. ## Learning as a rebellious act **Nune:** I’m a big bookworm — everyone who knows me knows that. I’ve developed a tradition for this show of asking people about books. What was the book that made you want to learn something — that gave you the spark of curiosity? **Ia:** One book I read a long time ago but has been on my mind a lot recently is Asimov — both *I, Robot* and his short stories. There’s one especially, where he describes how we create artificial intelligence — a very short, very beautiful story, **“The Last Question”** — and they’re training an intelligence just by feeding it books. When I read it, I thought, “That’s so cute, such an imaginative way.” And then we created it by feeding it books. **Nune:** And now we’re living in that reality. **Ia:** He could already see it that long ago. What I’ve reflected on most: when I read *I, Robot*, my dream job was **robot psychologist** — I wanted to be Susan Calvin. I thought, “If I had that, it would be so good.” And then facing the truth — that maybe I *don’t* want to be a robot psychologist now that the technology is so readily available — was very shocking. There are so many stories we tell ourselves, and it’s always interesting to be confronted by the truth. **Nune:** Is *I, Robot* the one that introduces the three laws of robotics? Science fiction is so important — it helps us imagine these paths. It’s very interesting to live in these days; we’re seeing things we read about from books written in the ‘50s and ‘60s now being born and applied — from one side in a very different way, from another side in the same way. I always go back to a book by Heinlein, *Have Space Suit—Will Travel*. Not because it has any AI in it, but because it brings back the love of learning. The main character gets a space suit and genuinely gets interested in how it’s built — he strips it down and puts it back together, and those pages always give me back the curiosity and the wanting to learn. I’m also reading one now from 1994, *Permutation City*, about people put into a kind of VR world, exploring generated models of consciousness versus biological ones. It’s so relevant today, because beyond AIs and LLMs, a lot of people are starting to understand it’s going to be more about how we can apply biology together with AI. **Ia:** The intelligence part is interesting, because right now we choose *either* human intelligence, *or* the standard statistical machine — the more primitive machine learning — *or* the LLMs. Hopefully soon we’ll see an interesting combination of these, as opposed to going with one closed-box attitude. **Nune:** Let’s root-cause this one last time. We talked about teaching, about learning, and about how AI can be applied in a smart versus an automatic, unconscious way. If you had to root-cause it — not the surface reason, not “people are lazy” or “the tools aren’t good enough yet” — what’s the real root cause of the risk that we collectively get worse at learning? **Ia:** There are a lot of reasons to be concerned, and very dangerous implications to **deskilling the population** and having intelligence as a service — I don’t like where things are being pushed; it’s definitely a nightmare. But set that aside. Politically, **learning is a fundamental rebellious activity** — one that brings you power. You rebel against a lot of things, you gain control over something that was unreachable to you before, and you rebel against time itself. Not only because you slow down biological aging, or even reverse aging in the brain, but because **you allow yourself to become vulnerable again, to be an open book, and to find the child inside.** You get to be a kid again. That’s one of the most precious things you can do for yourself — almost like magic. So for me it’s very important to keep learning, to see the risks and face them and rebel against them. Learning is a fundamental rebellious activity. You rebel against time itself. **Nune:** That’s part of not aging — having this spark of learning. We have to be conscious of not letting our interactions with AI rob us of that feeling. Any practical recommendations? Like, breathe five minutes a day before talking to AI? **Ia:** I have strictly **no-AI days** — not because I’m saying that’s necessary, but because I just don’t know yet what the best approach is. I try to be conscious of what I’m engaging with: “Now I’m using it to ask random questions; now for something I actually don’t know and don’t even want to do — I just want it done; now to assist.” I try to both limit how much I use it in one specific way, and give myself time *without* it, so I’m not too impacted by whatever the implications are. We don’t know yet. **Nune:** Those blissful hours when your token limit is reached and you can just sit and not use it. Another tradition we have: every guest leaves a question for the next guest. The previous one was from Adrian: “What surprised you the most in the discipline you were most comfortable with?” **Ia:** I’ve been thinking about this so much, and it’s so hard. It’s a tough one. **Nune:** I think it’s hard to even figure out which discipline you’re *most* comfortable with — that part of the question is already hard. **Ia:** Something a lot of people find surprising about engineering is **how different it is from what it looks or sounds like.** First of all, how many social skills are involved — how much humility, cooperation. The stereotype is that you get on, write a lot of code, and that’s the fun. But the fun is also in the barriers that exist in real projects, and developing the skills to confront them. **Nune:** With the democratization of programming, a lot more people are starting to put into words what software *engineering* is — not just programming. It’s way more than code. It’s understanding your peers, understanding people from other disciplines — even having a way to limit your own computer time. Whether you were a programmer or you’re just starting with AI tools, we’re all spending more and more time in front of the computer. Yoga is what will save you. **Ia:** And mindfulness practices have helped me so much to be a better engineer — sometimes you need to set your ego aside, step back, look at things. That meditative thing is very useful. **Nune:** Good for your back, too — take care of your back. So, maybe try not to make the next guest think *this* much: what’s your question for the next guest? **Ia:** If you had to start your career — your learning journey — or pick a major right now, would it be different? What would it be, and why? **Nune:** Nice. That would also define what we advise the new juniors coming into the world — though we’re always biased by our past and the situation we’re in, and we can’t know the future. That’s simply the truth. **Ia:** I don’t think I did you the favor of asking an easy question. ## References [Automating myself out of development (spec → plan → code)](https://www.thoughtfultechnologist.com/p/automating-myself-out-of-development)— Part 2 coming soonIsaac Asimov, *I, Robot*and short stories, incl. “The Last Question” —[I, Robot](https://en.wikipedia.org/wiki/I,_Robot)·[The Last Question](https://en.wikipedia.org/wiki/The_Last_Question)