Wir stellen Ihnen den Citizen Developer SDLC von Tenex vor, einen sechsstufigen Lebenszyklus, der die mit KI erstellten Anwendungen von Nicht-Entwicklern vom persönlichen Prototypen zur unternehmensweiten Produktion führt, auf die sich das gesamte Unternehmen verlassen kann.
Von Alex Lieberman (@businessbarista), Arman Hezarkhani (@ArmanHezarkhani, Suchi Patel und Ashwin Kadaru (@AshwinKadaru
Ein Framework von Tenex.co.
Die Kurzfassung
Der Citizen SDLC ist ein sechsstufiger Lebenszyklus (Idee, Eingangstor, Triage, Bereitstellung, Bau, Betrieb und Änderung), der Software, die von nicht-technischen Mitarbeitern mit KI erstellt wurde, vom persönlichen Prototypen zur kontrollierten Produktion führt. Ein Prinzip zieht sich durch jede Phase: KI erledigt die Arbeit, deterministischer Code setzt die Leitplanken, und Menschen kümmern sich um die Ausnahmen. Er existiert, weil KI die Kosten für das Schreiben von Code auf nahezu Null gesenkt und den Engpass nachgelagert hat – hin zur Sicherstellung, dass das Gebaute solide ist, und zur Verwaltung einer wachsenden Anzahl solcher Anwendungen, sobald sie live sind.
Einer unserer Kunden ist eine Investmentfirma. Ein Mitglied ihres Portfolio-Operations-Teams, jemand, der noch nie eine Zeile Code geschrieben hat, hat das Dashboard gebaut, das ihr gesamtes Team jetzt täglich nutzt. Es verfolgt die Wertschöpfungsarbeit in mehreren Dutzend Portfoliounternehmen. Sie hat es gebaut, indem sie Claude Anweisungen gab und etwa zwei Monate lang iterierte. Jede einzelne Zeile wurde von KI geschrieben.
Und es ist gut. Die Ansichten sind richtig, der Workflow passt zur tatsächlichen Arbeitsweise des Teams, und die Akzeptanz war sofort da. Sie hat das richtige Produkt skizziert, bevor überhaupt ein Ingenieur involviert war.
Das ist kein Zufall. Jahrzehntelang war die Person, die ein Geschäftsproblem verstand, fast nie die Person, die die Software zur Lösung bauen konnte. Diese Lücke zu schließen, war eine Herkulesaufgabe: ein Produktmanager, der ihr Problem in ein Pflichtenheft verwandelte, Ingenieure, die das Pflichtenheft in Code übersetzten, und ein Platz in der Warteschlange hinter all den anderen Dingen auf der Roadmap. Zwischen der Idee und dem Werkzeug vergingen Monate, und das, was schließlich ausgeliefert wurde, war die Interpretation einer anderen Person von dem, was sie gemeint hatte.
Diese Lücke ist gerade zusammengebrochen. Die Macht, etwas zu bauen, ist zu den Menschen übergegangen, die den Prozess tatsächlich verstehen, wissen, was die Daten bedeuten, und jeden Tag in diesem Workflow leben. Sie hat beim ersten Mal das Richtige gebaut, weil sie die Quelle war. Niemand stand dazwischen, um sie zu übersetzen oder es ein kleines bisschen falsch zu machen. Das ist das Versprechen der Citizen Development, und sie hat es eingelöst.
Dann haben wir unter die Haube geschaut.
Die gesamte Anwendung war eine einzige HTML-Datei. 540 KB. Ungefähr 5.300 Zeilen. Der Master-Datensatz lebte darin als ein 80 KB großer Datenblock in einer einzigen Zeile. Wenn die Datei aktualisiert werden musste, hatte die KI Patch-Funktionen hinzugefügt, die bei jedem Laden der App Werte überschrieben. Das Speichern der Arbeit bedeutete, dass die App ihr eigenes HTML überschrieb, sich selbst auf Ihren Laptop herunterlud und Sie es als neue Version in ein gemeinsames Laufwerk hochluden. Wenn zwei Personen gleichzeitig bearbeiteten, gewann die letzte Speicherung, und die Änderungen der anderen Person verschwanden.
Eines Tages suchte eine Speicherfunktion nach einer Markierung in der Datei, fand sie nicht und schrieb trotzdem zurück, was sie hatte. Die gesamte 540 KB große Anwendung wurde auf 7 Bytes verkürzt. In einem einzigen stillen Schreibvorgang hörte das Dashboard, auf das ihr Team täglich angewiesen war, auf zu existieren, und nichts in der Art und Weise, wie es gebaut wurde, war darauf ausgelegt, dies zu erkennen, zu stoppen oder rückgängig zu machen.
Die meisten Führungskräfte, die diese Geschichte hören, schlussfolgern, dass Citizen Development eine Haftung ist, die abgeschaltet werden muss. Wir denken, das ist die falsche Lektion, und die Unternehmen, die danach handeln, werden verlieren. Die richtige Lektion: Sie hat ihren Job brillant gemacht. Niemand hatte die Straße gebaut, auf der die Software ausgeliefert werden konnte.
Der Engpass hat sich verlagert
Jahrzehntelang war das Bauen von Software der teure Teil. Es war langsam, knapp und kostspielig, und der gesamte Softwareentwicklungslebenszyklus ist entstanden, um es zu schützen. Spezifikationen, Tickets, Sprints, Code-Review: Jede Zeremonie im traditionellen SDLC existiert, weil das Schreiben des Codes der Engpass war.
KI hat diese Phase auf nahezu Null reduziert, und der Engpass hat sich verlagert. Wenn jeder in einem Nachmittag eine funktionierende App bauen kann, ist die teure Arbeit nicht mehr das Bauen. Es ist das, was danach kommt: sicherzustellen, dass das Gebaute solide und sicher ist, und eine wachsende Flotte dieser Apps zu verwalten, sobald sie live sind.
GIF
Und das Bauen verlangsamt sich nicht, was zwei Probleme schafft, die gelöst werden müssen:
Erstens: Qualität unter der Haube. Ein Agent, der von einer leeren Seite durch einen Nicht-Ingenieur angetrieben wird, konvergiert zu einer hackigen Software, die heute funktioniert und für immer nicht wartbar ist. Die 540-KB-Datei ist kein Ausreißer; sie ist die Standardausgabe des Bauens ohne Leitplanken.
Zweitens: Wildwuchs. Jedes Team möchte seine eigene App, und keine zentrale IT-Abteilung kann Dutzende davon manuell bauen und betreiben. Ohne Leitplanken wird jede auf dem Stack gebaut, den der Builder oder das Modell gerade griffbereit hatte: eine andere Datenbank, ein anderes Authentifizierungsschema, Geheimnisse, die irgendwo landen. Blockieren Sie stattdessen die Anfragen, dann hören sie nicht auf, sie wandern nur in den Schatten. In beiden Fällen erben Sie nicht nur eine Flotte von Apps, sondern auch das verworrene Durcheinander der darunterliegenden Infrastruktur, und nichts davon kann die IT vernünftig sichern, unterstützen oder erklären.
Die eigentliche Frage, vor der jedes Unternehmen bald steht: Wie lassen Sie nicht-technische Mitarbeiter echte interne Software ausliefern, ohne diese Flotte zu erben?
Die drei Standardantworten scheitern alle:
1) Alles abschotten. Anfragen stauen sich, die Geduld geht aus, und die Schatten-Apps werden trotzdem gebaut. Jetzt können Sie nichts davon sehen. Sie können nicht kontrollieren, was Sie nicht sehen können.
2) Freien Lauf lassen. Nicht-Ingenieure ohne Struktur auf KI-Tools ansetzen und die Demos feiern. So bekommen Sie die 540-KB-Datei. Und Sie können das nicht im Nachhinein durch Reviews beheben. Wenn ein Monolith im Code-Review auftaucht, ist er bereits ein Monolith. Das muss am Startpunkt verhindert werden.
3) Alles reviewen. Bei jeder Änderung eine menschliche Genehmigung einholen. Ihr IT-Team ist schlank, das Bauvolumen explodiert, und jetzt wartet jede Bereitstellung auf den Terminkalender eines Reviewers. Reviews töten entweder die Akzeptanz oder werden zum reinen Abnickprozess. Beide Ergebnisse vereiteln den Zweck.
Die Antwort ist also kein weiteres Richtlinienpapier, sondern ein Lebenszyklus: ein echter SDLC, entwickelt für Menschen, die sich nie als Entwickler bezeichnen werden, mit Leitplanken, die in die Plattform eingebaut sind, statt in ein Memo geschrieben. Eine Straße, die einen Build von der ersten Idee in natürlicher Sprache bis zur kontrollierten Produktion führt, ohne den Builder jemals zu bitten, ein Ingenieur zu werden. Die Person liefert die Absicht; die Plattform sorgt für die Disziplin.
Ein Prinzip zieht sich durch jede Phase: KI erledigt die Arbeit, deterministischer Code setzt die Leitplanken, und Menschen kümmern sich um die Ausnahmen. KI entwirft, klassifiziert und schreibt. Code entscheidet, was erlaubt ist. Menschen werden nur dort eingesetzt, wo tatsächlich Urteilsvermögen erforderlich ist. Behalten Sie diese Aufteilung im Kopf; sie ist es, die das Ganze skalierbar macht.
Wir nennen es den Citizen SDLC. Sechs Stufen, jede kontrolliert.
Stufe 1
Die Idee
Eine Person beschreibt die App mit Hilfe von KI in einfacher Sprache: was sie tut, wer sie nutzt, welche Daten sie berührt, wem sie gehört. Dauert Minuten und liest sich wie ein Memo. Es dient gleichzeitig als Kurzbeschreibung, die alles Nachgelagerte antreibt. Dies ist der erste Schritt des Betriebsmodells: KI erledigt die Arbeit, aus einem wirren Reden ein strukturiertes Artefakt zu machen.
So sieht das in der Praxis aus. Jemand aus der Fondsbuchhaltung tippt: „Ich möchte einen Tracker für Kapitalabrufnotizen. Im Moment ist es eine Tabelle, die ich von Hand aktualisiere und jeden Freitag per E-Mail verschicke.“ Die KI stellt die Fragen, die ein Aufnahmeanalyst stellen würde. Wer muss es sonst noch sehen? Zwölf Personen aus der Fondsbuchhaltung und Investor Relations. Wo leben die Daten heute? In einer Tabelle in Box, und schreibgeschützt ist in Ordnung. Wem gehört es, wenn Sie weg sind? Ihrem Vorgesetzten. Aus dem wirren Reden ist eine Kurzbeschreibung geworden: Zweck, Benutzer, Datenquelle, Zugriffsniveau, Eigentümer, sogar eine erste Schätzung der Form der App. Ein PRD im Grunde, verfasst von jemandem, der noch nie den Begriff PRD gehört hat.
GIF
Es existiert noch nichts. Kein Code, kein Zugriff, keine Infrastruktur. Das ist beabsichtigt: Das Unternehmen bildet sich eine Meinung über die App, bevor die App existiert, anstatt sechs Monate, nachdem sie tragend geworden ist.
Stufe 2
Das Eingangstor
Jede Anfrage durchläuft ein einziges strukturiertes Eingangstor, und derselbe Vorgang, der sie einreicht, wirft sie direkt in die Triage. Die Kurzbeschreibung ist die Anfrage, das Ticket, das die IT sieht, der dauerhafte Datensatz und ein Eintrag in einem Katalog, den jeder durchsuchen kann – alles auf einmal. Keine Anfragen auf dem Flur, keine Gefälligkeiten, keine Schatten-Pipeline. Sie können nicht kontrollieren, was Sie nicht sehen können, und Sie können nicht teilen, was Sie nicht finden können. Das Eingangstor macht beides ab Tag eins wahr.
Dies ist die Stufe, die die Schatten-Pipeline tötet. Ein Build, der das Eingangstor überspringt, kann weiterhin als Prototyp auf einem Laptop existieren, aber dort bleibt er auch. Alles, was einen Prototypen in Software verwandelt, auf die ein Team sich verlassen kann, liegt nachgelagert zu dieser Stufe: echter Speicher, Firmen-Anmeldung, eine Bereitstellungs-Pipeline, ein Ort, um sie tatsächlich auszuführen. Nichts davon erreicht einen Build, der nie durch das Tor gekommen ist. Sie können das Eingangstor umgehen; Sie kommen nur nicht über den Prototypen hinaus, wenn Sie es tun.
Stufe 3
Die Triage
KI klassifiziert die Anfrage entlang zweier Achsen. Form: Um welche Art von App handelt es sich? Eine Reverse-Audit-Analyse dessen, was Mitarbeiter tatsächlich bauen, reduziert sich fast immer auf eine kurze Liste: Artefaktgeneratoren, Workflow-Automationen, CRUD-Apps und interaktive Dashboards. Die Benennung der Form sagt Ihnen, welche Architektur sie benötigt, und gibt der nächsten Stufe die befestigte Straße vor, die sie stempeln muss. Schadensradius: Wie viel Schaden könnte dieser Build anrichten, wenn er schiefgeht? Wir bewerten das über vier Dimensionen:
- Reichweite und Fähigkeit: Was kann es berühren, und kann es nur lesen oder auch schreiben?
- Umkehrbarkeit und Autonomie: Gibt es einen Menschen im Kreislauf, und kann die Aktion rückgängig gemacht werden?
- Exposition: Wer sieht die Ausgabe, und wie weit reist sie außerhalb des Unternehmens?
- Datensensitivität: Wie vertraulich sind die Daten, mit denen es interagiert?
Aber hier ist die Regel, die dies vertrauenswürdig macht: KI berät. Code entscheidet. Das Modell liest die Kurzbeschreibung und klassifiziert sie; dann prüft ein von der IT geschriebener Richtlinien-Code jede Klassifizierung gegen die Regeln. Sehen Sie es beim Kapitalabruf-Tracker in Aktion. Form: interaktives Dashboard. Schadensradius: interne Fondsdaten, zwölf interne Benutzer, schreibgeschützt, Mensch im Kreislauf, keine Überschneidung mit bestehenden Apps. Jede Dimension liegt innerhalb der genehmigten Schwellenwerte, also ist es genehmigt, und kein Mensch hat darüber diskutiert.
Ändern Sie nun eine Tatsache. Angenommen, der Tracker benötigt auch LP-Commitment-Daten. Die Kurzbeschreibung kann noch so überzeugend sein; diese eine Änderung treibt die Datensensitivitäts-Dimension über den von der IT gesetzten Schwellenwert, und die Anfrage geht an eine Person. Dazwischen fand keine Beurteilung statt. Eine Regel trifft entweder zu oder nicht.
Drei Ausgänge:
- Genehmigt. Schadensradius innerhalb aller Schwellenwerte, vollständige Kurzbeschreibung, hohe Zuversicht. Bei unserem Kunden werden etwa 9 von 10 Anfragen auf diese Weise automatisch gelöst.
- Wiederverwenden. Es überschneidet sich mit einer bereits existierenden App, also wird der Antragsteller an den Besitzer dieser App weitergeleitet, anstatt ein Duplikat zu bauen. Duplikate werden zusammengeführt, nicht vervielfacht.
- Eskaliert. Eine Dimension überschreitet ihren Schwellenwert, oder die Zuversicht ist gering. Eine Person in der IT- und Sicherheitsabteilung erhält die vollständige Anfrage als Kontext.
GIF
Die zehnte Anfrage, der Ausreißer, landet immer noch mit der vollständigen Kurzbeschreibung auf dem Schreibtisch eines Menschen. Die anderen neun brauchten das nie.
Stufe 4
Die Bereitstellung
Hier ist der Schritt, der es der IT ermöglicht, in großem Umfang „Ja“ zu sagen: Bereitstellung bedeutet nicht, dass die IT die Kontrolle darüber verliert, was ausgeliefert wird, sondern dass die Kontrolle der IT vorgelagert wird. Anstatt jede App im Nachhinein zu reviewen, erstellt die IT die befestigte Straße einmal, und jede App wird auf ihr geboren. Eine Person genehmigt, und die Plattform stempelt die App aus der Straße für ihre Form: ein Repository, Firmen-Anmeldung, eine Bereitstellungs-Identität, eine private Umgebung und eine eigene Datenbank, alles definiert als Infrastructure-as-Code, das der IT gehört und versioniert wird. In Minuten bereitgestellt.
Dies ist der einzige Moment, in dem erhöhte Rechte laufen, und ein Mensch sitzt davor. Jede App wird isoliert, kontrolliert und geprüft geboren: ihre eigene abgeschottete Umgebung, keine öffentliche Adresse, keine in der Cloud gespeicherten Geheimnisse, eine nur-append-fähige Prüfspur ab Tag null. Die Sicherheitsarbeit fand einmal statt, in der Straße. Keine App muss sie wiederholen.
Da die Straße pro Form erstellt wird, ist die menschliche Genehmigung eine Standardhaltung, keine dauerhafte Steuer. Neuartige Formen und Builds mit hohem Schadensradius behalten das menschliche Tor dauerhaft. Aber sobald sich die Straße einer Form über genügend Builds bewährt hat, können Anfragen mit geringem Schadensradius auf dieser Straße automatisch bereitgestellt werden. Es ist dieselbe Logik „menschliches Urteilsvermögen für die Ausreißer sparen“, die eine Stufe früher angewendet wird: Anfangs leiten Sie mehr an eine Person weiter, und wenn sich die Muster bewähren, verschiebt sich die Grenze zur Automatisierung.
Und die Straße trägt noch etwas, das genauso wichtig ist wie die Infrastruktur: das KI-Regelwerk. Das geerbte Repository übergibt dem Codier-Agenten bei jeder Sitzung eine Reihe von Anweisungen, die die aus echten Fehlern gelernten Anti-Patterns kodieren. Betten Sie keine Datenblöcke über 1 KB inline ein. Fügen Sie keine Funktionen hinzu, die Daten beim Laden der App neu schreiben. So wird das Problem der Qualität unter der Haube gelöst, ohne den Builder zu bitten, eine einzige Best Practice zu kennen: Die Straße zwingt den Agenten, sie zu befolgen. Jede dieser Regeln ist eine Narbe mit einer Geschichte dahinter (Sie haben eine davon gelesen).
Stufe 5
Der Bau
Der Builder gibt seinem Codier-Agenten (Claude Code, Codex usw.) Anweisungen in einer kontrollierten Cloud-Arbeitsumgebung, niemals auf seinem eigenen Laptop. Ein Terminal-Agent auf einem Laptop erbt alles, was dort sitzt: E-Mails, synchronisierte Laufwerke, Browser-Cookies, zwischengespeicherte Anmeldeinformationen. In der Arbeitsumgebung sieht der Agent das Projekt. Nichts sonst.
Alles, was ein Ingenieur normalerweise mit sich trägt, wird stattdessen von den Leitplanken getragen: bei unserem Kunden 35 Leitplanken in vier Schichten, die der Builder nicht ausschalten kann.
Die Merge-Schicht enthält speziell für KI-generierten Code entwickelte Drift-Prüfungen: Dateigrößen-Budgets, keine übermäßig großen Inline-Daten, Konformität mit der Prüfspur. Grün oder es wird nicht gemerged. Wenn eine Prüfung fehlschlägt, bittet der Builder den Agenten, es zu beheben, und schiebt erneut.
Menschen reviewen keine Routineänderungen. Die Prüfungen sind das Review. Routineänderungen bewegen sich mit der Geschwindigkeit von CI, nicht mit der Geschwindigkeit des Terminkalenders eines Reviewers. Was einen Menschen erreicht, ist der folgenreiche Ausreißer, mechanisch erkannt: destruktive Schemaänderungen, neue Abhängigkeiten, Änderungen an den eigenen Einschränkungen des Agenten, alles, was die Infrastruktur berührt. Diese warten auf eine Person. Nichts anderes. Und wenn doch einmal etwas Neues entkommt, ist die Lösung eine neue automatisierte Prüfung, nicht mehr menschliches Review. Das System wird strenger, indem es Lektionen kodiert, nicht indem es Meetings hinzufügt.
Erinnern Sie sich an das Dashboard aus der Einleitung. Zwei dieser Drift-Prüfungen wären in der ersten Woche darauf angesprochen worden. Der 80-KB-Einzeilen-Block wäre bei seinem allerersten Commit durch CI gefallen, Monate bevor sich einer der Fehlermodi manifestiert hätte.
Stufe 6
Betrieb & Änderung
Sechs Monate später läuft der Kapitalabruf-Tracker immer noch, und hier zeigt der Lebenszyklus, was er wert ist. Jemand in der IR hinterfragt die Überweisungsfrist für die März-Mitteilung. Die Prüfspur antwortet in dreißig Sekunden: wer das Feld geändert hat, wann und was vorher da stand, aufgezeichnet in derselben Transaktion wie die Bearbeitung selbst. Niemand rekonstruiert die Wahrheit aus einer E-Mail-Kette. Wenn der Builder das Team wechselt, geht das Eigentum an einen benannten Nachfolger über, anstatt sich in Luft aufzulösen. Und wenn sie das Unternehmen ganz verlässt, stirbt ihre Anmeldung, und jede Tür, die sie geöffnet hat, schließt sich sofort. Der Tracker inbegriffen. Die Feature-Anfrage für das nächste Quartal geht denselben Weg wie der erste Commit.
Governance arbeitet mit Signalen, nicht mit jährlichen Audits. Die Nutzungsmetriken des Trackers zeigen, dass zwei weitere Teams darauf zurückgreifen, also wird er aufgewertet und erhält Investitionen. Das Währungs-Dashboard, das seit April niemand mehr geöffnet hat, wird archiviert, nicht dem Verfall im Menü überlassen. Niemand trauert ihm nach. Das Eigentum wird am ersten Tag zugewiesen, sodass nichts seinen Ersteller überdauert, ohne Eigentümer zu sein. Die Dokumentation wird regeneriert, während sich die App weiterentwickelt, sodass sie nie veraltet. Eine ungenutzte App ist ein Fehler, keine Trophäe. Das Ziel war nie die Anzahl der Apps: Es ist ein lebendiger Katalog, dem Ihre Leute tatsächlich vertrauen, anstatt ein Friedhof vergessener Software.
Wenn der Katalog von zehn auf zweihundert Apps anwächst, kann ein zentrales Team nicht mehr alles im Auge behalten, und die Aufsicht muss nach außen zu den Teams verlagert werden, die die Apps besitzen. Wann und wie weit föderalisiert wird, ist eine Frage des Urteilsvermögens und verschiebt sich mit dem Wachstum des Portfolios. Governance ist hier eine Haltung, die Sie ständig justieren, keine Kontrolle, die Sie einmal einstellen.
Die Regel, die das Ganze zusammenhält
Es gibt einen Auslöser, den wir jedem Kunden beibringen, weil er 90 % der Fragen „Muss das den vollen Prozess durchlaufen?“ beantwortet: die Zwei-Verbraucher-Regel. Sie funktioniert, weil sich in diesem Moment das Risikoprofil ändert.
Jemand, der eine Analyse für sich selbst auf dem eigenen Laptop mit begrenztem Datenzugriff erstellt? Geringer Schadensradius, leichte Governance. Diagramme, Memos und Skripte, die sie für sich selbst ausführt, brauchen keine Bereitstellungs-Pipeline. Aber in dem Moment, in dem eine zweite Person die Ausgabe direkt nutzen möchte, anstatt den Autor um Aktualisierungen zu bitten? Der Schadensradius springt: mehr Reichweite, Daten, die weiter reisen, jemand anderes, der darauf vertraut, dass es richtig ist. Es ist jetzt Software, und es wird bewusst als explizites Ereignis in den vollständigen Lebenszyklus überführt. Dieselben Datenquellen, dieselbe Identität, neue Straße.
Diese eine Regel ist der Grund, warum der Prozess die Leute nicht überfordert. Die meisten Builds überschreiten die Grenze nie. Diejenigen, die es tun, sind genau die, die die Zeremonie wert sind.
Womit wir ehrlich umgehen
Keine Plattform bringt Ersteller von Software dazu, perfekten Code zu schreiben. Das behaupten wir nicht. Die Schichten existieren, damit ein Fehler eine Unannehmlichkeit innerhalb einer kleinen Grenze ist, kein Vorfall im gesamten Unternehmen. Jede Schicht deckt genau das ab, was die darüber liegende nicht kann:
Und Audits verhindern nichts, aber sie machen jeden Vorfall kurz, erklärbar und zurechenbar. Das ist der Unterschied zwischen einem schlechten Nachmittag und einem schlechten Quartal.
Citizen Development ist nicht dazu gedacht, professionelles Engineering zu ersetzen. Systeme der Aufzeichnung in regulierten Prozessen, alles, was kunden- oder investorenorientiert ist, Apps für externe Benutzer, alles, wo Ausfallzeiten eine finanzielle Strafe nach sich ziehen: Das gehört weiterhin zum Engineering, und das Eingangstor leitet es am ersten Tag dorthin. Was es ersetzt, ist der Engpass. Es demokratisiert den langen Schweif interner Tools, die nie ein formelles Engineering-Projekt wert waren, und liefert sie mit einer Geschwindigkeit aus, die die Roadmap-Warteschlange nie bieten könnte. Ein Framework ohne Grenzen ist ein Slogan; dieses hier weiß, wofür es nicht gedacht ist.
Was sich tatsächlich ändert
Bei der Investmentfirma ist die erste App, die durch die Plattform geht, diejenige, die sie motiviert hat: das Dashboard aus der Einleitungsgeschichte, neu auf den Leitplanken aufgebaut. Dieselben Bildschirme. Dieselbe Erstellerin. Jetzt mit echtem Speicher, Firmen-Anmeldung und einer Historie jeder Bearbeitung. Es kann sich nie wieder auf 7 Bytes verkürzen, weil die Code-Klasse, die dies verursacht hat, nicht gemerged werden kann.
Etwa 9 von 10 Anfragen werden bereits automatisch gelöst, und dieser Anteil wächst nur. Die meisten Dinge, die nicht-technische Ersteller bauen, haben von Natur aus einen geringen Schadensradius. Interne, meist lesende, kleines Publikum. Sobald sich die Straße jeder Form bewährt, werden mehr dieser Builds sicher bereitzustellen, ohne dass ein Mensch im Kreislauf ist. Die menschliche Aufmerksamkeit konzentriert sich weiterhin auf den folgenreichen Ausreißer und verdünnt sich überall sonst.
Ja dauert heute Minuten und tendiert zu sofort, weil Nein eingebaut ist.
Jedes Unternehmen wird bald Hunderte von Erstellern haben. Die meisten Unternehmen entscheiden noch, ob sie davor Angst haben oder sich darüber freuen sollen. Diejenigen, die gewinnen, werden nicht die mit den meisten Erstellern sein. Sie werden die mit den besten Straßen sein.
