Media & Appearances

Einstieg: Kunden gewinnen ohne Recruiter und Portale

Thomas: Freelancer gibt es da draußen sehr viele. Wirklich erfolgreiche, die ohne Recruiter und Portale an Aufträge kommen, leider nicht so viele. Aber einen habe ich heute hier. Marcus, schön, dass du da bist.

Marcus: Ich freue mich, da zu sein.

Thomas: Kommen wir direkt zum Thema: Wie gewinnst du deine Kunden? Und wie schaffst du es, auf Portale und Recruiter zu verzichten?

Marcus: Ich hole ein bisschen aus, weil das keine Selbstverständlichkeit ist. Als ich vor drei Jahren mit der Selbstständigkeit gestartet bin, habe ich mir fest vorgenommen, mich unabhängig vom Recruiter-Markt zu machen. Der war mir schon bekannt, und was mir daran nicht gefällt: Der Recruiter-Markt hat sehr viele Parallelen zum Arbeitnehmermarkt.

Wenn man sich das objektiv anschaut, sind die Projektausschreibungen sehr ähnlich zu Stellenausschreibungen — meistens nur nicht so hübsch präsentiert. Und der Bewerbungsprozess dahinter ist ebenfalls sehr ähnlich. Genau daraus wollte ich ausbrechen.

Die Entscheidung dazu habe ich Ende 2022 getroffen. Ich hatte zu dem Zeitpunkt keinen Kunden. Anfang 2023 habe ich gekündigt und losgelegt, mich selbst zu vermarkten.

Wie das am Anfang so ist: Man weiß nicht, was man tut. Ich habe einen Entwickler-Background, auch wenn ich direkt aus einer Managementrolle kam. Intuitiv versucht man dann erstmal, sich über technische Themen gut darzustellen und darüber in Projekte reinzukommen. Ich habe die typischen Fehler gemacht und einen Bauchladen angeboten. Mein erster Webauftritt ist mir heute ein bisschen peinlich. Sinngemäß stand dort: „Ich bin der Beste, ich kann alles, buch mich.“ Aber das funktioniert eben nicht.

Relativ schnell habe ich aus der Marktresonanz gelernt, dass man sich positionieren muss. Man muss eine Nische bedienen, die man klar benennen kann. Aber diese Nische ist eben nicht Java-Entwicklung. Sie ist auch nicht Softwarearchitektur. Eine Nische ist ein Problem, das der Kunde hat — und du hast dafür eine Lösung.

Man muss seine Denkweise verändern: Aus dem Problem heraus schnürt man ein Angebot. Man bewirbt nicht das Produkt oder die Dienstleistung, sondern die Problemlösung. Diesen Mindset-Shift musste ich erst hinbekommen.

Das hat sich natürlich entwickelt. Ich hatte diesen Bauchladen, bin auf Netzwerkveranstaltungen in der Umgebung gegangen und habe dort Gespräche geführt. Dabei habe ich schnell erkannt: Die beste Sales-Strategie ist, den anderen reden zu lassen und zuzuhören. Aktives Zuhören.

Daraus schnürt man ein Angebot. Wenn man das ein paar Mal gemacht hat, erkennt man Muster. Dann kann man das Angebot verallgemeinern und bewerben. Aber die Reihenfolge ist wichtig: Erst verstehen, welche Probleme die Wunschkunden wirklich haben. Erst danach kann man ein Angebot formulieren.

Das ist eine Lernschleife. Wenn man selbstständig startet, sollte man nicht den Anspruch haben, diese Schleife überspringen zu können. Das ist in Ordnung — aber man muss sich dessen bewusst sein.

Von Performance zur Gesamtbetrachtung

Thomas: Was war deine erste Positionierung? Viele kennen die Theorie mit Painpoints. Aber was war das konkret bei dir? Welchen Pain hast du gefunden? Bei wem?

Marcus: Nachdem ich erkannt hatte, dass der Bauchladen nicht funktioniert, habe ich überlegt: Was kann ich gut, und was ist am Markt nicht so stark vertreten?

Ich habe eine Historie aus der Gaming-Industrie, und dort ist Performance ein großes Thema. Ich habe an Online-Games gearbeitet. Da hat man viel Last auf den Systemen und eine andere Interaktion als bei klassischen Webseiten. Man hat nicht nur viele User, sondern viele User, die sehr viele Interaktionen ausführen. Aus dieser Historie heraus musste ich mich stark mit Performance beschäftigen, speziell auf der JVM.

Also dachte ich: Ich brauche eine Positionierung. Performance auf der JVM — das ist doch eine Nische. Auf dem Markt kannte ich niemanden, der das so angeboten hat. Das klingt erstmal gut.

