Blogmark

Mitchell Hashimoto on how you can keep yourself and others on your team honest about the customer-facing code you are shipping, especially in a time where so much code is being generated by LLM coding harnesses.

The "whiteboard defense:" I should be able to pull you aside at any moment and ask you to explain any customer-facing system you've shipped. You should be able to clearly explain how it works and defend the decisions you made. This is my benchmark for responsible AI usage.

I don't expect line-level familiarity with the code. I don't care if you remember the exact function name or implementation detail. You may not even know it. I don't care.

But if I ask "why did you do X instead of Y?", "what happens if this actor behaves maliciously?", "what data structure did you use here and why?", or "where does this fail?" you should be able to answer confidently.

For PoCs, demos, experiments, whatever: I don't care. Generate 100% of it and understand none of it. Speed over quality every time in those specific scenarios.

But if you're shipping customer-facing work, you can't be shipping things you don't understand at a high level.

For really core decisions of features you've owned and shipped, yes, you should be able to know and defend your decisions. I do think this is a little too idealistic.

There are many times, pre- and post-November 2025 Inflection where after a few months and a lot of context-switching, those details start to get pretty fuzzy. "Why did we make X tradeoff?" or "Why did we decide to have Y happen in this one scenario?" Sometimes we chat for a minute and it all comes flooding back. Other times I realize I'm going to need to dig through the codebase or my notes to see if I can jog my memory. There are certainly times where a couple developers and stakeholders are chatting and none of us know the exact reason we went a certain direction. We end up having to just own it -- this is how the system works, what do we want to do going forward.