Problem zuerst verstehen: Warum ich mit KI bessere fragen stelle, bevor ich code

In meinem letzten Beitrag habe ich beschrieben, warum Software-Entwicklung mehr ist als Code zu produzieren. Das Feedback war positiv, aber ich habe es aus Sicht eines Entwicklers beleuchtet und es kam die Frage auf, es auch aus Sicht der Manager zu beleuchten.

Software-Entwicklung vs. Programmieren

Kurz noch einmal erwähnt, für mich beschreibt Software-Entwicklung den ganzen Prozess, der zu einem fertigen Produkt führt und die Programmierung ist ein Teil dieser Arbeit und dabei wird "nur" Code produziert. Ich will diesen Teil nicht abwerten, sondern aufzeigen, dass er ein Teil etwas Größerem ist.

Okay, warum schreibe ich Software

Es ist so offensichtlich und trotzdem wird es oft im Alltag vergessen und andere Prioritäten nehmen den Platz ein.

Software entsteht nicht, weil eine Technologie spannend ist, sondern weil ein reales Problem existiert und ich es mit Software lösen kann. Dabei ist meistens Kostenreduktion der Hauptantrieb.

Wenn ich es schaffe, Arbeit einzusparen, welche von einer Person 8 Stunden am Tag händisch gemacht werden muss, dann rede ich schnell über große Beträge.

Wenn ich es schaffe, diese Person "frei" für wichtige Arbeiten zu bekommen, dann habe ich als Unternehmer doppelt gewonnen. Ich muss nicht eine zweite Person einstellen UND ich kann einen Facharbeiter besser einsetzen.

Warum sollte ich jemanden gut Ausgebildeten hinsetzen und eine Excel-Liste ausfüllen lassen, wenn die gleiche Person einen Mehrwert für meine Kunden generieren könnte.

Ich denke da an Steuerfachangestellte, die sich ihre Mandanten anschauen können und Vorschläge erarbeiten, wie Prozesse optimiert werden könnten, anstatt einfach stumpf Rechnungen abzutippen.

Was bedeutet das

Ich brauche Klarheit, welches Problem gelöst werden soll, welche Grenzen gelten und woran Erfolg gemessen wird. Wenn diese Klarheit fehlt, helfen selbst die besten Entwickler nicht, weil sie dann nur Annahmen umsetzen.

Hier beginnt bereits der erste Schritt, denn oft haben Entwickler nicht so tiefen Einblick in Unternehmensprozesse und im Management ist die Erfahrung, was alles mit Software machbar ist, auch begrenzt (das schreibe ich aus Sicht eines Entwicklers).

Hier entsteht der erste Mehrwert, den dir Software-Entwicklung bringen kann.

Sparringspartner und Brainstorming

Mit KI ist es möglich, bereits vorab grundlegende Fragen zu klären oder Gedankenspiele zu machen, aber die KI sagt immer Ja. Sie ist der Mitarbeiter, der zu allem Ja und Amen sagt und alles toll findet.

Ein guter Softwareentwickler ist in der Lage, Ideen und Tipps zu geben. Am wichtigsten ist es aber auch, dass jede Entscheidung Vor- UND Nachteile hat. Auch wenn ich mich selbst immer wieder dabei erwische, wie ich überall "Probleme" und "Lösungen" sehe. Das wirkt oft in Gesprächen eher negativ und reserviert, aber ich sehe das eher wie ein Tanz.

Während ich bremsend wirke, habe ich oft den Eindruck, dass Entscheider euphorisch zu Entscheidungen neigen, ohne die langfristigen Implikationen dieser Entscheidungen zu verstehen.

Das soll keine Rechtfertigung für mein Verhalten sein (das ist ausbaufähig) oder ein Vorwurf an Entscheider, sondern ich sehe da eine Dynamik, die richtig genutzt Kräfte freisetzen kann auf beiden Seiten.

Technische Schulden

Ich denke, jeder Entscheider wurde bereits mehrfach von einem Entwickler damit genervt und kann es nicht mehr hören, aber was steckt genau dahinter.

Mein Beispiel ist, dass Quelltext "lesbar wie eine Geschichte" sein sollte.

Dasselbe kann ich auch bei verschachtelten Bedingungen erreichen.

Hier ein schwerer zu lesendes Beispiel Logik:

$order = [
    'paid' => true,
    'shipped' => false,
    'cancelled' => false
];
 
$processable = false;
 
if (!$order['cancelled']) {
    if ($order['paid']) {
        if (!$order['shipped']) {
            $processable = true;
        }
    }
}
 
if ($processable) {
    ...
}

Die ordentliche Version mit der gleichen Logik:

