AI Coding 2026: Wie agentenbasierte KI-Entwicklung unsere Tech-Projekte verändert hat

Kurze Zusammenfassung:

Im Jahr 2026 hat ein norwegisches Bauunternehmen zwei Stunden manueller Renovierungskalkulation durch einen dreißigminütigen KI-gestützten Review ersetzt - mit nur sechs historischen Beispielen, die dem Modell die Regeln beigebracht haben. Notizen von LANARS aus Oslo darüber, was sich in der Softwareentwicklung in diesem Jahr tatsächlich geändert hat: Coding-Agenten als Teammitglieder, kleine Senior-Teams, die liefern wie große, und der neue Engpass, der nicht mehr die Engineering-Kapazität ist. Zwei Fallstudien (Lomundal, SelectAI), ein praxisorientierter 90-Tage-Plan für KMU, und die Risiken, die in der Produktion wirklich beißen. Etwa 13 Minuten Lesezeit.

Ein Dienstag in Oslo. Ein Lomundal-Inspektor schließt die iPad-App nach der Begehung einer Renovierung, die er gerade durchgegangen ist - drei Zimmer, originale Verkabelung, ein Badezimmer, das bessere Jahrzehnte gesehen hat. Er drückt «finish» und steigt ins Auto. Wenn er zurück im Büro ist, liegt bereits ein mehrseitiges Excel-Kostenangebot in seinem Posteingang. Positionen nach Gewerk sortiert, Abhängigkeiten geordnet, Materialien und Stunden und Eventualitäten - die Art von detailliertem Angebot, das früher zwei oder drei Stunden eines Senior-Kalkulators in Anspruch nahm.

Niemand bei Lomundal oder LANARS hat diese Regeln programmiert. Wir haben Claude sechs historische Paare gegeben - Begehungsbericht und das von ihm produzierte Angebot, sechs Stück, das war alles - und das Modell gebeten, die Regeln selbst zu schreiben. Das von Claude produzierte Dokument lebt nun in einem Make.com-Workflow. Neue Begehung rein, Excel raus, bevor der Inspektor zu Hause ist.

Das ist es, was sich 2026 geändert hat. Kein Slogan über denkende Computer. Ein norwegisches Bauunternehmen hat die arbeitsintensive Mitte seines Kalkulationsprozesses durch ein Modell ersetzt, das die eigenen Regeln des Unternehmens aus sechs historischen Beispielen gelernt hat, und es ist jetzt in der Produktion und macht die Arbeit. Der Rest dieses Beitrags handelt davon, was das möglich gemacht hat, was wir über die Projekte hinweg sehen, die wir von unserem Büro in Fornebu aus führen, und was wir von den nächsten zwölf Monaten erwarten.

Eine Anmerkung zu unserem Hintergrund

LANARS startete in Norwegen 2018 als kleines Team in Partnerschaft mit Unternehmen aus dem StartUpLab in Oslo. Der Engpass für diese Gründer war fast immer die Engineering-Kapazität - das Backlog war eine Liste von «machen wir später»-Punkten, jedes neue Feature bedeutete einen Sprint, jeder Sprint bedeutete ein Einstellungsgespräch. 2026 hat sich der Engpass verschoben. Engineering-Kapazität ist heute günstig genug, dass der Umfang nicht mehr die Einschränkung ist; es ist die Urteilskraft. Das ist die gesamte Prämisse dessen, was folgt.

Die drei Verschiebungen

Drei Dinge sind in der Softwareentwicklung gleichzeitig passiert, und sie verstärken sich gegenseitig. Der Rest des Beitrags arbeitet die Konsequenzen heraus.

1. Coding-Agenten wurden zu Teamkollegen. Die IDE-seitige Veränderung, über die alle diskutieren, oft schlecht.

 

2. Kleine Senior-Teams liefern wie große. Die team-ökonomische Veränderung, die für unsere Gewinn-und-Verlust-Rechnung mehr getan hat als jede andere.

 

3. KI wird jetzt im Produkt selbst erwartet. Die kundenseitige Veränderung, die graduell, aber unverkennbar ist.

Verschiebung 1. Coding-Agenten wurden zu Teamkollegen

2023 schrieb ein Engineer bei LANARS einen Funktionsnamen und ließ das Modell die Zeile vervollständigen. 2026 öffnet derselbe Engineer ein Ticket in Jira, übergibt es an Claude Code und sieht zwanzig Minuten später einen funktionierenden Pull Request erscheinen - mit Tests, mit einer Beschreibung der Trade-offs, die das Modell abgewogen hat, und mit der Art von kleinen Refactorings, die ein sorgfältiger Senior-Engineer nebenbei gemacht hätte.

 

Die Aufgabe des Engineers ist nicht verschwunden. Sie hat sich verschoben, vom Tippen von Zeichen hin zum Spezifizieren der Intention, zum Reviewen von Diffs, und zum Orchestrieren mehrerer paralleler Agent-Sessions gleichzeitig. Wir haben Engineers, die drei oder vier Claude-Code-Sessions in verschiedenen Worktrees simultan laufen lassen: einer liefert ein Feature, einer schreibt Tests für die Arbeit der letzten Woche, einer debugged einen flaky CI-Lauf, einer prüft Dependency-Upgrades. Das Output wird weiterhin von einem Menschen reviewed. Die Generierung nicht.

 

