Exploring the ideal AI-native development experience has required deep, ongoing R&D. We’re working on the frontier of several technologies and pushing them to do things they’ve only recently become capable of, like generating software simulations.

Recently, we decided to take a bite-sized first step toward our vision for the ideal development experience in this new AI era. We turned an internal tool we built to manage Claude Code’s memories into a small product others could try.

We did this by temporarily gating (for non-CodeYam team users) our more experimental R&D functionality and shipping our CodeYam CLI tool with the CodeYam Memory feature that external users could try front and center.

The tool can be installed in any terminal where you’re running Claude Code using an npm package and one-line installation instructions.

We wanted to make it as easy as possible for people to try CodeYam Memory, so following Show HN tips we made it free, local, and usable without sign-up.

We launched last week on Hacker News, and then this week on Product Hunt. I’ll share my raw observations and takeaways.

Although I’ve been on both Hacker News and Product Hunt for over a decade as a user, this was my first time launching anything as a builder or maker.

Since both were first launches for me, these learnings should be taken with a grain of salt.

Show Hacker News: The Launch that Failed

How We Prepared to Launch on Show HN

For our Show HN launch, our first public launch beyond sharing CodeYam with a small number of friends to test, we went in with a simple goal: make it as easy as possible for folks to try CodeYam Memory and for us to get feedback.

We tried to follow the Show HN tips and guidelines as closely as possible.

We redesigned and relaunched our website to emphasize how easy it is to get started with CodeYam CLI & Memory for Claude Code, and that the tool is free, local, and requires no sign-up.

We also shipped a launch blog post explaining why we built the tool and how to get started. We recorded two demo videos: one showing CodeYam Memory being used on our own project, and another showing it being used on a third-party open source project, Plane.

We drafted our Show HN post in advance along with my first comment as a maker. I also asked Anthropic’s Claude AI to analyze past launches to help aim for the right style and length, and repeatedly checked the Show HN guidelines and tips.

I even asked Claude Cowork when the ideal launch time might be and tried to follow the suggestions: mid-week and as early in the morning as possible. I’m not sure the recommendation was actually accurate, but I figured it didn’t hurt to try to follow it.

Show HN: The Launch That Was Invisible

I submitted our Show HN early in the morning last week (in my local Mountain Time). Almost immediately, despite waking up early, there was an avalanche of other Show HN launches. Our post was quickly pushed down the page – it felt like in seconds.

The first external comment was from a random HN user asking about my name, not asking questions or sharing feedback about our product.

In a move of desperation to at least give our launch a chance to be seen by anyone who might try what we built and find it useful or at least share feedback, we emailed friends and our investors and asked them to look for our launch and, if they had something meaningful to say, engage in the comments. Not that Hacker News strongly discourages this, in contrast to Product Hunt which encourages you to amplify your launch.

We had also been advised that sharing a direct link to a launch on HN could lead to throttling. So instead we asked people to find the post themselves from the main HN site or, as became increasingly necessary, search for “codeyam” and locate the most recent post.

Ultimately, none of this mattered.

The launch was visible on shownew on Hacker News, the page where you can browse the newest Show HN posts, and we got some upvotes and engagement from friends. But we never made it onto the main “Show” tab of Hacker News, let alone the front page.

What was interesting is that there were stale posts on Show HN with far less engagement than we had. We confirmed we weren’t shadowbanned or flagged, but I suspect heavy throttling by the HN team in terms of what actually makes it to the Show HN main page.

The Show HN rules state:

“Every Show HN appears on shownew. Once it clears a small points threshold, it will appear on the show page in the top bar.” In our experience, this wasn’t true.

It almost seemed like points didn’t matter, or that some points invisibly counted more than others. My leading theories are that votes from users with high karma carry more weight and that Show HN is more heavily moderated or curated than the rules suggest.

While I appreciate the HN team trying to prevent visibility from being gamed, it also feels like it has become extremely difficult for a launch to gain any visibility without getting very lucky. The alternative would be gaming the system, which we neither know how to do nor are particularly interested in doing.

This week, as an experiment, we had a different team member post a Show HN at a significantly earlier time, early morning Eastern Time. Same result. One external user commented, but it was a new HN account, and we never made the Show page or the front page.

Product Hunt: Surprise Overnight Success

After our failed Show HN launch, we were not feeling optimistic about the chances of getting visibility through popular launch sites. Still, we had a free product people could use, and it felt worth trying to launch it on Product Hunt as well.

Our small team had already moved on to our next product and engineering priorities, so I made a deal with my co-founder: I’d handle the Product Hunt launch mostly myself so it wouldn’t distract him or our team, and then report back with learnings.

I’ve been on Product Hunt for a long time (joined the site in July 2015) and introduced myself on the Product Hunt forum a couple of weeks ago, but had never launched as a “maker.”

Luckily, Product Hunt has a pretty robust launch guide. We were also able to update and repurpose some of the materials we created for the Show HN launch and adapt them for Product Hunt.

One major difference from Hacker News is that Product Hunt allows much less text description and relies far more on visuals like screenshots, a demo video, and links to your site and socials. There’s also the option to create an “interactive demo” which I briefly looked into but didn’t pursue.

I put together our Product Hunt launch and scheduled it for the next day.

When you schedule a launch on Product Hunt, it goes live at 12:01 AM Pacific Time, which gives you the biggest window to accumulate votes for that day. I went to bed planning to wake up early, though not early enough to see the launch go live at 1:01 AM Mountain Time.

Luckily, my co-founder is on Eastern Time. While I was sleeping, our launch organically picked up nearly 80 upvotes and he was able to respond to a couple of early comments.

When I woke up a few hours later, I realized we had a chance to be among the top launches of the day. This surprised me, especially since the very top launches were from startups and companies with large existing followings, e.g. Google and OpenAI both launched products that day.

Given our surprise early organic results, it felt worthwhile to keep an eye on things, so I prioritized responding to comments and questions. I also had a bit of an existing following on Product Hunt (around 200 followers), so it’s possible some friends saw our launch early on.

When I first checked, we were around #17 or #18. I realized we could move up fairly easily since only a handful votes separated the launches between #10 and #20.

Product Hunt allows and even encourages you to promote your launch, so I shared it on socials (my personal socials and our startup CodeYam’s pages) and sent a follow up email to friends and investors. I also shared the launch in a few WhatsApp and Slack communities I’m part of that allow this kind of content and have other founders who might empathize with our competitive launch day.

We eventually peaked at #13 for the day, with just a couple votes separating us from #12.

I also heard from several people that their upvotes or comments seemed to be throttled by Product Hunt. One founder friend told me they tried to comment but it didn’t go through; another said they upvoted and commented, but it never appeared. Still, at least some of the votes and comments came through.

My suspicion, though I can’t confirm it, is that Product Hunt weighs things like comment quality, account age, or account credibility when deciding what counts.

One thing Product Hunt encourages is getting verified. I had previously applied (and linked certain social accounts like LinkedIn), but only realized on launch day that my verification was still “pending.” It was approved later the same day, but not sure that it had any impact (seems unlikely).

Some of our friends and supporters are newer to Product Hunt (at least a couple amazing folks messaged me to tell me they joined so they could support our launch), so I suspect their impact, while still amazing and helpful, was limited. That said, these folks can now much more easily support future new product launches for us on Product Hunt, which could be impactful.

