AIDBDeveloper: Integrating AI, Databases and Applications

Some time ago, I published an AI-integrated chess database application on this blog. That project was already an experiment in making AI part of the application itself, rather than simply placing a chatbot next to it.

AIDBDeveloper is the natural evolution of that idea.

In fact, the story began before AI. I first developed the database side, with a common abstraction layer and separate implementations for Oracle, SQL Server and MySQL. When I started working seriously with language models, I applied the same pattern: one abstract AI layer, with separate implementations for each provider.

The first one was OpenAI. Google came later. As a curiosity, Claude generated the initial Google implementation using the OpenAI version as a reference; I then had to integrate it, fix the problems and make it actually work. It was a useful sign that the architecture was becoming standardized enough for one implementation to serve as a model for another.

As database services, AI and application components became increasingly interconnected, the growing complexity forced me to reorganize the whole project around three main areas: application, databases and artificial intelligence.

AIDBDeveloper is the application that brings all of this together. It is intended as a general platform for R&D and training, where different applications can be assembled from reusable dashboard components: SQL editors, grids, charts, documentation tools, file managers, configuration tools and, of course, AI-related components.

One of the most important parts of the design is context management.

AIDBDeveloper keeps the AI context in its own internal format, independently of any specific provider. It is then translated into whatever format OpenAI, Google or any future provider requires. This makes it possible to use different models within the same conversation and gives the application full control over the information sent to each one.

Messages can be edited, deleted or disabled without being removed from the conversation. The application can add or remove parts of the context whenever necessary, and tool calls and their results can also be edited manually. It is even possible to create examples of tool usage that never actually happened.

The application also collects token usage data directly from provider APIs, which will become particularly useful in the experiments I will publish next.

In the video below, I give a general tour of the architecture, dashboards, AI console, context management, tools and some of the ideas behind making AI a real part of the application instead of an external add-on.

This is only the starting point. In the next articles I will use the platform for more concrete experiments, beginning with a text-analysis workflow involving thousands of requests and millions of tokens.

Thanks for reading, and see you next time.