Suchergebnisse für: „Modell“

Du kennst das: Eine Suchmaschine liefert in Sekunden Ergebnisse, dein Smartphone erkennt deine Stimme und trägt einen Termin ein. Dahinter steckt Künstliche Intelligenz. Ein Bericht des Wall Street Journal (WSJ) hat Diskussionen ausgelöst. Der Artikel zeigt, wo KI heute eingesetzt wird – in der Medikamentenentwicklung oder automatisierten Kundenbetreuung. Bereiche, die vor fünf Jahren undenkbar schienen. Was bedeutet das? Wie stellst du dir diese Technologie vor, ohne dem Hype zu verfallen?

Stell dir einen Assistenten vor, der unendlich viele Bücher gelesen hat, aber nicht versteht, was in ihnen steht. Er zitiert jede Statistik, doch nach den Gefühlen des Autors gefragt, steht er ratlos da. So funktioniert KI im Kern. Sie ist kein bewusstes Wesen, sondern ein Mustererkennungssystem. Der WSJ-Bericht hebt Fortschritte bei generativer KI hervor – Systeme, die Texte, Bilder oder Musik erzeugen. Sie lernen aus Datenmengen, berechnen Wahrscheinlichkeiten: Welches Wort folgt? Welches Pixel passt? Das Ergebnis wirkt menschlich, aber die Maschine versteht nichts. Sie spielt ein komplexes Ratespiel.

Der WSJ-Artikel betont: Unternehmen wie Google, Microsoft und Amazon investieren Milliarden. Ein Bereich ist die personalisierte Medizin. KI analysiert Patientendaten, erkennt Risiken, schlägt Behandlungen vor. Doch der Bericht warnt: Je leistungsfähiger die Systeme, desto lauter die Forderungen nach Regulierung. Wer trägt die Verantwortung, wenn eine KI einen Fehler macht – eine falsche Diagnose oder eine diskriminierende Entscheidung? Die Frage ist gesellschaftlich, nicht technisch. Diese Debatte greift der WSJ-Bericht auf.

Vielleicht fragst du dich: „Was hat das mit mir zu tun?“ Eine Menge. Jedes Mal, wenn ein Streaming-Dienst eine Empfehlung gibt, Spam gefiltert wird oder ein Chatbot hilft, arbeitet KI im Hintergrund. Sie ist Teil deines Alltags – unsichtbar, aber präsent. Der WSJ-Artikel beschreibt, wie Unternehmen ihre Effizienz steigern, aber auch Arbeitsplätze verändern. Routineaufgaben werden automatisiert. Das klingt bedrohlich, bietet aber Chancen. KI befreit uns von stupider Arbeit, damit wir uns auf Kreatives und Soziales konzentrieren können. Die Frage ist, wie wir diesen Wandel gestalten.

Ein weiterer Punkt ist die „Erklärbarkeit“ von KI. Viele Systeme arbeiten wie eine Blackbox: Daten rein, Ergebnisse raus, niemand sagt genau, warum. In Medizin oder Rechtswesen ist das ein Problem. Wie soll ein Richter eine KI-Entscheidung nachvollziehen, wenn selbst Entwickler sie nicht erklären? Der WSJ-Artikel verweist auf Forschungsansätze, die Entscheidungen transparenter machen – etwa durch eine Liste der wichtigsten Faktoren. Doch das ist schwierig: Je komplexer das Modell, desto schwerer durchschaubar seine Logik.

Auch die Wirtschaft ist betroffen. Der Bericht zitiert Analysten: KI wird in zehn Jahren globale Wertschöpfung in Billionenhöhe freisetzen. Gleichzeitig warnen sie vor einer „KI-Lücke“ zwischen großen Konzernen und kleinen Unternehmen. Das erinnert an die Anfänge des Internets: Wer zu spät kam, hatte das Nachsehen. Heute ist es ähnlich. Wer KI nicht versteht oder einsetzt, riskiert den Anschluss. Aber der WSJ-Artikel macht Mut: Viele KI-Tools sind als Open Source oder Cloud-Dienste erschwinglich. Du musst kein Datenwissenschaftler sein – du musst lernen, richtig zu fragen.

