Going Back to “BASIC’s
Threads & Perspectives: Your “Mother Tongue” The New Programming Language
Inspired by: The democratization of access to intelligence for 8+ billion people
When I started my career in technology, I was introduced to a large underwriting application that supported the Property and Casualty business. My role was to develop, maintain, update, and test the code. It took a lot of time to understand the existing code and relate it to functionality.
I happened to come across a set of insurance manuals collecting dust, and out of curiosity, picked up the Property and Casualty manual. After I read it, it dawned on me that there was a whole new language (English) that I had to learn about insurance. This helped me accelerate my ability to do all of the required tasks. Most importantly, I had learnt to speak the language of underwriters and could listen to what they were saying, understand, and translate their intent better. Did they care if the application was written in C++ or Visual Basic? Probably not.
What they cared about was whether I understood what they meant. And once I did, they wanted to engage with me. Over time, I almost stopped thinking about programming languages altogether. The translation from business intent to system behavior was valuable work. Not the code.
That was the early 1990s. Over the next three decades, across different companies, roles, and industries, I kept seeing the same pattern. The people who created the most value were not the deepest specialists — they were the ones who could cross the gap between what the business needed and what the technology could do. The ones who learned the other side’s language.
Now, in 2026, I watch that pattern playing out at a civilizational scale, not through people like me doing it manually, but through the architecture of AI itself.
This essay explores that shift. It draws on the Suzuki method of musical education, on the history of the BASIC programming language, and on the structural parallel to the telecom revolution that brought wireless connectivity to billions who never had a landline. These are different stories from different domains, but they share a single architectural insight:
The technology that wins is not the one that is most powerful. It is the one that eliminates the prerequisite for participation.
In 1964, Kemeny and Kurtz couldn’t teach every Dartmouth student assembly language. So they created BASIC — Beginner’s All-purpose Symbolic Instruction Code — and met the students where they were. In 2026, we can’t teach eight billion people Python. So we are making their mother tongue the programming language.
We are going back to BASICs.
Meet Them Where They Are
When it comes to adoption, every major technology wave tells the same story. It is never about making people more capable, but it is about removing the barrier and making it accessible based on what they are already capable of.
VisiCalc, the first spreadsheet in 1979, eliminated the need for programming to do financial modeling. Mosaic, the first widely adopted browser, eliminated the need for people to learn Unix, protocols, and networking and made discovery as simple as point and click. You just needed to know what you were looking for.
“There’s an app for that.” The mobile revolution was accelerated by eliminating the need for a computer and its accessories and bringing the capability to people, either through smartphone features or text-based capabilities.
The pattern is consistent. Each wave, the prerequisite was real until it wasn’t. Assembly language, programming, networking protocols, and desktop operating systems. Each one was genuinely necessary in its time and eventually abstracted away, revealing the more durable requirement underneath: logic, business understanding, curiosity, and intent.
Today’s prerequisite, programming literacy, is being abstracted away just as the others were. And what it reveals is the most human prerequisite of all: knowing what you want and being able to say it in your own language.
The underwriters at the insurance company never needed to learn C++. They needed someone who could hear their intent and translate it. Each wave of technology has been bringing the machine closer to the human. Programming literacy may be the last prerequisite we have to consciously eliminate.
Fluency Before Literacy
Every child in the world learns their mother tongue fluently. Whether it is Navajo or Japanese or any of the 7,000+ other languages spoken today, no exceptions. They don’t fail at acquiring their native language. Shinichi Suzuki spent decades observing this and concluded that it is the sequence that matters in learning.
Babies absorb tone, rhythm, and melody for months before they produce the first word. They imitate sounds before they understand grammar. They speak fluently for years before anyone teaches them to read. The formal structure of language comes after these competencies are built through immersion. This sequence drove extraordinary results when Suzuki applied it to music education, not because the children were gifted, but because the sequence was right.
This model appears across a wide variety of domains, sports, science, and business. David Epstein’s research in the book Range documents it. People who sample broadly, explore without premature commitment, and delay specialization consistently outperform those who go deep too early. The more unpredictable the environment, the more breadth beats depth.
The pattern is:
Immersion → Imitation → Fluency → Formal structure.
This matters now because large language models follow the same sequence not by design philosophy, but by architectural necessity. A foundation model is pre-trained on the broad corpus of human expression: billions of pages, every register, every domain. It absorbs patterns before it “understands” anything. It achieves fluency, the ability to generate coherent, contextual language, before any formal structure is imposed through fine-tuning or alignment.
The formal layer safety, domain specialization, task-specific behavior — comes last. Just as it does for children. Just as Suzuki argued it should be for musicians.
When smaller, specialized models are built for specific domains — customer service, medical diagnosis, and legal review, they derive their capability from this broad foundation. Whether through direct distillation or through training data curated by larger models, the breadth has to exist somewhere in the lineage. No one has built a capable, generative small model that doesn’t trace back to a large one. The broad phase can be inherited, but it cannot be skipped.
Fluency first. Literacy after. In children, in music, in AI.
If the sequence is clear, broad immersion before specialization, fluency before formal structure, then the question becomes: what happens when this architecture reaches people who were never on the old path to begin with?
The Leapfrog
India never built landlines to every village. Neither did most of Africa, Southeast Asia, or Latin America. The “last mile” problem running copper wire to every home, every community, every remote settlement was too expensive, too slow, and ultimately unnecessary. Wireless bypassed it entirely. By 2026, there will be more mobile phone subscriptions worldwide than there are people.
The landline wasn’t replaced. It was skipped.
This is the pattern of the leapfrog: when the barrier to the old path is high enough, and the new path is accessible enough, billions of people don’t adopt the next version; they skip an entire generation of infrastructure.
Mobile didn’t just give people phone calls. It gave them banking without bank branches. M-Pesa launched in Kenya in 2007, and within a decade, more Kenyans had mobile money accounts than had ever held a traditional bank account. The phone wasn’t a substitute for the bank. It was a bypass.
The same leapfrog is now happening with programming.
You can’t teach eight billion people to code. The infrastructure required education systems, curriculum, years of training, and access to development environments is the equivalent of laying copper wire to every village. And just as wireless made that last mile irrelevant, natural language as an interface is making programming literacy irrelevant for most of what people need computers to do.
Get Sudi Navile’s stories in your inbox
Join Medium for free to get updates from this writer.
But this leapfrog is amplified beyond the telecom precedent in three ways.
First, zero marginal infrastructure. Wireless still required towers, spectrum licenses, and handsets. Natural language as an interface requires a browser or a phone devices that already exist in most hands. The physical layer is already deployed from the previous leapfrog.
Second, the capability is bidirectional. Mobile gave people a device to consume services and make transactions. AI gives people the ability to create, specify, generate, and deploy software. The gap between user and builder collapses. You are not just connecting people to the network. You are handing them the means of production.
Third, compounding speed. The telecom leapfrog took roughly fifteen years to reach global scale. The AI leapfrog is operating on a two-to-three year cycle because the distribution infrastructure, internet, cloud, and mobile already exist. Each leapfrog stands on the shoulders of the one before it.
There is one more difference, and it may be the most consequential. Every previous leapfrog democratized access but still required a producer ecosystem that couldn’t bypass the prerequisites. Mobile banking lets millions skip the bank branch, but someone still had to build the platform and that required traditional software engineering. Smartphones let billions skip the desktop, but “there’s an app for that” required millions of developers who went through the old path. The consumer leapfrogged. The producer never did.
AI collapses both sides. When the interface is natural language, the act of specifying what you want and the act of creating it become the same act. The consumer and the producer converge. For the first time, the leapfrog doesn’t just bypass the prerequisite for using technology — it bypasses the prerequisite for building it.
The underwriters at the insurance company didn’t need a programming leapfrog. They had me. Eight billion people can’t each have a bilingual translator sitting between them and the machine, or can they? That is exactly what AI is. And unlike me, it speaks all 7,000+ languages.
The leapfrog gives eight billion people the capability. But capability without trust doesn’t scale. The next question is: what do you hold onto, and what do you let go?
Lose Your Artifacts
I never cared how the compiler unrolled a loop. Neither did the underwriters at the insurance company. They cared whether the system did what they needed it to do. The code was an artifact — necessary at the time, but never the point.
Every wave of technology has asked us to let go of an artifact we thought was essential. Assembly programmers mourned the loss of machine-level control when high-level languages arrived. Designers resisted templates. In each case, the artifact felt like the craft. Letting go felt like losing something real.
AI asks for a bigger release. Not just the code, but the visibility of the implementation path. When a large language model generates a solution, you cannot trace its process the way you could read source code. The artifact, the visible, inspectable implementation, is gone.
This is only a problem if you believe the artifact was where the value lived. It wasn’t. Most people don’t understand how a car engine works. They turn the key and trust it to get them where they need to go. The value was never in the engine. It was getting to the destination.
The value lives in two places: the intent that initiated the work, and the outcome that resulted from it. Everything in between the language, the framework, the architecture, the elegance of the code was infrastructure. Necessary, but not the point.
What you do hold onto is the reasoning. The code is throwaway. The decision logic is not. Why did the system make this choice? What criteria did it weigh? What did it prioritize and what did it trade off? That trail — expressible in natural language, in plain markdown, in the mother tongue is the accountability layer. You lose the implementation artifact. You keep the decision artifact.
The underwriters didn’t evaluate my work by reading C++. They evaluated it by whether the system reflected their judgment correctly, and whether I could explain why I built it the way I did. Intent in, reasoning visible, outcome out. The code in between was mine to manage. Now it is AI’s.
The question this raises is: if the implementation is throwaway and the reasoning must be preserved, how do you define what “right” looks like before the AI builds anything?
What Right Looks Like
In software engineering, there is a discipline called test-driven development. You write the test before you write the code. The test defines what “correct” looks like. The code is then written to pass it. If the implementation changes, rewritten, refactored, and/or replaced entirely, it doesn’t matter, as long as the test still passes.
This same principle applies to the world we’ve been describing, where the implementation is throwaway, the artifact is AI’s to manage, and the human’s role is to specify intent. But the unit of work shifts. You are no longer writing tests for code. You are writing tests for intent. (TDI: Test Driven Intent)
The underwriters at the insurance company did this instinctively. They didn’t hand me a technical specification. They described what the outcome should look like, how a policy should be rated, what factors should be weighed, and what the edge cases were. They defined correctness in their language. The implementation was my problem.
This is the same discipline, scaled. The human specifies what “right” looks like in natural language, in their mother tongue. The AI generates whatever implementation satisfies it. If the implementation is wrong, you don’t debug the code. You refine the intent. If the AI rewrites the entire solution in a different language or framework, it doesn’t matter as long as the specification is still met.
This resolves the tension from the previous section. You don’t need to see inside the black box. You don’t need to understand the implementation. You need to define what “right” looks like clearly enough that the outcome can be verified against it. The accountability lives in the intent specification and the reasoning trail, not in the artifact.
Humans are not naturally good at defining what “right” looks like. If requirements could be wrong and briefs could be incomplete, you should expect intent to be ambiguous as well.
But the previous leapfrogs didn’t wait for people to become better communicators. The technology has adapted. Search engines learned to interpret bad queries. Spreadsheets offered autocomplete. Smartphones offered autocorrect. The gap between what the human meant and what the machine understood was closed from both sides.
AI narrows this gap further than any previous technology — because it can ask back. It can clarify. It can offer options. It can generate a first draft and let you react to it, which is far easier than articulating intent from a blank page. The human doesn’t have to be a perfect specifier of intent. They have to be a good judge of outcomes.
And that, “Judging whether the result is right “, is something humans are very good at.
What We’re Not Imagining
This essay has argued that the pattern is clear: meet people where they are, fluency before literacy, lose the artifact, define what right looks like. But every one of these principles assumes that humans set the direction and AI executes.
What if we are already running into our own limitations?
In 2016, AlphaGo played Move 37 against world champion Lee Sedol. No human in the history of Go — thousands of years, millions of games — had ever conceived of it. It violated established theory. It worked. The entire global repository of human Go knowledge did not contain this move.
AlphaFold predicts protein structures with extraordinary accuracy. Biochemists can verify the output — the structure matches experimental data. But the model’s path to the answer doesn’t map onto any framework in biochemistry. It is correct for reasons that no human discipline can narrate.
DeepMind’s AI discovered new mathematical relationships in knot theory. Human mathematicians could verify the results. But they had to work backwards — reverse-engineering the AI’s discovery into a language they could understand. The AI didn’t use human mathematics to get there. Humans used human mathematics to catch up.
These are not future scenarios. They have already happened. And the common thread is this: AI has produced outputs that sit outside the cognitive range of eight billion people. Not beyond our ability to verify, we can check the results. Beyond our ability to conceive. No human was going to play Move 37. No human was going to find that mathematical relationship through the path the AI took.
As we make this capability available to everyone, the question shifts. The previous sections asked: can we remove the barriers so people can express what they want? But what if the deeper barrier is imagination itself? What if the frameworks AI generates, the solutions it finds, the paths it takes — exist in a space that eight billion human minds, collectively, have never visited?
We built this essay on human metaphors, Suzuki, Epstein, BASIC, and the telecom leapfrog. These metaphors work because they map human experience onto AI architecture. But there may be a horizon past which the metaphors stop. Where AI operates in a space that has no human parallel and therefore no human language to describe it.
The ceiling is no longer access to AI. It is no longer literacy. It may no longer even be intent. The ceiling may be the boundary of human imagination itself, and AI is already on the other side of it.
We are going back to BASICs. What we build from here has yet to be written in whatever language we choose, or in one we haven’t yet learned to read.
© — toaiornot.ai, a property of fourthcircle.ai
