Wie beeinflusst KI-gestütztes Coding Ihre Arbeit?

• Wenn Sie in letzter Zeit KI-Tools für professionelle Programmierarbeit verwendet haben, teilen Sie bitte Ihre Erfahrungen
  • Welche Tools haben Sie verwendet?
  • Was war effektiv und warum?
  • Auf welche Schwierigkeiten sind Sie gestoßen, und wie haben Sie sie gelöst? (Falls überhaupt.)
• Bitte geben Sie ausreichend Kontext (Tech-Stack, Projekttyp, Teamgröße, Erfahrungsniveau) an, damit andere aus Ihren Erfahrungen lernen können
• Ziel ist es, den tatsächlichen Stand der KI-basierten Entwicklung im März 2026 objektiv zu erfassen — ohne Hype und Wunschdenken

---

Zusammenfassung der Antworten auf Hacker News

Probleme mit KI-generierten Dokumenten und Kommunikation

• Manager erzeugen mit Claude 50-seitige Design-Dokumente, PRDs und Slide-Decks und schicken sie mit der Bitte um „schnelles Review“ herum, obwohl sie sie selbst nicht gelesen haben
• Manche Mitarbeitende erzeugen endlos Slides und weichen konkreten Fragen aus
• Ein DB-Performance-Problem, das früher in 30 Minuten lösbar war (z. B. durch Hinzufügen eines GSI), dauert nun eine Woche, weil eine 37-seitige KI-generierte Dokumentation entsteht (Erklärung, Mitigation, Plan, Review, Risiken, Deployment usw.)
• Es entsteht ein „KI-an-KI“-Kommunikationsmuster, bei dem Empfänger KI-generierte Inhalte wiederum per KI zusammenfassen lassen
  • Im Ablauf „Konzept → LLM bläht es auf → LLM fasst es zusammen → Empfänger“ drohen Kontext- und Nuancenverluste wie bei der Stillen Post
• Es gilt als unhöflich, wenn eine Seite minderwertige Inhalte ausschüttet und von der anderen sorgfältiges Review erwartet — eine asymmetrische Erwartungshaltung
• Ein Freelance-Kunde schickte mit KI übertrieben ausgearbeitete Spezifikationen, wollte in Wirklichkeit aber nur eine CSV-Tabelle mit 30 Zeilen

Negative Erfahrungen im Arbeitsumfeld

• Senior-Entwickler lassen alles von KI erledigen und wälzen das Aufräumen auf Junior-Entwickler ab
  • KI-generierter Code hält sich nicht an das API-Design des Hauptprojekts und enthält massenhaft unnötige Fehlerbehandlung und Parsing-Code
  • Das Aufräumen dauerte über eine Woche; da das ursprüngliche Team ähnliche Ergebnisse fast sofort geliefert hatte, wirkte die KI-Lösung paradoxerweise langsamer
• Ein großes börsennotiertes Unternehmen setzte sich das Ziel, innerhalb eines Jahres 100 % KI-generierten Code zu erreichen, und trennte sich von Mitarbeitenden auf allen Ebenen, die dagegen waren
• In einer Kultur, die Feature-Release-Geschwindigkeit über Codequalität stellt, werden Ingenieure, die an Qualität arbeiten, strukturell als „ineffizient“ eingestuft
• Ein Teammitglied nahm Wochen alten Code, fütterte ihn in Claude und reichte das Ergebnis als fertig ein — mit falschen Business-Anforderungen und vielen schweren Bugs
• In Umgebungen, in denen KI-Nutzung verpflichtend ist, steigt die Last für Code Reviews massiv; täglich müssen tausende Zeilen schlechter PRs geprüft werden
  • „Alles, was ich mochte, wurde mir weggenommen, und nur das, was ich nicht mochte, ist übrig geblieben“

Erfahrungen bei FAANG und Großunternehmen

• Ein FAANG-Mitarbeiter: Im Job noch nie ein commit-fähiges Ergebnis erhalten, bei privaten Projekten aber 10-fache Beschleunigung
  • Eigene Frameworks und Libraries in großen Codebasen fehlen in den Trainingsdaten, wodurch die Sichtbarkeit des Modells begrenzt ist
  • Im Team kennt praktisch niemand persönlich einen echten Erfolgscase
