- The Strategist
- Posts
- What Language Learning and Montessori Tell Us About AI Coding
What Language Learning and Montessori Tell Us About AI Coding
It's All About Output
Duolingo is one of the most popular language-learning apps. Yet plenty of people who have steadily done their lessons—day in and day out, for years— can’t have a simple conversation.
You may be one of these people.
This isn’t because Duolingo doesn’t work. Instead, if you look at raw amounts of time in the app, I think you’d find the following breakdown of activities:
80% Reading
10% Writing
7.5% Listening
2.5% Speaking
So, for all those hours you’ve spent on the Owl app, only a tiny fraction is spent on listening and speaking, and even the bulk of that is spent on listening.
It is the case that reading improves speaking to a small degree. But if you want to improve a skill, the bulk of your time needs to be spent on that skill. If you want to improve your conversational skills, you must have conversations in French. No amount of fill-in-the-blank reading flashcards will compensate for the lack of raw experience in conversational French.
Montessori Method
Montessori schools know this and take it to the extreme—they have children practice writing before they begin reading. In many cases, children who can learn to write words spontaneously start being able to read them.
Children have a lot to say, so there’s a lot more intrinsic motivation to write so they can express themselves.
In both the case of Duolingo and the case of Montessori, it’s all about output. You want to focus on speaking rather than reading/listening or writing rather than reading.
AI Coding
The big fear around AI coding is that while it does seem to help junior engineers produce more code, there’s a question of whether it will handicap them and keep them as juniors forever.
This appears to be the case if we apply the lessons from language learning and literacy. AI coding generates a lot of code that the engineer will read (if you’re lucky), but they won’t write much at all.
We want engineers to write code. They won’t get better at writing code by reading a lot of it, at least not as fast as if they’d get better by actually writing code.
So, what to do?
Input Matters Too
As I said before, reading does help with writing—some, but not as much as writing. So, while AI, applied poorly, may shut a door, it can also open a window.
One thing we’re lacking in software engineering is tons of comprehensible input. That is, the amount of code that we read is small. Sure, you can browse open source, but the applicability is limited since you aren’t familiar with the requirements or architecture.
AI code, on the other hand, often attempts to solve a problem. We’re familiar with the architecture and intimately familiar with the requirements since we’ve used them to write the prompt. Thus, the output generated by AI is something we should find familiar.
As I implied above, many people tend not to read the output and just assume it’s right. This is wrong on two counts: one, it may not even be the correct output, and two, we’re losing a chance to learn.
By having such a plethora of comprehensible input, we can arrange a learning system that potentially teaches junior engineers faster.
How?
Start ‘Em Young
Rather than using AI to replace or supplement junior engineers, we should focus on using AI coding to invent a new layer underneath them. Interns, high schoolers, etc.… can potentially learn a lot because before, they were doing “nothing” (assuming they weren’t in a good computer science class), and now they have access to mountains of comprehensible input.
These training wheels will create a new generation of junior programmers who have had years of exposure to comprehensible input. As junior engineers attempt to tune the AI down a bit to write more and more, they will have a lot more experience to draw on.
You can see this even in literacy. While output matters most, input is often more manageable and less stressful to get exposed to. So it’s often super easy to just give people mountains of comprehensible input, leaving them less exhausted than having attempted to output that same amount.
For example, while teaching writing first is challenging and has many upsides, as children grow in literacy, exposing them to as much comprehensible input as possible synergizes with a writing-based approach. You can do this very quickly by turning on the captions on your TV, which can expose children to more text than the entire Harry Potter series year after year. It is barely cognitive loading, so it’s not exhausting, so you can leave the captions on. And according to some studies, you’ll double the chance they’re reading at grade level using this “one weird trick.”
Likewise, by exposing non-programmers (whether interns or non-technical CEOs) to comprehensible input, you pave the way and build a foundation for technical understanding we have never had an opportunity to develop before.
The trick? Read the code.