A few weeks ago, I saw someone on Reddit comment something along the lines of “If you think Claude Code is good, you’re a vibe coder.” The force of my eyes rolling into the back of my head almost killed me.

As I’ve consumed more content about AI-assisted tools, I’ve noticed “taste” mentioned as a differentiating quality between “good” and “bad” software developers. Within the professional software development world, there seems to be a taste stack:

• Problem Identification: Selecting the right problems and solutions to build
• Tools: Picking the right programming languages, tools, frameworks, etc. for building
• Logic Development: Building logic that is efficient, extensible and scalable
• Visual Design: Wrapping logic in a usable, design-forward interface

I struggle with how the word “taste” is being used, both because of its entanglement with economic constraints and how it creates an exclusionary binary of good vs. bad developers. Personally, taste is a tool for building an aesthetic, and an aesthetic holds beauty, a point of view. The word is almost a misnomer… it’s really “craftsmanship” that people are referring to.

As software development becomes more accessible, I’m curious if evaluation will move beyond the obvious and into the indescribable, the mysterious, the emotional. What would it mean for someone to say, “That’s a beautiful piece of software” and not refer to anything identifiable? In order to break into this domain, software developers will need to be thought of as creatives rather than engineers.

Food for thought:

• Lenny Rachitsky’s interviews with Anthropic’s Ben Mann and Cursor’s Michael Truell
• The Vibe Coding Paradox by Sangeet Paul Choudary
• Vibe Coding as a Software Engineer by Gergely Orosz
• A Survival Guide to a PhD by Andrej Karpathy
• How Vibe Coding Really Works by Alex Glushenkov
• Man Ray on craftsmanship and mystery
• Ira Glass on a creative’s taste

I’m building out an idea that’s been sitting on the shelf – a platform that allows users to gather around a shared prompt and share incremental updates, centering focus on process rather than product. During MVP development there’s been a lot of trial and error: discarding agent-generated code, re-prompting the agent, moving back to older commits, starting the project over during peak frustration*… A PRD, no matter how well defined, isn’t enough at this point in time for an agent to build a complex system that aligns exactly with the intended. I’m learning that guiding agents successfully, in addition to writing clear requirements, involves reducing their assumptions by setting the development context, building in validation, and specifying end goals for tasks.

Techniques for Moving from PRD to Production

During PRD Development:

• Ask agent to list questions it’s unsure about in PRD and answer them (Cursor tutorial with Lee Robinson )
• Ask agent to break PRD down into development phases

Setting Cursor Rules Before Building:

• Specify using git, the commit message verbosity, and the frequency of commits
• Specify building tests during development and validating development phases against these tests

During Development:

