Why doormen are still around but lift operators disappeared

The world definitively doesn’t have a shortage on blog posts or articles on what AI could do. Mostly those takes are very futuristic to say the least. The purpose of this blog post is to focus on what is really possible today.

To frame the story, let’s go back in time.

For roughly the first half of the twentieth century, most lifts had a person inside them. The operator opened the door, asked which floor you wanted, and took you there. Automatic lifts had existed since around 1900, but passengers did not trust a car with no one at the controls. What broke that deadlock was not better technology. It was a strike.In 1945, New York lift operators walked out and kept about 1.5 million office workers out of their buildings, at a cost to the city of around 100 million dollars. After that, building owners moved to automatic lifts, and within a couple of decades the occupation was gone.

Around the same period, most hotels also had a doorman. On the surface, his job was just as simple: open the door for guests.Automatic doors are now as mundane as anything, and yet doormen are still very much around. So why did one occupation disappear while the other one remained, when both looked equally easy to replace?

There are socio-economic dimensions to this, but the core of it is simple. The lift operator's job could be fully specified. There are no exceptions that need human judgement. If a guest wants to reach the seventh floor, they want the seventh floor. End of story. The doorman worked in a much more complex environment. He was not just opening a door. He was judging who gets in and who does not, delivering packages, greeting regulars, helping with luggage, handling the occasional VIP. That work is judgement-heavy, and judgement is exactly what does not automate away.

How a startup writes code today

To see where this lands for software, start with how we build at Nomain.

Very much like the doorman, we engage closely with our customers. Those engagements turn into concrete identified pain points, which are turned into feature requests. Our developers research those feature requests with our own coding agent with the whole code base as the context. The question is: what is the user pain point, how can we address that, and what does it mean for our code base? That becomes a clear spec detailing what needs to be done and how it relates to our architecture and data model. Our developers rarely write a single line of code by hand. They keep the big picture in mind and supervise what the agent does.The finished code is then reviewed by another agent and tested automatically with unit tests and our end-to-end tests. The last review is always done by a human team member, but having the review agent allows to focus on the big picture, on the shape of the feature and architecture, not the code itself.

So, even though this sounds like a fully automated process, why are we still hiring more people? Because a product developer does much more than write code. The job is about understanding what we are actually doing, how will tech-decisions fit into our architecture, what kind of demands does the use-cases pose (like latency and efficiency) and what feels right. That is human judgement. A developer has to know the overall architecture, the data model, and the context the software runs in, and then choose the approach accordingly.

The human brain is more powerful than we tend to realise. Right now, AI looks very capable in the first few iterations, but it introduces a new risk: going too fast while not realizing what you are doing. A weak developer paired with AI is the most dangerous combination in IT today. When human judgement is outsourced to AI, it is remarkably easy to iterate yourself into a mess that can no longer be salvaged. Even with an experienced team, we can move too fast when we are trying to ship a large feature quickly and stop holding the big picture in mind as tightly as we should.

That said, AI works. We are highly efficient with a very small team and there is no arguing around that. This is a picturefrom early 2026, when we really were rolling out our agentic development workflow and achieved over 150% increase in output in just a couple months.

‍

‍

The doorman line in development practices

The parallel to the doorman is clear once you look at the tasks that a development team does.

The tasks that we’ve outsourced to AI, such as impact analysis and writing code against a clear specification are tasks with a well-defined goal. They are fully specified. The code either passes tests or not and compiles or it does not. You have either mapped all the dependencies or you have not. That is lift operator work, and AI can do them faster and better than a human. Deciding whether your code is actually fit for the purpose the end user has in mind or aligned with your architecture and data model is a judgement call. That is the doorman deciding whether to let a drunk guy into the hotel at three in the morning.

What is different about the mainframe

Most of our customers work in an environment very different to us. Instead of micro services and cloud-native components, they operate with a monolithic mainframe code base, under strict regulatory confines and in a huge organization.

From a development point of view, nothing about a mainframe environment is fundamentally different from a modern stack. In both cases there is a server running machine-readable instructions to complete a task that is valuable to a person or a business.

The programming language differs of course. COBOL,JCL, PL/I and Easytrieve instead of the latest version of C#. But that is not rally the problem. Language models have seen millions of lines of legacy programming languages and they understand them well.

