The likes of Copilot are ok at boiler-plate if it has an example or two to follow. It’s utterly useless at solving problems though.

Soon our excitement over CICD and shipping every minute will look very naive. There’s a future coming where every request execution could be through a different effective code path/base.

Plenty of new jobs from AI because of AI code, vibe coding.

CoT fixes this. And in a way, non CoT can retrigger its context by reading the code.

In a similar fashion, engineers remember their context when reading code, not necessarily by keeping it all in their head

"That code is old and the paradigms are dated" is uttered with the same disdain as "That shed is old and the floorboards have dry rot"

The best thing that happens to a startup is actual traction and paying customers, because once that happens the refactoring churn is usually shoved to the back burner

People aren't thinking far enough, why bother with programming at all when an AI can just do it?

It's very narrow to think that we will even need these 'programmed' applications in the future. Who needs operating systems and all that when all of it can just be AI.

In the future we don't even need hardware specifications since we can just train the AI to figure it out! Just plug inputs and outputs from a central motherboard to a memory slot.

Actually forget all that, it'll just be a magic box that takes any kind of input and spits out an output that you want!

--

Side note: It would be really interesting to see a website that generates all the pages every time a user requests them, every time you navigate back it would look the same, but some buttons in different places, the live chat is in a different corner, the settings now have a vertical sidebar instead of a horizontal menu.

It's the responsibility of the coder/user/collaborator to interact with the code and suggestions any model produces in a mindful and rigorous way. Not only should you have a pretty coherent expectation of what the model will produce, you should also learn to default/assume that each round of suggestions is in fact not going to be accepted before it is. At the very least, be prepared to ask follow-up questions and never blindly accept changes (the coding equivalent of drunk driving).

With Cursor and the like, the code being changed on a snippet basis instead of wholesale rewriting that is detached from your codebase means that you have the opportunity to rework and reread until you are on the same page. Given that it will mimic your existing style and can happily explain things back to you in six months/years, I suspect that much like self-driving cars there is a strong argument to be made that the code it's producing will on average be better than what a human would produce. It'll certainly be at least as consistent.

It might seem like a stretch to compare it to taking drugs, but I find that it's a helpful metaphor. The attitude and expectations that you bring to the table matter a lot in terms of how things play out. Some people will get too messed up and submit legal arguments containing imaginary case law.

In my case, I very much hope that I am so much better in a year that I look back on today's efforts with a bit of artistic embarrassment. It doesn't change the fact that I'm writing the best code I can today. IMO the best use of LLMs in coding is to help people who already know how to code rapidly get up to speed in domains that they don't know anything about. For me, that's been embedded development. I could see similar dynamics playing out in audio processing or shader development. Anything that gets you over that first few hard walls is a win, and I'll fight to defend that position.

As an aside, I find it interesting that there hasn't been more comparison between the hype around pair programming and what is apparently being called vibe coding. I find evidence that one is good and one is bad to be very thin.

Everyone should be asking AI to write lots of tests- to me that's what AI is best at. Similarly you can ask it to make plans for changes and write documentation. Ensuring that high quality code is being created is where we really need to spend our effort, but its easier when AI can crank out tests quickly.

PS: Also, some people act as if they have to remove their common sense when using Gen AI code. You have to review and test the generated code before merging it.

Still, for some things we weren't wrong, our weird hacks where do to crazy edge cases or integrations into systems designed in a different era. But we where around to help assess if the code could be yanked or at least attempt to be yanked.

LLM assisted coding could technically be better for technical debt, assuming that you store the prompts along side the code. Letting someone what prompt generated a piece of code could be really helpful. Imagine having "ensure to handle the edge case where the client is running AIX 6". That answers a lot of questions and while you still don't know who was running AIX, you can now start investigating if this is still needed.

Naur argued that complex software is a shared mental construct that lives in the minds of the people who originally build it. Source code and documentation are lossy representations of the program—lossy because the real program (the 'theory' behind the code) can never be fully reconstructed from them.

Legacy code here would mean code where you still have the artifacts (source code and documentation), but have lost the theory, because the original builders have left the team. That means you've lost access to the original program, and can only make patchwork changes to the software rather than "deep improvements" (to quote the OP). Naur gives some vivid examples of this in his essay.

What this means in the context of LLMs seems to me an open question. In Naur's terms, do LLMs necessarily lack the theory of a program? It seems to me there are other possibilities:

* LLMs may already have something like a 'theory' when generating code, even if it isn't obvious to us

* perhaps LLMs can build such a theory from existing codebases, or will be able to in the future

* perhaps LLMs don't need such a theory in the way that human teams do

* if a program is AI-generated, then maybe the AI has the theory and we don't!

* or maybe there is still a theory, in Naur's sense, shared by the people who write the prompts, not the code.

There was an interesting recent article and thread about this:

Naur's "Programming as Theory Building" and LLMs replacing human programmers - https://news.ycombinator.com/item?id=43818169 - April 2025 (129 comments)

Is that really true? A human programmer has hidden states, i.e. what is going on in their head cannot be fully recovered by just looking at the output. And that's why "Software evolves more rapidly under the maintenance of its original creator, and in proportion to how recently it was written", as is astutely observed by the author.

But transformer based LLMs do not have this hidden state. If you retain the text log of your conservation with an LLM, you can reproduce its inner layer outputs exactly. In that regard, an LLM is actually much better than humans.

Real issue is that AI code is not your code in terms of copyrights so if you want to run a company on that code and someone makes a copy you don't even have grounds to argue.