Компонент за 30 минут: поиск разработчика-камикадзе и почему это катастрофа

Инженерный разбор того, как «скорость нажатия кнопок», «лондонские партнёры» и 30 бесплатных тестовых заданий выдают компанию. С цифрами, кодом и прогнозом коллапса.

На прошлой неделе я откликнулся на вакансию веб-программиста в «Мир охоты» — сеть магазинов товаров для охоты, рыбалки и активного отдыха, которая позиционирует себя как одна из крупнейших в России.То, что началось как стандартный процесс найма, превратилось в хрестоматийный пример токсичности, замаскированной под «передовые практики».Спойлер:

Тестовое задание за 30–60 минут (включая развёртывание Битрикс)
«30 кандидатов уже выполнили ТЗ за 2 дня»
«Лондонские партнёры» используют 1С-Битрикс
Философия: «сейчас важна скорость нажатия кнопок»

Это не просто «плохая вакансия». Это инструкция по уничтожению кодовой базы за 6 месяцев. Разбираю с позиции разработчика с 10-летним опытом в Битрикс и специалиста по обучению LLM-моделей.

Вакансия: Веб-программист (1С-Битрикс)

Опыт: 3–6 лет

Стек: PHP 7+/8, Bitrix D7, JavaScript, Git

Ключевое требование: «Активное использование AI-инструментов для ускорения работы»Формат: Удалённо, ГПХ, почасовая оплата

На бумаже — ничего необычного. Откликнулся.

После первичной переписки HR присылает ТЗ:Задача: Реализовать компонент на 1С-Битрикс (D7), который:

Получает список товаров из инфоблока
Выводит товары с ценой и остатком
Добавляет сортировку по цене
Реализует кеширование

Дополнительно: использовать D7, читаемый код, описать AI-инструментыОценка времени: «Если Вы работаете AI + Bitrix регулярно, задание займёт 30–60 минут»

Давайте отключим веру в чудеса и посчитаем фактическую трудоёмкость:

ЭТАП 0: ПОДГОТОВКА ОКРУЖЕНИЯ (игнорируется работодателем)

Установка Битрикс (веб-сервер, PHP, БД) — 15–30 мин
Настройка компонентного кеша — 10–15 мин
Создание инфоблока + тестовых данных — 10 мин
Настройка прав доступа, индексация — 5–10 мин

Итого этап 0: 40–65 минут

ЭТАП 1: РАЗРАБОТКА КОМПОНЕНТА

Структура компонента (.description.php) — 15 мин
Реализация getList() на D7 (ORM) — 20–30 мин
Сортировка + валидация параметров — 10 мин
Тегированный кеш (не просто общий!) — 15–20 мин
Обработка исключений, логирование — 10 мин

Итого этап 1: 70–85 минут

ЭТАП 2: ТЕСТИРОВАНИЕ

Проверка логики — 10–15 мин
Тестирование инвалидации кеша — 10 мин
Edge cases (сортировка, пустые данные) — 10 мин

Итого этап 2: 30–35 минут

ОБЩАЯ СУММА: 2.5–3.5 ЧАСА (150–210 минут)

Оценка работодателя: 30–60 минут

Реальная оценка: 150–210 минут

Расхождение:400%

Это не «оптимистичный прогноз». Это фундаментальное непонимание процесса разработки или сознательная манипуляция.

В финальном ответе прозвучала фраза, которая должна насторожить любого:

«У нас уже 30 кандидатов выполнили ТЗ за 2 последних дня, мы не сможем себе позволить оплатить каждое»

Считаем экономику процесса:

Кандидатов в день: ~15 человек
Время на проверку одного ТЗ: ~15–20 минут
Время команды на проверку: 4–5 часов в день
Стоимость часа техлида: ~3 000–5 000 ₽
Ежедневные затраты на скрининг: ~12 000–25 000 ₽

Вопрос на миллион: если компания готова тратить 12–25 тысяч рублей в день на проверку тестовых, почему она не готова оплатить одно выполнение ТЗ кандидату (2–3 часа × ставка)?

Если проверка ТЗ не происходит, а код просто собирается в папку:

30 кандидатов × 2 часа работы = 60 часов бесплатной разработки

