DEV Community: Oberon Lai

Build real WordPress sites on your Mac by chatting with AI (fully local)

Oberon Lai — Wed, 28 Oct 2026 13:30:38 +0000

Disclosure: I build ShipPress, the Mac app this article is about.

AI coding agents like Claude Code and Codex are pretty good at writing WordPress themes and pages now. When I actually use them, though, the code is rarely where I get stuck. The friction is everything around it:

setting up a local WordPress with PHP and a database
deciding which folders the agent is allowed to touch
rolling back a change that went wrong
getting the finished site onto a real server

I built ShipPress, a free Mac app, to take care of those parts. Here's what building a WordPress site through chat looks like with it.

What you need

macOS (Apple Silicon or Intel)
one of these AI CLIs with your own account: Claude Code, Codex, Grok Build, Antigravity CLI or Cursor CLI
ShipPress (free): https://shippress.codotx.com/?ref=devto-en

You sign in to the CLI with your own account. ShipPress doesn't store your credentials, and AI usage runs on the plan you already pay for. On first launch ShipPress can install the AI tool for you with one click, so you don't have to open a terminal.

The flow

1. Pick a starting point

Either describe your project in one sentence or start from one of the bundled block themes (there are WooCommerce shop designs too). For example:

Build a website for a small harbour-side cafe called "Harbor Beans", with a menu and opening hours.

Putting the name in the sentence also sets the site name.

2. Let the AI build

Your chosen CLI builds the theme, pages and content straight into a local WordPress install. You can run more than one AI worker on the same site at once.

3. Fix things by chatting

Make the header dark green.
Add the opening hours to the footer.

The preview updates right away. ShipPress saves a restore point after every AI change, so you can go back with one click. For me that's the biggest difference from working with the bare CLI.

The canvas view shows all your pages side by side, and you can click a spot on a page to ask for a change there. You can check the phone view too.

4. Go live

direct connections: InstaWP, Hostinger, Pressable, Cloudways, Kinsta, xCloud
over SSH: SiteGround, WordPress.com, DigitalOcean and other hosts with SSH access
no hosting at all: export a static site and host it through ShipPress, including buying a domain in the app (not for shop sites)

Bare CLI or ShipPress?

	Bare CLI	ShipPress
Local WP environment	you set it up	the app does it
Undoing changes	your own git workflow	automatic restore point per change
Preview	open a browser yourself	live in the app
Deployment	by hand	host connection, SSH or static export

If you're comfortable in a terminal, the bare CLI works fine. ShipPress is for people who want to build WordPress sites with AI without living in the terminal.

Wrapping up

AI agents are genuinely useful for WordPress sites. The hard parts are the environment, rollback and deployment, and that's what ShipPress handles.

It's still early. If you try it and get stuck anywhere, tell me in the comments or open a GitHub issue.

Download: https://shippress.codotx.com/?ref=devto-en
Issues: https://github.com/oberonlai/shippress-releases/issues
Video tutorials: https://www.youtube.com/@codotx-app

A Windows version is planned.

Oberon Lai

5 safety steps before you let an AI coding agent touch WordPress

Oberon Lai — Wed, 28 Oct 2026 11:19:02 +0000

Disclosure: I make ShipPress, a Mac app, and I mention it briefly at the end. Everything before that works without my tool.

Claude Code, Codex and similar agents can now do a surprising amount of work on a WordPress theme or a set of pages. They also sometimes go a little past what you asked: they edit files they shouldn't touch, or write straight to the database. These are five things I wish I had done from day one after a few months of pairing AI agents with WordPress.

1. Work locally or on staging, never on production

It sounds obvious, and it's the one that saves you the most. Don't let the agent work over SSH on the live site. Make changes locally or on a staging copy, check them, then move them over.

wp-env, Local, Docker: it doesn't matter which. What matters is that it's a place where breaking things hurts nobody.

2. Limit the working directory

If you hand the agent the whole repo or the WordPress root, it will read wp-config.php and core files too. If you only want it working on the theme, start it inside the theme folder:

cd wp-content/themes/my-theme
claude   # or codex, etc.

With Claude Code, a CLAUDE.md in the project that spells out what's allowed helps a lot:

## Rules
- Only change files under wp-content/themes/my-theme
- Don't read or change wp-config.php or core files
- Suggest new plugins, don't install them yourself

3. Back up the database, not just the files

git can roll back files. But posts, pages, menus and block theme template edits live in the database, and git alone won't bring back a page the AI rewrote.

So export with WP-CLI before every session:

