Wenn jeder Software bauen kann, wer entscheidet dann, was nicht gebaut wird?
When Anyone Can Build Software, Who Decides What Not to Build?
Generative KI macht das Erstellen von Code billig, doch was sich anhäuft, ist nicht der Code, sondern der Zustand: Daten, Integrationen, regulatorische Pflichten und Betriebsprozesse. Der Autor argumentiert, dass Architektur nicht verschwindet, sondern sich auf „Urteilsvermögen vor Festlegung“ verlagert – die Fähigkeit, lokal rationale Entscheidungen zu erkennen, bevor sie Unternehmensfolgen haben. Ein Beispiel aus seiner Laufbahn zeigt, wie ein schnell gebautes Tool jahrelang als Silo nachwirkte.
Je billiger Software zu erstellen wird, desto teurer wird Inkohärenz.
- deminature
Hochwertige Software mit LLMs zu bauen, ist immer noch sehr zeitaufwändig. Die überwiegende Mehrheit der Leute wird sich die Mühe nicht machen, egal wie niedrig die Einstiegshürde ist, denn Zeit ist nicht gratis. Dazu kommt, dass Softwareentwicklung die meisten Menschen nicht interessiert, aus demselben Grund, aus dem Elektronikbasteln die meisten Menschen nicht interessiert. Es ist ein Nischeninteresse mit begrenzter Massenattraktivität. Aus diesen beiden Gründen wird der Beruf des Softwareentwicklers die KI überleben.
- OakNinja
Dieses Problem ist nicht neu. Das Neue ist, dass jeder das Kernproblem, das er lösen will, verstehen kann, ohne ein Entwicklerteam einzubeziehen, indem er schnell Ideen entwickelt und Prototypen baut.
Wie immer ist es dann Sache des Unternehmens, Prioritäten zu setzen – genau wie es schon immer war.
* Halte nicht an einer Idee oder einer Prompt-Ausgabe fest, nur weil du Zeit damit verbracht hast.
* Code schreiben ist einfach. Ihn warten ist schwer.
* Wenn es keine Zeit spart oder Umsatz generiert, ist es nur eine Ausgabe.
* Output ist nicht gleich Wert.
- anonzzzies
Wir (meine Firma) haben eine unternehmensweite LoB-„Basis“, in der sich über die ungeraden 40 Jahre hinweg so ziemlich jeder Prozess angesammelt hat, den man sich vorstellen kann, und damit schauen wir uns einfach die Prozesse großer Konzerne an und bieten an, sie zu automatisieren – auf Abteilungsebene, damit sie weder die Zustimmung des Vorstands noch der IT-Abteilung brauchen, um dafür zu bezahlen. SOTA-KI kann das mit unserer Basis in ein oder zwei Tagen erledigen, fast von allein, und wir verlangen dafür knapp unter dem Abteilungsbudget. Wir müssen bissige, sarkastische „Projektmanager/Vertriebler“ zu den vielen Meetings schicken, denn natürlich wollen diese mittleren Manager als nützlich wahrgenommen werden, also sind diese Meetings für uns objektiv nutzlos, aber trotzdem das übliche Elend. Sie (die Fleischraum-Meetings) sind inzwischen natürlich weit teurer als der (nur) technische Teil, selbst wenn man das Framework mit einem gewissen Lizenz- und SLA-Kostenbetrag veranschlagt.
Diese Konzerne, und es sind größtenteils Multinationale, die meist US-, IN- oder CN-Eigentümern gehören, und buchstäblich alle ihre IT-Abteilungen stinken absolut; sie hängen auf Java oder C# von vor 20 Jahren fest, mit null Anreiz, irgendetwas zu verbessern oder zu lernen; sie haben von KI gehört, nutzen sie aber für nichts.
Das ist ein lukrativer Selbstläufer, in welcher Region auch immer Milliarden wert, wenn man es schafft, auf der richtigen Ebene reinzukommen. Ich bin nicht sicher, ob das Bestand haben wird, denn nach meiner Erfahrung können die meisten dieser Leute in diesen Abteilungen heute durch ein LLM auf einem iPhone ersetzt werden, und LoB-Apps sind ziemlich langweilig, wenn man einen soliden Berater hat, der ein paar Jahrzehnte Wissen mitbringt; sie müssen doch LLMs genau dafür trainieren?
- CurleighBraces
Ich finde, es ist differenzierter als das, zumindest im Moment.
Es stimmt, dass jeder Software bauen kann, aber das macht die Software nicht gut, und es stimmt nicht, dass das speziell von Geschmack abhängt.
Als Beispiel: Ich arbeite gerade mit einem Unternehmer, der keine Programmiererfahrung hat, aber erfolgreich ein Produkt gebaut hat, das er auch schon an ein mittelgroßes Unternehmen verkauft hat.
Ohne mein Zutun und ohne zu wissen, an welchen Hebeln man die KI ansetzen muss, performte die Software jedoch nicht so, wie sie es musste, obwohl die neuesten Frontier-Modelle ihr Bestes gaben, um das umzusetzen, was er beschrieb.
Zumindest im Moment braucht es noch erfahrene Entwickler.
- ma2kx
Ich bin etwas verwirrt. Es ist ein interessanter Beitrag, aber ich bin nicht sicher, ob ich genau verstanden habe, worauf er mit seinem „Policy as Code“ hinauswollte. Er schlussfolgert: „Policy-as-Code erzeugt Unternehmenskohärenz ohne zentrale Architekturfunktion“, dem würde ich zustimmen, aber argumentieren, dass er übersieht, dass es heute an Infrastruktur / Unternehmen als Code mangelt. Zumindest, wenn man möchte, dass ein Agent die Probleme, mit denen er begonnen hat, lösen oder sich ihrer zumindest bewusst sein kann. Die Richtlinien definieren sozusagen die Grenzen unseres Arbeitsumfelds, aber nicht die Arbeit selbst. Dieses „Know-how“ ist für Menschen meist implizit, aber für LLMs unsichtbar und begrenzt den Kontextrahmen, in dem der Agent operiert, auf seinen gegebenen Prompt (und vielleicht durch die Richtlinien eingeschränkt, wenn sie im Kontext sind).
Wenn ich zum Beispiel sein Beispiel nehme:
„Mitarbeiter an der Front überspringen möglicherweise Pflichtfelder, weil der Prozess bei jeder Kundeninteraktion fünfzehn Minuten Reibung hinzufügt.“
Erstens ist unklar, was die Richtlinie für diese Felder ist, wenn sie Pflicht sind und trotzdem übersprungen werden können. Und warum sind sie Pflicht, wenn das Überspringen offenbar nur weniger Reibung bedeutet, ohne andere Konsequenzen? Wie soll ein Modell entscheiden, ob es die Richtlinie für diese Felder durchsetzen, eine Automatisierung programmieren oder sie einfach freiwillig machen soll?