Рыночная стоимость часа битрикс-разработчика = 1 500–3 000 ₽

Потенциальная «экономия» = 90 000–180 000 ₽

Вывод: либо процесс найма катастрофически неэффективен, либо это осознанная модель получения бесплатной рабочей силы. В обоих случаях — бегите.

Цитата из переписки:

«По такой системе вот уже несколько лет работают наши Лондонские партнёры и мы планируем так же перейти на данный формат»

Сравним факты:1С-Битрикс:

Основная география: РФ, СНГ (95%+)
Язык документации: Русский
Популярность в Европе: <1%
Типичный e-commerce стек: Битрикс, Инфостарт

Западный рынок:

Основная география: Европа, США
Язык документации: Английский
Популярность Битрикс: практически нулевая
Типичный e-commerce стек: Shopify, Magento, WooCommerce, Laravel

Утверждение «Лондонские партнёры используют Битрикс» эквивалентно:

«Наша команда в Кремниевой долине работает на 1С:Предприятие»
«Партнёры из Берлина выбрали платформу Тинькофф для процессинга»

1. Манипуляция авторитетом

«Лондон» создаёт иллюзию международного уровня, престижа, высоких стандартов.

2. Копипаст из другой вакансии

Текст не адаптирован под реальный стек, просто скопирован откуда-то.

3. Некомпетентность источника

HR или руководитель не понимает разницу между технологиями и рынками.

Любой из вариантов — сигнал о непрозрачности коммуникации.

Кульминация диалога, когда я указал на нереалистичность оценки:

«И здесь да, сейчас важна "скорость нажатия кнопок", о которой Вы писали выше. Мы не готовы предложить Вам должность.»

Перевод с корпоративного на русский:

«Нам не нужен инженер. Нам нужна печатная машинка.»

Взгляд разработчика, который не только пишет код, но и обучает LLM-модели

Компания заявляет, что ищет «ментора по внедрению ИИ», который научит команду «генерировать код и проверять его». При этом приоритет — «скорость нажатия кнопок».

Давайте посмотрим, что произойдёт с кодовой базой через 3–6 месяцев такого подхода.

Команда, воодушевлённая «новым форматом», начинает генерировать код через ИИ. Ментор учит:

Напиши компонент битрикс, который выводит товары с ценой, сортировка по цене, кеш. Быстро.
Типичный промпт в философии «быстрее»

Результат генерации:

// component.php $arResult = []; $res = \Bitrix\Main\ORM\Data\DataManager::getList([ 'filter' => ['=ACTIVE' => 'Y'], 'order' => ['CATALOG_PRICE_1' => $arParams['SORT']], // ⚠️ НЕТ ВАЛИДАЦИИ $arParams['SORT'] — SQL injection возможен ]); while($item = $res->fetch()) { $arResult[] = $item; } // ⚠️ НЕТ ОБРАБОТКИ ИСКЛЮЧЕНИЙ // ⚠️ НЕТ ТЕГИРОВАННОГО КЕША — только общий // ⚠️ НЕТ ЭКРАНИРОВАНИЯ входных параметров $this->IncludeComponentTemplate();

На первый взгляд: работает, сортирует, кеш есть.На самом деле:

🚨 Уязвимость к SQL-инъекциям через $_REQUEST['SORT']
🚨 Кеш сбрасывается целиком при любом изменении
🚨 Нет логирования — при падении «белый экран»
🚨 Жёсткая привязка к CATALOG_PRICE_1 — невозможно переиспользовать

Метрики на этом этапе:

✅ Скорость разработки: +200%
❌ Покрытие тестами: 0%
❌ Статический анализ: не настроен

Команда масштабирует подход. Появляется 10–15 таких компонентов. Начинается магия:

// component2.php — другой разработчик, другой ИИ $cache = \Bitrix\Main\Data\Cache::createInstance(); if($cache->initCache(3600, 'unique_key', 'folder')) { $arResult = $cache->getVars(); } else { // ⚠️ ЗАБЫЛИ $cache->startDataCache() ПЕРЕД ЗАПИСЬЮ // ⚠️ КЛЮШ КЕША не включает параметры сортировки // = разные сортировки отдают ОДИН И ТОТ ЖЕ кеш }