Ich habe auf meiner Website einen Performance-Workshop als Einstiegsangebot beschrieben und bin damit auf Netzwerkveranstaltungen gegangen. Was sich dann herausgestellt hat: Wenn niemand etwas anbietet, heißt das nicht automatisch, dass man eine geniale Nische gefunden hat. Es kann auch heißen, dass es kein verkaufbares Produkt ist.

Genau das war der Fall. Die Leute hatten zwar Performance-Probleme, und ich kam darüber in Gespräche. Aber Performance war nur ein Symptom von vielen.

Ich erinnere mich an ein Gespräch mit einem Startup aus Duisburg. Die bauten eine Supply-Chain-Software, um Produktion in Asien und Verschiffung nach Deutschland zu managen. Die Anwendung war schon bei wenigen Nutzern sehr langsam. Aber das war nicht das einzige Symptom. Sie hatten lange Entwicklungszeiten, Features wurden nicht zeitgemäß umgesetzt, es gab viele Bugs, und Anforderungen vom Produkt wurden häufig iteriert, weil Entwicklung und Produkt aneinander vorbeiredeten.

Da kam ein ganzer Haufen zusammen. In dem Gespräch wurde klar: Sie brauchen keine isolierte Lösung für Performance-Probleme. Sie brauchen eine übergreifende Betrachtung der Software.

Wir starteten das Gespräch über einen Performance-Workshop. Verkauft habe ich dann einen Architektur-Workshop, den ich nicht vorbereitet hatte, den ich nicht beworben hatte, den ich noch nie gehalten hatte und bei dem ich noch nicht genau wusste, was ich mache. Ich habe ihn durchgeführt, es gab ein gutes Ergebnis, und danach habe ich den Kunden weiter betreut.

Beim nächsten Lead passierte dasselbe wieder: Einstieg über Performance, aber eigentlich brauchte der Kunde eine Gesamtbetrachtung.

Thomas: Spannend. Der offensichtliche Painpoint, mit dem du den Kunden bekommst, und das, was du am Ende verkaufst, können also zwei unterschiedliche Dinge sein. Mit welchem Angebot gehst du heute rein? Immer noch Performance?

Marcus: Nein, heute nicht mehr. Heute habe ich gelernt, dass es Bedarf daran gibt, Software im Gesamten zu betrachten.

Mein Wunschkunde hat — salopp gesagt — die Kacke am Dampfen. Es muss ein echter Schmerz vorhanden sein, idealerweise mit einem Leidensweg, der schon ein paar Jahre geht. Wenn ich diesen Kunden finde, biete ich dafür eine Lösung an: Wir machen zuerst eine Gesamtbetrachtung der Software.

Dabei schauen wir nicht nur auf Technik. Wir müssen auch Prozesse in der Softwareentwicklung betrachten, die Kompetenzen des Teams, die Einbettung des Teams in den Unternehmenskontext, die Führungsschiene und die Kommunikation von oben nach unten. Das hängt alles zusammen und lässt sich nicht isoliert betrachten.

Üblicherweise startet das mit einem Workshop. Daraus entsteht ein Bericht, der auch unabhängig von mir Wert liefert und den der Kunde weiterverarbeiten kann. In vielen Fällen geht der Kunde danach mit mir in die Umsetzung, weil es sich anbietet, die notwendigen Schritte gemeinsam zu gehen.

Warum persönliche Gespräche entscheidend sind

Thomas: Das ist auch ein niedrigschwelliges Offer. Du hast den Fuß in der Tür, man lernt sich kennen. Wenn du Kunden suchst, bei denen die Kacke am Dampfen ist: Wie findest du das heraus? Wie sieht dein ICP aus? Wie bekommst du die Pipeline voll?

Marcus: Das funktioniert nur im persönlichen Gespräch. Menschen kaufen von Menschen. Was für mich nicht funktioniert, ist eine Pipeline über E-Mail-Marketing oder rein über LinkedIn. Auch wenn ich auf LinkedIn aktiv bin: Über LinkedIn selbst verkaufe ich nichts. Ich verkaufe nicht über E-Mails und nicht über Ads. Das habe ich probiert.

Dafür ist das Produkt zu komplex, und es braucht Vertrauen. Ich verkaufe am besten über mein Netzwerk oder über Netzwerkveranstaltungen, bei denen echte Gespräche entstehen.

Thomas: Welche Netzwerkveranstaltungen würdest du empfehlen? BNI, EO, Meetups, eher techlastig oder PO-lastig?

