Descriptions:
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:
– https://www.linkedin.com/in/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
