Near future, that seems right, further out I am guessing GPT-4 could enable the level to a couple years of real-world skill instead of two semesters.
With the pipeline as such:
business need -> tasks/cards outlined -> tests written -> code written -> refactor as changes needed
There is still a need for someone to manage the business to task relationship. Let the business person prompt, and the engineer to confirm the prompt output tasks makes sense technically, edit for any errors, and do any modifications needed for specific architectural choices or desired abstractions. With well-enough defined tasks, you can start to write the tests that conform to those tasks. Again, engineer checks the prompt-output, ensuring the tests line up with the card, making any edits as required. With tests written, the code can be written such that it conforms to the tests for correctness, cards for general I/O, and business use-case for domain-specific variables and such.
It's the same domain splits that occur in our current day-to-day practice that are cause for pain. Business person and product person have a miscommunication, the wrong tasks/cards get outlined. The task writer and the test writer have a miscommunication, the tests get written poorly and problem the business is trying to solve gets murky. The tests are written poorly so the code is written poorly. The code is written poorly so the product must be refactored.
The understanding of each others intent must be had and communicated effectively or the downstream problems will mount quickly. It's in this area where GPT-3 still seems a bit lacking, and maybe GPT-4 will resolve the issue a bit. Another worry I have with this sort of model is the spaghetti and debuggability a misunderstanding may have. When code is written more slowly, as is the case today, one is able to mentor the junior and provide feedback over the process. This not only prevents a huge mess, but allows the team to resolve any initially unsaid misunderstandings.
The speed and scale of messes one can now create with this tool is completely massive!
With the pipeline as such: business need -> tasks/cards outlined -> tests written -> code written -> refactor as changes needed
There is still a need for someone to manage the business to task relationship. Let the business person prompt, and the engineer to confirm the prompt output tasks makes sense technically, edit for any errors, and do any modifications needed for specific architectural choices or desired abstractions. With well-enough defined tasks, you can start to write the tests that conform to those tasks. Again, engineer checks the prompt-output, ensuring the tests line up with the card, making any edits as required. With tests written, the code can be written such that it conforms to the tests for correctness, cards for general I/O, and business use-case for domain-specific variables and such.
It's the same domain splits that occur in our current day-to-day practice that are cause for pain. Business person and product person have a miscommunication, the wrong tasks/cards get outlined. The task writer and the test writer have a miscommunication, the tests get written poorly and problem the business is trying to solve gets murky. The tests are written poorly so the code is written poorly. The code is written poorly so the product must be refactored.
The understanding of each others intent must be had and communicated effectively or the downstream problems will mount quickly. It's in this area where GPT-3 still seems a bit lacking, and maybe GPT-4 will resolve the issue a bit. Another worry I have with this sort of model is the spaghetti and debuggability a misunderstanding may have. When code is written more slowly, as is the case today, one is able to mentor the junior and provide feedback over the process. This not only prevents a huge mess, but allows the team to resolve any initially unsaid misunderstandings.
The speed and scale of messes one can now create with this tool is completely massive!