One of GitHub Copilot’s well known strengths is writing boilerplate code. But in the past, what, 10 years? There has been less boilerplate to write as languages have improved. I’ll take Objective-C and Swift for example: Language features have removed specific known boilerplate, like replacing retain/release with ARC and autosynthesizing protocol conformances. And as of Swift 5.9, macros can practically address cases of boilerplate that would have been a burden to build into the base language.
For instance, the stored properties of a type decorated with the @Observable macro will track incoming access during a view update, in order to re-invoke that view update when their values change.
That’s a whole lot like a pattern my projects used to use around 2015: We’d have a UIViewController with some stored properties that could change, and we’d note certain parts of the view that needed updating based on which properties they accessed. It came down to a didSet on each stored property to run each of the update___ functions that depended on them. Of course wiring that up was the programmer’s job, but the pattern was very straightforward. And here it is done for us, just tracked dynamically, and having the tracking installed by a macro.
It is said, many things we know as “design patterns” from the object oriented world are, from the perspective of macro-heavy languages like Lisp, an opportunity to DRY.
Boilerplate elimination and limited token context windows are two reasons I would rather use AI tools with languages that are nice and terse in the first place.
In any case, I think Copilot will continue to shine in one-shot, “how can I write this code” scenarios, and with languages that aren’t getting any shorter.