Gedanken zu den Meta Chatbots.

Ich bin mir sehr sicher, dass Meta seine KIs entwickelt und sie einfach überall einbauen wollen, damit sie eine Weiterentwicklung rechtfertigen können. Vermutlich haben sie einfach ein Text Generierungs Framework auf Basis von Insta/Facebook/Twitter/Reddit posts gebaut und das funktioniert bei sachlichen Texten vermutlich nicht so gut wie bei Posts die von Menschen kommen könnten.

An sich finde ich es nicht verkehrt so etwas einzubauen, aber als jemand der sich selber shitposter nennen würde habe ich ein guess was passieren wird: User werden versuchen die Bots allerhand kritische oder Creepy Dinge wie “H. did nothing wrong”, Markierungen von Politikern oder Zuc und so weiter sagen zu lassen. Sie werden versuchen Fehler zu provozieren und die dann als Memes Posten. Dann wenn sie es nach Tagen geschafft haben, wird niemand mehr mit den Bots interagieren.

Aber was müsste man tun, dass die Bots wirklich sinnvoll sind. Meiner Meinung nach würden Dogmatische Bots sehr gut funktionieren. Also ein Bot, der z. B. Unter verschwörungsposts kritisch nachfragt oder offensichtlichen Falschmeldungen widerspricht. Oder einer der z. B. Die Marxistischen lehren vertritt und der eben nach diesem Dogma antwortet.

Oder eben Service-Bots. Den man, Ähnlich wie bei Google Allo, einschalten kann um eine Bahnverbindung, telefonnummer Konzert Datum und so weiter raus zu suchen. Oder intelligenter noch, den man z. B. Wissenschaftskommunikationen raussuchen lassen kann um eine Aussage zu verifizieren.

Also kurzum wirklicher Mehrwert und nicht einfach nur seelenlose Unterhaltung.

noch dazu muss man bedenken, dass eine abfrage bei ChatGPT mit durchschnittlich 250 Wörtern etwa eine halbe kWh braucht und das anlernen etwa den Stromverbrauch eines Mittleren Dorfes im Jahr braucht.

Weiß Musk das schon? Zeit die Schriftart in ‘gloryblaze’ umzubenennen.

Wenn China Taiwan schluckt und die alleinige Kontrolle über die beste Mikrochipproduktion der Welt hat, willst du als Chef mehrerer extrem Chiphungriger Unternehmen so tief es nur irgendwie geht in Winnie Poohs Honigtopf stecken… Es sei denn du hast Rückgrat.

Am besten würde ich es finden wenn ein “neuer Dennis” gefunden werden kann und es wieder 1x Täglich weiter geht. Was ich auch nicht schlecht finden würde ist wenn der Podcast von reinen Daily News zu einer etwas journalistischen Betrachtung kommen könnte. Nicht mehr 1x am Tag die neuen Features runterrasseln und die Headlines vorlesen, sondern 1x in der Woche ein Überthema nehmen und vielleicht mit einem Experten dafür drüber reden. Z.B. eine Folge in der es nur um den Wert von X geht oder in der nur die Idee einer Alles app deutlich tiefer besprochen wird, oder eine Recherche wie tief musk eigentlich wirklich in Chinas Hinterausgang steckt. Und was war nochmal mit den Arbeitsbedingungen bei Tesla oder der Wahlmanipulation bei Meta? Also kein Social Media Update mehr, sondern eine Social Media Recherche.

Ich habe ein paar Gedanken zu Musks “neuem” Entwicklerteam. Es sagt, er hat mehr als 5x so viele Features wie das Alte Entwickler Team mit 5x weniger Leute umgesetzt. Als Person die eine ganze Menge Erfahrung in Entwickler Teams und mit dem Management dieser hat kann ich mir ganz genau vorstellen wie diese Entwickler Teams aussehen.

Normalerweise existiert in jedem Softwareteam mindestens 0,5 Stellen pro Entwickler, die dafür sorgen, dass die Entwickler reibungslos entwickeln können. Fast am wichtigsten sind z.B. die sogenannten Anforderungsspezifikatoren (Applikation-Manager), die jedes neues Feature “auf dem Papier” entwickeln. sie geben vor wie ein neues Feature auszusehen hat und wie es zu funktionieren hat. Klassischerweise sind diese Leute die einzigen im Team der mit dem PO (product-owner), dem Chef des jeweiligen Projektes/Softwareteil reden. Zusätzlich gibt es noch viele andere stellen wie den Softwarearchitekten und die Tester, Deployer, Git-Manager und so weiter. Ein gut funktionierendes Entwickler Team ist vor allem Arbeitsteilung. Lass die Person die am besten DB-Abfragen schreiben kann keine Zeit mit Oberflächen, Dokumentation oder Testung verschwenden, sondern lass das andere Leute machen. Deshalb hört man auch von Firmen wie Google, dass sie 10.000 Leute in der Entwicklung angestellt haben. Davon sind aber vermutlich nicht mal 50% Entwickler.

