If you’re building a custom tool or IDE in 2026, AI has changed your project on three levels at once: who your users are, how the tool should be designed, and how it gets built. In February 2025, we published our guide to building a custom IDE or tool, with AI strategy listed as one consideration among eight. That framing is outdated now. AI is no longer a decision you make alongside the others. It reshapes several of them.

This article is the update. We keep what still holds from the 2025 guide, condensed with links back for depth, and spend most of this piece on what’s actually new.

Defining purpose, audience, and MVP is still the first step, and nothing about it changed with AI. Know who uses the tool, what problem it solves, and what the smallest viable version looks like before you touch the stack. Our 2025 guide covers this in detail.

What’s new: AI capability feeds back into the workflow itself. The more a model can do, the less the old sequence of steps holds up as designed. Some steps disappear, others merge, and new checkpoints appear where a human needs to step back in.

Plenty of advice right now says to throw out how your users have worked for years and design the workflow AI-native from scratch. We take that route ourselves when a domain is ready for it. The risk comes from treating it as the starting point. Committing to a full redesign before you’ve shipped anything is exactly where projects stall, especially in domains with decades of accumulated workflow.

What works more reliably is starting from the existing workflow and using targeted prototypes to test, step by step, what AI can actually take over if you expose the right functionality and data to it. That process tends to surface workflow changes on its own: sometimes all the way to a full AI-native redesign, sometimes only to automate certain parts of the workflow. Either is a fine outcome when it’s driven by what you learned from real use.

AI changes the users, the design, and the way the tool gets built.

For a long time, a tool had one kind of user: a human sitting in front of a UI. That’s no longer true. Increasingly, an AI agent uses your tool too, calling its functions, reading its state, and driving its workflows on someone’s behalf. Supporting that second user isn’t just another small architectural decision. It can require running the tool, or the parts an agent needs, headless and callable without a UI in front of them at all.

It also raises a strategic question early: should your tool come with an agent of its own, with an integrated workflow, or should it primarily provide capabilities that other vendors’ agents can use? It also reshapes your UX, since reviewing and steering an agent’s progress is a different interface problem from enabling humans to make changes themselves. We’ll come back to that in the next section.

MCP is the most talked-about way to expose capabilities to agents, but it’s not the only one. A CLI, often paired with a skill file that tells an agent how and when to use it, is just as common a pattern in 2026. For some tools, it’s the more natural fit. If a CLI is already on your requirements list for scripting or CI, adapting it for agents can be a smaller incremental effort than building and maintaining a separate MCP server. It still requires suitable documentation, as well as optimizations and guardrails for agent use. Choose based on what best enables agents to address your users’ needs, not on which protocol currently gets more attention.

Whichever surface you choose, designing it well for an agent is a different skill from designing a good human-facing API, and it’s a place where experience pays off. An agent needs to understand your API from its schema and docs alone, without a human clarifying edge cases in a support channel. It also often needs things a traditional API doesn’t: a confirmation step before an irreversible action, a dry-run mode, integrated filtering mechanisms to avoid overflowing the context, structured output instead of formatting meant for a terminal, a way to set context once (like a project) instead of repeating it on every call, error messages that steer the agent towards a working alternative, or a guardrail that blocks a technically valid but obviously wrong call before it executes.

A single API for both human and agent callers sounds attractive because it leaves only one surface to maintain. In practice, that can make the API worse for both: too rigid for a human integration and too open-ended for an agent to use safely. A pattern that holds up better is a deterministic, general-purpose API as the core, with a narrower, agent-specific API layered on top and built with the guardrails agents actually need.

That agent layer doesn’t have to be a from-scratch redesign. We’ve seen more than once that an existing, well-documented API that shipped early enough to end up in an LLM’s training data gives the model a real head start in understanding it, one a clean, novel redesign doesn’t have. Whether that head start outweighs a purpose-built agent API is worth testing case by case.

Treating a generic agent-facing API as the whole answer misses a real, current debate. Three strategic decisions usually appear:

