INITE | AI-first экосистема

Прежде чем что-то автоматизировать в компании по аренде оборудования, мы неделю считали, и эти замеры изменили проект. Среднее время от брони до отгрузки оказалось самым бесполезным из собранных чисел: среднее прятало хвост, а в хвосте жили отказы. Решение о составе работ приняли по трём другим счётчикам: сколько заявок пришло вне рабочих часов, на сколько не ответили вообще и как часто стоящая на площадке машина числилась недоступной. Последовавшая перестройка заняла 3 недели и увела путь от брони до отгрузки с 4 часов до 3 минут. https://inite.ai/ru/blog/rental-case-the-week-before

Обработка заказов в аренде оборудования медленная потому, что работы там мало, а ожидания много. Заявка стоит между тем, как координатор открыл таблицу, кто-то подтвердил, что машина действительно вернулась, договор собрали, подпись выпросили, а водителю дозвонились. Каждый шаг занимает минуты, промежутки между ними занимают часы. Автоматизация шагов экономит минуты, а закрытие передач между людьми и есть то, что увело одну прокатную компанию с четырёх часов до трёх минут. Основную часть починки сделали детерминированные правила, а не языковая модель: проверка доступности обязана отвечать одинаково каждый раз. https://inite.ai/ru/blog/order-processing-equipment-rental

Оплата внутри чата ChatGPT прожила около пяти месяцев. Она запустилась 29 сентября 2025 года с Etsy, добавила горстку брендов на Shopify и была свёрнута 4 марта 2026 года, а 24 марта OpenAI это подтвердил. Убили её три совершенно обычные операционные проблемы: налог с продаж, борьба с мошенничеством и точность остатков в реальном времени по множеству продавцов. Уцелело то, что важно владельцу магазина. Agentic Commerce Protocol по-прежнему опубликован под Apache 2.0, ассистенты по-прежнему приводят покупателей к продавцам, а покупка теперь завершается на вашем собственном сайте. Работа вернулась туда, где и была: к вашим карточкам товара, точности остатков и вашей оплате. https://inite.ai/ru/blog/agentic-commerce-after-instant-checkout

https://inite.ai/ru/blog/safe-ai-framework-human-in-loop

https://inite.ai/ru/blog/inite-estate-real-estate-vertical

