AI-Native Product Creation

For a long time, product development was about craftsmanship. Everything from specifications to code to design artifacts had to be carefully made by hand. Each role was built around a particular craft — backend engineers, frontend engineers, designers, product managers, project managers — all working through a complex web of specialized tools. Jira or Trello for tickets, Confluence or Google Docs for documentation, Figma for design, GitHub for code, and so on.

This ecosystem of tools made sense in a world where everything took time and handcrafting artifacts was the main bottleneck. You needed layers of process to make sure that expensive craftsmanship was directed toward creating the correct artifacts. But with AI, the balance has shifted completely. What used to be expensive — writing code, writing specs, writing documentation, producing designs — is now abundant and fast.

So the question becomes: how do we build products when the hard part is no longer the manual work?

Being “AI-native” is not just about using AI tools to assist with development. It means reorganizing the whole product creation process around what AI actually works well with — and avoiding the structures that get in its way.

AI thrives on short, focused, textual contexts. It doesn’t need a Jira board or a Confluence space. It works best with a well-structured repo that contains everything in plain text — specs, strategies, architecture, next steps, and documentation — all expressed in markdown.

When everything relevant lives in this file structure, AI models like Claude can move seamlessly across the material. They can generate code, update documentation, draft user flows, and maintain consistency between strategy, product, and implementation. The repo becomes not just a source of code but the full map of how the product evolves.

In AI-native work, meetings are no longer for alignment in the traditional sense. They are primarily for enriching context — for the humans and for the AI.

Every week, our team meets to discuss progress, what we’ve built, what we’ve learned, and what we’re focusing on next. We record these meetings, not to archive them, but to transcribe them accurately using higher-fidelity transcription models. Those transcripts become the raw material for AI to update our documentation and planning files.

We have two key markdown files in our monorepo, in the docs/process folder: NEXT-STEPS.md and DELIVERED.md. Each week, we review (during a recorded meeting) what has been completed, move those items into DELIVERED.md, and update NEXT-STEPS.md with what we’ll focus on next. This replaces our need for Jira or similar tools entirely.

After transcribing the meeting, we use Claude to update these files directly. The prompt is simple: “Update next steps and delivered based on this week’s discussion: [transcript pasted here].” Claude makes the changes, we review them, and if something is off, we record short corrections or voice notes and have it adjust. After a couple of passes, the updates are ready to be committed as a PR. Team members comment directly in GitHub, and Claude can then address those PR comments as well.

This becomes the full weekly coordination loop.

A major mindset shift in AI-native work is realizing that you’re no longer limited by how many tasks you can personally handle in sequence. You can run multiple Claude Code sessions in parallel — each one focused on a different problem.

One session might be refining documentation, another fixing a feature, another writing code for a new module. You can move between them as you would between conversations with teammates. Each session has context, and each evolves iteratively.

AI will almost never produce expert-quality work on the first try. You can think of it as working with a capable but inexperienced co-worker — one who can take direction, iterate fast, and produce drafts across any discipline. The key is your role in the iteration loop: you know what “good” looks like, and through feedback, you bring the work up to that level. The result is a steady stream of progress across many parallel tracks.

If you only have a single AI conversation ongoing at any given time, you are probably not being more efficient than without AI.

With multiple ongoing sessions, you end up with a lot of changes in the same working copy. The challenge then is to be able to create reviewable PRs without disturbing your team of AI agents actively working on your code. Personally, I keep committing to one main working branch — a WIP branch — that collects all the changes I’m iterating on with different Claude sessions.

I choose to commit changes manually rather than asking the AI agents to do it. This is equivalent to reviewing the “PR” of your AI colleague and serves as the first level of defense against AI slop/mistakes. Once I have working and tested changes ready for CI checks and teammate review, I cherry-pick the commits into separate branches and create PRs. Each PR can then address a specific product or documentation change and go through its own CI, testing, and review process independently.

This cherry-picking is done in a separate local checkout of the same repo so as not to disturb the AI agents. The WIP branch becomes the place where everything happens, and the second checkout is for sorting and preparing PRs for merge.

Whenever a PR fails checks or a deployed version behaves differently than expected, I ask Claude to debug directly — pasting the PR number or URL in the chat so that it can check GitHub Actions logs or cloud logs, depending on where the issue appears. The AI session that produced the feature usually has enough context to resolve the issue efficiently.

Over time, this way of working starts to feel natural. The GitHub repo holds the product, the process, and the relevant parts of the company’s knowledge base. The AI becomes an active participant in development and product strategy — updating, generating, fixing, and documenting continuously.

The real role of the human team shifts toward clarity: understanding what to build, how to evaluate results, and how to steer the AI effectively. Meetings, reviews and documentation exist primarily to enrich shared context and help the AI do better work.

An AI-native company builds products this way not because it’s trendy, but because it’s the only way to move fast while staying coherent. Once you understand how to organize your knowledge and workflows around AI, the layers of traditional process — the project management tools, the rituals, the ticket systems — become unnecessary overhead.

You end up with something simpler: one repo, a few markdown files, transcribed discussions, and a constant loop of iteration between humans and AI. And that’s enough to not only build real products, end to end, but also to go one step further and focus on value creation and growth — with the product just being a means to an end.

More on that in another post. :)