В 2012 году ученые показали, что бактериальную систему CRISPR-Cas9 можно превратить в программируемые «ножницы» для ДНК. Через восемь лет Дженнифер Дудна и Эммануэль Шарпантье получили за эту работу Нобелевскую премию по химии.

16 июля 2026 года команда Дженнифер Дудны представила в Science способ проектировать такие белки с помощью ИИ. Ученые создали компактные нуклеазы, которых нет в природе, а затем проверили их в бактериях, растительных и человеческих клетках. Некоторые варианты работали лучше белка, с которого начался эксперимент. Зачем генной терапии искусственный редактор клеток и что ждать в будущем — разбираемся в материале ниже.

Привет, Хабр! На снова команда Research & Insights Центра стратегии цифровых продуктов МТС. Мы уже разобрали мировой рынок 5G и объяснили, почему в России нельзя взять и «включить» эту технологию. В этой статье поговорим о том, кто и за что будет платить…

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

Привет, Хабр! Как-то я пересмотрела десяток роликов с роботами подряд — просто чтобы понять, что из увиденного вызывает у меня доверие, а что нет. Робот Figure, который делает кофе за минуту, гуманоид Tesla, эффектно падающий во время презентации в Майами, гимнастическая программа Atlas от Boston Dynamics с сальто и рывком через кувырок. Все три ролика показывают одну и ту же индустрию, но оставляют совершенно разное впечатление.

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

Забегая вперед: переломного момента, после которого прогресс в этой области стал бы очевиден без объяснений — по аналогии с тем, что произошло несколько лет назад в языковых моделях, — в робототехнике пока не случилось. Технология развивается быстро и вполне предсказуемо — ее прогресс измеряется не вау-эффектом, а скучными процентами в отчетах. Попробуем разобраться, как эти проценты читать.

Привет, Хабр! Я — Даша, отвечаю за обучение руководителей в MTC Web Services, проектирую образовательные продукты для наших лидеров: от коротких программ до длинных траекторий развития.

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

Еще полгода назад я подключала ИИ исключительно на последних этапах. Когда решение уже найдено, модель помогает быстрее его реализовать: предложить структуру, придумать название курса, создать черновик контента или скорректировать текст. Сейчас же я открываю чат с LLM гораздо раньше, когда решения или образа результата еще нет в голове, и использую его не только для того, чтобы сделать работу быстрее, но и чтобы снизить вероятность ошибки на самом важном этапе — когда необходимо решить, что именно нужно делать. Это, пожалуй, самая заметная перемена в моей работе с ИИ, о которой и пойдет речь в этом материале.

Спойлер: здесь не будет обзора моделей. Меня гораздо больше интересует, как меняется рабочий процесс, когда ИИ становится частью проектирования. 

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

Как меняется работа с корпоративными данными под влиянием ИИ, рассказали эксперты на седьмом MWS Meetup.

Привет! Меня зовут Алиса, я преподаю писательское мастерство. Я часто работаю с авторами из IT-сферы, которые хотят реализовать себя в художественной или нон-фикшен прозе. И очень часто меня спрашивают про то, как ИИ меняет эту сферу. Можно сколько угодно размышлять и строить догадки на эту тему, но в этой статье я оттолкнусь от одного интересного исследования. Его авторы проверили 14 419 книг на Amazon на наличие ИИ-текста и сопоставили результаты с данными о продажах. По сути эта работа затрагивает вопрос сохранения ценности писательского труда в ближайшие годы.

Несколько месяцев назад я разбирала на Хабре отчет «Нетфликс-2025» и пыталась понять, почему истории сегодня работают иначе, чем десять лет назад. Тогда меня особенно зацепила тема безграничного выбора. Стриминг превратил огромную библиотеку контента в отдельную культурную среду: зритель приходит туда за сериалом, а получает еще и опыт открытия, рекомендации, фан-сообщество, мемы, разговоры — и возможность найти историю, в которой узнает себя.

Сам «Нетфликс», конечно, описывает все это победоносно: аудитория якобы больше не пугается изобилия, потому что алгоритмы помогают не утонуть в нем. Среди 8000 единиц контента обязательно найдется что-нибудь для вас. Остается только открыть приложение и довериться выдаче.

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