Marcus: Ich schaue meistens auf meetup.com, was in der Gegend stattfindet. Entwicklerzentrierte Veranstaltungen besuche ich gelegentlich, aber ich erinnere mich nicht, darüber einen echten Lead gewonnen zu haben. Dort entstehen eher interessante Kontakte fürs Netzwerk.

Gut funktionieren Product-Owner-Veranstaltungen. Dort trifft man Menschen, die den Frust erleben, wenn Softwareentwicklung hakt. Da kann ein Champion im Unternehmen entstehen, der dafür sorgt, dass man reinkommt.

Außerdem schaue ich nach branchenspezifischen Veranstaltungen. Die beste Veranstaltung, auf der ich war, war 2023 eine CTO-Veranstaltung. Da waren nur CTOs. Ich bin über einen Kontakt reingekommen, sonst hätte ich sie nicht gefunden und keinen Zugang gehabt. Das war Gold wert. Aus einem Abend sind zwei Beauftragungen entstanden, die am Ende auch umgesetzt wurden.

Warum CTOs externe operative Unterstützung brauchen

Thomas: Ich hatte bei CTOs immer die Erfahrung: Das sind Techies, die wissen, was sie machen. Die haben ihr Team und ihr Netzwerk. Wie hast du es geschafft, daraus Leads zu machen? Was konntest du anbieten?

Marcus: Ich glaube, das ist ein Trugschluss. CTOs haben einen technischen Background und wissen in der Regel, wie es gemacht werden sollte. Sie kennen die Probleme und können sie benennen.

Aber sie haben ein Problem in der Hierarchie. Sie hängen zu weit oben. Sie können strategische Entscheidungen treffen, aber sie können sie nicht selbstständig operativ umsetzen. Dafür brauchen sie vertraute Personen darunter, die die Kompetenz mitbringen, es in die Umsetzung zu bringen.

Auch dort schwingt die Hierarchie mit. Jemand, der unterhalb des CTOs in der Umsetzung ist, hat immer noch Peers, mit denen er seit Jahren zusammenarbeitet. Der kann gewisse Entscheidungen nicht so durchdrücken, wie es für die Lage vielleicht notwendig wäre.

Den CTOs ist das bewusst. Diejenigen, mit denen ich zu tun habe, waren dafür empfänglich zu sagen: Wir brauchen jemanden von außen, der reingeht und Gewohnheiten durchbricht.

Das heißt nicht, dass man großen Stress erzeugt oder unfair agiert. Darum geht es nicht. Es geht darum, Gewohnheiten zu durchbrechen. Genau dabei kann ein Externer helfen.

Thomas: Das ist auch meine Erfahrung: Als Externer wird man fast zum Sprachrohr der Internen. Nicht im Sinne von „Thomas hat geile Einfälle“, sondern: „Ich wiederhole nur das, was mir dein Team sagt.“ Dadurch funktioniert die Disruption.

Marcus: Es gibt noch einen zweiten Faktor. Viele Entscheidungen müssen nach oben vertreten werden. Es ist menschlich, dass eine externe Analyse und externe Handlungsempfehlungen im Management oder in der Geschäftsführung stärker gewichtet werden. Diese politische Spielerei ist CTOs bewusst. Auch deshalb kann so etwas hilfreich sein.

Erfahrungen aus der Gaming-Branche

Thomas: Du hattest Gaming erwähnt. Ich kenne viele Klischees: Überstunden, schlechte Bezahlung, Crunch, alles muss Triple-A sein. Was sind Anekdoten aus deiner Gaming-Erfahrung?

Marcus: Diese Anekdoten kommen nicht von irgendwoher. Da ist schon etwas dran. Ich habe sieben Jahre in der Gaming-Branche gearbeitet. Dabei muss man sagen: Bei mir waren es Mobile Games und anfangs Browser Games. In Deutschland haben wir nicht so viele Triple-A-Studios. Was wir aber aufgebaut haben, ist die Free-to-play-Branche.

Dort unterscheiden sich die Firmen stark in ihrer Kultur. Ich habe bei einer Firma gearbeitet, bei der es so war, wie du beschrieben hast: hoher Leistungsdruck, schlechte Bezahlung. Ich bin damals mit 36.000 Euro Gehalt eingestiegen. Das war auch damals wenig. Gleichzeitig gab es denselben Druck, den man vielleicht auch bei einem VW-Konzern als Entwickler gehabt hätte. Wenn Release anstand, war es normal, am Wochenende oder spät abends zu arbeiten.

Auf der anderen Seite habe ich das total genossen. In der Gaming-Branche gibt es einen gewissen Schlag Mensch. Viele wissen, worauf sie sich einlassen. Gleichzeitig gibt es viele Bewerber, die dort rein wollen. Firmen können stark selektieren. Rückblickend war das allgemeine Kompetenzniveau sehr hoch, und ich habe unglaublich viel gelernt.

