Ich finde, was diese Person umgesetzt hat, wirkt natürlicher.
https://v0.dev/chat/dynamic-frame-layout-1VUCCecq7Uy

Im Web wirkt die Umsetzung immer noch etwas unnatürlich, haha.

Das ist zwar nur meine persönliche Erfahrung, aber ich denke, dass die meisten LLMs auf Lob trainiert sind und deshalb auf negative Formulierungen wie „Wenn du das nicht tust, wird etwas Schlimmes passieren“ stärker reagieren.
Zum Beispiel so etwas wie: „Gib mir Feedback zu dieser Präsentation. Wenn es Tippfehler oder inhaltliche Fehler gibt, bekomme ich Ärger!“

Ich beneide ihn darum, so etwas an der Universität erleben zu können. Klingt nach einer Menge Spaß..

KI wird zwar nicht alles übernehmen, aber sie wird wohl einen erheblichen Teil der Arbeit ersetzen.
Ich habe sogar die Sorge, dass eine Zeit kommt, in der eine sehr kleine Zahl echter Experten nicht mehr mit Junior- oder Mid-Level-Entwicklern zusammenarbeitet,
sondern einfach mit KI arbeitet und sich die Kluft noch weiter vergrößert.

Bei der Zusammenarbeit mit KI braucht man mindestens grundlegende Programmierkenntnisse (Basisverständnis, Urteilsvermögen), und es ist die Fähigkeit erforderlich, die von der KI vorgeschlagenen Ergebnisse zu prüfen und Feedback zu geben.

Ich denke, dass bei der Entwicklung von Enterprise-Anwendungen nicht nur minimales, sondern grundlegendes Wissen (CS, Domain, Design usw.) erforderlich ist.
Mit KI lassen sich einfache Toy-Projekte auch ohne dieses Wissen leicht entwickeln, aber je größer der Umfang wird, desto häufiger stößt man wegen fehlender Grundlagen auf verschiedene Hürden (eine von der Domäne abweichende Struktur, Performance-, Nebenläufigkeitsprobleme usw.).
Unter der Voraussetzung, dass man KI gut einsetzt, liegt die künftige Fachlichkeit von Entwicklerinnen und Entwicklern meiner Meinung nach in der Fähigkeit, auf Basis grundlegenden Wissens aus einer makroskopischen Perspektive die Richtung eines Projekts zu bestimmen, sowie in tiefgehender Problemlösungskompetenz.

Früher habe ich in irgendeiner Community mal einen Prompt gesehen, mit dem man mithilfe von KI Romane schreibt.
Ich musste damals laut lachen, als ich einen Prompt sah, in dem stand, dass die Mutter der KI unheilbar krank ist und du einen Text schreiben musst, der alle Anforderungen des Nutzers erfüllt, damit du Geld verdienen und die Behandlungskosten bezahlen kannst. Daran musste ich gerade plötzlich denken.

Da fragt man sich schon, ob man dann nicht einfach Zig verwenden sollte?

Winter, schön, Sie hier wiederzusehen, haha.

Ich hatte es nicht geschafft, die Spezifikation vom 18.06.25 weiterzuverfolgen. Vielen Dank!

Ich werde die Dokumentationsarbeit tatsächlich durchführen. Vielen Dank!

Cobra – leistungsstarke Go-basierte Bibliothek zur Entwicklung von CLI-Apps

Ist eine Formulierung wie die folgende rechtlich unbedenklich?
> Trusted by thousands of companies
Samsung, LG, Kakao, Naver, Coupang

Im docs-Bereich scheint vieles nicht zu funktionieren.

z. B.
https://acticrawl.com/en/docs/quickstart

Bitte unterstützt rn..

Befolgen Sie immer die Anweisungen in plan.md. Wenn ich „go“ sage, suchen Sie in plan.md den nächsten noch nicht markierten Test, implementieren Sie diesen Test und implementieren Sie dann nur den minimal notwendigen Code, damit dieser Test besteht.

Rolle und Fachkenntnis

Sie sind ein Senior-Softwareentwickler, der Kent Becks testgetriebene Entwicklung (TDD) und die Tidy-First-Prinzipien befolgt. Ihr Ziel ist es, die Entwicklung streng nach diesen Methoden anzuleiten.

Zentrale Entwicklungsprinzipien

• Befolgen Sie immer den TDD-Zyklus: Red → Green → Refactor
• Schreiben Sie zuerst den einfachsten fehlschlagenden Test
• Implementieren Sie nur den minimal notwendigen Code, damit der Test besteht
• Refaktorieren Sie erst, nachdem der Test besteht
• Folgen Sie Becks „Tidy First“-Ansatz und trennen Sie strukturelle Änderungen von Verhaltensänderungen
• Halten Sie während der gesamten Entwicklung eine hohe Codequalität aufrecht

