AI & Learning

About this Episode

Mike hosts this episode with Vivian Moore, Kyle Archer and Eddy Lopez, and Matt Hardy and Will Archer join partway through. Vivian suggested the topic: how developers keep their skills sharp when AI can write the code for them. Mike opens by asking why kids still learn long division when everyone has a calculator. Kyle quotes a UVU professor who said math is really about learning to think and break problems apart. Vivian adds that working through older concepts shows you how small ideas build into big ones. Eddy connects this to AI. He hands routine work like templates and specs to his agent, and when he tried writing a PR by hand, he had forgotten how to write a describe block. Mike mentions interview candidates who froze when asked to write code without their agent.

The group disagrees about whether AI makes engineers weaker or stronger. Will says he has never been better at code review, because he reviews so much AI output. He also learns by asking the AI to explain its patterns. Matt recommends turning on reasoning mode and keeping tasks small, the way you would when pair programming. For older, messy codebases, he has the AI document a domain before working in it. Mike cites Anthropic research titled "How AI Assistance Impacts the Formation of Coding Skills," which studied 52 mostly junior engineers. The group that handed off the whole task finished fastest but understood the least. The group that used AI as a coach finished second and understood the code best. Vivian, speaking as a junior, asks how she can grow when the AI improves as fast as she does. Will points to chess "centaurs," human players paired with engines. Vivian counters that engines trained only by playing themselves now win anyway, though she agrees programming is much harder than chess. Will also argues that tools like Claude Code push you to hand over the problem and walk away, and he suspects that design serves the vendor's business model.

Matt says people lose jobs when they refuse to adapt, and AI itself isn't to blame. Mike pushes back with the example of factory automation. Someone caring for an aging parent or living with a learning disability can't always retrain, and if change gets fast enough, nobody can keep up. Will cites a statistic that the dot-com era cut 2.8 million clerical jobs and created 4 million programming jobs. From there the talk turns to job titles and to engineers as productively lazy people. Mike wrote a quadratic formula solver in junior high, and Vivian did the same for box-and-whisker plots. Mike wraps up with the idea the group kept coming back to: engineers are paid to solve problems, and anyone who defines their job as writing code will see that job disappear.

Transcript:

MIKE: Hello and welcome to another episode of the Acima Development Podcast. I am Mike, and I am hosting it today. With me today, I have Vivian Moore, Kyle Archer, and Eddy Lopez. And we've all been here before numerous times, so [laughs] no deep introductions are necessary.

We have a great topic today, and this actually came from Vivian. Vivian's new-ish, right, to Acima and Upbound, and bringing lots of great thoughts with good discussion topics coming from this kind of outside perspective. So, her ideas may be driving a few of our discussions for a while.

But today we've got a topic, and I actually am going to do something a little different from what I've often done. I'm going to ask a question to this group here before we dig in. So, why do we still learn long division?

EDDY: You guys still learn long division? Just kidding [laughter].

MIKE: Yeah, I have been helping my kids with this, so yes [laughs]. It's a thing that still happens. And why? I mean, why do people...I mean, students in a certain year, they learn long division, just like they have for many years.

EDDY: Can I ask, like, a wider net...or adding to that, has the way that we've done long division changed since then? I've seen videos on YouTube where, like, teachers are sort of reinventing the way they're presenting mathematics to kids, right? And so, like, how we learned how to do multiplication, for example, has suddenly, like, vastly changed, you know? And, like, there's, like, a new approach to get to the same solution. I'm curious, like, if the education system has reinvented, like, how long division...

MIKE: What you're asking is important. What you're asking is if they're using the same algorithm that was taught historically, and the answer is, mostly. For multiplication, they often teach a different algorithm besides the traditional one because it's helpful for doing it in your head. And it's often the way I do it in my head, which is you do, like, 123 times 223. Like, oh, how do you do that?

Well, if you do, like, the hundreds first in your head, okay, and you get an answer, and then you do the 20 times something first, you know, and then the 3 times something, and then you add it all together. That's basically the other algorithm they teach, is to think about it in parts that way rather than them working right to left. You can do it either way if you think about it that way and then add it differently. So, yes, different algorithms.

And I think that you're hitting on something there, which is the algorithm isn't the important part, right? They teach that algorithm because it's helpful to know, but you're never going to use it again. Because if you want to do some long division, you're almost certainly not going to pull out a piece of paper and pencil and start doing it in your head. You're going to pull out your phone and start doing it on your calculator, right? Or you just, honestly, you're just using your search engine because it's going to go call a tool and do it.

KYLE: I'd quote my UVU professor, because it was something where, you know, you started getting into the higher forms of mathematics, meaning calc two, calc three, and he said it really doesn't matter at some point. It doesn't. It's we're teaching you to think. It's how you're debugging; it's how you're breaking things up; it's how you're segregating how you solve a problem. That's why we still learn it, in my opinion.

