Stop with vibe coding! Seriously

"When you have a hammer in your hand, everything starts to look like a nail."

Vibe-coding seems to say: "Go and program!"

There’s data, and you need some report? Go vibe-code! Backend, frontend, VPS, all that stuff. But why, if you can just ask AI to make an Excel file with the right structure and formulas? It will be clearer, you can work with it in the future, and you can give it to someone without dealing with access issues, security, etc.

Want to launch a blog or some content project? Go vibe-code! Study Next.js, Sanity, Supabase, Vercel! Deploy, debug! But why, if you can take either Ghost or WordPress, use the same AI to get recommendations for necessary plugins and themes, set up the entire layout, and get a clear, updatable solution?

This is how this article started when my wife – the director of a small private school – asked me to help with her new project. Over time, she accumulated a lot of experience in various education-related issues – from motivation to preparation for OGE, EGE, etc. She wanted to gather, generalize, and share this knowledge. To create a great expert journal about education.

The first thought was: "Now we’ll quickly vibe-code everything!"

The second thought: "Why?" Especially if it will need updates, if it will need to be handed over to others, if, in the end, we need to quickly create an MVP and then improve it later.

The budget for a separate developer and designer – zero. The person who was dealing with this at the start (me) – is not a frontend developer and not a WordPress developer. I understand infrastructure, but layout and PHP – definitely not my specialty.

Why not write our own engine?

The first temptation – well, really, to take Codex or Claude Code, get another dose of dopamine from the fact that "the neural network" will take an unfamiliar stack, create its own CMS, and voilà – it’ll work! But if you honestly look at the task: we need a blog with categories, SEO, images, search, RSS, etc. This is a fully solved task. WordPress has been doing this for twenty years.

Writing our own engine – this is not developing a journal. It’s developing a CMS that will later be used for the journal. The difference is fundamental. I need to publish articles, not debug the rendering of Markdown.

WordPress may not be the most elegant solution. But it has something that a custom solution doesn’t: a ready-made admin panel, media library, SEO plugins, role system, REST API, WP-CLI for automation. All of this is free, documented, and works.

Stack choice: VPS on Ubuntu, nginx, PHP 8.3, MySQL 8.0, WordPress with the GeneratePress theme. Nothing unusual. All customization is done through mu-plugins and CSS.

How AI Work is Organized

The entire project was ultimately done through Claude Code – a CLI tool that connects to the server via SSH, writes PHP, edits configs, uploads files. I formulate the task in Russian, it executes. The process looks roughly like this:

Me: "Create the homepage: a hero block with a pinned article, a three-column grid of recent articles, a popular block, a list of fresh posts, a grid of sections."

AI: generates a PHP script that creates Gutenberg content, writes CSS, and configures the theme.

Me: "The three columns don’t work, everything is in one."

AI: figures out that WordPress core styles override the custom CSS, moves styles into a high-priority mu-plugin.

Me: "Now it works. But the spacing is too large."

AI: fixes it.

And so on.

What Was Actually Achieved in a Couple of Evenings in a Relaxed Mode

From scratch, from an empty VPS to a working magazine:

• Configured server: nginx with caching, PHP-FPM, MySQL, SSL certificates, firewall, fail2ban.

• WordPress with a custom magazine-style homepage: hero, article cards, fresh list, section grid.

• Design: minimalist, responsive, Inter font, white cards on a light background. Not a UX masterpiece, but looks neat.

• SEO: Rank Math, sitemap, human-readable URLs via slugs, transliteration of slugs.

• 12 mu-plugins for customizing everything – from header to footer.

Iterative Process: How It Looks in Practice

Vibecoding is not “say it and it’s done.” It’s a dialogue. Sometimes quite exhausting.

A typical iteration looks like this:

1. Formulate the task. The more precise, the better the result.

2. AI does it. Usually about 80% correct.

3. Check in the browser. Find the problem.

4. Describe the problem. "Text sticks to the edges," "the block moved," "everything broke on mobile."

5. AI fixes it. Sometimes on the first try, sometimes not.

6. Repeat from step 3.

A specific example from the project. The "Sections" block on the homepage. Initially, the AI generated it as static HTML—the category names were hardcoded directly into the page content. I renamed the categories in the WordPress admin, but nothing changed on the homepage. Makes sense: the HTML is static.

The solution was a mu-plugin with a the_content filter, which inserts up-to-date data from the database every time the page is displayed. But the first version of this plugin contained a hardcoded list of category slugs. By that time, I had already renamed the categories, the slugs had changed—and out of eight sections on the homepage, only two appeared (the ones whose slugs matched the old ones).

The second iteration: instead of a fixed list—get_terms(), which fetches all categories from the database. It worked.

Three iterations for a task that would have been obvious to a WordPress developer on the first try. But I am not a WordPress developer, and I didn’t have to become one.

Another example: CSS. WordPress generates its own inline styles (class is-layout-constrained and similar), which override custom CSS from the theme settings. It took several iterations to understand why the three-column grid stubbornly rendered as a single column. The solution was mu-plugins with priority 999, which are guaranteed to load after the core styles. This is non-obvious knowledge if you don’t live in the WordPress ecosystem. The AI arrived at it through trial and error—not immediately.

