Ich bin kein Softwareingenieur

• Die Ablehnung der Identität als Softwareingenieur begann vor 23 Jahren mit der Einschätzung: „ein guter Hacker, aber kein Ingenieur“
• Das Agenten-Paradigma fühlt sich an wie ein Ansatz, mit nichtdeterministischen Programmen Programme zu erstellen, die deterministisch sein sollten
• Das Vertrauen in Code beruht auf Lesbarkeit, Verständlichkeit, Effizienz, Nachvollziehbarkeit und der Reproduzierbarkeit, bei gleichen Eingaben gleiche Ausgaben zu liefern
• Agentic User Flows am Arbeitsplatz und KI-Nutzungs-KPIs werden als Ansatz wahrgenommen, der Metriken und natürlichsprachliche Eingaben über guten Code stellt
• Das Zukunftsbild der KI-Branche wirkt wie eine Vorstellung, die nicht nur die Softwareentwicklung ersetzen, sondern das Denken selbst mit einem Burggraben umgeben will

---

Software Engineering und das Agenten-Paradigma

• Die Haltung, sich selbst von der Identität als Softwareingenieur auszuschließen, geht auf die Erfahrung zurück, vor 23 Jahren von einem Kollegen als „guter Hacker“, aber nicht als Ingenieur bezeichnet worden zu sein
• Das jüngste „neue Agenten-Paradigma“ wirkt, als würde man Maschinen wie Waylon Smithers bitten, keine Fehler zu machen, und das Ergebnis anschließend als professionelles Software Engineering verkaufen
• Ein Ansatz, bei dem Programme mit nichtdeterministischen Ausgaben verwendet werden, um Programme zu schreiben, die deterministisch sein sollten, wird als Zukunft des Software Engineering präsentiert
• Das grundlegende Vertrauen in Code liegt weiterhin in Lesbarkeit, Verständlichkeit, Effizienz, ausreichender Nachvollziehbarkeit und der Reproduzierbarkeit, bei gleichen Eingaben gleiche Ausgaben zu erzeugen
• Da Reproduzierbarkeit in realen Systemen bereits schwierig ist, darf das Schreiben von Code selbst nicht auf „beweglichem Sand“ errichtet werden
• Details wie die Auswirkungen einer aus verketteten Unterabfragen und Aggregatausdrücken aufgebauten View auf die Query-Performance, Inversion of Control und ein Design, bei dem Funktionalität von Methoden getrennt wird, damit sie unabhängig testbar ist, bleiben weiterhin wichtig

Misstrauen gegenüber KI-zentrierten Entwicklungsabläufen

• Die am Arbeitsplatz geforderten Agentic User Flows haben keine klare Bedeutung, und es ist schwer nachzuvollziehen, warum ein Texteingabefeld für natürliche Sprache besser sein soll als die Auswahl aus einer kleinen Menge von Optionen
• Es gibt Bestrebungen, Agenten in jeder Phase des Softwareentwicklungslebenszyklus einzusetzen, und es wird sogar behauptet, handgeschriebener Code werde behandelt werden wie COBOL
• Agenten wirken wie LLM-Prompt-Wrapper, die Ausgaben je nach Kontext bewerten, und die tatsächlichen Ergebnisse erscheinen oft unzureichend
• Der Einsatz von KI wird über KPIs verfolgt, doch in den vergangenen 23 Jahren war es wichtiger, guten Code zu schreiben als KPIs zu erfüllen
• Früher geschriebener Code wurde einmal mit dem Urteil bedacht, er sehe „so aus, als hätte ihn ein Mathematikstudent geschrieben“, und das wurde als großes Lob aufgefasst
• Eine Implementierung eines Staff Software Engineers im selben Unternehmen hatte keine expliziten Interfaces, legte den DI-Container als public static-Member offen und verwendete CSV-Konfiguration nicht, weil sie für tabellarische Daten geeignet gewesen wäre, sondern weil „Business-Anwender sie leichter nutzen können“
• Die Aussage, diese Implementierung sei sehr schlecht, führte zu Problemen und mündete ironisch in die Schlussfolgerung, man selbst sei wohl kein Softwareingenieur
• Zweimal kam von Personen, die als klug gelten, der Rat, KI akzeptieren zu müssen, weil sie die Zukunft des Software-Schreibens und der Branche sei; diese Haltung wirkt jedoch nachlässig
• Die KI-Software, die ausprobiert wurde, fühlte sich nicht so an, als würde sie beim Denken helfen, sondern eher so, als würde sie den Denkprozess stören oder aktiv an sich ziehen, und genau diese Vereinnahmung ist beunruhigend
• Führungskräfte großer KI-Unternehmen sprechen fröhlich über die Zukunft der Softwarebranche, kündigen an, ihre Produkte würden devastating effects auf Beschäftigung haben, und verwenden Formulierungen wie „intelligence too cheap to meter“
• Dass diese Zukunft so erschreckend wirkt, liegt nicht daran, dass Maschinen alle in Büroklammern verwandeln würden, sondern daran, dass sie sich vorstellen, das Denken selbst mit einem Burggraben zu umgeben

