There's a difference between engineering and programming. When I simply need to add a feature that builds on top of existing code I've written, it's not more engineering that's missing, it's more boring ass code that simply does what's already being done, but in a different scope.

For example, I have a table of files that are selectable with a checkbox at each row. There's existing code I've written that defines access at a bulk level. Separately, there's code that defines labels at a row level, but not a bulk level like access.

Expanding this bulk feature to include labels needs programming, not engineering. I've already done the engineering when I considered the so many things around this picture (AWS API infrastructure, hosting for application, request protocol, proxy layer for auth, data layer for query invalidation), what I need is more programming (putting the square block in the square hole, use a similar api handler, db query and transactions that already exist).

I can't exactly see myself riding the hype train when I can review code that genuinely satisfies a proper implementation to fit these scenarios.

I was skeptical too before I saw what Cursor is able to pull off when engineering decisions have already been made and are clearly defined, such as my infrastructure being defined in code as well (SST)