Three recent developments are worth a look. First is Runway, which unveiled Solaris, a system that renders interactive user interfaces frame by frame using a model without writing any front-end code. Second is Google Research’s WikiSkill paper, which explores how agents can distill an executable operating manual for themselves after troubleshooting and post-mortems. Third is GitHub’s release of enterprise self-hosted GHES 3.22, enabling teams to run command-line coding tools inside isolated internal networks without relying on the public cloud.
The release statuses of these three developments differ: Solaris is currently a research preview; WikiSkill is a proof-of-concept prototype in an academic paper; and while GHES 3.22 itself is officially generally available, its support for isolated execution is explicitly labeled as a technical preview. These remain frontier demonstrations and should not be treated as tools ready to deploy straight into production.
In conventional interface development, teams are accustomed to writing front-end code, assembling component trees, and wiring up click and swipe event handlers. In its demos, Runway showcased a completely different paradigm: no front-end scripts run under the hood, and there are no actual system widgets—the visual frame itself is the software. Yet Solaris is not about clicking around arbitrarily from a blank slate. Before use, the user must provide an initial state (such as a brand environment or product scenario, where the initial frame can consist of real product imagery and reference materials to anchor the scene to real-world objects) and use text prompts to define what interactions like clicks and drags mean within that context. Only then do the user’s clicks, drags, and inputs serve as conditioning signals, driving the model to calculate the next frame in real time within the predetermined scene configuration. The entire interaction feels like rapidly flipping through a flipbook, with the appearance and motion of every control painted in real time by the model. This technology comes from Runway’s research preview published on August 31, 2026, in the official Solaris announcement, which the company calls a first-generation interface world model.
This architecture eliminates the code intermediary layer found in traditional software. According to Runway’s technical documentation, the rendering layer has no state abstractions or structured intermediate representations; frames are generated directly by the model. Runway sums up this approach as “the visual frame itself is the software,” arguing that traditional code represents a premature freezing and lossy compression of the potential interaction space. To support this claim, they published a reverse-extraction experiment in which multimodal models were tasked with recovering front-end code from a single webpage screenshot; every tested model lost original information when reconstructing complex components. However, this experiment only proves that reverse-engineering code from static images involves information loss—it does not prove that generating pixels directly is free of information loss.
Architecturally, Solaris is split into two models working in tandem. The system has no preset screens or templates; the semantics of interactions are governed by text prompts. A front-end language model is responsible for understanding requests, deciding next steps, and generating prompts to guide rendering; a back-end world model based on Gen-4.5 specializes in rendering the interface’s visual presentation and interactive feedback. To compress frame generation speeds down to an operating latency acceptable to humans, the team combined three engineering techniques: serial frame-by-frame generation, distilled denoising, and feeding self-generated samples back into the training set for secondary fine-tuning. Officially, the latency threshold where the feeling of interactivity vanishes is pegged at around half a second, after which operations no longer feel interactive.
In terms of presentation, the company published a user preference study involving 250 participants and roughly 7,500 pairwise comparisons. The baseline was a front-end coded interface written by Claude Opus 5. The company self-reported that in instruction following, participant preference favored Solaris 61% to 24%; in the naturalness of interface behavior, preference favored it 71% to 21%. On cost, the company claimed its real-time operating cost is several orders of magnitude cheaper than standard video diffusion models. However, the frame of reference for this comparison is video diffusion models, which are themselves computationally expensive, meaning this does not translate into a cost advantage over traditional web rendering.
Looking beyond the company’s self-reported figures, a search of public records as of September 11, 2026, revealed no third-party independent hands-on evaluations of the technology. All retrieved public discussions are based entirely on a few polished demo videos released by Runway. As of that date, Solaris remains in a research preview state: there is no public beta access, no announced pricing, and no API. It offers only an early-access application form, with no timeline disclosed even for an official launch.
In its announcement, the company outlined four unresolved technical limitations. Stably rendering crisp, legible text within dynamic scenes remains difficult; the model occasionally hallucinates plausible-looking but fundamentally erroneous interface states, subtle errors that are far harder to debug than outright program crashes or error popups; maintaining visual consistency across long sessions remains tough; and pure pixel rendering cannot work with accessibility features like screen readers. These shortcomings directly constrain its feasibility for general-purpose software production.
In the Reddit community discussion, many developers ran the numbers: once traditional front-end code is bundled and deployed to the client, no matter how much the user clicks or drags, the server incurs zero incremental inference cost; relying on a world model to generate pixels frame by frame, however, consumes GPU compute with every single interaction, driving serving costs up linearly with session duration. In the Reddit UX design discussion, peers also pointed out that defining interfaces through behavioral demonstration has a long history in human-computer interaction (HCI). Solaris’s breakthrough lies primarily in its generative visual rendering pipeline, while the interaction paradigm itself still adheres to existing user-interface interaction logic.
When writing code with LLMs in daily work, engineers often run into a frustrating loop of repeated mistakes: after spending hours in the terminal debugging alongside a model to finally untangle the idiosyncratic limitations of an obscure library, closing the chat window and opening a fresh one wipes the slate clean—the model immediately forgets every pitfall it encountered, hitting the exact same roadblocks when faced with the same error next time. Because model weights remain frozen once deployed, capturing these hard-won engineering lessons without retraining model parameters has long been a practical dilemma. On August 27, 2026, Liyan Tang and colleagues from Google Research—with co-author Tu Vu from Virginia Tech—published the WikiSkill paper. They proposed a system that compiles execution trajectories into persistent instruction manuals; the paper is released under the CC BY 4.0 license, with no official code repository or official blog post provided.
WikiSkill organizes the workspace into three distinct layers. At the bottom lies the immutable raw trajectories, which preserve all historical execution records in full. In the middle is a wiki directory that is never purged, storing pattern inductions, issue indices, post-mortem logs, and efficacy tracking for each rule. At the top sits a structured skill directory housing operating manuals that can be rolled back to earlier versions at any time. This approach of continuously accumulating knowledge in an external environment to avoid repeated trial-and-error builds on the wiki concept proposed by Karpathy in April 2026.
The entire system operates in a loop powered by four components. The front-end execution agent carries out tasks and generates trajectory traces. In each cycle, the wiki maintenance component samples no more than 8 trajectories—containing at most 5 failure cases and 3 success cases, with individual log lengths capped at 15,000 characters—to conduct root-cause analysis on failed steps and summarize shared patterns in the wiki. In the background, the skill proposer component reads the wiki and drafts updates to skill files. Finally, the gating verification component evaluates the draft against a validation set. The gating mechanism uses the historical best validation score as its admission threshold: a new draft is merged only if its performance on the validation set is strictly superior to the historical best score; otherwise, it is immediately rolled back to the previous stable version. Even if a draft is rejected, the maintenance component logs the attempted changes and reasons for rejection into the wiki, preventing subsequent iterations from heading down the same blind alleys. The skill files adopt Anthropic’s standard format established in 2026, specifying trigger conditions, disallowed scenarios, and concrete execution steps, while preserving the evolutionary context of the manual.
In ablation tests on Gemini-3.5-Flash, when the proposer component drafted skills without wiki input (with the wiki maintenance component also removed), the baseline average accuracy was 48.7%. Incorporating the wiki as a post-mortem reference boosted average accuracy by 15 percentage points to 63.7%, with performance on the LiveMath mathematical reasoning benchmark surging from 51.3% to 72.6%. In the full primary experiments, Gemini-3.5-Flash’s average accuracy rose from 49.5% to 68.1%, while Qwen-3.6-27B climbed from 39.4% to 63.3%. The gains delivered by skills scaled with the parameter size of the base model: across 4B, 9B, and 27B models, accuracy improvements reached 12.3, 17.5, and 23.9 points, respectively. Equipped with skill files, Qwen-3.5-9B achieved a final score of 47.4%, leapfrogging the initial 39.4% baseline of the 27B model operating without skills.
The evaluations also revealed a counterintuitive phenomenon: when the full text of the wiki—brimming with debugging logs and reflective summaries—was dumped directly into the prompt context of the front-end execution agent during training rollouts, the model’s average score not only failed to rise, but fell from 63.7% to 60.9%, with LiveMath dropping from 72.6% to 64.8%. Lengthy, granular troubleshooting logs are laden with redundant details that interfere with the front-end executor’s attention allocation. The wiki’s true utility is as an offline resource for the proposer component to pore over, distilling lessons into concise, structured operating protocols before delivering them to the front-end agent for execution.
Alongside the positive gains, the paper explicitly documented negative transfer. In one experiment, spreadsheet-processing skills synthesized by Qwen-3.5-4B were fed directly into the more capable Gemini-3.5-Flash, causing the latter’s accuracy to plummet from 50.5% to 18.1%. The workarounds devised by smaller models to bypass their own limitations ended up binding and throttling the more optimal problem-solving pathways available to higher-reasoning models.
In terms of task coverage, WikiSkill did not take first place across every benchmark. On the OfficeQA benchmark, Qwen-3.6-27B posted a score of 53.7%, trailing Trace2Skill’s 54.3% and SkillOpt’s 54.8%. In the limitations section, the authors noted that the current system lacks dynamic retrieval and dynamic triggering logic for skills, injecting all generated skills into the context in bulk. Furthermore, gating rules that evaluate solely on score improvements discard neutral proposals that, while not yielding immediate score increases, may carry latent value. An official codebase has not been open-sourced; the only public implementation is the third-party reproduction project ashutoshsinghpr7/wikiskill, which primarily documents how the gating mechanism intercepts invalid proposals.
An engineer opens a command-line tool on an internal dev machine, types a command, and code suggestions stream smoothly onto the screen. Not a single packet is transmitted to Microsoft or GitHub public servers during inference, no third-party login prompts appear in the terminal, and every network request routes exclusively to self-hosted servers deployed inside the company’s own data center. This setup arrives courtesy of the GHES 3.22 Release Notes published on September 8, 2026. According to the GHES 3.22 General Availability announcement, while the host server software itself is now generally available, the accompanying support for running Copilot CLI in isolated environments is explicitly designated as a technical preview subject to change in future releases.
Many enterprises have long remained cautious about cloud-based AI
coding assistants, primarily over code egress and compliance audit
concerns. Support for bringing your own model endpoints to run local,
private inference offline was actually introduced on April 7, 2026.
However, that earlier design pushed configuration onto individual
developers, requiring each person to set environment variables and model
endpoints on their local machines, making it impossible for enterprise
security and compliance teams to enforce unified policies. The
substantial shift in GHES 3.22 is centralizing configuration authority:
system administrators configure upstream model parameters just once in
the self-hosted GHES administrative backend using the
ghe-config command-line utility, allowing employees to
connect seamlessly with their existing self-hosted GHES credentials.
According to the custom
model endpoints documentation, the architecture decouples what was
once a bundled call chain into four distinct layers: the developer
machine, which runs the local Copilot CLI client; the enterprise
self-hosted GHES instance, which handles code hosting and employee
identity authentication; model inference, where an embedded
copilot-proxy service forwards requests to upstream model
endpoints for compute; and the vendor cloud, which is completely
disconnected from GitHub’s public cloud in offline mode. This
architectural separation allows enterprises to independently control
identity and network boundaries.
For model interface standards, the internal proxy supports three
protocol specifications: openai, azure, and
anthropic. Selecting the openai specification
allows connection to various compatible backends deployed internally,
including private inference engines like Ollama, vLLM, and Foundry
Local. Models mounted by enterprises must natively support tool calling
and streaming, with the documentation recommending a context window of
at least 128k tokens. To prevent data from accidentally escaping over
the network during anomalies, the system implements an interception
policy: if a model provider configuration is invalid, the client
surfaces an error rather than silently falling back to GitHub-hosted
public models. In offline mode, the system does not initiate
subscription status checks to the GitHub public cloud, and all telemetry
reporting is disabled.
An isolated configuration does not automatically guarantee that code assets remain confined to the internal network. The official documentation lays out an explicit architectural condition: complete network isolation holds true only if the upstream model endpoint configured by the enterprise is itself hosted within an isolated or air-gapped network. If an administrator points the upstream address to a commercial API on the public internet, developers’ prompts and code files will still traverse network boundaries through the built-in proxy server and reach external service providers.
Switching to isolated mode also entails functional compromises. In
its current technical preview state, GitHub MCP server tools, web search
and scraping, GitHub-hosted model switching, telemetry reporting, and
automatic client updates are all unavailable. The core capabilities
reliably supported locally are primarily AI-assisted coding, local file
I/O, and gh CLI commands operating against the enterprise
self-hosted instance. Pushing forward to enterprise-wide scale still
leaves numerous questions unanswered in the official documentation, such
as enterprise licensing and entitlement allocation mechanisms,
request-level audit logging and compute metering, traffic routing across
multiple model providers, and log retention granularity for the proxy
service itself. In GitHub
community discussion #205381, several enterprise teams urged GitHub
to elevate the self-hosted edition into a first-class platform with
unified delivery and robust governance, though these demands remain
community feedback and have yet to appear on an officially committed
roadmap.
Runway demonstrated an attempt to bypass code and render interfaces directly using a model, Google Research validated the feasibility of having agents compile operating manuals for themselves in the background, and GitHub added a key puzzle piece for enterprises seeking centralized control over private model deployments in internal environments. However, moving from proofs-of-concept and early demos to running reliably across complex, evolving real-world workloads leaves many engineering hurdles to overcome. For now, the best path forward is to clearly recognize the boundaries and constraints staked out by each approach, while keeping a close watch on future iterations.