• Select the appropriate model for the type of partnership you want (https://docs.cursor.com/en/guides/selecting-models)
• Specify the end goal that you want when you prompt a task or the agent/model will pick an end goal for you (https://www.anthropic.com/news/tracing-thoughts-language-model)

*This reminds me of an Ira Glass interview where he talks about creative work and the frustration creatives feel in the early years of their career when the work they produce doesn’t align with their taste. Coincidentally, a developer’s taste is something I’ve heard mentioned in multiple interviews on vibe coding as a necessity for validating agent solutions. Interesting parallel between taste in work that is considered “creative” traditionally and code built with agents. Are we all turning into storytellers?

Job Hunting Sucks

Job hunting is exhausting. My days are a constant juggle between LinkedIn, Claude, Google Docs, and company websites—filtering jobs, evaluating fit, writing custom resumes. Add the pressure to apply quickly (applications submitted closest to posting date get priority) and networking for internal referrals (also get priority), and suddenly my entire day is gone.

So I Built a Script

An AI trend I’ve noticed is a shift from one-size-fits-all applications to hyper-personalized ones. Since tools like Cursor lower the barrier to building apps, why not solve your own problems? We used to build generic solutions for maximum reach. Now we're personalizing everything and building locally to meet individual needs.

So I did what people are doing but probably aren't discussing publicly—I used Cursor to build Leads, a job tool that streamlines job discovery to application. You can try it out here.

Leads does three things:

• Analyzes your resume with Claude to understand what role you're seeking
• Finds and ranks fresh jobs by how well they match your background and job requirements
• Saves interesting jobs and generates personalized resumes

Working on this for a few days taught me three key lessons about building with AI:

Start Small, Iterate Fast

Originally, I wanted a website to share with friends. I fed Cursor my problem and requirements, and it built something way beyond what I needed. I got lost in UI details trying to remove elements.

So I put on my MVP hat: I needed something quickly (built within a day), just for me, no UI necessary and a script was enough. I scrapped everything and worked iteratively—first job scraper, then job analysis, then relevancy scoring, and so on. Got a proof of concept within an hour or two.

Test as You Build

Building piece by piece let me test individual components and build confidence to keep going. The Cursor agent often builds tests unprompted, and catching issues early beats debugging a massive codebase later. The agent also doesn’t always build what you intend, so manual oversight is still necessary. Forget the Waterfall model and get to validation quickly.

Clean Up Your Code

Iterative development with agents creates redundancy because the agents aren’t always building off of previous work. For example, Leads initially had three identical if statements for match scoring (High/Medium/Low)—same logic, just different title styles. I pointed this out and prompted Cursor to “refactor and deduplicate code when appropriate,” and it cleaned things up nicely. Not necessary for functionality, but crucial for scalability.

The biggest efficiency gain? Caching API results. All that iterative testing burned through my Anthropic credits fast. I had Cursor cache Claude's analyses— resumes, keywords, job listings, personalized resumes — making the script faster and cheaper.

The Reality

Within a few days, without writing code myself, I built something that significantly reduces time spent on applications. I feel less drained and can focus on learning new skills and doing things that bring me joy.

But I won't lie… part of my soul died building this. It's wild that I could do it so quickly, and wilder that this is what staying competitive looks like. Yet it's also an evolution in using AI tools that are quickly becoming industry standard.

Please don't ban me, LinkedIn.

(No Editing)

Job Hunting Sucks

A problem I’ve had recently is managing my energy while job hunting. My days consist of:

• Filtering jobs for my requirements
• Evaluating if I’m a good fit
• Writing custom resumes

I’m trying to accomplish one task, which is applying to a job, but it requires hopping back and forth between LinkedIn, Claude, Google Docs and company website. Add in trying to apply to x number of jobs and then networking to find an internal referral and my day is gone. Not only is it exhausting, but there’s added pressure to do it quickly because applications submitted closest to the job posting date have a higher chance of being reviewed.

So I Built a Script

One AI trend I’ve noticed is a shift from large scale on-size-fits-all applications to hyper personalized ones. Since vibe coding lowers the barrier to entry for developing an app, it costs less to build something for yourself, so why not do it. In addition, existing apps can use AI to build in personalization so that each user gets a different experience based on their needs. We used to build generic apps to meet the needs of as many customers as possible. Now we’re personalizing existing apps and building locally to meet the needs of even more customers.

So I did what people are doing but probably aren’t publicly discussing – I used Cursor to build Leads, a job tool that streamlines the three actions to quickly move me from job discovery to application. You can find and use Leads here.

Leads will:

1. Analyze your resume with Claud

2. Understand what role you're seeking

3. Find fresh jobs matching your criteria

4. Rank them by how well they match your background and industry preferences

5. Displays jobs ranked by match quality (High/Medium/Low) with confidence scores

6. Saves jobs of interest and generates personalized resumes with Claud

I’ve been working on this on and off for a few days, the majority of my time being spent scoping the application, validating the functionality, refactoring and improving efficiency/lowering cost.

Scoping the application

Originally I wanted to build a website to share with friends so I fed Cursor my problem and requirements. It built something that went beyond what I needed and I started getting in the weeds of the UI. So I put my MVP hat on – I needed an app quickly (built within a day), only for myself at the minimum, and I didn’t need a UI – a script was more than enough. I asked the agent to scrap everything and worked on the script iteratively: first job scraper, second job analysis, third job relevancy… and so on. This got me exactly what I needed much faster, honestly within an hour or two.

Validating the functionality

By building iteratively, I was able to test the individual pieces as I developed and build confidence to keep going. I used to test software in a former life, so I’m familiar building extensive test plans for new features. Cursor can build tests to validate functionality (often unprompted), and testing as you go rather than waiting until the very end simplifies debugging and gets you to a proof of concept faster.

Refactoring

Because I built iteratively, the Cursor agent generated code that had a lot of redundancy. For example, Leads generates a match score (High, Medium, Low) for each job based on your skills. Initially, it had three if statements for each match level and within those statement if listed keywords and reasoning. The code worked, but styling the matches differently, the code between the three statements was identical.

if high match,

style with green circle

 `add keywords`

 `add reasoning`

if medium match,

style with yellow circle

add keywords

add reasoning

if low match,

style with red circle

add keywords

add reasoning

Having written code before, I recognized that the shared actions could be moved out of the if statements. With that observation, I prompted Cursor to refactor by deduplicate code when appropriate and it cleaned things up nicely. Is this necessary for the application to function correctly? No, but reducing unnecessary code is an important principle for building a scalable application.

Improving Efficiency

Along scalability lines, because I was doing so much iterative testing, I was calling Claude over and over for the same analyses and quickly ran out of Anthropic API credit. Here’s where my technical background came in handy. I prompted the Cursor agent to cache results when Claude was called: analyzing resumes, analyzing keywords, analyzing job listings, generative personalized resumes. Reducing API calls to only when necessary made the script faster and saves me money as I continue to use the tool.

Conclusion

Within a few days and without writing any code myself, I built a script that significantly reduces the amount of time I spend on job applications. I feel less drained and can focus time on learning new skills and doing things that bring me joy. I won’t lie though… there’s a part of my soul that died building this script. It’s wild that I was able to do it so quickly and that this is what I need to do to stay competitive in the current job market. But it’s also an evolution to using AI tools that are quickly becoming industry standard. Please don’t ban me, LinkedIn.

My first attempts using vibe coding to build apps gave results that were flashy but lacked substance. A few weeks ago, I got frustrated using iMessage to coordinate a spontaneous hangout with friends. What was supposed to be an easy trip to our local bar turned into hours of back-and-forth texts. By the time we settled on a time, my internal battery was depleted.

Curious, I did what most people are probably doing—I opened a few vibe coding tools and entered the same prompt:

I want to build an app that helps me schedule casual and spontaneous hangouts with friends.

It was magical watching applications build in real-time, but the solutions were more complicated than what I actually wanted to use. Claude and Lovable immediately started building. Cursor was different—it prompted me with key questions to scope the idea down.

Claude

Lovable

Cursor

This got me thinking: is there a product equivalent to prompt engineering? A set of techniques to guide vibe coding into producing answers that align with product thinking? We know the LLMs matter, but prompt engineering shows that how you interact with an LLM is just as important.

A Framework for Product-Led LLM Development

Over the past few weeks, I've been experimenting with simple product development using Cursor. I'm sure my techniques will evolve—soon I might even have my own agent based on my individual style of product development. But here's a starting point for using chatbots with product thinking.

Start with the User Problem

Like any product framework, begin by identifying the user problem you're trying to solve. The advantage of feeding this into an agent is turning it into a thinking partner. You're not solutioning yet—use the bot to think big and move quickly through possibilities.

Identify Your User Segment

Just because it can code before your eyes doesn't mean the solution will be valuable. You still need to understand who you're building for. Once the agent knows your user problem, prompt it to ideate on potential user segments and select the one that best fits.

Define User Success

Now that you have your problem and user segment, identify what success looks like: What actions should users be able to complete? How should they feel when using your application? This should inform the solution, not the other way around.

Set Constraints and Ideate Solutions

With user success defined, start ideating on solutions with constraints: platform (web, mobile, script), level of polish (MVP/MLP), tech stack preferences, core features and scalability requirements. The more you define, the more tailored the agent’s recommendations become.

Select a Solution and Ask for Architecture Options

As the PM/Engineer, you still need to use your “taste” to identify if the architecture of a solution will work in your context. For example, agents aren't great at building scalable applications yet. Try prompt engineering techniques: ask for alternative architectures or question whether the recommended architecture is scalable.

Why This Matters

With these techniques, you can use product thinking to guide vibe coding agents toward viable solutions without building anything first. This criteria can become a detailed PRD (you can even use the agent to review it), or you can prompt it to start building a solution immediately.

The result? Higher control over the solution and something that's actually valuable to potential users, not just impressive to watch being built.

I haven't coded professionally since 2018, but those late nights debugging in my college's CS lab “dungeon” are burned into my memory. A few weeks ago, I decided to experiment with AI-powered coding assistants to understand how they might fit into my Product Management workflow.

My first attempt was ambitious—I fed the same prompt to multiple assistants to compare their solutions. While there was magic in watching software appear from a few words, the results felt overly complicated. The UI choices were distracting, and I couldn't easily visualize the project structure. These tools excelled at helping me “work backwards” and refine my problem, but I wanted something more tangible.

So I simplified. I decided to build a basic personal website with Cursor, and managed to go from nothing to hosted in just a few hours. It blew my mind.

What Made the Difference

Cursor's agent provides enough abstraction to let me focus on what I want to build instead of how to code it. The integrated IDE eliminated constant context switching between tools, letting me stay in a flow state longer. I could focus on ideation and building without the usual tool-hopping friction.

Initially, I was hesitant to dive into an IDE. As a PM, I'm used to tools that enhance problem discovery and high-level planning—not getting deep into code. I worried that being too close to implementation would add unnecessary work to my plate. I also wasn't sure my rusty coding skills would be enough to make Cursor valuable.

What I discovered was the opposite. The time invested gave me a deeper understanding of the development process and made it easy to explore ideas without creating distractions. The agent made it less about knowing specific programming languages and more about clearly specifying what I wanted and debugging when things went wrong.

If you're intimidated: a basic intro programming course is enough to get started. These skills are very attainable for PMs and lead to better collaboration.

The Elephant in the Room

There's an unspoken tension when PMs start prototyping or mocking up experiences: are we overstepping into our designers' or engineers' responsibilities? At Apple, they called your direct responsibilities your “sphere of influence”—working outside it was a big no-no. It's a relic of the hierarchy that's been historically necessary to coordinate thousands of employees building for millions of customers.

The truth is, the person who'll excel at AI-assisted development is probably a TPM—someone who can identify customer problems worth solving while understanding enough about design, engineering, and testing to keep things moving. But I hesitate to even write this because there's so much pressure across roles to maintain relevancy, and these rigid role definitions are something the industry needs to evolve past.

At the end of the day, if a team is truly collaborating, there's very little ego about how they reached a solution.

Why This Matters

AI-powered coding assistants make me excited to build software again. With Cursor, I built something tangible quickly while learning along the way. I feel satisfied with what I created and motivated to turn more ideas into reality.

Bottom line: it's the most fun I've had coding, maybe ever.

I truly believe we're approaching a future where people currently labeled as “non-technical” will be capable of end-to-end software development. Don't let the big, bad, dark mode IDE stop you.

(No AI Modification)

I haven’t coded professionally since 2018 but the late nights I spent debugging code in my college’s “dungeon” (CS lab) are burned into my memory. A few weeks ago, I started messing around with AI-powered coding assistants to better understand how they can be integrated into my Product Management workflow, so I entered the same prompt into a few assistants to see how their solutions differed. There was magic in seeing software being built so quickly from a few words, but I found the solutions overly complicated, the UI design choices distracting, and visualizing the project structure difficult. They were great for practicing “working backwards” and refining the problem I was trying to solve but I wanted a mutable skeleton.

I abandoned the experiment and focused on something simpler, building a basic personal website, and I was able to build one, from nothing to hosted, with Cursor in a few hours. It blew my mind.

Cursor’s agent provides enough coding abstraction to focus my attention on defining what I want to build instead of the programming language I am using. In addition, the agent being integrated into the IDE reduces the amount of context switching I’m doing investigating how to implement a component or debugging an issue in the code base. It felt easier to focus on ideation and building for a longer period of time because I wasn’t hopping back and forth between different tools.

There are plenty of AI-powered coding assistants to choose from these days and I was hesitant to dive into an IDE off the bat. Being a PM there’s an emphasis on using tools that only enhance productivity related to problem discovery, high-level ideation, and development planning, and I thought being that close to code again would add unnecessary work to my plate. To be honest I also wasn’t sure if my coding experience would be enough for the tool to be valuable to me since Cursor is marketed towards “technical” folks. What I found was that the time I did invest into building a solution with Cursor paid off in a deeper understanding of the development process and made it easy to investigate curiosities without creating distractions.

While having some experience with coding was helpful for using the IDE, the agent made it less about knowing how to write code in a specific language and more about knowing how to specify what I wanted and how to debug the system when something went wrong. If you’re intimidated, a basic intro-level programming course is enough to get started using Cursor. I’d like to write up some tips in another post but for now I want to emphasize that these skills are very attainable for Product Managers and make for better collaboration.

There’s an elephant in the room that needs to be acknowledged when we talk about PMs using AI-assisted coding assistants. At most companies, there’s an unspoken tension between PMs and their partners during collaboration… if I, the PM, mock up an experience or engineer a prototype, am I overstepping into my designer’s or my engineer’s responsibilities? When I worked at Apple, your direct responsibilities were called your “sphere of influence”… working past your sphere was a big no no. It’s a relic of the hierarchy that’s been necessary historically to build many interrelated products across different organizations with thousands of employees for millions and millions of customers.

If we really want to stick to the way Software Development companies have defined roles in the past 5 years, the truth is that the type of person that will excel doing AI-assisted software development is a TPM, a generalist who can clearly identify and define customer/business problems worth solving in addition to understanding a little bit of everything in the cycle to get things moving: design, engineering, testing, etc. But I hesitate to even write this because there is so much pressure across roles to maintain relevancy and the hard line between the way roles are defined is something the industry needs to evolve past. At the end of the day, if a team is truly collaborating, there is very little ego about how they reached a solution.

Tangent aside, AI-powered coding assistants make me excited to build software. With Cursor, I was able to build something tangible quickly and learn along the way. I feel satisfied with the project I built and motivated to continue turning ideas into a reality. Bottom line – It’s the most fun I’ve had coding maybe ever. If Cursor were to add functionality for non-technical users, I would love for the agent to suggest or integrate prompt engineering techniques into its outputs. This would increase satisfaction with the agent’s outputs and help users move past the friction of development roadblocks.

I truly believe there’s a future not too far from now where people who are currently labeled as non-technical will be capable of end-to-end software development. Don’t let the big, bad, dark mode IDE stop you.

It's impossible to escape the doom and gloom think pieces about how AI will impact tech—most of them fixated on the “death of the software developer.” As AI enhances existing development tooling, it's natural that developers will work at higher levels of abstraction and existing processes will become obsolete.

But this feels more like evolution than death. The way we communicate with computers is becoming closer to how we communicate with humans. There's a shift from identifying developers by the languages they write to the problems they solve.

Yes, this transformation is important. Yes, we need to understand AI's moral and ethical impact on humanity. But what interests me is how AI might help software move beyond Tech and into Craft.

The Liberation of Programming Languages

As AI integrates into development processes, our existing non-AI programming languages and tooling lose their commercial value. They become liberated from the constraints of capitalism: revenue targets, business objectives, scale requirements, performance metrics, growth imperatives.

When there's no external objective other than creation, software development can become a “capital C” Craft.

Think about traditional crafts—weaving, woodworking, papermaking. Many practitioners deliberately reject modern machinery, not because it's inefficient, but because it removes the mark of the human hand. I can imagine new software communities forming with similar principles, refusing AI-assisted tooling for the sole purpose of highlighting human creativity and intention.

A Different Kind of Software Creativity

This new motivation could lead to forms of software creativity we've never seen before. It's the rebirth of a medium: programming languages that seem inefficient under current market drivers become languages that allow deeper levels of control under a new purpose.

Imagine software built not for users or revenue, but for the pure joy of creation. Code written as poetry. Applications that prioritize beauty over functionality. Digital experiences crafted with the same intentionality as hand-thrown pottery.

A Seed of Positivity

In all the rubble of AI disruption discourse, here's something genuinely exciting: the possibility that software development could rediscover its soul as a craft. Not everything has to scale. Not everything has to optimize for engagement or conversion.

Sometimes, the most meaningful work happens when we choose the harder path—not because it's more efficient, but because it's more human.

(Original – No AI Modification)

It’s impossible to escape the doom and gloom think pieces anticipating how AI will impact the Tech industry, the majority of it focused on the death of the Software Developer. As AI enhances existing Software Development tooling (programming languages, IDEs, models, data analysis, project management), it’s natural that Software Developers will work at a higher level of abstraction and existing processes will become obsolete. This change is more of an evolution than a death… the way we communicate with computers is becoming closer to how we communicate between humans and there’s a shift from identifying a developer by the computer languages they write to the problems they solve. And yes, this is important, and yes, it’s also important to understand moral and ethical impact of AI on humans as a whole, but what is interesting to me is how AI will help Software move beyond Tech and into Craft. As AI integrates into Software Development processes, our existing non-AI assisted programming languages/tooling are no longer seen as valuable and will be liberated from the constraints of Capitalism: revenue, business objectives, scale, performance, growth, etc. When there is no external objective other than creation, Software Development can turn into a ‘capital C’ Craft. Similar to how traditional Crafts (weaving, woodworking, papermaking *wink wink*) reject modern machinery, there can be the formation of new Software communities that refuse AI-assisted decision-making in their tooling solely for the purpose of highlighting the mark of the human hand. This new motivation could lead to a different form of Software creativity beyond what we’ve seen, and that’s exciting! It’s the rebirth of a medium: a programming language that is now seen as inefficient under current drivers becomes a language that allows a deeper lever of control under a new purpose. A seed of positivity in the rubble.

Food for thought:

• https://www.oreilly.com/radar/the-end-of-programming-as-we-know-it/
• https://sourcegraph.com/blog/chat-oriented-programming-in-action
• https://www.404media.co/microsoft-study-finds-ai-makes-human-cognition-atrophied-and-unprepared-3/
• https://sciodev.com/blog/what-is-the-meaning-of-true-craftsmanship-in-software-development-2/
• https://manifesto.softwarecraftsmanship.org