now sometimes that's 4 hours, but I've had plenty of times where I'm "racing" people using LLMs and I basically get the coding done before them. Once I debugged an issue before the robot was done `ls`-ing the codebase!

The shape of the problem is super important in considering the results here

You have the upper hand with familiarity of the code base. Any "domain expert" also necessarily has a head start knowing which parts of a bespoke complex system need adjustment when making changes.

On the other hand, a highly skilled worker who just joined the team won't have any of that tribal knowledge. There is a significant lag time getting ramped up, no matter how intelligent they are due to sheer scale (and complexity doesn't help).

A general purpose model is more like the latter than the former. It would be interesting to compare how a model fine tuned on the specific shape of your code base and problem domain performs.

People usually talk about how they're better than LLMs in the domains they're experts and with known codebases.

What about all the other, large amounts of cases? Don't you ever face situations in which an LLM can greatly help (and outrace) you?

Yeah totally, for unknown codebases it can help kick you off in the right direction (though it can send you down a totally wrong path as well... projects with good docs tend to be ones where I've found LLMs be worse at their job on this ironically).

But well.. when working with coworkers on known projects it's a different story, right?

My stance is these tools are, of course, useful, but humans can most definitely be faster than the current iteration of these tools in a good number of tasks, and some form of debugging tasks are like that for me. The ones I've tried have been too prone to meandering and trying too many "top results on Google"-style fixes.

But hey maybe I'm just holding it wrong! Just seems like some of my coworkers are too

While in some sense it's interesting to store the prompts people might use, I feel like that might only accentuate the "try to tweak prompts over and over to pray for the result you want"-style workflows that I am seeing so many people around me work in.

People need to remember how good it feels to do precise work when the time comes!

I'm a nushell user but like... job control in nushell is pretty miserable still unfortunately.

Nushell is definitely my fav of the set (xonsh is a neat experiment but ultimately is missing pipeline programming that nushell gives....), and I write personal shell scripts for myself mostly in nu.

Aside: for shell scripts, my preference is something like nu, then python + stdlib, giving me argparser etc, then just zsh/bash/whatever. Seriously annoying how POSIX shells do not give good argument parsing, tho I get it's a hard problem

Is there any good faith read of this that people can lend credence to? The one I could maybe come up with (with their mention of stability) is "we want OSes derived from AOSP to be stable, instead of following main too closely". They mention third party devs working off of stable too... so maybe they're like "instead of dealing with outside contributors messing around with our 'wip' stuff, we'll sign up for integration work".

Almost all device run on the initial android release (QPR0), and never shipped any of quarterly updates. Even less so using _main_ as a baseline so that point is moot.

With android 16 introducing "mid releases" (QPR2), they expect OEMs to start shipping those as well, QCOM already has a QPR2 BSP release, and Samsung is expected to release QPR2 based builds soon.

As far as contributions go, google usually wanted patches to apply to main, I don't think that ever changed. And even there now that AOSP development is fully closed, it's even easier as partners will likely just upload patches against internal main instead. Less integration work there as well.

There really isn't a good explanation as to why they want to do move code drop cadence, other than they can and want to avoid wasting time releasing QPR1/3 that no OEM ever shipped (expect Pixels that is)

Android's foundation has been mostly stable for years now, with fairly minor changes between releases. So I guess they just don't want to deal with too many versions to document and support, given that device vendors are generally awful.

Also for a long time they were doing yearly (or longer) release, afaiu it's only the past two years that they switched to quarterly (with the QPR release).

So the source code will be released in a kind of FreeBSD releases? These pieces work together, base things off them, don't mess with (or even see) any WIP stuff.

In other words, the result is still open, but the development process is not.

I don't work on Android, but I suspect it's a whole lot less work for both confidentiality and maintenance to not have to worry about daily/weekly OSS releases. That's probably worth more to the decisionmakers than the value of random contributions from people who aren't already inside the partner tent.

[edit] based on the other comments, I surmise that public pushes were already infrequent.

> the result is still open, but the development process is not.

Is the source code available at all times? This is a genuine question, I don't know right now.

Cost, I assume. It’s expensive to do releases, both in CI and release operations costs.

Maybe less fragmentation?

Sure. Development at Google is glacially slow because nobody does any work, and so they're only publishing releases bi-annually because there aren't enough substantive changes to make quarterly releases seem important. This will also allow the teams to move to biannual OKRs instead of quarterly, which lets ICs and line managers do half as much work while giving executives justification for why they need twice as much headcount.

When it comes to large bureaucracies, always assume laziness over malice or strategic competence.

So is this similar to the DCMA in the US, where there's a lot of iffyness about abuse and actually knowing that someone is actually a rights holder?

At least with DMCA you so get a notice and you can somewhat challenge it. With Italy's Piracy Shield you have no notice and there's no public record of which IPs/websited have been blocked, so it's hard to even challenge it in court.

Nothing prevents anyone from sending in a fake notice anonymously, which will still force any provider to take down your content until challenged.

Not really, this is at a World level. Italy wants to ban an IP globally in 30 minutes.

DMCA take downs are domain specific with one provider. So scale is completely different here.

I mean markdown existed, but before that there's like... whatever format phpbb and friends let you use for forum posts right? There was stuff that was text-y.

But perhaps it was the first big format that was followed a Unix-y "here's a CLI tool to go to HTML from this" thing, instead of some php script

Bbcode. But that required tags like [b] and [i] so was just HTML light.

I feel like even outside of AI translation, formalization not capturing the spirit of what the informal description was provided is always a risk.

This is also a big risk when trying to prove code correctness: "prove this algo works" means you gotta define "works" along certain axes, and if you're very unlucky you might have a proof that exploits the uncertainty around a certain axis.

We have also worked via Renovate recently and are enjoying it. The dashboard is particularly nice for onboarding repos with lots of old deps (checkmark -> make a PR is a nice flow that semi-automates things).

Dependabot integrates decently well with Github of course but so far renovate has worked well for us.

When distros figure out how I can test my software with a dep at version A and the same dep at version B in a straightforward way, then we can talk.

NPM forcing a human to click a button on release would have solved a lot of this stuff. So would have many other mitigations.

A thing I've experienced is people buying a bigger fridge, and then just leaving it when they move out because they're moving to a place with a fridge that is fine (for example, moving in with someone who has a nice fridge). Everyone walks away from that basically fine.

Especially the landlord who got a free fridge updgrade.