Теперь та же проблема добралась до книжного рынка, только с дополнительным ускорением. Стриминговые платформы сделали практически бесконечным доступ к уже произведенному контенту, но чтобы пополнить каталог новым фильмом или сериалом, все еще нужны сценаристы, актеры, съемочная группа, монтаж и довольно много денег. Книгу же технически можно сгенерировать за несколько дней и сразу отправить на площадку самопубликации. И тут возникает множество вопросов: а качественнее ли текст, создаваемый ИИ, и если да, то в каких жанрах? Можем ли мы отделять «ИИ-шлак» от авторского текста — особенно если по изображениям мы это уже делаем все хуже?

Раньше инженера растили на задачах, которые сейчас называют «рутиной»: написать автотесты, собрать первичную аналитику, разметить датасет или составить документацию. Эта черновая работа была естественным тренировочным полем. Пробираясь через нее, новичок совершал контролируемые ошибки, проходил код-ревью и формировал профессиональное суждение (engineering judgment) — интуитивное понимание того, как система ведет себя в реальности. 

В классической инженерии этот этап называют «накоплением насмотренности»: нельзя спроектировать надежный мост, не изучив сотни типовых узлов и чужих ошибок. Похожий принцип десятилетиями поддерживал живучесть ядра Linux: Линус Торвальдс и команда топ-мейнтенеров годами заставляли новичков вручную переписывать патчи, чтобы те ментально «проросли» в архитектуру подсистем и переняли культуру инженерных решений.

Генериративный ИИ автоматизировал рутинные задачи — написание тестов, разметку данных, — которые раньше служили тренировочным полем для развития инженерного суждения. По мнению исследователей Microsoft, этот сдвиг к 2026 году остановил традиционный конвейер передачи опыта, создавая риск «кадрового дефолта» в IT. В исследовании Microsoft говорится, что AI Drag (эффект торможения) становится главным вызовом, требующим перестройки обучения специалистов.

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

Маршрутизация языковых моделей кажется достаточно тривиальной задачей: простые запросы уходят дешевым моделям, сложные — дорогим.  Еще можно выбирать модель по специализации: одну для программирования, другую для обработки изображений, третью для анализа документов. Но это легко только на первый взгляд.

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

Привет, Хабр. Я Матвей Лихота, старший Go-разработчик и DevSecOps. Как это часто бывает с внутренними инструментами, идея этой утилиты появилась уже после того, как у нас упал прод. Во время хотфикса сотрудник забыл обновить в одном из двух сервисов версию библиотеки с контрактами и в результате в зависимостях осталась предыдущая версия. Перед слиянием код собирался и тесты проходили, но после деплоя сервис упал с ошибкой 500: новое поле в структуре запроса не появилось на сервере. Пришлось откатить изменения и даунтайм был ощутимый.

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

Тогда я решил, что теперь проверять актуальность зависимостей будет CI. Так и появился Dependency Validator.

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

О том, как меняется подход к автоматизации разработки, рассказали инженеры MTC Web Services на митапе для Go-разработчиков. А еще в эфире разобрали несколько практических сценариев, где в одном случае ИИ-агент получает собственную среду выполнения, в другом типовые инфраструктурные задачи выносятся на общую платформу, а в третьем — код создается на основе описания API.

Общий тренд — разработчику приходится все больше заниматься архитектурой, задавать правила работы и проверять результат. Об этом подробнее под катом.

Недавно вышел очередной фильм по «Дюне». Первая же серия — открывающий облет над Арракисом: камера ныряет между дюнами, будто сама превращается в песчаную бурю, гигантский червь всплывает из-под поверхности пустыни как левиафан, а орнитоптеры складывают крылья настолько правдоподобно, что на секунду забываешь, что это графика, а не документальная съемка насекомообразной машины. Работа сделана душевно и с почтением к первоисточнику.

И все же чего-то не хватает.

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

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

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

Привет, Хабр! В первой части я старался держаться в рамках оригинального Fallout 4. Мы исправили проблемы движка, убрали подергивания, обновили текстуры, погоду, воду и растительность. В результате игра стала выглядеть и работать заметно лучше, но по сути осталась той же. Именно этого я тогда и добивался.

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

Я пару лет назад купил по случаю, очень недорого PS4 Fat. Приобрел как нерабочую — по словам предыдущего владельца, она не давала изображение на экран. Получив девайс, я первым делом проинспектировал HDMI-порт. И точно, он оказался поврежден. Пара внутренних контактов оторвались, причем довольно сильно. При помощи длинного и узкого пинцета у меня получилось их выровнять и прижать к прежнему «месту обитания». 

