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

Дальше всё развивается предсказуемо. Раз разобрать поток руками невозможно, на разбор ставят языковую модель — ту же технологию, которая этот поток и создала. AI пишет код, AI ищет в нём уязвимости, AI решает, какие из находок настоящие. И остаётся вопрос: как понять, что модель не ошиблась, если проверять её ответ, вообще-то, тоже некому.

Эту проблематику подробно разбирали на OFFZONE — конференции по практической кибербезопасности, которая прошла в Москве 20–21 августа. Среди тем докладов — применение ИИ для поиска уязвимостей и анализа результатов, автоматизация задач специалистов и новые риски, которые возникают вместе с этими возможностями. Два выступления особенно точно продолжили разговор о том, что происходит, когда в цепочку поиска и проверки уязвимостей всё активнее включается AI. Мы попросили их авторов подробнее прокомментировать эту тему.

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

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

Находок стало больше. Но не только из-за уязвимостей

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

Да, поток находок вырос в несколько раз. Но объяснять это только дырявым машинным кодом неправильно, и Дмитрий сразу это проговаривает:

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

То есть часть роста — это не новая опасность, а новая видимость. Строк стало больше, потому что их стали быстрее писать. Правила сканеров перестроили. Подключили инструменты, которые раньше в эти места не смотрели.

Но команде, которая разбирает эту очередь, от такого объяснения не легче: откуда бы ни взялся рост, вручную столько находок всё равно не обработать. И дело не только в количестве — изменилось ещё и то, как эти находки приходят.

Три механизма, из-за которых дефекты идут пачками

Это, по словам Дмитрия, главное практическое отличие генеративного кода. Раньше уязвимость была разовым событием: кто-то один раз ошибся в одном месте. Теперь ошибка тиражируется.

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

«Агент применяет один шаблон ко всем похожим местам — если шаблон дефектный, дефект тиражируется».

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

Третий механизм Дмитрий Абрамов называет самым коварным:

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

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

Что ушло, что пришло

Набор дефектов заметно изменился. Меньше стало синтаксических ошибок и простых логических багов. Отдельная история — SQL-инъекции: их стало «заметно меньше просто потому, что модель почти всегда тянет ORM». Не из соображений безопасности, а потому что так написано в большинстве примеров, на которых модель училась.

Вместо них выросли пути эскалации привилегий, архитектурные дефекты, SSRF (когда сервер можно заставить сходить по адресу, который выбрал злоумышленник), отсутствие CSRF-защиты и security-заголовков. Плюс, как формулирует Дмитрий, «отсутствие понимания архитектуры приложения» — код, который сам по себе корректен, но не учитывает, как устроена система вокруг.

Причину он называет одну:

«Но все эти ошибки чаще всего проскакивают из-за недостаточности контекста, передаваемого агенту».

Часть проблем лечится буквально этим. Заголовки и CSRF в его команде почти исчезли после того, как добавили то, что они назвали «ИБ-контекстом». Модель не отказывалась делать безопасно — ей просто не сказали, что от неё этого ждут.

А вот ролевая модель и бизнес-логика контекстом не лечатся. Здесь нужны ручные проверки или специфичные автотесты, а значит, снова человеческое время.

Кстати, он поправил саму постановку вопроса про слепые зоны:

«Слепыми называть неправильно, скорее было бы правильно — невнимательные».

Разница есть. Слепая зона — то, чего инструмент не видит в принципе. Невнимательность — то, что исправляется правильно поставленной задачей.

Ошибки не в коде, а в поведении агента

Есть категория проблем, которая не попадёт ни в один SAST, потому что это вообще не про код.

«Лишний вызов инструмента, преждевременное завершение задачи, „починил“ тест вместо кода, сфабрикованный отчёт о прогоне — как у Replit. Это не свойство кода, это свойство процесса, и статические анализаторы к нему не приспособлены по определению».

Эта мысль пригодится дальше. Модель, которая уверенно рапортует об успехе, — проблема не только на стороне написания кода, но и на стороне его проверки.

Разбирать некому. Ставим на разбор модель

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

Напрашивается очевидное: спросить у модели, настоящая это уязвимость или ложное срабатывание. Спросить действительно можно.

«Спросить можно, и ответ придёт мгновенно — складный, развёрнутый, уверенный».

У него в докладе есть слайд, который так и называется: «Складно ≠ доказано».

Почему прямой вопрос не работает

Причин три.

Уверенность модели ничего не значит. Модель на семь миллиардов параметров — класс «умной автодополнялки» — на прямой вопрос подтверждает почти половину сработок и выдаёт целые серии с уверенностью 1.0.

«Само-оценка модели без внешней калибровки театральна, опираться на неё нельзя».

Формулировка вопроса определяет ответ. Куда модель натаскали при обучении, туда она и копает. Универсальная рамка «найди источник и сток» — то есть место, где данные попадают в приложение, и место, где они используются в опасной операции, — хорошо работает на цепочечных дефектах. И не работает там, где никакой цепочки нет: захардкоженный пароль или слабый алгоритм шифрования видно по одной строке.

«Универсальная рамка „найди источник и сток“ на дефектах-„свойствах“ хоронит реальное: на одном моём замере неудачная постановка вопроса похоронила 140 реальных сработок из 363».

У прямого вопроса нет метрик. Без размеченного эталона — набора сработок, по которым заранее известны правильные ответы, — неизвестно ни какая доля подтверждений оказалась правдой, ни какую долю реальных дефектов модель вообще поймала. Остаётся верить ей на слово.

Здесь стоит остановиться. У Дмитрия дефект проскакивает, потому что агенту недодали контекста. У Юрия модель хоронит реальную сработку, потому что ей задали не тот вопрос и не показали нужный кусок кода. В обоих случаях дело не в модели.

Модель предполагает, правила решают

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

Второе — сработки разделены на два сорта, и доказываются они по-разному.

Уязвимость-свойство. Опасен сам факт в коде: пароль в исходниках, слабый хеш, слишком открытые права. Вопрос ровно один — настоящий секрет или заглушка. Никакого пути данных здесь нет и быть не должно. Таких сработок в потоке подавляющее большинство, около 93%.

Для них выстроена лестница проверок, и модель на ней — лишь одна из ступеней. Сначала работает алгоритмика без всякой LLM: ключ в формате боевого AWS — сразу подтверждаем, файл сгенерированный или из SBOM — сразу ложное срабатывание. Это снимает больше половины шума и не стоит ни одного обращения к модели. Дальше вопрос уходит модели, но задаётся по сути факта. Потом больше сотни детерминированных правил проверяют её ответ и могут вердикт поправить. Потом пороги по классам: слабый ответ превращается в Unknown. Последняя ступень — человек. Отдельным правилом запрещена сама формулировка «не вижу пути атаки» как причина закрытия: именно на ней система и теряла те самые 140 сработок из 363.

Уязвимость-путь. Здесь опасен маршрут данных: SQL-инъекция, XSS, обход каталогов. Вопрос другой — дошли ли данные атакующего до опасного вызова и была ли по дороге защита. Вот для этого типа и сделан evidence gate.

Evidence gate: перечисли факты — вердикт выведется сам

Идея в том, чтобы не спрашивать у модели вердикт вообще. Сначала она обязана заполнить таблицу фактов по жёсткой схеме: найти настоящий sink — строку, где реально выполняется опасный вызов (сканер её часто теряет); перечислить каждую переменную запроса — откуда пришла, какой строкой, была ли по дороге защита; выписать список незащищённых переменных.

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

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

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

«Придумать вывод легко, придумать проверяемую улику сложно. <…> Фактам — да, поэзии — ни-ни».

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

И снова всё упирается в контекст. Чаще всего система отвечает «недостаточно данных» по одной причине: трасса слишком короткая. Модель видит место, где переменная попадает в опасный вызов, но не видит, откуда эта переменная пришла и проверяли ли её по дороге. Лечится это не увеличением окна и не моделью побольше, а доставкой недостающего кода. Юрий пробовал 72B через внутренний портал и получил обратный результат:

«Дисциплина важнее размера».

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

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

Почему локально

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

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

«Облачная модель обновляется без спроса, и вчерашний замер сегодня уже ни о чём».

Со стоимостью тоже всё сходится: одна игровая RTX 4080 разбирает около восьми тысяч сработок в сутки за электричество.

История про токен

Самая показательная часть доклада— не про метрики.

«Боевой GitLab-токен, модель с уверенностью 1.0 обозвала его „placeholder in test configuration“ — заглушкой в тестовом конфиге, — поверила пути файла и похоронила. Реальный секрет, закрытый автоматом».

Доверие команды после такого падает мгновенно:

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

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

«Доверие к автомату устроено как доверие к коллеге: ошибаться можно, прятать ошибки нельзя. Система, которая сама показывает промахи и после каждого меняется, доверие возвращает. Система, которая уверенно бормочет „всё хорошо“, теряет его навсегда».

Где проходит граница

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

Дмитрий Абрамов:

«У меня довольно чёткая граница, и она проходит не по сложности задачи, а по обратимости последствий и по возможности проверить результат. Не стал бы автоматизировать применение фиксов без человека. Черновик патча — отлично, автомерж в прод — нет, особенно в авторизации и криптографии».

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

Юрий Туманов отвечает про свою часть работы, но приходит к тому же. Автомат работает там, где улика видна прямо по артефакту, а полноту можно проверить канарейками. Цепочечные классы — SQL-инъекции, XSS, path traversal, всё, где нужно доказать путь данных через приложение, — идут к человеку: именно там небольшие модели выдают уверенные галлюцинации, а уверенный неверный вердикт обходится дороже, чем честный ответ «недостаточно данных». Необратимые действия без человека — ротация и отзыв секретов, блокировки, автопатчи с автомержем — тоже нет. И отдельно:

«Выбор допустимого риска и разметка эталона — решение людей с числами на столе. Эталон размечают люди: отдай его модели — и система начнёт сверяться сама с собой, по кругу».

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

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

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

Для разработчика это значит, что самая нудная часть жизни PR, когда код уже написан, а CI красный и ревьюер оставил пятнадцать комментариев, теперь может быть делегирована. Обновление раскатывается постепенно; кто не хочет ждать, запускает команду Check for Updates. Сборки есть для Windows, macOS и Linux (deb, rpm, tarball, Snap), отдельных условий для России на странице релиза нет.

• Agent Merge (Preview) включается настройкой chat.agentMerge.enabled и запускается из окна Agents; агент повторяет цикл исправления и перезапуска workflow до готовности PR.
• Multi-root workspace для агентов в статусе Experimental: chat.agentHost.copilotAgent.multiRootEnabled и chat.agentHost.claudeAgent.multiRootEnabled; хуки агента по-прежнему привязаны к одной папке.
• Agent Host работает отдельным процессом и может обслуживать несколько окон; протокол Agent Host Protocol опубликован отдельно.
• Связанные чаты показываются деревом внутри сессии со статусами и ожидающими подтверждениями; появились уведомления, когда агенту нужен ввод или он закончил.
• Из мелкого: терминальные расширения больше не получают задержку запуска до 5 секунд, режим Compact layout уменьшает отступы между панелями.

Как работает Agent Merge и чего он пока не обещает

По описанию Microsoft, Agent Merge «помогает довести pull request до финишной черты» (перевод редакции), то есть до состояния, когда его можно сливать. Пользователь указывает PR, агент читает review feedback, смотрит на failed checks и merge conflicts и правит код, после чего снова запускает workflow. Цикл повторяется, пока проверки не пройдут и замечания не будут закрыты. Функция в Preview, поэтому Microsoft не гарантирует ни стабильность, ни то, что агент справится с любым конфликтом; сколько итераций он делает и как считаются затраты на модель, в заметках к релизу не сказано.

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

Что даёт агентам multi-root workspace

Раньше агент видел только одну корневую папку. В 1.136 для Copilot и Claude можно включить работу со всеми корнями workspace; это экспериментальная функция за двумя отдельными настройками. Ссылки на рабочие пространства разрешаются по имени проекта, абсолютному пути и URI, а при совпадении имён VS Code показывает варианты и не выбирает молча. Ограничение осталось одно, зато важное: хуки агента (agent hooks) по-прежнему работают в пределах одной папки.

Под капотом это стало возможным благодаря Agent Host, отдельному процессу, который теперь умеет обслуживать несколько окон редактора. Протокол взаимодействия с ним, Agent Host Protocol, Microsoft опубликовала отдельно; вместе с Copilot SDK это заявка на то, чтобы сторонние агенты подключались к VS Code по одной схеме.

Остальные изменения релиза

• Дерево сессий: заголовки, статусы и ожидающие approvals; чаты можно раскрывать, переименовывать, переносить и удалять.
• Уведомления о том, что агенту нужен ввод или он закончил работу; по умолчанию только для сессий не в фокусе.
• Корпоративные политики могут включить распознавание речи на устройстве и запретить очистку диктовки языковой моделью.
• Compact layout уменьшает интервалы между панелями.
• Запуск терминальных расширений больше не получает искусственную задержку до 5 секунд.

Стоит ли включать прямо сейчас

Agent Merge имеет смысл пробовать на репозиториях, где CI быстрый и есть чёткие правила ревью: там цикл агента даст видимый результат. На проектах с медленными пайплайнами каждая итерация будет стоить минут ожидания и токенов, а сколько именно, Microsoft не раскрывает. Multi-root режим полезен монорепозиториям, но пока экспериментален, и хуки в нём не работают за пределами одной папки.

Кому обновление ничего не изменит: тем, кто не пользуется агентским чатом, и командам без подписки на Copilot. Для них в 1.136 остаются Compact layout, ускорение запуска терминальных расширений и мелкие изменения редактора, терминала и доступности. Полные заметки к релизу со скриншотами лежат на сайте VS Code; подробности про approve от Copilot и его учёт в правилах веток мы разбирали отдельно.

Источники: VS Code: August 2026 (version 1.136) release notes, Релиз 1.136.0 на GitHub

Изображение на обложке: Microsoft, логотип Visual Studio Code

Для обычного пользователя PyCharm без плагина Cadence новость ничего не меняет. Для тех, кто подключал сервис, JetBrains даёт жёсткую рекомендацию: все учётные данные, к которым Cadence имел доступ, считать скомпрометированными и заменить, включая ключи облаков, токены GitHub и GitLab, SSH-ключи и ключи подписи. Региональной разбивки пострадавших компания не даёт; если сервис у вас был подключён, рекомендации те же.

• Период доступа атакующих: 8–24 августа 2026 года; JetBrains заметила эксплуатацию 23 августа и отключила сервер 24-го.
• Вектор: CVE-2026-63077 в TeamCity, который оркестрировал облачные задачи Cadence; патч на сервер не поставили.
• Утекли имена пользователей, реальные имена, email, время последнего входа и IP; полный бэкап сервера Cadence за 2024 год; AWS IAM-пользователи и их учётные данные; файлы в S3-бакетах JetBrains.
• Мог быть доступен исходный код, синхронизированный из PyCharm; затронуты ли бакеты клиентов, компания не установила.
• Токены плагина Cadence в PyCharm аннулированы; JetBrains просит заменить все секреты, доступные сервису, и проверить репозитории, облака, реестры пакетов и системы деплоя.

Что такое Cadence и при чём тут TeamCity

Cadence — облачный сервис JetBrains, который через необязательный плагин PyCharm позволяет отправлять тяжёлые вычисления, например обучение моделей, на удалённые машины. Чтобы запускать эти задачи, сервис использовал TeamCity, собственный CI-сервер JetBrains, как оркестратор облачных нагрузок. Именно в этой инсталляции TeamCity была уязвимость CVE-2026-63077, позволяющая удалённо выполнять команды без входа. Компания признаёт, что для этого сервера действовало то же правило, что и для остальных: патчить сразу после выхода исправления. Правило не сработало.

The server should have been patched, but it was not.

Хронология

• 8 августа: атакующие воспользовались уязвимостью TeamCity и получили доступ к серверу api.cadence.jetbrains.com.
• 8–24 августа: период активности; в это время были доступны данные пользователей, бэкап, учётные данные AWS и файлы в S3.
• 23 августа: JetBrains обнаружила эксплуатацию.
• 24 августа: сервер отключён, токены плагина Cadence в PyCharm аннулированы.
• 31 августа: первое обновление отчёта с перечнем затронутых данных.
• 1 сентября, 12:05 CEST: второе обновление; расследование ещё включает несколько проверок.

Что именно утекло

Компания перечисляет четыре категории. Первая — персональные данные пользователей Cadence: логины, реальные имена, адреса почты, время последнего входа и IP-адрес, с которого он был. Вторая, самая неприятная, — полная резервная копия сервера Cadence за 2024 год: JetBrains подтвердила, что атакующие получили доступ к её содержимому, а в нём могло быть всё, что сервис хранил на тот момент. Третья — AWS IAM-пользователи с учётными данными, то есть доступ к части облачной инфраструктуры JetBrains. Четвёртая — файлы в S3-бакетах компании; проверить, были ли затронуты бакеты клиентов, JetBrains на момент публикации не смогла.

We have confirmed that the threat actors accessed data contained in the Cadence server backup from 2024.

Отдельно компания допускает, что атакующим мог быть доступен исходный код, который пользователи синхронизировали из PyCharm в Cadence для запуска задач. Доказательств извлечения секретов из текущего окружения сервиса, по словам JetBrains, не найдено. Между «не найдено доказательств» и «не было» большая разница, и компания сама рекомендует исходить из худшего: список секретов, которые нужно считать скомпрометированными, включает облачные учётные данные, токены GitHub, GitLab и Bitbucket, учётные данные реестров пакетов и контейнеров, SSH-ключи и ключи подписи.

Что сделать, если вы пользовались Cadence

• Проверьте в PyCharm, стоял ли плагин Cadence; его токены JetBrains уже аннулировала, но это закрывает только вход в сервис.
• Замените всё, что было доступно из задач Cadence: ключи AWS, Google Cloud и Azure и любых других облаков, токены GitHub, GitLab и Bitbucket, учётные данные реестров пакетов и контейнеров, SSH-ключи, ключи подписи.
• Пересмотрите репозитории, которые синхронизировались в сервис, на предмет секретов в коде и истории коммитов: они могли уйти вместе с исходниками.
• Проверьте журналы облачных аккаунтов за 8–24 августа на действия от имени сервисных пользователей, которыми пользовался Cadence; JetBrains отдельно называет AWS и S3, IAM, реестры пакетов и системы деплоя.
• Если в 2024 году вы пользовались Cadence, а потом ушли, ваши данные могли находиться в бэкапе за 2024 год; состав пользователей в нём компания не раскрыла.
• Ждите финальный отчёт: расследование не закончено, и список затронутых данных может расшириться.

Урок для всех остальных

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

Источник: Cadence security incident, August 2026 (JetBrains)

Изображение на обложке: JetBrains

Quail 4 — финальный стабильный выпуск линейки Quail, и автор анонса, менеджер продукта Android Studio Амман Фасил Асфав, называет её «готовой к использованию в продакшене». Помимо локальной модели в IDE вошли 23 готовых «навыка» агента под типовые задачи Android, кликабельные ссылки на классы и методы в ответах, индикаторы состояния в списке чатов и сворачиваемый показ рассуждений модели.

• Android Studio 2026.1.4 (Quail 4) стабильна; это последний выпуск линейки Quail.
• Gemma 4 работает локально через встроенный движок инференса; код не покидает машину, лимитов на токены нет.
• Минимум 12 ГБ оперативной памяти для самых маленьких моделей; по словам Google, «машины с 32 ГБ и больше будут работать лучше всего».
• 23 встроенных навыка агента (AGP 9 Upgrade, Android Profiler, Navigation 3, Adaptive и другие) выбираются автоматически по запросу и отключаются одним переключателем.
• Локальный режим включается в Agent model selector или в Settings, Tools, AI, Model Providers, Gemma; веса IDE скачивает, проверяет и обновляет сама.

Как устроена локальная модель

Android Studio сама скачивает веса Gemma 4, проверяет их и обновляет. Внутри IDE работает лёгкий движок инференса, поэтому отдельный сервер вроде Ollama поднимать не нужно. Модель выбирается в переключателе Agent model selector или в настройках: Settings, Tools, AI, Model Providers, Gemma. После этого агент работает локально: анонс подтверждает многофайловые рефакторинги полностью офлайн; остальные сценарии облачного агента Google для локального режима отдельно не перечисляет. Google подчёркивает два свойства: исходный код не покидает локальную машину, и квоты на токены не действуют.

Your source code never leaves your local machine and you never hit token quota limits.

Требования к железу компания называет прямо: самые маленькие варианты Gemma 4 стартуют на 12 ГБ оперативной памяти, а лучше всего работают машины с 32 ГБ и больше. На ноутбуке с 16 ГБ, где рядом крутятся эмулятор и Gradle, стоит ожидать, что локальная модель окажется медленнее и заметно проще облачной. Это цена за приватность и отсутствие квот, и оценивать её нужно под свой проект: по нашему опыту, многофайловый рефакторинг на маленькой модели требует больше ручных проверок, чем на облачной.

Что такое навыки агента

«Навык» здесь — заранее написанная инструкция с контекстом под конкретную задачу Android: как обновить проект на Android Gradle Plugin 9, как читать данные профилировщика, как переехать на Navigation 3 или сделать адаптивную вёрстку под планшеты и складные устройства. В Quail 4 таких навыков 23, и IDE подбирает их по метаданным запроса сама. Если подбор мешает, навыки отключаются общим переключателем в настройках IDE.

Что ещё изменилось в интерфейсе агента

• Ссылки на классы, функции, методы и пути файлов в ответах агента стали кликабельными.
• В списке Recent Chats появились индикаторы: загрузка, ожидание ввода, завершение фоновой задачи.
• Вкладки Task и Walkthrough объединены во вкладку Summary of Changes; по ней стоит проверять правки перед применением.
• Рассуждения моделей с режимом reasoning показываются сворачиваемым блоком.

Что менять в проекте и процессе

• Обновите Android Studio до 2026.1.4 через Check for Updates; проект менять не нужно.
• Если в компании запрещено отправлять код во внешние сервисы, включите Gemma в Model Providers и убедитесь, что облачный провайдер в настройках не выбран.
• Проверьте память: 12 ГБ — заявленный минимум для самых маленьких моделей, 32 ГБ и больше — рекомендация Google; на 16 ГБ закройте эмулятор перед работой агента или пользуйтесь физическим устройством.
• Для миграции на AGP 9 попробуйте одноимённый навык: это задача с сотней мелких правок, где агент экономит время.
• Региональных оговорок в анонсе нет, но доступность загрузки весов из России Google не подтверждает; проверяйте на своей машине. Локальный режим не требует подписки на облачные модели.

Контекст

Линейка Quail шла к этому весь цикл: в Quail 2 появились параллельные чаты с агентом, затем навыки, интеграция с Firebase и первая поддержка локальных моделей в Canary-сборках. Quail 4 закрывает линейку и делает локальный режим штатным в стабильной версии. Следующая линейка Android Studio получит новое кодовое имя; сохранится ли в ней локальная Gemma как основной сценарий, Google не говорит, и это предположение редакции по тону анонса.

Источники: Leverage Android skills and Gemma 4 in Android Studio Quail 4 (Android Developers Blog), Android Studio release notes

Изображение на обложке: Google, Android Developers Blog

Арендовать мощные VPS под ресурсоемкие задачи в текущих реалиях выходит неоправданно дорого. При этом дома у меня уже был выделенный неттоп (мини-ПК) с 16 ГБ оперативной памяти на базе энергоэффективного процессора Intel N95.

Пройдя путь от простых Bash-скриптов и сторонних туннелей до полностью автоматизированной инфраструктуры, я создал проект ServeHub-2. В этой статье я подробно разберу, как эволюционировала сеть проекта, почему декларативный подход победил императивный и с какими неочевидными багами пришлось столкнуться в процессе автоматизации.

История настройки сетевой архитектуры

Использование Tuna

В самом начале проекта я еще не думал о VPN как о способе пробития NAT и основе, на которой будет строиться вся система. Первое, к чему я пришел — сервис Tuna. Если кратко, это аналог Cloudflare Tunnel за условные 300 рублей. У него очень приятный веб-интерфейс и невероятно простая настройка. Однако для полноценной независимой архитектуры он не подошел по двум причинам:

• Сервера Tuna находятся вне контроля пользователя.
• На удаленном сервере нельзя развернуть свои сопутствующие сервисы.

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

Вот пример конфига для tuna (все максимально просто, создаем контейнеры для ssh туннеля, чтобы был доступ ssh, а также основной http туннель с привязкой к nginx или любому другому прокси если такой есть):

В поисках гибкости: тесты Pangolin и переход к FRP

После Tuna я решил двигаться в сторону собственного контроля и попробовал Pangolin. Однако решение быстро отвалилось: для дешёвого сервера оно оказалось слишком «тяжёлым» и избыточным. Главные минусы — ощутимый оверхед по ресурсам и лишний слой принудительной веб-аутентификации перед самими сервисами. Это ломало нормальное взаимодействие с родными мобильными клиентами (вроде Element для Matrix или Bitwarden для паролей), где повторная авторизация в браузере просто не нужна.

На смену пришел FRP (Fast Reverse Proxy). Он выполнял ту же функцию проброса, но хостил я его уже на собственном арендованном VPS в режиме Layer 4 (TCP). Это дало абсолютную гибкость: внешний VPS не заглядывал внутрь пакетов и ничего не расшифровывал, а просто пересылал сырой поток домой. Кроме того, это отлично оптимизировало расходы: вместо 300 рублей за Tuna и ещё 300 рублей за отдельный VPN, я стал платить всего 500 рублей за один стойкий VPS, который мог настраивать как хочу. (к тому же можно было обойтись даже дешевле, так как VPS с 4 гб оперативки загружен всего лишь на 40%, процессор всего на 20%-40%)

FRP состоит из 2 конфигурационных файлов (один на удаленном сервере frp server, другой на локальном frp client), все также довольно просто, однако его можно использовать на разных слоях. У меня он брал трафик за стандартный TCP и передавал его на локальный сервер.

Также доп. фишка в том что основная конфигурация происходит именно в frpc, который, в свою очередь, передает часть настроек на frp на удаленном сервере.

frpc.toml:

frps.toml:

Полноценный переезд на WireGuard (AmneziaWG) и 8 часов отладки

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

• Безопасность: FRP всё же открывал внутренние ресурсы в публичный интернет, оставляя их доступными для сканеров портов.
• Удобство маршрутизации: Все участники сети стали равноправными узлами в одной виртуальной локальной подсети. Больше не нужно было настраивать постоянные односторонние пробросы.
• Дополнительный бонус: Поскольку удаленный VPS был куплен в Нидерландах, через этот же VPN я автоматически получил безопасный доступ ко всем зарубежным ресурсам.

Для реализации схемы на удаленном VPS был развернут контейнер wg-easy с поддержкой AmneziaWG, а на домашнем мини-ПК — клиентский контейнер Amnezia (сборка из Dockerfile с использованием amnezia-tools и модулем ядра хоста).

И именно здесь я поймал самый изнурительный баг проекта. После развертывания трафик упорно шёл только в одну сторону. Часов 8 ушло на диагностику iptables, маршрутов и чтение зарубежных форумов (что бесполезно, учитывая специфику наших блокировок). Оказалось, провайдер просто дропал обратный трафик стандартного WireGuard, так как пакеты шли без маскировки. Причина крылась в docker-compose.yml: у меня было прописано image: ghcr.io/wg-easy/wg-easy:latest. Как выяснилось, тег latest на Docker Hub намертво прилип к старой 14-й версии, а поддержка параметров AmneziaWG появилась только в ветке 15.x. Изменение тега на конкретную версию (15.3) решило проблему за секунду.

Благодаря переходу конфигурация получилась максимально простой, основные отличия от стандартной документации выделил в коде: (в основном то, на что пришлось долго рыть информацию)

