[jeffbr13]

I’m not sure I have much sympathy for the problem. Copilot is going to force everyone to move up the abstraction stack.

I absolutely disagree with how Copilot has been trained on the intellectual property of others, and I think Microsoft/GitHub should be taken to court over it (and I say that as an IP cynic, but if you play that game, you should stick by the rules), but this technological cat is out of the bag.

Students (and everyone else) should be thinking much harder about how they test and verify the behaviour of any given piece of code and how they design systems to stick together. This class of technology is going to automate away many of the jobs where you just pump out code. This is fine. It’s no different to someone inventing a burger-flipping machine, and I’m sure many here would agree it’s better if humans didn’t have to flip burgers for a living (modulo solving employment being necessary for a decent/tolerable existence). It may turn out that the next step in software productivity is not a new generation of cool and highly-abstract declarative programming languages (4GL) but simply automating away the drudgery of writing code in the extant kinda advanced languages (3GL) which are ‘good enough’.

Arguably Copilot doesn’t change much about the software development process. You can already get software developed pretty cheap if you farm it out to low-quality contractors or a lot of juniors straight out of school. There’s a whole branch of the industry that will hire anyone straight out of university to manage and front development teams in South Asia. But as we say, quantity has a quality all of its own. And the only way to manage software (not code) quality with this method is to verify and test that the deliverables actually meet your criteria and expectations.

It’s currently a great time to focus on TDD/BDD and code specification because our time spent on the D is about to get a lot shorter. There is still a place for artisanal hand-crafted code. But the mechanical loom has arrived.