Forty years ago, I could write a handful of lines of BASIC, press RUN and watch the computer do something I had imagined. Today, I can describe a requirement in ordinary English and see a working result take shape.
The machinery behind those two experiences could hardly be more different. Yet I recognise the feeling.
For much of the time between them, I felt that programming had become less direct. We gained enormous capability, but also layers of work between an idea and the moment we could see it working.
AI is giving me some of that immediacy back.
When the problem came first
Like many people at the time, I learned to program in BASIC. A thousand lines was a substantial piece of software. The machines were limited and the language was… basic, but getting started required little ceremony. You wrote a few instructions, ran them, saw the result and changed what did not work.
Back then, it felt like 90% of my effort went into solving the problem and 10% into fighting the machine and the tools. Most of my attention went into the thing I wanted to build.
The reward was immediate. A small amount of carefully chosen text could produce a surprisingly useful result.
A brief remission with Visual Basic
Moving from BASIC into C++, and then Visual C++, was a change of scale. Developing for Windows meant dealing with windows, messages, APIs and the machinery around the functionality I actually wanted to write. Even simple operations like working with strings became more complex.
Then Visual Basic offered a brief remission.
People laughed at VB, and it certainly had shortcomings of its own. But it hid much of that Windows plumbing. I could put controls where they belonged, write the behaviour behind them and see something useful working without spending so much effort on the interface itself. For a while, the tools were helping me again rather than getting in the way.
It did not last.
When the complexity returned
As I moved into larger enterprise systems, particularly the era of Enterprise Java, the scaffolding multiplied again: frameworks, application servers, configuration files, build systems, dependencies, security controls, testing regimes and deployment processes.
Much of it was necessary. We were building systems with demands that my BASIC programs never faced: scale, resilience, maintainability, integration and accountability.
But there was a cost.
The computers were vastly more powerful. The journey from thought to result did not always feel faster.
By then, I sometimes felt the ratio had shifted from 90:10 to something closer to 50:50 — and that was being generous. Half the effort could disappear into configuring the tools, satisfying the framework and navigating the machinery before the business problem had moved very far at all.
A small enhancement could mean a disproportionate amount of setup and typing. The computers were vastly more powerful. The journey from thought to result did not always feel faster.
I missed the feeling that I could simply have an idea and make it work.
Back to brain, words and functionality
I am now working on a project that brings together cloud services, components and heaps of automation. It is not a trivial system. Yet a surprising amount of the development happens through conversation.
I explain what I want, shape the requirements, discuss the trade-offs and ask AI to assemble or modify the necessary functionality. Then I inspect the result, test it, challenge it and refine it.
The work has not disappeared. But much of the mechanical translation has moved elsewhere.
The path increasingly feels like brain → words → functionality.
And the words matter. A well-crafted instruction expresses purpose, constraints and expected behaviour. Improving that instruction can be more productive than spending the same time fighting a configuration file or writing another layer of boilerplate.
I have jokingly called this “10GL”. It is not a real classification of programming languages, and AI is not a conventional interpreter or compiler. The point is the felt jump in abstraction: I can work closer to the problem I am trying to solve.
The advantage — and risk — of unpredictability
There is another difference from conventional programming, and I do not think it is entirely a disadvantage.
Traditional software usually expects data in a format someone anticipated. Change the structure of the input and you may need another parser, mapping rule or exception handler.
AI can often deal with variation more gracefully. I can give it a neatly structured file, a loosely formatted document or information with missing labels, and it may still infer what matters and apply the intended logic. Sometimes that adaptability is exactly the functionality I need.
But the same flexibility comes with a price. Inference can be wrong. A model might interpret ambiguous information differently on another run, or quietly fill in a gap incorrectly. Its ability to handle unexpected inputs is not a guarantee that it understood them.
That changes the engineering judgement. I want AI where interpretation and flexibility create value; I want explicit rules, tests and conventional software where repeatability and auditability matter. Where AI produces code, that code can be saved and run independently, with predictable behaviour to the extent the program and its environment permit.
The trick is not to pretend the uncertainty has vanished. It is to decide where it is acceptable and how to check the result.
Not just vibe coding
AI-assisted coding is hardly a secret now. There is even a name for a particularly informal version of it: vibe coding.
That is not really the revelation I am trying to describe. Nor am I suggesting that describing a feature and accepting the first plausible output is good engineering. Experience still matters in framing the problem, recognising a poor design, testing the result and knowing when the solution is too fragile.
There are costs, too: time spent reviewing generated work, the possibility of subtle errors, service costs and dependence on tools that can change. Not every task benefits from putting AI in the loop.
That is productive. More importantly, it is satisfying.
What has changed for me is where I spend my effort, and how quickly I can get useful feedback. I can move across different parts of a project, make a small improvement and see it work without first constructing all the scaffolding myself.
That is productive. More importantly, it is satisfying.
Perhaps the circle is closing
I do not want to go back to BASIC, nor would I trade away the engineering advances of the intervening decades.
But I do want more of my time spent on the problem and less on the machinery around it.
Forty years ago, a few lines of BASIC were enough to make an idea real. For a while, the supporting complexity seemed to grow faster than my ability to turn ideas into working results. Now the distance is shrinking again — albeit with different risks and a new need for judgement.
Perhaps I am not rediscovering an old programming language at all.
Perhaps I am rediscovering what I liked about programming in the first place.
