Agree with those 2 camps. The latter camp is all cheered up which is nice, but they should be asking the question if their solution is valuable enough to be maintained. If so, you should make all generated code your code, exactly in the form it needs to be according to your deep expertise. If not, congratulations, you have invented throw-away code. Code of conduct: don't throw this code at people from the former camp.
Or to phrase it more succinctly: if you are in camp 2 but don't have the passion of camp 1, you are a threat for the long term. The reverse is dangerous too, but can be offset to a certain extent with good product management.
> If so, you should make all generated code your code, exactly in the form it needs to be according to your deep expertise.
This is solved problem with any large, existing, older code base. Original writers are gone and new people come on all the time. AI has actually helped me get up to speed in new code bases.
> If so, you should make all generated code your code, exactly in the form it needs to be according to your deep expertise.
Is this also true of all third party code used by their solution? Should they make all libraries and APIs they use their own in exactly in the form it needs to be according to their deep expertise? If not, why not?
If so, does this extend to the rest of the stack? Interpreters, OSes, drivers? If not, why not?
No. They don't need to maintain, debug and extend those libraries.
Well, what if one becomes unmaintained or has issues that only affect your project. Why is that uncontrolled code different to generated code? Is it specifically that it's generated?
This isn't a trick question, BTW. It's a genuine attempt to get to the rationale behind your (and the GP's) stance on this.
In particular, the GP said:
> Or to phrase it more succinctly: if you are in camp 2 but don't have the passion of camp 1, you are a threat for the long term.
That hints I think at their rationale, that their stance is based on placing importance on the parts of software development that they enjoy, rather than any logical basis.
> Well, what if one becomes unmaintained or has issues that only affect your project.
This happens, but very rarely compared to changes in your own code base. If a library breaks, you can usually find an alternative, but even in that case you need to know how to modify your own code.
The difference with generated code is that you are tasked to maintain the generated code.
> This happens, but very rarely compared to changes in your own code base.
I don't think this is true, but say we accept it.
> The difference with generated code is that you are tasked to maintain the generated code.
Is this a task that LLMs are incapable of performing?
> Is this a task that LLMs are incapable of performing?
That's what people tend to report, yes.