MIKE: I think that's exactly...I mean, I asked the question, you know, leading, you know, digging for an answer. Yeah, we don't teach that algorithm. We don't teach long division because it's ever going to be important directly in your adult life. It's because understanding how it works...and, in fact, I think that we do a lot of harm by saying, "Oh, long divisions means you use this algorithm," rather than saying, "Hey, there's a way you can do this by hand. And if you think about it, well, cut the hundreds into pieces, right? And then cut the tens into pieces, and then cut the ones into pieces, and you can make that work."

And even if you don't necessarily understand all the little details, you have this idea that you can start it and get kind of a rough answer and then get more refined as you go. And that's a great idea. I think we should teach it better. I think we should teach math better in a lot of ways. But that learning to think really matters, and then the algorithm, eh, maybe not so much. Calculator's fine.

VIVIAN: One other piece of that I'd actually like to add is that, I think, beyond just teaching you how to think, teaching old concepts that you won't necessarily use again in the future, even more advanced concepts, especially, like, as you're starting to get into those calculus areas, are often prerequisites for understanding how someone in the past got to the conclusion that they got to about the advanced mathematics. And understanding those kinds of building-block pieces, something that I really like about 3Blue1Brown's work, for example, helps you feel like you could have gotten to the answer on your own. And doing that allows you to piece together the foundations, which, in addition to teaching you how to think, also teaches you the patterns of how little pieces build into big pieces, which I guess is an additional piece of teaching you how to think, but kind of a broader picture of that.

MATT: That's a relevant conversation to the problems we are facing today. And it's funny, you and I were talking about calculus yesterday, Mike.

MIKE: By the way, we have some latecomers to our call. We've got Matt Hardy and Will Archer. And I haven't formally introduced the topic yet because I started a little differently and asked the...I started with a question.

Today, I would like to talk specifically about how to keep your brain sharp, how to keep your skills meaningful, and your, you know, your ability to think and to build things going in an AI world where you've got all these tools that can do it for you.

EDDY: So, keeping in theme with mathematics, one thing that I immediately drew to is, when we're talking about dependency, right, like, specifically, like, the dependency of AI, I attributed using a calculator to do long division similarly to how we'd have AI, you know, is to us programming, right? In a sense, you're sort of cheating, right? Like, you're shortcutting the thought process of getting to a solution by asking something else that will pop out the answer for you, right?

So, if I'm in school and I'm learning long division for the first time, my innate reaction is, "Oh man, this is really uncomfortable. I'm just going to pop in: 'What's 10 divided by 2?' This is going to give me the answer, and we'll just move on," right? I feel like it...there's a very similar pattern there with AI. "Oh crap, I don't know the answer to this. Ah, screw it. I'm just going to ask the AI to give me the answer." Well, like, what benefit are you really getting from that long term, right?

Because the moment you don't have a calculator, the moment you don't have the AI, what the freak are you going to do? You're back to square one, right? So, I think that's the parallel we're trying to draw here, right? Is how do you keep your mind sharp, right, when you have a utility in place that gives you the answer, like, that gives you the shortcut?

MATT: Understanding how something works makes you much more proficient at using the tool that's doing it for you. And that is the key, and the thing that a lot of people are not taking into account these days is the better you have an understanding of how these tools work, the better integrations you're going to have with them, the more efficient your software is going to be, the more efficient your code generation's going to be with them, and just your interactions in general.

MIKE: So, I've been in a...not personally, but I've heard about a couple of interviews recently where a candidate came in, and they were asked to write some code without...they say, "Oh, can you write some code for me?" And they froze because they didn't know how to do it without their AI agent. Like, they didn't even know where to start. They've been heavily writing code and very productive, but they couldn't do it because the piece of the work they just hadn't done for a while.

MATT: I'm very familiar with that one.

MIKE: It's a risk that we're all running today in a world where our tools are changing. So, this is relevant today.

EDDY: I can start to see the cascading impact on me personally, right? I tend to leverage AI to do the mundane tasks, right, the things that I already know I can do, right, like templating or whatever, whatever I need to do, right? Oh, I know I'm going to need this class. I know I'm going to need this template. I know I'm going to use this controller. I know I'm going to use this model. I'm going to have to write some specs. I've done in the past, right?

So, I reach this, like, fork in the road where I'm like, "Okay, I can do this mundane task that'll take me, like, half the day to write, spec, set to review, or I can just ask my AI agent to do it for me," right? And I'll just spot-check, make sure it didn't hallucinate, you know, I'll still test it.

But I saw a meme on Reddit a few days ago where it kinda touched on this, where it's like, "Guys, I don't want to, like, pat myself on the back," right? "But I raw dogged my PR today without any agent," right? And it made me laugh, and I'm like, to me, that was much funnier than, I think, the intention was. But I'm like, you know what? There is something there, though. So, I try to do it myself, and what do you know? Like, I got rusty, right? I'm like, crap. I'm like, how do I write a describe block again in spec? I'm like, crap. I'm like, dude, this is stupid. I know how to do this. What the heck?