Евразия, которая всегда воевала с Остазией Кто бы мог подумать, что всего через несколько десятилетий после распада последней большой тоталитарной конструкции значительная часть Евразии снова начнет жить внутри мира, настолько похожего на роман Оруэлла, что сравнение с “1984” постепенно перестанет быть литературной метафорой и превратится почти в бытовое описание окружающей действительности. Самое поразительное здесь даже не в том, что государство вновь научилось запрещать слова, переписывать биографии, объявлять вчерашних союзников врагами и превращать войну в бесконечный фон повседневной жизни. Все это история уже видела множество раз, и никакого особого технологического чуда для воспроизводства подобных режимов не требуется. Гораздо интереснее то, насколько точно современность восстановила саму архитектуру оруэлловского мира, одновременно сделав ее сложнее, устойчивее и, что особенно важно, добровольнее. В романе существовало Министерство правды, которое непрерывно редактировало прошлое, уничтожая документы, исправляя газетные архивы и приводя историческую память в соответствие с текущей политической линией. Сегодня для этого уже не обязательно сжигать бумагу или физически перепечатывать старые выпуски. Достаточно изменить поисковую выдачу, удалить публикацию, ограничить доступ к архиву, пометить нежелательную интерпретацию как экстремистскую, а затем заполнить информационное пространство тысячами почти одинаковых пересказов новой версии событий. Прошлое больше не нужно уничтожать, его можно просто утопить в управляемом настоящем. При этом система не требует, чтобы человек действительно поверил в новую версию. Ей достаточно, чтобы он перестал доверять собственной памяти. В этом смысле современная пропаганда работает тоньше, чем пропаганда XX века. Ее задача заключается не столько в том, чтобы убедить население в существовании единственной истины, сколько в том, чтобы уничтожить саму возможность различать истину и ложь. Когда каждое событие получает десятки противоречащих друг другу объяснений, когда любое свидетельство можно объявить постановкой, любое изображение подделкой, любого очевидца агентом, а любую последовательность фактов совпадением, человек постепенно приходит не к официальной позиции, а к интеллектуальной капитуляции. Он больше не говорит: “Я верю государству”. Он говорит: “Все равно никто ничего не знает”. Именно в этот момент власть достигает значительно большего результата, чем обычная цензура, поскольку человек, лишенный доверия к собственной способности понимать происходящее, уже не нуждается в постоянном надзирателе. Он самостоятельно отказывается от попытки собрать реальность в непротиворечивую картину и принимает ту версию мира, которая позволяет ему сохранить относительный психологический комфорт. Оруэлловское двоемыслие часто понимают слишком примитивно, как способность одновременно верить в два взаимоисключающих утверждения. Однако его настоящая сила состоит в другом. Двоемыслие позволяет человеку видеть противоречие, осознавать его и одновременно вести себя так, будто никакого противоречия не существует. Он может помнить, что вчера происходило одно, сегодня слышать официальное утверждение о противоположном и не испытывать потребности привести эти две версии в соответствие, потому что сама способность удерживать непрерывность причин и следствий становится политически опасной. Если враг изменился, значит, враг не менялся никогда. Если цели войны изменились, значит, именно такими они были с самого начала. Если вчерашнее обещание не выполнено, значит, этого обещания никто не давал. Если экономическая реальность расходится с телевизионной, значит, проблема находится не в телевизоре, а в недостаточной лояльности наблюдателя. Так формируется среда, в которой язык перестает быть инструментом описания реальности и становится системой авторизации. Слова нужны уже не для того, чтобы передавать смысл, а для того, чтобы определять принадлежность говорящего. Правильная формулировка подтверждает, что человек свой; неправильная, даже фактически точная, обнаруживает в нем потенциального врага.

Точно так же субъектная операционная система сегодня может восприниматься как SaaS с агентами, хотя это описание скрывает самую важную часть изменения. SaaS с агентами по-прежнему предполагает, что продукт является центром, а агент служит его дополнительным интерфейсом. Субъектная операционная система предполагает обратное: субъект является центром, а продукты становятся интерфейсами, памятью и инструментами, через которые он действует. Пока это различие не стало очевидным, архитектура INITE действительно может казаться набором слишком сложных решений для задач, которые можно собрать в n8n или реализовать обычным backend. После того как различие становится очевидным, прежняя архитектура начинает выглядеть недостаточной. Следующая единица программного обеспечения В эпоху облаков основной единицей был сервис. В эпоху SaaS основной единицей стал продукт. В эпоху AI-native систем основной единицей становится субъект. У субъекта есть идентичность, память, набор навыков, цели, ограничения, права, история действий и способность собирать временные процессы под конкретную задачу. Он может использовать несколько продуктов, работать в нескольких доменах, взаимодействовать с другими субъектами и сохранять непрерывность между сессиями, устройствами и бизнес-контекстами. Поэтому INITE движется не к созданию еще одного семейства AI-сервисов, а к архитектуре, в которой вертикальные продукты, MCP-интерфейсы, skills, durable workflows, специализированная память и business interfaces собираются в единую среду существования цифровых субъектов. Сегодня эта идея может быть непонятна даже сильным разработчикам, поскольку она требует отказаться от представления, что код, сервис или приложение являются центром вычислительной системы. Однако именно в этом и заключается смысл происходящего перехода. Те, кто продолжит совершенствовать реализацию внутри старой модели, еще некоторое время будут оставаться востребованными, поскольку старый мир не исчезает мгновенно. Но основная ценность постепенно перейдет к тем, кто способен проектировать новый. И когда это станет очевидно большинству, перестраиваться будет уже значительно дороже.

