Bring Back Engineering-First Workflows. Needs an Advanced Engineer Mode

I think there is currently something missing in the AI coding market, especially for advanced developers and software engineers.

More and more tools are moving toward “autonomous generation”, “vibe coding”, and simplified agent-based workflows. While this is impressive for demos, prototypes, or beginner-friendly experiences, it often becomes frustrating for engineers working on serious applications, scalable systems, infrastructure, backend architectures, DevOps pipelines, or production-grade software.

One of the reasons Cursor originally felt different was because it behaved more like a true engineering assistant rather than a generalized autonomous generator.

Today, many tools are starting to converge toward the same direction:

  • abstract everything,

  • hide internal workflows,

  • automate aggressively,

  • reduce visibility and control.

And honestly, this creates problems for advanced users.

When an AI “does everything”, developers progressively lose:

  • architectural control,

  • workflow transparency,

  • code traceability,

  • consistency,

  • predictability,

  • and maintainability.

For serious engineering work, this matters a lot.

This is why I believe Cursor would greatly benefit from an “Engineer Mode” or “Advanced Technical Mode” focused on controllability and engineering-grade workflows.

Some examples:

  • Bring Browser mode back as a primary workflow instead of hiding it behind the Agent abstraction.

  • Allow advanced users to fully customize tool behavior and execution order.

  • Expose more internal reasoning and actions.

  • Allow manual selection/prioritization of scripts, tools, and contexts.

  • Add advanced workflow profiles:

    • Engineering Mode

    • DevOps/Infrastructure Mode

    • Research/Debugging Mode

    • Autonomous Agent Mode

  • Focus on transparency and precision instead of maximum automation.

  • Give developers stronger control over context management and architectural consistency.

Another very important point:
In an Engineer Mode, the interface should remain stable and non-intrusive.

Advanced users generally do not want the IDE UI to constantly reorganize itself, replace panels automatically, or force new workflow abstractions visually.

Instead:

  • keep the interface modular,

  • allow optional panels/features,

  • let users decide what they want to display,

  • and preserve the classic development workflow experience.

The UI should adapt to the engineer — not the opposite.

A lot of experienced developers prefer having:

  • predictable layouts,

  • stable tooling,

  • visible execution flows,

  • and manual control over what is shown or hidden.

The current trend in AI coding tools is heavily optimized for fast generation and “wow effect”, but there is still a huge space for an AI assistant designed specifically for experienced engineers.

Personally, I don’t want an AI that replaces engineering decisions.

I want an AI that amplifies engineering capabilities while keeping the developer fully in control.

I truly believe Cursor could become that tool.

^ this!

Thanks for posting that. The current push to this Agents Window thing has me quite nervous. That is just not the way I hope Cursor goes. It’s moving way away from engineering-first. It just feels like we are 1-update away from Cursor’s UI being only this Agents Window garbage.

Edit: I shouldn’t be so harsh about calling it garbage, though. I’m sure some people like it. But I can’t stand Claude Code for the same reasons I don’t like Agents Window.

Hey, thanks for the detailed feedback. Posts like this are helpful because they set a frame for talking about product direction, not just one-off fixes.

A few practical things you can do right now, so you don’t have to wait for Engineer Mode as a separate feature:

  • Custom Modes (agent / ask / plan / debug plus custom ones with a configurable set of tools and models) partly cover what you describe as workflow profiles. You can set up your own Engineering / DevOps / Debug mode with the tools you need and a default model. Docs: Plan Mode | Cursor Docs and Overview | Cursor Docs
  • Rules, Skills, Hooks, MCPs give a lot of control over what context is used, what tools are used, and in what order. Docs: Rules | Cursor Docs, Agent Skills | Cursor Docs, Hooks | Cursor Docs, Model Context Protocol (MCP) | Cursor Docs
  • Plan Mode gives you an explicit review step before changes, which is the closest match to the transparency plus control workflow for serious work.
  • Browser is still available as an agent tool, there isn’t a separate mode for it. This is the point that comes up most often, so I’m calling it out separately.

On UI stability and predictable layout, that’s valid feedback. The team is paying attention, but I can’t give an ETA for specific changes.

If you want to continue the thread, it’d be easiest if each sub-request (Engineer Mode profile, Browser as primary, layout stability, tool execution ordering) is its own post, or at least a list with your priorities. That makes it easier to get upvotes and track.

@Alexandre_Malaise Thanks for speaking what was in our mind! I find it frustrating too, how they keep pushing for the agent/chat mode, cause a lot of times I need to have the terminal, app, running, check files but with the new direction it’s really hard to do so.

I only read the first two paragraphs.

I simply ignore everything except Cursor build-in tools. And even within Cursor, I ignore things like the Agent window, even though I don’t write the code myself. I look at different prompt libraries, skills and MCP and I just don’t understand why I need it and why I should waste my time on it.

And when I really had pain, I created Agent Compass and Agent Enforcer. The only pain I still have is mockup-to-GUI development, which no one has solved for non-web applications, and I don’t have the resources to develop Agent Viewport myself.

Just work the way you expect an engineer to work and add tools only when they can solve a real pain point, not just add a vibe.