> Trust me when I say that in the hands of someone who doesn't have your experience, the LLMs would not be getting the results you get.

https://code.ffmpeg.org/FFmpeg/FFmpeg/issues/23049

So there's this 11 year old issue in a forgotten ffmpeg plugin and I fixed it with deepseek by putting it into a self-testing loop. Probably would have taken me a few weeks to even understand the initial code to begin with. I haven't done C work in a long ass time and have zero knowledge of even what sub pixel sampling means.

With DS4 took me a few days and a couple of dollars. And by few days I mean I checked on it a few minutes every half hour or so a few times.

I don't understand the code it wrote but it's been in production for a while now and no issues so it's good. Ended up speeding up our video processing pipeline by 20-30%.

So while I do agree that it is cool you were able to do this, I‘ll say:

Sending in the patches but refusing to take responsibility for them is a surefire way to contribute to maintainer burnout. Please don’t do this. Either commit to fixing something and driving the PR to merge, or abstain from it entirely.

The bottleneck isn’t the speed of coding, and what you’re doing here is actively worsening the situation.

idk if it's really worsening, someone who has the same issue can apply the patch. I understand why they rejected it but also I'm not willing to learn everything that DS4 did there since I don't plan on working on ffmpeg filters and the knowledge is pretty much useless to me outside this patch. Too much time commitment for.. fixing a filter no one really cared about for 11 years.

But you can see how the parent's comment doesn't really hold, I was able to achieve this while not knowing anything other than what I need fixed and making the LLM test itself towards that goal.

I used to do this too, but I learned that will give you inconsistent dosage as the pills aren't guaranteed to have the active ingredient spread uniformly.

If the pill has a score line, it's designed for halving (or quartering, if it has two.) Otherwise, no guarantees.

I don't think inference is subsidized, it's the training. So what happens is, there's no new models anymore or are released slower.

API inference is probably not subsidized. Coding plans absolutely are.

Isn't there such a thing as low hanging fruit?

Aren't we already approaching theoretical physical limits? We're at 2nm

(1) Yes.

(2) Are you saying that you think we're at the limits of computing in general, or that specific technology?

We know, for example, that a human brain level intelligence is possible to run on a human brain. We are nowhere near that. And actually that's not even a physical limit necessarily.

But that is...not a low hanging fruit.

> We are nowhere near that.

Nowhere?

Leaving aside the discussion on LLMs intelligence vs human intelligence, on a purely energy consumption level we are definitely and without any possible questioning nowhere near that indeed.

we are not at 2nm, we just call it that.

still need to feed the livestock multiple times a day, chop wood, fix stuff around the house

I think the difference is they're completable jobs. You work until it's done. At least for the day.

You aren't chopping wood everyday. Hopefully that's been prepared.

Feeding yes.

Not sure I get it. The model you're improving is local? If so how do you even calculate cost compared to an API

Open source models.

wmo routes requests between frontier models and open source models that continuously train using Tinker. As the smaller models improve, more traffic gets routed to them.

Calculating cost is just tokens in/out.

What are the costs to train and use the Tinker models?

Expensive, in the thousands. We have our own infra in house and are working on bringing these costs down

But in the thousands can pencil out if you're saying tens of thousands over calling the frontier models, no?

Exactly

Or Thunderbird is much older and has a lot more users

Blender is actually much, much older than Thunderbird.

wow, did not expect blender to be 32 years old, thanks for correcting me.

but still, they were open sourced about 1 year apart. I still think having a bigger user base is a good reason for the difference

That's relevant to why it historically had bizarre UX issues, like ctrl+s being the shortcut to erase the scene and start a new one: it predated most of those conventions, and has its own UI tooling. It's also always been designed to use three mouse buttons, coming from the Unix world, which used to be problematic when not everyone had a mouse with a clicky scroll wheel.

It's come an absurdly long way since I first dabbled with it in the early 2000s, and has gone from a niche FOSS tool to something widely used in its field.

Nowadays, Blender is an example of masterful UX for a professional tool. Immediately responsive, information dense UI with keyboard shortcuts for absolutely everything. Actions are composable, like with vim: something like "ex5" will extrude five units on the x axis.

UI standardization, CUA, X11, Motif date from the late 80s.

Right, but those are for simple tasks. Much like vi or emacs, the keybindings are esoteric and historical but so much of what makes the tools great is reliant on on said historical and esoteric behaviour that changing any of it becomes an exercises in futility

Unlees you invest thousands your local ai won't even come close to the cheap cloud llms. Local is only worth it if you care about privacy or have a legitimate usage for the hardware otherwise. Money wise it isn't worth it

I think you bring up a good point about privacy. Companies probably should not be handing over intellectual property to cloud AI third party vendors. Perhaps all of that should stay on-prem and then the cloud vendors could be used to fill in the gaps.

Enterprises running in public clouds have Zero Data Retention policies with the vendor. Routing the ai spend through Azure or AWS usually bring these policies along with it, ie enterprise data and useage is not ingested to retrain the model.

the qwen 27b is quite good for doing a mvp

I mean, if you're using one of the $200/month plans, you'd recoup the cost in a year or two.

You're not running an Opus 4.8/GPT 5.6 tier model on $5k of hardware at a useful Tok/s

that's how it works in my country, though there are no denies, almost 90% of transactions over 20-30$ will require I go into my bank app and confirm it.

rarely a big transaction will go through without 2FA but I've never had a transaction declined outright without first asking me to 2FA from the bank app

since pi is built to modify itself, isn't it better to use a language like typescript where LLMs have a LOT of training data?

a harness doesn't do any computations by itself so what benefit is using a compiled language?

i find LLMs generally play better with compiled languages actually, they do great with rust. you can think of it almost as analogous to a harness.

The more structure the better. Provides strong guardrails.

I’ve had great experience with Elixir and the new compiler combined with Ash.

They play better with statically typed languages, not compiled ones in particular. Rust's typing is stricter than Typescript though so that probably helps.