Design Ops in the Age of AI-Generated Code

Introduction

Nowadays, code-generation tools like Lovable, Bolt.new, and Cursor let us build application skeletons much faster than before. My last week’s post and this week’s work with those two startups made me think about the UX process in digital-product development - here are my reflections. Coding is becoming cheaper than original design work, so we have to change the way design contributes to a project.

Where We Are

Since products emerged that allow technical and non-technical founders to create software quickly, the pace of launches has grown rapidly. I am now trying to figure out the most effective way to approach the design process. An effective design process is still critical to digital-product success: understanding users and meeting business needs within technical constraints is essential. Yet design must be an enabler, not a blocker.

My Experience with Two Very Different Startups at the Same Stage

Recently, I had the privilege of working with two startups that perfectly illustrate different design-process needs. One operates in an already well-explored and crowded space—an investment platform offering a portfolio of products and investment opportunities. The other works in the novel space of performance marketing. The main difference between them lies in market saturation.
The investment startup is entering a well-established business model. Its market entry demands perfect UX and strong marketing, leaving no room for quick design iteration. The market is saturated, and people are used to similar products.
In the performance-marketing case, the tool invented by the founders does not yet exist, and its indirect competitors have limited market adoption. That makes it far more important to iterate quickly, launch soon, and then close the design loop with feedback from incentivised users and founders.

Known Business Case – Traditional UX Approach

When building an investment platform where many similar products already exist, we need to replicate their tested and verified UI patterns, then focus on the unique wedge the founders want to capture. A design-first approach makes sense here. We should not launch something quickly just to test it with any users—they already know the product type well. Unless we deliver a truly unique wedge, we must compete directly with established platforms. Whether on cost, better UX, or performance, we have a solid baseline in this saturated market.
That reality points us toward a regular product-operations flow:

• market research
• low-fidelity prototypes
• feedback from developers, users, and business stakeholders
• high-fidelity design
• software development

Competing with well-established players, we cannot let our solution feel worse than theirs. It may have fewer features, but its UX must be flawless; people will doubt its usefulness if it behaves oddly. Development, in my view, should be tightly controlled.

Novel Startup – New Approach

In the novel performance-marketing startup, what matters most to the founders is getting quick feedback loops from incentivised users and launching products soon. There is no existing market usage, so shipping quickly and onboarding users to build the moat is crucial. Using AI, founders can create a product without UX limitations, skipping the wait for design, and then—before releasing to users—test it with the design lead for clearance.
Because building a digital product from scratch with Lovable, Cursor, or Bolt.new now takes days instead of months, design could slow things down, especially when designers are not part of the founding team. Founders know the problem they want to solve, and design is there to challenge them while bringing market-comparison research and, later, user research. With that setup, product iterations can be much quicker.
AI works best today for new features, new products, and putting down the basics. It gets trickier when we must maintain design-system consistency and UX coherence. As the product matures, returning to more traditional product-operations methods probably makes more sense. It feels a bit like working with a PrestaShop or WooCommerce template: design has to meet product goals, business goals, and technical constraints. The best way I have found to work with templates is to run a design check after each developer delivery but skip design at the very beginning. I will dig deeper into this next week. In general, whenever we work with an already-made product, we must consider what has been used before and how it behaves.

Wrapping Up and What’s Next

My take is that design and product management must, as always, align with each specific case. Business KPIs and market awareness are essential for sensible decisions that help founders progress quickly. Design remains crucial to product success, but product operations must be configured to deliver the greatest value in every sprint or time frame.