Ever since the commercialisation of the Graphical User Interface pioneered by systems like the Xerox Star and popularised by the original Apple Macintosh, software has relied heavily on point-and-click interactions. If you wanted to book a trip, buy a pair of shoes, or research a health symptom, you were expected to navigate a labyrinth of user interfaces. You click menus, adjust range sliders, fill out multi-step forms, deal with cookie pop-ups, and open dozens of browser tabs just to cross-reference basic information. We have become accustomed to spending more time managing the software rather than actually achieving our goals.

That contract is officially changing. Driven by advances in artificial intelligence and large language models, a new generation of web tools is pioneering a radical philosophy: Intent-Driven Design. Rather than expecting our users to learn complex menus and click through elaborate sales funnels, these platforms operate by capturing high-level human goals and silently executing the grunt work in the background.

This vision builds on long-standing HCI concepts like Golden Krishna’s “The Best Interface Is No Interface” and Don Norman’s principles of human-centered design.

The ultimate goal of modern web design is no longer to build prettier buttons or flashy animations; it is to eliminate the interface entirely.

Well, at least what we understand based on our current experience.

It is essential for UX designers to understand the changes we’re witnessing and even re-evaluate our role, shifting our focus from designing visible interfaces to guiding transparent, intent-driven AI experiences.

The Death Of The “10-click” Process

To understand where web design is going, we first have to look at the friction we have accepted as “normal” for decades.

Consider the traditional workflow of buying a flight online. The user experience is intentionally hyper-interactive:

1. Navigate to a travel aggregator or airline website.
2. Select “Round Trip” from a dropdown menu.
3. Type the origin city and wait for auto-complete.
4. Type the destination city and wait for auto-complete.
5. Click a calendar modal, toggle through months, and select departure and return dates.
6. Choose the number of passengers and cabin class.
7. Click “Search” and wait for the results page to load.
8. Filter by price, layover duration, departure time, and airline.
9. Sort the results and scan through dozens of individual options.
10. Click through a three-page checkout funnel dodging upsells for rental cars and travel insurance.

This is a classic point-and-click UI paradigm. The computer acts as a passive container of data, and the human acts as the orchestrator, manually inputting parameters, interpreting raw outputs, and executing each micro-step along the way.

Intent-driven design flips this dynamic entirely. Instead of forcing you to navigate the mechanical steps of how to find a flight, the interface asks a simple question: What are you trying to accomplish?

When you express a goal, such as “Find me a non-stop flight to Chicago next weekend under $300 that arrives before 5 PM”, the software reads your intent, executes the multi-step search query behind the scenes, compares the options, and presents a single actionable resolution. The ten clicks dissolve into one clear intent outcome.

Three Web Platform Examples Replacing Buttons With Intent

This shift isn’t a theoretical vision of the distant future. Some of the world’s most accessible websites allow you to experience intent-capturing systems already.

1. Perplexity AI: Search Without The Open Tabs

Traditional search engines like Google were built as directories. You typed a keyword, and the interface rewarded you with ten blue links. The actual work of opening five tabs, skimming long articles, dodging ads, and manually assembling an answer was left to you. Although this is now changing, with AI content appearing first when you search on Google.

Perplexity AI allows anyone to perform instant intent-based searches. Instead of forcing you to click into multiple tabs, the interface synthesises the perfect result for your context.

• The interaction: You ask a complex question in plain English: “Compare the top three budget laptops for a computer science student, focusing on battery life and keyboard quality.”
• The invisible work: In under two seconds, the platform searches the web, reads dozens of articles, evaluates hardware specifications, and cross-references user reviews.

• The result: (See screen above) Instead of throwing web pages at you, Perplexity dynamically generates a single custom answer complete with formatted comparison tables, pros and cons lists, and concise inline citations. You get the outcome of thirty clicks in just one.

2. Vercel v0: Web Design Without Dragging And Dropping

For years, creating a website meant using visual builders like Figma or drag-and-drop web editors. As designers, we spent hours manually drawing rectangles, picking hexadecimal colour codes, adjusting padding values, and sometimes writing CSS code.

