Похоже, мы переходим от автоматизации к OPS-программированию

Я занимаюсь интеграцией AI и автоматизации в бизнесе, и за последний год у меня сильно поменялось ощущение от того, куда вообще движется рынок.

Раньше всё было достаточно понятно. Есть процессы, есть люди, есть задачи, и есть инструменты, которые помогают что-то автоматизировать. Ты берёшь Zapier, n8n, какие-то внутренние скрипты, иногда добавляешь AI и решаешь конкретную проблему.

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

Бизнес уже не хочет просто «автоматизировать пару действий».

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

И самое главное чтобы это не превращалось в отдельный сложный IT-проект.

И вот здесь появляется ощущение, что рынок начинает двигаться в сторону того, что я бы назвал OPS-программированием.

Когда ты работаешь уже не с кодом в привычном смысле, и не с no-code сценариями, а с чем-то посередине. С операционной логикой, которая становится программируемой. Которую можно собрать, протестировать, упаковать и использовать как полноценную систему.

И вот на этом фоне я наткнулся на TEXX (тэкс). (https://texx.app)

Сначала я посмотрел на него как на очередной инструмент. У меня таких было уже десятки. Но довольно быстро стало понятно, что он попадает как раз в эту новую логику.

Причём важно, что это не абстрактный стартап «для всего мира». Насколько я понимаю, это продукт, который делают русские разработчики (кто и как раскопать, к сожалению, не получилось) и изначально ориентируют его на российские компании, на локальные инфраструктуры, на те сценарии, где облако либо нежелательно, либо вообще невозможно.

И это сразу задаёт другой уровень задач.

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

А здесь подход изначально другой.

Когда начинаешь разбираться, становится понятно, что TEXX это не просто про «собрать workflow». Это попытка сделать так, чтобы автоматизация в итоге превращалась в самостоятельную исполняемую сущность. В нечто, что можно передать, развернуть и запустить отдельно.

И вот это для меня как для интегратора оказалось ключевым.

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

Ты можешь сделать идеальный сценарий в n8n, но дальше начинаются вопросы. Где он будет жить, как его деплоить, как обеспечить безопасность, как не тащить за собой лишнюю инфраструктуру. И очень часто решение либо становится слишком сложным, либо просто не доходит до продакшена.

В TEXX это ощущается иначе.

Ты собираешь процесс, но у тебя изначально есть понимание, что это не «настройка внутри интерфейса». Это будущий исполняемый объект. И это сильно меняет мышление.

И здесь важно отдельно проговорить одну вещь, которую я сам не сразу до конца осознал. Результат, который ты получаешь на выходе, это не просто «файл с логикой» и не какой-то вспомогательный артефакт. Это полноценная программа, которая может работать в разных режимах в зависимости от задачи.

В самом простом варианте она может запускаться локально как обычное приложение и выполнять нужный процесс. Но при этом тот же самый исполняемый файл может быть запущен как веб-сервер и предоставлять эндпоинты, к которым можно обращаться из других систем. Если нужен интерфейс, он может работать в режиме web-view и отдавать веб-интерфейс, доступный с любого компьютера в сети. А если речь идёт про интеграцию с агентными системами, этот же файл можно поднять в режиме MCP и подключить к любому оркестратору, используя его как инструмент в руках LLM.

И вот в этот момент окончательно становится понятно, что речь идёт уже не про «автоматизацию внутри инструмента», а про полноценный исполняемый слой, который можно использовать как часть инфраструктуры.

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

Здесь это ощущается иначе.

Агент это часть системы. У него есть доступ к плагинам, к инструментам, к данным. Он может выполнять действия, запускать процессы, взаимодействовать с внешними сервисами. При этом, если нужно, к нему можно добавить интерфейс тот же чат, Telegram, любой другой канал. Но это не обязательная форма. Это просто один из способов взаимодействия.

И это важный сдвиг.

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

В реальных задачах это выглядит очень прикладно.

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

В классической логике ты бы начал поднимать отдельную систему, инфраструктуру, возможно, тот же n8n или что-то подобное. Это долго, дорого и не всегда оправдано.

А здесь сценарий выглядит иначе.

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

И этот файл запускается на компьютере сотрудника. Без облака. Без дополнительной инфраструктуры. Внутри закрытого контура.

И в этот момент ты понимаешь, что порог входа сильно снижается.

Потому что для таких задач уже не нужна отдельная команда разработки. С этим может справиться обычный технический специалист внутри компании.

И это, на мой взгляд, очень важный момент.

Потому что как раз такие «маленькие» автоматизации чаще всего и дают максимальный эффект, но именно они реже всего доходят до реализации из-за сложности внедрения.

Отдельно важно, что в TEXX изначально заложена работа с данными с учётом требований безопасности. В том числе через механизмы деперсонализации, когда перед передачей в модель данные очищаются или трансформируются. Это выглядит как небольшая деталь, но в корпоративной среде именно такие детали часто решают, можно ли вообще использовать AI в процессе или нет.

И вот в итоге складывается довольно интересная картина.

С одной стороны, это инструмент, который явно делался под корпоративный рынок. Под интеграции, под внутренние процессы, под инфраструктуры, где важен контроль.

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

И в какой-то момент ты начинаешь ловить себя на мысли, что работаешь уже не с автоматизацией в привычном смысле.

Ты работаешь с операционной логикой как с программой.

Не пишешь код, но создаёшь систему. Не настраиваешь сервис, а собираешь инструмент. Не запускаешь workflow, а разворачиваешь решение.И вот это ощущение, наверное, и есть главный вывод для меня. Рынок постепенно уходит от «инструментов для автоматизации» к «средам для OPS-программирования». И TEXX выглядит как Интересный и 100% перспективный продукт который одним из первых, эту идею пытается реализовать не в теории, а на практике.

Как сказал один мой знакомый, это: "OpenClaw + n8n". Отчасти он прав, но, как мне кажется, Область применения этого продукта гораздо шире и сделано немножко больше для людей. Будем наблюдать за развитием дальше.

PS. Ключ лицензии я получил бесплатно. Было безумно приятно. Я просто написал Telegram-бот поддержки и мне его прислали. Интересный подход))