• Ein Amazon-Ingenieur: Mit Kiro (AWS-eigenes Tool) und Opus 4.6 2- bis 4-fache Produktivität im Job, mehr als 10-fach im Side-Business
  • Einsatz nicht nur fürs Schreiben von Code, sondern auch für Datenanalyse, Debugging und das Management von Deployment-Loops
  • Ein Feature, das früher einen Monat dauerte, wurde in zwei Wochen umgesetzt — entscheidend war die gesparte Lernzeit für Detailwissen, das man nur einmal braucht
• Zu einem Amazon-Ausfall: Das kolportierte Verbot von KI-Code stimmt nicht; während des Incidents gab es nur einen KI-bezogenen Fall auf Basis eines alten internen Wikis
• Ein Microsoft-Ingenieur: Mit GitHub Copilot und unbegrenztem Opus wurde die Arbeit zwar schneller, aber die Erwartungen stiegen übermäßig (von 2 Wochen auf erwartete 2 Tage)
• In R&D bei einem Großunternehmen liegt der größte Wert in Bug-Tracking und dem Erzeugen von einmaligem Logging-Code; auch Prototyping ist deutlich schneller geworden
  • Weil die Implementierung billiger wird, verschärft sich jedoch der Wettbewerb darum, was überhaupt gebaut werden soll — schnelleres Denken und klarere Urteilsfähigkeit werden wichtiger

Positive Erfahrungen und Produktivitätsgewinne

• Ein Ingenieur mit 10 Jahren Erfahrung, kleines Team: Eine Consumer-App mit 100K DAU wird von 3 Personen gebaut und betrieben; früher hätte man dafür wohl 10 gebraucht
  • Keine Bug-Liste, zwei Personen verstehen fast die gesamte Codebasis, Refactorings finden deutlich häufiger statt
• Simon Willison: Seit November 2025 schreibt er den Großteil seines Codes mit Agenten, sogar auf dem iPhone mit Claude Code
  • Projekte, über die er jahrelang nur nachgedacht hatte, setzte er in wenigen Stunden um; das verschiebt die Möglichkeiten von Solo-Entwicklern
  • Beim Schreiben einer Go-App mit Claude Code lernt er eine neue Sprache quasi durch Osmose
• Ein erfahrener Freelancer: Nach dem Einsatz von Claude Code 95 % Genauigkeit bei Terraform, in Datenprojekten mehr als 5-fache Geschwindigkeit
  • „Dinge, die ich früher nicht konnte, kann ich jetzt; Schwieriges wird einfach, und Einfaches wird schnell und einfach.“
• Ein kleines Game-Studio nutzt KI zur Verbesserung interner Tools und Workflows; je näher eine Aufgabe an einer Idee ist, desto besser funktioniert KI-Coding
• Ein Betreiber einer kleinen Brauerei baute mehr als fünf interne Tools, etwa für Buchhaltungsautomatisierung (16 Std./Monat → 3 Std.), Produktions- und Verkaufsberichte sowie Reward-Tracking

Einsatz zum Verständnis von Codebasen und beim Debugging

• In großen oder Legacy-Codebasen hilfreich für Fragen wie „Welche Funktionen fassen diese Tabelle an?“
• Beim Erkunden eines großen Monolithen: Auf die Frage „Wie viele Arten von Authentifizierung gibt es an API-Endpunkten?“ wurden in 5 Minuten vier Varianten gefunden und zusammengefasst
• Beim Debugging exzellent für die Analyse, warum komplexe Regexes nicht matchen, sowie für Stack-Traces und Log-Analyse
• Die Onboarding-Zeit in unbekannte Codebasen sinkt von Tagen auf Minuten
  • Prozesse wie „einen Kollegen in Indien oder Osteuropa fragen und über Nacht auf Antwort warten“ werden von KI vollständig ersetzt

Sorgen um Codequalität und Wartbarkeit

• Wiederkehrende Probleme von KI-generiertem Code: unnötige Komplexität, übermäßige Fehlerbehandlung, duplizierte Logik, Nichtnutzung bestehender Funktionen
• Bei Code, der gewartet werden muss, ist selbst schreiben langfristig oft schneller — bei KI-Code fehlt später das mentale Modell für Änderungen
• Ein Fall, in dem Claude einen HTML-Sanitizer durch eine benutzerdefinierte Regex ersetzen wollte — Tests bestanden, aber es entstand eine Sicherheitslücke
• Beim Bau einer API mit Authentifizierung wurde eine Route hinzugefügt, über die jeder per PUT neue API-Keys setzen konnte
• KI führt fast nie proaktive Refactorings zur Reduktion von Codebasis-Komplexität durch und häuft stattdessen weiter Logikduplikate, unnötige Abstraktionen und zyklische Abhängigkeiten an
• Es gibt auch ein Beispiel einer 200K-LOC-Codebasis, die zu 99,5 % mit KI geschrieben wurde, allerdings nur mit striktem TDD und Review jeder einzelnen Zeile

