Coding is the easy bit

In Rory Sutherland’s 2021 book Alchemy, he describes The Doorman Fallacy:

The ‘doorman fallacy’, as I call it, is what happens when your strategy becomes synonymous with cost-saving and efficiency; first you define a hotel doorman’s role as ‘opening the door’, then you replace his role with an automatic door-opening mechanism.

The problem arises because opening the door is only the notional role of a doorman; his other, less definable sources of value lie in a multiplicity of other functions: taxi-hailing, security, vagrant deterrence, customer recognition, as well as in signalling the status of the hotel.

Rory Sutherland

Since 2021, AI has made us all look like doormen. We have roles that are apparently easily defined and therefore automated. Unfortunately though, the parts of the job that are easiest to define are least important to success. An individual’s value resides almost entirely in the “less definable” parts of the job.

4GLs and low code development

In the 1980s and 90s, fourth generation programming languages (4GL) gained popularity as an alternative to code heavy languages such as C, C++ and latterly Java. 4GL is a broad concept but I’m referring specifically to ‘form generator’ drag and drop tools such as Visual Basic and ‘database forms’ included in Microsoft Access. The design intention is sound: 4GLs are specialised tools designed for a narrow set of problems. What followed though was problematic. Decision makers saw high productivity from relatively low skilled workers using 4GLs and assumed that the productivity gain would apply equally to generalist programmers.

The concept still exists today as “low code platforms” and “graphical programming environments”. I recently used Avaya Orchestration Designer – a tool for creating call centre IVR (interactive voice response) systems by dragging and dropping components into a flow. The marketing blurb highlights a reality gap:

Orchestration includes a Designer interface, which is a graphical tool that account administrators can use to create workflows that manage how interactions route through the contact center according to business needs.

Avaya Orchestration

The assumption is that the tool is so easy to use that ‘administrators’ can meet the business needs themselves. The ‘development’ or ‘engineer’ role is redundant in this workflow. It’s a graphical tool, therefore the engineer’s specialist skills are not required.

This is the first doorman fallacy of software engineering. Managers and decision makers see developers typing and quite reasonably assume that an engineer’s role is typing commands into a computer. If you can automate away the typing, you can could have ‘administrators’ build the systems in their spare time.

When I worked with graphical tools such as Avaya Orchestration, I found them to be excellent at defining the behaviours of the call centre. However, they were absolutely awful for source code management, configuration management, code review (how do you diff a picture?), environment management, deployment, unit / automated testing, scaling and high availability, logging, monitoring and all the general problems that software engineers worry about.

This is why my employer chose to hire software engineers rather than call centre administrators to build IVRs. Call centre admins would write IVRs that perfectly capture business requirements but would not stand up to the rigours of a production environment and unpredictability of real world users.

AIs and vibe coding

And so in 2025 we see new tools and techniques but the same old problems and assumptions. First off, AI is surprisingly good at comprehending and writing code. And it’s early days so it’s only going to get better. So certain businesses and decision makers are gleefully looking forward to reducing bills on expensive engineers. Given AI’s capability, we can replace experienced developers with less experienced ones plus their AI companion. Or just automate the juniors altogether! Just as with low-code platforms of the last couple of decades and 4GLs before that, I advise caution. They’re all great tools but they have limits.

Let’s assume that AI gets to the stage where it will generate 50% of my code. If you assume that I spend all day writing code, AI will make me twice as productive. Or if you prefer, you can hire half as many engineers. However, in a typical week I will spend time coding, testing, designing, specifying, fixing, maintaining, supporting, monitoring, planning and selling. If I can generate 50% of my code, I can maybe improve my productivity by 5%.

This is the second doorman fallacy of software engineering. Managers and decision makers see us writing code and quite reasonably assume that an engineer’s role is to create code. If you can automate away the coding, you can replace their roles with AI.

A former colleague of mine had many wise sayings but the wisest of all was:

Coding is the easy bit

Dave

The idea that an engineer’s job is to write code is so pervasive that many developers believe it. I’ve seen engineers who write beautifully crafted code, commit it to source control and leave with a sense of a job well done. Source code on your laptop or in source control is of no value. It becomes valuable only when it’s running and in the hands of real users who can do something useful with it. Engineering is a cost centre. It’s the users who create value. Users can’t solve some problems by themselves so they employ us (at considerable cost) to help them.

If engineers are to survive into the AI era, we need to be absolutely clear about what it is we do. We’re not typists. We’re not coders. We solve problems.