# before
wp db export backups/before-ai-$(date +%Y%m%d-%H%M).sql

# roll back if needed
wp db import backups/before-ai-20261028-1300.sql

And on the file side, commit after every step:

git add -A && git commit -m "before: ask agent to change header colour"

4. Keep each request small

"Build me the whole website" is much harder to review and undo than "build only the hero section of the home page". If you work in small rounds (request, check, snapshot), you can see right away which instruction broke something.

5. Read the diff before you deploy

Before anything goes live, I check at least this:

git diff --stat                  # which files changed
wp plugin list --status=active   # any plugins you don't recognise?
wp option get siteurl            # did the URL get rewritten?

If siteurl or home reaches production still set to your local URL, the site stops loading. That one is worth a second look.

Summary

Work locally or on staging
Limit where the agent can work
Back up files with git and the database with wp db export
Small requests, check after each one
Check the diff and settings before you deploy

Aside: an app that does this for you

Steps 1 to 3 were too much manual work for me every time, so I built a free Mac app called ShipPress. It sets up a local WordPress site, lets the AI CLI you already have (Claude Code, Codex, Grok Build, Antigravity CLI, Cursor CLI) build the site, and creates a restore point every time the AI changes something. You can publish through host integrations like InstaWP, over SSH, or as a static export.

Download: https://shippress.codotx.com/?ref=devto-en

If you have your own tricks for keeping AI agents safe around WordPress, I'd love to hear them in the comments.

Oberon Lai

Créer de vrais sites WordPress sur Mac en discutant avec une IA (100 % en local)

Oberon Lai — Wed, 28 Oct 2026 10:19:38 +0000

Transparence : je développe l'app Mac ShipPress, dont parle cet article.

Les agents de code IA comme Claude Code ou Codex écrivent désormais des thèmes et des pages WordPress plutôt correctement. En pratique, ce n'est presque jamais le code qui me bloque, mais tout ce qu'il y a autour :

monter un environnement WordPress local avec PHP et une base de données
décider quels dossiers l'agent a le droit de toucher
revenir en arrière quand une modification tourne mal
mettre le site terminé sur un vrai serveur

C'est pour ça que j'ai créé ShipPress, une app Mac gratuite. Voici à quoi ressemble le déroulé quand on construit un site WordPress uniquement en discutant.

Ce qu'il vous faut

macOS (Apple Silicon ou Intel)
l'un de ces CLI d'IA avec votre propre compte : Claude Code, Codex, Grok Build, Antigravity CLI ou Cursor CLI
ShipPress (gratuit) : https://shippress.codotx.com/?ref=devto-fr

Vous vous connectez au CLI avec votre propre compte. ShipPress ne stocke aucun identifiant, et l'utilisation de l'IA passe par votre abonnement existant.

Le déroulé

1. Choisir un point de départ

Soit vous décrivez votre projet en une phrase, soit vous partez d'un des thèmes blocs fournis (il y en a aussi pour les boutiques WooCommerce). Par exemple :

Crée un site pour le petit café "Harbor Beans" sur le port, avec la carte et les horaires d'ouverture.

2. Laisser l'IA construire

Le CLI choisi construit le thème, les pages et le contenu directement dans une installation WordPress locale. Vous pouvez aussi faire travailler plusieurs workers IA en même temps sur un même site.

3. Ajuster en discutant

Passe l'en-tête en vert foncé.
Ajoute les horaires d'ouverture dans le pied de page.

L'aperçu se met à jour tout de suite. Après chaque modification de l'IA, un point de restauration est créé automatiquement, et un clic suffit pour revenir en arrière. Pour moi, c'est la plus grosse différence avec le CLI seul.

La vue Canvas affiche toutes les pages côte à côte, et vous pouvez cliquer directement sur un endroit pour demander une modification. La vue mobile se vérifie aussi.

4. Publier

connexion directe : InstaWP, Hostinger, Pressable, Cloudways, Kinsta, xCloud
par SSH : SiteGround, WordPress.com, DigitalOcean et d'autres hébergeurs avec SSH
sans hébergement : export en site statique hébergé par ShipPress, avec achat de nom de domaine dans l'app (pas pour les boutiques)

CLI seul ou ShipPress ?

	CLI seul	ShipPress
Environnement WP local	à monter soi-même	géré par l'app
Annuler une modification	à la main avec git ou autre	point de restauration automatique à chaque modification
Aperçu	ouvrir le navigateur soi-même	immédiat dans l'app
Mise en ligne	à la main	connexion hébergeur, SSH ou export statique