Wir haben Claude Code zum Engineering-Standard bei LANARS gemacht, ab Anfang 2026. Jeder Engineer benutzt es täglich. Neue Engineers werden in ihrer ersten Woche darin eingeführt. Der Produktivitätsabstand zwischen agentengetriebenen und nicht-agentengetriebenen Arbeitsabläufen ist 2026 weit genug, dass es, ehrlich gesagt, Geld auf dem Tisch liegen ließ, das optional zu machen. Wir haben uns für die Standardisierung entschieden und bereuen es nicht.

Verschiebung 2. Kleine Senior-Teams liefern wie große

Die zweite Verschiebung ist leiser, aber für uns wichtiger. Über 2024 und 2025 haben wir nach Fachdisziplin eingestellt: Backend, Frontend, Mobile, DevOps. Wir waren gut darin. Wir sind es immer noch. Aber die Kosten, außerhalb der eigenen Disziplin zu arbeiten, sind 2026 zusammengebrochen, und Engineers, die diesen Schritt tun können, sind dramatisch wertvoller als die, die es nicht können. Der Grund ist einfach. Ein Engineer, der versteht, wie gute Architektur aussieht - der ein System lesen, entscheiden kann, was wohin gehört, und beurteilen kann, ob eine vorgeschlagene Änderung zum Modell passt - kann jetzt legitim über den gesamten Stack hinweg liefern. Die mechanischen Teile der Arbeit in einem unbekannten Framework oder einer unbekannten Runtime sind genau die abgegrenzten, gut spezifizierten Aufgaben, in denen Agenten brillieren.

Also ist der Engpass bei «kann diese Person über Web, Mobile, Embedded und Infrastruktur hinweg liefern?» nicht mehr «kennen sie alle vier in gleicher Tiefe?». Er ist «können sie über die Architektur gut genug nachdenken, um einen Agenten zu steuern, der die Details erledigt?». Die Latte für architektonische Lesekompetenz ist gestiegen. Die Latte für stack-spezifisches Wissen ist gesunken.

Für uns bedeutet das, dass kleine Senior-Teams enorme Mengen Arbeit liefern. Sechs Personen in einem Projekt sind ausreichend, wenn jede dieser sechs glaubwürdig mehrere Agenten durch jeden Stack steuern kann, den die Arbeit erfordert. Wir spüren den Output von Teams zwei- bis dreimal unserer Größe, und das ist das Verhältnis, das wir am häufigsten von Gründern hören, die dieses Jahr mit uns gearbeitet haben.

Verschiebung 3. KI wird jetzt im Produkt selbst erwartet

Die dritte Verschiebung ist auf der Kundenseite, und die stärkste Version der Behauptung ist überzeichnet, also formulieren wir sie vorsichtig. 2023 war KI etwas, das man als Feature-Flag auf ein bestehendes Produkt aufsetzte. 2026 bemerken Kunden - sowohl Konsumenten als auch B2B-Betreiber - wenn ein Produkt, das sie ausprobieren, irgendwo eine intelligente Ebene hat und eine Alternative, die sie gerade ausprobiert haben, nicht. Intelligente Suche. Ein gesprächsbasierter Onboarding-Schritt. Ein Workflow, der den Entwurf der E-Mail schreibt, sodass der Mensch nur noch editiert. Ein Agent, der die langweilige Mitte einer Aufgabe übernimmt.

Das ist nicht in jeder Kategorie eine harte Anforderung. Wir tun nicht so. Was wir sagen, ist, dass es in Kundengesprächen häufiger auftaucht als vor einem Jahr, und die Richtung ist klar. Eine SaaS ohne eines davon 2026 zu liefern, ist zunehmend eine Positionierungsentscheidung, die verteidigt werden muss, nicht eine Standardannahme, die nicht verteidigt werden muss.

Der Rest dieses Beitrags besteht hauptsächlich aus Cases und Konsequenzen der drei Verschiebungen oben. Wir werden weiterhin darauf zurückkommen.

Im Maschinenraum

Es gibt eine Art von Unehrlichkeit in Agentur-Content über KI, die wir vermeiden wollen - das Framing «wir nutzen KI, um Projekte zu liefern» ohne Spezifität, die Zeile, die jede Beratung auf Erden in diesem Jahr schreibt. Hier also ist, was tatsächlich innerhalb von LANARS 2026 wahr ist, mit den Teilen, derer wir uns sicher sind, und den Teilen, die noch in Bewegung sind. Claude Code ist verpflichtend. Jeder Engineer bei LANARS benutzt es täglich, seit Anfang 2026, kein Opt-out.

