SimplifyC++ Article
From FlashCode to AI: Forty Years of Programming Between Deep Understanding and Rapid Production

Since the mid-1980s, the world of programming has changed in ways that are difficult for anyone who started recently to fully imagine. Yet one thing has remained unchanged for me: that first fascination of seeing a computer do something because I told it to do it.
My story began almost forty years ago, when simply seeing a computer was exciting, owning one was an expensive dream, and programming meant understanding almost every instruction you wrote.
Today, I can describe a program to an AI system, discuss its architecture, request changes, correct mistakes, and within a few hours have something that might previously have required weeks or months of work by myself or by a team of programmers.
This journey is not merely a story about faster computers and more powerful programming languages. It raises a much deeper question:
What do we gain when tools make us dramatically faster, and what might we lose when those same tools perform part of the thinking for us?
The Beginning: A Computer That Did Not Even Work
My first real contact with a computer came in the mid-1980s with a small Sinclair machine.
Ironically, the machine did not work.
Yet even a non-working computer was enough to create fascination at that time.
I remember a plastic overlay placed over the keyboard to identify Arabic letters. There were no high-resolution displays, no modern mouse, no Internet, no app stores, and certainly no endless online tutorials.
The computer itself was something strange, rare, and exciting.
At another time, I saw a PC only from a distance in a commercial agency. As I remember, its price was around $7,000, making ownership completely unrealistic for many people.
Today, we carry devices in our pockets that are incomparably more powerful than those machines, yet perhaps we have lost some of the wonder of that first encounter.
At the time, simply seeing:
READY
appear on the screen could make you feel that you had entered an entirely new world.
MSX: When the Computer Finally Became Mine
Later, I bought an MSX computer, and that was when my real relationship with programming began.
BASIC was the doorway.
You could write:
PRINT "HELLO"
and immediately see the result.
Then:
FOR I = 1 TO 10
PRINT I
NEXT I
and suddenly the machine was executing logic that you had written yourself.
To someone accustomed today to massive IDEs, visual designers, code completion, frameworks, and AI-generated code, this may appear trivial.
It was not.
Every instruction you understood added another piece to your mental model of how computers worked.
You learned concepts such as:
Variables
Loops
Conditions
Input
Output
Arrays
Functions
one by one.
More importantly, you usually understood why what appeared on the screen had happened.
FlashCode: My First Encounter With the Idea of Writing Less to Produce More
At an early stage, something happened that I still remember clearly.
I met someone who sold me a program which, as I remember, was called FlashCode. It promised to help create programs more quickly.
He spent roughly an hour explaining the program, took his payment, and that was it.
As was common in that era, the software itself was, of course, a copied version.
But what matters to me today is not the story of that transaction. What matters is the idea that entered my programming life at that moment:
Should I write the entire program myself, or should I use another program to generate part of it for me?
We did not use terms such as:
Low-Code
Code Generation
AI Coding
but the fundamental concept was already there:
Use a tool that raises the level of abstraction and reduces the amount of work you must perform manually.
That idea has accompanied the entire software industry ever since.
Programmers Have Always Been Moving Upward Through Abstraction
A large part of programming history is the history of humans moving away from low-level details toward higher levels of abstraction.
We began with:
Machine Code
then:
Assembly
then:
C
then higher-level languages.
Then came:
Libraries
Frameworks
GUI Builders
RAD Tools
Code Generators
CMS Platforms
and today:
Artificial Intelligence
At every stage, someone complained that the new tool would make programmers lazy.
But if we applied that argument literally, every programmer today would still be writing software in machine code.
Nobody considers this:
std::vector
a form of cheating because the programmer did not manually implement the underlying memory management.
Nobody considers:
std::sort()
unacceptable simply because the developer did not rewrite a sorting algorithm from scratch.
And nobody asks a GUI programmer why a ready-made:
Button
TextBox
Dialog
was used instead of drawing every pixel manually.
Technology advances because we are able to build on top of what has already been created.
But there is an important difference between:
using abstraction after understanding the foundations beneath it,
and:
using abstraction because we have no idea what is happening underneath.
That distinction is where the real issue begins.
Speed Can Have an Intellectual Cost
Every tool that increases productivity can also hide more implementation details.
When I wrote programs line by line, I was forced to ask:
What does this command do?
What type is this variable?
Where does this value go?
Why did this loop stop?
Why did this function fail?
Today, AI can generate hundreds of lines of code in seconds.
This is extraordinary for productivity.
But it can also produce a programmer who possesses:
5000 lines of working code
while being unable to explain:
500 lines of it
And here we must distinguish between two completely different things:
Speed of code production
and:
Depth of understanding.
They are not the same.
What Can Be Lost When Tools Do Everything?
If a beginner becomes accustomed from the first day to saying:
Build me a program that does this.
and then simply runs the generated result without understanding it, an important intellectual foundation may never develop.
The person may know how to obtain:
Result
without understanding:
Algorithm
Architecture
Memory
Data Structures
Errors
Complexity
Security
When the program works, everything may appear perfect.
But when something unusual fails, the difference becomes obvious between:
someone who uses the tool,
and:
someone who understands what the tool produced.
AI can write code.
Judging whether that code is good still requires knowledge.
But There Is Another Side to the Story
It would be equally wrong to view artificial intelligence only as a threat to programming knowledge.
For someone with long experience and clearly defined practical goals, AI can become an enormous multiplier of productivity.
This is exactly what I see in my own work today.
I am not working in a vacuum, and my goal is not to prove that I can personally write every line of every system.
I have technical projects, websites, administrative systems, databases, publishing systems, statistics, content-management tools, and many secondary technical tasks.
Many of these are necessary, but they are not necessarily where I want to spend most of my time.
Traditionally, there were perhaps three choices:
Learn everything myself
or
Spend months writing everything
or
Hire programmers
The third option, accumulated over many projects and years, could easily represent tens or even hundreds of thousands of dollars.
Today there is a fourth option:
Me
+
AI
And the economics of development change dramatically.
AI as a Development Team I Could Not Traditionally Hire
I can tell AI:
Create an administration page.
Then:
Add search.
Then:
Make it responsive.
Then:
Connect it to the database.
Then:
Add security.
Then:
This section is not working; here is the error message.
We inspect the problem, modify the implementation, and continue.
After only a few hours, I may have something that previously required the combined work of:
Designer
Frontend Developer
Backend Developer
Database Developer
Tester
or at least one highly capable developer working for a considerable amount of time.
At that point, AI becomes more than a simple:
Code Generator.
It becomes:
A mechanism that gives one person execution capacity that previously required several people.
A Complete Program in Two Hours — But What Do Those Two Hours Really Mean?
When I say that I can now create a complete program in two hours with the help of AI, that does not mean forty years of knowledge have suddenly become worthless.
In many ways, the opposite is true.
Behind those two hours stand decades of experience in knowing what questions to ask.
I often already know:
- What I want the program to accomplish.
- What looks logically correct and what does not.
- When an architecture is poor.
- When the result differs from the actual requirement.
- What to request after the first implementation.
- How to test the result.
- When to reject a solution and ask for another one.
This leads to a very important point:
Artificial intelligence does not make forty years of experience worthless; it can multiply the value of those forty years.
An experienced programmer uses AI differently from a beginner.
The beginner may say:
Build the program for me.
The experienced developer may say:
Here is the architecture, these are the constraints, this is the platform, these are the mistakes we must avoid, and this is the result I need.
The difference between those two prompts can be greater than the difference between two programming tools.
Does AI Reduce Programming Knowledge?
Yes.
And it can also increase it.
Both outcomes are possible.
It depends on how it is used.
If the workflow is:
Prompt
↓
Copy
↓
Paste
↓
Done
knowledge may gradually weaken.
But if the workflow is:
Ask
↓
Read
↓
Understand
↓
Question
↓
Modify
↓
Test
↓
Learn
AI can become one of the most powerful educational tools programmers have ever had.
The difference is not AI itself.
The difference is the user.
I Do Not Need to Memorize Everything — But I Must Understand What I Decide
There is another important change in the meaning of programming knowledge.
In earlier decades, obtaining technical information was more difficult.
Memorizing command names, syntax, and APIs therefore had greater practical value.
Today, information can be retrieved almost instantly.
So the importance of this question decreases:
Do you remember the exact syntax of this function?
while the importance of this question increases:
Do you know when to use it, why to use it, and what consequences its use may have?
The strongest engineer in the AI era may not be the person who memorizes the largest number of APIs.
It may be the person capable of evaluating:
Design
Correctness
Performance
Safety
Maintainability
Architecture
In other words, value gradually shifts from:
writing instructions
toward:
choosing the right instructions and verifying that the entire result is correct.
The Danger of Becoming a Manager of Code You Do Not Understand
There is, however, a genuinely dangerous area.
AI can rapidly generate:
Website
API
Database
Authentication
Admin Panel
Payment Integration
But if the owner of the system understands none of it, that person may possess working software without knowing where its weaknesses are.
There may be:
- A security vulnerability.
- A poor database query.
- A race condition.
- An authorization error.
- An unnecessary dependency.
- Unmaintainable code.
- A solution that works only for the current case.
Therefore, the best relationship with AI is not:
You are the programmer and I am merely the user.
but rather:
You are an extremely fast assistant, and I remain responsible for the engineering decisions.
Why AI Is Especially Valuable to People Whose Main Profession Is Something Else
There is one category of people whose lives may be transformed by AI even more dramatically than those of professional programmers.
They are people with real domain expertise who need software as a tool rather than as an end:
Engineer
Researcher
Doctor
Entrepreneur
Designer
Domain Specialist
In the past, such people might have had excellent ideas but faced a major barrier between the idea and its implementation:
Software Development Cost
A project could require tens of thousands of dollars before anyone even knew whether the idea would succeed.
Today, a domain expert can move much closer to implementation personally with the assistance of AI.
This is an enormous economic shift.
Artificial intelligence does not merely reduce the time required to write code.
It reduces:
The cost of turning an idea into software.
That Is Exactly What Happened in My Case
Having a professional background outside software development did not prevent programming from remaining an old and persistent passion.
But today I have many activities that require software even though software development is not necessarily the main work on which I want to spend every available hour.
Creating systems such as:
Website
Admin System
Database Tools
Statistics
Publishing Tools
Search
Newsletter System
User Management
is necessary.
But implementing every one of those systems manually from scratch could consume enormous amounts of time.
AI has allowed me to use that time differently.
Instead of spending a week implementing a secondary feature, I may complete it in hours and return to the work I consider more important.
And that is where its real value appears:
AI did not merely save me from writing code. It gave time back to me.
And in a human life, time is far more valuable than the number of lines of code one personally typed.
Would I Become a Better Programmer by Writing Everything Myself?
In one sense, yes.
I would certainly learn more details about every component.
But the more important question is:
Is that the best possible use of my time?
If building a website administration system that is not my main goal requires a month of work, while AI can help me complete it in a day, how valuable is the extra technical knowledge compared with the month that has been lost?
There is no universal answer.
A computer-science student learning data structures should not ask AI to solve every exercise instead of learning.
But a project owner who needs an administration panel is not required to re-study all of computer science before being allowed to create one.
The goal determines how much depth is necessary.
From FlashCode to AI: The Principle Is the Same, but the Scale Is Completely Different
When I think back to that early program I bought because it promised to help create software more quickly, I notice something interesting.
From the beginning, I was effectively asking:
How can I make the computer help me build software for the computer?
FlashCode was, for me at that time, a small attempt at answering that question.
Then the years passed:
BASIC
↓
Programming Languages
↓
Libraries
↓
Frameworks
↓
RAD Tools
↓
Web Development
↓
Code Generators
↓
Artificial Intelligence
The underlying principle did not change.
What changed was the power of the tool.
A tool that once saved perhaps dozens of lines can now generate thousands of lines, discuss them with you, redesign their architecture, modify them, and help diagnose their failures.
Forty Years Compressed Into a Conversation
From my perspective, there is something almost paradoxical about the journey.
In the mid-1980s, I was looking at a non-working Sinclair machine and trying to understand this strange new object called a computer.
Then I began writing BASIC on an MSX.
Then I searched for software that could help me create programs faster.
Then I learned more languages, tools, systems, and technologies.
And today I can sit in front of a computer and say:
I want an application with these requirements.
and receive the answer:
We can build it this way.
Then the code begins to appear.
What would once have appeared to me as science fiction has become an ordinary part of daily technical work.
But Speed Must Not Kill Curiosity
Despite my admiration for this new capability, there is one thing I hope we do not lose.
That old question:
Why?
Why does this work?
Why did this fail?
What happens inside this function?
Why is this algorithm faster?
How does the data move?
How does the system manage memory?
Curiosity is what transforms a person from merely being a user of a tool into someone capable of controlling the tool.
AI can give us:
the answer.
But the enduring value of the programmer lies in knowing:
whether the answer is actually good.
Conclusion: Do Not Reject the Tools — But Do Not Surrender Your Mind to Them
After almost forty years of working with programming, I do not believe the answer is to resist new tools.
If programmers had followed that philosophy throughout history, we would still be writing assembly language for everything.
But neither do I believe we should surrender the entire thinking process to artificial intelligence.
The combination I find most powerful is:
Human Knowledge
+
Human Experience
+
AI Speed
=
Enormous Productivity
Artificial intelligence can allow one individual to perform work that once required a team, reduce development expenses that might otherwise have reached enormous amounts, and give the owner of an idea an implementation capability that was previously unavailable.
But the strongest results appear when the human remains capable of directing, evaluating, correcting, and understanding the tool.
My journey began with a Sinclair computer that did not work, continued through MSX and BASIC, passed through an early program promising faster software creation, and has now reached an era in which an entire system can sometimes be built through a conversation lasting only a few hours.
This is not the end of programming.
In my view, it is the beginning of a different stage of programming.
In the past, I had to tell the computer how to do almost everything. Today, I can explain what I want—but it still needs me to know why I want it, how it should work, and whether what it created is actually correct.
Perhaps this is where the value of the programmer is moving in the AI era: away from the mere speed of typing code and toward something higher:
Depth of understanding, quality of judgment, and the ability to turn an idea into a correct system.
From FlashCode, which helped reduce some of my work in the early days, to AI systems that can now compress weeks or months of development into hours, the lesson remains surprisingly consistent:
A more powerful tool does not make a knowledgeable human less valuable; it makes that knowledge far more productive.
What did you think?
Sign in to react or comment.
Comments
0No comments yet.