Si vous êtes à l'aise dans le terminal, le CLI seul fait très bien l'affaire. ShipPress s'adresse à ceux qui veulent construire du WordPress avec l'IA sans se battre avec le terminal.

En résumé

Les agents IA sont tout à fait utilisables pour des sites WordPress. Les vrais obstacles sont l'environnement, le retour en arrière et la mise en ligne, et c'est ce dont s'occupe ShipPress.

Le projet est encore jeune. Si vous l'essayez et que vous bloquez quelque part, dites-le dans les commentaires ou ouvrez une issue GitHub.

Téléchargement : https://shippress.codotx.com/?ref=devto-fr
Issues : https://github.com/oberonlai/shippress-releases/issues

Une version Windows est prévue.

Oberon Lai

Echte WordPress-Seiten auf dem Mac per KI-Chat bauen (komplett lokal)

Oberon Lai — Wed, 28 Oct 2026 09:26:51 +0000

Hinweis: Ich entwickle die Mac-App ShipPress, um die es in diesem Artikel geht.

KI-Coding-Agenten wie Claude Code oder Codex schreiben WordPress-Themes und Seiten inzwischen ziemlich gut. In der Praxis hänge ich aber selten am Code fest, sondern an allem drumherum:

eine lokale WordPress-Umgebung mit PHP und Datenbank aufsetzen
festlegen, welche Ordner der Agent anfassen darf
schiefgegangene Änderungen zurückrollen
die fertige Seite auf einen echten Server bringen

Genau dafür habe ich ShipPress gebaut, eine kostenlose Mac-App. Hier zeige ich, wie der Ablauf aussieht, wenn man eine WordPress-Seite nur per Chat baut.

Was du brauchst

macOS (Apple Silicon oder Intel)
eines dieser KI-CLIs mit eigenem Konto: Claude Code, Codex, Grok Build, Antigravity CLI oder Cursor CLI
ShipPress (kostenlos): https://shippress.codotx.com/?ref=devto-de

Du meldest dich im jeweiligen CLI mit deinem eigenen Konto an. ShipPress speichert keine Zugangsdaten, und die KI-Nutzung läuft über deinen bestehenden Tarif.

Ablauf

1. Startpunkt wählen

Entweder beschreibst du dein Projekt in einem Satz, oder du nimmst eines der mitgelieferten Block-Themes (es gibt auch welche für WooCommerce-Shops). Zum Beispiel:

Bau eine Website für das kleine Café "Harbor Beans" am Hafen, mit Speisekarte und Öffnungszeiten.

2. Die KI bauen lassen

Das gewählte CLI baut Theme, Seiten und Inhalte direkt in einer lokalen WordPress-Installation. Du kannst auch mehrere KI-Worker gleichzeitig an einer Seite arbeiten lassen.

3. Per Chat nachbessern

Mach den Header dunkelgrün.
Füge die Öffnungszeiten in den Footer ein.

Die Vorschau aktualisiert sich sofort. Nach jeder Änderung der KI entsteht automatisch ein Wiederherstellungspunkt, sodass du mit einem Klick zurückkannst. Das ist für mich der größte Unterschied zur Arbeit mit dem nackten CLI.

In der Canvas-Ansicht siehst du alle Seiten nebeneinander und kannst direkt auf eine Stelle klicken, um eine Änderung anzufordern. Die mobile Ansicht lässt sich auch prüfen.

4. Veröffentlichen

direkte Anbindung: InstaWP, Hostinger, Pressable, Cloudways, Kinsta, xCloud
per SSH: SiteGround, WordPress.com, DigitalOcean und andere Hosts mit SSH
ganz ohne Hosting: als statische Seite exportieren und über ShipPress hosten, inklusive Domainkauf in der App (nicht für Shop-Seiten)

Nacktes CLI oder ShipPress?

	Nacktes CLI	ShipPress
Lokale WP-Umgebung	selbst einrichten	macht die App
Änderungen zurücknehmen	selbst mit git o. Ä.	automatischer Wiederherstellungspunkt pro Änderung
Vorschau	Browser selbst öffnen	sofort in der App
Deployment	von Hand	Host-Anbindung, SSH oder statischer Export

Wer sich im Terminal wohlfühlt, kommt auch mit dem nackten CLI gut zurecht. ShipPress ist für Leute gedacht, die WordPress mit KI bauen wollen, ohne sich mit dem Terminal herumzuschlagen.

Fazit

KI-Agenten sind für WordPress-Seiten absolut brauchbar. Die Hürden sind Umgebung, Zurückrollen und Deployment, und darum kümmert sich ShipPress.

