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.
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
More options
Context Copy link