No Figma. No Jira. No Docs: What Gusto's AI-First Product Build Reveals About the Future of Lean Development

TL;DR

• Gusto shipped Gusto Embedded (a new product line) with a 3-person team in weeks, using Claude as the primary development tool—no Figma designs, no Jira tickets, no written specifications.
• The "context window as shared memory" approach replaced traditional documentation: the team iterated directly in Claude's context, treating conversation history as the single source of truth.
• This isn't about eliminating process entirely—it's about radically reducing coordination overhead when AI can hold and execute on complex context that previously required artifacts.
• The approach works best for small, experienced teams building net-new products; scaling this model to larger orgs or legacy codebases remains an open question.

---

When Eddie Kim, CTO of Gusto, described building Gusto Embedded without Figma, Jira, or documentation, my first reaction was equal parts fascination and skepticism. As someone who's spent years in product management watching teams drown in Confluence pages and Jira grooming sessions, the idea of ditching it all sounds like fever-dream productivity porn. But Kim isn't some founder in a garage—he's running engineering at a public company with 400+ employees. If his team pulled this off, it's worth understanding how and why.

The short version: Kim and two engineers built an entirely new product line in a matter of weeks using Claude (Anthropic's AI assistant) as their primary development environment. No design mockups. No sprint planning. No PRD. They iterated directly in Claude's context window, using the conversation itself as the evolving blueprint. When they needed to pivot, they didn't update a spec doc—they just continued the conversation. The AI held the context, generated the code, and the humans steered.

This isn't just a story about moving fast. It's a signal about how AI tools are beginning to reshape the fundamental trade-offs in product development.

The Traditional Tax: Why We Document Everything

Let's start with why we have Figma, Jira, and Google Docs in the first place. These tools exist to solve coordination problems. When you have multiple people working on a product—designers, engineers, PMs, QA—you need shared artifacts to:

1. Align on intent ("What are we building?")
2. Distribute work ("Who's doing what?")
3. Preserve decisions ("Why did we choose this approach?")
4. Onboard new people ("How does this system work?")

The larger your team, the more essential these artifacts become. A 50-person product org without documentation is just 50 people with conflicting mental models, building in different directions.

But here's the tax: creating and maintaining these artifacts is expensive. Writing a good PRD takes hours. Keeping Jira tickets up-to-date is a Sisyphean nightmare. Designers spend as much time documenting components as building them. And despite all this effort, the artifacts are always slightly out of sync with reality. Code diverges from specs. Designs get "interpreted" during implementation. The Jira board becomes archaeological sediment.

We tolerate this tax because the alternative—pure verbal coordination—doesn't scale past 3-4 people. Human working memory is too limited. Conversations are ephemeral. You can't "replay" a hallway discussion from three weeks ago.

Until now.

The Context Window as Shared Memory

What Eddie Kim discovered is that a sufficiently large context window changes the equation. Claude (and models like it) can hold tens of thousands of tokens in active memory. That's enough to contain:

• The entire conversation history of a product's development
• Key architectural decisions and their rationale
• Code snippets, API designs, and implementation details
• Evolving requirements and pivots

In Kim's workflow, the context window became the shared artifact. Instead of writing a spec and then translating it into code, the team iterated directly in conversation with Claude. "We want to add OAuth support." Claude generates an implementation. "Actually, let's use PKCE flow instead." Claude refactors in the same thread. The conversation itself is the design doc, the implementation plan, and the change log.

This works because the AI can:

1. Recall earlier decisions without anyone having to remember or search for them
2. Maintain consistency across the codebase based on patterns established in conversation
3. Execute on ambiguous instructions that would require multiple clarifying Slack threads in a traditional workflow

The result is a development loop that's dramatically tighter. Instead of:

PM writes spec → Designer creates mocks → Engineer reads spec → Engineer asks clarifying questions → Designer updates mocks → Engineer implements → QA finds gap between spec and implementation → Repeat

You get:

Human describes intent → AI proposes implementation → Human refines → Ship

The AI collapses multiple roles (spec writer, code generator, consistency checker) into a single conversational interface.

My Take: This Is Real, But It's Not Universal

Here's where I want to inject some opinion, because I think the discourse around "AI replacing process" is going to get messy fast.

I think what Gusto did is genuinely novel and represents a real unlock for small teams building greenfield products. The constraint that made this possible wasn't just Claude's capabilities—it was the team size (3 people), the problem space (net-new product, no legacy constraints), and the skill level (a CTO and senior engineers who could evaluate AI output critically).

But I'm skeptical this approach works as-is for:

• Teams larger than 5-7 people. Once you have multiple workstreams, you need some way to coordinate across them. The context window doesn't help if half the team is in a different Claude thread.
• Products with complex compliance or regulatory requirements. "The conversation is the documentation" doesn't fly when auditors or legal teams need to review your decision trail.
• Organizations with junior engineers. This workflow assumes everyone can critically evaluate AI-generated code and catch subtle bugs or architectural missteps. That's not a given.
• Codebases with significant legacy debt. Greenfield projects let you establish clean patterns from scratch. Refactoring a 10-year-old Rails monolith is a different beast.

What I do think is that Kim's experiment points to a new category of tooling: AI-native development environments that treat conversation as a first-class artifact. Imagine a tool that:

• Persists conversation threads as "living specs" that update automatically as code changes
• Lets multiple team members branch and merge conversational context, like Git for dialogue
• Generates traditional artifacts (PRDs, diagrams, API docs) on-demand from the conversation history for stakeholders who need them

That's the bridge between "no docs" and "enterprise-ready." You get the velocity of conversational development with the auditability and coordination benefits of traditional artifacts—but the artifacts are derived, not primary.

What This Means for Product Builders

If you're a PM, founder, or product leader, here's how to think about applying these ideas:

1. Experiment with "docs-light" for small, high-trust teams

If you're spinning up a new 0-to-1 project with 2-4 people, try a 2-week sprint with minimal documentation. Use Claude (or Cursor, GitHub Copilot, etc.) as the central coordination point. See how far you get before you need a Jira ticket.

The key is high trust and tight feedback loops. Everyone needs to be in the same (virtual) room, able to course-correct quickly.

2. Rethink what "documentation" is for

Traditional docs serve two audiences: the people building the thing and the people who come after. AI tools are fantastic for the first group (real-time coordination) but still weak for the second (onboarding, compliance, long-term maintenance).

Consider a hybrid: use conversational AI during active development, but have a "documentation sprint" at the end where you generate durable artifacts for future readers. Tools like Claude can even help with this—"Here's our conversation history; generate a technical design doc."

3. Invest in "context management" as a skill

In a docs-free workflow, the bottleneck shifts from "writing things down" to "keeping the right context loaded." This is a new skill. You need to:

• Know when to start a fresh conversation vs. continue an existing thread
• Periodically summarize and "checkpoint" context so you don't lose critical decisions when you hit token limits
• Develop shared conventions for how to structure conversations (e.g., "Always start with the user problem before jumping to implementation")

Teams that get good at this will move faster than teams that treat AI as a fancy autocomplete.

4. Don't mistake speed for quality

The biggest risk of this approach is shipping fast but fragile. AI-generated code can be subtly wrong in ways that don't surface until production. The lack of written specs means fewer opportunities for others to poke holes in your logic.

Mitigate this with:

• Aggressive testing. If you're not writing docs, you'd better be writing tests.
• Frequent demos. Show the product to users and stakeholders early and often. The conversation with Claude isn't a substitute for user feedback.
• Post-ship reviews. After you launch, do a retrospective: What would we have caught if we'd written a spec? What bugs slipped through? Use that to calibrate.

The Bigger Picture: Unbundling the Product Org

Zoom out, and what Gusto did is part of a larger trend: AI is unbundling the traditional product org.

For the last 20 years, we've built companies by assembling specialists—designers, engineers, PMs, QA, tech writers—and using process and tooling to coordinate them. The assumption was that each role required deep, narrow expertise that couldn't easily be combined.

AI changes that assumption. A single person with Claude can now:

• Generate UI mockups (via AI design tools or code)
• Write backend and frontend code
• Draft user-facing copy
• Create test cases

Not at the level of a specialist, but often at "good enough" quality for early-stage products. This doesn't eliminate the need for specialists—you still want a great designer for your core flows, a senior engineer for your data architecture—but it does mean you can defer hiring them until later.

The result is smaller, more fluid teams. Instead of a 10-person product squad with fixed roles, you might have 3 generalists who use AI to cover the gaps, plus 1-2 specialists who parachute in for high-leverage work.

This is exciting for founders and early-stage teams. It's disruptive for mid-career specialists whose value was in being the "only person who knows how to do X." And it's a leadership challenge for execs trying to figure out how to reorganize around these new capabilities.

What Doesn't Change

For all the hype, let's be clear about what AI doesn't do:

• Understand your users. Claude can't tell you if your product solves a real problem. That still requires user research, customer conversations, and market intuition.
• Make strategic trade-offs. Should you build feature A or feature B? Should you prioritize growth or retention? These are judgment calls that require human context about your business, not just technical feasibility.
• Navigate organizational politics. If you need buy-in from five stakeholders across three departments, no amount of AI is going to eliminate that coordination tax.

The "no docs" approach works when the team is small, aligned, and empowered to make decisions. The moment you need to convince someone outside that bubble, you're back to making slide decks.

The Path Forward

Eddie Kim's experiment is a glimpse of what's possible, not a playbook for everyone. The teams that will win in the next 3-5 years are the ones that figure out how to:

1. Use AI to collapse coordination overhead where it makes sense (small teams, greenfield projects, high-trust environments)
2. Preserve the benefits of traditional process where it's still necessary (compliance, onboarding, cross-functional alignment)
3. Develop new workflows and tooling that bridge the gap between conversational development and enterprise needs

We're in the early innings. The tools are still rough. The best practices are still being discovered. But the direction is clear: the future of product development is less about managing artifacts and more about managing context. The teams that learn to work with AI—not just using AI—will build faster, leaner, and more creatively than we thought possible.

And maybe, just maybe, we'll finally get to delete Jira.