Something that occurred to me the other day is that AI has turned writing high-quality software from a P problem into an NP problem.
Writing high-quality software used to be (in a loop):
(1) Read and understand a large, complex, and probably messy codebase
(2) Formulate a problem
(3) Design a solution for it
(4) Implement a solution for it that fits well into existing contours
(5) Verify that solution, and goto (1-4) if more iteration is needed
This is the process now:
(1) Formulate a problem (and describing it to the AI)
(2) Verify the solution that the AI gives you, and goto (1) if more iteration is needed
Some people seem to think that (1) is the whole name of the game now. This is COMPLETELY missing the point of the tool, though. It's supposed to get rid of the polynomial-time part of the software-development lifecycle. It's not supposed to make it O(1), and pretty much all of the AI-slop trash I see go by has clearly never had a human actually look at what it's producing.
None of this is surprising I guess, but if you consider yourself to be a strong engineer and tend to hold a high bar, I think it's very important to bear this in mind. ""Prompt engineering" and "context window engineering" are important (those are encapsulated by (1) above), but you have to also do the verification and meaningfully look at what's coming out the back end of the AI to fully bake what it's giving you.
It's kind of baffling to me that people don't do this, because you can still 10-20x+ your productivity, _and_ produce even better-quality code than you were before. It would be like someone deciding to bake 1000 cookies to 60% done instead of baking 700 cookies to 99.99% of the way done, when before you used to bake a batch of 24 to 100% of the way done in the same amount of time.
English
