I think "working product" is doing a lot of heavy lifting for you here.
I think anyone who has done serious product development wouldn't be so flippant and dismissive about the difficulties of even conveying WHAT to build, let along getting the right balance of quality, timeliness, and actual functionality.
The price hikes are going to be absolutely devastating.
Imagine oracle level price acuity along with 0 competition and utter dependence. This is the future the AI labs are drooling for. You will be charged based on the value it delivers. People will be start making trade offs on if hiring humans would be cheaper than AI, etc.
There's no way they're going to leave all that money on the table when there is all that investment to pay back.
Paint VOCs sounds fine, until it's done at industrial scale, and it's also your neighbor, and also all the children in the neighborhood have asthma, and also healthcare is a lot more expensive...
This list isn't things you "cant do in california" but "polluting things you can't do in highly populated cities".
I'm not sure what the conclusion here is other than health is not important.
Most of this stuff could be done in compliance with the laws but it’s just cheaper to do it somewhere else where you allowed to vent poison in the air rather than having to filter it out.
Are they only banned in the cities, or are they banned in the state, which -- even in California, should have rural areas far enough away from cities to be tenable?
It's an interesting conundrum though, because in many cases, the cities could not exist without the things that are being banned in the cities. It's a curious goal of populations to centralize, then ostracize all the things that enabled that centralization
Everywhere in California that isn't a giant population center is growing food for the rest of the country, or is a mountain where these things can't be built anyway.
They're probably "not banned" only in the "basically lying" sense that they per rule won't approve you in certain cities and if you do happen to be rural the process is hostile and expensive enough that it's not worth it for the value such a facility would generate. That's how that sort of stuff is in my state.
That's the thing, often when people say stuff like "its banned" what they really mean is:
- the cost of mitigating the human health risk is too high
- competitors in low-environmental regulation places don't pay for those costs
- ongoing verification is expensive
I mean, let's face it, "self-regulation" of industries isn't really working that great. And for things that are health hazards that are basically borne by someone else, why should a local government make it easy to cheat and lie about this stuff?
The people arguing against this seem to assume that their right to have a business, make a profit, whatever, is a self-evident Good Thing, and rarely provide any additional arguments beyond "but the jobs". If they were at the VERY LEAST saying "we can make X safe" then maybe it'd be interesting. But as it is, the argument is basically asking us to mortgage the health and safety.
Nobody here wants to just let big business do whatever and turn the rivers weird colors again or go back to smog but it's very clear that the current regulatory system is not suitable and is hurting us.
It boggles the mind that someone could honestly (by which I mean dishonestly and malice are far simpler explanations) step into this conversation and be like "no, this is all fine and well, god forbid someone start spraying cars in a shop in the desert without jumping through all most of the same expensive hoops that make it not worth it down town (and would make it doubly not worth it out in the desert).
And it's not just autobody work. There's all manner of necessary economic activity that's being kept out or made artificially expensive in this manner.
I've used chatgpt-shell, but I have since turned my LLM usage to gptel inside org-mode buffers. Every day I use org-roam-dailies-goto-today to make a new file and turn on gptel (the use of org-roam-dailies is 100% optional). Then I do my interactions with gptel in here, using top level bullets and setting topics to limit context.
I have 10 months of chats, and now I can analyze them. I even had claude code write me up a program do that: https://github.com/ryanobjc/dailies-analyzer - the use of gptel-mode allows me to know which parts of the file are LLM output and which I typed in, via a header in the file.
Keeping your own data as plain text has huge benefits. Having all my chats persistent is good. It's all private. I could even store these chats into a file.gpg and emacs will auto encrypt-decrypt it. Gptel and the LLM only gets the text straight out of emacs, and knows nothing about the encryption.
I found this better than the 'shell' type packages, since they don't always keep context, and are ultimately less flexible than a file as an interaction buffer. I described how I have this set up here: https://gist.github.com/ryanobjc/39a082563a39ba0ef9ceda40409...
All of this setup is 100% portable across every LLM backend gptel supports, which is basically all of them, including local models. With local models I could have a fully private and offline AI experience, which quality based on how much model I can run.
> Keeping your own data as plain text has huge benefits. Having all my chats persistent is good. It's all private.
While agent-shell is much newer than chatgpt-shell, it likely has richer interaction by now (specially the compose interface). I'm veering off topic here... agent-shell now saves all interactions to project/.agent-shell/transcripts as Markdown files. We can totally do org too, but I just haven't gotten to it.
Until you realize you're just begging and coaxing a human to better beg and coax a machine to output working code - when you could just beg and coax the machine yourself.
The "just generate go code automatically then check it in" is a massive miswart from the language, and makes perfect sense because that pathological pattern is central to how google3 works.
A ton of google3 is generated, like output from javascript compilers, protobuf serialization/deserialization code, python/C++ wrappers, etc.
So its an established Google standard, which has tons of help from their CI/CD systems.
For everyone else, keeping checked-in auto-generated code is a continuous toil and maintenance burden. The Google go developers don't see it that way of course, because they are biased due to their google3 experience. Ditto monorepos. Ditto centralized package authorities for even private modules (my least fave feature of Go).
> For everyone else, keeping checked-in auto-generated code is a continuous toil and maintenance burden. The Google go developers don't see it that way of course, because they are biased due to their google3 experience.
The golang/go repo itself has various checked-in generated repo
It's kind of weird how you downplay tardive dyskinesia, as if it was kind of a no big deal, whatever kind of thing. Would you accept having tardive dyskinesia induced by a drug?
Is that really your position?
Your other words seem fine, but that is a standout sentence!
regarding #2: "Automate the dumb/boring stuff", I always think of the big short when Michael Burry said "yes I read all the boring spreadsheets, and I now have a contrary position". And ended up being RIGHT.
For example, I believe writing unit tests is way too important to be fully relegated to the most junior devs, or even LLM generation! In other fields, "test engineer" is an incredibly prestigious position to have, for example "lead test engineer, Space X/ Nasa/etc" -- that ain't a slouch job, you are literally responsible for some of the most important validation and engineering work done at the company.
So I do question the notion that we can offload the "simple" stuff and just move on with life. It hasn't really fully worked well in all fields, for example have we really outsourced the boring stuff like manufacturing and made things way better? The best companies making the best things do typically vertically integrate.
I think anyone who has done serious product development wouldn't be so flippant and dismissive about the difficulties of even conveying WHAT to build, let along getting the right balance of quality, timeliness, and actual functionality.
reply