Der größte Lift liegt am Anfang neuer Arbeit. Wenn wir uns an ein brandneues Projekt setzen, oder an ein neues Feature innerhalb eines bestehenden, ist die eingesparte Zeit nicht «ein bisschen». Sie ist um ein Vielfaches schneller als dasselbe Team 2024 vorangekommen wäre. Wir ziehen Scaffolding hoch, Datenmodelle, API-Oberflächen, die langweilige Mitte des UI, Test-Harnesses, Deploy-Konfiguration - alles vor dem Mittagessen an Tag eins. Der Rest des Projekts ist, wohin die menschliche Zeit geht, aber Zeit-bis-zum-aussagekräftigen-Prototypen ist kollabiert. Der Lift ist gleichmäßiger über die Disziplinen verteilt, als wir erwartet hatten. Backend, Frontend, Mobile, DevOps - alle bewegten sich ungefähr im Gleichschritt. Die Einschränkung in jeder Disziplin war das Tippen von Boilerplate, nicht der harte Teil. Die harten Teile sind immer noch hart. Sie sind nur nicht mehr von Stunden mechanischer Arbeit umgeben.

Monitoring zählt mehr, nicht weniger. Wenn Software günstiger zu schreiben wird, steigen die Kosten, nicht zu wissen, was in der Produktion passiert, weil die Dinge, die man nicht sieht, auch schneller versendet werden. Wir haben in Observability investiert - Logs, Traces, Error-Tracking, KI-gestützte Produktionsuntersuchungen - um mit der Geschwindigkeit Schritt zu halten, in der sich der Code ändert. Architektur ist die neue Gating-Fertigkeit. Wir stellen Seniors ein. Wir stellen 2026 keine Juniors ein, zumindest noch nicht, und das ist eine bewusste Entscheidung. Die Gating-Fertigkeit in einem agentengeführten Workflow ist architektonische Lesekompetenz - die Fähigkeit, anzuleiten, zu reviewen, schlechten Output abzulehnen. Diese Fertigkeit baut man nicht im ersten Jahr durch das Schreiben von CRUD-Endpoints auf. Man baut sie über ein Jahrzehnt auf.

Wir haben eine längere Version dieses Gedankens auf unserer AI-Strategy-2026-Seite, einschließlich, wie wir über Governance denken, den Unterschied zwischen Vibe Coding und KI-gestütztem Engineering, und das senior-only-Operating-Model. Die Kurzfassung von allem: Geschwindigkeit ohne Verständnis ist Schulden mit Frist.

Fallstudie eins. Lomundal: als sechs Beispiele genug waren

Lomundal ist ein norwegisches Bauunternehmen mit Sitz in Oslo, das Renovierungsprojekte in der Region durchführt. Ihre Kalkulatoren schauen sich eine Wohnung oder ein Haus an, entscheiden, was ersetzt werden muss, was geflickt werden kann, was strukturell ist, was kosmetisch ist, und erstellen einen detaillierten Kostenvoranschlag. Der Voranschlag muss detailliert sein - mehrere Gewerke, Abhängigkeiten zwischen Positionen, Materialien, Stunden, Eventualitäten - und er muss verteidigt werden können, wenn ein Kunde eine Position hinterfragt.

Der Engpass war nicht die Begehung. Wir hatten Lomundal bereits eine Flutter-iPad-App gebaut, die die Begehung selbst handhabt: strukturierte Datenerfassung vor Ort, Fotos, Sprachnotizen, sofortige PDF-Generierung. Der Engpass war die Kalkulationsphase danach. Wir haben dieses Projekt so begonnen, wie wir es 2024 begonnen hätten - indem wir versuchten, die Regeln aufzuschreiben. Wir saßen mit Senior-Kalkulatoren zusammen. Wir fragten, wie sie entschieden, was eingeschlossen werden sollte. Wir schrieben Dinge auf. Und wir stießen schnell an eine Wand. Es gab Hunderte von Positionen. Es gab Abhängigkeiten. Es gab «nun, es hängt davon ab, was sonst noch im Raum ist»-Urteile. Es gab Ausnahmen. Das Regelwerk war zu verworren, um es per Hand zu programmieren, ohne ein mehrjähriges Projekt, und Lomundal brauchte kein mehrjähriges Projekt.

Hier ändert 2026 die Antwort. Statt die Regeln zu programmieren, gaben wir Claude sechs historische Begehungsberichte gepaart mit den entsprechenden Voranschlägen, die Lomundal erstellt hatte. Sechs. Wir sagten ihm: finde die Regeln heraus. Schreib sie auf. Das tat das Modell. Der Output war ein langes, strukturiertes Regeldokument, das sich las wie dieselbe Logik, die Lomundals Kalkulatoren im Kopf hatten, aber explizit. Die Kalkulatoren lasen es, korrigierten die Teile, die falsch waren, fügten die impliziten Beschränkungen hinzu, die Claude verpasst hatte, und übergaben es uns zurück.

