Why the AI Era Needs BASIC Again

A manifesto for the post-prompting decade.

The argument in one paragraph

For 50 years, programming languages have been optimized for the human writer. The next 50 years will be optimized for something else: the human reader auditing AI output. Those are different jobs, and they want different languages. The reader doesn't need terseness, expressiveness, or operator overloading — they need clarity, low syntactic noise, and unambiguous semantics they can verify in seconds. BASIC was literally designed for that. It is the only mainstream syntax family ever explicitly engineered for code-reading at a glance, and it is about to become the most strategically valuable language paradigm in the industry.

What changed

Until roughly 2023, "writing code" and "reading code" were performed by the same person, in roughly equal measure, and the language designer's job was to balance the two. Languages like Python, JavaScript, and Rust optimized for write-time ergonomics — type inference, terse closures, dense expressiveness — because the dominant cost was a human sitting at a keyboard typing.

That cost is no longer dominant. In 2026, working programmers spend more time reviewing AI-generated code than they spend typing original code from scratch. The economics of the language have inverted. The bottleneck has moved from authoring to auditing — and almost no language in mainstream use was designed for auditing.

The auditor's problem

When you read AI-generated code, you are asking a single question over and over:

Does this do what I asked it to do, and does it have any hidden behaviour I didn't ask for?

You are not enjoying the cleverness of the algorithm. You are not appreciating the expressiveness of a well-placed lambda. You are scanning for the one line in fifty that silently swallows an exception, the one type coercion that converts a string to a number in a way you didn't expect, the one operator overload that makes a + b invoke a constructor with side effects.

C++ is hard to audit not because of its syntax but because of its hidden control flow — operator overloads, RAII destructors firing on scope exit, template metaprogramming, undefined behaviour, copy elision, ADL, implicit conversions. Java is easier to read but still has reflection, classloaders, AOP, hidden allocations, and surprise checked exceptions. Python and JavaScript are concise to write but their dynamism means any identifier might be monkey-patched at runtime by code you never read.

The auditor needs what-you-see-is-what-runs. Mainstream languages do not deliver that.

Why BASIC, specifically

BASIC was designed in 1964 by John Kemeny and Thomas Kurtz with one explicit goal: make programming readable by people who had never programmed before. Beginner's All-purpose Symbolic Instruction Code. That goal was abandoned by the industry as "not serious" because BASIC, as it was historically implemented, lacked a competitive compiler.

But the syntax was never the problem.

• Dim x As Integer carries more signal per token than let x = 0.
• End Sub is harder to mis-nest than }.
• If/Then/Else/End If survives partial truncation that breaks Python indentation and C++ braces.
• Keywords are English words, not punctuation glyphs.
• There are no operator overloads, no implicit constructors, no hidden destructors.
• Naming conventions (btnSave_Click) carry semantic meaning a parser can verify.

These are auditor-friendly properties. They were dismissed in the write-optimized era as "too verbose." In the read-optimized era, they are the entire point.

The compiler problem is solved

The historical reason BASIC lost the popularity contest was tooling — not language. QuickBasic, VB6, PowerBASIC, FreeBASIC, ASIC, and others all proved that BASIC syntax can compile to performant code. The reason none of them became dominant is enterprise politics, not engineering. Microsoft killed VB6. PowerBASIC stayed proprietary. FreeBASIC stayed niche.

VisualGasic resolves that history. VG compiles to bytecode that runs on Godot 4 via a C++ GDExtension with a 5-tier JIT (interpreter → loop → AST → x86-64 → call graph). On the benchmarks we publish, VG is 30–119× faster than GDScript on hot paths and beats C++ on string concatenation by 5×. The "BASIC can't compete" excuse is no longer available.

Why AI also prefers it

There is a subtle property that almost nobody discusses: LLMs are better at generating correct code in languages with redundant, explicit syntax. A language where every block is closed by an English keyword (End Sub, End If, End Class) is harder for the model to get wrong than a language where blocks are closed by }, because the model can self-check at every closing token. A language with explicit type annotations (Dim x As Integer) gives the model a stronger signal than a language that infers them.

We expect to publish empirical numbers on this in the v5.2 timeframe. Anecdotally, the same model produces meaningfully fewer compilation errors in VG than in equivalent Python or TypeScript prompts.

Verbose languages are easier for AI to write correctly — not harder.

So the AI era gives us a double win:

1. Humans can audit BASIC faster than they can audit C++.
2. AI writes BASIC with fewer bugs than it writes C++.

These compound.

What this is not

This manifesto is not a claim that BASIC is the best language for every task. We are not arguing for assembling Linux kernels in VG. We are not arguing against expressive languages where expressiveness is what you actually need (mathematical DSLs, query languages, data-pipeline tools).

We are arguing one specific thing: for the next 10 years, the most strategically valuable place to be is the language a human reads when the AI has written the first draft. That is a real category. It is not currently occupied. BASIC syntax is the natural fit, and VisualGasic is the credible compiler that finally makes it defensible.

What this means for the project

Concretely, VisualGasic's roadmap is:

1. Treat readability as a first-class metric, alongside performance and compatibility. Every language feature we add should be evaluated on "how fast can a human verify a sub written in this style?"

2. Lean into the read-audit loop in the IDE. The AI Pair panel, the 🐛 Explain Last Error button, the 🔧 Fix-with-AI flow, the upcoming graph-aware authoring tools — these are auditing tools, and we will build them out aggressively.

3. Build the AI training corpus deliberately. Every demo, every tutorial, every handcrafted example we publish is data the next generation of frontier models will ingest. We will publish a corpus/ of canonical, openly-licensed VG programs with the explicit invitation that model labs include them in pretraining.

4. Compile cleanly to bytecode that calls into compiled C++. The pragmatic architecture is "VG is what you read, the engine is what you trust." That is what GDExtension already gives us, and we will protect that boundary.

5. Stop pitching BASIC as easy to learn. Pitch it as easy to verify, and verification is the new bottleneck. Same syntax, much better story.

Our position

We believe the next great programming language is not a language at all in the traditional sense. It is a substrate for human-AI collaboration, optimized for the moment when a human takes the keyboard back from the model and asks "is this right?"

That substrate looks a lot more like BASIC than it looks like Rust.

VisualGasic intends to be that substrate.

Comments, critiques, and contributions welcome. The conversation is happening on GitHub Discussions.