I care about design system adherence, technical flexibility, and clean code — so I wanted to see if I could get the LLM to cooperate and use AgnosticUI to build a bespoke login form.
It took a few attempts, but I got there. The AI generates the login without hallucination, follows real breakpoints, and sticks to design-system constraints.
Same spec, multiple frameworks. Different fonts and branding to show it's customizable.
The Login Playbook and prompts are public in the AgnosticUI docs — useful if you're experimenting with AI + design systems and care about repeatable output.
Anders Hejlsberg’s work has shaped how millions of developers code. Whether or not you recognize his name, you likely have touched his work: He’s the creator of Turbo Pascal and Delphi, the lead architect of C#, and the designer of TypeScript.
We sat down with Hejlsberg to discuss his illustrious career and what it’s felt like to watch his innovations stand up to real world pressure. In a long-form conversation, Hejlsberg reflects on what language design looks like once the initial excitement fades, when performance limits appear, when open source becomes unavoidable, and how AI can impact a tool’s original function.
What emerges is a set of patterns for building systems that survive contact with scale. Here’s what we learned.
Watch the full interview above.
Fast feedback matters more than almost anything else
Hejlberg’s early instincts were shaped by extreme constraints. In the era of 64KB machines, there was no room for abstraction that did not pull its weight.
“You could keep it all in your head,” he recalls.
When you typed your code, you wanted to run it immediately.
Anders Hejlsberg
Turbo Pascal’s impact did not come from the Pascal language itself. It came from shortening the feedback loop. Edit, compile, run, fail, repeat, without touching disk or waiting for tooling to catch up. That tight loop respected developers’ time and attention.
The same idea shows up decades later in TypeScript, although in a different form. The language itself is only part of the story. Much of TypeScript’s value comes from its tooling: incremental checking, fast partial results, and language services that respond quickly even on large codebases.
The lesson here is not abstract. Developers can apply this directly to how they evaluate and choose tools. Fast feedback changes behavior. When errors surface quickly, developers experiment more, refactor more confidently, and catch problems closer to the moment they are introduced. When feedback is slow or delayed, teams compensate with conventions, workarounds, and process overhead.
Whether you’re choosing a language, framework, or internal tooling, responsiveness matters. Tools that shorten the distance between writing code and understanding its consequences tend to earn trust. Tools that introduce latency, even if they’re powerful, often get sidelined.
Scaling software means letting go of personal preferences
As Hejlsberg moved from largely working alone to leading teams, particularly during the Delphi years, the hardest adjustment wasn’t technical.
It was learning to let go of personal preferences.
You have to accept that things get done differently than you would have preferred. Fixing it would not really change the behavior anyway.
Anders Hejlsberg
That mindset applies well beyond language design. Any system that needs to scale across teams requires a shift from personal taste to shared outcomes. The goal stops being code that looks the way you would write it, and starts being code that many people can understand, maintain, and evolve together. C# did not emerge from a clean-slate ideal. It emerged from conflicting demands. Visual Basic developers wanted approachability, C++ developers wanted power, and Windows demanded pragmatism.
The result was not theoretical purity. It was a language that enough people could use effectively.
Languages do not succeed because they are perfectly designed. They succeed because they accommodate the way teams actually work.
Why TypeScript extended JavaScript instead of replacing it
TypeScript exists because JavaScript succeeded at a scale few languages ever reach. As browsers became the real cross-platform runtime, teams started building applications far larger than dynamic typing comfortably supports.
Early attempts to cope were often extreme. Some teams compiled other languages into JavaScript just to get access to static analysis and refactoring tools.
That approach never sat well with Hejlsberg.
Telling developers to abandon the ecosystem they were already in was not realistic. Creating a brand-new language in 2012 would have required not just a compiler, but years of investment in editors, debuggers, refactoring tools, and community adoption.
Instead, TypeScript took a different path. It extended JavaScript in place, inheriting its flaws while making large-scale development more tractable.
This decision was not ideological, but practical. TypeScript succeeded because it worked with the constraints developers already had, rather than asking them to abandon existing tools, libraries, and mental models.
The broader lesson is about compromise. Improvements that respect existing workflows tend to spread while improvements that require a wholesale replacement rarely do. In practice, meaningful progress often comes from making the systems you already depend on more capable instead of trying to start over.
Visibility is a part of what makes open source work
TypeScript did not take off immediately. Early releases were nominally open source, but development still happened largely behind closed doors.
That changed in 2014 when the project moved to GitHub and adopted a fully public development process. Features were proposed through pull requests, tradeoffs were discussed in the open, and issues were prioritized based on community feedback.
This shift made decision-making visible. Developers could see not just what shipped, but why certain choices were made and others were not. For the team, it also changed how work was prioritized. Instead of guessing what mattered most, they could look directly at the issues developers cared about.
The most effective open source projects do more than share code. They make decision-making visible so contributors and users can understand how priorities are set, and why tradeoffs are made.
Leaving JavaScript as an implementation language was a necessary break
For many years, TypeScript was self-hosted. The compiler was written in TypeScript and ran as JavaScript. This enabled powerful browser-based tooling and made experimentation easy.
Over time, however, the limitations became clear. JavaScript is single-threaded, has no shared-memory concurrency, and its object model is flexible (but expensive). As TypeScript projects grew, the compiler was leaving a large amount of available compute unused.
The team reached a point where further optimization would not be enough. They needed a different execution model.
The controversial decision was to port the compiler to Go.
This was not a rewrite. The goal was semantic fidelity. The new compiler needed to behave exactly like the old one, including quirks and edge cases. Rust, despite its popularity, would have required significant redesign due to ownership constraints and pervasive cyclic data structures. Go’s garbage collection and structural similarity made it possible to preserve behavior while unlocking performance and concurrency.
The result was substantial performance gains, split between native execution and parallelism. More importantly, the community did not have to relearn the compiler’s behavior.
Sometimes the most responsible choice isn’t the most ambitious one, but instead preserves behavior, minimizes disruption, and removes a hard limit that no amount of incremental optimization can overcome.
In an AI-driven workflow, grounding matters more than generation
Hejlberg is skeptical of the idea of AI-first programming languages. Models are best at languages they have already seen extensively, which naturally favors mainstream ecosystems like JavaScript, Python, and TypeScript.
But AI does change things when it comes to tooling.
The traditional IDE model assumed a developer writing code and using tools for assistance along the way. Increasingly, that relationship is reversing. AI systems generate code. Developers supervise and correct. Deterministic tools like type checkers and refactoring engines provide guardrails that prevent subtle errors.
In that world, the value of tooling is not creativity. It is accuracy and constraint. Tools need to expose precise semantic information so that AI systems can ask meaningful questions and receive reliable answers.
The risk is not that AI systems will generate bad code. Instead, it’s that they will generate plausible, confident code that lacks enough grounding in the realities of a codebase.
For developers, this shifts where attention should go. The most valuable tools in an AI-assisted workflow aren’t the ones that generate the most code, but the ones that constrain it correctly. Strong type systems, reliable refactoring tools, and accurate semantic models become essential guardrails. They provide the structure that allows AI output to be reviewed, validated, and corrected efficiently instead of trusted blindly.
Why open collaboration is critical
Despite the challenges of funding and maintenance, Hejlberg remains optimistic about open collaboration. One reason is institutional memory. Years of discussion, decisions, and tradeoffs remain searchable and visible.
That history does not disappear into private email threads or internal systems. It remains available to anyone who wants to understand how and why a system evolved.
Despite the challenges of funding and maintenance, Hejlsberg remains optimistic about open collaboration. And a big reason is institutional memory.
“We have 12 years of history captured in our project,” he explains. “If someone remembers that a discussion happened, we can usually find it. The context doesn’t disappear into email or private systems.”
That visibility changes how systems evolve. Design debates, rejected ideas, and tradeoffs remain accessible long after individual decisions are made. For developers joining a project later, that shared context often matters as much as the code itself.
A pattern that repeats across decades
Across four decades of language design, the same themes recur:
Fast feedback loops matter more than elegance
Systems need to accommodate imperfect code written by many people
Behavioral compatibility often matters more than architectural purity
Visible tradeoffs build trust
These aren’t secondary concerns. They’re fundamental decisions that determine whether a tool can adapt as its audience grows. Moreover, they ground innovation by ensuring new ideas can take root without breaking what already works.
For anyone building tools they want to see endure, those fundamentals matter as much as any breakthrough feature. And that may be the most important lesson of all.
In today’s fast‑moving digital arena, security isn’t a solo act—it’s a team sport. Every day, defenders across the globe suit up, strategize, and work shoulder‑to‑shoulder to protect organizations and communities from an ever‑evolving field of cyberthreats. That shared spirit of collaboration is exactly why we’re proud to celebrate our 2026 Microsoft Security Excellence Awards winners—exceptional teammates who elevate the game for everyone.
On Monday, January 26, 2026, in Redmond, Washington, we brought together the all‑star players of the Microsoft Intelligent Security Association (MISA), partners, finalists, and Microsoft security leaders—to honor the innovators, defenders, and visionaries driving the future of cybersecurity.
“Congratulations to this year’s Microsoft Security Excellence Awards winners and all the remarkable finalists,” said Vasu Jakkal, Corporate Vice President, Microsoft Security Business. “Security is truly a team sport, and our partners demonstrate the power of collaboration every day. By joining forces and harnessing the latest advancements in AI, we’re building stronger defenses and paving the way for a safer digital future together.”
Just like in any great sport, success comes from strong teamwork and relentless practice. Over the past year, our partners have pushed the boundaries of what’s possible—from pioneering AI‑powered threat intelligence to advancing Zero Trust strategies that keep organizations safer than ever. The finalists and winners represent the very best of this collective effort: disciplined, innovative, and deeply committed players who raise the bar for everyone on the field.
After careful review of all nominations, our esteemed judging panel selected five finalists per category, with winners selected by votes from Microsoft and MISA members. We’re honored to recognize these standout contributors—thank you for being the teammates who make the whole ecosystem stronger.
Security Trailblazer
Partners that have delivered innovative AI-powered solutions or services that leverage the full Microsoft range of security products and have proven to be outstanding leaders in accelerating customers’ efforts to mitigate cybersecurity threats.
Avertium—Winner
Avanade
Bulletproof
ExtraHop
Ontinue
Data Security and Compliance Trailblazer
Partners recognized for leading innovative solutions and providing comprehensive strategies to secure customer data with Microsoft Purview. These leaders help customers protect data everywhere, address regulatory needs, and drive AI-powered outcomes with expertise across Purview’s advanced security and advisory services.
BlueVoyant—Winner
Invoke LLC
Netrix Global
Quorum Cyber
water IT Security GmbH
Secure Access Trailblazer
Partners recognized for pioneering innovation in identity, security, and management using Microsoft Entra and Microsoft Intune. Their solutions advance secure access and endpoint management, applying Zero Trust principles to protect organizations and deliver strong security outcomes.
Tata Consultancy Services—Winner
Cayosoft
Devicie
IBM Consulting
Inspark
Security Changemaker
Individuals within partner organizations who have made a remarkable security contribution to the company or the larger security community.
Anna Bordioug, Protiviti—Winner
Jon Kessler, Epiq
Justine Wolters, Cloud Life
Mario Espinoza, Illumio
Nithin RameGowda, Skysecure Technologies Pvt Ltd
Security Software Development Company of the Year
Security software development companies with standout AI-powered solutions that integrate with Microsoft Security products, delivering exceptional value and customer experiences while driving industry impact and adoption.
Illumio—Winner
ContraForce
Darktrace
inforcer
Tanium
Security Services Partner of the Year
Security Services partners that excel at integrating Microsoft products with security services, delivering strong results, driving adoption of Microsoft Security solutions, and leveraging advanced AI for innovation, sales, and customer support.
Invoke LLC—Winner
BlueVoyant
Cloud4C
Shanghai Flyingnets
Quorum Cyber
Looking ahead: Stronger together
Congratulations once again to this year’s exceptional winners, and sincere appreciation to everyone who joined us in honoring our outstanding cybersecurity team players. Their unwavering commitment, innovative spirit, and deep expertise drive progress not only within our community but also across the industry as a whole. Together, their efforts empower us to advance our shared mission of creating a safer, more resilient digital world for all. We look forward to building on this momentum and continuing our collaborative journey toward a secure future.
To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.
AI-driven medical image report generation can help medical providers become more efficient and productive.
Current models are difficult to train because reporting practices vary widely among providers.
Universal Report Generation (UniRG) uses reinforcement learning to align model training with real-world radiology practice rather than proxy text-generation objectives.
UniRG has achieved state-of-the-art performance across datasets, metrics, diagnostic tasks, longitudinal settings, and demographic subgroups.
Test results show that reinforcement learning, guided by clinically meaningful reward signals, can substantially improve the reliability and generality of medical vision–language models.
AI can be used to produce clinically meaningful radiology reports using medical images like chest x-rays. Medical image report generation can reduce reporting burden while improving workflow efficiency for healthcare professionals. Beyond the real-world benefits, report generation has also become a critical benchmark for evaluating multimodal reasoning in healthcare AI.
Despite recent advances driven by large vision–language models, current systems still face major limitations in real-world clinical settings. One challenge stems from the wide variation in radiology reporting practices across institutions, departments, and patient populations. A model trained with supervised fine-tuning on one set of data may learn its specific phrasing and conventions instead of more general patterns—a problem known as overfitting. As a result, the model performs well on that data but delivers poor results when evaluated on unseen institutions or external datasets. Moreover, since model training is often aimed at producing text that looks similar to existing reports, some well written but clinically inaccurate reports can slip through.
In this blog, we introduce Universal Report Generation (UniRG) (opens in new tab), a reinforcement learning–based framework for medical imaging report generation. This work is a research prototype intended to advance medical AI research and is not validated for clinical use. UniRG uses reinforcement learning as a unifying mechanism to directly optimize clinically grounded evaluation signals, aligning model training with real-world radiology practice rather than proxy text-generation objectives. Using this framework, we train UniRG-CXR (opens in new tab), a state-of-the-art chest x-ray report generation model at scale, spanning over 560,000 studies, 780,000 images, and 226,000 patients from more than 80 medical institutions.
To our knowledge, this is the first report generation model to achieve consistent state-of-the-art performance across report-level metrics, disease-level diagnostic accuracy, cross-institution generalization, longitudinal report generation, and demographic subgroups. These results demonstrate that reinforcement learning, when guided by clinically meaningful reward signals, can substantially improve both the reliability and generality of medical vision–language models.
Spotlight: Microsoft research newsletter
Microsoft Research Newsletter
Stay connected to the research community at Microsoft.
A unified framework for scaling medical image report generation
UniRG builds state-of-the-art report generation models by combining supervised fine-tuning with reinforcement learning, which optimizes a composite reward that integrates rule-based metrics, model-based semantic metrics, and LLM-based clinical error signals. This approach allows the resulting model UniRG-CXR to learn from diverse data sources, move beyond dataset-specific reporting patterns, and learn representations that generalize across institutions, metrics, and clinical contexts. Notably, UniRG-CXR sets a new state of the art on the authoritative ReXrank leaderboard (opens in new tab), a public leaderboard for chest X-ray image interpretation, as of 01/22/2026, surpassing previous best models by substantial margins (Figure 1).
Figure 1. Overview of UniRG-CXR. (a) Training Data: UniRG-CXR is trained on the training splits of MIMIC-CXR, CheXpert Plus, and ReXGradient-160k, covering diverse institutions and patient demographics. (b) Training and Rewards: Taking input from the current image, clinical context (e.g., indication), and optionally prior studies, UniRG-CXR uses GRPO reinforcement learning to optimize composite rewards that combine rule-based, model-based, and LLM-based metrics. (c) Evaluation: We assess UniRG-CXR on held-out test sets (MIMIC-CXR, CheXpert Plus, ReXGradient), and unseen datasets (IU Xray and proprietary data). Report quality measured using ReXrank metrics and an LLM-based clinical-error metric, while diagnostic ability is evaluated via F1-based disease classification from generated reports. (d) ReXrank Results: UniRG-CXR achieves SOTA performance across four datasets and two generation settings (findings only and findings + impression), showing substantial gains over prior state-of-the-art systems.
Universal improvements across metrics and clinical errors
Rather than excelling on one metric at the expense of others, UniRG-CXR delivers balanced improvements across many different measures of report quality. More importantly, it produces reports with substantially fewer clinically significant errors. This indicates that the model is not just learning how to sound like a radiology report, but is better capturing the underlying clinical facts. Explicitly optimizing for clinical correctness helps the model avoid common failure modes where fluent language masks incorrect or missing findings (Figure 2).
Figure 2. UniRG-CXR achieves state-of-the-art performance, delivering consistent and comprehensive performance gains across metrics. (a) On the ReXrank leaderboard, UniRG-CXR (green) shows robust, universal improvement across all evaluation metrics. (b). Starting from the same SFT checkpoint, RL with our combined reward achieves more balanced gains across metrics and the highest RadCliQ-v1 score compared to RL on single metrics. This ablation study is trained and tested on MIMIC (c). Ablation study on the training dynamics shows RL full (UniRG-CXR) achieves significantly better RadCliQ-v1 score than RL only on BLEU. (d). During training, RL full (UniRG-CXR) shows a steady decrease in clinical errors per report as compared with a fluctuating trajectory without consistent improvement from an ablation run without error awareness (i.e. removing CheXprompt metric optimization). Both (c) and (d) show results on 1024 MIMIC validation set from ablations that are trained on MIMIC. (e). Case studies illustrate that UniRG-CXR can produce error-free reports, unlike MedVersa and MedGemma. (f). UniRG-CXR yields a substantially higher proportion of reports with $\leq 1$ error and fewer with $\geq 4$ errors than prior models.
Strong performance in longitudinal report generation
In clinical practice, radiologists often compare current images with prior exams to determine whether a condition is improving, worsening, or unchanged. UniRG-CXR is able to incorporate this historical information effectively, generating reports that reflect meaningful changes over time. This allows the model to describe new findings, progression, or resolution of disease more accurately, moving closer to how radiologists reason across patient histories rather than treating each exam in isolation (Figure 3).
Figure 3. UniRG-CXR enhances longitudinal report generation. (a). Comparing UniRG-CXR and its non-longitudinal ablation with prior models on longitudinal report generation, we show UniRG-CXR exhibits the best performance and the longitudinal information is beneficial to the performance. (b). UniRG-CXR achieves the best performance across different longitudinal encounter points ranging from the first encounter to the more complex 5th+ encounters, showcasing its improvements are across the board. In comparison, prior models such as GPT-5, GPT-4o and MedGemma are barely surpassing the copy prior report baseline (grey lines). (c). Compared with prior models which barely improve over the copy prior baseline (dashed line), UniRG-CXR significantly and consistently improves performance across different temporal disease change categories including new development, no change, progression and regression (categorized by GPT-5 on ground truth report). Qualitative examples are shown for each category where UniRG-CXR correctly predicts the temporal change based on the input. All results in this figure are on MIMIC test set with prior information where available.
Robust generalization across institutions and populations
UniRG-CXR maintains strong performance even when applied to data from institutions it has never seen before. This suggests that the model is learning general clinical patterns rather than memorizing institution-specific reporting styles. In addition, its performance remains stable across different patient subgroups, including age, gender, and race. This robustness is critical for real-world deployment, where models must perform reliably across diverse populations and healthcare environments (Figure 4).
Figure 4. Generalization and robustness of UniRG-CXR. (a). We evaluate UniRG-CXR in a zero-shot setting on two datasets from previously unseen institutions: IU-Xray and PD (proprietary data). UniRG-CXR consistently outperforms prior models, maintaining substantial performance gains in this challenging setup. (b) and (c) present condition-level F1 scores on MIMIC-CXR and PD and highlight that UniRG-CXR remains the overall top-performing model in condition-level diagnostic accuracy. (d). UniRG-CXR demonstrates stable and robust performance across gender, age, and race subgroups, all of which exceed the performance of the second-best model (the dashed lines).
UniRG is a promising step toward scaling medical imaging report generation
UniRG introduces a reinforcement learning–based framework that rethinks how medical imaging report generation models are trained and evaluated. By directly optimizing clinically grounded reward signals, UniRG-CXR achieves state-of-the-art performance across datasets, metrics, diagnostic tasks, longitudinal settings, and demographic subgroups, addressing longstanding limitations of supervised-only approaches.
Looking ahead, this framework can be extended to additional imaging modalities and clinical tasks, and combined with richer multimodal patient data such as prior imaging, laboratory results, and clinical notes. More broadly, UniRG highlights the promise of reinforcement learning as a core component of next-generation medical foundation models that are robust, generalizable, and clinically aligned.
Version 1.7.0 of WordPress Studio is a major upgrade for anyone building WordPress sites locally, especially developers and power users who like to automate tasks and work from the terminal.
In earlier releases, the Studio CLI focused mainly on creating and managing preview sites.
With version two, it becomes a full-featured command-line companion for much of your Studio workflow, including creating and managing local sites, running WP-CLI in the right context, connecting to WordPress.com, and more.
In this post, we’ll review what’s new and share practical ways to incorporate the Studio CLI into AI-assisted workflows.
For the full command reference and advanced options, see the updated Studio CLI documentation included with this release.
What is a CLI?
A CLI (command-line interface) lets you control tools and applications by typing commands into a terminal, instead of clicking through menus. Developers tend to like CLIs because they’re:
Fast: Spin up, change, or remove environments with a single command
Repeatable: Run the same commands on any machine, or bake them into scripts
Automatable: Let build systems and AI agents run commands for you
Even if you don’t typically work in the terminal, the Studio CLI is still worth paying attention to.
It’s the common “language” automation tools can use to interact with Studio. Once it’s enabled, your editor, scripts, or AI coding assistants can do things like create a new site, run database upgrades, or publish a preview without you having to navigate through multiple screens in the Studio application.
Getting started with the Studio CLI
To begin using the Studio CLI, complete the following steps:
Open the WordPress Studio application on your machine.
From the main menu, open the Settings modal. You can also click the gear icon in the top-right corner of the app.
Enable the Studio CLI option and click Save.
On macOS, you’ll be prompted for your computer password to allow installation.
Once the Studio CLI is enabled, you will have access to a global studio command from your preferred terminal application:
studio <area> <command> [options]
In Studio 1.7.0, the CLI now covers four main areas:
Authentication: Manage your WordPress.com account for features that require it
Preview sites: Create and update WordPress.com hosted preview sites
Local site management: Create, start, stop, configure, and delete Studio-managed local sites
WP-CLI integration: Run WP-CLI commands inside correctly configured Studio environments, without installing WP-CLI yourself
You can see an overview at any time by running studio --help:
Most commands are designed to be run from the root folder of a Studio-managed site.
For quick access, you can open that folder directly in your terminal by clicking the Terminal button on the site’s Overview tab.
Managing local Studio sites
One of the biggest upgrades in Studio CLI v2 is end-to-end local site management from the terminal.
Rather than switching back to the Studio user interface for routine tasks, you can create a site, check its status, start or stop it, and clean it up when you’re finished.
It’s a faster day-to-day workflow, and it also makes automation much easier, whether you’re writing scripts yourself or using an AI agent to do it for you.
At the center of it all is the studio site command. The available options include:
studio site status # Get status of site
studio site create # Create a new site
studio site list # List sites
studio site start # Start site
studio site stop # Stop site(s)
studio site delete # Delete site
studio site set # Configure site settings
Create local sites with a single command
Use studio site create to spin up a new site in your current directory or at a specific path. Here are a few examples of what you can do:
# Create a new site with default options in the current folder
studio site create
# Create a new site with a custom domain and HTTPS
studio site create --https --domain hello.wp.local
# Create a site in a different directory
studio site create --path /path/to/site
The CLI will:
Set up a local WordPress environment.
Start the WordPress server.
Open WP Admin in your browser when it is ready.
You can run this from an empty folder, or from a directory that already contains a WordPress site that is not yet registered within the Studio app.
List, inspect, start, and stop local sites
When you are working with multiple local sites, the `list` and `status` commands make management much easier:
studio site list # Show all local sites known to Studio
studio site status # Status of the site in the current directory
Status output includes:
Whether the site is running
The local URL, for example http://localhost:PORT
Key configuration details such as PHP version and login information
Starting and stopping sites is also straightforward:
studio site start
studio site stop
This works well in scripts that need to start a site, run tests or content operations, and then stop it again.
Delete and configure sites safely
When you are finished with a project, you can remove it from Studio and, if needed, delete all the associated files from your machine with the following commands:
studio site delete # Remove the site from Studio
studio site delete --files # Remove the site and files
For configuration changes, studio site set lets you adjust settings for a specific local site:
studio site set [options]
You can, for example:
Change the PHP or WordPress version.
Update the local domain or port.
Toggle features that affect how the local environment runs.
Tip: Run studio site set --help for the full list of available options.
Authentication from the terminal
Some Studio features, such as creating or updating preview sites, require a logged-in WordPress.com account.
Studio CLI v2 gives you dedicated studio auth commands so you can manage this from the terminal:
studio auth login launches a browser flow and gives you a token to paste back into your terminal to complete the login.
studio auth status tells you whether you are authenticated and which account is active.
studio auth logout disconnects the CLI from your WordPress.com account and clears stored credentials.
If you run a command that needs authentication while logged out, such as studio preview create that we will review next, the CLI will guide you to log in.
Preview sites from the CLI
Preview sites are temporary, shareable environments hosted on WordPress.com that mirror your local Studio site. They are ideal for sharing work with others who do not have a local environment.
The CLI provides a complete set of commands:
studio preview create # Create a preview site
studio preview list # List all your preview sites
studio preview update <host> # Redeploy changes to a preview
studio preview delete <host> # Remove a preview site
Tip: Run studio preview list to see all previews associated with your WordPress.com account, then use the host value from that output with studio preview update or studio preview delete.
Built-in WP-CLI, configured for you
WP-CLI is the official command-line interface for WordPress itself. Studio CLI v2 integrates it directly through a dedicated studio wp command, so you do not need to install or configure WP-CLI on your own:
studio wp [<wp-cli-command>] [<wp-cli-arguments>...]
From your site’s root directory, you can run common WP-CLI tasks like:
studio wp core version shows the WordPress version for the current site.
studio wp plugin list lists installed plugins (and their status).
studio wp core update-db runs any required database updates after a WordPress update.
Studio sets the environment variables, paths, and credentials for you, so these commands run against the correct database and files with no extra setup.
Using Studio CLI with AI coding tools
One of the biggest advantages of Studio CLI v2 is how naturally it fits into AI-assisted development workflows, especially with tools like Claude Code and Cursor.
These agents read the code in your local project (including themes and plugins) and run commands in your environment, which makes it possible to offload much of the repetitive work. For example, they can:
Use studio site commands to create, start, stop, and manage local environments.
Run studio wp for diagnostics, database tasks, and content management.
Create and update WordPress.com preview sites for review without leaving your editor.
Provide context
The AI tool you’re using may not automatically understand WordPress Studio or the Studio CLI. To get useful results, start by giving the AI agent a bit of context about what it’s looking at and what tools it can use.
For example, imagine you’ve opened a local Studio site folder in your terminal.
Begin by telling the AI agent what this directory is, and that it can run the Studio CLI.
In this example, we’ll use Claude Code and explicitly note that it can invoke the CLI via studio.
“This is the folder for a WordPress Studio site. You have access to the Studio CLI, which can be invoked by running studio. Start by exploring the available options.”
From there, you should get a response that looks like this:
With a simple prompt, the AI now has a solid understanding of the Studio CLI. This example was generated using Opus 4.5.
Automate environment setup
Once the AI understands what Studio can do, you can start handing off routine setup tasks. For instance, you might tell your agent:
“Set up a new local WordPress site using Studio with the name “Nick’s Site””
Behind the scenes, it may run something like:
studio site create --path "../nicks-site" --name "Nick's Site" --skip-browser
Here’s an example of the output from Claude Code, again using Opus 4.5.
Debugging and verification with WP-CLI
Studio also makes it easy to troubleshoot issues using WP-CLI — especially when you’re staring at an error and don’t want to manually hunt down the cause.
You might say:
“Use the Studio CLI to run WP-CLI checks and figure out why this site is failing, then propose fixes.”
From there, the agent can:
Run studio wp commands (for example, plugin list, theme list, or core update-db) to collect diagnostics.
Suggest (or apply) code and configuration changes based on what it finds.
Re-run the same WP-CLI checks to confirm the issue is resolved.
If you haven’t already, check out this great overview of WP-CLI to get a sense of what it can do.
Creating preview sites
Preview sites are one of the most popular features in WordPress Studio, but creating them and keeping them updated can feel a bit tedious if you’re doing it through the Studio user interface.
The CLI streamlines the workflow, and it becomes even easier when you pair it with an AI agent.
When you’re ready to share your work with a client or teammate, you can simply ask your AI to create a preview site:
“Can you spin up a preview site for me?”
If you’re not already authenticated, the agent will prompt you to log in, then it will create the preview and return the URL. The output should look something like this:
As you continue working locally, you can periodically ask the agent to update the preview site.
If you’re also using the AI to help build the site, theme, or plugin, you can even add a rule like: after any major change, update the preview site automatically so your shared link stays current.
Best practices when using AI with Studio CLI
AI agents can be incredibly effective copilots when you pair them with the Studio CLI. They can speed up setup, troubleshooting, preview deployments, and run real commands against your environment.
That said, a little structure up front helps you get the benefits while avoiding unpleasant surprises.
Work from the Studio site root (or use `–path`). This ensures commands run against the project you actually intend, especially if you have multiple sites on your machine.
Set clear boundaries in your prompts. For example: “Do not delete sites,” “Only run read-only studio wp commands,” or “Ask before running database migrations.”
Double-check destructive operations. For commands like studio site delete and studio preview delete, have the agent show you the exact commands it plans to run before it executes anything.
Used thoughtfully, AI plus Studio CLI can remove much of the repetitive setup, testing, and deployment friction, so you can focus more on designing and building great WordPress experiences.
Start building with Studio CLI
Studio CLI v2 makes WordPress Studio more scriptable and automation-friendly for everyday development, whether you’re running commands yourself or working with an AI agent.
If you want to go further, the Studio CLI documentation walks through everything you can do and how to fit it into your workflow.
If you haven’t tried WordPress Studio yet, or it’s been a while, this is a great time to jump in. Download Studio, spin up a site, and take the updated CLI for a quick test drive.
Log in
Agentic Vision, a new capability introduced in Gemini 3 Flash, converts image understanding from a static act into an agentic process