Ein übersehener Aspekt ist der Energieverbrauch. Der WSJ-Bericht erwähnt: Das Training eines einzigen großen KI-Modells kann so viel Strom verbrauchen wie ein Haus in einem Jahr. Das wirft ökologische Fragen auf. Energieeffizientere Chips und Algorithmen sollen helfen, aber das Thema bleibt. KI ist kein Selbstläufer, sondern eine Technologie, die wir bewusst gestalten müssen. Der Bericht fordert mehr Forschung zu nachhaltiger KI.

Zurück zur Analogie: Stell dir KI wie einen extrem schnellen, spezialisierten Handwerker vor. Er schlägt einen Nagel perfekt in die Wand, aber bei der Bildauswahl für die Einrichtung scheitert er – ihm fehlt der Geschmack. So sind aktuelle Systeme: Meister der Mustererkennung, unfähig, Kontext, Ironie oder Ethik zu verstehen. Der WSJ-Artikel unterstreicht: Deshalb müssen wir KI in menschliche Entscheidungsprozesse einbetten.

Der WSJ-Bericht zeigt: KI ist keine Zukunftsmusik mehr. Sie durchdringt unseren Alltag – von Assistenten über selbstfahrende Autos bis zur personalisierten Werbung. Aber sie ist kein Wundermittel. Sie ist ein Werkzeug, das in den richtigen Händen Vorteile bringt, aber auch Risiken birgt. Der wichtigste Satz aus dem Artikel: „KI ist nicht intelligent im menschlichen Sinne – sie simuliert Intelligenz.“ Wenn du das verinnerlichst, nutzt du die Chancen, ohne dem Hype zu glauben. KI wird bleiben. Sie wird nur so gut sein, wie wir sie einsetzen.

Quelle: wsj.com

Du stehst an der Gepäckausgabe am Flughafen. Dein Koffer kommt auf dem Band, du greifst zu – aber zwischen deinem Koffer und dem nächsten liegen immer zwei andere Koffer. Du wartest jedes Mal, bis die anderen vorbeigezogen sind. Wären alle Koffer eines Typs direkt hintereinander, könntest du sie viel schneller einsammeln. Genauso arbeitet der Speicher deines Computers – und viele Entwickler ignorieren das, bis die Performance plötzlich einbricht.

Ein erfahrener Java-Entwickler hat sich dieses Phänomen genauer angesehen. Er berichtet von seiner Arbeit mit großen Klassen und vielen Attributen. Normalerweise denkt man bei Performance an Algorithmen und deren Komplexitätsklassen – O(n), O(log n) und so weiter. Doch selbst bei einem einfachen linearen Durchlauf (O(n)) können die Laufzeiten dramatisch variieren. Der Grund liegt tiefer: im Zusammenspiel zwischen CPU-Caches und der Anordnung der Daten im Arbeitsspeicher.

Wie der Computer seine Daten organisiert

Die CPU hat mehrere Cache-Ebenen: L1, L2 und L3. L1 ist klein und extrem schnell, L3 größer und langsamer. Das Betriebssystem teilt den Arbeitsspeicher in Seiten (Pages) ein, und die Hardware lädt Daten in sogenannten Cache-Lines. Eine Cache-Line ist typischerweise 64 Bytes groß. Wenn du auch nur ein einziges Byte aus dem Speicher anforderst, lädt die CPU gleich die gesamte Umgebung – 64 Bytes – in den Cache. Der Gedanke dahinter: Daten, die zeitlich oder räumlich nahe beieinander liegen, werden oft zusammen benötigt.

Der Entwickler hat auf seinem System die konkreten Werte ermittelt: L1d-Cache pro CPU-Kern etwa 35 KiB (nach Teilung durch die Anzahl der Instanzen), was 560 Cache-Lines entspricht. Diese Zahlen sind nicht nur Theorie – sie entscheiden darüber, wie schnell dein Programm läuft.

Array of Structs vs. Struct of Arrays – ein Beispiel

Angenommen, du modellierst ein Spiel mit Monstern. Jedes Monster hat einen Namen, eine Position, Lebenspunkte und einen booleschen Wert is_alive. In Java würdest du vermutlich eine Klasse Monster schreiben mit allen Feldern und dann ein Array von Monster-Objekten anlegen. Das nennt man Array of Structs (AoS). Jedes Objekt belegt im Speicher eine bestimmte Größe – sagen wir 64 Bytes. Wenn du jetzt alle Monster durchgehst und nur prüfen willst, ob sie noch leben, holst du trotzdem jedes Mal das gesamte Monster-Objekt in den Cache. Die Cache-Line wird mit den 64 Bytes eines Monsters gefüllt – und du nutzt nur ein einziges Byte daraus. Verschwendung.

