Разработчик создал AI-инструмент, который превращает беспорядочные требования в архитектуру приложения
Инженер Фелипе Родригес представил платформу Noesor, которая анализирует размытые текстовые требования и генерирует структуру модулей, модель данных и даже предупреждает о скрытых рисках — всё до написания первой строчки кода.
Проблема не в том, что разработчики плохо проектируют системы, а в том, что требования, которые им приходят, часто не содержат достаточно информации для проектирования вообще.
Сценарий, знакомый каждому
Представьте: вам пишет менеджер по продукту и скидывает два абзаца текста в мессенджере. Что-то вроде: «Нужен простой Uber для доставки лекарств, дай оценку и архитектуру к завтрашнему дню». Всё. Два абзаца — и вы должны назвать сроки, выбрать стек, спроектировать базу данных и не пропустить техническую ловушку, которая рванёт через три спринта.
Инженер Фелипе Родригес утверждает, что устал от этого «этапа импровизации» и решил автоматизировать процесс. Результат — платформа Noesor, которая берёт на себя первичный разбор требований и превращает их в структурированный технический фундамент.
Что умеет Noesor
Платформа позиционируется как инструмент в духе Design-First — подхода, при котором архитектура проектируется до написания кода, а не вырастает стихийно в процессе. Концепт не новый, но автоматизация на этом этапе — действительно полезная идея.
Что Noesor извлекает из текста требований:
- Модули и компоненты. Предлагает техническую структуру системы — микросервисы, монолит или serverless-границы.
- Модель данных. Определяет ключевые бизнес-сущности (например, User, Transaction, Booking) и описывает связи между ними.
- API-контракты. Формирует черновик интерфейсов между бэкендом и фронтендом.
- Управление рисками. Пытается найти противоречия, пробелы и скрытые проблемы в исходном требовании. Пример из описания: требование описывает подписочную модель, но не определяет логику вебхуков при неудачном списании с карты.
Последний пункт — самый интересный с инженерной точки зрения. Именно невысказанные предположения чаще всего приводят к проблемам на продакшене.
Как попробовать
Родригес явно понимает, что разработчики не любят регистрацию ради любопытства. Поэтому вход устроен с минимальным трением:
- Без регистрации. На главной странице можно вставить текст требования или загрузить PDF — результат появится примерно за 30 секунд.
- С бесплатным аккаунтом. Позволяет получить расширенный анализ.
- Премиум. Полный набор инструментов для серьёзного планирования.
Нисколько неудивительно, что инструмент заточен под конверсию: дать попробовать бесплатно, а потом предложить заплатить за глубину. Стандартная модель, но в данном случае она оправдана — если AI действительно находит проблемы в требованиях, это экономит часы работы.
Скептицизм обязателен
Здесь важно остановиться и не поддаваться энтузиазму. Это пост от основателя продукта на DEV Community — платформе, где разработчики делятся проектами и ищут обратную связь. Никакого независимого тестирования, сравнения с аналогами или деталей о том, какая языковая модель работает под капотом.
Неясно несколько вещей:
- Насколько хорошо Noesor справляется с действительно нестандартными доменами — fintech, healthcare, gaming? Или он заточен под типовые CRUD-приложения?
- Как инструмент интерпретирует противоречивые требования? Помечает ли он свои выводы как гипотезы или выдаёт за готовое решение?
- Какова точность? Есть ли исследования или хотя бы примеры «до и после»?
Без ответов на эти вопросы Noesor остаётся скорее прототипом с обещающей идеей, чем готовым инструментом для продакшена.
Почему идея всё равно важная
Независимо от качества конкретного продукта, направление верное. Индустрия давно мучается с фазой «от требований к архитектуре». Архитекторы тратят дни на воркшопы, Event Storming, маппинг доменов — и всё это на основе документов, которые часто противоречат сами себе.
AI-инструмент, который хотя бы структурирует хаос, выделяет сущности и указывает на пробелы, может стать аналогом линтера для архитектуры. Не замена архитектору, а первый черновик, который нужно проверить. Собственно, так и работает любой полезный AI — он не принимает решения, а ускоряет цикл.
Что дальше
Родригес прямо просит сообщество «жёсткую инженерную обратную связь» — в частности, интересно, находит ли инструмент скрытые риски, насколько точна генерация сущностей данных и какие форматы вывода (например, код Mermaid для диаграмм) были бы полезны.
Для разработчиков, которые устали гадать по двум абзацам требований, Noesor может стать полезным экспериментом. Но принимать результаты его работы на веру без проверки — плохая инженерная практика. Как, впрочем, и принимать на веру любые требования.