Build with AI

You don't have to be a PHP developer to build for Basehim. An AI assistant can write an app or a theme for you, if it knows Basehim's rules. This page explains how to set that up, the safest way to work, and what you still need to check yourself.

What you need

• A Basehim site to test on. A copy of your site, a subfolder install, or a local install (Getting started). Never let new code reach your live site first.
• An AI assistant. Any capable chat assistant works; coding agents and assistants that connect to your site can do more (see below).
• The context page. AI context for Basehim development is a compact rulebook written for AIs. It's what stops the assistant from inventing functions or bringing in habits from WordPress.
• The prompts. Prompts for building with AI has ready-made requests for the common jobs. Fill in the blanks and paste.

What AI is good at, and what it isn't

AI assistants are good at the parts of an app that follow patterns: the manifest, admin screens, AJAX actions, settings, tables, scheduled tasks, themes from a description or a design. With the context page they follow Basehim's conventions well.

They are not a substitute for testing, and they still make mistakes: an assumption you didn't intend, a check that's missing, an API that doesn't exist. Treat what you get as a strong first draft from a fast colleague. You decide what it should do, and you check that it does.

Be extra careful with anything that handles payments, personal data, uploads or user accounts. For those, run the review prompt, and consider asking an experienced developer to look before you go live.

Three ways to work

1. A chat assistant

The simplest way, and enough for most apps and themes.

1. Open a new conversation and paste the context, or tell the assistant to read https://www.basehim.com/docs/ai-context.
2. Paste a prompt from the prompts page with your details filled in.
3. The assistant replies with a folder tree and the files. Create the folder on your computer, save each file, and ZIP the folder (the ZIP should contain your-app/app.json).
4. Upload the ZIP on your test site: Apps → Upload for an app, Appearance → Themes → Upload for a theme.
5. When something doesn't work, paste the error or the report back into the same conversation.

Good for: people who don't use a code editor; small and medium apps; themes.

2. A coding agent on your computer

Coding agents (in your editor or terminal) can create the files directly, run PHP's syntax check, and work across many files at once.

1. Install Basehim locally (Getting started), or open your app or theme folder in your editor.
2. Put the context in the agent's project instructions, for example a CLAUDE.md, AGENTS.md or rules file at the top of your project, so every request follows it.
3. Ask for one feature at a time with the prompts, and let the agent edit the files in content/apps/your-app/ or content/themes/your-theme/.
4. Test in your local site, then ZIP the folder and install it on your test site.

Good for: developers; larger apps; keeping your work in Git.

3. An assistant connected to your site

Basehim has a built-in MCP server, so assistants that support MCP can connect to a site and work with it directly (Connect an AI assistant to your site).

• Content tools come with core: an assistant can search, read and write posts and pages, within the scopes of the API key or OAuth connection you give it.
• Code tools come from the Basehim Dev Tools app. With it, an assistant can read your apps and themes, write files, check PHP syntax, render pages and read logs, so it can build and fix an app on the site itself. Setup, modes and the full tool list are in Basehim Dev Tools.

Dev Tools is built to make this safe:

• An administrator chooses the mode under Admin → Basehim Dev Tools: Disabled (no code access), Read-only (look, don't touch) or Development (read and write).
• Writes are limited to content/apps/… and content/themes/…. Core can be read but never changed, and secret files such as .env are never readable.
• Every write is checked: the current file is saved first, PHP is syntax-checked, then the site is started in a separate process and its home page, admin sign-in and MCP endpoint are health-checked. If anything fails, the change is rolled back automatically.
• Every change has an operation id, so you can roll it back later.

Good for: fixing an app that was switched off, small changes to a theme, and working on a staging site without copying files by hand.

Use Development mode on a staging site, not on your live site, and switch it back to Disabled when you're done. Even with checks and rollback, a change can be valid PHP and still do the wrong thing.

A safe workflow, step by step

1. Describe it on paper first. Who uses it, what it stores, what's public, what runs on its own. The prompts ask for exactly this.
2. Start every session with the context. Without it, assistants guess.
3. Build the smallest useful version. Get the core working before adding settings, widgets and extras.
4. Read the assistant's assumptions before you install anything, and correct the wrong ones.
5. Install on your test site and open Apps → your app → Report → Check again. It checks the code can load before it runs.
6. Test it as different people: an administrator, an editor, a subscriber, and signed out. Try to do what each one shouldn't be able to do.
7. Read the permission window when you activate the app. Every permission should make sense for what the app does.
8. Run the review prompt in a fresh conversation, and fix every "must fix".
9. Check Apps → Logs after testing. Warnings there are often the first sign of a problem.
10. Then, and only then, install it on your live site, after a backup.

Keep yourself and your site safe

• Never paste secrets into an AI: your .env, database passwords, API keys, or your users' personal data. Nothing here needs them. If a key ends up in a chat, change it.
• Give connected assistants the least access. An API key with only the scopes the job needs; Dev Tools in Read-only unless you need writes; Disabled when you're done.
• Don't install apps you can't explain. If you don't understand why an app needs a permission, ask the assistant, or don't install it. An app runs with the same rights as Basehim itself (App permissions).
• Keep backups. Before installing a new app or updating one on a live site.
• You are responsible for what you publish. If you share your app on the marketplace, test it as carefully as you would code you wrote by hand.

Getting better results

• One feature per conversation. Long conversations drift; start fresh with the context and your current files.
• Attach the current files when asking for a change, so the assistant edits what you have instead of inventing it again.
• Paste exact errors. The report text and log lines, not "it doesn't work".
• Ask for the checklist at the end of every answer. The context tells the assistant to include it; if it doesn't, ask.
• Ask "why" when something surprises you: a permission, a table, a capability. A good answer is part of the review.

Related

• Basehim Dev Tools: build and manage your site with an AI agent
• AI context for Basehim development
• Prompts for building with AI
• App development best practices
• MCP and AI agents and Connect an AI assistant to your site
• Build your first app and Build a theme from scratch, if you'd like to learn the basics by hand