Die Copilot-Täuschung – The Copilot Delusion

 (deplet.ing)
37 Punkte von GN⁺ 2025-05-25 | 25 Kommentare | Auf WhatsApp teilen
  • Der Glaube, dass AI-Coding-Tools die Entwicklungsproduktivität tatsächlich steigern, ist ein Irrtum
  • Solche Tools untergraben die Freude am Programmieren und das tiefe Verständnis des Menschen
  • AI kann bei repetitiver Code-Erzeugung nützlich sein, hat aber Schwächen bei Kontext, Performance und Nuancen
  • Übermäßige Abhängigkeit führt dazu, dass Lern- und Entdeckerdrang sowie Code-Qualität von Entwicklerinnen und Entwicklern nachlassen
  • Problematisch ist auch, dass das Wesen des Programmierberufs durch AI-Komfort langsam verschwindet

Einleitung: Die Täuschung rund um AI-Coding-Tools

  • Dieser Text behandelt den Stand von AI-Codegenerierungs-Tools im Mai 2025
  • Die Debatte über die Unfähigkeit von AI könnte mit der Zeit abflauen, doch das Problem der Beschädigung von Wesen und Freude des Programmierens dürfte sich eher verschärfen

Kapitel 1: Mein Kollege, der Programmierer

  • Anhand der Erfahrung, mit einem unprofessionellen Entwickler zu arbeiten, der verantwortungslos Code kopiert und einfügt, wird betont, welche Probleme solche Kolleginnen und Kollegen hinterlassen: schlechtere Performance, Bug-Bomben und ignorierte Architektur
  • Solche Kolleginnen und Kollegen ändern fortlaufend Code ohne Tests, Profiling oder Kontextverständnis und nehmen dem Team am Ende Motivation und Lernwillen
  • Durch das überraschende Geständnis „Captain Obvious“ wird offengelegt, dass diese Beschreibung in Wahrheit eine Satire auf AI-Coding-Tools wie GitHub Copilot und Claude Codex ist
  • Ein echter Copilot im Flugzeug versteht das Gesamtsystem, arbeitet kooperativ und übernimmt Verantwortung. AI-Copiloten hinterlassen dagegen ohne echtes Verständnis nur oberflächlichen Code
  • Unter dem Namen „Copilot“ werden sie mit der Fassade von Produktivität und Innovation in die IDEs aller Entwicklerinnen und Entwickler gedrängt

Kapitel 2: Die Vorteile von Copilot

  • AI-Coding-Tools sind nicht völlig nutzlos
  • Sie sind nützlich, wenn Einsteiger einfach die komplexe Syntax von Sprachen wie C++ lernen oder Konzepte schnell nachschlagen wollen
  • Bei Brainstorming, Kontextaufbereitung und repetitivem Template-Code sind sie schneller und machen weniger Fehler als menschliche Praktikanten
  • Klar ist aber auch: Weil ihnen jedes Gespür für Performance und Effizienz fehlt, droht bei Einsatz ohne Aufsicht eine Katastrophe der Produktqualität
  • Sie können kontextlose Scaffold-/Entwurfscodes schnell liefern, aber vollständiges Design und Tuning bleiben Aufgabe menschlicher Entwicklerinnen und Entwickler

Kapitel 3: Ich als Entwickler und AI

  • Der Autor legt Wert auf die „Freude am Coden selbst“ und das Erfolgserlebnis des eigenen Bauens
  • Wenn man AI den repetitiven Code (boilerplate) überlässt und sogar auf die eigene Implementierung von Bibliotheken oder Makros verzichtet, verschwinden am Ende Kreativität und innere Motivation der Entwicklerinnen und Entwickler
  • Die durch FOMO (Angst, abgehängt zu werden) getriebene Abhängigkeit von Copilot führt dazu, dass grober und unvalidierter Code schnell ausgeschüttet wird
  • Die Abhängigkeit von AI nimmt die Chance auf echtes Lernen sowie auf Verständnis von Low-Level-Performance, Struktur und Code-Qualität
  • Der Name „Copilot“ ist keine Bezeichnung für einen gleichwertigen Kollegen, sondern ähnelt eher der Fantasie eines Gamers mit kurzer Erfahrung, ein Flugzeug steuern zu können

Kapitel 4: Computer sind Maschinen

  • Die Fähigkeit, die Realität und Struktur der Maschine (Hardware) sowie ihre Performance-Eigenschaften zu verstehen, liegt allein beim Menschen
  • AI hat keine direkte Intuition oder Erfahrung mit realen Cache-Misses, Memory-Layout, Profiling oder Performance-Bottlenecks
  • Die Antworten von AI sind vom Kontext losgelöst und in Bereichen, in denen konkrete Optimierung nötig ist, wertlos
  • Selbst beim Bau einer gewöhnlichen CRUD-App sollten Entwicklerinnen und Entwickler Respekt und Sorgfalt gegenüber Nutzern und Systemen mitbringen
  • Professionalität und Handwerkskunst entstehen durch direkte Erfahrung, Mühe und wiederholte Verbesserung

Kapitel 5: Fazit

  • AI-Coding-Tools und ihre leichte Zugänglichkeit führen zum Verschwinden des Hackergeists
  • Es besteht die Sorge, dass in der Branche nur noch passive Nutzer ohne echtes Interesse an Coding, Struktur und Performance übrig bleiben
  • Früher war die Szene erfüllt von reiner Neugier und Kreativität – mit nächtelangem IRC, Hardware-Experimenten und Low-Level-Erkundung
  • Heute bleiben nur noch mechanische Arbeit und Gleichgültigkeit, in denen bloß „AI-Patches geprüft“ werden
  • Gewarnt wird vor dem Risiko, dass Codegenerierung ohne Kontextverständnis und echte Fähigkeiten zum Industriestandard wird und wirklich kompetente Menschen verdrängt werden