Симптомы:

🐛 Пользователь меняет сортировку → видит товары в старом порядке
🐛 Админ добавляет товар → он не появляется до полного сброса кеша
🐛 При нагрузке >100 RPS компоненты возвращают устаревшие данные

Попытка диагностики:

# Логи пустые — нет логирования # Профайлер показывает: 80% времени — повторные запросы к БД # Но понять, какой компонент виноват — невозможно

Метрики:

⚠ Время на фикс бага: 4–8 часов (иголка в стоге сена)
⚠ Регрессии: 30% изменений ломают «что-то где-то»

Кодовая база достигает критической массы «быстрого кода». Происходит коллапс:

// Типичный «унаследованный» компонент спустя 5 месяцев class LegacyFastComponent extends CBitrixComponent { // ⚠️ 300+ строк в одном методе // ⚠️ 7 уровней вложенности условий // ⚠️ Хардкод цен, скидок, валют в трёх местах // ⚠️ Кеш инвалидируется «на всякий случай» при любом событии // ⚠️ Зависимости от глобальных $_REQUEST, $_SESSION, $USER // ⚠️ Нет интерфейсов, нет контрактов, нет тестов public function executeComponent() { if($_REQUEST['sort'] == 'price') { // ... 50 строк } elseif($_REQUEST['sort'] == 'name') { // ... ещё 50, но с другой логикой кеша } // И так 6 вариантов сортировки — КОПИПАСТ с микро-отличиями } }

Что происходит с командой:

Новый разработчик

Тратит 2 недели, чтобы понять, как добавить одну фичу. Увольняется.

«Опытный специалист» (из их вакансии)

Пытается рефакторить → ломает 3 других компонента → боится трогать

Ментор по «скорости»

Учит генерировать ещё быстрее → добавляет ещё 2 компонента в неделю

Техлид / Архитектор

Пишет документ «Почему всё сломалось» → его игнорируют, потому что «надо быстрее»

Бизнес-метрики на этом этапе:

📉 Скорость разработки: -70% (по сравнению со стартом)
📉 Стабильность продакшена: <95% (постоянные инциденты)
📉 Стоимость изменения: +500% (правим 5 мест для одной фичи)
📉 Мораль команды: на нуле

Здесь я говорю не как разработчик, а как специалист по обучению LLM-моделей.ИИ-ассистенты — это не «волшебная таблетка». Это инструмент, который усиливает паттерны, на которых он обучен.

# Упрощённая аналогия из мира LLM def train_code_model(dataset): if dataset.contains('bad_patterns'): # Код без валидации, кеша, тестов model.learn('these_patterns_are_normal') return model.generate_more_bad_code() # Иначе модель учится на качественных примерах

Что происходит в вашей команде:

Фаза 1: Разработчики генерируют код с промптами «быстро, просто, работает».

Фаза 2: Этот код попадает в репозиторий → становится «контекстом» для будущих запросов.

Фаза 3: ИИ начинает предлагать ещё больше кода в том же стиле, потому что «обучился» на ваших примерах.

Фаза 4: Команда теряет способность отличать качественный код от «быстрого».

Результат: Вы не автоматизируете разработку. Вы автоматизируете деградацию архитектуры.

Для контраста — как я использую ИИ в своей практике:

«Создай компонент Битрикс на D7 со следующими требованиями: 1. Использовать ORM \Bitrix\Main\ORM, без прямых SQL-запросов 2. Входные параметры: $arParams['SORT'] (валидация: только 'price', 'name', 'date'), $arParams['CACHE_TIME'] 3. Кеш: тегированный, теги формируются из ['iblock_{ID}', 'price_{CAT_ID}'], инвалидация по событиям 4. Обработка ошибок: логирование в \Bitrix\Main\EventManager, fallback на пустой массив 5. Тесты: подготовить пример теста на PHPUnit для prepareParams() 6. Документация: добавить PHPDoc для всех публичных методов Сгенерируй код с комментариями, объясни выбор архитектурных решений.»

✅ Правильный промпт — это спецификация, а не «сделай быстро»

Результат:

✅ Код, который можно поддерживать
✅ Архитектура, которую можно масштабировать
✅ Документация, которая помогает

Генерация бойлерплейта

→ Как использую ИИ: прошу сгенерировать шаблон компонента

→ Что делаю сам: проверяю соответствие стандартам Битрикс

Рефакторинг

→ Как использую ИИ: прошу предложить оптимизацию запроса

→ Что делаю сам: анализирую, не нарушает ли это бизнес-логику

Поиск багов

→ Как использую ИИ: прошу найти уязвимости в коде

→ Что делаю сам: проверяю находки, добавляю тесты

Обучение команды

→ Как использую ИИ: создаю примеры промптов и паттернов

→ Что делаю сам: провожу код-ревью, объясняю «почему так, а не иначе»

Ключевое отличие: ИИ ускоряет исполнение, но архитектурные решения, валидация и ответственность остаются за инженером.

Если текущий подход сохранится:

«Скорость кнопок» ↓ Код без архитектуры ↓ Технический долг (месяц 1–2) ↓ Баги, которые нельзя воспроизвести (месяц 3) ↓ Страх вносить изменения (месяц 4) ↓ Паралич разработки (месяц 5) ↓ Перезапуск проекта с нуля (месяц 6) ↓ ПОТЕРЯ 6–12 МЕСЯЦЕВ И БЮДЖЕТА

Финальная стадия: даже «опытные специалисты» не смогут разобраться в коде, потому что:

❌ Нет единых стандартов
❌ Нет документации
❌ Нет тестов
❌ Нет логирования
✅ Есть только «быстро», «работает» и «не трогай»

А ментор, который учил «генерировать быстрее», к этому моменту уже будет учить другую команду.

Правило: если вы видите 2 и более пункта из списка в вакансии или переписке — это системная проблема, а не случайность. Задавайте жёсткие вопросы до выполнения ТЗ.

Почему именно 2+?

1 пункт — может быть случайностью, ошибкой формулировки, недопониманием
2 пункта — начинает проявляться паттерн поведения
3+ пунктов — это уже системная токсичность, бегите не раздумывая

Чеклист красных флагов:

Оценка комплексной задачи <1 часа без готового окружения
«Много кандидатов уже выполнили» без объяснения процесса
Приоритет «скорости» над «архитектурой» в формулировках
Оплата ТЗ только «финальному» без критериев
Пассивная агрессия на уточняющие вопросы
Подмена требований по ходу диалога
Упоминание «международных партнёров» в контексте локального стека

Если вы ищете разработчика, который:

✅ Будет «генерировать код и проверять его»
✅ Уложится в 30 минут на компонент
✅ Научит команду «нажимать кнопки быстрее»

— вы найдёте такого человека.Но вы не получите:

❌ Поддерживаемый код
❌ Масштабируемую архитектуру
❌ Команду, которая понимает, что и почему делает
❌ Продукт, который работает стабильно

Вы получите:

✅ Быстрый старт
✅ Много кода
✅ Иллюзию прогресса

А через 6 месяцев:

❌ Код, в который страшно зайти
❌ Команду, которая боится вносить изменения
❌ Продакшен, который падает
❌ Необходимость начинать всё сначала

Вопрос: стоит ли «экономия» 30 минут на тестовом таких рисков?

1. Задавайте вопросы ДО ТЗ

Кто будет проверять?
Предоставляется ли стенд?
Оплачивается ли?
Сколько кандидатов на этапе?

2. Не верьте «примерным» оценкам

Если говорят «30–60 минут», а задача требует 2–3 часа — это либо некомпетентность, либо манипуляция.

3. Цените своё время

Вы — эксперт. Ваше время стоит денег. 2–3 часа на ТЗ = 2–3 часа, которые вы не потратили на обучение, пет-проект или отдых.

4. Распознавайте красные флаги

Что произошло:

Я отфильтровал неадекватного работодателя («Мир охоты»)
Сэкономил 2–3 часа на ТЗ + недели токсичной работы
Получил отличный кейс для портфолио

Что получили они:

30 бесплатных тестовых заданий (возможно)
Публичную репутацию «токсичного работодателя»
Продолжение поиска «скоростного нажимателя кнопок»

