I don't know, I thought the design looked really nice.

How did you use it? OpenRouter, or provider directly?

I'm guessing downvoted because OpenRouter was mentioned in the note (which may not have been there originally), but aside from that this is a perfectly legitimate question. In order to reproduce we need to know how. Was it a coding agent like opencode, an IDE, or something else?

OpenCode + Direct Deepseek API.

If they give me the resulting model in the end, they can train on my data all they want. Hell, I'll send them more of it.

Anthropic's and OpenAI's costs seem to include a fairly ok margin, from the very fourth hand info I have.

In total, how many hands do you have?

Enough to reach the bottom of the rabbit hole.

Those aren't their hands.

I wish projects would have a short "what this is" paragraph. Right now, the front page is a forum, "docs" says the documentation is maintained by users and links to the changelog, and there's nothing anywhere that tells me what this project does.

Agreed the website is poorly organized, but if you click About, you get that paragraph:

https://tvheadend.org/p/about

> Tvheadend is the leading TV streaming server and recorder for Linux supporting ATSC, DVB-C/C2, DVB-S/S2, DVB-T/T2, ISDB-T, IPTV, SAT>IP and HDHomeRun input sources. Tvheadend outputs HTTP (VLC, MPlayer), HTSP (Kodi, Movian) and SAT>IP streams, and can ingest multiple Electronic Program Guide (EPG) formats including over-the-air (OTA) broadcast data for DVB and ATSC, and OpenTV extensions like XMLTV and PyXML.

So it's a DVR project in the vein of TiVo and Windows Media Center.

Streaming, not DVR. Think TV to IP

It does include a fairly full-featured DVR system - I used to use it with Kodi to record shows off DVB-T.

Oh, I must be misremembering. I also used to use it with XBMC/Kodi, but I recalled kodi itself being the dvr element. Or maybe I’m even conflating it with plex. It has been a minute :D

Ah nice, thank you.

It's not though, is it? That's Lesotho, Eswatini borders Mozambique.

I think https://privacy.com is the best solution we can have with the current system.

I don't know about the GP, but my workflow is similar to theirs, but I aim to ship low thousands of lines per week. The fewer the better. I even tell the agent to only write high SNR tests, otherwise it just adds useless "make sure this function returns this thing we hardcoded".

I usually succeed, BTW. I spend a lot of time planning, but usually each PR is a few hundred lines, and fairly easily reviewable.

I mostly work with Python backends, though these days it might be any language (Ruby, Go, TS).

Hell, I use the (closed-source) app Smart Audiobook Player and I wanted Audiobookshelf integration. I asked Claude, it decompiled the app, added the extra code, recompiled the APK and it works perfectly, syncing my book's progress with the server.

Truly magical, it would have taken me months.

That’s super cool.

If no post planned, please consider - that’s very “an app is a home cooked meal”, and I love it.

I could write something, but it would be "I told Claude to do this and it did, I'm happy", there isn't really much more detail to write about. What would you like to see?

I’ve seen a few posts just like that ^_^

It’s mostly your original story of motivation, in brief prose, that does the heavy lifting of a satisfying post,

followed by exactly what spec and names of tools you used, mundane as they may feel,

your exact prompt(s) (because this is of technical interest in and of itself),

and screenshots of excerpts/link to output.

Things that stood out to you along the way would also stand out to others.

The comment alone will probably be the most intriguing one I read all day.

Huh, sure, I'll write something up today! You can subscribe to https://stavros.io to get an email (there's a form under each article).

But why doesn't Gitea add it? It already has everything else, why are these forges always Github clones instead of doing more?

My best guess is lack of resources and that they want to focus on the well known PR workflow instead of trying new things out of the gate. It's exactly that, it's a proven github workflow for better or for worse that most people are familiar with.

Well, if you are building one you generally want to support the 99% workflow, not the experimental one.

What part of gerrit is so different? Stacked PR’s work fine right (not in github, as a concept)

The number one thing that gerrit does that is important is keep comments tied to the code between commits.

By which I mean the discussion doesn't get broken between changes, and it makes it far more trivial to iterate on things in the review without breaking the discussion. And for the reviewer to see what's changed between revisions at the specific comment point they're looking at. And then have a nice clean commit at the end instead of some dogs breakfast of merge commit with revision commits shoved in it.

How does that work? If the code the comment applies is to is changed, does it expand the range? Or try to relocate it or something? Or it just doesn’t try at all, and it just applies a comment to a certain change/diff section?

It does (hand waving) things to keep the comment in place. It doesn't always get it 100% right, but it's pretty good.

But more importantly, Gerrit has a "Change-Id" it adds to the git commit which is independent of the git hash, so it can track changes independent on the "logical" commit separate from the physical commit.

It also is able because of this to show you what changed for a given commented section between those commits. Allowing you to properly review the changes.

GitHub just acts like a dumbass and throws away comments or threads if the original commit is rewritten. And so forces you into this garbage workflow of endless "commit to address review comments" or "new version" commits, which then have to be either manually rewritten before merge, turned into a (garbage) merge commit, or squashed down into one commit.

There's two reasons.

1. Gerrit's approach requires a stable Change-Id in the commits. So it doesn't just work out of box with stock git. It requires that the submitter's git configuration and the repository be set up to support this. (Note that JJ supports this out of the box)

2. Cargo cult. We have a whole generation of software developers who grew up in this generation, love GitHub, and have never known anything else. The "PR" approach is considered orthodox. Unless they went and worked at a Google or somewhere like that, they've probably never been exposed to alternative processes.