Machine Coding

The Walk That Changed How I Program

I had been programming for nearly thirty years, and I knew how much work could hide behind a few hundred lines of code. But for about a year I had been trying to get to grips with machine learning, and I was getting nowhere fast. I was reading papers, studying implementations, wrestling with unfamiliar ideas. I might get a notebook working, or write a blog post, but I was still spending most of my time trying to understand how to write the software instead of finding out what I could do with it.

Then, shortly after GPT-4 appeared, I was out walking my dog.

I had come across a research paper from Facebook. I wanted to understand it, and I had an idea: what if I turned the research into a trading system? Ordinarily, I would have spent weeks reading the paper, working through the algorithms, writing code and debugging my misunderstandings before I had anything worth trying.

Instead, I gave the problem to GPT-4. Here was the paper. Here was what I wanted to explore. Could it help me build it?

In what I remember as about three minutes, it produced a couple of thousand lines of code.

I looked at it and knew two things. I knew enough about programming to recognise that it had done a substantial amount of work, and I was confident the implementation would run. And I knew I could not have produced it myself in anything like that time. When I got home, I tested it. With a few minor changes, it worked.

That did not prove I had a profitable trading strategy, or that every line of code was perfect. But it proved something to me about the way I could work. A research idea that would have occupied me for weeks had become something I could actually try. The obstacle between the paper and the experiment had changed.

I remember the clarity of that moment. My days as a coder were over.

I did not mean that I would never look at source code again, or that machines could now be trusted to build anything without checking. I meant that, for my own work, I had stopped seeing hand-writing the implementation as the best way to create software. I wanted to explore ideas and see them become real. Now I had a different way to do that.

I had seen something change, recognised what it meant for me, and made a decision.

That is where this book begins. It is about noticing when the work has changed, being willing to change with it, and learning to use the machine to bring ideas into existence.

An Opinion on the Future of Coding

This book is about machine coding.

It is also an opinion.

We should establish that distinction at the beginning because what we are discussing is new. Very new. We are witnessing a fundamental change in the way software is created, and nobody can reasonably claim to have established the definitive way of doing it.

There are competing approaches, different tools, different models, and different philosophies. Some people use artificial intelligence to assist with programming. Others delegate entire implementations to machines. Some work interactively, reviewing every change. Others build automated systems that can operate for extended periods with limited human involvement.

Each approach has its merits.

This book presents one particular view, developed through approximately a year of practical experience building software with artificial intelligence. It is not intended to prescribe the only way forward.

Every developer will find their own path.

Nevertheless, we have arrived at a fairly strong conclusion.

Coding is, or will very soon become, a solved problem.

That statement requires some qualification.

We are not suggesting that all software problems have been solved. Nor are we suggesting that machines can reliably produce correct software from every vague instruction, or that the need for human judgement has disappeared.

We are making a narrower and, we believe, more consequential argument.

The mechanical activity of translating an understood requirement into programming-language instructions is becoming something machines can do sufficiently well that humans should no longer regard it as their primary responsibility.

That changes the nature of software development.

For decades, we have treated the ability to write code as the defining skill of a software developer. We learned programming languages, memorised syntax, studied frameworks, and developed an understanding of how computers execute our instructions.

These skills were necessary because the human was the programmer.

Now we have another participant.

A machine that can read code, write code, examine repositories, execute tests, diagnose failures, consider alternative implementations, and increasingly participate in the entire development process.

This is not simply a better text editor or a faster autocomplete system.

It is a change in the division of labour.

We believe that the responsibility for producing code should progressively move to the machine, while human attention moves toward deciding what should be built, why it should be built, how it should behave, and whether the result is acceptable.

This does not eliminate the complexity of software engineering. In some respects it exposes that complexity more clearly.

A machine can produce thousands of lines of code in minutes. Those lines may be useful, unnecessary, incorrect, elegant, or dangerous. The ability to generate them is no longer sufficient evidence of progress.

What matters is whether they accomplish the intended purpose.

Consequently, machine coding requires us to reconsider how we define problems, organise work, preserve knowledge, evaluate results, manage quality, and learn from experience.

Those are the subjects of this book.

We will present methods we have used, systems we have built, mistakes we have made, and ideas we believe deserve further exploration. Some of these ideas will undoubtedly change as the technology advances.

We make no claim to having the final answer.

But we do have an opinion.

The future of coding is that the machine does the coding.

The human has a different job.