Dieses Dokument lebt nun innerhalb der Make.com-Pipeline, aufgerufen über das Anthropic-Modul. Eine neue Begehung kommt als PDF an. Make übergibt das PDF an Claude mit dem angehängten Regeldokument. Claude produziert die Positionen. Ein kleiner Post-Processor formatiert sie in die Excel-Vorlage des Unternehmens. Die Aufgabe des Kalkulators ist nicht mehr «den Voranschlag von Grund auf aufbauen». Sie ist «die Excel-Datei prüfen, dort anpassen, wo Claude falsch lag, sie versenden». Was früher eine zwei- bis dreistündige Aufgabe pro Voranschlag war, ist jetzt ein etwa dreißigminütiger Review-Durchgang. Die Pipeline ist in früher Produktion - weniger als fünfzig Voranschläge sind zum Zeitpunkt des Schreibens durchgelaufen - aber die Zeitersparnis war über die Charge hinweg konsistent.

Der andere Vorteil ist Zuverlässigkeit. Manuelle Kalkulation in dieser Komplexität ist genau die Art von Arbeit, bei der eine müde Person um fünf Uhr nachmittags eine Zeile übersieht, eine Abhängigkeit überspringt oder einen Aufschlag vergisst. Die Claude-derivative Pipeline produziert jedes Mal den vollständigen Output. Das Review des Kalkulators fängt den seltenen Fall ab, in dem das Modell den Bericht falsch gelesen hat; das Modell fängt die Fälle ab, die der Kalkulator übersehen hätte.

Die Lektion aus Lomundal geht weit über das Bauwesen hinaus. Das ist ein Muster, kein Einzelfall. Fast jedes KMU hat irgendeine Version davon in seinem Betrieb lauern - ein Buchhaltungsteam, das ungeschriebene Regeln befolgt, wie eine Rechnung zu kategorisieren ist, ein Ops-Team, das weiß, welche Bestellungen zur Überprüfung markiert werden müssen, ein Support-Team, das weiß, wann eskaliert werden muss. Das Muster ist in jedem Fall dasselbe: paaren Sie historische Beispiele mit ihren Ergebnissen, bitten Sie Claude, die Regeln zu schreiben, prüfen und korrigieren, dann betreiben. Das Detail mit sechs Beispielen sollte die Schlagzeile sein, nicht eine Fußnote - die Kosten, dies an einem Workflow innerhalb des eigenen Unternehmens zu versuchen, sind weitaus geringer, als die meisten Betreiber annehmen.

Das ist der Teil von «KI für KMU», den wir 2026 für am wenigsten diskutiert halten. Alle reden über Chatbots. Der größere kurzfristige ROI für kleine Betreiber liegt hier - KI als Werkzeug zu nutzen, um die implizite Logik zu extrahieren und anzuwenden, nach der das Unternehmen bereits operiert.

Fallstudie zwei. SelectAI: ein norwegisches Aquakultur-Startup, sechs Monate vom Konzept zum Pilot

Die andere Fallstudie ist ein Startup, kein KMU. Es ist das sauberste Beispiel, das wir dafür haben, wie AI-native Entwicklungsgeschwindigkeit Ende-zu-Ende tatsächlich aussieht.

SelectAI ist ein norwegisches Aquakultur-Startup. Seeläuse sind eines der größten wirtschaftlichen und tierwohlbezogenen Probleme in der norwegischen Lachszucht; die übliche Praxis zur Messung der Lausebelastung besteht darin, fünfzehn bis zwanzig Fische pro Käfig jede Woche herauszunetzten und von Hand zu zählen. Die Stichprobengröße ist klein genug, dass ein Ausbruch eine Woche entfernt sein kann, bevor jemand ihn in einem Bericht sieht. SelectAIs Antwort ist eine schwimmende In-Käfig-Einheit, die SelectAI 350, die jeden Fisch aus drei synchronisierten Kamerawinkeln erfasst, während die Fische freiwillig durch einen Analysekanal schwimmen. Ein Computer-Vision-Modell klassifiziert jeden Fisch - Lausekategorien, die der Taxonomie von Mattilsynet entsprechen, Tierwohlindikatoren, juvenile Läuse, die manuelle Zählungen oft übersehen. Etwa tausend Fische pro Sitzung statt fünfzehn.

LANARS hat die Firmware und Software in Partnerschaft mit AI Experts gebaut, einer KI-Firma aus der Region Grimstad. Ich sitze im Vorstand von SelectAI, also halte ich die Trophäenliste kurz - was hier bemerkenswert ist, ist der Zeitplan. Vom Konzept zu einer funktionierenden Hardware-Einheit, validierter Software, einer Annotationspipeline, die von Biologen verwendet wird, und Piloten auf echten norwegischen Farmen: sechs Monate. Das Team besteht aus drei Personen. 2024 hätte ein Projekt mit diesem Umfang anderthalb Jahre mit einem doppelt so großen Team gedauert. Die interessante Designentscheidung ist eine, bei der wir einen Moment verweilen wollen, weil sie Verschiebung 2 (kleine Senior-Teams) und Verschiebung 3 (KI im Produkt) gleichzeitig erfasst: die Hardware wurde um das Modell herum entworfen, nicht umgekehrt.