Skill-Verfall und psychologische Auswirkungen

• „Ich kenne meinen eigenen Stil der Faulheit gut genug, um zu wissen, dass meine Fähigkeiten verkümmern würden“ — daher die bewusste Entscheidung, KI-Codegenerierung gar nicht erst zu nutzen
  • Ein Kollege räumte ein, seit 6 Monaten von KI abhängig zu sein; obwohl er aufhören will, greift er immer wieder automatisch dazu, fast wie bei einer Sucht
  • Ein Junior-Entwickler reichte im letzten Jahr immer absurdere MRs ein; später wurden Spuren von KI-Nutzung entdeckt
• Ein Senior-Ingenieur: „Ich merke, dass meine Coding-Skills abbauen, bin mir aber nicht sicher, ob Coding wirklich der Teil war, der mir am meisten Spaß gemacht hat“ — er investiert nun mehr Zeit in Design und Architektur
• In Privatprojekten baut man mit KI zwar 10-mal schneller, fühlt sich aber nicht wirklich mit dem Ergebnis verbunden, weil „ich es nicht selbst gemacht habe“, und verliert die Motivation bis zur Fertigstellung
• „KI macht die Teile gut, die ich mochte, und zwingt mich, mehr Zeit mit den Teilen zu verbringen, die ich nicht mochte oder die mich auslaugen“ — insgesamt steigt der Stress
• Ein Ingenieur im dritten Berufsjahr: KI kann 90 % erledigen, aber für die restlichen 10 % braucht man das mentale Modell dieser 90 % — und das entsteht nur, wenn man selbst programmiert

Effektive Workflows und Best Practices

• Der Ablauf Spezifikation → Plan → Kritik → Plan verbessern → Implementierung liefert die höchste Qualität
  • Nach dem Einsatz des Plan Mode folgt die Implementierung; anschließend wird mit demselben Modell zusätzlich ein Code Review gemacht (am besten in einer separaten Session)
• Mit Dateien wie AGENTS.md / CLAUDE.md werden Coding-Stil, Muster und Verbote dokumentiert — Updates erfolgen jeweils am Ende einer Session
• Agenten sollten eigene Debugging- und Verifikationsfähigkeiten erhalten: Tests ausführen, Logs prüfen, Screenshots validieren usw.
• Wenn Einschränkungen im Voraus klar formuliert werden („nur Standardbibliothek, keine neuen Dateien, maximal 50 Zeilen“), steigt die Ergebnisqualität drastisch
• Zwischen mehreren Agenten werden Statusdateien (mechanical ledger) geführt: Commits, Tests und fehlgeschlagene Patches werden dokumentiert, damit neue Sessions den Kontext aus dem realen Zustand statt aus Erinnerung rekonstruieren
• Mit Git worktree können mehrere Aufgaben parallel bearbeitet und Kontexte sauber getrennt werden

Nichttechnische Rollen und die Ausweitung von KI

• Ein PM/Betriebsleiter in einer kleinen Firma ohne Programmierer baute im letzten Jahr 12 interne Tools und lernte Entwicklungsgrundlagen in erstaunlichem Tempo
• Ein nichttechnischer Mitgründer kann funktionale Prototypen erzeugen, aber für den Weg zur Produktionsreife braucht es weiterhin Ingenieure — Pair Programming ist produktiver als Designdokumente
• Für das Debugging von mit MS Copilot erzeugtem ESRI-Arcade-Code eines nichttechnischen Managers waren 3 Stunden Pairing nötig — die Rolle eines „KI-Debugging-Experten“ entwickelt sich zu einer neuen abrechenbaren Tätigkeit

Unterschiede je nach Domäne

