Vinglish Zero: Build Week Project Story
Inspiration
Programming languages have a tendency to make things seem unrelated. Say, you have a function written in four languages Python, C, Java, and Vinglish (A language I created before the hackathon, known for its simplicity, and inspired by the movie "English Vinglish" where the main character learns English and faces many struggles as a woman). You would notice immediately that these languages might not even share a shred of surface syntax, and yet a developer is able to understand the intent behind them. But a compiler cannot. (It can turn the task into binary but fails to understand intent)
That gap was the starting point for Vinglish Zero. I essentially wanted to build a tool that reasons about what code does, rather than what it happens to look like. The motivating question was extremely simple: can we really preserve the parts of program understanding that are inspectable and also repeatable, instead of asking say, an AI model to do so?
Zero is my answer: it is a deterministic, language-agnostic semantic reasoning engine for source code. It is certainly not a compiler, another programming language, or an LLM wrapper. It receives code through language adapters, lowers it into a shared Semantic IR, and derives semantic intent through explicit rules.
I was also initially inspired by the fact that many programmers have a habit of pasting their code to GPT and saying "Fix all errors". It's a well known problem that we use quite a bit of AI credits, as well as time in debugging code with an LLM.
What I Built
The project turns source code into a common semantic representation and then evaluates a fixed reasoning pipeline:
Source code
-> language adapter
-> Semantic IR / Semantic Graph
-> facts
-> evidence
-> hypotheses and constraints
-> intent report, diagnostics, and semantic query metadata
The key boundary in this entire thing is the Semantic IR. After lowering, the reasoning engine does not really know whether a graph originated in Python, Java, C, or Vinglish. It sees language-neutral concepts such as functions, loops, conditionals, calls, assignments, mutation, return values, and collection traversal. Hence the term language-agnostic.
From those concepts, Zero derives facts and evidence, evaluates competing
hypotheses, eliminates hypotheses whose required constraints are absent, and
produces a structured IntentReport. The current verification corpus manages to validate 32 semantic
patterns, including accumulators, filters, mappers, reducers, searches,
histograms, grouping, partitioning, composition pipelines, and collection
operations.
The design makes the core claim easy to inspect:
IntentReport = f(SemanticGraph)
where (f) is deterministic. The same semantic graph produces the same facts, evidence, rejected hypotheses, confidence values, and final report on every run. There is no model inference, embedding lookup, external API call, or probabilistic scoring in the runtime path. It is all purely mathematical determinism
Zero also includes semantic diagnostics. A compiler may report a type mismatch;
Zero can connect that issue to a demonstrated semantic role, such as an
accumulator within a reduction, and return structured suggestions grounded in
the report's evidence. Its query command searches intent reports and semantic
pipelines rather than source text, so a query such as filter THEN reduce is a
query over the cached semantic state.
How I Built It
I built Vinglish Zero as a Rust workspace with deliberately narrow boundaries:
- adapters own language-frontend integration and only lower into Semantic IR;
- the semantic engine consumes only the shared IR;
- reasoning separates fact extraction, evidence providers, hypothesis registration, constraints, and confidence calculation;
- diagnostics consume compiler-neutral diagnostics plus intent reports;
- the query and incremental-cache layers consume deterministic reports rather than source syntax.
The Vinglish integration is especially intentional. Vinglish Zero does not depend on compiler crates or expose compiler HIR. The compiler exports a versioned JSON transport model; Zero imports that stable contract and lowers it into its own IR. That lets the compiler and semantic engine evolve separately.
For the other supported frontends, Zero uses official language tooling rather than a handwritten parser: CPython AST for Python, the Java Compiler API for Java, and Clang tooling for C. Cross-language verification compares their final semantic reports rather than their syntax trees. The current benchmark corpus contains 92 cross-language samples, while the verification suite checks that equivalent programs preserve their intended classification across the supported frontends.
Codex and GPT-5.6 were used as tools (thank you openAI for the free 2500 credits, appreciate it), not as a part of the runtime. They definitely accelerated repository exploration, implementation, testing, documentation, and iteration on adapter and verification boundaries by a lot and helped me finish what I finished within a week. The important architectural decision was most definitely to keep that assistance outside the product's conclusions: every result emitted by Zero is still traceable to versioned IR, explicit evidence, and deterministic code.
Challenges
The hardest part was resisting the easiest-looking solution. It would have been straightforward to ask an LLM what a function appears to do, but that would make the system difficult to reproduce, compare, or trust in a tooling workflow. Instead, the engine needed a small enough semantic vocabulary to work across languages while retaining enough structure to distinguish similar patterns.
My goal was simple, I did not want to find places to use an LLM to make our job easier. I mean.. everyone does that nowadays. My goal was to see where I could eliminate the use of an LLM to make the LLM's job easier, and the developer's job easier too.
That created several practical challenges:
- Language independence. Adapters must normalize differences without leaking parser or compiler-specific concepts into the engine.
- Deterministic ambiguity. Real functions can plausibly look like several patterns. Zero keeps competing hypotheses, applies explicit eliminations, and exposes supporting and rejected evidence instead of hiding the decision.
- Stable integration. The Vinglish compiler and Zero needed a durable boundary, so the transport contract is versioned and deliberately separate from internal HIR.
- Verification. A claim of language agnosticism is weak without tests. The project therefore verifies equivalent intent reports across representative Python, Java, C, and Vinglish inputs.
- Performance without obscurity. Incremental caching, compact semantic blobs, and deterministic query metadata improve reuse, but the stored state must remain inspectable and versioned.
What I Learned
I learned that semantic tooling gets higher credibility when the uncertainty is modelled as structure rather than hidden behind fluent english. A rejected hypothesis is VERY VERY useful information. A confidence value means more when it is the reproducible result of rule evaluation rather than a random opaque prediction.
I also learned that a shared representation is only useful when its boundaries are defended. The compiler does parsing; adapters do lowering; the engine does reasoning. Keeping those responsibilities separate made it possible to add frontends without adding language branches to the reasoning core.
Finally, I learned that AI-assisted development and deterministic software are not opposites. GPT-5.6 and Codex made the engineering loop faster. The product itself remains deliberately inspectable: users can ask why a classification was made and follow the answer through graph, facts, evidence, constraints, and report. They are supposed to be used in coexistence, only then will people yield better results.
Why It Matters
Developers increasingly work across languages, repositories, and abstractions. Syntax search is still pretty useful, but it cannot actually answer the question that matters most during maintenance: where is the code that performs this behavior?
Vinglish Zero explores a different foundation for that question. It treats semantic intent as a first-class, deterministic artifact that can be verified, diagnosed, cached, and queried across language boundaries.
Code should not only be searchable by what it looks like. It should be searchable by what it does.
Log in or sign up for Devpost to join the conversation.