A Good Idea Shouldn't Have to Be in English

For most of computing history there was a quiet entry fee on top of the obvious ones. Not just logic, not just patience, not just access to a laptop and a connection. The fee 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 didn't just have to learn how a loop works. 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

Here is the part that bothers me. That entry fee never measured who had a builder's mind. It measured 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. She can watch it take shape. And then she can learn the concepts underneath by seeing what her words produced. The idea comes first. The syntax, and even the English, become things she grows into rather than gates she has to clear before she is allowed to start.

That reordering matters. 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 worth being honest about, and it 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. 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, and there is almost nothing left for it to invent.

Same idea, two completely different results. The gap between them is not English. It is precision, and precision is the kind of thing 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

Somewhere along the way, "vibecoder" became an insult. Shorthand for someone who doesn't really understand what they're building, who is just vibing while the machine does the work.

I think that is backwards.

Directing an AI tool well is a real skill. Being precise about what you want. Noticing when the output is subtly wrong. Knowing what to ask next. Verifying the result instead of trusting it. Those are exactly the habits good engineers already have, and they are the habits that now let a much larger group of people participate in building 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, not as a way to dodge programming, but as a more honest front door to it.

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 people 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.

Under the plain-language surface, 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 them never stop being yours. Deciding what to build is intent, confirming that what came back is actually right is verification, and no model takes either off your hands. A beginner runs that loop on day one with a single sentence. A senior engineer runs the same loop with harder questions at the checking step. Nobody graduates out of it.

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 already moved. 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, not a finished thing with results to point at. But the direction is the whole point: let the people the old filter turned away walk in through plain language, then hand them the concepts underneath as fast as they want to take them.

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.

That way in is what we are trying to build.