Habr: author explained why AI should not be reduced to vibe coding alone

A column on Habr made an unexpectedly sober point: the problem isn't with vibe coding itself, but with the habit of reducing work with AI to just writing code. The author suggests thinking broader and choosing not the most "technological," but the shortest and maintainable path to results.

Not Code for Code's Sake

The text starts with a critique not of the models, but of the term "vibe coding" as too narrow a frame. If you constantly think in terms of "let's generate an app," it's easy to miss more practical solutions. For a data report, sometimes it's enough to ask AI to assemble an Excel file with formulas and a clear structure. For a content project—select a combination of a ready-made CMS, template, and plugins, rather than spending time on frontend, deployment, and debugging your own stack.

"AI in your hands is a great multi-tool, not a hammer."

This is the main pivot of the article: code shouldn't be the goal in itself. If a task has long been solved by the market, AI is more useful as an accelerator for setup, customization, and launch, rather than as a factory for new technical debt. This approach is especially important for small teams, where after launch the system still needs to be maintained, handed over to other people, and not buried in questions about access, security, and compatibility.

Blog Instead of Your Own CMS

The author illustrates this with a specific case: there was a need to quickly launch an expert education journal for a small private school. The temptation was typical for 2026—take Claude Code or another agent and "vibe code" your own CMS on a trendy stack. But after a quick reality check, the solution turned out to be obvious: a blog with sections, SEO, images, search, and RSS—this is an already solved problem that WordPress has covered for years.

Instead of a custom app, a pragmatic stack was chosen: VPS on Ubuntu, nginx, PHP 8.3, MySQL 8.0, WordPress with GeneratePress theme.

AI didn't go anywhere—it was used as an executor via SSH, writing PHP, editing configs, tuning the theme, and assembling customizations through mu-plugins.

• server with nginx, PHP-FPM, MySQL, SSL, firewall, and fail2ban
• journal homepage with a hero block, article cards, and section grid
• basic SEO, sitemap, and human-readable URLs
• 12 mu-plugins for targeted customization
• about 600 lines of CSS and several helper Python scripts

Essentially, the author didn't abandon AI—he stopped forcing AI to build what already exists. This is the central argument of the article: in many projects, the win comes not from maximizing the amount of generated code, but from the ability to rely on a ready-made platform and polish only the narrow spots.

Where AI Is Really Useful

The strongest part of the text is the description of the real process, without magic and without promotional hype. AI didn't do everything "with one command." The work went in iterations: a person formulates a task, the model does roughly 80% of what's needed, then a cycle of checking, finding visual problems, and targeted fixes begins.

For an unfamiliar stack, this still gives enormous time savings, because you don't need to spend weeks learning WordPress API, hooks, filters, and CSS cascade quirks. But the article honestly lists the limitations too. A console agent doesn't see the result in a browser, doesn't know about manual changes in the admin panel, and can easily break an adjacent block while fixing the current one.

In one case, AI made the categories block static HTML, and after renaming sections on the homepage, nothing updated. The fix came only after several iterations: first through the_content filter, then by abandoning hardcoded slugs in favor of get_terms(). In another case, they had to separately figure out why WordPress core styles were breaking the three-column grid, and raise the priority of custom styles to 999.

From this comes the second important conclusion: AI doesn't replace architectural thinking and basic technical competence. It accelerates infrastructure, customization, and routine CSS, but doesn't make mature product decisions on its own. If a person doesn't understand the domain, doesn't notice security errors, and can't assess the quality of the result, the model will simply produce plausible answers that will fall apart on a real project.

What This Means

The Habr column hits the nerve of the market well: it's too easy to start measuring AI success by the amount of code written around it. In practice, business more often needs not a new framework, but a fast, cheap, and maintainable solution. Therefore, the most useful AI scenario today is not mindless vibe coding, but choosing the shortest route: somewhere it will be a custom service, and somewhere Excel, WordPress, or another ready-made product that you can launch and hand over without extra pain.