Es passieren dort aber verrückte Dinge. Eine Geschichte wurde mir erzählt: Eine Firma hatte ein Browsergame zu Battlestar Galactica. Sie wollte verhindern, dass Spieler mehrere Accounts nutzen. In den AGB stand schon immer, dass man nur einen Account haben darf, aber es wurde lange nicht durchgesetzt.

Irgendwann wollte man aus Fairness-Gründen Multiaccounts sperren. Also wurde über IP-Adressen gematcht und der Banhammer geschwungen.

Einen Tag nach dem Rollout stand plötzlich ein saudischer Scheich an der Rezeption, hatte einen dicken Ordner dabei und sagte: „Der Account meiner Tochter wurde gesperrt, ich möchte den Geschäftsführer sprechen.“

Dann wurde intern telefoniert, und es stellte sich heraus, dass über diesen Account mehrere Millionen Euro umgesetzt worden waren. Also wurde der Geschäftsführer geholt, der Account wurde entsperrt, und der Fall wurde persönlich geklärt. Das zeigt, welche absurden Dimensionen diese Branche annehmen kann.

Thomas: Ich kenne ähnliche Geschichten: sehr ungleiche Verteilung, ein kleiner Teil der Spieler macht einen großen Teil des Umsatzes.

Marcus: Das habe ich auch erlebt. Ich habe einige Zeit an Goodgame Empire mitgearbeitet. Das Spiel hatte damals 220 Millionen registrierte User. In der Spitze hatten wir 100.000 bis 200.000 Concurrent User auf dem System, bei Peaks ging es Richtung 300.000.

Zwischen ein und zwei Prozent der User haben überhaupt jemals Geld ausgegeben. Von diesen zahlenden Usern gab es wiederum einen sehr kleinen Anteil, der so viel Geld ausgegeben hat, dass er die gesamte Entwicklung finanziert hat.

Ich erinnere mich an ein System namens Private Offer System. Das war ein gezieltes Marketingsystem. Anhand verschiedener Parameter — zum Beispiel ob jemand gerade angegriffen wurde oder wie viel Geld er bereits ausgegeben hatte — konnte man gezielt Angebote machen.

Wir wollten einmal herausfinden, wo das Limit liegt. Es wurde ein Item-Set hergestellt, bestehend aus mehreren Items. Technisch waren das Bilder und ein paar Werte, die ein Balancer eingetragen hat. Ich habe es im System eingepflegt. Mit allen Beteiligten war das vielleicht ein Tag Arbeit.

Jedes einzelne Item wurde für 500 Euro verkauft, das Gesamtpaket also für 3.000 Euro. Ich habe das freitags live geschaltet. Montags fragte ich nach, wie oft es verkauft wurde. Es wurde übers Wochenende 63-mal vollständig verkauft. Offensichtlich war das nicht die Grenze.

Das zeigt: Das eigene Verständnis davon, was teuer ist und welchen Wert etwas hat, muss nicht mit dem Wertverständnis des Gegenübers übereinstimmen.

Das kann man auf die eigene Arbeit übertragen. Man sollte sich nicht fragen: „Finde ich meinen Workshop für 6.000 Euro am Tag teuer?“ Die Antwort wäre wahrscheinlich ja. Man muss fragen: Ist der Wert, den ich schaffe, für mein Gegenüber und dessen Kontext gerechtfertigt? Mit welchen Summen hat der Kunde zu tun?

Wie man Keynote-Speaker wird

Thomas: Du bist nebenher auch Keynote-Speaker auf größeren Events. Für viele Freelancer ist es schon ein Ziel, Speaker zu sein. Wie wird man Keynote-Speaker? Wie hat sich das bei dir entwickelt?

Marcus: Das war kompletter Zufall. Ich habe nie darauf hingearbeitet, Keynotes zu sprechen. Was ich seit vielen Jahren mache: Ich bin auf Konferenzen präsent. Das habe ich schon vor der Selbstständigkeit gemacht und danach fortgeführt.

Meine Motivation ist, dass ich als junger Entwickler selbst stark von Konferenzen profitiert habe. Das Wissen, das mir dort vermittelt wurde, hat mich geprägt. Ich möchte etwas davon zurückgeben. Weil ich das seit vielen Jahren mache, kamen die Gelegenheiten irgendwann.

Bei der RabbitMQ Summit habe ich eine Keynote gegeben. Die Organisatoren kamen auf mich zu. Sie hatten die Summit zum ersten Mal in Deutschland veranstaltet; vorher war sie in London. Hier hatten sie noch kein Netzwerk und suchten einen deutschsprachigen Speaker für die Keynote. Sie fanden mich über LinkedIn und sahen, dass ich routiniert bin. So kam das zustande.

