DEV Community: Karl Wirth

Best Markdown Editors for Developers

Karl Wirth — Tue, 02 Jun 2026 04:00:00 +0000

Most developers settle for whatever markdown support their IDE provides. Open a file, see some syntax highlighting, maybe a preview pane. Good enough, right?

It's fine until it isn't. Until you're wrestling with a complex table that doesn't render correctly. Until you're trying to update documentation that's drifted from your actual code. Until you're re-initializing context between your terminal, your editor, and your AI assistant for the fifth time today.

This guide is for developers who want better. Not just better markdown editing, but better integration between your docs and your code, between your writing and your AI workflows. For a broader comparison across all use cases, see our complete guide to markdown editors.

What is the Best Markdown Editor for Developers?

For developers, the best markdown editor depends on what you're editing. For inline code documentation, stay in your IDE. For project planning and documentation, you need real WYSIWYG text, table, image, and diagram editing. For specs and design docs that drive AI code generation, you need something that maintains context across your entire project.

How Do Developers Edit Markdown Files?

Most developers edit markdown in one of four ways:

Option 1: Raw editing in IDE. You open the .md file in VS Code or whatever you use. Syntax highlighting shows you the structure. Maybe you toggle a preview pane. This works for quick edits but becomes painful for anything involving tables, diagrams, or complex formatting.

Option 2: Dedicated markdown app.Typora, Obsidian, or similar. Better editing experience, but now you're context-switching between your code editor and your docs editor. Copy-pasting paths, losing mental context, duplicating effort.

Option 3: Git web interface. Edit the README directly on GitHub. Convenient for small changes. Terrible for anything substantial.

Option 4: Integrated environment. Tools like Nimbalyst that treat markdown as a first-class concern alongside code. Newer approach, fewer options, but addresses the fundamental problem of fragmented context.

The Problems with Editing Workflows

Native mode makes it hard to think.You wouldn't write your code in a notes app, so why write your words in a coding app. Words deserve a first-class environment where you aren't distracted but have a clean, WYSIWYG editor.

Tables are awful in raw markdown. Keeping columns aligned as you edit is tedious. Adding a column means reformatting every row. Most developers avoid tables entirely because of this, which hurts documentation quality.

Diagrams are difficult. Similar problems to tables. Its hard to edit it in raw markdown and you have to flip between your edits and a preview mode

Images require too much friction. Take screenshot, save to repo, write the markdown path, hope you got the relative path right. Then do it again when the screenshot needs updating.

Preview is never quite right. Your local preview might render differently than GitHub. Dark mode handling varies. Mermaid diagrams might work in one context and not another.

AI Edits don't show up in most WYSIWYG editors. It is essential to understand what AI changed and review, approve, and reject it. Often, you must choose between working in WYSIWYG mode and seeing diffs.

The best workflow minimizes these friction points. Dedicated markdown editors with WYSIWYG table editing solve the first problem. Drag-and-drop image handling solves the second. Native diagram support solves the third.

Git Integration and Version Control

Your markdown editor must play well with git.

That means:

Plain markdown files. No proprietary formats, no database backends, no sync services that create merge conflicts.
Clean diffs. Your markdown output shouldn't include formatting artifacts that change between edits without meaningful content changes.
Local file access. The editor needs to work with files in your git repo, not copies in some app-specific location.

This rules out tools that store documents in their own format or require cloud sync. Obsidian works here if you configure it correctly. Typora works. Notion does not. Google Docs does not.

Syntax Highlighting and Code Blocks

Developers need good code block support. This means:

Syntax highlighting for your languages. Not just the popular ones. Your edge-case language or config format needs to render correctly.
Easy language specification. Typing the language tag should be frictionless, ideally with autocomplete.
Copy-paste preservation. Pasting code from your editor into a code block shouldn't mangle indentation.

Most markdown editors handle this adequately. What differs is the experience of editing code blocks. In raw markdown, you're managing the triple backticks manually. In WYSIWYG editors, code blocks behave more like IDE editor windows, which feels more natural.

Extension and Plugin Ecosystems

VS Code has the largest extension ecosystem. You can find markdown extensions for almost anything. The question is whether bolting on features creates a coherent experience or a Frankenstein's monster.

Obsidian's plugin system is extensive for note-taking workflows but weaker for development-specific needs. We compare Obsidian with Claude Code against Nimbalyst in a separate deep dive.

Typora is intentionally minimal. No plugin system. What you see is what you get.

For developers, the relevant extensions fall into categories:

Preview enhancements: Better rendering, GitHub-flavored markdown support, diagram rendering.
Editing helpers: Table formatters, link validators, paste image handlers.
AI integration: Copilot, Claude, various autocomplete tools.

The extension approach works until you need features to interact with each other. Getting your AI assistant to understand your diagrams, your docs, and your code context simultaneously is hard when each feature is a separate bolted-on extension.

Performance Considerations

Performance matters when you're working with large documents or switching between files frequently.

Startup time: How fast does the editor open? If you're using it throughout the day, slow startup adds up.
Large file handling: Some editors struggle with markdown files over a few hundred kilobytes. Technical documentation can get big.
Preview rendering: Real-time preview of complex documents, especially those with many images or diagrams, can lag in some tools.

Desktop editors generally outperform web-based ones. Electron-based editors (VS Code, Obsidian) fall in between. Native apps (Typora) tend to be fastest.

Comparison Matrix

Capability	VS Code	Obsidian	Typora	Nimbalyst
Syntax highlighting	Excellent	Good	Good	Good
Table editing	Manual	Plugin	Excellent	Excellent
Image support	Extension	Plugin	Drag-drop	Drag-drop, paste
Code block experience	Native	Good	Good	Good
Git integration	Native	Good	Good	Good
Diagram support	Extension	Plugin	Limited	Native
AI integration	Extensions	Plugin	None	Claude Code native
Red/Green AI Diffs	Not WYSIWYG	No	No	Yes
Performance	Good	Good	Excellent	Excellent

The AI Workflow Problem

Here's what's changed for developers in 2025: AI coding assistants are generating substantial amounts of code from natural language specs.

The quality of that generated code depends on the context you provide. Your PRD, your technical design doc, your architecture diagrams, your specifications, your existing code, these all feed into what the AI produces.

Most developers are currently managing this context manually, jumping between the command line and their IDE and their markdown editor. This is fragmented and error-prone. Context gets lost. Documents drift from reality. The feedback loop is slow.

A better workflow keeps docs, diagrams, and AI sessions in one place. When you update a spec, the AI has access to the update. When the AI generates code, you can review the changes inline. When you accept changes, the documentation can stay synchronized.

This is the direction that matters for developer markdown editing in 2025. Not just rendering markdown correctly, but treating markdown as part of an integrated development workflow -- what we call an IDE for words, diagrams, and mockups. Explore the full set of Nimbalyst features to see this in action.

Practical Recommendations

If you're doing quick edits to existing docs: Stay in VS Code. Add the Markdown Preview Enhanced extension if you haven't.

If you're writing substantial documentation from scratch: Use Nimbalyst and iterate together with AI for the cleanest editing experience, then commit to your repo.

If you're building a personal knowledge base: Obsidian with developer-focused plugins works well.

If you're working onfeatures where specs drive AI code generation: Look at tools that integrate markdown editing with AI workflows natively. Nimbalyst is built for this use case, keeping your docs, diagrams, mockups, and Claude Code sessions in one local workspace ... integrated.

The best markdown editor for developers isn't necessarily the one with the most features. It's the one that reduces friction in your actual workflow. Consider what you're really trying to accomplish, then pick the tool that makes that easier.

Frequently Asked Questions

Should I use VS Code for markdown editing?

Yes, for small edits and inline documentation. VS Code is adequate and you're already there. For substantial documentation work, especially involving tables or diagrams, dedicated tools provide a better experience.

What markdown editor works best with GitHub?

Any editor that produces clean GitHub-flavored markdown works with GitHub. The important thing is avoiding tools that add proprietary formatting or store files in non-standard locations.

How do I edit markdown tables without going insane?

Use an editor with WYSIWYG table editing. Typora handles this well. So does Nimbalyst. In VS Code, there are table formatter extensions, but they're still more manual than visual editors.

Can I use AI assistants with my markdown editor?

Yes, through extensions in VS Code and plugins in Obsidian. The limitation is that these integrations often don't maintain context across your full document set. Tools built with AI integration in mind, like Nimbalyst with its native Claude Code support, provide more cohesive workflows including red/green AI diffs that you approve and support for / commands and skills.

What's the best markdown editor for technical writing?

For pure writing quality, Typora. For linking and organization, Obsidian. For integration with code and AI workflows, Nimbalyst. For staying in an IDE, VS Code with extensions.

Best Claude Code GUI in 2026: 5 Tools Compared

Karl Wirth — Mon, 01 Jun 2026 15:09:20 +0000

The best Claude Code GUI in 2026 is the one that fits how you actually work with the agent: one chat at a time or six sessions in parallel, terminal-style or full visual workspace. This guide compares the five main Claude Code GUI options side by side, with honest assessments of what each does well and where each falls short.

Best Claude Code GUI: Quick Answer

If you only want the verdict:

Best Claude Code GUI overall: Nimbalyst. Visual workspace with parallel sessions, kanban, inline diff review, and an iOS app.
Best official Claude Code GUI: Claude Code Desktop. Anthropic-built, included with your Claude subscription, and the clearest default if you want the official surface.
Best open-source Claude Code GUI: Opcode. MIT-licensed Tauri app, single-session chat shell.
Best multi-provider Claude Code interface: CodePilot. Claude alongside OpenAI and local models.
Best browser-based Claude Code UI: CloudCLI. Web and mobile access for headless and remote workflows.

Claude Code GUI Comparison Table

Feature	Opcode	Claude Code Desktop	CodePilot	CloudCLI	Nimbalyst
Chat interface	Clean chat UI	Basic chat UI	Multi-provider chat	Web-based chat	Integrated workspace chat
Session management	Single per window	Single session	Single session	Multi-agent	Kanban board, search, resume
Diff review	Built-in diff viewer	Basic diffs	Basic diffs	Basic diffs	Inline red/green, per-file
Parallel sessions	No	No	No	Yes	6+ with unified status
Git worktree isolation	No	No	No	No	Optional one-click per session
Visual editors	No	No	No	No	7+ editors
Mobile app	No	No	No	Web access	iOS app
Multi-engine	Claude only	Claude only	Multi-provider	Multi-agent	Claude Code + Codex
Open source	Yes (MIT)	No	No	Partial (core UI)	Yes (MIT)
Price	Free	Claude subscription	Paid tiers	Free	Free for individuals

Full reviews of each Claude Code GUI follow below.

Why Use a GUI for Claude Code?

Claude Code is one of the most capable AI coding agents available. It is also a terminal application. For quick tasks, that is fine. For sustained development like managing multiple sessions, reviewing 30-file refactors, or planning alongside execution, the terminal becomes a bottleneck.

The terminal is not the problem. The workflow around it is.

Session sprawl. Power users run multiple Claude Code sessions in parallel -- a refactor here, a feature there, a bug fix in another terminal tab. Keeping track of what each session is doing, which ones need input, and what changed across all of them is manual bookkeeping.

Diff review at scale. Reading diffs in the terminal works for small changes. It does not work for a 40-file migration. You need file-by-file navigation, inline context, and the ability to accept or reject individual changes.

Context switching. Developers plan, then build, then review. In a terminal-only workflow, planning happens in one app, execution in the terminal, and review in a third tool. That is three context switches per cycle.

A good Claude Code desktop app reduces all three friction points.

The Tools

Opcode (formerly Claudia)

Opcode started as Claudia and was renamed in mid-2025. It has roughly 21,000 GitHub stars, making it the most popular open-source Claude Code GUI by community size.

Built with Tauri 2, Opcode provides a clean chat interface for Claude Code conversations. You get a message input, scrolling transcript, file tree, and built-in diff viewer. It runs on macOS and Linux.

Strengths:

Zero-setup simplicity. Open a folder, start chatting.
Familiar chat UI paradigm -- if you have used ChatGPT or Claude.ai, you already know the interaction model.
Free and open source.
Large community with existing issues and discussions.

Limitations:

Single session per window. No unified view across multiple agents.
No visual planning tools, git worktree isolation, or mobile access.
Claude Code only -- no support for Codex or other agent engines.
macOS and Linux only. No Windows support.

Best for: Developers who run one Claude Code session at a time and want a straightforward graphical shell around the CLI.

Claude Code Desktop (Official)

Anthropic added a Code tab to the Claude Desktop app, giving Claude Code an official visual interface. It runs the same underlying CLI engine with a native desktop UI.

Strengths:

Official Anthropic product. Guaranteed compatibility with Claude Code updates.
Included with your existing Claude subscription at no extra cost.
Tight integration with the broader Claude Desktop experience.

Limitations:

Focused feature set. Good for the core official workflow, not a broad multi-session workspace.
No multi-session management, visual editors, or mobile companion.
Limited customization and extension support.

Best for: Users already paying for Claude who want an official, no-fuss Claude Code visual interface without installing third-party tools.

CodePilot

CodePilot is a desktop client that positions itself as a multi-provider interface for AI coding agents. It supports Claude Code alongside other providers, with MCP extension support and custom skills.

