Automated Coding and the Future of Programming
How automation is likely to change professional software development.
Enterprise architecture (source: Pexels)
At Microsoft’s Build conference, Microsoft CTO Kevin Scott talked about an experimental project in which an AI, trained on code in GitHub, actually creates programs: it generates function bodies based on a descriptive comment and a message signature. (Skip to 29:00 of the video.) Along similar lines, an unrelated research paper reports on unsupervised translation of programs from one language to another–indeed, probably an easier task than natural language translation.
Microsoft’s demo is, well, a demo, and the research paper is a research paper. Microsoft’s AI was able to provide method bodies for some relatively simple functions; it was obviously rather limited. It begs the question of exactly how you write the comment that tells the AI what to do; are we just replacing a description in a precise programming language with a description in an ambiguous, imprecise human language? I’m sure that training the model costs more than hiring a developer to write a few short functions. And while it’s easy for me to believe that software can translate some simple code from COBOL to Rust, I can only imagine that it would be horribly confused by the multitude of tricks programmers used in the 1960s and 1970s to deal with computers that had, by modern standards, miniscule memories. Programming jobs are not going to disappear tomorrow.
Learn faster. Dig deeper. See farther.
Nevertheless, it’s important for us to think about what automation might mean for the future of programming. Is this a glimpse of the future, and if so, what is it telling us? What can we learn from it? Programming will increasingly be automated; and, as someone who got started writing assembler on a PDP-8, I can tell you that programming is already highly automated, and that a good optimizing compiler is already an advanced AI system that takes your hints and turns them into working code.
Programming is not going to “go away” or “become obsolete.” However, its meaning will change. I’ve previously written about blue- and white-collar programmers: programmers who connect things, and programmers who design the things that are connected, and build the tools to connect them. These are different (though highly overlapping) skillsets. And while Microsoft’s demo may show that programmers may eventually be liberated from the task of coding up simple functions, the code-generating engine was certainly built by a team of programmers, and possibly a large one. The programmers who write the higher-level tools, like Microsoft’s coding engine itself, can breathe a sigh of relief. As can programmers who design APIs, since you still have to provide the function/method signatures.
And the blue-collar programmers who connect things? While this demo could spit out functions, I saw few signs that it could build larger systems out of the functions that it wrote. Although it had the ability to call functions that it had written, it could not put together a large program from a written specification. It might be able to spit out a simple bill, but it certainly couldn’t spit out a complete billing system. A project for future research? No doubt, but that’s probably dozens of years out. Programmers who connect things—the plumbers of the digital world—are also safe.
But this feat still begs the question about what we mean by programming. In the video, Kevin Scott talks about reducing the time programmers spend on dull, repetitive tasks. Yes, that’s what we all say about AI: it will reduce the time spent on dull, repetitive tasks and free more time for creative work. Let’s break that down, though. Most of programming is specifying, in excruciating detail, how to execute some process. That can be dull, it is often repetitive, and it is certainly error-prone. And we really need to think more about what programming ought to be. To use Scott’s word, what are the “creative” aspects of programming?
I’m not sure that “creative” is the right word. Back in the 1960s and 1970s, more programmers were called “analysts.” That job title is still in use, but it’s not all that common: Glassdoor shows about 10,000 jobs for “programmer analyst,” 44,000 for “programmer,” and 100,000 for “software engineer.” Monster shows about 20,000 for “programmer analyst,” 300,000 for “programmer,” and 170,000 for “software engineer.”
While the job may have differed little from what it is now, let’s think about what “analyst” means. Analysts analyze a problem; they think about what the problem is, and how to solve it effectively. They think about breaking it up into parts. They may even think about whether it should be solved; they might think about how it should be solved, what ethical issues it raises and how those issues should be handled. Can the software be abused? If so, how? What steps can be taken to prevent abuse? And analysts need to think about how people will use the software: what’s the user interface, what’s the user experience, can it be used by people with disabilities?
In O’Reilly’s Software Architecture Fundamentals Superstream, Thoughtworks’ Rebecca Parsons said that “analysts” were essentially doing software architecture: making big picture decisions about what the software should do, and how it should be built. Analysts and architects need to understand the business case. They need to present decisions about software systems to management in business terms. She used the need to test a backup strategy as an example: rather than telling the CEO about the technical details, just say “This test will show us how long it will take to get back online if the system crashes on the busiest retail day of the year.” That’s what an analyst does.
Our emphasis on writing code, and on measuring productivity by “lines of code,” is myopic. Just look at all the wonderful (and absolutely necessary) tools we have for building, testing, archiving, and deploying code. But those tools, essential and revolutionary as they are, don’t address the real issue: are we solving the right problems? There are thousands of applications out there that pass every unit test, every integration test, and every acceptance test, but are still awful to use. And we are learning that there are new dimensions to software that we’ve rarely thought about: are there groups who need to use our software and can’t? Does your software support accessibility? Can it be used by people who don’t have reliable access to computers and to networks? The work of an organization like Code for America isn’t technically profound or deep. What’s radical about a product like GetCalFresh was the act of re-engineering the system to make it usable by the people who need to use it. And we need a lot more analysis like that.
There’s a lot more to programming than just slinging code and writing functions. The most important parts of the job have nothing to do with writing quicksort on the whiteboard in an interview. There’s a lot to think about; and currently, programmers spend too much time rushing code out the door to meet a release date than they spend thinking about the bigger picture. That’s almost always someone else’s job. But whether or not it gets into production, Microsoft’s research gives us an opportunity to think about what programming really means. What’s the real job? What are we really trying to accomplish?