Da man über Musks “Führungsstil” durch Tesla und SpaceX eine menge weiß, kann man mit ziemlicher Gewissheit sagen, dass für Musk nur Entwickler was in der Entwicklung zu suchen haben. Er hat quasi alle Leute die nicht aktiv coden direkt in der ersten Welle rausgeschmissen, was auch die damalige Head of Development gegenüber ,ich meine, CNN bestätigt hat. Musks Stil ist es die Tür aufzureißen einen “Elevator pitch” einer Software reinzuschreien und dann zu warten bis das Feature fertig ist. Sowas ist für eine gute Entwicklung tödlich. Oftmals gehen nicht mal 50% der Gesamtzeit eines Features in die Entwicklung, sondern in die Planung, die Definition, den Tests und dem ausrollen. Dadurch dass der Entwickler nur die Infos “Der Nutzer soll seine Impressionen sehen” bekommt, baut er es nach bestem Wissen und Gewissen so ein wie er es aus der Entwicklerbrille am besten findet, ein. So kommt es z.b. dass dieses Feature sehr gut ist und auch sehr gut aussieht, aber Katastrophal platziert ist. Eben weil es nicht von jemandem kommt, der ein möglichst gutes Feature aus der Bedienersicht plant, sondern aus der Entwickler-Innensicht. Solche “Schienenlegen während der Zug fährt” Prozesse sorgen nur dafür, dass das Feature länger dauert und mehr entwicklerzeigt verschlingt, weil Musk das Feature z.B. Blau haben will, aber nie gesagt hat dass es blau sein soll, es wird also zeit verschwendet das Perfekte rot zu finden nur um es dann wieder umzufärben.

Dazu passt es sehr gut, dass sie sich nicht trauen ihren Code zu veröffentlichen, weil er nicht gut aussieht. Das Stichwort hier ist Technical Debt. Jede Anpassung oder Erstellung eines Codes muss wie z.B. auch beim Hausbau genau gemacht werden, da man ihn sonst schlechter warten kann oder mehr zeit für die Fehlerbehebung braucht als zum Einbau. Wenn man den Keller beim bau nicht gründlich abdichtet wird er irgendwann volllaufen. Vielleicht nicht heute, vielleicht nicht morgen, aber in ein paar Jahren wird es passieren. Und dann braucht das Beheben des Probleme deutlich mehr Ressourcen als es ein ordentlicher Bau getan hätte. Dieser “Fusch am Bau” wird als Technische Schuld (Technical Debt) bezeichnet und ist ein Grund mehr, weshalb moderne Entwicklerteams länger für ein Feature brauchen und auch aus mehr Leuten bestehen. Meistens entsteht Technische Schuld durch “quick and dirty” Lösungen. Statt dass man z.B. seine Architektur aufbohrt und neue Klassen ordentlich einbaut, was tage dauern kann und etliche andere Baustellen aufmacht, werden die einfach dran geklatscht und sorgen so irgendwann für ein Fehler. Ähnlich wie wenn man eine Etage auf ein bestehendes Haus baut, aber das Treppenhaus und die Wasserleitungen nicht erweitert, sondern einfach Außen am Haus langlaufen lässt. “Klappt doch alles”. So wird es auch bei X gewesen sein. Musk will neue Features JETZT. Und das entfernen der Technischen Schuld bring einen eben nicht vorran. Es wird immer und immer mehr auf den alten code draufgeschaufelt und das von Leuten die den Code erst seit Wochen oder Monaten kennen. Klar wird er da zu Frankensteins Monster. Wenn sich dass dann jemand mit Expertise ansieht sieht man direkt wie instabil und wackelig das alles doch ist.

Das ist leider Typisch mid 50ger Entwickler. Sie haben das Spaghetti-Coding (Nach Markus Bühl: Muss nicht schmecken, muss wirken) verinnerlicht und bekommen das nicht mehr raus. Für sie sind die ganzen Modernen Konstrukte wie Clean Code, Code Mentoring, CI oder TDD die dafür sorgen sollen das der Code auch von einer fremden Person zu verstehen ist, nur Zeitverschwendung “es hat ja auch immer ohne funktioniert”.