Lightning Lesson: 3 Workflows to Make Your Codebase AI-Ready with Claire Vo & Zach Davis

Hey everyone! In a recent lightning lesson for Maven's AI Native PM series, I was so excited to hang with my friend Zach Davis, Principal Engineer at LaunchDarkly. We discussed a challenge I see all the time: product managers and designers are ready to contribute to the codebase with AI, but the engineers aren't always ready to let them in.

The bottleneck is often the codebase itself—it’s not set up for agents, which means it’s also not set up for easier human collaboration. The friction of setting up a local environment, understanding the code, and navigating team processes can stop great ideas before they even start. Zach and I believe there’s a better way for product, design, and engineering to work together alongside our new AI agent friends.

We shared a few key processes we've learned for making your codebase and your team truly AI-native. We covered three main areas: using background agents to democratize coding, rethinking the PRD-to-production pipeline, and leveraging a concept called compound engineering to create a flywheel of efficiency. Let’s get into the workflows.

Workflow 1: Using Background Agents to Ship Code

One of the best entry points for bringing AI into your development process is the background agent. A background agent is different from an IDE assistant like Cursor that runs on your local machine. Instead, it operates in the cloud on its own sandboxed machine. Think of it as an always-on junior engineer that anyone on the team can assign tasks to. It has a working environment, it understands the codebase, and it can take a request all the way to an open pull request (PR).

This approach removes the huge barrier of local environment setup, which is often where non-engineers get stuck. As Zach pointed out, using a background agent through a shared platform like Slack is also a fantastic way for the whole team to learn in public. You can collaborate on prompts, see how others are working with the agent, and get those reps in to improve your prompting skills.

For this to work, your prompts really do matter. Just because the work is happening behind the scenes doesn't mean the agent needs less guidance. This is a great forcing function for an organization to get better at writing well-scoped, specific requirements.

How to Use a Background Agent

In the session, I showed a quick example of how a PM can use a background agent to ship an iteration on an existing feature. The goal was to add CSV and Google Sheets export functionality to a feature matrix in my app, ChatPRD.

1. Create a Clear Spec: I started by creating a simple PRD in ChatPRD that outlined the requirements for the export feature.
2. Export to Markdown: I exported the PRD into Markdown. This is a format that agents can easily understand.
3. Kick off the Agent in Slack: I went over to our Slack channel and called the agent, which in this case was Devin. I attached the Markdown file from Step 2 and a screenshot of the UI where the feature should be added.
4. Write a Specific Prompt: I gave it a clear, constrained instruction. Instead of a vague request like "build an export feature," I was very specific.

Devin, Can you please build out CSV and Google Sheets export feature for our products competitors feature matrix? Thanks!

From there, Devin kicks off its own cloud machine, runs the app locally, and starts building the feature. It will eventually open a PR for the engineering team to review. It’s a simple, low-effort way for a PM or designer to fix a UI bug, update some copy, or, in this case, ship a small but valuable new feature, all without touching their local terminal.

Workflow 2: Structuring the PRD-to-Production Pipeline

The first workflow is powerful, but for agents to be truly effective, they need access to good information. This brings us to the next critical piece: where your specs and PRDs live. The old way of working with PRDs in siloed Google Docs or Confluence pages just doesn’t cut it anymore. They become outdated quickly and are difficult for agents to consume.

The new approach is to treat your specs and docs as code. This doesn't necessarily mean they must live in your product's repo, but they should live in a repo where they are programmatically accessible and code-adjacent. This creates a single source of truth that is version-controlled, easy to update, and simple for agents to read.

How to Make PRDs Programmatically Accessible

I showed how we manage this for the ChatPRD codebase. We have a separate repository where we keep all our plans and documentation in a docs/ folder.

1. Centralize Docs in a Repo: All our PRDs, architectural documents, and plans are stored as Markdown files in a dedicated folder. This makes them discoverable and readable for both humans and agents.
2. Use an MCP to Access Docs: Inside my IDE (Cursor), I use what we call an MCP (Model Connector Plugin). This is a tool that allows the AI to programmatically connect to and pull data from other sources. In my case, I have an MCP set up to pull PRDs directly from ChatPRD into my IDE.

1. Generate a Plan from the PRD: Once I've pulled the relevant PRD into my workspace, I can use the agent to transform that product-level document into a technical plan. I simply highlighted the PRD content and gave the agent a prompt:

I want to work on this PRD, build a technical plan

The agent then generates a technical implementation plan right inside my IDE, formatted for an engineer to start working. This eliminates the context-switching and copy-pasting between a Google Doc and the codebase, ensuring everyone is working from the same source of truth.

Workflow 3: Accelerating Velocity with Compound Engineering

Once your codebase is set up for agents and your PRDs are accessible, you can start to build a true flywheel of velocity with a concept called compound engineering. The core idea is simple: if you find yourself doing a repetitive task more than once, you should turn it into a "skill."

A skill is just a set of reusable instructions, written in Markdown, that tells an agent how to perform a specific action within your repository. You can create skills for anything: running pre-flight checks before a commit, scaffolding a new component, or even updating documentation. And here’s the key: you should have your agents write skills for you.

Zach demonstrated how this works in the LaunchRQ CLI repository.

How to Create and Use Skills

1. Start with a Skill-Creator Skill: This might sound a bit meta, but the best way to start is by creating a skill that writes other skills. Zach showed how he took a skill from the company Every and adapted it for the LaunchDarkly repo to serve this purpose.

1. Ask the Agent to Write a Skill: Zach identified a common task: updating the public-facing documentation whenever changes are made. Instead of doing this manually, he asked the agent to create a skill for it with a natural language prompt.

Can you create a skill for this repo, to update this stuff?

1. Review the Generated Skill: In about 30 seconds, the agent created a new update_documentation.md file. This file contains the step-by-step instructions the agent will follow whenever it's asked to update the docs. It's human-readable, editable, and version-controlled along with the rest of the code.

Now, any developer (or background agent!) working in the repo can invoke this skill using a slash command or just by describing the task in natural language. The agent will recognize the intent and use the skill to perform the action correctly every time. By creating and centralizing these skills, you make your entire team—both human and AI—more effective and your development process faster.

Putting It All Together

These three workflows build on each other to create a highly efficient, collaborative environment. It starts with making coding more accessible to the whole team using background agents. It's reinforced by structuring your PRDs and specs as code so that everyone is working from a clear, single source of truth. And it accelerates over time as you build a library of skills that automate repetitive tasks for both your human and agent teammates.

Making your codebase better for AI has the wonderful side effect of making it better for humans, too. It forces clarity, encourages good documentation, and ultimately helps your entire organization ship better products, faster.

Go Deeper: Building an AI-Native EPD Org

If you want to go deeper on these topics, Zach and I just launched our first course, Building an AI-Native EPD Org. We cover how to set up your culture and operating model, get organizational buy-in, and implement advanced agent patterns to get your codebase ready for AI. The course is designed for executives, senior ICs, and anyone looking to lead this transformation in larger teams.

Episode Links

You can watch the full lightning lesson on Maven.