Das Drei-Winkel-Kamera-Layout existiert, weil das Modell drei synchronisierte Ansichten benötigt, um zu vermeiden, denselben Lachs auf beiden Seitenflanken doppelt zu zählen. Wir bauten den Rig um das herum, was das Modell brauchte - übrigens patent pending. Das ist eine kleine Sache an der Oberfläche, aber eine große darunter: 2024 hätten wir den offensichtlichen Einzelkamera-Rig gebaut und den Datenqualitätsverlust als physikalisches Gesetz akzeptiert. 2026 hat das Modell ein Vetorecht über die Hardware-Spezifikation, weil das Modell das Produkt ist.

Der Validierungszyklus ist schnell, aus dem gleichen Grund, aus dem jedes andere 2026-Projekt schnell ist: die Kosten, ein weiteres Werkzeug zu bauen, sind gering. Wenn das SelectAI-Team eine maßgeschneiderte Ansicht braucht, wie das Modell in einem bestimmten Käfig abgeschnitten hat, wird diese Ansicht in derselben Woche ausgeliefert, nicht in einer Quartalsplanung. Das Annotationswerkzeug selbst, das von Biologen über mehrere norwegische Standorte hinweg verwendet wird, wurde in diesem gleichen Zyklus gebaut und überarbeitet.

Wir werden drei Traktionspunkte erwähnen und dort aufhören, weil die Lektion in der Geschwindigkeit liegt, nicht in der Trophäensammlung: fünfzehntausend Fische bisher analysiert, Feldvalidierung bei Varde Fiskeoppdrett und Lerøy unter echten Winterbedingungen, und Förderung von Innovasjon Norge. Das Hauptziel - Mattilsynet-Zulassung als automatisiertes Lausezählsystem, das manuelle Zählungen auf Behördenniveau ersetzen würde - zielt auf Ende 2026 ab.

Die Version dieser Geschichte, die Betreiber und Gründer lesen sollen, ist: kleines Team, kurzer Zyklus, KI im Bauprozess und im Produkt gleichzeitig, Hardware um das Modell herum entworfen, Feldvalidierung innerhalb des ersten Jahres. Nichts davon war 2024 Routine. All das ist 2026 Routine.

Was das für Gründer bedeutet

Die größte Veränderung für einen Startup-Gründer 2026 sind die Kosten des Ausprobierens. Die «Idee-testen»-Phase eines Startups kostete früher sechs Monate und den Großteil einer Seed-Runde. In vielen Kategorien kostet sie jetzt zwei Wochen und einen Bruchteil davon. Die Muster, die uns ein Jahr kosteten, um sie für StartUpLab-Teams 2018 aufzubauen, sind heute Wochenend-Übungen.

Das hat zwei Gründer-Kohorten gleichzeitig hervorgebracht, und es ist wert, beide zu benennen, weil sie das Geräuschniveau des Startup-Marktes für die nächsten zwei Jahre definieren werden.

Eine Kohorte ist der Wannabe-Vibe-Coder - Solo-Gründer mit Koffein und einem Coding-Agenten, die Prototypen ausliefern, die kein echtes Problem lösen. Die meisten überstehen kein Quartal. Echtes Geräusch im Markt deswegen: Investoren sehen mehr Pitches, Einstellen ist lauter, Aufmerksamkeit ist schwerer zu bekommen. Die andere Kohorte ist der Gründer, für den echter Wert jetzt schneller den Markt erreicht. Das sind Leute, die das richtige Problem hatten und immer das Richtige bauen würden - sie mussten nur sechs Monate auf ein MVP warten. Jetzt warten sie sechs Wochen. Die Feedback-Schleife beginnt früher. Die guten sehen aus wie SelectAI: echte Partner, echtes Geld, echte Validierung innerhalb des ersten Jahres.

Für Gründer, die 2026 Kapital aufnehmen - hier ist eine konkrete Rahmung, von der wir erwarten, dass Investoren innerhalb der nächsten sechs Monate auf sie konvergieren. Ein Startup, dessen MVP länger als acht Wochen gedauert hat, sollte bereit sein zu erklären, warum - entweder war der Umfang ungewöhnlich tief (regulierte Branche, neuartige Hardware, echte ML), oder es lief etwas schief, wie das Team an den Build heranging. Der Benchmark hat sich verengt, und er wird sich weiter verengen.

Die strategische Implikation ist unbequem. Die Latte, um bemerkt zu werden, ist höher, weil das Geräusch lauter ist; die Latte, um echt zu sein, ist niedriger, weil das Ausliefern günstiger ist. Distribution, Geschmack, und die Fähigkeit, mit Kunden zu sprechen - die Teile, die KI nicht macht - sind jetzt die tatsächliche Einschränkung. Engineering-Kapazität ist es nicht.

Was das für Betreiber bedeutet

Für ein kleines oder mittelständisches Unternehmen, das einen bestehenden Betrieb führt, ist die Antwort anders, und wohl unmittelbar profitabler.