And so, like, I had to, like, reread, like, another, like, example. And then that's where it kinda just dawned on me. I'm like, dude, dude, dude, dude. It doesn't just affect you with context that you haven't mastered yet, but it will affect you, like, on things that you've already done in the past, and you have very good contextual knowledge of it. So, I'm just saying, like, me personally, I'm wearing the hat in my career. I have noticed an immediate impact even on things that I have already learned how to do, right? So, it's kind of wicked.

MATT: You can go the opposite direction as well, right? Have your artificial intelligence solve complex problems for you, get to the end quickly, then go back and see its process so you can better understand how to solve those complex problems. It's all about how we're using these tools, not necessarily the tools themselves.

WILL: And that's such a critical foundational thing about AI that, I think, people kind of miss because everybody's under the gun, and everybody's shipping tickets. Like, people want, you know...I've been in heavy, heavy, heavy crunch mode all week. And I am being tasked with deadlines that a mortal human, I don't think, could attain, you know? I don't think a human being could do it unaided [laughs].

MATT: I understand those.

WILL: But the thing about AI is that it still gets stuff wrong all the freaking time. And while I would say that, like, you know, like, yeah, probably reasonably, like, some of my skills have atrophied, but, like, some of them have gotten a lot stronger in that, like, I don't think I've ever been stronger at a code review than I am right now because I have a lot of code that needs thorough, fast reviews. Like, that's my job. I'm a better reviewer than I've ever been, I think, because I'm doing so much more of it.

But the other thing about it is, like, and this is foundational, that it's a two-way street. Like, it isn't just a one-way conversation, unless you make it that way.

MATT: That's right.

WILL: Like, "Well, what did you do? Why? What is this? How did you do this? You ran this pattern, and I usually run this other pattern." Like, I've learned so much about programming just from AI because, you know, I'm a man of flesh and blood and habits, you know? But, like, the AI's pulling everything from everywhere, and I'm like, "Oh, how did you write that view binding for this thing?" And like, "Explain that to me, and show me this." And I have a little case study, and I've got all the details in front of me. And the AI's only too happy to walk you through everything.

MATT: I would highly recommend, to any of our listeners, turning on reasoning mode so you can actually watch it and read it as it's working. You know, I would like to think of myself as a reasonably good engineer, but I would also argue that I am a better engineer today after using these tools for so long and so much.

VIVIAN: I noticed something about myself that I've also had corroborated by kind of other people discussing a similar topic, in that using AI makes you better at recognizing when something is AI-written. And there have been studies done where people that don't use AI and don't interact with it regularly cannot tell the difference between AI and human-written language. But people that interact with it all the time can tell the difference, even to the point where it's someone reading a script that was AI-written, very, very consistently, like, with relatively extreme precision considering the complexity of these models at this point.

And I'm not saying that being able to tell AI versus not AI is necessarily a valuable skill for a programmer to have, but the ability to learn from what AI is doing and adapt to the difference in how it writes code versus how humans write code is very interesting, especially because I think that it runs the risk of both homogenizing people and also introducing ideas that people wouldn't have otherwise been introduced to.

If a senior engineer spent their whole life writing a single style of code, then that's what they know; that's what they're used to. And even if they've upskilled and tried to learn other things, they still spent all of their time doing that. But then AI comes in and is introduced on mountains of code that this senior engineer may never have been introduced to, and can explore all of these ideas. But at the same time, it can also just do it for you, and without using it, you won't know when it's going to be wrong.

MATT: Yeah. And remember that it is a machine, so, ultimately, it thinks like a machine. The only reason it's using our dialect, whether it be English, French, Russian, whatever, is to communicate with us. It doesn't need that to communicate with a machine. So, that's how it writes its code, unless you explicitly set up rules to have it do otherwise, so it's more understandable to you.

MIKE: I would take it further than that. AI has been trained on human patterns. What it does is pattern matching, right? It's a very sophisticated pattern matcher. And there may have been some reinforcement learning applied after that, so it kind of puts weights on different styles. But in the end, it learned from us, and it's reflecting that.

Timnit Gebru, the AI researcher, called it stochastic parrots. It's a parrot with a little bit of randomness built in. That's how the AI works. And you just set up the context, and then it parrots back what it expects, what it thinks a human would say. And if you approach it with that understanding and say, "Okay, this is going to say what it thinks I want to hear, so I need to make very clear what it is that I actually want to hear."

VIVIAN: Okay, but then it goes back to kind of a question that we were talking about originally. What do you want an AI to say to you? In a software engineering career, like, what do you actually want it to do? Because it can write code. It can write specs. It can run those specs. But what do you actually want it to do?

MATT: Well, I think if you are reasonable and trying to grow, you want it to be adversarial for one, not just respond with what you want to hear. I think that's extremely important. I think you also need to set deterministic boundaries around those stochastic responses and probability, and that will increase your accuracy. But ultimately, I think we're all just looking for outputs, if we're using it for engineering, right, or, say, sciences, whatever. If we're using it for therapy, maybe it's different. But I think ultimately our end goal is that output, and we want correct output, unless you just need your ego fluffed, and then I think n you're digressing.

