Дело о ненужной рекомендательной системе, сделанной с помощью AI

О проблемах найма я узнал не из аналитических отчётов — а потому что сам оказался внутри рынка труда. С одной стороны — как кандидат, с другой — как человек, работавший с HR и процессами найма.

Так же читая новости и статьи, в том числе на Хабре, как стремительно развивается AI в разработке, решил реализовать инженерный эксперимент и создать MVP рекомендательной системы для HR.

В этой статье делаю разбор того что получилось в итоге:

• как архитектура и BDD стали “ограничителями” для агента

• как я формировал и тестировал требования с помощью AI

• как сформировал RAG/контекст для AI агента

• с какими проблемами столкнулся и что сработало

• где мое место в процессе разработки

• какие skills потребовались мне и какие в итоге сформировал для AI агента

Обвинение: Проблемы временные, рынок IT сам перестроится под текущую ситуацию.

Со стороны всё выглядит так, будто AI уже оптимизировал рынок труда: вакансии закрываются, резюме фильтруются, автоматические отклики растут, а подходящие кандидаты находятся по тегам, паттернам и ключевым словам.

Защита: Но когда оказываешься внутри, картина резко меняется. Ты отправляешь десятки откликов — а ответов единицы. Чаще всего это автоматические отказы без объяснений.

Параллельно я продолжал общаться с HR — и с другой стороны всё выглядело не лучше. Сотни откликов на одну вакансию, значительная часть нерелевантная, а времени на вдумчивую проверку просто нет.

В итоге рынок начинает жить «обходными путями»:

• личные рекомендации;

• закрытые профессиональные чаты;

• вендоры с собственными базами кандидатов.

Фактически, рекомендации существуют — но они разрознены, не консолидированы и живут вне систем. Так и появился замысел рекомендательной системы — не как продукта, а как инженерного эксперимента.

Обвинение: BDD и архитектура — оверинжиниринг для MVP

BDD? — Но требования в MVP всё равно поменяются.

Архитектура? — Но AI ведь сам её придумает в процессе реализации.

Со стороны кажется, что BDD и архитектура — это просто способ замедлить разработку и усложнить себе жизнь. Особенно если цель — быстро проверить гипотезу.

Защита: Честно говоря, я и сам не могу утверждать, что с заложенной архитектурой и BDD реализовал бы всё быстрее. Ведь я изначально выбрал именно этот путь.

Только начал я не с требований, а с архитектуры. Сначала задал базовые сущности MVP — слой model . Потом подумал, какие изменения над этими сущностями возможны и как они должны контролироваться — контракты и интерфейсы взаимодействия. А оценив примерный объем разработки выбрал Telegram-бот для UI, в связи с чем выбрал модель - state machine.

И только внутри этой архитектуры начал формировать бизнес-требования:
как именно ведёт себя каждая сущность, кто и что может делать, какие переходы допустимы.

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

Хоть это и выглядит как замедление разработки, так как зачем формировать требования, если уже все есть в голове, зачем писать тесты, которые требуется поддерживать. Но это все была подготовка к подключению AI к разработке. Ведь первоначальная идея была в том, что написанные мною требования и тесты - будут ограничителем для AI агента.

Забегая вперёд — когда я пробовал занести не проработанные требования в задаче: AI начал придумывать поведение, «улучшал» то, о чём его не просили. т.е. BDD был нужен не столько мне, сколько AI. А вот выстроенная архитектура помогла мне, лучше контролировать изменения, которые вносил AI агент.

Обвинение: Всё это красиво работает только на маленьком MVP

Как только продукт растёт, требования начинают конфликтовать, контекст расползается, а контроль превращается в ад.

Защита: Логичный вопрос: а что будет, если этим займётся AI?

В своей работе я и раньше использовал AI — не для генерации требований, а для их проверки.

Базовый подход выглядел так: я передавал user stories, описание задачи, черновые требования и просил AI провести их тестирование. Базовый промт был таким:

Тут AI выступал в роли Test Analyst и проверял требования на полноту, логическую согласованность, однозначность и тестируемость, выявляя риски и противоречия. В случае неопределённостей он не предлагал решений, а формулировал уточняющие вопросы, после чего приводил требования в чёткий, проверяемый вид и выносил вердикт — готовы ли они к реализации.

Ключевой момент: решение о том, считать ли требования готовыми, всегда остаётся за человеком. AI лишь подсвечивает слабые места.

И тут важно понимать: сколько вопросов задаст AI — полностью зависит от входных данных и контекста.

Если контекст размыт — вопросов будет много.
Если требования слабые — цикл уточнений будет длинным.
Если контекст нерелевантен или отсутствует — AI сам начнёт «нащупывать» систему вслепую.

Отступление: По сути тут идеально ложится система RAG. Я реализовывал ее так - у задачи в JIRA есть свои теги, у каждого тега, была своя документация. Например, тег payment добавлял в контекст документацию по платёжным сценариям.

