On April 21, 2026, freeCodeCamp published my tutorial on building an automatic JSON-LD Knowledge Graph with PHP. A 3,000-word technical article with six implementation steps, production code, and database queries. Every line of PHP in that article was written with Claude as my coding partner. And every line passed through a human editorial review before it went live.

The process of getting from draft to publication changed how I think about writing code with AI. Not because the code was wrong. Because the process of defending every function to an editor forced me to understand what I had built at a level that building it never did.

The gap between building and explaining

When I build features for shinobis.com, the workflow is fast. I describe what I need to Claude. Claude writes the PHP. I test it. If it works, it ships. If it does not, I describe the problem and Claude fixes it. The loop is tight and productive. In six months I built a trilingual blog with JSON-LD automation, content negotiation, an AI radar, generative identity images, and two public tools. All on vanilla PHP with shared hosting.

But building and explaining are different skills. When I started writing the freeCodeCamp tutorial, I realized I could describe what each function did at a high level. I could not explain why it did it that way. Why does the system use a @graph array instead of nested objects? Why is the publisher an Organization instead of a Person? Why does the entity detection use strpos instead of a regex pattern?

Claude had made those decisions during implementation. I had accepted them because the output worked. Writing the tutorial forced me to interrogate every decision. Some were correct for reasons I had not considered. Some needed to change.

What I removed from Claude's draft

The first draft included sections that Claude suggested and I initially kept. A comparison table of JSON-LD formats across five CMS platforms. A section on Schema.org vocabulary hierarchies. A discussion of RDFa versus Microdata versus JSON-LD.

All technically accurate. All irrelevant to the tutorial. The reader who opens a freeCodeCamp article titled "How to Build an Automatic Knowledge Graph" does not need a history lesson on structured data formats. They need the code. The comparison table was the kind of content AI generates to fill space: comprehensive, well-organized, and unnecessary.

Removing those sections cut 800 words and made the tutorial tighter. Every paragraph that survived had to answer one question: does this help the reader implement the system? If the answer was no, it went.

What I added that Claude did not suggest

Three things made it into the final article that were not in the AI-generated draft.

First, the section on what I learned after three months in production. Claude cannot write that section because Claude does not have three months of production data. The insight that adding the abstract property had immediate impact on LLM processing, that citation alongside relatedLink signals knowledge relationships differently, that defining the publisher as an Organization increases trust signals. Those came from observing real behavior on a real blog over real time.

Second, the diagrams. The article includes four diagrams showing the pipeline architecture, the difference between static and graph-based JSON-LD, the @graph entity connections, and the annotated output. Claude did not suggest visual aids. I added them because ten years of UX design taught me that technical concepts land faster when you can see the structure, not just read about it.

Third, the testing methodology. The original draft ended with the implementation. I added a section on validating the output with Google Rich Results Test and auditing the schema with AI models. The recommendation to paste your JSON-LD into ChatGPT and ask for a score came from my own process. I did it, got an 8.7, made improvements, got a 9.1. That before and after is non-commodity content. Nobody else has that specific score progression because nobody else ran that specific audit on that specific schema.

The editorial process

freeCodeCamp has editorial reviewers. My article was assigned to Abbey. The review was not a rubber stamp. She questioned technical claims. She asked for clarification on the difference between about and mentions in JSON-LD. She flagged a section where the explanation assumed knowledge the reader might not have.

Every editorial comment forced me to go back to the code and verify. Not verify that it worked. Verify that I could explain why it worked. There is a difference. Running a function and seeing correct output proves the code is functional. Explaining to another person why the function is structured that way proves you understand it.

Three of Abbey's questions led me to discover things about my own implementation I had not noticed. The json_encode flags (JSON_UNESCAPED_SLASHES and JSON_UNESCAPED_UNICODE) were in the code because Claude put them there. I had never questioned them. When Abbey asked why they mattered, I tested what happens without them. A Spanish title with an accent mark broke the entire JSON-LD block silently. A URL with a forward slash got escaped into an unreadable string. Those flags were not decoration. They were preventing real bugs on a trilingual blog. I understood my own code better because someone asked me to explain it.

The line between using AI and understanding code

There is a version of this story where I paste Claude's output into a freeCodeCamp submission form and wait for approval. That version gets rejected. Not because the code is wrong but because the explanation is shallow. AI-generated tutorials have a specific texture: correct information organized in a predictable pattern with no personal insight, no production data, and no evidence that the author has ever run the code outside a sandbox.

The version that got published is different because I did the work that AI cannot do. I ran the system in production for three months. I observed how different AI models responded to the schema. I made changes based on real feedback. I removed sections that were technically correct but editorially wrong. I added sections that came from experience, not from prompting.

Using AI to write code is not the same as understanding code. But using AI to write code and then being forced to explain every line to a human editor closes that gap faster than anything else I have tried. The editorial process was not a filter. It was a learning accelerator.

What changed after publication

The article has been live since April 21. Three measurable things happened.

First, the backlink from freeCodeCamp. Their domain authority is among the highest in the technical publishing space. For a blog with a domain rating of 3.2, a single dofollow link from freeCodeCamp is worth more than dozens of links from smaller sites. Not because of the link juice alone but because of the trust signal it sends to every system that evaluates source credibility.

Second, the comment that surprised me. Someone asked "Could you share the source code?" The entire source code is in the tutorial, step by step. But the reader wanted a single file they could drop into a project. That told me something about how developers consume tutorials: they read the explanation to decide if it is worth implementing, then they want the complete code in one place.

Third, and this one matters most to me: I stopped thinking of myself as a designer who uses AI to code. I started thinking of myself as someone who builds software with AI and understands what gets built. The distinction is not semantic. It changes what I am willing to ship, what I question before deploying, and how I explain my work to others.

What I would tell someone who wants to publish with AI

Do not submit AI output. Submit your understanding of AI output. The difference is everything.

Read every function. Not to check for syntax errors. To check whether you can explain the decision it represents. If you cannot explain why a function uses strpos instead of preg_match, you do not understand the code well enough to publish a tutorial about it.

Remove the sections that AI adds to be comprehensive. AI fills space because completeness is its default. Your job is to cut everything that does not serve the reader. If a section exists because it is technically related to the topic but does not help the reader implement the thing you are teaching, it goes.

Add what only you can add. Production data. Before and after numbers. Decisions you made and why. Mistakes you caught. The things that make your tutorial different from every other tutorial on the same topic. AI cannot manufacture experience. If your tutorial does not contain experience, it is commodity content that will be outranked by the next person who writes the same tutorial with real data.

And find an editor. Not an AI editor. A human who will ask you questions you cannot answer yet. Those questions are where the learning happens.

The tutorial is live on freeCodeCamp: How to Build an Automatic Knowledge Graph for Your Blog with PHP and JSON-LD.