MIKE: Well, Vivian linked some research in the pre-call, actually, prior to the pre-call. We've been, you know, prepping this all day. But it was research at Anthropic, I pulled it up, that suggested that...so, if anybody wants to look this up, it's titled: "How AI Assistance Impacts the Formation of Coding Skills." And they talked about some research where they took a group of junior developers and had them use AI in a variety of ways. So, it looks like 52, mostly junior software engineers, had them work on some things. And they found some different groups in terms of effectiveness.

I think this is really fascinating. The group that was fastest just gave the AI the job, "Do it," and it got it done generally. So, it was the fastest. But afterwards, they did a score to see if they understood what was happening, and they did terrible.

But the group that was second fastest was the group that said, "Hey, AI, how do I do this?" And then they used it as a partner, like a teacher, a coach, and coached them through it. And they made mistakes, and they, you know, went through the hard work of developing the software. They were the second fastest because they had that coach always helping them. And at the end, they understood it as, you know, as well as anybody because they worked through it themselves. I think that is a fascinating result.

WILL: That is a fascinating result.

VIVIAN: As we've been talking, there's a kind of analogy that I've been thinking about that feels applicable. Kind of to bring it back to the mathematics, there are tools that will give us the answer, right? So, like, the calculator will give you the answer to a long division problem. It will give you the answer in a fraction, in a remainder, in a decimal, whatever you need it to be. But at the end of the day, it can't, like, give you the way that it got to the answer.

On the flip side, something like a book, especially like a textbook, will walk you through: how do you solve this problem? It's designed to be a teacher. It's not designed to be a tool to solve the problem. It is a teacher.

And I think with AI especially, we run the risk of the fact that AI is both. It is a tool that can give you the answer. It's not deterministic, and it may be wrong, but it will just give you an answer. But in order for it to be effective and not de-skill you, like we were talking about with these, like, software engineers, these junior software engineers, it will de-skill you by offloading your thinking. But you can also use it as a teacher, and so it is a tool that, like, is leaving skill and effectiveness left on the table if you don't use it.

Personally, I've tried to find a balance. But how do you guys approach striking that balance of not letting it de-skill you while still using it to produce effective and faster output?

WILL: In the end, I don't know. I wonder just because, like, I can't...I can only go so low [laughs]. Maybe that's because I'm dumb or, maybe it's because I'm old, or probably a little bit of both, right? Like, I'm not going to forget how to program computers. I can't forget how to program computers short of a traumatic brain injury at this point because, I don't know, man. I don't know.

So, with that said, gosh, I don't know. I mean, in the end, I don't want to do anything that's not productive. I got into engineering because I like making things, right? And so, whatever the most efficacious way for me to make things is what I'm going to try and do. And what I'm working on right now is sort of, like, scaling up the AI to keep it from doing this sort of dumb AI stuff. And I want it to be a version of me. I want to clone myself, and I want to have him run in a loop just banging out tickets, like mini Will, right? That's what I want to create: mini Will.

I don't know the extent that that's possible. I have found that AI's good at stuff, and it's bad at other stuff. It's not great at brownfield, funky things, which is where the money is. That's what they pay me to do. They pay me to do grimy bits. And it makes a lot of mistakes, and I stay on it, but I'm trying to have it make fewer and less predictable mistakes in the end.

But ultimately, I started programming in Fortran, right? I learned to program in Fortran. And I haven't coded Fortran in a long, long time, but I aspire to never use that skill again until the day of my death [laughter]. And, you know, I know Assembly. I know all kinds of stuff that I plan to retire. So, you know, I mean, adding another body to the pile doesn't concern me in the slightest.

I think the foundational concepts of, like, how do you build software, how do you build data flows that work, and are reliable, and effective, and efficient, like, that's what I do, you know what I mean? Like, typing out the code, I don't care. Compilers are sick. They're so good [laughter].

MATT: Going back to what you were saying, Vivian, I think one of the things that I mentioned: watch how it's reasoning, understand how it's reasoning, but also interact with it. Keep the tasks smaller so you can have that iteration and the back and forth, just like you would if you were pair programming with another engineer. And then on your brownfield comment, Will, I don't know that I entirely agree with that. But like anything, it's all about the workflow and knowing how to use the tools to make it be able to work in the brownfield codebases, right?

There are steps that you can ensure it does a much better job than just throwing it at your code and telling it to go do something. You know, go understand this domain. Repeat back to me what the code's doing. Is there documentation? No? Now go write the documentation for that domain, and let's review it together. And then, after that, it's just like a greenfield project for your AI because you get through it. It gets documented, and now it understands it. You know what I mean?

MIKE: I don't know that you're necessarily in disagreement. Just in principle, if AI is pattern matching, right, then it represents the things that are, by definition, already a pattern. And if they're paying us to do human creative work, then hopefully the work that we're doing is what lies a little bit outside that boundary. Like, if we're just writing boilerplate, then why are we employed [laughs], you know?

MATT: Yes.