Die Lomundal-Geschichte ist die Vorlage. Finden Sie einen repetitiven, gut definierten Vorgang innerhalb Ihres Unternehmens - normalerweise einen, der die Zeit einer Senior-Person als Engpass hat. Kalkulieren, Klassifizieren, Entwerfen, Triagieren, Berichten, Zusammenfassen. Wählen Sie den mit den saubersten Inputs und Outputs. Bringen Sie einen Make.com- oder äquivalenten Workflow zum Laufen. Hardcoden Sie den Prompt. Schließen Sie einen Kunden oder ein internes Team daran an. Messen Sie einen Monat lang. Wir sehen zwei Fehlermuster konsistent.

Das erste ist, den auffälligen Use-Case zuerst zu wählen. Der auffällige Use-Case ist üblicherweise kundenseitig und mit hohem Einsatz. Es ist der falsche Ort zu beginnen. Beginnen Sie mit dem langweiligen internen Workflow, von dem niemand begeistert ist. Eine fehlerhafte kundenseitige KI-Funktion blamiert Sie vor Nutzern. Ein fehlerhafter interner Workflow blamiert Sie nur vor sich selbst, was das bessere Klassenzimmer ist.

Das zweite ist, nicht zu messen. KI-Funktionen, die ab Tag eins nicht instrumentiert sind, verrotten leise. Modell-Drift, Prompt-Regressionen, Edge-Cases, die einmal im Monat auftauchen - diese sind ohne Observability nicht sichtbar. Die gleiche Disziplin, die für jeden Produktionsservice zählt, zählt für KI-Workflows, und wohl mehr, weil die Fehlerarten seltsamer und weniger mechanisch sind.

Was den ROI angeht, eine ehrliche Beobachtung statt eines Versprechens. Über die KMU-Aufträge, die wir 2025 und 2026 durchgeführt haben und die in der Form Lomundal ähneln - abgegrenzter interner Workflow, schmale Inputs, schmale Outputs - sehen wir typischerweise Betriebszeit-Reduktionen im Bereich von fünf bis zehn Mal, und Amortisation des Builds innerhalb von einem bis drei Monaten. Die Varianz ist groß. Die Projekte mit den saubersten historischen Daten und dem geduldigsten Review-Zyklus liegen am oberen Ende des Bereichs; die Projekte, die zu viel auf einmal versuchen, am unteren Ende. Behandeln Sie diese Zahlen als Orientierungsrahmen, nicht als Angebot.

Der 2026-Stack (CTO-Notiz)

Wenn Sie 2026 als CTO Technologie auswählen, hier ist die kurze, meinungsstarke Version. CEOs ohne CTO im Raum können weiter überspringen, ohne etwas Wichtiges zu verpassen.

Auf der Web-Seite ist das Prinzip, ein Framework mit erstklassiger Unterstützung für Streaming und Partial Rendering zu wählen, auf einer Plattform deployed, die volles Node.js (nicht nur Edge), lange Function-Timeouts und Instanz-Wiederverwendung für KI-Workloads bietet. Das sind 2026 keine exotischen Anforderungen; das ist Tischwäsche.

Für den Modell-Zugriff ist die hebelstärkste Entscheidung, durch ein Modell-Gateway zu routen statt direkt zu einem einzelnen Anbieter. Provider-Strings machen den Modellwechsel zu einer einzeiligen Änderung. Fallback-Routing handhabt Provider-Hicks. Zero Data Retention sollte der Standard sein. Vereinheitlichte Abrechnung bedeutet weniger Rechnungen zu jagen. Das Gateway ist der Teil jedes KI-Stacks, der sich in unseren Projekten am schnellsten amortisiert hat, mit großem Abstand.

Für Storage, bevorzugen Sie managed Postgres, managed Redis für Hot-Path-Caches, und managed Object-Storage für Uploads, alles provisioniert durch einen einzigen Marktplatz, sodass Umgebungsvariablen dort landen, wo sie sollen, ohne manuelle Klempnerarbeit. Für Auth, ein managed Identity-Service mit Middleware-basierten Session-Checks. Für Mobile, ein cross-platform Framework, zu dem das gleiche agentengetriebene Engineering-Muster natürlich passt; wir haben Flutter sowohl bei Lomundal als auch bei SelectAI aus diesem Grund verwendet.

Dieser Stack ist meinungsstark, weil die Meinungen die Zeit zurückverdienen. Ein Team, das etwas anderes wählt, kann absolut Erfolg haben - aber sie werden Gründer-Stunden mit Infrastrukturentscheidungen verbringen, an die sich in zwei Jahren niemand mehr erinnert. Wir verbringen diese Stunden lieber mit dem Produkt.

Wo es bricht

Die Risiken 2026 sind nicht die Risiken, über die sich Leute 2023 Sorgen gemacht haben. «Wird KI Entwickler ersetzen» ist kein 2026-Gespräch. Die echten Risiken sind leiser, und es geht mehr um Disziplin als um Technologie. Aufgelistet ungefähr in der Reihenfolge, in der sie norwegische Betreiber, mit denen wir arbeiten, am häufigsten beißen.

