Claude Code was transformative and it made me realize that something very incredibly significant had occurred. Letting the LLM "drive" like this was inevitable. Now I see just exactly how this will transform our industry. I'm a little scared about how it will end for me/us, but excited for now.
Letting an LLM drive in an agentic flow removes you from the equation. Maybe that's what some want - but I've personally found I end up with something that doesn't feel like I wrote it.
Now... get off my lawn!
On a more serious note, I do think that the maintenance aspect is a differentiator, and that if it’s something that you end up committing to your codebase then ownership and accountability falls to you. Externally sourced libraries and frameworks ultimately have different owners.
In particular, the PR author's response to this question:
> Here's my question: why did the files that you submitted name Mark Shinwell as the author?
> > Beats me. AI decided to do so and I didn't question it.
The same author submitted a similar PR to Julia as well. Both were closed in-part due to the significant maintenance burden these entirely LLM-written PR's would create.
> This humongous amount of code is hard to review, and very lightly tested. (You are only testing that basic functionality works.) Inevitably the code will be full of problems, and we (the maintainers of the compiler) will have to pay the cost of fixing them. But maintaining large pieces of plausible-in-general-but-weird-in-the-details code is a large burden.
Setting aside the significant volume of code being committed at once (13K+ lines in the OCaml example), the maintainers would have to review code even the PR author didn't review - and would likely fall into the same trap many of us have found ourselves in while reviewing LLM-generated code... "Am I an idiot or is this code broken? I must be missing something obvious..." (followed by wasted time and effort).
The PR author even admitted they know little about compilers - making them unqualified to review the LLM-generated code.
I catch a lot of nonsensical and inefficient code when I have that "back and forth" described above - particularly when it comes to architectural decisions. An agent producing hundreds or thousands of lines of code, and making architectural decisions all in one-go will mean catching those problems will be vastly more challenging or impossible.
I've also found reviewing LLM generated code to be much more difficult and grueling than reviewing my own or another human's code. It's just a mental/brain drain. I've wasted so many hours wondering if I'm just dumb and missing something or not-understanding some code - only to later realize the LLM was on the fritz. Having little or no previous context to understand the code creates a "standing at the foot of Mt. Everest" feeling constantly, over and over.
absolute opposite here.
LLMs , for better or worse, generally stick to paradigms if they have the codebase in front of them to read.
This is rarely the case when dealing with an amateur's code.
Amateurs write functional-ish code. TDD-ish tests. If the language they're using supports it types will be spotty or inconsistent. Variable naming schemes will change with the current trend when the author wrote that snippet ; and whatever format they want to use that day will use randomized vocabulary with lots of non-speak like 'value', or 'entry' in ambiguous roles.
LLMs write gibberish all day, BUT will generally abide by style documents fairly well. Humams... don't.
These things evolve as the codebase matures, obviously, but that's because it was polished into something good. LLMs can't reason well and their logic sometimes sucks, but if the AGENTS.md says that all variables shall be cat breeds -- damnit that's what it'll do (to a fault).
but my point : real logic and reasoning problems become easier to spot when you're not correcting stupid things all day. it's essentially always about knowing how to use the model and whatever platform it's jumping from. Don't give it the keys to create the logical foundation of the code, use it to polish brass.
garbage in -> garbage out ain't going anywhere.
I think LLMs are much more effective when you have a good understanding of a field and can work in the above way; their assistance is useful because I don't have time or brainpower to be an _expert_ in many of the fields I'm _knowledgable_ in.