I have enough admiration for him to be willing to hear the argument and have my mind changed, but they clearly have friends at YC and on the surface it doesn't look good.
The BBC’s arts coverage outright humbles the Times and has for decades. (Also better obituary writers IMO, but YMMV). It’s absolutely the BBC I would come to, to read about Hockney, not a Murdoch newspaper.
But inexpensive they are not.
Sam Woodhouse is a senior BBC journalist and that article includes footage from an outstanding BBC arts programme interview by another senior journalist, Katie Razzall.
Hopefully the BBC will interview one of their own greats, Melvyn Bragg, about him. Bragg and Hockney were friends for half a century.
The link you provided was not to the BBC's arts coverage. It was to a BBC News article, again written by a generalist. The BBC does great things with the arts. I have been listening to BBC on shortwave since before you were born, and know it very often excels in that area. But this is not that. You are comparing two different things.
not a Murdoch newspaper.
The New York Times is not a Murdoch paper. That you believe this shows you know very little about the New York Times.
But inexpensive they are not.
Reading the article you linked to costs precisely $0.00 (£0). Reading the article from the Times costs money. Again, you are conflating the BBC as a whole with the BBC News web site.
Hopefully
Yes, hopefully. But that's not what we're discussing here. We're discussing the merits of the link you posted versus the link that was submitted.
In the eight days you have been on HN, your comment history shows that you have very strong opinions about the press. Opinions that are often equally wrong. That topic has been almost your entire comment history. I recommend you read and listen to other people more.
Oh, I made a tiredness error re: the NY Times, yes, sorry. (I have some memory issues, rather than being an idiot; the Times of London is Murdoch). In what was otherwise a simple and good-natured defence of the BBC on a topic they are quite good at.
For reference, I did not post the BBC link. That was someone else, wasn't it?
What the heck is the rest of this personal character demolition you are doing?
(Absolutely certain I haven't mostly been talking about the press, as it goes.)
Thanks for, er, the invasively rude "welcome". I am actually not that new to HN at all, so much as restarting after a long break from it. But you have fully reminded me why I put an old account beyond my own use so I couldn't continue to use it.
The reason I finally decided to come back was because I saw enough good discussions about local LLMs, that I am using to teach myself some AI stuff, that is the best place to quickly ask and to find people who can explain things without me bothering developers unnecessarily.
HN has always been a good place to ask the side questions you know it's impolite to ask on a Github issue!
This was a tiredness/bad short term memory error because I am British and the comment I referred to just said “the Times”. I do in fact know that the NYT is not Murdoch; the Times (of London) is.
My declining brain jumped the tracks.
FWIW my comment still seems pretty accurate even applied to the NYT. The NYT is without a doubt the better publication to share the short moniker, don’t get me wrong. For all its many contemporary faults, it’s the world’s greatest newspaper. But the BBC’s arts coverage puts it in the shade.
LLMs routinely fail at our business specifics: Local tax regulations, particularities of the accounting process, specifics of our ledger implementations.
This is domain expertise - software engineers are not needed for that. Ofc often senior sws are expert in it, but they aren't necessary.
Traditionally its been useful for frictionless production to have engineers to be able to do maybe 90% of their work without consulting the business experts but this is the whole crux of the moment TFA discusses - "tradition" is over.
In this new world its now the job of a senior engineer not to have this domain expertise themselves, but to know how to ensure the agents have it, or can acquire it and it be verifiably correct.
Senior engineers who hang on to the idea that their advanced business domain expertise makes them safe will soon be as dead in the water as juniors who haven't pivoted.
>This is domain expertise - software engineers are not needed for that. Ofc often senior sws are expert in it, but they aren't necessary.
Our engineers frequently need to be on the loop with product and stakeholders: Due to real world messiness, many times the only true answer to "how does this currently work" is in the code. Enabling product and stakeholders to fetch that knowledge would be a giant time saver, so we've experimented with LLMs.
I recommend you try this exercise: place a non technical person in front of a complex business' codebase with an agent in between and get them to extract or shape business knowledge through it.
I'm serious, it's not a rethorical device, genuinely do try with a coworker or a friend. It will teach you a lot seeing how the way they approach the problem is different to yours.
> This is domain expertise - software engineers are not needed for that.
I want to work with the business domain experts you work with. The ones I’ve worked with are experts in their domain, not modeling that domain in software.
Left to their own devices with Claude Code, they produce some great POCs. Then those POCs buckle under their own weight they pile on contradicting requirements and have opus spinning to fix bugs.
Maybe the models will get good enough to solve for this, but they’re not there yet.
As in my reply to the sibling comment, I am not disputing that engineer expertise remains important; I'm saying the nature of it is now different and will continue to rapidly change in its place in the business stack.
It's effectively a pause. In a project the size of CPython, and a subproject the complexity of a JIT, you can't continue work on a separate branch/repo without guaranteeing that there will be a massive amount of (both textual and semantic) merge conflicts down the road.
But with a project running for as long as they are, is it not already clear what they are going for? Is the architecture not settled?
If it is, is it not documented somewhere? Maybe as a formal PEP?
If it is not and it is still in heavy experimentation phase (which is fine), it should not be part of the mainline CPython no matter how much more effort it is for the team to experiment with.
That works, until that inevitable one merge that's harder to fix and takes longer, which in my experience then tends to snowball until it's basically the very merge hell you were trying to avoid. Can't say I've ever had a great experience with long lived feature branches. I can't imagine what it would even look like trying to do this on such a massive project and such an overarching feature.
I appreciate Cloudflare's loud positive proclamation here wrt the OS future; I know scepticism is warranted with some takeovers but although there might be a trend towards Cloudflare fit over the long term that's very different from closing down or abandonment so this generally seems positive to me - best wishes to all parties.
Thanks for this, it looks interesting - how does it relate to your commercial service (upilote)? I ask so I can better understand what it offers.
I interpreted it as follows:
upilote are maybe a competitor to say loveable et al and as part of your marketing/community outreach you supply an open-source self-hostable (llm endpoint excepted) version of your service?
upilote (mellosouls): your second reading is correct.
This is not a Lovable competitor, and it's not all of upilote.
upilote is the product: chat → agent builds → live preview.
This repo is just the infrastructure layer underneath it that we extracted and open-sourced under MIT. It handles one container per project, preview URLs, running agents, sleeping when idle, waking on request, persistence, and recovery after reboots.
For us, it simplified a lot of things. Instead of managing all that logic ourselves, it became: submit a task and stream events back.
reply