Следовательно, ценность инженера постепенно перемещается на уровни, где требуется не механическая реализация, а формирование пространства допустимого поведения. Становятся важнее архитектурные инварианты: что субъект имеет право делать, какие данные он способен видеть, как проверяется результат его работы, где заканчивается его автономность, как сохраняется история решений, каким образом обеспечивается воспроизводимость и как система восстанавливается после ошибки. Становятся важнее evals, потому что в вероятностной системе невозможно ограничиться обычными unit-тестами. Становится важнее observability, потому что необходимо понимать не только технический маршрут запроса, но и логику принятого решения. Становится важнее проектирование памяти, потому что качество субъекта определяется не размером модели, а тем, что он способен вспомнить, связать и применить в нужный момент. Наконец, становится важнее понимание бизнеса, поскольку агент, способный писать код, резко сокращает расстояние между решением и реализацией. Инженер, который не понимает, зачем существует система и какое изменение в реальности она должна произвести, теряет преимущество перед человеком, умеющим формализовать цель, ограничения и критерии качества. Кому действительно угрожает agentic coding Обычно угрозу автоматизации обсуждают применительно к слабым специалистам, которые выполняют рутинные задачи и не способны работать за пределами шаблонов. Это справедливо, но неполно. Agentic coding угрожает также сильным специалистам, если их сила полностью привязана к уровню, который перестает быть дефицитным. Можно превосходно знать определенный фреймворк, глубоко понимать внутреннее устройство Kubernetes, виртуозно оптимизировать запросы или строить сложные CI/CD-процессы, однако если основная часть этих действий становится доступна агенту, ценность экспертизы определяется уже не количеством известных деталей, а способностью применять их внутри более широкой архитектурной картины. Проблема не в том, что агент завтра станет лучше каждого инженера во всех областях. Проблема в том, что он уже становится достаточно хорош, чтобы радикально изменить экономику разработки. Если раньше для создания продукта требовалась команда специалистов, каждый из которых отвечал за отдельный слой, то теперь один сильный архитектор, работающий с агентами, способен закрывать значительную часть полного цикла: от исследования и проектирования до реализации, тестирования, инфраструктуры и документации. При этом агенты продолжают улучшаться быстрее, чем большинство специалистов перестраивает собственную модель работы. Что останется человеку Человеку останется не меньше работы, но она станет другой. Потребуются инженеры, которые умеют проектировать среды, а не только компоненты. Потребуются архитекторы, способные определять границы автономности. Потребуются специалисты, которые умеют строить системы оценки, контроля и восстановления. Потребуются люди, способные соединять техническую архитектуру, бизнес-логику, экономику, право, безопасность и пользовательский контекст. Главной компетенцией станет не способность написать больше кода, а способность создать пространство, в котором код может безопасно и осмысленно порождаться без постоянного человеческого участия. Это уже не классическая разработка программного обеспечения, где машина исполняет замысел человека. Это проектирование вычислительных субъектов, которые получают цели, память, навыки и возможность действовать, оставаясь внутри заданных ограничений. Почему непонимание является ожидаемой реакцией Когда новая парадигма только появляется, она почти всегда воспринимается через язык предыдущей, поскольку другого понятийного аппарата у аудитории пока нет. Облако сначала воспринималось как чужой сервер. Микросервисы воспринимались как множество маленьких backend-приложений. Контейнеры сравнивались с облегченными виртуальными машинами. Смартфон долго считался телефоном с дополнительными функциями.