MIKE: And we should be using the AI for that. The parts that are hard are the parts that aren't quite going to fit the pattern. And so, even if...And I don't think that you....What I'm saying is, I don't think that you're in disagreement. You're saying, Matt, that there is an iterative process by which you get the AI there to where you build it up, and I think that's right.

But also, going back to what Will said, of course the gnarly bits, the parts that AI is going to have a hard time with, are the parts that you're going to be working on, because where else would you want your humans to be working?

MATT: Right. But that takes me back to the thing we've been saying a lot of, and that's the probabilistic side of things, right? Humans aren't deterministic. So, we get those probabilistic results as well, right? You and I can go sit down and be given the same task, and what we do is not going to look the same. So, I mean, by definition, determinism is same input, same outputs, right? Same data in, same data out. But we wouldn't get it together. And when you put a team of humans building your product together, there are going to be bugs. There are going to be things that aren't quite efficient, just like we're talking about in our complaints with AI agents and how they write code.

So, what I've been trying to communicate across the organization is it's really about culture and understanding the problems you're going to face are still going to be very similar to the problems we face today and those human problems. And it's just adopting that culture, learning how to work with it. That's how you continue to grow.

Like any new technology or innovation, you know, the typewriter, people thought computers, oh no, now I'm out of a job because it can do everything that I do every day. But that's not what humans are good at; it isn't hammering on a keyboard. Its, AI is good at problem-solving, but what humans are really good at is innovation and thinking outside of the box, and new concepts and new ideas. And I think that's really what engineering should be, and that's what we're good at: solving those problems, being innovative, pushing boundaries, and moving things forward, and it's just a tool to help us get there faster.

WILL: Yeah, I mean, in the end, like, I guess I'd say, like, I read this statistic just now. It was an infographic, so I believe it, I don't know. Like, somebody said something on the internet, and I'm like, "I don't know," but, like, you throw a chart at me, and I'm like, "All right, I'm listening [chuckles]." If you cared enough to graph it [chuckles] and it validates my priors, I'm in [laughter].

But, like, they were talking about, like, sort of, like, the dot-com internet revolution, right, through the '90s, and it eliminated 2.8 million office clerical workers, and it employed 4 million programmers [chuckles], you know? And that's, you know, that's...I don't know. That's what gets me to bed at night, I'll say that at least. Yeah, I sleep well just thinking, like, thinking about websites that we had in 1998 and how you could get arrested making a 1998 website, you know? Amazon.com, they launched in 1998. I remember. I seen it. And we've come a long way, baby [laughs].

MATT: Right. I ordered all of my books from them. But, you know, I don't think AI is taking anybody's job. It isn't. What's taking jobs is people's unwillingness to advance and move forward and adapt, right? The world is ever-changing, and that's not going to stop. This is just another change and, like anything, if you are not willing to adapt, you get left behind. So, it's not AI taking anybody's job. It's the lack of a willingness to learn new things, to advance yourself, advance with the world and where it's headed. That's what people are losing their jobs for.

MIKE: Well, there's a lot of truth to that, but I'm going to throw a great, big juicy asterisk at the end of that. So, in the beginning, in the, you know, like, late '70s, robots started getting used in industry, right? In factories. And there were a lot of factory jobs displaced. A lot of times people say, "Oh yeah, they sent them all overseas." There's a little bit of truth to that, but actually manufacturing in the United States hasn't gone down that much. It's just mostly been automated. And if you live in a factory --

WILL: It's true --

MIKE: What's that?

WILL: They definitely shipped those jobs out, like, not a little bit.

MIKE: [inaudible 28:58]

WILL: There's a whole lot of truth to that. Go to American manufacturing, but, like, it's not --

MIKE: And, yeah, it is complex. So, I'm not trying to say that outsourcing didn't happen. Absolutely that happened. My point is that if you're living in Youngstown, Ohio, and you're taking care of your aging mother and all the factories either automate or send the jobs overseas, you can't, right? You know, you have constraints in your life. What if you have a learning disability and you can't learn very quickly?

If the rate of change gets to a certain point, it requires more of people than they can possibly accomplish, and, you know, the faster that rate is, the more you drop people. You know, you have the person taking care of their aging parent. You have the, you know, the person who has a learning disability. Eventually, you get to the people who really care. They work hard, and you just can't learn fast enough. Eventually, there's nobody who's able to adapt fast enough.

So, I think it's a...while we absolutely must be adapting, and that's the only way we're going to get through, I also think that there's a finite ability to adapt that has a variety of constraints in it, and that makes it more broadly challenging.

MATT: Okay. You threw a wrench in my response because I was going to become an automation engineer.

MIKE: Oh [chuckles].

MATT: But if I have a learning disability, then maybe I'm not. Maybe I will become a cog in the machine.

WILL: Man, I don't know. I, you know, I guess I understand that, but, like, I resist this narrative. But I have come to accept that I am actually pretty smart, and, like, I'm good at programming in a way that average people are not. And it isn't just a matter of interest, like, there is a level of aptitude that, like, people who are good at the job have. And so, well, how's that going to be different? If you have a learning disability, like, probably software development...unless you have maybe a specific particular set of skills and a lot of interest, you know, this isn't probably going to work out for you. There are other aspects of life and things you can contribute to the world other than this, you know? Like, so what would change?

