Mark Huebel · VP of Engineering, TimelyCare
Build speed is solved.
Absorption isn't.
I ran the experiment at TimelyCare, where I lead engineering. Moving product development to AI‑native delivery raised build speed roughly 30‑fold against our 2022 baseline — and delivered output about four‑fold. The gap is absorption: review, release, and go‑to‑market were built for the old cadence — sensibly, because engineering used to be the slow part. The writing here covers how we made the shift, and what to do once the constraint leaves engineering.
- 27×
- concept to production
- 36×
- time to first executable
- ~4.6× per engineer
- team 16% smaller
- 0.90 → ~0
- pre-code share of delivery
The figures, and where they came from
Median time from concept to production fell from about 20 days to 18 hours, measured against the 2022 pre-platform baseline. Time to first executable came down about 36-fold over the same period. The share of active delivery spent before any code existed fell from 0.90 to near zero, recording zero in four of the last six months.
Resolved engineering work went from 142 issues in a 2022 quarter to 551 in a 2026 quarter, while the organization went from 19 people to 16. Build speed rose far faster than delivered output — the difference is work the processes around delivery, sized for the old cadence, weren't yet set up to receive. That moved the company's constraint out of engineering.
A product manager working directly with agents delivered in 47 days a case-management capability a pod had spent 136 days approaching — and showed along the way that the company could retire a third-party contract rather than integrate it, ending a recurring licensing cost.
Measured against our 2022 pre-platform baseline. Duration figures from internal delivery metrics; work volume from resolved engineering tickets.
Where the writing comes from
I'm a self-taught engineer. I started out freelancing — an inventory system for a nonprofit, a job tracker for an engineering firm, apps for a smart-sprinkler company later acquired by Moen — then joined Stack Sports, where I went from mobile developer to leading new projects within a year.
In 2019 I joined TimelyCare as its first engineer, before there was a production product. I built the core of the telehealth platform, grew the engineering organization as the company scaled, and lead it today as VP of Engineering.
The writing here comes from the most recent chapter: moving product development from human-driven to substantially agent-driven, in regulated healthcare, and keeping notes on what held up. The doctrine lives in Harness Engineering; the blog is the working notebook.
The operating doctrine, written down
After changing how TimelyCare ships, I wrote down what the change taught me. Three pieces, and they run in order: a map of the ground, how to work well inside a cycle, and what to build when you'd rather not be in every cycle.
The 9-Stage AI Adoption Model
The roadmap from phase-gated delivery to compounding systems: nine ways of working, each with the signals that tell you whether you're in it yet.
The Agentic PDLC
Working well inside the loop: give the agent the problem rather than the solution, and keep the seams it would otherwise manage for you off your team's desk.
The Strategy Compounding Loop
Working on the loop instead of in it. Execution, alignment-checking, and strategy revision stay separate, so the work itself sharpens the strategy that steers it.
Loop & Harness Engineering · five chapters, each a loop
01 The Loop · 02 Inside a Build · 03 Scaling to a Portfolio · 04 Betting Beyond the Data · 05 About This Doctrine
Read the doctrineNotes in long form
The disruptive PDLC: the gap in our own numbers
Build speed rose about 30-fold against our 2022 baseline. Delivered output rose about four-fold. The seven-fold gap between them is the velocity wall, measured, and closing it means moving the day-to-day onto agents and the people to judgment. This is the forecast.
Outcomes over output: bets until the problem is solved
The velocity wall starts upstream, in how the work gets chosen: when building gets cheap, a ranked list of requests stops being strategy. The scarce thing is a problem with a definition of done.
Disruptive engineering: when PMs ship the code
In Q2, about half of our Product and Engineering contributors shipped production code on their own — including every PM and designer who took part. Christensen's framework is what convinced us to try.
Where this goes next
I write about building with AI agents at production scale without losing the wheel. If you're working the same problem, I'd welcome the conversation.