Das Projekt ist noch früh. Wenn du es ausprobierst und irgendwo hängen bleibst, schreib es gern in die Kommentare oder als GitHub-Issue.

Download: https://shippress.codotx.com/?ref=devto-de
Issues: https://github.com/oberonlai/shippress-releases/issues

Eine Windows-Version ist in Planung.

Oberon Lai

5 précautions avant de laisser un agent de code IA toucher à WordPress

Oberon Lai — Wed, 28 Oct 2026 08:13:29 +0000

Transparence : je développe l'app Mac ShipPress, que je présente rapidement à la fin. Les conseils qui précèdent marchent très bien sans mon outil.

Claude Code ou Codex savent maintenant faire beaucoup de choses sur un thème ou des pages WordPress. Mais un agent déborde parfois de sa mission : il modifie des fichiers qu'il ne devait pas toucher, ou écrit directement dans la base de données. Voici cinq habitudes que j'aurais aimé prendre dès le début, après quelques mois à faire travailler l'IA sur WordPress.

1. Travailler en local ou en préproduction, jamais en production

Ça paraît évident, et c'est pourtant ce qui protège le plus. Ne laissez pas l'agent travailler en SSH sur le site en ligne. Modifiez en local ou sur un staging, vérifiez, puis seulement ensuite publiez.

wp-env, Local ou Docker, peu importe. Ce qui compte, c'est d'avoir un endroit où casser quelque chose ne gêne personne.

2. Limiter le répertoire de travail

Si vous donnez à l'agent tout le dépôt ou la racine WordPress, il lira aussi wp-config.php et les fichiers du cœur. S'il ne doit toucher qu'au thème, lancez-le dans le dossier du thème :

cd wp-content/themes/mon-theme
claude   # ou codex, etc.

Avec Claude Code, un fichier CLAUDE.md dans le projet permet en plus d'écrire noir sur blanc ce qui est autorisé :

## Règles
- Ne modifier que les fichiers sous wp-content/themes/mon-theme
- Ne pas lire ni modifier wp-config.php ni les fichiers du cœur
- Proposer de nouvelles extensions, sans les installer soi-même

3. Sauvegarder la base de données, pas seulement les fichiers

Git permet de revenir en arrière sur les fichiers. Mais les articles, les pages, les menus et les modifications des modèles d'un thème de blocs vivent dans la base. Git seul ne vous rendra pas une page créée par l'IA.

Avant chaque session, un export avec WP-CLI :

# avant
wp db export backups/avant-ia-$(date +%Y%m%d-%H%M).sql

# retour arrière si besoin
wp db import backups/avant-ia-20261028-1300.sql

Et côté fichiers, un commit après chaque étape :

git add -A && git commit -m "avant : changement de couleur du header"

4. Donner des tâches courtes

« Construis-moi tout le site » est bien plus difficile à vérifier et à annuler que « Construis seulement la section hero de l'accueil ». En avançant par petits tours (demande, vérification, sauvegarde), on voit tout de suite quelle consigne a cassé quelque chose.

5. Relire le diff avant de déployer

Avant toute mise en ligne, je vérifie au minimum ceci :

git diff --stat                  # quels fichiers ont changé
wp plugin list --status=active   # une extension inconnue est-elle apparue ?
wp option get siteurl            # l'URL a-t-elle été réécrite ?

Si siteurl ou home arrivent en production avec l'URL locale, le site devient inaccessible. Ça mérite un second coup d'œil.

En résumé

Travailler en local ou en préproduction
Limiter le périmètre de l'agent
Fichiers avec git, base de données avec wp db export
Petites tâches, vérification à chaque étape
Contrôler le diff et les réglages avant le déploiement

Au passage : une app qui fait ça automatiquement

Les étapes 1 à 3 me demandaient trop de travail manuel à chaque fois, alors j'ai créé ShipPress, une app Mac gratuite. Elle installe un WordPress local, laisse votre CLI d'IA existante (Claude Code, Codex, Grok Build, Antigravity CLI, Cursor CLI) construire le site, et crée un point de restauration à chaque modification de l'IA. Pour publier, il y a des intégrations d'hébergeurs comme InstaWP, le SSH ou un export statique.

Téléchargement : https://shippress.codotx.com/?ref=devto-fr

Si vous avez vos propres astuces pour faire travailler un agent IA sur WordPress sans risque, je serais ravi de les lire en commentaire.

Oberon Lai

5 Sicherheitsmaßnahmen, bevor du einen KI-Coding-Agenten an WordPress lässt

