I was first introduced to computers back in 1983, with the ZX-81 (1KB of RAM, black & white colors only) and then the ZX-Spectrum (16KB or 48KB RAM with 16 colors). It was truly magical – I could use a programming language (BASIC was the inbox language back in the day) to make the computer do stuff, create games and other fun applications. Fun was a big part of it – creating something out of nothing, and it was fun and challenging, like a game, whether I was programming an actual game or not.
Shortly after my initial encounter with the ZX computers, I got a Commodore 64, which I had for the majority of the 80s. Just like the ZX computers, BASIC was the built-in programming language (a different variant, mind you, which at the time was somewhat frustrating). BASIC was still the main language, but it was common to do at least some programming in machine language, or more precisely, assembly language. The main reason was the slowness of BASIC, being interpreted rather than compiled, running on a 1MHz 6510 CPU (a variant of the 6502, also used in the Apple II and Atari 800 computers). For many applications and games, BASIC was just too slow; machine language was fast.
Fast forward many years – BASIC is no longer a thing. Assembly/machine language is not commonly used, either; in the majority of cases, there is no need. Mainstream compiled languages like C, C++, even C# and Java (JIT-compiled), coupled with much more powerful processors and faster memory is good enough for many applications. Even interpreted languages like Python and JavaScript enjoy much success, even though they are “slow”, but fast enough for many applications (sometimes with libraries written in compiled languages). The use of assembly language is marginal, specialized, and never used for full-blown applications. The reasons are obvious – assembly is verbose, has C-like procedural/structural at best, not to mention being CPU-specific. With the introduction of higher-level abstractions in programming languages, the need for assembly is minimal, only common in areas like operating systems, firmware, hypervisors, embedded systems – and even in those areas never used for the full software – moving to a higher-level language that is still “close to the metal” like C, C++ or Rust as early as possible.
The AI Coding Era
Unless you’ve been living in a remote cave – unlikely if you’re a software developer – you’ve seen and probably used AI’s coding prowess. I admit I find it somewhat sad that humans will write less code manually, delegating coding to AI agents. Perhaps it’s a natural evolution – usage of higher-level abstractions. But there is a fundamental difference. In the past, the higher abstraction was typically another programming language, with possibly enhanced tooling and development environment (I’m ignoring visual programming languages that had some promise but never gained widespread use because of inherent limitations in “visual” expressive power).
AI coding is different – we’re using natural language for that, which is potentially ambiguous and imprecise – exactly the reasons programming languages were created to begin with.
As I write these lines, AI coding is used a lot, where human intervention ranges from none to significant – the responsibility for the code quality (whatever that means for that codebase) is on the human, at least for now.
The classic clashes of programming language enthusiasts – C# or Java? Python or Ruby? C or C++? (X or Y – have your pick) – they seem to matter less. Is it really necessary to know the latest advancements in the C++ standard? Should we really care about a new library added to the standard? If AI generates the code, and we as humans just do a code review – should we really care about the nuances of coding? Supporters of AI coding probably see a future (not too distant, mind you) where AI will code everything based on human and possibly AI specifications, without the code even being visible to humans. But why stop there? Maybe AI can come up with a more efficient language – the use of textual tokens is good only for humans, after all; Maybe a more compact and efficient binary language would make AI coding even faster.
One objection to this model is that there will be bugs, so maybe humans are still needed. AI is not infallible, at least not yet. The code in production may have bugs, some quite nasty – data races, memory issues, logic bugs that may be complex to resolve in some domains; or performance issues. This is where humans must intervene – they must be able to understand the code to be able to fix bugs. On the other hand, AI can help resolve these bugs as well, as it’s already doing. Just provide a guiding prompt, log output, etc., and the AI is happy to chase down bugs. Is it guaranteed? Not yet, but as AI is getting better, at some point it would be able to resolve bugs on its own, maybe with some human guidance at times. Even in such cases of human intervention, “seeing” the actual code may not be necessary. The AI will do the fixes – as long the expected behavior and performance metrics are reached, why care about the code at all? There is no need to know what that code looks like, as it may be some internal binary format convenient for the AI to process anyway.
There may be extreme cases with bugs that can’t be resolved in this way. AI can always convert the binary language to something humanly comprehensible so that the human can take a closer look.
For some, these potential developments may be too much. Are we really going to delegate programming to machines completely? Maybe history can teach us something.
Before the creation of pocket calculators, scientists had human “calculators” that did the grunt work, while the scientist focused on the “scientific” parts. With electronic calculators, that human calculator role was gone – we trust calculators implicitly. When we write code in a high-level language like C, we use a compiler to convert the C code into machine language so that physical CPUs can execute it; just like with calculators, we trust these compilers implicitly. It doesn’t mean compilers don’t have bugs – they do, but we still trust them. It’s very rare to see a developer looking at an assembly output from a compiler, comparing it to the original code to find discrepancies. A compiler bug would eventually be fixed.
Why not consider AI coding in the same way? AI can make mistakes, just like compilers can, but AI can also fix them once they’re discovered. We don’t need to see any code.
An End to Human Coding?
Does all this mean that humans don’t need to code manually anymore? I believe we’re headed in that direction. It seems that humans are no longer needed for coding. It’s no wonder that there is a genuine fear among many programmers that their job is being “stolen” by AI. If human coding is no longer needed – where does the human programmer go from here?
I recently was a guest at a live podcast. I was demonstrating writing a Windows kernel driver from scratch, which involves quite a few coding details you must get right. One participant asked whether we need to know all these details – surely AI can write the code instead of me. Well, maybe AI can write the code just as well as me, and possibly better. What I was focusing on is not the coding details themselves, but the architecture and concepts underlying the code – how does a kernel driver work? How is it loaded? How does it manage its resources? How is it connected to the kernel? Etc. The point is that the details of the code may be delegated to AI, but the foundational concepts can’t. For one, how can the human do a code review to validate the AI’s coding? Even if we assume AI coding has no mistakes, what about the overarching architecture and design we’d like to have? AI may not have the full picture. Even more than that – let’s assume I delegate all the coding the AI – I still have to describe to the AI what to code – in this example, what is the role of the driver in this project? How should it communicate with user mode? What logging methods I’d like to use? There is more than one option, which is where the human needs a deep understanding of the domain to be able to give high-quality specification to the AI. The human becomes a designer and architect, delegating the nitty-gritty details to the AI.
This gradual transition is a process, not a binary switch. It won’t happen in a month, but it won’t take decades, either. It’s hard to predict the pace of progress with AI, as it seems to be exponential – something human beings are not built to deal with – we’re linear creatures.
Conclusion
There is a part of me that is sad about this state of affairs. I still like to write code manually, creating things I can call my own. All my knowledge of the intricacies of certain programming languages will eventually be obsolete. Should I learn the newest version of a programming language? At this point in time, my answer is still yes. But I suspect my answer will change in the not-so-distant future.
If AI codes my applications, is the code really mine? This may be the wrong question. What’s “mine” is the application idea, architecture, features, capabilities, and design. The code itself is just an implementation detail, best handled by machines.
Pavel Yosifovich 