Look at the bright side, it's much more feasible now :)

Yes, it's not deterministic, and if you were using it commercially, the ROI would be terrible, and it's certainly not reliable but for a hobby project.... why not?

Encouraging people to understand the layer of abstractions they're building on is helpful, doesn't matter if they do it by hand or with clankers.

LLMs lower the barrier for execution - they make you faster. The unstated question is: faster at what - they can make you faster at something clever, or faster at the entirely wrong thing...

Your point is correct if we're looking at it through a scarcity lens - the effort to make it certainly decreased a lot - but that doesn't mean that anything is now worthless. We can just move onto doing bigger, better things now, until we hit the next limits...

> Encouraging people to understand the layer of abstractions they're building on is helpful, doesn't matter if they do it by hand or with clankers.

But we know that long term use of LLMs does not lead to better understanding, it leads to reliance on the LLM for the person to be able to function at their job.

You also depend on {computers, the internet, electricity, groceries, etc.}, that's not the discriminating factor.... the question is, are you actually better at your job using it, and are you stunting your own growth?

I'm not claiming to have a definite answer to either, but I think the right question to ask is - are you going to benefit from using it in the long run? If yes, carry on, if no, re-evaluate what you're doing :)

Early in my career, I had a consulting job where the client wanted me to work on their system using their tools. They had nothing and would not provide anything. No compilers, no runtimes, nothing but a regular, run of the mill, desktop office workstation. Instead of performing the task in Visual Studio with .NET like we had planned, I did it in Excel with VBA macros.

If you come to rely on specific tools such that you can't do your job without them, you're no longer doing the job you think you're doing, you're now just a tool operator. If I don't have a computer of some kind, I'm not writing software, I'm just a manager. If my team can't work because GitHub is down, then we've done a bad job of being software developers.

The experience taught me that there are two kinds of tools: those that are necessary and those that are nice to have. Yes, that job sucked, and yes, I quit that job, but more because they refused to pay me the overtime I needed to get it done with such crappy tools.

I had another job where we were one client of many on site with a vendor for a training event and the vendor couldn't get a system configured correctly for our cohort to continue on. Part of the problem was their configuration system was garbage, very easy to get wrong, very time consuming to manually edit. While they were dicking around with throwing edits against the wall, I wrote an HTML page with JavaScript to make a UI to edit the data in an much more natural way and then generate the config file. It took 10 minutes and saved us hours of waiting so that we could continue on with the training. Perhaps the takeaway from that experience was that Valve's engineers write shitty config systems. All I know is we got the training event done and I walked away with a piece of paper that said I was now a Certified Hardware Vendor, which we then used to sell more contracts on our own.

That's just not true... the flags to get preprocessed output and assembly are quite useful and used a fair bit, in fact. Multiple reasons - sanitychecking your code, finding bugs, or even finding compiler errors.

You'd be surprised, again.... most compilers don't generate very good code, mostly because

1. the time for optimisation is limited

