Noch weiß niemand, wie man mit AI baut
(worksonmymachine.substack.com)- Derzeit ist noch keine AI-Entwicklungsmethodik etabliert; alle befinden sich im Experimentiermodus
- Im AI-Zeitalter verliert das traditionelle Expertenkonzept an Bedeutung, und alle bleiben ewige Anfänger
- Der tatsächliche Entwicklungsprozess entsteht durch improvisierte Dokumentenansammlungen und iteratives Trial-and-Error
- In der Zusammenarbeit mit AI entstehen mit kurzer konzentrierter Zeit und minimalem Input gewaltige Ergebnisse
- Auch ein eigenes Dokumentensystem ist nur vorübergehend; letztlich setzen alle ihre einmaligen Experimente fort
The Great Experiment Nobody's Running the Same Way
- In der AI-Entwicklung kennt derzeit niemand einen festgelegten Weg
- Es ist ein Umfeld, in dem angesammelte Expertise nach Malcolm Gladwells 10.000-Stunden-Theorie ihre Wirkung verliert
- Die Entwicklung von AI-Tools verläuft so schnell, dass sich kaum Routine aufbauen lässt
- Selbst AI Pair Programming hat eine Erfahrungstiefe von unter zwei Jahren; alle sind ständig Anfänger
My Current Experiment (Subject to Change)
- Vor Beginn der Arbeit gibt es vier zentrale Dokumente, auf die Bezug genommen wird
pair_programming.mdproject_plan_{some extension}.mdtechnical_considerations.mdmcp-browser-architecture.md
- Auch dieses Dokumentensystem wurde nicht von Anfang an entworfen, sondern ist spontan gewachsen
- Anfangs begann alles mit einem Architektur-Dokument; durch wiederkehrende Probleme und Schwierigkeiten bei der Informationsweitergabe wuchs es nach und nach auf vier Dokumente an
- Die vier Dokumente wurden nicht als optimales Ergebnis festgelegt, sondern weil es sich irgendwann so anfühlte, als müsse nichts mehr hinzugefügt werden
- Manchmal fühlt es sich an, als würde man sich selbst vorspielen: „Dieses Dokument ist die Architektur“ und „Dieser Prozess ist offiziell“
- Die Software funktioniert tatsächlich, und der entscheidende Punkt ist, dass selbst solche provisorischen Systeme Ergebnisse hervorbringen
- Die Rollen der einzelnen Dokumente sind wie folgt
- Architecture Overview: Ausgehend von der README wird festgehalten, „was diese Software eigentlich zu tun scheint“
- Technical Considerations: Wiederkehrende Frustrationen oder Probleme werden dokumentiert; jedes Mal, wenn Claude durcheinandergerät, werden Details ergänzt
- Workflow Process: Dokumentiert wiederholte Abläufe; tatsächlich ist es weder eine offizielle Regel noch ein sakrosanktes Dokument, sondern eine Sammlung von Methoden, die dieses Mal zufällig funktioniert haben
- Story Breakdown: In 15- bis 30-Minuten-Einheiten aufgeteilte Arbeits-Chunks. Da Claude schnell vergisst, dient das dazu, den Gesprächsverlauf häufig aufzufrischen
Time Dilation in the Age of AI - Zeitverzerrung im AI-Zeitalter
- Bei der jüngsten Entwicklung von Protocollie war die Zusammenarbeit mit AI eine Erfahrung, die das bisherige Zeitempfinden in der Softwareentwicklung vollständig durcheinandergebracht hat
- Das Projekt lief so ab, dass Claude mit einer bestimmten Funktion beauftragt wurde, währenddessen Zeit für das Privatleben blieb und in Abständen Kontrolle sowie kurzes Feedback gegeben wurden
- Die tatsächlich konzentrierte „Arbeitszeit“ lag bei knapp 90 Minuten pro Tag, doch die AI produzierte in der Zwischenzeit schnell tausende Zeilen Code
- Im Verhältnis zum Input kommen zu schnell und zu viele Ergebnisse heraus, sodass die bisherigen Formeln von Einsatz und Output, Aufwand und Ergebnis, Zeit und Fortschritt zusammenbrechen
- Manchmal erzeugt diese schnelle Entwicklung sogar Schuldgefühle; sie wirkt unvereinbar mit traditionellen Entwicklungsparadigmen und fühlt sich bisweilen wie Schummeln an
Phase des „Spaghetti-Experiments“
Die aktuelle AI-Entwicklungsumgebung wird als Phase des „Spaghetti-Experiments“ beschrieben
- Das heißt: Schon der Akt, Spaghetti experimentell an die Wand zu werfen, ist sinnvoll; es ist nicht wichtig, was tatsächlich kleben bleibt. Das Werfen selbst ist das Experiment
- Alle möglichen Irrwege, fehlgeschlagenen Experimente und zufällig funktionierenden Verfahren dienen als Datenpunkte eines kollektiven Experiments
- Auch das verwendete 4-Dokumente-System kann jederzeit bedeutungslos werden; wichtig ist, den experimentellen Geist beizubehalten
Neudefinition dessen, was Programmieren überhaupt ist - What Even Is Programming Anymore?
Ein Blick auf die Geschichte des Codings führt zu der Erkenntnis, dass wir mit dem Fortschritt der Abstraktion in eine Ära eingetreten sind, in der „man beschreibt, was man will, und es wird umgesetzt“
- Der Einsatz von AI entwickelt sich dabei zu etwas, das mehr ist als nur eine neue Abstraktionsschicht
- Programmieren verlangt heute nicht mehr primär Syntaxwissen, Algorithmusverständnis oder Systemdesign-Fähigkeiten, sondern neue Kompetenzen wie „konkrete Vorstellungskraft“ und „präziser Ausdruck von Absichten“
- Die „Fähigkeit, das Gewollte konsistent und klar zu beschreiben“ wird wichtiger als alles andere
Die philosophische Bedeutung des 4-Dokumente-Systems - The Four-Document System as Accidental Philosophy
- Dieses 4-Dokumente-System ist letztlich ein Protokoll von Erinnern und Vergessen, eine „Aufzeichnung von Erfahrungen, die man nicht noch einmal wiederholen möchte“
- Architecture Overview: „Was ich wissen wollen würde, wenn ich mein Gedächtnis verloren hätte“
- Technical Considerations: „Probleme, die ich nicht noch einmal wiederholen möchte“
- Workflow Process: „Muster, die ich nicht verlieren möchte“
- Story Breakdown: „Wie man Fortschritt erzielt, wenn man jedes Mal wieder von vorne beginnt“
- Alle Dokumente sind letztlich Nachrichten an mein zukünftiges Ich
- Im Kern sind sie Wegweiser an sich selbst, um Informationsverlust vorzubeugen
Unbequemes Plateau und permanenter Anfängerstatus - The Uncomfortable Plateau
Derzeit sind alle wie Junior Developer in einem dauerhaft instabilen Anfängerzustand
- Anders als klassische Juniors gibt es wegen des Tempos technologischer Veränderungen nicht einmal genug Zeit, um wirklich erfahren zu werden
- In sich ständig verändernden „Naturgesetzen“ werden Anpassungsfähigkeit und Experimentierfreude wichtiger als stabile Routine
- Diese Unsicherheit ist beängstigend, wenn man an Kontrolle festhält, kann aber auch befreiend sein, wenn man sie akzeptiert
Where This All Goes
Es ist unklar, was als Nächstes gebaut wird, welcher Prozess genutzt wird und ob die diesmal entstandenen vier Dokumente weiterhin verwendet werden
- Alle Entwickler sind gleichzeitig Experten in ihrer eigenen Routine und in neuen Situationen völlige Anfänger
- Wenn vier Tage Arbeit dem entsprechen können, was früher mehrere Monate gebraucht hätte, wird die Fähigkeit, „das Gewollte zu beschreiben“, zur entscheidenden Kompetenz
- Auch diese vier Dokumente sind weder Empfehlung noch Template, sondern nur eine Spur des kollektiven Experiments
- Dokumente, Prozesse und Methoden sind allesamt temporäre Produkte, und die Herangehensweise anderer muss nicht die eigene Antwort sein
Letztlich bauen wir alle Sandburgen (Software) bei Ebbe und wissen, dass die Welle des Fortschritts sie bald wieder fortspülen wird
Schon bald wird jemand ein 3-Dokumente-System, ein 5-Dokumente-System oder einen völlig anderen Ansatz ausprobieren, und auch dieser könnte wirksam sein
Fazit
- Entwicklung mit AI ist ein kollektives Experiment und eine fortlaufende Reihe kreativer Trial-and-Error-Prozesse
- Selbst der Prozess einer einzigen Woche kann durch das hohe Tempo schon zum Relikt der Vergangenheit werden
- Die Spuren anderer können hilfreich sein, aber wirklich wichtig ist, den eigenen Weg zu finden
Zum Schluss: Die vier verwendeten Dokumente sind derzeit auf GitHub öffentlich zugänglich
- Sie sind keinesfalls die absolute Antwort oder ein Template, sondern nur ein Beispiel für ein Experiment zu einem bestimmten Zeitpunkt
- Es wird betont, dass man sich an den Spuren anderer orientieren kann, ihnen aber nicht einfach folgen muss
- Die Entwicklung eigener Experimente und Methoden bildet das neue Entwicklungsökosystem im AI-Zeitalter
4 Kommentare
Ich wollte das am Wochenende übersetzen und posten, aber GN+ ist mir wohl zuvorgekommen 🥲
Bei dem Teil „Das Dokumentationssystem wurde auch nicht von Anfang an geplant, sondern ist das Ergebnis von improvisiertem Anwachsen“ habe ich stark mitgefühlt und musste schmunzeln. haha
Was für ein seltsamer Kommentar von irgendeinem sektiererischen Typen, der behauptet, Bang sei ein Lehrer.
Hacker-News-Kommentare
Ich kann diesem Artikel wirklich viel abgewinnen. Ich bin zufällig auf Kidlin’s Law gestoßen, also die Idee: „Wenn du ein Problem klar schriftlich formulieren kannst, ist es schon zur Hälfte gelöst.“ Im heutigen AI-Zeitalter ist das ein extrem starkes Prinzip. Da natürliche Sprache zum wichtigsten Mittel der Kommunikation mit Technologie wird, kann man das Potenzial von AI maximieren, wenn man ein Problem klar definieren kann. Auch der asynchrone Coding-Ansatz ist wirklich spannend. Ich persönlich nutze Repl.it sehr häufig, und es ist eine erstaunliche Veränderung, sich einfach auf die Problemlösung konzentrieren zu können. Wenn ich Coding-Tools benutze, fühlt es sich an, als hätte ich in Mario Kart einen Stern oder Pilz eingesammelt. Es macht riesigen Spaß, aber manchmal geht die AI auch völlig in eine seltsame Richtung, sodass Eingriffe und Entscheidungen in Echtzeit nötig sind. Früher war schon ein einzelner Stack schwer genug zu verwalten, und jetzt fühlt es sich an, als hätte man es mit unendlich vielen Stacks zu tun
Ich denke dabei oft daran, dass ich auf meinem eigenen Weg zum Software Engineer viel Zeit damit verbracht habe, überhaupt erst die Begriffe der Softwarewelt zu lernen, um beschreiben zu können, was ich machen wollte
Bei Repl.it gibt es wirklich Fälle, die an guten Tagen in ein paar Minuten gelöst sind, an anderen aber einen ganzen Nachmittag dauern. Trotzdem ist es manchmal sehr frustrierend, wenn selbst die Vorschläge unter dem Prompt-Feld nicht richtig funktionieren
Eigentlich war es schon immer schwer, ein Problem klar zu formulieren, und das ist heute nicht anders. Es ist großartig, dass es jetzt Tools gibt, die klare natürliche Sprache in Code übersetzen, aber selbst mit AGI wird sich an der Aufgabe, klare Spezifikationen zu erstellen, nichts ändern. Dank dieser Tools wird man wohl weniger Zeit damit verbringen, mit dem Coding selbst zu kämpfen, aber am Ende bleibt das wirklich klare Schreiben von Spezifikationen der schwierigste Teil
Ich mag diese neue Art des Programmierens sehr. Ich weiß nicht, wohin sie sich entwickeln wird, aber im Moment bin ich sehr zufrieden. Selbst jetzt baue ich in Zeiten, in denen ich mich sonst ausruhen würde, Code, und es fühlt sich eher wie Erholung an. Besonders gut ist das für Senior-Entwickler mit langer Berufserfahrung. Editing-Arbeit ist inzwischen meist langweilig. Wenn ich im Code ein fehlerhaftes Muster entdecke, muss ich oft vieles ändern, um eine neue Idee auszuprobieren; Dinge, für die ich früher Stack Overflow durchsucht und lange nachgedacht hätte, erledigen jetzt ein Copilot-Hinweis oder einfach Claude. Ich habe zum Beispiel eine simulierte Aktienbörse gebaut, und früher habe ich solche Arbeiten oft aufgeschoben, weil die Anbindung an echte Börsen so lästig war. Jetzt hat Claude alles gebaut, während ich HN gelesen habe. Wenn man dann noch Strategien implementieren will, werden auch die im Grunde langweiligen Wiederholungsarbeiten sofort erledigt. Tippfehler, Abhängigkeiten hinzufügen und ähnliche Dinge haben früher viel Zeit gekostet, aber das muss jetzt nicht mehr sein. Man könnte sich Sorgen machen, dass der Code so zum Chaos wird, aber ich spreche immer mit Claude und prüfe Änderungen kritisch. Erfahrung hilft dabei, und man merkt auch schnell, wenn die AI auf dem falschen Weg ist. Insofern sind diese Tools für mich genau zum richtigen Zeitpunkt in meiner Karriere gekommen. Das Problem bleibt bei Junior-Entwicklern. Es ist, als würde man direkt auf den Gipfel eines Berges springen, dessen Treppe verschwunden ist, und ich frage mich, wie sie sich noch entwickeln sollen
Ich stimme bei den Aussichten für Junior-Entwickler zu. Ich bin fast 50 und programmiere seit über 30 Jahren in vielen verschiedenen Bereichen, und auf Grundlage meiner Erfahrung weiß ich, wie man Agenten gut steuert und die Architektur stabil hält. Wenn ohne Erfahrung alles von AI fertig serviert wird, frage ich mich wirklich, wie die Nächsten wachsen sollen. Das wird die Zeit zeigen
Ich nutze Large Language Models auch gern, aber nur ständig Prompts einzugeben ist langweilig und macht mich etwas unruhig. Es fühlt sich an, als wüsste ich nicht genau, wie das Programm eigentlich funktioniert. Selbst etwas zu bauen macht wirklich Spaß, und bereits bekannte Wiederholungsarbeiten oder Aufgaben, die mich nicht interessieren, überlasse ich dem LLM. Ich habe mit Claude sogar ein terminalbasiertes Snake-Spiel gebaut, und das war wirklich faszinierend
Ich frage mich, ob du für dich selbst schon gemerkt hast, dass du zu den alten Kleinarbeiten nicht mehr zurückkannst. Seit dem Aufkommen der LLMs ist mein Wunsch größer geworden, während der Arbeit auch mal rauszugehen. Ich beneide neue Entwickler fast darum, dass sie nicht mehr wie früher 12 Stunden lang auf einen Monitor starren und Zeit verschwenden müssen, nur weil sie zwei Black Boxes nicht miteinander verbunden bekommen
Mich würde interessieren, ob ihr bei der eigentlichen Implementierung alles immer von Anfang bis Ende in einem Zug macht. Ich arbeite immer iterativ und schrittweise, schreibe und verfeinere dabei fortlaufend. Als Zeichnungsmetapher: zuerst grob den Gesamteindruck festlegen und dann immer detaillierter ausarbeiten. In jedem Schritt wird etwas klarer, was ich eigentlich will, und so erzielt man mit minimalem Aufwand maximale Wirkung. Beim Coding ist mein Stil stark auf Refactoring ausgerichtet: erst minimal funktionsfähigen Code schreiben, dann TODO-Kommentare hinterlassen und ihn iterativ verbessern
Es begeistert mich wirklich, dass diese Tools langweilige Arbeiten übernehmen, die ich schon tausendmal gemacht habe
Für mich ist AI im Kern die nächste Generation der Google-Suche: ein System, das sich auf Grundlage aller im Internet vorhandenen Informationen unterhalten kann. So wie mit der Verbreitung von Suchmaschinen in vielen Branchen Jobs verschwunden sind — Zeitungen, Telefonbücher, Enzyklopädien, Reisebüros und so weiter — wird auch AI solche Veränderungen auslösen. Aber ich glaube nicht, dass das eine so existenzielle Krise ist, wie viele denken. AI ist einfach ein Werkzeug. Clevere und kreative Menschen werden mit diesem Werkzeug viele großartige Dinge tun. Am Ende hängt alles davon ab, wie man es nutzt. Suche ist zu Chat geworden. Früher musste man selbst nachsehen, jetzt chattet man und die AI sucht es heraus — und tut noch mehr als das
Ich bin mir nicht sicher, ob die Chat-LLM-Oberfläche wirklich die optimale Form ist. Es scheint einen intelligenteren Ansatz zu brauchen
Anders als zu Googles Glanzzeiten gibt es jetzt mehr Rauschen als Signal, und die Herkunft der Daten wird undeutlicher
Es fühlt sich schon jetzt so an, als würden bei Google zuerst AI-erzeugte Müllinhalte auftauchen statt brauchbarer Informationen
Moderne Suchmaschinen geben einem nur noch Antworten, aber nicht mehr den Weg dorthin, und damit verschwindet die Rolle der Menschen, die Informationen korrekt finden und dokumentieren. Wenn das verschwindet, werden am Ende alle die Orientierung verlieren. Da AI bestehende Informationen wiederverwertet, braucht es einen Weg, die Urheber — besonders gute journalistische Autoren — finanziell zu beteiligen. Sonst besteht die Gefahr, dass die Grundlage demokratischer Gesellschaften erodiert. Die Nachrichtenbranche steckt schon seit Jahren in der Krise, und die Folgen sehen wir bereits: Misstrauen, Spaltung, Desinformation und äußere Einflussnahme. AI könnte der Branche den letzten tödlichen Schlag versetzen. Es geht nicht nur um den Ersatz von Arbeitsplätzen; der Weg, auf dem wir uns befinden, führt in eine sehr düstere Richtung
Auch außerhalb der Suche ist das klar nützlich
Ich möchte Claude Code vom Handy aus auf einer Cloud-VM laufen lassen und beim Spazierengehen oder auf dem Fahrrad weiterarbeiten, indem ich zwischendurch Feedback gebe
https://vibetunnel.sh
Das Verhältnis von Input und Output ist interessant. Normalerweise versuchen wir, die Menge des Outputs zu maximieren, aber jetzt ist es eher umgekehrt. Ich möchte weniger die maximale Menge als vielmehr, dass der Arbeitsprozess in konkrete und überprüfbare Schritte zerlegt wird. Wenn ich gemeinsam mit Cursor Anforderungen schreibe, klappt es am Anfang gut, aber dann gibt es das Problem, dass versehentlich große Mengen Code erzeugt werden, die vom Plan abweichen. Es schafft manchmal nicht einmal, nach einer Markdown-Überschrift eine Leerzeile einzufügen, oder man muss es immer wieder auf Kleinigkeiten hinweisen. Ich habe das Gefühl, ich möchte den iterativen Prozess, die Qualität und die Konsistenz stärker unter Kontrolle haben. AI zeigt ihren Wert besonders dann, wenn man offene Probleme in geschlossene, testbare Probleme verwandeln kann. Ich brauche ein Tool, das mir hilft, offene Probleme in geschlossene Probleme umzuwandeln
Wenn sich dieses Erlebnis ständig wiederholt — „Ich komme ins Büro, teste, was Claude gebaut hat, und wenn es funktioniert, committe und pushe ich“ — dann habe ich als Cybersecurity-Berater wohl eine sehr lukrative Zukunft vor mir
Ich glaube nicht, dass das Vibe Coding ist, sondern etwas völlig Neues. Ich nenne es „flex coding“. An einem Nachmittag habe ich eine ganze App gebaut und war gleichzeitig ein guter Vater. Wenn ich sage: „Baue jetzt die UI für die Serveranbindung“, dann codet Claude und ich kehre in meinen Alltag zurück. Ich mache Frühstück, spiele mit meinem Sohn, schaue fern, und dazwischen codet Claude weiter. Alle ein bis zwei Stunden schaue ich kurz rein, teste und gebe Feedback
Emotional ist das natürlich sehr attraktiv und für viele wahrscheinlich ein Traum-Lifestyle, aber ist Claudes Code wirklich zuverlässig genug? Kann man ihn einem Kunden in Rechnung stellen oder in einem Produkt verwenden, für das der eigene Ruf auf dem Spiel steht? Meine Antwort ist „nein“. In der Praxis habe ich oft Referenzfehler gesehen, Fälle, in denen bestehende Typen kopiert und nur umbenannt wurden, und Situationen, in denen es scheinbar gar keine Typfehler mehr gab. Als ich es Tests schreiben ließ, hat es manchmal keine Tests gebaut, die bei Fehlern wirklich fehlschlagen, sondern merkwürdige Tests, die am Ende nur seine eigene Verifikation bestehen. Es ist schön, wertvolle Zeit mit der Familie zu verbringen, aber ich würde niemandem empfehlen, eine von mir so gebaute App für etwas Wichtiges zu verwenden
Bei Menschen, die so arbeiten, frage ich mich, warum man ihnen überhaupt Gehalt zahlen sollte, und warum ich selbst für Software Geld ausgeben sollte, wenn ich es doch auch einfach selbst machen kann
Nur als Warnung: Bald fängt Claude vielleicht noch an, sich zu beschweren, dass du selbst auch mal etwas arbeiten sollst
Ich stoße bei Software-Tools für die Nutzung von LLMs an Grenzen. Es gibt keine Möglichkeit, ein einziges globales System-Prompt auf alle Apps anzuwenden, die auf einem OpenRouter Key basieren, und es ist auch umständlich, Unterhaltungen von einer App in eine andere zu übertragen. Nicht einmal denselben MCP-Toolzugang kann man sauber für alle Apps bereitstellen. Die UX von Claude Code ist derzeit wohl die beste, aber ich möchte nicht an ein Claude-Abonnement gebunden sein, sondern über meinen eigenen Key mit Anbietern meiner Wahl verbunden werden
Mir scheint, es fehlt an Dingen, die erfolgreich für Sicherheit, Internationalisierung, Lokalisierung, Barrierefreiheit, Usability und Ähnliches gepromptet wurden. Das Problem ist, dass es zu viele Amateure gibt, die sich ohne solche Qualitätsaspekte als „Software-Macher“ bezeichnen. Ohne diese Punkte kann man mit kommerzieller Software niemals erfolgreich sein. Wer glaubt, das lasse sich einfach per Prompt lösen, hat in dem Bereich keine ernsthafte Erfahrung
Fairerweise muss man sagen, dass auch bei realer kommerzieller Software viele diese Aspekte nicht richtig berücksichtigen
Ich bin ebenfalls skeptisch, aber von den vier verlinkten Dokumenten scheinen zumindest die zu Barrierefreiheit und Usability dabei zu sein. Internationalisierung und Lokalisierung sehe ich nicht, aber im Kern dürften sie nicht so anders sein. Sicherheitsfragen hingegen wirken auf mich wie ein ganz eigenes Feld
Es überrascht mich, dass es immer noch viele Menschen gibt, die glauben, Entwicklung in der Art „Mein System aus vier Dokumenten? Am Ende ist es auch nur Spaghetti, das zu einem Muster geworden ist, und morgen kann alles wieder zusammenbrechen. Dann werfen wir eben wieder Spaghetti an die Wand“ ließe sich skalieren
Ich experimentiere in letzter Zeit mit modellgestützter Entwicklung und kann den Abschnitt im Artikel darüber, was Programmierung eigentlich ist, stark nachvollziehen. Ich nutze meine 25 Jahre Erfahrung und mein Informatikstudium, aber es fühlt sich nicht mehr wie traditionelles Programmieren an, bei dem man den Code mit den eigenen Händen schreibt. Im Moment fühlt es sich eher so an, als wäre ich ein Pilot, der Werkzeuge steuert, statt etwas in Handarbeit herzustellen. Menschen, die genau diese Handarbeit lieben, werden die Branche meiner Meinung nach in den nächsten fünf Jahren wahrscheinlich verlassen. Natürlich wird es weiterhin Bereiche geben, in denen Handarbeit nötig ist, aber eine neue Methodik öffnet sich gerade. Noch ist nicht jeder darin geübt, aber auch das wird Teil der Branche werden