Bearbeitungshistorie des Textes

  • Ein Disclaimer zum Veröffentlichungsdatum wurde hinzugefügt
  • Nach HN-Feedback wurde die Position zur Reichweite der Performance-Kritik (komplexe Systeme vs. CRUD) präzisiert
  • Zur besseren Lesbarkeit wurden Satzstil und Zeichensetzung teilweise angepasst

Verwandte Beiträge

25 Kommentare

 
roxie 2025-05-27

Der Text selbst ist unterhaltsam, aber ich bin langsam etwas müde davon, dass sich so viele Beiträge im Grunde auf „Es ist nicht die Lösung für alles, keine AI zu nutzen, aber es ist genauso wenig gut, ihr blind zu vertrauen und sich von ihr abhängig zu machen“ zusammenfassen lassen..
 
ifmkl 2025-05-26

LLMs und KI entwickeln sich mit der Zeit immer weiter. Noch vor wenigen Monaten war es praktisch kaum möglich, etwa bei der Konsistenz von Code viel zu erwarten, aber inzwischen kann man, wenn man den von der KI auf Grundlage der anfänglichen Konfigurationsanfrage erstellten Code in diesem Workspace als Dateien hochlädt und ihr die Anweisung gibt, beim Schreiben neuen Codes stets den bestehenden Codestil einzuhalten, ziemlich konsistenten Code erzeugen lassen.
 
crawler 2025-05-26

> Wenn man sich frühere Posts des Autors ansieht, scheint er Spieleentwickler zu sein.
> Kenntnisse und Materialien zur Spieleentwicklung konnten von LLMs nicht in großen Mengen gelernt werden, daher scheint der Autor des Haupttextes die Grenzen von LLMs stärker zu spüren als im Fall von CRUD-Apps.

Ich habe den Text komplett gelesen, und letztlich denke ich, dass der Autor genau deshalb eine etwas voreingenommene Sichtweise hat.
Natürlich stimmt es, dass das Vorgehen im Haupttext, wie beschrieben, fast schon lehrbuchhaft richtig ist,
aber ich denke, dass AI bei CRUD und Frontend, wo es bereits viele Trainingsdaten gibt, schon ausreichend gute Arbeit leistet.
Man sollte sie innerhalb der eigenen Domäne wohl so gut wie möglich nutzen.
 
superscv 2025-05-26

Ich habe den Eindruck, dass es ein gewisses Missverständnis über die vom Autor beabsichtigte Aussage gibt.
Der Autor legt den Fokus auf die Performance, Stabilität und Wartbarkeit der von ihm betreuten Projekte sowie auf eine geeignete Architektur und Code-Konsistenz; gerade Architektur und konsistenter Code gehören jedoch zu den Bereichen, in denen aktuelle LLMs besonders schwach sind.

Gerade im Webbereich gibt es einen starken Zustrom an Entwicklern, und die Haltung „Hauptsache, es läuft irgendwie“ ist dort weit verbreitet, weshalb sehr viele qualitativ schlechte Codes veröffentlicht wurden. Darauf basierend wurden LLMs trainiert, sodass die Qualität der Ausgaben mitunter geradezu absurd schlecht ist.

Bitten Sie GPT doch einfach einmal: "Das soll ins Web-Frontend, implementiere mir bitte den Quicksort-Algorithmus in JS." Wenn Sie in der Ausgabe keine Probleme erkennen, hat diese Diskussion meiner Meinung nach keinen großen Sinn.
 
ohnul 2025-05-26

Hallo. Aus Neugier habe ich einmal gesagt: „Ich möchte das im Web-Frontend einsetzen, also implementiere bitte den Quicksort-Algorithmus in JS.“ Allerdings fällt es mir schwer zu erkennen, was genau das Problem ist. Wenn Sie es mir erklären könnten, wäre das eine große Hilfe. Vielen Dank im Voraus. https://chatgpt.com/share/68340f9b-b684-8002-8dd5-495d477065cd
 
ohnul 2025-05-26

Irgendwie scheint der Link nicht richtig zu funktionieren, deshalb versuche ich es noch einmal neu. https://chatgpt.com/canvas/shared/68341217ae788191b66a523c948b1a8e
 
superscv 2025-05-26

Die zweite quickSortInPlace()-Variante, die Sie angehängt haben, ist auch eine langsame Implementierung.

Führen Sie einfach den folgenden Code aus.

function quickSortInPlace(arr, left = 0, right = arr.length - 1) {
if (left >= right) return;

const pivotIndex = partition(arr, left, right);
quickSortInPlace(arr, left, pivotIndex - 1);
quickSortInPlace(arr, pivotIndex + 1, right);
}

function partition(arr, left, right) {
const pivot = arr[right];
let i = left;

for (let j = left; j < right; j++) {
if (arr[j] < pivot) {
[arr[i], arr[j]] = [arr[j], arr[i]];
i++;
}
}

[arr[i], arr[right]] = [arr[right], arr[i]];
return i;
}

function quickSort(arr) {
if (arr.length <= 1) return arr;

const pivot = arr[arr.length - 1];
const left = [];
const right = [];

for (let i = 0; i < arr.length - 1; i++) {
if (arr[i] < pivot) {
left.push(arr[i]);
} else {
right.push(arr[i]);
}
}

return [...quickSort(left), pivot, ...quickSort(right)];
}