Skill важен не потому, что является хорошо документированной функцией, а потому, что становится единицей поведения, которую субъект способен обнаружить, понять, скомбинировать с другими навыками и применить внутри нового контекста. Temporal в этой конструкции является не просто workflow engine, а durable runtime для процессов, которые могут продолжаться часами, днями и месяцами, переживать сбои, ожидать внешних событий, запрашивать решения у человека и сохранять причинную непрерывность исполнения. SurrealDB или другая мультимодельная база данных интересна не как способ сократить количество инфраструктурных компонентов, а как возможный фундамент памяти, где документы, связи, события, права доступа, идентичности и семантические представления существуют не в отдельных технологических мирах, а внутри связного контекста. Все эти элементы становятся понятны только тогда, когда в центре схемы находится субъект. Пока центром остается приложение, они неизбежно выглядят как избыточный набор модных технологий. От SaaS к специализированной памяти Классический SaaS стремился забрать на сервер практически все: данные, бизнес-логику, обработку, автоматизацию, права доступа и пользовательский опыт. Клиентская часть оставалась интерфейсом, а backend фактически являлся самим продуктом. AI-native архитектура постепенно разворачивает эту модель. По мере того как клиент получает собственную модель, локальный контекст, инструменты, кеш, reasoning и способность выполнять код, значительная часть обработки может происходить рядом с пользователем или внутри принадлежащего ему вычислительного контура. Сервер при этом не исчезает, но его роль меняется: он становится специализированной памятью, пространством синхронизации, управления идентичностями и полномочиями, экономическим контуром и слоем представления общих данных. Именно поэтому вертикальные продукты INITE мы рассматриваем не как полностью независимые SaaS-системы, каждая из которых повторяет собственные auth, billing, automation, knowledge base и AI-слой, а как различные business interfaces к общей субъектной среде. INITE Estate показывает один срез памяти и набор действий, связанных с недвижимостью. INITE Health работает с другим типом контекста, ограничений и полномочий. INITE Education формирует образовательные траектории и навыки. INITE Brain организует память и индексирование. Auth и Billing обеспечивают общие контуры идентичности, доступа и экономики. На поверхности это разные продукты, однако под ними существует единая логика: субъект сохраняет непрерывность, переносит знания и навыки между доменами, взаимодействует с сервисами через стандартизированные интерфейсы и использует вертикальные приложения как специализированные способы видеть и изменять состояние мира. Почему low-code и no-code не исчезают, но перестают быть центром Переход к agentic coding не означает, что n8n, Dify и подобные платформы становятся бесполезными. Они продолжают решать важные задачи интеграции, прототипирования, соединения legacy-систем и быстрого построения детерминированных процессов. Однако они больше не должны быть местом, где живет интеллект системы. Когда reasoning заключен внутрь визуального графа, агент фактически превращается в один из блоков workflow, хотя логичнее было бы сделать обратное: workflow должен становиться временным инструментом агента, который собирается, исполняется и изменяется в зависимости от контекста. Low-code в этой модели перемещается на уровень инфраструктурного клея. Он помогает соединять системы, но не определяет их поведение. Поведение рождается на уровне субъекта, его целей, памяти, навыков, доступных инструментов и ограничений. Это принципиальное различие, которое невозможно увидеть, если обсуждение продолжает вращаться вокруг выбора платформы автоматизации. Новая инженерная иерархия В старой модели разработчик превращал требования в код. В новой модели код все чаще превращается в промежуточный артефакт, который агент способен создать, проверить и заменить самостоятельно.

