Make It Work, Make it Fast, Make it Easy

Note: Claude was not used to write this article, just the code that inspired it.

Introduction

Part of my responsibility as a Staff Software Engineer on the Developer Platform team is helping to ensure that our engineers are equipped with the tools they need to work effectively. Early on, we knew we had to get those engineers ready for a paradigm shift — one where engineers go from writing lines of code manually to reviewing them and guiding LLMs down the right path.

We needed to build paved paths that enabled engineers to be productive with these powerful new tools while remaining secure and safe. At the same time, we had to move quickly in order to fully appreciate the benefits of emerging technology trends. This blog post is about how I set out to learn to use these new tools while also making them more useful for engineers and LLM agents alike.

The Project

The project itself was simple: Zocdoc has a lot of great best practices and standards documented, as well as a canonical place to look them up. I wanted to go one step further and bring those standards closer to engineers.

Doing so meant integrating those standards more tightly into the tools used by engineers, including AI. As I was researching for this project, I identified three dimensions along which to improve integration:

• Discoverability: Reduce the time it takes to locate a relevant standard.
• Consumption: Reduce the time it takes to understand a standard.
• Maintenance: Reduce the time it takes to create, update, and review standards.

We already had a great system in place for understanding how to build things the Zocdoc way. I just wanted to take the concepts we already had and elevate them for a world where our engineers were AI-native.

My philosophy when building things

As a mentor and former instructor, I used to give my pupils the same advice:

• Make it work
• Make it fast
• Make it pretty

In that order.

The idea is that no one cares how pretty it is if it doesn’t work, and in general, what you’re building only needs to feel fast. As a result, you end up writing software that’s easy to maintain, easy to understand, and you generally avoid the trap of premature optimization and over-engineering.

The order matters, because we’re often so excited to make pretty things.

It’s no wonder then, that when I set out to solve this problem at Zocdoc, I used the same approach, with a twist:

• Make it work
• Make it fast
• Make it pretty easy

In the context of Zocdoc standards, I wanted to make them easier to read, easier to get to, and easier to use in context.

Making it work

The first thing I did was make it work. For this, I needed to understand how our standards were organized, so I read. A lot.

Enough to recognize that before I could distribute the standards, I needed to organize them. Claude analyzed the existing standards and reported back on patterns found in each. I then used that analysis to generate a template that included the following:

• YAML front matter that could be used by AI to index the standard
• A unique identifier for each standard (e.g. AUTH-001)
• A summary of do’s and don’ts
• More details with code examples where appropriate
• An appendix of useful links for deeper understanding

I then asked Claude to draft a set of skills that distilled these full-blown standards into a format that was easy for LLMs to consume and interpret.

The new format allows Claude, for example, to determine which standards apply to a given task, or to point engineers to relevant standards when they ask questions. I knew the full standards would be too much context to load up front, but I also didn’t want to lose the insightful information that engineers had written over the years.

By the time I finished, we had:

• Reorganized standards with consistent templates and unique identifiers
• The /install-standards skill bundled during setup
• The /standard skill to quickly find and read standards

At this point, everything worked — but it wasn’t fast, and it definitely wasn’t easy.

Making It Fast

When I say fast here, I mean two things:

• The time it takes Claude to load
• The time it takes to find a given standard

In the initial version, I scoped rules to certain file paths so that only relevant standards got loaded. However, this approach had issues:

• Some standards are universally applicable and always loaded
• Others only loaded when specific file types were present

The result was higher-than-desired context usage, slower load times, and more manual effort from engineers.

Making It Faster

I used the brainstorming superpower to better understand how Claude interacted with skills and rules, and to identify the biggest contributors to context usage.

After iterating on several approaches, I landed on a hybrid solution:

• A rules index mapping identifiers to one-line summaries
• Full rules loaded only when needed
• Path-based hints to help Claude decide relevance

This resulted in a 98.7% reduction in context usage while preserving access to important standards.

I also improved installation by switching to downloading prebuilt releases from GitHub, reducing setup time from ~10 seconds to ~2 seconds.

Now that everything worked and felt fast, I focused on making it easy.

Make it easy

For this project, easy meant:

• Easy installation
• Easy discovery of standards
• Easy contribution to standards

I simplified installation by removing unnecessary prerequisites and eventually requiring nothing beyond Claude itself, with packaging handled by CI.

To improve discoverability, I indexed standards and made them searchable. For example:

This would trigger the /standard skill to return relevant standards and suggestions to refine the query.

For contributions, I built a /write-standard skill and a Python tool to help engineers create and update standards using the new template. I also added linting to catch common issues and ensure consistency.

In that order

The order matters. It’s easy to focus so much on making something easy that you never get it working properly.

At the same time, this process is iterative. I cycle through work → fast → easy multiple times rather than trying to perfect each stage before moving on.

Conclusion

This simple philosophy helped me stay focused and move quickly. I was able to build something useful, get it into engineers’ hands, and improve it over time.

Through AI Training, I refined both my own approach and how Claude supports engineers — ultimately making both more effective at Zocdoc.