How a 20-year-old computer science student built a public information assistant—and demonstrated that he understood the code he shipped.
A computer science student working by himself built and deployed a functioning public information assistant for North Texas Mensa. The application answers questions using the chapter’s public newsletters, event records, and published Mensa information. It cites its sources, clearly identifies the limits of its knowledge, and is designed to become a reusable open-source platform for other chapters.
The application works. But in an era when AI can generate working software faster than many developers can understand it, that is no longer the only question worth asking.
Could the student who built it explain what the code was doing?
Ninchi created a record of the answer, one pull request at a time.
A public information assistant with visible boundaries #
The North Texas Mensa Public Information Bot was built by Ikye, a 20-year-old computer science student based in Japan, using React and Vite and deployed through Vercel.
The prototype answers questions about Mensa using public sources, including North Texas Mensa’s M-Aura newsletter PDFs, public event records, and information published by North Texas Mensa and American Mensa. Ask it “What is North Texas Mensa?” and it returns an answer in several seconds, followed by the records it used. Each source is labeled by category, originating organization, source type, and date, with links back to the original public material.
Just as important is what the application refuses to pretend.
The interface identifies itself as a “PUBLIC DATA PROTOTYPE” and states plainly that it contains “No private member content.” Its answers conclude with a qualification that many production AI systems omit:
“These are stored public-source records, not live web results from this chat request.”
That sentence reflects a meaningful engineering decision. Ikye did not merely build an interface that produced plausible answers. He told users where the answers came from, what data the system possessed, and what it could not claim to know.
Eight pull requests, eight scored challenges #
Ninchi was installed on the project in June 2026. As Ikye opened pull requests, Ninchi analyzed each code change, generated questions about the specific work being submitted, and evaluated his written answers against a hidden rubric.
Between June 8 and July 14, Ikye completed eight scored challenges across eight pull requests. He passed six, producing a 75% raw pass rate and a difficulty-weighted Ninchi Index of 67. He passed all four easy challenges and two of four medium challenges.
His strongest results appeared in the areas where he did the most substantive work: JavaScript, API design, documentation, and front-end user experience. A few additional challenges expired without answers during the first two days as the workflow was being configured. They remain part of the record rather than being quietly discarded.
These numbers are useful, but the sequence behind them tells the more interesting story.
From generated boilerplate to accountable design #
Ikye’s only two failed challenges came on his first pull request, when he created the project scaffold.
Ninchi asked why Vite had been selected instead of Create React App. His answer—“because it’s light weight compared to others”—received a score of 40. When asked to explain the respective roles of react and react-dom, he scored 60.
These were not obscure questions about a mature system. They concerned foundational decisions embedded in generated scaffolding that he had shipped but could not yet fully explain.
By mid-July, Ikye was rebuilding the chatbot around a language model. Ninchi asked him to explain the intent behind the functions generateOpenAiReply, isOpenAiEnabled, and shouldEnhanceWithOpenAI, including how the system decided whether to invoke the model.
He passed.
In fact, every scored challenge after the initial scaffold was a pass: six consecutive successful demonstrations of understanding. The important progression is not that Ikye became better at taking a test. It is that he moved from accepting generated code he could not adequately account for to designing and shipping code he could explain.
What the score means—and what it does not #
The Ninchi Index represents the percentage of completed challenges passed, weighted by difficulty. It records understanding demonstrated at a particular moment about a particular set of code changes.
It is not a measure of intelligence, aptitude, or long-term engineering potential. Ninchi does not present it as one.
That distinction is central to the product. Existing systems can tell us whether code compiled, whether tests passed, whether a pull request was merged, and how quickly a developer shipped it. Those are measures of performance. They are not necessarily measures of competence.
AI-assisted development makes the distinction more important. A model can produce functioning code for someone who does not understand its dependencies, security implications, architectural tradeoffs, or failure modes. The resulting application may perform correctly today while remaining difficult—or dangerous—for its nominal owner to maintain tomorrow.
Ninchi records evidence bearing on a different question: after AI helped produce the work, what could the human still explain and take responsibility for?
A feedback loop for developers working alone #
Ikye did not have a senior engineer reviewing each pull request. Like many students, interns, founders, and independent builders, he was working outside the traditional feedback loop through which junior developers become professionals.
Ninchi supplied part of that missing loop. Each pull request could prompt questions about the work he was submitting. He had to answer in his own words, and weak or incomplete explanations were recorded as such. A failure did not prevent him from continuing to build, but it made a gap in understanding visible.
That creates value in both directions. A project owner gains evidence that a junior developer understood the work being submitted. The developer receives a forcing function to inspect, explain, and learn from code that might otherwise have been accepted simply because it worked.
Oversight and education become two sides of the same mechanism.
A useful product—and a durable learning record #
The immediate result is a genuinely useful prototype for North Texas Mensa. Members and interested members can explore public chapter information through a conversational interface, see the material supporting each answer, and understand the system’s boundaries.
The deeper result is the record behind it.
The project did not simply end with a deployed application and a GitHub contribution graph. It produced evidence showing where its developer initially relied on code he could not explain, where his understanding improved, and how he progressed toward ownership of the system he was building.
The application is still evolving. Planned work includes a dedicated domain, scheduled ingestion to keep newsletters and event information current, stronger citation-backed answers, and additional educational material about artificial intelligence for Mensa members. The longer-term goal is to open-source the portal so other Mensa chapters can operate versions using their own public information.
AI made it possible for one student to build more than would have been practical a few years ago. Ninchi helped ensure that increased output did not have to come at the expense of human understanding.
One developer. One working public application. One verified commit at a time.