Thomas: Wenn jemand Keynote-Speaker werden möchte: Welchen Rat würdest du geben?

Marcus: Das Offensichtliche zuerst: Man muss Routine bekommen. Bevor man versucht, eine Keynote zu halten oder sich darauf zu bewerben, sollte man generell Vortragserfahrung sammeln. Also Vorträge auf mehreren Konferenzen einreichen und in die Routine kommen.

Zweitens: Keynotes brauchen andere Präsentationen als klassische Fachvorträge. Keynotes sollen inspirieren und einen Vibe für die Konferenz setzen. Sie sind nicht primär Wissensvermittlung. Es geht nicht darum, sich technisch darzustellen oder eine technische Lösung zu zeigen. Es geht darum, eine Geschichte zu erzählen, Lehren daraus zu ziehen und Gedanken anzustoßen.

Bei meiner Keynote auf der RabbitMQ Summit habe ich über Performance gesprochen. Der Talk war an die Geschichte von Quizduell angelehnt.

Quizduell ist eine App, bei der man gegen Freunde quizzen kann. Später gab es eine ARD-Sendung mit demselben Konzept: Zuschauer konnten über die App live mitspielen. Ich habe zufällig in der Firma gearbeitet, die diese App entwickelt hatte — nicht zu dem Zeitpunkt der Sendung, aber im Umfeld.

Technisch war das ein Worst-Case-Szenario: Eine App, die sonst kaum genutzt wird, bekommt plötzlich hunderttausende User gleichzeitig. Diese User interagieren alle in einem sehr kurzen Zeitfenster, weil man nur wenige Sekunden hat, um eine Antwort abzugeben.

Bei der ersten Live-Sendung versagte die Technik vollständig. Im Studio gab es keinen guten Backup-Plan. Jörg Pilawa musste eine Stunde lang überspielen, dass das Sendungskonzept technisch nicht funktionierte.

Für die Keynote habe ich alte Aufzeichnungen gefunden, zusammengeschnitten und dieses Desaster in mehreren Akten entfalten lassen. Das war ein guter Aufhänger: Es macht Spaß, die Story zu erleben, und gleichzeitig kann man viele Lehren daraus ziehen — vor allem, welche Verantwortung wir als Entwickler haben und welche Auswirkungen unsere Software auf Menschen haben kann.

Thomas: Also: Für Keynotes bewerben, einen anderen Vibe setzen, gute Story haben. Marcus, du bist mein persönlicher Held. Schön, dass du da warst. Bis zur nächsten Episode.

Begrüßung und Vorstellung

Tomas: Willkommen bei einer neuen Folge des airdys-Podcasts. Mein Name ist Tom, und wir geben euch nicht nur Orientierung im KI-Dschungel, sondern bauen auch ein tiefes Verständnis rund um KI auf. Wenn euch das Format gefällt, abonniert gerne den Kanal oder lasst uns einen Kommentar da. Auf unseren heutigen Gast freue ich mich besonders: Marcus Held ist Softwarearchitekt, Gründer und Geschäftsführer der Backendhance und freier Autor.

Marcus, hi! Erzähl uns doch kurz für alle, die dich noch nicht kennen, wer du bist und was du machst. Und als kleine Warm-Up-Frage dazu: Über welche Aufgabe freust du dich am meisten, dass du sie heute dank KI nicht mehr tun musst – oder worauf fieberst du hin, dass sie dir endlich abgenommen wird?

Marcus: Hi, freut mich auch sehr, dass ich dabei sein darf, und ich freue mich auf das Gespräch. Vielen Dank für die kurze Intro – ich erzähle gerne etwas über mich.

Wie du schon korrekt gesagt hast, bin ich freiberuflicher Softwarearchitekt. Ich habe mich darauf spezialisiert, mit dem deutschen Mittelstand zusammenzuarbeiten und dessen technische Anstrengungen in echten Wert zu verwandeln. Das mache ich durch das Alignment von Technologie, Prozess und Menschen. Ich fokussiere mich also nicht ausschließlich auf die Technik, sondern betrachte das Softwareprodukt als Ganzes und arbeite mit den Teams daran, dass sie die Werte schaffen, die das Unternehmen schaffen möchte – und entwickle dabei auch die Teams dort weiter, wo sie im Moment stehen.