• Web-/API-Entwicklung: Note A, über den gesamten Stack hinweg effektiv — von Architektur bis zum Debugging von Paketkompatibilität
• Unity-/Game-Entwicklung: Note C-, da Szenengraphen, Komponentenmodelle und hardwareabhängiges Verhalten nicht verstanden werden
• Medizinische Bildgebung: Scheitert an fehlendem Fachwissen; Vorschläge zur Performance-Optimierung brachten auf echten Daten keinerlei Verbesserung
• Rust-Anwendungen: In Greenfield-Python- oder Webprojekten effektiv, aber bei Rust-Apps unter 100K LOC sind agentische Workflows unproduktiv
• Signalverarbeitung, Embedded, HPC: Hohe Halluzinationsrate; bei Arbeit mit externen, undokumentierten APIs praktisch nutzlos
• C++-Graphalgorithmen: Ergebnisse sind extrem nichtlinear — entweder sofort richtig oder komplett daneben, ohne Mittelweg

Branchenausblick und Sorgen

• Prognose: Innerhalb von 5–7 Jahren könnte die KI-Blindheit auf CEO-/CFO-Ebene zu ernstem Talentmangel und einer Verdreifachung der Gehälter führen
• Sorge, dass die mittlere Ebene ausgehöhlt wird und am Ende nur wenige Seniors übrig bleiben, die Richtung vorgeben, koordinieren und ausführen
• KI tritt womöglich in eine Phase rekursiver Selbstverbesserung ein; wie weit das in sechs Monaten geht, ist kaum absehbar
• Ein MIT-Paper zeigte Grenzen bei der Skalierung der Modellbreite (width) sowie Probleme durch erschöpfte Trainingsdaten und sinkende Qualität synthetischer Daten
• „Entweder verlieren alle ihre Jobs, oder ein großer Markteinbruch steht bevor, oder beides“ — eine faszinierende, aber beunruhigende Zeit
• Im Freelance-Markt spüren Freelancer mit langfristigen Kundenbeziehungen bislang keine Verlangsamung, während kleine Einmalaufträge eher durch KI ersetzt werden könnten

Die bewusste Entscheidung, KI nicht zu verwenden

• Schon vor LLMs gab es Automatisierung durch Kollegen, doch KI fühlte sich an wie die Betreuung eines dummen Juniors — das nahm den Reiz
• „Eine Falle, die kein einziges Problem löst und nur neue schafft“ — daher ein explizites Verbot von KI in der eigenen Arbeit
• In der Robotik mit C++ und Python liefern KI-Coding-Versuche nur halb funktionierenden Müll, und das Beschreiben per natürlicher Sprache ist mühsam
• Das direkte Schreiben von Code als Prozess, in dem man über Architektur und die technische Zukunft nachdenkt, hat einen Wert, der sich niemals delegieren lässt

[GN⁺]

Hacker-News-Meinungen

• Das Schwierigste ist momentan, dass Manager mit Claude 50-seitige Designdokumente oder PRDs erstellen und sie mit „Bitte prüfen“ herumschicken
  Niemand liest sie, nicht einmal die Verfasser verstehen sie selbst. Manche Mitarbeitende erzeugen endlose Slide-Decks und weichen Fragen dann aus
  Sogar Leute, die lange nicht mehr programmiert haben, schlagen dank AI wieder Code vor, oft mit seltsamen Ideen
  Ich schreibe Produktionscode selbst von Hand und nutze AI nur für Bug-Reviews. Höchstens einfache Skripte für Lasttests überlasse ich der AI

  • Früher brauchte man 30 Minuten, um ein DB-Performanceproblem zu lösen, heute wird daraus ein 37-seitiges Dokument. Mit Erklärung, Plan und Risikoanalyse sieht es schick aus, ist aber Zeitverschwendung
  • Ich habe wegen genau dieses Problems auch gekündigt. Mein Manager hat wohl das kostenlose ChatGPT benutzt, und die Dokumente waren unverständlich lange Texte, bei denen ich jedes Mal verzweifelt bin, wenn ich sie prüfen sollte
  • Wenn mir jemand ein offensichtlich von AI geschriebenes Dokument hinwirft, lasse ich es von AI zusammenfassen. Oder ich gehe direkt hin und verlange eine Erklärung
  • Meiner Erfahrung nach sind LLMs okay für Code, den ich später nicht selbst anfassen muss, aber beim Design sind sie miserabel
  • Bei uns erzeugen Manager mit LLMs auch automatisch Jira-Tickets, in denen absurde Implementierungsdetails stehen, die Juniors verwirren. Am Ende räumen die Seniors hinterher auf

