My Development Non-Negotiables: Shipping Fast, Seeing Clearly, and Letting AI Assist

Lately, I've been pushing a significant volume of code – averaging around 10,000 lines a day. Of course, that kind of output isn't a solo act. It relies heavily on the intelligent use of development tools and processes, and a good chunk of the work goes into refining those tools. Getting these assistants to work smoothly is a complex topic on its own, but today I want to focus on the underlying infrastructural elements that make this kind of consistent development possible. Here are some of the non-negotiables I've found essential for maintaining that flow.

1. A Relentless Bias Towards Shipping

My first, and perhaps most crucial, non-negotiable is a fierce commitment to shipping – a "goggles on, hair flying in the wind" kind of fast. What do I mean by that? I'm talking multiple deployments a day, often on a whim, not tied to any pre-determined schedule. It's about the feeling of relentless forward momentum, the ability to react instantly. This requires everything to be aligned to this goal; if a fix or small feature can't go from idea to deployed in a few minutes, something is drastically wrong. Hours to deploy? Then this article is absolutely for you.

It's important to be clear: this level of speed isn't just a matter of attitude or individual effort. There's a monumental architectural effort behind the scenes, a fully-fledged DevOps infrastructure that makes it all possible.

For my infrastructure, there's a huge bias towards Developer Experience (DevX) over price. I prioritize tools and systems that empower developers to move quickly and efficiently, even if they come with a higher price tag. I’ve found that the increased velocity and reduced friction more than pay for the investment. It's a strategic choice: invest in DevX and reap the rewards in terms of faster iteration, higher quality, and happier developers. This is not just "move fast and break things," but more of a "move incredibly fast, and have the infrastructure to support it.

Don't even get me started on using the cheap [developer, model, computer]. If you thought that expensive ones cost too much, just try the cheap ones. They're lower priced for a reason.

2. Intense Observability: Seeing is Believing

But, rapid shipping alone isn't enough. We need to know exactly what's happening once that code hits production. That leads me to my next non-negotiable:

For me, 'observability' goes far beyond simple log files. While those are important, I need a much deeper, richer understanding of how users are interacting with the system. I'm talking video recordings of user sessions that I can literally watch. This level of visibility lets me spot friction points, UI issues, and unexpected behaviors in real-time.

Of course, alongside this visual data, robust analytics are critical. I need to understand key metrics and have the ability to slice and dice the data to get granular insights. I also heavily rely on feature flags. They give me the power to roll out new code gradually, test it with a subset of users, and roll back immediately if things aren't working as expected.

In short, my goal is to have the most complete view possible of my software in its natural environment. This approach isn't just about fixing bugs—it's about continuous learning and optimization. The more I can see, the better I can build. We're not just throwing code over the wall; we're actively observing its impact and iterating based on real-world usage.

3. Rigorous Testing: Validating Ideas and Protecting Deployments

We're not just throwing code over the wall; we're actively observing its impact and iterating based on real-world usage. But, observation alone isn't enough. We need ways to actively validate ideas and protect our deployments from regressions. This brings me to the third non-negotiable:

Testing, for me, is a two-pronged approach. First, it's about validation. I need the ability to put different ideas to the test and determine what works best for my users. This means employing rigorous A/B testing. I need to be able to roll out variations of a feature to different user groups, measure their performance, and make data-driven decisions about what to keep, refine, or discard. It's not just about guessing, it's about validating.

Second, testing is about protection. I can't allow frequent deployments to become a source of instability. So every single deployment is guarded by robust automated testing. This is non-negotiable; before any code makes its way to production, it needs to pass a battery of tests ensuring core functionality remains rock solid. This ensures I'm not just moving quickly, but I'm moving safely and confidently.

These two types of testing aren't independent; they work in tandem. A/B testing helps us explore, while automated testing ensures we're not breaking things in the process. Together, they are critical to the entire development cycle.

4. Living Documentation: Context is King

Together, they are critical to the entire development cycle. But the ability to ship quickly, see clearly, and validate rigorously doesn't mean anything without a well-documented process. This leads to my fourth non-negotiable:

Today, there really are no excuses for poor documentation. We have powerful tools that can assist us in almost every aspect of development, but they can only be as effective as the context they are given. I've found that I achieve the best results—including those massive shipping numbers I mentioned earlier—when I carefully think through my strategy and document it rigorously. This isn't just about the final product; it's about documenting the process itself.

This means I need living documentation; it needs to be current and accessible. For me, that means everything lives in the project repository. This is not an arbitrary decision. If my documentation lives somewhere else, it cannot be effectively used as context for my AI agents and models that I rely on so heavily to accelerate development. Documentation diagrams in formats that the models can't digest are completely unacceptable. My goal is for every piece of documentation to be a valuable resource for both my models and my team. We're not writing for documentation's sake; we're writing to empower ourselves and our tools.

This approach ensures my AI assistants understand the 'why' behind the 'what', enabling them to become truly valuable partners. It also means that new team members can quickly get up to speed by exploring a well-documented project that is consistent and living.

Conclusion

These four non-negotiables – a relentless bias towards shipping, intense observability, rigorous testing, and living documentation – form the foundation of my development workflow. They enable me to iterate quickly, learn continuously, and leverage the power of AI to achieve a level of productivity that simply wouldn't be possible otherwise. This isn't just about writing code; it's about building a system that amplifies my capabilities and allows me to deliver value to users at an unprecedented pace.