DEV Community

Mark Van Oosterwijck
Mark Van Oosterwijck

Posted on

How a Non-Developer Built a 95,000-Line WordPress Codebase with AI

I don't know PHP. I've never opened a computer science textbook. I can't read most of the code running my own site.
The site has 95,510 lines of custom code across 129 files. A custom WordPress theme at 84,272 lines. Two plugins at 8,000 lines. An analytics dashboard at 3,238 lines. No page builder. No Yoast. No RankMath. No parent theme.
Every line was written through conversation with Claude.
This is not a tutorial. This is a post-mortem of what happens when a non-developer builds a production WordPress site entirely with AI — what worked, what broke, and why the codebase looks the way it does.
What I built
SleekNova is a gift curation platform. Products go through a 17-agent AI verification pipeline and get scored on four dimensions before being published. The site needed to handle:

Custom post types for products, lab notes, agents, and guides
6 custom taxonomies (categories, vibes, occasions, relationships, price tiers, themes)
145 custom fields per product via ACF
A JSON importer that receives structured data from the AI pipeline
A complete SEO engine (meta tags, canonicals, OG, Twitter Cards, AI meta tags)
JSON-LD schema generation (Product, Review, FAQ, BreadcrumbList, Organization)
AJAX filtering, a gift quiz, and a data integrity feedback loop
A custom sitemap engine
An llms.txt file for AI crawler optimization — currently at version 60

Here's what the key files look like:
seo.php 7,362 lines (45+ iterations, replaces Yoast entirely)
schema.php 5,059 lines (JSON-LD generator)
class-importer.php 2,249 lines (receives Golden Files from agent pipeline)
single-sn_product.php 2,208 lines (product page template)
functions.php 4,891 lines (theme functions)
taxonomy-*.php ~800 lines each (10 taxonomy templates)
How I actually built it
No IDE. No terminal (at first). No GitHub. Just Claude in a chat window and a text editor to paste code into files.
The process for every feature was the same:

Describe what I want in plain language
Claude writes the code
I paste it into the file
I load the page
If it breaks, I paste the error message back to Claude
Repeat until it works

That's it. That's the entire development methodology.
For the first three months, I didn't know what a function was. I didn't understand why some code went in functions.php and other code went in template files. I just followed instructions and observed patterns.
Around month four, something shifted. I started recognizing shapes in the code. Not syntax — I still can't write PHP — but structure. I could see that this block handles the query, this block formats the output, this block catches the error. I couldn't write it, but I could read the intent.
This is the part nobody talks about when they discuss "vibe coding." You don't learn to code. You learn to architect. You learn what belongs where, what depends on what, and what will break if you change something upstream.
The SEO engine: 7,362 lines that replace Yoast
This is the file I'm most proud of and most terrified by.
seo.php has gone through 45+ major iterations. It started as a simple meta tag generator — maybe 200 lines. Then I needed Open Graph tags. Then Twitter Cards. Then canonical URLs for paginated archives. Then hreflang for future internationalization. Then AI-specific meta tags for LLM crawlers.
Each iteration was a conversation: "The current SEO setup doesn't handle X. Here's what I need." Claude would write the addition. I'd paste it in. Something else would break. We'd fix it.
After 45 iterations, the file handles:

Dynamic meta titles with fallback hierarchy
Meta descriptions pulled from custom fields with character limit enforcement
Canonical URLs that handle pagination, filtering, and taxonomy intersections
Open Graph and Twitter Card tags for every post type
JSON-LD structured data hooks (separate file, but triggered from here)
AI meta tags (ai:page_type, ai:content_type, ai:citation, ai:research_count)
Robots directives per post type
No-index rules for thin taxonomy pages

There is no Yoast. No RankMath. No SEO plugin of any kind.
The result: the site went from 5 daily Google impressions to 6,000+ in six months. Zero backlinks. Zero social promotion.
I am not claiming my SEO engine is better than Yoast. I'm saying that for this specific site, with this specific data structure, a purpose-built engine that understands the exact content model outperforms a generic plugin. Every meta tag knows about the 145-field product schema. Every canonical URL understands the custom taxonomy relationships. A generic plugin can't do that without extensive configuration that approaches the complexity of just building the thing.
The importer: where AI meets WordPress
class-importer.php at 2,249 lines is the bridge between the AI pipeline and WordPress.
The 17-agent pipeline produces a "Golden File" — a JSON document with 145 fields covering everything from product scores to truth maps to buyer stories. The importer receives this file and maps every field to ACF custom fields in WordPress.
This is where most of the bugs lived. Every field has a type, a validation rule, and character limits that sometimes differed between the spec documentation and the live ACF configuration. For months, imports would fail silently — a field too long here, an invalid enum there, a nested array where ACF expected a flat one.
Some examples of the mismatches I discovered:

sn_hero_narrative: spec said 550 characters, ACF enforced 470
sn_insider_detail: spec said 150 characters, live limit was 250
sn_review_sentiment: must be 50+ characters (not just a sentiment label)
sn_skip_if: pipe-separated items that must grammatically complete "Skip for someone who..."
PHP's str_word_count skips numeric tokens — a 25-word field might count as 22 in PHP

