Ищу двух разработчиков и проектирую с AI
Я ищу двух мидлов уже полтора месяца. Пока не нашёл, а сроки горят. Наш проект признан фокусным. Моя задача — собрать небольшую команду и выпустить MVP мультиагентной системы до конца года.
Но найм идёт медленно — сильных кандидатов мало. Поэтому в моменте я и техлид, и аналитик, и разработчик.
Уже несколько лет моя роль сводилась к валидации результатов. Аналитики делали драфт архитектуры. Дальше командный груминг. Я проверял решение и корректировал при необходимости.
А тут нужно всё самому. Собрать требования, спроектировать архитектуру, проверить её на устойчивость и зафиксировать итоговый вариант.
Очевидно, что проектировать самому руками — долго. Да и без взгляда со стороны можно упустить что-то важное. Поэтому я решил использовать LLM как партнёра. Это мой первый опыт E2E-проектирования с моделью.
Расскажу на вымышленном примере — AI-консьерж элитного ЖК. Агент должен решать вопросы жителей в чате, например: отключение воды, аренда парковки, протечка от соседей.
Важно: функционал системы будет постоянно расширяться новыми кейсами.
Этап 1. Прошу модель сгенерировать все сценарии использования консьержа. Она справляется хорошо, но не отлично. Часть кейсов выходит за рамки домена. Я ставлю задачу отсечь лишнее и собрать кейсы в группы.
Этап 2. Прошу накидать драфт разделения на агентов. То, что выдаёт модель, можно использовать как точку отсчёта — не более. Около 10 итераций правок уходит на первую рабочую версию.
Этап 3. Вижу проблему — много развилок действий агентов даже для простых ситуаций. Понимаю, что без универсальной логики научить их работать с новыми кейсами будет долго и дорого. Модель не видит этого, даже когда прямо прошу найти проблемы.
Этап 4. Нахожу решение сам: агенты должны быть абстрактными и работать по загружаемому сценарию. Модели оставляю сгенерировать JSON-ки — примеры сценариев и сообщений для взаимодействия агентов. Опять получаю сложную структуру — даю задачу упростить.
Этап 5. Моделируем более сложный кейс. Текущее разделение агентов ломается. Я регулярно прошу модель оценить архитектуру — она снова не видит проблем. И только когда явно указываю на них, модель соглашается.
Этап 6. Переходим к внутренней логике агентов. Просто спросить «Спроектируй внутреннюю логику агента» недостаточно. Модель чрезмерно усложняет — приходится снова давать задачу убрать лишнее.
Этап 7. Когда основные кейсы пройдены, доменные модели по моей инициативе группируем в ограниченные контексты. Ещё несколько итераций правок — и финальная спецификация готова.
Вся работа заняла около 40 часов. Мы прошли 305 итераций «вопрос — ответ». Из них 200 содержали мои корректировки, ограничения и требования к упрощению. 11 раз по моей инициативе менялась архитектурная концепция.
Важное наблюдение. Модель часто предлагала избыточные решения и создавала сложные контракты там, где нужны простые. Не находила фундаментальные проблемы без явного указания. Периодически выходила за границы задачи.
Зато она отлично искала противоречия в разных частях описания архитектуры — модель нашла 8 серьёзных нестыковок, которые я сам бы никогда не увидел. Генерировала гипотезы как отправную точку. Терпеливо закрывала рутину.
Без модели я бы не прошёл путь от минимальных требований до архитектурной спецификации за неделю — Затянулось бы на три-четыре недели.
Оставит ли нас AI без работы? Этот кейс доказывает обратное. Модели склонны к оверинжинирингу и не находят фундаментальные проблемы в собственных решениях. Именно поэтому они не способны заменить человека при проектировании сложных систем.
Умение задавать правильные вопросы и отсекать лишнее. Способность предвидеть проблемы и принимать решения на высоком уровне абстракции. Вот что делает человека незаменимым в эпоху AI.
Модель будет делать рутину — это факт. Но я не вижу причин переживать по этому поводу. Так даже лучше и интереснее.
А для вас AI — союзник или конкурент?
Обо мне | Telegram | MAX
5
4
1
1August 20, 2026 193 2
