Introduction of AI-driven software tools has changed the way I code up small project. I am still learning. This blog post documents an experiment I did that:

• Used three software tools: Claude Code, Google Antigravity and Github Copilot
• Asked each tool to create an implementation of a local tool
• When each one was done, create a second implementation using different design choices
• After all six alternatives were available, asked Claude/Antigravity/Copilot to compare/contrast the implementations and write a document

It was an interesting exercise both to see what I could do with the AI coding tools, the different solutions created and then their assessments by the tools.

Here was the first prompt I provided each tool (changing the name of the branch I asked it to pick)

I want a better solution for offline editing and updating of my wordpress
site: https://mvermeulen.org/gone2look4america/

The current workflow involves:
- logging into my site
- going to the wordpress dashboard
- doing functions such as:
  * drafting a new blog entry or a new page
  * editing/updating existing pages or blog entries
  * uploading media such as photos
  * creating links to strava routes
  * etc.

It works but I would like to do many more functions *offline* and then when
the internet is available do a "sync" to update various parts of the website
or add pages, etc.

Draft a new project with these abilities in mind. I want to compare what you
can do with a separate implementation from another tool and hence will give
you both this prompt. Show off what you can do and how well you can solve my
problem. Do this work on a branch named:
wordpress-local-antigravity-v1 and commit all the changes to this branch
when they are fully tested.

Surprise me with your creativity and thoroughness. However, if you are
completely stuck feel free to ask me a question or two.

For this initial development we won't have a login account/password to the
wordpress blog, but assume once deployed we will have such access. Make sure
to add appropriate safety checks to keep from accidentally destroying existing
content with those permissions.

Once the tool was finished, here is the second prompt I asked them to implement (again changing the branch name)

Good job. With the first implementation. Now that we have it done, create
a second alternative approach. Make different choices than the initial
implementation so we can see a range of what is possible as well as mix/match
capabilities. Pull all this work on a new branch named
wordpress-local-antigravity-v2 so it that stays separate from the main
branch and from the first implementation. Be creative.

For the most part these tools ran unattended except for asking me to approve file type commands that might accidentally change the system. Copilot gave me an implementation plan and asked me to ratify it (with one key design decision), the other tools just went off and started implementing. These six implementations took approximately 10 minutes each.

When I had completed the implementations, I asked each tool the following question to write a summary document

In this directory are six implementations of a tool to improve the experience
of updating a wordpress site from an offline location and then sync.

These are checked into the following six branches:

- wordpress-local-antigravity-v1
- wordpress-local-antigravity-v2
- wordpress-local-claude-v1
- wordpress-local-claude-v2
- wordpress-local-copilot-v1
- wordpress-local-copilot-v2

Create a document that:
- compares and contrasts the approaches taken
- identifies best practices, particularly those shown by one implementation but might be useful for others
- describes some key questions that might determine the choice taken
- recommends an approach, perhaps starting with one of the branches but adopting some ideas from others

Write your document into a file named: evaluation-antigravity.md.  Don't check it
in yet.

I moved the summary documents out of the way so implementations couldn’t see the other comparison. The three summary documents can be found at the following URLs:

• https://github.com/mvermeulen/ai/blob/main/wordpress-local/evaluation-antigravity.md
• https://github.com/mvermeulen/ai/blob/main/wordpress-local/evaluation-claude.md
• https://github.com/mvermeulen/ai/blob/main/wordpress-local/evaluation-copilot.md

They largely came up with similar conclusions. The most interesting finding was when asked for a recommendation: all three suggested starting with the claude-v1 implementation and then adopting things from the others. Rather than do my own summarization, I gave Gemini all three documents and asked for a summary. It is listed below the line.

I haven’t yet followed on these recommendations but one of my next steps will be to work with these tools and create a more complete implementation. I’ll need to think of the design choices but likely will follow the recommendation of starting with the first one developed by Claude.

---

Here is a comprehensive, synthesized summary of the three evaluations. It is formatted in clean, standard Markdown with clear headings and tables, making it perfectly optimized to copy and paste directly into your WordPress block editor (which seamlessly converts Markdown headings, lists, and tables into Gutenberg blocks).

Architectural Deep Dive: Syncing WordPress for an Offline-First World

Building a reliable, offline-first authoring environment that seamlessly syncs with a live WordPress site is a classic distributed systems problem. To explore this, three different AI tools (Antigravity, Claude, and Copilot) were tasked with designing an offline synchronization engine for a bike-touring blog.

Each tool provided two independent implementations, resulting in six distinct development branches:

• wordpress-local-antigravity-v1 & v2
• wordpress-local-claude-v1 & v2
• wordpress-local-copilot-v1 & v2

Below is a complete synthesis of how these implementations stack up across core architecture, safety mechanics, conflict resolution, and what a “perfect hybrid” production-ready system looks like.

1. Core Architecture Comparison

The six implementations primarily diverge along two structural paths: File-Based Markdown vs. Database-Backed Local Mirrors.

