Someone always trusted someone else to write the code
contents · notes
# contents
or rss. no spam, one-click out.
This feels crazy to say, but I'm at a place where I no longer look at or review the vast majority of the code I push. I trust AI to the point where, if it works as a user and solves the business requirements, I'm not concerned about the nitty-gritty details of the code. Again, it feels crazy to say, and it took me a long time to get here.
It's also highly dependent on what I'm pushing. When I recently shipped a new way to sign in, I reviewed the description of the pull request to verify what the AI built, the QA document it produced, and the risk analysis from my local software factory. Then I pushed it straight to production and tested it there for the first time to verify it works. If I were building payments code, I'd probably spend more time on it, but honestly, not much more. The AI does such a good job QAing that it has started to feel redundant for me to manually do what it has already done.
Someone always trusted someone else
DHH's opening keynote at Rails World 2026 is worth an hour of your time. A lot of it relates directly to this. The part that resonated with me more than anything was this:
I evaluate the Rust box as a black box on the outside, as any business owner in history who's ever commissioned a group of programmers to do anything for them. This is not a new phenomenon. Who now holds that responsibility has changed, but not the phenomenon.
In any business, someone has always trusted someone else to write the code that solves a problem. A CEO trusts their engineers to write it. With AI, the only thing that has changed is that we engineers now trust AI to write code the same way we have always been trusted to write it. That helped me wrap my brain around all of this.
The code still matters
To be clear, I think the code still matters, but at a high level: the architecture. The last thing I told an AI was to use single-table inheritance instead of creating a new model.