• Not every user of a domain-specific tool is fluent with a generic agent chat interface. Many expect a workflow tailored to their domain rather than a blank prompt box. On the other hand, a chat interface equipped with the right tools lets users create their own agentic workflows and address use cases you haven’t anticipated.
• For domain-specific tools especially, owning the full flow, including prompts, context assembly, and the review UX, tends to produce noticeably better results than handing that control to a generic harness. That control is often where the actual efficiency gains sit. Operating your own agent also adds concerns such as subscription management, rate limiting, and authentication.
• Relying entirely on a third-party commercial harness removes many LLM-provider hurdles, but it can also create business risk. The market is intensely competitive right now: agent products get acquired, rebranded, or rebuilt on a different underlying model within weeks, and pricing and access can shift just as fast.

A practical answer is not to bet on one fixed strategy. Ship your own integrated agent experience, tailored to the tool’s domain and UX so you control the harness, and expose the same capabilities through a standard surface such as MCP, a CLI, or both for external harnesses to connect to. Build the automation layer well, and the embedded agent and external surface can use the same underlying functions. Modern agent frameworks can make that second front door a relatively small addition rather than a separate project.

A modern tool has two types of users: humans and AI agents.

AI reshapes more of a tool’s UX and architecture than one article can cover. These are the considerations that show up on nearly every project.

If AI performs a workflow step, or a whole workflow, the UX challenge shifts. It stops being about how efficiently a human can create a change and becomes about how efficiently a human can review, steer, and trust what the AI produced. That’s a different design problem: diffs instead of forms, confidence signals instead of validation messages, and an easy way to correct a suggestion instead of just accepting it.

A code review agent is a clean example. The value isn’t in generating comments. Most agents do that reasonably well already. The value is in a UX that lets a reviewer scan, correct, and approve findings in seconds instead of minutes. Review-centric UX is worth designing for from the MVP stage rather than retrofitting once an AI feature ships.

That review-centric UX runs in both directions. An agent can use the tool’s own UI to show a human its state or intermediate steps, often more clearly than a chat transcript can. This is especially useful when a tool has been in use for a long time and domain experts are already very familiar with how it presents models and data.

The same UI can help a human build the context an agent needs. Selecting the right diagram elements, marking the relevant part of a trace, or pointing at the one row that matters is usually faster and more precise than describing it in a prompt.

None of this means retiring the traditional, non-AI UX. In regulated or IP-sensitive domains, not every user is allowed to send data to a model yet, and some don’t want to regardless of the rules. An AI-only interface is often too early for exactly the kind of tool that could benefit most from AI.

Plan for both as a day-one architectural decision: a traditional UX for the users and cases that need it, and a review-centric, AI-assisted UX layered on top for the rest. Integrating the two well can be challenging, but it is also an opportunity. When editing and reviewing are designed to work together, they can reinforce each other naturally.

Feeding AI the right context is also an architectural concern now, not an implementation detail you solve with a bigger prompt. Models need access to your tool’s domain data and state: the model in your diagram editor, the requirements in your ALM tool, the trace data in your analysis tool. How that context gets assembled, kept current, and scoped to what a given task actually needs shapes your data layer and your APIs. It’s cheaper to design that in from the start than to bolt it on later.

The same argument applies to the tool’s own capabilities. Cutting them into smaller, independent pieces with clean interfaces rather than one monolithic feature block pays off in ways that are new in 2026. Agents work far more reliably with focused, well-scoped capabilities than with one do-everything API. The same pieces can serve the human UI and the shared agent surfaces from section 2 without being rebuilt for each caller.

Individual pieces can also be replaced or rebuilt when a better approach arrives. AI-assisted development makes that a more contained effort than it used to be. This doesn’t mean maximal fragmentation. Every seam carries an integration and versioning cost. It means cutting along the lines where callers differ and where change is most likely.

Finally, keep the interface between your tool and the LLM narrow and swappable. The gap between frontier models closes and reopens every few months, so a stronger or cheaper model should be a configuration change, not a rewrite. The same applies to concepts around the model. Skills, MCP, and whatever comes next arrive quickly enough that your architecture needs room for new integration points without major surgery.