2. the constraints are overlapping and just completely intractable beyond a single function (do you want to inline this, saving on the call and increasing binary size, or not do it because it's cold?)

3. they don't have domain-specific knowledge about your code, and even with PGO, they might incorrectly decide what's hot and what's not - typical example are program settings. You didn't enable a setting during PGO instrumentation, compiler sees you didn't call that path, shoves it out of line. Now your PGO-optimised code is worse than -O2. And compilers have different levels of adherence to manual branch hinting - on MSVC you get a reorder at best, Clang and GCC try much harder at [[likely]] and [[unlikely]].

4. There's still quite a bit of low-hanging fruit left, mostly because progress is jagged ;) For example our calling conventions generally suck - this is actually why inlining is so helpful - and the inertia makes everyone emit the default calling convention and that's it.

For example, did you know that compilers have very inconsistent support for struct unpacking? It can be much faster to write

  int32 meow(int64 a, int64 b);

than

  struct mytype {
    int64 x;
    int64 y;
  };

  int32 meow(mytype a);

because the first one goes through registers on the MSVC ABI, the second one gets lowered to the caller passing a pointer to the stack. Before someone says "oh this just means MS sucks" - fair, but for std::unique_ptr the situation is the other way around... on the MSVC ABI the callee cleans it up so it's truly zero-cost, but on the Itanium ABI using it is worse than using T* as a raw pointer... see the GCC codegen :)

These examples might seem a bit cherrypicked but this is only scratching the surface, not to talk about the codegen in higher-level languages, which is even more dreadful. Manually optimising your code can usually get a magnitude worth of free performance, which is just tragic.

I wouldn't even rule out LLM codegen in the future - although they're quite unreliable today so you'd get miscompiles like crazy - but there's just so much low-hanging fruit left on the table that it wouldn't be too out of step...

Expanding the struct to two arguments does not take longer than rewriting your whole project in assembly.

I've never said that, but using assembly in certain places can certainly be justified, especially for the performance-intensive parts.

Calling win32 from other languages is supported, calling it from assembly is supported (as long as you use the calling convention properly, obviously), using ntdll to bypass the win32 API is not supported.

Basically on Linux the syscalls are the equivalent of Win32 except much narrower in scope.

> using ntdll to bypass the win32 API is not supported

But it is sometimes required to do things properly.

Yeah, you're definitely right about the shifting goalposts ("it's a stochastic parrot" -> "it hallucinates all the time, it can't even get APIs right" -> "it can generate functions but can't reason about the codebase" -> "the bottleneck was never shipping code")

At the same time, humans can move up the abstraction ladder faster than the LLMs can. At least, some humans. Agents can produce lots of code. They can also do the entirely wrong thing. The impact of wrong decisions have been massively write-amplified with more and more intelligent LLMs. With earlier ones, it got a sentence or a function wrong, you reprompted, the cost of a mistake was 10 seconds. Now, you can burn hours or even days of work on the entirely wrong thing without a competent human operator stepping in and course-correcting.

The trajectory of agents have been bigger and bigger context windows, bigger autonomy, but at the same time, a bigger blast radius. In this context, I don't think the human experts will be out of their jobs any time soon.

> At the same time, humans can move up the abstraction ladder faster than the LLMs can

This was kind of the point, its only true for now. I agree with you that this kind of stuff will take longer. I don't think there's probably good training data for it right now. Handling abstractions and course correcting is probably the job now, and it also happens to be exactly the data that we will be typing in our prompts. They'll train on it or something like it.

Unless something radical changes (and that isn't unprecedented! I'm just writing this as of today), the trend is still "just" a bigger hammer. It's bigger, you can get way more done, but the blast radius is also larger.

Take the strawman: even if AI can one-shot basically any application below let's say, 1MLoC, if your prompt is 4 lines, it will generate something. It can't read your mind. If you make proper specs, then you'll get what you want - but many people don't know what they want. And even if they do, they might have contradictions in their requirements, might be asking for something impossible, etc.

Ideally. But that requires the correct abstraction, requires keeping it up to date.... that's basically an unachievable ideal. You either have overabstraction/overengineering (most codebases) or you have repetition. Repetition is actually more preferable in the LLM-world because you have to keep less stuff in your head. And the LLM's head too.

Even if something does look copypasted, it might actually be semantically distinct enough that if you couple them, you'll create a brittle mess.

Additionally, there's always going to be global changes (update the code style, document things, refactor into a new pattern, add new functionality to callers, etc.). The question isn't whether you use your lanuage's tools or you do it by hand, the question is whether you use an LLM or do it by hand :P

Totally fair, but 42 if-statements across 32 files isn't something you need to fix with like ... a grand refactor or hexagonal architecture or event sourcing or whatever the overengineering pattern du jour is. You can fix that with a utility function or three, and a file/class/module/whatever that owns the code relating to some of those conditions.

I'm not some DRY zealot, but I've been in the "this system needs really similar changes to a ton of geographically distant code for simple changes" salt mines a lot. The people who say that kind of spaghetti is unavoidable are just as wrong as the ones who say it can only be fixed with a grand rearchitecture by a rockstar.

Sure but even wiring that utility function in is work :D If you have even just a 2-3-million LoC codebase, not even something truly enormous - making global changes does require typing, and a whole lot of it...

Such repetitions can regularly be deterministically automated, like find -exec sed and similar medium level tools.

If you spend a lot of time performing monotonic tasks, then your organisation needs to delete and refactor for a while until change in 'hot' areas of the code base are easy to make. Reaching for some code synthesis SaaS to paper it over will worsen the problem and should result in excommunication from the guild.

If you have a codebase that big, can you even fit enough of it into a context window for the LLM to make correct and meaningful changes across all of it? Admittedly I've only used LLM-based coding for smaller projects.

All of it hell no :D But just with any things, you break things down into subtasks. Then you break it down even more. You as a human don't hold all that stuff in your head either, so why would an LLM?

My current codebase is ~3 million LoC all in all (not greenfield, really old code), working on it by myself, the complexity is definitely manageable between Claude and me :)

I just want to mention that in my personal anecdotal experience, every codebase I have ever worked on, except 1, was underengineered and not overengineered. The last one was just "engineered".

LLMs are great at replacing repetition with an abstraction.

All of them you can already find on the internet with only a bit of searching btw. With the docs and headers and everything.

The only people who this stops are the people who want to do things "by the book". :P

Well, all it takes is for e.g. Nintendo to see that you're violating NDA and poof your game is gone from the eShop. So while in practice you can get the API docs, woe to the company that leaked them.

So if e.g. Wesnoth got ported to eShop they'd legally have to publish the source but Nintendo would instantly delist and sue for NDA violation.

Again, I hate the companies that do this. Nobody should buy from them. But that's what they do.

I don't follow, sorry.

1. In order to publish a game to a console, you do need an agreement with the console manufacturer. (Unless you're doing homebrew but then the point is moot.)

2. In that case, you do get access to the official documentation, everything is solid.

3. The word "legally" has a lot of bearing there. Sure, they have to. And if they don't, what? Will the other contributors sue them? If they aren't willing to do that, then they can get away with it.

4. The context is about someone trying to hack the devices. ("Who knows what some enterprising hacker might be able to glean about the workings of the console by looking at the APIs.") They certainly won't be bothered by NDAs.

That isn't technically true either ;) (sorry to be pedantic!)

If your data is encrypted, what your adversary needs is some information about you - which they can gather by either buying it from someone or by investigating you - and a $10 wrench to go over there and get the keys out from you...

Most secrets are only secrets because the combination of obscurity and incentives raises the bar high enough so no one who wants to bother really bothers.

<meta> You're incredibly rude but at the same time.... 100% right. On first reading it was quite off-putting, but your conclusions are solid. Emotions take over rationality, and people - just like thinking models - reverse-engineer a logical-sounding explanation for their actions, they don't "expose" their internal chain of thought.

Maybe the models are closer to us than we're comfortable to admit.