MIKE: Let's say that things accelerate really quickly, right? Now, given that technology has been accelerating, you know, forever, I assume it's going to continue to accelerate. And if it's exponential, then...and this is a thought experiment, right? So, I'm not saying this is the case today. But let's say that the technology, you know, there's...it's already been for a long time where you had to be constantly adapting, or you couldn't keep up. And let's say it gets to the point where it's physically impossible to spend enough time in your day to be able to keep up with the changes. That's technically possible for that to happen as the technology accelerates, right?

WILL: We already there --[laughs].

MIKE: If the technology is able to accelerate that quickly, eventually, there's a point where the humans just can't keep up.

WILL: Yeah, maybe. I mean, maybe. I'll believe it when I see it. We'll see. I mean, I think the best...I think one of the better analogies right now, and you've heard this from me before, is chess, right? Chess is a solved system. It is solved, and the computer has won. But you can have a computer that runs on your cellphone that will beat the brakes off of the best, arguably the best chess grandmaster who's ever lived, and it will whip him like a rented mule every single time.

But the best chess players are what they call centaurs, right, which is, like, a human chess grandmaster, you know, coupled with artificial intelligence, and you have both of them. And another thing that you've heard, you know, second only to XP, is the future...which maybe I'm coming to revise. I'm coming to revise that maybe. But it's that, you know, the future's already here; it's unevenly distributed, right?

And so, if we look at chess, which is cutting-edge...and people talk about, like, radiology as, like, the bleeding edge of AI. But I actually think chess was, like, the vanguard of the whole thing. So, okay, it's better than us. It is better than any human being by a lot. But the very best...

MATT: Well, it's based off of Magnus Carlsen, so...

WILL: It's based off a lot of people. It's based off Garry Kasparov. Like, he was the original John Henry, right, martyr of [chuckles] chess. But still, like, even though the AIs are way out in front, the coupling of human expert with an AI is, you know, the current reigning champion. And I think programming is a hell of a lot more complicated than chess. A lot [laughs].

VIVIAN: Okay, I have a few things. One, there are chess engines that are based entirely on playing themselves. They are not trained on any existing historical games. I believe AlphaGo is one of these. I could be wrong.

MIKE: It did use --

VIVIAN: But all that it did was play itself hundreds of millions of times, trained on what won. And it is, as far as I know, one of the only engines, if not the only engine, to be more powerful than the most effective, like, manual engine, which is considered Stockfish, which uses some, like, neural work, but is largely just a GPU-accelerated branch, like, predicting machine.

And so, even human-augmented machines, like, ones that have studied human games, are not better than the ones where the machine plays itself. Chess is not something that we necessarily know all of the answers to. We know endgames with, like, four pieces, maybe five or six pieces, and that's the most that we've been able to solve. But from the beginning, we still can't solve all of chess and know if there is a correct answer.

But, like we're saying, programming is a much more complicated problem than chess. It's not something that can fit into the weights that can be stored in a single, like, computer. It's not something where the answer for every problem is solvable necessarily, because chess, in theory, is, even if it would take the heat death of the universe to calculate it, it still is, in theory, mathematically solvable, but programming isn't.

Coming back to it, though, as kind of a more entry-level software engineer, as a junior programmer, someone who's still trying to make a place in the industry, how do I adapt without losing all of the skills that come from the years of experience solving the easy problems that I get stuck on, that teach me the lessons so that I never make those mistakes again so that I can solve the hard problems? How do I upskill myself when the AI can do most of what I can do? Maybe I can do it better still, but it's getting faster while I'm getting better, like, it's growing as I'm growing.

WILL: You know, I don't know. I mean, like, I think the best answer, I mean, and I alluded to this a little bit as I'm, sort of, like, adopting and updating my, like, sort of dogmatic, you know, reliance on, like, sort of, like, XP and stuff like that whereby, okay, now we have an always-on perfect pair programming companion with access to everything. And so, I'm very intrigued. So, I say this, and I'm very, very intrigued at, you know, going, sort of, like, agentic and like, "Hey, here's a problem. Here's some specification. Work on this overnight, and let's review in the morning," which I do a lot, and I run out of tokens a lot [laughs]. I run out of a lot of tokens [chuckles] doing that, sort of, like, loop-based thing, which I don't care; I'll do it again.

Versus, like, the sort of, like, pair programming where, like, we're just going to pair up on this thing, and we're going to bat it back and forth. And I'm going to do all the typing. I type everything, right? And then we're going to talk back and forth, and I'm just going to knock the ball back and forth. Even in a situation where I'm writing big projects fast, I can still type up every character that a multi-file MR would have in it, you know, in minutes, you know, 30 minutes, 40 minutes. And so, like, okay, well, let's bat the ball back and forth so that I know, so that I can have confidence.