Mein ganzheitlicher Ansatz richtet sich vor allem an Unternehmen, die im Mittelstand eine Nische besetzt haben und dort groß geworden sind, aber nicht in großen Strukturen arbeiten. Die typischen Kunden, mit denen ich zusammenarbeite, haben Entwicklungsteams von 20 bis maximal 50 Entwicklern. Dort werden besondere Anforderungen an die Strukturen und an die Technik gestellt, wie eine Software aufgestellt wird. Und in den letzten Jahren ist vermehrt das Thema KI und agentic Coding in den Fokus gerückt, wo ich Unternehmen jetzt auch dabei unterstütze, eine Strategie aufzubauen und sie umzusetzen.

Zu mir als Person noch ein bisschen Background: Ich entwickle Software seit ungefähr 15 Jahren. Ich habe eine relativ klassische Entwicklerlaufbahn hinter mir, habe als Backend-Entwickler gestartet und war viele Jahre in der Spielebranche in Hamburg unterwegs. Das größte Projekt hatte damals 220 Millionen registrierte User. Später bin ich wieder ins Rheinland gezogen, hatte ein paar Jahre die Abteilungsleitung bei einem Subunternehmen von Vodafone inne und habe ein Entwicklungsteam mit zu Höchstzeiten 30 Entwicklern geleitet. Vor etwas mehr als drei Jahren habe ich mich entschieden, mich selbstständig zu machen. Seitdem bin ich unter dem Markennamen Backendhance unterwegs.

KI-Automatisierung im Arbeitsalltag

Tomas: Und welche Aufgabe konntest du dank KI schon automatisieren – oder wünschst du dir?

Marcus: Ich habe über das letzte Jahr sehr viel umgesetzt. Was ich heute viel automatisiere, sind vor allem lästige Aufgaben für meine Selbstständigkeit. Beispielsweise das Produzieren von Content war immer schon zeitaufwendig. Da habe ich mir verschiedene Automatisierungen gebaut. Ein Beispiel: Für LinkedIn tippe ich die Beiträge nicht komplett selbst, sondern dafür habe ich KI-Agenten, die ich mit meinem Content befülle. Denen habe ich beigebracht, wie meine Markensprache ist und wie sie das Drumherum mitklären. Auch Angebotserstellungen, Arbeiten an meiner Webseite – das ist ein Riesenhelfer geworden. Wenn ich heute arbeite, habe ich eigentlich hauptsächlich OpenCode als Terminal auf meinem Hauptbildschirm, und darin mache ich alles.

Datenschutz, Vertrauen und das 8-Level-Modell

Tomas: Wenn du beim Kunden bist – was ich oft höre, sind Widerstände gegen KI bezüglich Datenschutz oder manchmal auch bezüglich des Vertrauens. Hast du da auch oft Widerstände bei deinen Kunden?

Marcus: Du sprichst zwei wichtige Punkte an. In meinem Alltag erlebe ich, dass viele Kunden offen sind zu lernen und auszuprobieren, was mit KI-Agenten heute möglich ist. Datenschutzbedenken waren bei den Kunden, die ich in letzter Zeit betreut habe, glücklicherweise weniger ein Thema. In den meisten Modellen, die ich benutze, ist es möglich, das Training auf den Daten auszuschließen. Das ist eine Grundvoraussetzung und auch eine Garantie, die ich meinen Kunden gebe.

Den zweiten Punkt – dass KI-Agenten wenig Vertrauen genießen – das beobachte ich tatsächlich. Aber weniger bei meinen Auftraggebern direkt, sondern mehr in den Entwicklungsteams selbst. Ich habe im März einen Vortrag auf der JavaLand in Brühl gehalten – „Kontext ist alles". In diesem Vortrag hatte ich ungefähr 50 Leute im Raum. Am Anfang habe ich die Frage gestellt, auf welchem Level sich die Zuschauer in der KI-Adoption befinden. Es gibt da ein Modell, das Steve Yegge in seinem Blogpost „Welcome to Gravetown" beschrieben hat. Er beschreibt acht Adoptionslevel von Softwareentwicklern im Umgang mit AI.

Das Erstaunliche war: Als ich die Level durchgegangen bin, waren nach Level 2 und 3 schon die Hälfte aller Hände unten, und ab Level 6 – also mehrere KI-Agenten parallel händisch – war gar keine Hand mehr übrig. Das fand ich eine total spannende Erkenntnis. Die KI-Adoption in unserer Branche ist ziemlich niedrig, weil man das selbst noch nicht erlebt hat.

Parallelisierung und der Entwickler-Loop

Tomas: Wie würdest du diese Parallelität beschreiben? Geht es darum, auf mehreren Repos zu arbeiten? Oder geht es darum, dass ein Agent schon QA macht auf dem Stand eines Entwickler-Agents, der bereits an der nächsten Aufgabe ist?

