What to look for in AI development environments

The question “Which AI environment codes best?” is losing value. GitHub Copilot, Google Antigravity, JetBrains Air, Kiro, Zed, and Zenflow can put capable coding models behind a developer prompt. The harder question is how much control a team can apply while those models plan, edit, test, and sometimes operate autonomously.

The scale of the tooling shows the shift. GitHub Copilot supports about two dozen AI models, including models from OpenAI, Anthropic, and Google. One particular Visual Studio Code installation exposed 346 tools to Copilot agents through default integrations, Model Context Protocol (MCP) servers, and plug-ins. That figure describes one installation rather than a standard Copilot configuration.

Teams therefore have to evaluate autonomy, context, permissions, workflow structure, isolation, and verification. A small code change may need little process, while a broad feature may require explicit requirements and repeated verification. An environment that supports both gives teams room to match controls to the work.

The AI coding decision has moved beyond code generation

Coding assistance moved from word completion to line completion, function completion, and program generation over roughly a decade. Agentic systems go further. An agent can inspect an existing codebase, propose changes, edit files, compile the result, run tests, react to failures, and iterate.

That shifts some developer work toward directing and checking machine-generated changes. The developer decides what context an agent receives, how independently it may operate, which tools it can invoke, and what evidence is required before accepting its output.

GitHub Copilot illustrates this broader scope. First offered as a plug-in to Visual Studio Code in 2021, Copilot now operates in VS Code, Visual Studio, Vim, Neovim, the JetBrains suite of IDEs, the command line through the GitHub Copilot CLI and a GitHub CLI extension, and GitHub itself.

Visual Studio Code can also add models beyond those included by default with a Copilot subscription. Options include Foundry Local via AI Toolkit, GitHub Models via AI Toolkit, Microsoft Foundry via AI Toolkit, and local models through Ollama. Local Ollama models do not count against a Copilot plan, although they consume local GPU or unified memory. These capabilities sit within the Microsoft and GitHub ecosystem, whose vendors benefit commercially from wider adoption of their development tooling.

The named environments overlap in some model families. Model access is one part of the decision. The rules governing how a model works inside an environment are another.

IDEs are becoming orchestration environments

An AI agent is a system that can inspect its working environment, select and execute actions, then adjust its plan as new information appears. In development, that can mean breaking a request into steps, reading repository files, modifying code, invoking tools, running tests, and responding to results.

The development environment becomes an orchestration layer: the place where models, tools, context, permissions, and workflows are coordinated.

GitHub Copilot exposes three default operating modes. Plan researches a problem and outlines a multi-step approach. Ask supports conversation without changing files. Agent can edit files in the workspace. Custom modes can extend those choices through plug-ins or user configuration; the installation earlier contained 16 custom modes.

Copilot agents also have nine categories of default tools, with potentially many tools in each category. MCP servers and plug-ins can add more. Some agent tasks can run for hours with only a few permission requests.

Google Antigravity takes a different approach. Google introduced the original Google Antigravity in November 2025 as an agentic development platform built from the VS Code “Code – OSS” IDE used internally by Google. Google’s own software mono-repository requires specialized infrastructure, including its internal Piper version-control tool rather than Git.

On May 19, 2026, Antigravity became the basis of a larger ecosystem. Google Antigravity 2.0 is a standalone, agent-focused desktop application evolved from the Agent Manager. Google Antigravity IDE is a separate IDE download. Google Antigravity CLI lets developers invoke, monitor, and interact with agents from a terminal, while the Google Antigravity SDK supports custom-agent development. Google has a commercial interest in adoption of this ecosystem and its Gemini models.

Antigravity lets developers alter agent behavior through workflow controls. Its “+” control adds media, mentions, actions, and, in Antigravity 2.0, browser access. The browser subagent can click, scroll, type, inspect console logs, capture the DOM, take screenshots, and record video, with native Chrome DevTools MCP integration.

Slash commands change how independently an agent operates. /goal tells the agent to continue until a task is complete without requesting intermediate input. /grill-me tells it to ask questions before implementation, while /schedule creates one-time or recurring Scheduled Tasks. Workspace-level and global skills use a SKILL.md file with YAML frontmatter, plus optional scripts, examples, and resources; the YAML description helps an agent recognize when a skill applies.

