Connect with us

Entwicklung & Code

Wie KI die Fähigkeiten von Entwicklerinnen und Entwicklern untergräbt


Mir ist vor Kurzem etwas passiert, das ich sehr erschreckend fand. Ich wurde gebeten, einen Pull Request zu reviewen, und bin dabei auf eine Codezeile gestoßen, die ich nicht verstanden habe und die für mein Verständnis keinen wirklichen Sinn ergeben hat. Da ich kein Freund davon bin, in einem Review vorschnell mit einem harschen

„Das ist falsch!“

zu reagieren, sondern stets versuche, auch die Option in Betracht zu ziehen, dass ich vielleicht etwas missverstanden habe, dass mir eventuell der Kontext fehlt oder dass ich noch nicht das gesamte Bild überblicke, habe ich den Entwickler, der diesen Pull Request verfasst hat, gefragt, was es mit dieser Zeile auf sich habe. Ich würde sie nicht verstehen. Die Antwort lautete:

„Das weiß ich leider auch nicht, ich habe das nicht so wirklich verstanden, aber ChatGPT hat gesagt, dass das so sein muss.“

Ich war sprachlos.


the next big thing – Golo Roden

the next big thing – Golo Roden

Golo Roden ist Gründer und CTO von the native web GmbH. Er beschäftigt sich mit der Konzeption und Entwicklung von Web- und Cloud-Anwendungen sowie -APIs, mit einem Schwerpunkt auf Event-getriebenen und Service-basierten verteilten Architekturen. Sein Leitsatz lautet, dass Softwareentwicklung kein Selbstzweck ist, sondern immer einer zugrundeliegenden Fachlichkeit folgen muss.

Meiner Meinung nach sollte man niemals und unter keinen Umständen Code als „fertig“ deklarieren, den man nicht verstanden hat. Ich habe mich über diesen Vorfall dann mit einer Reihe von befreundeten Entwicklerinnen und Entwicklern ausgetauscht. Das Erschreckende ist: Die meisten von ihnen haben diese Erfahrung auch schon gemacht. Es handelt sich also nicht um einen Einzelfall, sondern das scheint inzwischen eine durchaus gängige Normalität zu sein. Und das ist ein Problem, auf ganz vielen verschiedenen Ebenen.

Fangen wir mit dem offensichtlichsten Punkt an: Wenn Sie als Entwicklerin oder als Entwickler nicht in der Lage sind, Ihre Arbeit und Ihre Ergebnisse zu erklären, weil Sie Ihre Arbeit von einer KI erledigen lassen und mehr oder weniger einfach nur das durchwinken, was Ihnen die KI generiert hat, dann stellt sich die Frage: Welchen Mehrwert liefern Sie?

Empfohlener redaktioneller Inhalt

Mit Ihrer Zustimmung wird hier ein externes YouTube-Video (Google Ireland Limited) geladen.

KI zerstört Deine Intelligenz // deutsch

Anders formuliert: Sie sind deutlich teurer als die KI. Wenn Ihre gesamte Leistung lediglich darin besteht, einen (hoffentlich) passenden Prompt zu formulieren und dann das KI-generierte Ergebnis unhinterfragt und unverstanden einfach nur weiterzugeben, dann wäre es objektiv betrachtet günstiger und auch effizienter, die Aufgabe direkt der KI zu geben. Denn auch Ihnen muss zunächst jemand die Aufgabe erklären, zum Beispiel in Form einer Anforderung. Das ist aber letztlich nichts anderes als ein Prompt, und diesen könnte man theoretisch auch direkt an die KI übergeben und das Ergebnis 1:1 übernehmen. Das ginge nicht nur deutlich schneller, sondern wäre vor allem deutlich günstiger. Die Frage ist also: Womit ist Ihr Job gerechtfertigt?

Natürlich kann man nun einwenden:

„Entwicklerinnen und Entwickler sehen sich das Ergebnis aber noch einmal genau an und validieren es, und damit ist das Ergebnis am Ende dann viel besser!“