Die Alternative: Lege die Daten spaltenweise an. Statt eines Arrays von Monstern hast du separate Arrays für jeden Feldtyp: ein boolean-Array für is_alive, ein float-Array für die x-Position, ein int-Array für Lebenspunkte. Das nennt sich Struct of Arrays (SoA). Nun liegen alle booleschen Werte hintereinander im Speicher. Eine Cache-Line fasst 64 boolesche Werte (1 Byte pro boolean in Java, wenn nicht optimiert). Du kannst also 64 Monster auf einmal auf ihren Lebensstatus prüfen, ohne unnötige Daten zu laden.

Der Entwickler hat einen Benchmark durchgeführt. Bei einer Monster-Struktur von 1 KiB Größe zeigte sich ein bis zu 30-facher Geschwindigkeitsvorteil für SoA. Bei kleineren Strukturen (z. B. 64 Bytes) ist der Unterschied geringer, weil mehrere Monster-Objekte noch in eine Cache-Line passen. Aber sobald die Struktur größer wird, explodiert der Performance-Unterschied. Die CPU kann die Daten viel effizienter vorausladen, wenn sie sequenziell angeordnet sind. Der sogenannte Prefetcher erkennt das Muster und holt die nächste Cache-Line, bevor du sie brauchst. Du wartest praktisch nie auf den Speicher.

Wenn der Zugriff zufällig wird

Nicht alle Programme durchlaufen Daten schön linear. Hash-Maps, Bäume, Graphen und viele andere Datenstrukturen springen wild im Speicher umher. Der CPU-Prefetcher kann dann nicht mehr vorhersagen, wo die nächste Anfrage hingeht. Jeder Zugriff wird zu einem Cache-Miss – die CPU muss auf den langsameren Hauptspeicher warten. Hier wird die Größe deiner gesamten Datenmenge zum entscheidenden Faktor: Passt sie in den L1-Cache, sind die Zugriffe blitzschnell. Für L2 dauert es länger, für L3 noch länger, und wenn du den Hauptspeicher brauchst, wird es richtig teuer.

Der Entwickler hat eine Pointer-Chasing-Benchmark gebaut: N Monster-ähnliche Knoten werden zufällig verlinkt, und dann wird der Kette gefolgt. Jeder Sprung trifft eine unvorhersehbare Adresse. Das Ergebnis: eine Treppenkurve, die zeigt, wie die Zugriffszeit in Stufen ansteigt, sobald die Datenmenge die nächste Cache-Grenze überschreitet. Die Tabelle im Originalartikel verdeutlicht das: Bei 512 Monstern mit je 64 Bytes (Arbeitsmenge 32 KiB) liegt die Latenz bei ~3 ns – alles in L1. Verdoppelst du die Strukturgröße auf 128 Bytes (64 KiB Arbeitsmenge), steigt die Latenz auf ~11 ns, weil die Daten bereits in L2 ausweichen. Bei großen Datenmengen (131.072 Monster, 8 MiB vs. 16 MiB) liegen die Latenzen bei über 160 ns. Das ist der Unterschied zwischen einem Wimpernschlag und einem spürbaren Warten.

Besonders bemerkenswert: Die Kurven für verschiedene Strukturgrößen zeigen das gleiche Treppenmuster, nur verschoben. Größere Strukturen treffen die Stufen früher. Das heißt: Wenn du die Kontrolle über die Gesamtgröße deines Working Sets behältst, kannst du die Performance massiv beeinflussen.

Was heißt das für dich?

Als Entwickler denkst du vielleicht zuerst an Algorithmen-Komplexität. Das ist wichtig, aber nicht alles. Der Weg zum Speicher ist oft der Flaschenhals. Wenn du eine Datenstruktur entwirfst, frage dich: Welche Felder werden gemeinsam genutzt? Wie groß ist mein Working Set? Passt es in den L1-Cache? Kann ich die Daten so anordnen, dass sie sequenziell gelesen werden? Besonders bei Java mit seinen Objekt-Overheads (Header, Padding) ist der Unterschied zwischen AoS und SoA eklatant. Moderne JVMs optimieren zwar, aber sie zaubern nicht – sie können keine Cache-Misses vermeiden, wenn die Daten falsch liegen.

