AI-assisted development only works when engineers can define, test, and observe what “good” means with guardrails. At Zocdoc, that means crafting developer experiences that help teams ship reliable changes to patient and provider experiences.
At its core, AI Native Development is hard to trust when we haven’t clearly defined what “good” looks like. Defining “good” isn’t enough on its own. We also need strict validation to enforce it. That matters even more in healthcare, where data protection standards are non-negotiable. Because we work in healthcare, our AI-assisted development practices are designed around privacy, data protection, and human accountability. The guardrails described here focus on code quality and operational confidence without exposing patient or provider data.
Why does this matter? It shows up directly in achieving our goals:
- We now merge 80% more PRs (Pull Requests) per week, per engineer (p90). Time to approval also dropped by ~30mins as we improve confidence in guardrails.
- 95% of our engineers responded “always” or “most of the time” to survey questions surrounding the theme “AI tools produce code that I can use with only minor edits (i.e., without time-consuming rewrites)”.
- We deploy more and experience fewer incidents. Our “Change Fail Percentage” (number of incidents divided by number of deployments) dropped by 75%.
Our AI Native Development foundation is strengthening – here is how we achieved it.
Code Review
Code Review has always been a key pillar of code quality control. Not long ago, it was reasonable to expect rigorous, thorough human review from engineers on every pull request (PR).
In 2026, the bottleneck has changed: the cost of producing code has diminished to a point where that quality review is now perhaps the slowest point of the day-to-day SDLC. We saw this slowdown exemplified: in February 2026 we saw PRs stalling with time to merge slowing down by 86% (p90).
Given the flood of code being checked in and the desire to keep quality high, we’ve taken a hybrid approach to code review: every PR gets an automated review and a human approval is still required to merge. Our automated review lands first, providing an initial pass looking for quality, risk, style, standards, opportunities for refactor, and more. We’ve trained our automated review on our Zocdoc coding standards (see here for more on those) and tweak it per-repo as needed. Afterwards, human review comes in with most of the initial pass commentary out of the way.
We’ve also seen faster feedback improve time to first PR approval by 25%. At the same time, the spike in time to merge dropped from 86% slower to just 15% by May 2026 at p90. In short, PRs are stalling less. We’re also actively encouraging PRs under ~600–800 lines.
We’re still requiring human review because systems aren’t perfect. Not everything we hope to capture in automated code checks is automated yet, so human review helps fill some gaps and share context between teammates as to what is changing in a codebase.
Observability
Even with all of the reviews and testing in the world, software can still have issues. With more deployments and code going live, our observability tools need to be extra sharp in order to properly detect regressions and mitigate their impact. With AI Native Development, this is magnified. The perception is that AI code leads to more incidents and can erode trust with agentic systems.
Over the last few months, we noticed that:
- We wanted to detect issues in our systems even faster to provide a better experience for our patients.
- Our signal-to-noise ratio felt high. We had no means to routinely clean noise, so we left it federated.
We took a proactive approach and added even more observability around specific pieces of our Booking flow and other key user journeys. We also needed to tone down the noise to allow for us to focus on truly critical, actionable data.
To that end, we began to define and implement “infrastructure scorecards” to score services on their operational excellence. These scorecards help improve trust in AI Native Development by identifying healthy OpEx practices. Here are some of the scorecard metrics we defined:
- Code Coverage (are we maintaining a baseline measurement of test health?)
- Deployment strategy (can we rollback automatically if needed?)
- Authoring Smoke Tests (do we verify key flows work as expected post-deploy? )
- Noise in Error Reporting (do we have lingering issues in error reporting that should be addressed or filtered?)
Testing
Simply put, one of the best judges of quality for AI coding workflows is in deterministic testing and static code analysis checks. We don’t want to write tests just for the sake of writing tests, but we should err on the side of ensuring test coverage. For the sake of trust, test coverage serves as a first line of defense against any code change, from a human or an agent.
For example, some deterministic checks we can offload from LLMs include:
- Linting
- Typechecking
- Unit testing
- Integration testing
- End-to-end testing
- Visual regression testing
In terms of our UI guardrails, one blind spot we’ve previously addressed was our testing posture for mobile web.
Mobile device web browsers represent a significant share of our patient traffic. Resizing a desktop browser can validate responsive layout, but it cannot reliably surface the real-device behaviors that shape the user experience. The risk is false confidence – we convince ourselves a flow is covered because it works in a narrow desktop window, when we have not actually verified the environment most users are in.
Putting it All Together
Agentic coding leans on trust. Do we trust that agentic coding is doing a “good” job? Without clear boundaries and signals, we risk playing a guessing game that LLMs do what we want.
At Zocdoc, we’ve leaned into trust with agentic systems. By shoring up testing infrastructure, investing in hybrid reviews, and cleaning up our observability we’ve seen measurable growth in the quality of our agentic coding tools. Our questions when constructing agentic systems venture more into the realm of “what does good look like” and less of “is this specific model good at <my task>”.
In sum we are improving trust by:
- Continuing to improve deterministic, automated coverage. We’re altering our approaches and ensuring we’re testing the right things
- Investing in a belt and suspenders review process to improve automated review quality and improve the efficacy of human review.
- Ensuring high quality, actionable alerting against our key user journeys and critical systems
By strengthening the guardrails in which agents operate in, we help solve for the human factor of trust with agentic coding and further unlock the promise of AI Native Development.