A Grayframer Comes to Terms With ‘Vibe Coding’
Even if AI writes the code, humans still have to understand it, veteran mainframer Bruce McKnight reasons
For most of my career, learning to program meant staring at a green screen, a coding sheet or even a napkin, sometimes for hours, until the code finally bent to my will.
If you grew up in the era of enterprise systems and mainframes, especially before green screens were common, you know the process. You started with a problem definition or program specification, wrote the logic, compiled and ran the program, and then began debugging when it inevitably failed. Eventually the code worked, and by that point you understood every line because you had fought for (more often with) every line.
Recently, I experienced something new. I asked an AI assistant for help with a Python problem. In retrospect, the problem definition wasn’t that difficult. I knew a bit of Python from working with microcontrollers and IoT devices. But it seemed that no matter what approach I used, a successful result continued to elude me.
Normally, I would dive into the manuals and check out a few web sites for helpful hints. This was different. I was out of my depth and had a tight timeline. I didn’t have the luxury of spending time on a learning curve and its myriad blind alleys.
Eventually, I gave in and submitted my problem definition and the code I had struggled with for hours to an AI coding assistant. My mouse makes two clicks. One for button contact and one for its release. It seemed that the finished code was on my screen before that second click.
The AI assistant took my initial attempt and refined my code. Only this time it was simple, beautiful, elegant code.
In milliseconds.
My first reaction wasn’t excitement.
It was guilt.
The Way We Learned
For many of us who built our careers on large enterprise platforms, learning to code was an exercise in persistence. There was no internet. There were only punch cards or green screen terminals. You may find a code example in a book, but you didn’t paste in solutions. You didn’t ask a machine to generate code. You worked through the problem until the logic worked. If you got stuck, you asked a fellow programmer for help.
Struggle is part of the human learning process. We learn best when we have to work out an answer. In learning to program, by the time the program finally ran correctly, you had built it piece by piece, layer by layer, interface by interface. And you probably learned a new function or a new command or two along the way. We became better programmers through an iterative fail/succeed process.
So when an AI tool instantly produced a clean, elegant answer to my problem, the old instincts kicked in.
Had I just somehow cheated?
A Different Workflow
Once the initial reaction passed, I did what any engineer would do. I studied the code. I didn’t just cut and paste it into the stack and move on. I really studied it.
The solution was surprisingly simple and efficient. After a few minutes, I understood exactly how the AI’s approach worked and how it was more efficient than mine. Then I read its analysis and learned why it had taken that approach. I was a lone coder working out a problem. The AI assistant was thousands of coders who had solved similar problems in a thousand different ways. It combined the problem statement with my initial design and drew on its vast warehouse of examples to refine the optimal solution.
But it didn’t write the new code in a single pass. Much like a chess program testing thousands upon thousands of combinations before making its move, the AI assistant had rewritten and rewritten my code repeatedly, maybe thousands of times, scoring each one until its internal assessment processes decided which version was best.
That’s when something clicked. The important skill in that moment wasn’t typing the code. The important skill was understanding the problem and framing it correctly.
For decades, a traditional programming workflow went something like this:
Problem → Write code → Debug code → Repeat until it works.
With AI assistance, the workflow is starting to look more like:
Problem → AI proposes a solution → Engineer evaluates it → Engineer refines it.
The thinking doesn’t disappear. If anything, it moves up to a new performance level.
Understanding the Appeal of ‘Vibe Coding’
That experience also helped me understand something I’ve heard a lot about recently: “vibe coding.”
I have to admit that when I first heard the term, my reaction was YASO (Yet Another Shiny Object) that I didn’t have the inclination to understand. Now I see the obvious appeal. Instead of spending hours wrestling with cryptic syntax or some ill-fitting boilerplate, an idea can quickly become a working prototype. The distance between concept and implementation shrinks dramatically.
It’s probably the same reaction early machine-level programmers felt when they encountered an assembler for the first time.
“Why do I have to learn all the mnemonics and instruction formats when I know what a 1001 0001 0011 0110 does?”
“I don’t have time to learn all these macros and directives.”
Little by little, they learned and productivity improved. The same thing probably occurred when high-level languages like COBOL first entered the enterprise. And over time, programmers learned and their productivity improved again.
And, honestly, I see how exhilarating such a quick turnaround can be when using an AI assistant. It gives you more time to test out a wider range of ideas. Or maybe revisit the problem statement to see if it can be expanded.
But it also introduces a risk. Code that runs successfully is not the same thing as code that is understood. The real danger isn’t that machines can generate programs or replace engineers. The real danger is assuming that the understanding no longer matters. Feeding a specification to an AI assistant and promoting the code to production before anyone understands it can be extremely risky. It can introduce instabilities that no one is properly equipped to address. Governance and due diligence haven’t been put on the sidelines. In fact, they are more important than ever with AI adoption.
Why This Matters for Architects
As someone exploring the emerging role of AI architecture, this distinction feels important. My goal isn’t to become an AI developer. It’s to understand how AI developers think: how data flows through systems, how models integrate with applications, and how these new tools fit into the enterprise platforms organizations have relied on for decades.
That kind of architectural thinking still requires understanding the code, even if you’re not writing every line yourself. In that sense, my experience turned out to be less about programming and more about perspective. AI didn’t replace my thinking. It simply refined it at machine speed.
The Role of Experience
The experience also reinforced something I touched on in my article “In Praise of the Grayframers.”
Technology changes, but the value of experience doesn’t disappear. Engineers who have spent decades designing systems and debugging production problems know something that never really goes out of style: working code is only the beginning. Reliability, maintainability, stability and clarity— especially clarity—still matter. Even in a world where machines can generate programs in seconds, someone still needs to understand how those programs work.
And perhaps more importantly, someone needs to understand what to do when they don’t.
A New Balance
I still believe there is tremendous value in wrestling with a problem until the solution finally emerges. But I’m beginning to accept that programming itself is evolving. The next generation of engineers may spend less time writing code from scratch and more time evaluating and refining code produced by intelligent tools. After all, COBOL was intended to ease the burden of writing assembler code and assembler language was intended to keep humans from having to deal directly with binary language that machines understand.
Programmers became more productive with every advancement. If that’s the future, then perhaps the role of gray-haired engineers in the AI era isn’t to out-code the next generation.
Perhaps it’s to make sure that, even when the machines write the code, someone in the room still understands how it works.