Model choice sits inside these controls. Google Gemini 3.6 Flash is Antigravity’s default model and can operate at low, medium, and high effort. Google describes it as its strongest agentic and coding model yet and says it is faster than other frontier models on Antigravity. Those performance claims come from Google, which supplies Gemini and benefits from its use. Antigravity also supports Gemini 3.5 at low, medium, and high effort; Gemini 3.1 Pro at two effort levels; Anthropic’s Claude Sonnet 4.6 and Opus 4.6 with thinking enabled; and GPT-OSS-120B at medium effort. Google recommends selecting the lowest effort sufficient for the task to reduce token consumption.

JetBrains Air makes execution boundaries part of its control model. A task can run in a local workspace, a Git worktree, an isolated Docker container, or, once configured, in the cloud from a local machine or browser. It supports four agent providers: OpenAI Codex, Anthropic Claude, Google Gemini, and JetBrains’ own Junie. Developers can provide subscriptions or API keys for OpenAI, Anthropic, and Google or use JetBrains hosting through a subscription. JetBrains has a commercial interest in adoption of Air and its hosting service.

Air provides four permission levels ranging from plan first to full access. Developers can select an agent when starting a task, switch models within that agent, set effort for some agents, and supply context from files, folders, documentation, Git branches, and other sources. In one test, Claude Sonnet 4.6 (1M context window) ran at high effort with Ask permissions to optimize a C++ pi calculator locally.

These designs make the core question concrete: who decides what an agent may see and do, and when must a human intervene?

More autonomy increases the value of explicit structure

Autonomy raises a second question: what information should govern an agent’s decisions throughout a task?

Kiro addresses this through specifications and persistent steering. Developed by “a small, opinionated team within AWS,” Kiro is offered as an IDE based on Code OSS and as Kiro CLI (kiro-cli). The CLI currently has a planner agent and agent steering but does not handle specs. Kiro IDE (kiro) explicitly supports both vibe coding and specification-driven development (SDD). AWS has a commercial interest in Kiro’s adoption.

EARS requirements use the form WHEN [condition/event] THE SYSTEM SHALL [expected behavior]. This makes requirements explicit enough to test. Kiro can generate property-based tests (PBT) from EARS-formatted requirements. PBT checks properties across generated inputs rather than relying only on manually selected examples.

Steering provides another control. Kiro can generate product.md for purpose, target users, key features, and business objectives; tech.md for frameworks, libraries, development tools, and technical constraints; and structure.md for file organization, naming conventions, import patterns, and architectural decisions. These files preserve workspace information that can guide later agent interactions.

Kiro can also import and revise specifications and generate a specification after a vibe-coding session. It supports more than a dozen chat context providers, including #codebase, #spec, and #code, as well as skills following the open Agent Skills standard and MCP servers.

Its model configuration adds another dimension. On the free plan described, Kiro IDE supported Anthropic Claude Sonnet 4.5 and Sonnet 4.0 plus five open-weight models, with automatic model selection available. Its documentation also listed OpenAI’s GPT-5.6 Sol, Terra, and Luna; Claude Opus 4.5, 4.6, 4.7, 4.8, and 5.0; and Claude Haiku 4.5, activatable with a Pro ($20/month) or better plan.

These mechanisms solve different problems. Permissions constrain actions, while context determines what information is available for a request. Steering preserves project conventions; requirements define intended behavior; isolation constrains where execution and changes occur. As an agent makes more decisions between human checkpoints, each control can shape the resulting work.

Maximum rigor carries an effort cost

Vibe coding sits near one end of the workflow range. A developer directs an AI largely through prompts and gives the model substantial implementation discretion. That can keep quick prototypes lightweight, but it gives the developer fewer explicit requirements against which to check the implementation.

SDD creates a different control surface. A specification records requirements before the agent makes a sequence of implementation decisions. The developer then has an explicit basis for checking whether those decisions remain aligned with intended behavior.

Creating and maintaining that specification takes work. A narrow change with clear intent may not justify requirements, architecture documentation, an implementation plan, and every associated workflow step. This leaves a middle range between loose prompting and a full SDD process.

Several development approaches address parts of that range. Behavior-driven development organizes work around expected behavior. “Facts first,” a variation on test-driven development, uses facts defined as executable invariants that a machine can test. Intent-driven software development (IDSD) develops the older practice of intent, context, and expectations (ICE). These approaches offer ways to anchor work without establishing one as broadly superior.

