More Time Inventing, Less Time Planning
About a year ago, on a whim, I decided to see how far I could get with an AI coding tool on a feature I never would have attempted on my own.
I'm a product designer and am just technical enough to be dangerous. I know my way around git, the cli, VIM, html, CSS, and a little JavaScript. But this feature required new database columns, new routes, new workflows, optimistic UI. The kind of full-stack work that traditionally meant sitting down with an engineer, walking through the user experience, creating detailed mockups, and waiting until there was enough shared understanding to actually start building. Realistically, it might never have been prioritized at all. Pulling an engineer off other work is a real cost.
Instead, I opened Cursor and just started.
By the end of the day, it was working (imperfectly). My engineer instructed me on how to do the database migration over Slack. And after a little refactoring, the feature went live.
How I approached my job shifted permanently.
Pairing with AI
Before this shift, there was always a gap between what I designed and what shipped: hover states slightly off, loading states that aren't quite right, interactions that just don't feel right, because the engineer implementing the feature already had a lot to do just making it work, and the polish had to be compartmentalized.
There was always a round of small UX fixes after every feature.
With AI, I can close that gap. Cursor handles the mechanics while I focus on the product experience. What used to be a cycle of revision and handoff is now more like pair programming.
Deliver More Value, Faster
As I got deeper into this workflow, I developed more familiarity and intuition for how our product is built. I didn't set out to learn architecture. I couldn't write a React component from scratch. But working this closely with AI and with my engineers, I’ve absorbed enough to understand how the front end and back end of our product works.
Rather than technical constraints I try to ignore to preserve creativity, they’ve become more like a set of lego pieces I actually understand. I can look at what we've already built and ask what else it could do. I can be inspired by the architecture, riff off of it, find new value in it. The code has become part of my creative toolkit.
I recently built a feature that tells Iris to proactively find insights for our customers and create a report for them. In the old world, this would have taken days just to discuss and plan. Implementation alone would have been at least a two-week project.
Instead, I wrote a skill, created a simple flow, and had something running in staging by end of day. We talked about it for a few minutes in standup. The team reviewed the pull request, suggested improvements, and we moved on. I demoed the working feature to customers with their real data and got feedback we couldn't have gotten from a mockup.
The conversation shifted from should we build this? to how much further can we push it? That's a fundamentally better place to be.
A customer described an idea inspired by the demo during our weekly call. Between the end of that call and our morning standup, I opened Cursor to think through how we might actually build it.
A customer described an idea inspired by the demo during our weekly call. In the few minutes between the end of that call and our morning standup, I opened Cursor to think through how we might actually build it.
Cursor's first instinct was to propose an entirely new feature, new database table, and lots of new code. But because I'd built the insight reports feature myself and I knew how our app-builder worked under the hood, I redirected Cursor to build an experience supported by those two existing features instead. That was all the direction it needed! What would've taken weeks is now just a fast follow.
A year ago, I didn't know enough about how the product was built to do this. But today, I know when to question the LLM’s approach and how to point us in the right direction.
The Honest Part
There have been features I built end to end, got fully working, felt good about, and then realized we shouldn't ship. Not because they were broken, but because sitting with them, I'd think: this isn't the right priority. This isn't something we want to maintain. This was the wrong problem.
In the old world, we might have spent two weeks reaching that same conclusion. With this workflow, I got there in an afternoon.
Wasted effort? Maybe. But sometimes the fastest way to learn something is the wrong idea is to make it real. A working prototype surfaces doubts, edge cases, and complexity that a wireframe never does. Half an afternoon is a cheap experiment.
Sharing the Road
Recently, one of our engineers wanted to understand how users were actually using our product. We use LogRocket, but using it means watching hours of session recordings, which isn't feasible at our scale. So he built a script, wrote a prompt, and used Claude to scrape and analyze the conversations our users have with Iris. Then he handed it to me and said: think about what we should actually want to get out of this.
An engineer building something and asking a designer to help shape it is not something that would often happen in the past. We all used to have very distinct lanes. Now we share the road and bring different instincts to the same problems. The sharp line between design and engineering has blurred in the best possible way.
Instead of trying to fit AI into the way we work, we've learned to ask: What does this make possible that wasn't possible before? What can we now attempt that we never would have tried What assumptions about how software gets built can we throw out entirely?