When I started as a software engineer in the 1990s, I programmed COBOL on the IBM mainframe. Later, client/server applications came along. Many things were simpler back then. Not the technology, but the organization. I talked to the customers, gathered the requirements, did the architecture and the design, wrote the code, and made sure the application ran in production. Everything from one hand.

Today, more than 30 years later, I have the feeling: we are back. And that is good news.

How We Lost the Roles

Over time, projects became bigger, and so did the teams. So we specialized. The business analyst writes the requirements. The architect does the architecture. The developers implement. The testers test. And operations brings everything into production.

On paper, this looked good. In practice, it had a big disadvantage: every handover loses knowledge. The developer never talked to the customer. The architect never sees how the system runs in production. And in the end, the customer does not get exactly what they wanted.

Agile methods tried to solve this problem. Cross-functional teams, short iterations, close collaboration with the product owner. This helped. But the roles stayed. Only the handovers became shorter.

What Changes with AI

With AI coding agents, a big part of the implementation work goes away. Writing code, writing tests, boilerplate, migrations, mappings: AI can do this very well and very fast today.

This means one person suddenly has time for the whole thing again:

  • talk to the customer and really understand the problem
  • describe the requirements clearly
  • define the architecture and the design
  • guide and review the implementation done by the AI
  • make sure the application runs safely and stable in production

This is exactly what I did in the 90s. Only faster.

The Difference to Back Then

But it is not exactly the same as before. Two things are different today.

First: The specification is now input, not just documentation.

In the past, I often had the requirements in my head. I talked to the customer and then started programming directly. This worked because I was the developer myself.

Today, the “developer” is an AI. And the AI was not in the meeting with the customer. It only knows what I tell it. That is why the specification suddenly becomes the most important artifact in the project. If you write a good specification, you get good code. If you write a bad specification, you quickly get a lot of bad code.

Actually, this is an old idea. COBOL was designed to look almost like English. Even business people without programming knowledge should be able to read the code. Today we are one step further: we really write in natural language, and the AI turns it into code.

This is the core of Spec-Driven Development: the requirements come first, and everything else is derived from them. That is why, in the AI Unified Process, we work with requirements, use cases, and an entity model before the first line of code is written.

Second: The systems have become more complex.

In the 90s, I had a mainframe with COBOL programs and terminals. Later came client/server: a database server and an application on the PC. That was manageable. Today we have cloud, containers, security, compliance, observability, and much more. So today’s all-rounder needs very broad knowledge.

And they need a skill that was less important before: judging whether the result is correct. The AI delivers code that looks good. But is it also correct? Is it secure? Does it fit the architecture? Only someone who understands the whole system can judge this.

The New Role: The Architect Who Gets Their Hands Dirty Again

If I had to describe this role, I would say: it is an architect who gets their hands dirty again. They understand the business, they know the technology, and they guide the AI like an experienced developer guides a team.

This also means: the most important skills are no longer syntax and frameworks. The most important skills are:

  • Listening and understanding what the customer really needs
  • Writing clearly, so that humans and AI understand the same thing
  • Thinking in a structured way, so that architecture and design are right
  • Reviewing critically, so that only good code goes into production

These skills were always important. Now they are essential.

What Does This Mean for Teams?

So do we no longer need teams? Of course we do. Nobody builds large systems alone. But teams become smaller, and each person has more responsibility for the whole again. Fewer handovers, less loss of knowledge, faster feedback cycles.

For companies, this means: invest in people who see the big picture. And invest in clean specifications. They are the foundation for everything the AI builds.

Conclusion

I find this development very exciting. After 30 years of specialization, we are coming back to what software engineering really is: understanding a problem and building a good solution. From start to finish.

The tools are new. The principle is old. Keep IT simple.