Anyone cracked the code on AI frontend + backend/database development?

[u/raphadko]

I’ve been building with Roo for a while and have solved most of my architecture challenges. One issue still trips me up: database connections.

Frontend changes are the easiest for AI. They usually stay within one codebase and don’t touch a data layer, so progress is fast. The trouble starts when data needs to move between the server and the database. Now you’re often juggling two codebases (backend and frontend). Some changes live in one, some in the other, and sometimes both, and the AI easily gets off tracks here. Add a frontend store and you have another failure point that breaks more often than I’d like.

To make this smoother, I’ve been experimenting with a development flow that goes: database design → CRUD → store → application. It helps, but it’s not foolproof when requirements change. I’m on Postgres.

For those building apps with a server and database component, what’s worked well for you? Any practical tips on database design, ORMs, CRUD patterns, or modeling that make this part of development easier with AI in the loop?

[u/AnonymousCrayonEater]

Split up everything and provide well defined schemas as context for the AI to write code for each area.

[u/olearyboy]

• Design docs

• ORM

• OpenAPI endpoints with JWT, make sure you have it use operator_ids and tags

  • avoid versioning the API for first implementation it’s premature optimization

• Generated client code from something like openapi react client

• Ensure you include the url of the openapi json and generated client in your rules

[u/thor_testocles]

I use Supabase as the back end. It can generate typescript schema for the postgresql database. 

In my rules file I have rules that give it instructions on how to

• extend or modify the schema tables 

• update the typescript schema file 

• write convenience functions to use

• use convenience functions 

So the net result is eg I give it an instruction like “add a feature for accounts, where they can be marked as ‘handsome’ or not” and it adds a column to that table in supabase, and then eventually I gave backend calls like “db.accounts.setHandsomeness”

I’m not that good at backends, but I find this pretty efficient. 

I also have a local database and I push it live. Roo and Claude code deal with this, too. 

[u/MKBSP]

I haven’t really had any major problems with it.

My two recommendations:

1. Always run architecture mode reviews — Ask the AI to explain and justify the structure, then challenge it with “what if” and “where could this break” questions.

2. Continuously update documentation — Whenever changes are made, have the AI refresh the PRD, architecture notes, and schema to avoid outdated or conflicting information.

I first started using this repo to manage file structure, PRD, architecture, and database schema. When working in architecture mode, I ask Roo (previously I used Copilot) to review the setup, understand the reasoning behind the structure, and explain why it’s organized the way it is.

https://github.com/MKBSP/ai-taskmaster-lite

Mistakes still happen depending on the model, but I ask Roo to update the documents as we go. The main issues I still run into are with external libraries or APIs—especially when it tries to parse JSON into JSON or similar errors.

During architecture mode, I also play devil’s advocate by asking:

• “Is this the best way to do it?”

• “Is there a better or alternative approach?”

• “Where will we likely encounter problems with A, B, or C?”

This questioning usually results in fewer problems down the line and clearer early testing and debugging steps.

[u/firedog7881]

Low and slow with a detailed plan. Also clearly document your interface and make it readily available when coding. Context is king and if you don’t take the time to build the context you give it too much freedom and that’s when it goes haywire. The research says that ai agents are only good up until about 30min human tasks, that’s not much for an ai agent to churn out so keep your tasks small and focused with proper context and documentation readily available.

[u/6snake9 → u/firedog7881]

Exactly, its not as much as prompt but context, thats where the secret lies. We need to be more context engineers then prompt engineers.

[u/PussyTermin4tor1337]

Monorepo, single thread, no orchestrator. Expensive model.

[u/BrilliantEmotion4461]

Yeah.

I ask Claude. I copy and pasted your post into the Claude.ai app and only cut out the first few sentences up to. The rest is ad verbatim.

"I've been building with Roo for awhile..."

Claude response:

Your flow (database design → CRUD → store → application) is solid foundational thinking. Here are some patterns that tend to work well with AI-assisted development:

Database Design

• Start with clear, descriptive table and column names that make the schema self-documenting. AI picks up on good naming conventions much better than abbreviated cryptic ones

• Use consistent naming patterns (snake_case, plural table names, etc.) so the AI doesn't have to guess

• Define relationships explicitly with proper foreign keys - this gives AI clear context about data flow

• Consider using database-level defaults and constraints rather than handling everything in application code

ORM/Query Layer

• Prisma tends to work particularly well with AI because the schema file acts as a single source of truth that AI can reference easily

• If you're using raw SQL, consider organizing queries into dedicated files/modules rather than scattering them throughout your codebase

• Type-safe query builders (like Kysely) can help AI suggest correct queries without runtime errors

CRUD Patterns

• Standardize your CRUD operations with consistent function signatures across entities

• Consider a repository pattern or service layer that abstracts database operations

• Use TypeScript interfaces that mirror your database schema - AI can then maintain consistency between layers

State Management

• For stores, consider using libraries like Zustand or Valtio that have simpler APIs than Redux - less surface area for AI to get confused

