Vibe coding is real, it is spreading fast, and it is landing on Hacker News with 364 points and hundreds of comments from developers who have strong opinions about it. The idea is simple: describe what you want in plain English, let an AI model generate the code, iterate by prompting rather than editing, and ship something that works without deeply understanding every line. For WordPress development – a world built on PHP hooks, database abstraction, REST API endpoints, and decades of accumulated quirks – this raises a specific question: can vibe coding actually produce plugins that hold up in production?
This article is not going to tell you AI coding is the future of everything, and it is not going to dismiss it as a toy for people who do not know how to code. The honest answer is more useful than either of those takes. AI tools can build real WordPress plugins. They can also produce code with security holes, missing nonce checks, unescaped output, and logic that works in demos but breaks under real load. Knowing where the line is – and how to work productively on the right side of it – is what this article is about.
What Vibe Coding Actually Means
The term “vibe coding” was coined by Andrej Karpathy in early 2025. His description: “fully give in to the vibes, embrace exponentials, and forget that the code even exists.” In practice it means describing the output you want, accepting the AI’s generated code, running it, then prompting again based on what you see. The programmer moves from writing code to directing code generation.
That framing got picked up fast because it describes something many developers were already doing quietly. You describe a function, Claude or Copilot writes it, you check whether it does the right thing, you move on. The philosophical shift Karpathy described is about how far you take that pattern – whether you stay involved in understanding the code or whether you fully delegate comprehension to the AI.
The Hacker News thread that brought this into sharp debate highlighted a real split. One camp argues that if the output works and you can maintain it, the process that produced it does not matter. The other camp argues that code you do not understand is a liability waiting to surface at 2am when something breaks in production and you have no mental model to debug it. Both camps have a point, and both points apply directly to WordPress plugin development.
The AI Tools Actually Being Used for WordPress Development
Before getting into what works and what does not, it helps to know which tools developers are actually using for WordPress-specific AI coding. These are not all equivalent – they have different strengths for the WP context.
Cursor
Cursor is the tool most associated with vibe coding workflows right now. It is a VS Code fork with AI built into the editor at a deep level – you can select code and ask questions, describe changes in a sidebar chat, or use Composer mode to give it multi-file tasks. For WordPress development, Cursor handles PHP well and benefits from being able to read your entire plugin directory at once. Where it shines is mid-size refactors: “rename this hook,” “extract this function,” “make this work with custom post types.” Where it struggles is when you need it to understand WordPress-specific security requirements – it does not automatically apply nonce verification or escaping unless you explicitly ask.
Claude Code
Claude Code (Anthropic’s terminal-based tool) works differently – you give it a task from the command line, it reads your files, makes changes, and explains what it did. For WordPress development this is useful for project-level tasks: “audit this plugin for security issues,” “add REST API support to this CPT,” “write tests for this utility function.” Claude Code tends to produce more conservative PHP than some other tools, and it applies sanitization and escaping more reliably, though it still needs review. Its weakness is that it works best when you can describe requirements precisely, which means it rewards developers who know what correct WordPress code looks like.
GitHub Copilot
Copilot is inline autocompletion, now extended with chat. For WordPress it works well as a productivity tool – it knows add_action, add_filter, wp_enqueue_scripts, WP_Query and the common patterns. It autocompletes boilerplate fast. The limitation is that Copilot works line by line, which means it can suggest the right structure but miss requirements that span multiple functions (like making sure a nonce is created in the form render function and verified in the form handler function). Good for speeding up code you already know how to write.
Windsurf
Windsurf (from Codeium) is an agentic IDE that competes directly with Cursor. Its Cascade feature can run multi-step tasks autonomously – writing a file, running commands, checking output, iterating. For WordPress development it is capable of setting up a plugin scaffold, writing core functionality, and handling some test runs. The tooling is newer and the WordPress-specific knowledge base is slightly shallower than Cursor’s, but it closes that gap fast. It is worth watching if you are already evaluating AI editors.
What AI Coding Gets Right in WordPress Plugins
There are categories of WordPress plugin code where AI assistance is genuinely effective – not just “good enough,” but actually faster and often cleaner than writing from scratch.
Custom Post Type Registration
CPT registration is boilerplate. The structure is always the same: labels array, args array, register_post_type(), flush_rewrite_rules() on activation. AI tools produce this reliably. The main thing to verify is that show_in_rest is set to true if you want block editor support, and that flush_rewrite_rules() is only called on activation (not on every init). Here is an example of AI-generated CPT code that is actually correct after one pass of review:
AI tools consistently get this structure right. The flush_rewrite_rules() placement is the most common mistake – AI sometimes adds it inside the init callback instead of the activation hook. A quick review catches it.
Taxonomy Registration
Same story as CPTs. The register_taxonomy() call is predictable, the labels follow a standard pattern, and AI tools produce usable output. Verify show_in_rest, verify the CPT association is correct, and you are done.
Settings Pages and Admin Menus
add_menu_page, add_submenu_page, add_settings_section, register_setting – AI tools know these functions and can scaffold a working settings page in one prompt. The output tends to use options_page as the parent slug, use the right capability string, and produce the correct PHP for rendering fields. You still need to verify the nonce in the form handler, but the scaffolding is solid.
WP_Query Structures
For common query patterns – by post type, by taxonomy, by meta value, by date range – AI tools produce correct WP_Query args. The output rarely needs significant correction for straightforward queries. Where it gets tricky is complex meta queries with multiple relations, or queries that need to account for multisite contexts.
Hook Discovery
One genuinely useful vibe coding pattern for WordPress: describe what you want to do and ask the AI what hook to use. “I want to add a column to the posts list table.” “I want to run a function after a WooCommerce order is placed.” “I want to modify the query on the shop page.” AI tools are good at identifying the right action or filter for these tasks, which saves time digging through WordPress documentation or source code.
Where AI Coding Falls Short for WordPress
This is the section that matters most if you are thinking about shipping AI-generated code to production WordPress sites.
Security: The Consistent Weak Point
WordPress has a specific security model that AI tools do not apply consistently. Nonce verification, capability checks, input sanitization, output escaping – these are not optional. They are the difference between a plugin that works and a plugin that gets a site compromised. AI tools know these concepts but apply them inconsistently, especially when the codebase gets complex.
The most common pattern of failure: AI generates a REST API endpoint without a proper permission_callback, or generates an AJAX handler that does not verify a nonce. Both are critical issues. The generated code works – it does what was asked – but it does it in a way that exposes the site to attack. Here is a concrete example of an AI-generated REST endpoint with a security flaw, and the corrected version:
The corrected version adds proper argument registration with sanitization callbacks, explicit permission_callback declaration, typed parameters, and a cap on results to prevent abuse. None of this is complex – but AI tools do not always include it without being prompted.
Testing Is Almost Never Included
Ask an AI tool to build a plugin feature and you will rarely get PHPUnit tests along with it unless you explicitly ask. Even when you ask, the generated tests are often shallow – they test that functions return a value, not that they interact with the WordPress database correctly under different conditions, or that they handle edge cases like empty inputs or invalid post IDs. Vibe coding workflows that skip testing accumulate risk with every feature added.
WordPress Coding Standards
AI-generated PHP for WordPress often uses patterns that do not align with WPCS (WordPress Coding Standards). Yoda conditions, spacing conventions, inline comment formats, doc block requirements – these are not critical to function but they matter for code review, plugin directory submissions, and long-term maintainability. Running PHPCS with the WordPress ruleset on AI-generated code routinely produces several warnings or errors that need cleanup.
Complex Multi-Function Logic
When a feature requires multiple interacting functions – a meta box that saves data, a frontend template that displays it, a REST endpoint that exposes it, and a block that consumes the endpoint – AI tools can generate each piece separately, but integrating them into a coherent system requires understanding how they connect. The AI does not hold the full mental model of your plugin. You do. Vibe coding works for isolated features; it breaks down for systems design.
Update and Deprecation Awareness
WordPress evolves. Functions get deprecated. Block editor patterns change. AI training data has a cutoff, which means it can suggest deprecated functions or pre-5.x Gutenberg patterns that still technically work but are not current best practice. For production code, you need to verify against the current WordPress documentation.
A Security Review Checklist for AI-Generated WordPress Code
If you are using AI tools to generate WordPress plugin code, apply this checklist to every function that touches user input, database writes, or output to the page. It takes five minutes and catches the majority of issues AI tools introduce.
This is not an exhaustive security audit, but it catches the issues AI tools most consistently miss: missing nonces on form handlers, unescaped output, and raw database queries. Run these checks before committing any AI-generated code to a production plugin.
Real Plugins Built with AI Assistance
The most honest answer to “can vibe coding build real plugins” comes from looking at what developers have actually shipped. The pattern that keeps emerging is not pure vibe coding and not traditional coding – it is something in between.
Developers building internal tools and client sites are using AI to handle the scaffolding and boilerplate (CPTs, taxonomies, settings pages, basic CRUD operations) while writing the business logic, security-sensitive code, and complex query logic themselves. The split is roughly: AI for structure, human for substance.
Plugins submitted to the WordPress.org directory via AI-assisted development do exist – but they went through the standard review process, which means someone understood the code well enough to fix what the reviewer flagged. No plugin made it to the directory via pure vibe coding without at least one competent developer reading through the output.
The more interesting cases are client-specific or internal plugins where the bar is functional-and-secure rather than directory-approved. In those contexts, AI tools can handle a first draft of a simple plugin in an hour rather than a day. A developer who knows WordPress still reviews and fixes the output, but the total time is significantly lower.
The Honest Take on Vibe Coding for WordPress
Vibe coding – in the fullest sense of generating code you do not understand and shipping it without review – is not a viable approach for WordPress plugin development in production environments. The security model is too specific, the consequences of getting it wrong are too real, and the gap between “code that works in a demo” and “code that holds up with real users on a real server” is too wide to bridge with prompting alone.
AI-assisted coding – using these tools to handle boilerplate, scaffold structures, discover hooks, and generate first drafts that you then review and correct – is a genuine productivity improvement. Developers who know WordPress well are moving faster with these tools. The knowledge floor that makes vibe coding risky is the same knowledge that makes AI assistance most effective.
The answer to “can vibe coding build real plugins” is: partly. It can build the skeleton. The parts that make a plugin real – the security, the edge case handling, the testing, the knowledge of what can go wrong – still require a developer who understands what they are building. What has changed is that the boilerplate that used to fill most of a simple plugin’s development time can now be handled in minutes, freeing up time for the parts that actually require judgment.
That is a meaningful shift in how WordPress plugins get built. It is not magic, and it is not a replacement for knowing the platform. But it is real, and developers who figure out how to use it well are going to have a measurable advantage over those who do not.
Last modified: February 28, 2026
