The clickbait version of this post would probably be: “Is the IDE dead?”
I do not think that is the interesting question. Editors are not disappearing, and I still think there will be many moments where opening a file, reading the code, and making a precise change is the right thing to do. The more interesting question is what happens when the IDE is no longer the main surface where software work happens.
Gartner recently described the enterprise AI coding agent market as entering a “new phase of expansion and competitive realignment,” but the line that stood out to me was this:
“Enterprise AI coding agents mark a transformative shift from AI-assisted development to agentic software development, spanning the SDLC from planning to creating to reviewing code. Gartner predicts that by 2027, over 65% of engineering teams using agentic coding will treat integrated development environments (IDEs) as optional, shifting control, governance, and validation to automated platforms.”
That is exactly the direction I have been thinking about while building Fabriqa.ai.
For me, this is not just about better autocomplete, and it is not even just about AI editing files for us. The bigger change is the interface itself. In the old workflow, the developer opens an IDE, navigates files, edits code, runs commands, checks logs, previews the result, and uses AI somewhere inside that process. In the agentic workflow, the starting point is different: you describe the work, the agent inspects the repo, plans the change, modifies the code, runs commands, opens previews, checks logs, and brings back artifacts for review.
That starts to look less like a traditional file editor with a chatbot attached to it, and more like an Agentic Development Environment: chat as the main interaction surface, with artifacts, diffs, logs, embedded browsers, internal helper panels, previews, and validation results around it. The editor still matters, but it is no longer the only control surface.
The original Fabriqa bet
This was the original bet behind Fabriqa. I started building it at the beginning of January, mostly over weekends in very long sessions, and on weekdays after work until I could no longer keep my eyes open. By the beginning of March, I had released the first public beta. When I later looked at the commit history, even that conservative proxy showed the pattern: around 90% of analyzed commits happened outside regular weekday working hours.
Recently, even the remaining activity became interesting for a different reason. As models became better at long-horizon work, especially when the work is defined through proper specs, the workflow stopped being “me sitting at the keyboard while the agent works.” I now use Fabriqa to build Fabriqa: I create a list of specs, spin up multiple worktrees, let agents run on my Mac mini during the day, and then review the output at night or over the weekend before tweaking, validating, and merging the work back. GPT-5.5 has become my favorite model for this kind of work because I can kick off a meaningful task, let it run for hours, and come back later to review the result.
That experience made the ADE idea very concrete for me. I did not build Fabriqa by sitting inside a traditional IDE and writing code line by line. The work was driven through agents: specs, prompts, plans, generated changes, reviews, validation, worktrees, and iterations. In many ways, it started to feel like a small software factory running on my Mac mini, and that was not accidental. The factory idea was part of the Fabriqa vision from the beginning, which is why the name felt right when I bought the domain.
The market is moving toward the same shape
In the last few weeks, this shift became much harder to ignore. Gartner put the market language around it, GitHub introduced the Copilot app as an agent-native desktop experience, Cursor wrote that cloud-agent work increasingly looks less like porting a local agent to a server and more like building an operating layer around it, and Google Antigravity had already been pointing in the same direction with the idea that agents should have their own dedicated space to work.
What is interesting to me is not that these tools have better AI features. Their interfaces are moving toward the same shape: describe the work, let agents operate, observe the process, review the artifacts, and validate the result.
That is much closer to an ADE than to the traditional IDE workflow of opening files and manually editing code line by line.
Why spec-driven development matters
I strongly believe that spec-driven development is becoming the foundation for serious agentic work. That is why I built specs.md in December 2025, before building Fabriqa as the larger ADE around this idea.
One of the most encouraging signals recently came from the AWS AI-DLC team. I do not want to overstate it as “AWS uses specs.md internally,” because that is not exactly what I know. What I heard is more specific and, honestly, more meaningful to me: when they teach AI-DLC workflows to their clients, they are now using specs.md as one of the implementations, and some clients apparently prefer it over the official AI-DLC workflow.
We also had a conversation about the future of specs.md, partly because specs.md seems to be one of the only AI-DLC implementations outside of AWS’s own implementation. Hearing that from people working directly with enterprise clients was deeply energizing. It is one thing to build a tool because you believe the workflow should exist; it is another thing to hear that real teams are choosing it in practice.
Another company also told me they made specs.md part of their main spec-driven development flow, with tens, if not hundreds, of engineers using it. specs.md intentionally does not collect invasive telemetry, so I usually learn about this the old-fashioned way: someone messages me and says, “we are using this.”
Fabriqa comes with AI-DLC workflows built in, but I do not see AI-DLC as the only workflow that matters. The real point is giving teams a spec-native layer where they can bring their existing agents, subscriptions, and ways of working while keeping specs, artifacts, reviews, and delivery state connected.
Why the specs.md dashboard needed to move beyond IDE extensions
That same thinking is what led me back to specs.md. specs.md itself has always been usable outside of a VS Code extension; the issue was the dashboard and status surface around it. Earlier, it made sense to show that workflow state inside VS Code-based IDEs such as VS Code, Cursor, and Antigravity, because that was where most developers lived. But if development is moving toward ADEs, then the dashboard cannot remain mainly tied to IDE extensions. It needs to work in a normal browser, and it needs to work inside the embedded browser surfaces that ADEs now provide.
That is why I built the new specs.md web dashboard.
To try it, go to a project folder where you are already using specs.md, AI-DLC, or FIRE workflows, then run:
npx specsmd@latest dashboard
It will open the dashboard for that project, so you can inspect the spec-driven workflow from a normal browser. You can also open it inside an embedded browser in an ADE, which is the workflow I care about most. This makes it usable from environments like Codex, Claude Code Desktop, Fabriqa, or any other agentic development environment with a browser surface.
The demo video shows the workflow:
Curious how others are experiencing this: are you still mostly working in an IDE-centered workflow, or have you already moved toward an ADE-style workflow with agents, artifacts, previews, diffs, worktrees, and review loops?
Sources and references
Gartner press release: https://www.gartner.com/en/newsroom/press-releases/2026-05-20-gartner-says-the-market-for-enterprise-ai-coding-agents-is-entering-a-new-phase-of-expansion-and-competitive-realignment
GitHub Copilot app: https://github.blog/news-insights/product-news/github-copilot-app-the-agent-native-desktop-experience/
Cursor cloud-agent lessons: https://cursor.com/blog/cloud-agent-lessons
Google Antigravity: https://developers.googleblog.com/build-with-google-antigravity-our-new-agentic-development-platform/
