Who benefits now that AI writes programs?

Recent advances in generative AI have been astounding, completely transforming the world of programming in just a few years.

In the past, it was standard for programmers themselves to perform the entire sequence of work: understand the specifications, design classes, devise algorithms, write code, and debug…

However, that is no longer the case.

By using tools such as ChatGPT, GitHub Copilot, and Claude Code, you can have even fairly complex programs generated just by giving instructions in natural language. They not only write code but also investigate the causes of errors, propose fixes, and even create test code.

It is increasingly becoming unnecessary for programmers to write all the code themselves.

This is undoubtedly a wonderful advance.

However, I feel that there is one major problem here.

Perhaps only people with genuine programming skills can truly benefit from programming with AI.

In other words.

Can you notice problems in code written by AI?

For example, suppose you ask AI to create a business application. The AI will then generate plausible-looking code in an astonishingly short time.

However, whether that code is genuinely correct is a separate matter.

• It appears to work normally but malfunctions under certain conditions
• Processing speed drops dramatically as the amount of data increases
• There are problems with memory management
• It contains security vulnerabilities
• The structure makes adding features in the future difficult

Engineers with extensive programming experience may sense something is off as soon as they look at code like this.

“Could this operation be risky?”

“Wouldn’t it be better to give this part a slightly different structure?”

Such intuition is cultivated through years of experience.

Of course, even veterans cannot discover every problem.However, they at least have the judgment to know what to question and where to verify.

On the other hand, what about people with no programming experience and young engineers with little experience? If an AI-generated program runs, they may assume that it is correct.

They do not even notice that there is a problem in the first place.

AI has greatly improved our ability to write code. However, it does not automatically improve the human ability to evaluate the quality of that code.

Where Do Young Engineers Gain Experience?

In such a situation, the question we must consider is how young engineers will acquire practical programming skills from now on.

Until now, many engineers have gained experience in actual development environments.

They write simple programs, fail, investigate the cause, and fix it. They also read code written by senior engineers and have their own code reviewed.

Sometimes, fixing a single bug takes several hours.

By accumulating such experiences, they gradually became able to understand program structures and potential problems.

However, when AI automates the creation and correction of simple programs, the situation changes.

This is because AI takes over relatively simple tasks that young engineers used to handle.

In other words, you cannot develop your skills without gaining experience, yet the very opportunities to gain that experience may be reduced.

This is a problem that arises in occupations across every field, not just engineering, but it is particularly pronounced among programmers.

Of course, new learning methods that make use of AI will emerge. However, I think we must not forget that there are abilities that cannot be acquired simply by leaving things to AI.

Looking Back on the Era of 8-Bit Computers

I would like to talk about a little history here.

When I began learning programming, computers meant 8-bit computers.

It was the era when machines such as NEC's PC-8001 and PC-8801, Sharp's MZ series, and Fujitsu's FM series were used.

At the time, BASIC was the representative programming language available to individual users.

Needless to say, there were no sophisticated development environments like those of today.

There was no Internet and, of course, no generative AI either. If there was something you did not understand, all you could do was consult manuals or magazines. Moreover, magazines and technical books were expensive and were not readily available everywhere.

When creating a program, you first drew a flowchart on paper to organize the flow of processing. Today, even documentation is created using PC tools, so compared with that, it was an extremely primitive approach.

Then, referring to the flowchart, you entered the BASIC code.

However, the BASIC built into microcomputers as standard at the time could hardly be called a fast language.

When trying to create programs that required processing speed, such as games, BASIC alone had its limitations.

This is where machine language came in.

Directly entering machine language in hexadecimal

Today, even assembly language is rarely used in general application development.

However, back then, machine language was sometimes used to increase processing speed.

Moreover, assemblers were not something just anyone could easily use. The software itself was expensive or difficult to obtain.

Therefore, it was not uncommon to use a method called hand assembly.

Hand assembly means writing assembly-language instructions on paper and personally converting them into machine-language instruction codes.

For example, for the Z80,

take the following sequence of instructions:

convert it into the hexadecimal byte sequence shown above and enter it directly into memory. Looking back now, it was quite a primitive task.
Naturally, even a single-character mistake in the input would prevent the program from running correctly.

In some cases, the computer could even run wild.

On top of that, the debugging environment was poor. Error messages were not as helpful as they are today. Especially with machine language, a single mistyped character could send the program into a runaway state. It was a terrible environment in which, far from being able to debug, you had no choice but to reboot the computer.

Even so, we somehow managed to complete programs by reading the manual, looking up instruction codes, and checking the contents of memory.

It was an endless succession of hardships at the time, but looking back now, I think it was an extremely valuable experience. This is becausewe were compelled, whether we liked it or not, to be aware of what the computer was doing internally.

The excitement of being able to use C

Afterward, 16-bit computers became widespread, and environments in which C could be used became more readily available.

Of course, C itself had existed before the advent of 16-bit computers. However, it was a major change that development in C became possible even on personally owned computers.

For anyone who had struggled with hand assembly, C was truly a welcome arrival.

You could use variables, arrays, and functions.