Сильные разработчики тоже могут не заметить смену эпохи Недавно я провел вебинар об архитектуре INITE, где рассказывал не столько о конкретном наборе технологий, сколько о более фундаментальном переходе: от вертикальных AI-продуктов, workflow-конструкторов и привычного SaaS к среде, в которой основной вычислительной единицей становится не сервис, экран или бизнес-процесс, а цифровой субъект, обладающий памятью, набором навыков, полномочиями и собственным контуром исполнения. В аудитории были сильные разработчики, люди с серьезным инженерным опытом, которые умеют проектировать системы, писать качественный код и разбираться в сложных стеках, однако по реакции было заметно, что значительная часть слушателей не поняла, о чем именно идет речь. Они услышали знакомые названия, MCP, Temporal, SurrealDB, Dify, n8n, агенты, локальный processing, но попытались разложить их по привычным архитектурным ящикам: здесь API, здесь база данных, здесь orchestration, здесь frontend, здесь очередной слой автоматизации. Проблема заключалась в том, что доклад был не про новые инструменты внутри старой модели. Он был про то, что сама модель перестает быть центральной. Когда хороший код больше не является достаточным преимуществом Последние несколько десятилетий разработка программного обеспечения развивалась вокруг относительно устойчивого набора абстракций. Существовал пользователь, который взаимодействовал с интерфейсом, существовал backend, который реализовывал заранее определенную бизнес-логику, существовала база данных, в которой сохранялось состояние, а между компонентами проходили формализованные вызовы через API, очереди и события. Системы усложнялись, монолиты сменялись микросервисами, инфраструктура переезжала в облако, появились Kubernetes, serverless, event-driven архитектуры и low-code-платформы, однако базовый принцип оставался неизменным: поведение системы заранее проектировал человек, после чего машина детерминированно исполняла написанную им логику. Даже современные workflow-платформы, несмотря на визуальную гибкость и большое количество интеграций, в сущности остаются развитием той же парадигмы. Человек рисует граф, определяет ветвления, соединяет блоки, описывает обработку ошибок и решает, что должно произойти на каждом этапе. Машина по-прежнему не формирует способ выполнения задачи, а лишь проходит по заранее подготовленному маршруту. Agentic coding меняет не скорость создания таких маршрутов, а сам принцип их существования. Когда агент способен самостоятельно декомпозировать задачу, изучить доступные инструменты, выбрать последовательность действий, написать недостающий код, проверить результат и изменить план на основании промежуточного состояния, ценность заранее зафиксированного workflow начинает стремительно снижаться. Процесс больше не обязательно существует до момента исполнения. Он может собираться динамически как временная конструкция, необходимая для достижения конкретной цели. В такой среде умение быстро и аккуратно реализовывать заранее сформулированную функцию остается полезным, однако перестает быть главным конкурентным преимуществом, потому что значительная часть этого труда становится доступна моделям. Почему сильные разработчики могут не увидеть переход Инженерная компетентность почти всегда формируется внутри некоторой системы координат, причем чем успешнее человек работал в этой системе, тем труднее ему заметить, что меняются не отдельные инструменты, а сами основания профессии. Сильный backend-разработчик видит новый способ построения backend. Сильный DevOps-инженер видит новый способ автоматизировать инфраструктуру. Архитектор распределенных систем пытается представить агентов как очередной тип сервиса, а MCP воспринимает как еще один API-протокол, который можно сравнить с REST, GraphQL или gRPC. Каждая из этих интерпретаций технически допустима, но концептуально недостаточна. MCP важен не потому, что предлагает более удобный формат интеграции, а потому, что превращает возможности системы в пространство действий, доступное машине.

