I’ve been using AI-assisted coding for my work a lot recently, and I’ll admit, I wasn’t sure how I felt about it. Was I cheating? How do I know it’s right? Do I admit to using it? Looking at how software development has evolved over time helped answer those questions and led to a few realizations worth sharing.
From Binary to English: A Brief History of Abstraction
To understand why AI coding tools are legitimate, it helps to look at how we got here. Fundamentally, a CPU runs binary-encoded instructions. Because humans don’t think in binary, we created layers of abstraction to make programming possible.
First, we grouped bits into nybbles, bytes, and words: digit-based values we could represent in hexadecimal. But even hexadecimal wasn’t intuitive enough, so we created English-like mnemonics to represent each CPU operation.
When I was 12, I started by writing programs in pencil using these mnemonics, then hand-converting them to opcodes using a reference table before entering them into the CPU one byte, or initially, one bit at a time.
Then I discovered assemblers. They automated the conversion from mnemonics to bytecodes, eliminating the manual, error-prone process. It was still mostly a one-to-one conversion, and I still had to manage memory addresses, stack size, register usage, MMU bank switching, and whether subroutines returned with registers intact.
The Compiler Revolution
The next leap came with higher-level languages. Now, each command could translate into tens, hundreds, or even thousands of low-level instructions. Different compilers produced different code from the same source, with optimization flags that prioritized size or speed. We delegated enormous responsibility to these tools including memory management, heap and stack usage, variable storage, parameter passing.
Early compilers had bugs, so we watched for them. But modern compilers are remarkably reliable. The code they produce is what we told them to make. Bugs became the programmer’s responsibility, not the compiler’s.
This approach has worked for forty years, so it’s become deeply ingrained in how we think about software development.
AI: The Next Generation of Tools
Now we have a new generation of tools that takes abstraction to the next level. Rather than learning a language designed for computers to understand (even if it’s “English-like”), we can use plain English to describe what we want.
AI-assisted coding removes even more underlying drudgery and detail management. It still does only what we tell it to do. If our instructions, algorithms, or structures are flawed, we get bad code, just as we would with a poorly written program in any language.
The difference? Instead of single-stepping through a debugger, we can have a natural-language conversation with the AI, explaining what errors came up or what needs to change, and it handles the implementation details.
The Reality Check
Will it always be right? No. That’s why thorough testing for AI-assisted coding remains just as important as it’s always been. The benefit is increased development speed and fewer mechanical details to juggle mentally.
The code and documentation I’ve produced over the past few weeks would have taken three to four times longer using traditional methods, and likely would have contained more bugs and been less thorough.
AI-Assisted Coding Isn’t Cheating. It’s Evolution
AI-assisted coding isn’t something to feel guilty about. It’s simply the next evolution in development tools, following the same pattern we’ve seen since computing began: abstract away the mechanical details so humans can focus on the creative problem-solving.
But like any tool, it needs to be used properly to get good results. The final output is only as good as the programmer who crafts the task descriptions and does their due diligence on what comes out.
At Geisel Software, we’re building autonomous systems and advanced robotics solutions for clients including NASA. These complex projects require both cutting-edge tools and the engineering judgment to use them effectively. AI coding assistants are part of our toolkit now not because they replace engineering expertise, but because they amplify it.
The abstraction ladder keeps climbing. Our job as engineers is to climb with it.
