I use agents to build exactly what I want like I am pair programming with a jr engineer, and review every line of final output before I make a PR.

I would have zero tolerance if anyone that did anything less in my orgs. Owning and understanding the code you submit is the one job that matters most now.

With AI people aren't reading, writing, or thinking about the code. I would not say something that helps me remember a function name is comparible.

Tools like Resharper and IntelliSense make me more productive but don't inhibit my thinking, which is what LLMs seem to do.

It's really not.

Number and order of arguments, long names, etc. are just bureaucracy. Knowing them doesn't mean you understand the codebase any better than if you rely on the IDE for it.

It's a bit like remembering the exact date an historical event happened vs. knowing at which point in history it did, what other events relate to it, etc. Neither makes you better or worse at knowing and understanding the history of the event.

Juniors are only in trouble if us seniors stop hiring, training and mentoring. Don’t.

We need to continue the tradition of elevating humans through mentoring or we won’t have a future scaffolding for work to be done.

Delegation implies a specification and responsibility, both with don't exist for LLMs.

Desktops don't abstract CLI commands. Both are different interfaces on the same thing underlying. Both coreutils and Windows Explorer are "abstractions" (as you call them, but they're actually interfaces) on filesystems.

Claude won’t tell you why it did something. Instead, it will generate a probable explanation. The two are very different

Yep. I do so much work with Claude on product requirements and architecture before a single line of code is written, and test coverage is extreme.

If I need to understand a specific line of code it means I did something wrong in planning or in requirements for testing.

> You can just ask Claude why it did something

But will Claude give you an authentic rationale and a traceable, verifiable "line of reasoning" for those things? Or will it just construct the next plausible Markov chain built on whatever Reddit thread it ingested at random?

You can ask Claude or any LLM for citations, and it will RAG them out ex post facto. Those actually aren't citations, they're just web searches for related articles, and they don't necessarily support the assertions that you're asking to cite.

I am sure that Claude and the others can produce intermediate logs of their inference and "reasoning" process while they are processing stuff, but can they really go back within the context window and construct an authentic apologia for a specific thing when you ask for it?

> and it will tell you [why it did something]

No, it will invent retroactively a plausible sounding reason why someone might have done it that way. These are very different things.

An LLM has no special insight into itself and has no reasons. It will come up with something that is convincing, and it will change based on the word choices you used in the request. You can observe this by asking it why it did something that it didn't actually do.

Dementia patients also do this.

I am pretty tired of this analogy because it does not hold up to scrutiny. The purpose of a programming language is to describe a logical routine in deterministic nonambiguous language. A program is a set of nonambiguous instructions. Heightening levels of abstraction traditionally did not result in less understanding of the program's high-level routine.

An example: 'read input from CLI, do this specific transform on it, send log with this text to external service, then output transformed data to CLI' is a program. Going up the abstraction levels from assembly to Ruby, you always know the "What" of the program, while you understand less of the "How" at each step. This is not the case with LLMs used in the common way. The problem with LLMs is that you no longer have a grasp of the "What", because you are not reading the code; you may have memorized the ambiguous English "What" that I wrote above, but that is not sufficient to understand the true behavior because English is not sufficient to represent it; it must be represented in a programming language. (What is 'read'? What is 'send'? What happens with errors?) By the time you have sufficiently represented the program in English to be nonambiguous, you've written more text than the code would have been, with just as much rigor.

So LLMs represent a fundamental difference to traditional abstractions: the user has lost the understanding of what is actually happening, because they are prompting ambiguously, and thus they cannot possibly have a grasp of the behavior, because the behavior is not defined in their prompt. In other words, they are programming in a new programming language that has a ton of undefined behavior that just randomly happens. No one could understand the What of their program when using such a language, unless they compiled it to a nonambiguous language and then understood that instead.

Of course it is possible to read and understand the code output by the LLM. It is even possible to build a whole knowledge graph in your head, as you traditionally would, and have a pretty full understanding of the whole thing. But, you are always doing this with the outputted code, not with the inputted prompts. The prompts are not analogous to a higher level of abstraction in this way; they are analogous to JIRA tickets. You don't have to read the assembly to understand your program, but you do have to read the LLM outputs.

The other issue is that the above paragraph's process of understanding is discouraged. The time taken to fully understand the outputs approaches the time it would have taken to write them yourself, so is very rarely done, and that increasing rarity of understanding is what we are concerned about. The programmers are moving from an understanding of the program into an understanding of the JIRA tickets that produced the program; they are becoming product managers. The thing is, currently you still need someone who understands the program beyond the level of a product manager in order to retain maintainability and quality. Maybe in the future you won't, but right now you do.

No. Nada. Wrong.

With compilers, you still had to think in depth about the code, write it, develop and maintain muscle memory, understand what you were doing.

Many are not doing any of that, and coding is a skill you need to constantly practice.

Right! Exactly! You get it!

Just like when Boeing decided that their QA process should be abridged to save wasted time and money!

And that worked perfectly.

(edit: rereading I think maybe you don't support not reviewing all of LLM code you submit, but the above was written with another impression)

Completely wrong generalization.

I'm a person who is over-reliant on LLMs, doesn't know how most of the things in the codebase work, and is atrophying both in programming and in general cognition.

I used to care, a lot. And I still do.

I'm not dumb. I care a great deal and I always have. I've just never been good at programming.

When I recently found a small bug in how NTP is implemented in Home Assistant OS that was affecting my use of it, I thought about just reporting that bug.

But I set the bot forth to work on corrective measures, instead.

The first proposed fixes were overbearing and awful. Maybe they'd have worked but it hurt my soul to look at them. I couldn't accept them -- not for my system at home nor for anyone else's.

Through a laborious process (that many here could have skipped entirely), I eventually got what I feel is a cromulent fix down to a few lines of changes in an init script.

I didn't write it. All I did was direct (and sometimes brow-beat) the bot, rejecting things over and over while optimizing at a high level until it produced an acceptable result.

I now have a fix that is tidy-enough that it can be applied to running systems. It is easy to understand what it does, and why it does it -- even for me. Perhaps I should submit a PR...

> They just don't care. They didn't before either.

...but this kind of blanket mentality really puts a damper on my willingness to do so.

They cared enough to do good work before, so I don't think that your explanation suffices here. From my observation (not just with their programming but in other interactions), it truly is that using an LLM has made these people less intelligent than they were before.