Maven Clinic treats AI adoption as a company-wide change: employees use AI internally, products include AI features, and teams change how they work.
2
The company keeps a one-year view for direction while making real commitments over two to four weeks, because building software is now fast and model capabilities are hard to predict several months ahead.
3
Higher code volume requires engineers to decide when review is needed, keep pull requests near 500 lines, split large features into several changes, and avoid rubber-stamp approvals.
Summary
Dan Feng describes Maven Clinic's move from a traditional technology company toward an AI-native model. The change covers internal work, customer products, hiring, performance reviews, planning, coding, review, and reliability. Employees are encouraged to use AI for routine tasks, while Maven supports the tools that most engineers choose. Engineers are expected to work more independently because implementation can happen quickly with AI. Planning now separates a broad one-year direction from commitments made over two to four weeks. The old three-to-six-month planning window is difficult because nobody knows what models will do by then. Maven began coding-tool adoption with easy-to-check tasks, then expanded use across engineering. Since code output has grown, review depends more on engineer judgment and smaller pull requests. For AI features, Feng separates failures users can retry from failures involving money, where multiple models must agree. Automated tests run repeatedly, and launched conversations receive rubric-based evaluation plus human spot checks.
AI-native work combines internal use, product features, and changed company processes
Feng says Maven Clinic's approach has three parts. Employees should use AI for everyday work such as daily summaries, meeting management, and creating Jira tasks. The company also builds AI into its products, including a chatbot that can be available around the clock and help reduce operational cost. The third part is changing culture and the way teams work so they can make use of what AI offers. Maven Clinic began its AI journey two years ago and built Maven Intelligence, an orchestration layer across its products to enable AI for employees and clients.
Adoption works better when the majority gets shared tools and slow adopters get clear direction
Feng divides technology users into early adopters, the majority, and slow adopters. Early adopters mainly need access to tools and encouragement to share what they learn. The majority needs shared infrastructure, easy-to-use tools, regular feedback, and steady improvement. Maven supported Cursor when most employees used it, then also supported Claude Code when many switched. For reluctant adopters, the company listens to their concerns while being clear about where it is heading. Feng says teams should meet people where they are rather than force everyone onto one tool.
AI reduces the value of delegating implementation and raises the value of independent problem solving
Senior engineers at Maven used to define a problem, design a solution, and delegate implementation so work could happen in parallel. Feng says they now often solve the implementation themselves with AI because handing it off creates overhead after the solution is already understood. New hires therefore need to solve problems independently rather than rely on someone else to delegate implementation tasks to them. Maven looks for people who are genuinely interested in AI and keep learning. Engineers who understand the product can contribute beyond software implementation, especially when they can handle complicated and ambiguous problems.
One-year plans give direction while two-to-four-week commitments keep work changeable
Feng says Maven used to spend weeks or months finalizing requirements and design because implementation was expensive to change later. With AI, a build can take minutes, while arguing about what to build becomes expensive. The company can imagine what it wants to deliver in a year, assuming models will be able to do what is needed by then, but that view is directional. The real commitment is what the team will deliver in the next two to four weeks. Product managers and designers can refine the next batch while engineers release the current one, and the team can change course when an earlier decision proves wrong.
Three-to-six-month planning is difficult because model capabilities may change before the plan arrives
Feng calls the middle planning period awkward. Maven does not want to focus heavily on three- or six-month goals because it does not know what AI models will be capable of after several releases. Short requirement documents, around one or two pages, replace long PRDs or TDDs. These documents communicate the idea and give the team something to argue with and revise. Feng acknowledges that this conflicts with the quarterly and six-month planning habits common in technology companies. Teams have to learn a different planning rhythm.
Maven expanded coding-tool use from low-risk tasks to nearly all implementation
Maven started with tasks such as writing unit tests and documentation because they were easy to verify and carried little risk. That early use helped the company build confidence and create its own rules and guardrails. The practice then moved to the whole engineering team. Feng says engineers now use AI coding tools for nearly all implementation, while their time moves toward review, architecture, and evaluation. Engineers can still use a phone or automate more stages if they are comfortable, but Maven's adoption path began with work where mistakes were easy to find.
Code review needs engineer judgment when daily output grows from hundreds of lines to thousands
Feng says engineers who once wrote hundreds of lines a day can now write thousands, so the old review process cannot keep up. Maven tried AI code-review tools but does not yet rely on them completely. Engineers can identify pull requests that are simple enough to merge without another review, while remaining accountable for the result. When a review is requested, pull requests should stay near 500 lines because larger changes do not allow meaningful review. Large features can be stacked into several pull requests so work continues while each change is reviewed. Feng strongly rejects rubber-stamp approval because it creates false confidence.
Reliability depends on the cost of a failure, with stricter checks for money-related actions
Feng separates failures that users can tolerate from failures that require stronger controls. If appointment scheduling fails once in 10,000 attempts, a user can usually click again and reschedule. A reimbursement error is different because a request for $50 could result in $200, or a request for $200 could result in $50, creating an immediate escalation. Maven sends the same receipt to different models and moves forward only when their results agree. If they cannot agree, the system can send the customer to a human agent. Integration tests also run many times, with Maven requiring a consistently high pass rate, such as 90 percent.
"Building is super fast, it's probably couple minutes you can get it done, argument is really expensive."07:35
Who should watch
You are changing an established software organization and need a practical way to introduce AI without forcing every employee onto the same tool.
Your team is deciding how planning, hiring, performance reviews, or engineering roles should change when implementation becomes much faster.
You build AI features in healthcare or another domain where some errors are recoverable but financial or customer-facing mistakes require stronger checks.
