Anglican Christian. Software engineer and composer, theologian, writer, runner, photographer, and erstwhile podcaster. Platform engineering at Vanta. Previously the tech lead for LinkedIn web, Ember TypeScript & Framework emeritus.
→ chriskrycho.com
Replying to @chriskrycho@mastodon.social
@baldur So it’s often ending up being a *worse* version of the automation paradox: the direct outcomes being anywhere from somewhat to significantly worse and the second-order effect still being deskilling. We tolerate the cost of the automation paradox in aircraft autopilot and similar systems because it significantly improves average outcomes. It doesn’t seem to be doing that here.
Replying to @chriskrycho@mastodon.social
@baldur I would say (and in the past *did* say) that this was just a new version of the classic automation paradox, but the *classic* automation paradox involves higher performance than the baseline under normal circumstances. There are axes on which that is sometimes true here—adversarial review, e.g., surprisingly often does better than manual code review given existing code review practices (That’s its own topic of broken engineering practices, of course!) — but it’s not remotely all of them.
Replying to @baldur@toot.cafe
@baldur Aye. There have been meaningful changes, but the way I put it to people is: the November 2025/Opus 4.5 shift was from “the stuff they spit out doesn’t usually work” to “the stuff they spit out usually works… but it still isn’t *good*”.
It’s quite plausible to me that that change has *worsened* the quality of code coming across the line, because “works” is enough for some folks to say “ship it”. When it just didn’t work, you *had* to actually touch it, which may have helped… somewhat.