We also continued to get votes two days after the launch, which is nice but didn’t help our ranking by the end of launch day (we now have more votes than the company that finished #12, one spot above us for instance).

One thing I didn’t do, but noticed others did (including the team that was #1 the next day, which was an especially busy day on Product Hunt due to the promise of a Y Combinator interview for lucky founders), was to reach out to other PH Makers or Hunters in advance to ask for support.

Almost all of the #1 launches seemed to do this and had veteran hunters backing them, including self-proclaimed “#1 hunter” Chris Messina.

Unlike Show HN, when we launched on Product Hunt I received a lot of LinkedIn messages offering to sell upvotes. This is something Product Hunt does not allow, and something I have no interest in doing.

Unlike Show HN, our launch was featured on Product Hunt. I’m not entirely sure why, but I suspect the early organic traction helped.

Even though I tried to rally support (thanks, mom and dad) for a late surge, it seemed every other maker who launched that day was doing the same.

We finished the day at #13. I would have loved to break into the top 10 launches (which are featured in the next day’s Product Hunt newsletter), but honestly I’m quite pleased with the result.

Post-Launch Learnings

Overall, I’m glad we experimented with building in public and launched on both Show HN and Product Hunt. Despite our initial disappointment with Show HN, we had a good showing on Product Hunt.

Timing matters a lot, and there’s clearly an element of luck in when you launch. Community support matters too, but support from more established members seems to matter even more.

In hindsight, we might have done more to track results. We strongly followed the tip of making it as easy as possible for people to try the product and give feedback, but that also makes it harder to tell how many people actually tried it. Right now we’re mostly looking at lagging indicators like npm installs, feedback messages, and people joining our waitlist or Discord.

I’d like to have a simple way to know with more certainty when people install and use the product, although what we did felt sufficient for a lightweight launch of a small tool.

We’ll likely continue launching future products on both platforms. You’re welcome to follow CodeYam and/or myself on Product Hunt and of course look for anything CodeYam on HN or elsewhere.

The goal of this post isn’t to plug our launches but to share what I personally learned from the experience. That said, I’d be remiss not to mention that if you’re building software with Claude Code, you’re welcome to try CodeYam CLI & Memory. Feel free to share feedback here or in our Discord.

If this kind of write-up is useful, I’m happy to keep sharing what we learn.

Just let me know.

My current stack:

• VS Code by Microsoft

• Claude Code CLI by Anthropic

• GitHub CLI (triggered by Claude) by Microsoft

• Figma Dev Mode MCP Server (Beta)

I’ve heard OpenAI’s Codex has improved since I last tried it a few weeks ago, but for this project I stuck with this current stack.

Ironically, Anthropic recently published a postmortem of three recent issues that degraded response quality from Claude, widely discussed on Hacker News.

While I don't know if I hit these specific bugs, Claude's response quality varied wildly, and sometimes even hour to hour. I wasted several hours on occasions where Claude would make changes to completely unrelated parts of the application instead of addressing my actual request.

That said, despite the challenges, this was a pretty incredible experience. The fact that I, as a non-engineer, could take the new website designs (in Figma) and implement them with high fidelity as changes to our actual codebase by pairing with Claude is amazing.

This took weeks, not the months or years it might have if I learned how to code (and properly use Remix, in this case). While maybe I could have built a site equally quickly using a low or no-code website builder like Squarespace, Bubble, or Wordpress, it would have been using pre-made components that wouldn’t have made it possible to match our designs perfectly.

How I Worked With Claude

Initially, I did all my work locally. Meaning if anything had happened to my laptop, all my work would have been lost. In hindsight, a terrible idea.

In searching for the best way to work with Claude, I landed on a workflow quite similar to how many developers work today.

I’d start working on specific changes locally, often checking them on a development server (typically all on my laptop, although I recently learned I could also preview changes on a development server on a mobile device on the same network, which was very helpful).

I'd frequently push work-in-progress to a branch, then clean up and have Claude test changes before opening a pull request.

One trick that worked well was asking Claude to pretend to be my co-founder and CTO (or just an experienced developer) and review the PR and provide comments and a recommendation on whether to merge or require changes.

Often, Claude would catch some optimizations that had been missed earlier.

I would then ask Claude to apply whichever optimizations made sense, which were usually smaller code quality or clean up items.

It was silly yet satisfying when Claude (the PR reviewer) agreed the change looked good and was ready to merge.

After CI/CD checks passed, I'd merge and delete the branch, then manually test the changes on our development site.

For experienced developers, this probably sounds routine. For me, it was surprising to discover that AI-assisted coding worked in a relatively common software development workflow: branches, PRs, code review, testing, and deployment.

Claude’s Quirks (and How I Dealt With Them)

In working with Claude, there were a number of surprising and frustrating issues. Sharing my experience below in the case that it helps others.

Issue #1: Spammy, Unused Hashed Named Files Resulting From Figma MCP Dev Server Use

A teammate flagged that my PRs were cluttered with hashed SVG files. These were usually warped Figma components that weren’t referenced in the code.

This happened consistently with the Figma Dev Mode MCP server, even when I told Claude not to generate new SVGs. This might just be a quirk of the Figma Dev Mode MCP server, but tracking down and cleaning up unused files was annoying.

What worked best was asking Claude to look for files with hashed names and, confirming they were unused, delete them and any folders that became empty after their removal.

In parallel, I’d manually look for files with hashed names in the left side navigation in VS Code, flagging specific paths that were left behind by Claude for investigation.

I also would need to look at the site on the development server to make sure no used files got accidentally deleted (this happened a few times).

Once cleanup was done, I’d ask Claude to rename the rest with human-readable names (or “semantic names” as Claude preferred to call them). Claude was surprisingly good at creating file names (by first deriving context from the file itself), although I generally also reviewed and approved any changes.

Issue #2: Claude Stopped Working Mid-Task

In the past couple of days in particular (mid-September, 2025), I’ve encountered an issue where Claude seems to randomly stop working mid-task. It wasn’t always obvious when this happened; the task stayed in the list, but the tell was that the orange “thinking…” text disappeared.

When asked why it stopped working or re-prompted to continue, Claude would usually carry on as expected.

Sometimes Claude would stop repeatedly, requiring multiple ‘go on’ prompts even when I asked it not to stop until the task was finished.

Occasionally Claude even insisted a task was running when it had clearly stopped.

I’d just accept this and have Claude continue.

Issue #3: Claude Goes Too Far In The Wrong Direction

The most painful issue was when Claude seemed to spiral down the wrong path. Often the root cause was simple, such as a miscommunication or wrong assumption, like Claude confusing two similarly named files.

In a few instances, this led to a CI/CD Check failure; GitHub Copilot was actually really helpful here to request “details” about the failure, which I could then pass to Claude if relevant.

On a couple of occasions, the best course of action (although painful) was to rollback to the latest working version, take a break, and try again with a fresh instance of Claude.

While hard resets often were frustrating to do, on more than one occasion, I found that reverting changes and trying again later led to a totally different outcome. More than once, I ended the night stuck, only to return the next morning and solve the same issue in minutes.

This reinforced why frequent commits and PRs mattered, since they let me direct Claude back to a version I knew worked.

Conclusions: A Powerful Pairing, Proceed With Caution

Using Claude to rebuild our website has been a powerful experience. That said, proceeding with caution is essential here. For my early PRs, I had a developer teammate give feedback so that I could better understand what to look for myself.

Since our landing page is isolated from core product code, the risk was minimal. That said, I was constantly sanity-checking what Claude was changing. If I ever “vibed” too hard and lost focus, Claude would sometimes change the wrong files.

Beyond matching the designs, I had to consider factors that I understood in the abstract but had never built for at this level of complexity. To be clear, this is all far simpler than our core product, but more complex than anything I’d tackled before myself. Testing, accessibility, performance, code quality, and architecture all became more important as Claude, under my oversight, made changes. These often required iteration and experimentation, and as I grew more familiar with the part of the codebase Claude was touching, I developed better ideas for improvements.

Being able to rebuild our website as a non-engineer has been transformative. Still, I wouldn’t trust Claude, or any AI agent, to touch production code without close human oversight. My developer teammates were invaluable beyond my own checks. The real power right now is in pairing: humans set the direction, and AI accelerates execution.

Initially, through vibe coding, I built small software projects entirely from natural language prompts without editing or writing code. These were very simple, relying heavily on vibe coding with easy integrations for the auth/database via Supabase and to GitHub to deploy. See an example I shared on X earlier this year here.

Over time, I began blending vibe and agentic coding to progress beyond prototypes and into simple, shippable apps. A recent example: I built a couple of personal website variants (site one and site two) and moved this blog onto its own domain.

Tackling a New AI Development Challenge: Our Startup’s Website

Recently I had the opportunity to apply my vibe and agentic coding skills to something different. We had designs ready for a refreshed landing page for our startup CodeYam and wanted to get these shipped as soon as possible. At the same time, our developers needed to stay focused on our top priority of improving the core product. Rather than add the landing page to their workload, we decided to see if I could handle the website changes myself.

This felt different from starting fresh with a vibe or agentic coded project. It seemed much closer to a traditional web development workflow, but with AI tools integrated into the process.

Tooling Snapshot

AI vibe and agentic coding tools evolve quickly, so consider this section a snapshot of my experience only and not guidance for future tooling decisions.

For greenfield vibe coding when there’s no existing designs or code repository, I often start with v0 by Vercel. Since our designer had the new landing page in Figma, I tried v0’s “Import from Figma” feature. Unfortunately, I repeatedly hit errors importing the large and complex files and frames and had to abandon this approach.

Since my usual flow of vibe coding followed by agentic iteration would not work, I shifted into a full agentic workflow. I tested four editors:

• Visual Studio Code (VS Code)

• Cursor

• Windsurf (recently acquired by Cognition)

• Zed

I chose VS Code for its effective integrations with the agentic tools I wanted to use. I have heard great things about Cursor from engineers using code complete and Windsurf from engineers working with detailed specs and/or agent instructions, but neither felt quite right for me for this project. Zed is newer but feels like one of the first editors designed AI-first, and I am excited to see how it evolves but it did not feel as robust yet for the integrations I needed.

Comparing CLIs

I also tested several Command Line Interfaces (CLIs) and Model Context Protocol servers (MCPs). On the CLI side, I tried:

• Claude Code by Anthropic

• Gemini by Google Cloud

• Codex by OpenAI

• GitHub CLI by Microsoft (used primarily by AI agents directly)

I did not expect much variance, but these experiences felt surprisingly different.

Claude Code stood out for usability and felt intuitive even for me as a non-developer. Codex flooded my terminal with data I could not parse. Gemini sometimes strobed as it processed, which created an uneasy visual effect. I expect all of these tools will continue to improve, but for this landing page project I relied primarily on Claude Code’s CLI.

The GitHub CLI was used in conjunction with Claude Code’s CLI, rather than separately (I used Claude Code’s CLI, and Claude as an agent used GitHub’s CLI at times).

Model Context Protocol Servers (MCPs)

Alongside VS Code and the Claude Code and GitHub CLIs, I primarily used:

• Figma Dev Mode MCP Server (Beta)

• GitHub MCP

I also attempted to use Figma Code Connect but abandoned this after running into setup issues. The Dev Mode MCP Server (Beta) was simpler and effective enough for my needs.

Within Claude, I tried creating my own agent, an AI design engineer with Figma MCP superpowers. However, I often found that the default agent experience worked better than my custom agent (this was my first attempt to create an agent of my own within Claude though).

In the past, I’ve used Cline via a VS Code extension but did not find it necessary for this project.

There were a number of quirks in how the Figma Dev Mode MCP Server (Beta) worked, both alone and in combination with Claude Code. This led to occasional connection errors and/or odd outputs, but eventually (and after lots of experimentation and iteration) I was happy enough with the outcome to open a pull request to merge my changes into our main development branch.

Takeaways

This experiment showed me that agentic coding isn’t just for prototypes or side projects. It can enable non-developers to take on production work that once required a dedicated engineer. That said, I wouldn’t yet trust these tools outside of siloed, low-risk contexts. That said, the progress is remarkable. With how quickly the tools and workflows are evolving, I’m excited about how more non-developers might be able to confidently interact with and build useful code.

For now, though, humans remain essential. We’re still heavily reliant on human review and approval of agent-assisted changes. Ultimately people, not AI agents, are and must remain responsible for the quality and safety of their product and code.

For now, it’s back to building. My (human) colleague reviewed and merged my pull request yesterday. Now Claude Code and I are pairing up again to get additional site improvements into merge-ready shape.

The new landing page will live in its own dedicated space, where our designer and I will test before switching fully to production. As I make progress, I plan to share more about how I combine these tools and what I am learning as we get closer to launch.

AI has changed how many of us build software, and led to a number of new promising tools and processes that are rapidly and continuously evolving. Sometimes, you describe what you want and the AI spins up an entire app. Alternatively, AI agents will work alongside you in your repo, editing files and refactoring code as if it were a developer teammate. While both of these are technically AI-assisted software development, their nuances are quite different.

At , our team noticed we were using the term “vibe coding” without a shared definition, which was pretty confusing. Once we defined “vibe coding”, we realized there was another distinct pattern of using AI for software development that we now call “agentic coding.” Naming this distinction has helped us better explore and understand different AI-native tools and approaches for software development.

Vibe Coding

Vibe coding is building software entirely through a natural-language interface, without reading or editing the underlying code. You describe what you want, the AI builds it, and you interact only through prompts and high-level configuration.

Typical traits:

• No direct code manipulation

• Iteration happens through prompting

• Often starts from a blank slate or a boilerplate template

Common vibe coding tools: v0 by Vercel, Lovable, Figma Make, Bolt.new, GitHub Spark, Firebase Studio, Base44 (and there are many others).

You might still connect to services like Vercel (for deployment), GitHub (for version control), or Supabase (for database/auth), but you are not inspecting diffs or reasoning about the code’s architecture.

Vibe Coding Strengths:

• Very fast idea-to-prototype turnaround

• Low barrier for non-developers or early experimentation

• Feels like an evolution of no-code tools, with fewer rigid constraints

Vibe Coding Constraints:

• Not ideal for granular changes or debugging

• Less visibility into technical debt or maintainability

• Harder to ensure production-grade quality or security

Agentic Coding

Agentic coding is when AI agents directly interact with your codebase, often with repo access, editor integration, or CLI commands. You still have visibility and control, but the agent accelerates your work, edits multiple files, and can handle multi-step workflows.

Typical patterns:

• Pair programming agents (e.g., Devin by Cognition, GitHub Copilot)
  Full editor replacements (Cursor, Windsurf, Zed)

• Editor extensions (Anthropic’s Claude Code in VSCode, Cline)

• CLI-based agents (OpenAI Codex CLI, Gemini CLI, Anthropic’s Claude Code CLI)

Agentic tools often integrate with MCP Servers to pull information from other parts of the toolchain. For example, Figma Dev Mode MCP Server (Beta) can pass design specs into your coding environment and GitHub MCP Server can surface PR data or repo context.

Agentic Coding Strengths:

• Fits into established engineering workflows

• Enables targeted changes, refactors, and bug fixes

• Better for maintaining long-lived codebases

Agentic Coding Constraints:

• Higher learning curve than vibe coding

• Requires some technical fluency to be effective

• Speed gains depend heavily on integration depth and agent quality

What About Just Using ChatGPT or Claude to Write Code?

There is also a lighter-weight style of AI-assisted development that is neither vibe coding nor agentic coding. This is when you use a general-purpose LLM like ChatGPT, Claude, or Gemini to generate or explain code or a spec, which you’d then paste manually into your editor (for code) or into a vibe or agentic coding tool (for a spec).

How it works:

• You describe what you need in a chat window

• The model returns code snippets, specs, or explanations

• You copy them into your project or tool and adapt as needed

Why is this different? When compared to…

• Vibe coding: you still work in your own environment and see the code directly

• Agentic coding: the AI has no persistent repo context or direct integration

When it’s useful:

• Writing prompts or specs that you later use for vibe or agentic coding

• Small utility scripts or isolated functions

• Learning a new framework or API

• Getting unstuck on syntax or logic errors

• Early-stage exploration before deeper integration

Constraints:

• No persistent context across files or sessions

• Manual integration means more chances for mismatches

• Slower for multi-file or large-scale changes than agentic tools

For many, this “chat assist” approach is the most common entry point into using AI for development. It has almost no setup cost and works with any stack, but it does not match the speed or automation of fully agentic workflows.

Choosing the Right Approach

As a founder and former product manager who is learning to code, I have found that for:

• Greenfield projects: Vibe coding is the fastest way from idea to prototype.

• Existing codebases: Agentic coding is better for precision, quality, and maintainability.

• Hybrid workflows: Start with vibe coding for speed, then move to agentic tools for production readiness.

Today, most experienced developers and non- or less-technical builders I know, including myself, prefer a fairly similar stack: Claude Code in the CLI + VSCode or Cursor, with MCP Server integrations where possible.

For example, I am currently working on our CodeYam landing page website refresh and have been testing Claude Code with the Figma Dev Mode MCP Server (Beta) to translate designs into TypeScript/Remix. This experiment has shown me where these workflows work well and where they still fall short, especially when translating complex design files into code.

Why The Distinction Between Vibe and Agentic Coding Matters

The line between vibe coding and agentic coding is already starting to blur. Tools like v0 hint at hybrid models where you might start with a prompt-driven build and then transition into a more agentic refinement loop.

For builders, the key is knowing which approach fits the job. Vibe coding excels at rapid prototyping and greenfield projects. Agentic coding shines when precision, maintainability, and production readiness matter. Many developers end up mixing both, starting with speed and moving toward control.

This is still a new framework, and I am continuing to test how I use AI to help build software on various projects. I will share more from my experiments soon. In the meantime, if you have your own working definitions or see the split differently, I’d love to hear your perspective.

Leave a comment

This morning, I was surprised and delighted to see CodeYam mentioned in CNBC’s coverage of the IPO, in a piece by Jordan Novet on “Figma CEO’s path from college dropout and Thiel fellow to tech billionaire.” I had written about trying Figma Make, their AI tool for going from prompt to prototype, back when it was still in beta. I compared it to other vibe coding and prototyping tools like Vercel’s v0, Lovable, Firebase Studio, and Bolt.new. Here’s the quote:

“Nadia Eldeib, a former Lyft product manager and CEO of startup CodeYam, tried Figma Make before the broad launch and put it up against Lovable and v0. Writing on Substack, she said it appeared to be at an earlier stage.

It’s the sort of feedback that Field will read and send to his employees, known as Figmates. He reads support tickets and mentions of Figma’s name on X, formerly Twitter. He took no time off to address such matters on the very day that his company was conducting its IPO, ultimately pricing shares $1 above the expected range.”

At first, I just shared the article with a few folks (hello, family group chat), but the moment felt worth reflecting on more deeply.

When I left Lyft in 2021 to join South Park Commons as part of their first Founder Fellowship, one of the earliest questions I had to answer was what kind of founder I wanted to be, and what kind of company I hoped to build.

At Lyft, I had worked closely with teams led by former startup founders and joined through the acquisition of Kamcord. Those experiences shaped how I thought about leadership and what it means to build something meaningful.

As part of the SPC fellowship, there was a curated reading list that I believe was assembled by Avichal Garg, Finn Meeks, and Aditya Agarwal. Their recommendations still stick with me. While the full curriculum is SPC-confidential, I noticed today that one piece in particular stood out in my notes: “Why Figma Wins” by .

It described a product built on real technical innovation, grounded in product-led growth, and focused on delivering deep value to both individuals and teams. That combination stuck with me.

At SPC, I got a much closer look at different founders who I’d previously followed from afar. The four who inspired me the most personally were:

• Dylan Field of Figma

• Blake Scholl of Boom Supersonic (formerly Kima, acq. Groupon)

• Dustin Moskovitz of Asana (formerly Facebook)

• Mike Krieger of Instagram (now at Anthropic)

Each seemed to have reached a clear view of the problem they were solving and how technology could unlock a better path forward. They built tools that helped people work better, create more easily, or do things that hadn’t been possible before.

That mindset shaped how I approached the early stages of starting . It still shapes how we build. We’re working on a new kind of tool for developers, vibe coders, and eventually anyone building software. Our goal is to help people better understand and interact with what they’re creating, even when much of the code is being written by AI agents.

We’ve spent over 18 months in R&D, developing a focused vision of the problem, the product, and the underlying technology. Four years in, it still feels early. And I wouldn’t trade this journey for anything.

So today feels like the right time to say congratulations to Dylan and the Figma team. Your work has had a real impact on me. We’ve used Figma and FigJam since the very beginning of CodeYam (and even earlier, during my pre-idea phase at SPC), and I’m excited to try Figma Make again now that it’s generally available.

Congrats Figma and Dylan, and thank you.

This was especially true for complex systems, like those I experienced at Lyft while working on new rider products. While I felt at home in a product or business review, or even an engineering retrospective, as a product generalist with no formal coding background, I was afraid of getting into the code itself, let alone modifying it.

Now, as a startup founder working with an extremely technical co-founder, (a Pivotal Labs alum and repeat founder), I find myself increasingly drawn to understanding not just what software does or what value it adds, but how it works and how we build it.

In the past, when I tried to learn to code, the biggest roadblock was my time. I never felt I had enough time to deeply understand concepts, debug issues, or go beyond simple examples. I tried low-code and no-code tools as well, but the results were underwhelming. They worked well for basic prototypes or simple websites, but as soon as I wanted to create something unique or complex, I hit a wall.

Curiously, AI has helped me on both these fronts:

1. With AI, it’s easier to learn how to code and debug issues than with previous resources;

2. With agentic experiences and “vibe coding” tools, it’s easier to go from natural language to software application.

More recently, I’ve been pushing on learning how to code (traditionally), how to build software (agentically), and how to find the best of both worlds with AI-native software development and the emerging wave of new tools, editors, and agents.

While AI has made software development more accessible, a big gap still exists between prototyping and production.

AI Rubber Duck: Learning How to Code and How to Think About Coding

At the end of last year, I completed Harvard’s (in)famous CS50: Introduction to Computer Science class through the free online version. One of their newer tools is an “AI rubber duck debugger” with five hearts that decrease as you ask for help. When you run out, you get a “zzzzz” response until they replenish. It’s part video game, part token-meter, part rubber ducky. It was a godsend.

It helped me when I got the most stuck, but it also encouraged me to pause and think critically, rather than just offloading the problem to the AI.

Throughout this experience, I didn’t want the AI to write my code. I wanted it to help me think through problems, debug my logic, and occasionally show me a missing concept or better structure.

As an undergrad at Harvard years ago, there was an emphasis on learning how to think, not just what to know. AI enables this style of learning more efficiently, if used intentionally.

But AI is a double-edged sword. It can also help you skip learning and do more with less foundational knowledge. Feed some code with a bug into Claude or a spec and see what happens; odds are, you’ll get (re)written code returned. That’s powerful, but risky. In software, ignorance isn’t bliss. It’s bugs, inefficiencies, and security vulnerabilities.

This brings me to learning to “vibe code”.

Vibe Coding: A New Way to Build Software Applications

ChatGPT defined vibe coding as follows:

“Vibe coding is intuitive, flow-based programming driven by creativity and mood—not structure or strict plans.”

This can take the form of agentic experiences like Devin, or AI-enhanced editors such as Zed, Windsurf, Cursor, and GitHub Copilot. For me, it often means using natural language-to-app tools like v0 by Vercel, Lovable, bolt.new, or Firebase Studio.

These tools are a big improvement over the low and no-code platform experiences I tried in the past. But they still have limitations.

You can go from nothing to something quickly, often with a decent UI and some functional logic. But getting from an initial build to something production-grade is much harder.

I’ve been building low to moderately complex web apps with these tools, such as calendars and multi-page to-do apps. Here’s the workflow I’ve found most effective:

1. Prompt the AI to generate a product spec first, not the app itself.

2. Iterate on the spec until it looks solid.

3. Once it’s ready, ask the AI to build it. Usually this requires connecting to a service like Supabase first.

4. Iterate repeatedly, using both the preview window and a live URL to test.

There are quirks. For example, v0 sometimes gave me human-oriented multi-week roadmaps instead of just building what I asked. I had to be very clear that the tool was supposed to do the work.

Other experiences were frustrating rabbit holes. For instance, I couldn’t figure out how to switch my Supabase integration from a free to a pro account in v0. As a temporary hack, I’ve been reusing two free databases. That’s not ideal for anything beyond disposable side projects.

With Lovable, a deployed site showed a broken sign-in page that didn’t match the preview. It took five or more prompts to fix. Eventually it worked, but I still don’t know why.

Still, it’s been fun, and sometimes intensely annoying. Even something as “simple” as building a to-do app feels wildly different across tools.

I suspect my background as a product manager helped. Years of working with engineers trained me to think clearly about software, write strong specs, and communicate ideas well. All of that improves prompt quality. And with vibe coding tools, prompting well is the most important skill.

AI-Enabled Feedback Loops Are Critical, No Matter How You Build

The more I experiment, the more convinced I am that we need new tools to help people interact with the software they’re building through AI. Prompting alone isn’t enough.

That’s what we’re exploring at . We’re building a simulation-based IDE to make navigating, understanding, and debugging AI-generated code easier. This is something I have wanted on nearly every project I worked on.

Just as the rubber duck debugger saved me hours while learning to code, CodeYam could have saved me hours dealing with strange bugs in my current projects. We’re still in R&D, but I’m excited about what’s coming.

Right now, both experienced developers and newer builders like me can feel that AI is transforming how we build software. But building software has never just been about writing code. It’s about creating user value, iterating fast, testing, debugging, maintaining, and evolving your product.

The future I imagine is one where more people can participate meaningfully in software creation. It’s also a future where professionals can work with more power, precision, and creativity than ever before.

A crucial early step in qualitative user research is determining who specifically to talk to - who will provide relevant, representative feedback that leads to larger learnings? If you don’t talk to a group that you’re confident represents a broader range of opinions, your conclusions are not generalizable and it becomes difficult to decide on what to do next or how to apply your learnings.

What if you don’t know who your ideal customer profile or target market is?

If you're pre-product in the inception or idea stage, you might not have a well-defined target audience or ideal customer profile (ICP) yet. Or your current definition might lack specificity and detail. Don't panic! This is common in the early stages.

However, this can often lead to the instinct to throw a spaghetti-like mess of ideas at the wall to see what sticks. “I have a great idea,” you might think, and “if my friends and family say they like it then it must be great and I’m on the right track.” Wrong!

This is a dangerous trap, described extensively in The Mom Test. Your friends and family are likely biased towards being kind and positive. More importantly, unless they share specific identifying traits, they don't represent a replicable group of early users.

Even if they genuinely love what you're building, you'll struggle to find your next users once you exhaust your personal network if you don't know what characteristics to look for instead of randomly approaching potential customers.

People have a huge range of needs, wants, habits, and existing tools and you are not likely to succeed or learn quickly by taking a random approach. Instead, you’re relying on luck. While luck matters, I’ve found as a founder that I am more likely to “get lucky” through tight learning loops where I test specific hypotheses with particular groups who share common traits. This approach allows me to validate or invalidate ideas faster and apply insights to subsequent iterations.

Even for consumer applications, where theoretically your market might one day be “everyone with a smartphone” (e.g. for a mobile social app) you still benefit from narrowing down in the early stages to a specific hypothesis about your earliest adopters. What are the characteristics that make someone likely to be one of the first to try your product?

For a business targeting enterprise customers or developers, you might need to segment into distinct groups: your buyer and user might be different people, and your organizational champion might be yet a different stakeholder.

How do you decide who to talk to?

For each persona, identify their key attributes to clearly visualize who they are - and who they aren't. If this feels overwhelming, start by prioritizing just one group.

I typically start with the group I have the strongest hypothesis about and/or the group I expect will provide the most valuable insights through user research interviews.

In his blog post “How to find great participants for your user study”, Michael Margolis shares a useful worksheet for creating user research participant screeners that I’ve also found helpful in defining my ICP for research sessions.

While you don't need to use this exact worksheet, you should develop a clear sense of the defining characteristics that will help you identify appropriate participants for your user research interviews.

Recent Example: CodeYam Landing Page Research

At CodeYam, the startup I co-founded with Jared Cosulich, we're developing a new category of tools for software developers and their teams. Our product, called 'software simulation,' combines several technologies including generative AI and static code analysis to create a new application.

A key challenge is that while 'software simulation' is a new term, it most accurately describes what we're building. More familiar terminology would lead to incorrect assumptions about our product.

Our terminology is inherently ambiguous to anyone not intimately familiar with our team and product. As an early-stage startup launching a new product, that currently includes most people.

We aim to be precise in how we define this new tool for software builders and communicate its value, particularly for understanding and testing code changes, whether they're AI-generated, manually coded, or a combination of both.

We decided to run several landing page tests for CodeYam to refine how we describe our product and communicate its value.

Before this, I had attended several industry events (including Google Cloud Next, GitHub Universe, the Female Founder Retreat, Boldstart Founder Summit, and local AI-focused meetups for founders and developers in Boulder and Denver). These conversations generated new ideas for describing and positioning CodeYam, based on my impromptu experiments with different explanations and noting who showed interest.

My cofounder and I also explored extracting part of our core engine into a standalone product. This approach would let developers experience CodeYam earlier through a playground environment or a focused tool for automatically generating mock data, which could be a significant time-saver for development teams.

For our user research sessions for the landing page, this is what we decided on for our criteria:

We used our own variation of Jake Knapp’s Design Sprint FigJam Template to stay organized.

Once you’ve defined what traits to include / exclude, there are two crucial next steps:

1. Figure out where you'll recruit participants from

2. Establish how you'll screen responses

Figure out where you’ll recruit participants from

This approach varies significantly depending on your startup's stage and whether you're pre- or post-product-market fit.

If you have existing customers and usage data, these can effectively pre-screen candidates for user research. For instance, I frequently receive emails from larger tech companies (usually from product managers or dedicated researchers) seeking feedback from early-stage founders like me who have used specific features or match certain behavior patterns. They can identify potential research participants based on their usage data and contact us via our registration emails. Many of these companies add an additional screening layer, such as a brief survey, to verify eligibility for specific research initiatives.

As a brief aside, I love participating in these sessions. Providing feedback on products I regularly use (or have churned from) is as enjoyable for me as it is valuable for their teams. As a bonus, I learn firsthand how leading high-growth companies design and conduct their user research. I can adopt effective methodologies for CodeYam and note what approaches to avoid when sessions feel cumbersome.

At Lyft, I worked with an exceptional UX Research team within the Design organization built and led by Katie Dill. Collaborating closely with this team, I witnessed firsthand their invaluable contributions to ensuring we gathered feedback from relevant users, prioritized effective product and marketing strategies, and learned from every launch. Their research helped us mitigate risks before building and launching innovative features, for products ranging from the rider app itself to new products like electric bikes and scooters to transit payment systems.

Sometimes we utilized external vendors such as User Testing. While expensive, these services save significant time when you have clearly defined participant criteria, need rapid prototyping and research iterations, and prefer not to handle participant recruitment yourself.

As an early-stage startup, our approach differs significantly. Rather than spending substantial money on user research, we focus on staying scrappy by handling our own recruitment and screening.

In this scenario, identifying where your target users already gather and reaching them there becomes even more crucial. Adopt an 'always recruiting' mindset to maintain a pipeline of eligible participants ready for any upcoming research cycle.

For CodeYam, given our criteria, we decided to recruit from the following platforms:

1. Craigslist (specifically in the SF jobs and computers gigs sections). While results vary, we've found eligible participants here previously. With a well-designed screener that's difficult to game, this platform can yield good participants.

2. Social media posts primarily targeting second-degree connections and non-connections matching our feedback criteria. I focused primarily on LinkedIn and X, and have recently expanded to Bluesky and Threads.

3. Selective posting in communities with high concentrations of our target audience. We use this approach sparingly to avoid community fatigue. Some communities, like the Next.js Discord, prohibit research recruitment entirely; be mindful of that and always respect each community's guidelines.

4. As a final option, direct outreach to individuals in our personal networks who match our research criteria for specific rounds.

"We're also planning to experiment with these additional recruitment channels:

• Reaching out to qualified CodeYam waitlist subscribers who meet our research criteria

• Targeted outreach to specific individuals who match our criteria and whose feedback would be particularly valuable

Fair warning, recruiting often feels HARD. That’s normal and it’s going to require consistent energy and effort. You’ll likely get progressively better with each iteration.

If you feel like you can’t find folks in your target demographic, that’s a yellow flag. You'll eventually need to reach these same customers once your product launches. Difficulty finding research participants should serve as a warning sign. Typically, finding and recruiting people in your target audience becomes harder, not easier, as you exhaust the low-hanging fruit.

Recent Example: CodeYam CraigsList Post in SF

One thing we’ve gone back-and-forth on in posting to Craigslist is how much to reveal in your post about who you’re looking for.

In previous research, we kept descriptions deliberately vague to prevent candidates from tailoring responses to match what they thought we wanted, rather than representing themselves accurately.

Recently, we've tested being more explicit about who we want to speak with, specifically using headlines that appeal directly to developers and technical leaders. Results have been mixed.

While this approach attracts more relevant candidates, we've encountered some who successfully gamed our screener, forcing us to cancel sessions at the last minute. We're improving our evaluation process, but it remains a work in progress. More on this approach in the next section.

Establish how you’ll screen responses

For CodeYam, we use Google Forms to collect screening responses, then export these to a spreadsheet to evaluate potential participants. This allows us to efficiently categorize candidates for either current or future research sessions.

Here’s our most recent screening survey: https://forms.gle/khKxsVPwQeT1UNbw8

We've reused variations of this survey a handful of times, initially setting specific research dates, then keeping the link active with broader timeframes. This allows us to continuously collect responses even after completing a specific research round.

A few additions we've found especially helpful in our screening process:

• Requiring participants to provide a public social media handle (preferably LinkedIn) where we can verify their identity and background. While not perfect, as not all developers maintain social profiles, this has significantly improved participant quality. When applicants don't provide this information, they typically prove unsuitable for our studies.

• Requiring participants to join research sessions using a laptop rather than mobile devices, which previously caused difficulties viewing prototypes.

• Requiring participants to keep their camera on during sessions. This helps with identity verification and allows us to observe genuine reactions to our prototypes: confusion, excitement, etc. Recently, we caught someone who had appropriated another person's LinkedIn profile and biographical information; their true identity became immediately apparent once on camera.

Additionally, while your headline might state who you're looking for, the screener survey itself should avoid revealing your specific selection criteria. Making these too obvious encourages applicants to tailor their responses to what they think you want rather than representing themselves accurately. Surprisingly, we've encountered this issue multiple times even with seemingly straightforward screening questions.

Recently, we've noticed what appear to be AI-generated responses in our screening surveys. After initially being caught off guard, we identified patterns that made these formulaic submissions evident. While we may eventually use AI to assist with screening, our current volume is manageable enough for manual review.

Managing Recruiting and Scheduling

When reviewing screener responses with an established research schedule, I identify top candidates and match them to their available time slots. I typically create a dedicated scheduling tab within the same spreadsheet to organize this process.

Here’s an example (with fake data):

Once I know a person who I want to slot into a time slot, I’ll send them a personalized email using this template:

Recently, I've started using Superhuman's snippets functionality to streamline my email outreach. While I still manually update day/date/time information in the subject line and body, plus verify the recipient's name, these snippets significantly reduce the time spent drafting each invitation.

Alternatively, once you've sent this email once, you can simply copy the sent message into a new draft, updating only the recipient's email address, their name, and any time-specific information. This approach works well if you don't have access to email snippet-like templating functionality.

Once a participant confirms availability, I send them both a confirmation email and calendar invitation containing all the meeting details.

Here’s what the confirmation email looks like:

And here’s what the calendar invite looks like:

As soon as we establish session timeframes, I create calendar HOLD events and invite team members who will participate in the research sessions. Currently, our product designer Dani joins these sessions as an observer and note-taker. We also use Granola to generate an automated transcript and take meeting notes; in the past, we recorded sessions but found we never re-watched the recordings so that was overkill.

Finally, one day before the research session is scheduled to happen I’ll send a reminder email out. That looks like this:

I also verify that each participant has recently confirmed their attendance and ideally accepted the calendar invitation (though this isn't always the case).

TL;DR and Key Takeaways

Effective user research depends critically on recruiting, screening, and selecting the right participants. To succeed:

1. Define precisely who you want to interview and their key attributes.

2. Identify channels where your target participants already gather.

3. Implement thoughtful screening to identify truly qualified participants.

4. Develop a simple system for managing participant communication and follow-up.

Our current process blends automation with manual effort, and we continuously refine it.

Recruitment becomes particularly challenging when seeking participants with highly specific attributes—so recruit early and continuously, well before scheduling specific research slots.

I hope you find this helpful! Have feedback or questions? Please reach out.

You can also follow what we’re building at CodeYam more directly at blog.codeyam.com.

If you’re an early-stage startup founder, learning velocity is critical. Being able to test and reject or double-down on hypotheses to help you establish if you’re building the right business and product for the right customer and market is essential.

When you’re in the wilds of pre-product market fit and navigating the idea maze, you need ways to orient and learn whether you’re going down the right path – or about to hit a dead end.

Why I’m Writing About Gathering Qualitative User Feedback

While The Mom Test book by Rob Fitzpatrick is an oft-referenced and useful resource, I thought I’d share a bit about how I’ve approached getting feedback on early explorations as a founder for CodeYam and over the previous decade while working at technology startups. This is a practice I’ve honed over time and I’m still constantly learning, improving, and experimenting.

This journey began when I discovered the Design Sprint book and process developed by the team at GV while working at a startup called Kamcord roughly circa 2017. On and off (as needed) over the years since then, I have been using variations of that process, along with the accompanying GV Research Sprint created by Michael Margolis, to help get unstuck, speed up learnings, and test out new ideas in low-risk ways.

If you worked at a larger technology company, “design sprint” often comes with a very different set of connotations; you might imagine designers blocking off a week (or more!) of time on the product and development team calendars and spending it working on ideas that, while fun or interesting, are never going to be priorities to build. This whiteboard whimsy that leads to no real results is the opposite of what I’m talking about, and using facets of the sprint process to accomplish, here.

Instead, we’re trying to get real feedback from potential customers and/or users of a product (or that might be users of a potential future product that hasn’t yet been built). We are trying to get relevant feedback from a small, representative group as fast as we can to test our risks, hypotheses, assumptions, and to inform how we successfully meet our goals (or fail faster and move on with the learnings).

A Note on Using AI Tools for User Research

New AI tools can likely be a big boost in terms of getting useful feedback faster. However, I’m still experimenting with how best to use those in this process. I will share what I’m doing today, although I anticipate this may change.

That said, as an early-stage founder, it is fundamentally important to be “in the arena” and talking to the people that are, or might become, your buyers and/or users.

Even if your product is meant to be used by AI agents, there’s likely a human somewhere along the way responsible for those agents and/or buying your product and deciding to deploy it. Find and talk to those people.

Use AI tools to sharpen hypotheses and accelerate testing, but don’t use it to replace talking to your human customers or users.

How I’ve Learned from User Research

Some areas where I, often with a small team although sometimes solo, sought qualitative feedback and used elements of the sprint process successfully include:

• Testing out new product ideas (happening now)

• Testing out value propositions and messaging (also happening now)

• Testing out landing pages

• Learning about a user group or market

• Validating (or invalidating) that you’re actually tackling a meaningful problem / pain point

• Getting early signal about willingness to try a product or service

• Learning about willingness to pay

• Figuring out what parts of a product’s UI / UX are working or are confusing

• …among other use cases.

One counter-intuitive insight is that user research is an excellent tool to help you realize when you’ve failed to achieve your objective. Maybe the idea you fell in love with just doesn’t do it for the group you thought would be your customers. Maybe you realize the market is too small or too hard to reach. One of the biggest values of qualitative research is being able to fail, and learn from those failures, faster.

By reducing the amount of time and effort it takes to realize something doesn’t work, you’re extending your runway to experiment and iterate to get to something that is extraordinary.

If you’re a venture-backed startup, you’re probably taking a big, ambitious swing (we are at CodeYam!). Being able to learn through faster feedback loops that qualitative research unlocks is immensely valuable. It helps you make progress, or pivot, faster and with greater confidence.

Whether we’re testing an actual software product or just raw ideas through design prototypes, we’re able to get a “good enough” version of our hypothesis in front of our target audience and learn from their honest reactions.

What This Series Will Be About

This post kicks off a new series (length TBD) that dives into a bunch of connected user research topics; from figuring out who to talk to, where to find them, how to ask the right questions, and how to gather useful qualitative feedback. I’ll be pulling in real examples from CodeYam and past research to bring this all to life.

Some themes I’m thinking about covering:

• How to recruit the right people for user research, especially pre-product

• Designing a solid research guide

• How to run a research interview

• Deciding what to test (and when)

• How we’re approaching user research at CodeYam

• Hard-earned lessons from past research efforts

• Speeding up research workflows with AI

• Tools we’re using such as FigJam, Craigslist, Superhuman, ChatGPT, Claude, etc. and how they fit into the process

While startups' needs are never one-size-fits-all, my goal in sharing this is to help other founders, particularly those who are pre-product-market fit or conducting R&D to decide if they should pivot or double-down on a strategy or product direction. My hope is this gives other founders and their teams actionable insights and helpful tools to speed up their own feedback loops.

If you’re doing user research to explore startup ideas or make product or engineering decisions and have questions or feedback, I’d be happy to chat. Reach out any time at nadia [at] codeyam.com .

If you’d like to follow what we’re building and exploring at CodeYam, you can also subscribe to our company’s blog.

This year marks my third at the Boldstart Founder Summit. It's remarkable how much has changed from year-to-year, both for myself and our startup (CodeYam), the other founders, and the technologies we're building each day.

While last year AI-curiosity was a strong theme, this year everyone was sharing learnings and how they've adapted how they build software and, in some cases (like ours), what they're building to leverage the superpowers AI can provide for software development.

This year's format was an unconference with experienced founders hosting off-the-record discussions on prevalent themes.

Without getting into the off-the-record nitty gritty details, there were four categories that stood out to me in terms of the topics discussed:

1. The Evolution of Developer Experience

2. AI’s Transformation of Software Development Workflows

3. Product Comes First. But What About AI Agents as Users?

4. Business Insights for Technical Founders

1. The Evolution of Developer Experience

Developer experience (DX) is no less important in the age of AI-native software development. In fact, it might be more critical than ever.

Thinking "they're technical, they'll figure it out" about your users is a bad assumption, and you're likely radically underestimating how long it takes developers to onboard to your product or tool.

There's a lot to be gained from observing first-time users of your product and where they get stuck or hit bugs. While eating your own dogfood and testing your product is important, it's insufficient. It sounds silly, but a new user is only truly new once – and observing them is the highest-fidelity way to understand how to improve your onboarding experience.

The concept of "death by 1000 papercuts" resonated deeply when you think of a product you hate using, but aren't really sure why. The same is true for the products you're building; each small moment of confusion adds up and leads to a negative user experience and churn.

I've long been a fan of qualitative testing and using processes like GV’s Design Sprint and Michael Margolies’ methodologies to increase learning velocity. The benefits of user research and recording and/or watching users engage with your product, paired with AI tools to make data labeling and synthesis more efficient, cannot be understated.

Founders shared a lot of creativity not just around their own products but the tools they use. This was especially true for AI code generation and prototyping tools, of which there's been a Cambrian explosion that is challenging for even the most AI-embracing early adopter to keep up with today.

2. AI’s Transformation of Software Development Workflows

Every single founder I spoke with uses multiple AI tools today to help them build software. For some, this is primarily AI tools to help them write code such as Cursor, Cline, Codebuff, or Windsurf. Others are experimenting with AI editors like Zed or design-to-code experiences like bolt.new, v0, or lovable. Devin has great UX, but for the most part left a lot to be desired in terms of utility.

Still, even with the limitations or challenges of certain AI tools, many founders called out a "capabilities explosion" that has expanded the role of developers. "The role of product has completely changed," folks agreed, and the feedback loops from design to prototype to development to deployment have the potential to be tighter than ever before.

And if you're not taking advantage of the velocity boosts these tools can provide, you can bet your competition is. While there wasn't consistent agreement on what the ideal future of software development looks like, there was certainly consensus that how we're working needs to change – and for everyone in the room, likely already has.

Some see the future as orchestrating code, and ideas that once seemed silly or impractical now seem possible – although it's hard to say on what timeframe.

"Vibes" are also in, and vibe coding while using AI, while it has risks, is increasingly popular, especially for newer developers. Seasoned technical leaders, like keynote speaker Scott Yara, also are excited to return to writing code with AI.

3. Product Comes First. But What About AI Agents as Users?

In Scott's keynote, he reflected on decades of experience as a founder and technical leader. One of the things he said that most stood out to me was that "Product comes first" and that building something special is hard – so ask yourself, why is your product going to be special?

In terms of AI products, what does truly great look like? Waymo and ChatGPT are exciting examples, but we're still so early, and Scott suspects that more truly great AI software products are yet to come.

What we're building and how we're building is changing with AI. But so too, observed a few founders, is the demographic of our users. We're going from B2B and B2C to B2A (business to agent) and, eventually, maybe A2A (agent to agent). Thinking about how agents and AI indexes, finds, and uses your product is likely going to be increasingly important.

And it's early innings. A few founders have built developer tools recommended by AIs (e.g., Claude) but there are challenges – e.g., if an older version is recommended, or a newer version is not supported by models that your human customers are using to ask questions or debug.

Building for a future where humans, humans using AI, and AI agents are all using your product is increasingly important. But so is context. If something is mission-critical, it's likely that you're going to have a human-in-the-loop; e.g., nothing getting merged into a code base without a human review. On the other hand, in areas where there's lower risk to more truly agentic agents acting autonomously, there's room for more complete automation with less supervision – although still with appropriate boundaries and guardrails. Security is paramount.

This got me fired up thinking about what we're building at CodeYam, and how we are leveraging software simulation to give human users confidence in code changes. Making it easier to identify and address unintended side effects and bugs, regardless of if it's humans or AI generating the code (or some combination), is valuable.

4. Business Insights for Technical Founders

Boldstart optimizes for visionary technical founders, so it comes as no surprise that a lot of the teams are building products that are on the cutting edge of technology and AI today. When it comes to things like pricing, sales, partnerships, and enterprise adoption, there were a lot of hard-won learnings shared.

Without spilling anyone's secret sauce, I think it's important to call out that for enterprises, there's a dueling pressure to adopt innovative AI tools that can help their businesses but also still often fear working with startups. While some founders observed that, when sufficiently motivated, enterprise deal speed can move a lot faster than in the past, there are still hurdles.

One founder observed that "you have to sell the future like it's the past" – meaning fit into old paradigms for buyers while still delivering something new and better than what they bargained for. Backwards compatibility can act like a bridge that gets you into their stack and, once you've proved your value, you can land and expand your offering from there. Really proving out your value to potential customers early-on is critical.

E.g. Eliot Durbin’s observation on X:

Even in sales and partnerships, thinking about your learning velocity is crucial. Your learning rate "needs to exceed your competitors." Think of pricing as a product, and aim to learn and experiment accordingly.

Make sure you're defining, and measuring, the right metrics and you're focused on delivering value first.

Conclusion

What struck me most was how these themes interconnect: we're building the future of AI-native software development while we're exploring it as a room full of builders, which is simultaneously exciting and chaotic.

Velocity, as Ed Sim highlighted so effectively in his X recap, is essential.

The only thing I'm sure of is that next year's Founder Summit is going to be radically different from this year's, and I can't wait for how much I – and every other founder, builder, and operator – will have learned and built between now and then.

Thank you to Ed, Eliot, Ellen, Shomik, Ernest, Ron, Charlotte and the boldstart team and partners for bringing us together for these action-packed discussions. Thank you as well to the founders who led and joined sessions, shared insights and learnings, and were radically open about what’s working and what’s challenging today.

The sessions hosted by folks like Steve Manuel (Dylibso), Ian Jennings (Testdriver), João Moura and Rob Bailey (CrewAI) were incredible. I learned so much and left inspired.

Early on in my technology career, as an early employee at a YC-backed startup called Kamcord, if you asked me to picture a founder, I’d probably imagine…a hoodie-wearing dude living in SF who consumes gallons of coffee, Diet Coke, and/or Soylent and is constantly coding and gaming.

Or I’d picture Steve Jobs, who was (still is) venerated as the ultimate irreverent founder archetype.

To me, as an early employee, the trio of Kamcord founders embodied what startup founders ought to be: they’d worked on prestigious projects at companies like Google, graduated from MIT, and were Y Combinator graduates who’d raised money from major venture capital firms including GV (Google Ventures), Tencent, and Time Warner.

Our new product launches were reported on in TechCrunch time and again.

Even though the journey was not linear or straightforward by any means, I felt confident that with Kamcord’s founders and team, I was on a rocketship and just lucky enough to have a seat and be able to learn and contribute…well, anything.

From 2015 - 2017 while I was there, our team shipped and iterated a lot as we found, then lost, product-market fit. Through this experience, I learned that I love working on new technology problems and figuring out how to leverage these technologies to improve people’s lives.

I also learned that I love working on teams that build software products and being deep in the software development life cycle.

Kamcord’s team was acquired by Lyft (as also reported on by TechCrunch, naturally) and our zig-zagging rocket ship (in my opinion, anyway) docked at a much larger starship that was in the full throes of hyper-growth.

At Lyft, I worked with extraordinary people: from designers to engineers to EMs to product marketers to powerhouse people leaders. I learned how to create and manage a team, in addition to getting deeper into building software products – and going from 0-to-1 then scaling.

We had the opportunity to create products and user experiences that touched millions of people’s lives and increased the accessibility of transportation in cities across the United States. I personally also grew by tackling urgent and important high-visibility projects that required our team to frequently figure out new and better solutions. I honed my ability to figure out solutions as we went, including under great pressure to deliver – and fast!

In early 2021, after over three years at Lyft, I was recruited by the founders of a couple of promising startups to join their team as a founding product hire. Ultimately, I turned down these offers because my gut feeling told me it wasn't quite the right fit.

I started to reflect more seriously…what did I want to do? If I could do anything, what would most increase my velocity towards my north star?

I didn’t have an idea (yet), or cofounder (yet), or funding (yet)...but maybe, just maybe, I’d want to explore doing my own thing – at some point, in the future, when it made sense.

For the first time, I started to think that becoming a founder might be the best, and perhaps only way, to really go all-in on my goals and figure out the right problems to solve through technology and the best solutions through products. My calculus flipped from “why me” to “why not me.”

And right around then, something magical happened.

One evening, I had a catch up call with a friend (thank you forever for this, Mishti Sharma) who sent me this tweet from Avichal Garg:

“Oh” I thought “This sounds interesting.” On the spot, I applied.

It was technically a day after the deadline, but the Airtable form was still open.I was fairly convinced I’d never hear back from South Park Commons regarding the application I’d just sent into the void.

My SPC video submission answering: “what are the projects you’re the most proud of?” — I’m whisper-talking because I recorded the video late at night and didn’t want to wake up any neighbors.

But then I heard back. The SPC team wanted to chat.

In rapid succession, I met with Mitra Lohrasbpour (then a partner on the SPC Fund team) and Aditya Agarwal (SPC Partner and Co-founder). I was blown away by our conversations discussing what problems I might focus on – and what technology products I might build to solve them.

When Aditya told me I got into the inaugural SPC Founder Fellow cohort, despite being among the earliest stage of “pre-idea” founders in the batch, I was extremely surprised. And I said yes.

In my Founder Fellow cohort and the broader SPC community, I met brilliant, supportive peers. I learned many ways on how to validate and test markets, problems, and ideas (more on that in another post, maybe). I met my incredible co-founder and partner, Jared Cosulich, via the SPC community.

I want to add an important caveat here – being a venture-backed founder is for a specific subset of founders and startups. For the venture model to make sense, you need to have huge ambitions and the drive to achieve them (or fail trying) with incredible urgency.

And, as I learned at Kamcord, it’s a road that’s likely going to take longer than you thought and might not lead to the IPO you dream of when you start (in fact, most startups fail or are among the “living dead”, alive but going nowhere).

Becoming a VC-backed founder is not the only or even “right” way to become a founder for everyone, but it was at this point in time (and is today) for me. It matched the scale of my ambition (even without a specific idea) and the urgency I felt to build and scale a meaningful product that might benefit humanity or at least a significant subset (market).

Did I know I was fully ready to be a founder? Hell no. But I knew I’d learn and grow and have a greater chance of achieving the kind of impact I wanted to have in the world with my work.

Couldn’t I have done this part-time while at Lyft? For many, exploring startup ideas as a side-hustle is a viable option and a way to de-risk the earliest stages, but for me it really wasn’t. I was 100% all-in on my role at Lyft and I don’t think that’s a bad thing. I would not have felt right showing up to Lyft with less energy while simultaneously not giving myself the chance to go all-in on a new independent idea.

As a founder, it was important to me to find work that I was passionate enough about to want to think about nearly 24/7. I wanted what I was working on to matter so much to me that I’d basically be thinking about it constantly, from during the “work day” to Archimedes-style shower thoughts and epiphanies while surfing or on a walk.

With SPC, I knew I had partners and peers who had my back in going all-in even before having an idea or direction. And while I started as a solo founder, I quickly met a strong partner and co-founder in Jared with whom building together was even more extraordinary than exploring and building solo.

If you’re thinking about becoming a founder, I’d encourage you to ask yourself “why not”. You might have valid reasons, but you might also be surprised. I certainly was.

I have learned more in the past 4 years than in any earlier part of my career, and I continue to be fired up to solve hard problems for people creatively through the technology and products we create.

If you want to follow what Jared, myself, and our team are building at CodeYam, you can check out the latest demos and content here:

Visit the CodeYam blog

This is the second in what I hope will be a series of posts about my experience becoming and being a founder. You can find my first Founder FAQ post on “Did I always want to be a founder?” here.

If you enjoyed this or found it useful (or not), please share feedback. Your questions, suggestions, and comments will help me shape the future of this personal blog.

P.S. If you’re thinking about applying to South Park Commons, their current Founder Fellowship cohort application is now open (closes February 2, 2025). I tweeted about my experience here and here. I can’t say enough good things about my experience, the Founder Fellowship program, and the SPC team and community.

Special thanks to Dani Raskovsky for feedback on an earlier draft.

Share your voice and wisdom with a group of powerhouse women committed to advancing technology - and our place in it. It will be a unique opportunity to engage in meaningful conversations, exchange insights, and build valuable connections in a relaxed and bespoke setting.

Over a beautiful dinner at Dalida, Sara Dean facilitated a set of radically candid conversations around our experiences as senior technology leaders – and as women. One of the takeaways was to commit to an action item inspired by the evening.

As one of the only founders in the room, I was asked a lot of questions about my experience and committed to trying to be more transparent in sharing what I’ve learned. While I hope my perspective is useful to many founders regardless of their backgrounds, I would love to see – and inspire – more female founders.

Even beyond this dinner, I’m frequently asked questions such as:

• Did I always want to be a founder?

• How did I become a founder?

• How did I meet my cofounder?

• How did we decide on CodeYam?

• What is the founder work “life” like?

• …etc.

Answering everything in one go would be book-worthy, or at least book-length. In the rest of this post, I focus on the question of “Did I always want to be a founder?”. My goal is to describe my non-linear journey, and highlight some of the skills I learned and unlearned in becoming the software startup founder I am today.

Did I always want to be a founder?

Short answer: “no”.

As a kid, “what I wanted to be when I grow up” constantly shifted: from ice cream truck driver to an astronaut to a marine biologist to a lawyer. Becoming a software startup founder never crossed my mind.

It’s not for lack of exposure to business ownership; my mom actually is a serial entrepreneur. She founded a series of businesses during my childhood, ranging from petsitting (pre-Rover, she cornered our local market) to sports (she currently still runs the Fencing Sports Academy in Fairfax City, VA).

It’s also not for lack of exposure to science and technology; my dad has a PhD in Systems Engineering, worked at an Aerospace and Satellite Communications company, and now teaches Math and Computer Science. My younger brother learned game development and took apart / built a computer when we were kids.

Despite missing the early signals, in hindsight, my early passions are a natural fit for being a software startup founder. I was (and still am!) relentlessly curious and devoured books and drove my mom crazy with “why” questions. I loved creatively solving challenging and complex problems, spending hours inventing and then solving crazy math equations. I loved creating, often inventing games and fantastical stories for my classmates. And most of all, I loved helping people. Rather than growing out of these childhood passions, I feel like I had to learn to grow into them. This took years.

Relearning How to Learn: Recalibrating Risk Perception and Fear of Failure

As a freshman at Harvard, I initially chose classes in unfamiliar subjects based on interest. Many of my peers took the same classes for an easy A, which made for a punishing grade-curve. So, I adapted to an incremental approach choosing courses I felt confident I could succeed in, sometimes with significant effort. While this led to better grades, my choices were constrained to subjects that felt doable. I only began to choose more challenging courses again once graduation became more certain.

After college, unlearning this incremental approach took years. I had to overcome my fear of failure and a misdiagnosis of its inherent risks. Today, failure indicates that I’ve attempted something hard and meaningful. It’s an opportunity to learn. By failing to tackle something extremely difficult, I end up making greater progress and learning more than through a series of incremental successes. The risk is not in trying and failing; it’s in not trying at all.

While there are still perfectionist tendencies and moments where the fear – and pain – of failure resurfaces, I can separate out the emotions from the reality. It helps that I’m still a deeply curious person. I often reframe failure as a chance to learn through fun, or at least interesting, challenges and problem-solving.

Chasing My Curiosity to San Francisco: Startups, Pivots, and Hyper-Growth

Shortly after my college graduation, while working as a paralegal (full-time) and fencing coach (part-time), I felt an urge to explore. So, I pursued opportunities to fuel this curiosity through extracurricular classes, side projects, and volunteer work. I took an innovation in business class at Harvard’s Extension School and volunteered my time to support an EdTech startup.

Around this time, I noticed that mobile technology and software applications, especially social media, were exploding in usage. I’d been early-ish to Facebook (no surprise given where it originated) but now there was this app-explosion. I felt that technology was going to radically change our lives over the coming years, for better or worse (I hoped for better).

My career north star has been having the biggest positive impact I can on people at scale. I was drawn to software and technology and an urge to learn about this field and, if possible, have a positive impact. I wanted to be in the heart of this software application wave – and so I moved to San Francisco.

At the urging of a college friend, I joined the team at an early stage startup called Kamcord which was very early to mobile screen recording. When I joined, the team was working on an SDK (software development kit) for mobile game developers that allowed them to easily integrate screen-recording functionality for their players, along with a social community and video-sharing platform for mobile gamers.

A few months later, Apple announced a product called ReplayKit that offered the same functionality in a more native way. The Kamcord founders decided to pivot to mobile game live streaming, which quickly found product-market fit and took off.

Our streaming platform grew rapidly to millions of monthly active users (MAU) and some of the biggest streams had hundreds of thousands of concurrent viewers. Even more exciting, we launched virtual goods that enabled streamers to monetize their fanbase and make a living; this was far before the “creator economy” was as robust or known as it is today and was an incredibly meaningful product to our dedicated users.

However, we struggled to gain similar traction in other non-gaming content verticals (we’d tried to expand to beauty live steaming, for instance) and our growth slowed. We pivoted again to a new idea: to a mobile social app based on sharing reactions via short videos (think Loom screen-recording meets Snapchat mobile social experience). While we could get users to try this app, retention was terrible — we had a “leaky bucket” situation that no amount of user acquisition could repair.

When we failed to improve retention, we scrapped this app. In hindsight, it was likely a great feature (similar to Instagram stories) but not sufficient to achieve traction as a stand-alone application. We then explored a series of other ideas before ultimately being acqui-hired (acquired for the team) by Lyft.

I deeply admired the three Kamcord founders; I had the joy of continuing to work with two of them, along with some of my old teammates, at Lyft during hyper-growth post-Kamcord acquisition. The founders and the team they had built were incredibly special, and I feel lucky to know and have worked with them all.

To me, the Kamcord founders embodied what I thought founders should be: brilliant, charismatic MIT graduates who incubated their startup at YC and combined serious product and engineering skills. While I loved working with and for them, for a long time I didn’t self-identify as someone who could become a founder because I didn’t relate to the archetype I’d invented.

In a surprising twist, it was during Kamcord’s final and most challenging pivot and the struggle of going from nothing to an idea that I unintentionally first started to think and act like a founder. During this time, the Kamcord founders gave our team high autonomy. In my attempt to help our team navigate the idea maze and build something meaningful, I learned the skills and leaned into the traits that, I realize now, make me an effective founder.

I, oddly, thrived in the highly ambiguous and challenging scenario of knowing what we had done failed but not having a clear “what’s next”. I encouraged the team to experiment, ultimately getting the founders’ and team’s buy-in to try out the GV design sprint process. This helped us generate and validate (or invalidate) a series of new ideas, with three of them reaching the prototype stage.

Our ideation process explored many different problems and opportunities. We came up with hundreds (my best guess!) of ideas, from bitcoin applications to smart speakers and voice recognition to ML/AI facial recognition to location-based social to a skincare community to group-based messaging platforms. To this day, I still think some of the pain points we wanted to tackle and product ideas we had were quite exciting!

During this time, I also discovered that building products, ideally with a few close collaborators, is something I deeply enjoy – and am good at (better with practice). I love the blend of customer and market discovery and finding a problem and opportunity, then figuring out how to solve it through software. While I wasn’t a manager at Kamcord (only becoming one later while at Lyft), I learned how to collaborate with and, on occasion, lead an extremely strong team that included a mix of generalists and specialists across product, marketing, design, and data science.

At Lyft, I learned into developing my product and go-to-market skills focusing on new technology products, from launching a redesigned rider app to being a founding member of Lyft’s Bikes & Scooters team. Working on zero-to-one products and then growing them to dozens of cities, thousands of riders, and millions of rides was an incredible learning experience. There was also the added adventure of being at Lyft during hyper-growth and immediately pre and post-IPO, which is a unique chapter in any company’s lifespan. I gained invaluable experience building, launching and scaling new products and managing a team. However, only at the tail end of my time at Lyft, did I consider that I might want to “one day” become a founder.

What’s Next

Since this post is already quite long, I’ll aim to write a separate post about how and why I ended up becoming a founder when I did.

Spoiler: this was in large part thanks to South Park Commons team, as well as with the encouragement from mentors, friends, and former colleagues including Adi Rathnam, who was one of Kamcord’s co-founders, and an incredible product leader at Lyft and beyond.

If you enjoyed this post or found it useful (or not), please let me know. Your questions, suggestions, and comments will help me shape the future of this personal blog.

As we build CodeYam, the first software simulator, two themes are top of mind:

1. How to tame software’s complexity and be confident in delivering value, faster;

2. What the software development life cycle (SDLC) will look like in a world where AI generates more (and more!) code.

Last month, I attended three different conferences in SF where it became clear that these themes are on the mind of many software companies’ and startups’ leaders.

Next.js Conf: Make it work. Make it right. Make it fast.

At the Next.js Conf by Vercel, Guillermo Rauch’s keynote was focused on how recent improvements to Next.js enpower software developers and their organizations to better manage complexity.

He spoke of two different kinds of complexity: accidental complexity and essential complexity. Accidental complexity refers to fixable problems that are introduced (and correctable by!) engineering. Essential complexity instead refers to creating something truly unique, dynamic, innovative – and complex. For Next.js, the framework should be flexible enough to support applications on the full spectrum of complexity, from the simplest to the most advanced. Guillermo shared a set of principles that guide their approach on this; quoting Kent Beck, the author of Test Driven Development: By Example: 

1. Make it work.

2. Make it right.

3. Make it fast.

View Guillermo’s full talk from Next.js Conf here: 

My cofounder and CTO, Jared Cosulich, who spent earlier years of his career at a Pivot building Pivotal Labs’ Boston office, introduced me to the concept of test-driven development (TDD), so the principles as Guillermo described immediately resonated. While he was speaking of them in the context of changes to Next.js, I couldn’t help but think about how these apply to the software development life cycle more generally – and the future of it, as we enter an era where AI writes more and more code.

GitHub Universe: AI Native Software Development

At GitHub Universe in Fort Mason, San Francisco, the conference celebrated the 10th year by celebrating the present and by focusing on an AI native future of software development. The GitHub platform today serves over 100 million developers, and their vision is to simultaneously improve the experience for today’s developers and make their platform even more accessible through natural language to help the next 1 billion people become developers. For existing users, they doubled-down on developer choice by adding new models to GitHub Copilot. As for their vision, they introduced a new product called GitHub Spark that’s powered by natural language. 

At both the Next.js Conf and GitHub Universe, it’s clear that there are talented teams working on making natural language to software products possible, with different levels of abstraction that enable developers to choose to what extent they want to interact with the underlying code. Vercel’s v0 demos at Next.js Conf were standing-room only and there were multiple demos at both conferences that highlighted the ease of going from natural language to UI.

This introduces an exciting potential future where the constraint becomes our ability to imagine new software applications, not our technical abilities to build them. However, it’s not yet clear how near or far this future is today. Many of the examples were of very simple software applications like games or flight trackers; many of the attendees I spoke to mentioned they had not yet tried v0 or, if they had, it was primarily for wireframing and not complex, robust software. Similarly, GitHub Spark had a simple demo on the main stage but I haven’t heard of anyone using this in the wild. However, it is clear that more and more developers are leveraging AI for code generation.

DevGuild AI Summit III: Code Generation

AI code generation was the unifying theme of the DevGuild AI Summit III organized by Heavybit, which was an “unconference” format where participants self-organized around themes related to AI code gen. There were somewhere around 26 sessions, of which I attended three and co-led one. The session I co-led with two others who were curious about similar themes, despite being at the end of the day, was on how AI code generation will affect the entire SDLC.

There was great curiosity around what it meant for processes like Agile and the role of software developers (does this role go away or become more important than ever?). While we didn’t leave the room with answers, there was tremendous hope for AI enabling more empowered product-decision making and more efficient development processes. There was also concern and fear around what this future might mean, which led to deep discussion. 

At the AI Summit, I learned from several attendees about DORA, which is a research program focused on understanding what drives software delivery performance and how to help teams get better at getting better. DORA had just released their 2024 Accelerate State of DevOps report, which dug into how developers are leveraging AI – and the resulting impact on their productivity, their organizations, and their software delivery performance. Some of the takeaways are fascinating. For example: 

• “67% of respondents report that AI is helping them improve their code. Here, we see further confirmation of that sentiment. AI seems to improve code quality and reduce code complexity”

• “It isn’t obvious whether the quality of the code and the quality of the documentation are improving because AI is generating it or if AI has enhanced our ability to get value from what would have otherwise been considered low quality code and documentation.”

• AI is hurting software delivery performance: both throughput and, especially, stability.

• DORA team’s hypothesis on why throughput and stability are going down with AI code generation:  “since AI allows respondents to produce a much greater amount of code in the same amount of time, it is possible, even likely, that changelists are growing in size. DORA has consistently shown that larger changes are slower and more prone to creating instability”

• High-performing teams and organizations use AI, but products don’t seem to benefit. 

You can access the full 2024 DORA report here or watch a recent community discussion they hosted on AI adoption:

CodeYam: Software Simulation and the Future

At CodeYam, we’ve been thinking (and writing!) a lot about how to tame the complexity of software and accelerate software development while increasing confidence in code changes.

Our focus is on simulation specifically as a means to enable better understanding, testing, and delivery of software with far less effort than is required today. I had the chance to share a new demo of CodeYam and some thoughts on complexity live at Founder Central in Boulder, Colorado at the First Pitch event. 

You can read the recap and watch the recorded demo here:

CodeYam’s Substack

New Live Demo of How CodeYam’s Software Simulator Helps Tame Complexity in Software Development

Our Cofounder and CEO, Nadia Eldeib, recently gave a talk at the first-ever First Pitch Colorado event at Founder Central in Boulder, CO. and organized by Tim Morrissey (Drive Capital…

Read more

a year ago · 1 like · CodeYam and Nadia Eldeib

The points around software’s complexity resonated with founders in the audience, especially those currently battling complexity to try to build great software applications for new use cases.

As a quick update on our progress, we have recently moved from the R&D phase of “make it work” to now a new phase that starts to enter “make it right” – although we’re still working on making it work for increasingly complex software products, starting with CodeYam itself. This is an exciting new phase, with lots of work to be done.

If you’re curious about our progress there, feel free to follow the CodeYam blog: 

CodeYam’s Substack

At CodeYam, we're building a robust software simulator. This is our blog on Substack.

In the meantime, I’ll continue to share my personal observations and reflections here. By audience request, I’ll try to share more about my experiences and learnings as a founder as well (more on that coming soon). 

Now back to working on CodeYam! 

Hi, I’m the cofounder of CodeYam, a software simulator. In this article, I share a bit of background on our vision for the future of software development and why we are building this tool.

CodeYam came from a combination of reflection on past experiences building and maintaining complex software products and exploring how AI unlocks a uniquely better workflow. As founders, we are obsessed with building high-quality software products, faster. I’ve spent nearly a decade focused on the product and go-to-market for new technology products including at Lyft and at other startups. My cofounder Jared has spent over 20 years building user-friendly products with new technologies, including as a Director at Pivotal Labs. We met at South Park Commons, and have been building together for over three years. 

We realized that AI advancements make a more magical, J.A.R.V.I.S.-like tool that helps software teams craft quality products, faster, possible. And we see a bigger opportunity to help all software teams, including our own, with software simulation as a means of speeding up iteration, reducing costly errors and bugs, and making critical processes including testing and demos significantly smoother.

Historically, software teams have had to make tradeoffs between speed, quality, and scope. We believe with software simulation, you can significantly increase both speed and quality of software development. This reduces overhead for software organizations, and helps technical leaders, developers, and their teammates solve day-to–day problems more efficiently. 

Why build and use a simulator? 

Simulators are a powerful tool that speed up technology innovation and development. For example, the Wright brothers used a wind tunnel simulator to solve critical problems for their plane faster than the competition, becoming the first to fly. Today, companies like Tesla and Waymo use simulation to test how their self-driving cars might perform before they ever get on real roads. Even super hero Tony Stark had an AI assistant called J.A.R.V.I.S. to simulate and improve his Iron Man suit. 

However, software simulators are not used by most companies building software, with or without AI, today. By “software simulator” we mean something that automatically reads your software’s code, and generates data to simulate different scenarios. This is because software simulations were nearly impossible to build without recent advancements in AI. It was not technically feasible to analyze code effectively enough to properly isolate, mock, and generate data to support simulation. 

Even the biggest, most advanced software companies renowned for their quality sometimes have bugs hit production and impact their users. For modern software products with complex flows, it’s difficult to think through every single scenario and edge-case possible. When a bug is identified in production, often because users reported it after a bad experience, you then have to  figure out the root cause and identify and push a fix or rollback. This can be stressful and time consuming; even when you drop everything to try to find and fix a bug, you’re likely digging into a change that was not intentional or anticipated, which can make figuring out what to do tricky. 

CodeYam so far: our learnings from using software simulation to build CodeYam

While in R&D, our team has been dogfooding CodeYam and comparing our efforts to other tools we use to demo and test while in development. While it's still early days, we are already starting to notice improvements in everything from development, to team communication, to testing for quality assurance thanks to the software simulations. With CodeYam, we can easily understand the status of each development task. 

By viewing a preview of a code change, with a visual simulation, it helps the developer working on that branch anticipate the impact and catch unexpected issues. We can click into the interactive view of certain changes, exploring interactive simulations that make testing and demoing faster. 

The simulation lets us see how changes might appear to our software product’s users (which, in the case of CodeYam, is currently our team). We can switch user states to see how a new feature will look and act for different users based on their attributes. 

Our next milestone for CodeYam: a demo for software developers

Soon we'll be sharing a demonstration of how CodeYam could help in the pull request review workflow experienced by software developers. 

If you are excited about CodeYam and the future of software simulation, please get in touch. You can sign up for our waitlist, follow our CodeYam-specific blog on Substack, or reach out directly to me.

In the past couple of months, I’ve prioritized learning as much as I can about the challenges technical leaders and their teams face when building software products. To do this, I attended several conferences and workshops including Stripe Sessions and the UBS Women in Tech Summit in SF and the Vercel Ship conference in NYC. Just last week, I attended an AI Crafts Boulder meetup locally on mastering AI in Product Development. 

Across numerous sessions and conversations, several notable patterns emerged. Technical leaders today are facing increased pressure from other C-suite leaders to adopt AI tooling to reduce cost and increase their team’s productivity. Improving operational efficiency is top of mind for the C-Suite in the current market. These leaders want AI solutions to increase development speed, improve productivity, and reduce costs, while maintaining quality. Their organizations are already adopting AI tools for their software development. For example, Microsoft Copilot already has 1M paid users in 37K organizations while still in beta. And GitHub Copilot, their tool specifically for developers, recently saw 40% quarter over quarter growth (source). 

However, there’s often a disconnect between the C-suite’s expectations of AI’s capabilities and the reality of using AI for software development today. While tools like GitHub Copilot and Cursor or even Devin are promising, they are not yet capable of doing more than assisting a developer and sometimes have steep learning curves. Several technical leaders mentioned concerns around if developers leveraging AI without sufficient context or software development experience, then these tools can introduce more harm than good. Code might not follow best practices, no one (including the developer who created the code with AI) can easily understand how it works, and unexpected issues often arise. One technical manager mentioned that senior developers on their team were now less productive, because they needed to spend more time reviewing and debugging their less experienced teammates' code after they started using AI. 

Despite some early challenges, there is still a lot of excitement and hope around AI code generation tools. At the Vercel Ship conference in NYC, several of the presenters shared sneak peeks of how v0 might accelerate software creation in the earliest stages of a new project and many of the attendees expressed appreciation for a tool that might help them better evaluate model performance. For example, in the closing Q&A with Guillermo Rauch, the CEO of Vercel:

Both today and in a future where AI becomes more widely adopted as part of the code creation process, software teams need to understand and test changes. Figuring this out today typically requires a lot of manual effort. On our team, this looks like sharing demos of changes or testing changes before and after pushing them to production. In a world where more AI is being used to write code, being able to easily parse and understand the intended impact of the code becomes even more critical.

How do you do this? I believe software simulation is the solution. This is what inspired our team to being exploring something new: CodeYam. Our vision is to accelerate software development by improving how you track, understand, validate, share, test, reuse and maintain code. To this end, we are building a software simulator that automatically reads code and generates data to simulate the code in various scenarios. While still early, we believe this has the potential to save tremendous amounts of manual effort for developers and their collaborators, accelerating software development while reducing the cost and effort required. 

This desire to craft great software products faster is why we are building CodeYam. Our goal is to help technical leaders and their teams accelerate software development and improve quality while reducing cost to deliver great software products. 

If the idea of software simulation is relevant to you, we’d love to get your feedback. You can join our waitlist for CodeYam on our website, or sign up to receive blog updates on CodeYam’s Substack.

And if you’re interested in more of my personal musings, you can subscribe below.

Craft and Beauty in Creating Excellent Software Products

After Stripe Sessions last week in San Francisco, a conference to “discuss the most important internet economy trends”, I found myself reflecting less on the future of payments and more on the future of work. Specifically, excited to explore what the future of software product and development work will look like as AI becomes as ubiquitously used as it is talked about today. One of the breakout talks that was most striking was hosted by Katie Dill, the Head of Design at Stripe. She facilitated a discussion on “Craft and beauty: The business value of form in function” with Karri Saarinen, Cofounder CEO of Linear, and Yuhki Yamashita, Chief Product Officer at Figma.

Katie kicked off by sharing some fascinating observations around observing and measuring beauty. While “beauty is in the eye of the beholder” is a popular phrase and the subjectivity of aesthetics is often taken for granted, there is more than meets the eye. She shared the example of a Mondrian artwork compared to a fake version with slight design differences.

A quick poll of the audience reflected the wider statistical truth that over half of people, regardless of their art experience, can recognize the real Mondrian over the fake version. The way Mondrian deliberately laid his lines of paint is more beautiful, and his decision-making process reflects a rationale beyond just “looks nice”.

How Valuable Is Quality For A Business?

Stripe, Figma, and Linear are companies known for their opinionated and thoughtful approach to craft and design. This care shows up in details from the branding to the specifics of the user experience and even the emails their customers receive. Katie shared an example of an email for new Stripe users that saw double-digit percentage improvements in performance after design changes made the email not only more beautiful, but also more legible and effective.

Meticulous Craft: Decision-Making, Product, and Culture

One of Stripe’s core principles is “meticulous craft” and all members of the panel discussed the importance of craft in your company’s culture and people. Yuhki, for instance, called out that “if you need an OKR to convince someone of quality, you probably have the wrong team.” Similarly, Karri Saarinen said “quality doesn’t happen on its own, you need to push for it.” He further distinguished between craft being the activity and work that you put in, quality and beauty being the output that reflects the impact of that effort.

In this discussion, a key focus was around how craft and beauty and their inherent “quality” relate back to business value. How do you measure quality? Katie described three paths to achieve this goal. First, talking to your users, e.g. qualitative user research. Second, looking at data, and being specific about the metrics you choose to represent quality. Third, look to the team and if people take pride in their work and what you are making, then it is a good sign.

An example Yukhi later gave to embody evaluating and building a quality experience came from his past work at Uber. The team liked to imagine the “perfect” rideshare experience from the rider perspective. When imagining a perfect ride, you likely are thinking of as frictionless and fast an experience as possible. This was something we often thought about during my time working on the pickup experience team at Lyft as well.

Perhaps you imagine a one-click magical experience of calling a ride with the driver promptly arriving, you hopping in a clean and spacious car, and then arriving at your destination. However, the reality actually reflected that having additional touch points,like the ability to text or call your driver, could really improve the rider’s experience. While a “call driver” feature does not necessarily fit the imagined “ideal” experience, prioritizing this touchpoint creates a higher-quality experience for real riders in situations where a phone chat might make the difference between a completed pick up and a delayed or missed one.

Functional Beauty: Prioritizing Quality

Focusing specifically on functionality in beauty, there were a few observations. Yukhi emphasized the need to diligently evaluate if you are solving for a symptom or a root cause with what you are building. While solving for a symptom might seem simpler, you are likely creating a superficial solution that fails to actually address the core issue. Similarly, Karri discussed prioritization and suggested “don’t compromise on the main thing” you are focused on as a team. For Linear in their early days, this meant not compromising on core product decisions but putting less effort into non-core features like the help center in order to move faster. For Karri, this was an intuitive choice focused on “how and why” his business existed and what it is fundamentally about at its core.

Similarly, the discussion captured specifically design and quality for business (enterprise) as compared to consumer products or other categories. For decades, it was acceptable for enterprise software solutions to focus on functionality alone and ignore beautiful design. Karri challenged this, calling out that “business tools should not be worse than my personal tools, if anything it should be better.” Yukhi observed that the distinction between enterprise and consumer software design is getting thinner.

Beauty and the Beast of Workplace and Enterprise Software

For workplace products, users might care more about efficiency and productivity, and less about novelty. Moreover, thinking about the end use case is critical to designing a great product; Karri gave the example of dishwashers. Professional grade usually means more powerful, durable, simpler, and more focused. For a restaurant, a dishwasher might be simpler (fewer features) but also faster and more performant. This concept could be extended to professional quality software.

Extensibility: Continuous Craft for Software Products

While this Breakout talk was a highlight for me in Stripe Sessions, the theme was further reflected the next morning in the main stage AMA with Patrick and John Collison, Cofounders of Stripe, facilitated by Fidji Simo, the CEO of Instacart. Throughout the other presentations, whether it was explicitly discussed or implicit in the content and products shared, I continued to observe the themes of craft, quality, and beauty in software development and their impact on performance and business.

Do Users Love Your Product? The Future of Quality in Software Products

Karri asserted that “if people aren’t raving about your product, you probably don’t have a good product. Great products create fans.” Beyond the business value in individual product quality decisions, product quality is a potential moat for a software business.

This represents an interesting perspective, especially in light of a new wave of tools and products leveraging AI to help more people generate their own designs and digital products. Low/no code solutions like Bubble or Webflow have been around for a while, yet new solutions to help anyone create software are emerging left-and-right. While it is exciting to see new tools engineered to empower the next generation of founders and builders, regardless of their technical skills, I wonder: what will this future look like? How do we avoid a wave of generic, beauty-less new technology products created, not crafted, with AI tools?

AI has the potential to transform how software gets built and this technology is already starting to do so, as developers rely on products like GitHub Copilot to write code faster and marketers rely on tools like ChatGPT for quicker content generation. However, the core value in AI is not that it unlocks the ability to mindlessly create; instead, I believe it is that AI unlocks the ability to learn and iterate faster, creating something mindfully and then more easily iterating and improving on this starting point. In a world where AI increases productivity and generation of software products, craftsmanship becomes even more important in differentiating great products and user experiences from the rest.

Final Thoughts

In my experience working on new technology products at startups such as Kamcord, Lyft, and now as a founder, moving fast is of the utmost importance. However, I resist the notion that there will always be a tradeoff between speed and quality. In delivering great products, over and over, it’s about speed AND quality. Scope of your product work reflects what you’re able to deliver at the appropriate speed and with the appropriate quality — and even beauty.

While the goal of this post was primarily to recap my observations at Stripe Sessions, building quality products for companies and consumers alike is a passion of mine. Creating delightful experiences that add value to users’ lives cannot be done without craft. This is something I have experienced over and over while working on products for all kinds of customers.

Right now, our team is working on something new with the intent to help software teams build high-quality products, faster, and with more delightful and productive collaboration.

If you’d like to learn more about what we’re building or discuss how quality, craft, and beauty contribute to building uniquely great software products, please drop a line.

Subscribe now

In December 2023, we conducted a survey with a goal of hearing from developers and their collaborators building software products, projects, and companies to learn about how we might better support these individuals and their teams.

Two weeks ago, as part of an experiment to open-source more of my own learnings as a founder and product manager, I asked on LinkedIn if anyone was interested in an aggregated, anonymized version of the results of this survey. The answer was universally “Yes” so this post is a follow up to share our learnings.

Disclaimers

This survey was not meant to be indicative of global trends or patterns. Rather, it’s a point-in-time snapshot of trends amongst the respondents. We had 55 responses to the survey, although many questions were optional and we segmented certain questions depending on whether the respondent currently codes or not.

Additionally, we shared this survey primarily through our personal social networks, so responses from specific demographics, such as founders, CEOs, CTOs, experienced developers, and people based in California (both SF/the Bay Area and Southern California) and New York City, are more prevalent.

For more quantitative data and generalizable trends, if that’s what you’re looking for, you might instead look at surveys run by larger enterprise organizations or developer groups. Three larger surveys that our team found interesting were:

• 2023 Stack Overflow Developer survey results

• JetBrains 2023 State of the Developer Ecosystem survey results

• Hired’s 2023 State of Software Engineers survey results

• Reveal Survey Report: Top Software Development Challenges for 2023

While we should not generalize the results of our much smaller-scale survey, we were heartened to see that there were certain consistencies with patterns shown in the much larger scale surveys listed above, which will be called out once we get into insights and analysis.

Let’s dig in!

2023 Developer and Collaborator Insights and Analysis: Demographics

Demographic information is helpful because it grounds the rest of the information collected through a better understanding of who is responding to this survey and their relevant experience and circumstances. The vast majority of our respondents identified their work status as employees of a company (50%), founders (38%) or self-employed (16%). Note that the total is >100% because respondents could check multiple options if relevant to them.

In terms of experience levels of their current position, the majority of respondents again identified as founders (38%). This was followed by lead/principal level (29%), then senior level (20%), then mid-level (7%). A much smaller percentage of respondents identified as executives or junior level.

In terms of the description of their role, CEO (25%) was the most common, followed by CTO (15%). Given the levels of experience, the CEO and CTO respondents seem like they are mostly or all founders as well.

Outside of CEOs and CTOs, product manager (15%) and backend developer (10%) were the next most common. There were a number of other developer respondents, with specific roles varying from Security Developer to Frontend Developer, Data Engineer, and Full Stack.

Survey respondents were overwhelmingly technical, with the majority coding for both work and personal projects (44%). Some coded only for personal projects (17%) while others code only for work (9%). Just over a quarter of respondents (26%) responded that they do not code.

Background and Experience with Coding for Technical Respondents

Of the 40 respondents who identified that they code, we had specific questions about their background and experiences coding. The majority of respondents (35%) had 10+ years of professional programming experience. This likely reflects our network demographics and has a bias towards more experienced respondents.

In terms of which platforms respondents develop for, the most popular answer by far was web, with a nearly even split between a frontend focus (70%) and with a backend focus (68%). This is likely indicative of respondents who build web applications as full stack engineers, writing code across the entire application. Another popular platform was mobile, with iOS (30%) getting nearly double the development attention of Android (15%). A smaller percentage of respondents develops for terminal (23%) and other more specialized platforms such as IoT / embedded, gaming platforms, and infrastructure.

In terms of the primary programming languages used, where each respondent could list multiple languages, we saw significant overlap between our 40 respondents’ answers and the wider developer surveys referenced above.

The most popular language by far was JavaScript (70%) which lines up with the focus we saw on web application development from our respondents. We unfortunately had a survey bug where Javascript was duplicated among the responses, so we manually de-duplicated the data and created the chart below.

The next most frequently used language was Typescript (53%) followed by Python (43%). HTML / CSS (38%) and SQL (30%) were also frequently used. Other notable languages included Go (15%), Rust (10%), Java (10%), Elixir (8%) and Ruby (8%).

Smart contract languages such as Solidity and Move were write-ins as an “other” option, as was Cypher, so potentially those were slightly underrepresented by respondents since it was not an immediately available options.

Developer Tools: How Much Is AI Used for Writing Code?

When asked if developers currently use any AI tools when coding, of the 31 respondents the majority use ChatGPT (68%) and GitHub Copilot (55%). Other tools, if mentioned at all, were significantly less popular, with Claude and Cursor each only getting one response. That said, this survey was in December 2023 and it would not surprise us if the discovery and usage of other AI tools has meaningfully increased. We would also expect ChatGPT and Copilot to continue to dominate AI usage among developers for coding in the near-term.

Developer Tools: Resources, Technologies, and Discovery

Of our respondents who code, most discover new tools, resources, and technologies through friends (62%) and colleagues (54%). Communities such as Discord groups (49%) are also popular, as are specific news sources such as hacker news (46%) and blogs they follow (44%). Interestingly, search (36%) and Product Hunt (13%) and social media were identified as far less popular sources.

When it comes to paid resources, books were the top resource people paid for personally, followed by hosting costs, and courses. This indicates a significant investment in growth and learning among respondents who code. For folks paying for hosting, we expect they are likely either working on their own projects or early-stage founders.

Resources used by those who coded, and which were paid for by their company, were topped by hosting, messaging (e.g. Slack), and project management (e.g. Jira).

Tools that were most likely to have been used for free included component libraries, design systems, data / API access (e.g. weather API), testing / CICD (e.g. CircleCI) and build / pipeline tools (e.g. Expo).

Tools that were most likely to be used if a company paid for them included paging / monitoring (e.g. Sentry), Hardware (e.g. AI GPUs) and the previously mentioned project management and messaging tools.

Interestingly, wellness apps (e.g. Headspace) were equally likely to be paid for by an individual or their organization, and twice as likely to be paid rather than free usage. Professional coaching was mostly not used by respondents, but if it was, their organization most likely paid for this service.

Background and Experience: Collaborators Who Do Not Code

26% of our respondents said they don’t code, and so we have a much more limited set of results from this group. Of those who do not code, when asked how coding relates to their personal and professional experience, most had learned to code but do not actively use this skill (60%), some have never learned and have no plans to but work with developers (33%) and some are currently learning (13%) or would like to learn to code (13%).

As for the respondents who code, when it comes to using AI tools (in this case at work and not to write code), ChatGPT dominated (over 73% responded using it). Nothing else came close. The next most common response was not using AI tools (13%) and we had one response each for different tools such as Bard, Notion AI, Grok, Otter, and others. Note that this was an extremely small sample size however, with only 15 respondents.

In terms of discovering new tools, resources, or technology, responses were similarly likely to rely on colleagues (67%) and friends (53%). Communities (47%) and blogs (47%) also were popular. Search (40%) was slightly more popular than for coders, but this might also be due to small sample size.

In terms of resources that were paid for personally, this cohort responded overwhelmingly with books and courses.

Of resources paid for by their company, messaging (e.g. Slack) and design collaboration tools (e.g. Figma, FigJam) were the most common, followed by note taking (e.g. Notion) and project management tools (e.g. Jira). This group was understandably less likely to use tools for paging / monitoring, hardware (e.g. AI GPUs), and technical collaboration (e.g. Storybook). This potentially indicates a gap in tools for non-coding product team members and founders who are still working on or responsible for software products, but not as intimately involved in the development and testing of their product’s code. We will be delving into this more as a team in the future.

Bonus: What Did ChatGPT “Think” Of Our Survey?

In addition to the questions synthesized above, we fed survey results into ChatGPT and requested analysis and synthesis. This included more free-form responses, and led to ChatGPT identifying a set of themes and experiences.

Here is the verbatim response we got from ChatGPT which identified a number of challenges and pain points among developers and collaborators when it comes to creating and managing software products:

“The responses you’ve provided span a wide range of challenges and experiences in software engineering and technology leadership. Here’s a grouped summary:

Project Management and Development Challenges:

- Environment setup and maintenance.

- Struggles with clarity, prioritization, and speed in teamwork.

- Merge conflicts and wasted effort on unused features.

- Difficulty with context switching and managing time demands.

- Release cycles being too long and lack of customer feedback.

- Challenges with database scaling and understanding cloud expenses.

- Tooling fatigue, syntax issues, and dependency management.

- Slow build processes and deployment times.

Team and Collaboration Issues:

- Need for better team communication and collaboration.

- Challenges in integrating with poorly designed APIs.

- Difficulties in getting engineers involved in the design process early.

- Remote collaboration issues and lack of spontaneous interaction.

- Cross-team work inertia and knowledge imbalances among teammates.

- Poor communication and passive-aggressive behavior in teams.

- Misalignment on strategy and vision.

Business and Leadership Struggles:

- Business growth challenges and financial pressures.

- Difficulty in finding a cofounder and identifying real problems.

- Navigating internal politics and bureaucratic structures.

- Leadership making uninformed decisions.

- Maintaining visibility on developers’ day-to-day production.

- Difficulty achieving product-market fit.

Personal and Professional Development:

- Lack of coding practice leading to skill atrophy.

- Learning new technologies and keeping skills updated.

- Adapting to the use of AI in workflows.

- Seeking high-quality feedback and user engagement.”

What’s Next: Continued Learning, Building, and Experimentation

Our team is exploring three fronts in parallel. First, we are conducting ongoing research to better understand the challenges, experiences, and needs of software product teams and developers and collaborators working in these organizations.

Second, our developers are spearheading a technical R&D exploration into what we can do in terms of providing a valuable solution to some of the challenges we’ve identified, specifically around helping software product teams build high quality products faster and facilitate better understanding of changes.

Finally, we are also taking on a limited number of early design partners to provide a personalized software simulator solution for their teams.

Right now, we are focused on helping early-stage software startup teams and software consultancies in this category. If you’re interested in this, please reach out at nadia [at] ethoswallet [dot] xyz.

Survey 2.0

We recently kicked off a new survey to learn more about product teams and software collaboration processes. If you’re interested in sharing your feedback, you can take that survey here: https://bit.ly/2024-software-survey . Note that all questions are optional.

On software teams, there is often a lot of energy involved early on in setting up your technology stack. You choose programming languages, frameworks, platforms, and even specific productivity tools to support both the product you plan to build and your team.

Why bother with tools for product management?

In discussing helpful tools for product management, there is occasionally resistance from product managers to even classify this as something worthy of consideration. As a founder or PM responsible for both a product and team, you might prefer to prioritize your teammates’ requests over your own ideas. In this case, you might defer to developers and designers on what their ideal tools are, or just agree to whatever project management tool your CTO or Engineering Manager suggests. While this is often well-intended, the result can be a mismatch between the tools chosen by individuals and the product management processes that best serve the team, speeding you all up and providing sufficient support.

Maybe you leverage a service like Superhuman to be faster on email (I certainly do), but the thought of trying to add tools to your workflow to make product management or product-related responsibilities such as quality assurance and testing more productive seems counterintuitive.

What happens to the product stack when AI is more widely used to build software?

In a future where software developers and other team members are increasingly adopting AI to increase their productivity and output, building more software products and features faster, Product Managers and product-oriented founders must adapt.

While the desire to be a good collaborator and supportive of the tools requested by your team is a strong and useful urge for founders and Product Managers, you need to also consider how you’re interacting with those tools and your team. Are you able to make decisions efficiently and proactively? Or are you reacting to fire-drills, bugs and breaking changes? The latter might indicate that you either have outgrown your product stack or have not sufficiently invested in it and as a result are stuck in fire-fighting mode.

Leveling up the product stack is critical if product leaders want to be empowered decision-makers, productive contributors, and effective collaborators. Yet when compared to the quality and quantity of tools available to software developers, those targeting the software product life cycle are lacking.

Today, the majority of tools I am aware of seem to focus on project management, data analysis, user research, experimentation, communication, and manual testing.

How do you start to build your product stack?

Today, building your product stack should directly relate to your skills, your team’s needs, and your product and scale.

When you are pre-product or working on your first pre-product-market fit product and a small team with a couple of developers at most, Google Documents and Sheets or a GitHub tasklist is likely sufficient for prioritization and task management. You likely are testing changes in production, which is reasonable when you have no users, speed is of the essence, and there is a low likelihood of changes colliding as different developers push changes to production.

In the early stages, resist the temptation to add process or tooling prematurely. Leverage lightweight techniques and processes, primarily stand up meetings, designs in Figma, and lightweight to do list tracking, to make sure the team is on the same page around priorities and what needs to get done.

Once you’ve grown the product to something slightly more complex, have external users, and grown the team to more than a couple of contributors, maybe you’re now in your project management era. As long as you’re prepared for the overhead of making sure your projects, stories, and tasks stay updated, this is a great time to adopt a tool like Linear or Asana to help everyone understand priorities and track progress.

Update your product stack as needed

You will likely add and drop processes as requirements change, systems break, and graduate from one approach or task management tool to another to accommodate your growing product and team. Leaning on communication supplements project management tooling, and relying on regular cadences for check-ins on your product can help.

Our team, which is remote and distributed, uses two meeting formats: lightning-fast daily stand ups that are followed by a more free-form forum immediately afterwards for topics requiring a deeper dive, and weekly retrospectives. As asynchronous communication in a tool like Slack or Discord increases along with your workstreams, messaging will become harder to follow as channels proliferate so using threads or having a system for managing communication to help team members understand as they come online where to start and what to focus on is essential.

As you start to feel your product stack breaking, either because the team, user base, and/or your product have grown, look for solutions to address specific pain points. For example, if you are spending a lot of time in stand ups discussing priorities and it is no longer a quick meeting, consider adding tooling or rotating the meeting host and empowering them to manage the clock. If testing and QA is a struggle, look into tools that enable non-developers to preview and test changes in a staging environment.

Today, this is a little bit of a jigsaw puzzle, but with creativity and ingenuity you can create a product stack that is highly composable and achieves its purpose of flexing with you, your product, and team.

How will the product stack evolve in the future?

For people to make fast, smart product decisions in a future where AI is a potent part of the software development process, the product stack needs to evolve to support more complex projects and dynamic teams.

Project management platforms like Linear are already exploring leveraging AI to improve and expand their product’s capabilities, making it useful for product planning as well as project management.

Developer tools like GitHub’s Copilot are making writing code faster and easier than ever.

However, the part of the product stack that excites me the most is the tooling around in-development work. This is where there is the greatest opportunity both because there is a gap in tools available to product leaders and their teams today, and because in the future this gap will become increasingly painful as teams are able to more efficiently ship, and must then manage, more products and features.

We are working on a new product that compliments existing products for product planning and project management by focusing on improving the experience for all members of software product teams when a feature is in-development.

You can read earlier thoughts about how AI will impact software development, products, and teams in my previous post. I’ll also continue to open-source my observations, ideas, and learning in this ongoing writing experiment.

We’re also conducting a survey to learn about how others are building their product stack: https://bit.ly/2024-software-survey . Don’t be intimidated by its length; all questions are optional so you can skip anything as needed.

If you have feedback, please reach out at nadia [at] ethoswallet [dot] xyz .

As a software startup founder, my passion is building products that add value to people’s lives and businesses. As an experiment, I plan to start open-sourcing more of my ideas and learnings through this blog. I hope to inspire and connect with like-minded individuals with this writing. If you have feedback, reach out at nadia [at] ethoswallet [dot] xyz.

Now, let’s dig into today’s focus: how will AI impact software development, products, and teams?

Why should we care about AI in relation to our work / life?

AI is a hot topic that is a frequent source of discussion and change in my network. Many friends who work in technology are joining AI startups or building or integrating AI products at their existing organization. And connections in other industries are considering how to advise clients and evaluate AI products on their benefits and risks.

Unlike other game-changing technologies such as blockchain, where many in my network were deeply curious but not directly impacted, AI is already changing our day-to-day. Almost everyone I know is interacting with AI through product experiences such as ChatGPT and the content consumed. AI technology is increasingly utilized through products and integrations in both work and personal life.

What is the role of AI in software technology companies?

This is a fundamental question for anyone building or whose business depends on software (hint: probably you!).

There is generally consensus that AI will play a role in writing code for software products. How that happens may vary significantly in the short- and long-term. One version of how this happens today is GitHub Copilot (from Microsoft) that’s betting on helping developers move faster. After ChatGPT, Copilot was the most adopted AI product among 50+ respondents to a survey we conducted in December 2023. Another approach is that of Devin AI (built by Cognition Labs, who recently announced a $21 million Series-A round). Devin AI is marketed as the “first AI software engineer” that is fully autonomous and able to complete tasks independently.

Regardless of your thoughts around complete autonomy versus human-in-the-loop, the future likely involves more code being written more quickly, via direct or indirect involvement of AI. This means that new software companies, products, and features can be launched faster.

However, this increase in AI adoption to create code can lead to side-effects such as more code to maintain, more complex codebases, and possibly also less human-readable code. Merging in changes to a codebase can already be challenging without AI. Even the best Pull Request review process is likely to miss some details. If AI is generating more PRs at a much higher speed, then these issues will become even more untenable.

This leads to another question…

If software developers increasingly use AI to write code in one form or another, what does this mean for their product and team?

Anyone working on software products has likely experienced “technical debt” and the pains it produces for the team. Decisions made to ship fast in the early stages lead to compounding challenges later on that ultimately might lead to a slowdown for developers and deployments. In a world where there’s more code and more complex code, this painful experience accelerates.

For non-developer product team members, like product managers, UX researchers, designers, data scientists, and customer support roles, this amplifies an existing challenge around understanding what’s going on in your product and the underlying code, and how it impacts your business and users.

What if instead of project management, product teams could get a snapshot of the current state of the product directly through the code?

We’re not talking about reading GitHub commits, which while technically feasible can be difficult to get value from as a non-developer if your developers aren’t writing detailed change logs. While I can’t share too many details on what we are building yet, we are exploring helping software product teams understand the real status of their product by simulating changes to the code and providing summaries and interactive demonstrations.

If successful, this should not only help product team members answer questions like “What happened to this task that a developer was working on?” or “When will this feature hit production?” but it will also help with quality assurance and testing. Even the least technical member of the team should be able to easily set up a user scenario and experience a change, before it hits production. You can change variables to see how product changes impact users with different attributes without logging in or out or generating multiple user accounts for testing.

This same functionality can greatly benefit pull request reviews as well. Adding a completely new dimension of information to pull requests reduces the likelihood of any issues getting merged in.

What does the role of the product manager or product owner look like in the future?

Even before the adoption of AI in software development, there was skepticism about whether product managers are necessary. Now with AI, there’s an interesting question of “Who should make product decisions?” — if you could wholly automate them and make Devin a PM friend (or just give Devin product decision-making powers) should you do it?

Product decisions should and will continue to be made by people for the most part. However, AI can speed up and improve these decisions and will become a critical tool to help empower product decision-makers, whether that’s a Product Manager, founder, or engineer. AI can provide better data and insights to help PMs make smarter product decisions, faster.

We plan to leverage AI to reduce the amount software product teams need to spend on project management and communication to get everyone on the same page. We want to enable shorter, faster, and more meaningful and informed product decisions by providing everyone with a better understanding of the product. This includes simulating how a software product will appear for users in different states based on the underlying code changes earlier in the process than possible today. This will reduce collisions and miscommunication and lead to shipping high-quality products faster and with less cost and effort.

How can product managers and founders use AI to build quality products faster?

AI unlocks superpowers for founders and product managers to empower them and their teams to ship high-quality products faster than ever and experience more delightful collaboration in their interactions with developers and other critical team members such as design and product marketing. This will work for all software product teams from remote to hybrid to in-person.

Our team is partnering with select individuals to pilot an early product. If you’re curious to learn more about this, please reach out to nadia [at] ethoswallet [dot] xyz .

We’re also conducting a survey and will be prioritizing respondents for follow-up. You can complete the survey here: https://bit.ly/2024-software-survey .

All the survey questions are optional, so if you don’t know how to answer a question, just skip it.

What’s next?

Exploring how AI can help product and development teams collaborate more effectively to deliver high-quality products quickly is our focus. We’re investigating both how we can leverage AI to help solve software product process challenges today, and to build a solution that empowers teams to make great decisions in a world where AI becomes more common in software development. I’ll also continue to open-source more of our ideas, experiences, and learnings.

Recently, I joined South Park Commons’ inaugural Founder Fellowship cohort. In my first few weeks, I explored different spaces by asking myself: what am I passionate or curious about? I focused on exploring new problems without pushing pressure on myself to “solve” them or build at this point. In this post, I’ll share some of the learnings and opportunities uncovered in this initial exploration.

Following my sense of curiosity, I explored six spaces:

1. 🙋‍♀️ empowering women

2. 🧠 reducing sadness/depression

3. 🕵️‍♂️ future of news/information/media/communication

4. 🎒 ecommerce

5. 👑 consumer social media

6. 🌱 sustainability

I first conducted research, then synthesized key takeaways. Some results reinforced what I already knew to be true, while other learnings surprised me. I found that I naturally focused on two of the six spaces: (1) empowering women and (2) reducing sadness/depression. Below are the insights that most excited me from these two spaces, as well the opportunities for further exploration that they inspired.

1. 🙋‍♀️ empowering women

Women continue to earn less and are underrepresented in the C-Suite, particularly in male-dominated fields.¹ The women who successfully enter fields such as math, science, and technology are more likely to lack confidence in their competence and ability. Even when they are recognized as high-achievers, women in these fields are more likely than male peers to shrug off praise or lowball their own abilities.² Beyond this confidence gap, there’s also a promotion gap. For every 100 men promoted to manager, only 85 women were promoted. The gap is worse for Black women and Latinas: only 58 Black women and 71 Latina women were promoted per 100 men.³

A frequently offered “solution” is for professional women to champion other women. One study found that women at Harvard Business School in the top quartile of centrality (central and connected to people with many contacts in the MBA student network) and with an inner circle of 1–3 other women landed leadership positions that were 2.5 times higher in authority and pay than their female peers without this combination. Meanwhile, women in their class whose networks most closely resembled those of their successful male peers (with centrality but no female inner circle) took jobs with some of the lowest authority and compensation.⁴

In the workplace, however, senior-level women who champion younger women are more likely to receive negative performance reviews.⁵ Since there are fewer women promoted to senior-level roles at every level, there are fewer potential senior-level women to champion and uplift other women. This creates overhead for existing senior-level women, who already face additional pressure and stress as compared to their male peers.

Senior-level women in the workplace are significantly more likely than men at the same level to feel burned out, under pressure to work more, and that they have to be “always on”. They’re at higher risk for attrition and are about 1.5 times more likely than male peers to think about downshifting their role or leaving the workforce because of COVID-19, often citing burn out.⁶

Taking an “off-ramp” or career break is a privilege. Off-ramping is increasingly unaffordable, particularly for women with dependents. In January 2019, 15% of women in the workforce said they would like to off-ramp but can’t afford to do so. Moreover, while 89% of off-ramped women want to resume their careers, only 40% successfully return to full-time employment.⁷ Off-ramping often comes with significant opportunity cost: rejoining the workforce is hard and, if women do, they generally earn less and have less job security.⁸

Why should we try to address these problems now? There is some early signal that we may be nearing a tipping point at which meaningful change could be accomplished. At the beginning of 2020, the representation of women in corporate America was trending up and in the right direction. This progress was most pronounced for senior management roles: from January 2015 to January 2020, women in senior-vice-president roles grew from 23 to 28%, while representation in the C-suite grew from 17 to 21%.⁹

So, what opportunities are there to empower women? Some that jump to mind are:

1. Help companies, particularly those in male-dominated fields like technology, better support, promote, compensate, and retain women. This is supported by data: 26% of women who off-ramped felt their careers were unsatisfying and 16% felt their careers had stalled.¹⁰

2. Help women address the primary causes of off-ramping. Causes to address include burn out, pay and promotion gaps, stalling careers, and caretaking for children or family members. 69% of the women who off-ramped said they wouldn’t have done so if their companies had offered more flexible work options (e.g. reduced-hour schedules, job sharing, part-time career tracks or short, unpaid sabbaticals).¹¹

3. Offer new types of work or careers to help women have greater flexibility and an easier time exiting and reentering the workforce. The gig economy is one example of this, but perhaps there are as-of-yet unexplored opportunities to create meaningful, flexible work that will disproportionately benefit the professional women who need it most.

2. 🧠 reducing sadness/depression

Feelings of loneliness and isolation are on the rise in the U.S. digitally, and physically. More than 60% of Americans are lonely, feel left out, poorly understood, and that they lack meaningful companionship.¹² A report found a nearly 13% rise in loneliness since 2018.¹³ Loneliness is also strongly linked to mental health issues such as anxiety and depression.

What is causing this loneliness? Feelings of loneliness and isolation are connected with higher social media usage; 73% of heavy social media users reported feeling lonely, compared with 52% of light social media users.¹⁴ It’s sad yet unsurprising, then, that Gen Z respondents (18–22 years old) had the highest average loneliness score.¹⁵

Feelings of loneliness are potentially further exacerbated by the content we engage with on social media. “Engagement” is a metric often used by consumer social media companies as a way to prove they are providing value. However, at Facebook, the models of what content to show you to maximize engagement also “favor controversy, misinformation, and extremism.”¹⁶ This creates a negative flywheel where this content gets more engagement, which results in more of this content being prioritized, repeatedly. For example, Facebook employees found that users who would “post or engage with melancholy content — a possible sign of depression — could easily spiral into consuming increasingly negative material that risked further worsening their mental health” and this issue was reinforced by existing content-ranking models.¹⁷

Feelings of isolation are mirrored by actual isolation and self-segregation in the U.S. by political party lines. People are physically living in partisan bubbles, meaning Democrats self-select to live near others Democrats who share their political party affiliation and views; the same goes for Republicans.¹⁸ This co-location with only those with the same political party is nearly ubiquitous and agnostic of whether U.S. residents live in a city or suburb or rural areas.¹⁹ This self-segregation along political party lines in the physical U.S. seems to mirror the isolation and echo chambers that exist in the digital world.

There is no great alternative to social media for news. Traditional media can also perpetuate problematic narratives around minorities and people of color — if they even bother to cover them. Researchers at the University of Leeds shared reported that minorities received very little general news coverage in the U.K., but figured prominently in stories with “specific news agendas, notably immigration, terrorism, and crime.”²⁰ Brands and media advertisers are not doing much better in terms of diverse and inclusive representation. For example, an analysis of 27,000 Instagram images showed that the fashion industry’s Black Lives Matter mea culpa resulted in little to no change in representation of people of color.²¹

The pandemic has accelerated the general increase in loneliness and isolation. This has been a challenging time for U.S. workers, who face an increase in mental health issues.²² For example, 75% of U.S. employees struggled at work due to anxiety caused by the pandemic and other recent world events and 80% would consider quitting for a company with a greater focus on supporting mental health.²³ Employees that shifted to remote work are also experiencing new challenges. According to a recent survey: 4 out of 5 remote workers find it hard to “shut off” in the evenings, 50% cite sleep patterns interruptions, and 45% say they feel less mentally healthy while working from home.²⁴

So, what opportunities are there to reduce sadness/depression? Some that jump to mind are:

1. Promote wellness as a lifestyle by creating shared experiences that bring people together and build bonds. There are already a lot of different approaches to this — from Peloton and Strava to BetterUp and Headspace — so figuring out a unique, significant problem to solve or insight is critical.

2. Create an environment that rewards engaging with diverse thoughts and people and helps them disengage from unhealthy media habits. This seems like an extremely challenging but potentially rewarding endeavor. Companies like Clubhouse are already creating forums for potentially diverse groups to interact, while others like Dispo are attempting to introduce consumption constraints; anything new needs to meet an unmet need and answer the questions: “why this? And why now?”

As Founder/Investor Sari Azout recently tweeted:

What’s next?

I’ll continue to deep-dive into these two spaces. I plan to generate deeper insights into pain points, then begin to converge on more specific problems, markets, and opportunities. This will hopefully lead to testable hypotheses and ideas, and create a flywheel of testing and learning, increasing my velocity as I engage in this process and move from the “idea” to “build” phase.

Thoughts, feedback, advice, questions, or words of encouragement?

Please feel free to reach out on Twitter.

Finally, a special thanks to Zorayr Khalapyan for the suggestion to write about this and Amit Sankaran, Asad Akram, Jen Yip, Kate Yuan, and Leon Lin for the thoughtful feedback, edits, and support.

References

[1] https://hbswk.hbs.edu/item/how-gender-stereotypes-less-than-br-greater-than-kill-a-woman-s-less-than-br-greater-than-self-confidence

[2] Ibid.

[3] https://www.mckinsey.com/featured-insights/diversity-and-inclusion/women-in-the-workplace

[4] https://hbr.org/2019/02/research-men-and-women-need-different-kinds-of-networks-to-succeed

[5] https://hbr.org/2018/09/dont-underestimate-the-power-of-women-supporting-each-other-at-work

[6] https://www.mckinsey.com/featured-insights/diversity-and-inclusion/women-in-the-workplace

[7] https://www.amanet.org/articles/time-outs-take-an-increasing-toll-on-women-s-careers/

[8] https://www.nytimes.com/2020/11/17/business/economy/women-jobs-economy-recession.html

[9] https://www.mckinsey.com/featured-insights/diversity-and-inclusion/women-in-the-workplace

[10] https://www.amanet.org/articles/time-outs-take-an-increasing-toll-on-women-s-careers/

[11] Ibid.

[12] https://www.npr.org/sections/health-shots/2020/01/23/798676465/most-americans-are-lonely-and-our-workplace-culture-may-not-be-helping

[13] Ibid.

[14] Ibid.

[15] Ibid.

[16] https://www.technologyreview.com/2021/03/11/1020600/facebook-responsible-ai-misinformation/

[17] Ibid.

[18] https://news.harvard.edu/gazette/story/2021/03/democrats-and-republicans-live-in-partisan-bubbles-study-finds

[19] Ibid.

[20] https://www.nytimes.com/2021/03/10/world/europe/harry-meghan-media-race.html

[21] https://qz.com/1971689/fashion-brands-arent-keeping-their-instagram-diversity-promises

[22] https://www.forbes.com/sites/chriswestfall/2020/10/08/mental-health-leadership-survey-reveals-80-of-remote-workers-would-quit-their-jobs-for-this

[23] Ibid.

[24] Ibid.