I think the reason this is so popular is because it's simple and universal and doesn't force someone else's assumptions and workflows upon you.
I also think the reason this works is because it forces exactly what AI makes it convenient to skip:
The hard part of thinking about our assumptions and intentions, challenging them, and resolving them.
I think that stuff is what's often lost with AI. I work in growth nowadays, and it's easy to say "Write me copy for this landing page based on our docs" and it'll write something that contains real features, integrations, and potential benefits.
The hard part isn't finding features and how they could be useful, but to decide which are the 3-4 to spotlight based on what users care about most and how they actually use the product.
Or to realize that yes, there's a set of general "best practices", but we need to overrule some because we're in a niche category, so people will care about some niche details that other products don't need to surface on their home page.
I found the same is true in engineering. We recently rebuilt our Kubernetes operator because one CRD replicated connection and auth for each resource, which led to scalability issues:
-Each resource authenticated independently on restart, and the burst of API calls led to rate limits, which led to latency in getting to steady state.
-Each resource held its own client in memory, which led to OOM issues, which led to restarts.
If you ask AI on how to fix this, it did realize the issue was burst API calls and replication of connection/auth. But its suggestions were that we needed to build event watchers/dither/queues, etc.
This would've solved that specific issue, but not the underlying problem that we had an overloaded CRD.
The real solution was to turn auth/connection into separate CRDs that operate as a lazy, shared cache. This solved the underlying architectural problem, not just the symptoms of it.
Doing this kind of thinking is the important part, and you can't skip it and expect good results. Something like grill-me is a forcing function to do this.
FinnLobsien•1m ago
I also think the reason this works is because it forces exactly what AI makes it convenient to skip:
The hard part of thinking about our assumptions and intentions, challenging them, and resolving them.
I think that stuff is what's often lost with AI. I work in growth nowadays, and it's easy to say "Write me copy for this landing page based on our docs" and it'll write something that contains real features, integrations, and potential benefits.
The hard part isn't finding features and how they could be useful, but to decide which are the 3-4 to spotlight based on what users care about most and how they actually use the product.
Or to realize that yes, there's a set of general "best practices", but we need to overrule some because we're in a niche category, so people will care about some niche details that other products don't need to surface on their home page.
I found the same is true in engineering. We recently rebuilt our Kubernetes operator because one CRD replicated connection and auth for each resource, which led to scalability issues:
-Each resource authenticated independently on restart, and the burst of API calls led to rate limits, which led to latency in getting to steady state.
-Each resource held its own client in memory, which led to OOM issues, which led to restarts.
If you ask AI on how to fix this, it did realize the issue was burst API calls and replication of connection/auth. But its suggestions were that we needed to build event watchers/dither/queues, etc.
This would've solved that specific issue, but not the underlying problem that we had an overloaded CRD.
The real solution was to turn auth/connection into separate CRDs that operate as a lazy, shared cache. This solved the underlying architectural problem, not just the symptoms of it.
Doing this kind of thinking is the important part, and you can't skip it and expect good results. Something like grill-me is a forcing function to do this.