AI кодови асистенти в продукция: какво научихме след една година
Когато през април 2025 дадохме AI асистент на всеки инженер, очаквахме две неща: краткосрочен ръст в продукцията и последващ удар в тавана на ползата. Това, което реално се случи през следващите дванадесет месеца, се оказа по полезно и по неприятно от двете прогнози.
Къде отиде времето
Основните ползи не бяха в писането на код, а около него: тестове за стари адаптери на фискални принтери, миграционни скриптове, първа версия на release notes и превод на неясни логове от контролерите по станциите. При нови функционалности ускорението бе умерено. При поддръжка и glue код измерихме 30 45% по кратко време за цикъл, потвърдено спрямо Jira тикети от предишната година.
Къде боля
Два провала се появиха многократно. Първият самоуверено грешни предложения в специфична домейн логика: закръгляния при фактуриране, ДДС правила, ISO 8583 рамкиране. Вторият тихо отслабване на умението за четене на код при по младите инженери: когато асистентът обясни функция, не трябва да я разбираш, за да продължиш. Вече изискваме всеки pull request по фискалния модул да съдържа кратко писмено обяснение от автора, не от асистента.
Какво променихме в работния процес
Въведохме три предпазни механизма. Собствен linter, който маркира генериран код в чувствителни модули без човешки написан тест до него. Веднъж месечно „ден без асистент“, за да поддържаме базовата форма на екипа. И кратък вътрешен style guide, индексиран в асистента, с нашите правила за именуване, логване и обработка на грешки тази промяна имаше най голям ефект върху качеството.
Какво бихме казали на екип, който започва сега
Измервайте времето за цикъл по тип тикет, не на ниво организация. Теглете твърда линия около регулирания код за нас това е фискализацията, PCI обхвата и логиката по безопасност в колонките. И планирайте седмица за обучение, не час: най много ползи извлякоха хората, които се научиха първо да искат тестове, после код.
оставете коментар