Oberon Lai — Wed, 28 Oct 2026 07:22:36 +0000

Hinweis: Ich entwickle die Mac-App ShipPress. Am Ende des Artikels stelle ich sie kurz vor. Die Tipps davor funktionieren auch ganz ohne mein Tool.

Mit Claude Code oder Codex kann man inzwischen erstaunlich viel an einem WordPress-Theme oder an Seiten erledigen lassen. Gleichzeitig gehen Agenten manchmal etwas über den Auftrag hinaus: Sie ändern Dateien, die sie nicht anfassen sollten, oder schreiben direkt in die Datenbank. Hier sind fünf Dinge, die ich nach einigen Monaten mit KI und WordPress gerne von Anfang an gemacht hätte.

1. Lokal oder auf Staging arbeiten, nicht auf Produktion

Klingt banal, bringt aber am meisten. Lass den Agenten nicht per SSH auf der Live-Seite arbeiten. Besser: lokal oder auf einer Staging-Umgebung ändern, prüfen und erst dann übernehmen.

Ob wp-env, Local oder Docker ist egal. Wichtig ist nur, dass es ein Ort ist, an dem kaputte Dinge niemandem wehtun.

2. Das Arbeitsverzeichnis eingrenzen

Wenn du dem Agenten das ganze Repo oder das WordPress-Root gibst, liest er auch wp-config.php und Core-Dateien. Soll er nur am Theme arbeiten, starte ihn im Theme-Ordner:

cd wp-content/themes/my-theme
claude   # oder codex usw.

Bei Claude Code hilft zusätzlich eine CLAUDE.md im Projekt, die festhält, was erlaubt ist:

## Regeln
- Nur Dateien unter wp-content/themes/my-theme ändern
- wp-config.php und Core-Dateien weder lesen noch ändern
- Neue Plugins nur vorschlagen, nicht selbst installieren

3. Nicht nur Dateien, auch die Datenbank sichern

Dateien lassen sich mit git zurückdrehen. Aber Beiträge, Seiten, Menüs und Änderungen an Block-Theme-Templates liegen in der Datenbank. Mit git allein bekommst du eine von der KI erstellte Seite nicht zurück.

Vor jeder Session also ein Export mit WP-CLI:

# vorher
wp db export backups/before-ai-$(date +%Y%m%d-%H%M).sql

# zurück, wenn nötig
wp db import backups/before-ai-20261028-1300.sql

Und auf der Dateiseite nach jedem Schritt committen:

git add -A && git commit -m "vorher: Header-Farbe ändern lassen"

4. Aufträge klein halten

„Bau mir die ganze Website" ist schwerer zu prüfen und zurückzunehmen als „Bau nur den Hero-Bereich der Startseite". Wenn du in kleinen Runden arbeitest (Auftrag, prüfen, Snapshot), siehst du sofort, welche Anweisung etwas kaputt gemacht hat.

5. Vor dem Deploy den Diff anschauen

Bevor etwas live geht, prüfe ich mindestens das hier:

git diff --stat                  # welche Dateien sich geändert haben
wp plugin list --status=active   # sind unbekannte Plugins dazugekommen?
wp option get siteurl            # wurde die URL umgeschrieben?

Landen siteurl oder home mit der lokalen URL auf Produktion, ist die Seite nicht mehr erreichbar. Darauf lohnt sich ein zweiter Blick.

Zusammenfassung

Lokal oder auf Staging arbeiten
Den Arbeitsbereich des Agenten eingrenzen
Dateien mit git, Datenbank mit wp db export sichern
Kleine Aufträge, nach jedem Schritt prüfen
Vor dem Deploy Diff und Einstellungen kontrollieren

Nebenbei: eine App, die das automatisch macht

Weil mir die Schritte 1 bis 3 jedes Mal zu viel Handarbeit waren, habe ich die kostenlose Mac-App ShipPress gebaut. Sie richtet eine lokale WordPress-Umgebung ein, lässt deine vorhandene KI-CLI (Claude Code, Codex, Grok Build, Antigravity CLI, Cursor CLI) die Seite bauen und legt bei jeder Änderung der KI einen Wiederherstellungspunkt an. Veröffentlichen kannst du über Host-Integrationen wie InstaWP, per SSH oder als statischen Export.

Download: https://shippress.codotx.com/?ref=devto-de

Wenn ihr eigene Tricks habt, um KI-Agenten bei WordPress sicher arbeiten zu lassen, freue ich mich über einen Kommentar.

Oberon Lai