I vibe code more and more lately as see opportunities to safely leverage it. There are areas where I’m hesitant to use it though. Not because I didn’t think it worked, but because of information security concerns. I’ve spent enough time writing code across different languages and environments to know that the details matter. It’s one thing to generate something that runs. It’s another thing entirely to generate something that is maintainable, safe, and behaves correctly when you throw real data at it.

I wanted to build a WordPress plugin that would display a category cloud where the size of each category reflects not just how many posts are in it, but how recently those posts were published. Click a category, and it filters the posts below it. Simple concept, but not something I had sitting around already.

And honestly, I didn’t feel like writing it from scratch. I’ve done enough of that over the years.

The Approach

I didn’t start with a detailed design doc or carefully engineered prompts. In fact, inadvertently I did the opposite of what most “Prompt Engineering” guides seem to suggest. I kept things simple and iterative.

• Define the goal
• Generate a starting point
• Refine through small adjustments
• Test on a real site

That last part matters more than anything. Often something that works in isolation doesn’t work well when deployed into a real environment using real data. I can still remember early at Cisco where I’d built part of the code to use pipes (|) to separate data in a String. Fortunately one of the PMs used that symbol during their testing and broke things. My (naive) attitude was “who uses pipes when filling out this kind of data?” It doesn’t matter if the input is different – you should follow Postel’s law when programming – “Be generous in what you accept and consistent in what you send.”

What Worked Surprisingly Well

The core functionality came together quickly:

• WordPress plugin structure
• Shortcode for rendering
• Category retrieval
• Basic scoring formula (post count + recency)
• Rendering a usable UI
• If you are new or out of practice with Git or GitHub, ChatGPT can help there also.

Within a short period of time, I had something that:

• Rendered a category cloud
• Scaled category size based on data
• Filtered posts when clicking a category
• Looked reasonably clean with some basic CSS

I really didn’t feel like mocking up fake posts on the staging site for my friend. But my blog felt like a good spot to test. After all, I’ve been adding a post almost every month since early 2018. Working with that much data alone was impressive.

Where I Had to Pay Attention

This is where experience still matters. Things to worry about – user data input – how to clean, and also how to separate private data on GitHub.

1. Security (Don’t Skip This)

Anything that touches user input or output in WordPress needs to be treated carefully. This is one of those areas where generated code can get you 80% of the way there, but the last 20% is what keeps you out of trouble.

There were a few areas I made sure were handled correctly:

Sanitizing input

$selected = isset($_GET['scc_cat']) ? sanitize_title($_GET['scc_cat']) : '';

This prevents someone from passing unexpected values through the URL.

Escaping output

Anywhere data is rendered:

esc_html($item['name']);
esc_url($url);
esc_attr($font);

This is not optional. Generated code will often “work” without this – until it doesn’t.

Safe database interaction

Even though I added uninstall cleanup that removes transients, I made sure queries used proper preparation:

$wpdb->prepare(...)

No shortcuts here.

2. Dependency Awareness

The plugin relies on:

• /includes for logic
• /assets/css and /assets/js for presentation

You can’t just upload a single file and expect it to work. That’s obvious to someone experienced, but easy to overlook when generating code quickly.

I actually hit this mentally at one point – “can I just upload this one file?” The answer is no, and it’s good to remind yourself why.

3. Version Compatibility

The first install failed immediately.

Not because of logic, but because of metadata:

Requires at least: 6.2

The site was running WordPress 5.5. Granted I should know better, but my intent was to make it something that others could use. If it works with an older version, has been tested there, and is safe either way – don’t throw up artificial guard rails.

That’s the kind of thing vibe coding won’t catch unless you’re thinking about the environment. Adjusting that to 5.5 solved the issue, but it was a good reminder that generated code assumes a lot.

4. PHP Version Assumptions

The code used typed return values like:

public function register_shortcode(): void

That requires newer PHP versions.

Again – nothing wrong with that, but you need to know your target environment. It’s easy to forget that not every site is running the latest stack.

5. Performance (Deferred, but Not Ignored)

The initial implementation queries the latest post for each category individually. That’s fine for now, but it’s an N+1 query pattern, which won’t scale forever. I intentionally did not optimize it yet.

And why not? Because premature optimization is still a thing – even when code is generated. I want to see real usage first before deciding where to spend that effort. Granted with vibe coding the effort is much lower, but if it isn’t something you find fun – save it for later.

Minor Hiccups

Nothing major, but a few things worth noting:

• A browser console warning that turned out to be from an extension, not the plugin
• GitHub image paths not resolving initially (case sensitivity and directory structure matter)
• Making sure assets actually load (CSS/JS registration vs enqueueing)

All small, but all things that take time if you’re not expecting them.

What I Didn’t Do (On Purpose)

I didn’t:

• Add a settings page
• Over-engineer configuration
• Optimize queries prematurely
• Add AJAX before confirming behavior

It’s easy to get pulled into building features instead of validating usefulness. I’m still not convinced every plugin needs a settings page. Granted if there are features to customize it should be in a settings page and not where someone has to update code. The first area I’ll create a settings page for is the weight of SOMETHING vs SOMETHING.

What I Learned

Vibe coding is not about skipping thinking. But it is about shifting where you spend your time.

Instead of:

• writing boilerplate
• remembering syntax
• building structure from scratch

You spend time:

• validating behavior
• checking assumptions
• reviewing for security
• tuning logic

The tool accelerates what you can do but it doesn’t replace judgment.

Final Thoughts

The plugin works – it renders cleanly, behaves correctly on a real site with a large number of posts, and gives a useful visualization of content activity. And more importantly, it reinforced something I already suspected:

You can absolutely build useful things quickly with this approach – but only if you stay engaged in the process.

If you treat generated code as “done,” you’ll eventually run into problems. But if you treat it as a starting point, it becomes a very powerful tool.

I’ll likely continue refining this plugin – tuning the scoring, improving performance, and possibly adding AJAX filtering. But for now, it does what I needed.

Plus I didn’t have to get up to speed with PHP and then write it from scratch!