If can put properly engineered intent in the prompt that is verifiable, it works wonders. Anything that can defaults to the llm doing its way, you're right, it just can't converge to good, not with proper constraints.
I’d be rather interested in a recommandation that don’t comes with de usuals pits of others solutions and comes with a the actual css code that will apply to the element displayed in autocomplete while editing the html / jsx.
No, he's right. Techies are cowards. Those poor but educated people in the slums of Shenzhen are reverse engineering Nvidia GPUs to find out how to add more RAM, so what the fuck are we doing to have less results?
> so what the fuck are we doing in our cushy lives?
Racking in money printed out of thin air by banks using a sleight of hand then forcing people to give us things in exchange for said printed money under threat of being bombed, invaded, and sanctioned
The hard truth is that as much as you think yourself as a "proper" gamer, this segment always has, always will, _not_ be the proper target segment. Don't forget that mobile gaming has more revenue than everything else… combined. They have a play on this, and as much expansive as it looks, it's mostly due to the hardware inflation, and compared to alternatives, it won't look bad at all. For the segments that matters.
I don't see a market of people who want to pay Valve $1,050 to play Steam games on a custom Linux machine with old hardware that won't support big name games that have kernel anti-cheat on them.
I really don't see the vision Valve is looking for here.
I like that we can write the story that Microsoft sold their software with the home computer on the idea of productivity at home while the actual incentive was entertainment, and valve ends up justifying buying gaming hardware with the incentive that it can do productivity.
To be fair, that one came from an editor not a physicist; the physicist wanted to call their book «the goddamn particle», and it got censored/editorialized to «the god particle».
I've heard that story and it doesn't ring true to me. It's not that aggravating to find. Try measuring a neutrino mass, which is still an open problem and looks as if it will remain so for a very long time.
> So I can find a bug, I can fix it, but I am not allowed to tell them how exactly I did it.
Pin pointing the issue is way more than valuable than code. If you wrote a fix, you have analyzed the bug. The value is there, not in the fix. Sharing your fine analysis is the maximized contribution. Code is an optional bonus at most.
'I applied this change to my local fork as a temporary workaround, in case it's useful to consider' is the way to express this.
In one memorable case, by presenting it as problem+tempfix and inviting discussion, the developer argued that I should focus on repairing the other software that was the cause of brokenness. I agreed with them, we mutually closed the issue, and my code was (correctly) discarded.
Code is a secondary and optional part of the feedback process. Yes, it can be a more precise language for conveying a problem report. No, it is not necessarily a boon. Code never carried significant intrinsic value — the motivation of the author to show up and interactively participate with the project that was infinitely more valuable than any one patch! — and now with AI, code carries negative intrinsic value, indicative of drive-by patches with no likelihood of future participation.
The most effective contribution I made this month to a project was to spend three weeks reproducing a bug and then informing them of the process to repro it themselves. They were head over heels grateful, not only because I bothered to write a bug report, but because I followed up a week later when I managed to create a second repro case of the exact same issue under wholly different circumstances. The issue is, at its core, a reasoning error about a protocol handshake-setup-command process across 2+ devices, and patching their code to fix it is meaningless compared to the value I provided by simply showing my work in tracking down the problem.
Pull requests are, these days, more often an expression of entitlement ('I deserve praise, be grateful for my code, comply with my designs, or else') than of free-time invested into the project ('Hi, we've been working together in various bug reports for a while, and I saw this problem and felt like it would be a fun side project to hack on') and so I wholly endorse their decision to refuse them.
exactly. a _proposed_ code fix is a good indicator where the problem is (analysis) but more often than not the actual maintainable and sustainable solution will look different.
a code owner may choose a very different way of fixing things, even for what looks like a trivial fix.
You're right, there is plenty of space for features that require AI to work but that are undistinguishable from "classical" feature. Better autocompletion is a proven one for example.
If can put properly engineered intent in the prompt that is verifiable, it works wonders. Anything that can defaults to the llm doing its way, you're right, it just can't converge to good, not with proper constraints.