Die Idee, Entwickler könnten bald ersetzt werden, taucht in regelmäßigen Wellen auf. In den 60er Jahren hieß es, höhere Programmiersprachen würden das Problem lösen. Später sollten CASE-Tools, dann No-Code-Plattformen, dann Outsourcing den Bedarf an spezialisierten Entwicklern drastisch senken. Jedes Mal wurde es einfacher, Software zu produzieren. Und jedes Mal verschwand die Komplexität nicht, sie verlagerte sich nur.
Heute trägt diese alte Erzählung ein neues Gewand. Generative KI kann in Sekunden Code erzeugen, Tests schreiben, Refactorings vorschlagen. Gleichzeitig verlieren Junior-Entwickler und Regular-Entwickler spürbar an Marktwert, weil viele klassische Einstiegsaufgaben automatisierbar geworden sind. Und selbst erfahrene Entwickler werden in Deutschland entlassen, häufig aus Kostengründen oder aufgrund strategischer Fehlentscheidungen im Bezug auf KI.
Das wirkt wie ein Widerspruch. Wenn alles automatisiert wird, warum bleiben echte Seniors rar? Warum sind Architekten, die Systeme verstehen, weiterhin so gefragt?
Die Antwort ist unspektakulär, aber entscheidend: Werkzeuge reduzieren Oberflächenarbeit. Sie eliminieren keine Komplexität. Software ist kein Textproblem. Sie ist ein Strukturproblem.
Und genau dort trennt sich gerade der Markt.
Was gerade wirklich an Wert verliert
An Wert verliert vor allem reine Codeproduktion ohne strukturelles Denken.
Ein einfaches Beispiel:
Prompt:
„Erstelle mir eine REST API mit Spring Boot für Benutzerverwaltung.“
Das Ergebnis ist meist funktional:
- Controller
- Service
- Repository
- CRUD-Endpunkte
Alles läuft. Tests vielleicht auch.
Aber was fehlt oft?
- Keine klare Trennung zwischen Domain und Infrastruktur
- Geschäftslogik im Controller
- Direktzugriff auf JPA-Entities im API-Layer
- Keine expliziten Ports
- Keine durchdachte Fehlerstrategie
Kurzfristig sieht das produktiv aus. Langfristig entsteht Kopplung, die jede Erweiterung teuer macht. Auch mit KI. Wenn ein Junior nur lernt, so etwas zu generieren und zu akzeptieren, wird er austauschbar. Die KI liefert denselben Output.
Was stattdessen wertvoll wird
Wertvoll wird die Fähigkeit, Systeme zu formen.
1. Ports und Adapter wirklich verstehen
Nehmen wir dasselbe Beispiel, aber strukturiert gedacht.
Statt direkt auf JPA im Controller zuzugreifen, wird eine Domain-Schicht gebaut:
public interface UserRepository {
Optional<User> findById(UserId id);
void save(User user);
}
Das ist ein Port.
Die JPA-Implementierung ist nur ein Adapter:
@Repository
class JpaUserRepository implements UserRepository {
// mapping between JPA entity and domain
}
Der Controller spricht nicht mit JPA, sondern mit einem Use Case:
public class CreateUserUseCase {
private final UserRepository repository;
public void execute(CreateUserCommand command) {
User user = User.create(command);
repository.save(user);
}
}
Plötzlich entsteht:
- Entkopplung
- Testbarkeit ohne Datenbank
- Austauschbarkeit der Persistenz
- Klar definierte Verantwortlichkeiten
Eine KI kann diesen Code erzeugen. Aber nur, wenn jemand versteht, warum er so aussehen sollte.
2. Dependency Inversion bewusst einsetzen
Viele KI-generierte Lösungen hängen direkt an Frameworks:
@Service
public class PaymentService {
@Autowired
private StripeClient stripeClient;
}
Das sieht harmlos aus, koppelt aber die Fachlogik direkt an Stripe. Sauber gedacht würde man stattdessen ein Port definieren und dann eine Stripe-Adapter.
public interface PaymentGateway {
PaymentResult charge(Money amount);
}
class StripePaymentGateway implements PaymentGateway {
// Stripe specific logic
}
Jetzt hängt die Domain nicht mehr an Stripe. Sie hängt an einer Abstraktion. Das ist kein akademisches Detail. Das ist strategische Beweglichkeit.
3. Modularisierung statt Ordnerstruktur
Viele Projekte nennen sich „modular“, sind aber nur nach Technik sortiert:
- controller
- service
- repository
- dto
Echte Modularisierung schneidet nach fachlichen Grenzen:
- billing
- user-management
- reporting
- notification
Jedes Modul hat:
- eigene Use Cases
- eigene Ports
- eigene Adapter
Abhängigkeiten zeigen nur in eine Richtung. Das erfordert Denken. Und genau das wird gerade wertvoll.
4. KI richtig einsetzen
KI ist kein Ersatz für Architektur. Sie ist ein Beschleuniger. Statt zu sagen: „Schreib mir einen Service.“ Sagt man besser: „Erzeuge eine Clean-Architecture-Struktur mit klar getrenntem Domain-Kern, Ports für Persistenz und Messaging, Adapter im Infrastruktur-Layer, keine Framework-Abhängigkeiten im Domain-Modul.“ Der Unterschied im Output ist dramatisch. KI verstärkt Präzision. Sie verstärkt aber auch Unschärfe. Wer nur delegiert, produziert strukturelle Schulden in Rekordgeschwindigkeit.
Was Junioren konkret tun sollten
- Architektur lesen, nicht nur Tutorials konsumieren
Clean Architecture, Hexagonal Architecture, modulare Monolithen wirklich durcharbeiten. - Refactoring üben
Einen schlecht strukturierten Code bewusst in saubere Module überführen. - Tests ernst nehmen
Nicht nur happy path, sondern Verhalten absichern. - Domänenmodelle bauen
Geschäftslogik explizit modellieren statt in Services zu verteilen. - KI als Sparringspartner nutzen
Code generieren lassen, dann kritisch zerlegen:- Wo ist Kopplung?
- Wo sind implizite Annahmen?
- Wo wird Infrastruktur in die Domain gezogen?
- Verantwortung übernehmen
Architekturfragen stellen.
Abhängigkeiten hinterfragen.
Schnittstellen sauber definieren.
Warum das gerade die Chance ist
Der Markt selektiert gerade brutal, aber klar. Reiner Output verliert an Wert. Systemdenken gewinnt an Wert. Junioren, die sich jetzt in saubere Abhängigkeitsstrukturen, Modularisierung und Architektur vertiefen, entwickeln sich schneller in Richtung Senior als es früher möglich war. Nicht über Jahre von Tickets, sondern über bewusstes Strukturtraining. KI nimmt einfache Arbeit weg. Sie zwingt aber auch dazu, das Wesentliche zu lernen.
Und das Wesentliche war noch nie das Tippen von Code.
Es war immer das Entwerfen von Systemen.
