How to build an AI-Native Health Company — Dan Feng, Maven Clinic
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
10:32
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
105s
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
702s
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.
Mentioned resources
Channel & topics
Watch on YouTube · Back to latest
This independent, AI-assisted summary is provided for commentary and informational purposes. It may contain errors or omit important context. Please watch the original video for the creator's complete presentation. Video, thumbnail, and related copyrights belong to their respective owners.