The browser knows what the page looks like. The code editor knows how it was made. The coding assistant is waiting for somebody to explain both. Somewhere between these three windows, a developer has acquired an unpaid second job: carrying information from one piece of software to another. Quentin Romero Lauro has made that small, repetitive journey the subject of a company. His earlier work suggests he has been interested in such journeys for some time.
He is the co-founder and CEO of Radius, the San Francisco browser company previously known as Inspector and Sol Browser. The name has changed more often than the underlying concern: helping people work with AI without spending quite so much of their day preparing the introductions. To understand his route here, it helps to leave the browser for a moment and consider a Pittsburgh entrepreneur trying to write a business plan.
A plan, and someone beside you
Romero Lauro’s path through human-computer interaction included research at Carnegie Mellon’s Human-Computer Interaction Institute. He worked with Jeffrey Bigham and Yasmine Kotturi on how small-business owners brought generative AI into their working lives. Their 2024 study interviewed 11 entrepreneurs and support personnel. It paid attention to the people around the software: the co-owner sharing an account, the trusted intermediary using a system on someone else’s behalf, the person sitting beside a learner.
The details complicate the familiar picture of an individual staring into a chat box. A tool may be available to everyone while the practical knowledge needed to use it travels through a much smaller circle. Someone recommends a use. Someone demonstrates a step. Someone helps decide where the output belongs. The interface occupies a screen; the learning occupies a relationship.
That is an unusually useful starting point for a future founder. It makes adoption look less like a download count and more like an arrangement of people and tasks. In this reading of his work, the important unit is the person trying to get something done, with whatever assistance happens to be within reach. The software has to fit into that arrangement. A button labeled “generate” has no opinion about who will explain the result afterward.
The business plan that still needs its owner
BizChat gave those questions a particular object. Romero Lauro developed the AI business-planning tool with Kotturi and Aakash Gautam. The 2025 demo work drew on workshops and 15 interviews with small businesses. Its design addressed abilities that AI products often treat as incidental: editing, working with files, navigating a browser and knowing which business question to ask. Help could arrive within the task, at the point where it was useful.
A business plan is an apt test. It requires an owner to describe customers, products and intentions in a form that another person can assess. A convincing-looking document can conceal an unexamined assumption as neatly as an untidy one. Making the writing easier leaves the judgment firmly on the desk.
The later deployment study followed four workshops at a Pittsburgh feminist makerspace, examining logs from 30 participants and interviews with 10. The findings contained a productive tension. BizChat could translate ideas into business language and reduce barriers to seeking capital. Yet immediately available text could also bypass some of the thinking that planning requires. Peer support helped participants navigate that tension.
Speed, in other words, creates a further design question: where should a person pause? In business planning, the answer can affect whether the finished prose expresses an intention or merely resembles one. The distinction is especially important when the person using the tool is still learning the conventions of the document.
“Being critical towards your productive use of AI is extremely important.”
Quentin Romero Lauro
By April 2026, he had stepped back from leading BizChat, and other students were continuing the project. He had also taken a graduate HCI course with Gautam while an undergraduate at Pitt. The work crossed institutions and, eventually, changed hands. That continuation gives this chapter a satisfying ending: a useful project need not accompany its original builder to every subsequent address.
A debugger for the waiting game
At UC Berkeley, a different group of users had a different form of friction. Romero Lauro spent a summer in the SUPERB program and worked with the EPIC Data Lab on interfaces for debugging retrieval-augmented generation pipelines. He collaborated with Shreya Shankar, Sepanta Zeighami and Aditya Parameswaran. Their project, RAGGY, joined a Python library of composable operations to an interactive interface.
The underlying problem is easy to recognize even without the vocabulary. An AI system retrieves information, uses that information to produce an answer, and sometimes gets the answer wrong. Finding the mistake means examining the steps between the question and the response. When those steps are intertwined, the final answer offers limited guidance about which one to change.
The research explored engineers’ debugging practices through a study with 12 participants. It addressed a feedback cycle in which consequential parameter changes could require hours of preprocessing. RAGGY supported inspection and iteration so developers could investigate alternatives with less waiting. The work later received a CHI 2026 Best Paper award. Romero Lauro was also named a finalist for the 2026 CRA Outstanding Undergraduate Researcher award.
For the biography, the revealing detail is the kind of work he chose to examine. Debugging demands a view of the intermediate evidence. A person needs to form an explanation, change something, and see what happened. If each experiment requires a lengthy detour, the interface becomes part of the problem under investigation.
Business planning and debugging occupy different professional worlds. Both make a similar demand on software: let the user retain a meaningful role in deciding what comes next. That connection is an interpretation of his projects, rather than a claim that every project began with a single grand theory. Practical interests can recur without arriving wearing matching uniforms.
The invitation matters
His university years also involved making things happen for other builders. At Pitt, where he earned a B.S. in Computer Science, he served in the Computer Science Club and helped organize hackathons. As a co-executive director of SteelHacks XI, he worked on an event that brought more than 200 participants to Benedum Hall in September 2024.
“The energy from students was huge this year,” he said afterward. The weekend included a Bob Ross paint-along as well as coding. The combination has a certain administrative wisdom. People who have spent hours arguing with a computer may welcome a tree that is happy to exist without compiling.
The organizing belongs in the story because a technical gathering has its own interface. Someone has to find a team, understand the activity and feel able to contribute. Sponsorship and logistics may look remote from writing software, but they determine whether anyone gets the chance to write it together.
His smaller projects share that practical quality. TutorHHS matched high-school students with peer tutors. A physical chessboard recorded moves using magnets, Hall-effect sensors and a Raspberry Pi. These projects do different jobs, but both attach a technical system to an activity people already understand. The board has pieces. The tutoring platform has students who need to find one another. The point of the machinery is the activity it makes possible.
A company born in the handoff
Romero Lauro’s product experience included Character.AI’s product engineering team. With Michael Klikushin, who became his co-founder and CTO, he then built the company launched as Inspector in Y Combinator’s Fall 2025 batch. The founders described long days developing web-based games, moving between Figma, Cursor and Chrome DevTools while refining front-ends.
The work required transferring what they saw into forms a coding agent could use. Inspector connected the browser and codebase, letting developers select page elements and provide visual and runtime context. The idea was grounded in a task the founders were performing themselves. Their irritation had an address: the handoff between the visible page and the tool asked to change it.
There is a modest comic detail in his account of promoting the product. He said he made an Inspector advertisement in his living room at two in the morning. Research may produce a paper; company building can also produce a living-room production schedule. Neither the room nor the hour needs embellishing.
The product subsequently appeared as Sol Browser and now as Radius. Its current proposition places coding agents in a browser alongside the developer’s other tools. The tab, ordinarily a container for a website, becomes a place for work on the software itself. An interface people already navigate acquires another responsibility.
The interface is still up for discussion
The browser is an ambitious place to continue this inquiry because it already contains so much of a developer’s working day. Documentation, pull requests, the running application and communications compete for attention there. Bringing agents into that space makes their relationship to the rest of the work a design problem that users can encounter every day.
Romero Lauro’s trajectory gives that problem a particular background. He has studied entrepreneurs learning with other people and engineers inspecting complicated AI pipelines. He has helped organize a room of builders and worked on consumer AI products. The settings provide different tests of a common practical concern: whether the person can get from an intention to a useful next action.
A profile of an early founder can easily turn each earlier activity into a prophecy. His projects deserve more room than that. BizChat has its own users and continuing student stewards. RAGGY has its own research contribution. SteelHacks was an event people attended. Their value does not depend on having predicted a browser company.
Still, the sequence makes Radius easier to understand. The recurring attention is to what happens around the answer: the learning, the evidence, the handoff, the chance to revise. A coding agent may perform more of the task, but somebody still needs a workable view of the task being performed. Romero Lauro has chosen to build that view in the place where a great deal of work is already open. The next useful step might be in the tab beside you.