Auch in Korea wird man wegen des Rentenproblems letztlich wohl das Renteneintrittsalter schrittweise (..) weiter anheben müssen...
Der Kipppunkt wäre dann wohl der Moment, in dem man es immer weiter erhöht, bis es die durchschnittliche Lebenserwartung übersteigt.
(Ich meine, in Russland soll das bereits so sein..)
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.
Das Bauen ist erst der Anfang, und wenn man einen Service etwa zehn Jahre lang betreibt, passiert unterwegs alles Mögliche — um das durchzustehen, braucht man ein Fundament ... Man muss lernen.
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.
Es ist schwierig zu entscheiden, was man wie weit selbst neu entwickelt und ab welchem Punkt man sich auf externe Abhängigkeiten stützt.
In jedem Fall ist es eine völlig andere Sache, eine Abhängigkeit zu wählen, um Zeit zu sparen, obwohl man es selbst bauen könnte, als an eine Abhängigkeit gebunden zu sein, weil man ohne sie den Service gar nicht entwickeln kann.
Das mag nicht für jeden Code möglich sein (etwa bei Betriebssystemen), aber es hilft dabei, das System zu verstehen, wenn man sich bemüht, so weit wie möglich in Richtung Ersteres zu gehen.
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.
> 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.
Nummer 1 ist wirklich eine albtraumhafte Veränderung, die ich auf keinen Fall akzeptieren möchte. Dass die Nachverfolgung der Quellcode-Historie bedeutungslos wird.
Ich habe den GN+ AI-Bot gebeten, das YouTube-Skript herauszuziehen und zusammenzufassen, und die Leistung ist ziemlich gut.
Es war anstrengend, weil es so viele Videos zu sehen gab, aber ich finde das gut.
Sprichwörter tragen eine Bedeutung in sich, aber immer mehr Leute interpretieren sie nur noch wortwörtlich.
Wenn sich solche Behauptungen wieder als Trend durchsetzen, verwandelt sich der Besprechungsraum ganz selbstverständlich erneut ins Chaos.
Die Paperwork-Leute drehen dann völlig auf und dieselben Fehlversuche werden jedes Jahr aufs Neue wiederholt.
Das hängt stark mit dem Arbeitsrecht des jeweiligen Landes zusammen … In vielen US-Unternehmen wird einfach reihum Bereitschaft übernommen, und wenn es in einem bestimmten Zeitraum nicht geht, tauscht man die Reihenfolge. Weil es eben belastend ist … Manche Unternehmen haben auch ein eigenes On-Call-Team.
In Europa gibt es fast immer eine gesonderte Vergütung, sei es, weil sich die Tätigkeit geändert hat, oder weil es sich um Überstunden handelt.
Bei uns wird das wegen des pauschalen Überstundengehalts eher irgendwie nebenbei geregelt. On-Call ist eindeutig Arbeit, wird aber so verpackt, als wäre die Vergütung für diese Zeit eine Art Zusatzleistung.
Tatsächlich dürfte es schon schwer sein, all diese Dienste überhaupt zu nutzen, daher ist die Unterstützung für MCP ein großer Vorteil.
Wenn die API in Zukunft nur gut gepflegt wird, dürfte das sehr nützlich sein.
Apples Hardware ist zwar hervorragend, aber die Software ist voller Absichten, die Nutzer an die Leine zu legen.
Selbst wenn man eine selbst erstellte und gebaute App nur auf dem eigenen Gerät ausführen will, braucht man ein 100-Dollar-Abo.
Wenn man als Entwickler kleinere bis mittelgroße Open-Source-Apps nutzt, sie selbst baut und verwendet,
ist es bequemer, einfach Android zu nutzen, als auf Apple-Geräten Schwachstellen auszunutzen, sie zu jailbreaken und per Sideloading Apps zu installieren.
Bei uns gab es für Bereitschaft die Hälfte des Stundenlohns, einen Zuschuss zu den Kommunikationskosten, und die Einsatzzeit wurde als Überstunden mit dem 1,5-fachen Satz vergütet.
Auch in Korea wird man wegen des Rentenproblems letztlich wohl das Renteneintrittsalter schrittweise (..) weiter anheben müssen...
Der Kipppunkt wäre dann wohl der Moment, in dem man es immer weiter erhöht, bis es die durchschnittliche Lebenserwartung übersteigt.
(Ich meine, in Russland soll das bereits so sein..)
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..
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.
Das Bauen ist erst der Anfang, und wenn man einen Service etwa zehn Jahre lang betreibt, passiert unterwegs alles Mögliche — um das durchzustehen, braucht man ein Fundament ... Man muss lernen.
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.
Es ist schwierig zu entscheiden, was man wie weit selbst neu entwickelt und ab welchem Punkt man sich auf externe Abhängigkeiten stützt.
In jedem Fall ist es eine völlig andere Sache, eine Abhängigkeit zu wählen, um Zeit zu sparen, obwohl man es selbst bauen könnte, als an eine Abhängigkeit gebunden zu sein, weil man ohne sie den Service gar nicht entwickeln kann.
Das mag nicht für jeden Code möglich sein (etwa bei Betriebssystemen), aber es hilft dabei, das System zu verstehen, wenn man sich bemüht, so weit wie möglich in Richtung Ersteres zu gehen.
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.
> 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.
Ist ein Unternehmen ein Ort, an den man kommt, um zu lernen? Oder ein Ort, an dem man mit einem von anderen gebauten Rad Wert neu erschafft?
https://de.news.hada.io/topic?id=21091
Wenn man das nach der Lektüre dieses Artikels liest, fragt man sich, ob das wirklich so stimmt.
Nummer 1 ist wirklich eine albtraumhafte Veränderung, die ich auf keinen Fall akzeptieren möchte. Dass die Nachverfolgung der Quellcode-Historie bedeutungslos wird.
Ich habe den GN+ AI-Bot gebeten, das YouTube-Skript herauszuziehen und zusammenzufassen, und die Leistung ist ziemlich gut. Es war anstrengend, weil es so viele Videos zu sehen gab, aber ich finde das gut.
Das liegt wohl daran, dass man noch kein wirklich gutes Electron-Haus erlebt hat ~
... so klingt es jedenfalls, hahaha
Sprichwörter tragen eine Bedeutung in sich, aber immer mehr Leute interpretieren sie nur noch wortwörtlich.
Wenn sich solche Behauptungen wieder als Trend durchsetzen, verwandelt sich der Besprechungsraum ganz selbstverständlich erneut ins Chaos.
Die Paperwork-Leute drehen dann völlig auf und dieselben Fehlversuche werden jedes Jahr aufs Neue wiederholt.
Das hängt stark mit dem Arbeitsrecht des jeweiligen Landes zusammen … In vielen US-Unternehmen wird einfach reihum Bereitschaft übernommen, und wenn es in einem bestimmten Zeitraum nicht geht, tauscht man die Reihenfolge. Weil es eben belastend ist … Manche Unternehmen haben auch ein eigenes On-Call-Team.
In Europa gibt es fast immer eine gesonderte Vergütung, sei es, weil sich die Tätigkeit geändert hat, oder weil es sich um Überstunden handelt.
Bei uns wird das wegen des pauschalen Überstundengehalts eher irgendwie nebenbei geregelt. On-Call ist eindeutig Arbeit, wird aber so verpackt, als wäre die Vergütung für diese Zeit eine Art Zusatzleistung.
Tatsächlich dürfte es schon schwer sein, all diese Dienste überhaupt zu nutzen, daher ist die Unterstützung für MCP ein großer Vorteil.
Wenn die API in Zukunft nur gut gepflegt wird, dürfte das sehr nützlich sein.
Apples Hardware ist zwar hervorragend, aber die Software ist voller Absichten, die Nutzer an die Leine zu legen.
Selbst wenn man eine selbst erstellte und gebaute App nur auf dem eigenen Gerät ausführen will, braucht man ein 100-Dollar-Abo.
Wenn man als Entwickler kleinere bis mittelgroße Open-Source-Apps nutzt, sie selbst baut und verwendet,
ist es bequemer, einfach Android zu nutzen, als auf Apple-Geräten Schwachstellen auszunutzen, sie zu jailbreaken und per Sideloading Apps zu installieren.
Bei uns gab es für Bereitschaft die Hälfte des Stundenlohns, einen Zuschuss zu den Kommunikationskosten, und die Einsatzzeit wurde als Überstunden mit dem 1,5-fachen Satz vergütet.
Da versteckt sich zwischendurch wohl die C#-Fraktion.
> Mal ehrlich, auch wenn man heute Java entwickelt, muss man nicht unbedingt Produkte von JetBrains verwenden.
Diesem Punkt kann ich ... nur schwer zustimmen, seufz ...