Hacker News
points by user43928 4 days ago | 0 comments
Opus 5.5 is not normally copying the whole database to update a single row for no reason, and without mentioning a workaround. It's simply not my experience, and I don't think there is anything weird about me saying so.

I don't think I commented on performance tests at all.

Maybe I lack imagination here, yes, but generally I go by experience rather than talking about imagined issues. That is precisely what many here seem to do when it comes to explaining why AI couldn't work for them, and why reviewing the code remains necessary.

[–] prmph 4 days ago
See this basic architectural smell Claude Opus 5.5 produced just minutes ago:

Me: Why this:

> I'm adding a lookup to persistEphemeralVFolder so that a repeated search reuses the user's root vFolder with the same query instead of hitting the unique index.

Claude Opus 5.5: A search stores its query as an ephemeral root vFolder. The new unique index on (user, parent query, query) now rejects a second root vFolder with the same query. As written, persistEphemeralVFolder always inserts, so repeating a search would fail its insert, the retry with a fresh short code would fail too, and the search would return an error. The Ephemeral VFolder paragraph we rewrote in the SPECS also says a search reuses the existing vFolder with its query, so the user gets the same short code back.

The lookup I proposed would also copy the query-then-create logic already in the PUT /vfolders handler. A cleaner option is one shared engine function that finds or creates a vFolder by query, called by both the handler and persistEphemeralVFolder. Shall I do that, or keep the local lookup?

Churned for 6s · done 1:10 PM

Me: I mean, is it not cleaner to fix this: "persistEphemeralVFolder always insert"

And generally, we want the db and its indexes to do their work, not duplicating that in application code with pre-lookups and stuff

Claude Opus 5.5: You're right. Both persistEphemeralVFolder and the lookup I put in the PUT /vfolders handler should be replaced by a save with conflict keys (user, parent query, query), so the unique index decides whether a row is created or updated.

[–] user43928 3 days ago
What you're showing here seems to be a suboptimal choice being propagated, but with likely no practical impact at all if you kept the lookup.