This is honestly a lot of the problem: code generation tools can output thousands of lines of code per minute. Great, committable, defendable code.
There is basically no circumstance in which a project’s codebase growing at a rate of thousands of lines per minute is a good thing. Code is a necessary evil of programming: you can’t always avoid having it, but you should sure as hell try, because every line of code is capable of being wrong and will need to be read and understood later. Probably repeatedly.
Taking the approach to solving a problem that involves writing a lot of code, rather than putting in the time to find the setup that lets you express your solution in a little code, or reworking the design so code isn’t needed there at all, is a mistake. It relinquishes the leverage that is very point of software engineering.
A tool that reduces the effort needed to write large amounts of human-facing, gets-committed-to-the-source-tree code, so that it’s much easier and faster than finding the actual right way to parse your problem, is a tool that makes your project worse and that makes you a worse programmer when you hold it.
Maybe eventually someone will create a thinking machine that itself understands this, but it probably won’t be someone who charges by the token.
This is why Pull Requests and approvals exist though. If I am reviewing a PR and it takes 400 lines of code to do something that should be 25 lines, I’ll pick that up in my review, leave feedback, and send it back.
This is honestly a lot of the problem: code generation tools can output thousands of lines of code per minute. Great, committable, defendable code.
There is basically no circumstance in which a project’s codebase growing at a rate of thousands of lines per minute is a good thing. Code is a necessary evil of programming: you can’t always avoid having it, but you should sure as hell try, because every line of code is capable of being wrong and will need to be read and understood later. Probably repeatedly.
Taking the approach to solving a problem that involves writing a lot of code, rather than putting in the time to find the setup that lets you express your solution in a little code, or reworking the design so code isn’t needed there at all, is a mistake. It relinquishes the leverage that is very point of software engineering.
A tool that reduces the effort needed to write large amounts of human-facing, gets-committed-to-the-source-tree code, so that it’s much easier and faster than finding the actual right way to parse your problem, is a tool that makes your project worse and that makes you a worse programmer when you hold it.
Maybe eventually someone will create a thinking machine that itself understands this, but it probably won’t be someone who charges by the token.
This is why Pull Requests and approvals exist though. If I am reviewing a PR and it takes 400 lines of code to do something that should be 25 lines, I’ll pick that up in my review, leave feedback, and send it back.