There's an old joke floating around if anyone remembers where it's from:
A tech enthusiast has the latest and greatest smartphones, voice assistants, and everything else cool and flashy. A programmer has a single inkjet printer from the 90s, and they keep a shotgun by their bedside in case it makes a noise.
I always joke with people that I hate software in anything but a traditional computers _because_ I'm a software engineer. I want the car with the fewest smart features, a normal door bell, a non-smart washing machine.
Software sucks a lot of the time and it often gets in the way, at least the way it's deployed over the last decade. Very few things in my home should connect to the internet. My phone and computers. Begrudgingly my TV now.
Also, those things that connect to the internet but don't let you have control? They get EOL'd, despite having paid a premium for them. I've never had a stove from this century and they all work fine, because why the hell wouldn't they?
Quitting work years ago helped, even though I still enjoyed software development. I had intended to instead work on my own investments, but I stopped that after I figured out money is a joyless and meaningless motivator.
Mostly just saying no to helping anyone with computer problems. Fortunately changed from Windows 7 to Linux, so I can be mostly honest when I tell people I don't understand their laptop problems.
Said no to helping family with with any printer issues after ~2005. I often print stuff, but I use the printer at my local library or printshop.
I still occasionally dabble, but only for those people I dearly love. I'm still very good at tech support, I just don't do it.
I've got my tech frustration level down to about the background radiation level (as politics or taxes).
Maybe 3 decades ago people had excuses, but the latest decade of cookie abuses have been designed by people who not only knew better but who took that better world into account as they buried it away from the general public. The fact that half a million developers think CORS is a server security measure isn't an accident.
I'm not sure how other people are using LLMs for instrumentation, but IMO the layer you want running in prod is very different from what you want running for a one-off test. E.g., I have some code floating around which burns a pinned core on increasing a counter, with a little wrapper code around grabbing real timestamps at the beginning and end of a session and converting between the two units of time. It's helpful when microbenchmarking a very small unit of code as it actually behaves in a larger program (not perfect -- obviously tweaks the icache and pipeline behavior at a minimum -- but no measurement has zero tradeoffs, and you're always choosing which set of tradeoffs you prefer). An LLM can quickly instrument the call path I care about while I study this or that intervention. The ability to bang out a large amount of throwaway code is delightful.
I know you're not the culprit, but it's annoying to see crap like this (highly invasive tracking, ostensibly for slightly more efficient tax collection), when far cheaper, better efforts (like Rhode Island's attempt to add tolls for just semis -- 98-99% of their freeway maintenance costs) are killed before they have a chance to prove themselves.
FWIW, I've seen the flip-side as well; solid coding patterns are easy for a person (or an LLM) to copy. To abuse the analogy a bit, your gardeners are happy copying whatever happens to be there, bad code will dominate that process unless actively removed, and the exponential nature of that arrangement favours removing trash code (weeds) early, much earlier than you might otherwise think.
That seems fixable. When people include this JS garbage, have a header/title/etc stating that this is Google's professional opinion. Bake it into a library offering enough other features that a large number of people are inclined to use it.
- The big problem is that malicious ads are being displayed without appropriate attribution
- Add that attribution -- blame Google (or, supposing the ads are good, credit Google; a good header goes a long way toward swaying people's opinions)
- But it doesn't matter if a single website appropriately attributes Google's highest/lowest-quality ads. The last step (speculative and hand-wavy) is to incorporate that behaviour in some sort of software more people want to use. If you're fighting alone then you'll lose. If you can convince more people that appropriately crediting Google's advertising successes and blaming their malicious failures is advantageous, you'll (by definition) have more traction in the anti-megacorp-endorsed scams and other life-altering consequences.
Ad viewers are about as empowered as the cow the goes into your cheeseburger. No agency, and no communication mechanism to the rancher’s actual customer.
These companies that abstain from adsense and it’s revenue are WWW vegans.
The second you load JS onto your page, you lose that ability, you know that, right? the scammy ads aren't limited to that tiny little box you designate for ads. Advertisers work around that limitation pretty easily, and you should also probably read AdSense terms of service before doing too much to blame google. Some of the language will surprise you.
hmm thought this was about adwords JS 'intelligently' reading page contents, and when it finds such attribution with some special tags, filters out certain ads...
Assuming the LLM never got anything wrong or otherwise had to be re-prompted, that means your devs were reviewing 130 SLOC per hour, on what was described as moderately greenfield (examining new implementations rather than comparing to old historical accidents).
How?
I don't want to sound flippant, but if the point is to add human thought to the mix, that's a high review rate even when examining small tweaks to an existing, working product, even with substantial AI help to pre-filter major gotchas before you bother spending a lot of human effort on the review. That's only 20-30wpm, but a review isn't just scanning or reading code, especially if you're trying to figure out how a new system which doesn't run yet will fit together.
The fatigue aspect matters too, but another important point I was trying to get across is that not all reviews are created equally. In a working, well tested, properly factored system, with a high quality PR, I can do a cursory, local analysis of the new code and be very confident that it works. AI code I've seen is ... not that. I wouldn't be comfortable in that review without manually checking preconditions and postconditions, defining invariants, examining lifetimes, and a host of other activities. Moreover, for a greenfield replacement of lots of SLOC, I'd expect that most of the code for the early PRs can't even meaningfully run or do anything important, making any sort of broader architectural analysis impossible.
I could see a world potentially where they came up with a magic prompt allowing each proposed PR to be cohesive, shippable, well factored, and everything else you need to be able to actually review it at a higher level and be comfortable with the results, but I'm skeptical. That's a major innovation if they managed to do so even as a one-off, and that wasn't the thing they highlighted when talking about the project.
Is that actually a high review rate? Especially if you know the language and domain. Sure, initially there's a learning curve for a new codebase structure, but lots of lines will also be trivial and many changes might also be similar to each other.
For small separate changes in isolation then maybe it's ok? But not for whole days 8 hours each.
But then you need to watch for bugs coming from interaction with previous changes and in 700k loc that might be nontrivial. How do you know which states are reachable and which are not? That takes time.
It only takes a botched condition here (forgot a "not"? swapped "and"/"or"?), a swapped variable name there, code that looks ok, but isn't.
I've had good luck disabling the internet when I need my work computer to run faster. Those "security" checks are optional, and it'll let you work offline.
If just logging filesystem interactions and whatnot for future upload is also slow then you're hosed, but at one place I worked every application too an extra several seconds to start up for some sort of remote program inspection, which is fine till the application is git, grep, or cd.
whisper.cpp is awesome but even it just can't process a three-hour vid in seconds. What do you suggest should I'd be doing? Clench my butt-cheeks and stare intently into its work log, hoping it would finish faster? Ah, I know, you'd be like: "messing with your Emacs config", right? Because of course, the tale of any Emacs user is that they have no free time, no pets, no family - it all is occupied by Emacs.
My doctor's privacy policy is a bit more abusive than OpenAI's. It exists mostly because of a $%^&&* legal framework rather than malice, and I've grown accustomed to "if I don't want to die then I sign away these rights." Despite my having theoretically signed my soul away, my doctor isn't selling personal information to my exes or to life insurance companies (though they could in the US; that extremely personal information is no longer mine). OpenAI is engaging in the "technically legal maybe we'll see but obviously unintended" side of this transaction, and maybe that works out for them, but I wouldn't personally choose to be a shill for "it's unreasonble to expect somebody with 'legal' permission to do something other than the maximum 'legally' permitted" if I were in your shoes.
A tech enthusiast has the latest and greatest smartphones, voice assistants, and everything else cool and flashy. A programmer has a single inkjet printer from the 90s, and they keep a shotgun by their bedside in case it makes a noise.
reply