• Es liegt auch an der Teamkultur, aber wegen AI ist die Arbeit wirklich langweilig und anstrengend geworden
  Ich arbeitete an einem großen Feature, und Kolleginnen und Kollegen haben meinen alten Code in Claude geworfen und ihn dann als „fertige Version“ zurückgebracht
  Das Ergebnis verfehlte die Business-Anforderungen und war voller Bugs. Die Absicht, meinen Code zu verbessern, war gut, aber die Haltung „Claude wird das schon fertig machen“ war beleidigend

  • Gründer verfallen derzeit einer Produktivitätsobsession. Sie wollen alles automatisieren, wissen aber oft nicht einmal, warum
    Jetzt hat man nicht einmal mehr die Freiheit zu sagen „Ich weiß es nicht“, weil mit einer Zeile Prompt angeblich sofort eine Antwort kommt und Backend-Entwickler plötzlich auch noch Frontend übernehmen sollen
  • Das klingt nicht nach einem AI-Problem, sondern nach einem Problem der Teamstruktur. Warum übernehmen Kolleginnen und Kollegen deine Verantwortung? Was macht der Manager?
  • Wenn jemand mit altem Code arbeiten will, muss man einfach sagen: „Nimm den aktuellen Code“

• Im Unternehmen hat sich die Arbeit dank AI in endlose Aufräumarbeit verwandelt
  Wenn erfahrenere Entwickler mir von AI erzeugten Code übergeben, muss ich mich damit abmühen, ihn aufzuräumen
  Zum Beispiel sollte ich ein von einem Team gebautes Feature in die Haupt-Codebasis integrieren, aber das API-Design passte überhaupt nicht und es gab Berge unnötigen Codes
  Am Ende wurde über eine Woche lang refaktoriert, was alles verzögerte, und ich wirkte dadurch sogar langsamer
  Bei privaten Projekten macht es mit AI dagegen Spaß, schnell zu experimentieren und zu lernen
  Im Unternehmen sehe ich aber eine Zukunft, in der Mid-Level-Entwickler verschwinden. Es bleiben nur Leads und Juniors, und die Ebene dazwischen wird immer dünner

  • Wenn man in so einer Situation still alles nur aufräumt, wird man Teil des Problems. Die Verantwortung für die Qualität von AI-Code liegt weiterhin bei der Person, die ihn eingereicht hat
  • Für solche Aufgaben schicke ich einfach den Link „code proven to work”. Menschen mit ungeprüftem AI-Code zu belasten ist unprofessionell
  • Die Prüfung des API-Designs sollte automatisch durch CI blockiert werden. Wenn es nicht besteht, darf der PR nicht gemergt werden
  • Wenn ich kaputten Code bekomme, frage ich einfach zurück: „Das funktioniert nicht, soll das neu gemacht werden?“
  • Typisch für AI sind unnötige Fehlerbehandlung oder redundanter Parsing-Code. Das muss am Ende ohnehin ein Mensch aufräumen
  • Diese Aufräumarbeit ist die härteste Arbeit überhaupt. Man behebt strukturelle Mängel und bekommt dafür trotzdem keine Anerkennung

• Ich nutze AI überhaupt nicht. Ich kenne meinen Stil der Faulheit gut genug und weiß, dass meine Fähigkeiten abbauen würden, wenn ich damit anfange
  Ein Kollege hat das schon bemerkt und die Codegenerierung wieder sein gelassen, sagt aber, es fühle sich wegen der Bequemlichkeit wie eine Sucht an
  Ein anderer Kollege hat aufgehört, weil er AI-Code für ungeeignet zur Wartung hält. Stattdessen nutzt er sie nur noch für Fragen
  Bei einem Junior haben sich die Fähigkeiten dagegen tatsächlich verschlechtert. Die Struktur des von AI geschriebenen Codes ist unverkennbar

  • Ich lerne mit ChatGPT Pro auch Mathematik, würde es fürs Programmieren aber nie benutzen. Sonst verliert man zwangsläufig sein Coding-Gefühl
    Wenn es dringend ist, nutze ich es höchstens kurz als API-Referenz
  • Der Abbau der Fähigkeit, Code von Hand zu schreiben, ist real. Es ist wie Google Maps statt einer Papierkarte zu benutzen
    Aber die Behauptung, man könne AI-generierten Code nicht warten, leuchtet mir logisch nicht ein. Wenn er einem nicht gefällt, generiert man ihn eben neu
    Ich habe tatsächlich schon Fälle gesehen, in denen AI ein komplettes Framework neu geschrieben hat
  • Ich mochte es anfangs auch nicht, aber inzwischen kann ich ohne AI nicht mehr leben. Ich bin fünfmal schneller, verliere aber gelegentlich den Kontext und vergeude dann eine ganze Woche
  • Ich diskutiere mit AI über Ideen oder Tests, delegiere ihr aber nichts ohne Verständnis
    Der Wert eines Engineers liegt im Verstehen. Automatisierung ohne Verständnis ist ein Abbau von Humankapital

