# How to build an AI-Native Health Company — Dan Feng, Maven Clinic

## Executive summary

The transition to an AI-native company requires a fundamental shift in process and culture, moving away from lengthy planning cycles toward rapid, iterative development. While building software is now fast (minutes), the expense lies in arguing requirements. Build engineers must adapt by adopting short-cycle planning (2–4 weeks) and implementing rigorous, multi-layered testing strategies to manage AI-specific risks like hallucination. Key process changes include limiting Pull Request (PR) size (capped near 500 lines) and running integration tests multiple times to ensure reliability.

## Key takeaways

- Shift Planning Focus: Instead of spending weeks or months finalizing requirements, focus on delivering value in the next two to four weeks. Long-term plans (1 year) should only serve as directional inspiration, not rigid commitments.
- Redefining Code Review: Due to increased code output from AI tools, traditional code review must change. Engineers can self-certify simple PRs, and large features should be stacked into multiple smaller PRs (capped near 500 lines) to maintain meaningful review quality.
- AI Reliability Testing: For GenAI solutions, failure modes must be categorized (tolerable vs. not acceptable). Critical processes require consensus among multiple models (e.g., using different LLMs to review the same receipt) and running integration tests many times, rather than just once.

## Technical details

- AI Native Infrastructure: Maven Clinic implemented a 'Maven Intelligence,' an orchestration layer across all products to enable AI functionality company-wide. This infrastructure supports internal tasks (e.g., generating daily summaries, creating Jira tasks) and external product features.
- Development Workflow: The process favors short, iterative cycles over massive upfront documentation. Teams should write concise PRDs (one or two pages) that serve as communication tools for rapid iteration, rather than exhaustive technical design documents.
- Code Review Best Practices: To manage the volume of code generated by AI coding tools, PRs should be limited to approximately 500 lines. Large features must be broken down into multiple, reviewable PRs. The 'rubber stamp' (blindly approving code without meaningful review) is explicitly discouraged.
- Testing and Quality Assurance: Reliability requires running integration tests multiple times for every test case, not just once. For high-stakes processes (like financial claims), consensus is achieved by having several different models review the same input before proceeding.

## Practical implications

- Shift organizational focus from planning documents (PRDs) to short, actionable sprints.
- Implement self-service code review models while maintaining strict limits on PR size and complexity.
- Adopt a 'fail classification' approach for AI systems, determining which failures are acceptable risks versus critical errors.
- Treat AI tools as accelerators that augment human intelligence (reviewing/architecting), rather than replacements for deep technical oversight.

## Topics

AI Adoption, DevOps, Software Architecture, Build Engineering, Process Improvement, Maven Clinic, Dan Feng

Source: https://www.youtube.com/watch?v=WJRdLNhrsLQ