200 OK по протоколу, но не OK для клиента: автоматизация контроля совместимости API и приложения
Выпустить релиз — часы работы команды. Упасть на старте — 1 секунда. Узнать об этом не из отзывов пользователей — бесценно. Серверные тесты проходят, эндпоинт отвечает 200 OK, но мобильный клиент падает на первом же ответе API.Типичный сценарий: в user.id приходит null, у status появляется новое значение или меняется вложенная структура — и ответ API расходится с клиентскими моделями.
200 OK иногда = кома: почему API «работает», а приложение — нет (и как нам помог ИИ)
Статус 200 OK коварен своей тривиальностью.Бэкенд-тесты «зеленые», API честно отдает данные, а веб-клиент мгновенно подхватывает изменения. Кажется, что всё в порядке, но в это же время мобильные клиенты теряют работоспособность. Приложение не выдает сетевых ошибок, оно просто не может корректно обработать обновленный DTO: клиент ожидает одну структуру данных, а получает другую.Это не баг логики сервера, а технический разрыв между живым API и замороженным артефактом — версией приложения, которая ничего не знает о правках в схеме данных, сделанных через полгода после его релиза.
Из backlog в ТЗ: как мы с помощью AI превращаем клиентские запросы в исполнимые постановки на доработку системы
Мы в «Первой Форме» развиваем BPM-систему на базе low-code для автоматизации бизнес-процессов: документооборота, CRM, HR, PM и Service Desk. Мы работаем с B2B-клиентами, у которых платформа живет внутри реальных процессов компании: согласований, заявок, договоров, кадровых маршрутов, сервисных сценариев и внутренних регламентов. В такой модели у нас постоянно появляется поток запросов на доработку системы.
Agent Loop: почему одного вызова инструментов уже недостаточно для корпоративного AI-агента
В последние два года разговор об AI-агентах почти везде начинается одинаково. Берётся большая языковая модель, к ней подключаются инструменты — поиск, CRM, почта, база знаний, API — и дальше предполагается, что модель сможет сама выбрать нужный инструмент, вызвать его и на этом решить задачу.
Организация как Код: как описывать подразделения как исполнимые сервисные контракты
В большинстве компаний подразделение до сих пор описывается двумя способами. Первый — оргсхема, где есть прямоугольник с названием отдела и стрелками подчинённости. Второй — положение о подразделении, где сказано, что оно «обеспечивает», «контролирует», «сопровождает» и «взаимодействует». Формально этого достаточно: отдел существует, функции перечислены, зона ответственности обозначена.
Как мы превратили BPM-систему в инструмент для ИИ-агентов: реализация MCP в «Первой Форме»
У любой системы управления процессами есть одно неудобное узкое место. Между человеком, который понимает, какой процесс нужен бизнесу, и системой, где этот процесс должен работать, почти всегда стоит посредник — разработчик, интегратор или хотя бы продвинутый администратор. Владелец процесса знает, что ему нужна категория для согласования отпусков с определёнными полями и правами. Но чтобы это появилось в системе, он пишет ТЗ, ставит задачу, ждёт очереди и получает результат через несколько дней.
Как поддерживать корпоративную карту в рабочем состоянии, чтобы AI не начинал ошибаться
В прошлой статье я рассказывал, как мы в «Первой Форме» пришли к навигации по корпоративным данным и почему одной языковой модели недостаточно, чтобы получать полезные ответы внутри компании. Тогда речь шла о самой идее картографирования данных — о слое, который связывает разрозненные системы, знает смысл терминов и помогает находить путь от вопроса к проверяемому ответу.Но довольно быстро выяснилось, что построить карту один раз недостаточно.