• Ich bin Engineer bei Amazon und nutze intern das Kiro-Harness und Opus 4.6
  Meine Produktivität ist im Unternehmen um das 2- bis 4-Fache gestiegen, bei Side Projects sogar um mehr als das 10-Fache
  Früher musste ich Überstunden machen, heute liefere ich auch mit einem 9-to-5-Tag mehr Features ab
  AI ist nicht nur für einfaches Coden nützlich, sondern auch für Deployment-Automatisierung, Datenanalyse und Debugging
  Zum Beispiel übernimmt die AI nach einer Codeänderung die Schleife aus Deployment in die Gamma-Umgebung und Verifikation über CloudWatch-Logs
  Dadurch habe ich in zwei Wochen Funktionen für einen ganzen Monat fertiggestellt. Dass SWE zuerst automatisiert würde, kann ich nicht nachvollziehen
  LLMs haben Grenzen, aber schon auf dem jetzigen Niveau verändern sie die Spielregeln des Software Engineerings

  • Kürzlich gab es das Gerücht, dass Juniors keinen AI-Code mehr pushen dürfen. Ich frage mich, ob das stimmt
  • Ich habe AI auch beim Deployment eines Brückendienstes zwischen Linear und Coder.com genutzt, und die Automatisierung von kubectl und MCP-Integration war eine völlig neue Welt
  • Mich würde interessieren, warum du einen Jobwechsel vorbereitest und was du in deiner aktuellen Arbeit nicht machen kannst
  • Sehe ich auch so. Früher habe ich Zeit damit verschwendet, nutzlose Technologien zu lernen, aber dank AI sind Umgebungs-Setup und Lerngeschwindigkeit viel besser geworden
    Sorgen macht mir nur die Explosion an schlechtem Code, den AI produziert
  • Wenn du „Amazon Engineer“ sagst: Ist das womöglich eine offizielle Aussage?

• Ich arbeite bei FAANG. Im Job ist AI fast keine Hilfe
  Nur zum Zusammenfassen von Designdokumenten oder für die Codesuche ist sie brauchbar. Einen wirklich funktionierenden Commit habe ich noch nie bekommen
  Auch in meinem Umfeld sehe ich niemanden, der sie erfolgreich einsetzt.
  Bei privaten Projekten ist sie für kleine neue Aufgaben dagegen ganz klar 10-mal schneller
  Wahrscheinlich liegt das daran, dass die Codebasis im Unternehmen zu groß und komplex ist

  • Bei mir ist es genau andersherum: Mit AI habe ich von Terraform bis zu Big-Data-Projekten über 10.000 Zeilen geschrieben
    95 % funktionieren perfekt, und ich kann sogar vorhersagen, wo Probleme auftreten werden
    Als ein Kollege um Datensampling bat, konnte ich es sofort lösen
    Was früher Stunden dauerte, erledige ich heute während eines Gesprächs
    Was ich früher nicht konnte, kann ich jetzt; was schwer war, ist leicht geworden; was leicht war, geht jetzt schneller
  • Für kurze Skripte finde ich sie auch nützlich, aber in unbekannten Bereichen macht sie mich eher langsamer
  • Ich bin auch bei FAANG, und unsere internen AI-Tools haben sich zuletzt stark verbessert
    Prototyping ist schneller geworden, und ein LLM hat mich sogar schon auf Designfehler in einer API hingewiesen
    Zu schnelle Codegenerierung überholt allerdings das Review-Tempo, deshalb ist es entscheidend, in kleinen Einheiten zu generieren
    Auch beim Anpassen von Tests oder beim Nachverfolgen externer Build-Fehler hilft es enorm
    So viel Spaß an der Arbeit hatte ich lange nicht mehr, gleichzeitig ist die Angst um den Arbeitsplatz groß
  • FAANG-Codebasen enthalten viele geschlossene interne Frameworks, also Bereiche, auf denen LLMs nicht trainiert wurden
    Deshalb sind ungenaue Ergebnisse dort ganz normal
  • Stimme ich zu. Je kleiner, desto besser funktioniert es. Für großen Code taugt es nicht

