warpfork

My stance is against newfanglism as a social ethic. We start by imagining the social world we want to build toward, and then work backward to what technical practices and technologies will help or hinder us getting there. If you start with adoption of the new as its own end you can be led anywhere.

Some misc thots from it:

- metadata in other files: yes please. Nothing makes me more paranoid about file corruption than a media file changing... And then later finding it was a one character change in a comment tag.

- init that from id3 tags: sure.

- filename derive from metadata: want.

I don't necessarily want to die on the hill of "inline comments bad" either. But on the hill of "inline comments shouldn't dominate the data model so hard you can't make non-inline comments", yeah, would actually.

I might be weird on this but the only thing I've ever liked about github's idea of inline review comments is that one can mark them as addressed.

And I'd like that feature *better* if it was decoupled from the inline part. Checklists would be a lot closer to the ideal imo.

It can also be that I'm pasting this back to claude; there's no PR, there's no github, there is really no inline comments concept to bend backwards to fit there; so together with the semiotic wrongness, *and* the fragility vs other changes...gosh, I'd rather intensely rather not get forced to line#.

Example user story: I see a problem in a commit, and I write a note, under a heading, with an approximate change suggestion. I see it a second time; I add a note that the whole PR needs to be reviewed for this pattern.

*I don't enumerate all instances*. Inline comments not a win.

Patch stuff with line numbers in the "@@" line should also be capable of this though?

But at a higher level: Whether or not the user wants to map things into inline comments feels like it should be a choice. I, often, don't.

Cursed set of shell scripts driving mplayer

Please save me

I tend to think the headings should be headings... And if there's file paths and line numbers, those should be in the code block.

(I also tend to write reviews that group by topic and then list example incident points. Maybe I'm odd, but I think this good. Line info centricness makes it harder.)

This could totally be a "porque no los dos" situation though. Dropping in code blocks that are hand written and aren't patch formatted obviously has to be acceptable too.

I think I'm just rebelling about line numbers in the headings, mostly. 🤔

Like, for both humans and ai... For humans reading it *un*tool-assisted, the context lines help a lot.

For ai... I basically never tell them line numbers; I tell them what thing to fix. (Also not literally with patch format, but if we have tooling on the review write side, might as well.)

I sorta like it! A few things I'd probably differ on a bit.

I think headings are for people (or at least definitely h2 is).

I think context lines should usually be involved. If we have tool assist, writing those isn't pita... And it makes the whole thing more easily applicable after triv changes

Really good rubrics in here. Maintainance costs matter and this writeup captures that well. Focusing on usability of the rubrics as a conversation tool is also 👌

Let's do it??

I'm not even convinced the format has to be all that structured. Taking clips of the source to comment on it (maybe with some advisory line info, diff/patch edge markings style) seems totally sufficient; sometimes even superior to this many-threads nonsense some web stuff does, imo.

A code review can be an artifact itself.

(A lot of the best code review and change management tools are already moving that way. Github is a noticeable aberration & it's the worse for it.)

What if a code review results in... Just a file?

Push it and share it wherever you want. Work offline. Win?

Who's working on #localfirst code review tools?

Online git hubs aren't going away, but there's no reason for them to have a strangleholds on code review, nor drag it online.

Tools that diff two local branches. And help stage a markdown doc that serves as the review. Who's building?

Admittedly this is still (probably, surely) insider trading on obscene steroids, rather than bids being causative to the violence.

But it's still a stronger correlation between blood and money than any sane society should tolerate.

I really thought the "assassination markets" hypothesis for why betting markers like this are Bad Actually was supposed to be hyperbolic and hypothetical. Rhetorical. Used in argument about why not to do the thing.

Welp we did the thing and it's not rhetorical now.

oh my bad there was another reason

👀

Yeah, bigly want this too.

A process that can generate lots of code just generates lots of demand for code review.

We need better code review tools. Or ways to intervene in ways that are better than after-the-fact review, as you're thinking here. (Or both.)

Comfort with unknown unknowns, and leaving some space for them in your ontologies and any of your accounting, is a cornerstone of sound reasoning.

EA is what you get when you say "well, suppose there aren't any unknown unknowns".

...Which is, again, ironic. If these people were at all serious about their own credos, it would be a community that has minimal convictions and updates rapidly based on evidence.

It's... not, though.

Again, some good ones.

But broadly: oof.

There's some nice ones, and there's a community that every once and a while churns out a novel way to hold a trolley problem.

But intensity of "convictions" basically correlates with how dangerously misguided one of them is. And there are a LOT of convictions floating around in those circles.

People who boldly do math based on low-evidence baysians, in favor of utilitarianism, roughly.

So, hypothetically nice people, and hypothetically smart people... But somehow without the sense to stop extrapolating when error bars get wider than real values, so actually they're borderline dangerous.

The future of software development is exactly as its past and present.

It's about collaboration with people to make right decisions.

When it was slow to write code, it was slow to accumulate technical debt. What is it about LLMs that won't result in accumulating technical debt even faster than before?

Ah, that's good to have clarified, because my train companions today -- who I gained after hooting out loud over this -- were inquiring why such objects as these weren't inhabiting the Forbidden Zone.

I went a little overboard with this and a little bit insane. moultano.wordpress.com/2026/02/22/t...

@why.bsky.team have you crossed the Dark Breakfast thresholds