Der Punkt dabei ist nur: Genau das erfordert, dass man verstanden hat und nachvollziehen kann, was die KI generiert hat. Und genau das war im besagten Fall eben nicht gegeben. Insofern stellt sich durchaus die Frage: Wenn Sie regelmäßig so arbeiten, untergraben Sie damit nicht langfristig Ihren eigenen Job? Das ist vermutlich nicht in Ihrem Interesse.

Wie reagiert man auf einen solchen Vorfall? Eine Möglichkeit wäre, pauschal den Einsatz von KI zu verbieten. Das Problem dabei ist allerdings, dass Verbote in der Regel wenig bis gar nichts nützen. Das ist genauso wie bei einem Teenager, der fragt, ob er einen Instagram-Account haben dürfe, und Sie als Elternteil sagen dann „nein“.

Das Ergebnis ist mit hoher Wahrscheinlichkeit nicht, dass der Teenager dann keinen Instagram-Account haben wird, sondern dass er relativ bald stattdessen heimlich einen erstellt. Das kann natürlich nicht das Argument sein, um als Eltern allem einfach zuzustimmen, und letztlich muss den richtigen Weg hierfür auch jede Familie für sich entscheiden, aber ich persönlich denke mir: Es ist durchaus ein Vertrauensbeweis und etwas Besonderes, wenn Ihr Kind Sie das fragt. Vielleicht ist es sinnvoll(er), das Positive zu sehen und zu versuchen, gemeinsam einen Weg zu finden, statt ein pauschales Verbot auszusprechen, das ohnehin nicht greift.

So ähnlich ist es auch, wenn man in einem Unternehmen versucht, künstliche Intelligenz zu verbieten. Das kann man machen – aber es wird vermutlich nicht besonders gut funktionieren, weil die Versuchung, sich das Leben leichter zu machen, sehr groß ist.

Damit kommen wir zu dem Punkt, warum so viele Entwicklerinnen und Entwickler überhaupt auf künstliche Intelligenz zurückgreifen. Denn eigentlich müsste man annehmen, dass, wenn man das zu lösende Problem verstanden hat, es in der Mehrzahl der Fälle nicht so schwierig sein dürfte, den passenden Code selbst zu schreiben. Warum macht man das also?

Künstliche Intelligenz macht das Leben leichter, zumindest auf den ersten Blick. Man muss nicht mehr so viel über das Problem und die Lösung nachdenken, man kann mögliche Stolpersteine umgehen und mit weniger Aufwand zu einem guten Ergebnis kommen. Warum also sollte man das nicht nutzen?

Das lässt sich recht einfach beantworten, wenn man sich fragt, warum wir Kindern in der Grundschule nicht einfach einen Taschenrechner in die Hand drücken, sondern ihnen mühsam zunächst schriftliches Addieren und andere Grundrechenarten beibringen. Der Taschenrechner wird üblicherweise erst am Ende der Unterstufe oder am Anfang der Mittelstufe eingeführt, wenn das Kind die Grundrechenarten von Hand beherrscht.

Würden Sie es für eine gute Idee halten, wenn wir Kindern nun nicht mehr das Rechnen an sich, sondern nur noch das Bedienen eines Taschenrechners beibringen würden? Vermutlich nicht. Denn ein gewisses Grundverständnis ist zwingend erforderlich, um später komplexere Probleme lösen zu können.

Der Taschenrechner in der ersten Klasse ist jedoch nur ein Beispiel von vielen. Man könnte auch sagen: 99 Prozent der alltäglichen Kommunikation findet über gesprochene Sprache statt. Eigentlich muss man dafür auch nicht mehr unbedingt lesen und schreiben lernen. Das mag provokant klingen, aber wenn Sie sich fragen, wo Sie in Ihrem Alltag wirklich auf geschriebene Sprache angewiesen sind, dann ist das nicht allzu häufig der Fall. Alexa liest die Nachrichten vor, Tomaten und Gurken können Sie im Supermarkt vermutlich auch dann voneinander unterscheiden, wenn Sie das zugehörige Schild nicht lesen können, und in der Apotheke geben Sie ohnehin das Rezept ab, das Ihnen Ihre Ärztin oder Ihr Arzt ausgestellt hat. Wozu also noch lesen und schreiben lernen?