That doesn’t mean adopting every new standard the week it ships. Chasing every acronym is its own way to never ship anything stable. Leave room for the next integration point, and be deliberate about which ones actually earn a place in your architecture.

When AI performs a change, the UX shifts from creating to reviewing, steering, and approving.

We’ve collected dozens of specific lessons on integrating AI into a tool. Two are worth calling out here.

Don’t over-optimize the AI part on day one. If a workflow already meets your users’ quality needs at an acceptable cost in tokens, latency, and manual correction, further optimization may not be the best use of your time. Ship based on what today’s models can reliably deliver. A newer model will likely improve quality or reduce cost. Building for tomorrow means being ready to test and adopt those gains, not depending on them to deploy today’s feature.

That makes the second lesson even more important: deploy AI features fast, on the flexible basis described above, and treat them as always in motion. Ship with a clear label for what users should and shouldn’t expect yet, learn from how the feature is actually used, and tune or rebuild as user feedback and model changes warrant.

None of this works without guardrails, using the same discipline described for agent-facing APIs in section 2. For the feature itself, that means making limitations explicit and giving users an easy way to review, correct, or undo its output. With those in place from the start, “good enough today, evolving fast” is a legitimate way to ship AI rather than an excuse to skip quality.

Keep the initial quality bar practical, not perfectionist. Test representative tasks to establish that the feature can help, then get it in front of users early, through an opt-in preview where appropriate. Judge its value by the overall workflow, including the effort of reviewing and correcting its output, rather than expecting every result to be right. Let real usage reveal where it works, where it falls short, and which improvements matter most. Turn those lessons into lightweight evaluations as the feature and models evolve.

This shift can feel uncomfortable in domains where both tool builders and users are accustomed to deterministic workflows. Clear communication and alignment with early users matter: what can they expect, what still needs checking, and how will their feedback shape the feature? You know your domain and users best, so tailor the scope and rollout with them rather than applying a universal “ship fast” rule. Apply a higher bar where mistakes are hard to detect or undo, but look for opportunities to start learning early where they are not.

There are more AI-specific lessons than fit in one section; we’ll cover them in a dedicated follow-up post on AI-native tooling; follow us on LinkedIn to catch it when it’s published.

Ship AI features when they create value, not only when they are perfect.

Before picking a platform, decide whether you should build a custom tool at all. Our 2025 guide covers the make/reuse/buy decision in detail.

AI changes the calculus here more than any other step in this list. Custom development used to be the expensive option by default, which pushed many teams toward reuse or buying even when it was a mediocre fit. With AI-assisted development, the cost of building custom, especially for well-scoped, pattern-heavy parts of a tool, has dropped substantially.

That doesn’t mean building everything yourself. Reusing a mature foundation still saves you from reinventing a workbench, a file explorer, or an LSP integration, and buying still makes sense when a commercial product is a strong fit. But the threshold at which “just build it” beats “reuse or buy” has moved. It’s worth revisiting the decision with 2026 economics instead of carrying over assumptions from before AI.

The platform question hasn’t changed in principle since 2025: web-based technology stacks are the default, even when the result ships as a desktop app. Our 2025 guide and our piece on the shift away from Eclipse RCP cover the reasoning in detail.

One thing is worth a short update. Electron remains a safe, mature default for a browser-based desktop shell, but it’s no longer the only credible option. Tauri reached a stable, production-ready release with mobile support, and it’s a real alternative when bundle size and memory footprint matter more than plugin maturity for your case. Choose based on your actual constraints, not on which one is currently trendier.

More interesting is a shift in why deployment flexibility matters. Web-based tools shipped as desktop apps have proven surprisingly durable. Local files, hardware access, and data that must stay on-device keep that model relevant well beyond what many predicted.

Long-running agents change the calculus. An agent that works autonomously for minutes or hours shouldn’t depend on a laptop staying open, and several agents working in parallel on the same tool want isolated sessions rather than one shared local instance. Neither fits the classic desktop assumption of one user, one machine, one live session.