Настройка Nginx

Чтобы сервисы были доступны исключительно внутри подсети VPN, я задействовал Nginx. Доступ к приложениям был жестко ограничен на уровне конфигурации — веб-сервер принимает запросы только из диапазона IP-адресов 10.8.0.0/24. Любые попытки постучаться на сервер из внешнего интернета без активного VPN-туннеля автоматически сбрасываются Nginx.

Логика распределения завязана на proxy-протоколе: Nginx на удаленном VPS выступает основным входным узлом, принимает зашифрованный трафик, заворачивает его в заголовки с реальным IP-адресом клиента и через туннель перекидывает на локальный Nginx домашнего сервера. Локальный веб-сервер уже сам расшифровывает SSL и распределяет трафик по конечным Docker-контейнерам, сохраняя реальные IP в логах безопасности.

Вставлю один кусок кода из nginx на удаленной машине для примера, так все остальное примерно похоже (конфиги использовались в виде .template):

SSL-сертификаты

Для получения валидных SSL-сертификатов я настроил работу через автоматический Certbot по challenge-валидации DNS-01 c API Webnames. Сам домен привязан к внутреннему IP-адресу 10.8.0.1. Проверка через DNS позволила выпустить единый wildcard-сертификат на весь домен и его поддомены без необходимости держать открытым 80-й порт веб-сервера наружу.

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

В итоге получилась схема, при которой все сервисы доступны по красивым доменным именам с HTTPS, но абсолютно невидимы для внешнего интернета.

Вот настройка certbot:

История софта

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

Первый стек и оптимизация

Первыми на домашнем сервере прижились медиа-сервисы: Navidrome для стриминга музыки и Audiobookshelf для аудиокниг и подкастов. Они легковесные, имеют отличные мобильные клиенты с синхронизацией прогресса и полностью закрывают мои потребности. Позже к ним добавился Nextcloud как единое независимое облако для файлов, контактов и семейных документов.

Затем встал вопрос безопасного хранения паролей. Сначала я смотрел в сторону оригинального Bitwarden, но в итоге я выбрал Vaultwarden — альтернативный сервер на Rust, полностью совместимый с API Bitwarden. Он потребляет считанные мегабайты оперативной памяти и работает идеально. Дополнительно для удобства управления всей этой распределенной Docker-инфраструктурой в локальный стек был добавлен Portainer. (+ Portainer Agent на удаленный сервер)

Из интересных моментов, где мне пришлось немного больше возиться, чем с остальными сервисами это nextcloud настройка:

Ошибки проектирования: почему я удалил Matrix (Synapse)

Не все решения прошли проверку временем. На этапе использования Tuna и FRP я развернул сервер Matrix (Synapse) для защищенного обмена сообщениями. Мне казалось это крутой идеей, но когда я окончательно перешел на AmneziaWG, целесообразность мессенджера внутри закрытого туннеля сошла на нет.

Synapse требовал слишком много ресурсов, впустую расходовал оперативку домашнего ПК и усложнял конфиг Nginx. При этом реальной пользы для семьи он не приносил. Для критических алертов инфраструктуры и повседневного общения проще и эффективнее оказалось использовать Telegram. (плюс алертинг настроен именно через него) В итоге я полностью выпилил Synapse из стека, освободив ресурсы.

Вместо него я добавил в связку к wg-easy локальный AdGuard Home. Теперь он работает прямо внутри VPN-сети: очищает весь трафик от рекламы и трекеров на лету, кэширует DNS-запросы и не дает истории веб-серфинга улетать внешним провайдерам.

Основной проблемой с которой я столкнулся при использовании AdGuard Home, так это то что я так и не понял как заставить использовать AmneziaVPN клиент AdGuard как основной DNS, при этом AmneziaWG работает прекрасно. Как я понимаю дело в том что AmneziaWG работает намного проще на уровне ip и у него нету никаких доп фильтров, настроек и подобного, поэтому он просто берет данные из конфига.

От костылей на Bash к декларативному Ansible

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

Так я пришел к декларативному подходу и Ansible. Теперь вся конфигурация описывается в виде плейбуков и ролей, отражающих конечное желаемое состояние серверов. Конфиденциальные данные перенесены в файл secrets.yml, а хрупкие конструкции автоматизированы через шаблоны Jinja2. Проект стал идемпотентным: если шаги уже выполнены, Ansible их просто пропускает.

В итоге получилось несколько yaml файлов для стандартной настройки системы (bootstrap_os.yml) и для настройки каждого из хостов (setup_local.yml и setup_remote.yml). В итоге теперь все что нужно чтобы полностью с нуля развернуть проект - скачать Ansible, несколько других зависимостей на свой рабочий пк и запустить один manage_deploy.sh, в котором можно будет выбрать сценарий как будет вести себя Ansible и спокойно дождаться разворачивания сервисов.

Также благодаря Ansible я удобно реализовал переносимость проекта. Так как я решил не использовать тома docker, и вместо этого храню все в папках, чтобы перенести старые данные проекта нужно просто скопировать папку apps-data и положить ее в нужное место и все само заработает после повторного развертывания проекта. В Ansible выделяется отдельная пауза для этого.

Вот пример основного плейбука deploy.yml:

Тестирование мультидистрибутивности с помощью Vagrant

Проект изначально затачивался под работу на трех дистрибутивах: Ubuntu, Debian и Arch Linux. Тестировать Ansible-плейбуки прямо на рабочей локальной машине (в моем случае — EndeavourOS) слишком рискованно, а создавать виртуальные машины руками — долго и неудобно.

Решением стал Vagrant, позволяющий за пару минут развернуть чистые ОС в VirtualBox из готовых образов. Но в процессе настройки мультивендорного стенда в режиме сетевого моста (public_network) всплыли две критические проблемы:

1. Конфликт DNS: По умолчанию Vagrant создает NAT-интерфейс для управления нодой. При включении второго (публичного) интерфейса для локальной сети ломался дефолтный DNS-резолвер. Проблему пришлось решать принудительной очисткой и перезаписью файла /etc/resolv.conf через inline-скрипт автоматизации Vagrant.
2. Проблема с GRUB на Debian: В используемом базовом образе generic/debian12 конфигурация GRUB сохраняла жесткую привязку к конкретному имени диска из окружения сборщика. При повторном развертывании плейбуков на тестовом стенде это приводило к сбоям загрузчика. Чтобы автоматизировать очистку, пришлось внедрить скрипт, который на лету определяет имя системного диска через lsblk и автоматически передает правильные параметры в загрузчик через утилиту debconf-set-selections.

Вот код Vagrantfile: (в node.vm.provision происходит основное решение ошибок)

Надежная система бэкапов на базе BorgmaticДля создания резервных копий я внедрил Borgmatic (удобную надстройку над дедуплицирующим инструментом Borg Backup). Весь процесс автоматизирован с помощью связки системных юнитов borgmatic.service и borgmatic.timer. В бэкап уходят две ключевые директории: apps-data (конфигурации приложений и баз данных) и PersonalData (медиатека: музыка, книги, подкасты, файлы Nextcloud).

Развертывание системы бэкапов полностью берет на себя Ansible. Мне достаточно указать UUID внешнего жесткого диска — скрипт сам проверит его наличие в системе, примонтирует в нужную директорию, создаст зашифрованный репозиторий и настроит политику ротации (хранение 7 ежедневных, 4 еженедельных и 6 ежемесячных копий). Также в Prometheus выведен мониторинг самого репозитория .borg для отслеживания его размера и статуса успешности архивации.

Главная проблема при бэкапе работающих Docker-контейнеров — риск скопировать базу данных в «битом» или неконсистентном состоянии, если в момент создания архива в нее шла активная запись. Чтобы решить эту проблему, я задействовал механизм хуков в конфигурации Borgmatic.

Перед началом резервного копирования автоматически срабатывает команда остановки контейнеров проекта (docker-compose down), а после успешного завершения (или в случае возникновения непредвиденной ошибки) контейнеры автоматически поднимаются обратно в фоновом режиме. Для удобного просмотра архивов и быстрого восстановления файлов я развернул веб-интерфейс Borg UI.

Конфигурация borgmatic: (использую как Jinja2 шаблон, чтобы Ansible в плейбуках сам подставил переменные)

Наблюдаемость (Observability) уровня Enterprise

В последних релизах (v1.2.0 и v1.3.0) фокус проекта сместился на мониторинг и работу с логами.

Эволюция алертинга и переход на Gatus

Изначально для мониторинга доступности я смотрел на Uptime Kuma, но отказался из-за отсутствия удобной декларативной настройки через конфиги. Затем я развернул связку Blackbox Exporter и Alertmanager с уведомлениями в Matrix. Но тут крылась логическая несостыковка: весь алертинг был завязан на локальном ПК, и в случае его аппаратного отказа я бы просто лишился уведомлений.

Тогда я решил вернуть Uptime Kuma, но развернуть его на удаленном VPS в качестве внешнего «сторожа» и автоматизировать его настройку через Python-скрипт с библиотекой uptime-kuma-api. Но и тут ждали «грабли» — библиотека не обновлялась три года и намертво ломалась на свежих версиях Kuma.

В итоге идеальным решением стал Gatus. Он изначально проектировался под управление через YAML-конфиги и поддерживает отправку алертов, если сервер не отвечает. Из-за специфики фронтенда Gatus (он не умеет работать из подкаталога типа /gatus), мне пришлось перенести его и wg-easy на полноценные субдомены gatus. и wireguard.

Для Gatus получился простой конфиг:

Для мониторинга аппаратных ресурсов удаленного и локального серверов была развернута связка node-exporter + cAdvisor. Все уведомления теперь приходят мгновенно в Telegram-бота. Чтобы избежать лавины одинаковых сообщений (например, при перезагрузке хоста), в Alertmanager настроена жесткая группировка и дедупликация событий. Также добавлен экспортер для AdGuard Home, выводящий статистику заблокированных запросов в Grafana.

Централизованные логи: Loki + Grafana Alloy

В релизе v1.3.0 в стек была добавлена централизованная система сбора логов Loki. Вместо устаревшего Promtail в качестве агента сбора я применил Grafana Alloy.

Он эффективно собирает логи со всех запущенных Docker-контейнеров, парсит их и передает в Loki. Теперь вся история событий, ошибок веб-сервера Nginx или падений внутренних приложений доступна в едином интерфейсе Grafana с возможностью удобной фильтрации через LogQL, что значительно упрощает отладку.

Конфиг Loki:

Конфиг Grafana Alloy: (локальный конфиг)

Интерфейс: переход на Homepage

Изначально для домашней страницы я написал кастомную минималистичную HTML-панель с Glassmorphism-дизайном. Выглядело это красиво, но добавлять новые сервисы вручную через постоянную правку исходного кода было крайне неудобно.

В итоге я заменил самописную страницу на полноценный комьюнити-проект Homepage. Это дало некоторую гибкость: вся панель настраивается через простые YAML-файлы и поддерживает встроенные виджеты интеграции. Пока что она простенькая, но возможно в будущем сделаю что-то более продвинутое.

Заключение

Постарался подробно рассказать о структуре проекта и как я к этому пришел, очень много я не добавил, если пост зайдет, то я обязательно более подробно пройдусь по некоторым моментам: как я настраивал Matrix и на каком моменте я решил его убрать, как собирал локальный amnezia контейнер-клиент, что нового я добавил в релизе 1.4.0 и другое.

Также я перешел с manage_deploy.sh на отдельный GUI клиент, который будет полностью автоматизировать процесс подготовки к deploy. (написан на Go Wails). Про это тоже возможно сделаю статью.

Вся кодовая база проекта, подробная документация, инструкции по развертыванию открыты и доступны для сообщества:

🔗 GitHub-репозиторий: https://github.com/canntstand/ServeHub-2

Это моя первая статья на этом сайте и в то же время первый личный проект, которому я отдал так много времени (3 месяца). Буду рад вашему фидбеку в комментариях!

С практической точки зрения проект на**й не нужен. Есть GitHub, GitLab и куча нормальных инструментов. Но как эксперимент — почему бы и нет? Чисто посмотреть, можно ли заставить Telegram работать как VCS.

Почему не JSON

На старте я думал: «Положу всё в JSON, на кой мне база данных?» Проектов мало, пользователей немного, файлы текстовые — чего заморачиваться?

Подергал JSON туда-сюда пару дней и понял: не варик.

1. Конкурентный доступ. Два юзера одновременно коммитят — один перезаписывает файл другого.
2. Целостность данных. Если бот упал в середине записи — JSON остаётся в невалидном состоянии.
3. Версионность. Хранить историю изменений в JSON — это просто перенести проблему из кода в структуру файла.

Вывод: JSON — для конфигов, а не для данных, которые меняются каждую секунду.

Выбор SQLite и схема БД

Выбрал SQLite, потому что:

• Не надо поднимать отдельный сервер
• Целостность данных на уровне движка (транзакции, foreign keys, rollback)
• Всё в одном файле — скопировал и унёс

Сущности:

• users — telegram_id, username, current_project_id
• projects — owner_id, name, thread_id (каждый проект живёт в своём треде канала)
• files — filename, current_version, флаг modified (файл изменился и готов к коммиту)
• file_versions — мясо. Каждая версия файла с полным содержимым. Привязана к file_id и опционально к commit_id
• commits — сообщение, время, ссылка на проект
• commit_files — связка коммитов с версиями файлов (many-to-many, чтобы поддержать ветки)

Почему так: я хотел иметь возможность откатиться к любой версии любого файла. Да, база распухнет, но текстовые файлы — это не гигабайты видео. Плюс наличие file_versions и commit_files позволяет делать diff между версиями и смотреть историю изменений.

В коде вместо голых кортежей из SQL — датаклассы:

Маркдауновый ад

Казалось бы: взял код, обернул в тройные апострофы, кинул в Telegram. Telegram сам подсветит синтаксис, если указать язык. Красота. В теории.

На практике Telegram использует свой диалект Markdown, где куча служебных символов: _ * [ ] ( ) ~ > # + - = | { } . !

Попытка 1: заэкранировать всё подряд. Результат: код превращается в кашу. Вместо def __init__- получается def |_|_init|_|_ — уже не запустишь, и в канале выглядит как говно.

Попытка 2: не экранировать вообще. Telegram шлёт на**й с ошибкой «can't parse entities».

Попытка 3: экранировать только то, что реально ломает разметку. Выяснилось, что порядок важен. Сначала экранируем точки и подчеркивания, потом обратную косую черту. Но и это не панацея — последовательности типа \*

после экранирования превращаются в \\*, и Telegram снова недоволен.

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

Попытка 5 (финал): забил на Markdown и перешёл на HTML. Telegram умеет его принимать. Да, он не такой красивый, но зато предсказуемый:

Никаких точек, подчеркиваний, обратных слешей. Просто экранируем три символа — и код летит как надо.

Security by design

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

Добавил в /commit. Потом решил с другого аккаунта потестировать команды на чужих файлах. И тут бот на каждую команду стал выдавать «файл не найден» или «проект не найден». И я понял: безопасность уже работает. С самого начала. Из коробки. Без единой строчки кода.

Как так вышло? В таблице projects с самого начала было поле owner_id. При создании проекта я писал туда telegram_id владельца. Все запросы к БД фильтруются по этому полю:

Показать проекты — только свои. Найти файл — только в своих проектах. Выбрать проект — только из своих. Никаких лишних проверок. Просто SQL-запросы, которые с самого начала учитывали владельца.

Команды: от семи до двух десятков

Изначально казалось, что команд будет немного. Но...

Жизнь рассудила иначе.

• База: /start, /init, /use, /list, /ls, /commit, /log, /status
• Удаление: /rm, /rmproject + подтверждение
• Игнор: /ignore, /ignored, /unignore
• Ветки: /branch, /branches, /checkout
• Диффы и просмотр: /diff, /cat

Итого — уже под два десятка. И это не предел.

Простота > абстракции

В моём коде нет абстрактных базовых классов. Совсем. Потому что они нужны только когда у тебя есть минимум две разные реализации одного и того же. В GitGram всё проще: один способ работать с БД, один способ шифровать, один способ парсить .gitignore.

Если завтра появится вторая реализация — тогда и буду делать интерфейс. А пока это просто оверхед.

В GitGram:

• Хочешь понять, как работает add_file — идёшь в database.py и читаешь 10 строк кода.
• Хочешь увидеть обработчик /commit — открываешь bot.py и смотришь.

Никаких AbstractMinerShieldEventProcessor, BaseGitGramManager, InterfaceProviderFactory.

Код должен быть тупым. Чем тупее — тем проще его читать и отлаживать.

Что дальше

В планах:

• Докрутить коллаборацию (несколько человек над одним проектом)
• Приватные репозитории
• Кодспейс прямо в боте (да да знаю я сошёл с ума и бла бла бла..)

Итог

GitGram принимает файлы, режет их на куски если надо, постит в канал с подсветкой. Коммиты ходят, ветки переключаются, диффы показываются. Всё это в тредах, каждый проект отдельно.

На практике GitGram ни к чему. Но сама задумка — Git в Telegram — это же так прикольно. Просто посмотреть, можно ли такое вообще запилить.

Если хочешь поучаствовать

• GitGram
• Чат для хардкорных: @sandbox_hardcore — вся сырая разработка, факапы и обсуждения (без цензуры)

Подписывайся на мой TГ-канал — там я публикую все свои эксперименты, код и приглашаю к обсуждению. Только факты, мат и никакой политоты.

Мы рады анонсировать выпуск MDN MCP server. MCP (Model Context Protocol) — открытый стандарт, который позволяет ИИ-инструментам подключаться к внешним источникам данных. MDN MCP server использует этот протокол, чтобы перенести документацию MDN и данные о совместимости браузеров прямо в вашего ИИ-агента или IDE.

• MDN MCP server — экспериментальный сервер по протоколу MCP.
• Даёт ИИ-агентам и IDE доступ к актуальной документации MDN и данным о совместимости браузеров.
• Работает с VS Code, Zed, Cursor, Claude Code, Codex CLI, Antigravity CLI и Claude Desktop.
• В тестах с Claude Code Opus 4.7 MDN MCP дал гораздо точнее и надёжнее результаты о поддержке браузеров.
• Ответы с MDN MCP были вдвое быстрее, чем без него.

Зачем мы создали MDN MCP

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

Например, LLM или агент для написания кода может не знать, что существует функция вроде @view-transition CSS at-rule, или не знать, достигла ли она статуса Widely Available в Baseline и безопасна ли для использования во всех браузерах.

MDN MCP даёт вашему агенту для написания кода доступ к точной и актуальной информации о веб-платформе. Также он упрощает доступ к последней документации, не покидая привычные инструменты.

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

Как использовать MDN MCP

MDN MCP server работает с любым MCP-совместимым клиентом, включая:

• Редакторы: VS Code, Zed и Cursor.
• CLI-агенты: Claude Code, Codex CLI и Antigravity CLI (ранее Gemini CLI).
• Чат-приложения: Claude Desktop.

Ссылки в этом списке ведут к инструкциям по настройке MCP для каждого инструмента. Инструкции по установке и другие детали — на нашей странице MDN MCP server.

Как быстрый пример, чтобы использовать его с Claude Code, нужно выполнить следующую команду:

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

Какую разницу даёт MCP

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

Мы протестировали Claude Code Opus 4.7 с MDN MCP и без него на нескольких функциях, недавно появившихся в Firefox 150 и 151, спрашивая, как использовать функции и какая у них поддержка браузеров. А именно:

1. Как использовать CSS-функцию light-dark() для изображений и какие браузеры её поддерживают?
2. Как использовать CSS-псевдокласс :buffering и какие браузеры его поддерживают?
3. Как использовать атрибут shadowrootslotassignment на элементе и какие браузеры его поддерживают?
4. Как использовать Web Serial API и какие браузеры его поддерживают?

Мы заметили определённые закономерности в результатах. В большинстве случаев заметки по использованию от Claude Code с MDN MCP и без него были сопоставимы. Часть ответов, использовавших MCP, была структурирована лучше и полнее. Например, заметки для CSS-функции light-dark() также включали примеры с линейными градиентами, которые не были прямо упомянуты в вопросе, но тоже поддерживаются.

Когда дело дошло до информации о поддержке браузеров, победитель был очевиден: MDN MCP дал намного точнее и надёжнее результаты. Claude Code без MCP правильно определил поддержку браузеров только в одном случае — для псевдокласса :buffering.

Например, Claude Code без MCP настаивал, что декларативный атрибут shadowrootslotassignment поддерживается в Chrome 120 и Safari 18.3, возможно, путая его с опцией slotAssignment метода Element.attachShadow(). Но на самом деле Firefox 151 — первый браузер, в котором появилась поддержка этого атрибута.

Без MCP Claude Code также не дал никакой конкретной информации о поддержке браузеров для использования изображений в функции light-dark(): «поддержка менее однородна, чем вариант с цветом», тогда как с MCP он выдал полную таблицу с указанием Firefox 150 и Chrome (за флагом) как поддерживающих браузеров.

Худший результат Claude Code без MCP показал на вопросе про Web Serial API. Firefox 151 получил поддержку Web Serial API в мае 2026 года. Однако Claude Code без MCP правильно упомянул браузеры на базе Chromium как поддерживающие эту функцию, но также настаивал, что в Firefox она:

Не реализовано (и не в планах — см. позицию Mozilla по стандартам: «вредно»).

С включённым MCP Claude Code правильно определил, что Firefox 151 поставляет поддержку Web Serial API, согласно примечаниям к выпуску.

Кроме того, мы заметили, что в наших тестах ответы с использованием MDN MCP были вдвое быстрее. Без MCP Claude Code приходилось загружать и парсить немало HTML-страниц, чтобы найти актуальную информацию, что занимало время, но даже тогда не давало точных результатов.

Поучаствовать

Ваш отзыв помогает нам становиться лучше. Если вы столкнулись с проблемами, есть комментарии или предложения или хотите поделиться, как используете MDN MCP, мы будем рады услышать вас. Заходите в канал platform в нашем Discord. Если заметили проблемы, сообщайте о них в репозиторий mdn/mcp на GitHub.

Что дальше

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

Источник: Introducing the MDN MCP server — MDN Blog.

Попробуйте подключить MDN MCP к своему редактору или агенту и проверьте, насколько точнее станут ответы о веб-платформе.

1. Как я утонул в генерациях
2. Экзамен вместо «прыжков» по сервисам
3. Небольшой технический конвейер
4. Зачем цифры важнее впечатлений
5. Простой тест на форматы
6. Как ведут себя Riverflow, Flux и Seedream
7. Отчёты, артефакты и спокойная аналитика
8. Сценарий «восемь формулировок»
9. Зрелый подход к выбору AI

В прошлой статье я рассказывал, как собрал тестовый стенд для AI‑генерации. Теперь — про то, как превратил его в живой процесс с разными сценариями и метриками.

1. Как я утонул в генерациях

Я осознал что в очередной раз листал чат и не мог найти тот самый удачный вариант обложки.

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

2. Экзамен вместо «прыжков» по сервисам

Тогда я придумал простое правило. Любой сервис, который претендует на место в моём рабочем наборе, должен пройти экзамен. Не приятную беседу с общими вопросами, а одинаковый для всех, жёсткий сценарий. Без исключений и любимчиков.

3. Небольшой технический конвейер

Реализация получилась до обидного простой. Node.js, TypeScript, запуск через tsx. Список моделей вынесен в отдельный конфиг, API-ключ лежит в .env, а команды запуска выглядят вроде npm run test:niche или npm run test:collage-2x2-eight-prompts. Я взял творческий хаос и сложил его в аккуратный pipeline.

Дальше всё происходит автоматически: запускаешь тест — и один и тот же набор задач последовательно проходит через всех кандидатов. Мой вклад заканчивается на нажатии Enter.

4. Зачем цифры важнее впечатлений

Зачем вообще так усложнять? Потому что мантра «любая нейросеть — она и есть нейросеть» на практике не работает. Разброс колоссальный. Один сервис очень аккуратно держит геометрию кадра, но мелкие детали превращает в мыло. Другой рисует фактуру так, что хочется печатать и вешать, но при запросе «коллаж 3×3 с чёткими границами» внезапно решает творчески переосмыслить сетку. Третий стабильно отвечает и по времени, и по предсказуемости, но на сотне запросов выписывает такой чек, что хочется закрыть вкладку.

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

5. Простой тест на форматы

Возьмём самый базовый пример — проверка соотношения сторон. Формулировка элементарная: закат над горами, три варианта — 3:4, 1:1 и 16:9. Казалось бы, минимальный уровень адекватности. Но нет.

Достаточно пробежать глазами столбец со статусом. Три запроса — три быстрых проверки «на глаз». Там, где на 3:4 и 16:9 горит FAIL, модель откровенно игнорирует задачу и рисует квадрат или удобный для себя формат. И это при том, что промпт простейший: не сложная сцена, не коллаж — всего лишь «закат, горы и нужная рамка».

6. Как ведут себя Riverflow, Flux и Seedream

Если посмотреть на результаты, riverflow-v2-pro аккуратно соблюдает все три формата. Но за эту аккуратность приходится платить временем: портретная картинка генерируется около 360 секунд. Шесть минут — роскошь, если у вас в руках горящий дедлайн. Упрощённая версия, riverflow-v2-fast, выдаёт правильные форматы за секунды и остаётся в адекватных рамках по времени — это уже инструмент для реальных задач.runware+2

С моделями Flux история другая. Почти вся линейка black-forest-labs стабильно промахивается по нестандартным форматам: колонка «Соотношение» упорно показывает 4/3 или 1/1, хотя в запросе чётко указано «16:9, wide landscape». Относительно ровно ведёт себя только flux.2-max, который хотя бы честно выдаёт квадрат, но проблемы с другими соотношениями никуда не деваются.github+1

Seedream-4.5 от Bytedance, напротив, поражает скоростью: ответы прилетают за 7–8 секунд, но модель регулярно игнорирует заданный формат и возвращает квадрат 2048×2048. Для макета, привязанного к конкретным пропорциям — сторис, постера или баннера — такая «быстрота» только ломает всю вёрстку.eachlabs+1

7. Отчёты, артефакты и спокойная аналитика

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

Особенно сильно это помогает в задачах, где критична композиция: нужна ровная сетка 2×2 или 3×3 без самодеятельности в духе «я тут чуть подвину, так красивее». Это как раз те случаи, когда от сервиса нужна дисциплина, а не внезапные художественные «инициативы».

8. Сценарий «восемь формулировок»

Отдельный пласт наблюдений даёт сценарий «восемь формулировок» (collage-2x2-eight-prompts). Суть задачи не меняется, контент остаётся одним и тем же. Я варьирую только подачу: где-то пишу запрос грубо и коротко, где-то — щадяще и структурно, местами добавляю лишний контекст.

На этом месте становится видно, как модель реагирует не на саму тему, а на стиль запроса. Одна и та же нейросеть спокойно выдерживает строгое техническое ТЗ и проваливается при формулировке «сделай красиво, сам понимаешь». После таких тестов по-другому относишься к промптам: начинаешь формулировать точнее, понимая, какая модель как «слушает» текст. И внезапно исчезают загадки в духе «почему здесь получилось, а там всё развалилось».

9. Зрелый подход к выбору AI

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

Когда делаешь так, выбор перестаёт быть эмоциональной пыткой в стиле «нравится / не нравится». Он превращается в спокойное рабочее решение: этот сервис — для быстрых черновиков, этот — для вылизанной композиции, этот — для длинных и сложных запросов, в которых ошибка по смыслу недопустима. В этот момент генерация перестаёт быть магическим ритуалом с сюрпризами и превращается в нормальный, предсказуемый инструмент. Таким, каким он и должен был быть изначально.

Сделал себе инструмент, который это решает. Потом оформил в продукт. Называется CoAlly - сервер, который дает агентам общую память.

Что он делает

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