Where AI helped

Infrastructure. Setting up nginx, PHP-FPM, MySQL, SSL, firewall—all done through SSH commands generated by the AI. For me, this is routine, but it saves a lot of time. The main thing is to watch and verify exactly what the AI is doing.

WordPress customization. I don’t know the WordPress API at the level of hooks and filters. The AI does. It wrote 12 mu-plugins, each solving a specific task: removing the sidebar, overriding the grid, adding search to the header, creating a dynamic category block. I would have spent significantly more time on this digging through documentation.

CSS. I describe "cards with shadows, hover lift effect, mobile responsiveness"—and get ready-made CSS. Not perfect, but functional. Then we tweak it selectively.

Where AI didn’t help (or got in the way)

Does not see the result. The AI (at least, the console version of Claude Code) does not open a browser. It doesn’t know what the page looks like after its edits. All testing is on me. I look at it, describe it in words, and it makes the changes. This works, but it’s slow. Sometimes it would be easier to show a screenshot than explain “here, the text is sticking to the edge.” Actually, this is the approach I eventually settled on.

Does not understand the context of changes. When I renamed categories in the WordPress admin, the AI couldn’t know about it—it doesn’t track the state of the database in real-time. The solution with hardcoded slugs made sense at the time of writing, but became a problem after my manual changes.

Overwrites changes. Sometimes, when fixing one issue, the AI breaks something else. A classic example: I fixed the header break in the “Recent Posts” block via sed—accidentally replaced styles for the date too. Had to re-upload the entire file. It’s a minor thing, but it adds up.

Does not replace understanding of architecture. The AI can write a WordPress filter, but the decision “we need a filter, not static HTML” is mine. Or it’s theirs—but only after I explain the problem. Initiative is rarely shown, and when it is, it’s not always successful.

Plugins and the ecosystem. I installed Cyr-To-Lat for slug transliteration. It turned out that the plugin only transliterates server-side on save, but not in the Gutenberg editor before saving. We spent time figuring out that this is normal behavior, not a bug. A developer with experience in WordPress would simply have known this.

When vibecoding works

• Prototypes and MVPs. When you need to test an idea, not build a large production system. Our journal is an MVP, and it does its job.

• Standard tasks on an unfamiliar stack. I know what I need but don’t know the API of the specific platform. The AI fills in that gap.

• Small teams and solo projects. When there’s no separate frontend, backend, or DevOps person—the AI allows one person to cover all roles. Not perfect, but good enough.

• Customizing ready-made solutions. WordPress, Shopify, Bitrix—when you need to tweak something, not build from scratch.

When it doesn’t work

• Safety is critical. AI does not think about safety proactively. It will not suggest rate limiting, it will not consider CSRF, it will not check for SQL injections – unless you ask. Yes, there are skills where this is built in by default. But you need to be aware of this and apply it.

• You do not understand the subject area and hope that AI will "figure it out on its own." It won’t. It will produce plausible code that will break on the first encounter with reality.

• You cannot assess the quality of the result. If you don’t see flaws in AI’s reasoning, you will just be surprised why things sometimes fail.

Numbers

• Time: from an empty VPS to a working content blog – a couple of weekends, a few hours per day.

• Infrastructure cost: VPS (about 500–700 RUB/month), domain, SSL is free.

• Development cost: subscription to Claude. Zero hours of paid development.

• Code volume: ~12 mu-plugins (PHP), ~600 lines of CSS, a few Python scripts for complex tasks. All of this was written by AI, I wrote not a single line.

• Number of iterations per typical task: 2–4.

Conclusions

Vibecoding is neither magic nor a replacement for a developer. It is a tool that allows a person with a technical background (but without deep specialization in a specific stack) to create projects that previously required hiring a specialist or long self-study.

The key phrase is "technical background." I understand what nginx, DNS, SSL, SQL, CSS specificity, REST API are. I don’t know WordPress hooks by heart, but I understand what a hook is. Without this foundation, vibecoding becomes a black box – you can’t formulate the task, check the result, or understand why something broke.

Our blog works. Articles are published. SEO is configured. This is not an enterprise solution, but for the task of a "content blog for a school," it’s more than enough. And it was done by a single person, who was also working on other projects in parallel.

Probably, a professional WordPress developer could have done better. Surely, more correctly. But there was none, and the blog was needed. And vibecoding allowed us to solve this task – not perfectly, but functional. And in real life, "works now" is often more important than "perfectly never."

Conclusion from the article headline: you don’t need to rush into "coding" just because it’s trendy, youthful, and in fashion right now. Of course, sometimes you do need actual code, an application. But far from always! Don’t limit yourself. AI in your hands is a fantastic multitool, not a hammer.

Result

Our School All Together — A Journal about Education

For a start, in my opinion, everything is just great!

The texts are original, "crafted".

Images — yes, obviously AI-generated. But still much better than mismatched stock images. We’ll find a designer and come up with something more original.