Вторая роль, это platform engineer, который создает внутреннюю платформу, стандартные маршруты доставки, runtime-контракты, шаблоны сервисов, policy as code и self-service-инструменты. Его задача состоит не в том, чтобы вручную обслуживать команды, а в том, чтобы устранить необходимость ручного обслуживания. Третья роль, это SRE или production engineer, который занимается реальной эксплуатационной сложностью: надежностью, capacity planning, производительностью, деградацией, восстановлением, инцидентами, сетями, хранилищами и поведением распределенных систем в нештатных режимах. Между этими ролями почти не остается места для специалиста, основная компетенция которого заключается в переносе конфигурации из одного файла в другой. Платформа вместо отдела DevOps Зрелая организация не должна создавать очередь заявок в инфраструктурную команду. Она должна создавать платформу, внутри которой большинство правильных решений становится стандартным поведением системы. Разработчик не должен просить кого-то создать ему поддомен, секрет, pipeline, preview environment или базовый набор метрик. Он должен описать намерение, после чего платформа автоматически применит стандартные политики, проверит ограничения, создаст ресурсы и обеспечит наблюдаемость. Именно в этом направлении движется AI-native-разработка. Инфраструктура превращается в API, правила эксплуатации становятся машиночитаемыми, архитектурные ограничения оформляются как исполняемые политики, а значительная часть production engineering переносится в reusable skills и agentic workflows. В такой системе агент может выполнить почти всю операционную работу, но только при условии, что архитекторы и инженеры заранее определили допустимые состояния, границы полномочий и критерии корректности. Поэтому будущее принадлежит не специалистам, которые умеют работать с большим количеством инструментов, а инженерам, которые способны превратить свои знания о системе в формальные ограничения и автоматизированные механизмы контроля. Главный навык ближайших лет Раньше инженер ценился за способность произвести артефакт: написать код, собрать pipeline, развернуть кластер, настроить мониторинг или подготовить конфигурацию. Теперь производство артефактов постепенно становится дешевой частью процесса. Главным навыком становится способность определить, каким должен быть правильный результат, какие свойства необходимо проверить, где проходит граница допустимого и каким образом система сможет автоматически отличить корректное изменение от опасного. Это принципиально другой уровень работы. Нужно не писать очередной YAML, а проектировать среду, в которой неправильный YAML не попадет в production. Нужно не настраивать очередной deployment, а формализовать условия, при которых deployment считается безопасным. Нужно не вручную следить за сервисом, а строить систему, которая обнаруживает отклонения, объясняет причины и запускает предсказуемый сценарий восстановления. Именно поэтому DevOps в его привычном виде заканчивается. Ops возвращается туда, где он должен был находиться изначально, внутрь инженерной ответственности за работающую систему. Сильные разработчики будут осваивать эксплуатацию, сильные системные инженеры будут писать все больше кода, platform-команды будут превращать накопленную экспертизу в продукты для внутренних пользователей, а агенты заберут почти всю работу, ценность которой состояла исключительно в знании синтаксиса и последовательности ручных действий. Останется то, что автоматизируется значительно сложнее: архитектурное мышление, понимание причинно-следственных связей, ответственность за компромиссы и способность построить систему, которая не просто запускается, а сохраняет корректность в реальном мире.

В первом случае человек расширяет область ответственности, во втором ему часто приходится менять сам способ мышления. Разумеется, это не относится к сильным системным инженерам, которые понимают операционные системы, сети, storage, distributed systems и при этом способны писать качественный код. Такие специалисты останутся крайне ценными, однако их ценность определяется не знанием Kubernetes или Terraform, а глубиной понимания вычислительных систем. Agentic coding уничтожает инфраструктурное ремесло Основная часть повседневной DevOps-работы представляет собой преобразование намерения в конфигурацию. Нужно запустить сервис, агент пишет deployment. Нужно настроить HTTPS, агент создает ingress и certificate policy. Нужно добавить environment, агент обновляет pipeline. Нужно развернуть preview-стенд, агент собирает workflow. Нужно подключить метрики, агент добавляет instrumentation, dashboards и alerts. Человек еще недавно тратил на такую работу часы или дни не потому, что она требовала сложного инженерного мышления, а потому, что необходимо было помнить синтаксис, особенности инструментов, совместимость версий и расположение параметров. Именно подобные задачи автоматизируются первыми, поскольку агент хорошо работает там, где результат можно выразить в виде структурированного артефакта и проверить формальными средствами. Однако автоматизация создания конфигурации не решает главную проблему. Агент может написать deployment policy, но не знает, какой уровень риска допустим для бизнеса. Он может добавить retry, но не понимает, станет ли операция идемпотентной. Он может настроить autoscaling, но не определит самостоятельно, какая метрика отражает реальную нагрузку. Он может сформировать архитектурный тест, но только после того, как человек формализовал архитектурное правило. Поэтому ценность перемещается от производства инфраструктурных артефактов к проектированию ограничений, гейтов и доказательств. Новая инженерная единица отвечает не за пайплайн, а за безопасное изменение В старой модели команда отдельно писала код, отдельно тестировала, отдельно собирала и отдельно эксплуатировала. В новой модели основной единицей становится изменение, которое должно пройти через систему автоматических проверок и доказать, что оно допустимо. Такой pipeline должен проверять не только форматирование, тесты и наличие уязвимостей, но и архитектурные зависимости, совместимость контрактов, миграции данных, performance-бюджеты, влияние на стоимость, корректность rollback, соответствие SLO, правила доступа и поведение системы при частичных отказах. Именно здесь требуется понимание конкретного стека. Человек, глубоко знающий NestJS, понимает, какие зависимости допустимы между модулями, где должна проходить транзакционная граница, как устроен lifecycle приложения и какие ошибки возникают при неправильной работе с dependency injection. Человек, понимающий Temporal, знает, что нельзя смешивать детерминированную workflow-логику с внешними эффектами, что версия workflow является частью контракта и что retry policy нельзя выбирать формально. Человек, работающий с SurrealDB, PostgreSQL, Kafka или NATS, должен понимать не только способ подключения, но и семантику данных, транзакций, доставки и восстановления. Универсальный DevOps, не погруженный в предметную архитектуру, не способен построить такие гейты, поскольку он видит систему снаружи. Он может проверить, что контейнер запустился, но не может доказать, что приложение осталось корректным. DevOps распадается на три роли Исчезновение старой DevOps-профессии не означает, что эксплуатационная сложность исчезнет. Она просто перераспределится между более осмысленными ролями. Первая роль, это product engineer или full-cycle engineer, который отвечает за сервис целиком, начиная с кода и заканчивая его поведением в production. Для него deployment, observability и эксплуатация являются продолжением разработки, а не передачей работы в соседний отдел.