Code base size is another difference. Nomain's own product is around 500,000 lines ofcode. At mainframe users, we are now routinely analysing 25 million or even 100million. It is true that an LLM context window cannot hold all of that at once.But there are workarounds, and Nomain is a direct example of one. We turn thewhole code base into multi-level knowledge graph, which lets us analyse evencomplete banking systems at once with high accuracy.

One difference that really counts is the stakes. If our AI introduces a bug into Nomain's code, we can roll back to the previous release in a matter of minutes and that would be catched by our CI/CD pipeline anyway before going to production. Our operations are not regulated (apart from ISO27001 standard) and we are not critical infrastructure. We can take more calculated risks without facing a regulator's fine or the losses that follow when customers cannot buy a policy or reach their bank account. So it makes complete sense that banks and insurers do not work the way we do.

That leads to the second real difference, which comes from processes and developer setup.

Start with processes. Banks and insurers optimised their ways of working for a very different era and environment than a startup. A large enterprise carries far more communication overhead, more competing incentives, more initiatives, and more stakeholders who all have to work together than a startup does. Business knows the business, but not the challenges a large legacy estate creates. Developers know the actively developed code, but not always what the organisation is trying to achieve. What does a business analyst actually mean by a new user-story? What is genuinely required by law for motor insurance? On top of that, functionality is split across many systems owned by different teams, so understanding of end-to-end processes and their implementation can be scattered across dozens of people.

Then there is the technical setup of development environments and tooling developers are used to. Often mainframe development happens in a terminal window. Test environments have different data for regulatory reasons, along with different batch jobs and different code from production. There is often no modern version control, which makes rolling back a production problem very hard. That makes a truly agile feedback loop almost impossible, because new code can really only be tested in production. Modern AI tools are built for a modern DevOps experience: Git and VS Code. Moving from a black screen with code in Changeman and TEXO to using VS Coed and Git is a large cultural change, and training hundreds of people in a new way of working is always a significant shift. It carries technical challenges too, such as keeping the Git repository exactly in step with the version of the code on the mainframe. And because there is always a lot to do, people will resist a new way of working for as long as they can. "I am too busy right now to learn that new thing, I will just get this done the way I know."

Here is the encouraging part. These problems are not actually hard. DevOps and processes are the whole of it, and both can be moved onto AI-based practices without heroics.

The mainframe itself was the disruption once.Work done on paper moved onto a computer. “Lift operator tasks”, such as calculating a premium, were automated onto a machine. I bet many people were too busy doing calculations by hand, to program the same calculation into a mainframe application. Moving from a black screen to VS Code is not drastic by comparison.

I recently spoke with a member of a Microsoft black belt team, and his point stuck with me: companies that still run traditional mainframe DevOps are in a genuinely good position. They can start their modernisation directly in the AI era. The team is not fatigued from constant change, and they can start their journey with an open mind. Yes, it takes work. It needs change management and work across the organisation. But AI is not slowing down, and the benefits are hard to argue with.

AI is also easy to use

The whole interface is a question. "I would like to get this done, how should I start?" Is the output always perfect? No. Probably the automated lifts in the early days also had some bugs in the start, and people didn’t trust their safety. But as adoption grew and the rough edges were sanded away, it became the new normal. If you pick the use cases for AI well, you get outputs that are at least on par with a human one.

A few things people at our customers have already achieved with Nomain:

One team ran an impact analysis on a system that hadn’t been touched for years. The work took several people three days. Afterwards they asked Nomain to check the dependencies, and it returned the result in 52 seconds. The answer was the same as the team produced by hand. It barely makes sense to calculate the efficiency gain, because it is so high for that one task.

In other cases, non-technical business experts have handled a production incident on their own by asking Nomain for a root cause analysis. Nomain found that the likely cause was a transient timing issue and advised a retry, which worked. A developer's time was saved as the business expert was able to handle it on their own and everyone stayed focused on their own work. Extrapolate that with all business analysts in a large organization and the savings in time amount to hundreds or even thousands of hours saved every year. Nomain has also traced where a specific on-screen error message originated, again saving a lot of manual effort.

So the technology is here, it is available, and the benefit to the whole company is hard to dispute. What I see at many of our customers is a lot of potential to build an AI-native mainframe organization or try out their first cloud migration with better tools than any generation before.

Which brings us back to the doorman and the lift operator. When you go back to your work after reading this, look at the tasks in front of you. Do they involve lift operator work? Impact analysis, writing code against a clear spec, incident response, drafting user stories. If so, let AI handle it, and spend your own judgement where humans are still the best. Be the doorman.

‍