I started this week with a working block of my own, which I had already published in the last post, Core Confidence v2.9. While it was functional, I wanted to see what a “full-featured” version might look like if I let Telex, Automattic’s block creation tool, generate one for me. My thinking was that by comparing Telex’s output to my own code, I’d be able to spot what I was missing and finalize my block (learning, in the process).

I used details from the last post to begin crafting my prompt for Telex, then used the ‘Enhance Prompt’ option there, refining it for correctness, before hitting ‘Build’.

The Telex version was good, but it wasn’t extracting the version number from the previous post title — something I’d already managed in mine. I’ll keep working on it as a test bed, breaking things and reverse-engineering as I go. Watching the build was interesting; even though the code streamed by quickly, I was able to catch glimpses of the process.

I’ve shared a video below, of how it worked, based on the following prompt:

Create a Gutenberg block that displays a title with version numbers as styled headings on the frontend. In the editor, show a heading-style block with the current version number. Add an inspector panel that automatically detects version numbers from the previous post’s title using semantic versioning format. Provide three buttons for increment types: major, minor, and patch. When a user clicks an increment button, automatically calculate the new version number and update both the current post’s title and the block content. Display the detected previous version and calculated new version in the panel before applying changes. Include a confirmation step before updating the post title. The block should render as a customizable heading element on the frontend showing only the version number. Support standard heading levels and typography options. Handle cases where no previous version is detected by starting from 1.0.0.

I worked on the specific change I needed to make in my version. For it, I needed ‘major’ or ‘minor’ to be unselected when the Block loaded, then ensure that the version would be incremented only upon making a selection.

When I looked closer, I realized the reason the version type button was always starting with a selection was because it was directly tied to the version number itself. The RadioControl was storing that value, so it felt like the block was “deciding” for me. What I needed was to break that connection and give the version type its own independent state. That’s where useState(”) came in — now the control starts empty, and only when I choose “major” or “minor” does it pass that choice through handleVersionTypeChange, which then increments the version number. It was a small refactor, but it gave me the exact control I wanted: the version only changes when I say so.

*refactor – look at me using big developer words! Ha!

To really see the change, here are snippets from the code before and after:

// Before (original code)

// Line 18: Import statement
import { useEffect, useRef } from '@wordpress/element';

// Line 55: Attributes destructuring
const { versionType, versionNumber } = attributes;

// Line 59-62: Handler function
const handleVersionTypeChange = (value) => {
setAttributes({ versionType: value,
versionNumber: calculatedVersionNumber(value) });
};

// Line 69: RadioControl selected prop
selected={versionType}

// After (current code)

// Line 18: Import statement
import { useEffect, useRef, useState } from '@wordpress/element';

// Line 55-56: Attributes destructuring + local state
const { versionNumber } = attributes;
const [versionType, setVersionType] = useState('');

// Line 61-64: Handler function
const handleVersionTypeChange = (value) => {
    setVersionType(value);
    setAttributes({ versionNumber: calculatedVersionNumber(value) });
};

// Line 72: RadioControl selected prop
selected={versionType || ''}

This is how it works now.

I think today’s win was a really clear indicator of my own growth. I was able to look at the code and determine precisely what needed to be changed, to affect the needed change. I still need Cursor for syntax, but oh, am I getting closer to a good basis for understanding! It’s exciting.

My blog today was inspired by these two blog posts, I must say:

• How I Used AI to Build the WordPress.com Content Calendar (Without Writing Code) + Thoughts on Using AI for Web Development
• Telex Turns Everyone into a WordPress Block Developer

At the start of this journey, it felt like I was skimming information on the surface. Now I’m actually using that information to make real choices in my code — and that feels amazing!