DevOps заканчивается. Ops возвращается в инженерное дело DevOps долго воспринимался как самостоятельная инженерная специализация, возникшая на границе между разработкой и эксплуатацией, однако со временем эта граница не исчезла, как предполагалось изначально, а, напротив, превратилась в отдельную профессиональную территорию со своими инструментами, ритуалами, сертификатами и людьми, которые отвечали не столько за продукт, сколько за доставку чужого кода в production. Пока инфраструктура оставалась сложной, ручной и плохо стандартизированной, такая специализация была экономически оправданной. Нужно было поднимать серверы, настраивать сети, собирать пайплайны, писать скрипты развертывания, обслуживать Jenkins, Kubernetes, Terraform, Ansible, Helm и десятки других систем, каждая из которых требовала отдельного опыта и порождала собственный слой эксплуатационной магии. Сегодня значительная часть этой работы перестает быть инженерной задачей и становится задачей генерации, настройки и проверки конфигурации. Агент может написать Dockerfile, собрать CI/CD pipeline, подготовить Terraform-модуль, описать Kubernetes-манифесты, настроить базовые метрики и сформировать политику развертывания быстрее, чем человек успеет найти нужный пример в документации. Именно поэтому исчезает не эксплуатация как область знаний, а DevOps как профессия посредника между кодом и инфраструктурой. Проблема не в инструментах, а в отсутствии предметного понимания Слабость классического DevOps-подхода заключается в том, что он часто позволял человеку годами работать рядом с программной системой, почти не понимая ее внутренней логики. Можно уметь развернуть кластер, написать Helm chart, настроить autoscaling и собрать дашборд, но при этом не понимать, какие инварианты защищает приложение, что произойдет при повторной обработке события, где допустима eventual consistency, какие данные можно восстановить, а какие нельзя, почему конкретный retry опасен и что в действительности означает успешный deployment. Пока код писали люди, а эксплуатационные процессы оставались медленными и ручными, подобный разрыв между разработкой и инфраструктурой можно было компенсировать коммуникацией. Разработчик объяснял, что нужно запустить, DevOps-инженер пытался это упаковать, тестировщик проверял результат, а затем вся команда несколько дней выясняла, почему система работает не так, как ожидалось. В agentic-разработке такая модель перестает масштабироваться. Когда скорость производства кода возрастает в несколько раз, главным ограничением становится уже не способность написать очередной сервис или конфигурационный файл, а способность определить, соответствует ли изменение архитектуре, не нарушает ли оно контракты, не ухудшает ли надежность и может ли система доказать собственную корректность до выхода в production. Это уже не задача специалиста по инфраструктурным инструментам. Это задача инженера, который понимает стек целиком. Почему разработчику проще освоить Ops, чем администратору освоить разработку У сильного разработчика уже есть значительная часть необходимой когнитивной базы: он понимает типы, состояния, зависимости, интерфейсы, контракты, транзакции, тестирование, обработку ошибок, конкурентный доступ и последствия изменения кода. Чтобы взять на себя эксплуатационную часть, ему необходимо дополнительно разобраться в Linux, сетях, контейнерах, облачных примитивах, IAM, observability, отказоустойчивости и управлении ресурсами. Это серьезный объем знаний, но он ложится поверх уже существующей инженерной модели мира. Администратору, который привык работать с инфраструктурой как с набором машин, конфигураций и процедур, приходится совершить более глубокий переход. Ему необходимо научиться воспринимать систему не как среду, которую нужно настроить, а как исполняемую модель с формальными границами, состояниями, контрактами и проверяемыми свойствами. Именно поэтому формула “разработчики должны немного освоить Ops” выглядит реалистичнее, чем формула “DevOps-инженеры должны немного научиться программировать”.

