rileymichael

in a vacuum, sure. the average pull request will have multiple commits once opened (i.e. to address feedback or perhaps it was opened too early), each triggering a review. it's very easy to rack up $100+ per pr (and an eng may open a dozen prs in a single day)

what are people using for automated code review these days? the claude code review product originally mentioned it cost "$15-25 per review" (which is absurd), but it seems like they've removed that from their docs with the launch yesterday. we've looked at various products in the space (coderabbit, greptile, etc.) but have gripes with each.

honestly i'm thinking it might be easier (and cheaper) to launch our own agent from GH webhooks and trigger `/code-review`..

the second book is a bit slow with all the politics, but it's worth it because book three is the best of the trilogy

i've been working my way through all of the cosmere (after starting with mistborn), currently on book 3 of stormlight archive. can't put em down

the same way they currently enforce authors own all copyright in their contributions, via the contributor agreement (OCA). in the real world, people aren’t going to intentionally sneak in LLM-authored code and potentially be legally liable.

> I don't select my engineering tools because they give me a bad feeling - I select them because they do the thing I want them to. If Bun starts having more bugs and feeling like worse software, I'll stop using it. But I will base that on data -- not a feeling I have.

being reactive is fine if you can tolerate issues. otherwise, you need to be proactive -- don't wait for the train to hit you before you move off the tracks

i can't speak to gitea, but github and gitlab are explicitly mentioned as having a license in their policy:

> Please be aware that GitHub and GitLab are exceptions to this Policy because they are subject to explicit licensing arrangements that pre-date, and thus take precedence, over this Policy.

just noting that pinning within your own actions is not enough, you also need to ensure any composite actions do not use mutable references (for actions, docker images, etc.)

while external merge queues offer a ton more features, i wouldn't describe any of them as 'perfect' based on the simple fact the UX is bolted on. github continues to display their native UI components for merging, and users are forced to interact via arcane commands in comments or external CLIs/webpages. not ideal!

you should limit your output (manual or assisted) to a level that is well under your understanding ceiling.

Kernighan’s Law states that debugging is twice as hard as writing. how do you ever intend on debugging something you can’t even write?