• Ich arbeite in einem großen Tech-Unternehmen, und die Codebasis ist riesig und komplex
  Anfangs war ich AI gegenüber ablehnend, aber inzwischen hilft sie mir sehr bei Code-Navigation und Strukturverständnis
  Analysen, die früher Tage dauerten, übernimmt jetzt AI
  Codegenerierung nutze ich vor allem, um Boilerplate zu reduzieren. Die Qualität ist zwar niedrig, aber immer noch etwas schneller, als alles von Hand zu schreiben
  Bei privaten Projekten merke ich keinen großen Unterschied, aber ich rede gern mit ChatGPT, um meine Gedanken zu ordnen

  • Diese Nutzung als Verständnishilfe ist wahrscheinlich am sichersten und effektivsten
    Letztlich ist entscheidend, dass der Mensch den Kontext versteht und alles verifiziert

• Ich arbeite seit Langem freiberuflich, und AI hilft bei der Produktivität fast gar nicht
  Wenn ich Code prüfe, den ich an Kunden liefern soll, finde ich immer unnötige Komplexität, Performanceprobleme und Wartungsrisiken
  Für einfache Automatisierungsaufgaben ist sie natürlich brauchbar, insgesamt macht sie aber eher mehr Arbeit

  • Für Freelancer bedeutet AI am Ende sogar noch mehr Arbeit
    Wenn man sagt, man sei schnell fertig geworden, wird die Qualität angezweifelt, und die Kosten für die Modelle trägt man auch noch selbst
    Am Ende verbringt man den ganzen Tag im Kampf mit dem Terminal. Immerhin entstehen viele hübsche TUIs
  • Es wirkt, als würde der Freelancer-Markt selbst durch AI schrumpfen. Einmalige Aufträge verschwinden nach und nach

• Für mich bringt AI mehr Verlust als Gewinn
  Für Code-Reviews oder Suche ist sie gut, aber beim eigentlichen Coden muss ich alles immer neu schreiben
  Das Ergebnis wirkt wie Code von Studierenden, die nur irgendwie die Prüfung bestehen wollen
  Ich denke zwar jedes Mal „Vielleicht klappt es diesmal“, aber am Ende ist es Zeitverschwendung. Es fühlt sich ähnlich an wie damals beim Hype um JavaScript-Frameworks

  • Geht mir genauso. Bei der Fehlersuche oder beim Codeverständnis ist AI großartig, aber sie funktioniert nur dann gut, wenn Codequalität keine Rolle spielt
    Die eigentliche Frage ist, ob Codequalität überhaupt wirklich wichtig ist
    Wenn alles ausreichend modularisiert ist, kann man ein schlechtes Modul einfach neu generieren
    Genau das macht mir noch mehr Angst. Vielleicht werden wir tatsächlich bald ersetzt

• Überraschend, dass die Stimmung auf HN so pessimistisch gegenüber AI ist
  Ich bin seit zehn Jahren Engineer, und die Hälfte von dem auf Twitter ist wirklich wahr
  Unser Team hält zu dritt eine App mit 100.000 DAU am Laufen. Früher hätte man dafür zehn Leute gebraucht
  Es gibt keine Bug-Liste, und die Codequalität ist auch nicht schlechter als bei handgeschriebenem Code
  Die Refactoring-Frequenz ist sogar gestiegen, und das Tempo ist explosiv. Ich bin wirklich zufrieden

  • Ich verstehe, warum HN negativ ist. Aber AI ist beim Verstehen von Code dem Menschen bereits überlegen
    Das Risiko besteht nur darin, dass im Moment immer weiter Code hinzugefügt wird und die Komplexität explodiert
    Trotzdem kann in sechs Monaten alles völlig anders aussehen. Es ist gerade spannend und zugleich beängstigend
  • Die meisten Entwickler stecken noch in Angst und Verwirrung
    Aber je kleiner das Team, desto eher erzielt es mit AI explosive Produktivität
  • 100k DAU? Dazu würde ich gern einen Link sehen
  • Bei dieser Größenordnung könnten bald Massen von Klon-Apps auftauchen und den Großteil der Nutzer abziehen