Wie gesagt: Das ist ein provokantes Beispiel. Der Punkt ist jedoch: Wenn wir grundlegende Fähigkeiten entweder nie erlernen oder sie durch Nichtnutzung wieder verlernen, fehlt uns die Basis für komplexeres Denken. Und genauso ist das beim Entwickeln: Wenn Sie nie gelernt haben – oder zunehmend verlernen – Probleme selbst zu analysieren, Fehler zu suchen, unterschiedliche Lösungsstrategien zu entwickeln, Vor- und Nachteile abzuwägen, Dinge auszuprobieren, kurz: Erfahrung zu sammeln, dann werden Sie nie an Ihren Aufgaben wachsen. Dann sind Sie nämlich dauerhaft darauf angewiesen, dass jemand anders Ihnen sagt, wie Sie etwas besser lösen sollten.

Ich kann mir denken, welches Gegenargument an dieser Stelle kommen wird:

„Das kann mir doch aber auch die KI sagen. Ich muss nur fragen.“

Das Problem daran: Sie wissen nicht, was und wann Sie fragen müssen, weil Sie gar nicht wissen, was in der jeweiligen Situation relevant ist und worauf Sie achten müssten. Um ein Beispiel zu nennen: Wenn Sie eine Datei speichern möchten, und dabei sicherstellen wollen, dass sie auch dann vollständig geschrieben wird, wenn beispielsweise der Strom ausfällt, dann dürfen Sie die Datei nicht einfach so schreiben. Sonst haben Sie möglicherweise eine halbe Datei.

Stattdessen müssen Sie den Inhalt zunächst in eine temporäre Datei schreiben und diese dann umbenennen. Das Umbenennen ist nämlich (meistens) ein atomarer Vorgang. Unter macOS und Linux funktioniert das allerdings wiederum etwas anders als unter Windows. Wenn Sie dieses Problem lösen sollen, müssen Sie also all das wissen. Wenn Sie das nicht wissen, weil Sie nie gelernt haben, wie SSDs funktionieren, was Blöcke sind, wie ein Dateisystem funktioniert, was „atomar“ bedeutet, was eine Transaktion ist, welchen Einfluss Partitionen haben, was der POSIX-Standard ist, und so weiter – dann werden Sie den Vorschlag der KI auch nicht hinterfragen, sondern ihn direkt übernehmen. Und genau das ist das Problem.

Was Sie in solchen Situationen brauchen, ist also nicht nur Wissen, sondern vor allem auch Erfahrung. Wissen kann man nachschlagen. Erfahrung hingegen kann man nicht nachschlagen – die muss man machen: Sie müssen Fehler machen, Sie müssen herausfinden, wo die Ursachen liegen und wie man sie behebt, und das kostet Zeit. Wenn Sie das nicht tun, verlernen Sie – oder lernen gar nicht erst –, wie man komplexe Probleme löst.

Insofern fördert der Einsatz von künstlicher Intelligenz ein sehr oberflächliches Entwickeln: Auf den ersten Blick scheint alles korrekt. Wenn Sie kein tieferes Wissen haben, denken Sie schnell, dass alles zu passen scheint. Aber Sie können es nicht wirklich beurteilen. Sie erkennen nicht die Konsequenzen, kennen keine Alternativen, denken nicht aktiv über Codequalität, Performance oder Architektur nach, und Sie prüfen nichts mehr, weil Sie sich daran gewöhnt haben, dass die KI in der Regel richtig liegt. Doch KI-generierter Code – sofern er nicht trivial ist – enthält gerne subtile Fehler.

