Do not get deceived by the average number. I'm pretty sure that most of the money of the total goes to a handful of people, and the small remaining amount will be shared by the rest. Emphasizing the average amount is just their PR strategy.
You should read it especially now when more and more code is written by LLM. The important thing is not the code itself but your mental model of the software you're building. Sadly we seem to be moving away from it. We're accumulating more and more code that we don't understand or haven't even read.
I was going to say that an LLM can't do this, because it loses everything at the end of the session. But... could an LLM write out its "state" or "understanding" so that you could recover that for the next session? Do any LLMs currently have that ability?
It's very common, but (like most things with LLMs) it's not as deterministic as you might imagine. A common technique for agents is to have them create a "handoff" document (usually markdown) that summarizes the previous session-- goals, important files/links, etc. There are dozens of proprietary ways of doing this, and Claude Code automates the process with its /compact command and even does auto-compaction as you reach your context limit. ChatGPT has been doing autocompaction since the beginning as it started out with a comically small context window.
The problem with auto compaction is that you aren’t given the opportunity to review its compacted understanding to confirm that it’s correct or doesn’t contain large omissions. I try to avoid letting it compact whenever possible and stick to plans that I review because it seems to get extremely dumb after an auto compaction.
Yeah, I still find Opus to be pretty unreliable once you get past around 150K tokens, so I usually run a custom hand-off command at that point that extracts specific elements to specialized documents. The command contains a "Documentation Map" with single line summaries of each of those documents to help the agent sort everything out. Like most memory systems, it works pretty well around 80% of the time. I messed around with RAG and other complex solutions, and I never got much better results than my KISS system.
In theory maybe in some sense, but if we read Naur's definition of "theory" in a more strict or philosophical way, they can't in full. An LLM can't build a theory, because it doesn't have "real" experience, it's essentially just following rules. It also can't really argue or justify its choices like a person can.
This is discussed in the "Ryle's Notion of Theory" section of the original essay.
This brings up a philosophical question. Are we willing to hand over the role of "theory building" to LLM if that's even possible? If yes, what will be the role of human beings?
It may destroy many foundational assumptions that humans have had for thousands of years.
Theory building for, say, physics? No, humans need to understand that, if at all possible.
Theory building for a program? That's less important. But you give up any chance of a human ever being able to work well on it. That may be an important loss; we'll know in 5 or 10 years.
It's very conceivable that we reach a point where software is treated as a black box, i.e. no human ever reads it, only LLMs read and modify it. Isn't this essentially what vibe-coding means?
Many (most?) people make a living from their job whether they like it or not. Having a job that they dislike is far better than losing one because of AI whatever that means.
Could also be possible today, but we chose a capitalistic system that leads to an increasing wealth gap. And now we're in a situation where the richest 1% own 50% of the wealth.
So, if we increase automation and the ownership structures stay the same, this inequality will get worse, not better.
It’s interesting, people talk about inequality and I definitely feel it myself – I see so many rich people around me. But I am in that 1%, just like many on this forum. At least according to https://dqydj.com/average-median-top-individual-income-perce... yet I still have to work for a living.
> The cost will exponentially increase over time and the systen will eventually collapse.
From what I'm seeing in the numbers, the big problem of the coming century is population collapse. Maybe I'm just too much of a believer in the intermediate value theorem, but I'm sure there has to be a way to arrive at a society with a sustainable usage of resources.
Nope. If everything is totally automated, if ever, the gap between the rich and the poor will widen even more. Most people will live in misery while only a handful of people enjoy all the automation.
> Having a job that they dislike is far better than losing one because of AI whatever that means.
Is it really worse even if "whatever it means" is living in a post-scarcity society where everyone can shareel in the fruits of the AI's labor?
I'm not saying that's where this are necessarily going. But I am saying that that's what we should be aiming for, rather than trying to preserve the status quo.
This reminds me again of _Programming as Theory Building_[1] by Peter Naur. With agents fast generating the code, we lose the time for building the theory in our heads.
Shortening feedback loops was what Kent Beck and TDD advocates were emphasizing. Now TDD has been ruined by "experts", people are realizing the importance of fast feedback loops from a different perspective.
But what most of them do is not to be more efficient but to be shown to be more efficient. The main reason they are so obsessed with AI is because they want to send the signal that they are pursuing to be more efficient, whether they succeed or not.
Peter Drucker popularized the phrase "Efficiency is doing things right; effectiveness is doing the right things."
Being a credibly efficient at doing the wrong things, turns out to be a massive issue inside of most companies. What's interesting is I do think that AI gives opportunity to be massively more effective because if you have the right LLM, that's trained right, you can explore a variety of scenarios much faster than what you can do by yourself. However, we hear very little about this as a central thrust of how to utilize AI into the work space.
In my experience plenty of places are quite inefficient at doing the wrong things as well. You might think this reduces the number of wrong things done, but somehow it doesn't.
It's almost comical isn't it, but it actually turns out that this is a big foundation behind behavioral economics. In essence you can get trapped in an upper level heuristic and never stop for a moment and thinks things through.
Another one of my favorite examples is that there is some research out of Harvard that basically suggested that if people would take and spend 15 minutes a day reviewing what they had done and what was important, they increased their productivity 22%. Now you would think that this is so obvious and so dramatic you would have variety of Fortune 500 companies saying "oh my goodness we want all of our workers to be 22% more productive" and so they would simply send out a memo or an email or some sort of process to force people to do some reflecting.
I would also suggest that Microsoft had a unique advantage based out of the idea that people should have their own enclosed workspace to do coding. This was deeply entrenched when Bill was running the company day-to-day. And I'm sure as somebody that was a coding phenomenon, it simply made sense to him. But academically, it also makes sense.
Microsoft has reversed this policy, but as far as I can tell, it doesn't have anything to do with the research. It has to do with statements about working together efficiently. or AI productivity. If there's real research then it's great.
My problem is it just doesn't appear to be any real research behind it. Yet I'm sure many managers at Microsoft thinks that it's very efficient. Of course, if you do know anybody at Microsoft that codes, they have their own opinion, and rather than me repeating hearsay, it would be fantastic to have somebody anonymously post what's really going on here. I'll betcha a nickel that 90% of them are not reporting that they feel a lot more effective.
That happens whether immutable or not. In the mutable world, you have to guard that using a mutex or something. In that case, operation 1 may be blocked by operation 2, and now you get a "stale" state from operation 2. But that's okay. You'll get a new state next time. The real problem occurs when two states are mixed and corrupted.