Auch für KI- und Datenverarbeitungs-Pipelines ist das relevant. Viele Matrix-Operationen, Embedding-Lookups oder Graph-Traversals profitieren von cache-freundlichen Layouts. Das Wissen um Cache-Lines und Seiten ist keine Spielerei für Assembler-Programmierer – es ist ein Werkzeug für alle, die ernsthaft performante Software schreiben wollen.

Der Artikel des Entwicklers erinnert uns daran: Jedes Byte zählt. Nicht nur auf der Festplatte, sondern auch im Arbeitsspeicher. Die Hardware ist kein undurchschaubarer Kasten – sie folgt klaren Regeln. Wer sie versteht, kann aus demselben Algorithmus das Doppelte oder Dreifache an Leistung herausholen. Und manchmal reicht schon eine kleine Umstellung – von Array of Structs zu Struct of Arrays – um aus einer lahme Endlosschleife einen rasanten Durchlauf zu machen.

Quelle: fzakaria.com

Ein Architekt, der jahrelang Grundrisse von Hand zeichnete, bekommt plötzlich einen Assistenten, der in Minuten Baupläne entwirft. Softwareentwickler erleben Ähnliches mit Coding Agents. Ein erfahrener Open‑Source‑Entwickler hat seine Erfahrungen geteilt: Er schreibt kaum noch Code von Hand. Viele erleben diesen Wandel.

Seine Arbeitsweise hat sich fundamental verändert. Projekte wie Vite+ (Features in Rust, obwohl er die Sprache kaum beherrscht), fate 1.0 (Live Views, Drizzle‑ und GraphQL‑Support) und Codiff (eine schnelle Diff‑Review‑App) entstanden zu 90 % oder 100 % durch KI‑Codegenerierung. Für Athena Crisis, ein älteres, von Hand geschriebenes Spiel, ließ er die KI 70 Fehler beheben, Features implementieren und Tests schreiben – während er an anderen Projekten arbeitete. „Ich bin einfach nur erstaunt“, sagt er. Nie zuvor gab es eine solche Verbesserung der Entwicklererfahrung.

Wie der Workflow mit KI‑Agenten heute aussieht

Er nutzt die Codex CLI mit einem starken Modell (GPT‑Level). Er bevorzugt die Befehlszeile, weil sie mit einem leeren Blatt beginnt – keine alten Chats, keine Ablenkung. Sein Arbeitsplatz: ein Terminalfenster pro Projekt, links Codex, rechts die Konsole. So arbeitet er an drei bis sechs Projekten gleichzeitig. Der Flaschenhals ist nicht mehr das Schreiben von Code, sondern das Diskutieren und Reviewen der Ergebnisse. Er ordnet die Projekte räumlich auf einem großen Bildschirm: fate oben Mitte, void links, Athena Crisis rechts. Diese räumliche Zuordnung hilft beim Multitasking.

Seine Prompts sind knapp: „Ich will X bauen. Hol Kontext aus Y und Z, mach einen Vorschlag und frag mich, was noch unklar ist.“ Bevor der Agent startet, iteriert er mit ihm über den Plan. Bei Fehlerbehebungen schreibt der Agent zuerst einen Test, der den Fehler reproduziert. Das erhöht die Wahrscheinlichkeit, dass er das richtige Problem löst. Trotzdem: Die Modelle gehen oft in die falsche Richtung. Manchmal ist es besser, eine Sitzung abzubrechen und neu zu starten. Für größere Änderungen nutzt er /review-Zyklen. Sein Review‑Tool ist Codiff, das einen geführten Walkthrough der Änderungen liefert.

Die neuen Engineering Values

Der Autor leitet Werte ab, die für die Softwareentwicklung ab 2026 entscheidend sind. Die Art, Code zu produzieren, hat sich gewandelt, aber grundlegende Prinzipien bleiben – ihre Gewichtung verschiebt sich.

Starke Verantwortung

Gute Ingenieure zeichnen sich durch Domänenwissen und Eigentümerschaft aus. KI‑Agenten verstärken das: Wer sein Produkt kennt, liefert schneller. Wer keine Ahnung hat, erzeugt Lärm. Koordination wird teurer. Deshalb setzt er auf kleine Teams von zwei bis drei Personen mit klaren Zuständigkeiten und isolierten Repositories. Das tut weh, denn er war lange ein Verfechter von Monorepos. Starke Verantwortung bedeutet, Architektur, Anforderungen und langfristige Richtung zu verstehen, die Arbeit der Agenten zu reviewen und Entscheidungen zu treffen – manchmal direkt auf main zu pushen. Code‑Reviews in kleinen Teams dienen der Abstimmung, nicht dem Streit über Zeichensetzung.

