Continuous Function

An AI native learning and research platform that turns frontier AI concepts and papers into intuitive learning blocks.

Comment

Inspiration

Answers are abundant, but genuine understanding is much harder to develop.

Modern AI can summarize a paper in seconds, but producing a fluent answer is not the same as understanding the underlying ideas. I started Continuous Function because I wanted to build something between a passive course and a general-purpose chatbot. It is intended as a place where a serious learner can bring a difficult paper, equation, architecture, or model behavior, state what they expect to happen, test that expectation, and leave with an insight they can apply elsewhere.

The goal was not simply to provide more explanations. It was to help learners develop a mechanistic understanding that remains useful after they close the page and no longer have someone guiding them through the material.

What it does

Continuous Function combines an interactive mathematical atlas, a personal notebook, an experimental workbench, and a research environment for modern AI.

A learner might begin with a paper, identify the knowledge it assumes, and follow a connected knowledge graph until they reach a relevant concept notebook. Each mechanism can then be explored through intuition, mathematics, runnable code, and an interactive demonstration. These are different ways of examining the same idea, and learners can use whichever perspective helps them understand it most clearly.

The Transformer Systems Lab applies the same approach to systems concepts such as attention, grouped-query attention, and KV-cache tradeoffs. Each topic becomes an experiment in which the learner makes a prediction before observing the result.

The core learning loop is:

question → prediction → manipulation → evidence → invariant → next move

Rather than immediately revealing an answer, the system first asks the learner to commit to a prediction. The learner then changes a parameter, observes how the mechanism behaves, compares the result with the original prediction, and records the rule or pattern that remains valid. The explanation, equation, code, interactive control, and measured result should all describe the same underlying mechanism. Maintaining that consistency is one of the central design principles of the project.

The project also keeps three categories separate, since they are often blurred together in AI products:

  1. Working product: the atlas, paper mapper, knowledge graph, concept notebooks, demonstrations, and current lab experiences.
  2. Research record: source scopes, protocols, evaluations, reproducibility artifacts, and documented non-results.
  3. Design hypothesis: the proposed research assistant, evidence ledger, and governed execution model.

The Atlas-64 research illustrates why this distinction matters. It investigates whether the internal coordinate systems of different models can be aligned around shared concepts. The work includes defined protocols, structural checks, and provenance records. However, it does not claim to improve model quality or achieve a benchmark gain. I have tried to preserve that uncertainty rather than convert an interesting structural result into a stronger marketing claim than the evidence supports.

How I built it

The application is built with Next.js, React, and strict TypeScript. Educational content is stored in filesystem-driven YAML and MDX, which makes concepts, prerequisites, sources, and cross-domain connections easier to inspect and version.

KaTeX is used for mathematical notation, while D3.js, Three.js, and GSAP support the interactive visualizations. The project also includes content validators, unit tests, accessibility checks, and browser-based verification. These checks are intended to test not only whether the software works, but also whether the educational relationships between the explanation, mathematics, code, and demonstration remain intact.

I do not think of intuition, mathematics, code, and interactive demonstrations as four independent content sections. They are four representations of the same object, and the system was designed around that assumption.

How I used Codex and GPT-5.6

The project was not produced from a single large prompt. It developed through a sequence of repository-based Codex sessions.

In each session, Codex read the product principles and current task queue, inspected the actual state of the implementation, and worked directly with the repository. It edited TypeScript, React, MDX, schemas, tests, and research artifacts. It also ran validators and browser checks, then recorded relevant decisions and handoffs.

Files such as AGENTS.md, the task queue, design documents, and evidence artifacts served as shared memory between sessions. This allowed a new session to continue from the documented state of the project rather than requiring me to reconstruct earlier decisions from a chat transcript.

I remained responsible for the direction of the project, the boundaries of its claims, and the final decisions. Codex helped translate those decisions into implementation details that could be inspected, tested, and revised.

GPT-5.6 was used for the final audit. It reviewed the repository and task history, compared the project narrative with the available screenshots and artifacts, and helped distinguish between demonstrated functionality, research records, and future design proposals. It also assisted with the submission narrative, storyboard, and video. The project therefore reflects a longer process involving multiple tools, reviews, and human decisions rather than the output of a single model.

Challenges

The most difficult part was making the interactions pedagogically useful rather than merely visually impressive. Adding motion is relatively easy. Designing an experiment that changes how a learner understands a mechanism is much more difficult.

The written explanation, mathematical expression, code, interactive control, and observed result all need to remain consistent. Preserving that consistency becomes increasingly difficult as the project evolves.

Continuity was another major challenge. Long AI-assisted projects can quickly lose coherence when important decisions exist only inside individual conversations. To address this, I moved product principles, task status, experiments, reviews, and failed attempts into versioned files within the repository. This made them part of the project record rather than part of my personal memory.

A third challenge was avoiding what I think of as capability theater. The broader vision is ambitious, but each screen and claim still needs a clearly defined evidence class. A reproducible structural result is not automatically evidence of improved model quality. A design prototype is not the same as a deployed research assistant. A polished synthesis without reliable sources remains a draft, regardless of how convincing it sounds.

What I learned

Asking learners to make a prediction before seeing the answer changes the nature of the learning process. It turns passive recognition into a commitment that can be tested and potentially shown to be wrong. I did not initially expect this distinction to matter as much as it does.

I also learned that closure is often more valuable than breadth. It is tempting to keep adding new topics and demonstrations, but one complete path from a question to evidence and then to a reusable principle is more useful than several disconnected, partially finished experiences.

Conversation is useful for exploring a problem, but it is not a reliable way to preserve the resulting knowledge. When claims, evidence, experimental runs, approvals, and decisions exist only in a chat history, they become difficult to recover and verify. Important project objects need durable identities within the repository rather than brief references in a conversation.

Coding agents also become much more useful when they operate within clear principles, bounded tasks, validators, and persistent evidence. Their role is not to replace judgment. Their value lies in making decisions concrete, reproducible, and easier to review later.

What comes next

The longer-term goal is to develop an AI-native commons for serious learning and research. A research assistant would serve as the primary interface, but it would not function as an oracle or as the canonical record of the work.

A question would become a structured investigation. Claims would connect to specific evidence. Approved runs would produce durable artifacts. A learner or researcher should be able to pause, resume, review, or hand off the work without requiring someone else to reconstruct the entire process from a chat transcript.

That is the central aim of Continuous Function: to make understanding interactive, cumulative, and trustworthy, one evidence-based step at a time.

Built With

Share this project:

Updates