Engines & kernels, not applications
Why LLMs will turn most engineering & design software into infrastructure
A large cohort of the most valuable software companies in the world can be thought of as a very sophisticated engine or kernel, with a UI on top. Examples of this include:
Solidworks - CAD Geometry Kernel + UI
Ansys - Simulation engine + UI
Figma - Web-based vector graphics engine + UI
After Effects - Motion graphics kernel + UI
Premiere - Video processing engine + UI
DaVinci Resolve - Color grading engine + UI
Unreal Engine - Game engine + Editor UI
Wolfram Mathematica - Symbolic computation engine + UI
Gurobi - Operations research solver + UI
Revit - BIM engine + UI
Hex/Jupyter - OLAP Python kernel + UI
Essentially, almost any product serving sophisticated “builders” (engineers, architects, designers, etc) looks like this.
For the most part, I would argue that somewhere between 90-99% of the IP and value of these products lies in the computational complexity of the engine, with the UI and user workflow for the most part really just being a UI that maps to the API surface of the engine. Indeed, aside from Figma, I think almost none of the the products I list above can be considered “elegant” or “simple to use” - but people learn to use them anyways because they are powerful.
Traditionally, it was critical for such products to build out and think about the UI as the main (if not only) way for people to use these products. An engine without the workflow would have been completely inaccessible to the people who need to use these tools.
However, large language models (specifically coding agents) are beginning to change this dramatically. Coding agents are very good at assembling on-the-fly UIs. They are also amazing at mapping a complex user request into a set of API calls. And correspondingly, they seem quite promising for solving the classic challenge these products have in terms of accessibility, learning curve, & product complexity.
BlenderGPT is a fun, but simple example of this, which uses LLMs to script Blender, the 3D design software. The “stack” essentially becomes LLM + Blender Engine, with the UI of Blender becoming somewhat irrelevant.
I think we are already at the point where this paradigm of a Claude CoWork style interface on top of one these engines is in some cases more powerful and flexible than simply using the application itself.
The first vector by which this occurs is that AI allows for automation of larger, complex, and especially more procedural tasks. It can map semantic intent to a large loop of doing a bunch of things in a certain order - something you could of course do yourself, but which would take forever.
The second vector by which this occurs is that AI can help with discovery and fully “accessing” the breath of what the tool offers. Even very experienced professionals in these domains are often unaware of the full range of functionality embedded in these very complex engines. As an example, even hardware engineers with 10-20 years of experience often don’t feel like they are experts in CAD simulation. AI makes these sorts of workflows that matter, but are outside of the “core”, accessible.
The third vector is flexibility. You can have something closer to personalized, ephemeral UI as you do things - which in some cases is more powerful than the fixed UI paradigms of these tools. This also allows for things like progressive disclosure of complexity.
You are starting to see bits and pieces of this in the wild. Marimo is popular partially because the notebooks are stored as pure python, meaning that you can treat Marimo more like the “engine” of a data science notebook. Rive is interesting because it can be used as an embedded animation rendering engine fully programmatically, something note really possible with AfterEffects.
Similarly, there are now a number of startups that are applying ChatGPT style UIs on top of these engines - similar to BlenderGPT.
As LLMs continue to improve and progress, I think that the right way to think about this type of software will be purely as an engine or kernel, not really as an “application”. And I think this will be very, very disruptive to many of these categories as a result.
I specifically think this creates two general themes of startup opportunity that are interesting:
Code-gen based automation of existing “Engine + UI” Tools - Build an LLM based, conversational UI that allows one to dynamically manipulate products like Blender, Unreal, Premiere, or similar via code generation. Essentially, use AI to treat the existing products like engines, not applications. I think in many cases this can both expand the scope of who can use these sorts of tools, as well as vastly increase the productivity of the people already using these tools
Build an “engine” startup in one of these categories designed for programmatic use - Ultimately, most of these products were not designed to be used more like infrastructure than like applications. While many expose some kind of scripting or extension API, they are ultimately limited. And more importantly, if you were purposefully designing the interface for an agent writing code against it, it would almost certainly look different. Systems for agents look different, as we have seen with how many traditional software infrastructure categories are being rewritten for agents.
What’s interesting about #1 is that you can finally side-step the biggest traditional challenge in these spaces - feature density - because you can access all existing features via code generation. What’s interesting about #2 is that you can start with a very small/specific scope, because in the programmatic case you often just need to do 1-2 things better, vs. rather than having to do everything better because you are trying to replace the core system of engagement. In other words - LLMs structurally remove the classic reasons it has been hard to build new startups in these categories.
A few years ago, I invested in a company, Modyfi, that built a completely novel GPU-accelerated graphics engine that ran inside the browser. It allowed for real time rendering & compositing of motion graphics in situations where AfterEffects might have needed 10+ minutes to render. At the time, they also attempted to build a novel UI & workflow tool to make use of this engine, but this was very difficult to do because it was going to take forever to be at feature parity with AfterEffects from a UX perspective and workflow perspective. The company eventually sold to Figma.
I think that if Modyfi were started today, the better approach may actually be to try to monetize the engine mostly via AI-based code generation as the interface. Essentially, Modyfi becomes more like a “tool” in the agent world than an application. This would have saved the team so much time & money, let them get to market faster, and honestly played more into the companies’ unique strengths.
I am very interested in teams going after ideas along these lines. All of these feature dense “engine” categories are much more up for grabs than they ever were before. Shoot me a note if you’re building in this area - davis @ innovationendeavors.com