[GN⁺]

Lobste.rs-Kommentare

• In Mary Waltons Buch über W. Edwards Deming gibt es diese Anekdote. Ein Fabrikarbeiter produzierte wegen einer Maschinenstörung nur noch Ausschuss, meldete das zwar, aber da die Wartung sich verspätete, wollte er die Maschine selbst reparieren, als der Aufseher kam und ihm sagte, er solle sie einfach weiterlaufen lassen.
  Letztlich war das also die Anweisung, „Ausschuss zu produzieren“, und er sagte: „Wo bleibt da mein Stolz als Arbeiter? Es wäre besser, wenn der Aufseher mich wenigstens so sehr respektieren würde wie die Maschine.“ Er wollte keinen Ausschuss produzieren und dafür auch noch bezahlt werden.

  • Ist das dieses Buch? https://deming.org/the-deming-management-method-by-mary-walton/
    Lohnt es sich zu lesen?

• Ich habe viel weniger Berufserfahrung als der Autor, aber zu Beginn meiner Karriere habe ich wegen der vielen Probleme mit CSV versucht, einige Arbeitsabläufe von CSV wegzubekommen, und damals bekam ich als Antwort: „Für geschäftliche Workflows ist CSV einfacher.“
  Damals fand ich diese Antwort wie der Autor ziemlich mies, aber mit der Zeit bin ich zu der Ansicht gekommen, dass dieses Urteil wohl näher an der Wahrheit lag.

• Wenn dich so eine dumme Meinung nach dem Muster „Vor 23 Jahren hat jemand gesagt, du seist kein Software Engineer“ immer noch quält, dann besteht die Lösung meiner Meinung nach darin, sich nicht so sehr um die Meinung anderer zu scheren.
  Wenn dich die törichte Politik deines Arbeitgebers oder die mangelnde Gewissenhaftigkeit deiner Kollegen frustriert, such dir eben ein anderes Unternehmen. Es gibt 8 Milliarden Menschen auf der Welt, viele davon wollen, dass Computer irgendetwas für sie tun, und viele davon bezahlen für Programmierung.
  Das klingt wie: „Als ich das erste Mal in einer Bäckerei gearbeitet habe, sagte ein Kollege, Croissants seien eine Verschwörung von Big Dairy, um mehr Butter zu verkaufen, und ich habe das zur Grundlage meines Weltbilds gemacht und beschlossen, nie wieder in einer Bäckerei arbeiten zu können.“ Wenn das Alter des Autors nicht dabeistünde, hätte ich ihn für einen Oberstufenschüler gehalten, aber wer von etwas vor 23 Jahren spricht, ist für so etwas wohl längst deutlich zu alt.

  • Ich kann nur mutmaßen, warum dieser Beitrag geflaggt wird, aber bei dieser Vermutung bin ich ziemlich sicher. Das Kernproblem ist jedoch nicht so sehr der unfreundliche Ton, sondern dass er an der zentralen These des Textes vorbeigeht.
    Der Punkt des Textes ist nicht, dass der Autor tatsächlich kein Software Engineer sei; vermutlich hat er lange genug unter genau diesem Titel gearbeitet. Der Punkt ist eher, dass diese Selbstabgrenzung von der Berufsbezeichnung eine Reaktion auf die Art ist, wie sich diese Branche verändert hat.
    Es ist im Grunde ein „Das ist keine Ingenieursarbeit, das ist Bullshit. Wenn das gemeint ist, wenn man von Software Engineering spricht, dann bin ich das nicht.“
    Ich persönlich kann dieses Gefühl nachvollziehen. Oft hatte ich den Eindruck, dass es eine Beleidigung anderer Ingenieurdisziplinen ist, das, was wir als Softwareentwickler tun, „Engineering“ zu nennen. Vor allem deshalb, weil wir es so nennen und uns dann doch kaum darum kümmern, was wir eigentlich bauen.
    Bauingenieure nehmen es sehr ernst, wenn eine Brücke einstürzt, und wenn es zu einem großen Kollaps kommt, reagiert die gesamte Branche, lernt daraus und versucht sicherzustellen, dass so etwas nie wieder passiert. Dagegen können sogenannte Software-„Engineers“ Produktionsumgebungen aus völlig vermeidbaren Gründen immer wieder lahmlegen und das anschließend noch als Erfolgsgeschichte in den Lebenslauf schreiben.
    Was ich über die heutige Richtung des Software Engineering denke – nämlich die Tendenz, sich nicht um den tatsächlich ausgelieferten Code zu kümmern und dessen Erstellung an andere „Intelligenzen“ zu delegieren –, kannst du dir vermutlich denken.
    Ich will nicht behaupten, ich würde vollständig verstehen, warum das passiert, oder hätte alle Antworten darauf, was man dagegen tun sollte. Aber wir sollten wenigstens nicht so tun, als wäre das eine ernsthafte Tätigkeit – also „Engineering“.