Это частично помогало, но проблему полностью не решало. Сейчас мне уже очевидно: Контекст — это не документация. Документация описывает “что есть”. Контекст для AI должен отвечать на “как должно быть” и “где границы”. Поэтому требования оказались эффективнее.

При этом сами требования могут становиться источником документации. А если добавить к ним код — AI уже способен генерировать техническую документацию с привязкой конкретного требования к конкретной реализации.

Я выбрал BDD, потому что хотел, чтобы требования были как контракт между мной и AI агентом.

Этот контракт имел очень конкретную форму:

• нумерованный список требований;

• без двусмысленностей;

• с явными условиями и ограничениями;

• пригодный для:

  • составления плана реализации,

  • покрытия тестами,

  • передачи агенту без риска «додумывания» поведения.
    

В контекст я дополнительно передавал ранее зафиксированные требования, чтобы AI мог выявлять противоречия между новыми и существующими правилами. Именно в таком виде я использовал этот подход на этапе UX :

Когда требования стали формализованными и пронумерованными, появился вполне логичный шаг: ставить задачи для AI-агента по принципу: One task = one rule ID

Обвинение: Требования есть, осталось запустить агента — и он сам всё сделает.

Защита: Звучит логично. Но сразу возникает вопрос: что именно он сделает, какой ценой и сколько токенов сгорит по дороге?

На практике выяснилось, что если просто «скормить требования» агенту, он действительно будет что-то делать, он сам придумает зависимость требований одно от другого, составит план и будет делать что-то свое.

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

• с привязкой к одному Rule ID,

• с указанием архитектурного слоя,

• с ожидаемым покрытием тестами.

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

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

• какие требования уже реализованы;

• какие из них покрыты тестами;

• где есть расхождения между кодом и ожиданиями.

Чтобы он не начал «дописывать» систему поверх неизвестного фундамента.

Т.е. при внедрении AI я провожу аудит кода, и так делаем поэтапно слой за слоем реализации. Так как было понимание, насколько критичен правильный контекст, логично было пойти дальше. Так появился MODULE.md — минимальный, скучный, но крайне полезный документ. Шаблон:

В нём фиксировалось:

• за что отвечает модуль;

• какие у него точки входа;

• какие Rule ID он реализует;

• с какими данными работает;

• что обязательно нужно проверить при изменениях.

Как еще одна точка опоры для AI-агента.

Краткий результат аудита:

• у агента появился чёткий маршрут чтения: GENERAL.md → business/* → MODULE.md → code

• из описанных 19 бизнес правил с требованиями к ним. 1 реализовано полностью с тестами, 6 частично реализованы, 12 - реализация отсутствует.

• появилось 8 MODULE.md, которые впоследствии стали стабильным контекстом для RAG

Дальше я сформировал пул задач по принципу: One task = one rule ID

Для этого использовал промт:

Суть промта для постановки и выполнения задач:

• AI работает как инженер-исполнитель, а не генератор идей: он реализует только то, что описано в правилах и требованиях.

• Все задачи формируются строго на основе источников истины (rules, logic, coverage, MODULE.md), без домыслов и новых поведений.

• Сложность задачи влияет на выбор модели: простые инфраструктурные вещи — дешёвые модели, сложная логика и риски — более мощные.

• Если правило неполное или противоречивое, задача помечается как BLOCKED - (требуется уточнение), если выходит за рамки MVP — как DEFERRED (больше как рекомендация)

• Каждая задача имеет чёткие критерии приёмки, требования к тестам и влияние на данные.

• Завершение задачи обязательно сопровождается:

  • worklog’ом - что сделано и почему (обращался пару раз к нему в спорных моментах - например, когда покрытие кода тестами увеличилось, а количество тестов уменьшилось - агент решил, что новые интеграционные тесты покрывают тесты из юнит, поэтому он их удалил),

  • обновлением архитектурного контекста в MODULE.md,

  • проверкой согласованности кода, тестов и документации.

• Задача не считается выполненной, пока не обновлены код, тесты и документация.

В итоге по использованию моделей при написании кода: ~ 70% задач/кода — Haiku, ~20% — Sonnet, ~1%-остальные и 9% - Hand work (ручная работа)

Да, без ручного вмешательства не обошлось. Так как задач получилось около 80 задач, которые разбил на фазы реализации. Первые фазы прошли почти без моего участия. Но чем сложнее становились задачи, тем чаще агент начинал:

• писать слишком много комментариев → раздувался контекст;

• плодить локальные хелперы → код расползался;

• подгонять тесты под реализацию, а не наоборот.

Отдельной болью стали технические нюансы MVP:

• H2 vs PostgreSQL — у агента ломались тесты из-за несовместимости → пришлось зафиксировать паттерн (GeneratedKeyHolder / keyHolder)

• Нестабильные интеграционные тесты — агент “лечил симптомы” → пришлось создавать базовый H2-класс + транзакционная изоляция

• State-machine — агент ходил по кругу → тут написанный мной E2E вскрыл корень проблемы (переключение state вынести выше)

• даже команды запуска тестов пришлось зафиксировать — агент упорно пытался использовать Linux-утилиты вместо PowerShell

Теперь у меня есть несколько рекомендаций (больше для себя):

• Все повторяющиеся проблемы сразу заносить в правила и промты.

• Проблемы, которые нашли вы, а не агент, покрывать тестами, которые напишите сами, а не агент.

• На последних этапах реализации, покрыть код E2E тестами используя диаграмму переходов и состояний - как обход графа.

• Использовать английский язык в требованиях и промтах, что уменьшает расход токенов.

• Делать ограничение, на количество попыток исправления проблемы агентом.

Обвинение: Опыт и навыки в программировании больше не так важны.

Теперь важен выбор AI — он и архитектуру придумает, и код напишет, и тесты добавит.

Защита: AI развивается очень быстро, какие-то навыки усиливает в реализации ПО, а для других уменьшает значимость. Я лишь могу судить о своих - FullStack QA Lead. Что мне помогало, как

• FullStack:

  • чтение и анализ кода - Если не уметь читать код, вы не понимаете, что именно он сделал.

  • понимание архитектуры приложений - Без чётких границ слоёв агент начинает смешивать ответственность

  • написание автотестов - опыт позволял не только решать спорные моменты, но использовать лучшие решения - экономя время.

• QA :

  • тест-анализ и покрытие тестами - Хороший тест - как способ зафиксировать поведение системы. В рамках агента тесты запускаются гораздо чаще и их ценность от этого только увеличивается.

• Lead:

  • декомпозиция - работ, задач, фаз, требований, слоев и т.д.

  • управление реализацией - распределение задач между мной и различными AI, работа с проблемами, приоритизация задач.

  • контроль агента - Когда вмешаться, а когда дать ему доработать.

  • обучение - системное модернизация промтов и правил - как и с людьми цель, чтобы Агент, мог делать большую часть без контроля.

По сути, AI стал ещё одним (во множестве лиц) членом команды.

Какие еще навыки потребовались:

• prompt engineering - в малой степени, так как сейчас с этим лучше справляется сам AI, я лишь только дорабатываю.

• понимание, как агент читает контекст и что он игнорирует.

• Reasoning Engineering - для сложных многоэтапных задач.

• проектирование агентной архитектуры и памяти (RAG).

Как интересно меняется мир IT, ты уже не знаешь, что тебе потребуется завтра. И даже мои SKILLS можно загнать в набор действий, описаний для заданного контекста. Именно эта идея появилась, когда я впервые прочитал про skills для AI-агента.

Какие skills для агента у меня есть:

• формирование и анализ требований (тут я передаю идею в контексте и с AI пытаемся сформировать все виды требований, определить границы, риски, оценка конкурентов - подход итерационный общение, после каждого получаю документ с описанием идеи, требованиями и списком того что нужно проверить и как)

• тестирование требований (тут два шага - формирования промта под определенные проверки, используя базовый промт и только потом тестирование требований)

• формирование задач по требованиям, составленную в порядке приоретизации и зависимостей.

• аудит - это тоже задачи для агента, но цель ее только оценить и актуализировать информацию для RAG.

• обучение - во время работы с Агентом, я нахожу проблемы, описываю их человеческим языком их решение. выполняя эту команду он обновляет правила разработки, формализованным для себя.

Итоги

Цель моей статьи, не что я сделал и не инструкция "делайте так же", а:

1. показать, что сегодня один человек с опытом и AI может проверять идеи, которые раньше требовали команды;

2. где AI реально ускоряет, и что может помочь вам.

3. поделиться практикой работы с требованиями, тестами и агентом

4. показать, что требуется держать руку на пульсе своих навыков, чтобы пользоваться новыми подходами в разработке и тестировании

В итоге у меня получился не просто MVP, а работающая система взаимодействия с AI:

• требования → тесты → задачи → агент → аудит → обновлённый контекст;

• набор повторяемых подходов, которые я уже использую как skills;

• и проект, который можно развивать дальше — или адаптировать под другие задачи.

👉 Сам проект

Если вы HR и вам интересна идея консолидации рекомендаций по кандидатам — буду рад обсудить.
Если вы работаете с AI-агентами и требованиями — давайте сравним подходы.
Если вам нужен человек, который умеет держать систему в голове и управлять AI как частью команды — тоже пишите мне в телеграмм @a_wert.

Мир IT меняется быстро. И, кажется, сегодня важнее не знать «что будет завтра», а уметь строить системы, которые быстро адаптируются под изменения. Если вам интересно, а что дальше. Подписывайтесь на мой канал.

Спасибо, что дочитали.