class OrderStatusDecider
{
    public function canBeProcessed(Order $order): bool
    {
        if (true === $order->cancelled) {
            return false;
        }
 
        if (false === $order->paid) {
            return false;
        }
 
        if (true === $order->shipped) {
            return false;
        }
 
        return true;
    }
}
 
...
 
    if ($decider->canBeProcessed($order)) {
        ...
    }
...
 

Um die Beispiele zu verstehen, ist es nicht so wichtig, ob jemand programmieren kann oder nicht. Es reicht, beide Lösungen zu verstehen, denn diese beinhalten die gleiche Logik und der Entwickler muss beim "schlechteren" Beispiel einfach mehr geistige Leistung aufbringen als bei einem leichter lesbaren Beispiel.

Anderes Beispiel: Ich verstehe Deutsch, aber bin nicht in Bayern aufgewachsen, sondern in NRW. Wenn ich also einen Text im bayerischen Dialekt lesen würde, dann vermute ich, dass ich sehr viel davon verstehen würde, aber es ist bestimmt anstregender und nach mehreren Seiten bin ich erschöpfter, als wenn ich ein "Kinderbuch" mit einfacher Sprache lesen müsste.

Dasselbe gilt für Quelltext, denn ich habe nur begrenzte geistige Kapazitäten und je mehr davon "frei" bleibt, umso besser kann ich mich um das Problem selbst kümmern.

Lesbarkeit macht den Unterschied

Die Lesbarkeit von Quelltext hat direkten Einfluss auf das Projekt, denn nur wenn der Entwickler den Quelltext kennt, kann er verlässliche Aussagen zur Machbarkeit und Komplexität eines Features treffen.

Auch wenn Schätzungen nie genau sind, egal unter welchen Umständen, so kann man die Genauigkeit doch stark beeinflussen. In welchem Projekt ist die Schätzung vermutlich genauer, in dem gut lesbaren mit vernünftiger Dokumentation, wiederkehrenden Mustern, die einheitlich im Projekt genutzt wurden oder im Projekt, wo ich selbst noch einmal nachschauen müsste, was alles eintreffen muss, damit eine Bestellung verarbeitet werden kann.

Das war bis hier nur das Vorspiel zu dem eigentlichen Thema. Für mich als Entwickler habe ich eigentlich schon den Hauptpunkt aufgezeigt, ich muss den Quelltext lesen und verstehen können. Denn in Meetings werde ich gefragt, wie ich das neue CRM/ERP-System anbinden kann, ob ich zu dem Datensatz des Kunden noch weitere Felder hinzufügen kann.

Was hat das mit KI zu tun?

KI macht mich nicht automatisch schneller. Sie hilft mir aber, mehr Fragen zu stellen und schneller Antworten zu sammeln. Wenn Expertise da ist, kann ich mit KI viel mehr Aspekte beleuchten, Abhängigkeiten sichtbar machen und Informationen zusammentragen, die sonst im Alltag untergehen würden.

Besonders hilfreich ist KI, wenn ich Konzepte erklären muss, die im Management weniger bekannt sind. Sie bereitet Beispiele, Vergleiche oder Kürzungen auf, die ich dann auf meinen Kontext zuschneide. Mir passiert es immer wieder, dass ich vergesse, wer der Adressat einer E-Mail ist und werde dann zu technisch. KI erinnert mich daran, die Sprache anzupassen, damit alle Beteiligten verstehen, worum es geht und welche Entscheidungen anstehen.

Wer ist verantwortlich?

Wenn meine Applikation komplett mit KI generiert wurde, was ja nicht unmöglich ist, wer soll dann beurteilen, wie einfach ein neues System angebunden werden kann? Wer behält den Überblick über das Projekt und entscheidet, welche Komplexität akzeptabel ist?

Niemand wird auf die Idee kommen, einen externen Entwickler anzurufen und zu fragen, warum der eigene Shop offline ist, weil es offensichtlich ist, dass dieser keine Ahnung vom Setup oder vom Quelltext hat. Bei einem internen Entwickler würde man erwarten, dass dieser genug Überblick hat.

Fazit

Ich werde nicht schneller durch KI, aber ich werde besser. Klarheit über Problem, Zielbild und Verantwortung schlägt Tooling.

KI hilft mir, mehr Fragen zu stellen und Antworten aufzubereiten, ersetzt aber nicht den Überblick und die Entscheidung, welche Komplexität vertretbar ist.

Lesbarer Code, nachvollziehbare Entscheidungen und ein klarer Ansprechpartner bleiben die Basis, erst dann kann KI wirklichen Mehrwert liefern.