I agree that it's possible AI is unable to generate exceptional code (at least not at the moment), but there are definitely places where average or below-average may just be good enough.

If the goal is deliver business value, an argument can be made that one could leverage AI for bits of code where high skill isn't required, and that that could free up the human developer to focus on places where high skill is more important (high level system architecture, data model designs, simpler user experiences that reduce the amount of work overall).

If a dev just used pure "vibe coding" to generate code and didn't provide enough human oversight to verify the high-level designs, then you can definitely get into an issue where the code gets out of control, but I think there's a middle ground where you have a hybrid of high-level human design and oversight and low-level AI implementation.

I think the line between how much human involvement there is versus pure AI coding may be a sliding one. For something like a startup that is unsure if their product is even providing enough user value, it might make sense to quickly prototype with AI to see if a product is viable, then if it is, rewrite parts with more human intervention to scale up.

Not true at all. Good code is concise and does what it's supposed to do without any weird side effects or artifacts. That has nothing to do with "maintainability for humans".

Why would you want to avoid side effects, other than making it less hard for the next developer working on the code to understand how it works? Nature uses side effects all the time, and is widely considered to work pretty well.

LLMs are even more limited than humans though- tiny context windows, can't really learn new things- which really raises the bar on writing APIs that are footgun free.

Context windows have grown significantly, the biggest one at are at 2 million tokens right now. That plenty enough, as even in his t codebase you don't need to feed the fill codebase in, you just need to provide the LLM a map of e.g. functions and where to find them, and the LLM can pull the relevant files itself as it plans the implementation path. And for that the current context window is plenty.

> LLMs are even more limited than humans though- tiny context windows,

For now.

Given the power and cooling requirements, and the underlying techniques used for LLMs right now, I think 'for now' is going to be quite a few years. Maybe a decade plus. Plenty of time to train a new cohort of human developers who do more than just code 24/7.

Maybe the whole concept of "clean code" is built around maintainability for humans, but I think there's a version of organization of "good code" that makes it much easier to avoid like nested loop foot guns.

Using LLMs as compilers is unwise. Ultimately software must be configured or written by humans, even if there are layers and layers of software in between us and 'the code', and that act of configuration/writing is programming.

I think alot of the fastest moving and innovative companies right now are generating most code with ai. the ones who ignore this will be left behind

Which ones stick out the most to you?

That was the same argument folks used against high level languages when Assembly was king.

It will come, even if we are a couple of years away.

I don't think LLMs themselves (at least what we currently call LLMs, with the Transformer-based architecture) will provide that. They're too prone to hallucinations.

However, I do think that they will pave the way towards another technology that will work better. Possibly some hybrid neurosymbolic approach. There are many researchers working on this, and the current hype around LLM will help fund them. Sadly, it will also add considerable amounts of noise that might hinder their ability to demonstrate the usefulness of their solutions, so no clue when that future happens, if it does.

At least compilers are deterministic and their operation can be easily inspected.

Said someone that never researched miscompilation issues or UB.

They are mostly deterministic.

LLMs can also provide the equivalent of an -S switch.

You are correct, of course, but the general consensus is that (in languages other than C++) compilers are largely close enough to deterministic that the difference doesn't matter. LLMs, by design, don't even attempt to go in this direction.

Not entirely sure what I'd do with an LLM -S switch. Debug the output/intermediate representation of the LLM, knowing that the next time I press "enter", it's probably going to give me an entirely different output?

It won't be much different from human computers in that regard, isn't after all what everyone is looking for as replacement?

Probably, yes.

But then, aren't we all happy that we moved from human computers and to electronic computers with programming languages and compilers?

The first is a bug in the compiler, the second is a bug in your code.

Not everyone agrees, see Linus.

At that point “building software” goes away as a distinct activity. Everything is a conversation with an AI, that builds software to answer questions or perform tasks you request as needed.

you forgot the pesky “security” aspect of system :)