Vercel v0 lets anyone test its generative interface builder right from the home page without signing in.

• The Interaction: A user types a descriptive goal into the input prompt: “Create a modern dark-mode dashboard for a subscription SaaS app showing monthly revenue, active users, and a customer churn chart.”
• The invisible work: The underlying AI understands layout principles, accessibility guidelines, UI component libraries, and responsiveness. It writes clean HTML, Tailwind CSS, and React code in real time.
• The result: Rather than spending an afternoon manipulating elements, the user receives a fully functional, pixel-perfect user interface in seconds! The traditional visual design tool disappears, replaced by raw human intent.

3. Goblin.tools: Breaking Down Overwhelming Tasks

Many traditional productivity tools require you to manually construct task lists, drag items across Kanban boards, and assign micro-deadlines. Goblin.tools is a free, single-page suite of single-task AI tools designed specifically for neurodivergent users or anyone feeling overwhelmed, requiring zero sign-ups or configuration.

• The interaction: You enter a vague, intimidating goal into the Magic Todo tool, such as “Prepare for a job interview”.
• The invisible work: Instead of forcing you to plan every step, the system analyses the cognitive load of the goal and automatically breaks it down into small, actionable sub-tasks adjusted to your preferred level of detail.
• The result: The interface eliminates the stressful task-planning phase and presents a clean checklist tailored to your exact goal.

The Core Pillars Of Intent-driven Web Design

When you remove traditional menus, sidebars, and forms, how do you keep a website usable? Designers pioneering this space rely on three core pillars:

Pillar	Traditional UX approach	Intent-driven UX approach
User input	Micro-actions (Clicks, dropdowns, toggles)	1. High-level goals (Natural language, context, habits)
Interface state	Static layouts (Everyone sees the same page)	2. Generative UI (Layouts created dynamically on the fly)
Task execution	Manual execution by the user	3. Autonomous execution by background AI agents

1. High-level Goals

An invisible interface doesn’t always wait for you to type a command — it leverages context to anticipate user needs. Guided by industry standards like Apple’s Human Interface Guidelines on Contextual & Ambient Design, modern systems read environmental metadata, such as device state, location, and past interaction patterns, to trigger proactive actions.

For example:

• Time and location: A food delivery web app prioritising your saved home address and dinner items automatically at 6:30 PM on a weekday.
• Cross-app history: A calendar application noticing an email about an upcoming appointment and surfacing a one-click “Add to Schedule” card without forcing you to copy and paste event details manually.

2. Generative UI

In traditional web design, every user sees the exact same layout. An e-commerce store shows the same navigation bar whether you are a first-time visitor looking for customer support or a returning customer tracking a package.

As highlighted in the Nielsen Norman Group’s analysis on AI as a new UX paradigm, computing is shifting from command-based interaction to outcome-specification. This enables Generative UI, where interfaces are rendered dynamically on the fly based on what you are trying to do in that exact moment. For example, platforms like Vercel v0 demonstrate how raw intent can instantly render functional code components without manual layout building. If you express a desire to compute complex financial data, the interface generates a dynamic calculator widget on demand, receding once your goal is completed.

3. Execution by AI Agents

Traditional interfaces are obsessed with prevention, constantly peppering users with confirmation pop-ups (“Are you sure you want to delete this file?”).

Intent-driven interfaces adapt Jakob Nielsen’s 10 Usability Heuristics on User Control and Error Recovery by shifting the safety net from prevention to easy reversibility. Because autonomous agents take actions on your behalf, products prioritise frictionless rollback mechanisms. A prominent “Undo” button, simple revision prompts (“Make this summary shorter”), and transparent audit logs replace intrusive warning modals.

The Hidden Risks

While removing interface friction is liberating, stripping away visual controls introduces significant product design challenges. When software acts on inferred intent rather than direct point-and-click commands, designers must navigate critical ethical and technical pitfalls.

The Illusion Of Control

When a website makes decisions for you, it can quickly feel patronising or invasive. As explored by the Stanford Human-Computer Interaction (HCI) Group, automation must maintain clear boundaries to prevent user frustration. Furthermore, ethical frameworks from the Center for Humane Technology emphasise that product designers must guard against manipulative defaults.