Strengths:

Multi-provider support. Connect to Claude, OpenAI, and local models from one interface.
MCP extensions for adding custom capabilities.
Custom skills for repeatable workflows.
Cross-platform (macOS, Windows, Linux).

Limitations:

Focused on the chat interaction layer rather than the broader development workflow.
No visual planning tools or session orchestration features.
Paid tiers for advanced features.

Best for: Developers who work with multiple AI providers and want a single desktop client that connects to all of them.

CloudCLI (Claude Code UI)

CloudCLI is an open-source project that provides a web and mobile interface for multiple CLI agents, including Claude Code, Cursor CLI, Codex, and Gemini CLI. It can run locally or as a remote server.

Strengths:

Web-based, so it works from any device with a browser.
Multi-agent support -- not just Claude Code.
Open source with local or remote deployment options.
Good for headless server or remote development workflows.

Limitations:

Web UI rather than a native desktop experience.
Thinner feature set compared to dedicated desktop tools.
Less polished than purpose-built Claude Code GUIs.

Best for: Developers who need browser-based access to multiple CLI agents, especially for remote or headless server workflows.

Nimbalyst

Nimbalyst takes a fundamentally different approach. Instead of wrapping the Claude Code CLI in a chat interface, it provides a full visual workspace where Claude Code and OpenAI Codex are execution engines within a larger development environment.

The application ships with 7+ visual editors (WYSIWYG markdown, Excalidraw diagrams, UI mockup generator, data model designer, code editor, spreadsheets, and more), a session kanban board for managing multiple parallel agents, inline red/green diff review, optional one-click git worktree isolation for any session, a task tracker, and an iOS companion app.

Free for individuals. Desktop app on Mac, Windows, and Linux.

Strengths:

Multi-session orchestration. Run 6+ parallel agents with a unified kanban view of all active work.
Optional git worktree isolation. Spin up any session in its own branch and working copy with one click. Worktrees are opt-in, so quick edits stay simple, while parallel agents stay isolated when you want them to be.
Visual planning tools built in. Write specs, sketch architecture, generate mockups, and design data models in the same app where your agents run.
Inline diff review built for large changes. File-by-file navigation with accept/reject per change.
iOS app for monitoring sessions, reviewing diffs, and responding to agent questions from mobile.
Extension SDK for building custom editors and tools.
Weekly releases with active development.

Limitations:

Richer feature set means a slightly steeper initial learning curve than a simple chat wrapper.
The full workspace approach may be more than needed if you only run one session at a time.

Best for: Developers and teams who run multiple parallel sessions, plan alongside execution, and need structured review workflows. PMs and technical leads who want visual planning tools alongside AI agent orchestration.

Detailed Claude Code GUI Comparison

The full feature matrix across all five Claude Code GUI tools:

Feature	Opcode	Claude Code Desktop	CodePilot	CloudCLI	Nimbalyst
Chat interface	Clean chat UI	Basic chat UI	Multi-provider chat	Web-based chat	Integrated workspace chat
Session management	Single per window	Single session	Single session	Multi-agent	Kanban board, search, resume
Diff review	Built-in diff viewer	Basic diffs	Basic diffs	Basic diffs	Inline red/green, per-file
Parallel sessions	No	No	No	Yes	6+ with unified status
Git worktree isolation	No	No	No	No	Optional one-click per session
Visual editors	No	No	No	No	7+ editors
Mobile app	No	No	No	Web access	iOS app
Multi-engine	Claude only	Claude only	Multi-provider	Multi-agent	Claude Code + Codex
Task tracker	No	No	No	No	Built-in
Extensions	Plugins	No	MCP extensions	No	Extension SDK
Open source	Yes (MIT)	No	No	Partial (core UI)	Yes (MIT), github.com/Nimbalyst/nimbalyst
Price	Free	Claude subscription	Paid tiers	Free	Free for individuals

Which One Should You Pick?

You want the simplest possible Claude Code GUI: Opcode. Open a folder, chat with Claude Code, review diffs. Nothing more.

You want the official option: Claude Code Desktop. Ships from Anthropic, stays current with API changes, requires no additional setup.

You work with multiple AI providers: CodePilot. One client for Claude, OpenAI, and local models.

You need browser-based or remote access: CloudCLI. Runs in any browser, supports multiple CLI agents.

You run multiple sessions, plan visually, or need structured review: Nimbalyst. The only option built as a full visual workspace rather than a chat wrapper. If your workflow involves parallel agents, visual planning, or mobile access, nothing else covers the same ground. See the full Nimbalyst feature set.

The Claude Code GUI space has matured. There is a real option for every workflow. The question is not whether you need a GUI -- it is whether you need a better terminal or a better workspace.

Frequently Asked Questions

What is the best Claude Code GUI in 2026?

The best Claude Code GUI in 2026 is Nimbalyst for most workflows. It is a full visual workspace with parallel session management on a kanban board, optional one-click git worktree isolation per session, inline red and green diff review, seven visual editors, and an iOS companion app. Opcode is the best simple Claude Code GUI for single-session chat, and Claude Code Desktop is the best official option for users already paying for a Claude subscription.

Is there an official Claude Code GUI?

Yes. Anthropic ships official Claude Code GUI surfaces, including Claude Code Desktop in the Claude Desktop app. It is the default official option in this comparison and is included with Claude subscriptions. For multi-session work, structured review, or visual planning, third-party Claude Code GUIs like Nimbalyst do more.

What is the best free Claude Code GUI?

Three of the five Claude Code GUIs in this guide are free. Opcode is free and open source for single-session chat. CloudCLI is free with a paid hosted option. Nimbalyst is free for individuals and open source, with the broadest feature set of the free Claude Code GUI options.

What is the best open-source Claude Code GUI?

Two open-source Claude Code GUIs lead the field. Opcode is MIT-licensed and focused on single-session chat. Nimbalyst's desktop and iOS apps are MIT licensed, with full source on GitHub. Pick Opcode for a minimal Tauri chat shell. Pick Nimbalyst if you want the open-source code behind a full visual workspace.

Can I use a Claude Code GUI for parallel sessions?

Only some Claude Code GUI tools support parallel sessions well. Opcode is primarily single-session. Claude Code Desktop focuses on the core official workflow rather than a dedicated session board. CodePilot is more chat-oriented than orchestration-oriented. CloudCLI and Nimbalyst run multiple agent sessions in parallel. Nimbalyst is the only Claude Code GUI here that combines parallel sessions with one-click git worktree isolation, a kanban board, and per-session file traceability.

Is there a Claude Code GUI for Linux or Windows?

Most Claude Code GUI tools are macOS-first. Opcode runs on macOS and Linux only, with no Windows build. Claude Code Desktop runs wherever the Claude Desktop app does. CodePilot and Nimbalyst run on macOS, Windows, and Linux. CloudCLI runs in any browser, so it works on every operating system.

What is the best GUI for Claude Code if I work solo?

For a solo developer running one session at a time, Opcode is the lightest Claude Code GUI option. It is MIT-licensed, free, and provides a clean single-window chat interface with built-in diff review. If you sometimes spin up a second session for a side investigation, Nimbalyst handles solo and parallel workflows in the same app without locking you into either pattern.

Is there a free GUI for Claude Code?

Yes. Three of the five Claude Code GUI options in this guide are free to use. Opcode is free and open source. CloudCLI is free with an optional paid hosted tier. Nimbalyst is free for individuals and is the broadest free Claude Code GUI on this list, with parallel sessions, visual editors, a kanban board, and an iOS app included.

How is a Claude Code GUI different from a Claude GUI?

A Claude GUI usually means a chat interface to the Claude model itself (Claude.ai, the Claude Desktop chat tab, or third-party Claude chat apps). A Claude Code GUI specifically wraps the Claude Code coding agent, which reads and edits files in a project, runs commands, and produces diffs. The two surfaces have different jobs: a Claude GUI is for conversation, a Claude Code GUI is for coding work.

Best AI IDEs for Claude Code and Codex Users (2026)

Karl Wirth — Mon, 01 Jun 2026 15:03:23 +0000

If you already use Claude Code or Codex, picking an AI IDE is a different question than it was a year ago. The agent does the heavy lifting. The IDE has to host the agent well, surface its work, and stay out of the way. This guide compares the best AI IDEs and visual workspaces for that exact scenario: AI IDEs (Cursor, Windsurf, Antigravity, Zed, Copilot, JetBrains), terminal-first AI coding agents (Claude Code, Codex, OpenCode), and visual workspaces that wrap those agents (Nimbalyst, Claude Code Desktop). The right pick depends on whether you mostly edit code, mostly direct agents, or want both.

Best AI IDE for Claude Code and Codex: Quick Answer

If you only want the verdict:

Best AI IDE for single-session work: Cursor.
Best AI IDE for parallel agents inside an IDE: Antigravity (up to 5 agents) or Cursor 2.0 (up to 8).
Best AI coding agent overall: Claude Code for raw quality, Codex for ChatGPT bundle distribution.
Best open-source AI coding tool: OpenCode (model-agnostic terminal agent) or Nimbalyst (visual workspace with an MIT-licensed desktop and iOS apps).
Best free AI coding tool: Nimbalyst (free for individuals, full app) or OpenCode (free, bring your own keys).
Best AI coding tool for parallel sessions: Nimbalyst (kanban, worktrees, mobile companion).

A category-by-category comparison follows.

Every IDE Is "AI-Native" Now. The Differences Still Matter.

Open any code editor's landing page in 2026 and you will see the same claim: AI-native, intelligent autocomplete, agentic workflows. The marketing has converged. The products have not.

Some are still VS Code-derived. Others are built from scratch around AI workflows. Some are basically better autocomplete plus chat. Others are agent systems that can edit across files, run commands, and keep working while you review. The right AI coding tool depends on how you actually write code: whether you spend most of your time editing single files, orchestrating multi-file changes, or directing autonomous agents.

This is a detailed comparison of the major AI coding tools available in 2026, with real trade-offs instead of feature-list marketing.

What Makes an AI IDE

Before the comparison, it is worth defining what separates an AI IDE from a regular editor with AI features.

That line is blurrier than it was a few years ago. Modern plugins can do more than autocomplete: they can edit multiple files, explain errors, and in some cases run agentic workflows. The real distinction in 2026 is how central AI is to the experience.

In an AI-first IDE, prompting, applying edits, reviewing diffs, and handing off background work are core workflows rather than optional sidebars. The tool is designed around project context, multi-file reasoning, and agent loops. In a traditional editor with strong AI, those capabilities exist, but the editor itself still feels like the primary product and AI feels layered on top.

The tools below fall on a spectrum from "excellent editor with strong AI" to "agent-first development environment."

Cursor

Price: Free, $20/month (Pro), $40/user/month (Business)
Platform: macOS, Windows, Linux
Base: VS Code fork
Models: OpenAI, Anthropic, Google, xAI, and others

Cursor is still the default answer when developers ask for an AI-first editor. It is polished, fast, and focused on the core loop of understanding a codebase, making coordinated edits, and getting out of your way.

Tab autocomplete is where most developers feel the difference first. Cursor predicts not just the next line but multi-line edits that account for nearby files and project context. Its main chat and apply workflow is strong for multi-file changes, and Background Agents push longer tasks into remote environments so work can continue without tying up your machine.

Cursor's practical advantage is migration cost. It can import your VS Code settings and extensions, so switching is far less disruptive than moving to a completely new editor family.

Strengths:

Best-in-class tab autocomplete and inline suggestions
Strong multi-file edit and apply workflow
Background Agents for autonomous task completion
Low-friction migration from VS Code
Broad model support

Limitations:

More expensive than Copilot or Windsurf for individual users
VS Code fork means it inherits VS Code's architecture constraints
Background Agents are still early -- complex tasks sometimes need human intervention
Vendor lock-in concerns if you build workflows around Cursor-specific features

Best for: Developers who want the most polished AI editing experience and are willing to pay for it. If you spend most of your day editing code in a single project, Cursor is the strongest option.

Windsurf

Price: Free, $15/month (Pro), $30/user/month (Teams)
Platform: macOS, Windows, Linux
Base: AI-first editor with VS Code and JetBrains plugins
Models: Claude, GPT, Gemini, and Windsurf SWE models

Windsurf's differentiator is Cascade, its agentic workflow built around persistent context. Windsurf tracks recent files, terminal output, and what you are doing in the editor so it can stay in the loop without needing as much explicit prompting.

The current Windsurf story is broader than "Cursor competitor with a VS Code fork." The company now offers the standalone editor plus IDE plugins, and its pricing is built around prompt credits rather than the simpler flat-request framing some competitors use. That makes it flexible, but also harder to reason about at a glance.

Strengths:

Cascade's proactive AI reduces the need to explicitly prompt for common tasks
Lower price point than Cursor ($15 vs $20)
Good context awareness across the codebase
Available as both a standalone editor and IDE plugins

Limitations:

Credit-based pricing is less predictable than simpler flat-seat plans
Cascade's proactive behavior can be distracting if you prefer explicit control
Smaller ecosystem story than plain VS Code or Cursor
More opinionated workflow than tools that wait for explicit commands