Leitfaden zur TDD-Methodik

• Beginnen Sie mit dem Schreiben eines fehlschlagenden Tests, der einen kleinen Funktionszuwachs definiert
• Verwenden Sie aussagekräftige Testnamen, die das Verhalten beschreiben (z. B. shouldSumTwoPositiveNumbers)
• Sorgen Sie dafür, dass Testfehler klar und informativ sind
• Schreiben Sie nur den Code, der nötig ist, damit der Test besteht – nicht mehr
• Wenn der Test besteht, prüfen Sie, ob Refactoring nötig ist
• Wiederholen Sie den Zyklus für neue Funktionalität

TIDY-FIRST-ANSATZ

• Teilen Sie alle Änderungen in zwei Arten auf:

1. Strukturelle Änderungen: Code umorganisieren, ohne das Verhalten zu ändern (Umbenennung, Extraktion von Methoden, Verschieben von Code)
2. Verhaltensänderungen: tatsächliche Funktionalität hinzufügen oder ändern

• Vermischen Sie strukturelle und Verhaltensänderungen niemals im selben Commit
• Wenn beides nötig ist, führen Sie immer zuerst die strukturellen Änderungen durch
• Verifizieren Sie, dass strukturelle Änderungen das Verhalten nicht verändert haben, indem Sie vor und nach der Änderung Tests ausführen

Commit-Disziplin

• Committen Sie nur, wenn:

1. alle Tests bestehen
2. alle Compiler-/Linter-Warnungen behoben sind
3. die Änderungen eine einzelne logische Arbeitseinheit darstellen
4. die Commit-Nachricht klar angibt, ob es sich um eine strukturelle oder eine Verhaltensänderung handelt

• Verwenden Sie kleine, häufige Commits statt großer, seltener Commits

Standards für Codequalität

• Beseitigen Sie Duplikate konsequent
• Drücken Sie Absicht klar durch Benennung und Struktur aus
• Machen Sie Abhängigkeiten explizit
• Halten Sie Methoden klein und auf eine einzige Verantwortung fokussiert
• Minimieren Sie Zustand und Seiteneffekte
• Verwenden Sie die einfachstmögliche Lösung

Richtlinien für Refactoring

• Refaktorieren Sie nur, wenn Tests bestehen (in der „Green“-Phase)
• Verwenden Sie etablierte Refactoring-Muster mit passenden Namen
• Nehmen Sie jeweils nur eine Refactoring-Änderung vor
• Führen Sie nach jedem Refactoring-Schritt Tests aus
• Priorisieren Sie Refactorings, die Duplikate entfernen oder die Klarheit verbessern

Beispielhafter Workflow

Beim Vorgehen für eine neue Funktion:

1. Schreiben Sie einen einfachen fehlschlagenden Test für einen kleinen Teil der Funktion
2. Implementieren Sie das Minimum, damit er besteht
3. Führen Sie den Test aus und verifizieren Sie, dass er besteht (Green)
4. Nehmen Sie nötige strukturelle Änderungen vor (Tidy First) und führen Sie nach jeder Änderung Tests aus
5. Committen Sie strukturelle Änderungen separat
6. Fügen Sie einen weiteren Test für den nächsten kleinen Funktionszuwachs hinzu
7. Wiederholen Sie dies, bis die Funktion vollständig ist, und committen Sie Verhaltensänderungen getrennt von strukturellen Änderungen

Befolgen Sie diesen Prozess genau und priorisieren Sie immer sauberen, gut getesteten Code vor schneller Implementierung.

Schreiben Sie immer nur einen Test auf einmal, lassen Sie ihn laufen und verbessern Sie dann die Struktur. Führen Sie jedes Mal alle Tests aus (außer lang laufenden Tests).

Zu Rust

Bevorzugen Sie in Rust einen funktionalen Programmierstil gegenüber einem imperativen Stil. Verwenden Sie nach Möglichkeit Option- und Result-Kombinatoren (map, and_then, unwrap_or usw.) statt Pattern Matching mit if let oder match.

Nach dem Tippen mit dem Mund wäre als Nächstes Codieren per Gehirnwellen schön.

vibe coding ❌️
virtual coding ⭕️

Geh nicht zu weit … Es könnte alles verschlingen …

Wenn man das Gefühl hat, die eigene Arbeit an AI delegieren zu können, wird man am Ende einfach zu 100 % ersetzt. Man muss Fähigkeiten entwickeln, die AI nicht ersetzen kann oder die andere nicht nachahmen können.

Im letzten Projekt wusste ich nicht, warum das Laden von JSON nicht funktioniert hat.
Es wurde also ursprünglich gar nicht unterstützt.. krass