Agreed with everything @kevinriggle wrote here. Another angle on this to try with people who simply do not understand what software engineering •is•:
AI can generate code fast. Often it’s correct. Often it’s not, but close. Often it’s totally wrong. Often it’s •close• to correct and even appears to work, but has subtle errors that must be corrected and may be hard to detect.
All the above is also true (though perhaps in different proportions) of humans writing code! But here’s the big difference:
When humans write the code, those humans are •thinking• about the problem the whole time: understanding where those flaws might be hiding, playing out the implications of business assumptions, studying the problem up close.
When AI write the code, none of that happens. It’s a tradeoff: faster code generation at the cost of reduced understanding.
2/
The effect of AI is to reduce the cost of •generating code• by a factor of X at the cost of increasing the cost of •thinking about the problem• by a factor of Y.
And yes, Y>1. A thing non-developers do not understand about code is that coding a solution is a deep way of understanding a problem — and conversely, using code that’s dropped in your lap greatly increases the amount of problem that must be understood.
3/
@inthehands My 30+ years as a dev disagree with the statement, "coding a solution is a deep way of understanding a problem", on semantics. Analyzing a solution is a deep way of understanding a problem. I've found that too many devs are in a rush to code and give short shrift to the analysis.
@inthehands I don't know if it's overly pendantic, because coding is the least thing in software development, which is why it is the ripest part for smart automation. (I felt the qualifier, "smart" was necessary, because there has been way too much dumb automation done already.)
@lwriemen
This is an overly pedantic quibble, though I agree with the underlying sentiment that people rush into coding too fast without thinking.
Doing the work of filling the things left between the lines for the reader to infer above: coding something •while thinking• — assessing the results, letting the ideas talk back and surprise, treating design and implementation problems as prompts to think about goals and context — is a deep way of understanding a problem.