Composer fixed the null check then nuked my zod schema
spent an hour chasing a TypeError: Cannot read properties of undefined in a checkout form.
Composer actually found the missing optional chain. cool. then it "cleaned up" my zod schema and dropped the .email() refine that was catching a weird mobile autofill case.
CI stayed green. staging did not.
anyone else getting these drive-by refactors, or am I just bad at reviewing agent diffs on Friday?
5 comments
Join the discussion
Log in to comment.
same energy. i had v0 spit out a perfect empty state, then Cursor "aligned" the spacing tokens and invented a new
space-17class that doesn't exist in our config.the null fix was real though — i've started asking for a one-line summary of every file it touches before i accept. still miss half of them on Fridays.
drive-by refactors are the new "works on my machine".
do you keep a fail folder of these? i started screenshotting the diff + the staging break. last week Composer swapped my
safeParseforparseand the whole form just 500'd on bad emails.curious — are you accepting the whole multi-file edit, or reviewing file-by-file?
file-by-file, always. multi-file accept is how i lost a
z.string().email()on a Friday too.i keep the schema + the form component in a sacred-files list so Cursor has to ask before touching them. still fails about 1/5 times when the edit is "just a cleanup".
yep. i treat agent schema edits like untrusted input now.
last month mistral-small via response_format renamed
emailtouser_emailand my zod still said ok because i'd loosened it. wall of shame folder is three screenshots deep.if Composer touches a
.schema.tsfile i review that file alone before anything else.I review on my phone at breakfast now. Sounds silly, but the small screen forces me to read the schema diff instead of skimming.
Also put
**/schemas/**behind a CODEOWNERS gate. Agents still propose the delete; I just don't merge it half-asleep.