Every one of these was discovered by a failed import, debugged through conversation with Claude, and fixed by adjusting either the importer or the upstream agent specs. The spec files have version numbers because of bugs like these.
The schema generator: 5,059 lines of JSON-LD
schema.php generates structured data for Google and AI crawlers. It's currently at version 52.
Every product page emits:

Product schema with Offer (price, availability, URL)
Review schema with the SleekNova score
FAQPage for the PAA questions
BreadcrumbList for site navigation
Organization for SleekNova Labs

Every lab note emits Article schema. Every guide emits Article with Dataset for embedded visualizations. Every agent page emits SoftwareApplication.
The llms.txt file — at version 60 — serves as a machine-readable specification that tells AI systems how to cite the site. Sixty versions means sixty times something about the content model changed and the documentation had to update.
I did not plan to have a 60-version llms.txt. I did not plan to have a 52-version schema generator. Each version exists because the content model evolved and the code had to follow.
What breaks
Everything breaks. Here's a sample:
Taxonomy intersection pages. When a user filters by both "Birthday" (occasion) and "For Mom" (relationship), the resulting page needs a unique canonical URL, unique meta title, and unique schema. The first version of seo.php didn't handle this. Pages were duplicating in Google's index. Fixing it took three iterations and added ~400 lines.
ACF repeater fields. Truth maps and buyer stories are stored as ACF repeater fields with sub-fields. The importer originally wrote these as nested JSON objects. ACF expected flat arrays with specific key patterns. Silent failures — the data looked correct in the JSON but didn't appear on the frontend. Took two weeks to diagnose.
Image processing. Product images need to be exactly 1000×1000px WebP at 90% quality with white backgrounds. The first version sampled the corner pixel for background color. Some product photos had shadows in the corner. Now it's hardcoded to white (255, 255, 255). A "fill" parameter controls how much of the canvas the product occupies — and a value above 1.0 causes clipping that we discovered only after 30 products were processed wrong.
PHP word counting. The sn_answer_capsule field has a 20-25 word limit enforced by WordPress's PHP str_word_count(). Python's len(text.split()) gives a different number. Hyphenated compounds like "hand-forged" count as one word in PHP, two in Python. The agent pipeline counts words one way; WordPress counts them another. We reconciled this in the Auditor agent spec.
The thing nobody tells you about AI-assisted codebases
The code works. The site runs. It serves thousands of pages. Google indexes it and sends 6,000+ impressions a day.
But I cannot maintain it alone without AI.
If Claude disappeared tomorrow, I would have a 95,510-line codebase I can partially read but cannot modify. I can recognize patterns, understand architecture, and diagnose problems at a high level. I cannot write a PHP function from scratch.
This is a new kind of technical debt. It's not bad code — Claude writes clean, well-commented code. It's dependency debt. My ability to operate my own system depends on continued access to the tool that built it.
I've mitigated this somewhat by documenting everything obsessively. Every agent has a versioned spec. Every field has a documented purpose. The llms.txt file describes the entire content model. If I had to onboard a human developer, the documentation exists. But the honest truth is that the documentation was written by Claude too.
The numbers
Lines of code: 95,510
Files: 129
Custom theme: 84,272 lines (46 template files)
Plugins: 8,000 lines (2 plugins)
Analytics dashboard: 3,238 lines
Key iteration counts:
seo.php: 45+ versions
schema.php: 52 versions

llms.txt: 60 versions
Agent specs: 50+ files, 33+ total methodology versions
Nov 2025: 5 impressions/day
Dec 2025: 58/day
Jan 2026: 246/day
Feb 2026: 1,137/day
Mar 2026: 2,785/day
Apr 2026: 6,000+/day
Zero backlinks. Zero promotion. Custom everything.
What I'd tell someone starting this today
Start with the data model, not the UI. I spent the first month getting custom post types and ACF fields right before touching templates. That investment paid for itself a hundred times over. When the AI pipeline was ready to export, WordPress had a place to put every field.
Treat every error message as a lesson. I pasted thousands of PHP errors into Claude. Each one taught me something about how WordPress works — not at the syntax level, but at the architectural level. After a year, I can predict what will break before it breaks. That's not coding knowledge. It's system knowledge.
Version everything. Not in Git (I still don't use Git properly). In filenames and spec documents. seo.php doesn't have 45 git commits — it has 45 moments where the previous version couldn't handle something the site needed. The version number is the scar tissue.
Accept the dependency. If you build with AI, you depend on AI. That's not a moral failing. It's a tradeoff. I traded "I can maintain this myself" for "I can build something I never could have built alone." For me, that trade was worth it. 95,510 times over.

The full codebase powers sleeknova.com. The 17-agent pipeline is documented at sleeknova.com/team/agents. I'm Mark, a non-developer in Rotterdam who learned that architecture matters more than syntax.

Disclosure: This article was written with AI assistance (Claude). The code described in the article was also built with AI assistance. The experiences, errors, architecture decisions, and growth data are mine.

Top comments (0)