I agree my analogy does’t fully capture the nuances, and can get behind your “tool use” alternative. Either way, I think our transition to AI is going to have to be deeper than trying to shoe horn agents into our existing workflows.
Not at all trying to downplay the stress/grief of others in this thread trying to navigate this challenging environment!
I only just recently hit the acceptance stage for agentic coding, so I don’t have a lot of experience (and I’m not a manager). One thing I have not been letting it do is commit for me. This probably ruins some workflows where one person has a bunch of agents working on several features at once, though I haven’t reached the level of acceptance where I think that is in any way even a remotely good idea for production apps 
In any event, manually committing forces me to work in a more careful way, reviewing each step of the output along the way (the commit message itself can still be generated, of course).
I could not agree this analogy is somewhat accurate.
C is 14 years younger than LISP. And C has not abstracted the CPU by any means. LISP did.
That’s not Java abstracted the memory management but the virtual machine per se. Erlang had VM a decade before Java has been ever created. LISP had a garbage collector almost 40 years before Java.
Abstracting syntax means operating on MetaAST level, not on another ad hoc, informally-specified, bug-ridden, slow implementation of half of COBOL (which each and every natural human language is.)
Allowing code assistants to abstract the syntax is a critical mistake leading to an unsupported sloppy software monsters, born to be dead in a year. Code assistants might produce a valuable result if and only if the developer knows exactly how the code is to be written in details, what language is to be used, what paradigm is most suitable for this case etc.
I don’t have an answer and I’m increasingly worried that the solution might lie in the realm of hiring. Teams will have to hire people with very similar views on agentic coding and LLM usage. Otherwise they’re risking to play a repeated prisoners dilemma game where people who put more human effort into work consistently lose and burn out.
Good news is that we’ll never have to argue over tabs vs whitespaces anymore or stuff like that. None of that is important comparing to your LLM usage pattern.
Huh? As a person who cares about typography since the XXth century, the argument over m-dashes (—) vs double-dashes (--) vs dashes (-) in each and every documentation piece/blog post is literally my nightmare nowadays.
I humbly beg your forbearance of my poor choice of exact syntax. I nevertheless stand by my general claim and hypothesis.
I don’t know what you’re talking about. The only conversation I know around m-dash is not about m-dash but around LLM generated writing
To keep my response tied to the OP, my prediction is that we are going to lose this battle, and quickly. I think that in the next 6-12 months, many many dev teams will abandon their pride in the “old” craft and embrace the speed at which new features can be shipped. I’m not saying I endorse this shift.
This conversation makes me wonder if we can solve the problem with new dev tooling. What does linting look like in the agentic era?
That’s exactly what a TAB user would say 
I have to explicitly note that this is a joke
If you read the topic name carefully, you will see that this is the discussion about the practical details we are all trying to work out. Your whole post is missing the topic
I am acknowledging the current challenges faced by OP and others while also stating my belief that this will soon be a moot point because our industry will bend to the pressure of this new agentic paradigm, and that the old ways will no longer be relevant. Part of me hopes I’m wrong about that.
[edit: I can see your point that my comments still don’t contribute to what to do about this. I, too, am still trying to figure that out.]