Zenflow makes workflow depth an explicit choice. Developed by the Zencoder team, Zenflow coordinates coding agents through SDD-oriented workflows and describes itself as an orchestration layer. Zencoder plug-ins work in Zenflow, while Zenflow features such as guided workflows have also been added to Zencoder. Zencoder benefits commercially from adoption of both products, so these descriptions are vendor claims about its own tooling.

Andrew Filev, CEO of Zencoder, said his team of experienced engineers had used Zenflow for their own product development for over a year when questioned about its readiness for production code. Filev leads the company behind Zenflow and benefits commercially from confidence in the product.

Zenflow offers four standard workflows:

Teams can also define custom workflows to fit their standards.

The design separates agent choice from workflow choice. The coding agent can be Zencoder, Claude Code, Codex, or Gemini. Zencoder itself is also the company name and the name of its AI IDE plug-in; the Zencoder plug-in offers about nine models.

Kiro provides another example of variable workflow structure through its support for vibe coding and SDD. These examples do not establish universal workflow categories. They show two vendor approaches that give developers more than one level of process around agent work.

Verification is becoming part of the development environment

Workflow control has limited value unless teams can check what an agent produced. Verification therefore belongs in any evaluation of agent orchestration.

Kiro’s property-based testing is one example. EARS requirements can feed PBT generation, connecting expected behavior to executable checks. This turns specification data into testing input.

Zed takes a review-centered approach. The team behind Zed previously created Atom, the hackable text editor; Electron, the JavaScript desktop-app platform; and Tree-sitter, a syntax-parsing framework now widely used for code analysis and syntax highlighting. Atom has been discontinued, while Electron and Tree-sitter remain active.

Zed itself is written in Rust and emphasizes speed, with language-model access largely through a “bring your own key” approach; Zed-hosted models require a subscription. Zed has a commercial interest in use of its paid hosted-model service. Version v1.13.2 included a broader evolution that had recently added Anthropic’s Claude Opus 5, OpenAI’s GPT-5.6, llama.cpp as a model provider, and automatic agent context compaction, alongside established capabilities including skills, collaboration, and remote development.

In a C++ π-calculation test, Zed’s code-review skill first evaluated the program and proposed changes. The developer reviewed them before authorizing implementation and testing with Claude Sonnet 4.6. The key control was a human checkpoint between machine recommendation and machine modification.

Zenflow uses a different verification pattern. Zencoder says its workflows run automated tests and cross-agent code review, with failed tests triggering automatic fixes. It also says tasks execute in isolated Git worktrees and multiple tasks can run in parallel in isolated environments. Projects are divided into tasks, subtasks, and chats, with task status available through Kanban boards or stacked list views. These are claims from the vendor selling the product.

For an executive evaluating these environments, generation quality is only one part of the decision. The workflow must also produce evidence before code moves forward: compilation results, automated tests, property checks, review checkpoints, failure handling, and execution isolation.

Usage accounting can make these orchestration choices economic as well as technical. Effective June 1, 2026, GitHub changed Copilot usage accounting from Premium Request Units to token consumption, while code completions and next edit suggestions are exempt from token limits. GitHub controls Copilot’s commercial terms, so this accounting rule should be evaluated as vendor policy rather than an independent measure of engineering efficiency.

Google’s recommendation to run Gemini models at the lowest effort level that can successfully complete the task reflects the same practical concern inside Antigravity: model effort can affect token consumption. Google supplies the models and platform and therefore has a commercial interest in how customers use them.

Main highlights

Evaluate orchestration: Model choice is becoming less differentiating as AI development environments gain agentic capabilities. Leaders should compare how platforms manage autonomy, context, permissions, tools, workflows, and execution boundaries.
Match autonomy with explicit structure: As agents make more decisions independently, teams need stronger controls over requirements, project context, permissions, and isolation. Choose environments that can preserve these constraints throughout an agent’s work.
Scale process to the task: Full specification-driven development can improve rigor but adds effort that may not make sense for every change. Leaders should favor environments that support lightweight workflows for narrow tasks and more structured processes for complex or high-risk work.
Make verification part of the workflow: Agent-generated code still needs evidence that it works as intended. Prioritize environments that integrate testing, review checkpoints, failure handling, and isolated execution rather than treating verification as a separate final step.