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.

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

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.