Will AI be a Job Killer? Or Creator?

AI Systems and Steam Engines

AI is a really powerful technology. 

Especially GenAI for software. 

It reminds me of the first steam engines. Around the year 1800.

Gigantic machines. But minimal efficiency, compared to the standards of today (2026). 

Though back in 1800, they were like the eighth wonder of the world. Efficiency? Less than 1%. Not unlike the AI systems of today. But still impressive at the time.

And people had to find out how to use them efficiently.

Which they did.

And so they will for AI systems. We will find ways to put them to good use.

Some jobs will be replaced by AI. But a lot more will be created.

See my Article: "Requirements for Measurability and New Jobs in Software Development"

The article in IT Spektrum 1/26

Here's an overview, generated by Google Gemini:

https://www.sigs.de/artikel/requirements-fuer-messbarkeit-und-neue-jobs-in-der-sw-entwicklung/

The article itself is written in German. If you'd like to have an english translation, please let me know. I'll provide it.

Overview of the Article 

"The article "Requirements for Measurability and New Jobs in Software Development" by Martin Rösch argues that Requirements Engineering (RE) and Architecture will remain the most important components of software development in the long term, especially in the age of Artificial Intelligence (AI).

Overview of Key Statements

• Requirements provide Measurability

• Zero-Defect Software Development

• Connection to Cognitive Psychology

• Dealing with VUCA

• Four Types of Knowledge Areas

• Process Adaptation

• Suitability for AI

• Consequences of GenAI (Generative AI)

• Conclusion - New Jobs

Key Statements

Requirements provide Measurability: The author describes how requirements (Anforderungen) in conjunction with acceptance criteria (AKs = test cases) already introduced objective measurability into software development in 1994 and saved projects by helping to resolve disputes about the "correct" object model.

Zero-Defect Software Development: Defect-free software could (beginning in 1994) be developed through the precise documentation of requirements and Acceptance Criteria (AKs), as well as the automated verification of object models. The questions about concrete AKs helped to identify the real experts.

Connection to Cognitive Psychology: Object models describe not only the business core of the software but also the stakeholders' understanding. According to ISO 30173, the "Real Twin" of the Digital Twin is the perception / imagination in the minds of the stakeholders.

Dealing with VUCA: Problems arise in RE when more than one knowledge area (KA, German: WG) is considered. The resulting frustration is described with the acronym VUCA (Volatility, Uncertainty, Complexity, Ambiguity). The solution lies in treating each knowledge area separately and connecting them precisely instead of creating a single large collection of requirements.

Four Types of Knowledge Areas: A distinction is made between (1) the business KAs of the users, (2) the technical KAs of the system, (3) the KA for process for creating the system, and (4) the KAs for each usage process of the system.

