> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/de/2026/w38-everything-can-be-engineered.md). # W38-Alles lässt sich als technisches Projekt organisieren Einige jüngste Arbeiten haben meinen Eindruck verstärkt, dass KI meine Herangehensweise an komplexe Probleme verändert. Früher konnte ich bei einem ausreichend komplexen Problem meist nur mehr Aufmerksamkeit einsetzen: Konfigurationen merken, Dokumentation pflegen, Hintergründe wiederholt erklären und nach Fehlern suchen. Selbst wenn mir klar war, dass sich das Problem programmatisch lösen ließe, lohnte sich der Aufbau und die Pflege eines Systems dafür nicht unbedingt. Heute mache ich daraus eher ein technisches Projekt. Fakten und Regeln festhalten, wiederkehrende Handgriffe an Programme abgeben, Änderungen prüfen sowie Historie und Rückwege erhalten. Neue Anforderungen lassen sich später auf dieser Grundlage ergänzen. Diese technischen Methoden gibt es längst. **KI senkt die Kosten ihrer Umsetzung und Pflege. Viele Projekte, die sich früher nicht lohnten, lohnen sich dadurch heute.** ## Von der Proxykonfiguration zu einem wartbaren Projekt Das erste Beispiel ist die Proxykonfiguration meines Macs. Anfangs ging es nur darum, einige Apps ins Netz zu bekommen. Mit wachsenden Anforderungen kamen die Aufteilung des Verkehrs verschiedener Websites, direkte Verbindungen ins Firmennetz, Unterschiede zwischen CLI- und Desktop-Umgebungen sowie Updates und Gerätewechsel hinzu. Jeder einzelne Fall war überschaubar. Zusammengenommen ließen sich die Regeln aber kaum noch allein im Gedächtnis verwalten. Heute löste ich ein Problem; später wusste ich womöglich nicht mehr, warum ich etwas so konfiguriert hatte oder was die nächste Änderung beeinflussen würde. Schließlich überführte ich die Lösung in ein privates Repository. Dort liegen Konfigurationsvorlagen, Routingregeln, Erzeugungs- und Prüfscripts sowie Handbücher für Wiederherstellung, Wartung und Fehlersuche. Vor Änderungen gibt es eine Vorschau, vor der Installation ein Backup und bei Problemen einen Rückweg. Auch die Migration auf einen anderen Mac hat klare Schritte und Abnahmeanforderungen. Ich habe die Migration auf einen anderen Rechner bereits praktisch durchgeführt und Wirksamkeit sowie Effizienz der Lösung geprüft. Was früher einzelne Untersuchungen und manuelle Konfiguration erforderte, folgt heute den Regeln und Abläufen im Repository. Damit ist auch die Wiederverwendbarkeit praktisch erprobt. Für mich besteht die Veränderung darin, dass ich diese Konfiguration endlich als langfristig gepflegtes System behandeln kann. Für eine neue App oder eine geänderte Regel gibt es einen Bearbeitungsort, eine Prüfmethode und eine nachvollziehbare Vergangenheit. **Die Komplexität bleibt, hat aber einen klaren Ort und ein klares Verfahren für ihre Bearbeitung.** ## Auch ein Agent-Team braucht Engineering Das zweite Beispiel ist mein seit einiger Zeit laufendes Agent-Team. Wer allein mit ein oder zwei Agents arbeitet, kommt normalerweise mit direkten Gesprächen und Aufgabenzuweisungen aus. Sobald aber mehrere Agents verschiedene Rollen übernehmen und komplexe Probleme selbst organisiert gemeinsam lösen sollen, braucht es klare Betriebsregeln. Wer zerlegt Aufgaben, wer implementiert, wer prüft, wie werden Aufgaben übergeben und wer übernimmt bei Problemen? Das muss vorher geregelt sein. Kommen automatisierte Aufgaben für Team oder Projekt hinzu, müssen auch deren Auslösung und Betrieb verwaltet werden. Etwa wenn Codeänderungen automatisch gesucht und PRs geprüft werden sollen oder Inhalte nach einem Merge im Integrationsrepository automatisch in die zugehörigen Teilrepositories übertragen werden. Diese Anforderungen gingen allmählich über die manuelle Pflege einiger Prompts hinaus. Deshalb ordnete ich Agent-Rollen, Kooperationsregeln und Automatisierungen in einem Projekt, das sich verwalten, betreiben und fortlaufend erweitern lässt. Rollenaufgaben, Kooperationsregeln und Betriebsstrategien liegen im Repository. Es beschreibt den Sollzustand des Teams; ein Synchronisierungswerkzeug prüft die Abweichung zum laufenden Zustand. Änderungen lassen sich vorher ansehen und nach dem Anwenden auf Übereinstimmung prüfen. So kann ich das Team laufend anpassen, ohne es jedes Mal neu zusammenzusetzen. **Eine gelungene Zusammenarbeit kann zur gemeinsamen Regel aller beteiligten Rollen werden.** Auch ein im Fehlschlag entdecktes Problem kann in Konfiguration und Prüfung eingehen und so die nächste Arbeit vorbereiten. Ich behandle das Agent-Team inzwischen als System, das Betrieb und Weiterentwicklung braucht. Modellfähigkeiten sind ein Teil davon. Rollengrenzen, Übergaben und Abnahmemethoden müssen genauso fortlaufend verbessert werden. ## Den Arbeitskontext des Teams auf einen gemeinsamen Versionsstand bringen Das dritte Beispiel ist ein laufendes MVP zur Steuererklärung. Wir entwickeln es im BFO-Integrationsrepository. Produkt- und Architekturdokumente, Schnittstellenverträge, Abnahmespezifikationen, Frontend- und Backend-Code sowie Agent-Werkzeuge liegen im selben Repository und bilden eine gemeinsame Versionsbasis. **Ich möchte eine Arbeitsweise erreichen, in der Dokumentation wie Code und Code als Produkt behandelt wird.** Wenn sich Produktregeln ändern, können Dokumente, Verträge, Implementierung und Abnahmekriterien gemeinsam geändert und geprüft werden. Wir können zu einer bestimmten Version zurückkehren und sehen, welche Anforderungen damals galten, wie der Code sie umsetzte und anhand welcher Kriterien die Richtigkeit beurteilt wurde. Früher verteilte sich dieser Kontext häufig auf Dokumente, Chatverläufe und die Erinnerung einzelner Menschen. Rollenübergreifende Zusammenarbeit erforderte wiederholtes Übertragen und Erklären. Das Produktteam erläuterte einmal, die Entwicklung interpretierte erneut, und das Testteam rekonstruierte ein weiteres Mal. Nach einer Anforderungsänderung musste man außerdem prüfen, ob alle dieselbe Version vor sich hatten. Das Integrationsrepository gibt dieser Arbeit eine gemeinsame Grundlage. Es beseitigt keine Verständigungsunterschiede zwischen Menschen. Es kann aber den Aufwand für Materialsuche, Versionsabgleich und wiederholte Hintergrundserklärungen senken. Diskussionen beziehen sich auf konkrete Änderungen, und ihre Ergebnisse haben einen klaren Ablageort. Auch KI kann diese Materialien lesen. Nach der Übernahme einer Aufgabe kann sie Anforderungen, Verträge, Implementierung und Tests nach Kontext durchsuchen, statt ganz von den vorübergehend im aktuellen Gespräch bereitgestellten Informationen abzuhängen. Das MVP läuft noch; der langfristige Nutzen muss sich erst zeigen. Besonders wichtig ist mir aber die spätere alltägliche Weiterentwicklung. Wenn diese Bestände mit dem Produkt gepflegt werden, kann jede Arbeitsrunde der nächsten eine vollständigere Grundlage hinterlassen. **Bereits geleistete Arbeit kann die Kosten künftiger Arbeit weiter senken.** ## Fakten und Darstellung im Finanzmanagement Das vierte Beispiel ist noch nicht umgesetzt: ein geplantes Projekt für meine persönliche Finanz- und Anlageverwaltung. Derzeit pflege ich in Google Drive wöchentliche, monatliche und vierteljährliche Unterlagen zur Prüfung der Familienfinanzen und beobachte fortlaufend die Märkte. Diese Arbeit möchte ich schrittweise in ein privates Projekt überführen. Dazu gehören die Grundlagen unserer Familienfinanzen, Anlageobjekte, Anlagekanäle, Marktbeobachtungen und die Protokolle regelmäßiger Prüfungen. **Am meisten reizt mich die Trennung von maßgeblicher Faktenquelle und Darstellung.** Wenn ich früher entschied, ob Informationen in eine Tabelle, ein Dokument oder eine Präsentation gehören, dachte ich oft schon über ihr späteres Aussehen nach. Das Darstellungswerkzeug bestimmte leicht die Organisation der Daten. Künftig möchte ich zuerst eine Grundlage mit Quellen, Zeitangaben und Versionen pflegen und daraus je nach Frage die Darstellung erzeugen. Für die Vermögensstruktur entsteht ein Diagramm, für die monatliche Prüfung ein Bericht. Will ich eine Veränderung verstehen, frage ich entlang der Historie nach. Alle Darstellungen stammen aus denselben Grunddaten und lassen sich mit ihnen abgleichen. So muss ich die Fakten nicht für jede Darstellungsform neu ordnen. Diagramme und Berichte lassen sich jederzeit erzeugen und anpassen. Langfristig gepflegt wird vor allem, ob die zugrunde liegenden Informationen richtig, vollständig und aktuell sind. Auch mein Verständnis von Engineering verändert sich damit. Ein Projekt kann Fakten, Regeln und Entscheidungsprotokolle tragen und daraus nach Bedarf Oberflächen für Menschen erzeugen. ## Mit KI amortisiert sich Engineering leichter Diese Beispiele haben eines gemeinsam: Sie haben eine gewisse Komplexität angesammelt und brauchen fortlaufende Pflege. Früher hätte ich dafür nicht unbedingt ein technisches Projekt angelegt. Skripte, Dokumentation, Prüfungen und Werkzeugpflege kosten Arbeit. Viele persönliche Anforderungen waren zu klein; ihr Nutzen deckte die Kosten nicht. Also blieb es bei manueller Arbeit. KI senkt diese Investition. Wenn Konfigurationen ordnen, Skripte schreiben, Tests ergänzen und Dokumente pflegen billiger wird, behandle ich mehr Probleme mit technischen Methoden. Proxykonfiguration, Agent-Zusammenarbeit, gemeinsamer Teamkontext und sogar Familienfinanzen kommen dafür infrage. **Zuverlässigkeit braucht weiterhin konkrete Mechanismen.** Fakten müssen abgeglichen, Änderungen geprüft und Fehler erkennbar sein. Bei Bedarf muss ein Rückweg bestehen. KI kann solche Mechanismen aufbauen und pflegen helfen, sie aber nicht ersetzen. Erst auf dieser Grundlage traue ich mir zu, weitere Fähigkeiten hinzuzufügen. **Das System kann mehr Probleme bearbeiten, ohne dass mein Gedächtnis und meine Aufmerksamkeit proportional mitwachsen müssen.** Meine Einschätzung wird klarer: Alles lässt sich als technisches Projekt organisieren. Genauer: **Sobald ein Problem Teile enthält, die sich eindeutig beschreiben, berechnen und prüfen lassen, kann ich versuchen, sie zu einem dauerhaft wartbaren Projekt zu ordnen.** Urteile und Abwägungen bleiben beim Menschen. Die Informationsaufbereitung, Ausführung und Rückmeldung darum herum können sich jedoch laufend verbessern. Früher fragte ich bei komplexen Problemen zuerst, wie viel Kraft ich investieren müsste. Heute frage ich zuerst, ob sich dafür ein System bauen lässt, das später weiterwachsen kann.