Designers must strike a delicate balance: automate routine execution, but explicitly prompt the user for high-stakes confirmations (such as financial transactions, publishing public content, or altering privacy settings).

The Black Box Problem

In a traditional UI, if you get an unexpected result, you can usually diagnose the issue — perhaps you checked the wrong filter box or selected an incorrect date.

With an intent-driven interface, troubleshooting becomes harder. To address this “black box” challenge, the Google PAIR (People + AI Research) Guidebook advocates for transparent feedback loops. The system must explicitly state its interpretation (“Searching for non-stop flights to Chicago under $300...”) so users can calibrate trust and correct misinterpretations instantly.

From A UX Perspective

As a UX designer, always being curious to understand how our design approach is changing in the world of AI, I find it essential that we re-evaluate the foundational elements of our craft.

Rather than designing static buttons and rigid forms, we need to learn to map and present dynamic, generative UI components that adapt on the fly to user intent.

By mastering these evolving patterns, like ambient feedback, inline prompts, and transparent AI status indicators, we can ensure that screenless, agent-driven tools remain intuitive, ethical, and deeply human-centered.

Conclusion

The ultimate goal: The best design is no design.

For decades, the digital industry has evaluated software success through engagement metrics like time spent in app, click-through rates, and page views per session. Websites were deliberately engineered to maximise visual engagement and interaction volume.

The philosophy behind Golden Krishna’s seminal book The Best Interface Is No Interface, aligned with the broader Center for Humane Technology’s Time Well Spent movement, turns these metrics on their head. The ultimate test of a modern digital product is no longer how visually captivating its buttons are, but rather: How effectively did this software solve the problem and get out of the user’s way?,

We are entering an era where web applications will no longer be measured by the beauty of their interfaces, but by their ability to render those complex interfaces completely obsolete. The future of the web isn’t more interaction — it is seamless, invisible completion.

Students who use AI to help them study tend to perform worse at school than those who don't, according to data from a global OECD educational report. The situation is more complex than it sounds though, with certain types of AI use giving learners a slight boost, especially among students taught to critically assess how well the AI tools perform.

The OECD's Programme for International Student Assessment (PISA) takes data from countries around the world every few years. This year's study, based on data collected in 2025, is the first to be carried out since AI use went truly mainstream. It tests 15-year-old students in science, math and read …

Read the full story at The Verge.

Microsoft has released the September 2026 Patch Tuesday Updates for all supported versions of Windows 11 and Windows 10. This month, the company rolled out 974 patches to address several vulnerabilities in Windows, Office, Azure, Active Directory, Exchange Server, Remote Desktop Client and Server, SQL Server, Windows Hello, Microsoft Defender, and other components.

Microsoft has already fixed 2,760 vulnerabilities this year, which is more than double the number from 2025. On the quality and experience update front, Microsoft has released several improvements for Windows 11 versions 26H1 as well as 25H2 and 24H2.

974 vulnerabilities fixed in the September 2026 Patch Tuesday updates

According to the Zero Day Initiative, Microsoft has fixed 114 security flaws rated as “Critical,” with the rest being rated Important in terms of severity. Here’s a list of the most notable vulnerabilities Microsoft addressed in September:

• CVE-2026-85880: This is an elevation of privilege bug in Windows Advanced Local Procedure Call (ALPC). This security vulnerability could be exploited by attackers to gain SYSTEM privileges.
• CVE-2026-81963: This is a privilege escalation vulnerability in the Windows Update Stack with a CVSS score of 7.8. Microsoft has warned that this flaw could allow attackers to gain SYSTEM-level access.
• CVE-2026-55007: This is one of the nine Exchange Server vulnerabilities disclosed this month. An unauthenticated attacker could achieve remote code execution on an affected Exchange Server by sending an email with a malicious Visio attachment.
• CVE-2026-69465: This is an authorization vulnerability in Microsoft SharePoint that carries a CVSS score of 8.8. Cybercriminals could exploit this flaw to execute code over an enterprise network.
• CVE-2026-65669: This is a 9.6-rated injection vulnerability in SQL Server that allows an unauthorized attacker to elevate privileges over a network. It could be exploited by hackers when a user submits instructions through SQL Copilot.
• CVE-2026-69525: This remote execution bug in Remote Desktop Services carries a CVSS score of 9.8.