Marcus: Beides ist inkludiert. In meiner Praxis ist es so: Wenn ich an einem Projekt arbeite, habe ich immer mehrere Git Worktrees auf meinem Rechner, wobei jeder dieser Worktrees von genau einem Agenten bearbeitet wird. Es ist wie in einem Team: Da würde man auch schauen, dass die einzelnen Teammitglieder unabhängige Aufgaben bekommen und sich nicht gegenseitig blockieren. Man muss schauen, dass man den kompletten Entwickler-Loop hinbekommt – über die eigentliche Implementierung, das lokale Testen bis hin zum Deployment. Wenn das soweit möglich ist, kann man den KI-Agenten vollständige Aufgaben geben, und sie können selbstständig validieren, dass ihre Arbeitsergebnisse korrekt sind.

Junior- und Senior-Entwickler im Wandel

Tomas: Seniors werden mit agentic Coding stärker parallelisieren können. Dadurch werden Juniors aber nicht mehr so herangezüchtet. Wie siehst du die Entwicklung der Rollen Junior und Senior?

Marcus: Mit dem Hebel, den die KI-Agenten jetzt bieten, haben wir eine fundamentale Veränderung in der Art und Weise, wie wir als Entwickler arbeiten. Wir können aber Parallelen aus der Vergangenheit ziehen. Als Compiler eingeführt wurden, gab es sehr vergleichbare Bedenken wie heute. Später, mit Garbage Collector und Virtual Machines, gab es die Bedenken, dass Entwickler nicht mehr in der Lage sind, Memory Management zu verstehen. Als IDEs eingeführt wurden, gab es Bedenken, dass Entwickler die SDKs nicht mehr verstehen. Es waren immer ähnliche Bedenken.

Junior-Entwickler, die heute anfangen, erleben eine ganz andere Welt, wie man Software entwickelt, und müssen das auch anders lernen. Manche Dinge, die wir Entwicklern erst später beigebracht haben, werden wir früher beibringen müssen. Mit KI-Agenten hat man den größten Hebel, wenn wir in der Lage sind, sie zu parallelisieren. Dafür müssen wir aber ein paar Dinge gelernt haben: wie man gute Anforderungen erhebt, wie man Edge Cases betrachtet, wie man das in den größeren Kontext des Gesamtunternehmens setzt. Das haben wir Junior-Entwicklern üblicherweise noch nicht beigebracht.

Context Engineering: Warum Kontext alles ist

Tomas: Es geht um den Kontext. Kannst du da ein bisschen in die Tiefe gehen?

Marcus: Der Hintergrund ist, dass Code-Autovervollständigung sich den Kontext nur in einem sehr beschränkten Rahmen zusammensucht. Wir bekommen nur das Ergebnis von KI-Agenten oder LLMs, das in den Trainingsdaten und im Kontext des LLMs vorhanden ist. Das einzige, womit wir dagegenwirken können, ist, dem KI-Agenten beizubringen, was eigentlich gute Praxis ist und was umzusetzen ist. Wenn ich KI-Agenten nutze, um Code zu schreiben, der Hibernate als Framework nutzt, sollte ich dem Agenten vorher sagen: Folgende Praktiken sollst du nutzen, folgende sollst du nicht nutzen. Dafür gibt es in sämtlichen KI-Agenten ein Konzept, das nennt sich Skills.

Für einzelne Projekte geht das natürlich noch weiter. Wir haben ja nicht nur das allgemeine Wissen über Best Practices zu den Technologien, die wir nutzen, sondern auch sehr großes Domänenwissen, das für die Anwendung und ihre Entwicklung wichtig ist. Dieses Wissen müssen wir dem KI-Agenten bereitstellen, damit er die richtigen Entscheidungen treffen kann. Es gab eine Studie im Januar 2026 zu AGENTS.md. Dort wurde über 124 Pull Requests hinweg analysiert, welcher Impact entsteht, wenn man eine gute AGENTS.md mit sauberem Kontext für die Anwendung bereitstellt. Das Ergebnis: bis zu 30 Prozent Laufzeit gespart und entsprechend bis zu 16 Prozent weniger Output-Tokens.

Die vier Kontext-Ebenen: AGENTS.md, Skills, Agents, MCPs

Marcus: Es gibt ein paar Stichwörter, mit denen man sich auseinandersetzen sollte. Eins der großen Stichwörter ist Context Engineering. Dafür gibt es verschiedene Layer für verschiedene Anwendungsfälle.

Wir haben eben schon über die AGENTS.md gesprochen. Das ist eine Art Systemprompt, der in jedem Chat automatisch mit eingelesen wird. Dort will ich allgemeine Informationen haben: wie das Repository aufgebaut ist, was der Use Case der Applikation ist, wie ich die Anwendung teste und starte.