Менять порт было просто лень, если честно. Я подключил к коннектору HDMI-кабель, стараясь не дышать, и… да, приставка завелась. Если пошевелить провод, появлялись артефакты, поэтому я поставил консоль на стол и лишний раз старался ее не дергать. Так прошло года полтора, играл довольно часто, никаких проблем не было… Пока однажды мой друг не взял консоль в руки (я как раз вышел) во время игры. Изображение пропало, и он, конечно же, стал переподключать кабель. Итоги — на анонсном снимке. Короче, пришло время чинить девайс, тут уж пинцет не помог бы. Как вы понимаете, далеко не все прошло гладко. Что ж, поехали! 

Да, прежде чем уедем, еще небольшая предыстория. Дело в том, что у меня солидный опыт микропайки. Я перечинил десятки ноутбуков, менял BGA-чипы как на iPhone, так и в лэптопах. Реболлил процессоры Nintendo Switch разных моделей, ноутбуков и тех же телефонов. Но вот так сложилось, что с HDMI-коннекторами PS4 дела не имел, поэтому и не трогал до поры до времени. И оно наступило, это время. 

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

Привет, Хабр! Представьте ситуацию в интернет-магазине. Клиент звонит и пишет в поддержку, так как получил поврежденный заказ. При этом он уже откладывал повторную покупку из-за долгой доставки в прошлый раз и не дописал отзыв, который хотел оставить неделю назад. Человек на грани ухода к конкурентам. Что увидит типичный оператор поддержки? Да просто текущее обращение. Он оформит возврат, закроет тикет — и на этом как бы все. Остальные сигналы останутся незамеченными им. В противовес ему, агентная система видит всю картину, ловит паттерны и закрывает боли клиента: оформляет возврат, предлагает промокод на следующую покупку, устраняет причину недовольства. Это рабочая модель, которую уже описывают аналитики McKinsey в свежем отчете о перестройке клиентского опыта в эпоху агентского ИИ.

Последние пару лет компании в основном просто добавляли генеративный ИИ поверх старых процессов. Да, чат-боты стали вежливее и быстрее, но логика принятия решений при этом у них не изменилась. Клиент как сталкивался с разрозненными сценариями на разных этапах пути, так и сталкивается. Агентский ИИ меняет эту логику. Вместо заранее прописанных сценариев он в моменте принимает решение на основе реального контекста. Что это значит на практике, через какие этапы проходят компании и какой результат получают на выходе?

Всем привет! Меня зовут Александр Цай, я ведущий инженер-аналитик в МТС Web Services.
Занимаюсь всем, что связано с данными и ИИ. Найти, заполучить, обработать, спроектировать, развернуть — это все ко мне.

Опущу все нудные подробности, решили мы развернуть себе Superset 6.1.0 — последнюю версию, но столкнулись с тем, что заказчику категорически не нравится штатный фильтр по датам и он не хочет пересаживаться со своего BI, а хочет он календарик. А еще — пару плагинов с оглядкой на PowerBI. Поэтому встал вопрос создания собственного плагина-фильтра.

Казалось бы, задача несложная. Пара-тройка гайдов в en сегменте имеется, есть даже документация и штатный генератор шаблонов. Но по факту оказалось, что все это не работает. Генератор так вообще не обновлялся аж с 2024 года: выдает шаблон, который ссылается на уже несуществующие классы и типы, что автоматически делает все гайды неактуальными…

А что все это значит? Время написать свой собственный!
Об этом и расскажу в сегодняшнем материале. 

Дисклеймер: Я питонист до мозга костей и в тайпскрипте, да и фронте в целом, понимаю не очень много. Простите меня, адепты сего языка программирования, но код самого плагина навайбкожен (хоть и проверен насколько я смог).
В npm не запушил тоже умышленно, цель статьи — дать исходники и показать, как можно собрать плагин. Любой желающий может что-то додумать и доработать, собрать или разобрать и так далее.

На старте почти любого проекта бизнес-аналитик оказывается в одной и той же ситуации. Бизнес говорит: «клиент может иметь несколько договоров», «договор относится только к одному клиенту», «товар идентифицируется артикулом».

Эти формулировки понятны предметным экспертам, но в таком виде их не передашь архитектору данных или команде разработки — для них это еще не техническое задание. Неясно, где здесь сущность, а где значение, что будет идентификатором, какие ограничения критичны, а какие можно оставить на уровне процессов.

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