const repeat = 100;
const arrLength = 10000;
const unsortedArray = new Array<number>();
for(let i = 0; i < arrLength; i++)
unsortedArray.push(Math.round(Math.random() * arrLength));

let sorted: Array<number>;

const qb = performance.now();
for(let i = 0; i < repeat; i++)
sorted = quickSort(unsortedArray);
const qe = performance.now();

const rqb = performance.now();
for(let i = 0; i < repeat; i++) {
let copied = [...unsortedArray];
quickSortInPlace(copied);
}
const rqe = performance.now();

console.log(q: ${qe - qb} ::: rq: ${rqe - rqb});
 
superscv 2025-05-26

Im Grunde ist das Code, der keinerlei Verständnis für den Aufwand bei der Erstellung, Handhabung und Zusammenführung von Collections erkennen lässt. Im Fall von C++ wurden bereits vor etwa 10 Jahren Vorschläge bzw. Implementierungen für Move-Konstruktoren vorgestellt, und ein scharfes Bewusstsein für die Kosten von Speicherkopien gehört dort zu den absoluten Grundlagen. Quick Sort ist seinem Mechanismus nach ein Algorithmus, der die Indizes aller Werte festlegen kann, und es ist besser, wenn auf die einzelnen Felder per Random Access zugegriffen werden kann.

Selbst ohne manische Optimierungen ergibt sich bei Anwendung allein der oben genannten Punkte ein Leistungsunterschied von mehr als dem Doppelten gegenüber der von Ihnen verlinkten Methode.
 
dudlf016 2025-05-27

Ich habe es selbst ausgeführt; es scheint etwas langsamer zu sein, aber ich glaube nicht, dass es bis zum Doppelten geht.

function quickSortInPlace(arr, left = 0, right = arr.length - 1) {  
    if (left &gt;= right) return;  
  
    const pivotIndex = partition(arr, left, right);  
    quickSortInPlace(arr, left, pivotIndex - 1);  
    quickSortInPlace(arr, pivotIndex + 1, right);  
}  
  
function partition(arr, left, right) {  
    const pivot = arr[right];  
    let i = left;  
  
    for (let j = left; j &lt; right; j++) {  
        if (arr[j] &lt; pivot) {  
            [arr[i], arr[j]] = [arr[j], arr[i]];  
            i++;  
        }  
    }  
  
    [arr[i], arr[right]] = [arr[right], arr[i]];  
    return i;  
}  
  
function quickSort(arr) {  
    if (arr.length &lt;= 1) return arr;  
  
    const pivot = arr[arr.length - 1];  
    const left = [];  
    const right = [];  
  
    for (let i = 0; i &lt; arr.length - 1; i++) {  
        if (arr[i] &lt; pivot) {  
            left.push(arr[i]);  
        } else {  
            right.push(arr[i]);  
        }  
    }  
  
    return [...quickSort(left), pivot, ...quickSort(right)];  
}  
  
// =============  
  
function quickSortGPT(arr) {  
    if (!Array.isArray(arr)) {  
        throw new TypeError('quickSort expects an array');  
    }  
    if (arr.length &lt;= 1) return [...arr];  
  
    const pivot = arr[Math.floor(arr.length / 2)];  
    const left = [];  
    const equal = [];  
    const right = [];  
  
    for (const el of arr) {  
        if (el &lt; pivot) left.push(el);  
        else if (el &gt; pivot) right.push(el);  
        else equal.push(el);  
    }  
  
    return [...quickSortGPT(left), ...equal, ...quickSortGPT(right)];  
}  
  
function quickSortInPlaceGPT(arr) {  
    if (!Array.isArray(arr)) {  
        throw new TypeError('quickSortInPlace expects an array');  
    }  
  
    const stack = [[0, arr.length - 1]];  
  
    while (stack.length) {  
        const [lo, hi] = stack.pop();  
        if (lo &gt;= hi) continue;  
  
        const pivotIndex = partitionGPT(arr, lo, hi);  
  
        // Tail‑recursion elimination: push larger partition first  
        if (pivotIndex - 1 - lo &gt; hi - (pivotIndex + 1)) {  
            stack.push([lo, pivotIndex - 1]);  
            stack.push([pivotIndex + 1, hi]);  
        } else {  
            stack.push([pivotIndex + 1, hi]);  
            stack.push([lo, pivotIndex - 1]);  
        }  
    }  
    return arr;  
}  
  
function medianOfThreeGPT(a, b, c) {  
    return (a - b) * (c - a) &gt;= 0 ? a  
        : (b - a) * (c - b) &gt;= 0 ? b  
            : c;  
}  
  
function partitionGPT(arr, lo, hi) {  
    const mid = lo + ((hi - lo) &gt;&gt; 1);  
    const pivotValue = medianOfThreeGPT(arr[lo], arr[mid], arr[hi]);  
  
    while (true) {  
        while (arr[lo] &lt; pivotValue) lo++;  
        while (arr[hi] &gt; pivotValue) hi--;  
  
        if (lo &gt;= hi) return hi;  
  
        [arr[lo], arr[hi]] = [arr[hi], arr[lo]];  
        lo++;  
        hi--;  
    }  
}  
  
function testQuicksort(qs, qsp) {  
    const repeat = 100;  
    const arrLength = 100000;  
    const unsortedArray = new Array();  
    for (let i = 0; i &lt; arrLength; i++)  
        unsortedArray.push(Math.round(Math.random() * arrLength));  
  
    let sorted = [];  
  
    const qb = performance.now();  
    for (let i = 0; i &lt; repeat; i++)  
        sorted = qs(unsortedArray);  
    const qe = performance.now();  
  
    const rqb = performance.now();  
    for (let i = 0; i &lt; repeat; i++) {  
        let copied = [...unsortedArray];  
        qsp(copied);  
    }  
    const rqe = performance.now();  
  
    // Bis auf 2 Nachkommastellen  
    const p1 = ((qe - qb) / repeat).toFixed(2);  
    const p2 = ((rqe - rqb) / repeat).toFixed(2);  
    
    console.log(`Quicksort: ${p1} ms, In-place: ${p2} ms`);  
}  
  