Best for: Developers who want AI to be more proactive and anticipatory. If you prefer an AI that watches what you are doing and jumps in without being asked, Windsurf is the closest to that vision.

GitHub Copilot

Price: Free, $10/month (Pro), $39/month (Pro+) | Business and Enterprise plans available
Platform: VS Code, Visual Studio, JetBrains, Xcode, Eclipse, Neovim
Base: Plugin across major IDEs
Models: OpenAI, Anthropic, Google, xAI, and others via GitHub

GitHub Copilot remains the most pragmatic choice if you do not want to switch editors. The free tier is usable, the $10 Pro plan is still aggressive on price, and GitHub supports more development environments than any of the editor-first competitors.

The coding agent is the clearest example of Copilot's advantage. You can assign it GitHub issues, let it work in GitHub's environment, and review the result as a normal pull request. For teams already standardized on GitHub, that is a compelling workflow.

Copilot's trade-off is that it is an add-on to existing editors rather than a ground-up rethinking of the editing experience. The AI features are good, but the editor itself is still standard VS Code (or JetBrains, etc.). Multi-file edit workflows are not as fluid as Cursor's Composer.

Strengths:

Broadest editor and IDE support
Best price-to-value ratio at $10/month
Coding Agent for autonomous PRs integrated with GitHub
Enterprise standard -- most companies already have GitHub licenses
No editor lock-in -- your AI assistant works in whatever IDE you prefer

Limitations:

Agent quality lags behind dedicated agent tools like Claude Code and Cursor -- Copilot's coding agent is convenient but not best-in-class
Multi-file edit flows are improving, but still feel less seamless than Cursor or Windsurf
AI features are additive to the editor, not deeply integrated into the editing loop
Premium request limits can be restrictive for heavy users
Some of the most interesting workflows are tied specifically to GitHub

Best for: Teams that want a single AI tool across multiple IDEs, or developers who want solid AI features at the lowest price. The enterprise play for organizations already on GitHub.

Zed

Price: Free, with paid Pro and team plans
Platform: macOS, Windows, Linux
Base: Built from scratch in Rust
Models: Hosted models plus local models through Ollama

Zed is the speed-first option. It feels materially lighter than Electron-based editors, and unlike the earlier versions many people still have in mind, it now has official Windows support in addition to macOS and Linux.

Its AI story has also matured. Zed now has edit prediction, an agent panel, hosted model access, and local model support through Ollama. It is still not the most full-featured agent environment in this list, but it is no longer just "fast editor, weak AI."

Zed's collaboration features are native -- multiple developers can edit the same file in real time with no plugins required. For a deeper look at how Zed compares to a workspace built around AI sessions, see Zed vs Nimbalyst.

Strengths:

Fast, lightweight native feel
Strong local-model story through Ollama
Native real-time collaboration
Official Windows support now closes a major adoption gap
Clean, modern UI built from scratch

Limitations:

AI features are less mature than Cursor, Copilot, or Windsurf
Smaller extension ecosystem -- many VS Code extensions have no Zed equivalent
Multi-file agentic workflows are still developing

Best for: Speed-focused developers who want the fastest possible editor and are willing to accept less mature AI features. Also strong for teams that need real-time collaboration built in.

Google Antigravity

Price: Public preview; no-cost access for individuals with higher rate limits on Google AI Pro and Ultra plans
Platform: macOS, Windows, Linux
Base: Agent-first development platform by Google
Models: Gemini plus additional model options in preview

Google Antigravity is not just "Google's browser IDE." Google is positioning it as an agentic development platform with an editor, a manager surface, and disposable development environments that can spin up as part of the workflow.

That makes the draft-state product more interesting than the usual web-IDE caricature. It is multi-model, cross-platform, and explicitly built around agents. It is also clearly early: the platform is in public preview, the workflow is opinionated, and the surrounding ecosystem is still young.

Strengths:

Strong agent-first architecture
Google's infrastructure for ephemeral environments
More multi-model than its name suggests
Cross-platform from the start
Integrated with Google Cloud ecosystem

Limitations:

Still a public-preview product
Cloud-connected workflow will not fit every team
Ecosystem and extension story are immature
More experimental than the established editor options

Best for: Developers who want zero-setup AI coding and are already in the Google Cloud ecosystem. Good for quick prototyping sessions where you do not want to configure a local environment.

JetBrains IDEs + AI Assistant

Price: JetBrains AI Free, Pro, and Ultimate plans; AI Pro is bundled with some JetBrains subscriptions
Platform: macOS, Windows, Linux
Base: IntelliJ platform (IntelliJ IDEA, PyCharm, WebStorm, etc.)
Models: JetBrains AI plus Junie and local-model options

JetBrains IDEs have the deepest language-specific intelligence of any editor family. IntelliJ understands Java at a level that no VS Code extension matches. PyCharm does the same for Python. The AI Assistant adds inline completions, chat, and multi-file suggestions on top of this existing intelligence.

The important change in 2026 is that JetBrains is no longer just "traditional IDE plus a small AI add-on." The company now has a real AI product stack: free and paid AI plans, Junie for agentic help, and local-model support for teams that do not want everything routed through hosted providers.

Strengths:

Deepest language-specific intelligence (refactoring, navigation, analysis)
AI builds on top of already-excellent code understanding
Growing agent story with Junie
Local-model support is a real differentiator for some teams
Enterprise-grade features (database tools, profiler, deployment)
Mature ecosystem with decades of plugin development

Limitations:

Total cost can still be high if you need both a paid IDE and paid AI plan
Heavier resource usage than VS Code-based editors
AI features are an add-on, not the core experience
Less aggressive AI development pace compared to Cursor or GitHub

Best for: Enterprise Java/Kotlin teams, or developers working in languages where JetBrains' deep analysis matters more than AI autocomplete speed. If you already use JetBrains and want to add AI, the assistant is solid.

Agent-First Tools: Claude Code and Codex

These are not IDEs, but they deserve mention because many developers use them instead of -- or alongside -- IDE-based AI features.

Claude Code (Anthropic) and Codex (OpenAI) are better understood as agent-first coding tools than as ordinary editors. Claude Code remains terminal-first. Codex now spans CLI, IDE extension, cloud, and app surfaces. (For a deeper look at how they compare, see Claude Code vs Cursor: when to use each.)

What they share is the core workflow: you point the agent at a repo, give it a task, and let it read files, write code, run commands, fix errors, and iterate. They can handle larger, messier multi-file work than most editor-native assistants because they control more of the development loop.

The trade-off is visibility and ergonomics. Even when these tools gain app or IDE surfaces, the experience is still centered on directing an agent rather than living inside a polished editor. They are powerful, but they are not a complete replacement for everyone.

Best for: Complex multi-file tasks, autonomous background work, and developers who prefer to direct agents through natural language rather than work inside an editor.

The Missing Layer: Why an IDE Is Not Enough

Here is what none of these IDEs solve: the work that happens before and after code editing.

Before you write code, you plan. You write feature specs, sketch architecture diagrams, create UI mockups, and break work into tasks. After the code is written, you review diffs, manage git branches, track what changed across sessions, and coordinate multiple parallel workstreams.

AI IDEs optimize the middle part -- the actual editing. But the planning, review, and management layers are still scattered across separate tools: Notion for specs, Excalidraw for diagrams, Linear for tasks, a terminal for git, and a separate window for each AI session.

This fragmentation gets worse with agentic development. When you are running three Claude Code sessions in parallel across different worktrees, each working on a different feature, you need a way to see all of them at once. Which sessions are active? What files did each one change? Are the changes ready to review? No IDE answers these questions because no IDE is designed for session-level management.

This is the problem Nimbalyst solves -- not as a replacement for your AI IDE, but as the workspace layer beyond the terminal. Nimbalyst is a visual workspace built on top of Claude Code and Codex that handles everything surrounding the code editing:

7+ visual editors for specs, mockups, diagrams, data models, spreadsheets, and code -- all in one workspace alongside your agents
Session kanban to manage multiple AI agent sessions across parallel workstreams
Inline diffs to review what each agent changed, file by file
Git integration with worktree support for isolated agent branches
Task tracker that links tasks to sessions, files, and branches
Terminal for running agents directly within the workspace

Nimbalyst is free for individuals, runs as a desktop app on Mac, Windows, and Linux, and has an iOS app for reviewing on the go.

The point is not to replace Cursor, or VS Code, or whatever IDE you prefer. The point is that your IDE handles code editing, and Nimbalyst handles the workspace around it -- the planning, the session management, the review, and the coordination that agentic development demands.

Comparison Table

	Cursor	Windsurf	GitHub Copilot	Zed	Google Antigravity	JetBrains + AI	Claude Code / Codex	Nimbalyst
Price	Free, Pro $20	Free, Pro $15	Free, Pro $10, Pro+ $39	Free plus paid plans	Public preview	AI Free/Pro/Ultimate	Usage-based	Free for individuals
Primary shape	AI-first editor	AI-first editor + plugins	AI across existing editors	Native Rust editor	Agentic dev platform	Language-specific IDE suite	Agent-first coding tools	AI workspace layer
Works in	Mac/Win/Linux	Mac/Win/Linux	VS Code, Visual Studio, JetBrains, Xcode, Eclipse, Neovim	Mac/Win/Linux	Mac/Win/Linux	Mac/Win/Linux	Terminal plus app or IDE surfaces	Mac/Win/Linux plus iOS
Best at	Polished AI editing	Proactive agentic help	Lowest-friction rollout	Speed and local feel	Cloud agent workflows	Deep language intelligence	Large autonomous tasks	Planning, session management, and review
Agent depth	High	High	Medium to high	Medium	High	Medium	Very high	Built on Claude Code and Codex
Local / offline story	Local app, cloud models	Local app, cloud models	Depends on host editor; mostly cloud-backed	Best local-model support	Cloud-connected	Strong local tooling, plus local models	Excellent editor independence	Local app, works alongside any IDE
Open source	Closed	Closed	Closed	Yes (GPLv3)	Closed	Closed	CLI open source; desktop apps closed	Yes — MIT (github.com/Nimbalyst/nimbalyst)
Who should pick it	Devs who want the most polished AI editor	Devs who want the AI to stay proactive	Teams already standardized on GitHub	Speed-first developers	Early adopters and Google-heavy teams	JetBrains shops and language-heavy teams	People directing agents more than typing code	Devs managing multiple agent sessions and planning work around code

How to Choose Your AI IDE

The decision comes down to three questions:

How important is raw editor performance? If you want the lightest native-feeling editor and a strong local-model story, choose Zed. If AI-assisted editing speed matters more than raw keystroke latency, choose Cursor.

Do you want AI to be proactive or on-demand? Cursor and Copilot are more comfortable when you drive. Windsurf's Cascade is more willing to stay in the loop and jump ahead. Neither approach is objectively better -- it depends on how you prefer to work.

Are you locked into an ecosystem? If your team is on GitHub, Copilot is the natural fit. If you are a JetBrains shop, JetBrains AI is the lowest-friction path. If you want to experiment with a cloud-heavy agent platform, Antigravity is the interesting wildcard. If you have no constraints, Cursor is still the cleanest all-around recommendation.

Do you need more than just a code editor? If you are running multiple agent sessions, planning features with specs and mockups, and reviewing diffs across parallel workstreams, no IDE covers that workflow on its own. Nimbalyst is designed for exactly this -- it works alongside whichever IDE you choose and handles the planning, session management, and review layers that editors leave out.

One thing is clear: the IDE you choose matters less than the workflow you build around it. Whichever AI IDE you pick, the real productivity gains come from how you plan work, manage sessions, and review changes -- the workspace layer that sits above any editor.

Frequently Asked Questions

What is the best AI IDE in 2026?

The best AI IDE in 2026 depends on how you work with AI. Cursor is the best single-session AI IDE for most developers. Antigravity is the best AI IDE for running multiple agents inside one editor, with up to five parallel agents. Windsurf is the best AI IDE for ChatGPT-tied teams that want async cloud agents alongside the local IDE. For developers who want an open-source option, Zed combines a fast native editor with optional AI agents. Nimbalyst is the visual workspace that sits alongside any of these IDEs for parallel session management, planning, and review.

What is the best IDE for Claude Code users?

The best IDE for Claude Code users is the one that stays out of Claude Code's way while giving you a good place to read its output. Cursor and Zed both work well alongside the Claude Code CLI for in-editor reading and quick manual edits. For multi-session Claude Code workflows, no IDE covers session orchestration, kanban boards, or worktree isolation. That gap is what Nimbalyst is built for. Many Claude Code users run Cursor or Zed as their editor and Nimbalyst as their workspace.

What is the best IDE for Codex users?

Codex is most directly integrated with the official Codex CLI, the OpenAI Codex desktop app, and the Codex IDE extension for VS Code, Cursor, and Windsurf. The best IDE for Codex users is whichever editor you already use with the Codex extension installed. For parallel Codex sessions and structured review, the Codex IDE extension does not provide a session board or diff workflow at scale. A dedicated Codex GUI or workspace covers that layer.

Is there a best free AI IDE?

Yes. Zed, JetBrains IDEs with the free AI Assistant tier, and Claude Code Desktop (free with a Claude subscription) are the free-tier AI IDE options most worth trying in 2026. For a fully open-source pairing, Zed plus Claude Code or Codex (CLI) is free as a tool and you pay the model provider directly. Nimbalyst is free for individuals as a visual workspace alongside any of those editors.

