Wir driften dann ganz massiv ab vom Thema:
a) Was funktioniert oder eben nicht ist immer Ansichtssache. Das System USA funktioniert aus meiner Sicht eben nicht, es sei denn, ein "Ich arbeite 3 Jobs und habe dennoch Probleme mein Dach über dem Kopf zu bezahlen" ist ein "funktionieren". Und Du hast da Jobs vor Augen, die brauchen: "neben den üblichen anderen Tauglichkeitsmerkmalen (Zuverlässigkeit, Pünktlichkeit, usw)" aber dann ist es ok, wenn da einfach jemand genommen wird "der gerade Geld braucht"? Irgendwie glaube ich, dass hier Dinge durcheinander geschmissen werden ...
b) Komplexität reduzieren
Genau das wird doch ständig gemacht und funktioniert extrem gut. Sei es in der Technik: Was interessieren Dich irgendwelche exakten Details? Du hast nur noch Module und die packst Du zusammen. Da nimmst Du ein Board, da kommt eine CPU drauf (Du achtest noch auf den gleichen Sockel bei beiden), dann steckst Du etwas RAM rein und noch eine Grafikkarte .... Viele Details interessieren nicht mehr.
(Findet sich bei vielen technischen Dingen. Was interessiert denn noch irgend ein Interna?)
Software Entwicklung doch genau das gleiche. Am Anfang hat man die CPU noch selbst bedient. Dann wurde immer mehr abstrahiert. Auf Grund der Abstraktion wurde vieles deutlich einfacher. Es wurden Hochsprachen entwickelt. Dann abhängige Produkte wie z.B. Datenbanken. Durch Abstraktion wurde vieles immer einfacher (Wer interessiert sich noch für die Komplexität von irgend welchen Kontext Switches bei Threadwechseln, Interrupts bei CPUs und all so ein Quatsch?) Und immer mehr wird nicht mehr selbst entwickelt.
Um es mal ganz deutlich zu machen einfach einmal eine Entwicklung, die ich mitgemacht habe:
- Ich habe ursprünglich in C eine eigene "Datenbank" geschrieben. Da wurden Datensätze in einer Datei gespeichert, ich hatte separate Indices und all sowas (Das war so um 1987/88).
- Dann später war das separat: ich habe dann SQL Befehle geschrieben und habe die Verwaltung/Speicherung/Optimierung als Komplexität abgegeben (Das war dann so 1995 und später)
- Jetzt schreibe ich sowas nicht mehr. Jetzt schreibe ich nur noch reine Entity Klassen und überlasse Frameworks den Zugriff. Ich schreibe da kaum noch Code. Je anch verwendetem Framework muss ich nicht einmal das Speichern selbst machen. Ich sage einfach: Gib mir die Entity. Wenn ich dann verlinkte Entitäten aufrufe, dann passiert das Laden der Daten im Hintergrund automatisch. Und wenn ich etwas ändere: Das wird getrackt. Ich speichere nicht mal mehr selbst. Also ganz massive Abgabe an Komplexitäten. Und das gibt es an vielen Bereichen. Ich schreibe doch keinen RestClient selbst. Ich gebe entweder das Interface vor und sage: Da will ich ein RestClient oder ich lasse das von der OpenAPI generieren. (Das ist Stand heute!)
c) Vibe Programming
Hier verstehe ich immer nicht, wieso hier die Welt der Software Entwicklung separat gesehen wird. Clean Code / Agile Vorgehensweise: Das klingt bei vielen als wäre hier das Rad neu erfunden worden oder so. Das sind ganz normale Standard-Vorgehensweisen. Das man in kleinen Teams kleine Dinge macht um damit dann schrittweise ein Problem zu lösen (Das ist so eine Umschreibung von Uncle Bob) ist in anderen Bereichen absolut normal und da würde niemand auf die Idee kommen, das anders machen zu wollen. Und auch das Vibe Programming ist doch keine andere Vorgehensweise als das, was Anfänger schon jetzt machen. Man probiert einfach etwas aus. Und wie man z.B. bei manchen Fragestellungen im Forum manchmal sieht: Da hat man offensichtlich keine Ahnung, was da überhaupt gemacht wird und es wird einfach irgend etwas zusammen gestrickt, was man irgendwo gefunden hat ...
Aber das ist doch normal. Wie baut denn ein Kind mit Bauklötzen? Also ich habe noch nie Kleinkinder gesehen, die Statik und Co berechnet haben um dann Bauklötze stabil und sicher zu stapeln.
Was spricht dagegen, etwas einfach zusammen zu bauen? Und dann schaut man: Funktioniert es? Super. Funktioniert es nicht? Dann probiere ich es einfach noch einmal.
Klar, so baue ich kein Hochhaus und kein Atomkraftwerk. Aber wie viele Leute bauen letzten Endes so etwas?
Wenn ich schaue, was ich in den diversen Konzernen gesehen habe, dann sehe ich eine Masse an Excel Sheets und PDFs und Co. Das einfach mal eben so zu ersetzen ist doch nichts wildes. ==> Hier kommen dann Low Code Ansätze ins Spiel und schon habe ich super Lösungen. Und die gehen mit mehr oder weniger Vibe Programming: Man klickt da mehr oder weniger was zusammen und testet es dann. Wenn es funktioniert: Super! Wenn nicht, dann schaut man noch einmal.
Und klar: Man braucht dann gewisse Sicherheit, aber die wird oft direkt bereitgestellt. Die Low/No Code Anbieter wissen in der Regel, was sie tun.
Oder man hat zur Not ein kleines lokales Programm und ein OneDrive/Sharepoint mit Dateien: Da hat man eine ähnliche Sicherheit wie bei z.B. Excel mit Macros.
Daher ist wirklich die Frage, was man wirklich genau braucht oder will. Viele Anforderungen sind schlicht Niveau: Bauklötze. Wenn es geht ist es gut wenn nicht baue ich es noch einmal. Und in der Zwischenzeit mache ich "EDV zu Fuss" (So nannte es mal ein Mentor damals. Da hatte ich in einem mittelständischen Unternehmen Prozesse optimiert und Tools entwickelt)
Und gerade wenn Du wenig Erfahrung in der Software Entwicklung hast: Ich bezweifle, dass Du bessere Ergebnisse lieferst wie eine KI mit vernünftigen Vorgaben. (Ohne Dir zu nahe treten zu wollen! Das ist keine Wertung Deiner Person! Es ist lediglich eine Erfahrung, die ich in meinem Berufsleben gemacht habe.)
d) Kontrolle von Ergebnissen einer KI
In einem (grossen) Projekt sehe ich da nicht wirklich ein grosses Problem. Aufgaben sind ordentlich unterteilt. Es werden also immer nur klar abgesteckte Teile gebaut und kommen als MR rein. Und unabhängig von dem Ersteller: Es wird ein Core Review gemacht. Da wird jede Zeile Code, jeder Change betrachtet. Wieso soll das schwieriger sein bei einer KI als bei einem menschlichen Entwickler? Unabhängig vom Ersteller habe ich immer die Chance, dass dieser einen Hinweis nicht versteht. Dann muss ich Schulen. Bei einer KI ist das dann eben eine Anpassung von Specs, Prompts, ... Bei einem Menschlichen Entwickler Schulungen und Co.
Ich habe das Gefühl, dass hier immer zu viel auf einmal erwartet wird, a.la. "Bau mir ein komplettes SAP" (natürlich nicht so sondern als Auflistung von Features) und dann schaue ich, was die KI entwickelt. Der Ansatz ist Müll. Mach das mal mit einem Entwickler. Da kann eigentlich auch nur Müll bei heraus kommen.
Unabhängig davon von all dieser Theorie um die es in dieser Diskussion geht: Unter dem Strich ist die Frage einfach: Wie kann die aktuelle KI uns aktuell unterstützen. Wenn Du mit einem Tool nicht klar kommst, dann hilft es Dir nicht. Beispiel Handwerker: Nagelpistole. Man muss immer überlegen: Hilft Dir das Tool. Wenn Du öfters viele Nägel verbrauchen musst, dann kann es sinnvoll sein, den Umgang damit zu üben und dann hilft es Dir. Wenn Du ein Elektriker bist und 2 mal im Jahr eine paar Nägel brauchst um irgendwo mal etwas Trockenbau wieder dran zu hämmern: Da ist das Tool Quatsch.
Man kann also einfach einmal schauen, was man da selbst braucht oder nicht braucht. Mein Arbeitgeber gibt jedem eine Github Copilot Enterprise Lizenz (mit entsprechenden Settings für Privacy) und der Kunde für den ich arbeite pusht das auch und hat es für viele Projekte freigegeben (Da gibt es noch gewisse Bedingungen die erfüllt sein müssen, aber das ist erst einmal hier uninteressant). Da kann man dann jederzeit schauen, ob und wo es einen unterstützt. Aber das geht dann auch soweit, dass es klare Hinweise und Hilfen gibt, wie man es einsetzen könnte. Und dann probiert man es aus und schaut sich das Ergebnis an.
Meine Erfahrung ist, dass die KI bei vielen Dingen gut unterstützen kann. Sobald der Kontext zu gross wird, wird es schnell zu viel (was evtl. mit Modellen mit größerem Kontext besser wird - das muss ich noch besser ausprobieren) aber ansonsten ist es super. JavaDoc schreiben ist bei mir ein Klick, die KI macht es, ich lese nur noch einmal drüber und passe ganz selten noch etwas an. Die KI schreibt bessere JavaDoc als ich (ich bin einfach zu faul a. la. getCar -> gets the Car - das ist etwas übertrieben und das Beispiel ist schlecht, aber ja: Ich halte es oft etwas minimaler ... Da ist die KI deutlich besser und erfasst auch mehr vom Inhalt der Methode.)
Oder Auswertung von Logs oder so - Gerade wenn man da zu sehr zugemüllt wurde - da kann die KI deutlich schneller Dinge ausfiltern.
Aber auch bei Tests mit Mocken und co - da kann die KI recht viel Tipparbeit übernehmen....
Das sind aber nur meine Erfahrungen. Und die sind halt auch speziell in dem Bereich, in dem ich tätig bin. Also nix Low Code auch auch nix Vibe Programming. Das ist also unabhängig von den Entwicklungen und Möglichkeiten die ich so noch sehe. Aber in der Praxis muss halt jeder für sich selbst heraus finden oder entscheiden, was er nutzen kann oder eben nicht. Die Entwicklung ist halt noch frisch. Da wird in den nächsten Monaten noch sehr viel kommen bin ich mir sicher und evtl. will man noch abwarten, ehe man hier etwas macht.
(Wobei Vibe Programming haben wir auch ... Wir haben kleine Tools mal eben durch die KI generieren lassen. Ein kleines node basiertes Tool für das Laden von Testdaten und absetzen von Requests an die Umgebungen. Da machen wir viel mit Bruno, aber das passte nicht immer. Teilweise haben wir direkt Daten in die Datenbank gepusht nachdem die Testcontainer gestartet sind und so ... Und Bruno passte nicht immer so gut von den Anforderungen. Da ist dann das Tool nicht schlecht und das war dann mehr oder weniger eine kleine Anzahl Prompts und das Tool war fertig ... )