Humans and machines
Machines have long been around us. They multiply our powers and speed and unlock feats we never imagined before. Through all these years, the sophistication of these constructs grew exponentially. This increased their usefulness to the point that it is unimaginable for many of us to live without them. I am not just talking about computers and smartphones but anything mechanical that holds, moves, and processes data or raw materials. This includes almost everything powered by electricity. Some of these items became “smart”, such as refrigerators, radiators, watches, lightbulbs, coffee machines, etc.
418 I am a teapot. Who’s laughing now? 😳
All these devices rely on humans operating them by setting rules and letting them execute or constantly interacting with them. Supposedly, the “smarter” the device is, the better it serves us. That may be true sometimes, but you likely have had or heard contrary experiences.
It all comes down to humans communicating their wants and needs to these devices. Depending on the device, you might need special training to do this. Think of operating a grappling machine, using Autodesk 3DS Max, or heating your food in a microwave. The more complex your need, the more specialized the required knowledge. That’s where much engineering, especially software engineering, comes in.
The need for a programmer
Why can’t you tell an excavator to go and dig a hole there and use the dirt that comes out to level your yard in the back? For this seemingly menial task, you need a human, an operator (programmer, if you will) to understand what you want and translate this to turns of knobs, pushes of pedals, joystick movements, and switch flips inside the cockpit. Voila, after a few hours, a ton of dirt is moved as you wanted.
See what the human did here? He took abstract concepts and translated them into low-level commands. This isn’t too far from software engineering. The computer is a bit more complex, and you need much more knowledge to operate it (or do you? 🧐).
Couldn’t you tell your computer what you want and let it execute? We are not there yet, but getting really close. For now, you need software engineers who can translate between you and the machine.
What’s terrific is that software engineers can use this translation skill to create specific machine translators (software). Which can be operated by someone without software engineering knowledge. There aren’t a lot of such areas where the creator’s skills can be used to make the creator himself irrelevant.
Is that a threat to software engineering as a living? You bet!
Communicating intent
Software engineering is the craft of translating highly abstract (and sometimes wildly inaccurate) intents to concrete (machine-understandable) low-level executable commands. This also includes creating software that can do the above to some extent.
There is much more to software engineering than just writing code. There are product design, UX, UI design, security, quality assurance, and operations, to name a few. For the sake of simplicity, I won’t cover each separately, but the ideas hold solid in those cases. For some of these roles, AI is already more advanced than humans.
A new kind of interface
Back in the day, there were punched cards, and then we had assembly, C/C++, PHP, Java/C#, Python/Ruby, etc. For a while, there was an evident need for higher-level languages. Why? Building something in assembly or later in C took so much work. Many things were abstracted away, and you didn’t need to deal with them. For instance, you don’t need to worry about registers and opcodes in Ruby or memory in Python. Multiple layers, or translators (compilers, interpreters, VMs, runtimes), might take your code and produce something executable.
To interact with the computer, you must speak a “language” that it understands. Since software developers have already created a lot of software, your choices are abundant. However, some languages are more capable than others for specific tasks. Some are highly domain-specific (like CAD software), and others are more general, like Python. No matter which one you choose, you must translate your thoughts into that language/interface, like with the excavator operator we discussed earlier.
Enter natural language
Thousands of years have passed since humans started interacting with each other, and the best way to do that is through natural language. Not counting domain-specific “languages” like math.
For a long time, understanding natural language was an obstacle for machines. We thought a computing capacity similar to the human brain was necessary. As it turned out, the limit is much lower. GPT4 only contains about 1% of a human brain’s capacity (comparing the 1.76 trillion parameters of the model to the 150 trillion human brain synapses). And GPT4’s predecessor is also very capable of understanding us.
Having this capability will open up countless possibilities. I am not talking about reasoning and problem-solving capabilities (yet); I am only talking about its ability to understand natural language. Those previously unable to speak to machines will suddenly gain the power to do so. They will become “programmers.” This is like giving a powerful magic wand to someone who hasn’t gone to wizard school. Because there is simply no need, the wand is capable enough to serve your will without you needing to learn complex movements and spells.
More creativity will emerge, and human productivity will skyrocket. Everyone will be a programmer, and communicating one’s intent to a machine will become second nature. But wait, there’s more.
It’s not just intent
Given that such a machine exists, how will we avoid the King Midas problem? In the centuries-old classical story, a king named Midas wishes to turn everything he touches into gold. His wish is promptly granted. It works great, but after a while, he realizes he can’t eat or drink anything and accidentally turns one of his daughters into a gold statue. The moral of the story is to be careful what you wish for.
The central question of King Midas’s problem is whether we can make our choices smart enough so we don’t end up like the king of the story. It’s trickier than you think. Try telling straightforward tasks to a child who doesn’t want to comply or a colleague who wants to comply but has different standards. They will “invent” creative ways to conform to your request without doing them. What else do we need for this to work?
Truths, assumptions, and context
Given the above chance of misunderstanding communication, it might be surprising that complex societies exist. How is this possible, then?
There is no shortage of people who think they know objective reality. While an individually verifiable and generally agreed-upon reality is elusive, there are fundamental “laws” many of us agree on. These are not necessarily true or false, good or bad, but they hold a ground we can build. These include social norms, civic laws, physics, and sciences. And, of course, on top of all that, we have individual preferences, likes, dislikes, previous experiences, beliefs, etc.
Whenever we state an intent, we usually mean it in our own reality. We want the perceiver to have complete knowledge of us, including everything from our beliefs to our physical world. That’s what I call context.
This knowledge must exist in the machine before executing our intent. Without it, we can’t be sure of the outcome and can quickly end up like King Midas.
Okay, but how?
Today, part of this knowledge is pre-trained in these models; some are deduced as assumptions, and some are given directly along with the description of your intent. From this, it clearly follows that all three sources of information are critical: what was pre-trained and what the model generalized, what assumptions it deduced, and what extra context we gave it.
This is what software engineering is all about. It requires much understanding of machines, their language, different tools and systems, and the user. If an AI does most of this at an average quality, everyone will quickly become a “programmer,” as in a creator of programs. Or better, we won’t need applications at all.
Does it work?
In short, hell yes! I am a software engineer, so my prompts are probably not what a non-engineer would write. My success rate is high since I think in the above framework. When it doesn’t work right away, I can quickly point out what’s missing and have various ideas to fix it. It’s almost always the inaccurate context I provide.
This technology is fantastic if you know how to use it and understand its limitations. Here are a couple use cases I had fun with:
- I invented RxLang to generate NgRx states, reducers, effects, and actions. It’s mind-blowing. And, of course, it comes with tests as well
- Generate VSCode plugins. I knew what I wanted but did not know the ecosystem. It took me <7 minutes from idea to production.
- Debug race conditions and generate unit tests for it
- Generate partial implementations and lots of boilerplate
- Generate countless 0-shot PoCs, from an online web editor with an S3 backend to Python CLI tools
- And, of course, I had lots of discussions about alternative solutions, problem statements, and debugging sessions
The above only covers software development. GPT is also there if I want to learn quantum physics and the universe’s origins or understand various concepts. (Spoiler: I created explorian.io for that 🙃)
Shortcomings
I noticed a few exciting things. I call them shortcomings, but they are more observations than actual defects.
The levels of abstraction are key
When using Github Copilot, many of the suggestions I received seemed overly tied to the implementation. I would get suggestions a few abstraction levels lower than what I was looking for. Those suggestions were correct but too narrowly focused. Once I nudged the code into a new direction, Copilot would quickly follow.
The above is the same context problem I described earlier. Github copilot works by “Filling-in-the-middle”, sending lots of code to the model to provide more information. However, code is all it sends; it doesn’t send architecture diagrams, the conversation during planning, the whiteboard you drew before starting coding, or the transcript of your conversation with colleagues. Lack of access to these severely limits the LLM’s prediction capability. It still performs quite well.
Lack of initiative, agreeableness
Have you ever felt that all your ideas were great when you asked ChatGPT? You are not alone; many people’s ideas are exceptional, according to OpenAI’s GPT4 model. It is always friendly and doesn’t want to critique unless you instruct it directly. And even then, it manages to avoid calling out bullshit.
This can easily be improved with prompt engineering, but you have to be skillful to craft something that works well. Why? You can already do it yourself if you know what you want the model to critique. If you don’t, it takes some practice to write prompts that will do that. Imagine a copilot who doesn’t just follow your lead but takes on this role occasionally. For this to happen, it must know the destination you aim for and have more context about the project.
Have no doubt, this is coming. The more data and context you feed an AI system, the more accurate its behavior will be. Where does it all bring software engineering in the near future?
The future of software engineers
Having a software engineering background, I find this question fascinating. I have given it much thought, and I am not alone. Some say this is “just” another technology, and we’ll still need software engineers. Some think that for software engineers to “disappear,” we need more of them first. Yet, others claim we should “give up on teaching programming to our kids” as they won’t need it in the future. Here is my take.
To give credit where it’s due, the seed of this idea came from Viktor Somodi. Three classes of engineers will emerge. It already started but will become more visible as the AI era continues.
The first class is the classical software engineers; they know their stuff well and don’t want anything to do with the “AI hype”. Next are the AI-native engineers, born into this era, who consider classical computing knowledge obsolete. The middle ground is AI-enhanced engineers, already proficient software engineers eager to adapt AI tech and form a bridge between the other two groups. Let’s dive in a bit more.
Classical software engineers
This is a temporary state as members will either transition or become extinct. It is always a good idea to have skeptics when a new technology emerges, but I don’t yet see a clear benefit in not embracing this technology. Avoiding these tools will slowly make you irrelevant, as those who do can do your job much faster and cheaper. This is as big as electricity back in the day. You can, of course, go without, but competing will be very hard. Anyone in this group will likely have a regular job until they retire, but the population of this group will not increase as newcomers will likely end up in the other two groups.
A lot of human professions survived automation by declaring that their goods are superior because a master waiver created them or it is “hand-picked,” there is no inherent value in software that’s “human-made” or “crafted by hand.” This stems from humanity; I believe we will not pay more for software that’s of worse quality and has fewer features just because it was “human-coded.”
If you plan to be here, I wish you the best of luck. It’ll be more challenging than one might anticipate, but certainly not impossible.
AI-native engineers
This is the most exciting bunch. These people post wild new generative AI techniques on Twitter/X and experiment for hours. They have an intuition for what works and how it could be improved. These engineers and enthusiasts open new frontiers. This is the smallest group as of early 2024. We’ll need another few years to have truly AI-native engineers who do not know how most of the stuff works under it. People who believe we no longer need to understand computing as profoundly as today will likely end up in this group. This group is critical in advancing our efforts; however, relying too much on the frontier without having solid roots will lead to a slow decay. Think Foundation by Isaac Asimov. A technologically potent empire slowly fell apart because no one knew how to repair stuff they had taken for granted.
Being an engineer already, this isn’t a choice for you unless you instantly forget everything you know about bits, memory, and computing fundamentals. However, you might like to be in this group if you are not in engineering yet.
AI-enhanced engineers
This is the group you should aim for to stay truly competitive. You have a solid background in computing, and the market will welcome your expertise when all those existing systems need to be connected to AI components. Prompt engineering is one thing, but a usable copilot-level software won’t write itself… yet… Being here gives you a unique opportunity to contribute to this wildly developing technology. This is where you can best cooperate with existing AI solutions as you know how they work and what you need to do to alter their behavior. This is true symbiosis; you and the AI agent switch roles in leading and following. It does have its drawbacks, though. Knowing all you do, you inherently place yourself in a box that is very hard to peek out of. That’s where AI-native engineers will have an advantage.
There is just one caveat for this: effort. You well know that keeping up with technology requires tremendous effort. This is especially true for AI, which is improving at lightning speed. However, your effort will be well-placed and pay off nicely soon.
Next steps
If you are a software engineer or aspire to be one, now is the best time to be alive. A lot of people will argue that it is quite the opposite: that there is no clear path forward, nothing is safe, and our future is one big uncertainty. There is some truth to that, but I believe in a much brighter future. Having a plan is a great way to ensure it comes to fruition.
Here is what I recommend you do:
- Aim to be an AI-enhanced engineer; you are in the best position to be one
- Read AI papers, at least the gist of it
- There are great tools to help you; I am using arXivly.
- Get competent using this new technology
- I found the best way to do this is to read the docs of popular libraries like LangChain, EmbedChain, LlamaIndex
- When learning about new concepts, I love explorian.io
- Build pet projects that use these technologies
- Get a sense of what this’s good for and where to stay with good old engineering tools
- It isn’t as powerful as they say it is (yet…)
- It surely isn’t as useless as they say it is
- Sign up for a couple news aggregator newsletters
- It’s important to balance content consumption and experimentation; try to be read-write instead of read-only
- Put your ideas out there, and start engaging with other like-minded professionals
- You’ll surely find engineers in the exact same position 🙃
- Be sure to seek out those who disagree with you as well
Good luck on your journey!
Leave a Reply