From Binary to Agents: Abstraction, Automation and the Future of Programming

WhyWhy each generation of programmers has been told that the new layer isn't "real programming", and what that tells us about the layer we are in now

Programmers complain when an AI tool writes imperfect code. Earlier generations would have found this strange. Programming was once done by writing numbers that the machine could execute directly. Then came assembly language, then compilers, then increasingly elaborate layers of abstraction, and at each stage someone was unhappy that the work had stopped being real. AI coding assistants may simply be the latest stage in a process that has run since the first computers.

My argument is that agentic coding is not a break with the history of computing. It is a continuation of a long movement of human attention away from the mechanics of implementation and towards the design of systems. That is a less dramatic story than either "AI will replace programmers" or "students shouldn't use AI", and I think it is a more useful one, for practitioners and for teachers.see also: delegation vs collaboration

Programming as Abstraction

AtAt its core, computer programming is about producing really big numbers that can be interpreted by other really big numbers to produce whatever output we want, which is represented as one or more numbers. Everything that follows is a question of how far up from those numbers we are willing to stand, and who, or what, is doing the standing-in.

The stack of abstractions a programmer now works through looks roughly like this, from the bottom up:

• machine code
• assembly language
• high-level languages
• libraries
• frameworks
• integrated development environments (IDEs)
• code completion
• AI assistance
• agentic systems

Every step in that list does three things. It removes friction, it increases how much one person can produce, and it raises the level at which the programmer has to think. None of them removed the need to understand what was happening underneath. They changed where that understanding was needed.

The pattern I keep seeing is that the layer which seems indispensable to one generation becomes invisible to the next. Few programmers today think about the register allocation a compiler performs for them, and most do not need to. The layer that is invisible is not gone. It has been delegated, and someone still has to know it works.invisible !: absent. bugs hide there.

A Timeline of Delegation

TheThe table below is a rough timeline. The dates are approximate, and each row names what was handed to the tool and what the programmer kept.

Two points in the timeline are worth dwelling on. The first is that the compiler step was not accepted quickly. Grace Hopper's A-0 system of 1952 is usually cited as an early compiler, and the question of whether it was the very first is debated^[1]. According to one account, it took about two years for her employer's leadership to accept the approach. The second is that FORTRAN, published in 1957, was built on the premise that a machine could turn a higher-level description into efficient machine code. The team described both the language and the design of the compiler in the proceedings of the Western Joint Computer Conference^[2].efficiency meant beating hand-coded assembly

The Myth of "Real Programming"

EventuallyEventually we got to IDEs because some really strange people don't like vim or emacs and invoking compilers from the command line (they will learn, one day...), and IDEs then got intellisense."

Pat Parslow

Every generation has a version of this sentence: assembly isn't real programming, C isn't real programming, Python isn't real programming, visual tools aren't real programming, and now AI-assisted development isn't real programming. Most of us have heard some of these things, and some of us have probably said them.

The recurring pattern is that each generation defines "real programming" as whatever abstraction it learned first. The people who wrote in assembly had good reasons to distrust the compiler. The people who used compilers had good reasons to distrust IDEs that hid the build. Some of those who still prefer a terminal and a plain text editor will tell you, with real conviction, that anything with a menu bar has taken the programming out of programming. I suspect that in twenty years the people who learned on command-line tools will be the ones insisting that a particular newer tool is not real programming. Working command-line first has real merits, and the argument for it is not that everything else is fake.

What changes with each new layer is not whether programming is real, but what expertise looks like. When a layer is automated, the skill that was once the mark of a good programmer becomes a commodity, and a different skill becomes scarce. Productivity improvements tend to provoke resistance for exactly this reason. They change the status of what people are good at.the gate moves up: what was hard becomes basic

What Actually Matters

IfIf the argument so far holds, the value of software engineering has been moving steadily up the stack. The scarce skills increasingly involve architecture, decomposition, interfaces, testing, understanding of stakeholders, requirements engineering, and trade-off analysis. None of these is the production of syntax, and most of them were never primarily about syntax.

Fred Brooks made a related point in 1987. He separated the essential difficulties of software, which come from the nature of the problem and its complexity, from the accidental difficulties, which come from the tools and notations we happen to use. Brooks argued that tools and techniques could remove many accidental difficulties, but that no single development was likely to produce an order-of-magnitude improvement, because the essential difficulty would remain^[3]. That argument has held up better than most predictions about programming, and it is the best single lens I know for thinking about each new layer of abstraction. Each layer removes some accidental difficulty and leaves the essential difficulty where it was, usually a little higher in the stack.essential: problem's inherent complexity

The New Failure Modes

AA history that only celebrated abstraction would be a poor guide, so here are the failure modes that go with each new layer.

• Hallucination. An AI assistant can produce an implementation that looks plausible and is wrong. The code may compile, pass a superficial check, and fail in a case nobody tested.
• Hidden complexity. Every abstraction conceals something. A compiler hides the machine's behaviour, a framework hides the protocol, and an agent hides the reasoning that produced a change. Concealment is the purpose of abstraction, and it becomes a problem when nobody knows what has been concealed.
• Over-reliance. Teachers and practitioners have worried about this at every layer. A programmer who cannot work without the tool has lost the ability to check what the tool produces.
• Validation. Responsibility never leaves the people who build and deploy the system. Delegation changes what needs checking, but it does not remove the need to check.