Daten-Governance. Für norwegische Unternehmen, die regulierte Branchen bedienen - Gesundheit, Finanzen, alles, was die DSGVO-Landschaft berührt - muss die Frage, wohin Daten gehen, wenn sie an ein LLM gesendet werden, beantwortet werden, bevor der erste Prototyp ausgeliefert wird. Die zwei praktischen Standards: durch ein Gateway mit Zero Data Retention routen, und Anbieter mit expliziten DSGVO-Auftragsverarbeitungsverträgen und regionalen Deployment-Optionen wählen. Wir haben dieses Gespräch mit mehreren norwegischen KMUs geführt, und es ist selten so kompliziert, wie ihr Rechtsteam zunächst befürchtet, aber es muss explizit beantwortet werden, nicht implizit. Das Risiko ist nicht, dass der Regulator Sie erwischt; das Risiko ist, ein Feature zu liefern, das Sie später herausreißen müssen, weil es nicht verteidigt werden kann.

Halluzinationen in Produktions-KI-Funktionen. Das ist das Risiko, das die meisten Teams in ihrer zweiten KI-Funktion unterschätzen, nachdem die erste funktioniert hat. Produktionsmodelle werden gelegentlich eine selbstbewusste Antwort produzieren, die falsch ist. Das Muster, das das eindämmt, ist dasselbe, das jedes andere Zuverlässigkeitsrisiko eindämmt: die Oberfläche dessen begrenzen, was das Modell sagen darf, seine Antworten in abrufbaren Daten verankern, wo möglich, Outputs gegen ein Schema validieren, bevor sie einen Nutzer erreichen, und so instrumentieren, dass Sie die Fehlerarten früh sehen. Halluzinationen sind kein Problem der Forschungsphase; sie sind ein Engineering-Problem mit bekannten Gegenmaßnahmen, und sie sollten ein Checklist-Punkt sein, keine Hoffnung.

Code ohne Verständnis. Das häufigste Versagensmuster in Teams, die Agenten ohne Disziplin einführen, ist das Ausliefern von Code, den sie nicht vollständig verstehen. Kompiliert, Tests bestehen oberflächlich, und sechs Wochen später bricht etwas Subtiles in der Produktion, ohne dass jemand im Team das Kaputte schnell genug lesen kann, um es zu reparieren. Die Gegenmaßnahme ist das senior-only-Modell, über das wir oben geschrieben haben - Reviewer, die mit der Rate des generierten Codes Schritt halten können, ohne das Verständnis zu verlieren. Geschwindigkeit ohne Verständnis ist Schulden mit Frist.

Anbieter-Lock-in als Margen-Frage. 2023 war das eine Belästigung. 2026, mit wöchentlichen Modell-Releases und Preisunterschieden von Größenordnungen zwischen Kapazitätsstufen, ist es eine Margen-Frage. Architektieren Sie jedes Projekt so, dass Provider und Modell Konfigurationswerte sind, kein Code. Die Kosten, das zu tun, sind gering; die Kosten, es nicht zu tun, akkumulieren monatlich.

Die neue Bereitschaft. KI-generierter Code, der in der Produktion bricht, braucht einen Menschen, der den Fehler, den Diff, den Trace und die Argumentation des Modells lesen und entscheiden kann, was zurückzurollen ist. Die Aufgabe des Bereitschafts-Engineers hat sich von «reparier es» hin zu «beurteile es» verschoben. Das traditionelle Senior-Engineer-Fertigkeitenset ist wertvoller geworden, nicht weniger.

Ein praktischer 90-Tage-Plan

Wenn Sie ein KMU führen und testen wollen, was KI für Ihren Betrieb tun kann, hier ist die Form der ersten neunzig Tage, die für uns am konsistentesten funktioniert.

Tag 1 bis 14. Wählen Sie einen Workflow. Den einen repetitivsten, gut definierten, risikoarmen Workflow innerhalb des Unternehmens. Eine Antwort entwerfen, einen Datensatz zusammenfassen, einen Upload taggen, einen Voranschlag aus einem Bericht generieren. Vermeiden Sie den kundenseitigen. Vermeiden Sie den, der «erstaunlich wäre, wenn er funktionieren würde». Beginnen Sie mit dem langweiligen, dessen Inputs und Outputs Sie in einem Absatz beschreiben können.

Tag 15 bis 30. Liefern Sie die kleinstmögliche Version. Make.com oder äquivalent. Hardcoden Sie den Prompt. Ein interner Nutzer. Instrumentieren Sie jeden Input, jeden Output, jeden Modell-Call. Überspringen Sie nicht die Instrumentierung. Sie ist das ganze Spiel.

Tag 31 bis 60. Fügen Sie die Datenschicht hinzu. Wenn der Workflow von Ihren historischen Daten profitiert - und das tut er fast immer, wie Lomundal zeigt - geben Sie Claude historische Beispiele und lassen Sie das Modell die Regeln ableiten. Prüfen Sie mit dem Fachexperten. Korrigieren Sie die offensichtlichen Fehler. Geben Sie sie an die Pipeline zurück.

Tag 61 bis 90. Industrialisieren. Versionieren Sie den Prompt. Fügen Sie ein Fallback-Modell hinzu. Verschieben Sie das Regeldokument in die Versionskontrolle. Fügen Sie ein kleines Evaluations-Harness hinzu, das gegen ein eingefrorenes Set historischer Beispiele läuft, wann immer Prompts oder Regeln sich ändern. Dokumentieren Sie, was der Workflow tut und was er nicht tut.