You can find the full list of CVEs addressed in the September 2026 Patch Tuesday Updates below:

Product Family	Updates per Product/Version	Vulnerabilities Addressed	Distinct Updates	Type of Update
Azure	1	29	15	Individual
Defender	1	2	1	Cumulative
Developer Tools	1	27	36	Cumulative
Edge	1	16	1	Cumulative
Exchange Server	1	8	4	Cumulative
Office	1	99	11	Cumulative (except 2016)
Office 2016	1	99	18	Individual
Other	1	9	4	Individual
SharePoint Server	1	30	3	Cumulative
Windows	1	240	32	Cumulative

Quality and experience updates

Microsoft released the KB5124008 update for PCs running Windows 11 versions 26H1 and 25H2/24H2. This release brings additionalhigh-confidencee device targeting data, which increases coverage of devices eligible to automatically receive new Secure Boot certificates. Microsoft will continue certificate deployment through Windows updates across supported PCs and non-managed business devices in the next few months.

The KB5124008 update enhances the diagnostics logging experience for the OMA-DM client. It provides additional information to help troubleshoot device management server connection issues. Microsoft has also fixed a bug that could cause Microsoft Outlook and Teams to unexpectedly close on Arm64-based PCs.

Windows Update testing and best practices

Microsoft advises organizations to perform thorough testing to confirm that updates do not compromise the stability of their production systems. However, it is crucial to deploy Patch Tuesday updates to proactively address potential threats.

Additionally, IT administrators must prioritize backing up their systems before applying updates, utilizing the built-in backup features of Windows and Windows Server. These features allow for the restoration of specific files and folders or entire systems as required.

Last but not least, organizations should consistently monitor their systems for anomalies or unexpected behaviors. Regular monitoring is essential for staying vigilant against emerging risks and adopting appropriate security measures.

The post Microsoft Fixes More Than 100 Critical Vulnerabilities in September Patch Tuesday appeared first on Petri IT Knowledgebase.

The following article originally appeared on Sean Goedecke’s blog and is being republished here with the author’s permission.

In the 2010s, if you had technical gaps (say, you couldn’t write CSS), you had to either rely on a skilled colleague or just hope that the answer to your exact problem was out there on the internet. Today, everyone can write sort-of-okay CSS by delegating the task to an LLM. LLMs make everybody into a generalist.

Because of this, lots of people don’t think there’s any skill involved in working with LLMs. If you want the product that LLMs can deliver—PhD-level mathematics, pretty good but sometimes tasteless computer code, or awkward LinkedIn-style writing—you can simply ask for it. Since everyone is talking to the same models, “skilled prompters” are getting the same results as people touching LLMs for the first time.

This is wrong. The most important skill in prompting is expertise in the domain you’re prompting for.

A good illustration of this is Terence Tao’s conversation with ChatGPT about the recently discovered counterexample to the Jacobian conjecture. This is not the same ChatGPT I talk to! I couldn’t get to where Tao gets, even with unlimited tokens to burn.

There’s a lot to learn about good prompting from Tao’s conversation. Here are a few observations:

• Tao’s messages are very short and to the point. He doesn’t respond point by point to the model, just to the gist.
• The model outputs are much more concise than when I try to talk to GPT-5.6 Sol about mathematics. By signalling expertise, Tao shunts the model into “talking-to-mathematicians” mode, not “explaining-to-amateurs” mode.
• Tao pushes back when the model’s responses look wrong, but he doesn’t directly contradict; instead, he says things like “This looks more complex than I was hoping for.”
• Tao makes several leaps and suggestions himself. He almost never takes the model’s advice about where to go next.

However, you can’t prompt like Tao on mathematical questions just by following these tips. The key to his technique is actually understanding the mathematics: pulling the relevant idea out of ChatGPT’s multiparagraph response, suggesting alternate approaches or formulations, and identifying what “looks weird.”