Implementation Branch	Primary Interface	Local Storage / State	Content Format	Sync Pattern
antigravity-v1	Web Dashboard	SQLite Database	Markdown in DB	Immediate API Push/Pull
antigravity-v2	Web Dashboard	Frontmatter Only	Markdown Files	Immediate API Push
claude-v1	Python CLI	Flat JSON (.wpsync)	Markdown + YAML	Pull/Push (Dry-Run First)
claude-v2	Web Dashboard + CLI	SQLite Mirror	Raw Gutenberg HTML	3-Way Text Merge (diff3)
copilot-v1	TypeScript CLI	JSON Manifest	Markdown + Frontmatter	Plan / Apply Cycle
copilot-v2	Python CLI	JSON Vault + Ledger	Markdown + JSON Meta	2-Stage Plan & Execute

The Two Core Philosophy Camps:

1. The Markdown Camp (claude-v1, copilot-v1, copilot-v2, antigravity-v2): These treat plain-text Markdown files with YAML/JSON frontmatter as the source of truth. They are highly portable, Git-friendly, and lightweight. However, parsing complex WordPress elements (like galleries or shortcodes) back into Markdown during a “pull” can be lossy.
2. The Database/HTML Camp (claude-v2, antigravity-v1): These maintain a local SQLite mirror. claude-v2 stands out by abandoning Markdown entirely to edit raw Gutenberg HTML. This completely eliminates formatting loss but forces a more rigid authoring experience.

2. Conflict Detection & Resolution

When working offline, preventing your local draft from accidentally overwriting a live edit made on the WordPress dashboard is critical. The branches approach this with varying levels of sophistication:

1. Advanced 3-Way Merging (claude-v2): Uses a background baseline snapshot to perform an automated node-diff3 merge between local edits and remote live changes. It seamlessly merges non-overlapping edits (e.g., a typo fix on the web while you write a new paragraph offline) and only blocks on direct collisions.
2. Two-Signal Verification (claude-v1): Tracks both the remote modified_gmt timestamp and a localized hash of the rendered HTML (content_hash). If the remote site changed since the last pull, it halts and demands a --force override.
3. Single-Signal Drift Check (copilot-v1 & v2): Relies strictly on comparing the remote modified_gmt timestamp. Safe, but treats all remote timestamp changes as an immediate blocking conflict.
4. Blind / Weak Controls (antigravity-v1 & v2): v1 prevents local database rows from being clobbered on a pull but offers no real protection during a push beyond a standard UI modal. v2 features no conflict detection, pushing blind overwrites on every execution.

3. Human-in-the-Loop Safety Railings

Because a bad sync engine can easily wipe out a live database, the evaluations highlighted several phenomenal safety innovations designed to limit the “blast radius” of human or technical errors:

• The Terraform Pattern (copilot-v2): Instead of a generic --dry-run flag, this prints a human-readable change list and generates an encrypted, checksum-verified plan.json file. To execute, the user must explicitly provide the plan file and type out a randomly generated string (e.g., APPROVE-plan-12345).
• Blast-Radius Caps (copilot-v1 & v2): Introduces a strict destination allowlist (WP_ALLOWED_HOSTS) to prevent accidentally running a script against production, alongside a maximum operation cap that blocks runaway large-batch modifications unless an override flag is passed.
• Pre-Write Backups (claude-v1 & v2): Automatically downloads and takes a timestamped audit snapshot of the remote content immediately before executing any update or delete action, ensuring point-in-time recovery.
• High-Friction Deletion (claude-v1 & v2): Forces the operator to manually retype the exact live title of a post before allowing a deletion to proceed—and defaults to moving content to the WordPress “Trash” rather than executing a hard delete.

4. Standout Quality-of-Life Features

Beyond standard CRUD mechanics, the tools introduced creative solutions specific to a real-world workflow:

• HTML Passthrough Fencing (claude-v1): To solve the lossy Markdown conversion issue, any complex Gutenberg blocks or shortcodes that the local parser doesn’t understand are wrapped inside block-level HTML comments. This preserves them byte-for-byte during a round-trip sync.
• Automated Media Deduplication (claude-v2): Hashes image content prior to upload. If an identical file hash already exists in the WordPress Media Library, it skips the upload and maps to the existing URL, saving server clutter and bandwidth.
• GPX Route Parsing (claude-v2): Rather than just pasting a bare link, it reads raw local .gpx files, calculates cumulative trip metrics (distance, elevation gain), and formats them natively into a Gutenberg travel summary block.

Summary Recommendation: The Ultimate Hybrid Engine

All three evaluations reach an identical consensus on how to build a production-grade system. You should use wordpress-local-claude-v1 as your core baseline architecture, then manually backport the best-in-class safety features from the other branches.

The Perfect Target Architecture Checklist:

1. Authoring Layer: Use claude-v1‘s file-based Markdown system with HTML passthrough fencing. It keeps content in standard text files that are easily versioned in Git without corrupting complex WordPress layouts.
2. Planning Layer: Adopt copilot-v2’s immutable plan.json architecture. Forcing the creation and review of an explicit change plan ensures high-stakes transparency.
3. Gatekeeping Layer: Pull in copilot-v1’s host allowlists and operational batch limits to eliminate catastrophic copy-paste or destination targeting errors.
4. Conflict Layer: Start with the robust two-signal timestamp checks from claude-v1. If your workflow involves multiple authors, upgrade later to claude-v2‘s three-way text merge logic.
5. Recovery Layer: Keep claude-v1‘s non-negotiable automatic pre-write backups, guaranteeing you always have an immediate rollback state if a sync goes awry.