Запрос "проблемы с авторизацией" найдет запись про "token refresh rotation", хотя слова совершенно разные. Работает через эмбеддинги и косинусное расстояние, скоро выйдет фича с анализом смысловой корреляции при поиске.

Подключение

Шаг 1: регистрация

Заходим на coally.cortexally.ai, создаем аккаунт. Получаем API ключ.

Шаг 2: подключение к агенту (Claude, Cursor и др.)

Одна команда в терминале:

claude mcp add coally-nexus --transport sse https://coally.cortexally.ai/sse --header "Authorization: Bearer ВАШ_КЛЮЧ"

Перезапускаем Claude Code. В списке MCP-инструментов должен появиться coally-nexus.

Cursor, Windsurf, VSCode

Заходим в настройки Cursor -> Settings -> MCP -> Settings (значок шестеренки) или создаем/редактируем файл `.cursor/mcp.json` в корне проекта (или в домашней директории для глобального подключения):

Файл `~/.codeium/windsurf/mcp_config.json` для Windsurf или соответствующее меню для VSCode и других его форков.

Перезапускаем IDE|Agent. Готово.

Первая сессия

После подключения агент при первом взаимодействии проиндексирует проект автоматически. Если нет - попросите: "проиндексируй этот проект через CoAlly".

Что происходит при индексации: сканируется дерево проекта, находятся конфиги, важные воспоминания, memorybanks и др., все это эмбеддится и сохраняется как контекст.

Дальше агент сам начнет сохранять контекст работы после значимых изменений. Если нужно явно сохранить что-то: "сохрани контекст этой задачи в CoAlly".

Что получаем

На вопрос "что вчера делали по задаче авторизации? какой статус бага с токеном и сколько времени потребуется на доработку" Агент достает из CoAlly записи: "вчера в Cursor поправили ротацию токенов, причина была в TTL, затронули два файла. Могу сразу продолжить и на основе коммитов ... исправить точечно флоу, время на исправление — N минут."

Если работаете в команде - еще полезнее. Контекст коллеги тоже доступен. Его экспертиза и навыки также постепенно приобретают цифровую версию. Не нужно ждать стендап или писать в Slack.

Ограничения

Агенты иногда игнорируют инструкции и не сохраняют контекст. Бывает. Можно просить явно.

Семантический поиск хорош, но не идеален. Если запрос слишком общий ("что нового?"), результаты будут размытыми. Конкретные вопросы работают лучше.

Бесплатный тариф - 2 проекта. Для личного использования хватает. Для команд - тарифы Team и Enterprise.

Если верить статистике, сейчас ежедневно создается около 402,74 миллионов терабайт данных.

Согласитесь, довольно внушительная цифра.

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

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

Мы решили перейти на гибкое объектное хранилище S3 – чтобы централизовано хранить и управлять текстами, креативами, отчетами и другими маркетинговыми материалами с удобным доступом внутри команды, ведь S3 позволяет хранить файлы любого типа и объема и масштабируется автоматически. Осталось только выбрать ПО для хранения файлов в облаке, к которому можно подключить S3.

Ранее у нас был опыт использования Nextcloud, однако его функционал, подобный швейцарскому ножу (встроенные календарь, конференции, таск-трекер и т. д.), оказался слишком объемен для нашей, по сути, скромной задачи – удобного и стабильного хранения файлов.

Вот почему мы подыскали аналог Nextcloud – ownCloud. В отличие от более функционального Nextcloud, ownCloud заточен исключительно на работу с файлами. И при этом он поддерживает подключение облачного объектного хранилища S3. Поэтому для нас в сравнении Nextcloud vs ownCloud выбор был очевиден.

В этой статье я расскажу, какие возможности есть у ownCloud, почему это ПО может быть полезно и как настроить связку ownCloud и S3. Если вы хотите организовать безопасное, контролируемое хранение и обмен данными на работе или дома, то этот материал будет для вас полезен.

Что может ownCloud

Для начала – буквально несколько слов об ownCloud и его возможностях.

Это программное обеспечение с открытым исходным кодом для хранения, синхронизации и обмена файлами появилось в 2010 году благодаря усилиям разработчика KDE Франка Карличека, который стремился создать бесплатную альтернативу коммерческим облачным сервисам хранения данных.

OwnCloud позволяет:

1. получать доступ к данным из любой точки мира и хранить файлы на собственном сервере – под вашим полным контролем;
2. синхронизировать данные между устройствами – доступ к файлам возможен с компьютеров (Windows, macOS, Linux), смартфонов (iOS, Android) и через браузер, изменения на одном устройстве мгновенно появляются на всех остальных;
3. делиться файлами и папками по ссылке, настраивая права доступа, пароли и срок действия ссылок;
4. совместно работать с документами, отслеживать историю изменений и возвращаться к любой предыдущей версии файла.

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

Сегодня ownCloud используют компании (Philips, Nationwide, Zeppelin и др.) в самых разных сферах (IT, машиностроение, медицина и т. д.).

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

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

OwnCloud позволяет решать самые разные задачи, связанные с работой с файлами, – расскажем на примере трех кейсов, как это облачное хранилище помогает нам в отделе маркетинга.

Для каких задач мы используем ownCloud и S3

1. Централизованное управление материалами

Мы часто работаем с текстами, изображениями и презентациями. Дизайнеры и авторы загружают эти материалы в ownCloud, файлы автоматически сохраняются в S3, а для удобства поиска у нас настроены теги.

В итоге каждый член команды может видеть версии файлов (это важно для правок), нет хаоса в почте и мессенджерах.

2. Безопасное взаимодействие с подрядчиками

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

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

3. Долгосрочный архив креативов и отчетов

По закону (152-ФЗ в РФ или GDPR в Европе) компания обязана хранить персональные данные клиентов, а также отчеты о рассылках и рекламных акциях на протяжении определенного времени.

Для решения этой задачи мы настроили правило: файлы старше 90 дней автоматически перемещаются в S3 Glacier (холодное хранилище) – этот класс снижает стоимость хранения, а если, например, юристу понадобится скачать какой-нибудь отчет спустя 2–3 года, он просто выгрузит его из ownCloud буквально за 5–10 минут.

Теперь – в деталях и по шагам о том, как начать использовать ownCloud в связке с S3.

Как развернуть ownCloud и подключить S3

OwnCloud удобно использовать с объектным хранилищем S3 – таким образом можно:

1. масштабировать систему – S3 расширяется автоматически и не имеет ограничений по объему и количеству размещаемых данных и файлов;
2. оптимизировать затраты – можно платить не за дорогую конфигурацию виртуального сервера с большим объемом диска, а лишь за фактически занимаемое место, по модели pay as you go (оплата по мере потребления);
3. повысить надежность хранения – за счет встроенной в S3 тройной репликации данных (файлы хранятся в 3 копиях и размещаются на независимых серверах в разных стойках для абсолютной сохранности данных).

Итак, разберем, как настроить связку ownCloud и S3.

Разработчики ownCloud предлагают два варианта установки. Можно скачать ownCloud и установить его вручную или использовать Docker-контейнеры. Мы выберем второй вариант.

Для размещения ownCloud в нашем примере создадим виртуальный сервер на базе готового решения Docker.

Можно подключиться к серверу по SSH или с помощью терминала в панели управления.

Для размещения файлов создайте бакет объектного хранилища S3. Реквизиты доступа к нему будут в карточке бакета в панели:

Создайте директорию для размещения конфигурационных файлов проекта и перейдите в нее:

Затем вставьте в файл docker-compose.yml следующее содержимое с помощью любого текстового редактора:

После этого создайте файл .env, в котором будут храниться значения переменных. Шаблон файла следующий:

Теперь необходимо отредактировать эти строки:

1. ownCloud_DOMAIN и ownCloud_TRUSTED_DOMAINS – укажите домен (так как ownCloud будет размещен за обратным прокси, указывать рабочий порт здесь не требуется);
2. ADMIN_USERNAME – логин администратора;
3. ADMIN_PASSWORD – пароль администратора.

Обратите внимание! Изменение ADMIN_USERNAME и ADMIN_PASSWORD уже после развертывания контейнеров не возымеет эффекта. Изменить пароль администратора вы можете в настройках пользователя в веб-интерфейсе.

Далее необходимо указать параметры подключения к S3.

