A Good Idea Shouldn't Have to Be in English

For most of computing history, writing software demanded logic, patience, and access to a laptop and a connection. On top of those obvious costs sat a quieter entry fee, which was English.

The hidden entry fee

Think about what it actually took to learn to build software. The keywords were English. The documentation was English. The answers you searched for at 1 a.m. were English. The frameworks, the conference talks, the tutorials, and most of the people teaching them were Western and English-first.

If your first language was Kinyarwanda, or Tagalog, or Quechua, you had to learn how a loop works in someone else's language, well enough to read an error message under pressure. That is a real tax, and it was paid disproportionately by the people who were already furthest from the tools.

The filter measured proximity, not talent

What bothers me is that the entry fee never measured who had a builder's mind, only who happened to be born close to the industry.

A builder's mind is something else entirely: the instinct for systems, the patience for edge cases, the stubborn "what if we did it this way instead." Plenty of people have that instinct and never got to find out, because the on-ramp was written in a language that wasn't theirs and the culture around it treated that as their problem to solve.

We lost an enormous amount of talent to a translation gap.

What changes when you can speak your own language

Large language models change the shape of the on-ramp. You can describe what you want in the language you actually think in, and the model can turn that intent into working code.

Picture a student in Kigali who wants to build a small app for her community. She can describe it in her own words, watch it take shape, and then learn the concepts underneath by seeing what her words produced. The idea comes first, while the syntax, and even the English, become things she grows into rather than gates she has to clear before she is allowed to start.

For the first time, the thing you need on day one is a clear idea and the willingness to be precise about it, not a second language.

Precise beats fluent

There is a catch that turns out to be the first real skill. Speaking your own language gets you through the door, but the model still only builds what you actually describe. Ask it to "make a login page" and it has to guess almost everything: which framework, which fields, whether the email is validated, what happens on a wrong password, when the page even counts as finished. It will guess, and you will spend the afternoon discovering what it assumed. If you ask instead for a login page with an email and password, where the email is checked, a failed sign-in shows an error, and a success moves the user along, there is almost nothing left for it to invent.

The same idea gets two completely different results, and the gap between them is precision, which you can learn in whatever language you already think in. Turning a vague intention into a spec clear enough that the machine cannot wander off is most of what good direction is, and it is most of what the course spends its time on.

"Vibecoder" shouldn't be a slur

"Vibecoder" gets used as an insult for someone who doesn't really understand what they're building and is just vibing while the machine does the work. The Problem Was Never Vibecoding argues that directing a model well is a real skill.

The other problem with the insult is who it lands on. Describing what you want in your own language is how a much larger group of people now gets to build things. Calling that a slur is gatekeeping with a new coat of paint. The people sneering are often the ones who paid the old entry fee and would prefer it stay expensive.

Vibecoding is the front door, not the back door

This is why we are building a Vibecoding course lane as a more honest front door to programming.

It teaches computational thinking through plain-language direction first, then bridges to real code and real CS concepts as the learner is ready. The point is to let the people that the old on-ramp filtered out walk in, build something true to their own vision, and keep going as far as they want, whether that is shipping one useful thing for their community or going all the way to deep systems work.

Underneath the plain language, the course keeps circling back to one loop: you say what you want, the model generates something, you check whether it did what you meant, and you refine from there. Each chapter mostly asks where a given tool changes the cost, or the risk, of one of those steps. Two of those steps never stop being yours, because no model can decide what to build for you (intent) or confirm that what came back is actually right (verification). A beginner runs that loop on day one with a single sentence, and a senior engineer still runs it, with harder questions at the checking step.

None of this is a fringe bet. Most working developers already write code with AI somewhere in the loop. A recent Y Combinator batch included companies whose codebases were almost entirely model-generated. Most new graduates say they want this kind of training built into their degree rather than bolted on afterward. The on-ramp has already moved, so the open question is who gets to walk up it and in which language.

I want to be straight about where the course actually is. It is early, free, still being written in the open, and it has not run in a real classroom yet, so this is the shape we are building toward, with no results to point at.

A good idea shouldn't have to be in English to become real. It shouldn't have to be in code on day one either. It should just have to be good, and the person behind it should have a way in, which is what we are trying to build.