Adopting AI in Development: Vibe Coding Instead of Developers

A Bitrix24 product lead has published a case study on adopting AI in development: a team of five with no dedicated developers spent three months building a multi-user service for an internal corporate marathon with the help of AI assistants.

What they were building

The task looked compact: an internal tool for Bitrix24's annual sports marathon, where employees log physical activity, see colleagues' results and compete in teams. No off-the-shelf solution fit the specific format, so the team decided to build the product from scratch and chose vibe coding as the main development tool.

• Team: 5 people, no dedicated backend developer
• Timeline: about 3 months, work done only outside working hours
• Approach: vibe coding, with AI assistants as the main tool for writing code
• Result: a working multi-user service for internal users

Obraztsova warns up front: no theory about microservices, no elegant architecture diagrams, just an honest account of the pitfalls a team hits when product people take on a truly technical project.

Why quick wins run out

The first weeks deliver the classic vibe coding effect: code appears fast and features come together one after another. The AI assistant writes components, handles errors and turns a task into working code in seconds. Product people feel like developers, and that is a real "wow moment" at the start.

Over time, though, the pace drops. AI tools hold the context of a single component well, but get confused once the system grows to dozens of interconnected modules. Inconsistent dependencies, duplicated logic and hard-to-diagnose errors at the boundaries between layers all demand something the AI does not do for you: architectural thinking.

"There will be no advice here about microservice architecture or pretty diagrams.

It will be an honest account of what happens when product people take on a complex technical project, what pitfalls they hit and what they end up with," Obraztsova writes.

How vibe coding becomes an AI-driven team

The next stage is deliberate reorganization. The team moves from chaotic prompting to structured work: each member specializes in a specific part of the product and knows how to phrase tasks for the AI within their own domain.

This shift changes the skills that matter. A product lead in an AI-driven team spends more time decomposing tasks and setting the right context for the AI than writing code by hand. Prompt design and architectural design become equally important skills, and real team productivity emerges where they intersect.

In the end, the five arrived at a model in which the AI handles routine code writing, while humans do what the AI does poorly: making architectural decisions, managing technical debt and synchronizing between modules.

What this means

The Bitrix24 case reflects a maturing pattern among AI-oriented teams: vibe coding does lower the entry barrier for non-technical people and gives a fast start, but it does not remove the need for systems thinking. Without an architectural approach, a product does not get past the prototype stage. Companies that realize this sooner avoid costly refactoring. AI speeds up execution but does not replace design.

How can you use a neural network to develop an internal tool?

The Bitrix24 team used AI assistants as the main development engine, building a multi-user service over three months of vibe coding (work done in the evenings and on weekends).

What does adopting AI in development give you?

In the Bitrix24 case, adopting AI allowed five employees without dedicated developers to build a full multi-user service for a corporate sports marathon.

What problem were they solving?

They needed an internal tool for Bitrix24's annual sports marathon, where employees log physical activity, see colleagues' results and compete in teams.

How long did development take?

Three months of work in the evenings and on weekends.