The historical precedent for the last point is formal inspection. Fagan's account of design and code inspections at IBM reported that inspections removed a large share of defects, between 60% and 90% by his figures, before the first test was run^[4]. The method works because it moves verification to the points where errors are cheapest to find. The same principle applies to AI-generated code. The more of the implementation a tool produces, the more important the verification becomes, not less.

The studies I have looked at point the same way. In a randomised trial with experienced open-source developers, tasks took longer with AI tools allowed, although the developers estimated afterwards that the tools had sped them up^[5]. A separate study of developers learning a new library found that AI use impaired conceptual understanding, code reading and debugging, with no significant speed gain on average^[6]. Neither study says that AI tools are useless. Both say that the feeling of having been helped is not the same as having been helped, and that verification has to measure the real thing.the illusion of competence: see the short-circuit page

Implications for Teaching

ThisThis is where the history stops being a story and starts to affect what we teach. The questions I keep returning to are the ones from the earlier pages on educational purpose and delegation, applied to programming.

What should students still learn? I would say decomposition, architecture, debugging, testing, reasoning about a system's behaviour, evaluating alternatives, and explaining a design. These are the skills that stayed with the programmer through every earlier layer, and they are the ones that become more important as the layers multiply. The reasoning behind protecting them is in Avoiding the AI Short-Circuit, which shows what happens when a shortcut replaces the struggle that builds them.

What should be delegated? Boilerplate, repetitive transformation and routine implementation are the obvious candidates, but only after the student understands what is being generated. The principle is the one in How I Use AI in Teaching, and How Students Use It Responsibly: a tool may take over work once the learner can judge it, and not before.

What should assessment measure? Not the ability to type syntax from memory, which no one needs to do under exam conditions. It should measure understanding, design, judgement and explanation, which is the approach in Teaching with GenAI. A student who can explain why a design was chosen, what it assumes, and how it was checked is showing the skills that the next layer will require.cf. assessment design over syntax

The pages on agent archetypes and on auditable agentic systems show what that design work looks like once the layer is an agent rather than a compiler.

Beyond Coding

II suspect the pattern is not confined to programming. Several other knowledge professions have gone through the same transition from execution to design, and the examples below are my own observations rather than a survey.

• Computer-aided design replaced hand drafting. The draughtsperson's skill moved from the mechanics of the line to the design of the object.
• Statistical software replaced hand calculation. The analyst's skill moved from arithmetic to choosing the model and checking its assumptions.
• Geographic information systems replaced manual cartography for many tasks. The skill moved towards deciding what the map is for and what it should leave out.
• Digital photography replaced darkroom chemistry for most photographers. The craft moved from the process to the composition and the judgement of the image.
• Word processing and writing tools changed what a draft requires. The writer's effort moved from the layout and the mechanics of revision towards the argument.

In each case there were people who said the new tool was not "real" drafting, photography or writing, and in each case the complaint lost ground as the new layer became normal. The coding story is one instance of a wider pattern, and it would be odd if the professions that depend on code were the only ones exempt from it.the tool becomes the medium

Conclusion

TheThe history of programming is not a history of programmers becoming less capable. It is a history of people choosing not to spend effort on problems that machines can solve reliably. Binary gave way to assembly. Assembly gave way to compilers. Compilers gave way to increasingly powerful development environments. Agentic programming looks like the next step in that progression.

The challenge is not to preserve the act of writing code for its own sake, and nobody should have to hand-write a binary encoding to prove they are a real programmer. The challenge is to make sure that, as implementation becomes easier, we keep developing the judgement, understanding and architectural thinking that decide whether a system is worth building in the first place. That is the part no layer has yet taken over, and it is the part worth teaching.

Related Topics

• Generative AI in the Curriculum: Delegation, Collaboration, and Educational Purpose — the purpose-first approach that this page applies to programming.
• Avoiding the AI Short-Circuit — the evidence on what shortcuts do to learning.
• How I Use AI in Teaching, and How Students Use It Responsibly — the wider position on responsible use.
• Teaching with GenAI: Require It, Then Ask What It Did — how assessment can ask for the judgement a tool cannot supply.
• Software Architecture Styles — the design decisions that remain with the engineer.
• Multi-Agent Systems — the coordination problems that arise when agents do the implementation.

References

1. Computing History (computinghistory.org.uk). Grace Hopper completes the A-0 compiler (1952). https://www.computinghistory.org.uk/det/5487/Grace-Hopper-completes-the-A-0-Compiler/
2. Backus, J. W., Beeber, R. J., Best, S., Goldberg, R., Haibt, L. M., Herrick, H. L., Nelson, R. A., Sayre, D., Sheridan, P. B., Stern, H. J., Ziller, I., Hughes, R. A., & Nutt, R. (1957). The FORTRAN automatic coding system. Proceedings of the Western Joint Computer Conference, 188–198.
3. Brooks, F. P. (1987). No silver bullet: Essence and accidents of software engineering. IEEE Computer, 20(4), 10–19.
4. Fagan, M. E. (1976). Design and code inspections to reduce errors in program development. IBM Systems Journal, 15(3), 182–211.
5. Becker, J., Rush, N., Barnes, B., & Rein, D. (2025). Measuring the impact of early-2025 AI on experienced open-source developer productivity. arXiv:2507.09089. https://arxiv.org/abs/2507.09089
6. Shen, J. H., & Tamkin, A. (2026). How AI impacts skill formation. arXiv:2601.20245. https://arxiv.org/abs/2601.20245