Das Beispiel mit dem atomaren Schreiben ist mein üblicher Test: Kein Sprachmodell, das ich bisher ausprobiert habe, liefert auf Anhieb eine korrekte Lösung – im Gegenteil. Und hakt man nach, nähert es sich einer korrekten Lösung nach und nach an, bleibt aber erschreckend lange fehlerhaft. Und Sie merken das nicht, wenn Sie die Grundlagen nicht selbst verstanden haben.

Kurz gesagt: Wissen und Erfahrung schwinden – und damit auch Ihre Fähigkeit, echte Probleme zu lösen. KI macht Sie dümmer. Und je mehr Sie sie einsetzen, desto schneller tritt dieser Effekt ein.

Damit steuern wir auf eine Zwei-Klassen-Gesellschaft zu: Es gibt Entwicklerinnen und Entwickler, die den steinigen Weg gehen, langsam vorankommen, die Grundlagen verstehen und sich mit Details befassen. Und es gibt jene, die sich auf KI verlassen. Letztere werden aber langfristig keinen Erfolg haben, denn Sie sind nicht in der Lage, einen echten Mehrwert zu leisten. Ihr Job kann über kurz oder lang automatisiert werden.

Das ist überraschenderweise kein neues Phänomen. Schon vor KI gab es diese Unterschiede. Ich habe in einer Zeit programmieren gelernt, in der es (für mich) kein Internet gab. Daher war ich auf Bücher, Zeitschriften und vor allem auf logisches Denken angewiesen. Diese Zeit war mühsam, aber ich bin dankbar dafür. Sie hat mir beigebracht, ein Problem im Kern verstehen zu wollen – oder zu müssen.

Wer schon einmal mit mir im Pair Programming gearbeitet hat, weiß, dass ich ständig frage:

„Warum ist das so?“

Ich will verstehen, bevor ich handle. Aber ich habe oft das Gefühl, damit allein zu sein.

Bei der Fehlersuche beobachte ich zum Beispiel oft, dass viele Entwicklerinnen und Entwickler nicht gründlich den Code und die Fehlermeldung lesen und nachdenken, sondern mehr oder weniger blind und wahllos herumprobieren, was ihnen naheliegend erscheint. Ich hingegen analysiere den Code und finde so meist schnell die Ursache. Nicht, weil ich besonders klug bin, sondern weil ich mich auf das Problem einlasse und versuche, es zu durchdringen.

Viele machen sich meiner Meinung nach dabei das Leben zu leicht. Sie verlassen sich auf Assistenten, Frameworks – und heute eben auf KI, ohne sich mit den Grundlagen zu befassen. Das hat in den 1990er-Jahren schon nicht funktioniert, und heute funktioniert es immer noch nicht. Tiefes Wissen ist selten und wird durch KI noch seltener. KI verstärkt die Spaltung. Es gibt eine kleine Elite, die Systeme versteht. Und eine große Masse, die KI-Code validiert, ohne ihn zu verstehen. Diese Masse erlebt aktuell die Illusion von Beschleunigung und Befähigung, doch in Wahrheit schaufelt sie sich ihr eigenes Grab.

Unternehmen glauben, sie könnten künftig ohne Entwicklerinnen und Entwickler auskommen – bis irgendwann niemand mehr da ist, der komplexe Probleme lösen und die KI noch hinterfragen kann. Die wenigen, die das dann noch können, werden sehr, sehr teuer sein. Und dann ist das Gejammer groß …

Ich hatte eingangs gefragt, wie man mit dem Thema umgehen sollte. Ein Verbot wird nicht funktionieren, KI lässt sich nicht mehr aufhalten. Die Frage lautet also vielmehr: Wie arrangiert man sich mit KI?