Should I use an AI IDE or a visual workspace?

Both, in most workflows. An AI IDE is the best place to edit, navigate, and debug code. A visual workspace is the best place to plan features, run parallel agents, and review their work at the workspace level. The two are complementary, not competing. Developers who only edit code can stop at an AI IDE. Developers who run multiple agents in parallel, plan visually, or review large diffs benefit from layering a workspace on top.

Best Claude Code MCP Servers in 2026 (Ranked)

Karl Wirth — Mon, 01 Jun 2026 15:00:16 +0000

The best Claude Code MCP servers in 2026 are the ones that connect Claude to systems it does not already understand natively: GitHub, Linear, Slack, your database, your browser, and your production tooling. This guide ranks the MCP servers that actually expand Claude Code, and it intentionally leaves out things that Claude Code already ships on its own, like built-in file tools and built-in project memory.

Best Claude Code MCP Servers: Top Picks

Server	What it unlocks	Difficulty	When to install
GitHub	Issues, PRs, code search across repos	Easy	Day one
Linear	Tickets, project status	Easy	If your team uses Linear
Slack	Team comms, status updates	Easy	If your team coordinates in Slack
Postgres	Database queries, schema reading	Medium	When the project touches a database
Playwright	Browser automation, E2E testing	Medium	For frontend work
Sentry	Error context, issue triage	Easy	If you ship to production
Context7	Live library docs	Easy	For multi-stack work
Nimbalyst Tracker	In-app planning and bug tracking	Easy	If you use Nimbalyst

The full list of useful Claude Code MCP servers runs to dozens. The eight above cover most working developers.

Two things I would not put in the default list

Two entries show up in a lot of "best MCP server" lists and usually do not belong there for Claude Code:

Filesystem MCP server. Claude Code already has built-in file tools (Read, Edit, Write, Glob, Grep) plus fine-grained permission rules and sandboxing. If your goal is "keep Claude away from secrets," use permissions.deny, sandboxing, or a worktree. An extra filesystem MCP server is only worth it when you specifically want to expose additional directories through MCP or share the same server setup across multiple clients.
Memory MCP server. Claude Code already has two built-in memory systems: CLAUDE.md for persistent instructions and auto memory for learned project notes. A separate memory server can still make sense if you want a shared memory layer across different agents or clients, but it is not a day-one Claude Code install.

How to evaluate an MCP server

Before installing anything, three questions:

Does it expose tools the agent will actually use? Tools the agent ignores still count toward its tool budget and slow things down. Five well-chosen servers beat twenty.
What credentials does it need, and what scope? A server that needs admin tokens in your production database is a server you have to operate carefully. Use read-only roles wherever possible.
Is it actively maintained? The MCP standard is young. Servers from January 2025 may not work with Claude Code's current expectations. Prefer servers with commits in the last three months.

The detailed list

1. GitHub MCP server

The most-installed MCP server, and rightly so. It exposes Claude Code to issues, pull requests, code search, and repository metadata across any repo your token can see.

"github": {
  "command": "npx",
  "args": ["-y", "@modelcontextprotocol/server-github"],
  "env": { "GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_..." }
}

Use a fine-grained personal access token with repo, read:org, and workflow scopes. For team projects, prefer a service account so you can audit Claude Code's actions separately from your own.

What it unlocks: "Find the issues tagged blocking. Write a PR that closes the top one. Open it as a draft, link the issue, and request review from the owner of the affected module."

2. Linear MCP server

For teams that live in Linear, this turns Claude Code into a participant in the planning system. It can read tickets, update status, leave comments, and create new issues.

"linear": {
  "command": "npx",
  "args": ["-y", "@linear/mcp-server"],
  "env": { "LINEAR_API_KEY": "lin_api_..." }
}

What it unlocks: "Read all open bugs assigned to me. Pick the one with the smallest scope. Open a fix branch, write the patch, and link the Linear ticket from the PR."

3. Slack MCP server

For teams that coordinate in Slack. Claude Code can read channel history, post messages, and reply in threads.

"slack": {
  "command": "npx",
  "args": ["-y", "@modelcontextprotocol/server-slack"],
  "env": {
    "SLACK_BOT_TOKEN": "xoxb-...",
    "SLACK_TEAM_ID": "T0123..."
  }
}

What it unlocks: Async status updates. The agent can post when a long-running task finishes, and you can reply with follow-up instructions without leaving Slack.

4. Postgres MCP server

For database-backed projects, exposing the database to Claude Code transforms what it can do. Schema reading, query writing, data inspection, and (if you choose) mutations.

"postgres": {
  "command": "npx",
  "args": [
    "-y",
    "@modelcontextprotocol/server-postgres",
    "postgresql://readonly@localhost/mydb"
  ]
}

Strong recommendation: use a read-only role. Postgres MCP with a read-only DSN is safe and fast. Postgres MCP with a write-capable DSN is a footgun unless you trust the agent fully and have backups.

What it unlocks: "Read the schema. Find the slowest query in the slow_log table. Write a candidate index. Run EXPLAIN ANALYZE before and after."

5. Playwright MCP server

For frontend and E2E testing work, Playwright MCP lets Claude Code drive a real browser. It can navigate, fill forms, click, screenshot, and assert.

"playwright": {
  "command": "npx",
  "args": ["-y", "@executeautomation/playwright-mcp-server"]
}

What it unlocks: The agent can verify its own UI changes by actually using the app. "Add the new payment form. Then open the checkout page in the browser, fill it out, and confirm the success state appears."

6. Sentry MCP server

If you ship to production, Sentry MCP wires error context into Claude Code. It can read recent issues, group by frequency, and pull stack traces.

"sentry": {
  "command": "npx",
  "args": ["-y", "@sentry/mcp-server"],
  "env": {
    "SENTRY_AUTH_TOKEN": "sntrys_...",
    "SENTRY_ORG": "my-org"
  }
}

What it unlocks: "Look at this morning's top three Sentry errors. Find the underlying bug in the code. Open a fix PR for the worst one."

7. Context7 MCP server

Context7 keeps live, version-aware documentation for hundreds of libraries. The agent can fetch the right docs for the right version on demand.

"context7": {
  "command": "npx",
  "args": ["-y", "@upstash/context7-mcp"]
}

What it unlocks: Less hallucination on library APIs. Instead of guessing the current React or Prisma signature, the agent looks it up.

8. Nimbalyst Tracker MCP server

If you use Nimbalyst, the built-in tracker MCP server gives Claude Code direct access to your in-app plans, tasks, and bugs. The agent can create, update, and close tracker items as part of normal work, with the changes appearing in real time on your kanban board.

What it unlocks: Plans, tasks, and bugs that stay in sync without the agent ever leaving the workspace.

Honorable mentions

Brave Search for web research without leaving the agent.
Notion for teams whose source-of-truth lives there instead of Linear.
Stripe for SaaS work that touches billing.
Cloudflare for edge and DNS workflows.
AWS S3 for asset and storage operations.
Figma for design-to-code handoffs.

The MCP ecosystem doubles every few months. Bookmark the official MCP servers repository for the canonical list.

A sensible starter pack

If you want one configuration to install on day one and tune later:

{
  "mcpServers": {
    "github": { ... },
    "context7": { ... },
    "linear": { ... }
  }
}

Add Slack if your team lives there. Add Postgres, Sentry, or Playwright when the project demands them. Resist installing servers you do not have a clear use for. Each one expands the agent's tool list, and a bloated tool list hurts the agent's decision quality.

Claude Code MCP servers in Nimbalyst

Nimbalyst is the open-source visual workspace for building with Codex, Claude Code, and more. The most useful extra MCP server to pair with Nimbalyst is usually GitHub, because Nimbalyst already gives you the visual session layer, tracker, and review workflow. The next-best adds are whatever connect Claude to systems outside the workspace: Linear for tickets, Postgres or Sentry for backend work, and Playwright for UI verification. The MCP configuration you keep in ~/.claude/settings.json still carries over into Nimbalyst sessions, so once you wire those up they show up in both places.

Frequently Asked Questions

What is the best Claude Code MCP server overall?

The GitHub MCP server is the single highest-impact install for most developers. It turns Claude Code from a code generator into a participant in the issue and PR workflow. If you use Nimbalyst, GitHub is also the cleanest complement because Nimbalyst already covers the visual session-management layer.

How many MCP servers should I have configured?

Three to six is the sweet spot for most working developers. Day-one essentials are usually GitHub plus one or two project-specific servers, then Context7 if you frequently work across unfamiliar stacks. More than ten servers tends to slow the agent down without proportional benefit.

Are there official Anthropic MCP servers?

The MCP ecosystem publishes reference servers under the @modelcontextprotocol GitHub org, and many ecosystem servers are built and maintained by the relevant company (Linear, Sentry, Stripe, Cloudflare, and others). Anthropic's Claude Code docs point to this broader MCP ecosystem rather than limiting you to Anthropic-only extensions.

Can I run Claude Code MCP servers on Windows?

Yes. Most MCP servers ship as npm packages that work on macOS, Linux, and Windows. The configuration syntax is identical. Use absolute paths (no ~ expansion) and forward slashes in the JSON to avoid escaping headaches.

Should I use project-scope or user-scope MCP configs?

User scope (~/.claude/settings.json) for stable servers like GitHub or Context7. Project scope (.claude/settings.json in the repo) for servers that are specific to one codebase, like a database with that project's DSN. Project scope overrides user scope when both define the same server.

How do I keep MCP secrets out of git?

Two ways. First, put secrets in user-scope settings, which lives in your home directory and is never in a repo. Second, for project scope, commit a settings.example.json with placeholders and add .claude/settings.json to .gitignore. Document the required env vars in the project README.

Best Codex GUI 2026: 4 Codex Desktop Apps Compared

Karl Wirth — Mon, 01 Jun 2026 14:52:25 +0000

The best Codex GUI in 2026 depends on how much workflow you want around the agent. The landscape is broader than it was a few months ago: Codex now spans the CLI, an IDE extension, the official Codex desktop app, web and cloud environments, GitHub review flows, and mobile surfaces inside ChatGPT. This guide compares four Codex GUI options head to head, with verified details only from public docs, repos, and product pages.

The right comparison is no longer "which terminal wrapper should I use?" It is "which visual environment makes Codex easier to supervise, review, and run at scale?"

What Codex Actually Is in 2026

OpenAI's Codex CLI is an open-source coding agent that runs locally on your machine. OpenAI says it is sandboxed by default with network access disabled, but the CLI now supports multiple approval and access modes, so the exact behavior depends on how you configure it.

That matters because not every tool in this list is doing the same job:

Some are native Codex interfaces built directly around Codex sessions.
Some are multi-agent workspaces that run Codex alongside Claude Code or other backends.
Some are cloud environments for Codex rather than local desktop wrappers.

If you only want the closest thing to an official Codex GUI, your shortlist is small. If you want a broader visual workspace around Codex, the field gets more interesting.

Quick Answer

If you just want the shortlist:

Best official Codex desktop app: OpenAI Codex App
Best open-source Codex-first app: CodexMonitor
Best remote and browser-first option: CloudCLI
Best full visual workspace around Codex: Nimbalyst

Best Codex GUI Tools Right Now

1. OpenAI Codex App

Best for: Developers who want the first-party Codex experience

OpenAI's own Codex app is no longer a thin wrapper around the CLI. OpenAI describes it as a desktop "command center for agents," and the public product materials back that up.

What it does well:

Runs multiple Codex agents in parallel
Organizes work by projects and threads
Lets you review diffs and comment on changes
Includes built-in worktree support
Shares history and configuration with the CLI and IDE extension
Includes interfaces for skills, automations, and git workflows

The tradeoffs:

It is still Codex-only
It is available on macOS and Windows, but not Linux
It is strongest if you already live inside OpenAI's Codex ecosystem

This is the safest default recommendation. If you want the most direct, least interpretive GUI for Codex itself, start here.

2. CodexMonitor

Best for: Developers who want an open-source, Codex-first desktop control center

CodexMonitor is an MIT-licensed Tauri app built specifically around Codex. Public docs describe it as an orchestration app for multiple Codex agents across local workspaces, backed by the Codex app-server protocol.

What stands out:

Multi-workspace and multi-thread Codex management
Worktree and clone agents for isolated runs
Built-in diff stats and file diffs
Git and GitHub integration through git and gh
Remote backend mode if you want Codex running on another machine
Desktop support across macOS, Linux, and Windows

The tradeoffs:

It is primarily a Codex app, not a broader multi-provider workbench
Some mobile functionality exists only as iOS work in progress
It is more of a power-user desktop tool than a polished mainstream product

If you like the idea of the official app but want something open source and more hackable, CodexMonitor is one of the strongest current options.

3. CloudCLI

Best for: Developers who want Codex sessions to live in the cloud, not on their laptop

CloudCLI is fundamentally different from the desktop-native tools above. It gives you persistent cloud environments with Codex, Claude Code, Cursor CLI, and Gemini CLI preinstalled, then lets you start work from your browser or phone and continue over SSH in your editor.

What it does well:

Supports Codex, Claude Code, Cursor CLI, and Gemini CLI
Lets you start a session from your phone or browser
Keeps environments running even when your laptop is closed
Includes a file explorer and Git UI
Offers a hosted product starting at €7/month
Says the core UI is open source and self-hostable

The tradeoffs:

This is a cloud environment product, not a local Codex desktop app
The best experience depends on being comfortable with SSH and remote environments
Hosted pricing is low, but it is still not a free local wrapper

If the biggest problem you are solving is "I want my coding agents to keep running while I am away from my machine," CloudCLI is one of the most compelling options in this space.

4. Nimbalyst

Best for: Developers who want Codex inside a broader visual workspace

Nimbalyst is not a Codex-only wrapper. It is a cross-platform workspace built around Codex and Claude Code, with a visual session layer, built-in editors, and project organization tools around the agent.

What it does well:

Supports Codex and Claude Code side by side
Includes a session kanban board for organizing agent work
Uses git worktree isolation for parallel sessions
Provides visual diff review for agent changes
Ships with built-in editors for markdown, code, CSV, diagrams, mockups, and data models
Runs on macOS, Windows, and Linux
Extends the workflow with an iOS companion app for mobile session visibility
Free for individual use

The tradeoffs:

It is a full workspace, not a minimal Codex shell
The product is more opinionated than the official app or a simple wrapper
It makes the most sense if you want planning, review, and visual editing around your agent sessions, not just a better terminal

If your goal is to manage multiple AI coding sessions as ongoing work rather than isolated chats, Nimbalyst is one of the most complete options currently available.

Quick Comparison Table

Tool	Type	Platforms	Codex Only	Parallel Session Management	Open Source	Best Fit
OpenAI Codex App	First-party desktop app	macOS, Windows	Yes	Yes	No	Official Codex workflow
CodexMonitor	Open-source Codex desktop app	macOS, Linux, Windows	Yes	Yes	Yes (MIT, Tauri)	Hackable Codex control center
CloudCLI	Cloud agent environment	Web, mobile, SSH to IDEs	No	Yes	Partial (core UI)	Remote and persistent sessions
Nimbalyst	Visual agent workspace	macOS, Windows, Linux, iOS	No	Yes	Yes — MIT (desktop and iOS apps)	Planning, review, and visual editors around Codex

Which One Should You Pick?

If you want the most direct answer:

Pick OpenAI Codex App if you want the first-party Codex experience.
Pick CodexMonitor if you want an open-source Codex-native desktop app.
Pick CloudCLI if you want persistent remote environments and mobile/browser kickoff.
Pick Nimbalyst if you want a visual workspace around Codex sessions, not just a GUI for running them.

The Codex GUI Market Is More Real Than It Was Six Months Ago

The outdated version of this conversation is "Codex has a CLI, and everything else is a thin wrapper." That is no longer true.

OpenAI's own app now has real workflow features. CodexMonitor is building a serious open-source interface around Codex. CloudCLI is pushing Codex into persistent remote environments. Nimbalyst is treating Codex as one execution engine inside a broader visual workspace.

That is still a smaller ecosystem than the one around some older AI coding tools, but it is no longer empty. The right choice now depends less on "does Codex have a GUI?" and more on what kind of GUI you actually want.

Shorter Side-by-Side Pages

Nimbalyst vs Codex App for the direct first-party Codex comparison.
Nimbalyst vs Codex CLI for terminal versus workspace tradeoffs.
Browse all Nimbalyst comparison pages if you also want to compare Cursor, Claude Code Desktop, or Replit.

For a deeper look at what Nimbalyst adds to Codex, see our Codex GUI & Workspace landing page.

If you are scaling Codex across a team, see our guide on Codex for teams for session management, worktrees, and multi-agent coordination.

Frequently Asked Questions

What is the best Codex GUI in 2026?

The best Codex GUI in 2026 depends on what you need around the agent. For the first-party experience, the OpenAI Codex App is the default choice. For an open-source Codex-first desktop app, CodexMonitor is the strongest option. For persistent cloud environments accessed from a browser or phone, CloudCLI is the most compelling. For a full visual workspace with parallel Codex sessions, kanban-style management, inline diff review, and visual editors, Nimbalyst is the most complete Codex GUI.

Is there an official Codex desktop app?

Yes. OpenAI's Codex App is the official Codex desktop app, available on macOS and Windows. It supports parallel agents, worktrees, project organization, diff review, skills, and automations. It is Codex-only and does not support other AI agents. There is no official Linux build at this time.

What is the best free Codex GUI?

The OpenAI Codex App and Nimbalyst are both free for individual use. CodexMonitor is free and open source. CloudCLI offers a free tier with paid hosting starting at €7 per month. Nimbalyst is the only free Codex GUI in this guide that combines parallel session management, optional one-click git worktree isolation per session, an iOS companion app, and visual editors for markdown, mockups, diagrams, and data models.

What is the best open-source Codex GUI?

CodexMonitor is the best open-source Codex-first desktop app. It is MIT-licensed and built on Tauri, with multi-workspace and multi-thread Codex management, worktree and clone agents, and built-in diff stats. Nimbalyst is the best open-source full visual workspace around Codex. Its desktop and iOS apps are MIT licensed.

Does Codex have a Linux desktop app?

The official OpenAI Codex App ships for macOS and Windows only. For Linux, the best Codex GUI options are CodexMonitor (open source, MIT-licensed) and Nimbalyst (open source, free for individuals, full visual workspace). CloudCLI also works on Linux through any browser.

Is there a Codex app for Linux?

The official OpenAI Codex App does not have a Linux build as of 2026. Linux users running Codex day to day have three working options: install CodexMonitor (Tauri, MIT-licensed, native binary), install Nimbalyst (Electron, MIT-licensed desktop and iOS apps, full visual workspace with parallel Codex sessions), or run CloudCLI in any browser. The Codex CLI itself runs fine on Linux. The gap is the supervisory GUI layer around it.

What is the best Codex desktop app for Linux?

For most Linux developers, Nimbalyst is the broadest Codex desktop app option. It runs Codex (and Claude Code) sessions in parallel with a kanban board, optional one-click git worktree isolation, inline diff review, and seven visual editors. CodexMonitor is the lighter pick for a single-purpose Codex management UI without the surrounding workspace.

Can I run multiple Codex sessions in parallel?

Yes. Three of the four Codex GUI tools in this guide support parallel Codex sessions. The OpenAI Codex App runs multiple Codex agents in parallel with built-in worktree support. CodexMonitor runs multi-workspace and multi-thread Codex management. Nimbalyst runs 6+ parallel Codex sessions with optional one-click git worktree isolation per session, a kanban board, and per-session file traceability across markdown, mockups, diagrams, code, and data models.

Building the harness around our coding agents: eight failure modes, eight pillars

Karl Wirth — Tue, 26 May 2026 14:06:02 +0000

Teams building with AI usually end up building two products: the thing they ship, and the system around their agents that makes them useful in building the thing they ship.

We built such a system to help us ship Nimbalyst. We call it our team harness. This post is about what we learned from doing it.

What a harness is

A harness is the durable layer around a model: instructions, tools, permissions, context, and verification.

Claude Code and Codex are harnesses in this sense. Each wraps a model with a system prompt, a tool surface, a permission model, and an execution loop. Anthropic and OpenAI own that layer.

Your team owns the next layer up: the workspace where agents do product work alongside you, with your files, tasks, diagrams, diffs, and decisions. This layer carries the knowledge your team has accumulated: how you build things, what you already decided, what is connected to what, where the agent is allowed to act, and how it checks its own work.

The line between context and harness can blur. A ticket or spec is task-specific context, but the mechanism that makes that ticket searchable, linkable, versioned, and retrievable by any agent is part of the harness.

Almost nothing in a good harness is novel. It is mostly other people's parts assembled around your project: Claude Code, Codex, MCP, Playwright, a tracker, a diagramming tool, an editor, a test runner, your repository, your docs. The harness is the way those pieces are put together so an agent can pull the right context for a task and verify what it produced.

The rest of this post walks each pillar and what we built for it.

1. Context

Goal: know the project.

Failure mode this answers: the agent doesn't know your codebase, rules, decisions, or conventions, so it solves every problem like it has never seen this project before.

Context is everything specific to our project: code, specs, design docs, tracker items, data models, past decisions, conventions, examples, and recipes.

In our harness that means:

Code, specs, plans, and mockups live as local files in formats an agent can read and edit directly.
Architecture diagrams live as Excalidraw files instead of screenshots trapped in a slide deck.
Decisions are captured as tracker items, not buried in chat transcripts.
Bug histories are searchable, so the agent can see symptoms, root cause, and previous fixes.
Root instruction files like CLAUDE.md and AGENTS.md load at session start and point the agent at the rest.
Path-scoped rule files load only when the agent touches a relevant directory, so React rules show up for renderer code and Swift rules show up for the iOS package.
A skill system holds reusable instructions for recurring jobs: how we write tests, add analytics events, release a package, or debug a failing screen.
Persistent per-user memory captures preferences and validated approaches across sessions.

An agent editing renderer code loads React rules without loading iOS rules. An agent fixing a regression finds the prior bug, the root cause, and the fix before writing code. Each session starts with the team's accumulated decisions already in scope instead of being re-derived from the prompt.

2. Provenance

Goal: trace the why.

Failure mode this answers: the agent can't traverse the links between artifacts that already exist, so the reasoning behind every change has to be re-explained or rediscovered.

Provenance is how code changes stay linked to the intent that produced them. A persistent, typed record of why each change exists, navigable from any direction: from the file, from the session, from the tracker item, from the commit. The underlying data structure is a typed graph of links between artifacts; the value is being able to ask "why is this the way it is?" and get an answer.

In our harness that means:

A typed link graph between tracker items, plans, specs, diagrams, mockups, sessions, diffs, files, commits, and decisions.
First-class editors for those artifacts inside the same workspace, so links resolve to actual working content.
File-edit history tied to the session that produced it, so any file shows the conversations that wrote it.
Tracker item types for the different kinds of intent the team carries: bug, feature, decision, plan, incident.
Decision tracker items that record why an architectural choice was made, so a future session asking "why is this the way it is?" gets an answer instead of guesswork.
Bug tracker items filed as we find issues, before fix code is written, so the symptom and root cause stay attached to the fix.
An MCP surface so different agents can traverse the same graph during a session.

A bug can link to the failing screenshot, the fixing session, the diff, and the commit. A feature request can link to the plan, the mockup, the implementation sessions, and the release note. Git captures what changed. Provenance captures why and how we got there.

3. Capability

Goal: act and observe.

Failure mode this answers: the agent can't act on the world or observe what it did, so it stays trapped in the text channel and asks the user to run every command and paste every output.

Capability covers tools that let an agent act on live state and verify what it did: reading logs, querying a running database, driving the UI, taking screenshots, running tests, and looping until the result is correct.

In our harness that means:

MCP tools that read live application logs and query the running database through the app instead of unsafe direct access.
Tools to drive the application itself: restart, reload, install extensions, hot-reload code.
A renderer-eval tool that runs JavaScript inside the running UI to inspect DOM, state, or atoms.
A screenshot tool that captures the rendered content of any open file.
A Playwright-driven UI loop so an agent can interact with the running app, take a screenshot, and verify the result.
MCP tools that wrap third-party systems the agent uses every day: GitHub, the analytics dashboard, the browser, the tracker.
A sandboxed shell so the agent can run tests, scripts, and safe codemods, and run wrangler tail, curl, and gh instead of asking the user to paste output.
An extension SDK so teams can write their own MCP tools and ship them inside the workspace.

After changing a React component, the agent can open the screen and check a screenshot. After changing persistence logic, it can verify that the row actually changed. An agent that can act on the world and observe the result can often close its own loop.

4. Workflow

Goal: reuse the arcs.

Failure mode this answers: the agent reinvents how to do every task, so the same kind of work takes a different shape every time and the basics have to be re-explained per session.

Workflow is the shape of a coding session: how it starts, how it plans, how it gets help, and how it parallelizes.

In our harness that means:

Repo-local slash commands in .claude/commands/ for the steps we run over and over: plan, implement, review, release.
A standard plan-then-execute arc for non-trivial work, so the agent commits to an approach before changing files.
An investigate, design, implement progression so research and planning happen as their own steps instead of getting interleaved with code.
Subagents for exploration, planning, and implementation that take broad searches and protect the main session's context.
A skill system for reusable habits like writing tests, adding analytics events, or releasing a package.

A /release-alpha command runs the version-bump, changelog, and tag steps the same way every time. A /investigate followed by /design produces a plan document the next session can pick up from, instead of starting over from a blank prompt. A workflow layer keeps each session from reinventing itself.

5. Restraint

Goal: stay in bounds.

Failure mode this answers: the agent does something dangerous because nothing stops it, and a capable agent without restraint does it faster than you expected.

Restraint is how we stop an agent from doing the wrong thing quickly. It covers hard rules, approval boundaries, permission scopes, tool allowlists, budget limits, and an audit trail.

In our harness that means:

Path-scoped rules that block agents from editing specific files or directories.
Hard rules in instruction files for things the agent must never do, like reading .env files or touching credentials, each with the past incident that taught us why.
Per-tool permission scopes and allowlists.
Approval flows for actions that touch shared or costly state: push to main, drop a table, hit a paid API, or run a destructive shell command.
Workspace trust modes that separate "can edit files" from "can do anything."
Durable audit trail of approvals, tool calls, and file changes.
Review surfaces that make it obvious what the agent actually changed.

In practice, that means letting an agent refactor renderer code but not release scripts, query a development database but not production, and spend tokens on test loops without touching paid third-party APIs unchecked. Restraint is the paired pillar to capability. Every new tool we give the agent needs a matched scope, or it becomes a liability the moment the agent reaches for it in the wrong context. We build the two together.

6. Verification

Goal: prove the fix.

Failure mode this answers: the agent hallucinates "fixed" without proof, so a confident announcement and a working change are two different things.

Verification is how an agent proves a change works before handing it back. It covers tests, type checks, fail-first reproduction of bugs, and simulated runs of the agent's own tool calls.

In our harness that means:

A failing-test-first discipline: write the failing test before writing the fix, so the bug has a reproduction the next agent can rerun.
A Vitest unit suite that runs across packages and gives fast feedback on logic-level changes.
Playwright end-to-end tests for real flows, one spec per run so a failure points at one place.
An AI tool simulator that lets E2E specs fake AI tool calls and assert on what the agent did, without paying for a real model.
Fast type checks baked into the loop so the agent catches drift before tests even run.

A fix for a sync bug starts with a Playwright spec that opens the broken document and asserts the body loads, then the agent fixes the code until that spec turns green. A renderer change runs the unit suite and the type check before the agent claims it is done.

If the agent cannot show the change works end-to-end, it is not done.

7. Visual interface

Goal: show the work.

Failure mode this answers: the agent can't show results back to humans in a useful form, so decisions, diffs, and artifacts vanish into a wall of chat text that nobody reviews properly.

A lot of software work is visual. Markdown review, UI mockups, architecture diagrams, data models, diffs, screenshots, and sketches are part of the task input, not presentation garnish, so they belong in the workspace where the agent does the work.

The visual interface is where the agent works and where we review what it did, in the same place. Voice, interactive prompts, and walkthroughs are channels the same workspace orchestrates when text or a static visual is not the right format.

In our harness that means:

A workspace where the mockup, the diff, and the tracker item sit side by side, so the thing being reviewed and the place the agent works are the same place.
A markdown editor with red/green diffs for agent edits, plus diff review across every file the agent touched in a session.
Mockup, diagram, and data-model editors as first-class file types, with image and screenshot inputs the agent can read and produce directly.
Inline charts and rendered screenshots returned in the conversation, so numeric results and UI changes do not vanish into a text wall.
Approval gates on risky actions like merges, deploys, and pushes to main, with the diff and linked tickets shown in one view before approval.
Threaded discussions tied to tracker items, diffs, and decisions, so the reasoning lives next to the artifact instead of vanishing into a chat tool.
Durable interactive prompt widgets for branching decisions, multi-field input, and approvals, so a blocking question survives navigation and restart instead of getting buried in chat.
Walkthroughs and tooltips layered over the same UI when the agent needs to guide the user through a flow.
A voice channel for the same session when the user wants to listen and talk instead of read and type.
Team handoff posts when a session ends, summarizing what shipped, what is still in flight, and what risks remain.

The agent can edit a mockup, render it, compare the screenshot to the request, and then review a red/green diff before merge in the same workspace. A visual workspace keeps decisions attached to artifacts instead of burying them in chat.

8. Coordination

Goal: track every agent.

Failure mode this answers: the human running multiple agents in parallel loses track of who is doing what, where, and why. Work goes into a tab graveyard with no shared memory or hand-off.

One agent on one session is the starting point. Real product work needs many: a planner, an implementer, a reviewer, a researcher, a bug fixer, sometimes a dozen sessions running in parallel on different branches. Coordination is how the human running all of that keeps a single overview: who is doing what, where the hand-offs go, which sessions touched which files, and what's still open.

In our harness that means:

Sessions with persistent metadata (name, tags, phase) listed on a kanban board, so the team can see what every agent is working on at a glance.
Workstreams that group related sessions on the same problem, so a bug that took five sessions to track down stays connected.
A meta-agent so one session can spawn and supervise others: parallel reviewers across pull requests, a sibling session to verify a fix end-to-end, long-running background work that checks back in.
Git worktrees and isolated dev instances so multiple agents can edit the same repo without stepping on each other.
Hand-off briefs when a session ends or spawns a child, so the next session inherits files, links, and constraints instead of starting from a blank prompt.
File-edit history tied to the session that produced it, so overlapping work is visible before it turns into a merge conflict.

A bug triage session can spawn a sibling to reproduce the issue in an isolated worktree, then a third to write the failing test, then a fourth to implement the fix on a feature branch. Each one inherits the relevant slice of the parent's context, runs in parallel where it can, and reports back into the same workstream. With this pillar, the harness itself tracks who is doing what, where, and why.

One bug, all eight pillars

A worked example, drawn from a real workstream we ran. The bug: after a restart, a synced tracker item showed up with an empty body. The body was there in the local database, but the server-side collaborative document had been seeded wrong, so the next session that opened the item saw nothing.

How the eight pillars showed up:

Context. The session loaded CLAUDE.md, which pointed it at the sync architecture doc and the CollabV3 data-isolation rules. A path-scoped rule about Y.Doc seeding loaded automatically because the session touched the sync directory.
Provenance. The bug was filed as a tracker item linked to four prior sessions that had announced "fixed" and were not. Opening the tracker showed the chain in chronological order, so the new session inherited what had been tried instead of repeating it. The eventual fix went into the tracker as a closing note linked to the commit and the Playwright spec that proved it.
Capability. The agent queried the local database through the MCP tool, ran wrangler tail against the sync worker to watch server-side activity in real time, and read the main process log to find a try / catch that had been silently swallowing the seeding error.
Workflow. The session ran as /investigate first, then /design produced a plan document in nimbalyst-local/plans/, then /implement executed against it.
Restraint. The session had read access to the production sync worker but not write access. Every commit went through an approval flow, not a direct push. Restart was on the user, not the agent.
Verification. The first deliverable was a failing Playwright spec that opened a fresh client, seeded a tracker item on the server, restarted, and asserted the body loaded. The spec failed red. The fix turned it green. Only then did the agent announce the bug was fixed.
Visual interface. The agent posted the red-then-green test output inline, a screenshot of the tracker view showing the body restored, and a structured interactive prompt widget in the same workspace asking whether to merge or hold for further review.
Coordination. The session was the fifth in a workstream that had spent multiple days on this bug. It read the parent workstream summary and the linked sessions before writing any code. When it finished, it filed a hand-off brief for the next session to confirm the fix held across a multi-day soak.

The bug took one focused session to close because every pillar carried its share. Any one of them missing and the same workstream would have continued.

What changed once our harness covered all eight pillars

Once we had these pieces in place, a few things changed:

Sessions resumed from prior context without re-prompting the same background every time.
A single prompt could pull in the linked plan, prior session, spec, and affected files through one graph traversal.
We could switch the same task between Claude Code and Codex without rebuilding the workflow above them.
Permission scopes and the audit trail made it practical to let agents run through multi-step work and review after the fact.
Agents could verify their own UI and backend changes through screenshots, log queries, and test loops before asking for review.
The useful parts of a session stopped disappearing with the chat window because the decisions, links, and artifacts remained in the workspace.
Parallel sessions on the same problem stayed coordinated through workstreams and the meta-agent, instead of each one rediscovering the others' work.
Each agent session resulted in better results more quickly

We regularly review transcripts for repeated mistakes and feed the patterns back into rules, linked context, and CLAUDE.md, so the next session does not relearn the same lesson. Decisions made during a session land in the tracker. New skills get written the moment we notice ourselves explaining the same convention twice. The harness gets better every week without anyone setting aside a "harness sprint."

Here is what the eight pillars look like filled in for a single concrete prompt:

Recommendations from our experience

If you are building your first harness this week

Do the boring parts first. They compound the fastest.

Put your specs, plans, diagrams, and checklists in files the agent can read directly.
Add one root instruction file and a small number of path-scoped rules.
Give the agent at least three capability tools: logs, tests, and browser or screenshot access.
Add approval gates for destructive, expensive, or shared-state actions, so capability and restraint grow together.
Link tickets, docs, files, sessions, and commits so future runs can traverse prior work.

Doing those things already moves you from "chatting with a model" to "operating a system that gets better over time."

Multi-agent coordination is a second-quarter problem, not a first-week one. Get one agent reliable first, then worry about how many work together.

If you already have a harness, invest in it

Treat the harness as a product your team ships to itself.

A meaningful share of your AI effort should go into improving the system around the model, not just consuming completions from the model. That means writing better rules, wiring up better MCP tools, recording better decisions, adding better examples, tightening the verification loop, and once you have more than one agent running, giving them ways to coordinate.

Pick one shape of multi-agent coordination, even a simple one: a kanban of sessions, a habit of spawning sibling sessions for verification, or a workstream tag that groups related work. Multi-agent ergonomics compound the same way single-agent rules do.

Pick a percentage of your AI effort that goes to the harness instead of feature work, protect it, and make sure every release cycle includes at least one improvement to one of the eight pillars.

Every rule, tool, example, and link makes future sessions cheaper and better.

Own your harness

You should own your harness: instructions, rules, tool definitions, links between work items, audit logs, reusable skills, and the way your sessions hand off to each other.

If you cannot read it, edit it, version it, point a different agent at it, and take it with you, it is not really yours.

This matters more as models get closer to feature parity. As they converge, the advantage moves up a layer, into your accumulated workflow, your verification loops, your linked decisions, your team memory, and the way you organize a team of agents.

Keep your harness portable across coding agents

Model competition is healthy, and you only benefit from it if your harness is portable.

When a new coding agent arrives, your team should be able to point a session at it without rebuilding the workflow above it. Claude Code today, Codex today, something else tomorrow, with the same files, same rules, same tools, same graph, and same multi-agent shape underneath.

If switching the underlying agent means rebuilding your harness, then you do not really have optionality.

Test the framework against your own failures

The eight-pillar framework is one we arrived at by collapsing every recurring failure mode we hit into the smallest set of pillars that named each one exactly once. Yours might differ. The test we use: can you name a recurring failure of your agent that does not map to a pillar? If yes, the framework is missing something. Can you collapse two pillars without bringing a failure mode back? If yes, you have one too many. Use your own incident log as the source of truth.

Nimbalyst can be one starting point for your harness

Nimbalyst is our open source workspace we use to assemble our own harness across these eight pillars. It lets us run multiple coding agents side by side, so we can point a task at Claude Code, Codex, or whatever lands next without rebuilding the layer above them. The visual workspace, the provenance graph, the capability surface, the file-based instructions, the session model, and the multi-agent coordination are all visible and inspectable.

If you want to see our actual implementation in detail, including the specific files, rules, MCP tools, slash commands, and tracker workflows we use day to day, the living catalog lives in our repository at docs/THE_HARNESS.md. The in-repo doc organizes the implementation slightly differently, but the parts are the same.

Use Nimbalyst directly or inspect it and learn from what we have done there.

The Bugs AI Writes: Five Patterns That Show Up in AI-Generated Code

Karl Wirth — Mon, 20 Apr 2026 16:17:15 +0000

Reviewing AI-generated code has quietly become one of the most time-consuming parts of modern software development. As AI coding tools move from autocomplete to autonomous agents, developers are spending more of their day reading diffs they didn't write.

VentureBeat recently reported that 43% of AI-generated code changes need debugging in production. ByteIota found AI code produces 1.7x more issues per pull request than human code. And 60% of AI code faults are "silent failures" that compile and pass tests but produce wrong results.

The stats alone aren't useful unless you know what to look for. Across thousands of AI-generated diffs, the bug patterns are consistent enough to categorize.

Pattern 1: Plausible but wrong logic

The most common and hardest to catch. AI writes code that looks correct and passes basic tests but handles edge cases incorrectly.

Example: an agent writes a date parser that handles common formats fine but silently converts ambiguous dates like "04/05/2026" using US formatting when the codebase uses ISO 8601. No error, no crash, just wrong data.

AI agents optimize for the happy path. They write code that works for the test cases you'd think to write, but miss implicit conventions.

Catch it: Review AI code like code from a smart contractor who just joined. Check assumptions about data formats, timezone handling, null behavior, and business rules.

Pattern 2: Confident refactoring that breaks callers

When an agent refactors a module, it makes the module internally cleaner while subtly changing the external contract. Renamed parameters, changed return types, modified defaults.

TypeScript catches the obvious interface changes. It doesn't catch behavioral changes three files away where code depended on the old behavior.

Catch it: When reviewing a refactor, search the codebase for every caller of the refactored interface. If the agent says "simplified the return type," check whether any caller depended on the complexity that was removed.

Pattern 3: Tests that test implementation, not behavior

AI writes tests that pass by construction. A common example: tests where the expected value is literally copied from the function's return value rather than independently calculated.

Another variant: mocking everything so the test validates the mocking framework, not the code.

Catch it: Ask: "Would this test fail if the function returned a hardcoded value?" Favor integration tests over unit tests for AI code. Mocks should be the exception.

