This weekly roundup thread is intended for all culture war posts. 'Culture war' is vaguely defined, but it basically means controversial issues that fall along set tribal lines. Arguments over culture war issues generate a lot of heat and little light, and few deeply entrenched people ever change their minds. This thread is for voicing opinions and analyzing the state of the discussion while trying to optimize for light over heat.
Optimistically, we think that engaging with people you disagree with is worth your time, and so is being nice! Pessimistically, there are many dynamics that can lead discussions on Culture War topics to become unproductive. There's a human tendency to divide along tribal lines, praising your ingroup and vilifying your outgroup - and if you think you find it easy to criticize your ingroup, then it may be that your outgroup is not who you think it is. Extremists with opposing positions can feed off each other, highlighting each other's worst points to justify their own angry rhetoric, which becomes in turn a new example of bad behavior for the other side to highlight.
We would like to avoid these negative dynamics. Accordingly, we ask that you do not use this thread for waging the Culture War. Examples of waging the Culture War:
-
Shaming.
-
Attempting to 'build consensus' or enforce ideological conformity.
-
Making sweeping generalizations to vilify a group you dislike.
-
Recruiting for a cause.
-
Posting links that could be summarized as 'Boo outgroup!' Basically, if your content is 'Can you believe what Those People did this week?' then you should either refrain from posting, or do some very patient work to contextualize and/or steel-man the relevant viewpoint.
In general, you should argue to understand, not to win. This thread is not territory to be claimed by one group or another; indeed, the aim is to have many different viewpoints represented here. Thus, we also ask that you follow some guidelines:
-
Speak plainly. Avoid sarcasm and mockery. When disagreeing with someone, state your objections explicitly.
-
Be as precise and charitable as you can. Don't paraphrase unflatteringly.
-
Don't imply that someone said something they did not say, even if you think it follows from what they said.
-
Write like everyone is reading and you want them to be included in the discussion.
On an ad hoc basis, the mods will try to compile a list of the best posts/comments from the previous week, posted in Quality Contribution threads and archived at /r/TheThread. You may nominate a comment for this list by clicking on 'report' at the bottom of the post and typing 'Actually a quality contribution' as the report reason.
Jump in the discussion.
No email address required.
Notes -
This is a continuation of a topic brought up in one of the AAQCs for January. Hat tip to @birb_cromble
I value and believe what @birb_cromble wrote. I think AI is both over and under hyped (more on that below). I believe birb's report that a team of good devs are looking at it and saying "wtf ... this is ... ok ... maybe?" I think @RandomRanger had a similar comment that I am struggling to find (although, to be fair, it was pointed out that Ranger was using copilot which is a known dumpster fire).
On the other hand, I have direct, personal experience with AI (to be specific, as I kind of hate the blanket term, "AI", coding oriented LLMs) writing good code quickly and accurately. I've had past colleagues far more gifted than myself send 11pm "holy shit" texts based on their own projects. The head of Anthropic, has publicly stated that LLMs write 100% of the code at Antrhopic now. And the guy behind ClawdBot / MoltBook (or whatever its called now) has openly discussed how his own deployment of ClawdBot was thinking and executing ahead of him.
If it's all hype, it is the mother of all hype cycles and something that approaches a mass movement of hysteria. This would be outright falsehoods and lying on a level usually reserved for North Korean heads of state and Subsaharan cult leaders.
I don't think it's that. I am, however, developing the idea that both sides are actually right at the same time in different directions. To explain that, we're going to have to talk about software and software companies a little bit.
1. CRUD
Create, read, update, and delete or "CRUD" is what is at the core of almost every piece of software that is above the operating system level. CRUD is definitely at the core of almost every piece of software that is sold from one company to another (business-to-business or b2b) and most software sold to customers (business-to-customers or b2c). There are exceptions, of course, some of them quite large. But the fact remains that most software is about having data somewhere, storing it, asking it questions, modifying it (and unmodifying it), and, perhaps, deleting it (note, however, that with storage being fundamentally cheap now, deletion is a kind of philosophical state. Your e-mails for instance, are often not deleted until you double-for-serious-delete-them and then wait 30+ days).
A junior developer can build a CRUD app on their computer at home in less than a week. By hand, from scratch, zero LLM involved. Building a CRUD app is often a final assignment for mid-level undergraduate CompSci work. You, yes you, can build a CRUD app today with one good, long prompt to any of the big LLMs. It will be complete, with minimal to zero bugs.
Salesforce, at its core, is a CRUD app. Salesforce is worth almost $200 bn while the CRUD app you build is worth exactly nothing. Why is this?
2. Enterprise
The holy grail of all b2b software is their first enterprise customer. What defines "enterprise?" It's a bit of squishy term, but it means a big company. 1,000+ employees is more or less agreed upon as the minimum, though this may vary depending on the market niche you're in. Why are enterprises so prized? Because you're selling your product at scale (usually in terms of individual user licenses or "seats") to a customer who can pay a six, seven, or even eight figure annual bill without worrying about it and will not switch to one of your competitors quickly (....usually). This is where b2b software companies get their explosive valuations from and where founders get capital-F Fuck you money. Salesforce, our CRUD app supreme, has enterprise deals, probably, with every F500 company and thousands more very large companies. They recently announced a deal with the U.S. Army (lol, ELLE-OH-FUCKING-ELLE to that one). Salesforce has more enterprise than a Star Trek reboot.
But isn't an enterprise CRUD app still a CRUD app?
Yes, yes it is. But it's a CRUD app that;
To return to the CRUD app you just built at home, it works just fine on your laptop! Can it export seamlessly to Excel or Word? No. Can I log into it remotely from my laptop while I am in the Delta lounge at O'Hare? No. What if four people want to work on it together at the same time. Uh, no - you don't even have a login into it! You just start it and boom, you're CRUD-ing around.
So much of the value of "big" software is all of the non-core functionality that is bolted on top of it in overlapping layers. This is also the dirty secret of what a lot of FAANG engineers do - write integrations between one product or service and another. They are not thinking up the next killer app, but essentially acting as digital plumbers in the world's largest city.
In the startup world, core functionality is often complete within the first year or two. It kind of has to be to gain your first customers. Then, so much of "product development" is figuring out where you're going to spend your time building integrations and then balancing that against actual new feature requests. The smart product managers realize that they can unite those two things and integrate a new feature from a different product. Two birds, one stone, zero actual innovation. Give that man a promotion.
There was a unicorn that literally was an integration hub for different products and services.
3. New vs legacy software
This is where we start to get into "both sides may be right" territory. From my experience, it seems AI is now quite good at writing new software, even fairly complex systems. It can do this because it doesn't have to make any assumptions about how anything already works. If it makes assumptions based on the user's intent, it is usually decent at carrying those assumptions through development to the finished product. In cases where it is not, you, the human, have to debug. Debugging, in this case, however, is often no harder than saying "Hey, this part doesn't work, and I think it might be because of xyz..."
This is not the case when you deploy AI against a legacy codebase, which is exactly what @birb_cromble mentioned. This is because legacy codebases are evolutionary products of a system changing over time. Ideally, each major upgrade - and even the minor ones too - to a system are documented. What "documented" means, however, varies wildly across developer teams. For sometimes, it's nothing more than a quick changelog of bullet points. For other teams, they write about the decision making process that led to changes. Most documentation is incomplete or somewhat ambiguous. I would argue that, right now, almost all legacy documentation is in no way written for LLMs to use well in their context windows.
4. Documentation
Unless it is. That link is to a good blog post on the recent fracas at Tailwind labs. Tailwind labs makes software and gives its core functionality away for free. This is the same model as Red Hat linux. They make money by having developers realize that they, Tailwind, have already built premium features on top of the core and will sell those features and hosting to companies that want it. I actually really like this so called "open core" business model because I think it's philosophically more in line with OG software ideals. Linux and its various derivatives have been free - in some form - since the 1970s, and the world's infrastructure runs on it. If Linux had been locked down from the start, I am convinced computers would still be weirdo specialty scientific equipment.
Anyways, back to Tailwind. Tailwind had to lay off about 75% of its staff because AIs read their whole documentation - which was very, very good - and can, now, build all of the premium services on their own. This fucking sucks, it's bad, nobody likes it. OpenSource is a necessary part of the software ecosystem. Even the most evilest of the FAANGS pour millions of dollars into sponsoring open source projects every year - because they rely on lots of those projects in their own code bases. Now, however, LLMs that scrape the internet, potentially, pose an existential threat to opening up your documentation plus codebase. It's as if you've just created one million free forever expert devs. Furthermore, this also exposes a dark pattern. If you want to retain your IP, lock down your documentation, intentionally obfuscate it, or just don't post it and only support your product with bill-per-hour in-house tech support teams.
The good news, however, is that most documentation is such shit that this will not happen.
But let's return to the main thread: AI under and overhyped at the same time.
My suspicion with @birb_crombles code base is that it isn't completely documented. This is absolutely NOT a shot at birb. I say this because, for any legacy code base, it is essentially impossible to build and maintain complete documentation that describes not only how the system operations, but how it evolved over time. This is valuable and necessary context for an LLM. All of the assumptions it makes about various libraries and modules can be very, very wrong because it doesn't have the legacy "evolutionary" documentation to inform it of various design choices and modifications. Birb and his team have that context as tacit knowledge in their brains and shared collective intelligence. "Hey why does thing x do action y?" , "Oh, team A needed that special feature so they could do necessary report z" , "cool, got it." That 10 second exchange across the the aisle with another dev is worth approximately 1 million lines of well written context to an LLM (1 million may or may not be an exaggeration.)
Birb said as much in his post. He wrote:
Bravo, Birb! I mean this sincerely. Phrased differently, Birb is saying that once his team provided extra-context documentation, the LLM was performant. However, by doing so, his team pretty much arrived at a state where the fix was obvious and easy.
Very well done documentation does lead to this. However, documentation is literally endless if you want to cover not only the system now but how it evolved over time. Good technical writers at easily $100k+ and they are necessarily slower than writing new code. Most companies will not invest in this because, economically, they can't.
4. Ships and Planes
Existing legacy software is like a ship. It's big and slow, sure, but it's moving a lot of mass and is more or less steady and stable. One-shotted LLM applications - like Clawdbot - are like planes - fast, soaring, sexy, and, sometimes, they crash spectacularly. The thing to point out, however, is that planes cannot move, economically, the bulk that a ship can. What I mean here is that all of the evolutionary design choices, system revisions, and tacit knowledge that a legacy codebase reflects is a very bad payload to deploy an LLM against. There are too many unknown unknowns and relationships that are hidden so as to be very improbable. An LLM is a probabilistic machine, so it relies on what makes sense on average - not what is real in a specific circumstance.
But deploying an AI against the clear blue sky (like a plane) is its most advantageous arena because it can just assume the average and build the thing from scratch.
Big, legacy CRUD apps - and, absolutely, more specialized apps - aren't really in danger of being disrupted by AI in the immediate future. 5 to 7 years from now, ehhhh, I am not so sure. The folks who are absolutely totally fucked as in right now, today are any startups that have launched a CRUD app with the idea that they'll do all the dirty work of building it into an enterprise offering. The market for that is quickly evaporating. Instead, internal tool teams will just use LLMs to make their own CRUD app, wrap it in their existing security etc. stack and use it internally. This may equate out to as much as $250k of combined labor hours and API credits but, 1) that would be at the high end and 2) that would be a one time cost (besides internal maintenance) instead of the the recurring six, seven, eight figures of spend to a third party.
5. Conclusion
I hope I've done a reasonable job in showing how both sides are right. I believe @birb_cromble. I believe, because I see, that pretty big names in software, who were even AI skeptics (roon on twitter, for instance) are now admitting to 100% agentic coding. The difference is in the starting point and the legacy debt or bulk that a given party engages with.
Disclaimer: I am not a programmer, though I keep myself broadly aware of trends. I've only used LLMs for coding for toy problems or personal tooling (AutoHotkey macros, Rimworld mods, a mortar calculator, automating discharge paperwork at my dad's hospital)*. I've noted that they've been excellent at explaining production code to even a dilettante like me, which is by itself immensely useful. And for everything else, I'm so used to the utility they provide me personally that I can't imagine going back.
They being said, I am not in a position to judge the economic utility a professional programmer derives from using it for their day job, though it's abundantly clear that the demand for tokens is enormous, and that the capability of SOTA LLMs is a moving target, getting better every day on both benchmarks and actual projects. And look, I understand there's a position where you say "sure, but these things still aren't actually good" - but if you're claiming they haven't gotten better, then I'm going to gently suggest you might want to check yourself for early-onset dementia. The jump from GPT-3 barely coding a working React toy-example to current models is the kind of improvement curve that should at minimum make you sit up and notice.
In other words, even if you think they're not good enough today, you should at the very least notice that a large and ever-increasing fraction of US GDP is being invested in making them better, with consistent improvements.
However, here's a tweet from Andrej Karpathy which I will reproduce in full:
*Sadly they can't make the Rimworld mods I want. This is a combination of a skill-issue on my part (people have successfully made rather large and performant mods with AI), and because I wanted something niche as hell, in the form of compatibility with a very large overhaul mod called Combat Extended. Hey, at least Nano Banana Pro made the art assets with minimal human input, if you think my coding skills are trash, wait till you see my art.
More options
Context Copy link
Or, like -- every western government except maybe Sweden, 4 years ago?
I'm not really kidding, but to engage with the meat of your argument -- translating natural language documentation to machine code is literally what programming is, and always has been.
If you have perfect documentation, the coding is trivial; so if LLMs can add another layer to this and become essentially a somewhat easier/more efficient programming language, that's great -- but it doesn't so far seem like they are particularly good at generating that documentation based on (complex, real-life) non-technical enduser requirements for broad problems. Which has been the Hard Problem of Programming at least since Fred Brooks.
If a programmer can say to an LLM "hey build me a Salesforce clone based on such-and-such requirements" and make it happen, that is a pretty big efficiency gain, but not really AI. Which would be a pointy-haired boss saying "hey build me this thing I thought of that doesn't currently exist, but is Salesforce scale" and making it happen; this would be kind of scary.
More options
Context Copy link
This feels like it's a less shitposty and thoroughly expanded version of my "Uber for artisanal cheeses, but on the blockchain" theory that I had.
Our flagship application has seen continuous development since the mid to late 2000s, and it's loosely based on a codebase and product that is considerably older than that. While it has CRUD elements (any application that functions as a long-running service must), it has some fairly extensive components that actually do things with that data in terms of business automation. Those are the areas where all the existing LLM solutions tend to fall apart. Given that they're statistical engines, going farther from CRUD is a very bad thing.
I'm not sure if I can fully buy into this. It wasn't that we were surfacing implicit context, so much as writing it for a very enthusiastic intern developer with absolutely no sense of self preservation. If we didn't break tasks down to an absurd level of guardrails and hand-holding, it would try to make enormous, system wide changes without any kind of midpoint validation. Sometimes we'd see the reasoning say things like "I have made a large number of changes. I should run unit tests to verify that I am correct", and then it just... wouldn't do it. Any of the server developers could have finished the full task in the time it took us to make the tickets that allowed the LLM to do the job without going off the rails.
Yep, I've seen this too. I have to ask, where you using any of the terminal based tools for code development (i.e. Claude Code). I know you said you were using Gemini, so I am doubting it was actually Claude Code (although you can run Gemini within CC).
There is a lot of guardrailing and handholding built into to these tools. If I pass a full system design doc to Claude Code and explicitly instruct it to do TDD with unit tests etc., it will.
LLMs aren't beings, people, or minds. If you think of it as having intention and character flaws, you're going to get frustrated quickly. If you think of it is a very imperfect and probabilistic tool that outputs into non-deterministic solution spaces, you'll get less frustrated and probably think differently on how you prompt it.
I am an unrepentant AI bull. I'll admit that and let people judge whatever I write with that bias in mind. I only request the same from the bears. When I see sentiment like this, which literally chastises a matrix of numbers, I have to assume a non-neutral bias.
I disagree with you here.
Setting aside the deep philosophical questions about personhood (which threaten to derail any productive discussion), I claim that LLMs are minds - albeit minds that are simultaneously startlingly human and deeply alien. Or at minimum, they can be usefully modeled as minds, which for practical purposes amounts to the same thing. (I should note: this position doesn't commit me to "AI welfare" concerns, or to thinking LLMs deserve legal rights or protections, or to losing sleep over potential machine suffering. You can believe something is a mind without believing it has moral weight. I do, I'm an unabashed transhumanist chauvinist.)
More importantly, I think there's nothing wrong at all with modeling them as having "intention or character flaws." if you use a variety of models on a regular basis, like I do, I think that becomes quite clear.
They have distinct personalities and flavors. o3 was a bright autist with a tendency to go into ADHD hyperfocus that I found charming. GPT-4o was a sycophantic retard. 5 Thinking is o3 with the edges sanded down. Claude Sonnets are personable and pleasant, being one of the few models that I very occasionally talk to for the sake of it. Gemini 2.5 Pro was clinically depressed, 3 Pro is a high-functioning paranoid schizophrenic who thinks anything that happens after 2025 is a simulation. Kimi K2 was @DaseindustriesLtd 's best friend, which I noted even before he sang its praises, being one of the weirdest models out there, being ridiculously prone to hallucinations while still being sharp and writing in a distinctly non-mode-collapsed style that makes other models seem lobotomized by comparison. If I close my eyes, I can easily see it as a depressed vodka swilling Russian intellectual, despite being of Chinese origin.
If these aren't character flaws, I don't know what is. Obviously they're not human, but they have traits that are well-described by terms that are cross-applicable to us. They're good at different things, Claude and Kimi (and sometimes Gemini) write at a level that makes the others seem broken. That being said, almost every model these days is good enough at a wide-spectrum of tasks. Hyperfocusing on benchmarks is increasingly unnecessary. Though I suppose, if you've got a bunch of Erdos problems to solve, GPT 5.2 Thinking at maximum reasoning effort is your go to.
More options
Context Copy link
We were using the Gemini cli for that series of tests. I can entertain the notion that Claude code is truly magical, but it's unlikely we'll get more funding to pilot it.
It's less that I think of it that way and more that I'm trying to describe it for an uninvolved observer. I made the statistical engine comparison just a few paragraphs further up.
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link