Making database architecture as easy as describing what you want to build.

Building a database asks a lot before you can test an idea.

Before someone can start building, they have to think through tables, fields, types, relationships, indexes, and a dozen smaller architectural choices. The same work shows up when an existing app needs to evolve: a new feature, a cleaner schema, better indexes, or a clearer picture of what is already there. For experienced developers, that can be tedious. For someone without a traditional development background, it can be a real barrier.

As generative AI became more capable, we had a broad question to explore: how could we use AI to make Xano’s existing tools dramatically easier to use?

Database architecture felt like the right place to start.

Turn a request into safe, reviewable actions.

We treated the Copilot as a planning tool inside the database workflow. Someone could describe the application they wanted to build, ask for help with an existing structure, and get a clear plan they could understand and approve.

The AI could recommend what should happen. The application remained responsible for deciding whether and how it happened.

I owned the project from concept through implementation, working with my engineering manager to shape the initial idea into something we could safely ship.

This was late 2024, before tool-calling and agent workflows had become the standard pattern they are today. We defined a structured set of database operations the model could recommend, then built the application layer that validated, interpreted, and turned those recommendations into real database changes.

More like reviewing a plan from another developer.

Database architecture is inherently structured. I kept the useful information out of generic AI paragraphs and presented it as a plan people could scan and work through.

Recommendations became a visual, step-by-step plan. Tables, fields, types, relationships, and other proposed changes could be understood at a glance. Recognizable icons made schema types easier to scan, while more complex values stayed available without cluttering the primary view.

Every recommendation included an explanation of why the Copilot suggested it. Dependencies were explicit too: if a relationship needed a table to exist first, the UI made that visible before a user applied the plan.

Fast without feeling unpredictable.

Giving AI the ability to recommend database changes meant reliability mattered more than it would in a normal chat experience. Recommendations went through application-level validation before they could become actions. We checked that proposed changes were usable and that prerequisites existed—for example, that a referenced table existed before creating a relationship.

Potentially destructive actions required additional confirmation. The user always had a chance to understand the plan before executing it.

The hard part early on was getting consistently useful behavior from the model. We refined system instructions, taught it Xano-specific conventions, improved structured responses, and iterated toward the right balance of flexibility and reliability.