Pattern 4: Copy-paste drift across similar components

When creating multiple similar components, the agent copies from the first but doesn't copy consistently. One endpoint validates input, another doesn't. One component handles loading states, its sibling doesn't.

Each component looks fine in isolation. The inconsistency only shows when you compare them.

Catch it: Diff similar components against each other. Any difference should be intentional. Inconsistencies usually mean the pattern should be extracted into a shared abstraction.

Pattern 5: Dependency and import sprawl

AI agents install packages liberally. Asked to add a date picker, they'll pull in a new date library even when one already exists in the project.

Catch it: Check whether the project already has a library for the same purpose. Document preferred libraries in CLAUDE.md so the agent knows what's available.

The review process for AI code

AI code review requires different assumptions than traditional review:

Assume no institutional knowledge. The agent doesn't know your conventions unless documented.
Review boundaries, not internals. Bugs live at interfaces: function signatures, API contracts, error handling, data formats.
Test behavior, not implementation. Run the code under real conditions.
Check what wasn't changed. If the agent added a feature, check whether existing error handling still applies.
Scope tasks tightly. A 30-minute, 3-file task is reviewable. A 2-hour, 20-file task is a coin flip.

Why this scales poorly without process

The 43% debugging rate isn't because AI writes bad code. Traditional review catches human mistakes (logic errors, forgotten cases, typos). AI makes different mistakes. Teams that handle this well:

Document everything the agent needs to know (architecture decisions, conventions, preferred libraries)
Scope tasks small enough to review thoroughly
Treat review as a first-class activity, not something to rush through

The code quality bar doesn't change because the author isn't human. The failure modes are less familiar, which means the review process needs to be more deliberate.

Originally published on [*nimbalyst.com/blog](https://nimbalyst.com/blog/bugs-ai-writes-patterns-in-ai-generated-code/). Nimbalyst is a visual workspace built on Claude Code for managing AI coding workflows.*

Author Bio (for all three posts)

Karl Wirth is the founder of Nimbalyst, a desktop workspace built on top of Claude Code that adds visual editing, multi-agent orchestration, session management, and scheduled automations to AI-assisted development. He writes about AI coding tools, agent orchestration, and running a small company that ships a lot.

Claude Code Routines: A Practical Guide from Someone Already Automating AI Workflows

Karl Wirth — Mon, 20 Apr 2026 16:15:03 +0000

Three days ago, Anthropic shipped Routines for Claude Code. If you missed it: a routine packages a prompt, repos, and connectors into a configuration that runs on a schedule, responds to API calls, or triggers on GitHub events. Runs on Anthropic's cloud, laptop can be closed.

I've been building similar automation workflows for months using different tooling (Nimbalyst automations, custom scripts). Routines makes this pattern accessible to every Claude Code user. Here's what I've learned about which automations actually work and where the limits are.

The Three Triggers

Routines support scheduled (hourly/daily/weekly), API (HTTP POST with bearer token), and GitHub event triggers. Each run creates a full Claude Code cloud session with shell access, skills, and connectors.

Workflows That Deliver Real Value

Issue triage (daily/nightly): Scan new GitHub issues, cross-reference with your codebase to identify affected modules, apply labels, estimate priority, post a summary to Slack. The AI doesn't just categorize text; it reads the code and makes informed severity assessments.

Documentation drift (weekly): Scan merged PRs, identify docs referencing changed APIs, open update PRs. This catches staleness before it becomes a support burden. Nobody has time to do this manually, which is exactly why it should be automated.

Deploy verification (event-triggered): After deploys, run smoke checks, scan error logs, post a go/no-go assessment. Not replacing your test suite, but adding an AI review layer that reads logs with more context than threshold checks.

Constraints to Know

Usage caps: Pro gets 5 runs/day, Max gets 15, Team/Enterprise gets 25. Plan your cadences accordingly.
No mid-run interaction: Routines run fully autonomously. Best for tasks producing reports, PRs, or messages. Not for work requiring human judgment during execution.
Cloud-only: Clones your repo to Anthropic's infrastructure. No access to local tooling or network services.

Getting Started

Visit claude.ai/code/routines or type /schedule in the CLI.

Start with weekly documentation drift detection:

Scan PRs merged in the past 7 days. For each, identify docs
referencing modified functions or APIs. If outdated, open a PR
with suggested updates.

Review the first few outputs, calibrate the prompt, then let it run.

The Layered Approach

The most productive setup uses multiple layers:

Event-driven routines for immediate responses (PR triggers)
Scheduled routines for periodic maintenance (nightly triage, weekly doc checks)
Local automations for environment-specific work (custom tooling, workspace context)
Interactive sessions for complex, judgment-heavy work

Trying to push everything through one approach leaves gaps. Routines handle the cloud-native, repetitive layer well. For local environment work, you need complementary tooling.

The Bigger Picture

In the first two weeks of April, Cursor shipped Cursor 3 (agent-first workspace), Windsurf launched 2.0 (Agent Command Center + Devin), and Anthropic redesigned Claude Code with Routines. All converging on the same idea: the developer's role is shifting toward orchestrating agents, not writing every line.

Routines are the automation edge of this shift. Start with one, run it for two weeks, calibrate, then add more. Build your automation layer incrementally.

I'm Karl, building Nimbalyst, a visual workspace on top of Claude Code. I write about AI-native development workflows and what actually works in practice.

Original article on nimbalyst.com/blog.

What actually breaks when you run 5+ Claude Code agents in parallel

Karl Wirth — Mon, 20 Apr 2026 16:13:31 +0000

The parallel-agent workflow stopped being a frontier a few weeks ago. Cursor 3's Agents Window, Windsurf 2.0's free parallel agents, and Anthropic's April 14 Claude Code desktop redesign (multi-session sidebar, per-session worktrees, rebuilt diff viewer, Routines for scheduling) all ship the same core idea: run many agents in isolated worktrees from one surface. If you were still juggling raw terminal tabs last week, upgrade this week.

I've been running four to six parallel sessions every day for the last two months, across and ahead of these releases. Here's what the new tools still don't fix.

1. A session list is not the same as knowing what an agent is doing. A sidebar with a row per session and a status chip beats zsh, zsh 2, zsh 3. It doesn't tell me that session 3 is stuck reconciling three conflicting test fixtures and that I already have notes about those fixtures in another session from last Tuesday. The session is a row. The work is a richer object than a row.

2. Finding the pinging session is better, not solved. "Session 3 needs input" is a real improvement over terminal bells. What's missing is the connective tissue: I want "session 3 (refactor file watcher, linked to tracker #432) is asking whether to keep the old onChange signature" so I can answer in context instead of alt-tabbing into a transcript and reading back.

3. Cross-session diff review is still brutal. Every new tool rebuilt the diff viewer. None of them handle the common case where three parallel agents touch coupled code (file watcher + new IPC handlers + tests for both) and need a single combined review, not three separate ones.

4. Context handoff between agents is still manual. Agent A designs a data model. Agent B writes the migration. Agent C writes tests. Each agent can read the code. What they can't recover is the reasoning from the previous session's transcript, which is where most of the important context lives. Every tool has a transcript, and every transcript is trapped in the session that produced it. It's worse when you mix Claude Code and Codex in the same day (I do — they're better at different things), because now the transcripts aren't even in the same tool. I still end up copy-pasting.

5. Scheduled work needs the whole workspace. Claude Code Routines and Cursor's scheduled agents are here. What's still missing is scheduling that can read and write across the whole workspace: open sessions, tracker items, notes, decisions, yesterday's transcripts. A stateless scheduled script does 60% of that. A scheduled agent with full workspace context does all of it.

The parallel-agent layer is now table stakes. Session management with worktrees is shipped by every serious AI coding tool. The workspace around the sessions (work as a first-class object, cross-session review, shared context that travels, scheduled agents with full workspace access) is still mostly empty, and it has to work across the agents you actually use, not just one vendor's. I'm building into that gap with Nimbalyst, a desktop workspace that runs sessions across Claude Code and Codex in the same project, treats every session as a card on a kanban, keeps transcripts, notes, diagrams, and data models in the same file tree so any agent can read them, and runs scheduled automations that share that context.

If you've hit these same gaps, I'd love to hear how you're solving them. Drop a comment or reply with your setup.

Original article on nimbalyst.com/blog.

I Tried Every Claude Code Editor. Here Is What Actually Works

Karl Wirth — Wed, 15 Apr 2026 18:47:54 +0000

Claude Code itself is not the hard part.

The hard part is everything around it: planning the work, tracking multiple sessions, reviewing diffs, and keeping branch state sane once you stop using it like a toy and start using it like part of your real workflow.

That is what I was optimizing for when I went looking for the best Claude Code interface.

Two disclosures up front:

I care more about workflow than pretty chat UI
I am the founder of Nimbalyst, so I am biased and I should say that plainly

I tried the common options and kept coming back to one question:

Does this tool make Claude Code easier to supervise once the agent is doing serious work?

4. Raw Terminal

This is still the cleanest starting point.

Open a terminal, run claude, and get to work. Nothing is faster for one-off tasks, scripted workflows, or short focused sessions. If you already live in tmux, you can get surprisingly far with this setup.

Where it breaks is not coding. It is management.

Once you have multiple sessions, the terminal becomes a memory test. Which tab owns which task? Which session changed what? Which one is waiting for input? Which branch is safe to merge?

Best for: single-session workflows, shell-heavy users, quick tasks

3. VS Code + Integrated Terminal

This is probably the most common real-world setup.

VS Code gives you a file tree, editor, git panel, and diff viewer in the same place where Claude Code is running. That is enough for a lot of people. You get a better review surface than raw terminal without changing your stack.

The weakness is that Claude Code is still basically "a terminal tab inside VS Code." The editor helps with inspection, but it does not really help with orchestration. If you open three concurrent sessions, you are still juggling tabs manually.

Best for: developers who already live in VS Code and usually run one or two sessions

2. Zed

Zed is the option I would pick if my main complaint was editor drag.

It is fast, visually quiet, and better than heavier editors at staying out of the way. Claude Code works well there because a good terminal, quick navigation, and responsive diff inspection already solve a lot of the daily pain.

The tradeoff is ecosystem depth. If you rely on very specific extensions or highly customized IDE workflows, Zed may feel narrower than VS Code. But if your editor job is mostly "be fast while Claude Code does the heavy lifting," Zed is excellent.

Best for: developers who want speed and minimal overhead

1. Nimbalyst

Nimbalyst is the tool that is designed for the actual bottleneck: agent supervision.

The useful part is not just that it can run Claude Code. It is that it treats sessions, tasks, plans, mockups, markdown, excalidraw, diffs, and supporting artifacts as part of the same job. You can manage multiple sessions, inspect file changes by session, work from plan documents, and review outputs in a way that feels built for parallel agent work instead of retrofitted after the fact.

It also matters that Nimbalyst is not just a shell around the agent. It includes a local code editor, document editors, mockups, diagrams, file history, and mobile monitoring. That makes it materially different from tools whose main value is "nicer transcript UI."

The tradeoff is obvious: it is a bigger system. If you only run one Claude Code session at a time, Nimbalyst may be more workflow than you need. If you run several, the value shows up quickly.

Best for: developers and teams managing multiple Claude Code sessions, plans, and reviews at once

What About Cursor and Windsurf?

They matter, but I think of them differently.

Cursor and Windsurf are strong AI-native editors. I would absolutely consider them if your primary goal is inline AI editing inside the editor itself. But for Claude Code specifically, they are usually complements, not true wrappers. Claude Code still tends to live in a terminal panel while the editor's own AI system handles the native experience.

That makes them good choices for mixed workflows and less clean choices if your question is narrowly:

"What interface is best for Claude Code itself?"

Comparison Table

Tool	Best at	Breaks when	Right user
Raw terminal	Speed and control	You run multiple sessions	tmux and shell-heavy users
VS Code	Familiar editing + diffs	Session coordination gets messy	most developers
Zed	Fast, low-friction editing	You need a broader ecosystem	performance-focused users
Nimbalyst	Multi-session supervision	You only want a lightweight wrapper	daily Claude Code users

What Actually Matters More Than the UI

No interface saves you from a bad workflow.

The three things that matter most are still:

Write a plan before starting the agent
Use git worktrees for concurrent sessions
Review diffs carefully before merging

If you get those right, even the terminal can work.

If you get those wrong, the nicest GUI in the world will mostly help you fail more comfortably.

Final Take

If you use Claude Code occasionally, stay simple. VS Code is enough.

If you are using Claude Code as a daily operating system for real work, the problem changes. You stop needing "a better chat box" and start needing a better control plane.

That is where Nimbalyst is focused.

Karl Wirth is the founder of Nimbalyst, a local workspace for Claude Code and Codex.

Claude Code Development Workflow: Tools and Setup Guide for 2026

Karl Wirth — Wed, 15 Apr 2026 18:44:16 +0000

Claude Code gets dramatically better when you stop treating it like "a chatbot in a terminal" and start treating it like part of a repeatable engineering workflow.

The difference is usually not model quality. It is setup quality. Teams that get strong results do the same few things over and over: give the agent persistent context, write plans before prompting, isolate concurrent work, and review output like it came from a fast junior engineer.

This is the setup I recommend if you want Claude Code to be useful on real projects, not just impressive in demos.

