18,359 karma · joined September 12, 2011
There are some who would call that micro-management.
Which is self-defeating. If you don't make a good faith effort to understand what he said then you're leaving yourself in a poor position to credibly argue against it.
What about an example where religious belief fundamentally excludes someone from doing the actual job? Suppose a Muslim wants a job as a bartender, but refuses to actually serve people drinks because they consider it a violation on the rule against alcohol. Should the bar grant them a religious exemption and just accept that they won't be serving alcoholic beverages when that person's the bartender on duty?
Or what if two different religious beliefs come into direct conflict? Suppose a Jehovah's Witness whose manager is also a JW decides to leave the religion. Jehovah's Witnesses consider shunning apostates to be a religious commandment, so their manager might feel obligated to fire them. Is that OK?
Depending on how we resolve those conflicts, perhaps people can at least agree that there should be limits to religious exemptions, even if they don't agree on the specifics. But perhaps that's at least a starting point for a conversation. And perhaps from there we can extend out to Durham's position.
I realize that's embedded within a larger page on the Sorites paradox instead of being given its own page, but I'm not super interested in being that preoccupied with Wikipedia's editorial decisions.
So let's look at that preceding sentence so that we can get a better sense of what kind of labor he was talking about:
> The process and work involved in thinking through situations, through my work, through my ethics, through the way I handle other people, is a key component in being able to develop myself as a moral person.
"thinking through situations", "my ethics", "the way I handle other people", "develop myself as a moral person". This doesn't read to me like he's taking a Butlerian Jihad-type position that humans have a moral responsibility to do their own arithmetic. We're clearly talking about higher-level, more abstract thinking and decision-making that might carry real moral weight.
And that brings us to a difference that I think he might be seeing but that you seemed to be claiming does not exist when you said, "My main issue with these people is that they think AI/LLMs are different than everything that came before them." GPT-style decoder LLMs are the first time we've ever really seen people trying to rely on computers to make abstract and open-ended decisions such as drawing up business plans, drafting memoranda, or doing deep research-type tasks on any sort of scale.
I think that you're probably aware that there is a a noticeable difference between how people are thinking about LLMs now versus how they did back when GPT 2.0 was the latest and greatest. The fact that we can construct a hypothetical continuum of possible models between GPT 2.0 and GPT 3.5 Turbo and suggest that, in this counterfactual scenario, it might not be possible to draw a hard line that cleanly separates the tech itself into two discrete categories, is fundamentally missing the point. His concern was never stated to be about the technology itself; it was about how he was being asked to use it.
A continuum is not isomorphic to a single point.
Hypothetically the code is consolidating sites where allocation happens. Zig’s design seems to really push you toward this by making anything else a PITA. So then that allocator reference is being used frequently and already sitting in a register anyway.
The few extra instructions for explicitly passing it might be small compared to the cost of having objects carry their own references. That would grow each instance by ~8 bytes. It would mean that the pointer to the allocator needs to be pulled from a unique memory location for each instance, which is maybe an order of magnitude slower than already having it in a register. Larger data structures would also mean more cache misses, which are another order of magnitude slower.
And this is all chicken feed compared to actually taking a walk of shame out to the DRAM to fetch more memory. So the language ergonomics encouraging you to consolidate your allocation might trump all other considerations in practice.
Zig seems to be laser focused on systems programming domains where there is value in keeping unusually tight control over everything the program does. Aside from tinkering with Arduino, never been me. If it were, though, then I would probably not want to use a library that wants to be able to arbitrarily grow ArrayLists. I would probably want to structure my program so that it acquires pages of memory (actual memory, not just overcommit) in as few places as possible - ideally one - and from a location very close to the entry point. And a library that doesn’t play nice with that wouldn’t be much more palatable than a library that wants to bring its own memory management runtime along for the ride.
I don’t think that’s totally unreasonable? It’s more restrictive than what most of us are used to, sure. But it’s also quite a bit less restrictive than completely banning dynamic heap allocation as is common in aerospace applications.
It won't be floating anymore, but it will at least be somewhat physically intact, at least relative to the state it was already in. It was pretty well stripped bare back in the 80s, and further gutted after that asbestos abatement project a while back. And it will be available for people who can SCUBA dive to visit.
The worrying thing about using LLMs to do the "thinking" about what to say and how to say it is that you replace a plurality of human biases with the opinions of the small number of people who get to decide how these models are trained. Which will only seem unbiased if the bias baked into the LLM happens to align with your own.
It seems like agentic coding is removing the last few places where work really did force us to slow down and spend some time learning. I'm not convinced that's a good thing. I've seen too many situations where the rich mental map someone built up during learning time later saved the team multiple person-months' worth of effort by letting someone see a non-obvious solution that was much simpler than the original plan.
It’s true that that decision didn’t involve everybody getting their way. But that’s not organizational hell, that’s just organization. If you don’t want to contend with other people’s competing interests, the solution to that is solo development.
It’s kind of wild how nice Python’s C extension system, which enables basically zero cost interop with native code, is for certain purposes. It supports a situation that’s comparable to the games industry’s tradition of putting a Lua or Lisp tip on top of a C++ iceberg.
Perhaps these priorities were always irreconcilable.
Perhaps that’s why the existence of competing Python JIT projects that weren’t trying to commit directly into CPython’s main branch kept coming up in the conversation.
I’m sure the ship will eventually right itself, but it’s going to take some time for the profession to digest how AI coding has changed things and how to adjust incumbent working norms to account for it.
In this case a single committee directly engaged with both core developers and the community, through a fairly open process, explicitly bent several of their own official rules to suit the occasion, and indicated cases where further flexibility might be needed depending on how things develop.
I would call that a pretty stellar example of non-bureaucratic governance.
As they themselves pointed out, the problem isn’t that there’s anything wrong with an open-ended experiment. It’s just that open-ended experimentation doesn’t belong in main, of all places. They have an ongoing duty to ensure that a critical piece of global infrastructure remains stable and trustworthy to consider.
If having to put all that in writing and get a bunch of people to agree feels too burdensome to you, maybe that’s a sign that you would be happier working on something other than core changes to the world’s second most popular programming language.
(edit: That wasn’t meant to be a jab at the core developers working on the JIT. Based on what’s in the public discussion threads, they have been handling things very well throughout the process. It’s unfortunate that the SC let the project get this far before realizing the project had grown well beyond its original PIP’s mandate, and I’m sure that is deeply frustrating to the people leading the project. I know I would not be handling the setback nearly as gracefully as they are.)
In manufacturing, an oversupply of finished product quickly leads to overfull warehouses, and the company knows to slow down production until product moves.
In software it’s less visible. Features that nobody is buying don’t physically pile up in the shipping department. Decades of accounting for all programmer time as productivity has left managers with limited ability to recognize time spent building unnecessary bloat as a loss. Maintenance burden isn’t fully recognized as a loss, either. We tend to assume it’s roughly equivalent to profit, the same as all other code the programmers churn out.
And what you are seeing now is that it was always a myth. Not everything you do at work is profitable or productive, and AI is causing that fraction to decrease. So of course they aren’t going to pay you more for it.
I’m not sure the same conditions exist in other fields that deal with real world phenomena. Experiments to test hypotheses about biology or physics can take years and cost millions of dollars to run. They rarely scale down to the millipennies and milliseconds scale that makes letting a swarm of agents throw a bunch of shit at the wall and see what sticks a feasible option for finding mathematical proofs.
So you switched away from the specialty product, but you're still comparing a top of the line 6.3 inch iPhone to a mid-market Android phone. Why not compare it to a Pixel 11 Pro with 512GB. That way they're at least comparable devices. But also, that would cost $1,220, which I suppose doesn't go well with the intent of suggesting iPhones are several times as expensive as Android phones.
The reason why I'm digging in on this is, when you start your argument with such a transparently silly comparison, it gives the impression that you're dealing in superlatives and willing to say just any old thing. Which undermines your own credibility.
So, getting back to corporate - multiple times how much for SSO? Okta Essentials is $17/user/month, which is a little over half as much as the base price for Cursor Pro, and about 2/3 the price of a basic ChatGPT seat.
But also, I don't think you should use individual consumer behavior as a proxy for how the overall LLM market behaves. Current estimates are that individual users represent a pretty small share of overall genai revenue. Most of it comes from enterprise contracts. Those might be more price sensitive because the CFO gets a say in which vendor they choose.
For a couple years now I've been accustomed to choice of foundation model being a heavily scrutinized design decision because it's just about the easiest way to manage COGS. I can certainly imagine scenarios where, given the option to pay 1/2 as much in inference costs but with a 5% reduction in output quality, the boss would say, "Nah, that's a bad deal." But I have yet to encounter one in the wild.
The pattern seems to be that it makes people more productive when you measure it in terms of raw work product volume. But not all work product is equally valuable, and we have yet to see a clear pattern of increased economic productivity. Instead we just keep finding new and interesting bits of jaggedness in the frontier.
Of course nobody can prove those economic gains will not manifest at some point in the future. I can’t prove that Jesus isn’t coming soon, either. But I also can’t prove which millenarian denomination, if any, he would choose to bless in the event that he does come back.
So you’ll eventually want a more formal way to track and query everything, and to route the coding agents through that API to ensure consistency and reliability. At which point you’ve basically just reinvented the ticketing system that you originally sought to eliminate. Only it might still be flaky because every source control branch introduces a secondary source of truth for ticket status.
But I see every reason to believe demand will taper off. It seems it’s already happening. Enterprises have been deciding that maybe corporate chatbot and coding agent budgets shouldn’t actually be infinite. AI startups are starting to successfully outcompete each other, effectively killing off members of Anthropic’s customer pool in the process. And consumer demand for AI products seems to be dropping. None of these are signs that suggest that Anthropic has thus far met only 10% of plausible long-term demand.