Terence Tao is a better mathematician than I am a programmer. But the idea here—that domain knowledge makes you better at using LLMs—is something I’ve also experienced in my own work. If you have a good theory of your codebase, you can push the LLM much harder than if you have no familiarity. Because you have your own sense of what a good solution might look like, you can say, “No, I think it could be simpler here” or “But don’t we already do X?” or “Can we express this problem in these familiar terms?”

This touches on an idea I’ve written about before: that system design problems are dominated by concrete specifics, not generic principles. Of course both are useful, but I’d rather have familiarity with the codebase than a deep general understanding of software systems. In his conversation, Terence Tao asks a lot of specific questions like “Does X work here?” or “Given Y and Z, why A?” I can’t ask those questions about the Jacobian conjecture, but I can ask them about the systems I own at GitHub.

If you have no domain knowledge, you can cling onto the LLM to at least get something. That’s not bad! But if you have domain knowledge, you can wring far more value out of the same LLM by steering it hard in the direction you want. Most of us will have to do a mix of both these approaches, since we have domain knowledge in some areas but not others.

The usefulness of domain knowledge suggests that human expertise will continue to be useful even as models get stronger. For many tasks, the human is the bottleneck, not the model, because the difficult part is in communicating to the model exactly what kind of solution the human wants. The information is “in the model” already, but it takes a very smart human to pull it out.

This post got many comments on Hacker News. Some commenters share their anecdotes about how expertise has helped and lack of expertise has hurt. Other commenters say it’s plausible, but they have a sensible suspicion of a view that’s reassuring them about how they’re still valuable. I agree with that, though I suspect by the time we get around to studying this, the landscape will have changed under our feet again. Some commenters point out that OpenAI’s math prompts were inexpert, and so expertise isn’t required. Here I’d respond that OpenAI does have a team of expert mathematicians that checked and filtered the model’s suggested discoveries, and that you cannot currently skip that step.

JetBrains IDEs have worked with WSL for many years, and over time, several ways of using it have emerged across our products. Depending on the entry point, the IDE could rely on a different underlying architecture, leading to a different experience.

Starting with the 2026.2 release, there is one recommended entry point. In IntelliJ IDEA, WebStorm, and PhpStorm, opening a project that lives in WSL runs the IDE in what we call Native mode. The IDE stays a Windows application, while a small agent inside WSL handles files and processes on its behalf.

Below is how Native mode works, how our approach to WSL integration evolved to get here, and – since we tried three other approaches first – why we’re confident it’s the right foundation for your work.

What it takes to support WSL in an IDE

We’ll start with an idealized picture in which the IDE functions seamlessly inside WSL while being operated from Windows. In practical terms, “seamlessly” means you should be able to use any of the IDE’s capabilities – terminal, run and debug configurations, profiling, etc. – against a project that resides in a Linux environment. Not only that, but this must incur as little latency as possible for the coding experience to feel quick and natural, as if the project files and the IDE itself resided in a single operating-system environment.

We’ll trace how this challenge has been addressed, beginning with the earliest implementation, in which the IDE interacted with WSL through the 9P transport protocol. We will then cover Remote Development and WSLg before examining Native mode – the currently preferred mode for how IDEs work with WSL.

Toward native IDE execution in WSL

9P filesystem access and

For the IDE to function, it needs access to the basics of a project, which are plain files. This is where the 9P filesystem protocol comes in. It provides the mechanism that allows Windows-side processes access files inside WSL. In practice, project-related file I/O performed by the IDE – scanning, indexing, archive access, and similar operations – is routed through the 9P-based filesystem layer to the Linux virtual machine.

Once file access is accounted for, the next challenge is process execution. While running on Windows, the IDE must be able to invoke tools inside WSL with the correct Linux paths, working directories, executables, environment variables, and arguments. The IDE-internal GeneralCommandLine class manages this by normalizing command execution in the WSL environment.

While this architecture enables the IDE to operate against WSL, it introduces significant trade-offs in both file access and process execution.

The 9P protocol is known to be problematic for several reasons:

• Limited symlink handling – 9P does not properly expose Linux symbolic links to Windows through \\wsl$. As a result, the IDE may detect an entry but be unable to resolve or index the linked directory tree. This affects pnpm workspaces, Python virtual environments, PHP Composer path repositories, and other environments that rely on symlinks.
• Microsoft Defender scans – on-access scanning over 9P can stretch WSL file reads by tens of seconds.
• Latency and degraded throughput – 9P-backed filesystem access adds latency, and throughput can degrade significantly, especially in workflows involving many small files. Core IDE operations such as indexing follow this pattern, generating numerous separate requests that cross the Windows/WSL VM boundary through 9P.

The situation was no less challenging on the GeneralCommandLine side. The pipeline added a maintenance burden, as developers had to account for WSL-specific execution semantics across the codebase.

As a consequence, the approach became increasingly difficult to scale and maintain, and it surfaced persistent issues with symlink handling and performance.

Running the IDE inside WSL with WSLg

What if, instead, the IDE itself resided inside WSL, close to the project it works with? This is where WSLg comes in. It provides a way to run Linux GUI applications whose visual output is integrated directly into the Windows desktop.

Here’s why we do not recommend the WSLg approach:

• From a product perspective, if the IDE is displayed on Windows, it is preferable for it to behave as a Windows-native application rather than as a Linux GUI application projected into the Windows desktop. This preserves greater control over the IDE experience and avoids dependence on an additional GUI-remoting layer.
• In a WSLg setup, the IDE may run on the native Wayland path, where JetBrains Runtime uses WLToolkit against WSLg’s Wayland compositor. This path carries known limitations in rendering, popups, window management, input methods, and desktop integration.

No first-class product experience was ever built around this setup. Although running the IDE through WSLg is technically viable, it has never been considered the preferred direction, and no dedicated out-of-the-box installation or onboarding flow was provided. It remains an ad hoc workaround rather than a supported IDE workflow.

The Remote Development approach

Another approach was Remote Development, which addressed the same fundamental challenges of file access and process execution from a different angle. Rather than extending the Windows-based IDE across the WSL boundary, it moved the IDE backend into WSL and kept only the client on Windows. This architecture solved the underlying integration problems more directly, but introduced a different set of trade-offs.

The main technical challenge of this configuration is establishing and maintaining communication between them while ensuring that the UI accurately reflects user actions and the IDE continues to function as a coherent whole. At the same time, placing the backend inside WSL provides the clear advantage of direct access to Linux files and processes.

In this setup, the two IDE parts communicate over the JetBrains RD protocol. The protocol is a structured, bidirectional stream of IDE models and events that keeps the thin client and the backend IDE logically in sync, while all heavy work, such as indexing, analysis, builds, debugging, VCS operations, and so on, happens on the backend.

The client, in its turn:

• Renders all windows and editors, and handles user input.
• Mirrors the project and editor state it receives from the backend over the RD protocol, and sends back edits, caret moves, refactoring commands, debug actions, and so on.
• Loads UI-level plugins.

The elephant in the room, however, is the cost of this split architecture. The IDE backend is a heavyweight component in its own right, requiring roughly 2 GB of additional disk space and time to download and install inside WSL. The split also introduces an inherent performance penalty, as UI-event state, user input, and other interaction data must travel continuously between the local client and the backend.

It also adds development overhead, as the code has to be split into client and server parts. Leaving specific modules undivided can cause delays and freezes in highly dynamic UIs. The associated engineering effort therefore becomes a constant and unavoidable cost.

Native mode and the IJent agent

The current design – now integrated into most of our IDEs – represents the culmination of this work and addresses many of the shortcomings of earlier approaches to WSL.

To provide access to the Linux filesystem, processes, and other environment resources without relying on 9P, GeneralCommandLine, or other second-class communication mechanisms, we developed a small agent named IJent. Because it is designed specifically for IDE scenarios, we can shape its behavior, protocol, and capabilities according to our requirements.

Together, the IDE and IJent form a client–server pair. This may resemble the Remote Development model, but the server component is much thinner and, at the same time, more versatile. Installing IJent into a WSL environment is merely one of several possible configurations; the same model can also apply to Docker and Dev Containers.