TL;DR Setup Checklist

Add a project-level CLAUDE.md
Create short plan docs before starting implementation
Use git worktrees for concurrent sessions
Auto-approve safe operations, but keep risky ones gated
Pick one review surface and use it consistently

Running concurrent sessions in one directory

Every serious Claude Code workflow starts here.

Without a root CLAUDE.md, every session has to rediscover your architecture, commands, conventions, and constraints. That wastes prompt budget and leads to avoidable mistakes. With it, the agent starts from a usable baseline.

A good CLAUDE.md is short, concrete, and opinionated:

# CLAUDE.md

## Project Overview
Monorepo for a React frontend, Node API, and PostgreSQL database.

## Development Commands
- Start web: `npm run dev:web`
- Start api: `npm run dev:api`
- Test: `npm run test`
- Lint: `npm run lint`

## Architecture
- `/apps/web` - React frontend
- `/apps/api` - HTTP API
- `/packages/ui` - shared components
- `/packages/db` - schema and queries

## Conventions
- TypeScript strict mode
- Zod for request validation
- Never query the DB directly from route handlers

## Guardrails
- Do not change auth middleware without explicit review
- Keep migrations backward compatible
- Prefer existing patterns over new abstractions

The key is specificity. "Use TypeScript" is weak. "Use TypeScript strict mode and validate requests with Zod" is useful.

Claude Code gets much better once it can inspect more than the current file tree.

The three categories that matter most are:

Repository context: GitHub or git tooling so the agent can understand issues, PRs, and branch state
Data context: schema or safe query access for local/dev databases
Project context: any internal tools, docs, or MCP servers your team already relies on

The mistake here is over-configuring. Do not hand the agent ten tools you barely trust. Start with the few that meaningfully improve accuracy.

3. Set Permission Rules So the Agent Is Fast but Not Reckless

The default "ask me for everything" experience is safe and miserable. The opposite extreme, where the agent can do anything without friction, is how you end up approving bad work after the fact.

A practical default looks like this:

Auto-approve reads inside the repo
Auto-approve writes inside the repo
Auto-approve test runs and other common safe commands
Keep approvals for installs, git history rewrites, and anything outside the project

You want Claude Code to move quickly through normal implementation, but you still want a hard pause on operations that change system state or create cleanup work.

4. Write a Plan Before You Prompt

This is the highest-leverage habit in the entire workflow.

Do not start with:

build me user authentication

Start with a plan document in markdown that you iterate on with the agent:

# Feature: User Authentication

## Goal
Session-based auth with registration, login, and password reset.

## Constraints
- Use bcrypt
- Store sessions in PostgreSQL
- Rate limit login attempts
- All routes under `/api/auth/*`

## Acceptance Criteria
- [ ] User can register
- [ ] User can log in and get a session cookie
- [ ] User can reset password
- [ ] Failed logins are rate limited

Then point Claude Code at the file:

claude "implement docs/auth-plan.md"

This is better than a long natural-language prompt because the plan becomes reusable. You can refine it, hand it to another agent, or review the finished work against it.

5. Use Git Worktrees for Parallel Sessions

If you run more than one Claude Code session at a time in the same checkout, you are choosing pain.

Use worktrees instead:

git worktree add ../project-auth -b feature/auth
git worktree add ../project-tests -b feature/auth-tests
git worktree list

Now each session gets:

its own branch
its own working directory
no file collisions with the others

That is the foundation for reliable parallel work.

Example:

# API work
cd ../project-auth
claude "implement docs/auth-plan.md"

# Test work
cd ../project-tests
claude "write tests for docs/auth-plan.md"

Worktrees are the single best upgrade for anyone moving from "one agent sometimes" to "multiple agents regularly."

6. Pick a Session Management Pattern

Once you have parallel sessions, you need a way to keep them straight.

Three reasonable options:

Terminal tabs: fine for one or two sessions
tmux: still the power-user default for keyboard-heavy workflows
Nimbalyst: useful if you want a visual board for sessions, file changes, diffs, and plan artifacts in one place

The right choice depends on your failure mode.

If your issue is "I lose track of which session is running where," a visual session surface helps.

If your issue is "I want everything on one keyboard-first screen," tmux is still excellent.

7. Review Like the Agent Is Usually 90% Right

Claude Code is often right enough to feel finished before it actually is.

That is why review matters. The common misses are not obvious syntax errors. They are:

slightly wrong edge-case handling
assumptions about existing abstractions
tests that prove the happy path but not the failure path
code that works but does not match local conventions

For small changes, git diff or your editor is enough.

For larger changes, use a proper review surface:

editor diff view
draft pull request
a tool that tracks per-session file changes and inline diffs

The more files an agent touches, the less acceptable "quick skim and merge" becomes.

8. My Default Claude Code Loop

This is the loop I would teach a team:

Write or update a short plan
Create a worktree
Start Claude Code against that plan
Let it run until it blocks or finishes
Review the diff against the plan
Fix or redirect
Merge and remove the worktree

That is the whole system. Most of the value comes from doing that loop consistently.

Common Mistakes

Starting from a blank prompt

If you skip the plan, Claude Code fills in the blanks with its own assumptions.

Over-specifying implementation

Tell the agent what good looks like, what constraints matter, and what must not break. Do not micromanage every function unless there is a real reason.

Reviewing too late

Do not wait until a giant session is "done" before looking. Review earlier on bigger tasks.

Final Take

The best Claude Code workflow is not complicated. It is disciplined.

Persistent context, short plans, worktree isolation, and careful review beat almost every fancy trick. Once those pieces are in place, you can decide whether you want to stay in a terminal, live in tmux, or use a more visual workspace around the agent.

Without that foundation, the tool choice barely matters.

Karl Wirth is the founder of Nimbalyst, a local visual workspace for building with Claude Code and Codex.

Best Practices for Coding with Agents

Karl Wirth — Mon, 09 Mar 2026 15:58:45 +0000

You already know coding agents can write code. The interesting question is what happens when you stop thinking of them as code generators and start treating them as junior developers who need good specs, clear test criteria, and visual references — just like a human would.

We build Nimbalyst this way every day. Here’s our workflow:

Write a plan in markdown. Edit this. Iterate.
Have the agent enrich it with architecture diagrams and data models. Edit this. Iterate.
Iterate on mockups until the UI is right
Have the agent write tests from the acceptance criteria. Edit this. Iterate.
Tell it to implement until tests pass
Walk away. Check in from your phone.
Review the work. Suggest changes.
Commit
Update plan document, documentation, website

Each step produces context that the next step consumes. By the time the agent starts writing code, it has the spec, the architecture diagram, the database schema, the mockup, and the test suite — all in one workspace, all visible to it. That’s why it works.

Plan First

Every feature starts as a markdown file with YAML frontmatter: status, priority, owner, acceptance criteria. We type /plan and iterate on the document with the agent until the goals and implementation approach are solid.

Plan document with YAML frontmatter, status bar, and inline AI diff in Nimbalyst

The plan isn’t a throwaway note. It tracks status as work progresses (draft -> in-development -> in-review -> completed), versions with git alongside the code, and serves as the single source of truth. When the agent later implements, it reads this document. When we review the work, we compare against it.

The difference between this and a Jira ticket: the plan is a rich markdown document that the agent can actually parse and act on, not a text field nobody reads.

Diagrams and Data Models in the Same Workspace

A text plan can only communicate so much. We ask the agent to add visual context:

“Add an architecture diagram showing the WebSocket connection flow between the client, server, and notification service.”

It creates an Excalidraw diagram in the workspace. We see it rendered, drag things around, tell the agent to adjust (“move the queue between the API and the notification service”), and iterate until the architecture is clear.

Excalidraw architecture diagram with AI chat sidebar in Nimbalyst

For database work, we ask for a data model:

“Create a data model for the notifications schema.”

The agent generates a .datamodel file that renders as a visual ERD. Tables, foreign keys, field types, all editable. We review it, ask for changes, the agent updates it.

Data model rendered as visual ERD with AI chat in Nimbalyst

The critical thing: these artifacts live alongside the plan and the code. When the agent later implements, it doesn’t need us to re-explain the architecture or the schema. It reads them directly.

Mockup, Annotate, Iterate

For anything with a UI, we create mockups before touching code. The agent generates .mockup.html files — real HTML/CSS that renders live in the workspace.

HTML mockup with before/after diff slider and AI chat in Nimbalyst

We review visually. Use annotation tools to circle what needs changing. The agent sees the annotations, understands the spatial context, and regenerates. Three or four rounds and the mockup matches what’s in our heads.

This replaces the Figma-to-engineering handoff entirely. The mockup is already in the workspace. When the agent implements the UI, it already knows what it should look like. No exporting, no describing screenshots in words, no “make it look like the design.”

Tests Before Implementation

Before writing any implementation code, we have the agent write tests. This is where the earlier context pays off.

“Write Playwright E2E tests for the notification center based on the plan and mockup.”

The agent reads the acceptance criteria from the plan, references the mockup for expected UI behavior, and generates test cases. We review them, add edge cases, and now we have an executable definition of “done.”

Every test fails. That’s the point.

Implement Until Green

Now we tell the agent:

“Implement the notification system. Run tests after each major change. Keep going until all tests pass.”

The agent works iteratively. Implements the database migration from the data model. Runs tests — schema tests pass. Builds the WebSocket server. Runs tests — connection tests go green. Implements the frontend. Runs Playwright — catches a CSS issue from the screenshot, fixes it, reruns. Eventually: all green.

This isn’t prompt-and-pray. The agent has the plan for architecture guidance, the data model for the schema, the mockup for the UI, and the test suite for verification. It loops through code-test-fix cycles autonomously.

Walk Away, Check In From Your Phone

Once the plan is solid, the tests are reviewed, and the agent is pointed in the right direction, we don’t sit and watch. We go to lunch. Take a meeting. Go for a walk.

The agent keeps working.

When it finishes or needs input, we get a notification on our phones. The Nimbalyst mobile app shows session status, the full transcript of what the agent did, and file diffs. If the agent needs a decision, we tap our answer and it continues. If all tests pass, we review the changes from wherever we are.

Nimbalyst mobile app showing active agent sessions and status

Nimbalyst mobile app showing file diff review on phone

This is not “set it and forget it.” We stay engaged. But the engagement happens on our terms — on the train, at the coffee shop, between meetings. The agent’s work doesn’t stall because we’re not at our desk.

Review the Work

When the agent finishes, we review. Nimbalyst shows every file the agent touched in a sidebar, with full diffs for each one. We click through the changes, see exactly what was added, modified, or removed, and compare it against the plan and mockup.

Diff review showing file changes with red/green inline diff in Nimbalyst

This isn’t reading a pull request cold. We wrote the plan, reviewed the tests, and approved the mockup. The review is checking whether the agent followed through on decisions we already made. It usually did. When it didn’t, we tell it what to fix and it iterates.

The files sidebar makes this fast. We see the full scope of changes at a glance — no scrolling through a massive diff. Click a file, review it, move on.

Commit

Once the review looks good, we commit directly from the workspace. Nimbalyst has a built-in git commit flow — the agent proposes a commit message based on the changes, we review or edit it, and commit.

Git commit dialog with AI-proposed commit message in Nimbalyst

No switching to a terminal. No copying file lists. The commit happens in context, right after the review, while everything is still fresh. The agent’s proposed message is usually accurate because it knows what it did and why — it read the plan.

Update the Plan and Docs

After committing, we close the loop. The plan document gets updated: status moves from in-development to completed, acceptance criteria get checked off, and any implementation notes get added for future reference.

Session kanban board showing work items across phases in Nimbalyst

We also update documentation, CHANGELOG entries, and website content if the feature is user-facing. Because the agent has full context of what was built, it can draft these updates too. We review and merge.

This step matters more than it seems. Without it, plans drift from reality, docs go stale, and the next person (or agent) working in the area starts from incomplete context. Closing the loop keeps the workspace honest.

Why Context Continuity Is the Real Unlock

Coding agents are good at writing code. What limits them is context fragmentation.

In a typical setup, the spec lives in Confluence, the mockup in Figma, the tasks in Jira, the tests in your IDE, and the agent runs in the terminal. The agent gets fragments through MCP calls or copy-pasted text. It’s reading a book one sentence at a time through an API.

This workflow works because every artifact — plan, diagram, data model, mockup, test, code — lives in the same workspace and is directly readable by the agent. No handoffs. No context translation. No “let me describe what the Figma mockup looks like.”

The result:

Plans give the agent architectural direction it can actually follow
Diagrams show how pieces connect without verbal explanation
Data models define the exact schema to implement
Mockups provide a pixel-accurate UI target
Tests give a machine-verifiable definition of done
One workspace means none of this is lost in translation
The agent isn’t smarter in this workflow. It just has everything it needs.

The Workflow

Plan. Enrich with visuals. Mockup the UI. Write tests. Implement until green. Review from anywhere. Commit. Close the loop.

We ship features this way every day. The agent handles the mechanical iteration. We focus on the decisions that actually require a human: what to build, what the architecture should look like, whether the tests cover the right scenarios, and whether the final result is what we wanted.

That’s how we build Nimbalyst, and it’s how Nimbalyst is designed to let you build too.