🧲Чистый код отменяется: Дядя Боб признался, что вслепую доверяет ИИ-агентам 🌐Роберт Мартин - легендарный Дядя Боб, автор библии всех разработчиков "Чистый код" и "Чистая архитектура" в своём Твиттере заявил: что официально перестал вчитываться в исходники, которые для него пишут ИИ-агенты. Весь его новый воркфлоу сводится к примитивной схеме: алгоритм генерирует скрипт, автоматика прогоняет его через тесты, и если всё зелёное - работа сделана. Естественно, в комментариях начался пожар. На резонный вопрос о том, как гуру идеальной архитектуры может не глядя доверять нейросетям, которые регулярно галлюцинируют, бредят и лепят костыли, Мартин выдал максимально циничный, но убийственно точный ответ: Люди делают то же самое 🦔  CyberYozh

​Разработчики нейросетей скупают миллионы физических книг, чтобы накормить ими ИИ. А потом измельчают их и выбрасывают в мусор. Делают это тихо, в промышленных ангарах, без шума. Одна компания покупает книги миллионами. Машина отрезает у них корешок. Проглатывает страницы и сканирует их, одну за другой. А то, что от книги остаётся, отправляется в шредер. Таким образом, бумажные носители исчезают навсегда. В ходу идут только старые книги, вышедшие до 2022 года, написанные до того, как интернет заполнился текстами, созданными искусственным интеллектом. Они жаждут чистого человеческого знания. Мыслей реальных людей. Без примесей компьютерного бреда. И ради этого уничтожают оригинал. А что самое мутное в этой истории? Покупатель старых фолиантов не светится, нанимая посредника. Подписывает юридически обязывающее соглашение о неразглашении. Никто не знает, какая компания и какие именно книги выметает с рынка. Кто за этим стоит? Все анонимные информаторы указывают на Anthropic, разработчика Claude. А самый заметный оперативный ответственный за проект: Tom Turvey. Но это практика всего сектора. Здесь не только одна компания замечена за этим. Вопрос: а законно ли это? Да, законно. Есть уже постановление суда. Покупаешь книгу, сканируешь, уничтожаешь... и оставляешь себе цифровую копию... Всё законно. Но законно не значит хорошо. Уникальные экземпляры, которые существовали сто лет, теперь будут измельчены. Их содержание — под замком, внутри машин ИИ, которые завтра решат, какая информация дойдёт до ваших глаз... а какая нет. То есть если предположить, что по каким-то причинам возникнет глобальный блэкаут, или воздействие на дата-центры с помощью сильного ЭМИ - все знания, накопленные человечеством будут утеряны навсегда. Причём делается всё быстро, тайно, с маниакальным напором. Создаётся впечатление, что ИИ уже поработил разум своих разработчиков, превратив их в соучастников уничтожения всех знаний, накопленных человечеством. И как бы печально это не было, их уже не остановить.