Меня зовут Вадим Скляров, я бизнес-аналитик проектного офиса МТС Медиа. В этом материале расскажу, почему для этой задачи я выбрал ORM2 в качестве инструмента концептуального моделирования, какие приложения есть на рынке, почему в итоге понадобилось собственное SPA-приложение и чем оно оказалось полезным.

Организовать надежную связь в открытом карьере или шахте — задача технически нетривиальная. Любой, кто с ней сталкивался, знает, как сложно обеспечить решение без проводов с нормальной скоростью: приходится одновременно проводить радиопланирование для очень сложных условий распространения сигнала и выбирать точки размещения оборудования в сложных условиях зоны ведения горных работ — учитывая сам план работ, ограничения по организации электропитания и каналов связи для транспорта между элементами беспроводной сети, выполняя требования по пылевлагозащите и взрывобезопасности. При этом нужно сделать это решение бесшовным, без прерывания сеансов связи (при переключениях между базовыми станциями) и с минимальным числом мертвых зон. А уж приоритизация трафика — это вообще задача со звездочкой для любой беспроводной сети, не только в карьере или шахте.

Какую технологию выбрать для работы в сложных, удаленных от больших городов условиях? Сразу появляется идея — накрыть рабочую зону Wi-Fi. Но у этой идеи сразу несколько ограничений: 

• Низкие характеристики по покрытию, для покрытия значительной площади требуется установка десяток точек доступа, для каждой из которых требуется питание, канал связи, порты на сетевом оборудовании.
• Wi-Fi может терять сессии при переключении между точками доступа.
• Высокое затухание, высокая интерференция при переотражении.  
• Нет механизмов управления задержками при загрузке канала трафиком, линейно возрастает уровень задержки 

В отличие от Wi-Fi технология pLTE позволяет достичь качественно иного уровня автоматизации горных процессов (включая подземные работы), обеспечивая детерминированную задержку и стабильное соединение в сложных условиях рудников и карьеров.

Поэтому в горной отрасли все чаще делают выбор в пользу в private LTE/5G при создании опорной инфраструктуру связи. Давайте разберем, как технология, рожденная для массовых звонков и стриминга видео, становится основой безопасности и рентабельности горного дела.

Когда я разбирал в предыдущей статье гипотезы появления сознания, в центре внимания оказалась идея нейробиолога Антонио Дамасио о том, что сознание рождается не из абстрактного мышления, а из тела. Из тех базовых сигналов, которые организм подает сам себе ради выживания.

Но во что разворачивается это сознание по мере взросления человека?

Концепции возрастной психологии и психоанализа — от теории привязанности до моделей раннего эмоционального развития — показывают, что тело остается фундаментом и на следующих этапах. Только фокус смещается с механизмов восприятия на саму структуру личности.

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

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

Привет, Хабр! Я Матвей Лихота, старший Go-разработчик. В предыдущем материале я показывал, как получить Go-код из OpenAPI. Теперь хочу сделать еще один шаг назад — к моменту, когда контракта еще нет.

На демо частенько можно увидеть, как по простому запросу «напиши CRM» или «собери интернет-магазин» LLM уже через минуту готовит сервер, модели, миграции и тесты. Но в реальности, конечно, все происходит чуть иначе: проверяем код, а там — сюрприз-сюрприз ошибки. Повторив тот же промпт, мы получим другую архитектуру и снова потратим время на проверку. И нет гарантии, что после переделки ошибок не станет еще больше.

Конечно, все дело в промпте. Согласитесь, странно просить модель понять задачу, выбрать архитектуру, определить границы и все реализовать за один шаг? Что, если LLM сначала проектирует систему и выпустит OpenAPI, Proto, JSON Schema, CloudEvents и AsyncAPI? А код мы добавим чуть позже: за повторяемую часть будут отвечать обычные генераторы, а за проектно-зависимую — разработчики и агент в контексте репозитория.

Такой подход, где главным артефактом становится контракт, а код — его производной, можно назвать Documentation Driven Agent Development или Specification Driven Agent Development. Как он работает — покажу на примере разработки простой автоматической телефонной станции (АТС), а еще проведу границу между генераторами и агентами.

Древние надписи почти невозможно расшифоровать, но за ними стоят целые культуры, о которых мы почти ничего не знаем. Линейное письмо А с Крита, этрусские тексты, знаки долины Инда до сих пор не поддаются полному переводу. Без подсказок вроде розеттского камня или родственных живых языков работа превращается в лотерею, где каждый новый фрагмент может как помочь, так и запутать.

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