Geschmack, Geschmack, Geschmack

Er hat eine geringe Toleranz für Bullshit – und mit Agenten könne jeder den ganzen Tag Bullshit produzieren. Sein Appell: „Hör einfach auf.“ Guter Geschmack bedeutet nicht nur, großartige Produkte zu bauen, sondern auch zu entscheiden, ob es sich lohnt, Zeit in etwas zu investieren. Sein Rat an Teams: Verbringt mehr Zeit damit herauszufinden, was die Zeit wirklich wert ist.

Strenge Leitplanken und schnelle Feedbackschleifen

Große Organisationen legen Code enge Beschränkungen auf, um Geschwindigkeit zu halten. Mit Coding Agents verhält es sich ähnlich: Jede Sitzung gleicht einem neuen Mitarbeiter ohne Kontext. Je mehr Regeln (Lint‑Regeln, automatisierte Tests, schnelle Verifikation), desto schneller iterieren Menschen und Agenten. Schnelle, skalierbare Werkzeuge sind wichtiger denn je. Enge Feedbackschleifen machen den Unterschied zwischen einer Minute und einer Stunde Bearbeitungszeit. Tools sollten nur geänderte Dateien prüfen und nicht mit der Codebasis wachsen.

Kontext im Repository

Kontext war bisher über viele Orte verteilt: Notion, Meetings, implizites Wissen, Commit‑Kommentare. Jede Agentensitzung ist wie ein neuer Mitarbeiter, der nicht an all diese Quellen herankommt. Die Lösung: den gesamten relevanten Kontext direkt im Repository ablegen – lokal, zugänglich für Agenten und Menschen. Das ist der Ort, um Geschmack, Werte und Denkweise zu injizieren. Agenten sollten keinen Schrott in die Codebasis spülen. Code wird noch stärker fürs Lesen optimiert: Weniger und einfacherer Code ist leichter zu verstehen und zu reparieren.

Den eigenen Stack besitzen

Früher bestand eine App zu 95 % aus Drittanbieter‑Abhängigkeiten. Externe Bibliotheken waren sinnvoll, weil eigenes Schreiben teuer war. Aber das machte abhängig von einem Stack ohne Kontrolle. Jede Abhängigkeit bringt Architektur, Einschränkungen und Entscheidungen mit. Agenten verschieben die Kosten: Sie machen es günstiger, eigene Lösungen zu bauen. Der Entwickler hat einen eigenen Open‑Source‑JavaScript‑Stack aufgebaut – für Daten, Internationalisierung, UI, Tool‑Konfigurationen. Das erlaubt ihm, neue Projekte schnell mit engen Vorgaben für Agenten zu starten und die volle Kontrolle zu behalten.

Was das für uns bedeutet

Der Autor weiß, dass dies nicht nur individuelle Arbeitsweisen betrifft, sondern ganze Organisationen umkrempelt. „Alle technischen Organisationen werden sich drastisch ändern müssen, wenn sie erfolgreich sein wollen.“ Wer heute noch in traditionellen Code‑Reviews und langen Genehmigungsprozessen denkt, verliert den Anschluss. Code und Programmierung werden nicht verschwinden. Englische Spezifikationen in Markdown sind eine furchtbare Programmiersprache – dynamischer Code mit Agenten erscheint sinnvoller.

Die Rolle des Ingenieurs verschiebt sich vom Code‑Schreiber zum System‑Dirigenten. Alte Werte wie Sorgfalt, Verantwortung und guter Geschmack bleiben zentral, müssen aber neu interpretiert werden. Statt selbst jede Zeile zu tippen, kuratierst du die Ausgabe von KI‑Assistenten. Statt jedes Detail zu wissen, musst du sicherstellen, dass die Leitplanken stimmen. Statt aufwändiger Koordinationsschleifen setzt du auf kleine, fokussierte Teams und klare Verantwortungen. Das passiert jetzt. Die Frage ist nicht, ob du mitziehst, sondern wie schnell du deine eigenen Engineering Values anpassen kannst.

Quelle: cpojer.net