function main() {  
    const useGPT = process.argv.includes('--gpt');  
    console.log(`Using ${useGPT ? 'GPT' : 'geekNews'} quicksort implementation.`);  
    if (useGPT) {  
        testQuicksort(quickSortGPT, quickSortInPlaceGPT);  
    } else {  
        testQuicksort(quickSort, quickSortInPlace);  
    }  
}  
  
main();

===
node q.js
Using geekNews quicksort implementation.
Quicksort: 29.55 ms, In-place: 9.94 ms
node q.js
Using geekNews quicksort implementation.
Quicksort: 28.42 ms, In-place: 9.07 ms
node q.js
Using geekNews quicksort implementation.
Quicksort: 26.91 ms, In-place: 9.15 ms
node q.js --gpt
Using GPT quicksort implementation.
Quicksort: 28.73 ms, In-place: 9.22 ms
node q.js --gpt
Using GPT quicksort implementation.
Quicksort: 26.87 ms, In-place: 9.22 ms
node q.js --gpt
Using GPT quicksort implementation.
Quicksort: 27.97 ms, In-place: 9.30 ms
node --version
v22.14.0

bun q.js
Using geekNews quicksort implementation.
Quicksort: 32.05 ms, In-place: 17.39 ms
bun q.js
Using geekNews quicksort implementation.
Quicksort: 30.97 ms, In-place: 17.82 ms
bun q.js
Using geekNews quicksort implementation.
Quicksort: 29.73 ms, In-place: 16.14 ms
bun q.js --gpt
Using GPT quicksort implementation.
Quicksort: 30.61 ms, In-place: 12.63 ms
bun q.js --gpt
Using GPT quicksort implementation.
Quicksort: 31.09 ms, In-place: 12.76 ms
bun q.js --gpt
Using GPT quicksort implementation.
Quicksort: 33.24 ms, In-place: 12.75 ms
bun --version
1.2.14

deno q.js
Using geekNews quicksort implementation.
Quicksort: 32.30 ms, In-place: 6.79 ms
deno q.js
Using geekNews quicksort implementation.
Quicksort: 26.79 ms, In-place: 6.86 ms
deno q.js
Using geekNews quicksort implementation.
Quicksort: 26.09 ms, In-place: 6.85 ms
deno q.js --gpt
Using GPT quicksort implementation.
Quicksort: 27.18 ms, In-place: 7.92 ms
deno q.js --gpt
Using GPT quicksort implementation.
Quicksort: 25.34 ms, In-place: 8.12 ms
deno q.js --gpt
Using GPT quicksort implementation.
Quicksort: 25.39 ms, In-place: 8.09 ms
deno --version
deno 2.3.3 (stable, release, x86_64-pc-windows-msvc)
v8 13.7.152.6-rusty
typescript 5.8.3
 
superscv 2025-05-27

Ah … jetzt verstehe ich, was gemeint ist. Sie haben wohl nicht verstanden, was man womit vergleichen sollte … Der Quicksort-Algorithmus hat nicht zwei Implementierungsarten, nämlich quicksort und in-place …

Worauf ich von Anfang an hinauswollte, ist, dass es problematisch ist, quickSortGPT() und quickSort() im obigen Code (beides von GPT ausgegebener Code) zu schreiben und sie dann AI-Nutzern bereitzustellen, obwohl die Array-Zusammenführung bereits eingebaut ist.
 
dudlf016 2025-05-27

In der GPT-Antwort kommen sowohl quickSort als auch quicSortInPlace vor, und da in den Kommentaren auf den Teil [...,quickSort(left), ...equal, ...quickSort(right)] hingewiesen wurde, hatte ich verstanden, dass man quickSort mit quickSort und quickSortInPlace mit quickSortInPlace vergleichen sollte, aber offenbar ist das nicht so.
 
superscv 2025-05-27

Bei dem Satz „quickSort gehört zu quickSort“ fasse ich mir an den Hinterkopf.
 
superscv 2025-05-27

Bitte achten Sie beim Lesen unbedingt auf den Kontext.

Ich prahle hier nicht mit meinen aktuellen Coding-Fähigkeiten. Ich weise darauf hin, dass mangelhafter Code wie das hier als Beispiel verwendete quickSort() bei GPT mit hoher Priorität ausgegeben wird.

Wenn man GPT mehrmals durchsucht, wird oft einfach nur das Ergebnis einer einzelnen quickSort()-Funktion geliefert, und quickSort() ist wiederum nur ein Beispiel. Wenn man GPT für Arbeitszwecke um Code bittet, wird sehr oft Code mit viel zu niedriger Qualität ausgegeben (das ist meine Erfahrung als zahlender Nutzer). Wenn es Entwicklern selbst an der Fähigkeit fehlt, so etwas zu unterscheiden, stimme ich der Meinung des Autors im Haupttext zu, dass ein Projekt mit hoher Wahrscheinlichkeit in eine Richtung läuft, in der es kaputtgeht — und so bin ich zu diesem Kontext gekommen.

In meinem Umfeld nehmen Projekte, die mit solcherart miserablen Code überzogen sind, bereits ständig zu.
 
superscv 2025-05-27

Natürlich sollte man die Performance der beiden Funktionen quickSort() und quickSortInPlace() vergleichen........
 
