Machine Coding on Programmer.ie: Modern AI programming

The New Programming

Fri, 06 Nov 2026 00:00:00 +0100

The Introduction — An Opinion on the Future of Coding made a strong claim: the routine production of code is becoming a machine task, while the human task moves elsewhere. This chapter defines that move.

Traditional programming is about a human telling a machine how to perform a task. Machine coding is about a human organising machines to develop software.

That sentence is the distinction on which the rest of the book depends.

The Foundation Charter

Fri, 06 Nov 2026 00:00:00 +0100

The New Programming set out the division of labour: the machine increasingly produces the code, while I define the behaviour, organise the work, and judge the result. This chapter answers the first practical question that follows.

If the machine is going to do the coding, what should I decide before the work begins?

Ask a capable model to start a new project with no constraints and watch what happens. It will recommend several databases, compare frameworks, sketch alternative architectures, and generate configuration for all of them — before anyone has properly understood the problem. Left unconstrained, it will keep doing this. Each new task becomes an occasion to revisit settled questions, to introduce an inconsistent pattern, or to add a dependency that solves one small problem while creating three larger ones.

Configuring Your AI

Fri, 06 Nov 2026 00:00:00 +0100

The Foundation Charter settled what I am building and the ground I intend to build on. This chapter settles a different question: how I distribute intelligence across the work.

The objective is not to use the cheapest AI. It is to build the best software I can with the intelligence and tokens available to me.

That distinction matters because the most important place to spend intelligence may not be writing the code. It may be deciding what code needs to be written, and determining whether the result is correct.

Intent Before Implementation

Fri, 06 Nov 2026 00:00:00 +0100

The first three chapters established what machine coding is, what foundations to build on, and how to configure the intelligence that will do the work. This chapter is about what happens before any of that machinery engages: the moment when I do not yet know exactly what I want to build.

My starting position is deliberately strong:

If you can get it into words, the AI can build it.

That sentence describes my practical conviction after sustained machine coding, not a law of nature. Some ideas remain constrained by physics, by missing information, by permissions, by cost, by feasibility, or by the limits of available models — and producing an implementation is not the same as establishing that it works. Later chapters take up those constraints. But the traditional obstacle has substantially moved: translating an idea into source code is no longer the barrier it was. A developer can now explore an idea with a machine that helps develop the concept and can subsequently help implement it. Increasingly, I have found the ability to say what I want to be a more immediate constraint than the ability to write the code for it.

Give the Machine the System

Fri, 06 Nov 2026 00:00:00 +0100

Chapter 04 was about discovering what is worth bringing into existence. This chapter is about the world that new thing must inhabit.

An imagined possibility becomes buildable only when it meets reality: the client’s systems, the users, the infrastructure, the permissions, the obligations, and the things that cannot be compromised. My central claim is simple.

The machine needs to understand the world it is building within.

A machine can propose almost anything. My responsibility is to establish what it is allowed to build, what it must work with, and what cannot be compromised. That sounds like restriction, but it reads better in practice: once the machine understands the environment, it stops proposing elaborate systems that cannot be deployed and starts exploring solutions that are actually useful. Constraints, stated clearly, improve creativity rather than merely limiting it.

The Work Package

Fri, 06 Nov 2026 00:00:00 +0100

Chapters 02 through 05 established the conditions for machine coding: dependable foundations, configured intelligence, discovered intent, and an understood world. This chapter addresses what happens next — the daily practice itself. A goal exists, the machine is ready, the system is known. What, exactly, do I give the machine to do?

The answer I have arrived at, through enough failed attempts to respect the question, is the work package: a bounded engineering assignment that a machine can complete and an application can absorb. This chapter is about the skill of decomposing an intention into such pieces, directing their execution, and making the results accumulate into one coherent, working application.

Configuring Your Coding Machine

Fri, 06 Nov 2026 00:00:00 +0100

Chapter 06 taught the reader how to give a machine meaningful work. This chapter teaches how to equip the machine to perform it. Chapter 03 decided which intelligence each responsibility deserves. What follows decides what that intelligence can actually accomplish once it is switched on.

My central claim is simple, and I mean it as an engineering statement rather than a slogan:

The model is not the coding machine.

A coding machine is the model plus everything around it: the instructions it receives, the knowledge it can reach, the skills and capabilities installed, the connections to the outside world, the agent runtime that executes its decisions, the environment in which that runtime operates, the permissions that bound it, and the feedback that returns. Two agents built on the same underlying model can perform very differently on the same work package, because their machines differ. Configuring that machine is itself a programming decision — and, I have found, one with as much influence on the outcome as the choice of model.

A New Approach to Technology

Sat, 07 Nov 2026 00:00:00 +0100

The previous chapters built a method: foundations, configured intelligence, discovered intent, an understood world, bounded work packages, an equipped machine. This chapter steps back and asks what all of that means. I believe something larger than a workflow is happening — a change in humanity’s relationship with technology itself — and machine coding is one early instance of it.

The purpose of machine coding is not to make the programmer perform more operations. It is to make more of those operations unnecessary for the programmer.

Getting a Feel for the Machine

Sun, 08 Nov 2026 00:00:00 +0100

When I began machine coding, I thought the most important thing was choosing a capable AI. Capability still matters enormously, but I have discovered another skill that is harder to describe, and this chapter is about it.

You have to get a feel for the machine.

Different models behave differently. Some are quick to agree with you. Others seem to find something wrong with almost everything you hand them. Some are excellent at careful, repetitive changes but struggle to develop a complicated idea. Others can reason through an architecture beautifully and then make a mess of a simple implementation. And each has its own way of failing.

Follow the Process

Sun, 08 Nov 2026 00:00:00 +0100

This chapter makes a claim that may sound strange after everything so far. We have spent eight chapters moving the human away from implementation detail. Now I am going to argue for preserving something old-fashioned amid all that change: the discipline that keeps work traceable, reviewable, and recoverable — today taking the familiar shape of the git repository, the commit history, branches per unit of work, written notes, and a steady working cadence. Follow the process — even though the machine does the work.

Stop Slopping

Mon, 09 Nov 2026 00:00:00 +0000

The hardest thing about machine coding may not be getting the machine to produce something. It may be remaining in control while it produces far more than you can personally inspect.

Almost everyone who works extensively with AI discovers this the same way, in my experience — and I state that as strong practical expectation, not a measured universal. You begin brilliantly: a clear idea, a capable machine, rapid progress. The work expands impressively. Features arrive, interfaces improve, demonstrations dazzle. And then, almost without noticing, you have talked your way into something you never intended — something sophisticated, polished, and wrong. Not wrong in the way a bug is wrong. Wrong in the way a stranger is wrong: technically functional, and not yours.

It Happened Overnight

Mon, 09 Nov 2026 00:00:00 +0000

There is a particular feeling you get when you return to a piece of technology you once knew intimately and realise that most people no longer need to know it exists. It is not the same as discovering that a better version has been released. The work has moved. The thing you spent so much time learning is still going on somewhere, but it has stopped being your job.

I have been programming for nearly thirty years, and I have seen that happen before. I believe I am watching it happen again, this time to something much larger.

Build to Find Out