The Visual IDE
AI coding copilots are being universally adopted by PMs & Designers, giving them 10x the agency - but is a code-oriented system the optimal form factor for such users?
Over the last few months, I have spoken to numerous designers & product managers about how their job is changing in the face of AI coding tools. While there are numerous downstream implications of LLM-based coding assistants and agents, there is one predominant theme that has been front and center in almost every conversation - product managers and designers are increasingly writing software, not just specs/PRDs/mocks or other peripheral descriptions of software.
Basically every good PM & designer I know is now using tools like Windsurf, Bolt, Loveable, and similar to prototype application changes, and in some cases, even submit PRs on their own. This is remarkable given that many of these people are not technical, didn’t study computer science, and had never really written a line of code in their lives prior to LLMs.
Some direct quotes I have heard recently in discussions:
“Honestly, I don’t see very much value in using Figma anymore. I am better off just forking the codebase and using Cursor to create living prototypes. This is faster, avoids all the skew/drift of having separate mockups, and greatly simplifies hand-off to the engineers I work with” - Former design lead at Hashicorp
“I was recently trying to convince our team to work on a major new initiative, but I couldn’t get buy-in. I finally decided to just prototype a mini version of the idea over the weekend so I could directly show people what I meant. It was only when I showed my working prototype that I suddenly got everyone onboard. Before Cursor, I never would have had the capacity to do this, and we likely never would have pursued this direction” - Staff product manager at Duolingo
So we just launched this new feature for visualizing certain data and we needed to pick colors for it - and it is sort of a complex feature in terms of colors because there might be 20+ lines on a chart, and all these colors must be look good together and be high contrast against background etc. The designer sent me an initial set of colors and it didn’t work, and then he sent another set and those didn’t work. So what he then did instead was use Cursor to build a version of this application which included a color picker that I could flick through and see what many variations would look like directly. And seeing him do that, I was like, okay - This is going to change everything. Right? Like, designers can build applications” - Senior engineering lead at Cloudflare
If you look online, you increasingly see this sentiment everywhere - Gokul Rajamaram recently shared an example of a VP of product at a public company discussing how he is building a new feature or concept on his own every few days.
The key thing here is agency - tools like Cursor empower product managers and designers to be 100x more independent in ideation & driving impact because they no longer constantly need to wait for engineers to get things done. Every designer has 100+ UX papercuts they wish they could fix but which never get prioritized. Every PM has 5 ideas they wish they could concept to show customers to get feedback on, and has 100 minor feature requests and bug requests from customers they wish they could address. AI coding tools suddenly allow these things to be fixed outside of begging an engineer to include it in the next sprint.
Extreme behavior
In my opinion, this is a classic example of “extreme behavior” - where people are going out of their way to do something unnatural because the benefits are so substantial. Specifically, I do not think that code-first IDE are actually the optimal interface for PMs & Designers to prototype or make small changes to the product.
PMs/Designers are not software engineers and, for the most part, are not deeply familiar with the numerous concepts implicitly embedded in tools like Cursor, such as:
Git semantics - cloning, branching, etc
Interacting with a terminal and viewing console log outputs
Reading & writing code!
While you can, of course, ignore these things and “vibe code” your way through figuring things out until they work, this has obvious pitfalls. Tools like Bolt & Loveable partially solve this problem by abstracting much more “software engineering” concerns from the user, but are ultimately very oriented towards independent, “net new” apps rather than maintaining and updating a large, established codebase. They are also still quite code-oriented in terms of what they show the user.
So, while the behavior of some software engineering shifting right to PMs & Designers is here to stay, I think it is unlikely that the optimal end state of this is everyone using a software-engineer oriented IDE.
What would an “development environment” for the non-SWE persona look like?
If you thought about solving this workflow for non-software engineering persona from first principles, what might it look like? These are some of the principles that I think would matter a lot:
A more visual editing experience oriented around a staging preview of the app
IDEs treat code as the first class citizen and previews of the application as a secondary workflow. I think this should be flipped on its head for non-engineers - the “thing” you are working on should probably look like a live staging preview of the app, and code should secondary or tertiary.
You see hints of this direction in products like Replit which increasingly leans towards just showing you a natural language conversation with the agent plus the web app preview, and have increasingly deprioritized code & the terminal - though I think I would take the idea a lot farther than this if orienting towards PMs & Designers.
You can then imagine a range of editing workflows that would be more visual & language oriented than what you see in coding IDEs. For example:
Click through a workflow of the app and then describe how you want it to change in natural language
Use an “inspect element” like flow to click or select certain parts of the app, and then describe how you want it to change
Drag in a spec, PRD, Jira ticket, or similar and draw on top of the application like a canvas - highlighting the portion of the application the change should apply to
As you make such changes, you can imagine an AI coding assistant that progressively helps you implement this in the staging environment at increasing levels of sophistication - starting with DOM changes to confirm basic visual patterns, then HTML/CSS changes, then backend changes - corroborating the intent and purpose of your change with you as it goes.
This mirrors the experience of a designer sitting next to an engineer in an office - saying what they want and providing live feedback on the application as the engineer progressively implements it.
You’ll note that this is de-facto how non-engineers who “vibe code” in tools like Cursor work today - they basically just keep interacting with the localhost preview and telling the AI what to change until it works, completely ignoring the code being written for the most part.
A focus on simple, visual changes, not backend changes
Part of the power of a product like this would come from scoping down the breadth of what you aim to enable. Obviously, engineers will still be required for complex changes or major features in complex codebases - it is the small, mostly visual, mostly front-end changes that make sense to offload to PMs & Designers.
I would focus the entire product experience on these sorts of changes - perhaps even starting by only allowing changes to client-side HTML/CSS/JavaScript rather than messing with the backend at all.
This would allow you to simplify a lot of things - from the way the AI coding agents work under the hood to the user experience and workflows you need to support. Software IDEs are designed around enabling someone to change anything in a codebase - but this, in my opinion, is a non-goal for a product like this and is part of how you par back complexity to empower the non-software-engineer.
Prototyping as a wedge, but not the end state
A lot of the way tools like Cursor and similar are used today by product managers and designers is prototyping. By this I specifically mean - creating sample versions of the application which are used to demonstrate or communicate a concept, but which engineers don’t use as a baseline for code changes.
While I think prototyping is likely an important wedge use case to focus on as a startup in this space, in my opinion the major opportunity lies in going beyond that and finding the situations where the end deliverable is actually a pull request.
Consider the workflow I mentioned earlier - where the user interacts with the staging preview and iteratively refines it in collaboration with an AI coding agent. Once the application reflects the intent of the product manager or designer (e.g. the frontend/visuals/UX look right), the system can then spend many hours thinking about how to turn this change into a proper pull request, inclusive of additional changes that may be needed across the database, the backend, or other adjacent components. This can ultimately turn into a PR that is delivered to an engineer, enriched by all the specification the PM/designer did when iterating on the feature.
I think that going all the way to the pull request is how you capture real value as a startup in this space - as you are no longer just a prototyping tool but a key part of the software development lifecycle. Indeed, I think the natural adoption curve for a tool in this space would be:
Offer a free prototyping tool which can be adopted by any PM/designer on their own and requires no integration into the codebase or other systems. I would probably have this work mostly around screenshots - where you can screenshot pieces of the app you want to prototype changes to, the system creates a non-functional prototype of that UI (since it doesn’t actually know anything about your full codebase or application), but you can update it visually as you please to communicate ideas in much more expressive, interactive ways. This is sort of like a persona-specific Bolt that is designed to “branch” off of existing applications
The paid product would integrate into and fully understand your codebase - and would allow for the creation of truly functional prototypes built on staging versions of your application that can be turned into PRs
Of course, the quality bar for creating a pull request is much higher - which leads me to my next point.
Treating the hand-off to engineers as a first class citizen
One of the most significant challenges, and opportunities, in this space is tackling the handoff to engineer. An obvious failure case here is that all the PMs and Designers at a company start thinking they can make all sorts of changes on their own and this all gets sent as PRs to engineers, causing the engineers go crazy if many of these PRs are bad, low quality, or require a lot of changes to be production-grade.
I think this is solvable and indeed is part of where you would build a large set of features that do not need to exist in a tool like Cursor/Windsurf. For example:
Allow engineers to set policy for the types of changes that can or can not be turned into automatic PRs (e.g. “If it touches the database at all, it can’t be turned into a PR”)
If the AI agent determines after thinking for awhile that a given change is overly complex or unlikely to be implemented in an automated fashion correctly - it can simply go back to the PM/Designer and say “Hey I think this is too complex for me to handle, let’s just share the prototype with the engineers but I shouldn’t actually try to implement this”
The “feedback” flow would need to be seriously thought through. This idea breaks many of the assumptions in the standard pull-request workflow, where engineer one submits a PR and engineers 2/3/4 provide feedback which is then responded to by engineer one. If the reviewing engineer has feedback on the PR, what happens? Does this get sent to the PM/Designer? If so, how do they address it? If not, who is responsible for implementing those last-mile changes
I actually think getting this piece right is the hardest, and most critical part of building a product like this. Done correctly, engineers will also end up pulling you into their company, because they will be tired of their PMs/Designers vibe coding in Cursor and submitting lots of slop to them without guardrails.
Concluding
I am fairly convinced there is a massive startup opportunity in this space. I think design and product management are changing more right now than they have in the past 20 years thanks to AI-assisted coding. As a result, I think there is a unique opportunity to create an entirely new type of “integrated non-developer environment” which is oriented toward visuals and app interaction, not code.
I think it is exceptionally unlikely that this is done by existing incumbents (e.g. Figma, Productboard) because it obviates the core mental model of such products - the primary reason people worked in these lower fidelity mediums is because the burden of writing code was so high and the skillset so specialized.
While I don’t think that vector graphic-based designs or PRDs will go away, I think there are a lot of situations where it will now be much better to simply build and work on the real thing. You see this empirically today with all the designers/PMs using AI codegen tools instead of their traditional workflows.
If you are interested in building something in this space, please reach out - davis @ innovationendeavors.com