superscv 2025-05-27

Und dann teilt man ein Ergebnis, bei dem der Output mehr als doppelt, sogar drei- bis viermal so stark abweicht, und sagt anschließend, es seien wohl doch keine 2x?
 
superscv 2025-05-26

return [...quickSort(left), ...equal, ...quickSort(right)];

Denken Sie einmal genau darüber nach, was dieser Teil des Codes bedeutet.
 
roxie 2025-05-27

Ich lerne viel dazu.
 
ohnul 2025-05-26

Vielen Dank für die Antwort!
 
crawler 2025-05-26

Zunächst ist bei dem, was ich mit „AI innerhalb einer Domain nutzen“ meinte, natürlich selbstverständlich, dass Entwurf und Koordination vom Menschen übernommen werden ...
Eigentlich ist das heute, da inzwischen alle die Grenzen von LLMs kennen, so selbstverständlich geworden, dass man es kaum noch eigens erwähnen muss.

Als Nächstes zu dem Fall, dass normale Nutzer ohne Entwicklungswissen LLMs verwenden:
Ich glaube zwar nicht, dass weder der Haupttext noch Hacker News noch ich überhaupt darüber gesprochen haben, aber jedenfalls ist auch in diesem Fall das Niveau inzwischen so weit, dass die Nutzer mit den Ergebnissen zufrieden sein können.
Wenn das nicht so wäre, würden Bolt.new, v0 und sogar Cursor wohl kaum so bewertet werden wie heute.
 
superscv 2025-05-26

Zusammenfassung,

Autor: Entwickler sollten ihre Fähigkeiten selbst ausbauen und bewahren. Außerdem funktioniert KI nicht einmal besonders gut.

crawler: Hä? Bei mir funktioniert es gut?

superscv: Gibt viele Probleme...

crawler: Man muss es eben gut abstimmen und einsetzen

superscv: Scheint sich ziemlich weit von der eigentlichen Botschaft entfernt zu haben, die der Autor vermitteln wollte..
 
crawler 2025-05-26

Ich glaube, Sie haben nicht ganz verstanden, warum ich das Fachgebiet des Autors erwähnt habe und was mit der eigenen Domain gemeint ist.
Es wirkt töricht, alle Entscheidungen ohne eigenes Nachdenken an die AI zu delegieren,
aber ich kann auch die Leute auf der anderen Seite nicht so recht nachvollziehen.

Zum Schluss würde ich gern noch fragen, wie superscv Ihrer Meinung nach LLMs beim Programmieren sinnvoll einsetzen sollte.
 
superscv 2025-05-26

Normalerweise schreibe ich nicht oft Kommentare, aber warum ich ausgerechnet zu diesem Artikel einen hinterlasse, ist, dass ich den Gedanken des Autors ziemlich stark zustimme. Nicht AI oder LLM sind das Entscheidende, sondern ich denke, dass ich als Entwickler auf jede Umgebung vorbereitet sein muss, egal was kommt.

Aufgrund der Eigenschaften der Trainingsdaten liefert ein LLM vor allem Daten, die in der Nähe des Durchschnitts der weltweit im Internet verteilten Daten liegen. (Das oben erwähnte js-Quicksort beweist das.) Deshalb nutze ich es meist, um zu fragen, ob etwas in ideologischer oder Design-Hinsicht einigermaßen mit der allgemeinen Perspektive übereinstimmt oder davon abweicht, oder für Inhalte, bei denen lange unklar war, wen man überhaupt fragen sollte.
 
superscv 2025-05-26

Ich bin mir nicht sicher, welchen Sinn es hat, das Gespräch noch weiter fortzusetzen.

Wenn die Ansicht von vornherein lautet, dass von der AI erzeugter Code gewisse Risiken enthalten kann und man ihn daher sorgfältig bereinigen und angemessen nutzen sollte, dann wäre es wohl ausreichend, wenn Sie erklären, inwiefern der Text des Autors von bestimmten Denkverzerrungen geprägt ist. Selbst in der Zusammenfassung steht sinngemäß: „Kontextloser Scaffold-/Entwurfscode kann zwar schnell bereitgestellt werden, aber vollständiges Design und Tuning bleiben Aufgabe menschlicher Entwickler.“
 
superscv 2025-05-26

Die Botschaft des Autors ist zwar tendenziell etwas scharf formuliert, aber wenn man den Text genau liest, sagt er nicht: „Verwendet keine AI.“ Er macht vielmehr einen Vorschlag dazu, wie man sie nutzen sollte, und die Kernaussage ist, dass Entwickler nicht selbst an Fähigkeiten mangeln dürfen.

Warum die Botschaft des Autors so scharf wirkt: Sie wurde als Reaktion auf die Sichtweise formuliert, man werde mit Copilot entwickeln können (mit der Nuance einer hohen Entwicklungsabhängigkeit von Copilot). Deshalb hat er die Botschaft so zugespitzt, dass Entwickler keine Haltung einnehmen sollten, die dem eigenen Existenzwert schadet.

Da auch der Autor nicht die Botschaft vertritt: „Verwendet keine AI“, wird es letztlich, wenn man AI nutzt, auf irgendeinen Kompromiss hinauslaufen. Insofern scheint die eigentliche Botschaft Ihrer eben gegebenen Antwort grob ähnlich zu sein.

Allerdings fiel es mir schwer, dem Teil mit der „voreingenommenen Sichtweise“ in Ihrem ursprünglichen Beitrag zuzustimmen, weshalb ich zuerst geantwortet habe.
 
