AI-Assisted Development

Apso works well with AI coding assistants because the backend has a single source of truth: .apsorc. The assistant can reason about your product model, edit the schema, run the CLI, inspect generated code, and test the API without inventing a backend architecture from scratch.

Use this workflow when you know the product you want to build but want help turning it into entities, fields, relationships, and a running service.

Why This Workflow Works

AI tools are good at translating product language into structured files, but they often produce scattered backend code when there is no system boundary. Apso gives the assistant a narrower job:

Understand the product domain.
Write or update .apsorc.
Run apso generate.
Test the generated API.
Put custom behavior in src/extensions/.

The result is standard framework code you can review, edit, and hand to another developer.

Prompt the Assistant

Start with product language, then ask for a schema-first implementation.


I am building a freelancer marketplace.

Users can be clients or freelancers. Clients post projects. Freelancers apply to projects.
Accepted applications become contracts. Contracts have milestones and payments.

Use Apso. Create the smallest useful .apsorc schema first.
Then run apso generate, start the API locally, and test one full workflow with curl.
Do not edit src/autogen. Put custom logic in src/extensions if needed.

Review the Schema First

Before generating code, ask the assistant to explain the model.

What are the core entities?
Which relationships are one-to-many or many-to-many?
Which fields are enums?
Which entities need tenant scoping?
Which fields should be nullable at creation time?

This catches product mistakes before they become generated files.

Generate and Test

After the schema looks right, let the assistant run the normal Apso loop.


apso generate
apso migrate
apso dev

Then ask it to test one real journey:


Create a client, create a project for that client, create a freelancer,
submit an application, accept it, and read the resulting contract.
Use curl and show the response from each request.

The goal is not just a passing build. The goal is proof that the generated API matches the product workflow.

Change the Product Safely

When requirements change, keep the assistant in the same loop.


Add milestones to contracts. Each milestone has a title, amount, due date,
and status. Update .apsorc, run apso generate, run apso migrate,
and show the SQL before applying it.

Review the migration output before using it against shared or production data.

Guardrails

Keep .apsorc as the source of truth.
Do not let the assistant patch src/autogen/.
Ask for one small schema change at a time.
Require curl or SDK tests for the workflow the user will actually perform.
Ask the assistant to explain destructive migration risks before applying changes.