Ich glaube, man braucht die Weisheit, den Satz „X ist die Zukunft“ automatisch als „Ich wünschte, X wäre die Zukunft“ zu lesen.

Kann ich in vielen Punkten echt nachvollziehen, lol. Aus lauter Frust schaltet man einfach in den Modus "nur noch so viel arbeiten, wie man bezahlt wird" und dann finden sie es sogar gut, weil die Arbeit auf einmal reibungsloser läuft. Tatsächlich ist man damit aber nur in einem Zustand von "nicht mein Problem", obwohl man eine riskante Entwicklungsrichtung erkennt.

https://de.news.hada.io/topic?id=21170
Es ist gut, das zusammen mit diesem Artikel zu lesen.

> Allerdings war das Berechtigungsmodell nicht implementiert, sodass sich die Token-Berechtigungen nicht steuern ließen (bitte korrigiert mich, falls ich falschliege)

Derzeit wird dies unterstützt.

https://code.visualstudio.com/updates/v1_107/…

1. „Das Tempo ist belebend“ (die positive Seite)

• Position: KI erledigt langweilige Arbeiten schnell, was eher Energie gibt, und senkt zugleich die Lernkosten für neue Tech-Stacks, was positiv gesehen wird.
• Beispiel: Beim Einsatz einer unbekannten Sprache oder eines unbekannten Frameworks konnte man dank KI-Agenten den langweiligen Lernprozess überspringen und sich sofort auf die Implementierung konzentrieren.

2. „Definitionsstreit um Vibe Coding“ (Begriffsverwirrung)

• Debatte: Es ist umstritten, ob „Vibe Coding“ einfach bedeutet, sich von KI helfen zu lassen, oder ob damit gemeint ist, nur das Ergebnis zu prüfen, ohne den generierten Code zu reviewen.
• Konsens: Ursprünglich hatte der Begriff die negative Nuance von „Code nicht reviewen“, inzwischen hat sich die Bedeutung aber auf KI-unterstütztes Coding im Allgemeinen ausgeweitet.

3. „Tempo ohne Verifikation ist technische Schuld“ (die vorsichtige Seite)

• Kritik: Es ist riskant, den von KI erzeugten Ergebnissen zu vertrauen, ohne den Code zu verstehen. Später auftretende Bugs oder Wartungskosten (technische Schuld) werden größer sein.
• Vergleich: Es sei „so, als säße man in einem selbstfahrenden Auto, ohne zu wissen, wohin es fährt“; Implementierung ohne Verständnis schwächt am Ende die Fähigkeit zur Problemlösung.

4. „Erschöpfung durch Context Switching“ (die zustimmende Seite)

• Zustimmung: Während die KI Code generiert, kommt es zu häufigem Context Switching, wodurch die kognitive Belastung stark ansteigt.
• Symptome: Durch das ständige Prüfen und Korrigieren der KI-Ergebnisse ist die mentale Erschöpfung größer als beim direkten Coding. Vier Stunden Arbeit fühlen sich an, als hätte man den ganzen Tag gearbeitet.

5. „Verlust der Freude am Coding“ (Dopaminmangel)

• Erfahrung: Das Erfolgserlebnis (Dopamin), ein Problem selbst gelöst zu haben, verschwindet. Es fühlt sich leer an, als würde man statt des Spaßes am eigenen Zusammenbauen von Lego nur noch das fertige Produkt ansehen.
• Folge: Schnell nur Ergebnisse zu produzieren, ohne Freude am Prozess, macht Entwickler müde.

6. „Für Anfänger Gift, für Erfahrene Medizin“ (Unterschiede nach Erfahrungsgrad)

• Analyse: Erfahrene Entwickler können Fehler der KI schnell erkennen und korrigieren und dadurch produktiver werden, während Anfänger ein hohes Risiko haben, fehlerhaften Code unverändert zu übernehmen, Lernchancen zu verlieren und schlechten Code in großer Menge zu erzeugen.

7. „Erzwungener Rollenwechsel zum Manager“ (Rollenwandel)

• Phänomen: Entwickler werden vom „Schöpfer“, der selbst Code schreibt, zum „Manager/Reviewer“ gedrängt, der von der KI ausgespuckten Code prüft und korrigiert.
• Belastung: Das erzeugt extremen Stress, ähnlich wie wenn man allein in Echtzeit den Code von fünf Junior-Entwicklern (KI) reviewen müsste.

8. „Mangelndes Verständnis für Business-Logik“ (Hinweis auf Grenzen)

• Problem: KI kann gut Code schreiben, versteht aber weder den geschäftlichen Kontext noch die Gesamtarchitektur.
• Realität: Das Abstimmen von Business-Anforderungen auf den Code und die komplexe Arbeit rund um Edge Cases bleiben letztlich weiterhin Aufgabe des Menschen, und genau dabei entstehen Engpässe.

9. „Verschwinden von Pausen und Freiraum“ (Maschinenzeit)

• Vergleich: So wie Fabrikarbeiter früher im Takt der Maschinen arbeiten mussten, geraten Menschen heute in eine „Maschinenzeit“, in der sie vom hohen Generierungstempo der KI getrieben werden.
• Notwendigkeit: „Erzwungene Pausen“ wie Wartezeiten beim Kompilieren verschwinden, sodass das Gehirn keine Zeit mehr hat, Informationen zu verarbeiten und sich zu erholen. Bewusste Pausen sind unverzichtbar.

10. „Übergangsproblem des Tools“ (Ausblick auf die Zukunft)

• Diagnose: Die aktuelle Erschöpfung entsteht durch ein Missverhältnis: Verifikationstools (Tests, Lint usw.) kommen mit dem Tempo der KI-Generierung nicht mit.
• Lösung: Wenn sich Tools weiterentwickeln und Verifikation im gleichen Maß wie die Generierung automatisieren, könnte sich das Erschöpfungsproblem lösen lassen.