Process Adaptation: Large systems consist of n knowledge areas. The processes must be adapted to document KAs individually (requirements, AKs, object models) and to perform the integration not at the requirements level, but at the object model level (analogous to Amazon's approach to enterprise IT architecture).

Suitability for AI: Well-defined requirements and AKs (as automated tests) minimize AI hallucinations. Automated code generation by AI is expected.

Consequences of GenAI (Generative AI): Copy & Paste coding will disappear because AI is faster and better at that kind of work. The author draws a historical comparison with the introduction of the steam engine, where automatable parts of the work were automated, jobs were lost, prices fell, demand rose, and ultimately more new jobs were created.

Conclusion - New Jobs: In the long term, only RE (future knowledge documentation) and Architecture will remain from today's software development. More jobs will be created for knowledge documentation and for architects who design and connect all four types of knowledge areas. The reason for this is that RE brings measurability, precision, and quality, which leads to faster production, lower prices, and thus to a rising demand for individual software. "

If you ask for the full text (plus graphics) in English, I'll provide it.

Happy Reading !

The Time Has Come, For Creating Software Straight from Knowledge

After a break of 18 years, ...

... I now continue this blog.

Because AI has made it possible to generate software from descriptions of knowledge.

This is a game changer.

Now it gets interesting. 

Now AI can take care of the ugly parts of software development. 

The title I gave this blog in 2008 was "Software-Entwicklung ist Wissensverarbeitung". This is German and translates to "Developing Software is a Kind of Knowledge Processing". 

Maybe I was a bit early. 18 years early, to be precise. 

But the world has turned and now a few more people seem to agree.

Watch out for more to come.

Swiss Life vergeigt Großprojekt Amarta

Ich habe schon mehrere große und sehr große Projekte persönlich kennengelernt. Und alle hatten dasselbe Problem: Software-Entwickler merken nicht, wenn sie die Grenzen ihrer Verständnisfähigkeit erreichen und überschreiten.

Software-Entwickler stellen sich ihre Rolle gerne so vor, dass sie etwas Neues erschaffen. Doch tun sie das wirklich? Ja, die Software, die sie schreiben ist neu. Das ist unbestreitbar. Doch das, was die Software macht, sollte besser nicht neu sein, sondern haargenau das, was die Anwender als Lösungswissen für die gestellte Aufgabe formuliert haben.

Also erschaffen Software-Entwickler nicht etwas Neues, sondern wandeln Wissen von einer Darstellungsform (Wissensdokumentation) in eine andere (Software) um. Das Wissen ist der Rohstoff, der von Software-Entwicklern verarbeitet wird. Doch was braucht man für die präzise Bearbeitung eines Rohstoffs?

(1) Man muss in der Lage sein, das fertige Produkt präzise zu beschreiben (spezifizieren)
(2) Man muss Produkte ebenso präzise fertigen können
(3) Man muss präzise messen können, ob erstellte Produkte ihre Spezifikation erfüllen

Diese Grundregeln werden in Software-Projekten heute noch gewohnheitsmäßig missachtet.

Stattdessen gilt das Prinzip "Gruppen-Konsens". Und das geht so: Eine Gruppe von Anwendern und Entwicklern beginnt mit der Entwicklung eines Teilprojekts. Sie bilden sich eine Gruppenmeinung und handeln anschließend danach. Andere Teilprojekte arbeiten ebenso. Das Ergebnis:

1. Die Meinungen verschiedener Gruppen passen nicht nahtlos zusammen. Doch das merkt man erst, wenn die fertigen Software-Module nicht wie erwartet zusammenarbeiten.
   
   
2. Noch verhängnisvoller: Eine Gruppe erstellt ein Teilprojekt und geht dann auseinander. Ein Jahr später bekommt eine andere Gruppe die Aufgabe, das Teilprojekt zu überarbeiten. Auch sie bilden sich einen Gruppenkonsens, auf dessen Basis sie handeln. Mit ganz viel Glück stimmt ihr gefundener Konsens mit dem der ersten Gruppe übereinstimmt, mit nur wenig Pech aber weicht er ab. Das ist der Zeitpunkt, wo Fehler entstehen.

Analyse

Großprojekte (> 10 Mio EUR) verarbeiten viel Wissen. Und zwar mehr als in einen Kopf passt. Und auch mehr, als eine Gruppe von Menschen als gemeinsames Gruppenwissen aufbauen kann. Deshalb muss Wissen einfach, kurz und klar beschrieben werden. Sowohl das eigene, als auch das, was man von anderen Gruppen erwartet oder ihnen zur Nutzung anbietet.

Anforderungen, Regeln, Fakten und Beispiele: So haben Menschen seit vielen Tausend Jahren Wissen weitergegeben. "Exemplum docet" (Das Beispiel lehrt) wussten schon die alten Römer. Warum soll das nicht auch für Software gelten?

Und wenn dann jede Gruppe ihr Wissen, eingebettet in die für sie sichtbare Umgebung, beschreibt, modelliert und mit Hilfe einer kleinen Simulation auf Richtigkeit prüft, dann können auch Software-Entwickler die Sicherheit bekommen, dass ihre Software richtig ist. Auch und grade dann, wenn sie Teil eines viel größeren Ganzen ist.

Mit diesem Vorgehen habe ich die besten Erfahrungen gemacht. Es funktioniert.

Doch die Rolle der Software-Entwickler wird ein kleines Stück entzaubert: Sie sind nicht mehr die gottgleichen Schöpfer grandioser Software-Systeme, sondern getreue Dokumentierer von Wissen und anschließend seine sorgfältigen Bearbeiter, indem sie es in Software verwandeln.

Ob Swiss Life in diese Komplexitätsfalle getappt ist, kann ich nur vermuten. Ich halte es aber für sicher.

Kann man Datenqualität managen?

Fehler in Daten sind ärgerlich. Daher das Interesse an Datenqualität. Doch kann man Datenqualität managen? Ich denke, das geht nur indirekt, über Software- und Prozess-Qualität.

Warum? Das Ziel von Datenqualität sind "richtige" Daten. Das heißt, sie sollen keine Fehler haben. Was ist ein Fehler? Die ISO 9000 sagt: Wenn eine Anforderung nicht erfüllt ist, dann ist das ein Fehler. Also brauchen wir Anforderungen. Aber an was? An die Daten? Wer Datenqualität direkt managen will, stellt sich das so vor. Doch schauen wir mal genauer hin:

Daten sind immer das Ergebnis eines Prozesses: entweder eines manuellen. Das nennen wir dann Geschäftsprozess. Oder eines automatisierten. Das ist ein Software-System.

Also kommt ein Fehler in den Daten immer aus einem fehlerhaften Prozess. Und den muss man reparieren, egal ob Software oder Geschäftsprozess. Dann erzeugt er auch die richtigen Daten.

Ergebnis: (1) JA, Datenqualität kann man managen. (2) NEIN, man kann sie nicht direkt managen. (3) Der Weg zur Datenqualität führt über richtige Prozesse - egal ob manuell oder IT. (4) Daher beginnt DQ mit Anforderungen an Software und Geschäftsprozesse. (5) Wenn alle Anforderungen erfüllt sind, dann stimmen auch die Daten.

Wer DQ direkt managen will, versucht, ein Haus vom Dach her zu bauen. Das ist die falsche Reihenfolge.