Alfa-Bank Showed How Skeptics Deployed an Internal HR Service to Production with GLM-5

Alfa Bank shared a case where a team of vibe-coding skeptics brought a new HR service to production in several weeks using GLM-5. The experiment showed that AI significantly accelerates prototyping and routine development, but doesn't relieve the team of responsibility for architecture, Git, and release.

How the Project Was Selected

A pilot within HR Tech was assembled from three people who initially didn't believe in the practical benefits of vibe-coding: a team lead, a systems analyst, and a product manager. They were given freedom to choose a task, and the team decided not to do an abstract demo project, but instead take a real feature from the Alfa People development roadmap. This is how the "My Goals" service appeared, where bank employees can set goals and link tasks to them within the corporate HR platform.

The bet was not only on speed, but also on reasonable risk. If the project hadn't taken off, it wouldn't have broken critical business processes, but if successful, it would have closed a real need. Deadlines, meanwhile, were quickly tightened: the deadline was moved up several times, and development time was reduced to just a few days.

The team used already-conducted discovery, collected user pain points, and described minimal solutions, then gave the model the task of preparing a draft of business requirements.

How Development Went

In practice, the most challenging turned out not to be GLM-5 itself, but the collaborative work of people who had never written production applications before and had almost no experience with IDE and Git. The team lead had to first do a quick onboarding, set up the environment, and explain basic actions with branches, pulls, and pushes. Without this, AI did indeed accelerate individual pieces of work, but the entire workflow was slowed down by every conflict, misunderstanding, and divergence in changes. Further, the process looked like this:

• the team lead, systems analyst, and product manager worked on the service
• the interface was assembled through text descriptions and series of quick iterations
• the team created 19 prototype versions before choosing the basis for the product
• due to high load on GLM-5 during the day, development was often shifted to night hours
• among 15 pilot teams, only this composition managed to bring the service to production

AI mainly helped with layout, forms, validators, and initial versions of screens. The product manager described what the interface should be, the model generated HTML and UI logic, and the team lead then connected it to the backend and brought it to working order. After release, the service quickly gained real usage: in the first week, 10,000 unique users were recorded, 9,240 goals created, and 981 linked tasks, which for an internal product looked like a very strong start.

Where Limitations Emerged

The case demonstrates well that the main bottleneck in enterprise AI-driven development is not in code generation, but in engineering discipline. When multiple participants are simultaneously changing the project, lack of Git knowledge turns into constant manual work resolving conflicts. The second problem is infrastructural: 15 teams participated in the pilot at the same time, and during the day GLM-5 could take several minutes to respond, which made the tool almost useless and threw off the work rhythm.

Another telling moment happened right before the demo: the model and plugins became unavailable, and final bugs had to be fixed manually. This quickly sobers you up and dispels the illusion that AI can completely replace an engineer in a critical moment. Architecture, integrations, security, log verification, and solving edge cases still remained on the experienced developer's side.

In fact, it was precisely the manual fixes at the last moment that allowed the presentation and release to go smoothly without any issues.

"In large companies, vibe-coding is not a replacement for a developer,

but a tool in the hands of an experienced specialist."

As a result, the team arrived at a more sober usage model: AI is suitable for parallel work on routine tasks, interfaces, and draft hypotheses, but doesn't eliminate technical leadership. If release boundaries are not fixed, there's a temptation to infinitely expand the scope of tasks, because it seems like the model will "do just a bit more." In practice, it was precisely a strict task frame, manual control, and the ability to stop improvements at the right time that allowed the service to be completed.

What This Means

Alfa Bank's story is important because it shows vibe-coding without the advertising filter. Within a large company, it can already accelerate the launch of internal products, especially at the prototyping stage and typical UI tasks, but it only works where there's an experienced engineer, clear scope of work, and willingness to manually handle everything critical. In this scenario, AI is not autopilot, but a team accelerator that delivers results only with a mature process and strict accountability for the outcome.