By choosing this particular technology stack, we address a broad set of concerns:

• Rust implementation – Rust keeps the executable slim. By avoiding Java/Kotlin for the agent, we eliminate additional runtime dependencies inside containers or WSL.
• Transport layer – Stdio gives us a portable, firewall-friendly transport across all environments. Hyper-V sockets on WSL offer a faster path, which is especially beneficial for large or numerous filesystem transfers.
• Correct filesystem semantics – IJent executes filesystem operations on behalf of the IDE inside the target environment. As a result, path resolution, including symbolic links, follows correct Linux semantics rather than being mediated through 9P. Third-party plugins also benefit from this model, since their file operations are routed through IJent.

EelApi: one interface for any environment

For the IDE to fully benefit from IJent, changes on the IDE side are also required. Enter EelAPI.

EelApi is an API designed to abstract away the distinction between local and remote environments for everyone writing IDE-related code – plugin authors and platform contributors alike. With EelApi, the underlying environment against which the IDE operates should no longer matter, removing the need to account for these concerns explicitly in code. In this sense, EelApi is platform-agnostic, and the IDE can remain unaware of whether it is working locally, in WSL, in Docker, or in a Dev Container.

In general, IJent implements the EelApi interface, providing the actual functionality that EelApi exposes to the IDE and plugins.

If you’re interested in a more detailed explanation of EelApi, together with a practical introduction to the topic, head over to the article The Dev Containers Story: Introducing EelApi for Plugin Authors.

What this means in practice

There are two ways to open a WSL project today:

• Opening the project directly gives you Native mode in IntelliJ IDEA, WebStorm, and PhpStorm, and more IDEs are adopting the IJent and EelApi architecture as we speak.
• The Remote Development entry point on the Welcome screen still works, but it is no longer the recommended way to open a WSL project.

We conducted performance tests in order to compare 9P mode and Native mode. The results show a clear performance gain in favor of the new approach:

Cold-open benchmark

IJent cuts 38% off the wait for a large WSL project

9P IJent

Ready to work

18.5 s

11.5 s

38% less

Scan project tree

8.1 s

3.7 s

54% less

Index files

10.8 s

8.4 s

22% less

Read file content

12.2 s

5.7 s

53% less

Where this applies: A cold first open of spring-framework, with 23 subprojects and 8,191 source files. A small project with few source files showed no measurable difference.

Test setup: Median of five measured runs on Windows 11 with WSL 2, Ubuntu 24.04, and IntelliJ IDEA Ultimate 263.SNAPSHOT.

Beyond performance, this architecture places development in WSL within the broader context of development in non-local environments, allowing them to be approached through the same underlying model. The same IJent agent already backs our work on Docker and Dev Containers.

Thank you for reading and for all the feedback that helped us reach this point. Tell us how Native mode holds up against your projects in the comments below.

MG Siegler is the author of Spyglass. Siegler joins Big Technology to discuss Apple’s sudden burst of new products and what it means for the company as John Ternus takes over from Tim Cook. Tune in to hear why Apple’s foldable iPhone could reinvigorate the business, how its new hardware strategy marks a departure from the past, and what challenges Ternus will face as CEO. We also cover Google’s shifting AI strategy, OpenAI’s resurgence, Anthropic’s potential IPO, and the increasingly blurry meaning of AGI. Hit play for a wide-ranging look at Apple’s new era and the rapidly changing competitive landscape in artificial intelligence.

---

Enjoying Big Technology Podcast? Please rate us five stars ⭐⭐⭐⭐⭐ in your podcast app of choice.

Want a discount for Big Technology on Substack + Discord? Here’s 25% off for the first year: https://www.bigtechnology.com/subscribe?coupon=0843016b

Learn more about your ad choices. Visit megaphone.fm/adchoices

Download audio: https://pdst.fm/e/tracking.swap.fm/track/t7yC0rGPUqahTF4et8YD/pscrb.fm/rss/p/traffic.megaphone.fm/AMPP5870405148.mp3