Add copilot sandbox ca commands to check, create, trust, rotate, and remove proxy CA trust, including unattended Windows setup; /sandbox ca install becomes create and trust
Session timelines now clear busy status after interrupted turns finish.
Sandboxed commands run on Windows versions without filesystem enumeration support, with a warning that PowerShell's current location may be wrong
Footer text selection stays on the same visible line when the footer grows or shrinks.
Offer sandbox network bypass for Node/npm EACCES socket denials on Windows
CLI shutdown flushes pending telemetry before exit, with a bounded delay when telemetry is still initializing.
Complete, statically analyzable read-only shell pipelines can now enter execution-evidence review, while incomplete or unbound pipelines require explicit approval.
The following article originally appeared onRobert Englander’s blog siteand is being reposted here with the author’s permission.
The software industry has become deeply focused on autonomous AI systems. Agents that can replace workers. Agents that can write software. Agents that can operate applications on our behalf. Entire startups are now built around the assumption that the natural end state of AI is autonomy.
Some of this work is genuinely useful. AI-assisted coding can improve productivity. Generative systems are already helping people draft documents, summarize information, and accelerate certain kinds of repetitive work. There are clearly domains where more automation makes sense.
Still, I increasingly suspect the industry may be underestimating another opportunity that feels both more practical and potentially more transformative over the long term: natural language interfaces sitting on top of deterministic software systems.
Much of the current AI narrative assumes the model itself should become the authoritative actor. The AI writes the code. The AI performs the workflow. The AI executes the task. The AI makes the decision. The conversation around “agents” often assumes the system itself should gradually absorb more and more of that responsibility until people become optional.
The problem is that large language models are probabilistic systems. They’re incredibly capable. But they’re still statistical machines. They hallucinate, improvise, approximate. In many contexts, that’s perfectly acceptable.
Brainstorming, summarization, drafting, translation, and exploratory work all tolerate a degree of uncertainty. Deterministic systems generally don’t.
Financial systems have to calculate correctly. Scheduling systems have to preserve consistency. Medical systems have to maintain integrity. Accounting systems have to reconcile accurately. Reliability is still the foundation upon which useful software is built.
That’s one reason I think the most important role for LLMs may not be replacing deterministic systems, but reducing the friction between people and those systems.
Historically, software interfaces forced people to adapt to machine discipline. We learned command syntax. We navigated menus and workflows. We memorized procedures. We filled out forms in exactly the way the application expected. Even graphical interfaces, which were a huge leap forward, still largely required users to think in terms of the structure of the software itself. Natural language interfaces potentially invert that relationship.
Instead of forcing users closer to the system, the system moves closer to human expression. That may sound subtle, but I think it represents a significant shift in how software can be experienced. A user no longer needs to think primarily in terms of application structure or workflow design. The interaction begins to center more naturally around intent.
“Show me how delaying Social Security by two years impacts long-term spending.”
“Transfer $500 from checking into savings next Friday.”
“Why did my tax liability increase this year?”
“Find the contracts signed after January that contain auto-renewal
language.”
None of these requests eliminates the need for deterministic systems underneath. In fact, they depend on them. The natural language layer simply acts as an interpreter between human expression and authoritative execution.
That architecture feels considerably more durable to me than the idea that probabilistic systems should become the primary authority layer themselves.
One interesting thing about the current AI wave is that language models are often strongest in areas involving interpretation. They’re remarkably good at extracting meaning from ambiguous human communication, maintaining conversational context, translating between representations, and helping users express intent more naturally. Those are fundamentally interaction problems.
Meanwhile, the areas where language models remain weakest are usually the areas requiring guarantees, consistency, accountability, and deterministic correctness. Those are system-of-record problems. The current industry conversation often blurs the distinction between the two.
I don’t think conversational interfaces reduce the importance of deterministic software. If anything, they increase it. Once users begin interacting through natural language, the validation layer underneath becomes even more critical. Systems have to safely interpret intent, validate operations, preserve constraints, and maintain correctness even when the incoming requests are conversational and ambiguous.
The conversational layer improves accessibility. The deterministic layer preserves trust.
Both matter.
Every major era of computing has involved some kind of interface transition. Mainframes required specialized operators. Personal computers brought graphical interfaces that made computing accessible to nonspecialists. The web normalized hyperlinks, search, and forms. Mobile computing shifted interaction toward touch and gestures. Natural language may become the next major abstraction layer.
Not because computers suddenly became human-like, but because we finally built systems capable of translating between human communication and machine discipline at scale.
I also think this changes how we should think about software’s future. The current AI environment sometimes frames autonomy as the inevitable destination. If an AI can partially perform a task today, many assume the long-term outcome is full replacement of the person performing that task.
I’m not convinced that’s where the most durable value lies.
In many domains, the real friction isn’t execution. It’s interface complexity. People struggle less with the underlying capabilities of software than with the difficulty of expressing what they actually want the software to do.
Enterprise systems are notoriously difficult to navigate. Financial systems expose overwhelming complexity. Creative tools bury users under layers of workflow and terminology. Even relatively simple applications often require substantial onboarding before users become comfortable with them.
Natural language interfaces potentially change that equation in a meaningful way. They allow software to meet users closer to where they already are: ordinary human communication.
That doesn’t mean conversational systems should become undisciplined systems. In fact, I think the opposite is true. As interfaces become more conversational, the underlying architecture has to become even more rigorous about validation and execution semantics. The ambiguity doesn’t disappear. It moves.
Historically, much of the burden of precision sat on the user. The user had to learn the syntax, understand the workflow, and conform to the application’s structure.
Conversational systems shift more of that burden into the interpretation and validation layers of the software itself. That’s not a trivial engineering problem. It requires clarification, normalization, policy enforcement, validation, and authoritative execution underneath the conversational layer. It also requires accepting that probabilistic interpretation and deterministic execution aren’t competing ideas. They’re complementary ones.
This is one reason I increasingly think the future of software may become conversational without necessarily becoming autonomous. The two ideas are related. But they’re not the same thing.
There’s enormous value in reducing the natural friction between human expression and machine discipline. Large language models may ultimately prove most transformative not when they replace deterministic systems, but when they help people interact with those systems more naturally.
For decades, people have adapted to computers. It now seems possible that software may finally start adapting to people instead.
As the team behind a dedicated Rust IDE, we’re naturally curious to see how RustRover stacks up against other popular setups for Rust development and the strengths and trade-offs of each one. This article is the first in a series where we’ll look at different Rust workflows.
We’re not unbiased, but we want to give you an objective overview of what each tool offers. We’ll break down what each setup does well, its limitations, and what it’s like to use day-to-day. We’ll start with VS Code + rust-analyzer, one of the most common setups. We’ll also share a few tips for switching from VS Code to RustRover, so you can try it yourself and see what workflow is the best fit for you.
TL;DR: RustRover vs VS Code + rust-analyzer
VS Code is a general-purpose editor. The rust-analyzer extension provides Rust-specific completion, diagnostics, navigation, and refactoring.
RustRover is a professional Rust IDE with its own code analysis engine integrated with its Cargo project model, while other IDE tools use project context provided by that model.
VS Code gives you a modular environment that you can customize with extensions, settings, tasks, and launch configurations.
RustRover may suit developers who want code analysis, Cargo, testing, debugging, and refactoring connected through one project model.
Either setup works well for day-to-day Rust development. The better fit depends on how you prefer to organize and configure your tools. Some developers prefer to keep both options available, and switch between them based on the task at hand.
VS Code + rust-analyzer and RustRover: A quick overview
VS Code + rust-analyzer
VS Code was launched by Microsoft back in 2015, with the first released version 1.0 in 2016. It’s a general-purpose editor that you can extend for different languages and workflows. For Rust, language support comes from rust-analyzer, which runs as a language server and analyzes the Cargo workspace behind the files you have opened. It provides completion, diagnostics, inlay hints, navigation, quick-fixes, and refactoring inside VS Code.
VS Code lets you further customize your setup with extensions, tasks, launch configurations, terminal commands, and personal settings. This makes it a flexible option for those who want to use the same editor for multiple languages.
RustRover uses its own Rust analysis engine. When you open a Cargo project, the IDE analyzes the workspace and builds a model of its crates, dependencies, targets, and code structure. This understanding supports completion, navigation, inspections, quick-fixes, and project-wide refactoring.
Cargo, testing, debugging, databases, web dev support, and version control are also built into the IDE. RustRover remains configurable within this structure. You can customize keymaps, settings, code style, run configurations, toolchain behavior, and the interface, as well as install plugins for additional technologies and workflows.
RustRover vs VS Code: Key differences
Before we get into the table, a quick note about what we mean by “VS Code + rust-analyzer”: We’re focusing only on the parts of the setup that are essential for Rust development, which include the integrated terminal, tasks, launch configurations, and (in some cases) a debugger extension. We won’t cover every optional extension, only the tools needed for the workflows in this article.
The overview above explains how the two setups are put together. The table below shows how they differ when you navigate code, run Cargo targets, test, debug, and refactor.
rust-analyzer provides actions such as Go to Definition and Go to References. You can use them with VS Code’s Explorer and workspace search.
RustRover provides declaration and usage navigation through its indexed project model. The Project and Cargo tool windows provide additional workspace views.
Cargo and running code
You can run Cargo commands in the integrated terminal or start supported targets through rust-analyzer. Tasks can save commands you use regularly.
You can run targets from the editor or the Cargo tool window. RustRover creates run configurations that you can save and adjust.
Testing
You can run tests through rust-analyzer actions, Cargo commands, or VS Code tasks.
You can run tests from the editor or the Cargo tool window and view the results in the IDE’s test runner.
Debugging
Rust debugging requires a compatible extension, such as CodeLLDB or Microsoft C/C++. Launch configurations can save your debugger settings.
Rust debugging is included in the IDE and works through the same run/debug configurations used for targets and tests.
Inspections and refactoring
rust-analyzer provides diagnostics, quick-fixes, renaming, and other refactoring actions. Cargo Check or Clippy can provide additional feedback.
RustRover combines built-in inspections, quick-fixes, and refactoring tools with feedback from Cargo Check or Clippy. You can review affected usages before applying project-wide changes.
That difference in how the two setups are put together also comes up in community discussions. One Reddit user described it this way:
If AI is part of your workflow, you can use it in either environment for quick suggestions or larger-scale tasks that use broader project context. The agents you can connect, how you access models, and which development tools those agents can use differ. Here is a short overview of AI capabilities in both environments.
Area
VS Code
RustRover
AI workflows
VS Code supports inline suggestions, chat, planning, multi-file editing, and agent-driven tasks.
JetBrains AI provides code suggestions and other in-IDE features, while Air lets you run agent-driven tasks inside RustRover
Agent choice
You can use agent providers such as GitHub Copilot, Claude, and Codex.
Air works with agents including Junie, Claude Agent, Codex, GitHub Copilot, and OpenCode. You can also connect other compatible agents through ACP.
Models and accounts
You can use models included with a GitHub Copilot plan, connect supported providers with your own API key, or use supported local models.
You can use JetBrains AI, supported provider subscriptions, or your own API keys. Available options depend on the agent and provider you choose.
Development tools and context
Agents can work with workspace code, errors, tests, the terminal, and tools connected through MCP.
You can run agents inside RustRover and review their changes with the IDE’s project and code tools. Starting with RustRover 2026.3, agents can also control the debugger through MCP.
Air also goes beyond the IDE. You can use it through the web, command line, and mobile, while its team features cover shared environments and automations. For this comparison, we’re focusing on Air inside RustRover: running agents and reviewing their work alongside your code.
What do these differences look like in practice?
Imagine you are working in a multi-crate workspace. A function called from a binary crate is defined in a library crate and re-exported through another module. You need to find its declaration, check its uses, rename it, and run the tests that cover this functionality.
In VS Code, you can start with rust-analyzer’s Go to Definition action to find the function. Next, Go to References shows where it is used across the Cargo workspace, and Rename Symbol applies the new name across the relevant Rust files. Once the change is ready, you can run the affected test through a rust-analyzer action or use Cargo in the integrated terminal. If the test fails, rust-analyzer can provide the Debug action, while a compatible debugger extension provides debugging support. You can save commands and debugger settings in tasks and launch configurations to repeat the workflow.
In RustRover, you can start by following the function to its declaration through the IDE’s indexed project model. The Project and Cargo tool windows provide additional workspace views, while Find Usages shows where the function is referenced. You can then use the Rename refactoring and see what will change before applying the new name. Once the change is ready, run the test from its gutter action or the Cargo tool window. If it fails, you can start debugging from the same gutter action or run/debug configuration. RustRover creates a temporary configuration that you can save if you want to reuse the same arguments or environment variables.
Both environments can take you from navigation to a completed change. The difference is the path you follow and how the tools present the wider project context along the way.
We asked several Rust developers who normally used VS Code to work in RustRover for a week and keep a diary of their experience. This was a JetBrains study, so their comments do not represent every Rust developer, but they tell us a lot about what it’s like to make the switch.
“The debugger was easily the best part, honestly. Being able to stop right on the age check and see the real numbers made it click instead of me just assuming the math worked.”
Anonymous participant in a JetBrains RustRover diary study
How to switch from VS Code to RustRover in five steps
Switching from VS Code to RustRover doesn’t mean you have to re-learn everything. Follow the steps below to customize your setup so that RustRover feels familiar from day one.
1. Import your settings and select the VS Code keymap
When you first open RustRover, select VS Code in the Import Settings dialog and choose what you want to bring over. This can include your keymap, theme, extensions, and recent projects.
2. Open a familiar Cargo project
Start with a real project rather than a sample. If the repository has multiple Cargo projects and RustRover asks which ones to attach, include the projects you want the IDE to work with. Do not dismiss the dialog without checking it, or parts of the repository may be missing from the project model.
Orhun Parmaksız, a JetBrains Developer Advocate and open-source Rust contributor, shared how he brought his familiar workflow into RustRover:
“When I move to a new IDE, I prefer to keep the keybindings and habits I already use. For RustRover, I used IdeaVim and asked Codex to adapt my Neovim configuration. I saved the result in my dotfiles so I could reuse it, and VS Code users can take the same approach with their own keybindings. The transition was smooth; the only drawback was needing to restart the IDE for the configuration changes to take effect.”
Before opening the project, go to Settings | Rust and ensure that RustRover has detected the toolchain you expect to use. If the Toolchainversion shows a version number and you do not see an option to install or download Rustup, you are ready to continue.
4. Wait for the project to load
Let the first Cargo sync and indexing finish before investigating red highlighting or unresolved code. At this stage, RustRover is still building its understanding of the project, so some warnings may be only temporary.
5. Run or debug something you’re already familiar with
Choose a familiar test or target and run or debug it from the editor. This is a quick way to confirm that the project, toolchain, and main development actions are ready.
If your project uses Cargo features, you can manage them through the IDE instead of a separate JSON configuration. For complete setup instructions and more VS Code equivalents, see the migration guide.
RustRover or VS Code: Choosing the right fit?
If you already use VS Code for several languages, prefer a lighter editor, and want to choose your own extensions and configuration, staying with VS Code and rust-analyzer may make the most sense.
But if you want a professional Rust IDE with an integrated debugger, project-wide refactoring, Cargo.toml assistance, and tools that share the same understanding of your Cargo project, RustRover feels like a natural choice. The trade-off is that a full IDE can feel heavier and busier than an editor-based setup.
“VS Code still feels lighter for quick edits, but RustRover feels better when working inside a project for a longer time and trying to understand the code structure.”
Anonymous participant in a JetBrains RustRover diary study
If you are still unsure, open one of your projects in both environments and try doing a task you perform regularly. Seeing each setup in action will tell you far more than a list of features ever could.
FAQ
Does RustRover use rust-analyzer under the hood?
No, RustRover does not use rust-analyzer. It uses JetBrains’ own Rust analysis engine, which is integrated directly with the IDE’s project model, Cargo support, and other built-in tools.
Is RustRover free?
RustRover is free for individual non-commercial use, while commercial development requires a paid license. The free version has the same IDE features, but it includes anonymous usage statistics. However, this data does not include your source code or custom input.
Which Rust IDE is better for beginners: RustRover or VS Code?
RustRover is better for beginners because you can learn and practice Rust without leaving the IDE. Free courses such as Learn Rust and 100 Exercises to Learn Rust guide you through Rust concepts with exercises, hints, and feedback on your code. You can also find tutorials and more beginner resources on our Getting Started with Rust page.
Do I have to rebuild my workflow from scratch when switching to RustRover?
No, RustRover allows you to import your VS Code keymap, theme, extensions, and recent projects, so running and debugging in RustRover will feel familiar from the get-go.
Pankaj Kumar: The Scrum Master Success Metric of Team Independence
Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.
"The best thing to measure the success of a Scrum Master is that the team is not dependent on the Scrum Master." - Pankaj Kumar
For Pankaj, Scrum Master success has a clear test: can the team work, decide, inspect, and improve without depending on the Scrum Master for every step? He looks for self-organization, confidence in Scrum events, and a team that can continue improving without constant intervention. But he does not rely only on impressions. Pankaj uses team metrics such as velocity, backlog health, lead time, cycle time, and Cumulative Flow Diagrams when Kanban is in use. He also pays attention to team satisfaction and regular feedback. The frequency of that reflection depends on team maturity. Mature teams may need a two-week check-in rhythm, while newer teams need closer weekly attention. His maturity model is deliberately adapted team by team, because every team's product, skills, technical context, and backlog are different. The bigger point for Scrum Masters is useful: success is not being needed in every conversation. Success is seeing the team grow enough that your presence becomes lighter.
Self-reflection Question: What would your team do this week if you were not available to guide the Scrum events?
Featured Retrospective Format for the Week: Anonymous Action-Tracking Spreadsheet
Pankaj keeps retrospectives simple and practical. Before the retrospective, he shares a spreadsheet where team members can add what went well, what needs improvement, the action needed, who is accountable, the deadline, and the status of previous actions. He also allows anonymous input, which helps quieter team members raise points they may not want to voice live. During the meeting, the team reviews previous retrospective actions and then discusses the current sprint. Pankaj is careful about who is in the room. Sometimes supervisors are needed, but often their presence changes what people are willing to say. For him, facilitation starts with creating the right audience for the conversation.
[The Scrum Master Toolbox Podcast Recommends]
🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥
Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people.
🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue.
Pankaj Kumar is an experienced Scrum Master and Agile Coach with over 18 years in IT. He helps teams adopt Agile ways of working, improve collaboration, remove impediments, and deliver value consistently. He facilitates Scrum ceremonies, coaches teams and stakeholders, and supports Agile transformation across organizations.
1225. This week, we talk to lexicographer Steve Johnson from Dictionary.com. We look at how slang like "no cap" and "throw hands" works its way up from a separate slang dictionary, why one lexicographer fought against adding "rizz," and where "lost in the sauce" comes from. Then we look at what "overprompting" says about how we talk to AI, why food words like "quesabirria" and "elote" can take years to reach the dictionary, and how the team is starting to size up contenders for word of the year.
🔗 Share your familect recording in Speakpipe or by leaving a voicemail at 833-214-GIRL (833-214-4475)
As AI moves beyond the cloud and into robots, vehicles, and other physical systems, new approaches to models, simulation, and inference are emerging. Daniel and Chris are joined by Ming-Yu Liu, Vice President of Cosmos Lab at NVIDIA, who shares his perspective on open models, world models, and the future of physical AI. They explore why open models matter for innovation, how world models can help AI understand and simulate the physical world, and what it could take to build increasingly capable physical AI systems.
Midwest AI Summit: Join AI practitioners on October 15 in Indianapolis for practical sessions, hands-on discussions, and real-world AI solutions. Use code PracticalAI20 to save 20% on your registration. https://midwestaisummit.com/#tickets
Prediction Guard: A self-hosted AI control plane for running agents in high impact environments. predictionguard.com/practicalai
Log in