Ich glaube, die Lösung muss sein: Nutzen Sie KI als Werkzeug, aber behalten Sie die Kontrolle. Die KI darf keine Entscheidung treffen, die Sie nicht auch selbst hätten treffen können. Wenn Sie die KI nicht mehr hinterfragen können, dann haben Sie die Kontrolle verloren. Meine persönliche Faustregel lautet daher: Wenn Sie es nicht selbst schreiben könnten, dann nutzen Sie es nicht. KI darf helfen, aber nie Ihre einzige Wissensquelle sein. Und vor allem: Sie darf Ihnen nicht das Denken abnehmen, sonst verlernen Sie, selbst zu denken.

Wenn Sie nicht mehr verstehen, was passiert, haben Sie ein Problem. Der falsche Ansatz ist also zu sagen, dass es schon irgendwie passen wird. Der richtige ist, herauszufinden, was passiert und warum. Heute gilt dasselbe wie vor 30 Jahren: Tiefer Einstieg in die Materie ist anstrengend, aber lohnenswert. Er kostet Zeit, Disziplin und Ausdauer. Doch genau das unterscheidet Austauschbarkeit von Exzellenz. Wer sich dem KI-Trend einfach hingibt, wird untergehen. Echte Entwicklerinnen und Entwickler hingegen werden die neue Elite der IT-Welt sein.

Was bedeutet das nun für Sie? Ganz einfach: Verlassen Sie sich nicht auf KI. Wählen Sie nicht den bequemen Weg. Dieser führt in die Abhängigkeit. Wollen Sie langfristig gefragt sein? Dann denken Sie selbst. Die Frage, die Sie sich heute stellen müssen, lautet: Wollen Sie langfristig erfolgreich sein oder nur kurzfristig bequem?


(mai)



Source link

Entwicklung & Code

Projektmanagement: Wieso Diversität im Team wichtig ist


Moin.


Escape the Feature Factory: Stefan Mintert

Escape the Feature Factory: Stefan Mintert

(Bild: 

Stefan Mintert

)

Stefan Mintert arbeitet mit seinen Kunden daran, die Unternehmenskultur in der Softwareentwicklung zu verbessern. Das derzeit größte Potenzial sieht er in der Leadership; unabhängig von einer Hierarchieebene.

Die Aufgabe, dieses Potenzial zu heben, hat er sich nach einem beruflichen Weg mit einigen Kurswechseln gegeben. Ursprünglich aus der Informatik kommend, mit mehreren Jahren Consulting-Erfahrung, hatte er zunächst eine eigene Softwareentwicklungsfirma gegründet. Dabei stellte er fest, dass Führung gelernt sein will und gute Vorbilder selten sind.

Es zeichnete sich ab, dass der größte Unterstützungsbedarf bei seinen Kunden in der Softwareentwicklung nicht im Produzieren von Code liegt, sondern in der Führung. So war es für ihn klar, wohin die Reise mit seiner Firma Kutura geht: Führung verbessern, damit die Menschen, die die Produkte entwickeln, sich selbst entwickeln und wachsen können.

Für Heise schreibt Stefan als langjähriger, freier Mitarbeiter der iX seit 1994.

Im gesellschaftlichen Diskurs geht es bei der Diversität um eine Vielfalt bestimmter Gruppenmerkmale. Als Beispiel für die Vielfalt der Arbeitswelt sei die „Charta der Vielfalt“ genannt: „Ziel der Charta der Vielfalt ist es, ein Arbeitsumfeld zu schaffen, in dem alle Beschäftigten die gleiche Wertschätzung und Förderung erfahren, unabhängig von Nationalität, ethnischer Herkunft, Religion oder Weltanschauung, sozialer Herkunft, Behinderung, Alter sowie sexueller Orientierung und Identität.“ (Wikipedia)

Nun gilt es als akzeptierte Wahrheit, dass diverse Teams besser geeignet sind, um komplexe Probleme zu lösen, die etwa in der Softwareentwicklung auftreten. Bedeutet das, ich sollte in meinem Entwicklerteam alle Weltreligionen und ein paar Nationalitäten vertreten haben?