GN⁺ 2025-05-25
Hacker-News-Kommentare

  • Wenn man Software bauen will, die absolut robust sein muss – etwa für Herzschrittmacher, Raketennavigationssysteme oder den M1-Panzer –, dann sollte man AI-Coding-Agenten beiseitelegen und selbst lernen.
    Aber die meisten von uns bauen so etwas nicht, sondern CRUD-Apps mit fast identischen Anforderungen, bei denen sich nur das Schema und die Art der Integration leicht unterscheiden.
    Tatsächlich gibt es in der Software, die die meisten von uns bauen, kaum etwas Neues.
    Oft ist es am besten, vorhandenes Wissen wiederzuverwenden.
    Für mich sind Coding-Agenten einfach eine massiv gesteigerte Form der Wiederverwendung alten Codes.
    Und nebenbei: Ironischerweise wirkte dieser Text selbst ein bisschen so, als wäre er von AI geschrieben.

    • Ich will mission-kritischen Low-Level-Code ohnehin nicht schreiben.
      Ich halte AI-Tools nicht einfach pauschal für so nützlich wie der Autor, aber diese Diskussionen nach dem Motto „Wer kein Systems Programming in C macht, ist kein richtiger Programmierer“ gehen mir gewaltig auf die Nerven.
      Ich programmiere gern Frontend.
      Ich will auch keine Low-Level-Grafikbibliotheken selbst bauen.
      Ich bin nicht der Typ, der nachts plötzlich aufwacht und loshackt, aber ich habe Leidenschaft und Stolz für meine Arbeit.
      Ich finde nicht, dass alle dieselbe extreme Haltung wie der Autor haben müssen.
      Der Softwaremarkt sollte vielfältig sein.

    • Den Aussagen des Autors zu widersprechen ist völlig okay, aber zu behaupten, der Text selbst sei von AI geschrieben, ist schon ziemlich daneben.
      Der Autor hat lebendige Formulierungen, starke Metaphern und sogar wirklich lustigen Humor in seinen ganz eigenen Stil eingebettet.
      So etwas von einem LLM schreiben zu lassen, ist derzeit wirklich schwer.
      Das ist keine AI, sondern einfach gut geschrieben.
      Ob man den Thesen zustimmt oder nicht: Die Schreibe verdient Anerkennung.

    • Im Original steht auch eine Passage wie diese:
      „Code, der Flugzeuge in der Luft hält, Code, der direkt mit Menschenleben zu tun hat – den wirst du wahrscheinlich nicht selbst schreiben. Die meisten tun das nicht. Aber auch wenn du in einem Enterprise-Umfeld arbeitest und nur einfache CRUD-Apps am Fließband zusammennagelst, trägst du am Ende trotzdem die Verantwortung, Nutzern mit Respekt und Würde zu begegnen.“
      Das unterstreicht, dass selbst einfache Software ein Mindestmaß an Verantwortungsgefühl verlangt.

    • Tatsächlich erkennt auch der Autor einige Fälle an, in denen AI nützlich ist.
      Sein Kernproblem ist, dass wir AI „Copilot“ nennen und Einsteiger ihr dadurch zu sehr vertrauen könnten.
      Ein echter Copilot sollte ein erfahrener Profi und Kollege sein, aber AI ist im Moment mit fünfzigprozentiger Wahrscheinlichkeit einfach ein beschissener Kollege.
      „Im Moment lagern wir Neugier und Eigeninitiative aus dem System aus. Leute mit echtem Entwicklungspotenzial prüfen nur noch AI-Patchsets und verlieren dabei ihre Begeisterung. Das Terminal wird zur Tabellenkalkulation, der Debugger zum Sarg.“
      Trotzdem ist auch AI letztlich nur eine weitere Abstraktion.
      So wie manche befürchten, dass durch Automatisierung wie GC (Garbage Collection) die Grundlagen verloren gehen, gibt es auch bei AI die Sorge, dass sehr grundlegende Programmier- und Lernfähigkeiten verschwinden könnten.
      Webentwickler können dank Abstraktionen meist gute Websites bauen, ohne die tiefen Schichten des Stacks zu verstehen.
      Bei AI ist die Abstraktion aber voller Löcher, sodass etwas bis zu einem gewissen Grad funktionieren kann, auch wenn man die Grundlagen gar nicht wirklich beherrscht.
      Das Problem ist, dass man irgendwann merkt, dass ernste Bugs versteckt bleiben, und Debugging, Problemlösung und selbstständiges Lernen sind Dinge, die AI nicht übernehmen kann.
      Deshalb gibt es die Sorge, dass beim zu leichten Lernen mit AI wichtige Grundkompetenzen übersprungen werden könnten.
      Letztlich wächst man durch Wiederholung und dadurch, dass man selbst gegen Probleme anrennt – so lernt man wirklich.
      Wenn AI sogar dieses „Lernen“ abstrahiert, schwächt das langfristig die Fähigkeiten von Entwicklern.
      Natürlich wird nicht jeder automatisch dumm, nur weil er AI nutzt, und Menschen, die aktiv selbst lernen, wird es weiterhin geben.
      Aber insgesamt dürfte ihr Anteil sinken.
      Denn gerade für Anfänger könnte die Erfahrung verschwinden, etwas „selbst denkend und selbst bauend“ zu erschaffen.
      Und die Abstraktion AI hat am Ende eben viele Lücken.
      Aus Sicht von Anfängern wirkt es vielleicht so, als würde AI alles erledigen, aber letztlich braucht man trotzdem echte Programmier- und Debugging-Fähigkeiten.
      Wenn man also die Probleme in von AI erzeugtem Code wirklich sauber erkennen will, muss man sich die nötigen Fähigkeiten unbedingt aneignen.
      Ich selbst nutze AI-Coding-Hilfen ziemlich gut.
      Aber sie haben eben Nachteile, und mein Fazit ist, dass man sie nicht nur durch die rosarote Brille betrachten sollte.

    • Ich habe mit Google Whisk mal ein kurzes Comedy-Video gemacht und es dann auf TikTok hochgeladen, aber als ich die App geöffnet habe, war dort alles voller AI-generierter Inhalte und Videos, die Leute gegenseitig voneinander kopierten.
      Ich dachte, in „origineller Kreativität“ stecke wirklich noch etwas, aber am Ende sind wir wohl zu leicht reproduzierbar.
      Selbst wenn wir täglich Videos vom Coden auf TikTok hochladen, wiederholen sich am Ende nur endlos dieselben Apps.
      Wie Elon Musk sagt, fühlt es sich an, als bliebe jetzt nur noch, wirklich zum Mars zu fliegen.
      Schon vor zwei Jahren habe ich gesagt, dass LLMs gar nicht mehr so stark „halluzinieren“, und noch immer glauben die Leute, dass Menschen unbedingt nötig sind, aber ich will sagen, dass das immer weniger der Fall ist.
      Ich möchte diese Aussage in zwei Jahren noch einmal hervorholen.

  • „Die Maschine ist real. Silizium ist real. DRAM ist real. L1-Cache und False Sharing sind real, und auch wenn der Branch Predictor eine Münze wirft, ist das real. Wenn es dich interessiert, kannst du damit arbeiten.“
    Solche Zeilen wieder einmal als schön zu empfinden, war wirklich bemerkenswert.

    • Ging mir genauso.
      Der Autor hat in einem heiteren Dave-Barry-Stil geschrieben, und ich musste mehrmals laut lachen.
      Mir gefiel, wie er nachvollziehbare Gedanken über Copilot mit Humor ausgezeichnet ausgedrückt hat.

  • Was in Diskussionen über Softwareentwicklung oft fehlt, ist der Punkt, dass nicht nur „das Ergebnis des Codeschreibens“ zählt.
    Der Weg zum Ergebnis, mit all den Trade-offs unterwegs, ist selbst enorm wichtig.
    Wenn man nur eine einzige Funktion mit einem Junior in einer etwas komplexeren Codebasis umsetzt, merkt man sofort, welche Trade-offs man als erfahrener Engineer ganz unbewusst ständig trifft.
    AI hat zwar auch ein Konzept solcher Trade-offs, aber meist nur auf einem Niveau, das aus Beobachtung gelernt wurde.
    Sie hilft zwar dabei, „Code besser zu schreiben“, aber das eigentliche Urteilen und Denken bleibt am Ende menschliche Aufgabe.
    LLMs „denken“ nicht.
    Und je weiter sich AI entwickelt, desto größer wird das Risiko, dass Menschen selbst immer weniger denken.

  • Für mich sind sowohl die Vor- als auch die Nachteile von Copilot sehr nachvollziehbar.
    Aber anders als beim Hacker- oder Jugendideal eines „Handwerks“ waren Engineers immer schon Engineers.
    Dass die heutigen Kerntechnologien so mühsam entstanden sind, lag auch daran, dass man die damaligen Hürden unbedingt überwinden musste.
    Diese dramatische Geschichte im Nachhinein zu verallgemeinern als „so hat man es eben früher gemacht“ birgt die Gefahr einer verzerrten Sicht.

    • Als Software Engineer, der seit über 20 Jahren auf die harte Tour entwickelt, ist es für mich ein Privileg und eine Quelle von Erfüllung, schwierige Probleme zu lösen.
      Einfache CRUD-Updates sind repetitiv und langweilig, aber die gelegentlichen kniffligen Aufgaben, die Momente, in denen ich Wissen aus dem Studium wieder einsetzen kann, und die Ausnahmefälle wie rekursive Algorithmen sind die Juwelen meiner Laufbahn.
      Ich hoffe, dass auch künftige AI-getriebene Software Engineers diese Erfahrungen stärker zu schätzen wissen.
      AI mag manchmal logisch wirkende Antworten liefern, aber gelegentlich liegt sie komplett daneben und dann auch noch auf gefährliche Weise, deshalb braucht es Menschen, die wissen, was tatsächlich zu tun ist.
      Wenn AIs „halluzinieren“ oder Kontext fehlt, wird es immer Situationen geben, in denen am Ende doch Menschen das Problem lösen müssen.

  • Mein Vergleichsmaßstab ist nicht Pair Programming, sondern ausgelagerte Entwickler im Ausland.
    Dass sich Copilot, Cursor und andere AI-Tools oft deutlich besser anfühlen, liegt schlicht daran, dass ich keine Zeit mehr mit Zoom-Calls, unklarer Kommunikation, Sprachbarrieren und Verständnislücken verschwenden muss.
    Typische Outsourcing-Situationen sind zum Beispiel: „Es wurde eine Funktion isChild hinzugefügt, die boolean zurückgibt, bezogen auf den Root-Node, aber sie hat nichts mit der Prüfung zu tun, ob ein Parent existiert“ oder „API-Parameter können plötzlich kein Array mehr annehmen“.
    Wenn so etwas bei der Arbeit mit AI passiert, kann ich sofort sagen, dass es falsch ist, den Grund erklären, und es wird schnell korrigiert.
    Es gibt fast nicht dieselben Kommunikationsprobleme, Missverständnisse und Zeitverluste wie mit Menschen.
    In dem Moment, in dem AI sich leicht mit Jira-Tickets verbinden lässt, werden wohl rund 80 % der Entwicklungsarbeit zu Ticket-Schreiben und Aufsicht.
    Das heißt natürlich nicht, dass die Rolle von Engineers verschwindet – die Business-Seite wird keine guten Tickets schreiben, und am Ende muss trotzdem jemand die letzte Verantwortung tragen.
    Trotzdem werden viele Organisationen genau das vergessen, und dadurch entsteht Spielraum für große Unfälle.

  • Was ich aus diesem Text vor allem mitgenommen habe, ist dies:
    „Wir werden den rückständigen, aufgeblähten und übermäßig abstrahierten Zustand heutiger Software noch als Gipfel der Entwicklung preisen. Eine Kultur, die Performance bis ans Äußerste optimiert oder Systeme schlank, scharf und klar baut, wird nur noch als alte Geschichte existieren.“
    Ich sorge mich, dass Bibliotheken und Architektur-Patterns, die vor 2023 entstanden sind, künftig zum Kern der Daten werden, auf denen LLMs trainieren, und dadurch verfestigt werden.
    Statt weiter zu innovieren, könnten die Abhängigkeiten und der schmutzige Code der letzten 30 Jahre ewig weiterleben.
    Ich fürchte, dass sogar JavaScript für immer bleiben wird.

  • Ich spüre im Moment sehr konkret den Druck aus dem Leadership, jeden Tag zu hören: „Wir nutzen AI nicht genug“ oder „Wenn wir AI einführen, können wir bestehende Zeitpläne halbieren“.
    Es wird einem aufgezwungen, neue AI-Tools einzuführen, um KPIs zu erfüllen, und wenn man sich nicht anpasst, ist sogar von Teamabbau die Rede.
    Die Welt wirkt komplett verrückt.
    AI wird immer nur als „Werkzeug zum Ersetzen der Arbeit anderer“ verkauft.
    In Wahrheit wirkt AI wohl nur deshalb so gut, weil man bei der Bewertung fremder Arbeit ohnehin nicht wirklich genug über diese Arbeit weiß.
    Es fühlt sich an, als halte das Management den AI-Hammer in der Hand und schlage jetzt auf alles ein, als wäre alles ein Nagel.

    • Wir müssen wirklich überlegen, wie wir die Management-Struktur irgendwie verkleinern und Wege finden, Zeit in wirklich produktive Arbeit zu investieren.
      Ich hoffe auf eine Kultur, die sich stärker auf tatsächliche Arbeit und Delivery konzentriert als auf AI-Nutzung.

    • Das ist letztlich nur das Muster des „Hype Cycle“ der AI-Industrie.
      Wenn sich die Lage beruhigt, bleiben nur brauchbare Tools und Techniken übrig, der Großteil wird verschwinden.
      Wenn man klug erkennt, was tatsächlich Bestand haben wird, und Einfluss auf diesen Wandel nehmen kann, ist das auch künftig ein Weg, zu überleben – und genau darum sollte man sich bemühen.

    • Dieser aktuelle Zwang, „es schnell einzuführen“, steht völlig im Gegensatz zu dem, was für mich das Wesen von Engineering, Design und technischem Handwerk war.
      Früher war es Standard, bei Tools, Sprachen oder Services sorgfältig zu prüfen, ob und warum sie für unseren Fall geeignet sind, und dabei Vor- und Nachteile sauber zu begründen.
      Ein normaler Entscheidungsprozess bestand darin zu fragen: „Warum brauchen wir das?“ und „Warum ist dieser Service sinnvoller?“.
      Es gab Prozesse, um zu testen, ob eine Technologie wirklich eingeführt werden sollte, und danach auch, um den Erfolg und die Effizienz dieser Einführung zu bewerten.
      Unternehmen entfernen sich gerade von genau dieser gesunden Vorgehensweise.

    • Die Illusion, „AI sei immer ein Werkzeug, um die Arbeit anderer zu ersetzen“, ist viel zu weit verbreitet.
      Natürlich gibt es viele einfache Routineaufgaben, aber die meisten Tätigkeiten brauchen, wenn man sie gut machen will, eigene Nuancen und Feingefühl – und genau das droht in der Automatisierung verloren zu gehen.
      Ich kann dem Gerede nicht zustimmen, dass „80 % mit AI schon ausreichen“.
      Fehler wirken sich auf das gesamte System aus, und diejenigen, die das bewerten, haben zwangsläufig zu wenig Erfahrung aus der Praxis.

    • Ich glaube, dass Führungspositionen bald noch schneller verschwinden werden.
      Bis dahin: durchhalten.

  • Der Autor wirkt eindeutig wie ein C++-Entwickler.
    Tatsächlich funktionieren AI-Coding-Assistenten in C++ nur selten richtig, und Leute, die sie gut nutzen, tun das meist effizient in Skriptsprachen oder bei CRUD-Apps.

    • Wenn man sich ältere Posts des Autors ansieht, scheint er Spieleentwickler zu sein.
      Wissen und Material zur Spieleentwicklung konnten LLMs nicht in großen Mengen lernen, deshalb spürt der Autor im Unterschied zum CRUD-App-Fall die Grenzen von LLMs offenbar deutlicher.

  • Teile dieses Textes klingen in meinem Kopf, als würde die Figur Bertram Gilfoyle aus der TV-Serie Silicon Valley sie vorlesen.
    Bin ich der Einzige?

  • Der Kern ist, immer die Fähigkeit zum „Teleskopieren“ zu behalten.
    Dank Coding-Agenten mag es reichen, auf hoher Ebene zu arbeiten, aber wenn es nötig wird, muss man jederzeit tief in den Code hineinsteigen, ihn selbst verstehen und reparieren können – nur dann ist es sicher.