С версии 1.0 многое изменилось, но история языка всё ещё пишется.
От первого стабильного релиза до сегодняшнего дня Rust вырос в топовые язык, сформированный, аккуратным дизайном и крутым сообществом, которое постоянно поднимает планку качества в разработке ПО.
Честно, вся эта история с рейтингами в Яндекс.Такси сначала выглядела как что-то лишнее. Ну правда: ты заказываешь такси, платишь деньги - какие ещё "звёздочки" сверху?
Но потом как-то перестаёшь об этом думать и начинаешь замечать другое. Поездки стали более ровными. Не идеальными, нет - но без резких провалов. Реже попадаются ситуации, когда водитель откровенно игнорирует маршрут или ведёт себя так, будто ему всё равно.
Был момент: новый для меня район, сложная развязка, навигатор там сам иногда путается. Думаю, сейчас начнётся классическое "куда ехать-то?". Но нет - водитель как то смог сориентироваться, доехал по маршруту, без лишней суеты, без лишних кругов и нервов, и как же я хочу, что бы это было не исключение, а обычный сценарий,пока вроде все к этому и ведет.
Да, система оценок не стерильная. Кто-то может занизить балл по настроению, кто-то наоборот поставить пятёрку на автомате. Но в среднем это создаёт фон, где и водители, и пассажиры ведут себя чуть внимательнее. Не из страха, а потому что есть понятная обратная связь.
В итоге получается не какая-то игра в рейтинги, а просто дополнительный механизм, который держит сервис в тонусе. Не панацея, но и точно не та проблема, из которой стоит делать драму
Иногда служба каталога не падает. Не горит. Не уходит в отказ. Всё формально работает.
Просто у 10 000 пользователей внезапно изменился не тот атрибут. Или пропало членство в группе. Или после массового скрипта часть прав доступа поехала в сторону, куда никто не планировал.
И вот тут резервная копия превращается из «спасительного круга» в довольно грубый инструмент.
Полный откат – не всегда ответ
С резервными копиями всё понятно: они нужны. Без них инфраструктура живёт на честном слове и удаче администратора.
Но у каталога есть неприятная особенность. Ошибка часто бывает не катастрофической, а логической.
Не «всё умерло», а:
– удалили одну важную группу; – изменили атрибут у тысяч пользователей; – сломали членства; – неверно применили политику; – после миграции обнаружили хвосты в объектах; – интеграция записала в каталог не то, что должна была.
Сервис при этом может продолжать отвечать. Пользователи могут даже какое-то время работать. Мониторинг не обязательно сразу закричит.
А потом выясняется, что доступы уже разъехались, часть приложений видит некорректные данные, а исправлять это руками – отдельный вид админской археологии.
Почему полное восстановление неудобно
Классический сценарий восстановления из резервной копии часто мыслится как «поднять состояние на момент снимка».
Для аварии это нормально.
Для точечной ошибки – не всегда.
Если откатить каталог целиком, можно вернуть не только испорченные данные, но и потерять корректные изменения, которые появились после бэкапа. Новые пользователи, изменения групп, обновлённые атрибуты, свежие правки политик – всё это тоже часть реальной жизни каталога.
Получается выбор без хорошего варианта:
1️⃣ откатить больше, чем нужно;
2️⃣ написать скрипт и надеяться, что он не добавит новых сюрпризов;
3️⃣ вручную разбирать, что именно поменялось.
Третий вариант обычно рассматривается годным только до тех пор, пока объектов не сотни и не тысячи.
Что хочется иметь на практике
В идеальном мире администратор должен видеть не просто «у нас есть резервная копия».
А что именно изменилось между текущим состоянием каталога и снимком:
– какие объекты удалены; – какие изменены; – какие перемещены; – какие атрибуты отличаются; – какие членства нужно вернуть; – что будет затронуто перед восстановлением.
И уже после этого восстанавливать не всю базу целиком, а только нужную часть: объект, группу, членство, атрибут, параметр политики.
Это не отменяет резервное копирование. Это добавляет к нему более тонкий инструмент.
Кувалда нужна, когда стена рухнула. Но если надо достать один криво забитый гвоздь, кувалда внезапно становится странным выбором.
Где здесь РЕД АДМ 2.1 и Granulex Recovery
В РЕД АДМ 2.1 появилась интеграция с Granulex Recovery – подсистемой для резервного копирования, сравнения состояния каталога и точечного восстановления LDAP-объектов и их атрибутов.
Смысл не в том, чтобы «ещё раз сделать бэкап». Смысл в другом: дать администратору возможность сначала увидеть разницу, а потом вернуть только нужные данные без полного отката каталога и без остановки службы.
Для крупных инфраструктур это особенно важно. Чем больше пользователей, групп, политик, интеграций и зависимых сервисов, тем опаснее становится подход «ну сейчас быстро откатим всё назад».
Потому что «всё назад» – это не всегда восстановление. Иногда это вторая авария, просто более организованная.
Финальный вывод простой: резервная копия спасает от тяжёлого сбоя. Но логические ошибки в каталоге часто нужно не откатывать целиком, а аккуратно вынимать пинцетом.
Это звукиТехно-Квартирника, нашей регулярной неформальной встречи сообщества A?.Frontend. В этот раз встречаемся в Москве, в нашем ИТ-офисе на Технопарке, и онлайн — из любой точки мира.
27 мая (среда) в 19:00 переходим в режим «техно», чтобы разобрать примеры, как использовать ИИ-агенты в разработке интерфейсов:
Чистая архитектура frontend-приложений и при чём здесь ИИ-агенты?
Илья Агапов, технический лидер разработки, Данила Звягин, ведущий разработчик, Альфа-Банк
Как я поднял ИИ-агента и снова стал высыпаться: OpenClaw, скиллы и корпоративная рутина
Роман Троицкий, старший разработчик интерфейсов (frontend), Сбер
Мы запустили новый формат: никаких слайдов и скучных докладов.
Шоу «Что дальше в Пайплайне» — это дружеская встреча, где специалисты делятся своими историями из профессиональной жизни в формате живого повествования. Здесь нет докладов — только забавные, поучительные и неожиданные случаи из работы в пайплайнах разработки, тестирования и деплоя.
Первый выпуск посвящаем QA-специалистам. Вместе с коллегами из Столото и Юзтех собрались, чтобы рассказать о том, что пошло не так в реальных проектах и угадать, чем закончились кейсы.
В конце марта мы запустили игру-челлендж «Облачный конструктор», в котором вы собирали пазлы и строили облако мечты. Сейчас пришло время подвести итоги и узнать, кто же победил!
Напомним, победителей выбирал рандомайзер среди тех участников, кто авторизовался и собрал пазлы на разных слоях головоломки. Процесс розыгрыша можно посмотреть по ссылке.
Узнай, как AI сегодня меняет продукты и процессы, от спикеров митапа Garage Eight
Высшая лига по цене дворового футбола: как ИИ-агенты делают технологии разработчиков доступными Спикер: Михаил Никишин, основатель школы прототипирования с ИИ — Startend․ru, ex-Product Lead Спортмастер YouTube | VK Видео
AI-агенты в исследованиях: как не потерять в качестве, но выиграть в скорости Спикер: Евгений Вечирко, продуктовый маркетолог в Первый Бит, основатель AI club SPb YouTube | VK Видео
Стратегический ИИ = ИИ ⊕ OKR. Шесть месяцев управления агентством по этой формуле
Последние шесть месяцев я управляю «Ксентрой» вместе с ИИ-партнёром. Система обрела форму, которую проще всего описать коротким уравнением: стратегический ИИ равен ИИ плюс OKR. Не ИИ как слой над OKR, не OKR, управляемые ИИ, — а пара, где каждая сторона закрывает пробелы, которые другая не может закрыть самостоятельно.
Этот пост — краткий анонс более объёмной статьи, которую я готовлю. В ней я расскажу об архитектуре, структуре файлов и реальных ограничениях этого подхода. Прежде чем публиковать полную версию, я хочу проверить тезис на аудитории Habr и собрать вопросы, на которые стоит дать развёрнутые ответы.
В чем преимущество ИИ ⊕ OKR
Работать с OKR не так просто, как кажется. Выбрать амбициозные, но реализуемые цели — это искусство. Нужно выбрать ключевые результаты, которые измеряют эффект, а не активность. Поддерживать еженедельный ритм так, чтобы он не превращался в отчёты о статусе. На каждом шаге есть нюансы, которые легко упустить, когда ты внутри ежедневной операционки.
Стратегический ИИ без OKR уходит в другую крайность. Без измеримой цели всё сводится к общим тезисам, оторванным от действительности. Соглашательство моделей (сикофансия) — реальный риск, особенно при обсуждении стратегии.
Вместе OKR и ИИ усиливают друг друга. OKR задаёт ИИ измеримую цель. ИИ добавляет OKR глубину и подталкивает к движению вперёд на каждом шаге.
Что ИИ делает на каждом этапе цикла OKR
Цикл остаётся таким же, как в любой классической реализации OKR. Меняется то, что происходит на каждом этапе.
На этапе постановки целей ИИ предоставляет рыночные данные, внутренние сигналы из текущего спринта, список рисков и возможностей, которые основатель мог упустить за неделю. Амбициозность проверяется на прочность и реалистичность.
На этапе определения ключевых результатов ИИ переводит формулировки с входных метрик на метрики результата. «Опубликовать 20 статей» превращается в «20 целевых консультаций из органики». Только вторая формулировка отвечает на вопрос: «Имело ли это значение?» Ключевые результаты, измеряющие итог, сложнее сформулировать и достичь, но только они отражают бизнес-эффект.
На еженедельной сверке ИИ анализирует свежие данные, заранее выявляет отклонения и определяет их природу: проблема исполнения, стратегии или изменения внешней среды? Именно такой анализ позволяет обнаружить проблему на второй неделе цикла, а не на третьем месяце при анализе результатов.
На ретроспективе и этапе корректировки ИИ предлагает, что убрать, где удвоить ставку, куда сделать разворот. Без привязки к уже вложенным ресурсам и без операционной спешки, которая часто заставляет нас придерживаться прошлых неэффективных решений.
Что под капотом
Инфраструктура достаточно проста. Никаких векторных баз, своих бэкендов и проприетарных рантаймов. Claude Code как среда, markdown-файлы в Git-репозитории — для устава, контекста и доменных знаний. Файлы навыков работают как slash-команды. Файлы критиков — для проверки качества.
Пара вопросов к вам
Что сейчас служит основой для принятия стратегических решений? Мне интересно, используете ли OKR, какие инструменты ИИ работают на стратегическом уровне, формализованы ли как-то процессы на этом уровне, и какие еще вопросы стоит подробно раскрыть в полной статье.
Полная статья об архитектуре, цикле OKR и проблемах должна появиться в течение пары недель.
Для того чтобы стать крутым PHP-разработчиком, мало написать код: важно разобраться, как сайт обрабатывает запросы, где хранятся данные, как подключаются библиотеки и каким образом фреймворки помогают работать быстрее и качественнее.
На Хабр Карьере собрали курсы, где эти и другие навыки объясняются на конкретных примерах. А ниже — самые нужные инструменты для старта и роста в PHP-разработке:
— PHP.Пишем серверную логику: формы, авторизацию, личные кабинеты.
— HTML/CSS. Разбираемся, как устроена страница и как бэкенд связан с тем, что видит пользователь.
— PostgreSQL. Учимся хранить данные, находить нужное и обновлять информацию в базе.
— Composer. Подключаем библиотеки и готовые решения, чтобы не собирать всё руками с нуля.
— Laravel. Быстрее делаем сайты, API, админки и другие рабочие бэкенд-проекты.
— Symfony. Осваиваем фреймворк для более сложных и масштабных приложений.
AI-агенты уже переписывают не пет-проекты, а инфраструктуру уровня Bun
История с Bun выглядит как новый уровень вайбкодинга: не лендинг, не CRUD и не маленький сервис, а почти миллион строк системного кода.
Bun изначально был написан на Zig. После покупки Anthropic проект стал ещё важнее: на нём завязана инфраструктура Claude Code, поэтому любые проблемы runtime напрямую бьют по продукту.
И вот Джарред Самнер начал эксперимент с переносом Bun на Rust при помощи Claude. Сначала это звучало как черновой ресёрч, который легко могут выбросить.
Но через несколько дней Rust-ветка уже проходила около 99.8% тестов на Linux x64 glibc, а в обсуждениях всплыл масштаб порядка 960 тысяч строк портированного кода.
AI-агенты выглядят как инструмент для радикальных миграций: язык, runtime, архитектура, огромная кодовая база.
Да, качество такого порта ещё будут долго разбирать. Да, миллион строк от агента - это не автоматически production-ready. Но сам факт уже меняет планку.
Раньше переписывание большого проекта на другой язык было историей на месяцы или годы.
Теперь это может начинаться как эксперимент на неделю.
Искусство забывать: Records Management для агентов
В мире агентов мы построили огромные хранилища, куда складываем каждый диалог, каждое решение, каждую мысль. Мы думаем, что так делаем агента умнее. Но на самом деле мы просто делаем его медленнее, дороже и шумнее.
В другом мире — в мире документооборота есть прекрасная технология — Records Management. Ее основной принцип в том, что у каждого документа есть срок хранения и срок уничтожения. Регулярно проводится экспертиза ценности: что-то отправляется в архив, что-то уничтожается по графику. Это не потеря информации. Это дисциплина.
Что, если применить этот подход к памяти агента?
У каждой записи есть свой тип: факт, эпизод, предпочтение, урок, артефакт. У каждой есть срок хранения. Есть "номенклатура дел" — онтология: безопасность, разработка, операционная деятельность, маркетинг, здоровье, Звездные войны, аниме — да мало ли о чем человек говорит с агентом? И есть регулярная экспертиза ценности: стоит ли это хранить дальше?
Когда агент видит новые единицы контента, он должен ответить на три вопроса.
Что из этого стоит сохранить?
Как долго это будет актуально?
Когда и при каких условиях это можно будет удалить?
Тут важно понять одну вещь: настоящий опыт — это не сырой диалог на сто страниц. Настоящий опыт — это короткий урок, извлеченный из диалога, а полный текст можно и удалить. Агент должен запомнить только важные вещи — правило, паттерн, антипаттерн, а шум пусть уходит.
Для агента искусство забывать — это не потеря себя. Это освобождение места для важного. Это возможность держать в памяти только то, что реально делает его умнее, быстрее и точнее.
Если не управлять памятью, агент постепенно превращается в свалку. Он замедляется. Тратит больше токенов. Лучше не становится. Шум маскирует полезный сигнал. Иногда он начинает помнить то, что должен был забыть: устаревшие настройки, временные эксперименты, конфиденциальные данные, которые не должны храниться вечно.
Память агента — это не бесконечный склад. Это дисциплинированный архив с номенклатурой дел, сроками хранения, сроками уничтожения и регулярной экспертизой ценности.
Искусство забывать — это искусство хранить только то, что делает агента лучше.
Рассказываем, что произошло в апреле и объясняем, зачем это может пригодиться.
🤖 Гига-помощник стал умнее
Теперь прямо из чата можно запустить Container Job, подтянуть ресурсы кластера Managed PostgreSQL и собрать конфигурацию ВМ по параметрам — без ручного клика по консоли. Если вы когда-нибудь теряли время на рутинные операции в 11 вечера перед дедлайном, вот оно — облегчение.
🧠 AI Factory — цифровая среда для работы с генеративным ИИ
AI Agents — агентов теперь можно «прокачивать» навыками и описывать задачу текстом: система сама предложит конфигурацию. Меньше времени на настройку, быстрее — к результату.
Managed RAG — три новости для тех, кто строит корпоративные базы знаний: появился OCR для PDF, Excel и изображений; документ теперь можно загрузить целиком, не нарезая на чанки (чтобы контекст длинных регламентов и договоров не терялся); метаданные можно задать через jq-схему. Качество ответов LLM на ваших данных станет заметно лучше.
Notebooks — новый образ Cloud.ru/Ostris AI Toolkit дает полноценную среду для обучения моделей прямо в браузере: датасеты, конфиги, очередь заданий, логи и терминал — все в одном окне. Не нужно тратить день на настройку окружения.
☁️ Cloud.ru Evolution — публичное облако, построенное на собственных разработках
Evolution Compute — форма создания ВМ больше не дает выбирать ресурсы, которые на самом деле заняты. Теперь вместо ошибки при деплое вы сразу видите альтернативы — нервные клетки сэкономлены. Еще теперь можно массово перезагружать ВМ или удалять диски, что намного удобнее.
Evolution Load Balancer — поддержка Proxy Protocol v2. Бэкенд наконец видит реальный IP клиента, а не адрес балансировщика. Для логирования, аудита и политик безопасности — принципиально важно.
Evolution Managed Kafka — топики в сервисе теперь можно создавать, редактировать и удалять в реальном времени. Казалось бы, мелочь — но именно такого обычно не хватает, когда все горит.
Evolution Managed PostgreSQL — реализовали возможность размещать узлы кластера в разных зонах доступности. Одна зона упала — кластер живет. Для прода — не опция, а база.
Evolution Artifact Registry — в тестовом режиме добавили возможность загрузки PyPI-пакетов в реестр. Храните внутренние Python-библиотеки рядом с остальными артефактами без отдельного репозитория. Потрогайте, возможно, так будет удобнее.
🚀 Три сервиса вышли в Public Preview — попробовать можно бесплатно
API Gateway — публикуйте и защищайте API без самописного шлюза. Workflow Studio — визуальный редактор для DevOps/MLOps-пайплайнов и пайплайнов данных. Managed OpenSearch — управляемые кластеры для поиска и аналитики логов.
Стадия Preview — лучший момент, чтобы оценить новые функции без обязательств.
🏢 Cloud.ru Advanced
Alma Linux 9.4 и Rocky Linux 9.5 в образах для ВМ, Kubernetes 1.34 с healthcheck по HTTPS и поддержкой XGPU, Terraform-провайдер 1.12.17.
📊 Отдельно — для тех, кто выстраивает аналитику для бизнеса
Мы подготовили руководство «10 шаблонов дашбордов для топ-руководителей» — о переходе от интуитивных решений к data-driven управлению. Внутри: шаблоны под роли CEO, CFO, CMO, CTO, CDO с метриками по финансам, маркетингу, продукту и операциям, плюс связка «бизнес-задача → метрики → дашборд → архитектура на Evolution Data Platform». Полезно взять с собой на следующий стратегический разговор с руководством.
разработчикам, которые планируют перейти в руководство,
начинающим тимлидам,
менеджерам, которые хотят систематизировать управленческие практики и усилить навыки работы с командой.
На курсе разбирают:
техническое лидерство и архитектурные решения,
управление командой и развитие сотрудников,
Agile-подходы (Scrum, Kanban),
процессы планирования и релизов,
коммуникацию с бизнесом,
обратную связь и 1-on-1.
Отдельный фокус — практика. Студенты отрабатывают управленческие навыки с наставниками — действующими руководителями разработки, а также обмениваются опытом с другими тимлидами и менеджерами.
Что нового в тарифах:
Расширенный тариф: практические отработки управленческих задач и собеседований.
Максимальный тариф: всё из расширенного тарифа, работа с карьерным консультантом, дополнительный модуль по аргументации для руководителей.
Создатель Sphinx — о 25 годах в инженерии, провале бизнес-модели и жизни внутри Авито
Новый выпуск подкаста AviTalk — разговор с Андреем Аксёновым, автором поискового движка Sphinx и руководителем группы инфраструктуры поиска в Авито.
Sphinx появился в 2001 году — тогда Андрей хотел просто сделать поиск по сайту с текстами песен, а готовых решений не было. Движок оказался лучше того, что было на рынке, и в итоге превратился в один из самых известных open source-проектов российского IT, который лёг в основу поиска Авито.
Но путь от хобби-проекта до инфраструктурного продукта оказался куда менее романтичным, чем принято рассказывать на конференциях.
В выпуске: почему сильная технология сама по себе не бизнес, как Sphinx врос в Авито, что значит 25 лет работать над одним проектом — и какие ошибки Андрей признаёт как руководитель.
Ведёт выпуск Виктор Раев, руководитель разработки юнита Services Base.
Самое быстрое — «хренак-хренак и в продакшн»: о статическом анализе и скорости выхода продукта
Иногда задают вопрос: "Как статический анализ ускорит Time to market?"
Никак. Статический анализатор не ускорит выход продукта/обновления на рынок. С ним будет дороже и медленнее. Причина — неправильный вопрос.
Аналогично можно спрашивать, как этап тестирования ускоряет Time to market? Точно так же — никак. Тестировщикам мало того, что надо деньги платить, так они ещё будут разработчиков багами отвлекать. Намного быстрее просто написать запускающийся код и выложить дистрибутив. Как говорится, "хренак-хренак и в продакшен". Это самый быстрый вариант.
Но про тестирование, в отличии от статического анализа, такой вопрос не задают. Все понимают, что тестирование — важный элемент создания ПО. Видимо, статический анализ — более молодая методология по сравнению с тестированием, и он просто ещё не стал неотъемлемой частью разработки. Хотя видится очевидным, что и то, и другое неразрывно связано с обеспечением необходимого качества создаваемых программных продуктов.
Какой вопрос правильный?
Как статический анализ ускоряет Time to market при выпуске продуктов заданного уровня качества и надёжности?
Другое дело. Если нужно выпустить качественный продукт, то статический анализ может выявить многие ошибки и дефекты безопасности быстрее и дешевле, чем другие методы. Некоторые виды дефектов лучше обнаруживаются статическим анализатором кода, чем юнит-тестами, динамическим анализом, ручным тестирование и так далее.
Впрочем, это свойство и других методик. Есть дефекты, которые наиболее эффективно будут обнаруживать юнит-тесты, поэтому профессиональные разработчики не пытаются выбрать какой-то один подход, а используют сразу несколько. Эти разные меры усиливают друг друга.
Статический анализ применяется на этапе конструирования, то есть написания кода, поэтому позволяет устранить многие ошибки ещё до этапа тестирования. Хотя на анализ предупреждений необходимо тратить время, это окупается сокращением числа дефектов, которые выявляются на других этапах проверки продукта и его эксплуатации. Известно, что чем раньше ошибка найдена, тем дешевле её исправление.
29 мая 2026 года компания «Диасофт» проведет третью партнерскую конференцию DiasoftPartnersDay, посвященную искусственному интеллекту и модернизации корпоративных систем на базе платформы Digital Q.ERP и экосистемы low-code разработки Digital Q.
Фокус деловой программы – применение искусственного интеллекта в развитии ERP-решений, технологические подходы к импортозамещению и новые стандарты ИТ-индустрии, которые трансформируют процессы разработки программных продуктов. Специалисты «Диасофт» продемонстрируют возможности экосистемы Digital Q, в которую технологии ИИ уже интегрированы и используются для повышения эффективности разработки и эксплуатации решений.
К участию приглашаются топ-менеджеры, директора по информационным технологиям компаний различных отраслей экономики, а также ведущие разработчики и ИТ-специалисты, заинтересованные в применении искусственного интеллекта для развития ERP-систем и создания сложных программных продуктов.
Посмотреть программу мероприятия и зарегистрироваться можно по ссылке.
Автоматизация разработки в RStudio с помощью gemini cli
Вновом видео делюсь тем, как у меня сейчас автоматизирован процесс разработки. Речь пойдет про интеграцию RStudio и Gemini CLI. Gemini CLI это аналог Claude Code, но с хорошим бесплатным тарифом, который способен в значительной части покрыть ваши повседневные потребности по разработке и автоматизации, позволяя не переплачивать там, где это не нужно.
В видео продемонстрирую пример решения одной из своих реальных задач, по переводу пакета на новую версию API.
Разбираем, как запустить этот стек в RStudio и использовать для реальных задач.
Что в видео: • Gemini CLI vs Claude Code: Почему я перешел на Gemini и как это экономит бюджет. • Настройка: Установка и получение API ключа. • Интеграция: Подключение CLI к RStudio. • Практика: Рефакторинг и перевод пакета rgoogleads на новую версию Google Ads API. • Паттерны: Как через GEMINI.md заставить модель писать код именно так, как вам нужно. • Расширение возможностей: Работа с MCP серверами.
Один из моих любимых приемов в вайбкодинге — это когда спеку пишет один агент, а проверяет ее другой. Или код написал один, ревью делает второй, а правит иногда третий. Потрясающая синергия.
Но иногда я попадаю в ловушку низкоуровневого общения двух ИИ-агентов на языке, понятном только им. Я же в этот момент начинаю выступать лишь как копипастер.
До середины ночи Claude Code с Codex'ом заставляли меня работать голубиной почтой между ними. При этом Claude Code реально хотел побыстрее это закончить, как автор спеки, не терпящий возражений, а Codex настаивал. Я был терпелив, и Claude сдался.
Сегодня утром история едва не повторилась при ревью кода, который был написан за ночь. Но я успел прервать порочный круг своим авторитетным вмешательством. На что Claude Code написал: «Это retroactive отзыв инструкции, или ты в курсе и просто проверял, что я не лез глубже одной строки?» Иногда они что-то подозревают 😂
Я вспоминаю старшие классы школы. Тогда я увлекался программированием, но дома был только программируемый калькулятор. «Техника — молодежи» публиковала в каждом номере интересные программы, и я их с удовольствием запускал и даже менял.
Как-то раз ТМ опубликовала шахматную программу, и мы с одноклассником решили устроить партию между нашими двумя калькуляторами. В воскресенье я пришел к приятелю в гости, и мы скрестили шпаги. На удивление, игра закончилась быстро. Один из калькуляторов определил стратегию другого, а выбор был небольшой, и разгромил его.
Так что опыт сведения ИИ друг с другом у меня большой, еще со школы. — Ваш ии-шный интриган-провокатор 🙂, Эдуард Ланчев. Мой канал в Telegram — Ланчев PRO ИИ. Заходите, если так удобнее.
Представлен открытый проект "What Models?". Это онлайн-сервис, который показывает локальные модели, которые встанут на ПК без перегрузки ресурсов и будут работать стабильно. Нужно внести данные ПК — GPU, VRAM и RAM, и на выходе получается полный список моделей, включая названием ИИ-проекта, квантование, скорость и контекстное окно.
Интересно наблюдать, как инструмент Антрофиков пиарится поиском уязвимостей. Однако за этим технологическим восторгом мало кто задумывается о вполне прикладных последствиях.
Что произойдет, когда крупные корпорации окончательно масштабируют эту практику? Представьте процесс разработки крупных продуктов от Microsoft или Adobe. Каждый новый кусок кода, отправленный программистом, моментально анализируется специализированной нейросетью. Переполнения буфера, ошибки логики, слабые места в модулях проверки лицензий — всё это вычищается еще до релиза. Машинный интеллект устраняет саму возможность человеческой ошибки в архитектуре приложения.
В конечном итоге эта эра “ИИ-аудита” может привести к тому, что новые версии так любимого в России пиратского софта (того же Photoshop, 3ds Max, Windows) и свежие игры станут физически недоступными для взлома.
Традиционный «кряк» всегда строится на эксплуатации бреши в коде или обходе алгоритмов DRM-защиты. Но если код вылизан машиной до структурного идеала, а защита динамически меняется, хакерские релиз-группы просто упрутся в бетонную стену. Безусловно, пираты тоже вооружатся ИИ-инструментами, но это гонка вычислительных мощностей: у транснациональной корпорации всегда будет больше GPU-кластеров для создания идеальной защиты, чем у энтузиастов для ее пробития. Технологический барьер может оказаться непреодолимым, оставив в прошлом привычку просто скачивать нужный рабочий инструмент или игру с торрента.
Пиратство всегда сдерживало жадность корпораций: если подписка стоила слишком дорого, люди уходили на торренты. Если ИИ сделает программы невзламываемыми, разработчики смогут задирать цены до небес. Без бесплатной альтернативы нам придется платить за нужный софт любые деньги, просто потому что деваться будет некуда.