Nach meiner Erfahrung sind das nicht die Diversitätsfaktoren, die den Unterschied machen. Es kommt auf etwas anderes an. Ein Artikel in Harvard Business Review unterstützt diese Meinung und spricht von „kognitiver Diversität“.

Worauf kommt es an, wenn man ein Team divers aufstellen will? Ohne Anspruch auf Allgemeingültigkeit kann ich folgende Faktoren nennen, bei denen Vielfalt innerhalb eines Teams nach meiner Beobachtung einen positiven Einfluss hat.

Alter und Geschlecht spielen eine Rolle. Einerseits glaube ich, dass Männer und Frauen Probleme tendenziell unterschiedlich angehen. Das ist gerade bei komplexen Aufgaben hilfreich. Genauso sorgt eine größere Altersbandbreite im Team dafür, dass die Teammitglieder sehr verschiedene fachliche Erfahrungen mitbringen.

Die Dauer der Firmenzugehörigkeit ist ebenfalls ein wichtiger Faktor. Es ist hilfreich, wenn der „alte Hase“, der sehr gut vernetzt ist, weiß, wen das Team bei einem Problem ansprechen kann. Auf der anderen Seite laufen die jungen Teammitglieder nicht so leicht Gefahr, ein Problem so anzugehen, „wie wir das immer schon gemacht haben“. Sie bringen neue Ansätze und Sichtweisen ins Team.

Eine große Vielfalt der Perspektiven kommt ins Team, wenn nicht alle Teammitglieder die gleichen Ausbildungen durchlaufen haben. Eine Gruppe von Informatikern wird ein Problem sehr wahrscheinlich mit den Mitteln lösen, die man im Informatikstudium gelernt hat. Kommen weitere Disziplinen hinzu, etwa Sozialwissenschaften, Physik, Philosophie oder Ingenieurwesen, steigt die Zahl der Lösungsansätze. Mein Lehrer im Mathe-Leistungskurs hat gerne eine Geschichte aus der Eigentümerversammlung in seinem Haus erzählt. Bis auf eine Person handelte es sich um Akademiker, ihn selbst eingeschlossen. Wenn im Haus ein Defekt auftrat, haben die Studierten in der Versammlung über ausgefeilte Lösungsansätze diskutiert. In der gleichen Zeit hat der einzige Nicht-Akademiker den Schaden einfach repariert. Diese Anekdote zeigt, dass Monokulturen in der Ausbildung von Teammitgliedern oft nicht zu schlagkräftigen Teams führen.

Auch unterschiedliche Muttersprachen erlebe ich im Team als Bereicherung. Das mag an der damit verbundenen Vielfalt der Kulturen liegen, in denen die Teammitglieder aufgewachsen sind, oder daran, dass Sprache das Denken formt.

Einen weiteren Faktor nenne ich in Anlehnung an ein bekanntes Buch: schnelles Denken, langsames Denken. Manchmal ist es wichtig, schnell voranzuschreiten, um beispielsweise mit einem frühen Prototypen einer Software schnell Nutzer-Feedback zu bekommen. Andererseits ist es hin und wieder gut, ein Problem von allen Seiten zu betrachten, um mit einer fundierten Lösung an die Öffentlichkeit zu gehen. Teams, in denen beide Ansätze durch unterschiedliche Personen vertreten sind, haben oft Konflikte. Wenn sie es aber gelernt haben, die Konflikte in der Sache auszutragen und nicht auf der persönlichen Ebene, ist es eine Stärke, mal einen Schnellschuss machen zu können und ein anderes Mal langsam und gewissenhaft zu arbeiten. Wichtig ist, dass sich die Vertreter der jeweiligen Fraktion im richtigen Moment zurücknehmen können.

Und, last, but not least, schätze ich Softwareteams, die in verschiedenen Programmierparadigmen (imperativ, OO, funktional, Logikprogrammierung) denken können. Zwar ist es oft keine Option, während der Produktentwicklung die Sprache zu wechseln oder eine weitere hinzuzufügen, jedoch erlauben einige Sprachen, mehrere Paradigmen zu verwenden. Als Beispiel sei die funktionale Programmierung genannt, die ehemals ausschließlich in funktionalen Sprachen zu finden war und in den vergangenen Jahren auch in objektorientierte Sprachen eingezogen ist.

