Formbare Software: 80 % solide Basis, 20 % eigener Code
Malleable software = solid bases and custom code
Seit 22 Jahren beobachtet Michael Dubakov den Markt für Produktivitätstools. Jetzt sieht er einen fundamentalen Wandel: KI senkt die Hürde für eigene Software, doch für Teams bleibt die Frage, wo die Balance liegt. Der Artikel analysiert fünf Optionen – vom Bauen mit Codex bis zum Kauf spezialisierter Tools – und argumentiert, dass die ideale Lösung eine solide Basis (Daten, Berechtigungen, Verlauf) plus individuellem Code ist. Er zeigt, wie verschiedene Anbieter wie Notion, Retool oder Fibery sich dieser Vision annähern und welche Strategie er für die Zukunft empfiehlt.
Die solide Basis sollte abdecken, was für jedes Team identisch ist, und der eigene Code sollte abdecken, was euer Team besonders macht.
- watty
Das ist eine großartige Einsicht, ich stimme dem Autor zu! Schau dir meinen [INSERT VIBE CODED GITHUB LINK] an, der diesen Mustern folgt!
- momojo
Ich liebe diese Herangehensweise. Im Bio-Imaging-Bereich ist Napari ein großartiges Beispiel dafür. Wunderbar solide Basis, aber extrem erweiterbar, da es einfach nur Python bis in die Tiefe ist.
Es hat etwas Wunderbares, wenn mein Kollege mit einem Problem vorbeikommt und ich vor dem Mittagessen ein Napari-Plugin zusammenbauen kann, das genau ihr Problem löst.
Meine Reihenfolge der 'Werkzeug-Eskalation' ist normalerweise:
- Kann ich ihr Problem über naparis Inline-Terminal lösen?
- Kann ich es mit einem Einmal-Skript lösen?
- Kann ich es mit einem Einmal-Skript lösen, das eine Einmal-Plugin-Schnittstelle erstellt?
- Sollte ich das Plugin in unser firmenweites Repo aufnehmen, da dieses Problem häufig aufzutreten scheint?
- mickael-kerjean
Das ist der Weg, den ich mit meiner Dropbox-Alternative [1] eingeschlagen habe. Die 80% sind der schnelle Kern, der sich auf Dateiverwaltung konzentriert, die restlichen 20% kommen über Plugins, die eine der Kern-Schnittstellen implementieren, sodass du deinen eigenen Speicher, Autorisierung, Authentifizierung, benutzerdefinierte Apps zur Verarbeitung von Dateitypen, ... verwalten kannst. Lustige Tatsache: Es gibt 10x mehr Code in den verschiedenen Plugins [2], die alles abdecken, als der Kerncode, der die 80% sein sollte. Überraschenderweise brauchte jeder andere 20%. Außerdem finde ich es cool, dass der Typ, der ein gobd-konformes Log-System brauchte, das viele Eigenschaften hat, um Auditoren zufrieden zu stellen, die hash-verkettete, mit rfc3161 signierte Logs erzwingen, nicht dazu beiträgt, das System für alle anderen schlechter zu machen.
[1] https://github.com/mickael-kerjean/filestash https://github.com/mickael-kerjean/fdrive
- genatron_ai
Eine funktionierende Basis zu haben, die Agenten dann anpassen können, ist ein großartiger Ansatz, weil man einige der Brownfield-Vorteile erhält, bei denen es etablierte Muster gibt, denen man weiter folgen kann. Das ist oft viel schneller und vorhersehbarer als von Grund auf zu starten, wo man, obwohl agentische Entwicklung schnell ist, eine echte Dev-Denkweise haben und an alles denken muss.
- pavo-etc
Pi ist ein großartiges Beispiel dafür. Ich habe es als Basis für eine Flotte von Agenten verwendet, die ich auf meinem Server betreibe, aber anstatt die Pi-TUI zu nutzen, betreibe ich es im Headless-Modus und habe es erweitert, um XMPP als Kommunikationsebene zu verwenden, sodass ich jedes Gerät mit denselben Sitzungen nutzen kann und Agenten miteinander sprechen können.
Das Pi-Harness ist dafür gebaut, so erweitert zu werden, und es ist eine Freude, damit zu arbeiten.