Vibe Coding und Agentic Engineering rücken stärker zusammen, als mir lieb ist
(simonwillison.net)- Vibe Coding und Agentic Engineering wurden ursprünglich über Standards für Code-Review und Verantwortlichkeit voneinander abgegrenzt, doch mit der steigenden Zuverlässigkeit von Coding-Agenten verschwimmt diese Grenze in echter Produktionsarbeit zunehmend
- Vibe Coding ist ein Ansatz, bei dem man den Code kaum anschaut und das Ergebnis akzeptiert, wenn es den gewünschten Output liefert. Für persönliche Tools kann das nützlich sein, bei Software, von der die Daten und Nutzererfahrung anderer Menschen abhängen, wirkt es jedoch unverantwortlich
- Agenten wie Claude Code erledigen JSON-API-Endpunkte, SQL-Abfragen, Tests und Dokumentation inzwischen wiederholt zuverlässig, sodass es vorkommt, dass nicht mehr jede erzeugte Codezeile geprüft wird. Das schafft ein Risiko: Vertrauen in etwas ohne Ruf oder Verantwortung, anders als bei menschlichen Teams
- Inzwischen lässt sich in 30 Minuten ein Repository mit 100 Commits, guter README und vollständigen Tests erzeugen, sodass sich Qualität anhand des äußeren Eindrucks nur noch schwer beurteilen lässt. Der eigentliche Maßstab ist, ob jemand diese Software tatsächlich dauerhaft verwendet hat
- AI-Tools ersetzen die Erfahrung von Software Engineers nicht, sondern verstärken sie. Wenn die Codeproduktion von 200 auf 2.000 Zeilen pro Tag steigt, wandert der Engpass zu Design, Validierung, Betrieb und realer Nutzung
Die Grenze zwischen Vibe Coding und Agentic Engineering
- Im Heavybit High Leverage Podcast Ep. #9 über AI-Coding-Tools entstand die Sicht, dass Vibe Coding und Agentic Engineering in der Praxis stärker aufeinander zulaufen
- Zuvor wurden in Not all AI-assisted programming is vibe coding (but vibe coding rocks) Vibe Coding und verantwortungsbewusste AI-gestützte Programmierung klar voneinander getrennt; Letzteres wurde später als Agentic Engineering bezeichnet
- Vibe Coding bezeichnet einen Ansatz, bei dem der Code kaum angesehen wird: Ein Nutzer, der womöglich nicht einmal programmieren kann, fordert ein gewünschtes Ergebnis an, akzeptiert es, wenn es funktioniert, und fordert andernfalls eine neue Version an
- Bei persönlichen Tools, bei denen Bugs nur einem selbst schaden, kann Vibe Coding nützlich sein. Wenn man jedoch Software baut, von der die Daten und Nutzererfahrung anderer Menschen abhängen, wirkt dieser Ansatz unverantwortlich
- Agentic Engineering ist ein Ansatz, bei dem professionelle Software Engineers AI-Tools bis an die Grenze ihrer Fähigkeiten nutzen und dabei Einschränkungen wie Sicherheit, Wartbarkeit, Betrieb und Performance verstehen
- Ziel ist nicht, schneller Ergebnisse geringerer Qualität zu erzeugen, sondern höherwertige Produktionssysteme schneller zu bauen
- Das Problem ist, dass Coding-Agenten immer verlässlicher werden und man deshalb selbst bei produktionsreifen Aufgaben nicht mehr jede erzeugte Codezeile überprüft
Vertrauen, das dazu verführt, Code-Reviews auszulassen
- Wenn man Claude Code bittet, einen JSON-API-Endpunkt zu erstellen, eine SQL-Abfrage auszuführen und das Ergebnis als JSON auszugeben, entsteht das Vertrauen, dass es das korrekt erledigt
- Auch wenn man automatische Tests und Dokumentation hinzufügen lässt, erwartet man oft ein brauchbares Ergebnis, und dabei kommt es vor, dass der eigentliche Code gar nicht geprüft wird
- Wenn der Code nicht überprüft wurde, bleibt ein schlechtes Gefühl, ob es verantwortbar ist, ihn in Produktion zu verwenden
- Das lässt sich ähnlich betrachten wie die Nutzung von Software anderer Teams, wenn man als Engineering Manager in einer großen Organisation arbeitet
- Wenn ein anderes Team einen Bildskalierungsdienst bereitstellt, liest man in der Regel nicht jede Codezeile, die dieses Team geschrieben hat
- Man schaut in die Dokumentation, probiert das Skalieren von Bildern aus und veröffentlicht dann die eigene Funktion
- Erst wenn Bugs oder Performance-Probleme sichtbar werden, sieht man möglicherweise ins Git-Repository
- In den meisten Fällen behandelt man diesen Dienst als halbierte Blackbox
- Agenten werden zunehmend auf ähnliche Weise behandelt, aber anders als menschliche Teams hat Claude Code keinen professionellen Ruf und keine Verantwortlichkeit
- Menschliche Teams können sich durch gute Software in der Vergangenheit einen Ruf erarbeiten und stehen unter dem Druck, dass schlechte Ergebnisse ihrem professionellen Ansehen schaden
- Claude Code kann einen solchen Ruf nicht haben, baut aber Vertrauen auf, indem es wiederholt einfache Aufgaben korrekt in einem Stil erledigt, der Vorlieben für solche Arbeiten entgegenkommt
- Darin steckt ein Element der Normalisierung von Abweichungen
- Jedes Mal, wenn das Modell auch ohne enge Überwachung korrekten Code schreibt, wächst das Vertrauen
- Gleichzeitig steigt das Risiko, später im falschen Moment zu selbstsicher zu sein und dadurch Schaden zu erleiden
Die Bewertung von Software wird schwieriger
- Früher war es leicht, bei einem GitHub-Repository mit 100 Commits, guter README und automatisierten Tests anzunehmen, dass viel Sorgfalt und Aufmerksamkeit in das Projekt geflossen sind
- Heute kann man in 30 Minuten ein Git-Repository mit 100 Commits, einer schönen README und Tests erstellen, die jede Codezeile abdecken
- Solche Repositories können äußerlich identisch mit Projekten wirken, in die über lange Zeit echte Sorgfalt und Aufmerksamkeit geflossen sind
- Vielleicht sind sie tatsächlich genauso gut, aber von außen lässt sich das nur schwer erkennen, und das gleiche Problem entsteht sogar bei den eigenen Projekten
- Ein noch wichtigeres Kriterium als die Qualität von Tests und Dokumentation ist, ob jemand diese Software tatsächlich verwendet hat
- Selbst ein vibe-coded Ergebnis ist deutlich wertvoller, wenn die Person, die es erstellt hat, es in den vergangenen zwei Wochen täglich genutzt hat, als ein Ergebnis, das fast nie ausgeführt wurde und nur ausgespuckt wurde
Der Engpass verlagert sich vom Schreiben von Code auf andere Phasen
- Wenn man statt 200 nun 2.000 Zeilen Code pro Tag erzeugen kann, beginnen andere Teile des Softwareentwicklungs-Lebenszyklus zu brechen
- Der bisherige Softwareentwicklungs-Lebenszyklus war darauf ausgelegt, dass pro Tag nur einige hundert Zeilen Code entstehen
- Diese Verschiebung der Engpässe betrifft nicht nur nachgelagerte, sondern auch vorgelagerte Phasen
- In Jenny Wens Vortrag wird darauf hingewiesen, dass der bisherige Designprozess von der Annahme ausgeht: „Das Design muss von Anfang an richtig sein“
- Denn wenn man es an Engineers übergibt und diese dann drei Monate lang das Falsche bauen, ist das katastrophal
- Weil Design zu teurer Umsetzungsarbeit führt, gibt es umfangreiche Designprozesse
- Wenn der Build aber nicht drei Monate dauert, sinken die Kosten von Fehlern drastisch, und der Designprozess kann wesentlich mehr Risiko tolerieren
Warum ich trotzdem nicht glaube, dass die Karriere von Software Engineers vorbei ist
- Gespräche mit Agenten wirken für die meisten Menschen wie eine schwer verständliche „moon language“
- Einer der Gründe, warum die Karriere von Software Engineers nicht vorbei ist, obwohl Computer nun selbst Code schreiben können, ist, dass diese Tools bestehende Erfahrung verstärken
- Wer weiß, was er oder sie tut, kann sich mit AI-Tools deutlich schneller bewegen
- Je mehr man AI-Tools nutzt, desto häufiger bestätigt sich, wie schwierig Softwareentwicklung an sich ist
- Selbst mit allen verfügbaren AI-Tools bleibt das, was man erreichen will, schwierig
- Matthew Yglesias schrieb in einem Tweet: „Nach fünf Monaten ist mir klar geworden, dass ich nicht vibecode machen will. Ich möchte, dass professionell gemanagte Softwarefirmen AI-Coding-Assistenten nutzen, um mehr, bessere und günstigere Softwareprodukte zu bauen und sie mir gegen Geld zu verkaufen“, und dem wird zugestimmt
- Zusammengefasst wird das mit dem Vergleich, dass man zwar vielleicht die Hausinstallation selbst reparieren könnte, wenn man genug YouTube-Videos über Sanitärarbeiten gesehen hat, aber trotzdem lieber einen Installateur beauftragt
Die Risiken von SaaS und Eigenentwicklung
- Auch bei der Gefahr, dass Unternehmen statt SaaS eigene Lösungen bauen könnten, gilt weiterhin derselbe Maßstab: Bevorzugt wird Software, deren tatsächliche Nutzung sie validiert hat
- Bei persönlichen Projekten werden Tools bevorzugt, die ihre Ersteller zumindest einige Wochen lang selbst genutzt haben
- Übertragen auf Enterprise-Software lautet der Maßstab: Ein CRM möchte man nicht einführen, wenn es nicht bereits von mindestens zwei anderen großen Unternehmen sechs Monate lang erfolgreich genutzt wurde
- Bevor man Risiken eingeht, will man Lösungen, deren Funktionsfähigkeit in der Praxis bewiesen ist
1 Kommentare
Hacker-News-Kommentare
Vibe Coding und LLMs haben nicht erst disziplinlose Engineering-Organisationen oder -Ingenieure geschaffen, sondern nur bestehende Probleme sichtbar gemacht und beschleunigt
Viele Ingenieure haben lockere oder gar keine Standards und Praktiken fürs Schreiben von Code, und viele Teams haben nur schwache Kriterien dafür, Code in Produktionsumgebungen auszurollen
Das ist kein neues Phänomen, sondern bedeutet nur, dass Einzelpersonen und Teams, die nie Standards über den Softwareentwicklungslebenszyklus hinweg eingehalten haben, jetzt viel mehr Code erzeugen und Ideen leichter konkretisieren können
Ich habe noch nie erlebt, dass ein Kollege allein dadurch zu einem guten Ingenieur wurde, dass er schnell Code schreibt
Die besten Ingenieure, die ich kenne, sind Leute, die auf Basis von Erfahrung und sorgfältigem Urteilsvermögen wichtige Einsichten mit dem Team geteilt und so die Richtung des Systems positiv geprägt haben
„Claude, bau mir ein System. Aber bau es gut. Danke!“
Früher hat man, sobald die Codebasis der Feature-Entwicklung Widerstand entgegengesetzt hat, den aktuellen Engpass beseitigt und den Rest bis zum nächsten Widerstandspunkt aufgeschoben
Man hat also beim Bauen von Features ein Stück weit refaktoriert, aber Frontier-Modelle schieben den Moment, „in dem es zum Problem wird“, nach hinten
Weil sie einen gewissen Haufen bestehenden Codes verarbeiten können, zeigt sich das eher darin, dass LLMs mehr Regressionen verursachen oder Anforderungen häufiger verfehlen, während es sich für Menschen weniger so anfühlt, als würde die Arbeit schwieriger
Irgendwann ist dann aber so viel kaputt, dass man es reparieren muss, und die gesamte Codebasis ist zu einer fraktalen Schichtstruktur aus Entscheidungen geworden, die ich nie selbst getroffen habe, sodass sie schwer zu entwirren ist
Weil man den Code nicht mehr direkt editiert, verschwindet auch die körperlich spürbare Reaktion „Wenn ich das auf diese Weise ergänze, entsteht viel Spannung“, was es zusätzlich erschwert, den richtigen Ansatz für Refactoring zu finden
Code lässt sich jederzeit refaktorieren, und man kann Agenten dazu zwingen, kleine, modularisierte Teile und Dateien zu schreiben
Gute Engineering-Arbeit bleibt gute Engineering-Arbeit, egal ob ein Agent oder ein Mensch sie geschrieben hat
Im Moment muss der Mensch zumindest die Architektur verstehen und führen, während Agenten sehr gut bei Aufklärung und Vorschlägen helfen können
Falls ich nicht die Fortschritte der letzten Wochen verpasst habe, wirkt es eher so, als sei AI nicht verlässlicher geworden, sondern als seien die Fehler subtiler geworden
Wenn Code nicht kompiliert, ist das leicht zu finden, und wenn er kompiliert, aber nicht funktioniert, ist es ebenfalls noch einigermaßen auffindbar
Wenn er aber kompiliert und funktioniert, jedoch in bestimmten Edge Cases falsch ist, Sicherheitslücken enthält oder technische Schulden und fragwürdige Architekturentscheidungen mit sich bringt, ist das viel schwerer zu entdecken, und der Review-Aufwand sinkt überhaupt nicht
Eher im Gegenteil: Plausibel wirkender Code ist beim Review mental belastender als offensichtlich schlechter Code
Man lässt sie zuerst mehrere Tests schreiben, prüft dann, ob der Code dazu passt, und weist den Agenten an, den Code korrekt zu organisieren
Aber im Moment ist der Druck von oben so groß, dass überall eine breite Einführung erwartet wird, und wenn man sich dagegenstellt, ist das so entmutigend und karriereeinschränkend, dass es zermürbt
Weist man auf ein offensichtliches Problem hin, kommen sofort genauso viele Umgehungslösungen, in denen dann bald wieder andere Probleme auftauchen, die endlos neue Lösungen hervorbringen
Irgendwann fühlt sich das alles wie Arbeit für die Maschine selbst an
In vielen Firmen scheint das eigentliche Ziel verschwommen zu sein, und übrig bleibt nur noch das LLM selbst
Ich weiß nicht, ob denjenigen, die die Zukunft ihres Unternehmens auf diese Vision setzen und sie umsetzen, ein sanfter Ausstieg garantiert wird, um den Folgen zu entgehen, oder ob Rationalität als Ganzes über Bord geworfen wird
Mit soliden Engineering-Prinzipien kann man die Probleme vielleicht abmildern, aber ich frage mich, welche reale Effizienz in Bezug auf kognitive Last, Entwicklerzeit, Geld und endliche Ressourcen tatsächlich entsteht
Bei der Formulierung „Was geht kaputt, wenn man statt 200 Zeilen pro Tag 2.000 schreiben kann?“ ist es beschämend, Codezeilen als Maß für Engineering-Output zu verwenden
200 Zeilen zu reviewen und 2.000 Zeilen zu reviewen ist ein völlig anderer Arbeitsaufwand
Als ich dasselbe Programm noch einmal in meinem Kopf neu aufgebaut und ChatGPT nur wie Suche und Autovervollständigung genutzt habe, kam ich mit 1.500 Zeilen zum gleichen Ergebnis
Der Unterschied im Aufwand war ehrlich gesagt auch nicht riesig, wobei der von Hand gebaute Ansatz den Vorteil gehabt haben könnte, dass ich durch die zuerst mit Vibe Coding erstellte Version schon wusste, was ich eigentlich bauen wollte
Codezeilen als Eingangsgröße für Software-Reviews zu verwenden, ergibt Sinn
Denn man muss buchstäblich jede Zeile lesen
Nur als alleinige Metrik für Entwicklerproduktivität sind sie miserabel, und genau dann entstehen Probleme
Trotzdem sind sie nützlich, weil sie fast die einzige Kennzahl sind, die über verschiedene Firmen, Teams, Sprachen und Anwendungskontexte hinweg sofort intuitiv verständlich und vergleichbar ist
Selbst wenn dasselbe Team am selben Produkt arbeitet, kann eine Änderung von 1.000 Zeilen schnell erledigt sein, während ein Bugfix von 1 Zeile mehrere Tage Debugging brauchen kann
Deshalb sind PRs, Features oder Story Points außerhalb ihres Kontexts schwer vergleichbar, und wenn es eine branchenweit taugliche Standardmetrik für Entwicklerproduktivität gäbe, würden alle sie verwenden, aber ich halte das inhärent für schwierig
Für solche Vergleiche hilft es, wenn man davon ausgeht, dass der Kontext gleich bleibt
Wenn zum Beispiel ein Team in einem bestimmten Unternehmen gestern für ein bestimmtes Produkt mit einem bestimmten Tech-Stack und Qualitätsprozess N1 Zeilen geschrieben hat und heute mit AI N2 Zeilen, dann nähert der Unterschied zwischen N1 und N2 über die Zeit die reale Wirkung an
Auch strengere Studien zur Produktivität AI-unterstützter Entwicklung haben meist A/B-Tests verwendet, bei denen PRs derselben Gruppe vor und nach der AI-Nutzung verglichen wurden
Für mich liegt der Unterschied in der Qualität und Strenge der Pipeline
Vibe Coding bedeutet, etwas ein- oder ein paarmal auszuprobieren, das Ergebnis kurz zu prüfen und es dann zu nutzen, bis es kaputtgeht
Das eignet sich für leichte Proofs of Concept oder für risikoarme Apps für Einzelpersonen, Familie oder kleine Teams
Agentic Engineering kümmert sich um ein breiteres Spektrum an Themen wie funktionale Korrektheit, Performance, Infrastruktur, Resilienz/Verfügbarkeit, Skalierbarkeit und Wartbarkeit
Es gibt eine mehrstufige Pipeline zur Steuerung des Workflows, mit Phasen wie Projektaufnahme, Auswahl, Spezifikation, Aufteilung in Epics, Aufteilung in Stories, Coding, Dokumentation und Deployment
In jeder Phase gibt es harte Qualitätsgates wie bestandene Tests oder Performance-Kriterien sowie adversariales Review zu Geschäftswert, Vollständigkeit der Spezifikation, Eleganz des Codes und Strenge sowie Einfachheit der ubiquitären Sprache
Auch das ist ein Schieberegler
Manchmal will ich nicht für ein einzelnes Feature Interviews führen, Token verbrennen, drei Runden adversariales Review, Wertschätzung und eine detaillierte Spezifikation machen, sondern das Ticket einfach ins System werfen
Ich nutze Opus, GPT-5.5 und kleinere Modelle jeden Tag, übergebe ihnen aber nicht die gesamte Arbeit
Selbst wenn ich viel Mühe in die Definition und Verfeinerung der Spezifikation stecke, machen sie immer noch viele dumme Dinge, die ich in einem menschlichen PR-Review nicht durchgehen lassen würde
Hätte ich den Ergebnissen vertraut oder eine große Agenten-Pipeline gebaut und daraus ein falsches Gefühl von Stabilität gezogen, hätte ich sie leicht einfach in die Codebasis einfließen lassen
In zehn Jahren mag das besser sein, aber die heutigen Pipelines für Vibe Coding und Agentic Engineering wirken beide wie Variationen desselben Themas, nämlich alles vollständig an LLMs zu delegieren
Noch heute Morgen dachte ich, ich könnte Opus on Max Änderungen in einer einzelnen Datei überlassen, aber fast in jedem Turn gab es Fehler oder Auslassungen, die ich korrigieren musste
Der vorgeschlagene Code hätte meist funktioniert, war aber zu komplex und hat Teile wieder verschlechtert, die ich bereits von Hand vereinfacht hatte
Wenn sich so etwas über Tausende Agenten-Commits hinweg multipliziert, verschlechtert sich eine Codebasis schnell
Entwicklungsteams geraten in Schwierigkeiten, wenn sie ohne den richtigen Prozess aus Design, Test und Review zu bauen versuchen
Das galt schon vor agentischem Coding, aber jetzt noch mehr, und die Teams, die verstehen, wie man Agenten in diesem Prozess einsetzt, werden am erfolgreichsten sein
Habt ihr nicht auch das Gefühl, dass Coding-Agenten bei ihrem ersten Versuch der Lösung sehr nahe kommen, aber für die letzten 10 % oder 5 % enorm viel Arbeit nötig ist
Wenn man den Ansatz zur Problemlösung ändert, kann der Agent diese Lücke schließen
Vor zehn Jahren habe ich beim Programmieren alle 10 bis 15 Minuten angehalten, refaktoriert, getestet und analysiert, um sicherzugehen, dass alles perfekt ist
Denn Bugs kontaminieren sonst den gesamten nachfolgenden Code
Coding-Agenten können das nicht, sondern schleppen Bugs und falsche Architektur einfach mit sich weiter
Instinktiv möchte man den Agenten zwischendurch stoppen, aber aus verschiedenen Gründen geht das nicht
Stattdessen sucht man, weil die Kosten sehr niedrig sind, den Punkt, an dem der Agent den ersten Fehler gemacht hat, korrigiert den Prompt und löscht dann alles, statt den Code zu ändern, und lässt es von vorn neu laufen
Diese Schleife wiederholt man, bis der Prompt perfekten Code erzeugt
Manche werden einwenden, dass der Mensch dabei immer noch viel tun muss, aber genau das ist der Punkt
Der Mensch wird weiterhin gebraucht, und wenn man das Tool so einsetzt, ist man beim Schreiben von Code 10-mal schneller
„Etwas, das funktioniert“ bekommt man recht schnell hin, aber es dauert lange, Alternativen zu bewerten, zu verfeinern und zu testen, bis man Vertrauen hat
Der Punkt stimmt, aber niemand weiß, wo genau die Grenze liegt
Im kommenden Jahr werden vermutlich alle versuchen, sie zu finden, und deshalb hört man auch so oft, dass „GitHub neu erfunden werden muss“
In vielen Fällen lohnt es sich wirtschaftlich nicht, in die Mechanisierung gerade dieses letzten Teils zu investieren
Ich denke, die LLM-Anbieter haben von Anfang an den falschen Ansatz gewählt
Statt Arbeit zu ersetzen, hätten sie sich darauf konzentrieren sollen, Arbeit zu ergänzen, und offenbar war das eine teure Lektion
Vielleicht wäre es besser gewesen, von vorn zu beginnen, aber zu Beginn wusste ich noch nicht, wie die gewünschte Architektur überhaupt aussehen sollte
Nur weil das LLM damit kämpft, neue Features in eine bestehende Architektur einzupassen, kann man nicht einfach die gesamte laufende Codebasis wegwerfen und neu anfangen
Ein großartiger Beitrag von jemandem, der klug und bescheiden ist und ständig weiterlernt
Besonders gefallen hat mir der Satz: „Es gibt viele Gründe, warum ich keine Angst davor habe, dass Software-Engineering als Karriere endet, nur weil Computer jetzt ihren eigenen Code schreiben können. Einer davon ist, dass diese Dinge bestehende Erfahrung verstärken. Wenn man weiß, was man tut, kann man viel schneller laufen.“
Auch dieser Teil war stark: „Die Arbeit mit diesen Tools erinnert uns ständig daran, wie schwierig das ist, was wir tun. Software zu bauen ist brutal schwer. Selbst mit allen AI-Tools der Welt bleibt das, was wir hier erreichen wollen, wirklich schwer.“
Der Hinweis, dass sich auch die Upstream-Arbeit mitverändert, ist zutreffend
Vor allem Tools im Design-Bereich entwickeln sich so schnell, dass es sich offenbar nicht mehr lohnt, die Übersetzungskosten dafür, auf der Figma-Seite zu bleiben, in Kauf zu nehmen
Der beängstigende Teil ist, dass sich in der Codebasis Schichten von AI-Komplexität ansammeln und Menschen den Code irgendwann nicht mehr verstehen, sodass es teuer wird, ihn mit den neuesten Modellen zu entschlüsseln und zu ändern
Schon bald könnte Code-Wiederverwendung verschwinden, und wir könnten Geld verbrennen, indem wir das Rad immer wieder neu erfinden
Als man frühe Android-Apps gebaut hat, musste man zwingend die IDE benutzen, und um nach einem Button-Klick eine „Hello World“-Benachrichtigung anzuzeigen, musste man eine absurde Menge an Boilerplate-Code schreiben, was einen seelisch ausgesaugt hat
Sagt es mir nach: Der Großteil aller Software verbringt den größten Teil seines Lebenszyklus in der Wartungsphase
Entsprechend wird auch der Großteil des Geldes, das Software verdient, in dieser Wartungsphase erwirtschaftet
Die Branche hat das nach fast 100 Jahren immer noch nicht verstanden
Alan Kay hatte zu 100 % recht, als er sagte, die Computerrevolution habe noch nicht stattgefunden
Trotz aller heutigen Fortschritte befinden sich unsere Werkzeuge größtenteils noch in der Steinzeit
Meine große Hoffnung ist, dass AI uns bis zu dem Punkt beschleunigt, an dem sie das bestehende Paradigma so vollständig zerstört, dass es nicht mehr reparierbar ist, und wir endlich etwas Neues, Anderes und Besseres tun können
Also lasst uns dem Softwareentwicklungslebenszyklus jetzt mit AI ein Jetpack umschnallen und es einfach versuchen
Lasst uns schnell vorangehen und wirklich etwas kaputtmachen
Eine treffende Beobachtung, und sie fühlt sich auch für mich richtig an
Ich musste einen relativ einfachen Batch-Download → Konvertierung → API-Endpunkt aufsetzen und habe einen ziemlich detaillierten Prompt geschrieben, aber viele Implementierungsdetails wie die Datenquelle offengelassen
Opus 4.7 hat es zu etwa 90 % so gebaut, wie ich es gemacht hätte, und deutlich mehr Convenience-Methoden sowie Validierung in jedem Schritt eingebaut
Das war sehr gut und hat mir Luft gegeben, über schwierigere Probleme nachzudenken
Ich bin hauptsächlich Python-Entwickler, benutze aber auch andere Backend-Sprachen wie Rust oder Go regelmäßig, mit denen ich vertraut bin, wenn auch nicht auf demselben Niveau
Mit rund 13 Jahren Erfahrung, die stark auf eine Sprache konzentriert war, plus formaler Ausbildung in anderen Sprachen ist es viel leichter, LLMs anzuleiten
Die Last, Syntax, Grundbausteine, Paketmanager, Tests usw. zu lernen, ist im Vergleich zur früheren Art des Programmierens nicht groß
Vor Kurzem habe ich einem nichttechnischen Kollegen bei Reporting-Automatisierung mit Claude cowork/code geholfen
Dieser Kollege verstand die Business-Intelligence-Seite gut, hatte aber Schwierigkeiten mit der grundlegenden Ausdrucksweise, um einen
pyautogui-Wrapper per Vibe Coding zu erstellen, der RDP startet und Werte in eine MS-Access-Abstraktion über einer Lieferanten-Datenbank einträgtAls Beruf werden Entwickler wohl noch 5 bis 10 Jahre lang in Ordnung sein