That doesn’t require going cloud-first. But an architecture that can run its capability layer server-side, detached from any UI session, is likely to become one of the more valuable options you can keep open. Conveniently, that’s the same headless capability layer that agent support already asks for in section 2.

Web-based technology stacks are the default for building tools, even when the result ships as a desktop app.

If your requirements list looks like most tools’ do, with a workbench, an editor, a file explorer, a menu system, Git integration, and an AI chat panel, reinventing all of it from scratch is rarely worth it. Reusing an existing tool or framework as a foundation still makes sense in most cases, for the same reasons as in 2025: time saved, ongoing maintenance from a wider community, and an existing plugin ecosystem. Our 2025 guide goes into the criteria in detail: feature alignment, UX fit, customization depth, and the health of the community behind it.

It’s easy to underestimate how much of that value has nothing to do with how fast you can write the first version. AI makes building custom faster, but it doesn’t harden your dependencies for you, carry you through a major framework or runtime upgrade, or keep pace with new AI standards and protocols as they show up. A mature foundation does that work continuously. It also gives you a plugin ecosystem, where third-party and community-built features can plug into your tool without your team having to build all of them.

The options themselves haven’t consolidated to one obvious winner. Extending VS Code through extensions, or forking it or code-oss directly, keeps you close to a familiar IDE shell at the cost of working within that shell’s UX. If your UX needs to diverge further, you can use a modular framework such as Eclipse Theia, built to be adapted extensively, or build custom on a web framework plus a set of editor and diagramming components such as LSP and GLSP clients.

Custom tends to fit lighter-weight tools. The closer you get to needing a full workbench, the more you’d end up rebuilding what an existing framework already provides.

For a brand-new project, a desktop-native, non-web foundation such as Eclipse RCP is now an edge case rather than a serious default contender. Offline capability and hardware integration, the traditional reasons to reach for it, can also be handled by modern web stacks. It still makes sense when a new piece has to plug directly into an existing large RCP application, or into a certified toolchain that can’t move for regulatory reasons.

AI capability is now part of the same foundation evaluation, and it can outweigh other selection criteria. Does the foundation give you a place to plug in a review-centric UX and an MCP server or CLI without fighting the framework? Does it let you swap models without rewriting your integration?

Keeping up with AI’s pace on your own is hard, especially with new mechanisms such as MCP, Skills, and Plugins, new model-provider APIs, and techniques like prompt caching arriving constantly. A foundation that already integrates well with AI can carry much of that weight for you. Many platforms also let you work transparently with LLMs you control or ones bundled into a subscription such as Copilot, so you can adapt your delivery strategy later without much cost. Frameworks vary a lot here, and it’s worth testing specifically for this in a PoC rather than assuming any foundation handles it well by default.

Long-term governance and viability deserve a place on this list too. A fast-moving, single-vendor-controlled platform can serve you well for years and still change direction with little warning, deprecate something you depend on, or optimize for a very different set of users. A foundation with open, vendor-neutral governance gives you a way to influence that direction, or in the worst case to keep maintaining it yourself, instead of simply absorbing whatever the vendor decides next.

There’s no universally right foundation. The right one depends on your requirements, your team’s skills, and how much control you need over the UX. This is also where platform-agnostic expertise is worth the most: knowing the trade-offs of several foundations well enough to pick the one that actually fits, rather than defaulting to whichever one you already know.

No single foundation wins by default. The right choice depends on your requirements and UX.

PoCs were always the right way to de-risk a tool or IDE project before committing to a full build, and that applies to UX and workflow decisions as much as to architecture. It’s the same prototyping approach from section 1: testing step by step what AI can actually take over.

What changed is the cost of building one. AI-assisted development makes a PoC dramatically faster to put together, which means you can afford to build more of them, earlier, and answer more open questions before committing to an approach.