Welche weiteren Faktoren von Diversität sind in Softwareteams hilfreich? Ich würde mich freuen, in den Kommentaren Eure Meinungen zu lesen.

Abschließend möchte ich auf eine Frage eingehen: Wie kann man die Diversität bei Bedarf erhöhen? Das ist eine Frage der Teamentwicklung. Doch ich habe noch nicht erlebt, dass eine HR-Abteilung die genannten Aspekte beim Recruiting berücksichtigt. Auch ein Teamleiter sucht bei einer Neueinstellung eher nach jemandem, „bei dem die Chemie stimmt“. Das ist nicht pauschal schlecht, doch sollte man sich im Klaren darüber sein, dass eine höhere Diversität damit vielleicht nicht erreicht wird.

Das Team kann selbst die Führung übernehmen und an der Vielfalt arbeiten. Während sich am Alter, Geschlecht oder der Muttersprache der Teammitglieder nichts ändern lässt, ist eine bewusste Weiterbildung in Richtung neuer Skills und Kompetenzen möglich. Den Ausgangspunkt kann ein Team zum Beispiel damit machen, die Diversität der Gruppe zu bestimmen und sichtbar zu machen. Das ist der erste wichtige Schritt, um abzuleiten, in welchen Bereichen man nachbessern sollte. Und wenn eine Neubesetzung einer Stelle ansteht, kann das Team Einfluss nehmen. Damit übernehmen die Teammitglieder einen Teil der Führungsverantwortung, die sonst häufig von niemandem ausgeübt wird.

Im Podcast Escape the Feature Factory greife ich ausgewählte Themen des Blogs auf und diskutiere sie mit einem Gast. Durch den Austausch lerne ich eine zweite Perspektive kennen. Wenn Du auch daran interessiert bist, findest Du den Podcast bei Spotify, Deezer, Amazon Music, und Apple Podcasts. Wenn Du die Themen, die ich im Blog anspreche, verbessern möchtest, komm’ in unsere Leadership-Community für Softwareentwicklung.


(rme)



Source link

Weiterlesen

Entwicklung & Code

programmier.bar: Text-to-Speech mit Thorsten Müller


Immer mehr Alltagsgeräte geben Sprache aus. Was mit Screenreadern und Navigationssystemen begann, findet heute in Wohnzimmern und Hosentaschen mit Alexa und Siri statt. Doch wie lernen Computer eigentlich zu sprechen? Und lässt sich sogar die eigene Stimme klonen? Darüber sprechen Jan Gregor Emge-Triebel und Garrelt Mock von der programmier.bar mit Thorsten Müller, dem Macher und der Stimme hinter Thorsten-Voice. Die Besonderheit an dem Open-Source-Projekt: Sprachausgabe wird hier lokal erzeugt, komplett ohne Cloud-Dienste. Es ist auf Grundlage von Thorsten Müllers eigener Stimme trainiert und damit frei von rechtlich problematischen Trainingsdaten.

Thorsten Müller erzählt, was er beim Aufbau des Projekts gelernt hat, und gibt Tipps für alle, die selbst mit Sprachsynthese experimentieren wollen. Zusätzlich wirft er einen Blick auf die rasante Entwicklung der künstlichen Sprachausgabe. Neben Podcasting gibt es spannende Anwendungsfälle quer durch den Alltag.

Empfohlener redaktioneller Inhalt

Mit Ihrer Zustimmung wird hier ein externer Inhalt geladen.

Die aktuelle Ausgabe des Podcasts steht auch im Blog der programmier.bar bereit: „Text-to-Speech mit Thorsten Müller„. Fragen und Anregungen gerne per Mail oder via Mastodon, Bluesky, LinkedIn oder Instagram.


