AI & The Software Engineer's Job

It was evident in the earlier half of the 20th century that machines could perform tasks that had previously seemed to require human pattern recognition and judgment. While working on codebreaking, Alan Turing formalized the question “Can machines think?” as an Imitation Game in a 1950 paper, which we call the Turing Test.

Won’t Everyone Else Get Affected Too?

Just a few years later, the term “Artificial Intelligence” was presented in the summer of 1956 at Dartmouth College. John McCarthy and colleagues proposed a 2-month, 10-person study of artificial intelligence based on the idea that intelligence could be described precisely enough for a machine to simulate it.

The year 1957 saw the first programs that could play chess against a human opponent. In 1972, the commercially successful game called Pong introduced a basic computer paddle that you could play against. Even Pac-Mac had separate “AI personalities” which used simple rules to simulate intelligence.

I want to draw your attention specifically to the word simulate. To simulate means to imitate the appearance, behavior, or conditions of something else.

From Turing’s original paper to the LLMs we have today, the one thing we’ve proven is that computers can simulate many tasks the way humans do. The first requirement of any simulation, or rather imitation, of human behavior is to have and define that behavior first.

Unlike computers, humans can invent something entirely new about themselves to simulate, as Neil deGrasse Tyson noted in an interview.

Thus, if someone says engineers will be affected by AI, then everyone else will be too. Or no one would be. (A major change in how we do work is not the same as being affected, or else we’ll never welcome technological advancements.)

What’s Needed to Instruct AI?

Then, there’s another point: almost no one understands what software engineering really is.

In 1972, programming became easier because C made it possible to write code in a higher-level language rather than arduously writing assembly language. If I had “speak marketing”, then I’d say “C rendered all assembly engineers jobless because writing assembly was not as needed as before.” You can probably see the flaw in that argument immediately.

Here are a few things that most don’t understand:

1. A language is not what decides whether you’re a software engineer.

2. C was created by software engineers for software engineers.

3. Engineers don’t take pleasure in arduously typing long lines of code, especially when the problem’s already solved in their head.

4. The solution is whatever happens before the programmer starts typing.

Programmers have always invented new tools to reduce the burden of writing code. Be it CLI tools that generate scaffolding, or reusable libraries that don’t require solving the same problem twice. LLMs are just a more interesting and malleable scaffolding generator. Moreover, the actual task of writing code was always the least interesting bit about coding.

Today, we classify engineers as “frontend,” “backend,” or “AI,” or whatever. But these are not definitions of an engineer, but of the area they’re asked to handle. There’s no reason why a software engineer cannot switch disciplines and paradigms tomorrow, without losing the advantage of computational thinking.

Without computational thinking, it’s hard to define what it is that you want the computer (or the LLM) to imitate. Because without sufficient instructions, it will imitate the collective opinions of all the codebases out there, which is not something you’d always want.

And the only reason a non-technical person is able to write code “without design” is because someone else has trained the LLM to imitate specifically those patterns for those already-solved problems. It’s similar to how developers can use libraries they don’t fully understand but won’t be able to improve on them without gaining that knowledge.

In short, a computer is like a mirror. It will eventually reflect your thinking, or the thinking someone else does for you. That’s why it’s important to understand computational thinking so that you can give the LLM something good to imitate.

The Grand Misdirection

Finally, most engineers are focusing on the wrong thing. And many companies have done a great job of marketing that fools engineers into having the wrong conversations.

Here’s the misdirection. Someone non-technical builds something with a fancy-looking UI and proclaims, “We don’t need software engineers anymore!”

Well, they’re excited to be able to do things they couldn’t do before. That’s their “hello, world.”

However, instead of engaging in these kinds of tools that anyone can create, software engineers should focus on things THEY THEMSELVES want to create; ones which were not possible without the support of LLMs.

No, I’m not talking about a simple to-do list that’s been overdone so many times. Maybe you want to create a sophisticated to-do application which:

1. Automatically categorizes all tasks. It’s not as simple as asking an LLM to do it because you have to handle drift, reclassifications, bulk operations, etc.

2. Uses computational optimization to figure out which tasks to work on today while having the long-term view.

3. Integrates with many other things, including photos of pen/paper to import tasks.

4. Through automatic integration, it also figures out which of your tasks are already completed (maybe by scanning your repository).

5. And much more.

The moment you start setting a software engineering-level requirement, you immediately realize that the most difficult aspect of this problem is going to be the data model. How do we ensure that when we ship version 10, it does not break drastically, especially when you cannot conveniently migrate data?

In short, a simple to-do list app is the new “hello, world.” Almost everyone can build it, or fake building it. But when it comes to more sophisticated requirements, engineers can now use an LLM to save time and build things that they always wanted to build.

In short, by merely simulating the successes of yesterday, LLMs have not suddenly become sentient. There’s still a lot to do, and we’ve surely not run out of interesting and world-changing things to discover. Like Edison said, “We don’t know a millionth of one percent about anything.”

Conclusion

As long as software engineers stay curious and look forward to the future, they don’t have to worry about how much of the past gets automated and made easy. We can’t use LLMs to build yesterday’s tools; we need to focus on the next frontier of possibilities.

And that’s what software engineering has always been about.