1. Gemischte Reaktionen auf die Form ("LinkedIn-Vibes?")

• Kritik überwiegt: Viele verrissen das Format mit Zeilenumbruch nach jedem Satz als „aufgesetzt wirkenden Text eines LinkedIn-Influencers“ oder „wie von einer KI generierten Text“. Kritikpunkt: viel Verpackung, wenig Inhalt.
• Teilweise Verteidigung: Andere meinten, es sei ein gut lesbares Layout mit Blick auf die kurze Aufmerksamkeitsspanne moderner Menschen oder ein bewusst auf poetischen Rhythmus angelegter Stil.

2. Erfahrungsberichte zur Praxis des "dichten Verlangens"

• Erfolgsbeispiele: Es wurden Erfahrungen geteilt, wie man durch physische, zeitaufwendige Hobbys wie Bildhauerei (sculpting), analoges Schaltungsdesign oder das Schreiben von Postkarten depressive Gefühle überwunden und dem Leben mehr Dichte gegeben habe.
• Die Back-Debatte: Zum Beispiel des „ineffizienten Brotbackens“ aus dem Text entstand paradoxerweise eine Nebendiskussion, in der Ingenieure Tipps zur „Optimierung der Gehzeit“ mit dem Ofen austauschten.

3. Analyse der philosophischen und religiösen Ursprünge

• Rebranding alter Weisheiten: Einige meinten, es sei nur eine Neuverpackung des buddhistischen Konzepts der „Hungrigen Geister“ (Hungry Ghosts) oder klassischer Themen der westlichen Philosophie (etwa Augustinus) in moderner Terminologie (Thin/Thick).
• Gültigkeit der Einsicht: Zwar nichts grundlegend Neues, aber viele stimmten zu, dass die Einsichten für die heutige Gesellschaft gut aufbereitet seien.

4. Grenzen einer dichotomen Logik

• Warnung vor Konzeptvereinfachung: Das Schema „Konsum = oberflächlich, Schaffen = dicht“ sei gefährlich. Auch tiefgehende Lektüre (Konsum) könne dicht sein, und auch kommerzielles Schaffen könne oberflächlich sein.
• Wert der Erholung: Es wurde kritisiert, dass übersehen werde, dass Aktivitäten wie Dösen oder Gaming, die „oberflächlich wirken“, ebenfalls notwendige Erholung zur Regeneration sein können.

5. Hinweise auf strukturelle und Umweltursachen

• Nicht die Schuld des Einzelnen: Das Grundproblem sei das von IT-Unternehmen absichtlich entworfene Dopamin-Belohnungssystem (System).
• Praktische Zwänge: Der Annahme „Wir leben bereits im Überfluss“ wurde widersprochen. Wegen Existenzbedrohungen wie Wohnkosten, Gesundheitsausgaben und anderer Formen wirtschaftlicher Armut sei es in der Realität schwer, einem entspannten „dichten Verlangen“ nachzugehen.

Ist das nicht so etwas wie funktionaler Analphabetismus nach dem Motto „Das Weiße ist Code, das Schwarze ist das Terminal“? So ähnlich wie in einem Zustand, in dem man ohne Log-Auswertung oder Copy-and-Paste überhaupt nicht entwickeln kann.

Zu diesem Artikel gibt es auch „Part 1 examined why senior engineers leave“ und „Part 2 The Economic Intervention That Stops Engineer Attrition“.

https://codegood.co/writing/…

Ich habe gestern auch einen Facebook-Post gesehen, in dem stand, wie praktisch es sei, auf dem Mac Speicherplatz freizugeben (indem man Claude einfach selbst löschen lässt) ...

Könnte man verhindern, dass Führungskräfte diesen Artikel sehen..

Großartig.

Wenn ich so etwas sehe, achte ich einfach auf die Bedeutung des System-Prompts des Tools. Aktuell denke ich persönlich bei der Nutzung in Cursor: opus >= gpt 5.2 > gemini 3. Alles andere, also Sonnet oder 5.1 und so weiter ... nutze ich persönlich nicht mehr. Allerdings sind die Unterschiede bei gpt5.2 je nach Effort ziemlich groß ... Aber ein hoher Effort ist nicht immer automatisch besser. Deshalb nutze ich vor allem Opus und Gemini. Wenn ich gelegentlich auf ein schwieriges Problem stoße, lasse ich alle drei coden, lasse sie gegenseitig ihren Code bewerten und prüfe und übernehme es dann selbst.

Es scheint wirklich viele Leute zu geben, die --dangerously-skip-permissions nicht in einer Sandbox-Umgebung ausführen. Wissen sie vielleicht nicht, was „danger“ bedeutet? schluchz schluchz

Da ist kein falsches Wort dabei.

Hm, andererseits habe ich auch schon Juniors gesehen, die selbst merkwürdigen Code schreiben und dann behaupten, GPT sei dafür verantwortlich, also kommt es wohl ganz auf den Einzelfall an.

Agenten, die Tools verwenden, sind wirklich gefährlich. Hören wir ihnen einfach nur zu.

Ach so. Ich wusste das nicht, weil ich den in Windows 11 integrierten Editor nicht oft benutze. Danke.

Im Editor einfach F5 drücken.

Vielen Dank für Ihre Rückmeldung! Es wäre vermutlich gut, das im README festzuhalten.
Unabhängig davon dachte ich, dass man so etwas wie ein Open-Source-Rust-Paket vielleicht in den verschiedensten Umgebungen nutzen könnte, aber wenn es komplett von einem internen Netzwerk isoliert ist, wird es wohl schwierig sein T_T