Опишите её в двух-трёх предложениях. Я отвечу, что проверить первым и нужен ли здесь ИИ.
Восемь лет между продуктом и кодом научили меня простому: ИИ приносит пользу, когда один контур держит задачу, экономику, внедрение и результат.
Я отвечаю за ИИ-систему целиком, потому что на стыках теряется больше ценности, чем внутри самой модели.
Я много раз видел один и тот же сюжет. Команда показывает пилот, который уверенно отвечает на вопросы, извлекает данные или вызывает нужный инструмент. На демонстрации всё выглядит убедительно. Через месяц сотрудники продолжают работать по-старому, метрика не изменилась, а пилот живёт отдельной вкладкой в браузере.
Технически проект состоялся. Для бизнеса ничего не произошло.
Так появилась моя рабочая формула. Задача, экономика, архитектура, код и внедрение должны оставаться в одном контуре ответственности. Человек, который услышал исходную проблему, доходит до реальных данных, интеграции и момента, когда можно честно измерить результат.
Лучший первый запрос звучит довольно буднично. «Мы каждую неделю тратим два дня на проверку документов». «Рекрутеры не успевают разбирать отклики». «Пилот работает, но сотрудники им не пользуются».
Этого достаточно для начала.
За двадцать минут мы проверим потерю, данные и экономику. Дальше выберем готовый сервис, проектирование своей системы или остановимся без разработки. Если проект имеет смысл, я отвечу за путь от задачи до измеримого результата.
Последние восемь лет я работаю там, где продукт встречается с разработкой. Начинал с цифровых продуктов, писал на Python и TypeScript, собирал интерфейсы, работал с ML и RAG, а позже руководил направлением ИИ в Innovative People.
Названия ролей менялись. Наблюдение оставалось прежним. Самые дорогие ошибки редко происходят внутри одной специальности.
Бизнес говорит, что хочет ускорить процесс. Аналитик описывает набор функций. Архитектор выбирает красивый стек. Разработчик делает ровно то, что написано. В конце появляется система, которая соответствует техническому заданию и почти не влияет на исходную работу.
Каждый участник выполнил свою часть. Общий результат потерял владельца.
Мне всегда было тесно в одном участке этой цепочки. Когда я понимал бизнес-задачу, хотелось проверить, можно ли измерить потерю. Когда видел архитектуру, хотелось открыть реальные данные и убедиться, что она выдержит их грязь. Когда писал код, хотелось дойти до людей, которые будут пользоваться им во вторник утром, без команды проекта за спиной.
Со временем это перестало быть набором навыков. Это стало профессией.
Цифры не заменяют кейсы, но показывают, где этот подход уже выдержал реальную работу.
Работа начинается с простых вопросов. Где сейчас теряются часы или деньги? Кто отвечает за процесс? Какие данные уже есть? Как выглядит хороший результат в цифрах?
После этого можно обсуждать технологию.
В моей практике первый этап занимает около двадцати минут. Этого достаточно, чтобы увидеть главные развилки. Иногда нужен готовый сервис. Иногда имеет смысл спроектировать свою систему. Бывает, что данных недостаточно или автоматизация обойдётся дороже ручной работы. Тогда разговор на этом заканчивается.
Для подходящей задачи я фиксирую исходную метрику, считаю экономику, проектирую архитектуру и проверяю решение на реальных данных. Затем начинается внедрение. Модель может показывать высокую точность на тесте и всё равно быть бесполезной, если ответ приходит слишком дорого, сотруднику приходится перепроверять каждый шаг или интеграция ломает привычный процесс.
Экономика влияет на архитектуру буквально. Допустимая стоимость операции определяет модель и глубину рассуждения. Цена ошибки задаёт объём проверок и место человека в контуре. Частота задачи подсказывает формат решения. Это может быть автономный агент, обычный сценарий автоматизации или всего одна хорошо сделанная кнопка.
Один из моих проектов называется «Коготь». Изначально человек тратил часы на ручной поиск подходящих заказов, затем сам проходил одинаковую последовательность действий. Мы разложили эту работу на этапы и передали агенту полный цикл поиска, отбора и выполнения.
Ценность проекта стала видна без специальной презентации. У человека исчез кусок повседневной рутины, а система продолжила работать сама. Этот критерий мне близок. Хороший продукт постепенно становится незаметным. Пользователь думает о своей цели и почти не замечает автоматизацию.
«Коготь» также показал, насколько опасно начинать разговор с модели. У задачи были источники данных, ограничения площадок, критерии выбора, контроль ошибок и понятная стоимость результата. Модель занимала важное место. Вся система была намного больше одного вызова API.
Следующий проект, ORCH, появился из другой проблемы. Несколько ИИ-агентов умеют быстро выполнять работу, но без организации начинают конфликтовать, менять одни файлы, терять контекст и дублировать действия. Я собрал систему, в которой они берут задачи параллельно, работают изолированно и передают готовый результат на проверку.
ORCH уже используют больше ста человек. Для меня эта цифра показывает, что архитектура пережила контакт с чужими задачами, привычками и ожиданиями. Пользователю нужен проверяемый результат и понятная точка контроля. Внутренняя диспетчеризация агентов может оставаться за кадром.
Похожий принцип сработал в найме. В Innovative People рекрутеры тратили до 70% времени на первичный скрининг откликов. Мы встроили в процесс трёх агентов, которые взяли на себя скрининг и оценку. Люди сохранили решения, где нужны контекст и ответственность, а рутинная часть перестала съедать большую часть дня.
Эти проекты разные по устройству и аудитории. Их объединяет один критерий. После запуска меняется сама работа. Человек делает меньше механических шагов, быстрее доходит до решения и сохраняет контроль над важными точками.
От специалиста по ИИ часто ждут модель, агента или хотя бы эффектную демонстрацию. Я могу закончить первую встречу рекомендацией ничего не разрабатывать.
Так бывает, когда у процесса нет владельца, исходную метрику никто не измерял, данные существуют только в рассказах сотрудников или возможный эффект меньше стоимости внедрения. Код в такой ситуации создаёт новый расход и новую систему, которую придётся обслуживать.
Я считаю честный отказ частью работы. Клиент сохраняет бюджет. Я сохраняю время и репутацию. Если задача созреет позже, к ней можно вернуться с данными и понятным критерием результата.
Это защищает и от другой крайности. Удачный прототип легко принять за готовый продукт. В продакшене появятся права доступа, нестандартные входные данные, стоимость запросов, задержки, обучение команды и десятки мелких решений. Ответственность начинается именно там, где заканчивается демо.
Моя роль сохраняет контекст на всём пути проекта. Я слушаю человека, который владеет процессом, считаю эффект, участвую в архитектурных решениях, пишу код, интегрирую систему и смотрю на метрику после запуска.
Рядом могут работать специалисты клиента, дизайнеры, аналитики и разработчики. Единый контур нужен, чтобы решение не рассыпалось на аккуратно выполненные части с потерянным общим смыслом.
На fefelov.me я разбираю каждый кейс до последнего факта. Что стало быстрее? Какая ручная работа исчезла? Сколько стоит одна операция? Где человек сохранил контроль? Именно эти ответы отличают работающую систему от убедительной демонстрации.
Продуктовое мышление помогает выбрать правильную задачу. Инженерная практика помогает довести её до работающей системы. Ответственность связывает эти две части.