On 31 August 2026, Runway announced Solaris, the first model in a family it calls Interface World Models. The claim is not that it writes better front-end code. The claim is that there is no code. The interface is generated as video, one frame at a time, while you interact with it.
Most of the coverage has focused on the demos. The more useful question is what disappears underneath them.
Every piece of software shipping today goes through a translation step. Someone designs a screen. That design is converted into an intermediate representation (HTML, CSS, JavaScript, a component tree) before it can do anything. The browser parses that into a DOM, computes layout and style, and paints pixels. Interaction runs back the other way. A click hits an element, dispatches an event, mutates state, triggers a re-render.
Runway argues this intermediate representation is lossy in two directions. Visually, a rich design gets flattened into whatever the framework's primitives can express. Behaviourally, every interaction has to be anticipated and implemented in advance, so software ships as a frozen subset of the interactions that were possible, decided before any user arrives.
They put a number on the visual half of that. Runway tested several state-of-the-art multimodal models, including Claude Fable 5, GPT-4o and Gemini 2.5 Pro, on reconstructing thirty website interfaces from a single screenshot, scoring the results with SSIM and DINOv3 feature matching. Every model lost information, and the loss grew as visual complexity increased. Natural images fared worst, because rich visual detail does not survive being described in language. The benchmark is really an argument about representation. If a picture of a UI cannot round-trip through code without degrading, then code is the bottleneck.
Three pieces, worth separating.
Input as conditioning. Solaris treats user input the way a video model treats a text prompt or a reference image, as conditioning on the next frame. It observes clicks, drags and other interactions as it generates, and uses them as signals for what comes next. During training the model only ever sees interactions that have already happened, never future ones, so it learns the relationship between an action and its visual consequence. That is how it knows what should happen when you drag something, without anyone writing a drag handler.
Reasoning split from rendering. Solaris does not run alone. A language model sits alongside it and decides how the interface evolves. The LLM interprets the request, decides whether an interaction should modify the current scene or transition to a new one, defines the behaviours that make the scene feel alive, and produces the prompts that guide rendering. Solaris generates the pixels. Mapped onto a stack you already know: the LLM is your application logic, Solaris is the browser and the GPU, and the frame is the DOM.
Making it fast enough to feel like software. This is the engineering that matters. Standard video diffusion refines an entire clip over dozens of denoising steps, which is fine for content and useless for interaction. Runway notes that interaction stops feeling interactive somewhere around half a second of delay. They got under that in three stages, building on their Gen-4.5 video model. First they taught it to generate frames autoregressively, so each frame depends only on what came before. Then they distilled the many-step denoising process down to a few steps. Then they trained the fast model on its own outputs so visual quality holds up over a long session. Output runs at 720p.
None of this is unprecedented as a technique. Neural game engines have been doing action-conditioned frame generation for years. GameNGen ran DOOM as a diffusion model, Oasis did the same for Minecraft, and DeepMind's Genie line generates navigable worlds at 720p and 20 to 24 frames per second from a prompt. What is new is the target. Solaris points that machinery at business software instead of game worlds, which is a far less forgiving domain. A generated coastline can invent a rock and nobody minds. A checkout button cannot invent a price.
This is the part I would want any client to think through before getting excited.
There is no queryable state. In a coded app, state lives somewhere you can inspect, log, snapshot and restore. In Solaris it is distributed between the frame history the model is conditioning on and whatever the LLM decided. Runway is explicit that there are no predefined screens and no templates to fall back on. Maintaining coherence over long sessions is listed as an open research problem.
There is no integration surface. No DOM means no selectors. That removes end-to-end test automation, analytics event binding, browser extensions, scrapers, password managers, ad tech, and every internal tool ever held together by querySelector. Whatever replaces all of that does not exist yet.
Text is still hard. Runway names it first among the limitations. Stable, legible text remains one of the hardest problems in video generation, and interfaces depend on it more than almost any other visual domain. Their suggested workaround is a hybrid, with image models rendering text-heavy views where a brief pause is acceptable and video models handling continuous interaction.
Accessibility is unsolved. A generated frame exposes no semantics. Runway acknowledges that a generated interface still has to work with screen readers and accessibility APIs, and lists this as future work. For anything public-facing in Australia that is not a nice-to-have. It is a Disability Discrimination Act exposure, with WCAG 2.1 AA as the accepted benchmark.
Confident wrong answers. Runway's own framing is that for instructional or commercial use, a convincing wrong answer is worse than no answer. Today the model stays anchored by what you feed it. The starting frame can be composed from real product imagery, which grounds the scene in things that actually exist. Grounding generation in verified data as the session continues is described as active research.
This is the part almost nobody is talking about, and for most businesses it will matter more than any of the above.
Software today is built once and served many times. You pay engineers up front, and after that the marginal cost of one more user loading one more page is close to nothing. A cached page off a CDN costs a fraction of a cent in egress. Ten thousand users see the same bytes. That single property is why so much of the modern web works: free tiers, ad-supported content, SEO traffic, freemium funnels, all of it assumes serving is nearly free and only building is expensive.
A generated interface flips that. Every second a user spends in the session is inference you are paying for, and no two sessions are the same, so there is nothing to cache. Cost scales with engagement rather than with headcount or feature count. The user who lingers on your storefront is now costing you money, which is the exact inverse of the incentive every product team has been optimising for.
Runway acknowledges this directly. Generating every frame is still more expensive than serving a page built once, though they say the work that made Solaris real-time also made it orders of magnitude cheaper to run than a standard video diffusion model, and that the cost curve keeps improving. Solaris itself is not priced yet, but the anchor is worth having. Runway lists Gen-4.5, the model Solaris is built on, at 12 credits per second of generated video, with API credits at $0.01 each. That is $0.12 per second of conventional generation. A 5-minute session at that rate would be about $36. Cut it by 2 orders of magnitude and you are still at roughly $0.36 per 5-minute session, before the language model running alongside it bills its own tokens for every interaction it reasons about.
$0.36 is survivable for a high-value interaction. A mortgage application, an enterprise onboarding flow, a configurator for something expensive. It is not survivable for a content site, a free tier, or anything that gets traffic it does not convert. And it puts a real price on your bot traffic, which is currently just a line in a log file.
So the near-term shape is fairly predictable. Generated interfaces will show up first where the revenue per session is high enough to absorb per-second inference, and everything else stays coded, because build-once economics remain unbeatable for anything served at volume. Anyone modelling this needs to move a line item from capital expenditure to cost of goods sold, and that changes gross margin, not just the engineering budget.
Three things follow, and they point somewhere more useful than "front-end developers are finished".
First, the API layer gets more important. If the presentation layer is generated on demand and holds no durable state, then everything that has to be true (inventory, pricing, identity, payments, the audit trail) has to live behind a defined service boundary. The rendered frame becomes the least trustworthy part of the stack. Systems that already have a clean API surface can experiment with this. Systems where the business logic is tangled into the UI cannot.
Second, agents are the near-term use case, not consumers. Runway makes this argument directly. Today's models fail at ordinary computer-use tasks like booking a hotel because they are trained against coded interfaces and learn the specific layout rather than the task, so a second hotel site with a different layout breaks them. An environment that generates layouts which have never existed before is a training ground for exactly that weakness. It is a more credible commercial path than replacing your checkout.
Third, the app as a unit of software gets a real challenge. Runway's largest claim is that if the operating system can generate whatever interface the moment calls for, there is less reason to sort software into a fixed catalogue of apps. Storefronts become generated environments that keep the brand but reshape around the visitor. Tutorials render the next step in your own context instead of replaying the same sequence for everyone. Whether that arrives in three years or fifteen, the strategic question is worth asking now. If your product's value is its UI, that value is depreciating. If it is your data, your logic and your integrations, it is not.
Solaris is early-access research, request-only, and not a generally available product or API. Runway's own list of limitations covers most of what would stop it being used for real work. In a study with 250 participants across 30 interaction examples and roughly 7,500 pairwise judgements, evaluators preferred Solaris to a Claude Opus 5 coded result in 61% of instruction-following comparisons and 71% on natural in-scene behaviour. Strong numbers, though produced by the vendor, on scene-based interactions rather than forms and tables.
What has been demonstrated is that the design-to-code translation step is not physically necessary. That is a real result. It does not yet mean anything for whatever you are shipping this quarter, and anyone telling you otherwise is selling something. The sensible move is to make sure your logic and data are not welded to your presentation layer, which is good architecture whether or not any of this pans out.