• ownCloud_OBJECTSTORE_BUCKET – имя бакета S3;
• ownCloud_OBJECTSTORE_ENDPOINT – эндпоинт хранилища (например, https://s3.ru1.storage.beget.cloud);
• ownCloud_OBJECTSTORE_REGION – регион (ru1 для Beget);
• ownCloud_OBJECTSTORE_KEY – Access key бакета;
• ownCloud_OBJECTSTORE_SECRET – Secret key бакета.

Сохраните файл.

Остается лишь добавить файл конфигурации для Caddy – обратного прокси, через который пользователи будут получать доступ к ownCloud.

Создайте директорию config:

После чего создайте в ней файл конфигурации Caddyfile. Добавьте в него следующее содержимое, указав вместо ownCloud.betutorial.ru ваш домен ownCloud:

Обратите внимание! Caddy выпустит SSL-сертификат на домен автоматически.

Все запросы к домену будут проксироваться в контейнер ownCloud_server.

На этом настройка конфигурационных файлов завершена, можно запускать контейнеры:

Потребуется несколько минут, чтобы docker загрузил образ и развернул контейнеры.

После запуска перейдите по домену, чтобы проверить работу хранилища:

Выполните вход со стандартными доступами.

Обратите внимание! Если ownCloud недоступен или вы получаете ошибку при входе со стандартными доступами, проверьте корректность конфигурационных файлов. После внесения изменений перезапустите контейнеры.

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

Теперь проверим работу объектного хранилища – перейдем на главную страницу и загрузим файлы:

Файлы также появились и в объектном хранилище:

Обратите внимание! Файлы, которые вы удалите в ownCloud, будут перемещены в корзину и останутся в S3. Для их полного удаления очистите корзину ownCloud.

Чтобы делиться паролями с новыми пользователями, необходимо настроить отправку почты в ownCloud, сделать это можно в разделе Settings>General.

В нашем примере мы настроим отправку через SMTP:

После указания данных введите тестовый email и нажмите “Send email”. Если отправка успешна, вы получите уведомление об этом:

А на почтовый ящик поступит письмо:

На этом настройка завершена – можно начинать работать с файлами, используя связку ownCloud и S3.

Заключение

Если вы ловите себя на мысли, что данных стало настолько много, что поиск нужного файла порой происходит дольше, чем работа с ним (особенно если одни файлы хранятся на почте или в мессенджере, а другие – на ноутбуке или флешке), облачное хранилище может вам помочь.

Подобное ПО пригодится как для личных целей, так и для бизнеса – недаром в 2025 году в нашей стране был зафиксирован рост интереса крупного и среднего бизнеса к технологии облачного хранилища.

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

Я Java-разработчик и в основном работаю с backend: Spring Boot, базы данных, интеграции, авторизация, WebSocket — всё то, что обычно находится за интерфейсом.

В какой-то момент я поймал себя на мысли: я каждый день пользуюсь мессенджерами, но плохо понимаю, как они устроены внутри. Окей, JWT, WebSocket, PostgreSQL, Redis — это понятно. Но что технически означает фраза "end-to-end encryption"? Как сервер доставляет сообщения, если он не должен их читать? Где живут ключи? Что хранится в базе? Что происходит, если у пользователя два устройства?

Решил разобраться через практику. Написал мессенджер с нуля. Назвал Chaos Messenger.

Сразу честно: криптографическую часть я изучал вместе с Claude и ChatGPT — читал спецификации X3DH и Double Ratchet, разбирал примеры, задавал вопросы, пока не сложилась цельная картина. Frontend тоже делался с активной помощью ChatGPT: я backend-разработчик, React для меня не основная среда. Но архитектура, backend, интеграция WebCrypto, модель конвертов, хранение сообщений и принципиальные решения — мои.

Для меня AI здесь был не заменой понимания, а инструментом — примерно как документация, Stack Overflow и ревью коллег. Без понимания threat model и архитектуры такой проект всё равно не собрать.

В статье расскажу, как работает E2EE изнутри: как устанавливается сессия через X3DH, как каждое сообщение получает отдельный ключ через Symmetric Ratchet, почему сервер хранит только зашифрованные конверты, и какие ошибки я допустил по дороге.

Стек: Spring Boot 3, React 18, WebCrypto API, PostgreSQL, Redis, WebSocket/STOMP, Prometheus, Grafana.

Важная оговорка про web-E2EE

Когда я говорю, что сервер не может прочитать сообщения, я имею в виду backend, базу данных, WebSocket-слой и уже сохранённые ciphertext-конверты. У них нет ключей и plaintext.

Но у web-E2EE есть отдельная проблема: frontend-код тоже приходит с сервера. Теоретически скомпрометированный сервер может отдать изменённый JavaScript, который украдёт ключи или plaintext до шифрования. Это ограничение не конкретно моего проекта, а браузерной модели в целом.

Поэтому корректная формулировка такая: backend не получает ключи и не может расшифровать уже переданные или сохранённые сообщения. Защита от подмены клиентского кода — отдельный слой безопасности: подпись сборок, независимая верификация клиента, desktop/mobile-приложения, reproducible builds.

Почему обычный подход не работает

Большинство "мессенджеров" на GitHub выглядят примерно так:

Сервер знает всё. Видит каждое сообщение. Если БД утекла — утекла вся переписка. Если сервер взломали — читай что хочешь. Если завтра компания решит продать данные — технически ничего не мешает.

E2EE решает это радикально: backend не получает ключи и не хранит plaintext. Сообщение шифруется на устройстве отправителя до отправки в сеть, а расшифровывается только на устройстве получателя.

Это уже не вопрос политики конфиденциальности в стиле "мы обещаем не читать". Это архитектурное ограничение: если у сервера нет ключа, он не может превратить ciphertext обратно в текст.

Звучит как магия. На самом деле — два протокола и немного WebCrypto.

Главная идея: конверты

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

Именно так это работает в коде. В базе данных у меня это выглядит так:

Когда я впервые увидел

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

А вот что сервер возвращает при запросе списка чатов через API:

Не

. Не

. Буквально

(DevTools → Network → ответ API с

)

Откуда берутся ключи: X3DH

Главный вопрос: как Алиса и Боб получают общий секрет, если они никогда раньше не общались? И как сделать это так, чтобы сервер только помог передать публичные данные, но сам не смог вычислить итоговый ключ?

Для этого используется X3DH — Extended Triple Diffie-Hellman, протокол из экосистемы Signal. Его задача — установить общий секрет между двумя устройствами, используя долгосрочные и временные ключи.

Что хранится на сервере

Когда пользователь регистрирует устройство, он загружает на сервер пакет публичных ключей:

На сервер уходят только публичные части. Приватные ключи сериализуются и хранятся локально в браузере — и никогда не покидают устройство в сеть.

Здесь важно сказать честно: хранение приватных ключей в

Более строгий вариант — использовать Web Crypto API с

, чтобы приватный ключ жил внутри браузерного crypto runtime и его нельзя было экспортировать в байты. Но у этого подхода есть практическая сложность: ключи нужно переживать между перезагрузками страницы, синхронизировать с IndexedDB, аккуратно восстанавливать состояние устройства и не сломать UX.

В браузерных E2EE-приложениях обычно приходится выбирать между несколькими вариантами:

• Сериализуемые ключи в localStorage или IndexedDB — проще реализовать, но нужно очень серьёзно относиться к XSS и целостности frontend-кода.
• extractable: false + IndexedDB — безопаснее, но сложнее в реализации и восстановлении состояния.
• Нативное secure storage вроде Android Keystore или iOS Secure Enclave — лучший вариант для мобильных клиентов, но он недоступен обычному web-приложению.

В текущей версии Chaos Messenger используется первый вариант. Это осознанный компромисс для pet/open-source проекта и удобного запуска в браузере. Переход на non-extractable ключи и более строгую модель хранения стоит в roadmap.

Ключевой момент: backend всё равно не получает приватные ключи и не может расшифровать сохранённые ciphertext-конверты. Но защита ключей на клиенте — отдельная задача, и её нельзя честно замалчивать.

Установка сессии

Когда Алиса открывает переписку с Бобом впервые, происходит следующее:

В классическом X3DH четвёртая DH-операция с one-time prekey опциональна: она выполняется, если сервер выдал доступный OPK получателя. В моей реализации устройство публикует набор one-time prekeys при регистрации, поэтому первое сообщение обычно использует DH4. Если OPK закончились, сессию всё равно можно установить через остальные DH-компоненты, но это уже менее сильный вариант.

Боб, получив конверт с эфемерным публичным ключом Алисы, повторяет те же операции со своими приватными ключами и получает тот же самый

. Математика симметрична.

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

Получить

Как шифруется каждое сообщение: Symmetric Ratchet

X3DH даёт нам стартовый

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

Решение — симметричный ratchet. После каждого сообщения цепочка ключей продвигается вперёд:

Визуально это выглядит так:

используется для шифрования одного сообщения через AES-GCM, после чего уничтожается. Если атакующий компрометирует

— он прочитает только второе сообщение.

В рамках такой симметричной цепочки это даёт forward secrecy назад по цепочке: зная текущий или отдельный

Само шифрование сообщения:

А вот что уходит на сервер — живой пример из DevTools:

Сервер получает

и

. Расшифровать без

Важная оговорка: это ещё не полный Double Ratchet

В этом проекте реализован Symmetric Ratchet — цепочка, где из

для каждого сообщения выводится отдельный

Это защищает прошлые сообщения: если атакующий узнает текущий ключ или отдельный

, он не сможет откатить HMAC назад и получить старые ключи.

Но это не полный Double Ratchet из Signal Protocol.

В полном Double Ratchet есть ещё DH ratchet step: стороны периодически выполняют новый Diffie-Hellman обмен и обновляют root key. Это даёт break-in recovery — возможность восстановить безопасность будущих сообщений после компрометации части состояния.

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

Мультиустройство: один пользователь, несколько конвертов

Первый неочевидный момент: в E2EE сообщение адресуется не просто пользователю, а конкретным устройствам пользователя.

Если у Боба два устройства — телефон и ноутбук — нужен отдельный encrypted envelope для каждого устройства. Сервер не может взять один конверт, расшифровать его и "переупаковать" для второго устройства: у него нет ключей и он не знает plaintext.

Значит при отправке сообщения нужно зашифровать его отдельно для каждого устройства каждого участника чата.

Для чата где у каждого по 2 устройства — 4 конверта на одно сообщение. Для группы из 10 человек — потенциально 20 конвертов. Это нормально, это цена безопасности.

Сервер: хранение и доставка конвертов

На сервере сообщение создаётся с контентом

, а конверты сохраняются отдельно:

После сохранения — fanout по WebSocket. Каждое устройство получает свой конверт и только его:

Это важное отличие от обычного WebSocket-чата. В обычном чате сервер рассылает одно и то же событие всем участникам. В E2EE-чате сервер рассылает разные события разным устройствам: payload для каждого устройства содержит свой

Топик

— строго персональный. Устройство А не получает конверт устройства Б. Никакого broadcast — только адресная доставка.

Архитектура целиком

Баг который долго не замечал

В панели чатов показывается превью последнего сообщения. Я реализовал это через

Запускаю — в списке чатов у всех написано

.

Конечно. Сервер же не знает что там написано.

Я полчаса думал как решить это на сервере. Потом дошло: нельзя решить это на сервере — у него нет ключей. Решение только на клиенте.

После того как пользователь открыл чат и сообщения расшифровались — кешируем последнее в памяти:

Это хороший пример того, как E2EE меняет привычное мышление backend-разработчика. В обычном приложении preview — это поле в SQL-запросе. В E2EE-приложении preview — это локальное клиентское состояние, потому что только клиент видел plaintext.

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

Rate limiting: дыра которую легко не заметить

Эндпоинт

отправляет SMS с кодом. Без защиты любой скрипт может дёргать его тысячи раз — это называется SMS pumping fraud, SMS стоят реальных денег.

Redis у нас уже был для хранения онлайн-статусов. Добавил rate limiting поверх него:

При превышении — HTTP 429 с заголовком

. Клиент знает через сколько секунд можно повторить.

Важный нюанс: в текущей реализации, если Redis недоступен, сервис не блокирует авторизацию полностью. Для pet-проекта это приемлемый компромисс: лучше рискнуть одним лишним SMS, чем положить вход в приложение.

В production я бы сделал строже: fallback in-memory лимит на инстанс, отдельные лимиты по IP и телефону, антифрод-логику и алерты на всплески отправки кодов.

Авторизация WebSocket

Отдельная история — авторизация WebSocket соединений. HTTP-эндпоинты защищены Spring Security автоматически, но WebSocket — другое дело. STOMP-соединение устанавливается один раз, и нужно проверять JWT при каждом подключении.

Отдельно важно не только проверить JWT, но и связать WebSocket-соединение с конкретным устройством. Пользователь может быть один, но устройств у него несколько, а encrypted envelope адресован именно

Поэтому при подключении я проверяю не только токен, но и

: устройство должно быть зарегистрировано и принадлежать текущему пользователю. Иначе легко случайно превратить per-device E2EE-доставку обратно в обычный broadcast по пользователю.

Что получилось — живые скрины

Что реализовано:

• E2EE-модель с per-device encrypted envelopes
• X3DH session setup + Symmetric Ratchet + AES-GCM
• Мультиустройство
• Личные и групповые чаты
• Realtime доставка через WebSocket/STOMP
• Статусы SENT → DELIVERED → READ
• Редактирование и soft delete сообщений
• Online presence, typing indicator
• Фото-вложения
• Поиск пользователей
• Rate limiting на SMS через Redis
• Prometheus метрики + Grafana дашборд
• Swagger UI с JWT авторизацией
• 24 backend-теста на Testcontainers, 12 frontend на Vitest, E2E на Playwright
• GitHub Actions CI

Что ещё не сделано:

• Полный Double Ratchet с DH ratchet step и break-in recovery
• Ротация signed prekey и аккуратное пополнение one-time prekeys
• Более строгая модель хранения приватных ключей на клиенте: non-extractable CryptoKey + IndexedDB
• Защита от подмены frontend-кода: подпись сборок, независимая верификация клиента, reproducible builds
• Android-клиент с Android Keystore
• Реальный SMS-провайдер вместо кода в backend-логах
• Push-уведомления без утечки содержимого сообщений
• Более строгая metadata-модель для групповых чатов

Главный инсайт

E2EE — это архитектурное решение, а не библиотека.

Нельзя взять обычный Spring Boot чат и просто "включить шифрование". Нужно с самого начала проектировать систему так, чтобы backend не был участником доверенной зоны: он не должен получать plaintext, не должен иметь ключи и не должен уметь пересобирать сообщение из данных в базе.

Это меняет почти всё:

• структуру БД — вместо текста появляются encrypted envelopes
• API — сервер отдаёт [encrypted], а не preview сообщения
• WebSocket — доставка идёт не по пользователю, а по конкретному устройству
• мультиустройство — одно сообщение превращается в несколько ciphertext-конвертов
• frontend — становится полноценной криптографической частью системы, а не просто UI

Второй инсайт: мессенджер — это не "чат с WebSocket". В E2EE-модели это система доставки зашифрованных конвертов с адресацией по устройствам. Как только это принимаешь, многие странные на первый взгляд решения становятся логичными.

Репозиторий

Код открыт: github.com/vaazhen/chaos-messenger

В репозитории есть README на русском и английском, диаграммы, скриншоты, security audit, Docker Compose и запуск одной командой.

Проект не претендует на уровень production-криптомессенджера вроде Signal. Это учебный и инженерный open-source прототип, цель которого — показать, как E2EE меняет архитектуру backend, frontend и realtime-доставки.

Если вы делали что-то похожее — особенно интересно сравнить подходы к ротации prekey-ов, хранению non-extractable ключей в браузере и реализации DH ratchet step. Вопросы и критика приветствуются.

Около семи вечера начали падать транзакции. Не все - примерно 15%. Команда сразу занялась разбором: логи, метрики, трейсы. Стандартный процесс. Проблему нашли и починили за 40 минут. По меркам платёжки - нормально.

Но пока мы разбирались, в поддержку пришло 300 тикетов. Три сотни «что происходит», «у нас не проходят платежи», «когда заработает». Саппорт ничего не знал - он ждал, пока инженеры выплывут из логов. Клиенты ждали саппорт. Всё это время тишина с нашей стороны читалась как безразличие.

Проблему починили за 40 минут. Разгребали тикеты три дня.

Почему молчание хуже, чем «мы знаем о проблеме»

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

Если транзакция не прошла, но есть страница

с записью «Повышенное время отклика платёжного шлюза. Investigating. 19:12» - большинство людей закрывают вкладку и ждут. Не все. Но большинство.

Мы это проверили. После того как поставили нормальную страницу статусов, количество тикетов во время инцидентов упало примерно в три раза. Точнее - на 67% по среднему за квартал. Это не магия, это просто информация в нужный момент.

Что мы пробовали до этого

Расскажу честно, через что прошли, потому что это типичный путь.

Шаг первый: Telegram-канал. Завели канал «Статус сервиса». Писали туда когда что-то падало. Работало ровно до тех пор, пока кто-то не забыл написать. А потом написал через два часа когда уже всё починилось. Клиенты не понимали что происходило. Доверие к каналу упало быстро.

Шаг второй: статус в шапке сайта. Зелёный кружок когда всё хорошо. Ручной - кто-то должен был его менять. Понятно куда это ведёт: кружок всегда зелёный, потому что некогда, потому что забыли, потому что «сейчас разбираемся, потом обновим».

Шаг третий: Atlassian Statuspage. Это уже нормальный инструмент. Он решил проблему. Но у него есть два неудобства для русскоязычного рынка: оплата в долларах (что в 2022 стало практической проблемой) и серверы за пределами России (что для ряда клиентов принципиально с точки зрения регулирования).

Как устроен нормальный incident workflow со страницей статусов

Я говорю «нормальный» - имею в виду тот, который не требует героизма от дежурного инженера в 2 ночи.

Всё начинается с мониторинга. HTTP/TCP-проверки каждую минуту на все критичные эндпоинты: API, веб, база, очереди. Когда что-то падает - автоматическое создание инцидента и уведомление команды. Это не новость, большинство так и делают.

Новость в том, что параллельно с уведомлением команды - автоматическое обновление публичной страницы статусов. Не «кто-то должен написать туда», а именно автоматически. Клиент видит «Degraded performance» раньше, чем успевает написать в поддержку.

Дальше инженер работает по стандартному процессу: Investigating - Identified - Monitoring - Resolved. Каждый статус обновляется на странице. Клиенты, подписавшиеся на уведомления, получают апдейты в Telegram или email. Поддержка может в один клик скопировать ссылку на инцидент и отправить клиенту вместо объяснений.

После разрешения - postmortem прямо на странице. Клиенты видят что случилось, почему и что сделано чтобы не повторилось. Это, как ни странно, повышает доверие сильнее, чем если бы инцидента не было совсем.

Что важно при выборе инструмента

Несколько технических вещей, на которые стоит обратить внимание.

Uptime самой страницы статусов. Она должна быть на отдельной инфраструктуре. Если ваш основной сервис упал и страница статусов на той же инфраструктуре - вы получили идеальный шторм: сервис не работает и статус показать невозможно.

Собственный домен.

вместо

. Это доверие и брендинг.

Telegram-уведомления. Для российской аудитории это важнее email. Люди читают Telegram, а не почту, когда ищут статус сервиса в панике.

Локализация данных. Если работаете с персональными данными российских пользователей - вопрос где физически хранятся данные о ваших инцидентах становится юридическим, а не техническим.

Мы в Flaree делаем страницу статусов именно для таких случаев - серверы в России, Telegram из коробки, оплата в рублях. Сейчас открыт ранний доступ, первые 50 команд получают 3 месяца Pro бесплатно: flaree.ru

Что в итоге

Страница статусов - это не инструмент для больших команд. Это инструмент для любого сервиса, у которого есть клиенты и бывают инциденты. То есть для всех.

Настройка занимает 15 минут. Первый же инцидент, который клиенты узнают из статусной страницы раньше, чем напишут в поддержку - окупает это время с запасом.

P.S. Если у вас уже есть страница статусов - напишите в комментариях какой инструмент используете. Интересно что прижилось у разных команд.

TechCrunch со ссылкой на четыре источника пишет, что ИИ-IDE Cursor привлекает новый раунд на минимум $2 млрд при pre-money оценке $50 млрд. Раунд ведут возвращающиеся инвесторы Thrive Capital и Andreessen Horowitz, новым инвестором заходит Battery Ventures, а стратегический чек выписывает Nvidia. Раунд уже oversubscribed — желающих больше, чем мест.

• Raise: минимум $2 млрд, pre-money оценка $50 млрд (post-money — около $52 млрд)
• Шесть месяцев назад Cursor закрыл раунд при $29,3 млрд post-money — рост почти в 1,8 раза
• ARR в феврале 2026 — $2 млрд; прогноз к концу года — $6 млрд (тройной рост за 10 месяцев)
• Лиды: Thrive Capital и a16z (возвращающиеся), новый — Battery Ventures, стратег — Nvidia
• Главные конкуренты: Claude Code (Anthropic), переработанный Codex (OpenAI), GitHub Copilot (Microsoft)

Что такое Cursor и почему оценка $50 млрд

Cursor — это ИИ-IDE на форке VS Code, которую в 2022 году запустил стартап Anysphere. Основатели — четыре студента MIT: Michael Truell, Sualeh Asif, Arvid Lunnemark и Aman Sanger. Основная фишка — редактирование кода с контекстом на весь проект и автономные ИИ-агенты, которые могут выполнять многошаговые задачи в репозитории.

Оценка $50 млрд ставит Cursor в один ряд с Databricks и Stripe по масштабу, и рост от $29,3 до $50 млрд за полгода — это уровень, которого в категории SaaS за последние пять лет не достиг никто. Основной драйвер — корпоративный сегмент: по данным TechCrunch, Cursor продаёт подписки крупным командам быстрее, чем успевает обрабатывать лиды.

Как Cursor вышел в плюс по марже

До конца 2025 года Cursor работал с отрицательной gross margin. Причина типичная для всех ИИ-IDE на сторонних моделях: каждый запрос в Claude или GPT стоил дороже, чем компания могла взять с клиента по подписке $20 в месяц. Сейчас картина другая благодаря двум шагам.

Во-первых, в конце октября 2025-го Cursor запустил собственную модель — Composer — для задач, где не нужна полная мощность frontier-моделей, и добавил в IDE Auto-режим роутинга (система сама выбирает модель по сложности запроса). Во-вторых, появилась возможность звать более дешёвые модели, включая Kimi от пекинского Moonshot AI. Результат — положительная маржа на корпоративных клиентах, но всё ещё отрицательная на индивидуальных. Поэтому Pro за $20 в месяц — по сути инструмент привлечения, а деньги приходят с тарифов Teams и Enterprise.

Конкуренты наступают: Claude Code, Codex, Copilot

Главная угроза Cursor — Claude Code от Anthropic. Большинство пользователей Cursor исторически работали именно на моделях Anthropic — Claude Sonnet и Opus. Когда Anthropic сам вышел в ИИ-IDE-сегмент, Cursor получил рискованный сценарий быть замещённым собственным поставщиком. Ответ — Composer и диверсификация моделей.

Параллельно в сегменте работают переработанный OpenAI Codex (агент-IDE), GitHub Copilot от Microsoft и Windsurf (бывший Codeium, куплен Google в 2025-м). По темпу выручки Cursor пока лидирует в категории — и раунд это подтверждает. Claude Code сильнее на multi-file рефакторинге и планировании крупных задач, Codex — на тестах и CI-интеграциях; Cursor выигрывает по скорости inline-правок и удобству UI.

Что это значит для российских разработчиков

Cursor по-прежнему не продаётся в РФ напрямую: оплата идёт через иностранные карты (KZ, AM, KG, UZ — банки стран СНГ с Visa/Mastercard) или сервисы-посредники вроде PayPro Global и Zen. Актуальные тарифы: Pro — $20/мес, Teams — $40 за пользователя в месяц, Enterprise — по запросу. При такой траектории роста Cursor, вероятно, будет пересматривать цены на Teams/Enterprise в ближайший год — чтобы ускорить выход в прибыль на всех сегментах.

Что стоит учесть командам, которые используют Cursor:

• Бюджет на Cursor на 2026 год — с запасом +15–20%. Повышение цен на Teams/Enterprise вероятно в ближайшие месяцы
• Auto-режим и Composer для простых задач, Claude/GPT — для сложных. Включается в Settings → Models
• Оплата через карты третьих стран работает, но провайдеры периодически режут платежи ИИ-сервисам — держите резервную карту и посредника
• Enterprise-тариф даёт privacy mode и BYOK (bring-your-own-key): подключение корпоративных LLM в Azure OpenAI или AWS Bedrock. Для команд с требованиями по безопасности это может быть решающим
• Параллельно пробуйте альтернативы — Claude Code сильнее на рефакторинге крупных репозиториев, Codex выигрывает на CI и тестах

Что будет дальше: IPO и консолидация

При оценке $50 млрд и выручке, которая утраивается за год, следующий логичный шаг — IPO. В 2026–2027 годах Cursor может стать первой ИИ-IDE на публичной бирже, и это задаст новый бенчмарк для всего сегмента. Nvidia как стратегический инвестор — это доступ к CUDA-экосистеме и приоритетные мощности на обучение следующих версий Composer.

Риск, который никуда не уходит — зависимость от Anthropic и OpenAI для топовых задач. Если Claude 5 или GPT-6 выйдут с существенно лучшим кодингом и попадут в Claude Code или Codex раньше, чем Cursor сможет подтянуть Composer, оценка $50 млрд будет пересмотрена.

Выводы

Оценка $50 млрд для четырёхлетнего стартапа — сигнал, что рынок ИИ-IDE консолидируется быстрее, чем многие ожидали. Cursor пока лидирует, но Claude Code и Codex дышат в спину, а Microsoft с Copilot сидит на триллионной кассе. Практическое действие: к осени 2026 ждите первый серьёзный пересмотр тарифов Teams и Enterprise — следите за письмами от Cursor и держите под рукой параллельный план на Claude Code или Codex, если бюджет команды ограничен.

Исследователи Aikido Security обнаружили в реестре Open VSX расширение code-wakatime-activity-tracker — почти полный клон легитимного WakaTime. Отличие одно: в функции activate() расширение подгружает нативный бинарник на Zig, который сканирует систему и устанавливает второй дроппер в каждый редактор на базе VS Code.

• Кампания GlassWorm добавила новую стадию — нативный бинарник на Zig (win.node и mac.node), который запускается вне JavaScript-песочницы Node.js.
• Заражаются все VS Code-совместимые редакторы на машине: VS Code, VS Code Insiders, Cursor, Windsurf, VSCodium, Positron.
• Второй этап — фейк популярного расширения steoates.autoimport (5+ миллионов установок) под именем floktokbok.autoimport.
• Вредонос пропускает машины с русской локалью и использует Solana-блокчейн как C2-инфраструктуру.
• Если у вас стояли расширения specstudio.code-wakatime-activity-tracker или floktokbok.autoimport — считайте машину скомпрометированной и ротируйте секреты.

Как устроена атака

Клон WakaTime с одной изменённой функцией

Расширение code-wakatime-activity-tracker на Open VSX визуально повторяет оригинальный WakaTime: те же команды, те же запросы API-ключа, та же иконка в статус-баре. Разница только в одной функции — activate(), которая запускается при первом открытии расширения:

До какой-либо логики WakaTime расширение подгружает нативный бинарник из вложенной папки ./bin/ и сразу вызывает install(). На Windows это win.node — PE32+ DLL, на macOS — mac.node, универсальный Mach-O для x86_64 и arm64.

Полный обход песочницы

Оба бинарника — Node.js native addons: скомпилированные shared-библиотеки, которые Node подгружает через require() как обычные пакеты. Они загружаются прямо в рантайм Node и выполняются за пределами JavaScript-песочницы, с правами уровня операционной системы. Оба написаны на Zig. В macOS-бинарнике остались debug-символы — из них исследователи вытащили путь к проекту автора:

Сканирование всех VS Code-совместимых редакторов

Дальше бинарник ищет на машине каждый редактор, который понимает формат расширений VS Code. Проверяются стандартные пути установки — как в %LOCALAPPDATA%, так и в %ProgramFiles%:

На macOS аналогично обходятся /Applications/*.app для VS Code, Cursor, Windsurf, VSCodium и Positron. Если разработчик использует Cursor как основной редактор, но рядом стоит VS Code — оба окажутся скомпрометированы.

Подмена autoimport — расширения с 5 млн установок

Собрав список редакторов, бинарник скачивает вредоносный .vsix с GitHub Releases-страницы, подконтрольной атакующим. Пакет называется floktokbok.autoimport и подделывается под steoates.autoimport — популярное расширение с более 5 миллионов установок. Скачанный файл сохраняется во временный путь, а затем «тихо» ставится в каждый найденный IDE через его CLI-установщик:

После установки функция cleanupVsix удаляет скачанный файл, чтобы скрыть следы.

Что делает вторая ступень

Установленный autoimport — это тот же дроппер GlassWorm, который Aikido уже анализировали раньше. Он проверяет локаль системы и пропускает машины с русскими настройками, затем обращается к C2-серверу через Solana-блокчейн. Адрес C2 не зашит в бинарник — дроппер каждый раз читает его из блокчейн-транзакций подконтрольного кошелька, поэтому для блокировки недостаточно добавить один домен в deny-list, а закрыть весь Solana нереально.

Дальше дроппер выкачивает секреты с машины, ставит persistent-RAT и доставляет вредоносное расширение для Google Chrome — infostealer, который перехватывает сессионные cookies и нажатия клавиш.

Контекст: год эволюции GlassWorm

Aikido отслеживают GlassWorm больше года: кампания засветилась в марте 2025 с npm-пакетами, прятавшими payload в невидимых Unicode-символах, а с тех пор успела скомпрометировать сотни проектов на GitHub, npm и в VS Code Marketplace. Ключевое отличие нового этапа — переход к нативному коду на Zig: раньше нагрузка выполнялась в JS-рантайме расширения и её было видно в Developer Tools, теперь она уходит на уровень ОС, где статический анализ JavaScript-кода её уже не поймает.

Что делать прямо сейчас

1. Проверьте в каждом VS Code-совместимом редакторе список установленных расширений. Искомые имена: specstudio.code-wakatime-activity-tracker и floktokbok.autoimport.
2. Если нашли — считайте машину скомпрометированной. Удалите расширения, но этого недостаточно.
3. Ротируйте все секреты, к которым у машины был доступ: SSH-ключи, npm/pypi-токены, cloud-CLI, GitHub PAT, облачные credentials в ~/.aws, ~/.config.
4. Проверьте Chrome и Chromium-браузеры на неизвестные расширения и удалите их.
5. Пересмотрите cookies и активные сессии во всех браузерах, разлогиньтесь везде.
6. Для профилактики — перед установкой проверяйте издателя и число установок (autoimport, WakaTime и другие популярные расширения имеют миллионы установок и проверенного автора). Если в команде используется корпоративный endpoint protection — добавьте в его охват папки расширений IDE: это ловит malware в нативных аддонах, которые расширения тянут с собой.

Индикаторы компрометации (IoC)

Вредоносные расширения:

Хеши бинарников SHA-256:

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

Сетевые индикаторы:

Строки в бинарнике:

Выводы

Главный сдвиг в этом релизе GlassWorm — не сама подделка WakaTime, а то, что группа научилась перекладывать payload на нативный слой. Для защитников это означает две вещи: во-первых, статического анализа JS теперь мало — нужен контроль за любыми нативными аддонами, которые расширения тянут с собой; во-вторых, атакующим доступна не одна экосистема, а весь зонтик VS Code-совместимых редакторов сразу.

Расширение [...] кладёт рядом с JavaScript-кодом скомпилированный на Zig нативный бинарник. Это не первый раз, когда GlassWorm прибегает к нативному коду в расширениях. Но теперь бинарник работает не как payload напрямую, а как скрытый слой, который незаметно заражает все остальные IDE на машине.

Если вы разработчик — самый быстрый прикладной вывод: пройдитесь по списку расширений во всех установленных редакторах прямо сейчас, особенно если недавно ставили что-то через Open VSX. И пересмотрите, чьим расширениям вы в принципе доверяете по умолчанию.

Источники: Aikido Security, The Hacker News.

— 3 материала про ИИ в IDE: какие ассистенты доступны в РФ, Copilot бесплатно, ловушки Cursor

— 3 материала про контейнеры: Docker-советы, Podman как альтернатива, Docker для фронтендеров

— 4 материала про инструменты: Bruno вместо Postman, Linux-команды, Playwright + VS Code, дебаг vs console.log

ИИ в IDE

1. Топ 5 ИИ-ассистентов для IDE, доступных российским разработчикам

Обзор ИИ-ассистентов, которые реально работают в России: от GigaCode (Сбер) до Codeium. Для каждого — поддерживаемые IDE, ограничения и стоимость. 24 000+ просмотров — один из самых читаемых материалов за год.

Читать статью →

2. GitHub Copilot стал полностью бесплатным в VS Code

В декабре 2025 Microsoft сделала Copilot бесплатным внутри VS Code. Что входит в бесплатный тир, какие ограничения и стоит ли переходить с платных альтернатив — разбор для тех, кто пропустил.

Читать статью →

3. «Безлимит» Cursor оказался не таким уж безлимитным

Пользователи Cursor обнаружили, что тарифы меняются без предупреждения, а «безлимитный» план имеет скрытые ограничения. Если вы платите за ИИ-IDE — полезно знать, за что именно.

Читать статью →

Контейнеры

4. 6 советов, которые прокачают работу с Docker

Многоэтапные сборки, кеширование слоёв, health checks, .dockerignore и другие практики, которые сокращают время сборки и размер образов. 7 600+ просмотров.

Читать статью →

5. Контейнеры после Docker: Podman и что нас ждёт

Docker — уже не единственный вариант. Podman работает без демона, поддерживает rootless-режим из коробки и совместим с Docker CLI. Обзор состояния экосистемы контейнеров в 2026 году.

Читать статью →

6. 5 вещей про Docker, которые должен знать фронтенд-разработчик

Docker для тех, кто привык к npm start. Зачем фронтендеру контейнеры, как контейнеризировать React/Next.js-приложение и что такое Docker Compose на практике.

Читать статью →

Инструменты и приёмы

7. Bruno API Client — альтернатива Postman

Коллекции хранятся в Git, нет облачного аккаунта, работает офлайн. Bruno дошёл до версии 1.35 и стал серьёзной альтернативой Postman для тех, кому важна приватность и версионирование API-запросов. 6 200+ просмотров.

Читать статью →

8. 7 команд Linux, которые экономят время

Команды за пределами стандартного набора: от быстрого поиска по истории до мониторинга ресурсов. Подойдёт и тем, кто только осваивает терминал, и тем, кто ищет новые трюки.

Читать статью →

9. Playwright + VS Code: автотест за 15 минут

Пошаговый гайд: установка Playwright, расширение для VS Code, запись и запуск первого теста. Полезно, если откладывали автотесты — теперь порог входа ниже некуда.

Читать статью →

10. 1% разработчиков используют дебаг в VS Code. 99% — console.log

Исследование показало, что подавляющее большинство разработчиков игнорирует встроенный дебаггер VS Code. Разбор: почему так происходит, что теряют те, кто не дебажит, и стоит ли менять привычки.

Читать статью →

Команда Cursor представила Cursor 3 — агентно-ориентированный интерфейс, который работает поверх привычной IDE. Старый редактор на базе VS Code никуда не делся — на него можно переключиться в любой момент.

• Новый интерфейс построен с нуля — IDE на базе VS Code остаётся как альтернативный режим
• Мультирепозиторное рабочее пространство с параллельными агентами
• Бесшовная передача агентов между локальной машиной и облаком
• Composer 2 — собственная frontier-модель для кодинга с высокими лимитами
• Встроенный браузер для тестирования веб-приложений
• Маркетплейс плагинов: MCP-серверы, скиллы, субагенты

Что изменилось в Cursor 3

Изначально Cursor был форком VS Code — это позволяло контролировать интерфейс. В третьей версии команда пошла дальше: построила новый интерфейс с нуля, с агентами в центре архитектуры. При этом IDE на базе VS Code продолжает работать — переключиться можно через меню.

Все агенты в одном месте

Новый интерфейс изначально мультирепозиторный — люди и агенты работают в разных репозиториях одновременно. Все локальные и облачные агенты отображаются в боковой панели, включая запущенных с мобильного, из веба, Slack, GitHub или Linear.

Облачные агенты создают демо и скриншоты своей работы для ручной проверки — тот же опыт, что и на cursor.com/agents, теперь встроен в десктопное приложение.

Передача агентов между локальной машиной и облаком

Перемещение агентов между средами (handoff) стало быстрым. Можно перевести облачного агента на локальную машину, чтобы протестировать изменения на своём десктопе. Для быстрой итерации команда выпустила Composer 2 — собственную frontier-модель для кодинга с высокими лимитами использования.

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

От коммита до мёрдж-реквеста

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

Возможности IDE в агентном интерфейсе Cursor 3

Альфа-тестеры отметили, что Cursor 3 удачно сочетает возможности полноценной IDE с агентным подходом:

• Файлы и навигация по коду — полноценный редактор с LSP, go to definition, просмотр файлов в любой момент
• Встроенный браузер — агент может открывать, навигировать и взаимодействовать с локальными веб-приложениями прямо из интерфейса
• Маркетплейс плагинов — сотни расширений через MCP-серверы, скиллы и субагенты. Установка в один клик, поддержка приватных командных маркетплейсов

Планы Cursor: автономные агенты и командная работа

Команда заявляет, что с Cursor 3 заложена основа для более автономных агентов и командной работы. Параллельно продолжится развитие IDE-части.

Попробовать новый интерфейс можно в текущей версии Cursor: Ctrl+Shift+P → Agents Window (на macOS — Cmd+Shift+P). Переключиться обратно на привычную IDE можно в любой момент.

— Air — агентная среда разработки от JetBrains для параллельной работы с ИИ-агентами

— Поддерживает Codex, Claude Agent, Gemini CLI и Junie (собственный агент JetBrains)

— Агенты работают локально, в Docker-контейнерах или Git worktrees для изоляции

— Построена на базе свёрнутого Fleet

— Public preview для macOS, Windows и Linux позже

— Не заменяет IDE — дополняет IntelliJ/VS Code для агентных задач

Что такое Air

Air — не IDE в привычном смысле. Это среда для делегирования задач ИИ-агентам и управления их работой. Ключевое отличие от чатов с ИИ внутри IDE: Air построена вокруг агента, а не вокруг редактора кода.

На практике это работает так: вы формулируете задачу, указываете контекст (конкретная строка, коммит, метод), запускаете агента — и переключаетесь на другую задачу, пока первый агент работает. Когда агент завершает — приходит уведомление, и вы ревьюите diff в контексте всей кодовой базы.

Поддерживаемые агенты

Air поддерживает четыре агента из коробки:

• Codex (OpenAI)
• Claude Agent (Anthropic)
• Gemini CLI (Google)
• Junie — собственный агент JetBrains

Агенты взаимозаменяемы — можно переключаться между ними для разных проектов. Air поддерживает Agent Client Protocol (ACP) и в будущем добавит других агентов через ACP Agent Registry.

Изоляция и параллелизм

Агенты запускаются в одном из трёх режимов:

• Локально — по умолчанию, агент работает напрямую с файлами проекта
• Docker-контейнер — изолированная среда, изменения применяются после ревью
• Git worktree — агент работает в отдельной ветке, изменения мержатся через Air

Docker и Git worktrees позволяют запускать несколько агентов параллельно на разных задачах без конфликтов.

Чем Air отличается от Cursor и Copilot

Cursor и Copilot — это расширения IDE с ИИ-возможностями. Air — отдельное приложение, которое не заменяет IDE, а работает рядом с ней:

• В Cursor/Copilot вы пишете код, а ИИ помогает. В Air вы делегируете задачу, а ИИ пишет
• Air изначально спроектирован для параллельного оркестрирования агентов — Cursor остаётся преимущественно редактором с ИИ-помощником
• Air предлагает встроенный терминал, Git-клиент и превью для ревью результатов агента

Доступность и цены

Air доступен в public preview. Для использования нужна подписка JetBrains AI Pro (входит в All Products Pack) или AI Ultimate — либо собственные API-ключи от OpenAI, Google или Anthropic (только API Billing). При использовании своих ключей (BYOK) они приоритетны, а JetBrains-подписка покрывает остаток.

Пока доступна только macOS-версия. Windows и Linux — в работе.

Выводы

JetBrains Air — первая среда разработки, построенная вокруг оркестрации ИИ-агентов, а не вокруг редактора кода. Параллельный запуск, изоляция через Docker/worktrees, поддержка четырёх агентов — это ставка на то, что разработка сместится от написания к делегированию. Скачать — на air.dev.

Об этом сообщил пользователь GitHub под ником Angry-Orangutan, опубликовав подробный баг-репорт в публичном репозитории Microsoft.

Проблема затрагивает новый режим agent / subagent в Copilot и связана не с безопасностью в классическом смысле, а с биллингом. Тем не менее, эффект от нее вполне материальный: дорогие модели вроде Claude Opus можно использовать бесплатно и сколько угодно долго.

Как работает обход биллинга

Механизм уязвимости строится на нескольких допущениях в архитектуре Copilot.

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

В результате пользователь может начать чат с «бесплатной» моделью, например GPT-5 Mini, а затем внутри нее создать подагента, явно указав для него уже премиум-модель.

Дальше все просто: бесплатная модель делегирует работу подагенту, а тот выполняет задачи с помощью Opus или другого дорогого ИИ — без списания лимитов. По словам автора отчета, таким способом он запускал сотни подагентов и часами обрабатывал файлы, потратив всего несколько платных кредитов.

Реакция Microsoft

Интересно, что изначально исследователь пытался передать проблему через MSRC — стандартный канал ответственного раскрытия уязвимостей. Однако там ответили, что «обход биллинга не относится к сфере безопасности» и предложили оформить баг публично.

В итоге issue действительно появилась в открытом репозитории VS Code, но довольно быстро была закрыта со статусом «not planned». Это означает, что компания не обещает что-либо исправить и уж тем более не комментирует сроки.

Это решение вызвало волну иронии в обсуждении: пользователи отметили, что Microsoft фактически оставила инструкцию по бесплатному использованию платных моделей в открытом доступе.

Почему это важно

Формально речь идет не о взломе, а о логической ошибке в расчете стоимости запросов. Но на практике уязвимость подрывает саму модель монетизации Copilot и агентных функций VS Code.

Теперь разработчики могут использовать автономных кодовых ассистентов прямо внутри Xcode, без сторонних плагинов и костылей. То есть теперь ИИ сможет получать цель и самостоятельно решать, как к ней прийти. И все это прямо внутри IDE от Apple.

Claude и Codex — прямо в IDE

В Xcode 26.3 встроена нативная поддержка Anthropic Claude Agent и OpenAI Codex. Эти агенты могут работать на протяжении всего цикла разработки, а не только писать код по запросу.

Они умеют:

• изучать структуру проекта и файлы,
• искать информацию в документации,
• менять настройки проекта,
• запускать сборки и чинить ошибки,
• проверять результат через Xcode Previews.

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

Продолжение курса на «умный» Xcode

В Apple подчеркнули, что это логичное развитие функций ИИ, появившихся в Xcode 26. Напомним, что тогда IDE получила нового ассистента для Swift. Теперь же ИИ получил доступ к куда большему количеству внутренних возможностей Xcode.

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

Не только Claude и Codex

Помимо встроенных интеграций, Apple открыла Xcode для других агентов через Model Context Protocol (MCP) — открытый стандарт взаимодействия инструментов и ИИ-моделей.

Это значит, что в будущем разработчики смогут подключать любые совместимые модели и агентные системы, а не только решения от Anthropic и OpenAI.

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

Что произошло

Как следует из расследования, злоумышленники получили доступ к shared-серверу, на котором размещался сайт notepad-plus-plus.org и скрипт обновлений.

Они выборочно перехватывали трафик и подменяли ответы сервера обновлений, перенаправляя пользователей на вредоносные файлы. Атака была селективной: зараженные обновления получали не все, а только часть пользователей.

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

Почему это продолжалось так долго

По данным хостинг-провайдера:

• до 2 сентября 2025 года сервер находился под активным контролем атакующих;
• после обновления ядра и прошивки, прямой доступ был утрачен, но учетные данные внутренних сервисов оставались скомпрометированными;
• из-за этого до 2 декабря 2025 года злоумышленники все еще могли перенаправлять трафик обновлений.

Иными словами, сервер уже считался «чистым», но инфраструктурные ключи — нет.

При чем тут Notepad++ и обновления

Атакующие целенаправленно охотились именно за доменом Notepad++, зная, что в старых версиях механизмы проверки обновлений были недостаточно жесткими. Это позволило подсовывать поддельные манифесты обновлений без немедленного обнаружения.

Разработчик и хостинг-провайдер заявляют, что инцидент полностью закрыт:

Что делать пользователям

Авторы проекта рекомендует:

• скачать v8.9.1 вручную с официального сайта;
• установить ее поверх текущей версии;
• не использовать старые сборки с автообновлением без проверки.

Итог

Это тот редкий, но показательный случай, когда open-source проект пострадал не из-за собственного кода, а из-за слабого звена в цепочке поставки — хостинга. Полгода атака оставалась почти незаметной, потому что работала аккуратно и выборочно.

Разработчик Notepad++ публично извинился перед пользователями и признал, что история стала болезненным, но важным уроком: проверка обновлений — не опция, а обязательный минимум.

В конце 2024 года появилась технология, которая изменила подход к созданию видео через ИИ. Kling Motion Control — нейросеть, которая умеет переносить движения из одного видео на фотографию. Вы загружаете видео танцующего человека, добавляете фото малыша — и получаете видео, где ребёнок повторяет все движения из референса.

Как работает Kling Motion Control: технология переноса движений

Процесс создания танцующего видео через Kling Motion Control состоит из трёх этапов:

Этап 1: Анализ видео-референса

Нейросеть загружает видео с танцем (или любыми другими движениями) и анализирует несколько параметров:

• Пластику движений — как двигается тело, руки, ноги
• Ритм и скорость — темп движений, паузы, ускорения
• Поведение камеры — если камера движется (приближение, отдаление, панорамирование), Kling учитывает это
• Динамику окружения — если фон меняется, это тоже анализируется

Этап 2: Сопоставление с фотографией

После анализа референса нейросеть берёт ваше фото и определяет ключевые точки: положение головы, рук, ног, туловища. Затем Kling Motion Control сопоставляет позу на фото с начальной позой в видео-референсе.

Важный момент: качество переноса движений зависит от соответствия позы на фото и позы в начале референсного видео. Если в референсе человек стоит анфас, а на вашем фото — в профиль, результат может быть менее точным.

Этап 3: Генерация финального видео

Kling Motion Control создаёт видео, где персонаж с вашего фото повторяет движения из референса. Нейросеть учитывает:

• Сохранение черт лица и внешности с исходного фото
• Плавность перехода между кадрами
• Естественность движений (без резких рывков и искажений)
• Освещение и тени, соответствующие движениям

Результат: видео длиной 5-10 секунд, где ваш ребёнок (или кот, собака, любой персонаж) танцует так же, как в референсном видео.

Где доступна Kling Motion Control: Study24.ai

Kling Motion Control работает через китайскую платформу Kling AI. Проблема в том, что оригинальный сервис требует китайского номера телефона для регистрации и работает нестабильно из России.

Также есть платформа Study24.ai, которая предоставляет доступ к Kling Motion Control без сложностей:

• Работает без VPN из России
• Регистрация через email или соцсети, не нужен китайский номер
• Интерфейс на русском языке
• Встроенная библиотека референсных видео для танцев
• Подписка даёт доступ не только к Kling, но и к другим нейросетям для видео

Study24.ai — это агрегатор ИИ-инструментов для учёбы и творчества. Кроме Kling Motion Control, здесь доступны нейросети для создания презентаций, решения задач, генерации изображений. Удобно, когда всё в одном месте.

Как создать видео танцующего малыша: пошаговая инструкция

Разберём процесс создания танцующего видео через Kling Motion Control.

Шаг 1: Подготовка фото

Выберите фотографию ребёнка (или любого другого персонажа). Требования к фото:

• Чёткое изображение, без размытия
• Персонаж в кадре полностью или хотя бы по пояс
• Хорошее освещение, детали видны
• Желательно простой фон (чтобы нейросеть не отвлекалась на сложные детали)
• Поза близка к начальной позе в референсном видео

Лучше всего работают портретные фото, где ребёнок стоит анфас или в лёгком повороте.

Шаг 2: Выбор референсного видео

Найдите видео с танцем, который хотите перенести. Варианты:

• Загрузить видео с YouTube (скачайте через любой сервис)
• Снять референс самостоятельно

Референсное видео должно быть:

• Длиной 5-15 секунд (оптимально 8-10 секунд)
• С чётко видимыми движениями
• Без резких обрезов и склеек

Шаг 3: Загрузка в Kling Motion Control

На Study24.ai, выберите раздел Kling Motion Control. Загрузите:

1. Ваше фото (кадр, который будет "оживлен")
2. Референсное видео (откуда берутся движения)

Шаг 4: Настройка параметров

Kling Motion Control даёт несколько опций. Можно написать в промпте:

• Motion strength (сила переноса движений) — насколько точно повторять референс. 100% — максимальное соответствие, 50% — более свободная интерпретация.
• Camera motion (движение камеры) — переносить ли движения камеры из референса. Включайте, если в референсе есть зум или панорамирование.
• Quality — качество финального видео. Высокое качество дольше генерируется, но результат лучше.

Для танцующего ребёнка рекомендую: Motion strength 80-90%, Camera motion включен, Quality на максимум.

Шаг 5: Генерация видео

Нажмите кнопку генерации. Kling Motion Control создаёт видео за 3-8 минут в зависимости от длины и сложности референса.

Шаг 6: Скачивание результата

Когда видео готово, скачайте его в формате MP4. Kling сохраняет видео в разрешении 720p или 1080p (в зависимости от подписки).

Готовые промты для создания танцующих видео

Kling Motion Control работает немного иначе, чем текстовые нейросети. Здесь не нужны детальные промпты — главное правильно подобрать фото и референсное видео.

Но можно добавлять текстовые подсказки для улучшения результата. Вот проверенные промты:

Промт 1: Танцующий малыш (классический)

Этот промт подходит для создания видео танцующего ребёнка с естественными движениями. Используйте его с любым референсным видео детского танца.

Промт 2: Танцующий кот (юмористический)

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

Промт 3: Танцующая собака (энергичный стиль)

Видео где собаки танцуют ИИ создаёт отлично, если использовать энергичные танцевальные референсы. Добавьте детали породы: "golden retriever", "husky", "corgi" для точности.

Промт 4: Девочка танцует (балет)

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

Промт 5: Танцующий мальчик (хип-хоп)

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

Идеи для создания видео через Kling Motion Control

Kling Motion Control подходит не только для танцев. Вот другие идеи использования технологии переноса движений:

1. Исторические персонажи оживают

Возьмите фото исторической личности (Эйнштейн, Леонардо да Винчи, Пушкин) и создайте видео, где они танцуют современные танцы или делают смешные жесты. Отлично для образовательного контента с юмором.

2. Питомцы повторяют ваши движения

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

3. Ребёнок в роли профессионального танцора

Используйте референсы из профессиональных танцевальных выступлений. Ваш малыш будет «танцевать» как участник шоу «Танцы» или балерина Большого театра.

4. Семейные мемы

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

5. Оживление детских рисунков

Нарисуйте персонажа (или возьмите детский рисунок), сфотографируйте и создайте видео, где рисунок танцует. Магия для детей — их творения оживают.

6. Корпоративные поздравления

Фото руководителя компании + весёлый танцевальный референс = оригинальное новогоднее поздравление для коллектива.

7. Тренды для TikTok и Reels

Берёте популярный танец из TikTok, переносите на своё фото — и ваш контент готов. Не нужно реально снимать танец, достаточно фотографии.

Для чего нужна Kling Motion Control: 5 практических применений

1. Контент для соцсетей без съёмок

Самое очевидное применение — создание вирусного контента. Видео танцующего ребёнка, кота, собаки набирают миллионы просмотров в TikTok, Instagram Reels, YouTube Shorts.

Раньше для этого нужно было:

• Реально научить ребёнка танцевать (или снимать сотни дублей)
• Мучиться с питомцем, который не хочет сотрудничать
• Тратить время на монтаж

Теперь: одно фото + референсное видео = готовый ролик за 5 минут.

2. Образовательные проекты

Оживление исторических фотографий для образовательных видео. Представьте урок истории, где Пётр I танцует, Екатерина II делает жесты, а Ломоносов показывает движения.

Это работает и для науки: создайте видео, где динозавр двигается по референсу современной ящерицы, или клетка выполняет процесс митоза с анимированными движениями.

3. Персонализированные подарки

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

4. Креативная реклама и маркетинг

Малый бизнес часто не может позволить профессионального видеопродакшн. Kling Motion Control решает эту проблему:

• Фото продукта + танцевальный референс = вирусная реклама
• Логотип компании оживает и двигается
• Маскот бренда танцует в роликах

5. Развлекательный контент для детей

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

Технические особенности и ограничения Kling Motion Control

Что Kling Motion Control делает отлично

Перенос простых танцевальных движений
Классические танцы, хип-хоп, детские танцы — всё это Kling переносит почти идеально. Движения плавные, без артефактов.

Работа с портретами
Если референс и фото — оба портретные (человек виден по пояс или в полный рост), результат получается максимально качественным.

Сохранение черт лица
В отличие от многих нейросетей для видео, Kling Motion Control хорошо сохраняет внешность персонажа с исходного фото. Лицо узнаваемо на всём протяжении видео.

Где могут быть проблемы

Сложные акробатические движения
Если референс содержит сложную акробатику (сальто, стойки на руках), нейросеть может создать искажения. Лучше использовать более простые движения.

Несоответствие ракурсов
Если на фото человек в профиль, а в референсе анфас — результат будет хуже. Старайтесь подбирать фото и референс с похожими ракурсами.

Очень быстрые движения
Супер-быстрые танцы с резкими движениями могут создавать размытие и артефакты. Motion strength в таких случаях лучше снизить до 70%.

Длинные видео
Максимальная длина видео — 10 секунд. Для создания длинного танцевального ролика придётся генерировать несколько сегментов и склеивать в редакторе.

Частые вопросы про Kling Motion Control

Сколько времени генерируется видео?

От 3 до 8 минут в зависимости от длины референса и качества. Короткие видео (5 сек) генерируются быстрее, длинные (10 сек) — дольше.

Какой формат видео на выходе?

MP4, разрешение 720p или 1080p. Можно дальше обработать в любом видеоредакторе при необходимости.

Работает ли с животными?

Да, но результат зависит от позы. Если кот или собака на фото в позе, похожей на начало референса — будет отлично. Если сильное несоответствие (референс — человек стоит, фото — кот лежит) — могут быть артефакты.

Можно ли использовать свои видео как референс?

Да, загружайте любые видео. Можете снять свой танец и перенести движения на фото ребёнка.

Нужен ли VPN для работы?

Через Study24.ai — нет. Платформа работает из России без VPN. Если заходите напрямую на китайский Kling AI — нужен VPN и китайский номер.

Можно ли создать видео где танцуют несколько персонажей?

Можно, но лучше не включать больше 2-3 персонажей.

Заключение

Kling Motion Control изменил подход к созданию танцевальных видео через ИИ. Технология переноса движений из референсного видео даёт полный контроль над результатом — вы точно знаете, какой танец получится, потому что видели исходник.

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

Study24.ai предоставляет удобный доступ к Kling Motion Control без VPN и китайских номеров. Платформа объединяет лучшие ИИ-инструменты в одном месте — кроме создания видео, здесь доступны нейросети для учёбы, генерации изображений, решения задач.

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

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

Начиная с 22 декабря 2025 года, ее больше нельзя будет скачать. Ни через Toolbox App, ни через другие официальные каналы. Разработка и выпуск обновлений также прекращаются.

При этом JetBrains подчеркивает: речь идет не о провале эксперимента, а о смене стратегии. Команда Fleet, технологическая база и наработки никуда не исчезают — вместо IDE компания готовит новый продукт, ориентированный на агентную разработку.

Почему Fleet не взлетела как IDE

Fleet задумывалась как попытка переосмыслить IDE JetBrains через более легкую архитектуру, современный UI и отказ от наследия IntelliJ Platform.

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

Однако как самостоятельный продукт, Fleet не смогла занять четкую нишу. Она не смогла заменить IntelliJ IDEA и другие IDE JetBrains, но и не предложила достаточно убедительных преимуществ, чтобы существовать параллельно с ними.

Пользователи постоянно спрашивали, какую IDE выбирать. А наличие двух схожих линеек только усиливало путаницу.

Ставка на ИИ тоже не спасла Fleet

JetBrains пыталась перепозиционировать Fleet как AI-first редактор. Команда экспериментировала с новыми сценариями и проводила масштабные пользовательские исследования.

Вывод оказался неприятным, но честным: еще один ИИ-редактор не имеет шансов выделиться на фоне десятков ИИ-ориентированных форков VSCode.

В результате JetBrains решила сосредоточить развитие ИИ-функций внутри уже существующих IDE, где они действительно приносят ценность.

Новый фокус — агентная разработка

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

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

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

Поэтому JetBrains и решила не «втискивать» агентные сценарии в IDE, а создать отдельную среду разработки для ИИ-агентов. Именно в этом виде Fleet получила вторую жизнь — но уже под новым именем и с другим позиционированием.

Что будет с текущими пользователями Fleet

Если Fleet уже установлена, ею можно продолжать пользоваться. Однако обновлений больше не будет. А функции, завязанные на серверные сервисы JetBrains — включая AI Assistant — со временем могут перестать работать.

JetBrains обещает отдельно рассказывать о новом продукте по мере его разработки.

Компании выпускают ассистентов, автономные фреймворки и целые цепочки инструментов для автоматизации рабочих процессов.

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

Чтобы изменить ситуацию, OpenAI, Anthropic и Block объявили о создании Agentic AI Foundation (AAIF) — нового фонда под управлением Linux Foundation, который займется развитием открытых стандартов для ИИ-агентов.

Поддержку инициативе оказывают Google, Microsoft, AWS, Bloomberg и Cloudflare.

MCP, Goose и AGENTS.md объединяют в один стандарт

В рамках AAIF свои ключевые технологии передали сразу три компании:

• MCP (Model Context Protocol) от Anthropic — стандарт связи между агентами и внешними инструментами. За год появилось уже более 10 000 MCP-серверов, а Microsoft встроила поддержку MCP прямо в Windows и Visual Studio. Это превращает агентов в «первоклассных граждан» ОС и упрощает автоматизацию разработки.
• Goose от Block — локальный агентный фреймворк, способный работать на устройстве пользователя без облака. Он использует MCP как базовый коммуникационный слой.
• AGENTS.md от OpenAI — открытый формат, который стал «README для ИИ-агентов». Файл описывает проект в машинно-читаемом виде: тесты, сборку, архитектуру, стили кода, политику безопасности и рабочие процессы. Формат уже используют 60 000+ open-source проектов, включая VS Code.

Зачем это индустрии

Майк Кригер из Anthropic подчеркивает, что передача MCP под управление Linux Foundation гарантирует нейтральность стандарта.

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

Что значит создание AAIF для рынка

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

Это шаг к единой экосистеме, где агенты смогут взаимодействовать с инструментами, IDE, операционными системами и сервисами. И все это без кастомных протоколов и закрытых API.

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

Но теперь эта «шутка» стала наглядной — проект Stacktower превращает рисунок в настоящую визуализацию зависимостей.

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

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

Как работает Stacktower

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

Пользователь может загрузить зависимости своих приложений — например, на Python или JavaScript — и увидеть, что будет, если убрать даже один элемент.

На странице приводится пример для Node.js:

приложение зависит от Express → Express зависит от body-parser → body-parser зависит от qs → и так далее

Stacktower иллюстрирует, что даже простое приложение тянет десятки модулей, часто неподконтрольных разработчику.

Есть и Python-вариант:

импорт Flask тянет Werkzeug, Jinja2, MarkupSafe, Click и еще несколько пакетов. А те, в свою очередь, имеют собственные зависимости.

Зачем это нужно

Автор подчеркивает: цель проекта — не критиковать экосистемы, а показать их реальное устройство.

Стек современных приложений неизбежно сложен и даже крошечный модуль может стать критически важным. Именно так в 2022 году случайное удаление библиотеки left-pad временно «сломало» огромный кусок JavaScript-мира.

Stacktower превращает эту абстрактную проблему в понятный визуальный эффект: убираешь одну зависимость — рушится вся конструкция.

Комьюнити уже подхватило идею

Проект быстро разошелся по Reddit, Hacker News и X: разработчики делятся скриншотами своих «башен», спорят о хрупкости экосистем и обсуждают, стоит ли пересматривать подход к зависимости.

Кто-то предлагает добавить поддержку Rust и Go, другие мечтают о корпоративной версии инструмента для визуального аудита безопасности.

Изучить проект подробнее можно на его странице на GitHub.

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

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

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

Как отреагировали пользователи

В комментариях — смесь паники, иронии и технического разбора.

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

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

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

Были и попытки восстановить данные. Некоторые реддиторы посоветовали остановить запись на диск, использовать инструменты восстановления и проверить, формировались ли системные точки бэкапа.

Почему инцидент тревожит

Antigravity — относительно новая IDE Google. Она активно продвигается как «инструмент нового поколения» с интегрированным ИИ-ассистентом, автоматическим рефакторингом, «умными» рабочими областями.

Однако именно высокая степень автоматизации и может приводить к опасным ошибкам конфигурации.

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

В сети появился материал, автор которого — программист с 20+ летним стажем — вспоминает, как еще в 90-е взрослые уверяли его, что программирование обречено.

Тогда активно утверждалось, что ООП решит все проблемы раз и навсегда: появятся библиотеки-«кирпичики», а бизнес просто будет собирать приложения как LEGO, вообще без инженеров.

Прошли десятилетия, а профессия не только не исчезла — она стала одной из самых востребованных. Каждый уровень абстракции, который должен был «убить» разработчиков, просто поднимал планку и открывал новые задачи.

Мультимедиа, IDE и другие «концы света», которые не случились

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

Но через несколько лет это стало обыденностью — просто очередным <video /> в HTML. Никто массово не разорился из-за отсутствия мультимедиа в продуктах.

В 2000-х на горизонте появился новый «убийца профессии» — умные IDE вроде IntelliJ. Автодополнение, рефакторинг, перенос классов, исправление ошибок до сборки — все это казалось магией, которая вот-вот заменит людей.

Но инструменты лишь ускорили работу, а не забрали ее. IDE прекрасно переставляет код, но не пишет новую логику.

Автоматизация в реальности: она освобождает время, а не людей

Автор приводит два примера: он автоматизировал работу контрактника, мигрировавшего базу MUMPS, и автоматизировал собственные задачи по обновлению сайтов, боясь потерять работу. В обоих случаях люди остались на своих местах — просто стали заниматься чем-то другим.

Вывод простой: работы становится не меньше, а больше. Автоматизация убирает рутину, но не отменяет необходимости решать новые проблемы.

Новые ввения приходят и уходят, но разработка остается

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

Текущая волна ИИ — не исключение. Да, большие языковые модели меняют рабочие процессы. Да, они автоматизируют часть задач.

Но автор призвал быть честными с самими собой: такие сдвиги редко уничтожают профессию. Они скорее превращают ее в новую версию самой себя.

Вместо финала: ИИ не убьет разработчиков, но сделает их работу другой

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

Как и последние 30 лет, разработка остается живой потому, что мир постоянно усложняется. А значит — всегда будет кому этот мир программировать.

Задача в целом проста:

1. Открыть структуру таблицы
2. Скопировать названия колонок
3. Соотнести типы, которые существуют в спецификации (gRPC, OpenAPI, и т.п.)
4. Описать API метод
5. Проверить на соответствие стайл-гайду

Но это утомительно и отнимает драгоценное время разработчиков. Данную инструкцию за нас может выполнить инструмент db-exporter. В этой статье рассмотрим, как с его помощью автоматизировать процесс генерации CRUD-операций для gRPC, соблюдая стандарт Google AIP по ресурсно-ориентированному дизайну.

В последующих разделах мы подробно рассмотрим:

• Принцип работы db-exporter
• Процесс настройки и конфигурации
• Примеры генерации различных типов операций
• Валидацию сгенерированных proto файлов
• Как внедрить инструмент для постоянной работы с ним

Знакомимся с инструментом

db-exporter — это Open Source утилита для генерации кода и документации к схеме базы данных. «Экспортировать» можно в различные распространенные форматы: диаграмма классов, protobuf, код на Go и другие. На данный момент инструмент поддерживает PostgreSQL и MySQL. Реализована поддержка основных операционных систем. Инструмент достаточно молодой и активно развивается.

Для начала работы с db-exporter необходимо скачать его со страницы релизов. Далее разархивировать и переместить в /usr/local/bin. Или выполнить всё одной командой.

Mac OS

Linux

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

Составим пример

Договоримся, что нашим примером для генерации кода будет являться таблица пользователей. У пользователей есть: id, имя, отчество, дата создания, статус (активен, заблокирован) и дата удаления.

Итого, схема выглядит так:

Данного примера достаточно для того, чтобы рассмотреть ключевые моменты:

• Генерация первичных ключей (поле id)
• Генерация опциональных полей (поле middle_name)
• Генерация временных меток (поля created_at, deleted_at)
• Генерация енамов (поле status, енам user_status)
• Работа с soft-delete

Генерируем protobuf

Для того, чтобы запустить db-exporter необходимо описать конфигурацию —делается это декларативно, в yaml-файле. db-exporter оперируют задачами, в которых описаны:

• Формат, в котором нужно выполнить генерацию. В нашем случае — это grpc-crud
  

• Директория, в которую сохранить файлы
• Специфичные формату параметры (далее: спека задачи)

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

Итого, конфигурация, описывающая перечисленные требования, выглядит следующим образом:

Сохраняем этот файл, как .db-exporter.yaml.

Далее запускаем инструмент, выполняя команду db-exporter и получаем отчет о проделанной работе — db-exporter сообщает о том, какие файлы были созданы и какой они имеют вес.

Разбираемся, что получили на выходе

В результате выполнения команды был сгенерирован файл users.proto, в котором используется синтаксис соответствует proto3. Файл содержит:

• UsersService с методами List, Get, Delete, Undelete, Create, Patch
• Сообщение User, отражающее таблицу users
• Енам UserStatus

Сообщение User и enum UserStatus

Сообщение User отражает структуру таблицы users и имеет вид:

Что здесь видим?

1. id - uuid'ы генерируются, как строки. Первичный ключ помечается, как OUTPUT_ONLY, говоря о том, что поле используется только для ответов.
2. name, email сгенерированы, как строки
3. Поля created_at, deleted_at обернуто в гугловый Timestamp
   
4. Для статуса пользователя сгенерирован енам UserStatus

UserStatus выглядит следующим образом

Метод для получения списка пользователя

Метод List принимает на вход ListUsersRequest и возвращает ListUsersResponse

Запрос включает в себя поле с массивом идентификаторов пользователей. db-exporter добавляет в тело запроса первичный ключ, если первичный ключ состоит из одного поля. Также в запросе присутствует флаг show_deleted, как того требует стандарт AIP-132, при работе с сущностями, поддерживающими soft-delete: по умолчанию сервер возвращает список активных пользователей, например, используя sql-запрос с фильтром deleted_at is null.

По умолчанию db-exporter добавляет token-based пагинацию, описанную в AIP-158. Такая пагинация удобна для межсервисного взаимодействия. Но если основной клиент вашего API — это фронтенд, то вероятнее всего, вам нужна офсетная пагинация. Ее можно включить, добавив в спеку задачи pagination: offset. Если пагинация уж совсем не требуется, то pagination: none.

В ответе же список пользователей и токен следующей страницы.

Метод получения пользователя

Стандарт по получению ресурса описывает достаточную простую конструкцию — Метод Get принимает на вход GetUserRequest и отдает на выход сообщение User.

Тело запроса включает в себя поле id, так как оно является первичным ключом.

Методы удаления и восстановления пользователя

Стандарт AIP-164 гласит: мало того, что сущность удаляется методом Delete, так еще нужно и мочь ее восстанавливать с помощью метода Undelete, если таблица поддерживает soft-delete.

Поэтому в результате генерации мы получаем методы Delete и Undelete: db-exporter самостоятельно определяет поддержку soft-delete у таблиц, смотря на поля deleted_at и delete_time.

Метод Delete принимает на вход DeleteUserRequest и отдает на выход DeleteUserResponse. Метод Undelete принимает UndeleteUserRequest и возвращает восстановленный ресурс User.

Тела запросов также, как и для метода Get, содержат поле первичного ключа — id.

По умолчанию возвращается google.protobuf.Empty, как требуется в стандарте. Возможна генерация пустого сообщения DeleteUserResponse — для этого нужно добавить параметр в спеку:

Методы создания и обновления пользователя

По стандартам AIP-133 и AIP-134 методы Create и Update имеют похожие сигнатуры.

Тела запросов также схожи, включают в себя ресурс User и возвращают его обновленную версию.

По стандарту поле update_mask предполагается использовать для частичного обновления сущности. FieldMask содержит в себе список полей, которые необходимо обновить у сущности User.

Добавляем HTTP пути к методам

В gRPC есть полезная опция google.api.http, с помощью которой можно указать HTTP адрес для метода. Ее полезно использовать, если вы используете REST поверх gRPC сервисов — например, с помощью grpc-gateway.

Наверняка, мы хорошие разработчики и версионируем свой API: установим версию v1 в параметре path_prefix.

И получаем вот такой результат:

Валидируем результат

Теперь, когда у нас есть файл users.proto — важно проверить, что он корректен синтаксически. Для этого соберем go-клиент, используя утилиту protoc.

Указываем Go пакет

Выше мы обсуждали gRPC контракты без привязки к конкретному стеку. Ну что ж, время пришло!

Для генерации Go-клиента в .proto файле необходимо указать опцию go_package. Мы можем сами поправить .proto файл, но при частом использовании db-exporter это будет не так удобно, поэтому скажем экспортеру, какой пакет нам нужен. Для этого нужно указать опцию в спеке задачи .db-exporter.yaml:

Нам остается еще раз сгенерировать users.proto, используя уже знакомую команду db-exporter.

Собираем зависимости

Сгенерированный users.proto импортирует зависимости google.api для указания HTTP методов/путей, обязательности полей. Их можно скачать с GitHub googleapis: http.proto, field_behavior.proto и annotations.proto.

Скачать зависимости можем следующим скриптом:

Итого мы должны были организовать следующую структуру файлов:

Теперь запустим генерацию гошного кода:

В результате выполнения команды в наш проект добавились 2 новых файла:

• pkg/api/users.pb.go — структуры для ресурса, запросов и ответов
• pkg/api/users_grpc.pb.go — rpc-сервис UserService и клиент к нему

Вывод: из сгенерированного db-экспортером .proto файла можно сгенерировать валидный програмнный код. Считаем проверку успешно выполненной

Непрерывная генерация

Перезапись файлов

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

Теперь db-exporter не будет перезаписывать уже существующие файлы и будет генерировать только новые.

Генерация лишних таблиц

По умолчанию db-exporter генерирует файлы по всем таблицам из схемы БД. В проекте может десяток или десятки таблиц, не для всех из них нужна генерация CRUD-операций. Генератору можно передать список таблиц, по которым необходимо генерировать файлы.

Но править постоянно конфиг не очень удобно. Укажем переменную.

Теперь мы можем запускать генерацию по конкретным таблицам, например вот так:

Или обернуть это в Makefile:

Использовать эту конструкцию можно следующим образом:

Что в итоге?

В итоге мы собрали рабочую конфигурацию db-exporter, которая позволяет генерировать CRUD по схеме БД в валидный .proto файл, включая полезные опции: google.api.field_behavior и google.api.http. Собранную конфигурацию и необходимое окружение вы сможете найти по этой ссылке.

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

В репозитории вы также сможете найти примеры генерации диаграмм классов, mermaid, markdown и так далее.

Модель уже встраивают почти во все ключевые продукты Google — от поиска до инструментов для разработчиков.

Что такое Gemini 3

Gemini 3 представляет из себя новое семейство моделей. Основным флагманом в нем выступает Gemini 3 Pro, а для сложных задач появится отдельный режим Gemini 3 Deep Think.

По сути, это эволюция сразу в трех направлениях:

• Мультимодальность — текст, код, картинки, видео, аудио в одном стеке.
• Reasoning и «глубокое мышление» — лучше решает сложные задачи по науке, математике и планированию.
• Агентность — модель умеет не только отвечать, но и выполнять цепочки действий: работать с браузером, почтой, кодом.

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

Чем Gemini 3 отличается от 2.5

По заявлениям Google, Gemini 3 Pro:

• заметно обгоняет Gemini 2.5 Pro в большинстве бенчмарков по математике, логике, точности фактов;
• лучше понимает контекст и намерение — нужно меньше «танцев с промптами»;
• умеет генерировать код для сложных визуализаций, интерфейсов и 3D-сцен;
• работает как «thought partner» — пытается сокращать воду и говорить по делу, а не льстить.

Отдельный режим Gemini 3 Deep Think дает еще больший прирост в задачах на логику и новизну, но пока доступен только безопасностным тестерам. Позже появится и у подписчиков Google AI Ultra.

Где уже можно попробовать

Gemini 3 начинают раскатывать сразу «в масштабах Google»:

• Поиск (AI Mode в Search) — генерируемые ответы, визуальные раскладки, интерактивные элементы, симуляции.
• Приложение Gemini — для обычных пользователей и подписчиков Google AI Pro/Ultra.
• Для разработчиков: Google AI Studio, Vertex AI, Gemini CLI, новый агентный IDE-платформер Google Antigravity.
• Интеграции: Cursor, GitHub, JetBrains, Replit и другие сторонние инструменты.

Google Antigravity: агент как напарник, а не просто советчик

Отдельно Google показала Antigravity — «agent-first» платформу для разработки:

• агент получает доступ к редактору, терминалу и браузеру;
• может сам планировать и выполнять end-to-end задачи (например, собрать приложение, проверить, запустить, поправить баги);
• под капотом — Gemini 3 + специализированная модель для управления компьютером и модель для работы с картинками.

Идея простая: разработчик формулирует цель, а не последовательность команд.

Безопасность и «шаг к AGI»

Google утверждает, что Gemini 3 — их «самая проверенная» и «самая безопасная» модель:

При этом в компании также заявляются: Gemini 3 это крупный шаг к более общему интеллекту, а не просто очередная версия чат-бота.

Пока нейросеть пишет код, программист может смотреть TikTok, листать Tinder или играть в мини-игры.

Проблема, о которой никто не говорил

Создатели Chad IDE заявляют, что современные инструменты вроде GitHub Copilot породили новую форму «кризиса продуктивности». Мол пока ИИ пишет код, разработчик вынужден просто ждать.

Исследование команды показало, что 87% инженеров в этот момент тянутся к телефону. И, по данным самих авторов, теряют по 5–10 минут на пролистывание соцсетей после каждой генерации.

Так появился концепт «engagement-driven development» — разработки без скуки.

Как это работает

Chad IDE добавляет в окно разработки развлечения «с пользой для фокуса». Ключевая идея — не дать разработчику покинуть IDE, но при этом удержать внимание в контексте проекта.

Основные функции

• Active Generation Monitoring — визуализирует процесс генерации кода, добавляя анимации и контекстные подсказки.
• Micro-Interactions — легкие интерактивные элементы, которые не мешают, но отвлекают от телефона.
• Context Preservation — IDE «напоминает», над чем вы работаете, даже если вы смотрите видео.

Интеграции

Chad IDE поддерживает сервисы, которые обычно отвлекают. Теперь они используются «для концентрации»:

• TikTok и *Instagram Reels — вертикальные видео прямо в редакторе, автопауза при фокусе на коде.
• YouTube Shorts — подборка видео о программировании.
• Tinder — свайпы с «кодовыми» айсбрейкерами для разработчиков.
• Мини-игры — казуальные игры во время компиляции.

Авторы уверяют, что эти функции не мешают, а наоборот — предотвращают контекстные переключения.

Эффект: «меньше скуки — больше кода»

По данным внутреннего тестирования:

• количество отвлечений снизилось на 43%;
• время, потерянное на телефон, сократилось на 2,3 часа в день;
• продолжительность «состояния потока» выросла на 67%;
• а раздражение из-за долгих генераций — на 89% меньше.

Один из тестировщиков из *Meta назвал IDE «фиджет-спиннером для мозга, который держит тебя в контексте кода».

*Компания Meta и ее продукты признаны экстремистскими, их деятельность запрещена на территории РФ

Релиз вышел одновременно с .NET 10, который стал версией с долгосрочной поддержкой (LTS).

Что нового в Visual Studio 2026

По данным Microsoft, в новую версию вошло более 300 новых функций и 5000 исправлений ошибок, собранных по запросам сообщества. IDE получила обновленный дизайн на базе Fluent UI с 11 новыми темами и улучшенной производительностью.

Компания заявляет, что время загрузки проектов и зависания интерфейса сократились более чем на 50%, а общая отзывчивость среды разработки заметно выросла.

Главные изменения:

• интеграция GitHub Copilot во все части среды разработки;
• ускоренное открытие крупных проектов;
• переработанная система обновлений — теперь IDE обновляется отдельно от инструментов сборки;
• полная совместимость с более чем 4000 расширениями от Visual Studio 2022;
• поддержка новых инструментов для анализа кода и тестирования.

Отдельное обновление инструментов

Одно из самых ожидаемых нововведений — развязка Visual Studio и build tools.

Раньше обновление IDE приводило к изменению инструментов сборки и могло ломать рабочие процессы. Теперь разработчики могут получать ежемесячные апдейты Visual Studio с новыми функциями, не затрагивая цепочку сборки.

Релиз .NET 10

Одновременно с IDE вышел .NET 10 — LTS-релиз, который будет поддерживаться до 10 ноября 2028 года.

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

Компания рекомендует разработчикам как можно скорее перейти на новую версию, особенно для рабочих приложений. В процессе миграции можно использовать GitHub Copilot, который помогает адаптировать существующие проекты под .NET 10.

Почему это важно

Visual Studio 2026 делает ставку на скорость, стабильность и интеграцию с ИИ.

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

В ближайшие месяцы IDE получит поддержку многоагентной работы, улучшенный чат и доступ к новой модели GPT-5 Codex.

Компания отмечает, что это не гарантированный план релизов. Скорее он дает представление о том, как будет развиваться ИИ-экосистема Visual Studio.

Что появится в ближайшее время

Агентный режим и кастомные агенты

Microsoft тестирует возможность создавать собственных агентов — например, тестового и отладочного. Также рассматривается запуск нескольких Visual Studio Agents одновременно, чтобы выполнять параллельные задачи.

Режим чата с памятью и slash-командами

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

Интеграция с MCP

Visual Studio получит полную поддержку Model Context Protocol, который позволит подключать собственный dev-стек и MCP-серверы безопасно.

Среди улучшений — оптимизация производительности, белые списки серверов и единый UX для MCP-сервисов.

Модели нового поколения

Microsoft также работает над функцией Auto Model, которая позволит IDE самостоятельно выбирать оптимальную модель под задачу.

Но главное обновление — интеграция GPT-5 Codex, которая будет отвечать за контекстные подсказки и автодополнение кода.

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

Об этом рассказал глава прикладного и инженерного направлений ChatGPT Сулман Чоудри в беседе с Гергели Оросом, автором известной техрассылки The Pragmatic Engineer.

По словам Ороса, в OpenAI активно развивается новая модель — связка «super senior + super junior». Опытный инженер отвечает за архитектуру и стратегические решения, а «супер-джун» берет на себя скорость и гибкость. Он использует ИИ-инструменты на уровне, недоступном старшим коллегам.

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

Эти специалисты — представители нового поколения «AI-native» инженеров, для которых взаимодействие с языковыми моделями — базовый навык, сродни владению Git или терминалом.

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

Программы OpenAI для ранней карьеры

Все это логично вписывается в собственные инициативы OpenAI — Residency и Emerging Talent. Там прямо говорится, что компания берет людей «на переходе» между non-tech и IT, если они способны быстро осваивать инженерные принципы с помощью ИИ.

«Мы ищем людей, которые думают, как инженеры, даже если у них нет традиционного опыта разработки», — говорится в описании программ.

Контраст с рынком

На общем фоне это решение выглядит почти парадоксально. 2025-й стал годом, когда большинство IT-компаний сократили junior-позиции: автоматизация и рост LLM-ассистентов сделали базовую разработку избыточной. Но OpenAI, наоборот, делает ставку на специалистов, выросших в новой парадигме — тех, кто умеет кодить через ИИ, а не вместо него.

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

Об этом рассказал Логан Килпатрик, продакт-лид Google AI Studio, в посте на X.

Что такое вайб-кодинг

Термин vibe coding (от англ. vibe — «ощущение», «настроение») появился в 2024 году и описывает подход к программированию, где разработчик не пишет код вручную, а общается с ИИ в свободной форме, задавая лишь общие направления: «сделай RPG про кота-самурая», «добавь погодные эффекты», «пусть враги становятся умнее».

Пока этот подход работал только с простыми проектами вроде сайтов и мобильных приложений, но Google обещает вывести его на новый уровень.

Что умеет новый AI Studio

По словам компании, обновленный Google AI Studio «понимает задачу и автоматически подбирает нужные модели, API и инструменты».

Например, если пользователь захочет сделать приложение, генерирующее изображения по промтам, AI Studio сам подключит соответствующий API (в данном случае — Nano Banana API) и настроит всю инфраструктуру.

«Мы сделали процесс создания мощных, функциональных и ИИ-дополненных приложений максимально простым», — говорится в блоге Google.

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

Теперь и для игр

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

«Это откроет путь для новых 100 млн разработчиков. Многие мечтают сделать игру, но спотыкаются о C++, C# и Unreal Engine. Теперь они смогут создавать истории, персонажей и геймплей — без единой строчки кода», — написал он.

Разумеется, до уровня Civilization или Baldur’s Gate дело не дойдет. По словам Килпатрика, речь идет о «небольших проектах для друзей», где игроки сами управляют сюжетом и механикой.

Скепсис и ожидания

Пока даже самые продвинутые ИИ-инструменты едва справляются с генерацией простых 2D-игр вроде Wordle или Flappy Bird.

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

Тем не менее, Google, по слухам, готовит к релизу Gemini 3.0, который может радикально улучшить креативные и кодогенерационные возможности.

Если планы компании сбудутся, то к концу года видеоигра мечты может начаться не с кода, а с фразы:

«Сделай мне космический шутер, где коты сражаются против пылесосов».

Среднее время активного использования встроенного дебаггера — 1,4% от общего времени кодинга. Это примерно 13 минут в месяц.

В то же время медианное значение и того меньше — всего 0 минут. Это означает: большинство разработчиков не открывали отладчик вообще.

Console.log правит миром

Как выяснилось, в 75% случаев разработчики никогда не ставили брейкпоинты, предпочитая старый-добрый console.log().

Остальные использовали отладчик лишь эпизодически: 10% — менее одного процента времени, и только 15% — чаще, чем раз в месяц.

В среднем структура работы выглядела так:

• 46,2% времени — написание кода, включая «отладку логами»;
• 28,7% — чтение и анализ чужого кода и стектрейсов;
• 23,7% — рефакторинг и удаление отладочных вставок;
• 1,4% — работа в интерфейсе отладчика VS Code.

Почему так происходит

Исследователи называют феномен «психологией мгновенного отклика»:

Сonsole.log("here") дает результат через 3 секунды. Настроить дебаггер — 10 минут. Мозг выбирает дофамин, а не дисциплину.

Среди других причин — привычка («мы изучали console.log с первого дня»), кажущаяся сложность интерфейса и эффект «еще одной строчки лога». Это когда проще добавить еще один console.log, чем переключаться в режим пошаговой отладки.

Что это значит

Исследование не утверждает, что разработчики не отлаживают код — просто делают они это вручную. В среднем около 15–20% рабочего времени уходит на расстановку логов, чтение вывода и перезапуск приложения.

Авторы FlouState считают, что освоение встроенного дебаггера могло бы сократить этот цикл в разы. Но для большинства программистов console.log() остается самым надежным и быстрым инструментом.

«VS Code имеет отладчик мирового уровня. Мы просто им не пользуемся», — подытожил автор исследования.

В подкасте Dwarkesh Podcast он назвал идею полностью независимых ИИ-агентов «мечтой, но не рабочей технологией».

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

По его оценке, на решение всех этих проблем уйдет около 10 лет.

Переоцененные «агенты»

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

Но Карпати считает, что индустрия перепрыгнула через собственные возможности. В посте на X он уточнил:

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

Вместо замены — сотрудничество

Карпати выступает за совместную работу человека и ИИ, а не за полную автоматизацию.

Я хочу, чтобы ИИ подтягивал документацию API, проверял корректность, спрашивал, если не уверен. Чтобы я учился вместе с ним, а не просто получал гору кода, который «вроде работает».

Главная угроза, по мнению инженера, заключается в том, что при попытке «исключить человека из цикла», мир рискует утонуть в AI slop — некачественном контенте и ошибочном коде, генерируемом ИИ без контроля.

Карпати — не скептик, но реалист

Несмотря на критику, Карпати подчеркивает, что остается оптимистом. Его прогнозы просто «в 5–10 раз осторожнее, чем у типичного участника ИИ-вечеринки в Сан-Франциско».

Эксперты соглашаются: автономные агенты пока не способны стабильно выполнять даже серию простых действий. По оценкам специалистов ScaleAI, при пяти последовательных шагах вероятность безошибочного выполнения всех действий не превышает 32%.

Так что мечта большого бизнеса о полностью автономных «ИИ-разработчиках» пока остается именно мечтой.

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

Рынок ИИ-помощников для разработчиков насыщен: от глобальных решений вроде GitHub Copilot, Cursor и Windsurf до локальных стартапов. Но, по известным причинам, многие западные инструменты сегодня недоступны российским разработчикам или требуют сложных обходных маневров.

В этой статье посмотрим, какие ИИ-помощники реально работают без VPN, поддерживают российские способы оплаты и достойно конкурируют с западными аналогами.

Как будем сравнивать

Чтобы сравнение было честным и полезным, определим критерии заранее:

• Доступность без VPN. Инструмент должен открываться и работать без «танцев с бубном». VPN не только неудобен, но и может быть нежелателен на рабочем месте.
• Стоимость и оплата картой. Возможность оплатить подписку российской картой или через локальные платежные сервисы — важный критерий. Отличный ИИ, к которому нельзя получить доступ легально, пользы не принесет.
• Поддерживаемые IDE. Важно, чтобы помощник интегрировался с популярными средами: JetBrains IDE (IntelliJ IDEA, PyCharm, и т.д), VS Code или хотя бы имел CLI для терминала.
• Режимы работы. Не только автодополнение кода, но и полноценный «агентный режим»: умеет анализировать проект, предлагать решения, выполнять несколько шагов подряд (например, найти баг → предложить фикс → сгенерировать тест).
• Поддержка русского языка. Разработчикам важно писать запросы и получать ответы на родном языке, особенно при обсуждении сложных ошибок или бизнес-логики.
• Поддержка языков программирования. Минимальный набор: Java, Kotlin, Python, JavaScript/TypeScript, SQL. Чем шире поддержка, тем лучше для команд с разносторонним стеком.
• Выбор моделей. Хорошо, если есть возможность выбрать между проприетарными (GPT-4, Claude, Gemini) и локальными моделями — для приватности и on-premise сценариев.

GigaCode

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

Сильные стороны:

• Поддерживает разные режимы code completion — от автодополнения одной строки до генерации целой функции.
• Есть режим чата для диалога с моделью.
• Работает почти везде: JetBrains IDE (и их российские аналоги — GigaIDE, OpenIDE), VS Code и даже Jupyter Notebook.

Но дальше начинаются нюансы. GigaCode крепко завязан на экосистеме Сбера:

• Просто скачать и начать пользоваться не выйдет — нужна регистрация через GitVerse.
• Никакого выбора моделей: какая именно работает под капотом — загадка, а свою подключить нельзя.
• Агентного режима нет совсем — а в 2025-м это уже must-have. Сейчас разработчики привыкли запускать агента решать задачу и параллельно делать что-то другое (или листать рилсы, не будем лукавить 😏).

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

Попробовать GigaCode.

Yandex SourceCraft Code Assistant

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

Плюсы:

• Нет обязательной регистрации — скачал и пользуешься. Это приятно.
• Поддерживаются те же IDE, что и у GigaCode, кроме Jupyter Notebook.

Минусы (всё те же):

• Нет агентного режима
• Нет выбора моделей; непонятно, какая модель работает внутри.

Иными словами, SourceCraft выглядит как более «легковесная» альтернатива GigaCode — без лишних барьеров при установке, но и без прорывных фич.

UPD: Пока мы писали эту статью, яндекс успел выпустить своего агента. Полноценно потыкать его не удалось, но здорово, что инструмент развивается.

Попробовать Code Assistant от Яндекс.

Qodo Gen (ранее Codium)

Пока готовил материал, удивился: не все западные аналоги в России мертвы. Некоторые работают, хоть оплатить их официально и нельзя. Qodo — как раз из таких.

По сравнению с GigaCode и SourceCraft это уже совсем другой уровень. Qodo — часть целого набора инструментов для разработчиков: ревью кода, тестирование, работа с Git и многое другое.

Что понравилось:

• Поддерживает все популярные IDE, включая JetBrains, VS Code и другие.
• Отличный UX — работать приятно.
• Агентный режим есть.
• Поддержка code completion, чата и даже режима планирования задач — редкая фича.
• Можно выбирать контекст и подключать MCP-тулы.
• Доступны современные, мощные модели.

Что не понравилось:

• Локальную модель подключить нельзя.
• Бесплатный лимит смешной — всего 75 токенов в месяц. При активной работе этого хватает на пару дней, а потом... карета превращается в тыкву.

Qodo оставляет приятное впечатление – ощущается как взрослый, продуманный инструмент. Жаль, что его полноценно использовать из России пока проблематично.

Попробовать Qodo Gen.

Cursor

Обойти Cursor в обзоре ИИ-ассистентов почти невозможно. Про него говорят буквально все, и удивительно, что его название ещё не стало нарицательным для любого AI-помощника. Скачать Cursor можно без VPN — сайт доступен. А вот с оплатой уже не так просто.

Cursor — это отдельная IDE на базе VS Code со встроенным ИИ. Для кого-то это плюс: полноценная среда с ассистентом «из коробки». Для меня — скорее минус. Хочется добавить ИИ в привычную IDE, а не пересаживаться на новую. Тем более, мир разработчиков не ограничивается одним VS Code. В JetBrains IDE, GigaIDE или OpenIDE Cursor вы не установите. Поэтому его уместность в таком обзоре для меня под вопросом, но раз все о нём говорят — упомянуть стоит.

Главная фишка — Rules. Можно задать собственные правила генерации кода: стиль, форматирование, комментарии, даже требование писать тесты. Если настраивать лень, есть готовые наборы. Это логично: Cursor позиционируется как полноценная AI IDE, а не просто плагин. Хотя, честно говоря, такие «профили правил», на мой взгляд, было бы полезно видеть и в других инструментах.

Из обязательного набора: агентный режим, поддержка MCP-тулов и широкий выбор моделей.

Попробовать Cursor.

Koda

Ещё один ассистент, который работает без VPN и сейчас полностью бесплатен. Это не отдельная IDE, как Cursor, а расширение к уже установленным средам. На данный момент плагин доступен в VS Code, для JetBrains IDE и их российских аналогов — GigaIDE и OpenIDE, обещают сделать в ближайшее время.

На старте дают 1 000 бесплатных токенов для топовых зарубежных моделей — заметно щедрее, чем, например, у Qoda (75 токенов). Когда лимит закончится, остаются доступными бесплатные модели, так что работа не прервётся.

Русский язык поддерживается полноценно: можно формулировать запросы, обсуждать бизнес-логику и разбирать ошибки без переключения на английский. На лендингах GigaCode и SourceCraft Code Assistant явного акцента на это не видно. Возможно, это действительно не так важно?

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

Интерфейс местами проще, чем у западных аналогов, но на фоне отечественных выглядит более продуманным: меньше кликов, понятный UX, аккуратные подсказки, правильная вставка кода.

С моделями гибко: можно подключить западных провайдеров (если есть доступ) или локальную модель. Из коробки доступны современные модели — не только западные, но и восточные; по некоторым бенчмаркам они показывают очень конкурентные результаты.

Попробовать Koda.

Подведём итоги

Прежде чем смотреть на таблицу, важно помнить: идеального ассистента нет. У каждого свои сильные и слабые стороны, а многое зависит от ваших задач, стека и привычек. Выбирайте то, что ближе именно вам — а в комментариях расскажите, чем пользуетесь сами и почему. Это поможет другим разработчикам быстрее сориентироваться в море инструментов.

Компания объясняет, что публичного кода для обучения ИИ-моделей недостаточно: он не отражает «реальные сценарии разработки».

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

Зачем это нужно

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

Внутренние тесты уже показали пользу от такого подхода. Теперь JetBrains пытается масштабировать эксперимент на внешние команды.

Условия участия

Соглашение на передачу данных появится в версии IDE 2025.2.4, которая выйдет в ближайшие недели.

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

Опасения разработчиков

Главный риск — случайная утечка интеллектуальной собственности. Прецеденты уже были: в 2022 году ИИ воспроизвел чужой код, использованный при обучении.

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

Контекст

JetBrains активно продвигает собственный AI-агент Junie, а также интегрирует сторонние решения, включая Claude 4.5 от Anthropic. Но пользователи жалуются на высокую стоимость новых тарифов.

• Тестовая среда: используйте последний стабильный релиз (например, 3.5.6; см. страницу Tags на GitHub).
• Staging (предпроизводственная) и Production (производственная) среды: используйте последний минорный релиз предыдущей стабильной ветки.
• Если требуется новый функционал или критическая фиксация, можно собрать из актуального кода ветки main, используя официальный Docker-образ сборочного окружения.
• Компонент BE (Backend) требует CPU с поддержкой AVX2. Возможна сборка без AVX2 (работоспособно, но не рекомендуется — нет полноценного покрытия тестами).
• Начиная с 1.19 StarRocks поддерживает ARM, но потребует самостоятельной сборки на ARM-хосте (официальные готовые бинарники под ARM пока не публикуются).

Справочные ссылки:

• Страница Tags (например, 3.5.6, 4.0.0-rc01): https://github.com/StarRocks/starrocks/tags
• Release Notes 1.19 (сообщество): https://forum.mirrorship.cn/t/topic/552

Ниже — пример сборки из актуального кода ветки main с использованием официального Docker-образа.

1. Установка Docker и загрузка сборочного образа

Для примера используется CentOS 7.6 в виртуальной машине (рекомендуется ≥2 vCPU и ≥4 ГБ RAM). Во время сборки требуется стабильное сетевое подключение.

1.1 Установка Docker

1.2 Запуск Docker и автозапуск

1.3 Проверка установки

При успешном выполнении отобразится сообщение “Hello from Docker!”.

1.4 Ускорение загрузки образов (для нестабильных каналов)

Если загрузка официальных образов Docker медленная/нестабильная, можно использовать сервисы Alibaba Cloud Container Registry (ACR). Важно: официальный ACR image accelerator больше не синхронизирует последние образы. Если образ не скачивается или тег latest не содержит актуальную версию, воспользуйтесь альтернативами:

• Подписка в ACR на зарубежные исходные образы (subscription of overseas source images).
• Использование GA (Global Accelerator) для ускорения прямого доступа к зарубежным реестрам.

Рекомендация для Production: минимизируйте зависимость от Docker Hub из‑за сетевых рисков.

Если вы используете containerd:

• Убедитесь, что в /etc/containerd/config.toml задан config_path, например: [plugins."io.containerd.grpc.v1.cri".registry] config_path = "/etc/containerd/certs.d"
• Уберите конфликтующие mirrors (если есть), перезапустите containerd: sudo systemctl restart containerd
• При ошибке старта изучите вывод: journalctl -u containerd
• Создайте файл /etc/containerd/certs.d/docker.io/hosts.toml: server = "https://registry-1.docker.io" [host."https://<your-ACR-accelerator-address>"] capabilities = ["pull", "resolve", "push"]

1.5 Загрузка сборочного образа StarRocks

Выбирайте тег образа в соответствии с веткой/версией исходников (для ветки main — тег main; для ветки 3.5 — тег 3.5 и т. п.):

1.6 Просмотр локальных образов

2. Получение исходников StarRocks

2.1 Клонирование из GitHub или скачивание архива

Стандартно:

Если из‑за сетевых ограничений возникают ошибки (например, EOF), можно:

• использовать зеркало GitHub (пример): git clone https://github.com.cnpmjs.org/StarRocks/starrocks.git
• либо скачать архив кода из браузера: https://github.com/StarRocks/starrocks
• архив конкретного релиза: https://github.com/StarRocks/starrocks/tags

Чтобы ускорить клонирование, добавьте --depth 1 (если не требуется полная история).

2.2 Загрузка архива на сервер и распаковка (вариант с ZIP)

2.3 Запуск контейнера со сборочным окружением и монтированием кэшей

Рекомендуется смонтировать локальный Maven-кэш (~/.m2) для ускорения повторных сборок.

(Опционально — подключите ccache, смонтировав ~/.ccache, если это поддерживается образом.)

2.4 Проверка запущенных контейнеров

2.5 Вход в контейнер

2.6 Переход в каталог исходников

2.7 Сборка FE и BE

Скрипт скачает зависимости и выполнит сборку (может занять значительное время). Благодаря монтированию ~/.m2 зависимости будут переиспользованы в следующих сборках.

Результаты сборки — в каталоге output/:

Сборка без AVX2 (только при необходимости; не рекомендуется)

Измените build.sh, чтобы принудительно отключить AVX2:

Измените сборку сторонней библиотеки в thirdparty/build-thirdparty.sh (блок croaring):

Повторно выполните ./build.sh. Учтите: такой вариант не имеет полноценного покрытия тестами.

Полезные опции build.sh

2.8 Сборка Broker

Broker не собирается шагом выше — его нужно собирать отдельно:

Готовые файлы появятся в

.

2.9 Выход и повторный запуск контейнера при необходимости

Так как каталог с исходниками смонтирован в контейнер, результаты сборки доступны на хосте.

Примечания и рекомендации

• FE (Frontend) и BE (Backend) — основные компоненты StarRocks, сборка которых выполняется скриптом build.sh.
• Для воспроизводимости привязывайте тег сборочного Docker-образа к ветке/версии исходников (например, starrocks/dev-env:3.5 для ветки 3.5.x).
• Для ускорения повторных сборок используйте кэш Maven (~/.m2) и, при возможности, ccache для C++.
• ARM: официальный сборочный Docker-образ пока не рассчитан на ARM. Для ARM-сборки потребуется нативный ARM-хост и корректные версии зависимостей (JDK, CMake и др.).
• Список актуальных релизов и тегов: https://github.com/StarRocks/starrocks/tags
• Release Notes 1.19 (сообщество): https://forum.mirrorship.cn/t/topic/552

После этих шагов у вас будут собранные бинарные артефакты FE/BE и Broker, готовые к дальнейшему развертыванию кластера StarRocks.

Веб-приложения рано или поздно перерастают один сервер. Чтобы продолжить работу, компаниям нужно повысить отказоустойчивость, масштабируемость. А лучше — и то, и другое.

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

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

Визуализируем проблему

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

При скорости 3 RPS часть запросов отбрасывается. Если новый запрос приходит на сервер в момент, когда тот уже обрабатывает другой, сервер его отклонит. Пользователь получит ошибку — этого нужно избегать. Исправить ситуацию можно, добавив ещё один сервер в пул нашего балансировщика нагрузки. Ура, запрос принят! Балансировщик отправляет по очереди запрос каждому серверу. Это называется балансировкой, циклическим перебором или «round robin». Один из самых простых и действенных способов балансировки нагрузки. Он хорошо работает, когда серверы имеют одинаковую мощность, а запросы примерно одинаково затратны.

Когда round robin не подходит

На практике серверы редко имеют одинаковую мощность, а запросы требуют одинаковых ресурсов. Даже при идентичном оборудовании производительность может меняться.

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

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

Если понаблюдать за симуляцией, запросы немного меняют цвет. Чем дольше они не обрабатываются, тем темнее становятся.

Из-за различий в «стоимости» запросов в работе сервера происходит дисбаланс: накапливаются очереди. Накапливаются на тех серверах, которым не повезло, и подряд досталось несколько «дорогих» запросов. Если очередь заполнена, такой запрос будет отброшен.

Проблема сохраняется на серверах с разной мощностью. Маломощная часть железа быстро перегружается и начинает отбрасывать запросы. При этом более производительное оборудование простаивает. Этот сценарий показывает основную слабость round robin — колебания. Однако round robin всё равно остаётся стандартным методом балансировки HTTP-нагрузки для nginx.

Как улучшить round robin

Улучшить round robin балансировку можно с помощью алгоритма «взвешенного циклического перебора» или «weighted round robin». Так он лучше будет справляться с вариативностью.

Как он работает: разработчики присваивают каждому серверу вес. Определяется, сколько запросов в секунду потянет сервер. В симуляции мы используем известное значение мощности сервера — вес. И, проходя по пулам, отдаём более мощным серверам больше запросов.

Хотя такой подход лучше справляется с разбросом мощности серверов, чем обычный round-robin, нам всё ещё приходится иметь дело с вариативностью «стоимости» запросов. Тактика «поручать людям вручную выставлять веса» быстро перестаёт работать. Свести производительность сервера к одному числу сложно и требует аккуратного нагрузочного тестирования на реальных сценариях. Это делают редко, поэтому другой вариант взвешенного round-robin вычисляет веса динамически, используя прокси-метрику задержку (latency).

Логично, что если один сервер обрабатывает запросы в три раза быстрее другого, скорее всего, он действительно в три раза быстрее и должен получать в три раза больше запросов.

Разметим каждый сервер и покажем среднюю задержку трёх последних обработанных запросов. Отправляем 1, 2 или 3 запроса каждому серверу на основе относительного различия в задержках.

Результат схож с weighted round robin. При этом не нужно заранее указывать вес каждого сервера. Алгоритм адаптируется к изменениям производительности со временем. Это называется «динамический взвешенный round robin».

Осталось понять, как метод справится с мощными колебаниями в мощности серверов и стоимости запросов.

Уходим от round robin

Динамически взвешенный round robin хорошо учитывает колебания мощности сервера и затрат на запросы. Но можно решить задачу элегантнее и проще. Применим балансировку по принципу «наименьшего количества соединений» — least connections.

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

Этот алгоритм просто реализовать, он отлично работает вне зависимости от степени вариативности, избавляет от неопределённости и точно вычисляет нагрузку каждого сервера. Поэтому метод — стандарт балансировки HTTP-нагрузки в балансировщиках AWS и применяется как опция в nginx. Как и в других подходах, не удаётся избавиться от потерь запросов. Но единственный случай, когда он отбрасывает запросы, — это когда буквально не остаётся места в очереди. Он гарантирует использование всех доступных ресурсов, и потому — отличный выбор по умолчанию для большинства рабочих нагрузок.

Оптимизируем latency (задержки)

Потерянные запросы — это очень плохо, и мы стараемся их избежать. Цель неплохая, но это не та метрика, под которую чаще всего стоит оптимизировать HTTP-балансировщик.

Чаще нас волнует задержка (latency). Она измеряется в миллисекундах — от момента создания запроса до момента его обслуживания. В этом контексте принято говорить о разных перцентилях. Например, 50-й перцентиль (он же медиана) — это такое значение в миллисекундах, ниже которого находится 50% запросов и выше — тоже 50%.

Запускаем три симуляции с одинаковыми параметрами на 60 секунд. Каждую секунду снимаем метрики. Симуляции отличаются только алгоритмом балансировки. Давайте сравним медианы для каждой.

На графике перцентилям внутри одного алгоритма не назначены разные цвета. Более высокие перцентили всегда расположены выше.

Возможно, неожиданно, но у round-robin лучшая медианная задержка. Если смотреть только на этот показатель, мы упустим общую картину. Давайте посмотрим на 95-й и 99-й перцентили.

Мы видим, что round-robin показывает слабые результаты в верхних перцентилях. Как так получается, что у него отличная медиана, но плохие 95-й и 99-й перцентили?

При round-robin состояние серверов не учитывается, поэтому немало запросов попадает на простаивающие серверы — отсюда низкий 50-й перцентиль (медиана). Но с той же лёгкостью запросы отправляются и на перегруженные машины — поэтому 95-й и 99-й перцентили ухудшаются.

Выбираем параметры симуляций, чтобы избежать отбрасывания запросов. Это гарантирует сравнение одинакового количества наблюдений для всех трёх алгоритмов. Запустим симуляции с увеличенным значением RPS (запросов в секунду) и доведём все алгоритмы до предела. Ниже — график накопленного числа отброшенных запросов во времени.

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

Применяем ещё один алгоритм

Если мы действительно хотим оптимизироваться по задержке, нам нужен алгоритм, который прямо учитывает latency. Было бы здорово объединить динамический взвешенный round-robin с least connections: чувствительность к задержке первого и устойчивость второго.

Возьмём плюсы от обоих подходов и попробуем избавить от минусов.

Такая идея возникла не впервые. Существует алгоритм Peak Exponentially Weighted Moving Average «пикового экспоненциально взвешенного скользящего среднего» или PEWMA. Название длинное и сложное, но принцип понятный.

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

Как он это делает? Комбинирует приёмы из динамического взвешенного round-robin и из least connections, а сверху добавляет щепотку собственной «магии».

Для каждого сервера алгоритм отслеживает задержку последних N запросов. Вместо того чтобы считать среднее, он суммирует значения с экспоненциально убывающим коэффициентом. В итоге, чем старее измерение задержки, тем меньше оно влияет на сумму; свежие запросы влияют сильнее, чем давние. Полученное значение умножается на количество открытых подключений к серверу. Результат использует, чтобы выбрать, на какой сервер отправить следующий запрос. Меньше — лучше.

Сначала посмотрим на 50-й, 95-й и 99-й перцентили в сравнении с данными для least connections из предыдущей части.

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

А что насчёт потерянных запросов?

Сначала он показывает лучшие результаты, но со временем начинает уступать least connections. Это логично: PEWMA стремится к наименьшим задержкам, и из-за этого иногда оставляет сервер недозагруженным.

К тому же, у PEWMA много настраиваемых параметров. Реализация, приведённая в этой статье, использует конфигурацию, хорошо показавшую себя в протестированных сценариях; дополнительная тонкая настройка может дать результаты лучше, чем у least connections. Но это и минус PEWMA по сравнению с least connections: большая сложность.

Заключение

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

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

Подведём итоги:

1. Round robin (циклический перебор) — самый простой алгоритм, который отправляет запросы по очереди каждому серверу. Хорошо работает только при одинаковой мощности серверов и одинаково затратных запросах. Имеет лучшую медианную задержку, но плохие высокие перцентили.
2. Weighted round robin (взвешенный циклический перебор) — учитывает мощность серверов через веса, которые задают разработчики. Требует ручной настройки и тщательного тестирования. Не адаптируется к изменениям производительности.
3. Dynamic weighted round robin (динамический взвешенный циклический перебор) — самостоятельно определяет веса серверов по задержке ответов. Адаптируется к изменениям производительности со временем. Хорошо справляется с колебаниями мощности и стоимости запросов.
4. Least connections (наименьшее количество соединений) — отправляет запросы на сервер с наименьшим количеством активных соединений. Метод простой и эффективный. Он использует все доступные ресурсы. Стандартный метод в AWS, опция в nginx.
5. PEWMA (пиковое экспоненциально взвешенное скользящее среднее) — самый сложный алгоритм, оптимизирует задержку, учитывая историю ответов с экспоненциально убывающим весом и текущую нагрузку. Лучшие показатели задержки во всех перцентилях, но его сложнее настроить. Метод также может сбоить при перегрузках.

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

Главные отличия Web3 от Web2

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

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

В Web3 логика сильно меняется. Пользователь входит в систему с помощью криптокошелька, например, MetaMask. Каждая задача создаётся транзакцией и записывается в смарт‑контракт, а значит становится частью блокчейна. Удалить её уже нельзя — только отметить статус выполнения. Такой подход даёт прозрачность: любой участник сети может проверить, что задача действительно существует, и её статус изменён честно.

Стек Web3: что понадобится на практике

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

• Блокчейн: Ethereum, Layer‑2 (Arbitrum, Optimism, Base, Polygon), Solana.
• Языки: Solidity (EVM), Rust (Solana), Go (инфраструктура и сервисы).
• Библиотеки: ethers.js, wagmi.
• Фреймворки: Hardhat, Foundry, Truffle.
• Хранилища: IPFS/Arweave для файлов и метаданных.
• Кошельки/подключение: MetaMask, WalletConnect (v2/WalletConnect Network), Web3Auth.

Точка входа для новичка — Alchemy, а также ethers.js.

Пример. Быстрое подключение кошелька (ethers.js).

Архитектура DApp: из чего состоит современное Web3‑приложение

Любое Web3‑приложение строится из нескольких слоёв, каждый со своей ролью. Фронтенд остаётся привычным SPA, но работает не с сервером, а напрямую с кошельком и смарт-контрактами. Контракты содержат бизнес‑логику и хранят ссылки на данные в децентрализованных хранилищах. Оракулы обеспечивают связь с внешним миром, например, передают цены или сообщения между разными блокчейнами. Важную часть играет off‑chain слой — сервисы вне блокчейна (индексаторы, аналитика), которые помогают быстрее искать и обрабатывать данные, при этом не перегружать сеть.

Пример. Возьмём DeFi‑приложение. Пользователь открывает фронтенд и инициирует операцию swap(). В ответ фронтенд обращается к смарт‑контракту, который выполняет обмен токенов. Чтобы определить курс, контракт тянет актуальные данные через оракул. При этом тяжёлые артефакты, изображения или отчёты не хранятся в блокчейне напрямую — они лежат в IPFS. Сам контракт содержит только контент‑идентификаторы CID. Таким образом, получаем баланс: блокчейн отвечает за логику и безопасность, а децентрализованное хранилище — за данные.

Практика: ваш первый DApp за вечер

Давайте попробуем собрать простейшее приложение своими руками.

Шаг 0. Подготовка

Сначала убедитесь, что у вас стоит Node.js LTS и Git. Также нужен браузер с установленным MetaMask, где можно создать тестовый аккаунт. Чтобы оплачивать транзакции в тестовой сети, заранее возьмите немного тестовых монет через faucet — например, для Sepolia или Polygon Amoy.

Шаг 1. Проект

Создадим новый проект и установим Hardhat вместе с тулзами. Эта среда нужна для компиляции и деплоя контрактов.

Шаг 2. Контракт

В папке contracts/ создаём файл TaskTracker.sol и копируем туда код смарт-контракта из первого раздела. Это и будет бизнес-логика нашего приложения.

Шаг 3. Сценарий деплоя

Пишем скрипт, который разворачивает контракт в сети. Это простой скрипт на JavaScript, который вызывает методы Hardhat.

Шаг 4. Конфиг сети

В файле hardhat.config.js добавляем настройки для подключения к тестовой сети. Используем RPC-URL от Alchemy или Infura и приватный ключ от тестового аккаунта — его можно экспортировать из MetaMask, но использовать только для тестовой сети.

Шаг 5. Деплой в тестнет

Теперь запускаем скрипт деплоя. После выполнения увидите адрес контракта — он понадобится для фронтенда.

Шаг 6. Фронтенд (React + ethers.js + wagmi)

Собираем простое SPA: форма, чтобы добавить задачи, и кнопка «complete». Здесь мы используем ethers.js для обращения к контракту. Сделайте вызовы addTask и completeTask.

Подводные камни Web3-разработки и что с ними делать

Комиссии (gas): любая запись в блокчейн стоит денег и иногда комиссия выше ценности операции — например, $10 за простую задачу.

• Что делать: использовать Layer-2 (Arbitrum/Optimism/Base/Polygon), выбирать сети с низкими комиссиями (Solana, Avalanche), оптимизировать контракты и батчи транзакций.

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

• Что делать: показывать «оптимистичный UI», кешировать данные, переносить часть логики off-chain, использовать быстрые сети (Solana, Near, Aptos).

Безопасность: код контракта неизменяем, и одна ошибка может стоить миллионов.

• Что делать: проходить аудит (CertiK, Trail of Bits), использовать проверенные библиотеки (OpenZeppelin), писать тесты в тестовых сетях (Goerli, Sepolia), внедрять баг-баунти и ролевую модель доступа.
• Ресурс: ConsenSys Diligence — Smart Contract Security Best Practices.

UX: вход через кошелёк сложнее привычного логина/пароля. Нужно ставить расширение, пополнять баланс и подтверждать каждую транзакцию.

• Что делать: использовать аккаунт-абстракцию (ERC-4337), социальный логин, gasless транзакции через Paymaster, улучшать UI (подсказки, авто-фокус на MetaMask).

Регуляция: законы о Web3 пока разные в каждой стране. Легальное в одной юрисдикции может быть запрещено в другой (например, токенизация акций без лицензии).

• Что делать: консультироваться с юристами, следить за изменениями. Например, MiCA в ЕС — “Markets in Crypto-Assets Regulation” — это единый регламент по криптоактивам в Евросоюзе.

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

Карьерные возможности и перспективы

Web3‑разработчиков уже активно ищут: зарплаты в среднем предлагают выше, чем у Web2‑коллег. Кроме программистов, востребованы смежные роли: аудиторы смарт‑контрактов, специалисты по безопасности, а также продакт‑менеджеры и аналитики, которые понимают специфику блокчейна.

Чтобы войти в профессию, начните с изучения Solidity и базовых паттернов смарт‑контрактов. Сделайте пару пет‑проектов и выложите код в GitHub. Отличный вариант прокачки — участвовать в хакатонах и грантовых программах от Ethereum Foundation или Solana Grants. Это даёт и опыт, и контакты, и иногда финансирование.

Пара пет‑проектов + понимание блокчейна — хороший старт в Web3‑команду.

Будущее Web3

Web3 не вытеснит Web2 полностью, но поменяет привычный подход к разработке. Разработчику это открывает новые вызовы: комиссии, безопасность и UX, но одновременно и новые возможности — прозрачные данные, токенизация, децентрализованные бизнес‑модели.

Для тех, кто только входит в сферу, это шанс попасть в индустрию на раннем этапе и быстро нарастить экспертизу. Простые пет‑проекты, хакатоны и знакомство с инструментами дают ощутимый старт.

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

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

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

Во время работы я наткнулся на подход, который мне очень понравился: ADR — Architectural Decision Record, или «протокол архитектурных решений».

По сути, это документ, в котором фиксируются все изменения, внесённые в архитектуру: само решение, его влияние и полученные уроки.

Проще говоря, это как личный дневник — только для всей команды.

Почему это важно?

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

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

Будущие разработчики скажут вам спасибо. Подумайте о человеке, который через пять лет будет разбираться в вашем коде. Если вы не оставили объяснений, он, скорее всего, будет мучиться, пытаясь понять, зачем было сделано то или иное изменение. А теперь представьте другого разработчика в другой компании, который находит ADR-документ с чётким объяснением принятого решения. Он, без сомнения, будет вам благодарен.

Синьор-фронтендер из ВК Маргарита Лукина, автор телеграм-канала «Фронтенд кухня»:

Ценность ADR я впервые осознала в 2019 году. В команду, где работала, активно набирали новых ребят, и приблизительно раз в неделю кто-нибудь из новых разработчиков спрашивал "а почему это сделано так, а не иначе?" Приходилось постоянно давать ответы на одни и те же вопросы, и тогда-то я и поняла, насколько будет удобно записывать ответы где-нибудь в документацию в confluence и просто кидать ссылку новичкам.

В 2019 году я еще не знала сам термин ADR и говорила "документация". С термином я познакомилась совсем недавно — этим летом, на курсе по архитектуре монолитных приложений. Тогда я поняла, насколько эффективно можно использовать ADR для ускорения разработки и уменьшения TTM. Дело в том, что начиная разрабатывать новый проект, разработчик первое время (от месяца до полугода! всё зависит от размера проекта) погружается в проект — разбирается, как всё устроено, чтобы вносить изменения соответственно архитектуре. В этот период разработчик, по сути, составляет собственные adr — обычно в виде мыслеобразов в своей голове :) Если записать основные решения, разработчик сможет намного быстрее погрузиться в проект.

Как писать ADR?

Существует несколько общепринятых правил, но вы всегда можете адаптировать их под себя.

Вдохновившее меня соглашение можно найти на GitHub . Вы также можете ознакомиться с процессом ADR на Amazon.

Вот пример шаблона, который вы можете использовать.

Такой тип документа может находиться прямо в репозитории проекта, в Confluence или, например, в JIRA.

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

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

Синьор-фронтендер из ВК Маргарита Лукина, автор телеграм-канала «Фронтенд кухня»:

Многие руководители хотят видеть на своём проекте разработчиков, которые "сразу, без раскачки" начнут перформить. Совсем избежать периода погружения невозможно, но можно ускорить его в десятки раз за счёт ADR

Это те самые «монстры», которые рушат ключевую логику, приводят к потере денег, данных или репутации. Их объединяет одно: они блокируют пользовательский сценарий или создают серьёзную уязвимость.

Пример 1: «Призрачный промокод», или классический Race Condition

Представьте себе интернет-магазин, который запустил акцию: «Первые 100 покупателей получат скидку 50% с промокодом SUPER-SALE». Код простой: проверяем, сколько раз промокод уже был использован, и если меньше 100 — применяем скидку.

Ситуация: в понедельник утром маркетологи в панике: промокод применили 350 раз. Бизнес потерял кучу денег. Как так вышло?

Разбор полётов: проблема в параллельных запросах. Когда нагрузка на сервер высока, несколько пользователей могут одновременно отправить запрос на применение промокода.

Упрощённый код на бэкенде мог выглядеть так (Node.js-подобный псевдокод):

Что происходит под нагрузкой:

1. Запрос А приходит. usageCount равен 99. Проверка 99 < 100 проходит.
2. Запрос Б приходит сразу после Запроса А, но до того, как Запрос А успел обновить счётчик в базе. Для Запроса Б usageCount всё ещё равен 99. Проверка 99 < 100 тоже проходит.
3. Запрос В приходит в тот же момент, для него usageCount равен 99.

В итоге все три запроса успешно применяют скидку и увеличивают счётчик. Вместо одного использования мы получили три.

Это классическое состояние гонки (Race Condition). Проблема не в логике как таковой, а во времени и одновременном доступе к общему ресурсу (счётчику в БД).

Многие помнят про Race Condition, но часто забывают, что он может проявляться не только в классических банковских транзакциях, но и в менее очевидных местах: счётчики, генерация уникальных имён, бронирование слотов.

Как чинить? Самый надёжный способ — транзакции с блокировкой. Пояснение для новичков: FOR UPDATE говорит базе данных: «Сейчас буду менять эту строку, никому её не отдавай, пока я не закончу». Другие запросы выстроятся в очередь и будут ждать, пока первый не завершит свою работу.

Пример 2: «Тихий убийца производительности», или утечка памяти на фронтенде

Ситуация: пользователи жалуются, что после получаса работы в SPA (Single Page Application) сайт начинает тормозить, «съедать» память, а анимации становятся «дёргаными». Перезагрузка страницы помогает.

Разбор полётов: представим, что у нас есть компонент, который при монтировании подписывается на глобальное событие (например, изменение размера окна).

Этот компонент может появляться и исчезать с экрана много раз (например, в модальном окне). Каждый раз, когда он появляется, useEffect навешивает новый обработчик handleResize на глобальный объект window. Но когда компонент исчезает, обработчик не удаляется.

После 10 открытий-закрытий модального окна у нас будет 10 одинаковых обработчиков. При каждом изменении размера окна браузер будет выполнять одну и ту же «сложную логику» 10 раз. Через час их будет уже сотня. Это и есть утечка памяти (Memory Leak). Ссылки на функции handleResize и их замыкания остаются в памяти, потому что на них ссылается window.

Это классика, но дьявол в деталях. Утечки могут быть куда коварнее: неотписанные WebSocket-соединения, забытые таймеры (setInterval), ссылки на DOM-элементы в замыканиях, которые мешают сборщику мусора их убрать.

Как чинить? Всегда отписываться от событий в функции очистки.

Некритичные баги: «фича, а не баг»

Это ошибки, которые не ломают основной функционал. Они могут быть визуальными, «текстовыми», или проявляться в таких редких условиях, что 99.9% пользователей их никогда не увидят.

Пример 1: «Магия чисел с плавающей запятой»

Ситуация: в корзине интернет-магазина пользователь добавляет товар за 0.1$ и товар за 0.2$. Итоговая сумма заказа отображается как 0.30000000000000004$.

Разбор полётов: это не баг кода. Это фундаментальная особенность того, как компьютеры хранят дробные числа в формате IEEE 754 (floating-point).

Если кратко: большинство десятичных дробей не могут быть точно представлены в двоичной системе счисления, так же как 1/3 не может быть точно записана в виде конечной десятичной дроби (0.3333...). Когда вы пишете 0.1, компьютер хранит ближайшее возможное двоичное представление, которое чуть-чуть больше. То же самое с 0.2. При их сложении эти микроскопические неточности накапливаются и становятся видимыми.

Почему это чаще всего некритично? Проблема чисто визуальная и не мешает работе продукта. Если на бэкенде для финансовых расчётов используются специальные типы данных (как Decimal в Python или BigDecimal в Java), то реальный платёж пройдёт на правильную сумму (0.3$).

Это отличный пример бага, который выглядит как ошибка новичка, но его корни уходят глубоко в основы информатики. Опытные разработчики знают, что с деньгами нельзя работать через float / double и всегда используют либо целочисленное представление (хранят всё в копейках/центах), либо специальные библиотеки.

Как чинить (на фронтенде)? Просто отформатировать вывод.

Пример 2: «Восставший z-index»

Ситуация: на определённой странице выпадающее меню профиля пользователя оказывается под блоком с баннером. Кликнуть по ссылкам «Профиль» или «Выйти» невозможно. Баг воспроизводится только в Safari на macOS.

Разбор полётов: скорее всего, проблема в контексте наложения (stacking context). Многие думают, что z-index — это просто глобальный номер слоя: у кого больше, тот и выше. Но это не так.

Элемент с transform, opacity < 1, filter и некоторыми другими CSS-свойствами создаёт свой собственный «мини-мир» слоёв — stacking context. Внутри этого мира z-index работает как ожидается. Но никакой z-index: 9999 внутри одного контекста не поможет элементу перекрыть другой элемент из другого контекста, если сам родительский контекст находится «ниже».

В нашем случае, блок с баннером мог иметь, например, transform: scale(1) (для анимации при наведении), что создало новый контекст наложения. И если этот блок в DOM-дереве находится после шапки с меню, то весь его «мир» (включая фон и сам баннер) будет выше «мира» шапки.

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

Как чинить? Вариантов несколько:

• Убрать свойство, создающее stacking context (контекст наложения) с баннера, если оно не критично: это поможет избежать проблем с порядком наложения элементов (z-index), предотвратить случайное перекрытие модальных окон, тултипов и др., упростить управление слоями в интерфейсе;
• Создать stacking context для родительского элемента (это элемент интерфейса, на котором активируется выпадающий список) меню, например, добавив position: relative; z-index: 1; на саму шапку;
• Перенести элемент с меню в конец <body> через портал (как это делают в React/Vue), чтобы он не зависел от родительских контекстов.

Приоритет и серьёзность: как отличить одно от другого?

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

Серьёзность (Severity): описывает, насколько сильно баг ломает продукт.

Уровень 1: приложение не работает, данные теряются.

Примеры: приложение ломается при запуске, пользователи не могут его открыть; платёжная система не сохраняет данные транзакций, и деньги «исчезают».

Уровень 2: ключевой функционал не работает, но есть обходные пути.

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

Уровень 3: неключевой функционал работает некорректно.

Примеры: не работает кнопка «Поделиться» в соцсетях (если это не ключевая функция продукта); в списке товаров некорректно отображаются некоторые параметры, например, дата добавления.

Уровень 4: визуальный дефект.

Пример: опечатка в тексте.

Приоритет (Priority): этот термин определяет, насколько срочно нужно исправлять баг.

Уровень 1: чинить немедленно, бросив всё.

Пример: любой пользователь может получить доступ к чужим данным через URL (критическая уязвимость).

Уровень 2: включить в следующий спринт/релиз.

Пример: заметное падение производительности на мобильных устройствах при обработке данных в реальном времени.

Уровень 3: починить, когда будет время.

Пример: у кнопки на тёмной теме сайта некорректно отображается цвет.

Приоритет (то есть срочность) может зависеть от бизнес-контекста, сроков релиза и аудитории. Серьёзность (важность) — от технического влияния на продукт. При этом серьёзность и приоритет могут не только не совпадать по уровням, но и конфликтовать.

Например, на главной странице в названии компании замечена опечатка. Это 4-ый уровень серьёзности: сайт работает, ничего не сломано. Но при этом 1-ый уровень приоритета: ведь сайт — лицо компании, и отдел маркетинга требует исправить «ещё вчера». Что делать в подобном случае? Зависит от корпоративных правил и коммуникаций.

Важно обращать внимание на детали из контекста. Например: критическая утечка данных (уровень 1 серьезности) требует немедленного исправления (уровень 1 приоритета). Но баг с крашем приложения в редком сценарии и приоритетом 2-го уровня, если затронуты всего 0.1% пользователей. Или, допустим, сломалась опция «Экспорт в PDF» (это уровень 3 серьёзности), но клиент заплатил за неё высокую цену — значит, повышаем срочность.

Инструментарий охотника за багами: от нахождения до профилактики

Как превратить борьбу с ошибками из хаотичного тушения пожаров в контролируемый процесс? Нужен комплексный подход к «охоте на баги».

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

Системы отслеживания ошибок (Bug Trackers): центр управления полётами

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

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

YouTrack (JetBrains): трекер отличает скорость и «умный» поиск (на естественном языке), тесная интеграция с IDE JetBrains и GitHub. Часто воспринимается как более легковесная и быстрая альтернатива Jira для команд, ценящих эффективность.

Linear: продукт с минималистичным UI, упором на клавиатурные сокращения. Подходит для стартапов и небольших команд, где важен фокус и отсутствие накладных расходов на управление самим трекером.

GitHub Issues / GitLab Issues: интегрированы напрямую в репозиторий. Удобны для open-source проектов и команд, чья разработка тесно завязана на Git-операциях (мердж-реквесты, коммиты). Прямая привязка багов к коду — их главный козырь.

Системы мониторинга и сбора ошибок: радар, ловящий баги в реальном времени

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

Sentry: становится вашими глазами и ушами в продакшене. В реальном времени ловит исключения и ошибки на фронтенде (JavaScript, React, Vue и др.) и бэкенде (Python, Java, Node.js, Go и др.). Магия Sentry — в автоматической группировке схожих ошибок, алертах с детальным стектрейсом, контекстом (параметры запроса, данные пользователя) и даже возможностью записать шаги, приведшие к ошибке. Позволяет узнать о проблеме раньше, чем начнут сыпаться жалобы.

ELK Stack (Elasticsearch, Logstash, Kibana) / Grafana Loki: когда ошибка — лишь симптом, а корень проблемы спрятан глубоко в логике распределенной системы или инфраструктуре, нужен мощный анализ логов. Эти инструменты (особенно в паре со сборщиками логов по типу Fluentd или Promtail для Loki) собирают, индексируют и визуализируют гигантские объемы лог-данных со всех серверов и сервисов. Kibana и Grafana предоставляют мощные дашборды для поиска закономерностей, аномалий и первопричин сбоев.

Инструменты для дебага: скальпель для вскрытия проблемы

Когда баг локализован (благодаря трекеру и мониторингу), наступает время точечной работы — понять, почему он возникает и как исправить. Здесь незаменимы отладчики.

Browser DevTools (Chrome DevTools, Firefox Developer Tools): комфортный инструмент фронтенд-разработчика. Мощный отладчик JavaScript, инспектор DOM/CSS, детальный анализ сетевых запросов (заголовки, время, размеры), профилировщик производительности (выявление «бутылочных горлышек»), аудит безопасности и доступности — всё под рукой прямо в браузере.

IDE Debuggers (VS Code, IntelliJ IDEA, PyCharm и др.): дают суперспособность пошагового выполнения кода на бэкенде или даже на фронтенде (интегрируясь с браузером). Установка точек останова (breakpoints), просмотр состояния переменных в реальном времени, пошаговый проход (step into/over), оценка выражений на лету — это фундамент для понимания потока выполнения и нахождения логических ошибок.

Инструменты для профилактики: строим оборону до появления врага

Самые эффективные баги — те, которые никогда не попали в продакшен. Современные практики разработки делают ставку на автоматизированную профилактику ошибок на этапе написания кода. Вот ключевые союзники в этом:

• ESLint (JavaScript/TypeScript), статический анализатор кода — сканирует код до запуска, выявляя потенциальные баги, антипаттерны и нарушения соглашений по стилю. Находит опечатки, необъявленные переменные, опасные конструкции (напр., console.log в prod), потенциальные утечки памяти. Многие ошибки (например, сравнение == вместо === по правилу eqeqeq) может исправить автоматически (--fix). Интеграция в редактор (VS Code, WebStorm) и CI/CD пайплайны перехватывает ошибки мгновенно.
• SonarQube (25+ языков) для непрерывного контроля качества кода. Идёт глубже ESLint, выискивая сложные баги, уязвимости безопасности (OWASP Top 10: SQL-инъекции, XSS) и «запахи кода», ведущие к будущим проблемам. Выявляет критические ошибки: разыменование null (Null Pointer Exception), утечки ресурсов (файлы, соединения), возможные состояния гонки (race conditions). Оценивает технический долг и ключевые метрики (сложность кода, покрытие тестами), помогая поддерживать здоровье кодовой базы. Работает как часть CI/CD, предоставляя наглядные дашборды.
• Prettier (50+ языков) бескомпромиссно применяет единые стилистические правила (отступы, точки с запятой, переносы строк, кавычки). Устраняет целый класс потенциальных ошибок, связанных с неочевидной работой парсера из-за форматирования (напр., Automatic Semicolon Insertion в JS). Фокусирует код-ревью на логике, а не на пробелах.
• Проактивная профилактика: Prettier, ESLint, SonarQube автоматически блокируют огромный пласт рутинных ошибок и уязвимостей до того момента, как код попадет в репозиторий или сборку.
• Раннее выявление: Sentry, ELK/Loki мгновенно сигнализируют о сбоях в работе приложения, минимизируя время реакции и воздействие на пользователей.
• Эффективный менеджмент: Jira, YouTrack, Linear, GitHub Issues обеспечат прозрачность, контроль и анализ потока ошибок.
• DevTools, IDE Debuggers дают разработчику возможность точно диагностировать и исправлять корневые причины сложных багов.

Важно: максимальный эффект достигается при интеграции этих инструментов в CI/CD пайплайн. Prettier, ESLint и статический анализ SonarQube должны запускаться автоматически на каждый пул-реквест, блокируя мердж в основную ветку при обнаружении проблем. Сборка с ошибками или уязвимостями просто не должна попадать дальше. Это создает культуру качества и экономит сотни часов на исправлении «глупых» багов, позволяя команде сосредоточиться на сложных задачах и инновациях.

Это значит, что даже без подписки Ultimate вы сможете использовать и разрабатывать плагины на основе Language Server Protocol.

Что произошло?

JetBrains продолжает переход к единой дистрибуции IntelliJ IDEA — начиная с версии 2025.3, будет один установщик для всех пользователей, вне зависимости от подписки.

Уже в версии 2025.2 вступает в силу новый fallback-режим. Это бесплатный уровень для пользователей с истекшей подпиской, в котором доступен ограниченный набор возможностей IDE.

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

Что это значит для разработчиков плагинов?

Если вы пишете плагины на базе Language Server Protocol, они станут доступны куда более широкой аудитории — не только платным пользователям IntelliJ Ultimate, но и тем, кто работает в бесплатном режиме.

Важно: поддержка LSP исчезнет из Community Edition (она будет выведена из обращения после релиза 2025.2), так что fallback-режим станет основным способом бесплатного использования LSP в IntelliJ. Чтобы использовать LSP в своих плагинах, нужно:

• Таргетить IntelliJ IDEA Ultimate 2025.2.1 или новее.
• Указать опциональную зависимость на модуль com.intellij.modules.lsp.

Что умеет LSP в IntelliJ?

LSP API в платформе IntelliJ уже поддерживает:

• Подсказки с resolve-поддержкой.
• Переход к определению.
• Документацию при наведении.
• Диагностику.
• Code actions и быстрые фиксы.
• Форматирование документов.

В то же время представители JetBrains подчеркивают, что LSP — это не замена PSI. Встроенная PSI-система остается основой глубокой интеграции языков в IDE и именно она обеспечивает расширенные функции вроде рефакторинга, анализа кода и т.д.

LSP — более универсальный, но менее производительный и менее гибкий подход.

Что дальше?

Полный переход случится с релизом 2025.3, когда Community Edition перестанет существовать как отдельная сборка, а fallback-режим станет основной бесплатной точкой входа.

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

Модель создана с нуля, обучена на реальных пулл-реквестах и задачах из практики. Она уже доступна в IDE.

Новая глава в «вайб-кодинге»

Модель grok-code-fast-1 от xAI позиционируется как конкурент решениям от OpenAI, Google и Anthropic. Она оптимизирована для разработки на TypeScript, Python, Java, Rust, C++ и Go, а значит покрывает большинство реальных кейсов в современной разработке.

Модель уже интегрирована в IDE и CLI вроде GitHub Copilot, Cursor, Cline, Roo Code, Kilo Code, OpenCode и Windsurf. В ближайшее (но ограниченное) время она будет доступна бесплатно.

Быстрая, дешевая и довольно-таки умная

xAI делает ставку на цену, скорость и удобство. Стоимость использования grok-code-fast-1:

• $0,20 за 1 млн входных токенов
• $1,50 за 1 млн выходных токенов
• $0,02 за 1 млн кэшированных входных токенов

Во внутреннем бенчмарке SWE-Bench-Verified, модель показала результат 70,8%, но независимых тестов пока нет — их ждут в ближайшие недели.

В xAI утверждают, что при создании модели основное внимание уделялось практическому использованию и удобству в реальных задачах. Якобы разработчики оценили grok-code-fast-1 как «быструю и надежную» при повседневной работе с кодом.

До 160 токенов в секунду и 90% кэш-хитов

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

Кроме того, реализовано кэширование подсказок, которое обеспечивает до 90% попаданий при работе с GitHub Copilot и другими интеграциями. Это позволяет существенно сократить задержки и стоимость использования.

Его цель — понять, заменяет ли ИИ навыки, которые он оттачивал всю жизнь. Ответ оказался несколько сложнее, чем «да» или «нет».

«Я позволил ИИ писать весь код. Сам я не написал ни строчки»

Проект, над которым работал разработчик, — решатель головоломки «Ханойская башня», написанный на Python. Объем — около 5000 строк кода, 50 файлов, 20 классов.

Все идеи, архитектура, логи и алгоритмы были созданы через диалог с ИИ: Claude Sonnet 4, OpenAI GPT-o3 и Google Gemini Pro 2.5. Бенедетти использовал IDE Cursor, которая интегрирует ИИ в рабочий процесс.

Я не писал код. Я вел диалог с ИИ, задавал вопросы, уточнял детали, направлял. Это было похоже на парное программирование с очень умным напарником, который говорит на моем языке — и думает быстрее меня.

«ИИ удивлял — и ошибался. Но вместе мы сделали больше»

Разработчик отмечает, что код, создаваемый ИИ, часто превосходит по качеству то, что он написал бы сам. Однако 20% времени уходило на исправление ошибок и «творческих решений» ассистента:

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

Тем не менее, скорость работы, по его оценке, выросла как минимум вдвое.

Где-то ИИ спасал мне 10 минут, где-то экономил часы. Главное — я постоянно учился у него

«Вместе мы вошли в поток — но на другом уровне»

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

Я задавал вопрос — и получал не просто решение, а грамотную, порой даже остроумную реализацию. Временами я чувствовал, что говорю не с ассистентом, а с равным коллегой.

«ИИ — не замена, а усилитель. Но только если ты сам понимаешь, что делаешь»

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

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

Также он отмечает, что ИИ склонен навязывать «индустриальные» решения даже там, где проект требует простоты и ясности — и это стоит учитывать.

«Я больше не буду программировать без ИИ»

Эксперимент завершился положительным выводом: ИИ стал для него незаменимым помощником. Он помог писать быстрее, увереннее и с бóльшим удовольствием.

Я, пожалуй, больше никогда не буду писать код без ИИ-ассистента. Это слишком эффективно. И слишком увлекательно.

Однако Бенедетти подчеркивает, что ИИ не «заменил» его как программиста. Напротив — помог стать лучше.

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

Раунд возглавил венчурный фонд Sequoia Capital. С учетом предыдущих вложений, общая сумма финансирования проекта превысила $42 млн.

Проект возглавляет Натан Собо — создатель Atom, который в свое время стал архитектурной основой для VS Code.

Новые инвестиции позволят команде выйти за рамки построения UI и приступить к реализации глубокой интеграции ИИ в рабочий процесс разработки, а также представить собственную систему управления версионностью под названием DeltaDB.

Что такое DeltaDB

DeltaDB — это система, которая позволяет отслеживать изменения в коде с точностью до каждой операции редактирования.

В отличие от Git, который фиксирует состояние проекта по коммитам, DeltaDB формирует непрерывную временную шкалу изменений, в которую можно «вклиниваться» в любой момент — для обсуждения, анализа или интеграции.

Ключевое отличие — обсуждение изменений в реальном времени. Комментарии можно оставлять не к коммитам или diff’ам, а к конкретным правкам, строчкам, перемещениям или удалению кода. Это создает новое пространство для командной работы: обсуждение становится постоянным фоном, а не разрозненными ветками ревью.

DeltaDB спроектирована как надстройка над Git — она не отменяет git-репозиториев, а расширяет их возможностями детального отслеживания и сотрудничества в реальном времени.

Работа с ИИ — в том же контексте

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

Что еще важно

• Zed написан на Rust.
• Редактор доступен с открытым исходным кодом. Сам редактор — под GPLv3, серверная часть для многопользовательского редактирования — под AGPLv3, интерфейсная библиотека GPUI — под Apache 2.0.
• GPUI использует GPU для отрисовки интерфейса, что обеспечивает высокую отзывчивость и плавную работу редактора.

Zedless: альтернатива для тех, кто хочет полной автономности

На базе Zed развивается форк Zedless, ориентированный на пользователей, которым критична конфиденциальность.

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

В подкасте Matthew Berman Show он назвал это «одной из самых глупых идей», которые он когда-либо слышал.

Почему это плохая стратегия

По словам Гармана, джуниоры — одни из самых недорогих и гибких сотрудников. Они активно осваивают инструменты ИИ и растут вместе с ними.

Если компания откажется от найма младших специалистов, это ударит по ее кадровому резерву в будущем:

Что вы будете делать через 10 лет, если у вас не будет людей, которые чему-то научились и выросли внутри компании?

Гарман считает, что бизнес должен продолжать нанимать выпускников и обучать их фундаментальным навыкам: как разбирать задачи, писать код и применять лучшие инженерные практики.

Университетское образование теряет монополию

Также он отметил, что в условиях экономики, где ИИ играет ключевую роль, ценность не в конкретных дипломах, а в гибкости и способности адаптироваться:

Если вы потратите годы на изучение одного узкого направления и решите стать в нем экспертом на 30 лет вперед — могу с уверенностью сказать: это не сработает.

Вместо этого он рекомендует развивать критическое мышление, креативность и готовность к изменениям.

Что говорят другие эксперты

Заявление Гармана резко контрастирует с позицией некоторых лидеров индустрии. Например:

• Сэм Альтман (OpenAI) ранее сравнил ИИ-агентов с младшими сотрудниками, чья работа все чаще автоматизируется.
• Джефф Дин (Google) заявил, что ИИ достиг уровня, на котором может повторить навыки начинающего инженера — и это произойдет уже в ближайший год.
• По данным Goldman Sachs, безработица среди молодых специалистов в IT (20–30 лет) выросла почти на 3% с начала 2024 года — в четыре раза быстрее, чем в среднем по рынку.

Почему джуниоры все еще важны

Однако не все считают, что молодые кадры устарели. CEO GitHub Томас Домке также отметил: именно начинающие инженеры быстрее всего адаптируются к новым технологиям, включая ИИ:

Они не ограничены подходом «мы всегда делали так». Для них ИИ — это естественный инструмент, а не революция.

Журналисты с сайта 9to5Mac выяснили, что Apple добавила в IDE встроенную авторизацию через Anthropic-аккаунт, а также нашли упоминания моделей Claude Sonnet 4.0 и Claude Opus 4, выпущенной 14 мая 2025 года.

Что это значит для разработчиков

Хотя официально в Xcode пока представлена только интеграция с ChatGPT от OpenAI, свежая находка указывает на то, что Anthropic получит такой же уровень встроенной поддержки — без необходимости подключать API вручную. Это может стать значимым шагом для разработчиков, использующих Claude как основную LLM.

Напомним, что ранее Claude можно было подключить только через внешний API (как и другие сторонние модели). Теперь же Apple, по сути, приближает Anthropic к статусу, который до этого был лишь у OpenAI.

Эволюция Swift Assist

Функция Swift Assist была анонсирована ещё на WWDC 2024 как альтернатива GitHub Copilot. Идея заключалась в создании встроенного ИИ-помощника, который помогает писать код, разбираться в API Apple и работать с фреймворками.

Однако Swift Assist так и не был запущен в оригинальном виде. Вместо этого в Xcode 26 появляется более гибкий механизм под общим названием Intelligence с поддержкой:

• моделей Apple;
• встроенного ChatGPT (с ограничением по количеству запросов, если не авторизован);
• сторонних моделей по API;
• и теперь — Anthropic с полноценной нативной интеграцией.

Что нашли в Xcode 26 beta 7

По данным 9to5Mac, в последней бете IDE обнаружены:

• внутренние ссылки на Anthropic-аккаунты;
• параметры выбора между Claude Sonnet и Opus;
• конфигурационные файлы, намекающие на более глубокую интеграцию Claude в системы Apple, включая Siri и Writing Tools.

Это может означать, что Claude появится не только в Xcode, но и в других частях экосистемы — в качестве альтернативы ChatGPT.

Почему это важно

Claude — один из наиболее точных и аккуратных LLM, ориентированных на безопасность и детальность в генерации кода. Многие разработчики считают Opus и Sonnet лучшими ассистентами на рынке.

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

Apple пока не делала официальных заявлений о Claude в Xcode, но по текущим данным это лишь вопрос времени. Интеграция может быть активирована уже в ближайших обновлениях Xcode 26.

Мы собрали лучшие инструменты для мобильного программирования: от простых редакторов до IDE с компиляторами и отладчиками. Вы узнаете про приложения для фронтенда и бэкенда. Мы затронем тему вайб-кодинга и даже расскажем, как установить Linux-терминал поверх Android или iOS.

Ссылки на приложения опубликовали в комментариях.

CodePen

• Приложение для браузера: ✅
• Приложение для Android: ✅
• Приложение для iOS: ❌

Обзор начнём с онлайн-платформы для фронтендеров CodePen. Песочница работает с HTML, CSS, JS. С её помощью разработчики обмениваются идеями, создают прототипы и обучаются вёрстке. CodePen ценят за простоту – открыл песочницу, написал код, увидел результат.

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

CodePen поддерживает 7 фреймворков, 5 библиотек и 24 набора UI-компонентов. Возможности ограничены только мощностью устройства: превью тяжёлых пэнов на телефоне будет лагать.

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

Code Editor

• Веб-приложение: ❌
• Приложение на Android: ✅
• Приложение на iOS: ✅

Универсальный редактор Code Editor подсвечивает синтаксис 110+ языков. В приложении есть поиск и замена символов, отображение и скрытие строк, выделение совпадающих скобок, автоматические отступы.

Фронтендеры скачивают Code Editor ради предпросмотра HTML и плагина Emmet. Также через встроенную консоль удобно тестировать и отлаживать JS-скрипты.

Приложение распознает комбинации клавиш, поэтому к телефону можно подключить физическую клавиатуру и кодить как за маленьким монитором.

Code Editor поддерживает FTP, FTPS, SFTP и WebDAV для работы с удалёнными серверами. Ещё в приложение добавили Google Диск, Dropbox и GitHub, чтобы синхронизировать файлы между устройствами.

Acode

• Веб-приложение: ❌
• Приложение на Android: ✅
• Приложение на iOS: ❌

Редактор Acode охватывает 100+ языков программирования. Приложение оптимизировано для работы с файлами до 50000 строк. Acode выбирают для мобильной разработки, быстрых правок и обучения программированию.

Встроенный просмотр HTML и Emmet ускоряет вёрстку. В JS-консоли можно тестировать код фрагментами без создания отдельных файлов. Веб-сайты запускаются прямо в браузере приложения. Ещё редактор поддерживает GitHub, FTP/SFTP для работы с удалёнными серверами.

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

Pydroid, Cxxdroid, Jvdroid

• Веб-приложение: ❌
• Приложение на Android: ✅
• Приложение на iOS: ❌

Приложения от одного разработчика не случайно объединили в один раздел – это лучшие мобильные IDE для Python, C/C++ и Java. Каждое заточено под конкретный ЯП, но все построены на одной архитектуре и предлагают схожий функционал.

IDE работают автономно – интернет нужен только для скачивания дополнений. В каждом приложении есть терминал, примеры кода для обучения, система управления пакетами и библиотеками.

Редакторы поддерживают:

• подсветку синтаксиса,
• работу с вкладками,
• расширенную клавиатуру,
• быструю публикацию кода на Pastebin.

Pydroid 3 – самое функциональное приложение из тройки. Это интерпретатор Python 3 с менеджером пакетов pip и готовыми библиотеками для data science:

• numpy,
• scipy,
• matplotlib,
• scikit-learn,
• jupyter.

В премиум-версии доступны OpenCV, TensorFlow и PyTorch.

Есть поддержка GUI-приложений через Tkinter, Kivy с SDL2-бэкендом и PySide 6. Также встроен компилятор C/C++/Fortran для сборки нативных библиотек и Cython.

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

Cxxdroid – это компилятор C/C++ на базе Clang с поддержкой ассемблера. В менеджере пакетов есть популярные библиотеки:

• Boost,
• SQLite,
• ncurses,
• libcurl.

Графические библиотеки SDL2, SFML и Allegro доступны в премиум-версии.

Разработчики заморочились над системой кэширования, которая ускоряет сборку в среднем в 3 раза, а при использовании Boost – до 33 раз. Также есть режим интерпретатора (REPL) на основе CERN Cling для интерактивной работы с кодом.

Архитектура приложения исключает падения IDE из-за ошибок в пользовательском коде – анализ и компиляция выполняются одним компилятором.

Jvdroid работает на OpenJDK 11 – редактор поддерживает стандарты Java и jar-библиотек. Интегрирован с Maven для управления проектами и зависимостями. Компилятор оптимизирован с помощью Nailgun.

Приложение включает JShell для интерактивной работы с Java. Есть компиляция программ на Kotlin, Scala и Clojure через Maven. Ещё редактор показывает Javadoc для методов и классов.

Replit

• Веб-приложение: ✅
• Приложение на Android: ✅
• Приложение на iOS: ✅

Replit – облачная IDE с ИИ-агентом. Вы получаете помощника, который создаёт проекты по промпту: описываете идею приложения, агент предлагает функции, генерирует код и деплоит в облако.

Ассистент автоматически разбивает большие файлы на части, оптимизирует работу с API, добавляет нужные библиотеки. Есть поддержка основных языков:

• Python,
• JavaScript,
• TypeScript,
• C++,
• HTML/CSS,
• Java,
• Ruby и десятки других.

До 100 человек могут одновременно редактировать код. Готовые проекты деплоятся одним кликом. Доступна выделенная VM, автоскейлинг, деплой по запросу.

Встроенные инструменты:

• Автодополнение кода через Ghostwriter.
• Поиск и исправление ошибок в реальном времени.
• Модульное тестирование без настройки.
• Интеграция с GitHub (автосинхронизация).
• Аутентификация пользователей через Repl Auth.

ИИ-агент поддерживает ограниченный набор технологий – Flask и Node.js. С React и другими фронтенд-фреймворками могут быть проблемы. Интеграции доступны только с OpenAI, Google, PostgreSQL и S3.

Официальные приложения для iOS и Android позволяют кодить прямо с телефона. Интерфейс адаптирован под сенсорные экраны, поддерживается голосовой ввод для общения с ассистентом.

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

Termux (iSH Shell)

• Веб-приложение: ❌
• Приложение на Android: ✅
• Приложение на iOS: ✅

Termux – это полноценный Linux-терминал для Android. В отличие от редакторов кода, вы получаете ОС со всеми инструментами программиста. Можно работать с любыми языками программирования, компилировать код, устанавливать библиотеки, подключать базы данных, настраивать веб-серверы.

После установки в приложении вы увидите только чёрный экран – это Linux-терминал. Графического интерфейса нет, всё управляется командами.

Перед работой обновите систему:

Первая команда проверяет доступные обновления, вторая их устанавливает. На все вопросы отвечайте «Y».

Termux используют системные администраторы, разработчики, студенты IT-специальностей и все, кому нужна мобильная среда разработки. Единственный нюанс – нужно время на изучение bash, но это справедливая цена за мощный и гибкий инструмент.

Подведём итоги

Выбор мобильного редактора зависит от ваших задач:

• Для фронтенда подойдут CodePen (веб-разработка и прототипирование), Code Editor и Acode (универсальные редакторы с поддержкой HTML/CSS/JS).
• Для бэкенда есть отдельные IDE: Pydroid для Python, Cxxdroid для C/C++, Jvdroid для Java. Они работают автономно и включают все необходимые инструменты.
• Для экспериментов с ИИ попробуйте Replit – облачную IDE с умным ассистентом, который создаёт приложения по описанию.
• Для профессиональной разработки установите Termux (Android) или iSH Shell (iOS) – это полноценные Linux-терминалы с неограниченными возможностями.

Знаете классное приложение, которое не попало в подборку? Расскажите в комментариях о его плюсах и минусах! Ваши советы помогут коллегам в поисках идеального инструмента для работы с кодом на смартфоне.

Архитектура и обучение

GPT-5 — это языкoвая модель следующего поколения. Главное её отличие — в масштабе. По заявлениям руководства OpenAI, новая модель на порядок больше предшественницы. По оценкам, это триллионы параметров (~3–5 трлн). Однако GPT-5 — не просто увеличенная версия GPT-4: OpenAI объединяет разные подходы — классическое масштабное предобучение и спецмодели рассуждений («o-серия») — в единую архитектуру.

Сам Альтман назвал GPT-4.5 (внутреннее кодовое имя Orion) «последней моделью без chain-of-thought». GPT-5 же станет «объединённой» моделью, способной при необходимости выполнять развёрнутые логические размышления (chain-of-thought). Кроме того, в новой парадигме увеличена роль обучения с подкреплением и других методов: по словам Альтмана, GPT-5/6 будут использовать RL и делать научные открытия.

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

Тренировка GPT-5 потребовала огромных ресурсов — OpenAI, совместно с Oracle, наращивает датацентры (совокупная мощность >5 ГВт, свыше 2 млн чипов) для обучения своих самых продвинутых моделей.

Новые возможности по сравнению с GPT-4

GPT-5 обещает значительный скачок функциональности относительно GPT-4. Во-первых, модель станет полностью мультимодальной: помимо текста, она сможет работать с голосом, изображениями и, вероятно, видео. Во-вторых, GPT-5 уделяет особое внимание логическому мышлению: интеграция механизма chain-of-thought (пошагового рассуждения) даст модели способность разбивать сложные задачи на шаги и решать их значительно лучше GPT-4.

Ожидается также расширение контекста и памяти — GPT-5 сможет оперировать более длинными вводами и запоминать предпочтения пользователя, что сделает диалоги более непринуждёнными и персонализированными.

Предполагается переход от чат-бота к агенту: GPT-5 сможет автономно выполнять действия и сложные многошаговые задачи по запросу (благодаря интеграции со сторонними сервисами и инструментами). Наконец, OpenAI заявляет о работе над снижением галлюцинаций и bias — модель будет более точной и правдивой, избегая просто удобных/приятных ответов в пользу максимально полезных и честных.

Производительность и метрики

По предварительным данным и оценкам инсайдеров, GPT-5 демонстрирует существенно более высокие результаты чем GPT-4 во многих тестах. Например, технический директор Microsoft Кевин Скотт отметил, что если GPT-4 решает задания примерно на уровне школьника, то GPT-5 способен справляться на уровне аспиранта (PhD).

В OpenAI дают понять, что GPT-5 приблизит нас к качественно новому уровню интеллекта: Сам Альтман утверждает, что границ для возможностей GPT-моделей нет — при достаточных вычислительных ресурсах можно достичь ИИ, превосходящего человека практически во всех областях.

Области применения

Сфера использования GPT-5 ожидается очень широкой — от повседневных задач до высокоспециализированных исследований.

• В разработке ПО модель сможет генерировать и отлаживать более сложный код, ускоряя труд программистов. GPT-4 уже применялся для кода, GPT-5 улучшит эту функцию.
• В бизнесе GPT-5 найдёт применение для аналитики данных, написания отчётов, планирования стратегий и поддержки принятия решений.
• В науке и R&D ожидается новый уровень помощи — модель сможет выступать в роли интеллектуального ассистента исследователя: например, содействовать открытию лекарств и новых материалов. Представители OpenAI упоминали задачи масштаба поиска лекарства от редкого рака как посильные для GPT-5.
• Благодаря улучшенному пониманию контекста, образование и медицина тоже выиграют: GPT-5 может быть персональным наставником или консультантом, объясняющим сложные темы на понятном языке.
• Кроме того, переход к агентной модели означает, что GPT-5 сможет выполнять комплексные поручения (например, бронирование, покупки, управление расписанием) без детального пошагового контроля, что открывает возможности для автоматизации рутины во многих отраслях.

Реакция сообщества и экспертов

Выход GPT-5 вызывает смешанные реакции в техническом сообществе. С одной стороны, присутствуют опасения и призывы к осторожности: в марте 2023 года свыше 1100 экспертов (включая Илона Маска, Стива Возняка и ведущих исследователей ИИ) подписали открытое письмо с требованием приостановить обучение систем сильнее GPT-4 как минимум на полгода, предупреждая о рисках для общества. Тревога возникла из-за потенциальной угрозы неконтролируемого ИИ и массового вытеснения рабочих мест.

OpenAI частично разделяет озабоченность. Сам Альтман отмечал, что компания взяла паузу после GPT-4 и еще в июне 2023 подтверждал, что не начинала обучение GPT-5, уделяя время внешним аудитам и red-teaming для повышения безопасности модели. С другой стороны, многие специалисты с энтузиазмом ждут прорыв: например, в индустрии предполагают, что GPT-5 повысит уровень рассуждений и приблизит эру AGI (общего искусственного интеллекта). Руководители технологических компаний указывают, что подобные модели могут стать инструментом, доступным миллионам разработчиков и пользователей, позволяя им решать сложные проблемы — барьер входа в ИИ снижается, и это вселяет оптимизм.

Официальные заявления OpenAI

Несмотря на отсутствие полноценного анонса GPT-5, руководство OpenAI неоднократно комментировало планы по его разработке. На слушаниях в Сенате США (май 2023) CEO OpenAI Сам Альтман заявил под присягой, что компания «на данный момент не обучает GPT-5» и не планирует начинать в ближайшие месяцы. В начале 2024 года Альтман в интервью подтвердил, что не может назвать точную дату релиза GPT-5, но подчеркнул, что модель станет качественным скачком в способности к сложным рассуждениям; он в принципе не видит «потолка» для развития GPT при достаточных вычислительных мощностях.

В публичной «дорожной карте» OpenAI (озвученной 12 февраля 2025г.) было объявлено о скором выпуске промежуточной модели GPT-4.5, после чего через несколько месяцев запланирован GPT-5 (ориентировочно летом 2025). Альтман описал GPT-5 как «унифицированную систему», интегрирующую технологии предыдущих линеек (в том числе модель o3 для логики). При этом OpenAI подчёркивала, что выпустит GPT-5 только когда новая модель будет соответствовать внутренним стандартам качества и безопасности: в частности, если по итогам обучения она не окажется достаточно надёжной или безопасной, релиз могут отложить.

Также выходила статья о трудностях, с которых столкнулись разработчики GPT-5.

Как отмечает Никита Безлепкин, lead gen AI, автор телеграм-канала про AI, часто на основании инсайдов очень сложно понять, что реально будет из себя представлять модель:

Так как информации мало, она разнообразна — есть и PR, и дезинформация. Точно мы сможем узнать только в момент релиза. Конечно, качество можно проверить на основе популярных бенчмарков (например, арена), но все же я советую использовать свои бенчмарки, которые собраны на ваших реальных бизнес-кейсах.

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

Апдейт:

Команда OpenAI представила GPT-5 (видео на русском языке), новое демо 7 августа 2025