Developers · Getting Started with PAI

Use PAI to give your existing AI tools structure, scope, and domain knowledge.

PAI is built for people who already use LLMs and coding assistants. You don't have to change providers or rebuild your stack. You add PAI beside what you have today, and it helps your tools behave like they truly understand your domain.

What developers do with PAI

As a developer, you can use PAI to:

Scope new tools and services Turn a rough requirement into a precise, domain‑aware outline.
Describe your domain once, reuse it everywhere Capture entities, data shapes, and invariants so assistants stop guessing.
Standardize AI workflows Move from ad‑hoc prompts to repeatable, inspectable flows.
Supercharge existing assistants Feed PAI's structured scopes and models into ChatGPT, Claude, Gemini, or your own internal tooling so they produce better code, tests, and docs.

PAI is not a new assistant. It's the interface layer that makes your assistants easier to reason about and easier to trust.

Prerequisites

To get started as a developer, you'll need:

A working AI stack for example, access to one or more LLMs you already use
The PAI CLI installed in your development environment
A project or domain you care about for example, an existing codebase, service, or integration

PAI is designed to run locally in a terminal or code sandbox, so you can experiment safely and wire it into your workflows at your own pace.

Your first 10 minutes with PAI

Here's a simple, concrete way to see PAI in action. We'll assume you already have the PAI CLI installed.

Pick a real problem

Choose something you'd actually want your assistant to help with, for example:

"I need a tool that generates monthly settlement reports."
"I want to add a webhook service that notifies partners about refunds."
"I need to design a fraud‑check step in our payment flow."

Keep it real, not theoretical. PAI works best on real constraints.

Ask PAI to scope it

From your terminal or sandbox, run PAI to generate a scope for that problem. For example:

pai scope "Create a scope for a tool that generates monthly settlement reports from our transactions API. Include inputs, outputs, failure modes, and how it fits into the existing reconciliation process."

PAI responds with a structured scope describing:

The entities involved
Inputs and outputs
Constraints and edge cases
How this tool interacts with other services

You now have a precise, domain‑aware description of what you're building.

Review and tweak the scope

Read through the scope:

Does it match how your domain actually works?
Are important edge cases captured?
Are there existing tools or services it should reference?

If something is off, you refine the scope with PAI instead of rewriting prompts from scratch. Think of it like editing a design doc, not chasing a one‑off answer.

Feed the scope into your assistant

Once the scope looks right, you hand it off to your favorite assistant to do the generative work. You might say:

"Here is a scope for a new settlement report tool in our system. Use this scope to generate the initial implementation in our stack, plus tests and basic documentation."

Because the assistant starts from PAI's structure, it has:

Well‑defined inputs and outputs
Clear boundaries and dependencies
A shared language for domain concepts

That makes it much more likely to generate code and docs that actually fit into your system.

Iterate with PAI in the loop

As you review and refine the generated artifacts, you can:

Update the scope when requirements change
Extend the domain model as you discover new concepts
Use PAI to design follow‑up tools and integrations

Over time, PAI becomes your living map of how your domain works and how your tools fit together.

Integrate PAI with the assistants you already use

There are a few ways to connect PAI to your existing assistants.

Option 1: Copy/paste scopes

The simplest path:

Use the PAI CLI to generate scopes and domain descriptions.
Copy the structured output into your assistant's chat.
Ask it to generate code, documentation, or tests based on that structure.

This works immediately and is great for exploration or early adoption.

Option 2: Wire PAI in as a tool (MCP‑style)

For a deeper integration, you can expose PAI as a tool / MCP‑style service to your assistant.

In that setup, your assistant can:

Call PAI to generate a scope for a task
Ask PAI for domain definitions and interfaces
Use those responses as context when generating code or plans

Instead of you copy‑pasting scopes, the assistant asks PAI directly: "Generate a scope for a new notification service." You still control what PAI knows and what it can expose.

Option 3: Internal automation and pipelines

You can also use PAI as part of your internal automation:

Pre‑scope work for generated migrations or refactors
Enforce consistent patterns across multiple services
Generate design docs or interface specifications as part of a CI step

Anywhere you want consistency and structure around how AI interacts with your code and systems, PAI can sit in the middle.

What PAI can see and what it can do

By design, PAI separates knowledge from capabilities.

For public, web‑facing use (like on paicodes), PAI only accesses public, read‑only knowledgebases. No file writes, no direct modification of systems.
In your own environment, you can let PAI see more: internal docs, schemas, code fragments, API specs under your control.
Tooling that can read or write files, call services, or modify state is always explicitly exposed and controlled by you.

This lets you start safely:

Use PAI for scoping and structure first.
Introduce more powerful tools only when you're ready and can monitor them.

We use PAI exactly the way we want you to

The entire PAI stack was created using the same techniques you'll use as a developer:

We used PAI to scope services, tools, and interfaces.
We fed those scopes into LLMs to generate code, tests, and docs.
We iterated with PAI in the loop as requirements evolved.

When you run PAI in your own environment, you're not experimenting with a toy. You're adopting the workflow that built PAI itself.

Where to go next

Once you've run through your first scope, you can:

Try PAI on a more complex, real integration
Start capturing your domain models so they're reusable across projects
Experiment with wiring PAI in as a tool / MCP‑style service for your primary assistant
Explore the documentation for deeper examples and patterns
Learn how PAI works dive deeper into scopes, domain models, and the architecture behind PAI

Ready to start?

Open your terminal, pick a real problem, and let PAI scope it.

From there, your existing assistants will feel a lot more like domain experts without changing the models you rely on today.