Working with MIT: AI Research Meets Browser Engineering

When people learn that I am affiliated with MIT's Schwarzman College of Computing, CSAIL, and Sloan, they usually ask one of two questions. The first is how a 14-year-old ended up working with MIT researchers. The second is what academic AI research has to do with building a browser extension. Both questions have the same answer: the gap between research and product is smaller than most people think, and bridging it is where the most interesting work happens.

Finding My Way to MIT

I started building browser tools when I was twelve. The first version of what would become Tensor was a crude Chrome extension that used regex to extract product prices from Amazon pages and compare them against a hardcoded list of price thresholds. It did not use any AI. It barely worked. But it solved a problem I actually had, and that made it interesting enough to keep building.

By the time I was thirteen, the extension had grown into something more ambitious. I had added natural language commands, page summarization, and a basic form-filling capability. I was using open-source language models, stitching together APIs, and reading papers to understand techniques I wanted to implement. A lot of those papers came from MIT research groups, particularly from CSAIL's natural language processing and human-computer interaction labs.

I reached out to researchers whose work I was referencing in my code. I did not send a formal application or a polished proposal. I sent emails explaining what I was building, linking to my GitHub repository, and asking specific questions about their published techniques. Most researchers did not reply. A few did. Those conversations led to an affiliation with the Schwarzman College of Computing that has shaped how I think about AI development ever since.

CSAIL: Where Theory Becomes Architecture

CSAIL, the Computer Science and Artificial Intelligence Laboratory, is the largest research lab at MIT. The breadth of work happening there is staggering: from foundational machine learning theory to robotics, from programming languages to computer vision, from cybersecurity to computational biology. For someone building an AI-powered browser tool, it is like having access to an entire reference library of solutions to problems you did not even know you had.

Three areas of CSAIL research directly influenced Tensor's architecture:

Program synthesis and verification. CSAIL has a strong tradition of research in automatically generating programs from specifications and verifying that programs behave correctly. This work influenced Tensor's workflow recording system, which essentially synthesizes a replayable program from observed user actions. The verification techniques helped us build the checkpoint system, which ensures that workflows can recover gracefully from unexpected states.

Natural language understanding. The NLP research at CSAIL goes far beyond simple text classification. Work on semantic parsing, where natural language is translated into structured representations of meaning, directly inspired Tensor's command parser. When you type "find flights from Boston to Tokyo under $800 next weekend" into Tensor's command palette, the system parses that into a structured query with entities (origin, destination), constraints (price, date range), and intent (search). That parsing pipeline borrows heavily from semantic parsing techniques published by CSAIL researchers.

Human-computer interaction. CSAIL's HCI group studies how people actually use computers, which is often different from how designers think they use them. Their research on attention management, interruption cost, and task switching directly shaped Smart Focus, Tensor's productivity feature. The graduated intervention model, where Tensor starts with subtle awareness cues and only escalates to active interruptions after sustained distraction, is based on HCI research showing that hard interruptions are counterproductive.

Sloan: Understanding the Business of AI

MIT Sloan School of Management might seem like an odd fit for a technical project, but understanding the business side of AI has been as important as understanding the technology. Sloan's research on technology adoption, platform economics, and organizational behavior has influenced how we think about Tensor's market position and growth strategy.

Two Sloan concepts have been particularly influential. The first is the idea of complementary assets, the additional capabilities that determine whether a technology creates value for its creator or for someone else. A browser extension has limited complementary assets on its own. But a browser extension with a robust data platform, an integration ecosystem, and a community of power users builds compounding advantages that are difficult to replicate. This thinking influenced our investment in the MCP Relay, the Personal Context system, and the workflow marketplace.

The second concept is user-driven innovation, the observation that the most valuable innovations often come from lead users who modify products to fit their needs rather than from the manufacturer's R&D department. This is why Tensor has extensive customization, an open API, and a community-driven workflow sharing system. Our most innovative features have come from watching how power users modify and extend the tool in ways we never anticipated.

The Intersection of Theory and Product

The most valuable insight from working with MIT researchers is understanding the difference between a technique that works in a paper and a technique that works in a product. In research, you optimize for a metric on a benchmark dataset. In a product, you optimize for a user experience in an unpredictable environment. The gap between these two objectives is where most AI products fail.

Consider Tensor's self-healing selectors. The underlying technique, using multiple similarity metrics to find elements that have changed location or attributes, is well-established in the research literature. But making it work in production required solving dozens of problems that papers do not address. How do you handle elements that load asynchronously? What about shadow DOM encapsulation? How do you avoid false positives when two similar buttons exist on the same page? What is the right confidence threshold where being too aggressive causes wrong clicks and being too conservative causes unnecessary failures?

The research provides the theoretical foundation, but the product requires engineering judgment that only comes from deploying the technique against thousands of real websites and observing where it fails. This feedback loop between theory and practice is what makes the MIT collaboration valuable in both directions. We bring real-world failure cases that expose gaps in the theory, and the researchers bring analytical frameworks that help us understand why our heuristics work or do not work.

Research-Informed Development Process

Working with MIT has changed how we develop features at MingLLM. Before implementing a new capability, we now follow a research-informed process:

1. Literature survey — identify relevant academic work on the problem, including both successful techniques and documented failure modes
2. Baseline implementation — build the simplest version of the technique that could work in our context
3. Real-world evaluation — test against a diverse set of real websites and use cases, not just synthetic benchmarks
4. Failure analysis — categorize every failure mode and trace it back to either a theoretical limitation or an engineering gap
5. Iterative refinement — address failure modes in priority order, using theoretical insights to guide the engineering solutions
6. User validation — ship to beta users and measure whether the technique actually improves their experience

This process is slower than the typical startup approach of shipping fast and iterating based on user feedback alone. But it produces more robust features. When you build on a solid theoretical foundation, you spend less time patching edge cases and more time extending capabilities.

What I Have Learned

Working at the intersection of academic research and product development at age fourteen has taught me several lessons that I think are broadly applicable.

First, papers are starting points, not solutions. A published technique solves a specific problem under specific conditions. Applying it to a different problem or different conditions requires adaptation, and the adaptation is often harder than the original research.

Second, researchers and engineers think differently, and both perspectives are needed. Researchers optimize for generality and rigor. Engineers optimize for reliability and performance. The best products come from teams that can hold both perspectives simultaneously.

Third, age matters less than curiosity. I was worried that my age would be a barrier to being taken seriously in academic settings. It was not. Researchers care about whether you have interesting problems and whether you can engage thoughtfully with their work. Everything else is secondary.

Finally, the browser is an underappreciated platform for AI research. It is the most widely used application environment on earth, with unmatched diversity of content, interaction patterns, and user needs. The problems it presents, from DOM understanding to multi-modal content analysis to real-time user intent modeling, are genuinely challenging and largely unsolved. Building Tensor has given me a front-row seat to these problems, and working with MIT has given me the tools to approach them rigorously.

The collaboration continues. There is no shortage of hard problems at the intersection of AI and the browser, and no better place to work on them than at the boundary between theory and practice.