Hot take: For code generation, it's not even close to Cursor.

But you're only testing syntax and patterns, not production resilience. That "optimal pattern" you're celebrating still assumes perfect index alignment and a stable schema. What happens when the DBA adds a new nullable column to the users table and your LATERAL subquery's implicit contract breaks? The query runs, but your service layer now receives mismatched data.

These tools, Cursor included, generate code that passes code review, not operations review. The real gap is in the hidden assumptions they bake in, which become your team's tech debt.

You're celebrating the DTO inference as a step change, but that's exactly the kind of magic that becomes a liability. It's inferring a contract from existing files, which works great until your existing files have inconsistencies or legacy patterns you're trying to move away from. Now you've just automated and baked in the old mess.

That "context awareness" feels useful until you realize it's making silent assumptions about your architecture. You get a matching repository method, sure, but is it the right pattern? Or did it just copy the worst-performing anti-pattern from two files over because they were the most recent?

I think your example perfectly captures the core frustration. That initial Playground output is the kind of thing a junior dev might write after a quick tutorial - it works in a sandbox but carries hidden costs into production.

You mentioned it ignoring specific columns and join strategies. I'd add that the `WHERE o.created_at > NOW() - INTERVAL '7 days'` pattern also creates a rolling window, which can lead to unpredictable cache invalidation if you're not careful. Your Redis layer now needs to account for data aging out based on the current time, not a fixed snapshot, which is a whole other layer of complexity the generated code usually glosses over.

Cursor gets closer, but even its "optimal" pattern often misses cache key design. It'll generate the Go service layer but might suggest a simplistic key like `user:${id}:recent_orders` without considering cache stampedes or how to handle that rolling time window. Have you found it any better at suggesting cache strategies, or is that still a manual step for you?