Furthermore, conditional branches and repetitive operations could be described clearly. Moreover, the compiler would convert them into machine language. It may seem obvious by today's standards, but it was revolutionary back then.

On top of that, even when the PC or OS being used was different, the syntax of C itself remained unchanged, which was another relief.
That's because back in the day, it was taken for granted that the syntax of BASIC varied completely depending on the model of PC being used.

And C had another major characteristic.

It was the fact thatyou can write practical programs while keeping the computer's internal structure in mind.

C is still well suited to programming education

Currently, C is not necessarily the optimal choice for new application development.

Particular care is needed with regard to memory safety.

Pointer misuse, buffer overflows, access to freed memory, and similar mistakes can cause serious problems.

For new development where safety is a priority, a language that accounts for memory safety, such as Rust, may sometimes be more suitable.

Even so, I thinkthat C remains one of the very best options for foundational programming education.

This is because C does not conceal too much of a program's internal structure.

For example, you can learn the following:

• how a variable's value is stored in memory
• the relationship between arrays and memory addresses
• indirection through pointers
• function calls and passing arguments
• dynamic memory allocation and deallocation
• the relationship between data structures and algorithms

In high-level languages, many such mechanisms are abstracted.

This in itself is an important advance for improving development efficiency.

However, using abstracted mechanisms and understanding those mechanisms are not the same thing.

In C, mishandling memory can cause a program to stop running properly.

In an educational setting, such failures themselves become important learning material.

And C is not merely a language for learning low-level mechanisms.

You can also use file processing and data structures to build simple business applications.

In other words, it has both low-level elements for understanding a computer's internal structure and high-level elements for developing practical applications.

I believe that this delicately balanced position is what gives C its educational value.

Deliberately reverting to the inconvenient environment of the past

Here, I return to the initial discussion.

In an age when AI writes programs for us, what kind of programming education do we need?

As one approach, I am consideringthe idea of deliberately recreating the old, inconvenient programming environment.

For example, a learning environment such as the following:

1. No Internet connection
2. Do not use smartphones either
3. Generating code with generative AI is prohibited
4. First, draw a flowchart on paper with a pencil
5. Use C and enter the code yourself
6. If an error occurs, read the manual and investigate the cause
7. Support features such as the debugger will also be restricted according to the stage of learning

Of course, you do not need to do this in an actual development environment

It is, after all, an environment for basic education

The current development environment is very user-friendly

It provides code completion and points out syntax errors on the spot. With AI, it can even suggest fixes

However, in an environment that is too helpful, the answer appears before the learner has had a chance to think for themselves

Why did that error occur?

Why does that algorithm not work correctly?

Why was the contents of memory overwritten?

Perhaps learners need time to confront such problems on their own

The important thing is not simply to impose an inconvenient environment

It is to use inconvenience to help people understand the workings of computers, which they do not normally pay attention to.

Education without AI is also education for mastering AI

I do not want this to be misunderstood, but I am not rejecting programming with AI

If anything, I believe the use of AI will become essential in software development from now on

However, mastering AI and depending on AI are different things

Understand AI-generated code, identify problems, and modify it when necessary

This requires a foundation in programming

And to develop those foundational skills, it is surely helpful to have the experience of thinking for yourself, writing code by hand, and repeatedly failing, without relying on AI

For example, education might be divided into two stages

The first stage is programming education without AI

Here, you learn about algorithms, data structures, memory, the principles of program execution, and so on, through hands-on experience

The second stage is programming education that makes active use of AI

Here, you learn how to have AI generate code and how to understand, review, test, and improve it

By combining these two approaches, perhaps we can nurture engineers who can truly make use of AI, rather than merely having AI write code for them

Could we not turn inconvenience into an educational resource?

Current programming education seems to be moving in the direction of producing results quickly and making it easy to create applications.

That, in itself, is important.

However, whether a completed application runs and whether you understand how it works are separate issues.

The more AI makes code generation easy, the more significant this difference will become, I believe.

Programming environments in the past had countless inconveniences.

Reading manuals over and over, drawing flowcharts on paper, being unable to determine the cause of an error, and struggling for hours.

Back then, I dreamed of a time when I would no longer have to endure such hardships.

And that era actually arrived.

But now, in turn, that convenience may cause us to lose opportunities to learn the fundamentals.

It is quite ironic.

Of course, not all of the old teaching methods were superior. If learners are made to repeat meaningless struggles, no learning effect can be expected.

What matters is not reviving the old environment as it was, but reconstructing the educational value inherent in the inconveniences of those days in a way suited to the present .

For example, provide only a PC disconnected from the network, a C compiler, a simple editor, and a paper manual.

There, start with a simple program and have learners gradually create increasingly complex processes.

Have them examine the contents of memory and the operation of machine code as needed.

Then, finally, have them use AI to solve the same problem and compare the result with the code they wrote themselves.

Wouldn't such an educational environment be a good thing?

Precisely because it is an era in which AI can write code, perhaps we deliberately need time to write code without using AI.

Lately, I have been thinking about such things.

I also think it would be interesting if someday I could create an environment in which such education could be conducted.