The future of a physical object begins in an oddly quiet place. Before the mill, factory floor or launchpad, there is a screen and a piece of geometry that refuses to cooperate. A feature rebuilds. An assembly opens at the pace of airport luggage. The engineer waits. Michael Baron has chosen that interval - the lag between intention and feedback - as the problem around which to build a company.
Baron is the founder and CEO of Aurorin CAD, a San Francisco startup in Y Combinator's Winter 2026 batch. Aurorin makes mechanical computer-aided design software, the class of tool used to specify the parts inside cars, robots, aircraft, appliances and spacecraft. Its proposition is easy to repeat and difficult to execute: build the software afresh, including the geometry kernel beneath the interface, so modern hardware and an AI agent can be part of the architecture rather than late additions.
The company arrived in public with a vivid comparison. Aurorin showed a part it said an experienced SolidWorks user would spend 20 minutes making, produced in seconds instead. Speed is the headline metric. The deeper subject is permission. When a test costs less time, an engineer can attempt more versions. The tool becomes less like a filing cabinet and more like a sketchbook.
The projects before the company
Long before Aurorin, Baron was already living near the seam between software and machinery. By the time Lehigh University profiled him in 2023, he had built apps, embedded software for model rockets and robots, and a multi-GPU engine. These were largely independent projects. At Lehigh, he went looking for the complication that solo work cannot supply: other people.
He joined the Lehigh University Space Initiative after finding the student group at a club fair. The young organization was assembling the university's first Mars rover and preparing a CubeSat proposal. Baron headed its software team. His group helped design the architecture controlling the rover's cameras and motors, along with the ground-station laptop from which the machine was driven. For the proposed satellite, he outlined computer and software requirements for data arriving from sensors and antennas.
“I wanted to get experience working in a group.”Michael Baron, on joining Lehigh's space initiative
The sentence is modest, almost comically so, beside a rover. But it captures an early correction in his education. Technical range gets a project started; delegation gets a large one finished. Baron learned to assess what teammates understood, then shape tasks so each person could contribute. He later said the team's hands-on work and his leadership role were a major reason he secured his first SpaceX internship.
Three passes through SpaceX
That first summer in Hawthorne put Baron on flight software for satellites. He described the responsibility without decorative fog: designing, building and testing robust systems intended for use in the real world. After the internship, he wrote that software he had helped build was already in space. The next two visits widened the aperture. In 2024 he worked on Raptor combustion simulation. In 2025 he returned for Dragon guidance, navigation and control. Between those latter two, he worked on GPU driver performance at Apple.
Taken together, the assignments form an unusually tidy syllabus for the company that followed. Flight software punishes ambiguity. Combustion simulation asks software to describe unruly physics. Guidance systems turn math into motion. GPU performance makes every hidden delay visible. None of those jobs is CAD, but each teaches respect for what happens beneath a friendly interface.
Baron once explained the attraction of practical work in a line that could double as his hiring philosophy: “At SpaceX, they want to see what you can actually do.” Aurorin's founding-engineer description carries the same expectation. It asks for people prepared to follow work from identifying a need through prototyping, development, testing and validated learning. The artifact matters. So does watching somebody use it.
Why begin with the kernel?
A CAD kernel is the mathematical engine that decides how solids, surfaces, edges and operations behave. Most users never name it, just as drivers rarely discuss an engine-control unit. Yet it determines how quickly a complicated model can regenerate, how reliably one feature survives a change to another, and which new interactions are plausible.
Aurorin says its kernel is parametric and boundary-representation driven, built to use modern multi-core CPUs and GPUs. Most of its broader software stack is written in Swift, with native platform interface frameworks for both Mac and Windows. The visible product supports familiar direct and parametric editing while adding a chat interface through which an agent can create and modify geometry.
intent
agent
and model
The architectural decision matters because an agent operating CAD cannot live on eloquence alone. It needs a precise model of the object and reliable operations with which to change it. A convincing sentence that produces broken geometry is merely a very polished mistake. Baron's bet is that control of the kernel makes it possible to coordinate the AI interface, conventional tools and computation as one system.
“CAD is a sketch pad for thought and experimentation.”Michael Baron, responding to early product feedback
That description reveals the actual enemy: interrupted thought. Baron has argued publicly that software should not lag when an engineer works with complex parts or assemblies containing thousands of components. The point is not that every design should emerge from one enormous prompt. Aurorin's own demonstrations mix conversational instructions with ordinary editing. The aim is a quicker conversation between person, model and machine.
A founder in the feedback loop
Aurorin's launch also supplied a miniature study in Baron's operating style. Public reactions ranged from curiosity to blunt skepticism, especially around the difficulty of creating a new kernel. Baron answered questions, acknowledged criticism and asked people to report how their trials went. When someone published an independent tutorial only hours after launch, he celebrated the unexpected artifact. A user had moved from audience to teacher before launch day was over.
His responses were short and workmanlike: thanks, noted, coming soon. The interesting part was their direction. He kept pulling conversation back toward use. Try the software. Send feedback. Show what happened. This resembles the learning loop Aurorin promotes for engineering itself: reduce the distance between an idea, an attempt and information about the attempt.
The scale of the ambition is larger than the size of the early company. YC listed Aurorin with one founder at launch. Its public recruiting language imagines a handful of engineers helping other small groups build products that previously demanded far more people. Cars, satellites, computers and robots all pass through CAD; improve that common step, the argument runs, and the effect travels downstream.
There are hard questions inside this argument. Professional CAD earns trust over years. Engineers care about obscure geometry cases, compatibility, drawings, assemblies and the accumulated rituals of existing teams. A fresh kernel does not make those details disappear. It volunteers to meet all of them. Aurorin's public roadmap and hiring page acknowledge the breadth: geometry algorithms, parallel execution, native applications and an accurate agentic harness.
The useful kind of impatience
Baron's story so far is held together by a particular impatience, but not the theatrical kind. It is impatience with waiting that produces no new information. A rover team offered quick lessons about delegation. Space systems demanded working software. GPU performance made latency a measurable adversary. CAD now presents the same theme at a larger product scale.
The lesson available to other builders is not to replace every mature system from scratch. It is to inspect where the delay truly originates. Sometimes the interface is clumsy. Sometimes the workflow is wrong. Sometimes the ceiling sits in a foundation that everyone has stopped noticing. Baron looked beneath CAD's menus and chose the layer that governs the rest.
There is a second lesson in the sequence. Baron did not leap from model-rocket code to a company by collecting titles. Each project added a different constraint: embedded devices had limited resources, a rover needed a team, flight software had physical consequences, and graphics performance exposed computational bottlenecks. Aurorin gathers those constraints in one place. The product has to be mathematically exact, computationally quick, legible to a mechanical engineer and coordinated with an agent. His résumé reads less like a ladder than a set of tools carried into the same workshop.
What follows will be decided by engineers at their desks, not by the neatness of the origin story. They will open large files, make awkward changes, import old work and discover whether the promised feedback arrives sooner. That is a fitting test for a founder who has repeatedly argued that real artifacts outrank classroom ideas. The company begins with geometry; its proof will be what other people manage to build.