Кто выиграл? 👀

Для работодателей (включая «Мир охоты»):

Если после прочтения вы поняли, что ваши процессы похожи на описанные — это хороший знак. Значит, ещё не поздно измениться.

Начните с малого:

ВМЕСТО: «Компонент за 30 минут»

НАДО: «Компонент за 2–3 часа, предоставляем Docker-образ»

ВМЕСТО: «Оплатим финальному»

НАДО: «Оплатим всем, кто выполнил ТЗ по нашим критериям»

ВМЕСТО: «Скорость нажатия кнопок»

НАДО: «Качество архитектуры + разумная скорость»

Результат: вы начнёте привлекать не «кноподавов», а инженеров. Тех, кто строит системы, а не генерирует код. Тех, с кем можно расти.

P.S. Если вы — представитель компании «Мир охоты» и хотите обсудить, почему ваш подход ведёт к катастрофе — я открыт к диалогу. Иногда честный разговор стоит больше, чем 30 бесплатных тестовых заданий. Ваш рекуртер, к сожалению, отрезал возможность какого-либо диалога, после предложения обсудить условия тестового задания, что, к слову, только показало, что вам не нужен ментор, вы не готовы обучаться и слушать, вам нужен тот, кто будет работать по задачам ваших "опытных" специалистов.

Компонент за 30 минут: поиск разработчика-камикадзе и почему это катастрофа

📋 Исходные данные: что обещали

🎯 ТЕСТОВОЕ ЗАДАНИЕ: «30–60 МИНУТ»

⏱ ИНЖЕНЕРНАЯ ДЕКОМПОЗИЦИЯ: СЧИТАЕМ РЕАЛЬНОСТЬ

🚩 КРАСНЫЙ ФЛАГ №1: «30 КАНДИДАТОВ ЗА 2 ДНЯ»

📊 ЧТО ЭТО ЗНАЧИТ НА САМОМ ДЕЛЕ

🎭 АЛЬТЕРНАТИВНАЯ ГИПОТЕЗА

🚩 КРАСНЫЙ ФЛАГ №2: «ЛОНДОНСКИЕ ПАРТНЁРЫ» И 1С-БИТРИКС

🌍 КОНТЕКСТ, КОТОРЫЙ ИГНОРИРУЕТСЯ

🔍 ВОЗМОЖНЫЕ ИНТЕРПРЕТАЦИИ

🚩 КРАСНЫЙ ФЛАГ №3: «СКОРОСТЬ НАЖАТИЯ КНОПОК»

💥 ПОЧЕМУ «СКОРОСТЬ КНОПОК» — ЭТО ИНЖЕНЕРНАЯ КАТАСТРОФА

📉 СТАДИЯ 1: «РАБОТАЕТ — И ЛАДНО» (НЕДЕЛИ 1–4)

📉 СТАДИЯ 2: «ПОЧЕМУ ОНО СЛОМАЛОСЬ?» (МЕСЯЦЫ 2–3)

📉 СТАДИЯ 3: «НИКТО НИЧЕГО НЕ ПОНИМАЕТ» (МЕСЯЦЫ 4–6)

🤖 ПОЧЕМУ ИИ НЕ СПАСЁТ, А УСКОРИТ КОЛЛАПС

Принцип «Garbage In, Garbage Out»

🔧 КАК ДОЛЖНО БЫТЬ: ИИ КАК УСИЛИТЕЛЬ ИНЖЕНЕРНОЙ КУЛЬТУРЫ

✅ ИИ как «второй пилот», а не «автопилот»

🎯 ПРОГНОЗ ДЛЯ КОМПАНИИ С ФИЛОСОФИЕЙ «СКОРОСТИ КНОПОК»

📋 ЧЕКЛИСТ: КАК РАСПОЗНАТЬ ТОКСИЧНОГО РАБОТОДАТЕЛЯ

🔥 ВЫВОДЫ ДЛЯ РАБОТОДАТЕЛЕЙ

💡 УРОКИ ДЛЯ РАЗРАБОТЧИКОВ

🎯 ЗАКЛЮЧЕНИЕ

📢 ПРИЗЫВ К ДИАЛОГУ