Bis zum neunzigsten Tag macht der Workflow echte Arbeit, die Infrastruktur ist da, um die nächsten zehn Workflows ohne Neubau hinzuzufügen, und das Team hat das Muster verinnerlicht.

Häufig gestellte Fragen

 

1. Was bedeutet «AI-native Entwicklung» 2026 eigentlich?

Zwei Dinge gleichzeitig. Der Engineering-Workflow nutzt KI-Werkzeuge - Coding-Agenten, AI-Code-Review, KI-gestütztes Testing - als täglichen Standard, nicht als Experiment. Das Produkt selbst wird mit KI als primärer Fähigkeit ausgeliefert - Chat, Retrieval-Augmented Search, autonome Workflows - statt als nachträglich angeheftetes Add-on.

2. Wie lange dauert es 2026, ein MVP zu bauen, verglichen mit 2024?

Zwei- bis fünfmal schneller in unserer Erfahrung, abhängig vom Umfang. SelectAI hat ein funktionierendes Hardware-plus-Software-Produkt in sechs Monaten mit einem Team von drei Personen ausgeliefert - ein Projekt, das 2024 anderthalb Jahre mit einem doppelt so großen Team gedauert hätte. Für reine Software-MVPs sind drei bis acht Wochen realistisch für das, was früher drei bis sechs Monate dauerte. Die übrige Zeit geht in Produkturteilskraft, Kundengespräche und Design - nicht ins Engineering.

3. Kann KI mein MVP ohne Engineers bauen?

Für ein echtes Produktions-MVP - mit Auth, Zahlungen, Dateneigentum, einem Weg zur Skalierung - nein. KI-Werkzeuge beschleunigen Engineering, aber ein Mensch wird gebraucht, um architektonische Entscheidungen zu treffen, Änderungen zu reviewen, Sicherheit zu besitzen und Produkt-Trade-offs zu beurteilen. Eine realistische 2026-Zahl ist ein Engineer (oder ein technischer Gründer), der die Arbeit eines 2023-Teams von drei bis fünf macht.

4. Ist KI-generierter Code sicher in die Produktion zu schicken?

Mit einem normalen Engineering-Workflow - Review, Tests, CI, Observability, Bereitschaft - ja. KI-generierter Code wird 2026 jeden Tag in Produktion bei Unternehmen jeder Größe ausgeliefert, einschließlich unseres. Das Muster, das scheitert, ist «ohne Review ausliefern». Das Muster, das funktioniert, ist dasselbe wie vor KI: kleine Diffs, Tests, Review, Observability.

5. Welches Modell soll ich für mein Produkt wählen?

Routen Sie durch ein Gateway. Wählen Sie ein Frontier-Modell für qualitätskritische Pfade, ein kleineres schnelleres günstigeres Modell für hochvolumige risikoarme Pfade. Der spezifische Gewinner bei Qualität und Preis ändert sich monatlich; die architektonische Antwort - Modell als Konfigurationswert, nicht als Code-Änderung - nicht.

6. Müssen wir ein eigenes Modell trainieren?

Fast nie. Über die Projekte, die wir 2025 und 2026 ausgeliefert oder geprüft haben, haben weniger als eines von zwanzig vom Training eines Modells von Grund auf profitiert. Der Rest holt mehr Hebel aus Frontier-Modellen kombiniert mit gutem Retrieval, guten Prompts und guter UX. Die Ausnahmen sind domänenspezifische Vertikalen, die im Maßstab mit proprietären Daten arbeiten - SelectAIs Computer-Vision-Modell ist eines, weil Off-the-shelf-Modelle nicht wissen, wie eine norwegische Seeläuse aussieht.

7. Was ist der Unterschied zwischen SEO und AEO?

SEO (Suchmaschinenoptimierung) reiht Inhalte in klassischen Suchmaschinenergebnissen ein. AEO (Answer Engine Optimization) bringt Inhalte dazu, von KI-Antwort-Engines zitiert zu werden - Perplexity, ChatGPT, Claude, Google AI Overviews - wenn sie auf Nutzerfragen antworten. AEO bevorzugt klare Faktenaussagen, explizite Frage-und-Antwort-Blöcke, gut strukturierte Überschriften und entitätenreiche Inhalte, die ein Modell extrahieren und zitieren kann.

8. Wo in unserem Produkt sollten wir mit KI anfangen?

Mit dem langweiligen internen Workflow, von dem niemand begeistert ist. Das auffällige kundenseitige Feature ist mit hohem Einsatz; eine fehlerhafte KI-Funktion, die Kunden gezeigt wird, beschädigt Vertrauen. Ein fehlerhafter interner Workflow blamiert Sie nur vor sich selbst, was das bessere Klassenzimmer ist.

Engineering-Kapazität war früher die Einschränkung. Sie ist es nicht mehr. Die Einschränkung ist das, was immer schwieriger war - zu wissen, was zu bauen ist.