Autor: Elfi Rosenbaum

Stop Prompting. Start Engineering. Fast jeder spricht über Prompt Engineering. Aber was passiert, wenn ein LLM-System über einen einfachen Chatbot hinauswächst?

Die Idee, KI-Agenten als primäres Werkzeug in der Softwareentwicklung einzusetzen, wird derzeit breit diskutiert. Die Versprechen reichen von massiver Produktivitätssteigerung bis hin zur vollständig autonomen Code-Generierung. Die Praxis sieht erwartungsgemäß differenzierter aus. In diesem Beitrag berichten wir aus fünf Wochen Projektarbeit, in denen ein AI-Agent, konkret Claude Code von Anthropic, als primäres Entwicklungswerkzeug eingesetzt wurde. Dabei zeigen wir, wo sich die Produktivität tatsächlich verändert hat, wo sie gleich geblieben ist und welche neuen Herausforderungen entstanden sind, die in klassischer Softwareentwicklung so nicht existieren.

Die Landschaft der künstlichen Intelligenz hat in den letzten Jahren eine bemerkenswerte Transformation durchlaufen. Was einst massive Rechenzentren und spezialisierte Teams erforderte, wird nun für Unternehmen und einzelne Entwickler gleichermaßen zunehmend zugänglich. KI ist zu einem entscheidenden Bestandteil vieler Anwendungen geworden, und das Self-Hosting von KI-Modellen kann größere Kontrolle, Datenschutz und Anpassungsmöglichkeiten bieten, die cloud-basierte Lösungen einfach nicht erreichen können.

Ob Chatbot, Business-Agent oder Automatisierungstool, eines haben viele moderne KI-Anwendungen gemeinsam: Sie brauchen Kontext. Nur wenn ein System weiß, wer was wann getan hat, kann es sinnvoll reagieren. Technologien wie Semantic Kernel, MCP und Remote-Server liefern gemeinsam das Fundament, auf dem solche kontextbasierten Lösungen nicht nur funktionieren, sondern auch skalierbar und unternehmensweit einsetzbar sind.

SSDT (SQL Server Data Tools) in Visual Studio ist ein leistungsstarkes Werkzeug für die Entwicklung und Verwaltung von Datenbanken, insbesondere in Microsoft SQL Server. Es ermöglicht die Modellierung, Entwicklung und das Testen von Datenbanken direkt innerhalb der gewohnten Entwicklungsumgebung. Für Datenbanktests ist SSDT besonders geeignet, da es die Erstellung von Unit Tests für Stored Procedures, Funktionen und Datenbanklogik unterstützt, wodurch die Qualität und Stabilität des Codes sichergestellt werden kann.

Bisher haben wir unseren ASA SQL Code ausschließlich analytisch migriert, durch das Definieren einer Grammatik, das Parsen in einen AST und diverse Visitoren, die den Baum in eine neue Variante überführt haben. Jetzt wollen wir mal schauen, was eine KI zu diesem Prozess beitragen kann.

Im zweiten Teil unserer Serie zur Migration von SQL Anywhere zu Microsoft SQL Server tauchen wir tiefer in die Herausforderungen und Lösungen bei der Übertragung von Code-Entitäten wie Views, Functions, Procedures und Trigger ein.

In diesem Artikel geht es darum die Grundlagen für eine SQL Anywhere Migration zu legen. Dazu gehören: Export des Datenbankschemas, Teil-Erzeugen der Datenbank auf dem MSSQL Server, Übernahme der Daten aus der ASA Datenbank, Erzeugen der Indices und Constraints, Exportieren der Code Entitäten aus der ASA-DB

SQL Anywhere, im Folgenden kurz ASA genannt, war in der Vergangenheit eine beliebte Wahl für Applikationen, deren Backend SQL gestützt sein sollte. Wir im Hause Fischer & Consultants waren von dem Produkt sehr überzeugt und haben es für viele unserer Kundenprojekt eingesetzt. Im Laufe der Jahre haben wir dann auch den Vertrieb der ASA übernommen, das ist jetzt vorbei!