Vibe Coding as Surfing Between Hype and Neuro-Slop

Context

I work in a typical product IT company, with tasks, processes, and approaches to development and operations that correspond to this status. The core of our product line is a platform for communicative AI agents. There are also a few additional products - a voice training system and an omnichannel platform for automating the work of contact center employees, both in chat and voice. For those interested in details — the link to the website is in the profile description.

Technologically, our products are implemented on the following tech stack:

• Python / Go for the backend

• React for the frontend

• Microservice architecture (the criteria for compliance with this - is a separate large topic, we at least strive for this :)

• LLM models - both open-source and proprietary are used

• Prod - k8s, helm, ArgoCD

• Observability stack: Victoria Metrics, Grafana, Alert Manager, Loki

An important point - our products must provide the possibility of installation in the client's information contour on an on-premise model. This sets certain frameworks and limitations regarding the solutions we can use under the hood.

About six months ago, our team began using vibe coding focused on creative experiments with prompts and architecture for rapid prototyping of new agent features. By the roughest estimates, productivity has increased by 3-4 times.

What kind of beast is this?

The term "vibe coding," thanks to Karapaty, has become so popular that it has begun to stretch and blur in meaning. Some call any use of LLM in development vibe coding — even one request a day in Cursor is already "vibe coding." Others understand it as an extreme scenario: the developer does not write a single line manually but simply describes the desired application without architectural and algorithmic details and iteratively receives results from the model.

The second option is not just a philosophy; it is quite feasible today, and it provokes the most intense debates. Furthermore, when I mention vibe coding, I mean something in between: the developer actively delegates a growing share of work to the LLM but remains engaged in the context and retains engineering responsibility for the outcome.

The camp opposing code generation often appeals to the concept of "neuroslop" — supposedly everything that "comes out" of the LLM is unpredictable, full of hidden bugs, and unsuitable for production. Upon closer examination, this position has a very specific factual basis.

The first problem is troubleshooting. A developer who hasn't written code themselves and is poorly oriented in it will be helpless when something breaks in production at three in the morning. The second issue is architecture: an LLM without strict boundaries tends to generate solutions that work locally but do not scale well and are difficult to extend. The third is performance: without explicit load requirements, the model will not optimize what it was not asked about.

All these problems are real. But they arise not from the mere fact of using an LLM — they occur when architectural boundaries, reliability requirements, availability, and stack are not initially defined. In my opinion, the problem lies not in the tool itself but in its use without emphasis on the task-setting stage.

The golden mean that generates results

There is space between "I don’t write a single line myself" and "LLM only for autocompletion." It is in this space that real efficiency gains are found. A competent engineer sets the boundaries: stack, architectural principles, reliability requirements — and then delegates implementation to the LLM agent. The LLM writes code, and the person controls the direction and makes architectural decisions.

About a year ago, our typical workflow looked like this: the developer decomposed the task into detailed technical pieces and submitted each to the AI agent. This worked but required significant preliminary manual work. Now this preliminary part is also being automated — largely thanks to the mechanics of so-called skills.

Skills and agents: how it works in practice

A skill is essentially providing an agent with knowledge for a specific subject area or functional role. A product owner, IT architect, cybersecurity specialist, business analyst — each skill sets the necessary context for the agent, pulling in relevant standards and frameworks. In Cursor, global skills can be defined — they are registered once, after which the agent determines which skill fits the current request. At the same time, there remains the option to explicitly specify a skill for the current request.

You write "I want to write a technical specification" — the agent understands that a technical writer or business analyst skill is needed here, connects it, conducts an interview with you, asks clarifying questions, and forms a work plan. This plan is then sent to other agents. A person without a deep technical background, using properly configured skills, receives a structured and reproducible result — rather than chaotic code generated "out of thin air".

To date, developed ecosystems of agent skills have already been assembled. In my opinion, the following projects deserve special attention:

• https://github.com/obra/superpowers

• https://github.com/msitarzewski/agency-agents

• https://github.com/lst97/claude-code-sub-agents

Our company also actively uses agent skills to solve business process tasks that are not directly related to the field of development and operation. However, this experience and the challenges surrounding it deserve a separate article, please write in the comments.

Tools: what we use

The main tools used for development at targetai are Cursor and Claude Code. Codex from OpenAI is gaining popularity in the industry, but we resort to its use primarily in exceptional situations (for example, when changing the strategy and criteria for blocking access to Claude Code).

