← back
How to build an AI-Native Health Company — Dan Feng, Maven Clinic
Takeaway
Becoming AI native requires redesigning incentives and delivery practices alongside adopting models and tools.
Summary
- Maven defines AI adoption across internal tooling, customer products, and organizational culture, supported by its Maven Intelligence orchestration layer.
- Shared infrastructure, tool choice, and continuous feedback help mainstream adopters, while hiring emphasizes independent problem solving and product understanding.
- The team favors two-to-four-week delivery cycles and short planning documents because AI reduces implementation costs and makes longer-term capability forecasts uncertain.
- Coding-tool adoption began with easily verified tasks such as tests and documentation before expanding through accumulated rules and guardrails.
ai-adoptionhealthcareengineering-culture
Original description
Implementation used to be the expensive step, so teams spent weeks settling requirements before anyone wrote code. Dan Feng's observation is that the cost moved. Building takes minutes now, and arguing is what is expensive. Planning at Maven Clinic changed to match. A one year view survives only as direction, assuming models will handle whatever you need by then, while real commitment runs two to four weeks. Long requirement documents gave way to a page or two meant to be argued with. The awkward casualty is the three to six month plan, which he treats as close to unplannable when nobody knows what models will do by then. The rest is what breaks at that speed. Engineers who once wrote hundreds of lines a day now write thousands, so review had to change rather than scale. Engineers self certify which pull requests need a second reader and stay accountable either way, requests are capped near 500 lines, and large features are stacked into several. The failure he names is the rubber stamp, which buys false confidence rather than none. On reliability he refuses a single bar and sorts failures into tolerable and not. A scheduling action that fails one time in 10,000 is survivable, since the user clicks again. A reimbursement claim is not, because asking for $50 and receiving $200 is an escalation in either direction, so several models read the same receipt and it proceeds only if they agree. Integration tests run many times rather than once, since passing a nondeterministic system on one attempt proves very little. Speaker info: / dan-feng-2bb5703 https://www.mavenclinic.com/ Timestamps: 0:00 - Who here is already AI native 0:51 - Maven Clinic, and starting the journey two years ago 1:29 - Tractors do not replace farmers 2:08 - Adopting internally, then building it into the product 3:25 - Early adopters, the majority, and the reluctant 4:04 - Meeting engineers on whichever tool they moved to 4:43 - Why senior engineers stopped delegating implementation 6:03 - The blurring line between product and engineering 6:42 - Rewarding it in performance reviews 7:21 - When building is cheap and arguing is expensive 8:00 - Dream big for the year, commit for the sprint 9:16 - Why three to six month plans became the hard part 9:56 - Starting with the lowest risk coding tasks 10:36 - Pushing it to the whole team 11:13 - Code review when volume goes up tenfold 11:54 - Self certifying, capping size, stacking changes 12:34 - The rubber stamp problem 13:57 - Deciding which failures are acceptable 14:35 - Claims, where the tolerance is zero 15:54 - Automated evaluation plus human spot checks