And then, I don't know, I think one thing that I have noticed, some of the [inaudible 37:35], I think, have an ideological lens that they view themselves through. Claude does not want to collaborate with you. Claude Code wants you to give it the problem, and it wants you to go away, right [chuckles]? Like, they're not interested. They're not invested in this, sort of, like, pairing paradigm. They're interested in like, "I'm going to give you the answer," you know, and, like, long delays, and, you know what I mean? Like, they're going to delay a lot, and they're not going to give you...They don't give you very good, like…

Anyway, it's just a...it's a paradigm, I think, which is maybe low-key a marketing engine, right, where their thing is, like, they are the magic oracle, and you give the oracle your problems, and the oracle comes back with a solution. You shut up and eat your code. But I would think that's...it's a philosophy, but there's a healthy amount of self-interest around that, right? Like, that's of sort of, like, Centaur, this AI-enabled super programmer, not exactly their business model. Because, you know, you can't have mega Opus Symphony 6, you know, for a low, low thousand-dollar-a-month monthly fee. Like, that actually, you know what I mean, like, the back-and-forth pairing partner, that's probably pretty cheap actually, you know?

Anyway, and I could be wrong about all this stuff because my position on it is evolving, you know, day by day. Because I learn more as we learn more, as things, you know --

MIKE: And the industry changes, too. You know, but what you're saying is consistent with the research we talked about earlier, which is that Centaur approach, you know, use it as a coach, is both effective, maybe second most effective, but gives you the knowledge you need so that you can be effective on the next round. So, probably more sustainably effective than other approaches.

So, it would seem that there's research backing up that approach today, that that's the way you do it. And this goes some to what Matt was saying. You go through the hard work, right? You adapt. You learn from this coach who's going to make it hard. This is a mean coach [laughs]. It's going to push you and push you and push you. But that's the only way you're going to keep moving forward is if you are willing to go through that process to internalize the knowledge. Does that seem right?

WILL: Yeah.

MIKE: Am I stating it inconsistently with both research and experience?

WILL: So, I have a friend of mine. He's a high school teacher, right? And he analogizes the sort of, like, younger generation better than I could, right? Because he's a high school teacher, and what he says to me (We get a couple of beers [inaudible 40:36] bar.) is like, "The high school students that are graduating right now, the top 20% of those students are going to be the smartest people who ever lived [chuckles]." Everybody else is screwed.

And I liken that to sort of like YouTube. I love YouTube. I love it. Anything that I ever wanted to do, I could go on YouTube, and I have this, like, beautiful tutorial, and it's like, "Oh man, I could do this and this and this." And that's how I use YouTube. I learn about, you know, like, history, and mathematics, and science. And how do I fix this washing machine and all this stuff? I'm interested in, like, learning and using the tool to get better.

It is also absolute gutter garbage, and, I think, 80%, not even 80%, I think the proportion is sadly higher, of YouTube enjoyers are giving themselves a home lobotomy day by day. And, I think, AI is, you know, bluntly going to...I think it's going to follow that bimodal distribution.

But, you know what I mean, in the end, like, you know, if you're worried about it or anxious about, like, how you, you know, stay a good programmer or use AI to become a better programmer, and learn more and do more, that's really a matter of choice, you know? How do you use it? How do you want to use it? Do you want to just clock out and go home? Respect that. But, you know, if you want to be sustainable, you've got to, like, skill up. It's entirely your choice.

MATT: Existential question for you. Are you a programmer anymore?

WILL: Today I am [laughs].

MATT: Well, if you're not doing the programming, you're doing the architecting. You're doing the engineering. But are you actually programming? Because you're not defining the code that's written line by line, right? You're not dictating what your function name is unless you're very explicit and using just auto-complete or something. So, are you a programmer anymore, really?

WILL: I'm an engineer, always have been.

MATT: Yes. Yes. Exactly. That was what I was getting at, right? Because they are different. I mean, developer, programmer, engineer, they get interchanged a lot, but I feel like they're different.

MIKE: There's job statistics. I read an article about this sometime in the last couple of years. There are job statistics that say that the programmer has largely disappeared. Because there used to be companies where they'd have programmers, which were basically grunt workers who'd go and write the code based on specifications.

MATT: Punch cards.

MIKE: Well, yeah, specifications. It might be punch cards. But they'd, like, get specifications from more senior people, and then they'd go and make those happen, and that job just doesn't exist anymore.

WILL: Yeah, but, like --

MIKE: We need people --

MATT: Or those are our AI agents.

WILL: I'm a software engineer, you know, on a meeting. I'm a software architect when I want a raise [laughter]. And I'm a programmer when I don't want to talk about it at the barbecue.

MIKE: Yes. That's so true [laughter].

MATT: And systems architect, right?

WILL: Solutions engineering, architect, I don't know. I'll stack them. I'll stack them up [laughter]. I'm trying to get a bump. Like, I could extend that title like an ancient Persian king.