Use that headroom deliberately. Don’t limit it to technical risk. Build a PoC for your riskiest assumption, whether that’s which part of a workflow AI can actually take over, a review-centric UX that looks right on a whiteboard but hasn’t been tried by a real user correcting an agent’s mistake, or whether your chosen foundation actually handles an integrated agent, an MCP or CLI surface, or swapping models well.

A lower cost per PoC doesn’t lower the bar for a good one. It still needs a clear question to answer and real user feedback.

AI-assisted PoCs create a trap of their own. A working prototype is easy to vibe-code in a day, and because it already runs, it can quietly grow into the production codebase without anyone ever deciding that. A PoC isn’t held to production standards on purpose: thin error handling, no real tests, shortcuts everywhere. That’s fine as long as moving from prototype to product is a conscious step.

Revisit the architecture, harden what the fast first pass skipped, and review the generated code with the same rigor as any other contribution. Skip that step, and the PoC’s shortcuts become the production system’s technical debt on day one.

AI makes PoCs faster and cheaper, but don't let prototypes quietly become production code.

The roles from the 2025 guide still apply: domain experts who understand the workflows, tool-building experts who know the frameworks and protocols, and UX designers who can design for a technical audience. Our 2025 guide covers why each of these matters.

What’s added in 2026 is AI-coding fluency as a distinct skill on top of the others. A team that combines domain expertise, tool-building experience, and strong AI-coding practice doesn’t just move faster. It produces a different quality of output because the judgment behind every AI-assisted decision, what to ask for, how to evaluate the result, when to accept it, and when to push back, compounds with expertise.

The gap between an expert team using AI well and a less experienced team using the same tools is wider than the gap was before AI, not narrower. Teams that stay fluent across more than one coding agent tend to notice sooner when a tool starts falling behind and adapt faster.

There’s a second, narrower skill worth distinguishing from general AI-coding fluency: knowing how to build with AI, not just use it. Designing the context an agent needs, wiring up guardrails and confirmation steps, and building evaluations that tell you whether a model is reliable enough for a given workflow are different, more specialized skills than using an AI coding assistant well.

It’s also a very young field. Almost nobody has more than a few years of hands-on experience with it because the models themselves are only a few years old. Where real, proven experience exists, it tends to sit with teams that have been building AI-powered products in production rather than just experimenting with them.

We wrote in detail about how this plays out inside our own team, including adoption numbers, tooling choices, and where we think a software engineering company’s value actually sits in the age of AI, in AI (Coding) at EclipseSource: The Internal Story. If you’re building this fluency in your own team, that’s also what our Systematic AI Coding training is for.

The strongest teams combine domain expertise, tool-building expertise, and AI fluency.

Everything above still applies, but a migration comes with its own specific questions: what to reuse, how to run two tools in parallel during the transition, and how AI changes the economics of that particular kind of project. We’re covering that separately in an upcoming 2026 migration guide; follow us on LinkedIn to catch it when it’s published.

In this space, only one prediction holds reliably: AI will get more capable. Which workflows it absorbs, which standards win, and which products survive is much harder to call even a year out. The best preparation isn’t a better forecast. It’s flexibility: an architecture built to adapt, paired with development and deployment cycles fast enough to react in weeks, not quarters.

The high-level considerations from our 2025 guide still hold: purpose and audience, platform, foundation, PoCs, and team. What changed is that AI now reshapes several of them, from who uses the tool to how quickly you can validate an idea before committing to it.

Making these decisions well takes domain knowledge, tool-building expertise, and practical experience both using AI and integrating it into products. Getting that combination right may be the highest-leverage decision on this list.

If you’re planning or staffing a tool or IDE project and want a partner who can help you work through these decisions, platform-agnostic and grounded in daily AI-coding practice, we’d like to hear from you.

👉 Our service offerings for building custom tools and IDEs

👉 Our service offerings for building web- and cloud-based tools

👉 Our service offerings for AI-powered tools and IDEs

👉 Systematic AI Coding training

👉 Get in touch with us to talk about your project

💼 Follow us: EclipseSource on LinkedIn

🎥 Subscribe to our YouTube channel: EclipseSource on YouTube