(mai)





Source link

Weiterlesen

Entwicklung & Code

Cleverer Werbebetrug mit Android-Apps doch aufgeflogen


224 betrügerische Android-Apps hat Google aus seinem Play Store entfernt. Sie waren insgesamt 38 Millionen Mal installiert, von Android-Nutzern in 228 Ländern, und lösten täglich 2,3 Milliarden betrügerische Werbeanzeigen aus, die nie jemand zu Gesicht bekam. Klassischer Werbebetrug, aber besonders gut versteckt. Dennoch aufgedeckt haben ihn Sicherheitsforscher der Firma Human. Sie nennen den Fall „SlopAds“, in Anspielung an „AI Slop“, was KI-generierte Medieninhalte geringer Qualität bezeichnet.

Die betrügerischen Anwendungen hatten meist KI-Bezug und enthielten, so wie sie im Play Store eingereicht und zum Download angeboten wurden, keine Malware-Funktion im engeren Sinne. Erst nach erfolgter Installation wurde eine verschlüsselte Konfiguration mittels Firebase Remote Config nachgeladen. Darin enthalten waren Hyperlinks: eine Liste über 300 betrügerischer Webseiten, die der Bereitstellung der fremden Reklame dienten; ein Link zum Download eines Javascripts, das den heimlichen Abruf der Reklame über Webview steuerte; und ein Link zu vier PNG-Bilddateien.

In diesen Bildern war, steganografisch, weiterer Code versteckt. Die Apps bauten daraus die eigentliche Schadroutine, die Human „FatModule“ nennt. Diese Software prüfte zunächst, auf welchem Wege der Nutzer an die App gelangt war. Wurde sie mittels Suche im Play Store gefunden und installiert, arbeitete sie nur wie angepriesen, die Schadroutine wurde dann nie scharfgeschaltet.

Allerdings hatten die Werbebetrüger auch selbst Werbung geschaltet, nämlich für ihre Apps. Klickte ein Nutzer auf solche Reklame, landete auf diesem Weg in Googles Play Store und installierte die App, wurde deren Betrugsmodus aktiviert. Das sollte Sicherheitsforscher ausschließen, die sich eher im Play Store direkt bedienen, anstatt irgendwelche Reklame zu klicken.

Zusätzlich suchten die Apps nach Hinweisen auf mögliche Ausführung durch Sicherheitsforscher, etwa ein gerootetes Betriebssystem, einen Emulator oder Debugging-Werkzeuge. Nur wenn nichts dergleichen gefunden wurde, begannen die heimlichen Downloads von Werbung in einem versteckten Webview-Prozess. Selbst dann wurden die Abrufe über mehrere Weiterleitungen geschickt, um dem Werbeserver keine verdächtigen Referrer zu liefern.


Ablaufdiagramm

Ablaufdiagramm

Workflow der nicht-immer-betrügerischen Apps

(Bild: Human)

Human hat Google informiert, dass die 224 bekannten Apps aus dem Play Store gelöscht wurden. Google Play wird jene Anwender, die solche Apps bereits installiert haben, zu deren Löschung von ihren Geräten auffordern.

Wie lange die Täter schon am Werk waren, ist nicht bekannt. Sie hatten es immerhin auf 38 Millionen Downloads gebracht. Und noch während der laufenden Untersuchung Humans sind weitere Apps hinzugekommen.

Die Forscher erwarten nicht, dass die Täter sich fortan redlichem Broterwerb widmen werden; wahrscheinlicher sei, dass sie bald neuen Anlauf nehmen, mit einer noch ausgefeilteren Werbebetrugsmasche. Opfer sind einerseits Werbetreibende, die für Werbung bezahlen, die nie ein Mensch würdigt, und andererseits die App-Nutzer, deren Bandbreite, Prozessorleistung und Akkuladung für systematischen Betrug vergeudet wird.


(ds)



Source link

Weiterlesen

Beliebt