Hi everyone! My name is Darren, and I work on Data Engineering at Mercari. For today’s Advent Calendar post, we’ll take a break from technical details and talk about the broader tech landscape. And tomorrow, we’ll hear the origin story of Mercari India’s Center of Excellence. Stay tuned for more great posts!
The explosive release of ChatGPT has changed overnight what many thought possible with generative large language models (LLMs). All of a sudden, a chatbot is replacing the Google/Stack Overflow cycle, but rather than simply returning answers, it’s able to generate runnable code. What does this mean for our future as engineers? How should we philosophically approach the steady development of ever more sophisticated models that can write better code than humans? What is an “engineer”, anyway? Today we’ll discuss how to apply an engineering mindset to the AI future, which is coming whether we like it or not.
Unless you’ve been living under a rock, you have likely seen screenshots of ChatGPT conversations flooding the internet over the last few weeks. ChatGPT is a large language model from OpenAI productionized as a chatbot service, and it has been fine-tuned to follow instructions and produce more human-pleasing output than some of its predecessors such as base GPT-3. Although the details have not yet been released, it is likely based on prior work from InstructGPT, which used a GPT-3 base combined with reinforcement learning from human feedback (RLHF) to coax the model into producing better output.
Aside from being able to write sonnets, summarize complicated concepts, and perform other feats of LLM magic, ChatGPT was apparently also trained on a huge amount of computer code and is able to answer technical questions with real, actual code. Well, game over, right? Are we out of a job because ChatGPT can code? Not so fast.
A better way to approach this question is to think about what we engineers actually do. At its heart, engineering is about solving problems. As you level up in engineering, you solve bigger and bigger problems, and you combine the pieces of knowledge you’ve acquired along the way into larger and more complex programs and systems. Will there still be problems left to solve if a chatbot can write your unit tests? Is the unit of code that an LLM can produce the final output for a system, or is it a piece that fits into a larger whole? Even as models produce larger and more complicated outputs ranging from classes to modules to entire programs, those programs will fit into systems of their own, and engineers will be putting them together and solving the inevitable systems problems that arise.
Another aspect to consider is what LLMs like ChatGPT are not good at. LLMs and other deep neural nets are probabilistic machines. Even if they are right 99% of the time, you wouldn’t let one loose writing unchecked code in a system that depends on things working 100% properly. Modern software systems are not designed to work probabilistically; they’re designed to work deterministically. Yes, many distributed systems are designed under the assumption of transient errors, disconnects, and unreliable parts, but that is epistemologically completely different from a system that is designed to work probabilistically from the ground up. Formal verification solves this problem to a degree, but even moderate size programs quickly become unwieldy to verify mathematically, and the Halting Problem does not disappear once “perfect” AI coders start submitting the majority of PRs.
A “programmer” is someone who just writes code. But an “engineer” solves problems and builds things. Perhaps the medium changes, but the story of computer science since the beginning has been one of engineers pushing the limits of current technology in order to develop better ways of executing computations. Eighty years ago, nascent computer scientists were coding by manipulating physical gears to perform complex calculations like those from the Enigma machine, or changing configurations of plugs and switches to program the ENIAC. Modern computers followed soon after, and before you know it, coding was entering binary into punch cards. Assembly came next, followed soon after by high level languages such as Fortran, COBOL, BASIC, and finally C in 1972. At each step, engineers have taken the existing solution and simplified it to make their jobs easier and to increase the scope of what they could build. Having a digital assistant that can understand code is yet another force multiplier for engineers. But it will take time to get used to the new world of co-programming with AIs, and a lot of egos are at risk of being hurt in the transition. There is no indication that this is the “final stage” for engineering. Rather, a more likely scenario is that we engineers are able to build ever more powerful machines because we’ve abstracted away some of the complexity of the previous generation of tools, systems, and languages.
Additionally, as AIs take more of the mundane work off our plate, the human aspects of the job become ever more important. Writing code is just one part of the engineer’s job. Figuring out what code to write is far more important. What questions need answering? What can we remove? How does my project fit in with other products and projects across the company? These questions often rely on human relationships in order to decide and solve, because not everything can or should be dispassionately optimized by a machine. Talk to your coworkers. Learn to discuss and defend your ideas in design docs, prose, and speaking. Develop relationships with engineers and non-engineers alike, because it is the human relationships that are the lifeblood of a company just as much, if not more, than the raw outputs produced by its workers.
Finally, in the face of new technologies, some humility is always prudent. We simply don’t know what the future will look like, and it is incredibly difficult for humans to comprehend exponential technology curves. The best way to prepare for the future is to keep learning about the new while always focusing on the engineering fundamentals that never change: Engineers solve problems and build things. We use tools to do so, and we make those tools work for us in order to multiply our abilities. We build abstractions in order to hide complexity, but as soon as a new complexity layer arises, we build yet another abstraction layer on top of it, with no end in sight.
Engineers are going to keep engineering, and I can’t wait to build the future with you.