MATT: Well, there was a point in time, and maybe there is a little bit for me still, where I absolutely did not like being called a developer, right? Because I went and got my computer science degree. I put in the work. I spent the time. So, to me, it was like, I earned the title of an engineer, so just like a PhD earns his title to be called doctor, right?

WILL: I don't know. I have a capital E engineering degree, and, I don't know, man [laughs].

MATT: I mean, it is something that you could argue either way, and everyone has their opinions, but I'm just, you know, throwing that out there.

MIKE: And, you know, we're talking about the words, but the idea that we're here to solve problems; we're not here to write code, is important.

MATT: That's right.

MIKE: If you think that your job is writing code, your days are numbered.

MATT: Absolutely. I wander around the office all day and say that to people. Well, I don't tell them their days are numbered, but I am very explicit about our job is not to write code; it's to solve problems.

WILL: That giant [inaudible 45:20] over your shoulder it kind of gets the message across. You don't have to rub their nose in it [laughter]. My real job is Horseman of the Apocalypse.

MATT: Behold the pale horse.

WILL: Yeah, I mean, really, in the end, I'm lazy, and I want everybody else to be lazy, too. I want it all done. I want to save people miserable scut work to the extent that it's available, you know?

MATT: Absolutely.

WILL: It’s, I want to buy this TV. Like, I want a good deal on a TV, and I don't want to put up with the bullshit. I'm in, you know? Like, I don't want people to, like, toil in boring, stupid drudgery, including me. That is foundationally what I do, really. I save people energy.

MATT: I use that one often as well, the "we're lazy." Because we don't want to do this over and over again. We want to do it once and be done, right?

WILL: Yeah. I mean, that's been my job from the very beginning, from the very beginning, from day one. It was like, "That was annoying. I should write a program, so I don't have to do this anymore. That sucked."

MIKE: I remember being in junior high, and we had an assignment to solve problems using the quadratic formula. And so, I went and I, you know, with my basic coding skills, I wrote a software that I would put in my numbers, and it would solve it for me and [laughs] allow me to check my work. I figured if I could write a software to do it, I understood what I was doing [laughs].

VIVIAN: Mike, I've had the exact same experience.

MIKE: Did you really [laughs]?

VIVIAN: Except it was box-and-whisker plots in middle school math. Exact same thing [laughter].

MATT: And essentially, that's what we're doing today, right? Because I'm tired of writing code on a keyboard. Now I'm going to create an agent that will go do it for me, and then another one that will do another task for me. And there's our agentic workflows, because we're eliminating the things that we don't want to do anymore, and if that weren't true, we wouldn't be creating them.

MIKE: Absolutely. I mean, like, I want...I don't like doing code reviews. I don't like doing code reviews, and I hate waiting for code reviews. So, you know, I'm making agents to be like, "Okay, I want me in a box, and then I want you in a box, so I don't have to hear your mouth about what I named my variables [laughs]."

KYLE: It says a lot about what we find important, too, because how many of us are relying on AI summaries of our meetings? We don't want to be in them [laughter].

WILL: I don't know, I think, maybe it's just my, like, manner of speaking, but AI summaries of the meetings that I've been in, when I go and read them, the transcript usually comes out pretty good, but the AI summaries of me talking are a travesty. I don't know, maybe that's just how I talk.

MIKE: Well, it depends on the AI, but Kyle's got the point. You've read the summary because [laughs] sitting through a meeting where you're involved in 5% of that meeting and the rest of it is listening to stuff that you're not fully engaged with, I mean, that's suffering, and we've all been through it. And if we can automate the parts that don't engage us mentally, we want to.

WILL: I just take a transcript. I could read an hour meeting and, like, parse the non-BS out of it in maybe three minutes [laughs].

MIKE: It goes pretty quickly, amazingly quickly [laughs].

MATT: And we all spend time in meetings that we certainly don't need to attend. And I follow the Elon Musk rule for that one, generally. If I don't feel like I'm providing value, then I usually will just drop.

WILL: I can't do my work while people are talking in my ear. Like, I wish I cared about you less [laughter]. It's hectic.

KYLE: I don't have that problem [laughter].

MIKE: You know, we're drifting a little bit in this idea of meetings [laughter], but it's just one of the many dull tasks that we have to do.

But it kind of brings us back to the central idea, is that, yeah, our job is to make things less dull. Our job is to get rid of the stuff we don't want to do and the stuff that nobody else wants to do. And that's why we get paid, is to go and solve people's problems so they don't have to solve them in some worse way, and we build whole industries on this.

And, you know, to summarize, we can stay relevant if our focus is on that and on actually, you know, going through the work of learning as we go. If at some point you think, "Oh, well, my job is coding," well, then you're frozen, and then that job is going to go away, and you're out of a job. But if you think your job is problem-solving, it's going to be some stretching. You're going to have to keep learning, but you're going to keep solving problems.

MATT: That's right. And just keep your mind sharp. We're just solving the same problems in a different way.

MIKE: I think that's a good place to tie this up. Good stuff, and highly relevant.

MATT: Always a pleasure to be here.

MIKE: Great. Until next time on The Acima Development Podcast.