The solution to the first two is reuse. With enough energy, some form of recycling of becomes feasible for pretty much anything. No oil? Just make plastic from atmospheric CO2!
Is it a solution if the masses refuse to trade cheap convenience for more expensive and burdensome products/processes? Theoretically yes, but realistically no.
Woods Hole Oceanographic Institute says that dispersants caused a drastic reduction in surface volatiles, allowing the cleanup crew to work longer and more efficiently.
> The model showed that, without dispersants, the atmospheric concentration of benzene would have been about 6,000 times higher. Benzene concentrations in the air two meters above the sea surface would have been 13 times higher than the levels considered acceptable to breathe during a 10-hour working day or a 40-hour work week, based on guidelines by the National Institute for Occupational Safety and Health (NIOSH). However, the model showed that with the dispersant injection, atmospheric benzene concentrations were typically about 500 times lower than acceptable NIOSH levels.
I'd also highlight a third option (really a sub-option of #2) which is competition within the community. One's hobby might be shipping the fastest (such as in cracking communities), and I could very much see this disrupted in today's world.
> From my perspective, it seems like most of the progress being made is towards bringing about a sort of techno-feudalism and environmental collapse. Maybe a little bit less progress would actually benefit humanity?
I'd argue you're conflating two independent axis: technological progress and societal inequality.
AI is useful today and is getting more powerful and efficient. This is obviously great for humanity! It's enabling discoveries that were previously out of reach, and allowing us to accomplish the same amount of work with less effort.
AI is also generating massive amounts of money for the wealthy and powerful and increasing inequality. This is not great for humanity!
I do think it's important to keep in mind that this centralization of power and wealth is not caused by AI directly: the pattern exists whenever there's a desirable but scarce resource. The same argument that AI is increasing inequality can reasonably be made about concrete, steel, and steam engines. The problems caused by AI are really human problems at their core. It's possible AI could even help us fix them! (I'm not at all hopeful.)
LLMs haven't enabled any discoveries that were previously out of reach. If you disagree, name one?
>AI is useful today and is getting more powerful and efficient
No, it's getting less efficient at an exponential rate without proportional performance gains
>do think it's important to keep in mind that this centralization of power and wealth is not caused by AI directly: the pattern exists whenever there's a desirable but scarce resource. The same argument that AI is increasing inequality can reasonably be made about concrete, steel, and steam engines.
The goal of these LLM companies is to funnel all economic activity through their models. LLMs only exist because of how they strip mined human work without consent or compensation. I.e. LLMs do directly cause the centralization of wealth and power by how they were designed and how they are meant to be used.
> LLMs haven't enabled any discoveries that were previously out of reach. If you disagree, name one?
While not an LLM, protein folding is now often done via transformer.
> No, it's getting less efficient at an exponential rate without proportional performance gains
AI is expanding in both directions. Sure, it's eating the world with its compute demand and the bitter lesson bites, but we're also seeing drastically improved efficiencies employed alongside. The cost per task is dropping fast.
> The goal of these LLM companies is to funnel all economic activity through their models.
That's what all companies want, AI or otherwise.
No arguments here on the ethics of AI companies though.
In snowball games like this, losing a unit marks the beginning of the end. As such, you really have to go out of your way to lose units in the tutorial.
I enjoy coding deeply, and my feelings are not that simple.
I love code as a craft. I love spending time designing the perfect abstraction. I love seeing it come together in the implementation stage. I love the troubleshooting process and the understanding that comes when you finally engage with the root cause of the issue. I love all of this so much that I ship little, all my time is spent in process.
I also love code as a tool. I love working tirelessly towards describing a goal and then watching it come to completion. I love knowing my projects consume terabytes of data and spit out useful results. I love seeing my assumptions on the outcome proved right or wrong.
Now I can do the latter without the former, and it leaves me deeply conflicted. A large part of me is more excited than I've ever been. Another part of me is quite sad, and this is unfortunately the part where my ego lives. For now, I keep it in check by asking the LLM to describe the pros/cons of alternative architectures. That way I stay learning about the products I create.
As I like to tell others: before my job was 70% architecture & patterns and 30% coding & algorithms. Now my job is 100% architecture & patterns. While I still spend the majority of my time on architecture & patterns, and while I enjoy this aspect more than coding and algorithms, I am still working a "different job" than I was when my hands steered the code completely.
People say stuff like this all the time, but what does it actually mean? Like, isn’t the details of the code, at least at some level, part of the “architecture”? I’m so curious about what people who say this are actually making where they just sit around all day and dream up new lego structures without ever having to look at any of the bricks.
The bricks are pretty standardized? I mean, you're not reinventing singly-linked and doubly-linked lists from first principles no? When I program I think in terms of data structures, data hierarchy, and algorithms. I want to use a queue here, a lock here, a double linked list there, an array list over here, maybe a hash dictionary with linked-list chaining for collisions. It's only a few times in my career that I built a bespoke data structure from the ground up and they were all for very hot loops and one case involved working on a lock-free algorithm.
I've done a lot of functional coding in the past (in academia, in Haskell as a hobby, and Scala for a unicorn where I was an early hire.) This probably affects how I think. But I find it quite natural to organize my code this way. After all the fundamental data structures and the hierarchies relating them are what often determine core properties of your programs such as being CPU, Memory, or IO bound.
I also work as a pretty senior engineer and my tasks before agents were usually about leading a team to implement something. I would often do the v0 implementation to make sure we met customer requirements and then take a step back and help the team scale the service up. These days the team is a lot smaller and maybe just another engineer; the agents make up the rest.
I may have it wrong, but I think 'architecture' can include relatively low-level details: you could even design a program down to the level of what each function does, and still only be doing 'architecture', not coding, so long as you're not writing the code or specifying exactly how it should work.
> you could even design a program down to the level of what each function does, and still only be doing 'architecture', not coding, so long as you're not writing the code or specifying exactly how it should work.
So it all wishes and prayers? no wonder software quality is down.
Software is built on wishes and prayers. Programmers don't ship pixels to be installed in monitors, nor do we (mostly) work with compiler internals. We write a detailed set of instructions and hope that a bunch of systems we don't necessarily comprehend follow them well enough to get the intended results. It works because some folks got together and wrote down their wishes and prayers so good that others were able to understand and follow them later.
We can be curious about how others approach problems or we can try to find the faults. I feel like this comment is a great example of jumping to the negativity rather than trying to understand a different perspective.
I ultimately think learning how other people structure programs is an enriching task and not one that should cause you to dig in and discredit differently-shaped approaches.
> I ultimately think learning how other people structure programs is an enriching task
Learning from others is great. But there should be actually something to learn. When someone says
so long as you're not writing the code or specifying exactly how it should work.
It means they’re not creating software. They’re just playing with randomly generating something.
A software is the recipe for some process. The code is the formal version where everything is exhaustively specified. Not thinking about the code means you’ve stopped thinking about the software somewhere and no longer can say if it’s ok or not.
What's the point of leaving a comment if you're not going to change your mind and they're not going to change theirs? Is it just to advocate for your position?
As you're being very vague, I write more about my opinion, which is based on a guess of what your approach. Basically the Q of P imply Q where P is the guess (and P is the thing you're being vague). I'd like if you can prove that either P is not valid or that there's a different Q that exists.
Axiom: A software is the recipe for some process. The code is the formal version where everything is exhaustively specified.
P: Not thinking about the code
Q: means you’ve stopped thinking about the software somewhere and no longer can say if it’s ok or not.
To further go with my point, it's like explaining how to make a cake and you said that instead of a recipe, it's fine to provide just the name of the ingredients and a general instruction like: mix everything together and put it in the oven.
When we write code we sit atop a tower of abstractions. You're trusting your language's stdlib, its compilers, the syscalls offered by your kernel, the virtual memory implementation of the kernel. Your coworkers wrote code that you only interact with as a library or over an API of some sort. Let's not even think about the lossy abstraction of taking the ultimate bytecode generated and actually mapping it to the actual CPU pipeline that's running the code.
Modern computing is an exercise in trusting abstractions and then zooming into the abstractions and figuring out what went wrong when something breaks. Just because I wrote a web route doesn't mean I've audited the code behind the web framework, the event loop, the HTTP implementation, the TCP implementation and so forth. By your argument then I've already stopped thinking about my software and can't tell you if it's okay or not.
I'm sympathetic to both the perspective of sadness from the loss of hand coding and the perspective of joy from working at a higher level of abstraction, despite its costs in understanding. It actually seems very simple to me to hold both perspectives within me.
The thing you’re forgot to mention is that the trust in the layers below your code is not blind. Sure you treat it as axiomatic foundation. But when something breaks and you’re sure it’s not about your code, then you can investigate the actual part that is wrong in that foundation.
Once that’s done, there’s a matter of accountability where you can report the issue to the people responsible for that. Then because they know their own code they can repeat what you did and try to find where things went wrong.
That chain of accountability is the main issue there. We still have tower of abstraction, but no one knows about their layers. Accountability is lost and with it the trust is gone.
I never care about code, whether you wrote the majority of it or it’s just a glue that hold several library. What I care about is that the semantics of that module that I interact or build upon can be trusted, and when something wrong is an accident and not a daily event.
Even when you’re writing an application and not a library or a platform, you’re not free to write whatever. Your users depends on you, and themselves may have clients that depends on them. Being cavalier about what you write is just recklessness and in any other (real in some countries) type of engineering, it would be labelled as malpractice.
> That chain of accountability is the main issue there. We still have tower of abstraction, but no one knows about their layers. Accountability is lost and with it the trust is gone.
Right this is the main difference between our viewpoints. I don't work on completely open systems. A lot of my life I've worked on closed platforms, cloud runtimes, a mix of work that's been in my control and out of my control. I've filed my share of AWS tickets but ultimately most of them ended up not fixed by AWS. I've made peace with not having accountability for layers of the stack and am comfortable assuming that there are bugs on the foundation that I have to work around.
> Being cavalier about what you write is just recklessness and in any other (real in some countries) type of engineering, it would be labelled as malpractice.
I just design the fun part and let LLM deal with the chores.
For example recently I did tiny little hobby project, taking metrics of ESPHome/homeassistant MQTT and pushing it into prometheus. Coded the main parts, told LLM to do the boring part of setting up test suite, guided it thru making tests, it worked fine, tested it, then told LLM to do another boring task, taking all the datatypes it support and unit conversions (which is hundreds).
I got to do all the fun design stuff, but had code review assistant that also did all the boring tasks.
It's like making animation but you only have to make keyframes and initial coloring, with AI filling the blanks, just cutting out the tedium
I feel like most things at the Esolang Wiki fit the bill. Chef, Piet, and Befunge are two favorites that spring to mind. This reminds me of Chef in particular.
What evidence? You didn't link any. Searching for the hints in your comments brings up marketing by Anthropic "data you sent to one company is being sent to another without your knowledge or consent!" Anthropic also states this without any evidence, but I'm not suggesting it's not true!
I am so glad we never see stories against Anthropic/OpenAI claiming that! Thankfully we don't even have to search, critical thinking is enough to know that Anthropic/OpenAI are responsible data sovereign and others are not.
Nothing short of unredacted network logs and packet dumps would convince people like you (and even then you could just say they are forged). In the eyes of HN the Chinese model providers can do no wrong.
Anyways, they can easily be sued by DeepSeek if they are lying.
> critical thinking is enough to know that Anthropic/OpenAI are responsible data sovereign and others are not
Critical thinking is not relying on a confirmed bad actor because you think the others maybe could be bad actors.
So you're pushing a conspiracy theory, have no evidence to back it up, and you expect everyone else to do google searches to substantiate your claims. I see. Well, have a nice day then.
It's just as much a marketing blog post, but I'm not entirely unconvinced, just unsurprised. AI companies fundamentally all want the same thing: unrestricted access to everyone's data. I'm not planning on relying on any of them if I can help it.
reply