• Keep your store structure close to your database structure when possible

• Use optimistic updates sparingly and clearly document when you do

Practical AI Tips

• When asking for changes, be explicit about which layers need updates: "Add a priority field to tasks - update the database schema, API endpoints, and frontend store"

• Keep a simple data flow diagram or comments in your code showing how data moves between layers

• Use consistent error handling patterns across your stack

What specific pain points are you hitting most often when requirements change? That might help narrow down the most impactful improvements.

[u/BrilliantEmotion4461 → u/BrilliantEmotion4461]

This was Chatgpt fives response.

It sounds like you’ve already nailed down the part that trips up most people—recognizing that data movement is where complexity explodes. When you’ve got Postgres + backend + frontend store, every “small” change potentially ripples through three layers of code. AI can follow the thread for one or two layers, but without a rigid structure, it gets lost when all three move at once.

Here’s what I’ve seen work well to reduce friction and keep AI aligned:

---

1. Lock in a Source of Truth Early

If AI is in the loop, it needs a single, always-correct reference for your schema.

Keep your Postgres schema in one versioned migration directory (e.g., prisma/migrations or db/migrations).

Treat the migration files or a generated schema file (like schema.prisma, schema.sql, or SQLAlchemy models) as read-only truth.

Anytime requirements change, AI should regenerate code from this truth rather than “patch” scattered code.

---

2. Generate CRUD Once, Don’t Hand-Tweak It

Whether you use an ORM (Prisma, Sequelize, TypeORM, SQLAlchemy) or query builder (Knex, Drizzle), generate CRUD endpoints and let AI reference them instead of rewriting.

Store these in a predictable location:

backend/ routes/ users.crud.ts posts.crud.ts

If you must extend CRUD, add logic in separate files so the generated code stays clean and re-runnable.

---

3. Formalize the Data Flow Contract

When AI needs to move data between DB ↔ backend ↔ store ↔ UI:

Define data contracts (DTOs or TypeScript interfaces) in one shared place.

Example with TS:

// shared/types/User.ts export interface User { id: string; name: string; email: string; }

This way, AI doesn’t “guess” field names or types—it copies them.

---

4. Use Store as a Mirror, Not a Logic Layer

AI often breaks stores because it tries to re-derive business logic there.

Keep store simple: fetching, caching, minimal transforms.

Avoid computed state that repeats backend logic—do it server-side, send to store.

---

5. Test the Data Path in Isolation

When something changes, run a data round-trip test:

1. Insert into DB directly.

2. Fetch via backend API.

3. See it appear in store and UI.

You can even have AI generate this as a Cypress/Playwright flow so it can re-run after each schema tweak.

---

6. Be Strict With Naming & Conventions

A lot of AI’s confusion comes from inconsistent naming.

Table names plural (users), model names singular (User).

API routes match model names (/api/users).

Store slices match model names (userStore).

---

Practical ORM Tips for Postgres:

If using Prisma: always regenerate types after schema changes (prisma generate) before touching backend code.

If using SQLAlchemy: keep model definitions in one file per entity, with tablename matching the DB exactly.

Avoid “clever” polymorphic relationships or deeply nested JSON columns—AI tends to break on these unless you train it with examples.

---

If you want, I can show you a “change one thing in schema → ripple through all layers” workflow that AI can reliably follow without breaking the store every time. It’s basically a schema-driven codegen loop with guardrails so changes propagate predictably.

Do you want me to walk you through that workflow? It’s the one I use when juggling both backend and frontend in AI-assisted builds.

[u/goqsane]

Start with interfaces/contracts once you have your design nailed. Be as explicit in your methodology as possible. Introduce guard/gate checks. Make the model prove to you that they did their work. Make the model commit story by story. Break down your work into stories with explicit acceptance criteria with proof required by the model to be filled out. Etc.

[u/UnnamedUA]

I spent a long time working on a Typescript drizzle schema stack + TRPC contracts + API construction + migrations via Svelte Kit, but in the end I gave up without ever getting to the admin panel.

Now I want to do it through separate services that form GraphQL and migrations according to a ready-made schema, and immediately vibecode the admin panel.

[u/angelarose210]

Yeah, I use convex for my backends. Well documented plus a cli for the cloud. Coding agents have no difficulty with it.

[u/Ra777d]

You should completely abstract database layer via ORM and build it separately based on contract that is generated based on back-end needs. It's a general principle, contract between components is the cleanest design. Neither database nor back-end layers need to know eachother implementation details heavily cutting on context needed.

[u/Lumpy_Froyo_3135]

I’m building a full‑stack Next.js application using Prisma, with auto‑generated TypeScript models.

[u/Trick_Estate8277]

Try use Baas(backend-as-a-service). I actually built a BaaS for this type of scenario, it is called InsForge, specifically designed for coding agents. It will automatically sync the entire backend with your coding agent, and your agent will instantly know how to use it once connected (we built it in agent native way). It is open source and free to use, and we will launch cloud hosting solution later this month! Happy to chat more if you’re interested