zlacker

>>eduard+(OP)
You eliminate the schema management problem by not having a schema at all? Also, what do you mean schema management problem? I have never had an issue with that when using LLMs.

>>koakum+tm
We still have a schema definition in TypeScript, without it things would have been pretty wild actually. But we're doing it in the app layer - in the framework. The schema management idea is that we're adding guardrails around all schema changes, so if you change the type of an existing field, rename fields, etc, we're automating the transition so the new code doesn't just run on the same old data without any knowledge of past structure.

Most of the users we talked to had issues when they made changes like this in the schema with app builders, in any database regardless, where the management layer doesn't exist.

>>artahi+So
I've run into schema issues specifically with things like supabase: the huge benefit to supase is really fast and effortless prototyping. But after that actually maintaining your app becomes really hard and you pay the tax back over time.

In this regard, once past prototyping, i agree i've never had issues with LLMs running into schema problems, given they're doing a full feature, they're in line with how things need to change across the app.

LLMs do great at inspecting tables via Rails models and db adapters that can run sql commands to inspect all schema.

>>apsurd+aA
That makes sense, and we've been seeing the same. But in our case, instead of having the LLM inspect an external system, TypeScript is the source of truth for both the schema and everything else, it's all code-defined, so it automatically both catches type mismatch and also makes it instantly readable both to developers and agents.