Als zweites Werkzeug die genannten Skills. Das ist Spezialwissen, das man im Repository hinterlegen kann. Technisch sind das einfach Markdown-Files mit dem Wissen, plus zusätzlich eine Meta-Information mit einer Beschreibung, wann dieses Wissen hinzuzuziehen ist.

Es gibt eine dritte Ebene, die sogenannten Agents. Ich habe mir ein komplettes Entwicklungsteam als Agenten abgebildet. Ich habe beispielsweise einen Product-Owner-Agenten, einen Backend-Entwickler als Agenten, einen Legal Advisor, einen UX-Experten, einen QA-Experten.

Die letzte Ebene, wie man Kontext bereitstellen kann, sind die MCPs – das Model Context Protocol. Das ist eine Möglichkeit, die Funktionalität zu erweitern, die ein LLM ausführen kann. Ich habe in den meisten Projekten irgendwann einen Debug-MCP-Server geschrieben, der sich im Projekt registriert und tatsächliche Funktionalität bereitstellt.

Selbst bauen statt SaaS abonnieren

Tomas: Software-as-a-Service ist ein bisschen auf dem absteigenden Ast. Zumindest prognostiziert man SaaS-Firmen nicht die beste Zukunft, weil sehr viel Software einfach on demand von den Firmen geschrieben werden kann.

Marcus: Ich sehe das ein bisschen differenzierter. Zum einen kann ich deine Beobachtung bestätigen. Gerade für kleine Use Cases gehe ich immer häufiger hin und baue mir schnell etwas selbst, das für mich funktioniert. Nichtsdestotrotz glaube ich, dass damit nicht das Ende der SaaS-Unternehmen eingeläutet wird. Die große Herausforderung ist nicht das Bauen von Software, und war es auch vorher nie. Die große Herausforderung ist immer der Product Market Fit und das langfristige Betreiben der Software. Wo ich Schwierigkeiten sehe, ist bei diesen Micro-SaaS-Unternehmen. Aber die großen SaaS-Unternehmen werden deswegen nicht unter Druck geraten, weil das Betreiben von Software immer noch das ist, was am teuersten ist.

Code-Reviews mit KI: Vom Detail zum High-Level

Tomas: Guckst du noch jeden Code an?

Marcus: In der Praxis ist es so: Ich tue das nicht mehr. Es hat sich verändert. Wenn ich heute auf Code schaue, den ich mit KI produziere, dann schaue ich ihn mir immer noch an. Es ist nicht so, dass ich blind in Main merge, das mache ich nicht. Aber ich schaue mir nicht mehr Zeile für Zeile alle Details an, sondern es ist eher ein grobes Rüberscannen. Ich kontrolliere, ob die grundlegende Architektur zu dem passt, wie ich mir das vorstelle. Ähnlich arbeite ich auch mit Entwicklern zusammen. Wenn ich ein Team leite oder geleitet habe, bin ich auch nicht hingegangen und habe Zeile für Zeile jede Contribution angeschaut. Aber ich habe mir trotzdem angeschaut: Passt das strategisch, was da umgesetzt wurde?

Üblicherweise entwickle ich mehrstufig ein Feature oder eine Änderung in der Anwendung. Ich gehe erst hin, mache die Planung. Dann lasse ich das natürlich von KI-Agenten umsetzen. Aber als Nächstes lasse ich immer noch einen Refactoring-Agenten drüber laufen, der Kenntnis darüber hat, wie sauberer Code geschrieben werden soll. Als letzten Schritt habe ich noch einen Review-Agenten, der sich anschaut: Gibt es offensichtliche Bugs in dem Code, gibt es Seiteneffekte, die erzeugt werden könnten, und gibt es Security-Lücken, die hier aufgemacht werden?

Abschluss und Kontaktmöglichkeiten

Tomas: Sehr spannend. Das war ein sehr umfassender Blick, wie agentic Coding und KI dein Arbeiten verändert haben. Wenn man von dir mehr hören und lesen möchte, wo connectet man sich am besten?

Marcus: LinkedIn ist ein super Kanal. Dort einfach nach Marcus Held mit C suchen. Alternativ gerne Kontakt über meine Webseite aufnehmen, unter www.backendhance.com. Das ist übrigens ein Wortspiel aus Backend und Enhance. Dort findet man auch Artikel von mir aus den letzten Jahren. Ich freue mich immer über eine Kontaktaufnahme und einen Austausch in der Praxis.

Tomas: Super Schlusswort. Vielen Dank, Marcus. Wir sehen uns dann hoffentlich beim nächsten Mal.

Marcus: Ich freue mich. Vielen Dank, Tomas.