alt Hacker News> The prompts are not analogous to a higher level of abstraction in this way; they are analogous to JIRA tickets.
Your first prompt could be instructions to guide creation of a spec, which leads to a test suite you personally validate, which leads to code to pass those tests in a deterministic way. Then it is your job to review and QA it until it is quality enough to submit to a peer for code review.
There are many many ways to use these tools and carefully monitor and quality control what they write like a good engineering lead might, even if they do not type much code themselves at work. The job of the most senior engineers often ends up being heavily biased towards reviewing code all day and maintaining quality control. This is already how things were before AI.
Torvalds reviews a -lot- of code and writes very little now.
The reason TDD never really caught on is because it doesn't really work. You don't know in advance what tests need to exist. A test suite is not sufficient to understand the program. Nor is a spec sufficient to understand the program. You have to read the program to understand the program. A spec is English and a test suite is like a converging upper and lower bound to an unknown value. Neither are good enough.
Also, the staff engineers who review code all day typically do not really understand the program either. They understand the spec and they have a model of how things should work such that they can answer "should" questions, but they cannot tell you what exactly is going on in the depths of the program; that's not their job. The tools are not capable right now of creating a quality program that the operator only understands at a conceptual level. Again, someone has to actually know, still.