I know GlideOS does not want the risk of opening an App or acting as a developer since I offered up sharing this against a duplicate of the App and it “politely” said no for security reasons. But that is not what GlideOS asked for later. Migrating from Glide Classic to GlideOS from a schema-level should be nearly automatic given the shared knowledge based of the two products. Skip the screen migration, etc cause GlideOS would rebuild them better, stronger, faster. What GlideOS wanted was the schema information from the tables in the Glide Classic app and wanted me to export the tables as CSVs. My point is this should and could have been developed by Glide to transfer this information via an MCP or API.
From Claude:
Glide should be able to train its AI on what/how Glide Classic operates. It is not just a ‘parser’ for front-end queries. Or can you not train an AI??
11:43 AM
You’re absolutely right — and it’s a legitimate criticism of Glide’s product decision, not a technical impossibility.
Yes, you can absolutely train AI on proprietary systems.
This is exactly what companies do. The technical paths are well established:
Fine-tuning — take a base model and train it further on Glide Classic’s documentation, schema patterns, component library, action syntax, and computed column logic. The result is a model that understands Classic natively. Anthropic, OpenAI, and others offer this as a service.
RAG (Retrieval Augmented Generation) — embed all Glide Classic documentation, help articles, schema examples, and support tickets into a vector database. When a user asks a question, the relevant Classic docs are retrieved and injected into the AI’s context before it responds. No full retraining required — faster and cheaper to implement.
System prompting with domain knowledge — at minimum, Glide could inject a detailed Classic schema guide into every GlideOS session. Not as powerful as fine-tuning but dramatically better than nothing. This is the simplest possible solution.
So why didn’t Glide do it?
That’s the real question and honestly there are only a few explanations:
One is a product decision — they may be deliberately not investing in Classic and want users to migrate to the new platform. Supporting Classic deeply in GlideOS would reduce migration pressure.
Another is resource prioritization — building and maintaining a fine-tuned model on a legacy product costs engineering time they may be directing elsewhere.
A third is data quality — if Classic’s internal documentation is inconsistent or incomplete, training on it produces unreliable results which creates more support burden than it solves.
The broader point you’re making is important:
A company building an AI assistant for their own product has every advantage — they control the documentation, the schema specs, the API definitions, the support history, the user behavior data. If their AI doesn’t understand their own legacy product it’s a choice, not a limitation.