Regarding the models: our experience consistently shows that claude-opus-4.6 from Anthropic outperforms GPT-5.x in development tasks — despite OpenAI periodically reporting a higher position in specific benchmarks. It is also worth noting Qwen Coder 235B — a Chinese model comparable to Claude Sonnet across several indicators and actively catching up with the leaders. What will happen by the end of the year is an open question. The integration of agent skills is already standard for development environments that support vibe-coding. This is a boxed functionality of any of the aforementioned tools.

A real example from our life: a product in 4 weeks

The first product fully developed through the skill and agent model was ready in 4 weeks by one team. Without LLM, the same team would have spent 6–12 months on it. This is not a theoretical estimate — it is based on similar tasks that were solved earlier.

It should be noted that currently, this IT product is just beginning to attract its first live users. Accordingly, the volume of tasks for improvements received directly from users is currently insignificant.

In the development of this product, the proposed approach was used in full. During the development, the following agent roles were identified (here and below, the terms “skill” and “role” are considered synonymous):

• Product Manager (creates PRD)

• Architect (takes PRD, writes specs for the backend, contracts, data model, migrations, integrations, events)

• Designer (takes PRD, writes the specification for the frontend)

• Backend Developer Python

• Backend Developer Go

• Frontend Developer

Breaking down agents into roles necessitates the existence of intermediate artifacts. A simple example is the PRD (Product Requirements Document) — this artifact is the main output for the product manager agent. This requirement automatically brings us to a state where each iteration of work by any agent leaves clear traces.

And... sets such boundaries where the developer is forced to focus on the most detailed description of the requirements for the result! Such a requirement is a mandatory attribute of a sufficiently mature development process. This is also inherent in non-agency development of IT solutions. BUT - when a task suddenly falls on the team (people) in the mode of "it should have been in production yesterday" - it is usually characteristic for people to skip some stages in favor of the speed of implementation. The multi-agent approach makes this unavoidably necessary! Thus, this approach places developers in conditions where any feature leaves a set of necessary artifacts. Moreover - it redirects the developer's focus specifically to the design stage.

The presence of quality artifacts allows for a much clearer picture of the impact of proposed changes on the already existing functionality. In addition - with this approach, such artifacts as test cases and user manuals for working with some feature conditionally appear automatically. At the same time - creating agent skills based on the best industry practices (the aforementioned repositories of agent role sets) allows for immediate compliance with these practices.

As a result - we get a huge boost in development speed, while leveling out the shortcomings typically inherent in selective use of AI agents to solve narrow technical tasks. This has allowed us to achieve not a prototype, but a ready-to-load solution within 1 month.

How we measure changes

There are three metrics that clearly reflect the essence of the shift. The first - the share of lines of code written by a human versus those written by the model: the ratio is steadily shifting towards LLM. The second - the scope of tasks delegated to the model: a year ago these were specific technical subtasks, now - end-to-end "create a service with such requirements." The third and most indicative - lead time for solving a task from assignment to finished result.

"And why not complete autonomy?" We tried. The chain "agent-productologist → agent-architect → agent-developer → agent-reviewer → agent-tester" looks nice on the diagram, but in practice, each subsequent agent inherits and amplifies the mistakes of the previous one.

By the third link, a deviation from the original idea accumulates, which no one catches because there’s no one to catch it. Yes, we tried different approaches to prompting; the problem is not in a specific implementation, but in the lack of a control point between the links.

The result is formally functional code is assembled, tests pass, but the decisions made entirely without human involvement turn out to be fragile. We do not fundamentally reject complete autonomy; we tried it and saw that today an engineer in the role of orchestrator provides a more predictable and supported result.

And we do not stop testing hypotheses and approaches when working with agents.

Our Compromise Path

Neither a complete rejection of LLMs nor thoughtless extreme vibe-coding yields good results. The first leaves you slower than competitors. The second creates a debt, the work on which has an increasing cost over time. The golden mean — the engineer sets the framework, the agent implements it, skills ensure the quality of subject matter expertise — allows creating in a month what previously took a year.

The trend with skills has begun to develop actively literally in recent months. If it continues, the entry threshold for quality development through LLM will decrease — and this will change the balance of power faster than many expect.