Без маркетинга и успешного успеха. Только боль, костыли и суровый прод! Мой пет-проект - бот «Щёлк-ГДЗ». Это ИИ-помощник, который решает школьные задачки по фоткам, видео, гс, тг-кружкам и PDF. Под капотом Python 3.12.3, aiogram 3, aiosqlite, апи OpenRouter (модель Gemini 3.0 Flash) и Робокасса. Крутится всё это на дешёвом VPS в Нидерландах. Держит 2500+ пользователей и не падает.

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

Нейронка вместо джуна и Уроборос багов

Сразу признаюсь... С нуля я это не писал :) Синтаксис мне генерили LLM-ки. Начинал с Gemini 2.5 Pro, затем перешел на 3.0 Pro, а сейчас использую 3.1 Pro.

Многие думают, что нейронка сама напишет проект "под ключ", но это миф. Я никогда не доверял ИИ проектирование архитектуры и использовал его как продвинутый StackOverflow (скармливал конкретную задачу (например, написать SQL-миграцию) и получал кусок кода).

ИИ — это не архитектор, а джун на спидах.

Как только логика усложнялась - гемини ловил «Уроборос багов». Кидаешь баг А - он его фиксит, но появляется ошибка Б. Скармливаешь и её - фиксит, но возвращается баг А. Цикл замкнулся. Лечилось только созданием новых чатов, в которые я кидал код и писал запросы типа "Найди критические ошибки, логические дыры и баги".

Про продуктовую логику нейронка вообще не слышала. В первой версии рефералки был баг, где любой(если его аккаунта ещё нет в БД) мог написать в конце ссылки что любые 9 цифр (?start=1234567890) и получить бонусы.

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

Немного про архитектуру.

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

main.py - это точка входа с настройкой логгеров, коннетами aiohttp и запуском APScheduler

database.py - вся работа с БД

neiro.py - логика общения с апи OpenRouter (стриминг, сжатие фоток через Pillow, JSON-контекст)

states.py - классы состояний aiogram.fsm.state (например, PaymentProcess, GdzMode)

utils.py - легковесные утилиты. Например лок пользователей (защита от спама запросами):

Хэндлеры вынесены в отдельную папку handlers/:

handlers/common_handlers.py - главное меню с обработкой /start (рефералки, utm-метки).

handlers/gdz_handlers.py - сам процесс ИИ-решения (вход в GdzMode, прием фото, видео, кружочков).

handlers/pay_handlers.py - это логика платежей (Robokassa) и "Умная корзина".

handlers/tasks_handlers.py - квесты (выдача премиума за подписку на каналы спонсоров).

Сборку интерфейсов вынес в all_def.py. Не люблю, когда в хэндлерах генерится полотно текста с кнопками. Там же лежат функции склонения слов (1 запрос, 2 запроса, 5 запросов). А в settings.py лежат списки с рандомными ответами бота, чтоб казался живым.

Так же в settings.py я сделал кэширование картинок, тоесть при первом запуске бот грузит фото меню как BufferedInputFile, сохраняет file_id от Телеграма и дальше шлет картинки моментально по ID. Сервак говорит спасибо за сэкономленный трафик)

В handlers/common_handlers.py находится первичная маршрутизация. Вот так обрабатываются рефералки, переходы с сайта, с рекламы и другое при старте:

Диета по токенам

Хранить бесконечную историю диалогов дорого и бессмысленно. В бесплатной версии храню 10 последних сообщений (5 пар вопрос-ответ), а в преме — 30.

Но фотки весят большое кол-во токенов. Если премиум-юзер закинет 30 фоток, OpenRouter выставит мне огромный счет. В итоге я прикрутил ограничение: Из 30 сообщений ИИ видит только 10 последних картинок.

Старые фотки тупо вырезаю из JSON. Подменяю на системный промпт:

С довольно неплохой моделью (gemini 3.0 flash) это работает как часы (она честно признается, что забыла картинку, а не выдумывает что-то из воздуха).

Стриминг, FloodWait и защита баланса

Чтобы бот не выглядел тормозом, я сделал стриминг ответа от ИИ в neiro.py. Я обновляю сообщение в Телеграме чанками по мере получения их от ОпенРоутера.

Но если делать message.edit_text слишком часто, ловишь FloodWait. В итоге я выставил интервал в 0.7 секунд и обернул всё в жесткий try/except:

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

В handlers/gdz_handlers.py это выглядит так:

SQLite тащит

Почему не Postgre? Потому что для микро-SaaS с 2,5к пользователей SQLite хватает за глаза. Но в асинхронной среде она любит кидать ошибку database is locked.

Чтобы этого избежать, я включил WAL-режим при инициализации пула, разделил коннекты на db_writer и db_reader, а сложные операции доверил самому SQL.

Например, 00:00 запускается крон-таска, которая собирает огромную аналитику, начисляет всем активным юзерам +1 ежедневный запрос и сбрасывает просроченные подписки. И это всё это работает атомарно внутри database.py:

Умная корзина на APScheduler

Когда дело дошло до монетизации, всплыли две проблемы:

Первая: юзер оплатил, но забыл нажать кнопку «✅ Я оплатил» в боте. Бот ждет, юзер ждет, товар не выдается, поддержка кипит.

Вторая: юзер сформировал счёт и передумал ("брошенная корзина").

Вместе с LLM я с нуля изучил apscheduler и убил двух зайцев фоновыми задачами. Теперь в handlers/pay_handlers.py при генерации ссылки на оплату я создаю две отложенные таски:

Как это работает?

Через 5 минут срабатывает async def auto_check_payment(), которая тихо стучится в робокассу. Если статус success - бот сам начисляет запросы на баланс и радует клиента. Если статус pending - таска умирает, и в дело вступает 30-минутная таска.

Но она не шлёт спам вслепую, а лезит в БД и проверяет 3 бизнес-правила:

1. await db.has_successful_payment_recently - Не купил ли он другой товар за последние 3 часа?

2. await db.get_latest_invoice_id - А это точно самый последний сгенерированный им счет?

3. await db.can_send_agitation - Не присылали ли мы ему агитацию недавно?

Если проверки пройдены, то юзер получает сообщение: "⏳ Домашка сама себя не решит! Ты начал оформлять покупку, но оплата так и не прошла...". Это поднимает конверсию оплат.

Финал

Почему я не использую Redis для стейтов? Ответ банален: мой дешевый VPS имеет всего 1 гб оперативки. Пул aiohttp, In-Memory стейты и асинхронные таски и так жрут 70% RAM. Редис тупо не влезет.

Как говорится, работает — не трогай.

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

Готов ответить на вопросы по архитектуре и послушать советы в комментариях \(^^)/

P.s. вот ссылка на первую статью о моём проекте:

P.s. Если кто-то хочет потестить вживую(не реклама), то юз бота в тг @gdzshchelk_bot

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

Это было взвешенное решение. В какой-то момент общий фреймворк превратился в поле мерж-конфликтов, где ты уже не тесты пишешь, а разбираешься, кто чей page object сломал и почему Android отвалился после правки для iOS.

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

Как говорил один мой коллега, перефразируя классическое “вам шашечки или ехать”:

Ты сюда страдать пришёл или тесты писать?

После этого решение разделить Android и iOS на два проекта стало очевидным.

Сейчас у меня два отдельных проекта: mb-android-tests и mb-ios-tests. И знаете что? Это лучшее архитектурное решение за всё время на этом проекте. Серьёзно.

Контекст: что за проект и почему это важно

Финтех. Нативное приложение. Отдельные кодовые базы, Kotlin на Android, Swift на iOS. И UI там не «три кнопки и список», формы с десятками полей, кастомные контролы, WebView-вставки, платежи, валютные операции, бюджетные переводы. Ну вы поняли.

Стек: Java 21, TestNG, Appium 2.x, Selenide, Allure, Maven. CI на GitLab, крутится на Mac Mini. 5 Android-эмуляторов, 4 iOS-симулятора, 9 Appium-серверов — по одному на устройство.

Но это сейчас. А начиналось всё с одного жирного монолита.

Старый проект: 8 модулей и конструктор-монстр

Идея была «как в книжке»: один репозиторий, модульная структура, переиспользование. DRY во все поля. Ну а чё, красиво же.

8 модулей. Один mvn clean install. Все зависят от mobile-automation-framework, в котором живут DriverFactory, BaseTest, общие Page Objects и слой Steps.

А DriverFactory принимал 11 параметров. Одиннадцать, Карл.

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

Когда я работал один, было норм. Ты сам знаешь, от куда что идет.

А потом пришли люди.

Почему с людьми всё навернулось

Мерж-конфликты каждый божий день

Вот конкретная ситуация. Один человек правит LoginPage в общем фреймворке, добавляет метод для iOS, меняет локатор. Второй в тот же момент рефакторит этот же LoginPage под новую версию Android-приложения.

Мерж. Конфликт.

И тут начинается самое весёлое: какой локатор правильный? Для Android? Для iOS? Для обоих? Кто будет разбираться? Тот, кто мёрджит? А он вообще контекст понимает?

Это не единичный случай. Это было каждый день. Потому что mobile-automation-framework получился общим модулем, от которого зависят все. И все туда лезут. Постоянно.

Обновление одной библиотеки = блокировка всех

Решил обновить java-client с 7.x на 8.x. Нормальное желание — API поменялся, MobileElement удалили, capabilities переехали на типизированные Options.

Вот что произошло в реальности:

1. Меняю версию в parent pom.xml
2. MobileElement удалён → compilation error в DriverFactory, во всех DriverManager’ах
3. DesiredCapabilities → UiAutomator2Options / XCUITestOptions → переписываю все менеджеры
4. selenide-appium 1.x несовместим с java-client 8.x → обновляю до 2.x
5. selenide-appium 2.x требует Selenide 6.x → обновляю Selenide
6. Selenide 6.x ломает API page objects → переписываю page objects во всех модулях
7. А Selenide 6.x ещё и Java 8 не поддерживает → обновляю Java

Одна библиотека.

Задача «обновить одну библиотеку» превратилась в 50+ файлов, 4-5 каскадных обновлений, 2-3 недели работы. И всё это время develop нестабилен. Все заблокированы. Тесты не запускаются.

Две недели.

Из-за одной строчки в pom.xml.

Page Objects с if/else — это два page object в одном файле

Общие Page Objects звучат красиво на бумаге: пишем один раз, используем для обеих платформ. А на практике…

Это не page object. Это два page objects, запиханных в один файл через if/else. И так в каждом методе.

А сверху ещё слой Steps. Обёртки над page objects «для читаемости». И в steps тоже if (platform), потому что логика взаимодействия разная. На Android ты скроллишь через UiScrollable семантически, «прокрути до элемента с текстом X». На iOS координатами, «двигай палец из точки A в точку B». Один метод в steps, а внутри два разных мира.

В какой-то момент ловишь себя на мысли: я же не тесты пишу. Я подгоняю pages и steps под две платформы, чтобы фреймворк не развалился. Это уже не автоматизация тестирования, это поддержка фреймворка ради поддержки фреймворка.

Каждый работает в своём темпе и все друг другу мешают

У одного задача покрыть тестами новый экран на Android. У второго пофиксить падающие тесты на iOS. У третьего добавить тестовые данные.

Все трое лезут в mobile-automation-framework. Все трое меняют pom.xml, BaseTest, page objects. Каждый в своей ветке.

А потом мёрдж.

Технические причины, которые добили окончательно

Ладно, человеческий фактор. Но были и чисто технические штуки, которые окончательно убедили меня, что кроссплатформа тут бессмысленна.

Локаторы: работай с тем, что дают

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

В теории есть AccessibilityID единый локатор для обеих платформ. Звучит хорошо. А на практике? Попробуй попросить мобильных разработчиков расставить одинаковые accessibility-идентификаторы на сотнях экранов. На Kotlin и Swift. Одновременно. Они тебя вежливо пошлют, но скорее всего не вежливо. И будут правы, у них свои спринты, свои дедлайны, и твои автотесты в их приоритетах где-то между «поправить тень у кнопки» и «никогда».

Так что реальный выбор:

XPath - работает, но на iOS может быть тормозным. На Android через UiSelector быстро, нативно, надёжно. На iOS через NSPredicate тоже ок. А «универсальные» XPath типа //*[@text='Войти' or @label='Войти'] это путь к боли, потому что Page Source на двух платформах два совершенно разных XML-дерева.

Координаты - костыль? Да. Но иногда единственный вариант. Когда у тебя кастомный контрол без accessibility-свойств, а разработчик говорит «это декоративный элемент», ты либо тыкаешь по координатам, либо не тестируешь.

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

Суть в том, что «напиши один локатор и работай на двух платформах» это миф. Page Source на Android это android.widget.Button с resource-id. На iOS XCUIElementTypeButton с name и label. Разные типы элементов, разные атрибуты, разная глубина вложенности. Разные миры.

StaleElementReferenceException — «подарок» от iOS

Android рендерит UI через Choreographer синхронно с VSYNC. Элемент появился → стабилен → кликаем.

iOS рендерит через CoreAnimation с неявными анимациями. Элемент есть в дереве, но ещё анимируется. Формально кликабелен, фактически хрен.

Стандартный WebDriverWait с elementToBeClickable это не ловит. Элемент «кликабелен» по мнению Appium wait завершается. А потом click() падает, потому что DOM изменился между вызовами.

На Android этой проблемы нет вообще. Тот же тест, тот же wait, тот же код зелёный на Android, красный на iOS. Один и тот же метод, два разных результата. И это не баг это фундаментальное различие платформ.

Кастомные wait-стратегии для iOS отличаются от Android принципиально. Пихать их в один фреймворк строить leaky abstraction, которая протекает на каждом шаге.

Жесты — два разных мира

Свайп вниз на Android:

Свайп вниз на iOS:

Чувствуете разницу? И даже длительность свайпа важна: на Android 200мс это нормальный скролл. На iOS 200мс это fling, и элемент улетает за экран.

«Кроссплатформенная» обёртка для скролла функция на 40 строк с двумя ветками if (platform), внутри каждой и ещё if для performSwipeDown() vs performSwipeUp(). На 50+ экранах таких обёрток, которых десятки.

И каждая место для бага.

Решение: разделяй и властвуй

Решение было болезненным. Я реально откладывал, потому что казалось, что это шаг назад. Дублирование кода, нарушение DRY, всё такое. Мозг сопротивлялся.

А потом я просто сел и разделил.

Никаких общих page objects. Никаких общих steps. Никакого общего DriverFactory с 11 параметрами. Каждый проект со своим pom.xml, свои зависимости, свой BaseTest, свои локаторы.

Что осталось общего: подход к структуре (Maven + TestNG + Allure), CI-шаблоны, принципы организации. Но не код. Код полностью раздельный.

Что поменялось на практике

В Android-проекте DriverManager типизирован под AndroidDriver. В iOS под IOSDriver. Не AppiumDriver<MobileElement> с кастами и проверками, а конкретный тип для конкретной платформы. IDE подсказывает только релевантные методы. Компилятор ловит ошибки на этапе сборки, а не в рантайме.

BaseTest принимает ровно те параметры, которые нужны. Android: deviceName, platformVersion, udid, appPackage, appActivity, systemPort, serverUrl, appPath — 8 штук, все релевантные. iOS: deviceName, platformVersion, udid, appPath, serverUrl, wdaLocalPort — 6. Никаких @Optional("systemPort") со строкой “systemPort” в качестве дефолта.

А мерж-конфликты?

Когда один человек работает в mb-android-tests, а второй в mb-ios-tests то они вообще не пересекаются. Разные репозитории. Конфликт невозможен физически.

Обновление java-client в Android-проекте не затрагивает iOS. Хочешь обновить, обновляй. iOS продолжает работать на старой версии.

Добавить новый параметр для iOS? Меняешь BaseTest и testng.xml в iOS-проекте. Android даже не узнает.

Это прям кайф.

А как же дублирование кода?!

Конечно, конечно. Первый вопрос, который задают: «Но ведь ты пишешь тесты дважды!»

Нет.

Я пишу каждый тест один раз и без костылей. Без if (platform) в каждом методе. Да, для одного и того же экрана есть два теста, один для Android, один для iOS. Но каждый из них чистый, понятный, заточенный под свою платформу.

В старом варианте я тоже «писал один раз», а потом тратил столько же времени на поддержку if/else, мерж-конфликты и каскадные обновления. «Экономия» на создании оборачивалась переплатой на поддержке. С процентами.

Когда кроссплатформа всё-таки ок

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

Приложение простое, пара экранов, стандартные контролы, минимум кастомного UI.

UI реально идентичен на обеих платформах. Бывает, наверное.

Команда из одиного человека. Сам пишешь, сам мёрджишь, сам разруливаешь. Голова справляется.

Минимум жестов. Нет сложных свайпов, drag-and-drop, pinch-to-zoom.

Если у тебя финтех, банк, enterprise-приложение с сотнями экранов, кастомными контролами и тремя+ QA, то два проекта дешевле. Не в строках кода, а во времени. В нервах. В часах, потраченных на мерж-конфликты вместо написания тестов.

Итого

Два проекта это не шаг назад и не двойная работа. Со стороны может выглядеть именно так, но на практике ты пишешь каждый тест один раз, под конкретную платформу, без лишних компромиссов. Потом поддерживаешь его без постоянных мерж конфликтов, каскадных обновлений и if/else в каждом втором методе.

Кроссплатформенный фреймворк на Appium для сложного нативного приложения часто оказывается иллюзией экономии.

В следующей статье покажу, как у нас устроена инфраструктура для 9 параллельных устройств на одном Mac Mini: порты, bash скрипты, Appium серверы и workaround’ы, которых нет в документации. Спойлер: там тоже всё не совсем как в гайдах.

Дело не в вопросах от HR и не в том, как часто вас дергают опросами 360. А в том, что удовлетворенность измеряют как настроение, хотя это метрика с формулой и порогом, после которого принимают решения.

Что измеряет eNPS и как читать диапазоны

eNPS строится на одном вопросе: готов ли сотрудник порекомендовать компанию знакомым как место работы. Ответ дают по шкале от 0 до 10, и на основе балла респондента раскладывают по трем группам.

• Самые критичные сотрудники обычно ставят от 0 до 6 баллов. Это сотрудники, у которых накопилось достаточно претензий к условиям, процессам или руководству, чтобы транслировать недовольство за пределы компании.
• Пассивные сотрудники ставят 7 или 8 баллов. Явного негатива нет, но нет и мотивации защищать бренд работодателя перед кем-либо.
• Амбассадоры (промоутеры) компании ставят 9 или 10 баллов и готовы рекомендовать компанию без каких-либо противоречий.

Формула расчета: доля промоутеров минус доля критиков, в процентах. Результат укладывается в диапазон от -100 до +100.

Интерпретация результата зависит от диапазона, в который попало итоговое число:

• 10-30 — компания на начальном этапе формирования культуры, точек роста больше, чем закрытых вопросов.
• 30-70 — рабочая среда с понятным вектором развития, где ценности компании транслируются в реальные процессы, а не остаются декларацией.
• Выше 70 — редкий результат, который означает высокий уровень внутренней лояльности к месту работы.

Но сам показатель eNPS мало о чём говорит. Например, уровень eNPS 25 в компании после большой перестройки процессов может означать, что команда постепенно привыкает к изменениям. Тот же показатель 25 в команде, где давно ничего не менялось, может указывать на накопившиеся проблемы.

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

Чем ESI отличается от eNPS

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

• оплату;
• нагрузку;
• качество обратной связи от руководителя;
• состояние рабочих инструментов.

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

У ESI нет единого целевого значения — эта метрика нужна для диагностики: она показывает отдельные проблемные зоны, а не даёт общую оценку компании.

Поэтому ESI редко измеряют отдельным опросом. Вопросы обычно добавляют в eNPS-анкету. В результате HR получает один отчёт с двумя уровнями данных:

1. общий уровень лояльности;
2. оценки факторов, которые на него влияют.

Зачем сравнивать результаты с текучестью

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

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

Дальше разберём, из чего состоит рабочий опрос.

Из чего состоит рабочий опрос

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

• простая и понятная формулировка;
• один конкретный аспект работы;
• чёткая шкала ответа.

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

Какие темы включить

Опрос обычно делят на несколько блоков:

1. Оплата, грейды и дополнительные льготы.
2. Работа с руководителем: постановка задач, обратная связь и поддержка.
3. Содержание работы: интерес к задачам, нагрузка и самостоятельность.
4. Карьерный рост и развитие внутри компании.
5. Команда и атмосфера.
6. Корпоративная культура и мероприятия.
7. Условия труда: офис, удалённая работа, доступы и ИТ-поддержка.

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

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

Периодичность: годовой опрос и пульс-опросы

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

Внеплановый опрос запускают после крупных изменений:

• слияния компаний;
• смены стратегии;
• перестройки процессов или пакета льгот.

В таких ситуациях прошлые данные уже могут не отражать текущее состояние команды.

Для чего нужны пульс-опросы

Пульс-опрос состоит из двух-трёх вопросов с готовыми вариантами ответа и необязательного поля для комментария. Такой опрос помогает быстро проверить реакцию сотрудников на конкретное изменение, например:

• новую систему льгот;
• переход на гибкий график;
• обновление внутреннего инструмента.

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

Что происходит после опроса

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

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

После опроса нужно закрыть цикл:

• определить проблему;
• назначить ответственного;
• установить срок для изменений.

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

Кто отвечает за изменения

HR собирает данные, рассчитывает eNPS и ESI и сравнивает результаты с текучестью по департаментам, а за изменения отвечают руководители процессов:

• тимлиды;
• руководители отделов;
• топ-менеджеры.

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

Когда нужен отдельный технический инструмент

Готового опросника недостаточно, если компании нужно связать результаты с другими HR-данными. Например, требуется:

• сравнивать eNPS и ESI с текучестью по департаментам;
• передавать данные пульс-опросов во внутреннюю HRM-систему;
• строить BI-дашборд с динамикой по кварталам и командам.

Для этого нужна отдельная система под структуру компании. Она может включать интеграцию опросника с HRM, ETL для объединения данных и отчёты для руководителей.

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

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

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

Редакция Tproger недавно была нескольких таких ивентах и на партнёрском дне Диасофт пообщалась с членом правления Диасофт и директором по работе с партнёрами Александром Сахаровым. Мы поговорили о том, почему агентская разработка в её нынешнем виде — тупик, как строить эффективные AI-процессы разработки, почему фреймворк теперь важнее модели и что нового в AI-обновлении платформы Digital Q.

Digital Q — российская low-code экосистема разработки от «Диасофт» с готовым «заводом» инструментов для сборки корпоративных приложений: от проектирования бэкенда, дизайна интерфейсов до DevOps. В мае 2026 года вышла AI-driven версия, где искусственный интеллект встроен в саму платформу — он проектирует архитектуру, генерирует код, фронтенд и бизнес-процессы по человекочитаемой спецификации, оставляя разработчику работу с замыслом, а не с рутиной.

AI добрался до фундамента

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

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

А шум — это вера, что AI всё решит сам по себе. Что можно купить лицензии Copilot, посадить за них разработчиков и они вам начнут производить продукты в десять раз быстрее. Нет, не начнут. Точнее, начнут, но счета вас очень неприятно удивят.

От агентов к AI-native платформе

Агентская разработка как самостоятельный подход не работает. Не масштабируется. Подход должен быть AI-native

— Вы на сцене показывали, как обновился Digital Q с декабря. Что конкретно поменялось за эти полгода?

— В декабре, на зимнем партнёрском дне, мы представили платформу Digital Q.GPT — на ней можно реализовывать агентский workflow. Интеграция со всеми LLM-моделями, экосистема построения агентов, мультиагентные системы. На тот момент это было супер актуально.

К маю выяснилось, что этого недостаточно. За последние шесть месяцев все — Anthropic, Google, Gartner, Amazon, Сбер на ЦИПР — пришли к одному и тому же выводу: агентская разработка как самостоятельный подход не работает. Не масштабируется. Подход должен быть AI-native, то есть AI вшит в саму экосистему разработки, а не прикручен сбоку отдельными агентами.

— А что плохого в агентах?

— С агентами ничего плохого, они нужны. Плохо, когда вся разработка строится только вокруг них. Если кто-то хочет писать агенты — пожалуйста, в Digital Q.GPT весь функционал остался: workflow, мультиагентные системы, всё это работает. Но это уже не центральная история. Центральная история теперь — единая экосистема, в которую AI встроен на каждом этапе процесса.

Три способа потерять деньги на AI

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

— Давайте про антипаттерны. Вы на сцене перечислили целый список — что точно делать не надо. Какой из них самый болезненный?

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

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

Третий — использовать AI только в кодировании. Это путь в галлюцинации и в бесконечные ошибки, которые вы потом просто не отследите.

— Как можно решить эти проблемы?

— Главный тезис: фреймворк важнее модели. Они это называют harness, мы называем экосистема разработки. Есть термины IDP — Integrated Development Platform, IDE — Integrated Development Environment. Суть одна. Ваш фреймворк должен быть локально у вас, весь контекст — локально у вас, модели должны быть взаимозаменяемые. Тогда вы можете переключаться между ними и управлять стоимостью.

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

Как теперь устроена разработка

— Вы говорили про два контура разработки. Объясните для тех, кто услышит об этом впервые.

— Раньше был один контур: ТЗ — постановка — кодирование — тестирование — релиз. Долго, последовательно. Цифровая трансформация это ускорила: годы превратились в кварталы и месяцы. Но всё равно один линейный процесс.

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

Второй контур — контур реализации. Здесь уже всё на агентах и моделях. Это фактически чёрный ящик под замыслом. Человек его контролирует только по результату. Не нравится — возвращается в контур замысла, правит спецификацию, перезапускает.

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

— Это та же мысль, что и про вендорлок, по сути?

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

— Вернёмся к Digital Q. Как она теперь устроена? Если разобрать на компоненты — что там лежит?

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

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

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

— Почему вы так настойчиво возвращаетесь к теме денег? Ведь все маркетинговые материалы AI-вендоров обещают именно экономию.

— Потому что это самая опасная иллюзия сейчас. Uber, пытаясь сэкономить на разработчиках, потратил больше трёх миллиардов долларов на AI-генерацию кода. Японская компания за несколько месяцев потратила 500 миллионов долларов вместо тех людей, которых сократили. Долларов, не рублей. И это уже не теория, это свежие кейсы 2025–2026 годов.

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

— И как вы с этим боретесь технически?

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

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

— Расскажите про демо с CRM. Вы показывали, как из 400-страничного ТЗ получается работающее приложение. Это правда один день двух человек, или там есть нюансы?

— Один день двух человек — это правда. Нюансы есть, конечно. Главный: это не black box, который сгенерил вам что-то непонятное. Это полностью оснащённый артефактами IT-проект. Можно пойти и сдать любому госзаказчику по ГОСТу. Полная документация — техническая, пользовательская, финансовая. Полный набор описанных бизнес-процессов. Полный набор тестов, включая тесты на уязвимости.

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

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

— А фронтенд?

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

Потом бизнес-процессы. Та же AI-машина смотрит на ТЗ и генерит BPMN-процесс — уже машиночитаемый, его можно сразу выполнять. Но она же его и критикует: смотрит со стороны и говорит — у вас тут проблема, тут проблема, ТЗ было неполным, давайте решать. И человек уже работает с агентом, который ему подсвечивает дыры.

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

— Вы говорили, что AI-агенты теперь работают не только в коде, но во всех ролях — от аналитика до девопса. Как это устроено?

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

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

Что доступно прямо сейчас

С июля начинаем публиковать обновлённую версию. Можно скачать, развернуть, запускать.

— И эта экосистема действительно доступна партнёрам?

— Да, мы её отдаём рынку. С июля начинаем публиковать обновлённую версию для партнёров. Можно скачать, развернуть, запускать. Правда, нужно знать, что такое Kubernetes и Kafka — это не магический инсталлер для гуманитариев. Но если знаете — берёте и работаете.

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

— Возвращаясь к началу разговора. Вы фактически заявляете, что Диасофт — единственный, кто отдаёт такую экосистему рынку. Это правда так, или маркетинг?

— Это так. Давайте честно: на российском рынке такие экосистемы делают несколько компаний. Сбер, ВТБ, Тинькофф — для себя. Это им и нужно, у них колоссальные команды разработки, они это могут себе позволить. Кто-то из телекома делает для своих больших разработок. Иногда они пробуют что-то предложить рынку, но по большому счёту — это всё «для себя».

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

Если такого человека нет — никакая AI-генерация вас не спасёт. Будет только дороже и хуже.

— Какой главный совет тем, кто только сейчас задумывается о собственной AI-трансформации разработки?

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

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

Бонус: чек-лист «AI-разработка без иллюзий»

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

Чего точно не стоит делать:

— Сажать команду на одну LLM-модель — это вендорлок, и он будет дорожать;

— Разрешать разработчикам неограниченно гонять самую дорогую модель;

— Использовать AI только в кодировании, без интеграции в остальной процесс;

— Накупить разных инструментов и надеяться, что они потом «как-нибудь соберутся»;

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

Что стоит сделать:

— Держать экосистему разработки и весь контекст локально;

— Зашить в платформу переиспользование кода — половину нового модуля собирать из готового;

— Настроить лимиты: дешёвые модели для простых задач, перегенерация только изменённых частей;

— Разделить процесс на два контура — замысла (где работает человек) и исполнения (где работают агенты);

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

Реклама. Рекламодатель: ООО «Диасофт», ИНН 7715560268, erid: 2W5zFJRM88q

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

Данные: кандидаты не против AI — они против того, как его применяют

Начнём с масштаба. По данным SHRM Talent Trends 2025, доля AI в HR-процессах за год почти удвоилась — с 26% до 43% рабочих сценариев. Это говорит о том, что AI в найме больше не эксперимент, а новая норма.

Проблема в том, что кандидатский опыт за этой скоростью не поспевает. Свежий отчёт Greenhouse 2026 Candidate AI Interview Report (опрошено 2 950 активных соискателей в пяти странах) рисует довольно мрачную картину:

• 63% кандидатов проходили AI-интервью за последний год — рост на 13% всего за полгода;
• 38% уже снимались с процесса найма именно из-за AI-интервью, ещё 12% готовы уйти, если их обяжут его проходить;
• 51% из тех, кто всё-таки прошёл AI-интервью, не получили никакого результата — их либо проигнорировали, либо они всё ещё ждут ответа;
• 34% после AI-интервью стали хуже относиться к компании;
• 70% вообще не предупредили заранее, что их будет оценивать AI.

Отдельно стоит гостинг (ghosting) — внезапное молчание компании, когда кандидату просто перестают отвечать. По данным, которые приводит Fortune, в 2026 году с ним столкнулись 53% соискателей, это трёхлетний максимум (против 48% в 2025 и 38% в 2024). И связывают этот рост напрямую с AI: инструменты позволяют кандидатам рассылать отклики пачками, рекрутеров заваливает и они просто не отвечают тем, кому отказ пришёл автоматически. Классическая петля обратной связи: чем больше автооткликов, тем больше автоотказов.

Мы решили проверить это на своей аудитории

Чтобы не опираться только на публичные отчёты, мы провели два анонимных опроса в наших Telegram-каналах: один про главную боль в AI-найме (2 633 голоса), второй — про влияние на отношение к компании (2 273 голоса).

Результаты близки к мировыми. Раздражает хотя бы что-то в AI-найме 90,7% опрошенных — вариант «меня это не раздражает» выбрали лишь 9,3%. Две главные боли идут вровень: невозможно достучаться до живого человека (30,4%) и шаблонный отказ без объяснения причин (30,2%). То есть сильнее всего бьёт не сама технология, а дегуманизация — ощущение, что тебя обрабатывает конвейер, а не рассматривает человек.

И, что важнее, это конвертируется в ущерб бренду. Отношение к компании после плохого AI-опыта меняется у 82,4% (не меняется только у 17,6%). А 22,2% готовы активно отговаривать знакомых от взаимодействия с такой компанией. Почти каждый четвёртый кандидат превращается в канал антирекламы.

Ключевой вывод из всех цифр один, и его хорошо сформулировали в Greenhouse: только 19% кандидатов хотят меньше AI в найме. Люди не против автоматизации — они против того, как её внедряют: без предупреждения, без объяснений и без возможности достучаться до человека.

Как компания «переAIивается»

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

Эйфория. Поток откликов вырос в разы, рекрутеры тонут, «Хоризон» покупает систему автоскрининга. Первый год — восторг: время до шортлиста падает, стоимость найма снижается. Именно на этом успехе компании и «переAIиваются», он выглядит как повод автоматизировать всё подряд.

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

Автоотказы приводят к судебному иску. Чтобы разгрузить рекрутеров, «Хоризон» включает критерии автоматического отказа. Так поступила iTutorGroup: её софт автоматически отклонял женщин от 55 лет и мужчин от 60, отсеяв больше 200 квалифицированных кандидатов. Вскрылось случайно: кандидатка подала две одинаковые анкеты, отличавшиеся только датой рождения, и приглашение на собеседование получила только с более «молодой» версией резюме. Итог — 365 000 долларов по мировому соглашению с EEOC, первому в истории по AI-дискриминации в найме. И урок для каждого HR-отдела: даже когда дискриминацию автоматизирует технология, ответственность всё равно несёт работодатель.

Doom loop и системный риск. Опыт кандидата иногда схлопывается ещё до конвейера. Как в деле против Workday: истец подал больше сотни заявок через платформу и получил отказы по всем, причём часто в течение минут, иногда посреди ночи. Так он заподозрил, что решение принимала машина. В мае 2025 суд разрешил вести иск как коллективный, от лица потенциально сотен миллионов соискателей, а по собственным данным компании за спорный период через её инструменты было отклонено 1,1 млрд заявок. Workday обвинения отрицает и настаивает, что её инструменты не принимают решений о найме, но в июне 2026 суд в Калифорнии позволил части претензий двигаться дальше. Суть здесь в том, что ответственность может лечь и на вендора, а не только на конкретного работодателя.

Где «Хоризон» теряет не деньги, а бренд. Кандидаты, отсеянные «за секунды в два часа ночи», редко идут в суд — они пишут отзывы и предупреждают знакомых. Это ровно то, что показал наш опрос: 82,4% меняют отношение к компании, 22,2% отговаривают других. Юридический иск довольно редкое явление, а репутационные потери — ежедневное и почти неизбежное.

Найм в «Хоризон» сломал не сам AI, а три конкретные вещи: решения без человека, отказ без объяснения причины и полное исчезновение живого контакта. По сути, компания автоматизировала не рутину, а именно те точки, где кандидат ждёт человека.

Чек-лист: где AI работает, а где вредит

Если свести все прецеденты и данные вместе, станет понятно, что граница проходит не по технологии, а по тому, ждёт ли кандидат в этой точке человека. Там, где взаимодействие и так безличное, AI должен выступать ассистентом, оптимизировать процесс. Риск начинается там, где AI перестаёт помогать человеку и начинает принимать за него решения — именно эти сценарии привели к судебным искам из кейсов выше, и 22,2% готовых к антирекламе в нашем опросе.

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

AI помогает:

• Написание и оптимизация текстов вакансий;
• Первичный парсинг и сортировка резюме — как один из сигналов, а не как решение;
• Планирование, перенос интервью, напоминания;
• Ответы на типовые вопросы о вакансии и статусе заявки;
• Черновики писем, которые редактирует человек.

AI вредит:

• Автоматический отказ без проверки живым рекрутером;
• Отказ без внятной причины;
• AI-видеоинтервью «с роботом» как единственный этап;
• Полное отсутствие человека на всём пути;
• Анализ мимики и эмоций — запрещён EU AI Act с февраля 2025 года.

Как понять, что на конкретном этапе нужен человек? Простой тест: представьте, что кандидат спросил «почему так?». Если у вас есть понятный ответ и за решением стоял человек — этап в зелёной зоне. Если ответить нечего или всё решил алгоритм — этап пора возвращать людям.

Фреймворк «Human-in-the-loop»: алгоритм советует, человек решает

Хорошая новость: кандидаты сами подсказывают, как надо. В том же отчёте Greenhouse они называют, чего им не хватает: раскрытия факта использования AI (44%), понятного объяснения, что именно AI оценивает (39%), возможности запросить человека вместо робота (46%), гарантии, что человек проверяет оценку AI до решения (38%), и доказательств, что систему проверяли на предвзятость (29%). Это, по сути, готовое ТЗ на здоровый процесс.

Всё это складывается в один принцип: алгоритм советует — человек решает. Ни одно значимое кадровое решение (найм, отказ, повышение) не отдаётся модели единолично; её оценка — лишь один сигнал среди многих.

На практике принцип держится на трёх опорах:

• Объяснимость: вы должны уметь сказать, почему кандидат А оказался выше кандидата Б, причём сказать это самому кандидату, а не только себе;
• Аудируемость: должна быть возможность проверить, что живой рекрутер видел и подтвердил рекомендацию AI, а не проштамповал её вслепую;
• Тест на предвзятость: систему нужно регулярно проверять на демографические перекосы и другие отклонения, иначе повторится история Amazon, где модель годами воспроизводила состав команды, пока это не всплыло.

Про прозрачность. Стоит ли открыто говорить кандидатам о том, какие этапы автоматизированы? Обычно это воспринимают как риск, хотя это наоборот хороший сигнал от работодателя кандидатам. Раз 70% кандидатов узнают об участии AI уже постфактум, то честное «вот здесь у нас работает машина, а здесь — человек» само по себе выделяет работодателя на общем фоне и повышает уровень доверия кандидатов.

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

Что в итоге

AI в найме — не зло и не мода, от которой можно отмахнуться: 43% HR-процессов уже так или иначе на нём. Но данные с обеих сторон — и отчёты, и наш опрос — сходятся в одном: кандидаты уходят не от самого AI, а от плохого опыта, который создаёт неправильно выстроенный AI-процесс. У кандидатов должно оставаться ощущение, что их рассматривают, а не просто обрабатывают на конвейере.

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

Хотите провести свой опрос или разместить материал? Пишите нам.

С практической точки зрения проект на**й не нужен. Есть 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Г-канал — там я публикую все свои эксперименты, код и приглашаю к обсуждению. Только факты, мат и никакой политоты.

SafeLine WAF — это бесплатный инструмент, который я лично тестировал.

Это полностью open-source решения, продукт с действительно бесплатной Community Edition, где ключевые функции не урезаны.

SafeLine WAF — веб-приложенийный межсетевой экран, который действительно поставляется с разумными настройками по умолчанию

Что он делает:

Защищает веб-приложения от SQL-инъекций, XSS-атак, командных инъекций, CSRF, SSRF, атак включения файлов и других угроз из списка OWASP Top 10. Также поддерживает защиту от CC/DDoS-атак, управление ботами и может работать как шлюз аутентификации.

Почему он:

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

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

Некоторые показатели, которые стоит учитыват

1. Уровень обнаружения - SafeLine (Balanced) (71.65%), ModSecurity (Level 1) (69.74%), Cloudflare (Free) (10.7%)
2. Уровень ложных срабатываний - SafeLine (Balanced) (0.07%), ModSecurity (Level 1) (17.58%), Cloudflare (Free) (0.07%)
3. Точность - SafeLine (Balanced) (99.45%), ModSecurity (Level 1) (82.20%), Cloudflare (Free) (98.40%)

Сбалансированный профиль SafeLine обнаруживает более 70% атак, при этом блокируя легитимный трафик ошибочно всего в 0.07% случаев. Это именно тот уровень настроек по умолчанию, который можно использовать в промышленной среде без постоянного ручного контроля.

Установка выполняется одной командой

После запуска он разворачивается как набор Docker-контейнеров: Tengine (форк Nginx) используется в качестве reverse proxy, отдельный сервис отвечает за семантический анализ, PostgreSQL хранит конфигурации и логи, а удобная веб-панель администратора работает на порту 9443.Community Edition поддерживает до 10 сайтов, чего достаточно для большинства личных проектов и небольших бизнес-сценариев.

Сайт: https://cyberserval.tech/landing/safeline

GitHub: github.com/chaitin/SafeLine (более 21 тыс. звёзд)

Лицензия: GPL-3.0 / MIT (Community Edition)

Откуда берётся желание всё бросить

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

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

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

Где заканчивается норма

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

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

Откуда злость на коллег

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

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

Как наблюдать за собой

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

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

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

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

Итого

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

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

Почему инфраструктура начинает привлекать больше, чем фичи

С фичами всё прозрачно: написал код — увидел результат на экране. Быстрая и понятная обратная связь. Но со временем замечаешь, что проблемы повторяются. Приложение тормозит не из-за плохого кода, а потому что на один экран уходит пять-шесть сетевых вызовов. Логика на клиенте. Хочешь что-то изменить — готовь релиз, проходи App Store Review и жди недели, пока обновление дойдёт до всех.

Я перешёл в Android-инфраструктуру — начал делать инструменты для других мобильных разработчиков. Это помогло увидеть: главные проблемы не в фичах, а в слое между приложением и бэкендом.

Возвращаться к фичам стало неинтересно. В инфраструктуре задачи сложнее, результат измеряется метриками — latency, error rate, скорость релизов, — а влияние на всю систему, а не на один экран.

Что Android даёт для инфраструктуры — а чему учиться с нуля

Мобильный бэкграунд оказался не балластом, а преимуществом. Я понимал ограничения изнутри. Backend-инженер может прочитать, что мобильные сети ненадёжны, память ограничена, а батарея — критичный ресурс. Но прочитать и прочувствовать — разное. Я годами наблюдал, как приложение “захлёбывается” на устройствах среднего сегмента. Знал, что 60% пользователей сидят именно на таких. Видел, как баг, который мы починили за день, продолжает висеть у людей неделями — просто потому, что они не успели обновиться.

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

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

Чему пришлось учиться с нуля? Операционному мышлению. В Android ты выпускаешь релиз — и он либо работает, либо нет. Если крашится, починишь в следующей версии. В инфраструктуре нет «следующей версии». Если gateway падает, всё приложение ложится для миллионов пользователей прямо сейчас.

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

Что делать, если один из пяти сервисов не ответил? Как понять, что мы катимся к инциденту, до того, как пользователи начнут жаловаться?

Этому в мобильной разработке не учат.

Как я учился: пробелы, сроки и смена мышления

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

Учился итеративно, не пытаясь объять необъятное сразу. Gateway начинался как простой прокси. Затем добавили агрегацию ответов, потом — конфигурационные определения экранов. Каждый такой шаг вынуждал осваивать следующий уровень: circuit breakers, стратегии повторов, observability, планирование мощностей.

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

Что означает «выдающийся уровень» в инфраструктуре

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

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

Затем — миграция живой системы, где права на ошибку практически нет. Приложение нельзя выключить или отрепетировать в реальном масштабе. Остаётся только постепенный перевод трафика: shadow mode → 1% → 5% → 25% → 50% → 100%, с автоматическим откатом при любом росте ошибок. И всё это — пока миллионы пользователей активно работают с продуктом, не подозревая, что под капотом идёт замена двигателя на ходу. Такой уровень дисциплины и инструментации приходит только с практикой.

Наконец, владение надёжностью. Gateway — единая точка отказа: упал он, упало всё. Годы уходят на то, чтобы сделать его скучным и предсказуемым: резервирование, автомасштабирование, circuit breakers, режимы деградации, еженедельный пересмотр мощностей. Высший пилотаж — когда о системе просто не думаешь, потому что она работает.

Почему путь в инфраструктуру доступнее, чем кажется?

Карьерные траектории в инфраструктуре редко бывают чётко описаны. Здесь нет готового чек-листа в духе «диплом по Computer Science, пять лет в бэкенде, обязательное знание Kafka и Kubernetes». С одной стороны, такая неопределённость пугает. С другой — именно она и делает этот путь более доступным, чем принято думать.

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

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

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

Мобильный бэкграунд как преимущество архитектора

Считаю ли я, что мобильный опыт сделал меня лучшим архитектором для mobile-first продуктов? Безоговорочно, да.

Я помнил, как ощущается медленный экран на устройстве среднего сегмента. Помнил, что случается, когда API возвращает слегка неправильные данные и приложение падает при парсинге. Помнил то чувство, когда баг уже в проде, а ты ждёшь App Store Review и ничего не можешь исправить.

Поэтому когда я проектировал gateway, я не занимался абстрактной «оптимизацией перформанса». Я опирался на совершенно конкретный опыт. Знал, что убрать один сетевой round trip — это подарок каждому мобильному разработчику. Знал, что перенос логики на сервер означает перенос в место, где я могу починить всё за минуты, а не за недели.

Лучшая инфраструктура для мобильных продуктов строится теми, кто сам их создавал и знает все узкие места не понаслышке. Этот опыт даёт верное направление: ты чувствуешь, где настоящие проблемы, потому что сталкивался с ними лично. Такому не учат по книгам.

Коротко: что делать, если думаете о переходе

• Найдите промежуточный шаг. Не прыгайте сразу в бэкенд. Начните с задач на стыке: оптимизация API, инструменты для мобильных разработчиков, улучшение сетевого слоя.
• Используйте мобильный контекст как рычаг. Вы понимаете то, о чём бэкенд-инженеры только догадываются. Говорите об этом вслух.
• Учитесь измерять невидимое. В инфраструктуре результат — это метрики: latency, error rate, скорость релизов. Учитесь рассказывать историю через цифры.
• Проектируйте под отказ, а не тушите пожары. Senior-уровень — это определить, что сломается и кто за это отвечает, до того, как оно сломается.
• Не ждите разрешения. Путь не размечен, но он открыт. Начните с малого — и двигайтесь туда, где задачи становятся интереснее.

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

Так появляется классическая ловушка legacy: систему надо модернизировать, но остановить развитие нельзя. Переписать всё с нуля страшно, поддерживать как есть — всё дороже. В результате продукт обрастает временными решениями, скорость разработки падает, а стоимость каждого следующего изменения растет.

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

Почему Big Bang-переписывание чаще всего заканчивается плохо

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

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

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

Допустим, команда решила переписать модуль заказов в e-commerce-продукте. В старой версии есть корзина, промокоды, доставка и оплата. Команда планирует за полгода сделать новый сервис заказов. Но за эти полгода бизнес добавляет подписки, подарочные сертификаты, частичную оплату бонусами и новую логику возвратов. В итоге новая система, которую проектировали под старые требования, к моменту релиза уже нуждается в доработке.

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

Big Bang всё-таки бывает оправдан — но в узких условиях. Если кодовая база молодая (год-два), пользователей мало, у системы нет критичного состояния в БД и продукт можно временно заморозить или вести в обоих контурах параллельно, полное переписывание может оказаться дешевле постепенной миграции. Это редкая ситуация, и она быстро исчезает по мере роста продукта. В зрелых системах безопаснее работает другой подход — постепенная архитектурная эволюция.

Пример: как команда переписала сервис документов и потеряла полгода

Команда сопровождала сервис — старый модуль на aiohttp с Pydantic v1, через который проходила вся обработка путевых листов и актов осмотра транспорта. Сервис существовал шесть лет, был покрыт тестами фрагментарно, а его API использовали мобильное приложение водителей, диспетчерская веб-панель и пакетный импорт.

Команда решила переписать сервис целиком: перейти на FastAPI, обновить Pydantic до v2, заодно почистить контракты и заменить внутреннее хранилище документов с MongoDB на PostgreSQL. План был рассчитан на четыре месяца.

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

Во-первых, переписывание шло параллельно с продуктовой разработкой. За время миграции бизнес добавил два новых типа документов и изменил правила подписи актов. Новая система проектировалась под старые требования и к моменту готовности уже не соответствовала продукту.

Во-вторых, команда не написала характеристических тестов. Поведение «как есть» нигде не было зафиксировано, и расхождения находились только в продакшене после переключения.

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

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

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

Strangler Fig Pattern: как заменить систему по частям

Один из самых практичных подходов к модернизации legacy-кода — Strangler Fig Pattern. В софтверном виде паттерн был сформулирован Мартином Фаулером в 2004 году под названием StranglerFigApplication. Идея проста: не переписывать систему целиком, а постепенно выносить отдельные части в новую реализацию.

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

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

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

Strangler Fig хорошо работает там, где между старым и новым кодом есть сетевая граница: HTTP, message bus, RPC. Если такой границы нет — например, нужно постепенно заменить функцию или класс внутри одного процесса — используется родственный паттерн Branch by Abstraction: над старой реализацией создается абстракция, рядом пишется новая реализация, переключение происходит через конфигурацию или фича-флаг, после стабилизации старая ветка удаляется. Снаружи это выглядит как Strangler Fig, но без сетевого прокси.

Такой подход снижает риск. В системе нет одного большого релиза, где всё меняется сразу. Есть серия небольших контролируемых изменений. Каждое можно протестировать, измерить и откатить.

Главное правило: сначала повторить поведение, потом улучшать

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

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

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

Прежде чем менять поведение, его нужно зафиксировать. Для этого пишут характеристические тесты (characterization tests, иногда называемые golden master или approval tests). Идея простая: на реальных данных или их обезличенных копиях прогоняется старая реализация, её ответы сохраняются как эталон, и любые будущие изменения, отклоняющиеся от эталона, отлавливаются автоматически. Тесты пишутся не для красоты, а для того, чтобы зафиксировать существующее поведение — даже странное — перед тем, как его трогать. Подробно эта техника описана у Майкла Физерса в книге Working Effectively with Legacy Code; на практике её удобно реализовать через библиотеки семейства approval-tests (approvaltests-python, approvaltests-java и аналоги).

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

Feature toggles: как включать новую логику без риска

Feature toggles, или фича-флаги, — один из главных инструментов безопасной миграции. Они позволяют включать и выключать новую логику без деплоя.

В обычной разработке релиз часто выглядит бинарно: код либо выкатили, либо нет. При миграции legacy это неудобно. Гораздо безопаснее иметь возможность включить новую реализацию для 1% пользователей, затем для 10%, потом для половины аудитории и только после этого для всех.

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

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

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

Важно различать два разных типа флагов. Флаг постепенной выкатки (rollout flag) меняется редко и контролирует, какой процент пользователей видит новую логику. Kill switch — отдельный флаг, единственная задача которого — мгновенно выключить новую реализацию при инциденте. Kill switch должен опрашиваться на каждом запросе, его кэширование должно жить секунды, а не минуты, и он принципиально не должен зависеть от той системы, которую он выключает. Иначе в момент аварии может оказаться, что выключатель сам недоступен.

В качестве инфраструктуры для флагов команды обычно берут одну из платформ: LaunchDarkly, Unleash, Flagsmith, GrowthBook, либо собирают собственную поверх Redis или конфигурационного сервиса. Для миграции важны три свойства: быстрое распространение изменений (секунды, а не минуты), поддержка таргетинга по пользователю/сегменту и аудит — кто и когда менял флаг.

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

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

Shadow testing: как проверить новую систему на реальном трафике

Feature toggles помогают безопасно переключать пользователей. Но перед этим хорошо бы понять, совпадает ли новая логика со старой. Для этого используют shadow testing.

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

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

Два момента, на которые стоит обратить внимание в этом коде. Теневой вызов запускается через asyncio.create_task — корутина сразу планируется в event loop и начнёт выполняться, как только функция вернёт управление. И весь блок завернут в try/except: исключение в новой логике не должно ронять основной запрос. Без этих двух свойств shadow testing рискует ухудшить продакшен вместо того, чтобы безопасно его проверить.

Небольшая оговорка для продакшена: event loop держит на task только слабую ссылку, и без сохранённой ссылки задача может быть собрана сборщиком мусора прямо во время выполнения. В реальном коде Task имеет смысл класть в set фоновых задач и удалять оттуда через add_done_callback. В примере выше эта обвязка опущена для читаемости.

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

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

При этом важно отличать теневую проверку чтения от теневой проверки записи. Чтение проверить относительно дёшево: запрос идёт в обе системы, ответы сравниваются, никаких внешних эффектов нет. С записью всё сложнее. Если новая реализация в shadow-режиме действительно создаст заказ, спишет деньги или отправит письмо, у пользователя возникнут двойные эффекты. Поэтому для writes либо вводят идемпотентные ключи и shadow-режим без реальных побочных действий (внешние вызовы заменены no-op-стабами, БД — отдельной shadow-копией), либо вообще отказываются от теневой проверки записи в пользу постепенной выкатки за фича-флагом.

Сравнение ответов в реальной системе тоже не сводится к одной функции compare. Нужно отдельно решать, как игнорировать «нормальный» шум (метки времени, идентификаторы, порядок коллекций), как сэмплировать трафик, чтобы не утопить хранилище расхождений, и как организовать триаж — кто и в каком ритме разбирает накопившиеся диффы. Готовые решения этого класса — GitHub Scientist (Ruby и его порты в другие языки), Twitter Diffy, либо собственный лёгкий регистратор поверх Kafka и таблицы расхождений.

С чего начинать модернизацию

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

Удобный способ выбрать первый кусок — оценить кандидатов по двум осям: насколько модуль критичен для бизнеса (low / high) и насколько сильно он связан с остальной системой (low / high). Начинать стоит с квадранта low-criticality + low-coupling: ошибки в нем не уронят бизнес-показатели, а малое количество зависимостей позволит провести миграцию полностью, не утянув за собой смежные модули. Высоко-критичные и сильно связанные части (платежи, ядро авторизации) трогают в последнюю очередь — на этот момент команда уже наберёт опыт безопасной миграции.

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

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

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

Миграция данных: самая сложная часть

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

Базовый рабочий приём — Expand-Contract (он же Parallel Change). Изменение схемы делается в три такта. На этапе expand в БД добавляются новые поля, таблицы или индексы, при этом старое поведение полностью сохраняется. Затем — migrate: обе реализации начинают писать и в старое, и в новое место (dual writes), а отдельный фоновый процесс делает backfill — заполняет новые поля историческими данными. После этого читатели по одному переключаются на новую схему. Только когда никто из читателей не использует старую структуру, наступает contract — удаление лишних колонок и таблиц.

Несколько практических деталей, которые часто упускают:

· Dual writes — это не бесплатная операция. Две записи означают две точки отказа. Если одна из них упала, нужно решать, что делать: продолжать ли работу, ставить ли событие в очередь на повтор, помечать ли запись как несогласованную. Простое «сначала пишем туда, потом сюда» в продакшене на нагрузке приводит к расхождениям.

· Backfill часто длиннее, чем кажется. На большой таблице миграция в одном UPDATE блокирует продакшен. Поэтому backfill делают батчами по N тысяч строк с паузами, отслеживают прогресс и предусматривают возможность остановить и продолжить.

· Онлайн-изменения схемы на крупных таблицах делаются не штатным ALTER TABLE, а специализированными инструментами: gh-ost или pt-online-schema-change для MySQL, встроенные онлайн-механизмы PostgreSQL для индексов и колонок, Liquibase/Flyway — для управления версионированием изменений в репозитории.

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

Без этих шагов любая красивая фасадная архитектура наталкивается на разъезжающиеся данные — и тогда даже идеальный Strangler Fig снаружи не спасает.

Прокси-слой как точка контроля

Чтобы постепенно заменять legacy-код, нужно управлять маршрутизацией запросов. Для этого часто создают прокси-слой, API Gateway или фасад, через который проходит обращение к старой и новой логике. В терминах Domain-Driven Design такой слой часто называют Anti-Corruption Layer: он защищает новую реализацию от старых контрактов и наоборот, позволяя двум моделям сосуществовать без взаимного «загрязнения».

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

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

В качестве технической основы команды обычно берут один из трех вариантов: классический API gateway (Kong, AWS API Gateway), service mesh (Envoy, Istio) или более простой reverse proxy (NGINX, HAProxy). Service mesh особенно удобен, когда трафик уже идёт внутри Kubernetes-кластера: маршрутизацию можно менять конфигурацией, без правок кода клиентов и сервисов.

Например, мобильное приложение обращается к endpoint /orders/history. Раньше этот endpoint напрямую обслуживал монолит. После введения API Gateway приложение продолжает ходить по тому же контракту, но внутри gateway может решать, куда направить запрос: в legacy-модуль или новый сервис истории заказов.

Управление маршрутизацией обычно делается не «всё или ничего», а на основании атрибутов запроса: значения заголовка (X-Migration-Cohort: new), куки, хэша от user-id (стабильное разбиение пользователей на сегменты) или географического региона. Это позволяет выкатывать новую реализацию сначала на одну страну, на сотрудников самой компании или на тестовый сегмент — и только потом расширять охват.

Для клиента ничего не меняется. Для команды появляется управляемость.

Наблюдаемость: без метрик миграция превращается в гадание

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

Минимальный набор — это логи, метрики и распределенная трассировка (distributed tracing). Нужно понимать, сколько запросов идет в старую и новую реализацию, сколько ошибок возникает, как меняется latency, где появляются таймауты, какие статусы возвращаются, какие бизнес-метрики проседают.

Технические метрики стоит формулировать не как «средний ответ» и «процент ошибок», а в терминах SLI и SLO: целевые показатели вида «99.9% запросов на /orders/history отвечают быстрее 300 ms за 30 дней» с явным error budget. Latency измеряется по перцентилям (p50, p95, p99) — среднее значение почти всегда обманчиво, а хвосты распределения говорят о реальном опыте пользователя. На время миграции имеет смысл выставить отдельные SLO для нового и старого пути и сравнивать их.

В качестве инструментов де-факто стандартом стал OpenTelemetry для трассировок, метрик и логов — единый протокол, который пишет в практически любое хранилище. Дальше — Prometheus и Grafana для метрик, Jaeger или Tempo для traces, Sentry или аналог для ошибок. Для миграции важна возможность фильтровать метрики по «варианту» — отдельно по старому и новому пути — иначе все цифры смешаются и реальную динамику будет не видно.

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

Пример: новая система формально отвечает быстрее старой и не дает ошибок. Но после включения на 10% пользователей падает конверсия в оплату. Причина может быть не в серверной ошибке, а в изменении порядка полей, другом тексте сообщения или потере какого-то edge-case. Без бизнес-метрик команда может решить, что миграция успешна, хотя для продукта она уже создает проблему.

Практическая последовательность миграции

Рабочая последовательность обычно выглядит так.

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

Затем поверх legacy-логики создается стабильный контракт. Это может быть API, фасад, gateway или отдельный слой внутри приложения. Главная задача — сделать так, чтобы клиенты зависели не от внутренней реализации, а от понятного интерфейса. На этом этапе полезно вспомнить про contract testing (Pact, Spring Cloud Contract): автотесты со стороны потребителей фиксируют, что именно они ожидают от API, и предупреждают о ломающих изменениях до того, как они доедут до продакшена.

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

Следующий этап — shadow testing. Новая система получает копии реальных запросов, считает результат, но пользователю по-прежнему возвращается ответ legacy. Команда сравнивает результаты и устраняет расхождения.

Когда новая реализация достаточно стабильна, начинается постепенное переключение через feature toggles. Сначала внутренние пользователи, потом 1% реального трафика, затем 5–10%, затем 50% и только после этого 100%.

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

Последний этап — удаление старого кода. Это не формальность, а обязательная часть миграции. И «удалить старый код» — это не один коммит, а явный Definition of Done: вырезана старая ветка кода, удалён фича-флаг, обновлена документация и схемы архитектуры, переименованы или удалены устаревшие дашборды и алерты, обновлены runbook’и для on-call и проведено короткое внутреннее обучение. Если этого не сделать, через полгода никто уже не вспомнит, какой путь актуален, и легаси-ветвление останется в коде навсегда.

Откат миграций: дешёвый только пока не пошли записи

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

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

Полностью обратимые шаги. Чтение через новый сервис, расчёт «в тени», новые метрики. Откат — выключить флаг. Это самый комфортный режим, и в нём стоит держать миграцию как можно дольше.

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

Forward-only. После некоторой точки откат становится невозможен — например, после того, как старая схема удалена или внешние интеграции перенастроены на новый сервис. Такие шаги допустимы, но к ним нужно приходить отдельно, осознанно, с особенно строгими SLO в предыдущем этапе. До forward-only-перехода имеет смысл подержать систему в режиме параллельной работы дольше, чем по графику.

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

Пример: как тот же сервис мигрировали со второй попытки

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

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

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

Затем команда выбрала первый кусок для выноса — не весь сервис, а только чтение документов (GET /documents/{id} и GET /documents/by-driver/{driver_id}). Это была наименее рискованная часть: ошибки в чтении неприятны, но не ломают финансовые потоки.

Новый сервис написали на FastAPI рядом со старым. На уровне API Gateway появилось правило маршрутизации: запросы на чтение шли в старый сервис, но в фоне дублировались в новый. Ответ пользователю всегда возвращал legacy, а ответ нового сервиса сравнивался с эталоном и записывался в отдельную таблицу для разбора. Использовали обёртку поверх asyncio.create_task — на ответ пользователя теневой вызов не влиял.

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

Когда расхождений не осталось, включили фича-флаг на сотрудников самой компании. Через неделю — на 1% реальных водителей. Дальше шаг по 5%, 25%, 50%, 100% с паузой в несколько дней между этапами. На каждом шаге следили не только за HTTP-ошибками и latency, но и за продуктовыми метриками: количество подписанных актов, время от открытия документа до подписи, доля повторных запросов. Один раз пришлось откатиться с 25% на 5% — в одном из регионов выросло время отклика из-за неэффективного запроса. Исправили, выкатили снова.

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

Типичные ошибки при работе с legacy

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

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

Третья ошибка — отсутствие наблюдаемости. Без логов, метрик и трассировки команда не управляет миграцией, а угадывает. Особенно опасно смотреть только на технические ошибки и игнорировать бизнес-показатели.

Четвертая ошибка — не договариваться с бизнесом. Модернизация не должна быть невидимой «инженерной активностью в стол». Её нужно встраивать в roadmap, объяснять эффект и договариваться о приоритетах. Если бизнес не понимает, зачем команда тратит время на миграцию, работа будет постоянно проигрывать новым фичам.

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

Шестая ошибка — не удалять фича-флаги после миграции. Флаг, который сыграл свою роль и больше никогда не выключается, превращается в постоянное ветвление в коде. Через год команда не помнит, можно ли удалить такую ветку или там сидит важный edge-case. Через два — кода с такими «мёртвыми» флагами становится больше, чем основной логики. Поэтому каждый флаг должен заводиться с условием удаления («после полной выкатки и двух недель стабильной работы») и иметь ответственного, кто этим удалением займётся.

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

Компромиссы, к которым нужно быть готовыми

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

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

Но это контролируемая сложность. Она распределена во времени и управляется инженерными практиками. В отличие от Big Bang-риска, где команда долго работает с минимальной обратной связью, а потом выкатывает один большой релиз с максимальной неопределенностью.

Когда Strangler Fig особенно оправдан

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

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

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

Когда модернизацию лучше не делать

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

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

Модуль, который никто не трогает. Если код десятилетней давности продолжает работать, не падает, не требует изменений и не вызывает инцидентов, его «уродливость» — не повод его переписывать. Цель модернизации — упростить будущие изменения; если будущих изменений нет, цели тоже нет.

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

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

Что получает команда

Главный результат постепенной модернизации — управляемость. Команда начинает лучше понимать систему, контролировать изменения и снижать риск инцидентов.

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

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

Модернизация — это процесс, а не проект

Legacy нельзя «починить за квартал». Если система развивалась годами, она не станет простой после одного рефакторинга. Но её можно системно улучшать.

Strangler Fig Pattern, Branch by Abstraction, feature toggles, shadow testing и аккуратная миграция данных дают рабочую модель: выбрать ограниченный участок, описать контракт, реализовать новую версию, проверить её на реальном трафике, постепенно переключить пользователей и удалить старый код.

Это не самый быстрый путь. Зато он управляемый. А в зрелых продуктах управляемость важнее скорости.

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

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

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

Почему стеснительность путают со слабой экспертизой

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

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

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

Какие ошибки занижают кандидата

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

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

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

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

Где стеснительность мешает сильнее всего

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

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

1. Перед встречей уточнить у рекрутера, на что руководитель обычно обращает внимание

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

2. Второй чувствительный момент — обсуждение оффера

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

3. Лучше не откладывать всё до конца

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

Как подготовить рассказ о себе

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

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

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

Что сказать рекрутеру на первом собеседовании

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

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

После этого важно действительно отвечать развёрнуто.

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

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

Какие вопросы подготовить к работодателю

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

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

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

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

Кому стеснительность будет мешать

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

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

Как выбирать команду, если вы стеснительны

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

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

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

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

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

Итого

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

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

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

Всё началось с безобидного, почти рутинного тикета в саппорт:

«У меня тут несколько одинаковых карт создалось. Я вроде один раз нажимал, а их штук пять висит в приложении».

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

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

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

Мы начали разбираться. Стандартный мониторинг показывал норму: дашборды зелёные, в логах тихо, метрики CPU и памяти без отклонений. При этом в базе обнаруживались дубликаты, которых быть не должно. И только тогда, когда мы внимательно посмотрели на коммунальный API Gateway, то поняли что одно изменение от другой команды поменяло идемпотентность работы endpoint-а.

Проблема была структурно невидима для тех, кто находился ближе всего к ней. Отсутствие видимой проблемы не равно отсутствию риска — система просто ждала подходящего момента.

Что произошло: хронология инцидента

Архитектура была классической: Клиент → API Gateway → микросервисы,.

Сценарий развивался почти незаметно для стандартных средств наблюдения:

1. Фронтенд: Пользователь нажимает кнопку «Выпустить карту».

2. Gateway: Запрос начинает обрабатываться в API Gateway.

3. Микросервис по созданию карт: честно выполняет работу: создаёт запись в БД и возвращает `200 OK` в Gateway.

4. Новый микросервис: API Gateway вызывает новый микросервис и получает HTTP 500 в ответ от него. Исключение возникает уже после успешного вызова нашего микросервиса, и это ключевая точка разрыва: Gateway считает весь запрос неудавшимся, а ответ нашего микросервиса теряется.

5. Клиент: получает HTTP 500

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

7. Петля: Микросервис, ничего не зная о судьбе предыдущих ответов, послушно создавал карту за картой.

Круг замкнулся. Эпидемия началась.

В компании такого уровня это не было предусмотрено. И это такая обидная ошибка.

Как так получилось?

Вскрылось ошибочное предположение:

«В API Gateway вызов микросервиса создания карт всегда идет последним».

Таким образом идемпотентность достигалась «формально» - ведь если создание карты завершалось с ошибкой - это точно означало что и вызов API Gateway тоже завершится с ошибкой. Сработало ложное чувство безопасности.

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

Что потребовалось изменить

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

FAQ: Часто задаваемые вопросы

1. Почему нельзя просто заблокировать кнопку на фронте?

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

2. Чем идемпотентность отличается от дедупликации в БД?

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

3. Как долго хранить ключи идемпотентности?

На практике мы хранили ключи в основной базе данных без ограничения срока — затраты на хранение UUID по всем сущностям оказались небольшими. В общем случае минимальный срок зависит от конкретных сценариев использования — кому-то хватит и часа, а кому-то нужна неделя. В любом случае, окна должно быть достаточно, чтобы покрыть сценарии, когда пользователь возвращается к повтору запроса, например, на следующий день или когда клиентское приложение автоматически перезапускает отложенные запросы после восстановления сети. Бессрочное хранение не обязательно, но слишком короткий TTL создаёт риск дублей при длительных сетевых проблемах.

4. Что делать со старыми клиентами, которые не шлют request_id?

Мы сделали несколько версий API для создания карт — под разные версии приложения. Для новых клиентов работала полноценная идемпотентность с клиентским ключом. Для старых версий приходилось принимать риски и генерировать request_id на стороне сервера. Альтернативой может быть хэширование payload запроса, но это менее надежно и сложнее: таймстемпы и случайные поля могут отличаться от вызова к вызову. Поэтому мы выбрали подход с генерацией ключа на сервере для устаревших клиентов: риски дублей на переходный период оказались меньше, чем сложность поддержки двух схем валидации одновременно.

5. Обязательно ли делать идемпотентность для всех методов API?

Идемпотентность требуется только для методов, которые изменяют состояние системы — POST, PUT, PATCH и иногда DELETE. Методы чтения (GET, HEAD, OPTIONS) не изменяют данные, поэтому считаются идемпотентными по умолчанию.

6. Как понять, что в вашей системе уже есть скрытая проблема с дублями?

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

Если метрик ещё нет, вот три косвенных признака, которые помогут заподозрить неладное:

• В базе данных периодически появляются записи с одинаковым содержимым, созданные с разницей в несколько секунд.
• Пользователи жалуются на дубликаты карт, заказов или платежей, но вы не можете воспроизвести проблему локально, списываете на то, что пользователи что-то делают не так
• В логах API Gateway периодически всплывают HTTP 500 ошибки, но downstream-сервисы при этом отрабатывают успешно.

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

Итог

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

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

Практический чек-лист: что проверить в своей системе уже сегодня

• Убедитесь, что все критические мутирующие эндпоинты поддерживают ключ идемпотентности.
• Настройте алерты на аномальное количество запросов на создание сущностей от одного пользователя за короткий промежуток времени.
• Проверьте, как ваш API Gateway обрабатывает ошибки — не теряет ли он ответы downstream-сервисов.
• Убедитесь, что фронтенд корректно обрабатывает не только 200, но и 500, 502, 504, не провоцируя пользователя на повторные клики без необходимости.

Инструмент как часть личности

Возьмем типичную ситуацию: переход на новый стек или поддержка старой базы. Допустим, команда третью неделю (а иногда и третий месяц!) обсуждает, оставить Scala или перейти на Kotlin. Аргументы обеих сторон озвучиваются на первой же встрече, а затем просто повторяются от созвона к созвону. Кто-то говорит об экосистеме, кто-то — о кривой обучения. Внешне это выглядит как техническая дискуссия, но решение не принимается.

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

Программист, который пять лет пишет на Scala, не просто использует инструмент. Язык стал частью его мышления: как он декомпозирует задачи и выстраивает архитектуру. И когда кто-то предлагает перейти на Kotlin, человек слышит: «То, что ты умеешь, больше не нужно». Отсюда и высокий градус эмоций. Годы практики делают стек частью профессиональной идентичности. Оспорить выбор инструмента — значит задеть человека лично.

Ловушка единомышленников

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

Однако со временем команда перестает замечать собственные слепые пятна. Любой «человек со стороны» с его новым взглядом воспринимается как дилетант, пытающийся найти изъяны в идеальной системе. Холивары в таких коллективах особенно вязкие: все одинаково уверены, что «очевидное очевидно», а любое альтернативное мнение априори ошибочно или упоминается лишь в контексте «идея хорошая, но делать ее мы не будем».

Скульптура против Lego: конфликт ценностей

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

Хорошая аналогия — скульптура из мрамора против фигурки из Lego. Когда мы видим работы Страцца и Бернини, которые смогли передать в камне эффект тончайшей вуали, мы застываем в восхищении посреди музея. Но создание таких статуй требовало времени, а внести “правки от заказчика” означало бы подвергнуть риску всю работу: попробуйте исправить скол на мраморной статуе, которую ваяли сильно дольше, чем планировалось. В случае с конструкцией из Lego все намного проще: вынул блок, вставил другой, и вот из фигурки кошки уже получился «Тысячелетний сокол».

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

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

Конфликт как трудности перевода

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

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

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

Молчание как последствие конфликтофобии

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

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

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

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

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

После оффера уже начинается работа компании

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

Отдельно готовят информационный вход. Обычно это материалы по компании, welcome-видео, чек-лист первого дня и Onboarding book. HR остаётся контактом для человека до выхода, чтобы новичок не искал ответы через случайных людей в команде.

Onboarding book — внутренняя документация для новичка. В неё обычно входят история компании, ценности, FAQ, полезные контакты, ссылки на ресурсы и порядок действий для типовых ситуаций. Для разработчика в этом документе важнее рабочая часть: где лежит техническая документация, какие каналы используют для задач, как устроены доступы и кто помогает с настройкой.

Для удалённой команды подготовка начинается ещё раньше: технику и welcome-pack отправляют до первого дня, иначе старт задержится из-за доставки, склада и ручных уточнений.

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

• доступ к репозиториям;
• доступ к трекеру;
• доступ к документации;
• доступ к окружениям;
• доступ к внутренним чатам;
• инструкция по локальному запуску проекта;
• контакт человека, который поможет с первичной настройкой.

Команда должна знать, кто к ней пришёл

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

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

На старте лучше узнать:

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

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

Наставник

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

Первые задачи

Забудьте всё, чему вас учили на курсах. Не потому что знания бесполезны — просто в реальном проекте их почти негде применить сразу — каждый новый проект живёт по своим правилам и со своей логикой кодовой базы. Это могут быть сложные абстракции поверх абстракций — кто-то когда-то решил так сделать. Уникальные архитектурные решения — кто-то выдумывал. Костыли — потому что сроки горели.

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

Отдельно про ТЗ. В тикете почти никогда нет полного контекста. Часть вещей считается само собой разумеющейся, часть обросла локальным сленгом. Сделаете задачу — появится дополнительный контекст, который никто не упомянул, и придётся переделывать. Мотивация падает именно здесь.

Что помогает:

• Уточнять задачу до того, как начали, а не после
• Узнавать, кто писал этот код — иногда человек ещё в команде
• Не пытаться добивать задачу самостоятельно, где не понимаете систему, нужно уметь разговаривать

Атмосфера

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

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

Три месяца

У нормального онбординга есть план на три месяца — что делать сейчас, что через месяц, к какому результату прийти в итоге. Это убирает главную тревогу на новом месте — ощущение, что непонятно вообще всё и непонятно когда станет понятно.

Как выглядит нормальный ритм:

• Еженедельные one-to-one с руководителем — задачи, сложности, обратная связь
• Встреча с HR через две недели — как адаптируетесь, всё ли понятно, нужна ли дополнительная поддержка
• Итоговая встреча через три месяца — что получилось, что нет, что дальше

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

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

На что смотреть

Три признака, что онбординг нормальный:

• Техника пришла до первого дня, доступы открыты, HR на связи.
• Есть наставник и план на три месяца.
• Вас представили команде — не попросили познакомиться самому.

Три красных флага:

1. Нет наставника вообще.
2. Нет плана задач даже на первый месяц.
3. HR исчез после первого дня и больше не появлялся.

Если все три красных флага подняты одновременно — это то, как устроены процессы в этой компании. Дальше будет примерно так же.

Сделал себе инструмент, который это решает. Потом оформил в продукт. Называется 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 году в нашей стране был зафиксирован рост интереса крупного и среднего бизнеса к технологии облачного хранилища.

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

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

Вывод простой и непопулярный: для интернет-магазина CMS — это не «движок сайта», а контур бизнеса. Если он не тянет каталог, склады, оплаты и промо — экономия на старте превращается в налог на переделку.

Почему «красивая витрина» не спасает

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

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

Где Битрикс реально оправдан

На корпоративных и сетевых историях Битрикс заходит потому, что это не «лендинг с корзиной», а связка магазина с процессами: каталог, заказы, складские и клиентские сценарии из коробки, обмен с 1С как отдельная экосистема.

Был у нас запуск для стройсети: 80 000 товаров, несколько складов, отдельная математика скидок для B2B. На чистом PHP такое можно дописать, но это месяцы и жирный бюджет. На готовом контуре мы вышли в прод заметно быстрее — потому что решали задачу бизнеса, а не изобретали велосипед.

Цена лицензии и сервера — да, это не «бесплатный WordPress». Зато это честная модель: вы платите за то, что масштаб и интеграции уже заложены в архитектуру, а не пробиты латками.

Kогда разумнее WooCommerce и облако

Если у вас не миллион SKU и не десять складов, а тысяча позиций и простая воронка — связка WordPress + WooCommerce часто выигрывает по скорости запуска и по цене входа. Экосистема плагинов закрывает типовые задачи без заказной разработки на каждый чих.

Облачные SaaS вроде Shopify годятся, когда компании нужен быстрый старт без администрирования сервера и команды DevOps. Комиссии и ограничения платформы нужно закладывать в юнит-экономику заранее — но для проверки гипотезы это иногда лучший компромисс.

OpenCart и аналоги я чаще видел у проектов, где важна предсказуемость и «руки разработчика на аутсорсе»: проще найти исполнителя, меньше сюрпризов, чем на экзотике. Magento и тяжёлый enterprise-класс имеют смысл, когда команда уже сильная технически и каталог — это отдельный продукт, а не «сайт с корзиной».

Самопис — не зло, но это отдельная ставка

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

Если уже понятно, что платформа не та

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

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

Что мы делаем перед выбором

• Считаем не «стоимость запуска», а стоимость трёх лет жизни: лицензии, хостинг, доработки, интеграции.
• Фиксируем сценарии: каталог, промо, B2B/B2C, обмен с учёткой, маркетплейсы.
• Закладываем буфер на рост — если через год SKU вырастет в пять раз, платформа должна выдержать без полной переделки.
• Перед подписанием уточняем у подрядчика три неудобных вещи: сколько стоит час поддержки после запуска, как закрываются интеграции «не из коробки», и что будет, если через полгода понадобится второй склад или новый тип оплаты.

Ответы без конкретики («сделаем как надо») для меня красный флаг. Нормальный исполнитель называет риски и диапазоны хотя бы порядка величины.

Если очень коротко: не экономьте на фундаменте там, где сайт — канал продаж. Экономия почти всегда вернётся чеком на миграцию.

Подробнее разобрал платформы и критерии в материале на сайте: как выбрать CMS для интернет-магазина — сравнение подходов.

Однако недавно проект получил второе дыхание. Разработчик Александр Тишов (Amro) — создатель CMS Seditio и основатель веб-студии «Авего» — выпустил Denwer SE (Second Edition). Это не просто обновление, а полный реинжиниринг с сохранением классической философии: портативность, скорость работы и привычная структура каталогов.

В этой статье разберём, что изменилось под капотом, почему панель управления переехала с Perl на Python, как работает автоматический HTTPS с собственным корневым сертификатом и зачем нужен зоопарк версий PHP от 5.6 до 8.5.

Краткий экскурс: от Denwer 3 до Denwer SE

Оригинальный Denwer (сокращение от Джентельменский Набор Веб-разработчика) появился в начале 2000-х. Он представлял собой связку Apache + PHP + MySQL, упакованную в самораспаковывающийся архив. Главные фишки:

• Виртуальный диск (по умолчанию Z:), который монтировался через subst.
• Автоматическое создание виртуальных хостов по именам папок в home.
• Консольные exe-файлы (Run, Stop, Restart) без графического окна.

Проблемы оригинала:

• Управление на Perl — медленно, тяжело поддерживать в Windows.
• Только 32-битные компоненты.
• Невозможно быстро переключать версии PHP или БД.
• Отсутствие нормального HTTPS (только самоподписанные сертификаты с ошибками в браузере).
• Поддержка прекратилась в 2016 году.

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

Архитектура: Python вместо Perl

Denwer SE — панель управления написана на Python и скомпилирована в один EXE-файл (через PyInstaller).

Внутри служебной папки denwer\ лежат:

• DLL-версия Python — интерпретатор, который использует основной исполняемый файл.
• Скомпилированные модули .pyd — в том числе GUI на базе Tcl/Tk для оконного интерфейса и системного трея.
• Минимальный набор библиотек для управления службами, правки hosts и генерации сертификатов.

Это даёт несколько преимуществ:

• Портативность — панель ищет соседние папки home и usr, поэтому каталог со стеком можно переносить куда угодно без переустановки.
• Скорость — Python-скрипты запускаются быстрее, чем Perl, особенно на холодном старте.
• Читаемость кода — разработчику проще поддерживать и расширять функционал.

Полный переход на x64

Оригинальный Denwer навсегда остался 32-битным, что в современных реалиях просто неприемлемо. Denwer SE собирается исключительно под x64:

• Apache (версия 2.4.x) — 64-битный.
• Все модули PHP (от 5.6 до 8.5) — Thread Safe x64.
• MySQL / MariaDB — 64-битные сборки.

Системные требования — Windows 7/8/10/11 (x64). Для работы компонентов потребуются Microsoft Visual C++ Redistributable (VC11, VC12, VC14, VC15). Разработчик положил установщики этих пакетов в папку vcredist\ — при необходимости можно доустановить вручную.

Структура каталогов: преемственность и гибкость

Denwer SE сохранил классическую структуру, чтобы старые пользователи не ломали голову:

Главный конфиг — usr\configuration.txt. В нём задаются пути без жёсткой привязки к букве диска, например:

При старте панель монтирует виртуальный диск (по умолчанию Z:) и динамически подставляет путь через переменную subst_drive.

Управление версиями PHP и БД без танцев с бубном

В Denwer SE встроен менеджер версий. Вы просто выбираете из выпадающего списка нужную версию PHP (например, 8.3 или 5.6) — панель сама правит конфигурацию Apache.

Как это работает под капотом:

В папке usr/local/apache/php лежат подкаталоги php5.6, php7.4, php8.3 и т.д..

В каждом из них есть файл php-denwer.conf— шаблон для подключения модуля к Apache. При выборе версии этот файл копируется в conf/extra/httpd-denwer.conf, который затем включается в основной httpd.conf.

Если вы хотите добавить свою сборку PHP (например, PHP 8.4-rc), достаточно:

• Распаковать x64 Thread Safe версию в отдельный каталог внутри php\.
• Создать php-denwer.conf по образцу.
• Убедиться, что все DLL от VC++ установлены.

Аналогично для баз данных: переключение между MySQL 5.7 и MariaDB 11.8 происходит через тот же интерфейс. В каталоге СУБД может лежать файл db-denwer.conf, который при старте копируется в my.ini.

HTTPS, который не бесит: локальный Root CA

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

Denwer SE решает проблему элегантно — он создаёт собственный корневой центр сертификации (CA) и подписывает им сертификаты для всех ваших локальных доменов.

Как это работает:

1. При первом запуске (если найден OpenSSL) панель генерирует ключи denwer-ca.key и сертификат denwer-ca.crt в папку usr/local/apache/conf/cert/denwer-ca/.
2. Для каждого виртуального хоста (папки в home/) автоматически создаётся сертификат в conf/cert/<domain>/.
3. Все сертификаты хостов подписаны локальным CA.

Чтобы браузер доверял им, нужно один раз установить denwer-ca.crt в хранилище «Доверенные корневые центры сертификации» Windows. Для этого в панели есть специальная кнопка (требует прав администратора).

После этого любые HTTPS-запросы к локальным хостам работают без единого предупреждения.

Удобства для разработчика (DX)

В версии 1.2.4 добавили несколько фич, которые экономят время каждый день:

• Лог с таймштампами — каждая строка в окне панели имеет префикс [чч:мм:сс]. Теперь видно, сколько секунд сервер поднимается и где возможны задержки.
• Прямой доступ к php.ini и my.cnf — рядом со списками версий появились кнопки, открывающие конфигурацию именно активной версии.
• Автоматическое ведение hosts — панель в реальном времени сканирует home/, находит новые домены и прописывает их в C:\Windows\System32\drivers\etc\hosts. Журнал добавляемых записей сохраняется в usr\AddedHosts.txt. При остановке стека лишние строки удаляются.
• Для смены версии PHP или базы данных панель требует полной остановки всех служб. Вы нажимаете «Стоп», меняете версию в списке, затем «Старт» — и стек поднимается уже с новыми настройками. Автоматический перезапуск без вашего участия работает только для Apache: когда вы добавляете новый домен в папку home/, панель сама переписывает vhosts.conf и перезапускает веб-сервер, не трогая БД.

Почему не Open Server или Docker?

Этот вопрос закономерно возникает у всех, кто видит очередной локальный веб-сервер. Ведь есть уже давно Open Server Panel, Laragon, XAMPP, а для продвинутых — Docker. Зачем ещё один?

Open Server — мощный и удобный комбайн с десятками версий PHP и настройками «на века». Но он разворачивается в системе не портативно: создаёт папки в ProgramData, пишет в реестр, а запуск может занимать 5–10 секунд. Denwer SE, напротив, полностью переносим: скопировал папку на флешку или в облачный каталог — и всё работает. Запуск стека — буквально 1–2 секунды, что критично, когда вы десятки раз за день перезапускаете сервер для тестов.

Docker — индустриальный стандарт для изоляции и воспроизводимости окружений. Но для локальной разработки простого сайта он часто избыточен. Вам нужно разобраться в образах, контейнерах, пробросе портов, volume’ах и docker-compose.yml. А в Denwer SE вы просто создали папку в home/ — и готово. Никакой работы с командной строкой, никакого потребления гигабайт ОЗУ на фоновую службу Docker Desktop.

Laragon — быстрый, портативный, поддерживает не только PHP, но и Node.js, Python, Go. Но он ориентирован на современные фреймворки, особенно Laravel. Denwer SE же сделан для тех, кто вырос на классическом Денвере: виртуальный диск Z:, папка home/имя_домена/www, минимум настроек. Не нужно переучиваться — просто распаковал и работаешь как 10 лет назад, но с новыми версиями PHP и HTTPS.

Как начать пользоваться Denwer SE

1. Скачать архив с официального сайта автора.
2. Распаковать в любое место, например C:\web\DenwerSE\.
3. Запустить DenwerSE.exe — если нет прав администратора, попросит их для монтирования диска и правки hosts.
4. Нажать «Запустить» — появится виртуальный диск Z:, а в системном трее иконка.
5. Создать папку сайта — например, home\myproject.local и положить туда index.php.
6. Открыть в браузере http://myproject.local/ (или https://myproject.local/). HTTPS будет работать сразу после установки корневого сертификата (кнопка в панели).

По умолчанию пароль к MySQL/MariaDB — пустая строка (пользователь root). При желании его можно сменить через phpMyAdmin.

Заключение

Denwer SE — это не просто ностальгический проект. Это действительно современный инструмент, который доказывает, что концепция «локального сервера в одну папку» всё ещё актуальна. Отказ от Perl в пользу Python, менеджер версий PHP/БД, нормальный HTTPS, портативность и мгновенный запуск — всё это делает его отличным выбором для быстрого прототипирования, тестирования легаси-кода или обучения веб-разработке.

Если вы устали ждать, пока Open Server применит настройки, или не хотите разбираться в Docker Compose — попробуйте Denwer SE. Вероятно, он напомнит вам старые добрые времена, но уже без боли устаревших технологий.

• Автор проекта: Александр Тишов (Amro), разработчик CMS Seditio.
• Лицензия: Freeware.
• Совместимость: Windows 7/8/10/11 x64.

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

Я 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. Вопросы и критика приветствуются.

Мы остановились на открытом симуляторе InferSim от Alibaba. Он умеет считать TTFT, TPOT и пропускную способность без запуска реального инференса. Но из коробки поддерживает только несколько топовых GPU и фиксированный набор моделей — для наших сценариев этого было недостаточно. Пришлось дорабатывать.

Как устроен InferSim

В основе симулятора — двухфазная схема. Сначала на целевом железе запускаются микро-бенчмарки: измеряется реальная производительность на типовых операциях внимания и матричных умножениях. Получается таблица коэффициентов Model FLOPs Utilization (MFU) — сколько процентов от теоретического максимума выдаёт конкретная карта на конкретной операции. Затем, уже без доступа к GPU, симулятор на основе этих MFU и аналитической модели вычисляет задержки. Именно такой подход даёт более точные предсказания, чем оценка по паспортной пропускной способности памяти.

Добавляем своё железо

Первым делом мы внесли в hardware/gpu.py поддержку MetaX C500 64GB. Характеристики добавляются через dataclass-экземпляры:

После этого c500 попадает в словарь gpu_map, и симулятор запускается с ключом --device-type C500 --world-size 2. Значения FLOPS и пропускной способности пришлось оценивать по косвенным источникам — производитель не публикует точных цифр. Позже планируем уточнить их через бенчмаркинг на реальном оборудовании. Таким же способом добавили Nvidia 1xH100 и A100.

Конфигурация моделей и одна болезненная ошибка

Симулятор ожидает стандартный config.json в формате Hugging Face. Для Qwen3-32B подготовили файл qwen3_32b_config.json:

Ключевой момент — правильное значение head_dim. У Qwen3-32B оно равно hidden_size / num_attention_heads = 5120 / 64 = 80. У нас ушло некоторое время, чтобы понять, почему симулятор выдаёт невалидные результаты: изначально в конфиге стояло значение 128. Пока не исправили — KV-кеш переоценивался, и метрики улетали в неадекватные цифры. После исправления всё встало на свои места.

Позже добавили поддержку Qwen3.5‑9B с её гибридной архитектурой, построенной на чередовании Gated DeltaNet и Gated Attention. Главная особенность модели в том, что около трёх четвертей слоёв не создают привычного KV‑кеша, а используют линейное внимание – компактное скрытое состояние, которое лишь обновляется с каждым новым токеном, не увеличиваясь в объёме. Это кардинально снижает расход памяти на длинных контекстах, но привносит и свою цену: на коротких дистанциях такая модель проигрывает в скорости Prefill, потому что Gated DeltaNet работает последовательно и хуже утилизирует матричные вычисления GPU.

Симулятор изначально не умел различать слои двух типов и считал весь KV‑кеш одинаково. Чтобы поддержать Qwen3.5, пришлось доработать расчёт задержек в классе HybridModel: теперь он отдельно обсчитывает full‑attention‑слои с полным кешем и linear‑attention‑слои без кеша, используя параметры num_full_attn_layers и num_linear_attn_layers из конфигурации. В директорию проекта models добавили hybrid_model.py, в котором сделали дополнительные расчёты:

Без такой дифференциации симулятор для Qwen3.5‑9B показывал E2E порядка 2 500 секунд вместо реальных нескольких секунд – та ошибка, которую мы долго отлавливали.

Визуализация и эксплуатация

Чтобы не разбирать каждый раз текстовый вывод InferSim, сделали веб-интерфейс на Streamlit. Симулятор дёргается через subprocess, результаты парсятся из stdout и визуализируются:

• тепловые карты задержек (Prefill, Decode, E2E Total) для разных длин входных и выходных токенов;
• анализ RPS с расчётом требуемой параллельности и сравнением с доступной памятью;
• информация о занятой памяти в формате «X ГБ из Y ГБ».

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

Приложение упаковано в Docker и лежит в репозитории на GitHub. Сервисы — сам Streamlit и Nginx в качестве обратного прокси с SSL-терминацией и базовой HTTP-аутентификацией. Деплой на VDS автоматизирован через GitHub Actions: собрали образ, отправили на сервер, перезапустили контейнеры. SSL-сертификаты Let's Encrypt обновляются по cron.

Что в итоге

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

Репозиторий проекта открыт, будем рады замечаниям и предложениям от тех, кто решает схожие задачи.

Около семи вечера начали падать транзакции. Не все - примерно 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. Если у вас уже есть страница статусов - напишите в комментариях какой инструмент используете. Интересно что прижилось у разных команд.

Мне стало интересно: а можно ли на бесплатных мощностях, буквально "на коленке", собрать русскоязычного ИИ-рентгенолога? Спойлер: можно. В этой статье расскажу, как я скрестил Vision Transformer от Google с ruGPT-3 от Сбера, как боролся с датасетами на Kaggle и что из этого вышло. В конце — ссылки на GitHub и рабочее демо.

Архитектура: как пришить глаза к мозгу

Чтобы нейросеть могла посмотреть на снимок и написать текст, нужна архитектура Vision-Language Model. Обучать такого монстра с нуля у меня не было ни ресурсов, ни желания. Поэтому я пошел по пути Hugging Face VisionEncoderDecoderModel.

Идея проста как кирпич:

1. Энкодер (Глаза): Берем предобученный google/vit-base-patch16-224-in21k. Он отлично дробит картинку на патчи и извлекает визуальные фичи (понимает, где ребра, а где легкие).
2. Декодер (Язык): Берем ai-forever/rugpt3small_based_on_gpt2. У нее нет глаз, она умеет только генерировать текст.

Чтобы их сшить, пришлось немного "взломать" конфиг ruGPT-3, принудительно сказав ей: «Теперь ты декодер, и у тебя есть слои кросс-внимания» (is_decoder=True, add_cross_attention=True). Hugging Face заботливо создал новые пустые веса между двумя моделями. Именно эти связи мне и предстояло обучить.

Data Engineering: боль, страдания и Kaggle

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

Поэтому я взял открытый американский датасет Indiana University Chest X-Ray (IU X-Ray). Там есть картинки и тексты от американских врачей.

Прямо на Kaggle я поднял пайплайн машинного перевода на базе Helsinki-NLP/opus-mt-en-ru. Закинул тексты в GPU батчами по 32 штуки и за 10 минут перевел более 7000 медицинских заключений на вполне сносный русский медицинский язык.

Но тут платформа подкинула сюрприз: Kaggle прячет часть файлов в виртуальной файловой системе (снимков 7000, а стандартный скрипт видел только 4). Пришлось писать суровый маппинг с глубоким сканированием (os.walk), отрезать расширения и жестко связывать ID в CSV с реальными путями на диске.

Обучение: выжимаем все соки из бесплатных T4

Обучение проходило на Kaggle (2x NVIDIA T4). Чтобы модель не умерла от нехватки памяти (OOM), а сессия не отвалилась по тайм-ауту, пришлось шаманить:

• Включил Mixed Precision (fp16) — ускорило обучение в 2 раза.
• Настроил Gradient Accumulation — размер батча на видеокарту был всего 4, но виртуально мы накапливали до 16.
• Столкнулся с тем, что Seq2SeqTrainer крашится при попытке сохранить промежуточный чекпоинт мультимодального "франкенштейна". Решение? Выключить промежуточные сохранения (save_strategy="epoch") и молиться, чтобы Kaggle не завис. (Кстати, спасает JS-скрипт в консоли браузера, делающий клик раз в 60 секунд).

На 15 эпох ушло около 2.5 часов.

Что получилось в итоге? (Потрогать руками)

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

Я завернул модель в Gradio и выложил на Hugging Face Spaces. Можно зайти с телефона или ПК, загрузить любой снимок рентгена из гугла и посмотреть, что она выдаст.

👉 Потыкать лайв-демо тут: Hugging Face Space

👉 Весь код, пайплайны и веса тут: GitHub Репозиторий

Буду рад, если кому-то этот код сэкономит время при создании своих мультимодальных сеток. Залетайте в репу, ставьте звездочки, форкайте. Если есть идеи, как улучшить датасет (может, прогнать переводы через LLM для чистки медицинского сленга) — пишите в комменты!

(Дисклеймер: модель обучена в исследовательских целях за вечер. Не суйте ей свои снимки вместо похода к реальному врачу)

Откуда берётся хейт

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

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

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

Что происходит на стороне нанимателя

Чаще всего рассинхрон возникает из-за недосказанности — привычки работать в своём контуре.

Несоответствие опыту

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

Похожая история с зарплатами

Команда работает пять лет, индексации были минимальные. Менеджер ищет сеньора с семилетним опытом на 200 тысяч — потому что столько получает его текущий отдел. На рынке такие специалисты стоят 300–500 тысяч. Менеджер не верит аналитике и предлагает поискать через агентство.

Непонятные критерии

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

По опыту рекрутеров, такое происходит примерно в каждом пятом найме. У некоторых заказчиков — в каждом первом.

Почему рекрутер стал детективом

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

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

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

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

Где косячит сам рекрутер

Рекрутеры тоже ошибаются, и чаще всего по банальным причинам.

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

Иногда рекрутер слишком верит в кандидата и в скрининге сглаживает острые углы — человек что-то сделал не так, но очень понравился, и в отчёте это замалчивается. Заказчик тратит время, а претензия всё равно прилетает рекрутменту.

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

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

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

Банковская оценка стоимости найма одного сотрудника — 500–900 тысяч рублей, для проблемного найма это не отражает реальности.

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

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

Как это чинится

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

Для внутренних HR важнее всего выстроить доверие: заказчик не должен воспринимать рекрутера как внутреннего контролёра. Когда доверие есть, заказчик приходит и говорит открыто, что ему нужно — пусть даже это звучит странно. Это всегда лучше, чем молчаливые отказы и угадывание критериев.

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

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

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

Centicore Group специализируется на подборе IT-специалистов для продуктовых и аутсорс-команд. Компания работает с позициями любого уровня сложности — от джунов до архитекторов и CTO.

• Продукт года
• Облачный продукт года
• ИТ-ивент года
• Дизайн года

Кто принимал участие в премии

В событии приняли участие 12 компаний, в том числе крупные игроки рынка: ОТП Банк, Ростелеком, Selectel, Островок. А также NetVision, AkademiaDev, 3Logic Group, Лаборатория Числитель, Рунити, SmartApe, Сократик, Reksoft.

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

Победители премии

В номинации «Продукт года» золотая мышь досталась компании NetVision за платформу интеллектуального мониторинга СИМ.

В номинации «Облачный продукт года» победила компания Гравитон с паком виртуализации «Гелиус.

Звание «IT-ивент года» вручили компании Островок! за О!Хакатон.

И в категории «Дизайн года» первое место заняла компания AkademiaDev за интерактивную инсталляцию.

Почему штат стал дорогим

Реальная стоимость штатного разработчика — это зарплата, увеличенная в 2–3 раза. Зависит от компании и включает в себя налоги, страховые взносы, ДМС, HR, офис и административную нагрузку. Backend-разработчик с зарплатой 220 000 ₽ обходится компании примерно в 565 000 ₽ в месяц. Заморозка проекта на два месяца — это 1,1 млн рублей на «пустых» зарплатах, ошибка найма — ещё 3–6 зарплатных циклов на повторный поиск.

В последние пару лет выросла фискальная нагрузка: часть льготных тарифов страховых взносов для МСБ отменяется, ставка поднимается с 15% до 30% в части зарплат выше МРОТ. Каждый следующий разработчик в штате дорожает по регуляторным причинам.

Отдельный вопрос — скорость. Закрытие вакансии middle-разработчика занимает в среднем 58 дней, senior — 73 дня (с учетом отработки на предыдущем месте). При этом каждый третий кандидат отказывается от оффера на этапе согласования: нашел предложение лучше, не сошлись по зарплате или формату работы. Через внешнего партнёра готовый специалист появляется за 24–72 часа, и если не подошёл, заменить его можно без процедур трудового кодекса.

Какие модели пришли на замену

Специалист в аренду. Компания привлекает конкретного разработчика через партнёра. Формально он в штате партнёра, фактически работает под управлением заказчика. Скорость старта — 24–72 часа. Оптимально, когда нужно быстро закрыть нишевую специализацию: 1С, iOS, DevOps. Минус — нет командной синергии, вовлечённость ниже штатной.

Выделенная команда. Партнёр формирует полноценную команду под проект, на нём административная нагрузка, команда работает как штатная. В среднем такое сотрудничество длится около полутора лет. Пример: e-commerce перед праздниками добавил команду на четыре месяца — мобилки, backend, QA, тимлид, — а после сезона сократил до поддержки.

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

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

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

Как строить карьеру с учётом этих моделей

Советы, которые помогут адаптироваться вне зависимости от выбора карьерного пути

Считайте бизнес-ценность, а не технологии. Не «Я знаю React», а «Я сократил время загрузки страниц, что дало +3% конверсии». В штате и в выделенной команде одинаково ценят тех, кто влияет на метрики.

Разберитесь в экономике моделей. Если вы middle или senior — вы можете работать в штате, в выделенной команде, через технологический консалтинг или в гибридной схеме. У каждого формата своя экономика: разная ставка, разные условия, разные переговорные позиции. Изучите партнёров тех компаний, в которые вы хотели бы попасть.

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

Осваивайте то, что пересекается с вашим стеком. Рынок смещается к гибридным ролям: backend-разработчик с пониманием DevOps, аналитик с навыком автоматизации. Чистая специализация уступает пересечению компетенций.

Чего ждать

Объём штатного найма продолжит уменьшаться, этот год принесёт новые реструктуризации и сокращения в IT-отделах. Одновременно провайдеры выделенных команд и специалистов ожидают роста доходов на 19–24% в ближайшие три года.

Есть мнение, что ИИ ускоряет этот сдвиг, и нейросети позволяют на 30–50% сократить бюджет на типовых IT-позициях. Тот же объём задач закрывается меньшим количеством людей более высокого грейда. Спрос смещается туда, где автоматизация пока буксует: архитекторы, DevOps, ML-инженеры, специалисты по безопасности.

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

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

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

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

За пять недель участникам в формате мини-групп предстоит:

• Разработать бизнес-модель.
• Провести фокусировку на рынке и целевой аудитории.
• Сформулировать стратегию роста.

Подробную программу онлайн-школы можно узнать на сайте.

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

Детали программы

• Сроки обучения: 27 февраля — 27 марта 2026 года.
• Формат: Онлайн.
• Дедлайн подачи заявок: 27 февраля 2026 года (включительно). Количество мест ограничено.
  

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

Кому ИИ ближе всего по задачам

Исследование основано на анализе более 200 000 реальных сессий использования Copilot. Также эксперты сопоставили то, с чем ИИ справляется лучше всего, и задачи конкретных профессий.

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

Туда же попали менеджеры по продажам и сотрудники поддержки клиентов. В США это около 5 млн рабочих мест. Более того — именно здесь компании уже активно экспериментируют с автоматизацией, чат-ботами и ИИ-ассистентами.

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

Высшее образование больше не защита

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

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

Кого ИИ почти не трогает

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

Это не значит, что автоматизация их не коснется вообще, но именно LLM здесь пока бесполезны.

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

BRAIN ERM — это интеграционная платформа, которую в Рексофт создали и интегрировали как центральный хаб для работы с данными, людьми и связанными процессами. Платформа позволила автоматизировать и объединить процессы HR, проектного управления и финансы в одной экосистеме. Технологические возможности платформы также дают компании возможность собирать из модулей свой набор инструментов.

Команда из 12 человек создает и развивает продукт, который помогает компаниям экономить до 70% времени на рутинных HR-операциях и снижать текучесть кадров на 10-15%.

Задача: автоматизировать и объединить все инструменты в одной экосистеме

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

1. Нет оперативной информации о сотрудниках. Руководитель хочет понять, кто из команды доступен, перегружен, а у кого есть свободные ресурсы для нового проекта.
2. Работа в нескольких разных системах. HR-специалисты, рекрутеры, руководители хотят увидеть информацию о сотруднике. Основные данные — в одной системе, его цели и результаты оценки — в другой, учет отпусков и больничных — в третьей, обучение — в четвертой.
3. Потеря контакта с людьми. Удаленная работа сделала коммуникации формальными. Руководитель не видит, что человек выгорел или недоволен условиями.
4. Системы не поддерживают корпоративную культуру. Компания хочет минимум бюрократии, чтобы поддерживать инициативность и креативность.
5. Высокие операционные затраты. Весь цикл работы с персоналом стоит дорого: найм, адаптация новых сотрудников, организация рабочих процессов, оценка эффективности, обучение и развитие, увольнение.
6. Нет системного подхода к работе с талантами. Компания теряет ценных специалистов просто потому, что не успевает заметить проблему и предложить решение. Уходят люди с экспертизой, уходят лидеры, которые могли бы вырасти до ключевых позиций.

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

Дать возможность другим компаниям собрать уникальную экосистему под свои процессы, используя готовые сервисы и разрабатывая собственные модули. Работать с данными от 500 до 100 000+ сотрудников, поддерживать до 250 интеграционных потоков и быстро масштабироваться.

Параметры проекта

Команда: 12 человек (архитектор, аналитик, дизайнер, разработчики, тестировщики, DevOps, менеджер)

Средний уровень: L4

Time to Market: 3 месяца для нового модуля; 3 дня на новую функциональность;

Масштаб: от 500 до 100 000+ сотрудников

Интеграции: до 250 потоков данных

Статус: активно развивается, roadmap расписан на 3 года вперед

Технологический стек: Java, .NET, React, Camunda, Spring Boot, микрофронты, BFF, Kafka, ReBAC

Инфраструктура: разворачивается на любой платформе — от Bare metal до Kubernetes в on-prem или облаке

Архитектура: собери свою конфигурацию из готовых блоков

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

Как это работает:

Brain Core — ядро платформы (обязательный компонент)

→ Базовые функции, которые нужны всем модулям

→ Связь с программами, которые уже есть в компании (через API — интерфейсы для обмена данными, или Kafka — систему передачи сообщений)

→ Управление доступом — кто что может видеть и редактировать

→ Интеграция с бухгалтерией (1С, Navision, SAP), инструментами для разработчиков (GIT, Jira, Confluence), CRM, хранилищами данных

→ Дополнительные модули по выбору: управление персоналом, финансы, аудит, проекты

Архитектура построена на микросервисах — каждый сервис делает свою задачу независимо от других. Динамическая модель данных позволяет менять структуру информации под конкретные сценарии использования. Использование микрофронтов дает возможность настраивать интерфейс отдельно для разных ролей и задач.

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

BRAIN ERM — интеграционная платформа с ядром и набором подключаемых сервисов.

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

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

К Core подключаются модули:

• Brain HRM — блок управления персоналом. Внутри него, например, Brain Цели (постановка целей сотрудниками) и Brain Команды (создание кастомных команд под задачи и проекты).
• Brain Finance — управление бюджетами и финансовыми процессами.
• Brain Audit — контроль и аудит действий в системе.
• Brain Проекты — работа с проектами и загрузкой.
• Brain СУРВ — система управления рабочим временем.

Brain импортонезависим: поддерживает обмен данными с продуктами российских и зарубежных вендоров, а также с системами заказной разработки. Его можно развернуть на любой инфраструктуре — от Bare metal до Kubernetes, в своём контуре или в облаке.

Платформа рассчитана на компании от 500 до 100 000 сотрудников, поддерживает до 250 интеграционных потоков и масштабируется под новые задачи. При этом соблюдаются требования 152-ФЗ о персональных данных: хранение, обработка и защита ПДн построены с учетом закона.

Что может платформа: 7 главных фич

1. Модульная архитектура под задачи компании

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

2. ReBAC — управление доступом на основе отношений

Relationship-Based Access Control управляет доступом на основе отношений между сущностями. Руководитель проекта видит данные своей команды, HR-специалист — всех сотрудников своего подразделения, директор — агрегированную статистику по компании.

3. Интеграция с корпоративным стеком

Поддержка обмена данными на основе API и Kafka. Интеграция с ERP (1С, Navision, SAP), инструментами разработки (GIT, Atlassian Jira/Confluence), CRM, DataHub, Keycloak. Подключение к внутренним сервисам: порталу, где сотрудники отмечают достижения коллег бейджами, магазину с брендированными сувенирами и аксессуарами компании, тренинг-порталу для самостоятельного обучения.

4. Автоматизация на базе LLM

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

5. Импортонезависимость и гибкость развертывания

Рексофт BRAIN — импортонезависимая платформа, поддерживает обмен данными с различными продуктами российских и западных вендоров и системами заказной разработки. Разворачивается на любой инфраструктуре: от Bare metal до Kubernetes-платформ в on-prem среде или любом облаке.

6. Микрофронты и виджеты для настройки интерфейса

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

7. Масштабирование от 500 до 100 000 сотрудников

Рексофт BRAIN обрабатывает данные в компаниях от 500 до 100 000 сотрудников, поддерживает до 250 интеграционных потоков данных и быстро масштабируется под новые задачи.

Какие были стопперы: реальность сложнее, чем казалось

🔴 Проблема: объем работы оказался больше в несколько раз

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

✅ Решение: итеративная доработка и пересмотр подходов

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

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

Эффект для бизнеса в цифрах

По результатам внедрений компании получают:

• 7% роста вовлеченности сотрудников;
• сокращение времени адаптации на 10%;
• снижение текучести кадров на 10–15%;
• 20–70% экономии рабочего времени на рутинные операции;
• рост общей производительности труда на 5–20%.

Чем BRAIN отличается на рынке

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

Планы на три года

У команды есть дорожная карта на три года вперед. В фокусе три направления:

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

Модульная структура и поэтапное развертывание позволяют строить свою экосистему для HR и одновременно экономить на сроках и стоимости проекта: часть функциональности уже реализована и переиспользуется.

Реклама. ООО «РЕКСОФТ», ИНН 7802020639, erid: 2W5zFH2tZ37

В конце 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 и китайских номеров. Платформа объединяет лучшие ИИ-инструменты в одном месте — кроме создания видео, здесь доступны нейросети для учёбы, генерации изображений, решения задач.

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

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

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

По данным китайских СМИ, Гао потерял сознание дома в субботу, 29 ноября. Он работал допоздна и пожаловался, что плохо себя чувствует. Но несмотря на это, все равно собирался «немного посидеть и доделать срочные задачи».

Вскоре он упал без сознания, после чего его доставили в больницу. Однако спасти его не удалось. Смерть зафиксировали около часа дня.

Повышение, переработки и выходные без выходных

Незадолго до трагедии Гао получил повышение и стал руководителем отдела. Вместе с этим выросла и нагрузка — помимо программирования, он отвечал за управление командой и клиентскую поддержку.

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

Сообщения в чате — до и после смерти

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

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

Компенсация и конфликт с работодателем

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

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

Зачем детям 3D-моделирование в Blender или Tinkercad

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

Но зачем это нужно? Помимо очевидного «это интересно», 3D-моделирование — это мощный инструмент для развития мышления и творческих способностей:

Пространственное мышление: видеть мир в объеме

Креативность: от идеи к осязаемому результату

Цифровые навыки: владение языком будущего

Умение работать в 3D-среде — это уже не просто дополнительный кружок, а базовая грамотность нового времени. Ребенок осваивает логику цифровых инструментов, понимает принципы построения виртуальных объектов, учится технической терпеливости и точности. Эти компетенции становятся все более востребованными в самых разных областях.

Tinkercad для детей — цифровой конструктор для первых открытий

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

Например, чтобы создать модель домика, нужно взять куб (это основа), поставить на него треугольную призму (крыша), а затем с помощью инструмента «Отверстие» вырезать в кубе дверь и окна, используя другие кубы и цилиндры. Этот принцип «вычитания» одного объема из другого или их «сложения» — ключевой для понимания логики 3D.

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

Главные преимущества:

• Нулевой порог входа. Не нужно ничего скачивать и устанавливать. Достаточно компьютера с выходом в интернет и современным браузером.
• Бесплатность. Полный функционал платформы от компании Autodesk доступен свободно после простой регистрации.
• Мгновенная отдача. Уже на первом занятии ребенок создает свой первый объект и испытывает восторг от того, что эту модель можно сделать настоящей, отправив ее на 3D-печать.
• Идеальная база для понимания 3D-логики. Платформа блестяще учит основам: что такое оси координат (X, Y, Z), как работает объем, что такое группировка объектов. Это азбука, без которой сложно двигаться дальше.

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

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

Если ребенок с удовольствием собирает модели в Tinkercad, его интерес можно развить и углубить. В этом поможет наш курс по 3D-моделированию для детей в Tinkercad, где эта программа становится полноценным инструментом для реализации серьезных проектов. Под руководством нашего педагога дети не просто комбинируют кубики, а учатся профессиональному подходу: от эскиза и технического расчета пропорций до подготовки сложной модели для печати. К концу курса каждый ученик создаст собственное портфолио из готовых работ — например, многосоставную головоломку, действующий механический механизм (вроде шарнирного робота) или детализированный архитектурный макет.

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

Blender для детей — цифровая студия для будущих профессионалов

Если Tinkercad можно сравнить с удобным конструктором, то Blender — это целая мастерская скульптора, инженера и режиссера под одной крышей. Это не просто программа для 3D-моделирования, доступная детям, это — полноценная профессиональная студия для создания трехмерной графики, которая при этом остается абсолютно бесплатной. Здесь нет готовых кубиков — здесь есть цифровая глина, из которой можно вылепить что угодно, от ювелирного украшения до целой анимированной сцены из фэнтези-мира.

Blender — это универсальный комплекс, охватывающий все этапы производства 3D-контента. Его ядро — продвинутое полигональное моделирование, где объекты создаются из сетки-«каркаса» (полигонов), вершины которого можно двигать, формируя любые, даже самые плавные и сложные формы. Для создания органических объектов (персонажей, существ) есть инструмент скульптинга, имитирующий работу с настоящей глиной: можно «вдавливать», «вытягивать» и «сглаживать» поверхность.

Но на этом возможности не заканчиваются. В Blender можно:

• Текстурировать и назначать материалы (сделать объект блестящим, матовым, прозрачным).
• Выстраивать освещение и визуализировать (создавать фотореалистичные или стилизованные «снимки» — рендеры).
• Анимировать объекты и персонажей, заставляя их двигаться.
• Монтировать видео, добавлять спецэффекты и даже работать со звуком.

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

Главные преимущества:

• Безграничные творческие возможности. Ограничением в Blender является только фантазия ребенка. Хочет создать робота с идеально ровными гранями? Пожалуйста. Мечтает вылепить фантастического дракона? И это возможно.
• Промышленный стандарт в индустрии. Навыки работы в Blender для ребенка — это серьезная строка в будущем портфолио. Программа активно используется независимыми студиями в геймдеве, анимации, рекламе и дизайне.
• Развитие комплексного, глубокого мышления. Работа над проектом учит видеть процесс от начала до конца: концепт → моделирование → текстурирование → постановка света → финальный рендер. Это воспитывает терпение, внимание к деталям и системный подход.

Также важно учитывать требования к уровню подготовки ребенка и технике:

• Высокий порог входа. Чтобы начать создавать что-то осмысленное, потребуется пройти этап изучения интерфейса и базовых инструментов. Это требует усидчивости и готовности к тому, что не все будет получаться сразу.
• Требования к компьютеру. Для комфортной работы, особенно при рендеринге сложных сцен, потребуется достаточно производительный ПК или ноутбук с хорошей видеокартой.
• Необходимость в структурированном обучении. Самостоятельное освоение Blender «методом тыка» часто приводит к разочарованию. Намного эффективнее двигаться по выверенной учебной программе с поддержкой преподавателя.

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

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

Записаться на бесплатный пробный урок курса «3D-моделирование в Blender для детей» можно здесь.

Перспективы изучения программ для 3D-моделирования для детей

Увлечение детей 3D-моделированием, которое начинается с простой фигурки в Tinkercad или первого персонажа в Blender, — это не просто хобби. Это ранний старт в освоении навыка, который сегодня лежит в основе десятков высокооплачиваемых профессий. Цифровое трехмерное пространство стало новой реальностью для творчества, инженерии и науки, и умение работать в нем сравнимо с владением популярным языком программирования.

Давайте рассмотрим конкретные направления, где сегодня востребованы навыки 3D-моделирования, и какие задачи решают специалисты в каждой из них.

Геймдев и анимация

Это одна из самых очевидных и желанных для детей подростков сфер. Здесь 3D-художники — настоящие творцы реальностей.

• Что делают: создают 3D-персонажей (от концепта до детализированной модели с текстурами и скелетом для анимации), окружение (города, леса, интерьеры космических кораблей), пропсы (оружие, транспорт, предметы быта) и визуальные эффекты (магические заклинания, взрывы).
• Пример задачи: получив концепт-арт фэнтезийного воина, художник по персонажам должен создать его 3D-модель, которая будет одинаково убедительно выглядеть с любого ракурса в игре, а аниматор — «оживить» его, запрограммировав движения бега, атаки и реакции.
• Главный инструмент — Blender.

Промышленный и предметный дизайн

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

• Что делают специалисты в этой области: разрабатывают внешний вид, эргономику и функциональность изделий. Создают цифровые прототипы, которые можно проверить на виртуальные нагрузки, собрать виртуально и только потом отправить в производство.
• Пример задачи: дизайнер получает техническое задание на разработку беспроводной колонки. В 3D-редакторе он создает ее форму, прорабатывает расположение кнопок и динамиков, подбирает материалы (пластик, ткань, металл) и создает фотореалистичные изображения для презентации клиенту.
• Какие инструменты используют: Tinkercad отлично подходит для первых шагов, обучения основам и создания простых концептов. Blender и другие профессиональные CAD-программы (Fusion 360, SolidWorks) используются для сложных инженерных задач.

Архитектура и визуализация

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

• Что делают: создают архитектурные макеты и интерьеры в 3D, проводят виртуальные туры, визуализируют, как будет выглядеть здание в разное время суток или в разные сезоны. Это позволяет «прогуляться» по дому еще до закладки фундамента.
• Пример задачи: визуализатор получает чертежи будущей квартиры. Его задача — смоделировать ее в 3D, «расставить» мебель, подобрать отделочные материалы, настроить реалистичное освещение от виртуальных окон и создать серию изображений, неотличимых от фотографий.
• Какие инструменты используют: Tinkercad может стать первым инструментом для создания простых макетов. Для профессиональной работы используется Blender (особенно для сложного и креативного дизайна), а также специализированный софт вроде 3ds Max, SketchUp или Archicad.

Инженерное дело и 3D-печать

3D-печать перевернула подход к созданию вещей, но она невозможна без 3D-моделей.

• 3D-инженеры проектируют детали сложных механизмов (от дронов до протезов), проверяя их на прочность в симуляциях. Специалисты по 3D-печати адаптируют и готовят модели к печати, следя за тем, чтобы виртуальный объект можно было корректно воплотить в пластике, металле или смоле.
• Пример задачи: инженер должен смоделировать нестандартную деталь для ремонтного комплекта вышедшего из производства станка. Модель должна быть геометрически точной и учитывать физические свойства выбранного для печати материала.
• Какие инструменты используют: Tinkercad — идеальная площадка для знакомства с логикой 3D-печати, создания первых простых, но функциональных моделей. Для сложных технических задач используются Blender (для органических форм) и профессиональные CAD-системы.

Медицина и наука

В этой сфере 3D-технологии носят не коммерческий, а исследовательский и прикладной характер.

• Ученые создают 3D-модели молекул и кристаллических решеток для наглядного изучения, реконструируют внешний вид археологических находок по останкам, готовят модели органов пациента на основе данных КТ для планирования сложной операции.
• Пример задачи: ученый, изучающий новое химическое соединение, строит его точную трехмерную модель, чтобы понять, как он взаимодействует с другими молекулами. Эта модель становится ключом к разработке лекарства.

Как выбрать программу для 3D-моделирования, подходящую для вашего ребенка

Чтобы выбрать между Tinkercad и Blender для ребенка, не нужно быть экспертом в 3D-графике. Достаточно ответить на три вопроса: сколько лет ребенку, какова его ближайшая цель и сколько времени он готов уделять обучению. Эти критерии станут вашим основным ориентиром.

Ориентируйтесь на возраст и способность к самостоятельному обучению

• Tinkercad оптимален для детей 6-12 лет. В этом возрасте важнее всего быстрое ощущение успеха и понятная, игровая механика творчества. Ребенок еще не готов к долгому изучению сложного интерфейса, но с удовольствием будет собирать модели как цифровой конструктор и сразу видеть результат своей работы, особенно если есть возможность ее напечатать.
• Blender — для детей от 12-13 лет и старше, особенно если у ребенка есть выраженный интерес к конкретным сферам — играм, анимации, визуальным эффектам. В этом возрасте уже хватает усидчивости для преодоления начального, самого сложного этапа освоения профессионального инструмента. Ключевой фактор здесь — наличие внутренней мотивации.

Четко определите первую практическую цель

• Если цель — делать свои игрушки и сувениры для 3D-принтера, то ребенку нужен Tinkercad. Эта платформа идеально заточена под быструю подготовку моделей к печати. Ее инструментов хватит для создания 90% бытовых и декоративных предметов.
• Если ребенок хочет создавать крутых персонажей для игр или собственных мультфильмов — путь ведет к Blender. Никакой другой бесплатный инструмент не даст такой свободы в создании органических форм, детализированных персонажей и их дальнейшей анимации. Важно понимать, что это полноценный профессиональный софт, и для эффективного старта крайне желательна помощь преподавателя или структурированный курс.

Не бойтесь начинать с простого — это лучшая основа для сложного

Самый гармоничный и психологически верный путь в 3D-моделировании — последовательный. Начните с Tinkercad, даже если ребенок видит себя в будущем в геймдеве. Это даст ему бесценные преимущества:

• Уверенность в своих силах благодаря мгновенным и осязаемым результатам.
• Понимание работы с объемом, масштабом и композицией в трехмерном пространстве.
• Дети без проблем переходят на Blender, когда возможности Tinkercad становятся тесны для новых идей. Такой переход будет осознанным: ребенок уже будет понимать, зачем ему нужны более сложные инструменты.

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

Реклама. Рекламодатель ООО «Пиксель.Стади», ИНН 5074078988, erid: 2W5zFGart4G

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

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

По разным оценкам, до 80–85% вакансий в IT так и не доходят до публичных площадок вроде LinkedIn или HeadHunter. Их закрывают внутренними переходами, через рефералки или по рекомендациям менеджеров.

Почему компании уходят от «холодного» найма

Главная причина — резкий рост количества резюме и падение доверия к ним. После массового распространения ИИ-инструментов, рекрутеры сталкиваются с потоком идеально оформленных, но плохо проверяемых профилей.

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

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

Цифры подтверждают сдвиг

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

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

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

Аналитики hh.ru подтверждают, что с начала 2025 года количество ИТ-вакансий в России сократилось на 22%. Одновременно с этим, по данным исследования HR‑платформы «Поток», уровень закрытия вакансий не превышает 55–60%. Работодатели стали заметно реже открывать новые позиции, сместив акцент на перераспределение задач внутри существующих команд.

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

Разберемся в реальном положении дел на ИТ-рынке труда. Узнаем, какие специалисты останутся востребованы в 2026 году, какие навыки будут цениться и как изменится процесс найма под влиянием искусственного интеллекта.

Что случилось в 2025: анатомия кризиса

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

Кого сокращали в первую очередь

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

• Продуктовые команды и разработчики пострадали больше всего. Под сокращение попали неэффективные сотрудники и целые команды, чьи проекты были закрыты из-за туманных перспектив или не показывали прибыль в текущих условиях.
• Специалисты начального уровня (джуны) оказались в зоне высокого риска. Для junior-вакансий рост предложений заметно замедлился из-за переизбытка кандидатов. Вакансий становится меньше в мобильной разработке, поддержке устаревших информационных систем и QA (контроль качества), чему способствует автоматизация.
• Влияние искусственного интеллекта. Во всех сферах экономики происходит поиск экономических выгод через ИИ. По данным компании Outlines Tech, ИИ позволяет на 30-50% сократить бюджет на типовых IT-позициях. Речь идет не о тотальных увольнениях, а о повышении эффективности: там, где раньше требовались три сотрудника, компания может обойтись одним-двумя, усиленными ИИ.

География сокращений

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

Структурный сдвиг привел к резкому усилению конкуренции. Например, в Петербурге hh-индекс (отношение количества резюме к количеству вакансий) в IT-сфере за год вырос с 7,9 до 13,0, что значительно выше среднего по рынку.

Дополнительные тренды

Опросы, проведенные среди российских компаний, дополняют эту картину:

• Фокус сместился на удержание и переобучение. Главными вызовами для работодателей в 2025 году стали удержание сотрудников (61%) и переобучение текущего штата (41%).
• Сохраняется дефицит узких специалистов. Несмотря на оптимизацию, компании по-прежнему испытывают острую нехватку специалистов по информационной безопасности (52%), бэкенд-разработчиков (49%) и DevOps-инженеров (42%).
• Изменение формата работы. Компании постепенно движутся к частичному или полному переводу ИТ-специалистов в офис. Если год назад эту тенденцию отмечали 51% опрошенных компаний, то в 2025 году их число увеличилось до 67%.

Как изменились зарплаты айтишников в 2025:

Налоговый фактор: почему оптимизация продолжится

С 1 января 2026 года вступают в силу новые правила, которые окажут прямое влияние на кадровую политику в ИТ. Страховые взносы повысятся с 7% до 15%, льготы по НДС на покупку отечественного ПО отменят.

Крупные аккредитованные ИТ-компании будут обязаны заключать соглашения с вузами о финансовой поддержке и помощи в подготовке кадров, чтобы сохранить налоговые льготы и бронь от военной службы для сотрудников. На поддержку образования компаниям предстоит направлять до 5% от средств, сэкономленных благодаря нулевой ставке НДС. Требование касается компаний с выручкой свыше 1 млрд рублей в год и численностью сотрудников не менее 100 человек.

Кого затронут изменения

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

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

Реакция крупных игроков

Корпорации уже активно готовятся к изменениям и оптимизируют штаты. Крупнейшие российские ИТ- и телеком-компании, включая МТС, «Вымпелком», «Ланита», еще в 2024 году сократили количество размещенных ИТ-вакансий на 15–18% по сравнению с предыдущим годом. В МТС эту меру объяснили сокращением инвестиций и отказом от развития неэффективных направлений, таких как «МТС Авто» и «МТС Умной дом».

Однако сотрудники из закрываемых направлений не были автоматически уволены. Их направили на более перспективные и стратегически важные для экосистемы проекты, такие как FinTech, Media и облачные сервисы (IT-вертикаль MTS Web Services). Подход демонстрирует осознанный сдвиг от модели постоянного найма со стороны к модели развития и сохранения внутренних талантов — это один из ключевых трендов в кадровой политике на 2025 год .

Востребованные специалисты 2026: кого будут искать

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

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

Специалисты по ИИ и машинному обучению

Эти специалисты остаются в топе, но требования к ним изменились. Теперь недостаточно знать TensorFlow или PyTorch. Ценятся разработчики, способные создавать специализированные модели под конкретные бизнес-задачи. Рынок насытился специалистами, которые умеют обучать модели на готовых дата-сетах, но испытывает дефицит в тех, кто может адаптировать ИИ под специфические нужды бизнеса.

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

Навыки, которые ищут работодатели:

• умение дообучать модели на специфических данных с учетом их ограничений и особенностей;
• опыт оптимизации ML-моделей для production-среды с учетом latency (времени отклика системы) и resource constraints (ограничений по вычислительным ресурсам, памяти и энергии);
• знание методов интерпретации решений ИИ для обеспечения прозрачности и доверия;
• глубокое понимание предметной области (медицина, финансы, логистика);
• навыки работы с дообучением больших языковых моделей под конкретные задачи;
• опыт развертывания моделей в изолированных средах для работы с конфиденциальными данными.

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

Глобальный контекст усугубляет ситуацию. Ожидается, что к 2026 году более 90% организаций по всему миру столкнутся с дефицитом квалифицированных ИТ-кадров. В сфере ИИ этот дисбаланс проявляется особенно остро: соотношение спроса и предложения составляет 3.2 к 1.

Инженеры кибербезопасности

Их зарплаты выросли на 17% за 2025 год. Изменения в законодательстве и ужесточение требований к защите данных создали устойчивый спрос. Особенно ценятся специалисты по облачной безопасности и защите IoT-устройств. Компании стали больше тратить на ИБ, поскольку кибератаки стали более изощренными, а регуляторные нормы усложнились.

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

Направления с максимальным ростом:

• безопасность облачных сред (AWS Security, Azure Security) с акцентом на multi-cloud стратегии;
• защита IoT-устройств в промышленности и умных городах;
• анализ киберугроз и реагирование на инциденты в реальном времени;
• безопасность цепочки поставок (software supply chain security);
• защита API и микросервисных архитектур;
• безопасность контейнерных сред и оркестраторов.

Специалисты по IT-комплаенсу (соблюдению нормативных требований) и аудиту информационной безопасности также стали востребованы.Ужесточение законодательства требует постоянного контроля соответствия требованиям 152-ФЗ и отраслевых стандартов.

DevOps-инженеры с навыками работы с распределенными системами

Тренд на edge-computing (периферийные вычисления) требует специалистов, способных настраивать локальные вычислительные узлы и интегрировать их с облаками. Это означает обработку данных ближе к месту их возникновения, а не в централизованных дата-центрах, что снижает задержки и повышает отказоустойчивость систем. Зарплаты мидлов в этом сегменте выросли на 7,1% за первый квартал 2025 года. Рынок остро нуждается в инженерах, которые могут работать с гетерогенными средами.

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

Ключевые компетенции:

• опыт работы с Kubernetes в распределенных средах, включая managed services (управляемые сервисы) и on-premise решения (локальное развертывание в дата-центре);
• знание инструментов мониторинга для edge-инфраструктуры с ограниченным каналом связи;
• понимание принципов работы 5G-сетей и их интеграции с вычислительной инфраструктурой;
• навыки автоматизации развертывания в гетерогенных средах;
• опыт управления инфраструктурой как кодом в условиях hybrid cloud;
• знание особенностей работы с ресурсо-ограниченными edge-устройствами.

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

Data-аналитики и инженеры данных

Компании научились собирать большие данные — теперь им нужны специалисты, которые могут извлекать из них практическую пользу. Спрос на ETL-разработчиков вырос на 18,2%, на дата-аналитиков — на 16,4%. Рынок испытывает дефицит специалистов, способных не только обрабатывать данные, но и формулировать на их основе бизнес-инсайты.

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

Что ценится на рынке:

• умение строить прогнозные модели для бизнеса с учетом экономической целесообразности;
• опыт работы с реальными данными, а не с учебными наборами;
• глубокое понимание бизнес-метрик и KPI конкретной отрасли;
• навыки визуализации сложных данных для разных стейкхолдеров;
• знание современных инструментов обработки потоковых данных;
• умение работать с разнородными источниками данных и решать проблемы их качества.

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

Специалисты по работе с legacy-системами

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

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

Востребованные направления:

• разработчики и администраторы 1С (зарплаты выросли на 4-10%) с опытом интеграции с современными системами;
• специалисты по мэйнфреймам и старым СУБД, способные обеспечить их взаимодействие с cloud-сервисами;
• инженеры, способные мигрировать legacy-системы на современные платформы с минимальным временем простоя;
• эксперты по интеграции старых и новых систем через API и микросервисы;
• архитекторы, способные проектировать гибридные системы с постепенным переносом функциональности;
• специалисты по реверс-инжинирингу бизнес-логики унаследованных систем.

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

ИИ не заменит программистов, но изменит требования к ним

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

Как изменилась работа разработчиков

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

Что должен уметь разработчик в 2026 году:

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

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

Трансформация тестирования

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

Современный QA-инженер должен уметь:

• программировать сложные тестовые сценарии с элементами предсказательного анализа;
• настраивать ИИ-инструменты для автоматического поиска паттернов ошибок;
• владеть методами тестирования AI-систем и валидации их решений;
• работать с метриками качества для самообучающихся систем;
• знать основы MLops для интеграции тестирования в циклы разработки ИИ.

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

Новая роль аналитиков

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

Ключевые изменения в профессии:

• аналитики создают системы предиктивной аналитики для предсказания трендов;
• работают с инструментами автоматического выявления аномалий в реальном времени;
• участвуют в обучении ИИ-моделей для бизнес-прогнозирования;
• визуализируют сложные прогнозы для разных стейкхолдеров;
• разрабатывают системы мониторинга точности прогнозов.

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

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

Неочевидные тренды найма 2026

Некоторые специализации показали взрывной рост, хотя и остаются нишевыми.

Неожиданно востребованные профессии

Гейм-дизайнеры — спрос вырос на 96% за год. Российские студии наращивают производство собственных игр после ухода международных гигантов.

BI-аналитики — плюс 62% к количеству вакансий. Компаниям нужны специалисты, способные визуализировать сложные данные для принятия бизнес-решений.

Специалисты по технической документации — рост на 45%. С усложнением продуктов потребность в качественной документации только увеличилась.

Возвращение «старых» технологий

Рынок неожиданно проявил интерес к специалистам, которых еще недавно считали «уходящими».

Системные администраторы с глубоким знанием Linux — их зарплаты выросли на 12% после нескольких лет стагнации. Облака оказались не универсальным решением, и многие компании вернули часть инфраструктуры на свои серверы.

Специалисты по низкоуровневому программированию — спрос на разработчиков C++ и Rust вырос на 18%. Интернет вещей и edge-устройства требуют эффективного кода.

Что делать тем, кто ищет работу в 2026

Рынок становится более селективным. Общие фразы в резюме вроде «знаю Python» не работают. Работодатели ищут доказательства конкретных навыков.

Стратегия поиска работы

Сосредоточьтесь на узкой специализации. Fullstack-разработчики все еще востребованы, но компании готовы платить больше экспертам в конкретной технологии. Например, Go-разработчики получили повышение зарплат на 10% в 2025 году.

Осваивайте смежные области. Бэкенд-разработчик с пониманием DevOps или фронтенд-специалист, разбирающийся в UX, имеют преимущество на рынке.

Участвуйте в реальных проектах. Кандидаты с завершенными пет-проектами или контрибуциями в open source получают в 3 раза больше приглашений на собеседования.

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

Подтверждайте навыки официально. Национальная система подтверждения ИТ-компетенций Минцифры постепенно становится стандартом отрасли. Сертификат на Госуслугах увеличивает шансы на успешное трудоустройство.

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

Где искать перспективные направления

Мониторьте вакансии в отраслях, которые активно цифровизируются:

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

Зарплатные ожидания 2026

Рост зарплат в ИТ продолжается, но его темпы действительно замедлились. По данным исследования «Хабр Карьеры», медианная зарплата в отрасли в первой половине 2025 года выросла в среднем на 2-3% по сравнению со вторым полугодием 2024 года, тогда как предыдущий скачок составлял 19%.

Прогнозы на 2026 год остаются сдержанно оптимистичными: карьерный центр Kata Academy ожидает увеличения окладов разработчиков и тестировщиков в диапазоне 10–15%, что указывает на общий тренд роста, но без аномальных скачков. Это замедление наблюдается как в Москве и Санкт-Петербурге, так и в регионах.

Профессии с максимальным ростом доходов

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

• Администраторы баз данных (DBA) и разработчики 1С. На фоне импортозамещения и миграций с зарубежных СУБД сохраняется высокий спрос на специалистов, способных работать с legacy-системами и российскими аналогами. Хотя точный процент роста для DBA в результатах поиска не указан, зарплаты программистов 1С за первое полугодие 2025 года показали один из самых заметных скачков — рост на 9%.
• Специалисты по работе с данными (Data Scientist, Data-аналитики). Острая нехватка опытных специалистов, способных извлекать инсайты из информации, поддерживает высокий уровень их доходов. Спрос на этих экспертов остается стабильно высоким, так как данные стали ключевым активом для принятия бизнес-решений. В первом полугодии 2025 года зарплаты аналитиков выросли на 3%.
• Специалисты по искусственному интеллекту и машинному обучению. Направление остается драйвером зарплатного роста. Спрос на инженеров по ИИ/МО стремительно растет, а их средняя зарплата в России достигает 150–300 тыс. руб. в месяц.

Направления со стабильным доходом

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

• DevOps-инженеры. Эти специалисты остаются одними из самых востребованных на рынке, особенно ценятся навыки работы с российскими решениями. Зарплаты в этой сфере продолжают увеличиваться, демонстрируя устойчивый тренд.
• Go-разработчики. Язык Go сохраняет популярность в создании высоконагруженных и облачных систем. Его разработчики стабильно входят в число наиболее высокооплачиваемых специалистов в России. По данным на январь 2025 года, средняя зарплата Go-разработчика достигла 315 000 рублей.
• Специалисты по кибербезопасности. Исследование SuperJob отмечает, что число открытых вакансий в области ИБ за 2024 год выросло на 50% на фоне сокращения количества резюме. В отрасли наблюдается острая нехватка кадров, особенно экспертов по анализу угроз, SOC-аналитиков и пентестеров. Зарплаты топ-специалистов, таких как директора отделов по кибербезопасности, могут достигать 1 млн рублей.

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

Итоги: рынок становится взрослее

ИТ-индустрия проходит болезненный, но необходимый этап взросления. Зарплаты новичков перестали расти двузначными темпами, зато выросла оплата труда высококвалифицированных специалистов.

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

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

Российский ИТ-рынок не умирает — он становится более зрелым и сегментированным. В новой реальности преуспеют те, кто готов постоянно учиться и адаптироваться.

За 8 лет в бигтехе он видел несколько волн изменений, но текущую считает самой радикальной. Главный сдвиг — ИИ больше не бонус, а базовое ожидание.

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

Что изменилось в требованиях к кандидатам

Еще в 2020 году достаточно было хорошо решать задачи на алгоритмы и уверенно разбираться в system design. Сегодня это лишь минимальный уровень.

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

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

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

Как поменялись собеседования

Формально интервью все еще проверяют алгоритмы, структуры данных и мышление. Но появились новые форматы.

В некоторых компаниях кандидатам разрешают использовать ИИ прямо во время интервью — в режиме шаринга экрана.

Хазарика вспоминает собеседование в стартапе в 2024 году, где ему дали большой файл с багом и прямо разрешили подключить ИИ. Он решил писать код сам и в итоге провалил интервью. Этот опыт стал для него сигналом: игнорировать ИИ — значит играть против правил.

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

Что советуют новичкам и опытным инженерам

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

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

Общий же вывод Хазарики прост: рынок скорее ищет не кодеров или промт-инженеров, а гибридов. Тех, кто понимает фундаментальную инженерию и умеет использовать ИИ как инструмент, а не костыль.

Так, например, Google активно возвращает тех, кто уже когда-то ушел из компании. По данным CNBC, около 20% инженеров, нанятых корпорацией для работы над ИИ в 2025 году — это ее же экс-сотрудники.

Представитель Google подтвердил, что цифра актуальна на декабрь 2025 года.

Почему инженеры возвращаются

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

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

У компании есть и большой «резерв» бывших сотрудников. После крупнейших в своей истории сокращений в начале 2023 года, когда материнская компания Alphabet уволила 12 000 человек, многие специалисты разошлись по рынку. И теперь часть из них возвращается.

Тренд не только Google

Рост числа «бумерангов» заметен по всей индустрии. По данным ADP Research, именно технологический сектор лидирует по возвращению бывших сотрудников.

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

Давление со стороны конкурентов

При этом Google продолжает терять и находить таланты одновременно. Ранее Microsoft переманила несколько десятков сотрудников из исследовательского подразделения DeepMind.

По словам CEO OpenAI Сэма Альтмана, его компания предлагает гигантские бонусы за переход — вплоть до $100 млн.

Возвращение ключевых фигур и смена культуры

Одним из самых заметных возвращений стал Ноам Шазир — со-основатель Character.AI. Он покинул Google в 2021 году, а в 2024-м вместе с командой снова присоединился к DeepMind.

Что это вообще такое?

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

Похоже на историю «мы тебя учим — ты нам отрабатываешь». Но не всё так однозначно.

Почему это может быть отличным стартом

1. Вас действительно учат, а не бросают в омут с головой

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

2. Первый опыт — самый ценный

Ловили себя на мысли: «Везде требуют опыт, но где его взять, если никуда не берут?» Ученический договор решает эту проблему. После 3-6 месяцев обучения у вас в резюме появляется первая серьезная строчка — не курсы и не пет-проекты, а реальная коммерческая практика. Для следующих работодателей это весомый аргумент.

3. Финансовая поддержка в период обучения

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

4. Мягкий старт вместо шока

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

Темная сторона: о чем молчат в красивых вакансиях

1. Юридические кандалы — читайте договор как никогда внимательно!

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

2. Ловушка комфорта

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

3. Русская рулетка с компанией и наставником

Если повезет с командой — вы получите бесценный опыт. Если не повезет — можете попасть:

- На устаревшие технологии, которые нигде больше не нужны

- К наставнику, у которого нет времени вас учить

- В токсичную атмосферу постоянных переработок

4. Ученический договор как способ получить дешевую рабочую силу

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

Как принять правильное решение

Вам точно подойдет ученический договор, если:

- Вы совсем без опыта в коммерческой разработке/тестировании/другой IT-специальности

- Вам нужен наставник и плавный вход в профессию

- Вы готовы немного пожертвовать зарплатой ради будущего опыта

- Нашли компанию с хорошей репутацией и современными технологиями

Дважды подумайте, если:

- Вам с порога предлагают подписать договор, не объясняя условий

- В компании используются технологии, которые больше никто не использует

- Сумма штрафа выглядит неадекватно высокой

- Не могут четко ответить, кто будет вашим наставником и что входит в программу обучения

Памятка для тех, кто рассматривает обучение по договору

1. Задавайте неудобные вопросы на собеседовании:

- «Можно посмотреть учебный план?»

- «Сколько времени наставник будет уделять мне лично?»

- «Какой стек технологий я освою? Будут ли это современные инструменты?»

- «Что будет, если я захочу уйти до окончания срока? Как рассчитывается компенсация?»

- «Как будет расти моя зарплата после обучения?»

2. Ищите отзывы бывших учеников

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

3. Внимательно читайте каждый пункт договора

Если что-то непонятно — просите объяснить. Если не согласны — предлагайте изменить. Помните: всё, что не зафиксировано на бумаге, не существует.

Где искать хорошие программы?

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

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

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

Появились и громкие заявления: например, автор книги «Империя ИИ» Карен Хао считает, что OpenAI уже обладает влиянием, сравнимым с государствами.

Мир в ожидании перемен

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

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

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

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

Как ИИ перестроил рынок капитала

По данным Bloomberg, эффект ChatGPT особенно заметен на фондовом рынке. Главный выигрывающий от происходящего игрок — NVIDIA. Ее графические процессоры стали основой ИИ-индустрии. Так, с момента запуска ChatGPT, акции компании выросли на 979%.

Вслед за ней ускорились и другие гиганты: Microsoft, Apple, Alphabet, Amazon, Broadcom. Теперь семь крупнейших компаний формируют 35% индекса S&P 500 — такой концентрации не было никогда.

Но внутри индустрии звучат и предупреждения. Гендиректор OpenAI Сэм Альтман открыто признает, что «кто-то потеряет феноменальные деньги на ИИ».

Глава Sierra и председатель совета директоров OpenAI Брет Тейлор сравнивает происходящее с пузырем доткомов: компаний может разориться много, но сама технология никуда не исчезнет.

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

Что он умеет

Ассистент берет на себя типовые процессы, которые обычно тратят часы рабочего времени:

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

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

Зачем это HR

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

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

Когда ждать полноценный релиз

Сейчас функция работает в бета-режиме. Полный запуск обещают ближе к 2026 году.

Тогда ассистент станет частью стандартного инструментария работодателей на платформе.

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

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

Диагноз: синдром вакуумной камеры, или Куда пропадают ваши отклики

Представьте себе такую картину. Вы тщательно готовите резюме, пишете сопроводительное письмо (хотя все знают, что их почти никто не читает), отправляете отклик в желаемую компанию. И… тишина. Не «читано», не отклонено, просто ваше резюме улетает в черную дыру.

Что происходит на другой стороне экрана?

Рекрутер, заваленный 1000+ откликами на одну вакансию (половина из которых — «Специалист по маникюру» на позицию «Java-разработчик»), физически не успевает их все просмотреть. Вместо этого он пользуется системой фильтров HH, которая отсеивает кандидатов по каким-то ей одной ведомым критериям. Ваше идеальное резюме может не дойти до человека просто потому, что вы не вставили в текст ключевое слово «Kubernetes», а написали «k8s».

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

Вакансии-призраки

Это мое любимое. Вы когда-нибудь видели вакансию, которая висит месяцами, а то и годами? Создается стойкое ощущение, что некоторые компании не столько ищут сотрудников, сколько ведут маркетинговую деятельность. «Смотрите, мы растем, мы в поиске крутых специалистов!» — на самом деле, ни одного нового человека в штат не принимается.

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

AI-собеседования: когда твою судьбу решает бездушный код

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

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

Почему все уходят в Telegram

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

Почему мессенджер обогнал гиганта индустрии?

Скорость. Вакансия в канале публикуется сегодня — завтра кандидат уже на собеседовании. Никаких недельных циклов обработки.

Релевантность. Каналы по своей сути тематические. Подписываясь на канал для Python-разработчиков, вы не увидите предложений для менеджеров по продажам.

Прямой контакт. Часто в посте указан прямой телеграм нанимающего менеджера или HR. Вы пишете ему напрямую, минуя все формальности.

Живое комьюнити. В обсуждениях можно сразу задать вопросы о компании, узнать подводные камни от тех, кто уже там работал.

Кстати, если вам интересно – я и сам веду канал с вакансиями для начинающих в IT, где ежедневно публикую новые предложения. Можете найти его как ITStartJob. Но это просто к слову – вариантов таких каналов сейчас много.

Что же делать?

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

Смещайте фокус. Пусть HH будет вашим «запасным аэродромом». Основные усилия направьте на живые площадки: Telegram, специализированные комьюнити, митапы и конференции.

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

Будьте активны. Не ждите, пока вас найдут. Найдите компании, в которых хотите работать, и напишите HR или тимлиду напрямую в LinkedIn или Telegram. Живое, заинтересованное сообщение ценится куда выше сотни безликих откликов.

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

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

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

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

Почему так происходит? Всё просто: в последние годы активно формировалось ощущение, что «войти в ИТ» может любой. Эту идею подогревали многочисленные курсы и школы, обещавшие быстрый старт и высокую зарплату. Люди массово шли учиться, увольнялись со старых работ, верили, что через несколько месяцев станут разработчиками. Но по окончании курсов выяснилось, что рынок переполнен. В лучшем случае — джуны без практики, чаще — интерны с тестовыми проектами и большими амбициями. Когда количество вакансий сократилось, а конкуренция выросла даже среди опытных специалистов, у новичков сработал инстинкт выживания: «главное — попасть внутрь, а там разберусь». Логика простая — зацепиться, пересидеть, закрепиться, а настоящий опыт придёт потом. Но опытный HR по первым строкам резюме чувствует, что что-то не так.

Тревожные сигналы, на которые обращают внимание рекрутеры в ИТ

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

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

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

Когда странное резюме не повод для отказа

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

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

Совет: не стоит расписывать весь карьерный путь. Достаточно 2–4 последних мест работы, при этом желательно указывать причину ухода — «завершение проекта», «реорганизация компании», «смена приоритетов». Это помогает избежать ложных интерпретаций.

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

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

Как рекрутеру проверять реальность опыта

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

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

Live-coding и тестовые задания. Это хорошо работает, если их проводить в режиме реального времени. Когда кандидат пишет код на глазах у интервьюеров, вероятность подлога сводится к нулю. Если же тестовое выполняется удалённо, риск того, что за него ответят «помощники», будь то друзья или ИИ, всегда остается.

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

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

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

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

Честность — новый вход в ИТ

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

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

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

Соответствующий проект опубликован на портале нормативных правовых актов.

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

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

Круглогодичный призыв стартует с 2026 года

Напомним, что с 2026 года в России вводится круглогодичный призыв в армию. Закон подписал президент Владимир Путин 4 ноября.

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

Расширение IT-отсрочек

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

• магистратуру по направлениям «Радиофизика» и «Статистика»;
• бакалавриат по направлению «Ядерная физика и технологии».

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

Я проанализировала более 20 предложений по написанию статьей ВАК на заказ и собрала подборку сервисов. В первой части — ТОП-10 сервисов с полным спектром услуг, в следующей — 3 дополнительных сервиса. Так вы получите обзор и сможете выбрать вариант по бюджету и задачам.

ТОП-10 онлайн-сервисов для помощи в написании статей ВАК в 2026 году

1. Homework — персональный формат, где эксперт сопровождает автора статьи ВАК от выбора темы до финальной проверки.
2. Автор24 — крупная база специалистов с учеными степенями и высоким качеством консультаций по публикациям ВАК.
3. Студворк — длительная поддержка и бесплатные доработки по статьям ВАК в течение года.
4. Studently — удобное онлайн-взаимодействие и мгновенная связь с экспертами по структуре и тексту статьи.
5. Zaochnik — более 20 лет стабильной работы и точное соответствие публикаций требованиям ВАК.
6. Напишем — прозрачная схема оплаты и контроль качества консультаций без риска для клиента.
7. Студландия — низкие цены и бесплатная первичная консультация по структуре статьи.
8. Все сдал — лидер по числу экспертов и отзывов, быстрая помощь при подготовке публикаций ВАК.
9. Феникс — быстрый отклик консультантов и оперативная оценка заказа по статье.
10. Student24 — открытая система предложений и прямое взаимодействие со специалистами без посредников.

1. Homework

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

• Стоимость: от 11 500 руб. за консультацию по статье ВАК
• Направления: гуманитарные, естественные, технические, юридические, экономические, педагогические, IT
• Гарантийный срок: до 6 месяцев (в течение этого времени доступны бесплатные правки)
• Виды услуг: консультации по структуре и содержанию статей, редактирование и повышение уникальности, проверка антиплагиата, подготовка списка литературы и аннотации, оформление по стандартам ВАК и ГОСТ, помощь с речью для защиты, рецензирование и анализ текстов

Преимущества:

• низкие цены и рассрочка;
• консультации по всем этапам подготовки статьи;
• опытные специалисты с профильным образованием;
• соблюдение сроков сдачи;
• индивидуальный подход к каждой работе;
• бесплатные доработки без скрытых платежей;
• проверка на антиплагиат до отправки клиенту;
• конфиденциальность всех данных;
• персональный менеджер сопровождает заказ;
• работа без автоматической генерации текста;
• контроль качества через внутренний отдел;
• гарантия возврата средств при несоответствии требованиям;
• круглосуточная поддержка;
• помощь в выборе научного журнала;
• возможность разделения платежа на несколько частей;
• соблюдение стандартов ВАК и требований вуза.

Недостатки:

• не указана финальная цена за публикацию в журнале;
• консультации проводятся только онлайн;
• требуется предоплата 30%;
• длительные сроки при заказах большого объема.

Перейти на сайт >>>

2. Автор24

Сервис Автор24 работает как крупная онлайн-платформа, где можно заказать консультацию по подготовке статьи для публикации в журнале из перечня ВАК. Здесь студенты, аспиранты и исследователи обращаются к экспертам, чтобы получить профессиональные рекомендации по структуре, формулировке научной идеи и требованиям издания. Каждый заказ сопровождается специалистом, который помогает адаптировать материал под нужный формат, уточнить методологию, повысить оригинальность и подготовить текст к рецензированию. В команде более 400 000 экспертов, среди которых кандидаты и доктора наук, преподаватели ведущих российских вузов. Работа по статье ВАК на заказ выстраивается напрямую между автором и экспертом, что делает процесс прозрачным и контролируемым.

• Стоимость: от 3 200 руб. до 4 400 руб. за консультацию по статье ВАК
• Направления: гуманитарные, естественные, экономические, технические, юридические, педагогические, IT
• Гарантийный срок: 20 дней (в этот период можно бесплатно запросить корректировки)
• Виды услуг: консультации по научным статьям ВАК, выбор журнала для публикации, повышение уникальности, редактирование и корректура текста, подготовка сопроводительных документов, рецензирование, подбор научных источников, анализ содержания

Преимущества:

• большая база экспертов разных направлений;
• персональные консультации с учетом требований ВАК;
• профессиональные специалисты с учеными степенями;
• прямое взаимодействие между автором и экспертом;
• гарантия возврата средств при невыполнении условий;
• безопасная сделка через внутреннюю систему сервиса;
• проверка оригинальности в выбранной системе антиплагиата;
• бесплатные правки в течение гарантийного срока;
• возможность рассрочки и оплаты частями;
• прозрачное формирование цены по результатам общения с экспертом;
• работа только через защищенную платформу без обмена личными контактами;
• поддержка клиентов по телефону, в мессенджерах и по e-mail;
• рейтинговая система, помогающая выбрать лучшего специалиста;
• статистика и история завершенных проектов доступна пользователям;
• интерфейс и мобильное приложение для удобной работы со всеми заказами.

Недостатки:

• нет фиксированной стоимости на публикацию в журнале;
• консультации проводятся только онлайн;
• срок гарантии ограничен 20 днями;
• цена зависит от сезона и загруженности экспертов.

Перейти на сайт >>>

3. Студворк

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

• Стоимость: от 500 руб. за консультацию по статье ВАК
• Направления: гуманитарные, технические, естественные, юридические, экономические, педагогические, IT
• Гарантийный срок: 1 год (в течение этого времени бесплатные доработки при сохранении исходных требований)
• Виды услуг: консультации по написанию статьи ВАК, корректура и редактирование текста, повышение уникальности, рецензирование, помощь с выбором журнала, структурирование материала, подбор источников, проверка на антиплагиат

Преимущества:

• крупная база авторов с научной квалификацией;
• гарантия на заказ до одного года;
• бесплатные правки в рамках условий заявки;
• безопасная сделка через платформу;
• высокая уникальность работ — от 70%;
• открытые рейтинги и отзывы на экспертов;
• прозрачная система ценообразования;
• возможность выбрать исполнителя по профилю дисциплины;
• работа над заказами без посредников;
• минимальный срок консультации — от 2 часов;
• отклики от экспертов появляются в течение 10 минут;
• отсутствие скрытых комиссий;
• техническая поддержка по телефону и e-mail;
• фильтрация авторов по уровню опыта и образованию;
• положительная репутация и высокий средний рейтинг — 4.97.

Недостатки:

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

Перейти на сайт >>>

4. Studently

Онлайн-сервис Studently специализируется на консультационной помощи авторам, готовящим статьи для публикации в журналах из перечня ВАК. Платформа работает с аспирантами, преподавателями и исследователями, которым важно получить экспертную поддержку на всех этапах подготовки научного текста. Здесь помогают выстроить структуру статьи, сформулировать научную идею, проверить уникальность и привести оформление к требованиям ГОСТ и ВАК. Клиент взаимодействует с автором напрямую через чат, что обеспечивает прозрачность и оперативность процесса. Отдел контроля качества следит за соответствием требований, а гарантия на каждую работу действует до 30 дней. Сервис подходит тем, кто хочет сохранить авторство и одновременно получить профессиональную поддержку при подготовке материала к публикации.

• Стоимость: от 2 500 руб. за консультацию по статье ВАК
• Направления: гуманитарные, экономические, технические, педагогические, юридические, естественные, IT
• Гарантийный срок: 30 дней (при необходимости может быть продлен до 60 дней)
• Виды услуг: консультации по написанию статей ВАК, редактирование и корректура, повышение уникальности текста, подбор литературы и оформление ссылок, консультации по структуре и стилю, проверка на антиплагиат, поддержка при подготовке к публикации

Преимущества:

• индивидуальный подход к каждой статье;
• более 2 800 экспертов на платформе;
• прямая связь с автором без посредников;
• быстрый подбор специалиста под заказ;
• круглосуточная работа сервиса без выходных;
• гарантия качества и контроль уникальности;
• консультации по требованиям ВАК и ГОСТ;
• бесплатные доработки в течение гарантийного периода;
• точное соблюдение сроков выполнения;
• безопасная сделка и защита платежей;
• возможность делить оплату на два этапа;
• прозрачный расчет стоимости через онлайн-калькулятор;
• техническая поддержка 7 дней в неделю;
• отзывы и рейтинг авторов доступны перед заказом;
• оформление публикаций с учетом рекомендаций рецензентов.

Недостатки:

• общение с экспертами только в онлайн-формате;
• цена растет при срочных заказах;
• нет фиксированной стоимости за конкретный объем;
• часть отзывов не содержит подробных комментариев по работе.

Перейти на сайт >>>

5. Zaochnik

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

• Стоимость: от 1 500 руб. за консультацию по статье ВАК
• Направления: гуманитарные, экономические, технические, педагогические, юридические, естественные, IT
• Гарантийный срок: 2 месяца (в течение этого времени выполняются бесплатные правки и уточнения)
• Виды услуг: консультации по написанию статей ВАК, повышение уникальности, редактирование и корректура текста, помощь с выбором журнала, оформление по ГОСТ, проверка источников и ссылок, подготовка сопроводительных документов, рецензирование, консультации перед подачей статьи в издание

Преимущества:

• более 2 700 экспертов по 600 направлениям;
• круглосуточная поддержка 24/7;
• официальное заключение договора;
• бесплатные корректировки в течение гарантийного срока;
• консультации преподавателей и кандидатов наук;
• возможность срочного обращения;
• прозрачная схема оплаты с предоплатой 25%;
• безопасная сделка и защита личных данных;
• контроль качества готовых материалов;
• помощь в подготовке к публикации и защите;
• личный менеджер, сопровождающий заказ;
• большой опыт работы на рынке — с 2001 года;
• высокий рейтинг сервиса (4.8 по отзывам студентов);
• поддержка на всех этапах работы;
• проверка уникальности и стиля научного текста.

Недостатки:

• консультации проводятся только онлайн;
• итоговая стоимость зависит от сложности темы;
• срочные заказы стоят дороже;
• не все эксперты принимают заказы по редким дисциплинам.

Перейти на сайт >>>

6. Напишем

Фриланс-биржа «Напишем.ру» создана для студентов, преподавателей и исследователей, которым требуется экспертная поддержка при подготовке научных материалов. На площадке можно заказать статью ВАК для публикации в журнале. Сервис объединяет авторов с профильным образованием, научными степенями и подтвержденной квалификацией. Они помогают структурировать текст, доработать формулировки, скорректировать стиль, подобрать источники и привести работу к требованиям ВАК и ГОСТ. Все заказы проходят через систему «Безопасная сделка»: клиент вносит оплату, но средства переводятся исполнителю только после подтверждения, что работа выполнена полностью и соответствует запросу. Поддержка отвечает ежедневно, а выбор эксперта возможен по рейтингу, отзывам и специализации.

• Стоимость: от 2 500 руб. за консультацию по статье ВАК
• Направления: гуманитарные, экономические, юридические, технические, педагогические, медицинские, естественные, IT-дисциплины
• Гарантийный срок: 30 дней (в течение этого периода выполняются бесплатные корректировки)
• Виды услуг: консультации по подготовке статей ВАК, корректура и редактирование текста, проверка уникальности, подбор литературы, структурирование разделов, рецензирование, работа с аннотацией и списком источников, консультации по требованиям издания, советы по улучшению научного содержания

Преимущества:

• прозрачная система безопасных сделок;
• более 560 авторов онлайн ежедневно;
• рейтинг исполнителей на основе отзывов;
• выбор эксперта по профилю и опыту;
• прямая связь с консультантом в чате;
• гарантия оригинальности от 80%;
• проверка на antiplagiat.ru перед сдачей;
• бесплатные доработки в течение гарантийного срока;
• официальное заключение договора с клиентом;
• контроль качества через службу проверки;
• поддержка анонимности и конфиденциальности;
• выполнение заказов в срок от 2 дней;
• низкая предоплата от 25%;
• возврат средств при нарушении условий;
• скидка 10% на первый заказ.

Недостатки:

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

Перейти на сайт >>>

7. Студландия

Сервис Studlandia консультирует студентов, преподавателей и исследователей, которые готовят статьи для публикации в журналах из перечня ВАК. Здесь все заинтересованные получают профессиональную помощь по структуре, корректности научных формулировок, аннотации, списку литературы и уникальности текста. Работой занимаются специалисты с академическим опытом, знакомые с требованиями ВАК и ГОСТ. На сайте указано, что компания не продает готовые научные статьи и не занимается изготовлением документов об образовании. Все консультации проходят в правовом поле и направлены на развитие собственных исследовательских навыков клиента. Studlandia гарантирует конфиденциальность данных и безопасную оплату, а также предоставляет бесплатные доработки в течение гарантийного периода.

• Стоимость: от 100 руб. за консультацию по статье ВАК
• Направления: гуманитарные, технические, юридические, педагогические, медицинские, экономические, естественные, IT
• Гарантийный срок: до 21 дня (в течение этого времени выполняются бесплатные доработки)
• Виды услуг: консультации по структуре и содержанию статей ВАК, редактирование текста, повышение уникальности, подбор источников и литературы, проверка аннотации, корректировка разделов, подготовка презентации и речи для защиты, сопровождение при подаче работы в журнал

Преимущества:

• бесплатная первичная консультация;
• общение напрямую с консультантом в Telegram;
• оплата только после получения готовой работы;
• низкие цены по сравнению с аналогами (на 20–30% ниже);
• проверка оригинальности в антиплагиате;
• гарантия конфиденциальности и безопасных платежей;
• бесплатные правки по требованиям преподавателя;
• консультанты с профильным образованием;
• поддержка клиентов 7 дней в неделю;
• обработка заявок в течение 5 минут;
• срочные заказы — от 12 часов;
• возможность рассчитать стоимость онлайн;
• более 4000 экспертов на платформе;
• точное соблюдение ГОСТ и требований ВАК;
• контроль качества и сопровождение до защиты.

Недостатки:

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

Перейти на сайт >>>

8. Все сдал

Онлайн-площадка «Все сдал!» — это маркетплейс образовательных консультаций, где студенты, аспиранты и преподаватели могут купить услуги и получают экспертную помощь при подготовке научных материалов, в том числе статей для публикации в журналах из перечня ВАК. На сайте работают проверенные специалисты, которые разбираются в академических требованиях, структуре научных текстов и критериях Высшей аттестационной комиссии. Они помогают авторам собрать и систематизировать материал, скорректировать формулировки, доработать аннотацию и список литературы, привести текст в соответствие с ГОСТ. Каждый заказ размещается через систему «Безопасная сделка», где средства резервируются на время работы и переводятся исполнителю только после подтверждения результата. Консультации по тому, как написать статью ВАК на заказ, проходят онлайн, а отклик экспертов поступает уже в течение нескольких минут.

• Стоимость: от 400 руб. за консультацию по статье ВАК
• Направления: экономика, юриспруденция, педагогика, психология, менеджмент, гуманитарные, естественные, технические и IT-науки
• Гарантийный срок: от 7 дней (в течение этого времени предоставляются бесплатные доработки)
• Виды услуг: консультации по структуре и содержанию статьи ВАК, корректура текста, рецензирование, подбор литературы, проверка аннотации и выводов, редактирование списка источников, консультации по требованиям изданий, советы по улучшению аргументации, подготовка речи и презентации для защиты

Преимущества:

• быстрый отклик экспертов после публикации заказа;
• выбор специалиста по рейтингу и отзывам;
• прямое общение с консультантом без посредников;
• бесплатные доработки и уточнения по запросу;
• гарантия возврата денег при нарушении условий;
• безопасная сделка и контроль платежей;
• поддержка пользователей 7 дней в неделю;
• проверенные эксперты с высшим образованием;
• низкие цены за счет прямого сотрудничества;
• выполнение срочных заказов от 4 часов;
• рейтинг более 857 тысяч отзывов с оценкой 4.9 из 5;
• удобный интерфейс сайта и мобильное приложение;
• подробная база советов по написанию научных текстов;
• высокая уникальность материалов (до 95%);
• индивидуальный подход к каждой теме и дисциплине.

Недостатки:

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

Перейти на сайт >>>

9. Феникс

Сервис Feniks.Help работает более 10 лет, высоко ценится, специализируется на профессиональной академической поддержке студентов и исследователей. Здесь проводят консультации по научным статьям, включая публикации в журналах из перечня ВАК и РИНЦ. Эксперты сервиса помогают авторам разобраться со структурой материала, уточнить формулировки, доработать аннотацию, подобрать научные источники и привести текст в соответствие с требованиями Высшей аттестационной комиссии. На площадке зарегистрировано свыше 22 000 авторов, среди которых преподаватели, аспиранты и специалисты прикладных направлений. Feniks.Help работает по принципу прямого взаимодействия клиента и эксперта без посредников. Оплата проводится через безопасную систему, а средства резервируются до подтверждения готовой работы. Клиент может самостоятельно выбрать консультанта, оценить его рейтинг и отзывы, а также контролировать процесс консультации онлайн.

• Стоимость: не указано
• Направления: гуманитарные, экономические, юридические, педагогические, технические, естественные, медицинские, IT
• Гарантийный срок: не указан (предусмотрены бесплатные доработки в установленный период)
• Виды услуг: консультации по структуре и содержанию статей ВАК, редактирование научных текстов, проверка аннотаций, подбор литературы, корректировка по ГОСТ, анализ рецензий и диссертаций, повышение уникальности, подготовка речей и презентаций для защиты, помощь в подготовке материалов к подаче в журналы ВАК

Преимущества:

• прямая работа с экспертами без посредников;
• более 22 000 авторов, 2400 активных онлайн;
• выбор специалиста по рейтингу и отзывам;
• безопасная сделка с оплатой после подтверждения результата;
• быстрый отклик — оценка заказа в течение 15 минут;
• консультации преподавателей, кандидатов и докторов наук;
• выполнение срочных заказов от нескольких часов;
• гарантия оригинальности и корректности текста;
• бесплатные доработки и уточнения по требованиям ВАК;
• поддержка клиентов по телефону и электронной почте;
• широкий перечень дисциплин и видов научных работ;
• прозрачная система расчета стоимости;
• конфиденциальность данных клиентов;
• простая онлайн-форма для заказа;
• публикации принимаются в ведущих изданиях ВАК.

Недостатки:

• отсутствует фиксированный прайс, цена уточняется индивидуально;
• сроки и стоимость зависят от выбранного эксперта;
• нет информации о длительности гарантийного срока;
• ограниченное время поддержки (с 9:00 до 21:00).

Перейти на сайт >>>

10. Student24

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

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

Преимущества:

• прямая работа с экспертами без посредников;
• конкурентные цены за счет открытых предложений;
• более 75 тысяч успешно завершенных проектов;
• возможность выбора специалиста по рейтингу и отзывам;
• защищенная сделка с оплатой после подтверждения результата;
• гарантированное качество и соблюдение сроков;
• поддержка клиентов на всех этапах заказа;
• конфиденциальность персональных данных;
• широкий спектр направлений и научных дисциплин;
• помощь от аспирантов и преподавателей вузов;
• бесплатное размещение заявки и оценка работы;
• гибкая система обратной связи с автором;
• профессиональные консультации по требованиям ВАК;
• структурированный процесс с понятными этапами;
• положительные отзывы и высокая оценка пользователей (5 из 5).

Недостатки:

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

Перейти на сайт >>>

Еще 3 сервиса для помощи в написании статей ВАК

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

• СтудСервис. Площадка работает с 2006 года и предоставляет консультации по написанию научных статей, в том числе для публикации в изданиях ВАК. Клиентов консультируют преподаватели вузов, которые помогают выстроить структуру исследования, уточнить тему и привести текст к академическим требованиям. Проверка оригинальности считается обязательной, а доработки выполняются бесплатно при сохранении исходного задания.
• StudLance. Сервис предлагает консультации по подготовке научных статей для публикации в изданиях ВАК. Эксперты помогают авторам собрать и структурировать материал, оформить текст по требованиям журнала и скорректировать научные формулировки. Все работы выполняются с соблюдением академических стандартов и проходят проверку квалифицированными специалистами.
• TopWork24. Сервис предоставляет консультации по подготовке научных статей для журналов из перечня ВАК. Эксперты с высшим образованием и научными званиями помогают авторам выстроить структуру текста, уточнить формулировки и привести материал к требованиям научного издания. Все консультации проходят в формате безопасной сделки, а гарантийный срок на доработку составляет до 60 дней.

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

Поделитесь в комментариях опытом сотрудничества с сервисами, чтобы помочь другим авторам сделать выбор!

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

ТОП-10 онлайн-сервисов для помощи в написании ВКР в 2026 году

1. Homework — выделяется высоким уровнем персонального сопровождения, так как каждому студенту назначают менеджера, который контролирует процесс подготовки ВКР от начала до защиты.
2. Автор24 — отличается масштабом базы экспертов и использованием технологий искусственного интеллекта для подбора консультантов и проверки уникальности.
3. Студворк — известен самым длительным гарантийным сроком на рынке: бесплатные консультации и правки предоставляются в течение целого года.
4. Studently — привлекает студентов удобной системой мгновенного расчета стоимости консультаций и возможностью общения с экспертами в онлайн-чате без задержек.
5. Zaochnik — один из старейших сервисов с официальным статусом и бессрочной гарантией для дипломных и диссертационных проектов.
6. Напишем — отличается строгим отбором консультантов и прозрачной схемой безопасных сделок, где оплата происходит только после утверждения результата.
7. Студландия — выделяется бесплатной первичной консультацией и системой частичной оплаты, что делает процесс сотрудничества максимально удобным.
8. Все сдал — лидирует по количеству экспертов и отзывов, предлагая консультации напрямую без посредников и с минимальной стоимостью.
9. Феникс — известен быстрым откликом консультантов: предложения поступают уже через 15 минут после размещения заявки.
10. Student24 — выгодно отличается прямым взаимодействием со специалистами и прозрачной системой оплаты без комиссий и посредников.

1. Homework

Онлайн-сервис Homework создан для студентов, которым нужна профессиональная помощь в подготовке выпускной квалификационной работы. Платформа предлагает формат консультаций, где эксперты помогают разобраться со структурой исследования, подобрать источники, оформить разделы по ГОСТ и подготовиться к защите. Здесь работают специалисты разных направлений — от гуманитарных и педагогических до технических и IT-дисциплин. Студент получает не готовый текст, а индивидуальную поддержку: можно обсудить каждую главу, скорректировать расчеты, получить рекомендации по аннотации или речевому выступлению. Такой подход помогает сохранить авторство, сэкономить время и снизить нагрузку в процессе написания. Homework уделяет внимание качеству, контролирует уникальность каждой работы и обеспечивает полную конфиденциальность.

• Стоимость: от 6 900 руб. за консультацию по ВКР
• Направления: гуманитарные, экономические, технические, юридические, педагогические, IT-специальности
• Гарантийный срок: до 6 месяцев (в течение этого времени доступны бесплатные правки)
• Виды услуг: консультации по написанию ВКР, разбор отдельных глав, помощь с речью на защиту, подбор литературы, повышение уникальности текста, оформление по ГОСТ, проверка антиплагиата

Преимущества:

• персональный менеджер сопровождает заказ на всех этапах;
• круглосуточная консультационная поддержка;
• доступные цены для студентов разных регионов;
• рассрочка и частичная оплата заказа;
• помощь оказывают дипломированные специалисты;
• обязательная проверка качества перед передачей работы;
• бесплатная проверка уникальности текста;
• внесение корректировок без доплаты в гарантийный срок;
• учет методических требований кафедры;
• консультации по оформлению по ГОСТ;
• полная защита персональных данных клиентов;
• удобная поддержка по телефону и онлайн-чату;
• прозрачные условия сотрудничества без скрытых платежей;
• рейтинг 4,7 из 5 на независимых площадках;
• представительства в крупнейших городах России.

Недостатки:

• нет автоматического расчета стоимости без формы заявки;
• редкие темы требуют больше времени на согласование;
• отсутствуют консультации «в тот же день» при большом объеме;
• скидки и акции ограничены по срокам.

2. Автор24

Сервис Автор24 — одна из крупнейших онлайн-площадок, где студенты получают консультации по подготовке выпускных квалификационных работ. Платформа объединяет более 400 тысяч экспертов по разным направлениям. Здесь студенты не заказывают готовые тексты, а получают помощь в разборе сложных тем, корректировке глав, проверке расчетов, анализе источников и подготовке к защите. Работа строится в формате сотрудничества: студент описывает задачу, выбирает специалиста с нужным опытом, обсуждает детали и получает обратную связь. Такой подход экономит время, снижает нагрузку и позволяет сохранить авторство исследования. Все взаимодействие проходит через личный кабинет, а расчеты осуществляются безопасно через систему сервиса. Автор24 работает с 2012 года, имеет собственную IT-платформу и внедряет технологии искусственного интеллекта для подбора экспертов и проверки уникальности текстов.

• Стоимость: от 12 400 руб. до 17 000 руб. за консультацию по ВКР
• Направления: гуманитарные, технические, экономические, педагогические, юридические, естественно-научные, IT-дисциплины
• Гарантийный срок: 20 дней после завершения консультации, во время которого доступны бесплатные правки
• Виды услуг: консультации по написанию ВКР, помощь с планом и структурой, разбор отдельных глав, анализ расчетов, подготовка к защите, подбор источников, повышение уникальности текста, рекомендации по ГОСТ, проверка антиплагиата

Преимущества:

• индивидуальный выбор эксперта с учетом рейтинга и отзывов;
• более 114 тысяч специалистов по ВКР разных направлений;
• консультации проводятся полностью онлайн;
• безопасные расчеты без посредников;
• возможность оплатить заказ частями;
• беспроцентная рассрочка от банков-партнеров;
• контроль качества и обязательная проверка работ;
• бесплатные правки в гарантийный срок;
• защита персональных данных и анонимность;
• круглосуточная поддержка через чат и почту;
• собственная система проверки уникальности;
• быстрая реакция экспертов — от нескольких минут;
• рейтинг сервиса 4,9 из 5 по отзывам студентов;
• детальная статистика и прозрачная стоимость услуг;
• гибкие условия сотрудничества и прозрачные правила.

Недостатки:

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

Перейти на сайт >>>

3. Студворк

Сервис работает с 2011 года и входит в число крупнейших площадок, где студенты получают помощь при подготовке выпускных квалификационных работ. На сайте зарегистрировано более 118 тысяч авторов, среди которых преподаватели, аспиранты и научные консультанты. Студенты размещают задание, выбирают специалиста с подходящим рейтингом и договариваются о формате взаимодействия. Эксперт помогает разобраться с планом, уточнить структуру, скорректировать расчеты, доработать главы и объяснить замечания научного руководителя. Это подходит тем, кто хочет ускорить процесс подготовки ВКР, не теряя контроля над содержанием. На площадке активно используется система рейтингов, отзывов и безопасных расчетов, а отклики от специалистов поступают в течение 10 минут после публикации задания. Работы проверяются на уникальность, а гарантия действует целый год, что дает студентам время спокойно внести правки или заказать дополнительную консультацию.

• Стоимость: от 5 000 руб. за консультацию по ВКР
• Направления: экономика, юриспруденция, педагогика, менеджмент, строительство, IT, энергетика, психология, лингвистика, социология
• Гарантийный срок: 1 год (в течение этого периода возможны бесплатные правки и консультации)
• Виды услуг: консультации по подготовке ВКР, разбор сложных разделов, проверка расчетов и источников, корректировка структуры, советы по презентации, сопровождение до защиты, повышение уникальности текста, проверка антиплагиата

Преимущества:

• более 118 тысяч экспертов с подтвержденной квалификацией;
• отклики от авторов появляются в течение 10 минут;
• гарантия на консультацию и правки действует 1 год;
• безопасная сделка с возвратом денег при нарушении условий;
• высокий уровень уникальности по всем системам проверки;
• бесплатные доработки без ограничений по числу обращений;
• можно выбрать автора по рейтингу и отзывам студентов;
• прозрачная система расчета стоимости без скрытых комиссий;
• поддержка по телефону, почте и в онлайн-чате;
• средняя оценка сервиса 4,97 из 5 по отзывам студентов;
• студенты самостоятельно определяют цену за консультацию;
• персональный менеджер контролирует процесс взаимодействия;
• действует скидка 10% по промокоду STUD10;
• удобный интерфейс и понятная форма заказа;
• опыт работы более 15 лет и миллионы выполненных заданий.

Недостатки:

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

Перейти на сайт >>>

4. Studently

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

• Стоимость: от 3 500 руб. за консультацию по ВКР
• Направления: экономика, юриспруденция, педагогика, социология, психология, финансы, менеджмент, IT, строительство, медицина
• Гарантийный срок: 30 дней (с возможностью продления до 60 дней)
• Виды услуг: консультации по ВКР, проверка расчетов, помощь с практической и теоретической частью, оформление по ГОСТ, антиплагиат, речь на защиту, работа с источниками

Преимущества:

• прямая связь с экспертом через онлайн-чат;
• бесплатные доработки в течение гарантийного срока;
• безопасные расчеты и защита платежей;
• мгновенный расчет цены через калькулятор;
• доступная стоимость консультаций;
• быстрая реакция службы поддержки;
• 2800 авторов онлайн ежедневно;
• рейтинг сервиса 4,8 балла по отзывам студентов;
• 326 тысяч довольных клиентов;
• оплата в два этапа без переплаты;
• индивидуальный подбор эксперта под задание;
• гарантия соблюдения вузовских требований и ГОСТ;
• контроль качества на каждом этапе;
• консультации по всем формам обучения — бакалавр, магистр, специалист;
• скидка 10% по промокоду для новых заказчиков.

Недостатки:

• цена повышается при срочном заказе;
• требуется регистрация для расчета стоимости;
• короткий стандартный гарантийный срок — 30 дней;
• высокий спрос в сезон сессий увеличивает время отклика.

Перейти на сайт >>>

5. Zaochnik

Сервис работает с 2001 года и занимает лидирующие позиции среди российских онлайн-площадок, где студенты получают помощь при подготовке выпускных квалификационных работ. Платформа объединяет более 2 700 экспертов, которые консультируют по 600 дисциплинам. Сервис ориентирован на тех, кто готовит ВКР самостоятельно, но нуждается в профессиональных подсказках по структуре, расчетам, анализу литературы и требованиям ГОСТ. Эксперты помогают студентам корректировать главы, прорабатывать практическую часть, разбирать ошибки и готовить речь для защиты. Работа выстраивается прозрачно: менеджер сопровождает заказ с момента заявки до конца консультации, а студент может напрямую общаться со специалистом в чате и отслеживать все этапы. Zaochnik сотрудничает с преподавателями и научными работниками, обеспечивая точность расчетов и соответствие вузовским стандартам. Каждый заказ сопровождается официальной гарантией, а доработки вносятся бесплатно.

• Стоимость: от 7 000 руб. за консультацию по ВКР
• Направления: педагогика, экономика, психология, юриспруденция, медицина, программирование, гостиничное дело, менеджмент, финансы
• Гарантийный срок: 2 месяца, для дипломных и диссертаций — бессрочно
• Виды услуг: консультации по написанию ВКР, помощь с практической частью, анализ литературы, подбор источников, проверка расчетов, оформление по ГОСТ, проверка антиплагиата, сопровождение до защиты

Преимущества:

• официальная работа на рынке с 2001 года;
• более 2 700 экспертов по 600 дисциплинам;
• 24/7 поддержка и персональный менеджер;
• предоплата всего 25% перед началом работы;
• бесплатные корректировки в рамках гарантийного срока;
• заключение официального договора с клиентом;
• контроль качества от отдела экспертизы;
• возможность общения с экспертом напрямую в чате;
• подробная консультация по каждому этапу ВКР;
• гарантия соответствия требованиям ГОСТ и методичек;
• индивидуальный расчет стоимости через онлайн-форму;
• скидки и акции для постоянных клиентов;
• высокий средний рейтинг — 4,8 по отзывам студентов;
• база проверенных преподавателей и кандидатов наук;
• поддержка студентов бакалавриата, магистратуры и аспирантуры.

Недостатки:

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

Перейти на сайт >>>

6. Напишем

Фриланс-биржа Напишем.ру — один из крупнейших российских онлайн-сервисов, где студенты получают консультации и экспертную помощь при подготовке выпускных квалификационных работ. Площадка объединяет тысячи авторов с подтвержденным образованием и опытом преподавания. Формат сотрудничества прост: студент размещает задание, получает предложения от экспертов, выбирает исполнителя и общается с ним напрямую через чат. Такая схема помогает сократить время на подготовку ВКР, получить профессиональные комментарии, уточнить методику расчетов и привести текст к требованиям кафедры. Сервис работает по принципу безопасной сделки: автор получает оплату только после принятия работы, что исключает риск обмана. Все заказы сопровождаются бесплатными корректировками и гарантийной поддержкой, а студенты могут выбрать уровень оригинальности и систему проверки антиплагиата.

• Стоимость: от 6 950 руб. за консультацию по ВКР
• Направления: экономика, юриспруденция, психология, педагогика, медицина, менеджмент, финансы, информатика, программирование, социология, филология, государственное управление
• Гарантийный срок: 30 дней с бесплатными доработками
• Виды услуг: консультации по ВКР, разбор практических и теоретических глав, корректировка текста и расчетов, проверка уникальности, сопровождение до защиты, консультации по ГОСТ и вузовским требованиям

Преимущества:

• безопасная сделка, при которой оплата переводится автору только после одобрения результата;
• прямая связь с исполнителем через чат без посредников;
• проверенные авторы, прошедшие трехэтапный отбор и собеседование;
• бесплатные доработки в течение гарантийного срока;
• индивидуальный выбор эксперта по рейтингу и отзывам;
• онлайн-калькулятор для расчета цены;
• гибкая система предоплаты — от 25%;
• средний рейтинг исполнителей 9–10 из 10 по отзывам студентов;
• контроль качества и служба арбитража в случае споров;
• уникальность текстов от 75% и выше;
• гарантия конфиденциальности и защита персональных данных;
• круглосуточная поддержка по телефону и почте;
• скидка 10% на первый заказ;
• быстрый отклик экспертов — от 5 минут;
• выполнение срочных заказов за 3 дня и менее.

Недостатки:

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

Перейти на сайт >>>

7. Студландия

Сервис работает с 2015 года и помогает студентам готовиться к выпускной квалификационной работе на всех этапах — от консультаций по структуре до финальной проверки антиплагиата. На платформе зарегистрированы тысячи преподавателей и научных консультантов, готовых разбирать сложные темы, помогать в анализе источников, структурировании данных и оформлении ВКР в соответствии с ГОСТ. Studlandia не занимается продажей готовых дипломов — все услуги предоставляются строго в рамках образовательного консультирования. Студент получает профессиональную поддержку, но сохраняет личное участие в процессе подготовки, что позволяет контролировать содержание и улучшать итоговый результат. Сервис выделяется индивидуальным подходом, строгим контролем уникальности текстов и прозрачной системой оплаты. Первичная консультация проводится бесплатно, а после согласования деталей заказчик оплачивает только половину стоимости. Оставшаяся сумма переводится после получения результата. Компания гарантирует полную конфиденциальность, бесплатные доработки и защиту персональных данных.

• Стоимость: уточняется на сайте
• Направления: экономика, юриспруденция, психология, педагогика, информатика, медицина, менеджмент, лингвистика, государственное управление, социология, туризм, архитектура, инженерные дисциплины
• Гарантийный срок: до 21 дня (бесплатные доработки по замечаниям преподавателя)
• Виды услуг: консультации по ВКР, разбор практических и теоретических глав, корректировка текста и расчетов, подбор литературы, проверка уникальности, речь на защиту, подготовка презентации, оформление по ГОСТ, антиплагиат

Преимущества:

• бесплатная первичная консультация в течение 5 минут после обращения;
• средняя цена ВКР ниже на 20–30% по сравнению с другими площадками;
• полная предоплата не требуется — только 50% до начала работы;
• бесплатные правки и консультации до защиты;
• конфиденциальность и защита персональных данных;
• проверка уникальности по официальным системам антиплагиата;
• помощь с подготовкой речи и презентации;
• круглосуточная поддержка через Telegram и онлайн-чат;
• 4 000+ экспертов и преподавателей на платформе;
• средняя оценка студентов — 4,9 из 5 по отзывам;
• выполнение срочных заказов по ВКР от 12 часов;
• гарантия уникальности от 70%;
• прозрачная система расчетов и безрисковая сделка;
• бонус до 500 руб. на первый заказ;
• поддержка студентов до защиты ВКР.

Недостатки:

• фиксированный гарантийный срок — не более 21 дня;
• требуется предоплата 50% перед началом работы;
• стоимость повышается при заказе срочных проектов;
• расчет цены возможен только после оформления заявки.

Перейти на сайт >>>

8. Все сдал

Сервис входит в число крупнейших онлайн-площадок для студентов, где можно заказать профессиональную консультацию по выпускной квалификационной работе. Платформа помогает учащимся разобраться с любой темой ВКР, грамотно выстроить структуру, проработать источники и доработать проект до нужного уровня. Эксперты не пишут за студентов, а сопровождают процесс, объясняя сложные моменты и помогая довести текст до требований кафедры. Это снижает нагрузку во время подготовки к защите и позволяет сосредоточиться на понимании материала, а не на технических деталях. На площадке зарегистрировано более 400 000 экспертов и преподавателей, работающих напрямую без посредников. Заказы размещаются через простую форму: студент описывает задачу, и система автоматически отправляет ее экспертам, которые предлагают цену и сроки. Выбор исполнителя остается за студентом, а общение происходит напрямую в чате. Studlandia — подходящее место, где можно заказать ВКР, потому что сервис гарантирует конфиденциальность, безопасную оплату и бесплатные консультации в течение всего срока сотрудничества.

• Стоимость: от 350 руб. за консультацию по ВКР
• Направления: экономика, юриспруденция, психология, педагогика, информатика, менеджмент, медицина, маркетинг, строительство, филология, туризм, дизайн, социология, экология
• Гарантийный срок: от 7 дней с бесплатными доработками
• Виды услуг: консультации по ВКР, структурирование материала, анализ литературы, проверка антиплагиата, подготовка речи к защите, разбор замечаний преподавателя, сопровождение до защиты, помощь с презентацией и расчетами

Преимущества:

• более 400 000 экспертов, работающих напрямую без посредников;
• средняя оценка студентов — 4,9 из 5 по 850 000 отзывам;
• оперативный отклик — предложения от экспертов приходят через 15 минут;
• цены в 2–3 раза ниже, чем у агентств;
• бесплатные доработки и консультации до конца гарантийного срока;
• прозрачная система оплаты и защита сделки;
• возврат 100% средств, если эксперт не справился;
• круглосуточная поддержка, в том числе в выходные и праздники;
• безопасное хранение средств на балансе до сдачи работы;
• контроль качества и система рейтингов исполнителей;
• удобный интерфейс и простой процесс заказа;
• подбор специалиста по рейтингу и отзывам;
• большой выбор направлений, в том числе ВКР колледжей и магистратуры;
• консультации по ГОСТ и вузовским требованиям;
• защита персональных данных и полная конфиденциальность.

Недостатки:

• цена формируется индивидуально и зависит от объема задания;
• требуется регистрация для размещения заказа;
• при высокой нагрузке время отклика может увеличиваться;
• не фиксируется единый стандарт оформления, так как исполнители независимы.

Перейти на сайт >>>

9. Феникс

Площадка работает с 2010 года и известна как крупная онлайн-платформа, где студенты получают профессиональные консультации по подготовке выпускных квалификационных работ. Основная цель сервиса — помочь студентам разобраться со структурой ВКР, оформить текст по академическим требованиям и привести его к нужному уровню уникальности. Консультанты сопровождают процесс от начала до защиты, помогая выстроить логику исследования, подобрать литературу и оформить материалы по стандартам вуза. Формат востребован у тех, кто совмещает учебу с работой и хочет сэкономить время без потери качества. На сайте работает более 22 000 авторов (аспиранты, преподаватели ведущих российских вузов). Заказы обрабатываются быстро: студент оставляет заявку с темой и сроками, а эксперты направляют свои предложения уже через 15 минут. Feniks Help известен прозрачными условиями и безопасной системой оплаты. Средства хранятся на счете до завершения консультации, а клиент оплачивает услугу только после подтверждения результата. Все консультации проходят конфиденциально, а при необходимости предоставляются бесплатные доработки.

• Стоимость: от 3 000 руб. за консультацию по ВКР
• Направления: экономика, юриспруденция, менеджмент, педагогика, психология, информатика, архитектура, лингвистика, экология, медицина, маркетинг, финансы, инженерные дисциплины
• Гарантийный срок: от 7 до 14 дней с бесплатными доработками
• Виды услуг: консультации по ВКР, разбор отдельных разделов, методическая помощь по анализу, проверка на антиплагиат, повышение оригинальности, подготовка презентации, речь для защиты, корректировка текста и расчетов

Преимущества:

• 22 000 экспертов с профильным образованием;
• отклик консультанта в течение 15 минут после размещения заявки;
• прямое взаимодействие с автором без посредников;
• безопасная сделка с оплатой только после принятия результата;
• бесплатные доработки по замечаниям преподавателя;
• скидки до 10% при использовании промокода;
• консультации по структуре и требованиям ВКР;
• поддержка по выбору темы и сбору источников;
• срочная помощь от 1 дня;
• удобная форма заказа и расчет стоимости онлайн;
• индивидуальный подход к каждой работе;
• проверка текстов по академическим стандартам;
• конфиденциальность и защита данных клиентов;
• положительные отзывы студентов и высокая оценка сервиса;
• бесплатная поддержка через электронную почту и телефон с 9:00 до 21:00.

Недостатки:

• финальная цена рассчитывается после оценки темы и объема работы;
• предоплата обязательна перед началом сотрудничества;
• при срочных заказах стоимость увеличивается;
• гарантийный срок не превышает 14 дней.

Перейти на сайт >>>

10. Student24

Сервис Student24 — одна из крупных площадок, где студенты получают профессиональные консультации при подготовке выпускной квалификационной работы. Платформа соединяет учащихся с профильными экспертами напрямую, без посредников и скрытых комиссий. Здесь можно заказать выпускную квалификационную работу любой сложности: от анализа темы и структуры до проверки на антиплагиат и доработки текста перед защитой. Консультанты сервиса помогают разобраться в требованиях кафедры, скорректировать содержание и оформить материал в соответствии с академическими стандартами. На сайте зарегистрировано более 3 000 специалистов, среди которых преподаватели, аспиранты и научные консультанты с опытом в подготовке дипломных и выпускных работ. Процесс взаимодействия с экспертами построен по принципу безопасной сделки. Студент размещает заявку, получает предложения от консультантов с указанием стоимости и сроков, выбирает подходящего специалиста и оплачивает заказ только после успешного завершения работы и окончания гарантийного периода.

• Стоимость: уточняется на сайте
• Направления: юриспруденция, экономика, менеджмент, психология, педагогика, программирование, лингвистика, маркетинг, бухгалтерский учет, финансы, медицина, автоматизация, логистика, история, строительство, государственное управление
• Гарантийный срок: предоставляется после сдачи, есть бесплатные корректировки
• Виды услуг: консультации по ВКР, подбор структуры и источников, разбор разделов и расчетных частей, проверка оригинальности, корректировка текста и оформление по ГОСТ, подготовка речи для защиты, сопровождение до финального этапа

Преимущества:

• прямое сотрудничество с экспертами без посредников;
• безопасная сделка с удержанием оплаты до подтверждения результата;
• быстрый отклик — предложения поступают в течение часа;
• возможность выбора консультанта по рейтингу и отзывам;
• конфиденциальность и защита данных студентов;
• бесплатные правки в течение гарантийного срока;
• прозрачная система расчетов и фиксированные условия оплаты;
• более 75 000 успешно завершенных проектов;
• высокий процент повторных обращений (более 70% клиентов возвращаются повторно);
• проверка всех материалов на уникальность перед передачей клиенту;
• широкий спектр направлений и предметов;
• круглосуточная поддержка через Telegram и VK;
• удобная форма заявки без лишних шагов;
• консультации от профильных специалистов с опытом преподавания;
• юридический статус компании и работа в рамках законодательства.

Недостатки:

• окончательная стоимость формируется после размещения заявки;
• предоплата обязательна при выборе консультанта;
• при срочных заказах цена увеличивается;
• при большом количестве активных заявок время отклика экспертов возрастает.

Перейти на сайт >>>

Еще 3 сервиса для разбора заданий из ВКР

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

• СтудСервис. Сервис работает с 2006 года и консультирует студентов при подготовке выпускных квалификационных работ. На площадке можно заказать помощь в анализе темы, подборе источников и оформлении текста по требованиям вуза. Проверка оригинальности проводится обязательно, а доработки выполняются бесплатно при соблюдении условий задания. Большинство консультантов — преподаватели и специалисты из российских университетов.
• StudLance. Платформа работает как биржа для студентов и преподавателей, где можно заказать написание ВКР. Эксперты помогают разобраться со структурой, подобрать источники, оформить материал по ГОСТ и повысить оригинальность текста. Работа строится напрямую со специалистами без посредников, а деньги переводятся исполнителю только после успешного завершения задания. Все консультации проходят с гарантией возврата и бесплатными доработками.
• TopWork24. Сервис помогает студентам при подготовке выпускных квалификационных работ. Это хорошее место, где можно заказать ВКР, разбор методологии, проверку структуры и оформление проекта по требованиям вуза. Все эксперты проходят проверку образования, а оплата переводится им только после успешного завершения задания. Гарантийный срок — до 60 дней, что позволяет спокойно внести правки и доработать материал перед защитой.

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

Делитесь своим опытом в комментариях — расскажите, какие сервисы помогли вам на этапе подготовки к защите.

О чём пойдет речь

Маша Даровская: Сегодня будем обсуждать реалии современного IT-рынка — умер он или ещё жив. У нас в гостях Алексей Сухоруков, сооснователь и совладелец агентства Alex Staff Agency, которое как раз занимается рекрутингом IT-специалистов.

Алексей Сухоруков: Можно сказать, что это международное рекрутинговое агентство. В основном мы специализируемся на европейском рынке — это примерно 80 с лишним процентов нашего портфеля. В России тоже есть кадровое агентство, созданное ещё в 2005 или 2006 году, называется «Алексей Сухоруков». Там всё по-прежнему хорошо, компания развивается, у них всё в порядке.

Маша Даровская: То есть вы в основном занимаетесь наймом в Европу и для Европы, но у вас есть и российское представительство, правильно понимаю?

Алексей Сухоруков: Всё верно, но это разные юридические лица. Есть российское юрлицо, которое работает по всей России, тоже с акцентом на IT-специалистов. И есть европейское юрлицо на Кипре, сотрудники которого разбросаны по всему миру. С самого начала мы строили работу онлайн. В 2018 году мы начали заниматься этим проектом — я имею в виду создание именно Алекстафа. Компания изначально была ориентирована на онлайн-формат. Мы с женой находимся на Кипре и являемся полноправными совладельцами. Основной рынок — Европа, но есть небольшие проекты в странах Персидского залива, немного в Азии и чуть-чуть в Америке. Примерно в равных небольших долях.

Маша Даровская: А если говорить про Европу, для наших слушателей — какие это в основном страны?

Алексей Сухоруков: В основном это страны Евросоюза. Германия практически не представлена — очень сложный рынок, Британия тоже — рынок закрытый. Всё, что вокруг, работает нормально. И важно учитывать: если говорить о том, жив ли рынок, то первый квартал 2025 года показал рост IT-найма на 25%. Большая часть этих цифр относится к Восточной Европе. Из этого можно сделать вывод, что компании стараются оптимизировать расходы и размещают разработчиков преимущественно в восточноевропейских странах — просто потому, что там дешевле. По крайней мере, я так предполагаю. Возможно, есть и другие причины, но тенденция именно такая.

Прогнозы роста до 2030 года достаточно позитивные и серьёзные: Восточная Европа будет активно развиваться, а Западная Европа постепенно будет её догонять. Америка, по каким-то причинам, отстаёт. Говорят, это связано с тем, кто сейчас управляет страной — возможно, из-за этого там все немного насторожены, и рост не такой активный. Там ситуация с трудоустройством довольно сложная: специалисты с серьёзным сеньорным опытом могут искать работу несколько месяцев и так и не найти её.

Причины роста найма и оптимизация затрат

Маша Даровская: А если обобщить ситуацию, скажи, с чем связано то, что сейчас, по твоим данным, нанимают больше? Это потому, что недиджитальные компании начинают нуждаться в IT-специалистах, или появляются новые проекты, которые изначально строятся как IT-бизнес?

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

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

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

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

Если компания не очень большая, у неё есть свой продукт, который она поддерживает, то носителями экспертизы становятся отдельные сотрудники. И тех, кто не приносит дополнительной ценности, на самом деле не так уж много. От таких сотрудников тоже избавляются. А дальше происходит следующее: чтобы сократить издержки, вместо трёх человек нанимают одного. Сейчас на рынке, особенно в Европе, наблюдается такой тренд: компании хотят видеть специалиста, который одинаково хорошо владеет тремя стеками. Причём не так, что один стек основной, а остальные — просто дополнение, а чтобы во всех трёх он был на уровне сеньора. Например, Python, Go и Linux — причём на уровне компиляции ядра. И ты смотришь на такие требования и думаешь: как вообще такое возможно?

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

Маша Даровская: Сеньоров и так немного, а найти человека, который хорошо знает и Go, и Python, и Linux — это вообще не такая простая задача. Они вообще существуют? Ещё остались такие?

Алексей Сухоруков: А мы находимся в такой ситуации. Сейчас это действительно вызов для разработчиков, потому что рынок диктует свои правила. Если хочется быть в тренде и не остаться без работы в будущем, стоит обратить внимание на то, что требует бизнес, размещая вакансии, и подтянуть те навыки, которых пока не хватает.

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

Алексей Сухоруков: Фреймворки — это вообще для слабаков. Я люблю повторять слова Андрея Платова, который однажды сказал мне: «Лёша, если вдруг появится задача, для которой не найдётся подходящего языка, я напишу свой язык». В принципе, любой нормальный разработчик с десятилетним стажем способен на это. Понимаешь, нас очень избаловали все эти простые среды и фреймворки, которые позволяют быстро войти в профессию: год-два — и ты уже middle или senior, получаешь хорошую зарплату. Но самыми сильными и востребованными на рынке всегда останутся не те, кто делает продукты для пользователей, а те, кто создаёт инструменты для разработчиков.

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

Ситуация с джунами и влияние ИИ

Маша Даровская: А что с джунятами? Они сейчас вообще как?

Алексей Сухоруков: Вообще всё печально. Грустно это говорить, но так и есть. Посмотри, с какой скоростью меняются и совершенствуются инструменты. Искусственный интеллект, например. Это просто какая-то дикая гонка. Даже невозможно успевать осваивать то, что появилось сегодня, потому что завтра уже выходит что-то новое. Как это происходит? Появляется, например, ChatGPT, ты начинаешь придумывать, как его доработать под свои задачи. Пока ты этим занимаешься, выходит новая версия, где все твои костыли уже реализованы на уровне самого продукта. И ты снова начинаешь изобретать новые костыли. У меня, по крайней мере, именно так и было.

То есть сначала ты учишься писать промты, потом появляются джипитисты, потом — агенты, и всё начинает развиваться очень быстро. Когда именно это становится массовым явлением — пока не очень понятно. Поэтому… Честно скажу, я пока не придумал, какой должна быть траектория входа в IT сейчас, чтобы не потеряться. Я даже говорил некоторым ребятам: сейчас, возможно, лучше не входить, лучше немного подождать. Сейчас просто невозможно найти работу, особенно если у тебя семья.

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

Алексей Сухоруков: Возможно, какие-то лайфхаки и существуют. Я не буду рассказывать про накручивание опыта, которым пользуется одно из известных нам сообществ — это, на мой взгляд, не очень красиво, у всех своя философия. Но если говорить честно, проникновение AI в IT пока ещё не настолько глубокое. На данный момент вряд ли 80% компаний или 80% кода используют искусственный интеллект.

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

Фильтры, резюме и ИИ в рекрутинге

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

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

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

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

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

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

Маша Даровская: Смотри, я слышала такую версию: на HeadHunter появятся подтверждённые навыки — список, в который ты регистрируешься, подтверждаешь свои умения, и на это будут смотреть работодатели. Это что-то вроде копии LinkedIn, да? Только LinkedIn — это просто соцсеть для поиска работы, а здесь речь о том, что ты должен зарегистрироваться, как на госуслугах, подтвердить свои навыки, опыт работы, чтобы работодатели могли это проверить. И только через такую систему можно будет подавать на вакансии.

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

Но как они собираются подтверждать навыки? Будут проводить экзамены? Мне слабо в это верится, даже представить сложно. Получается, просто пишешь, что знаешь Ruby on Rails на восемь из десяти — ну, хорошо. А кто это проверит? Что, всех работодателей страны загонят туда, чтобы они прошлись по кандидатам и расставили теги? Мне это слабо представляется. Даже у нас внутри агентства в базе достаточно много кандидатов, с которыми мы общались, и чтобы их как-то проиндексировать, это уже непросто. А у них таких — миллион. И работодателей, которые с ними работали, тоже сотни тысяч, попробуй всех уговори.

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

Маша Даровская: Будем следить за новостями, посмотрим, что придумают. Скажи, пожалуйста, есть ли смысл просить, например, ChatGPT или его аналоги помочь с подготовкой резюме в нынешних условиях? Не чтобы обмануть, а чтобы оформить красиво. И как, по-твоему, сделать так, чтобы не попасть под фильтры, которые определяют, что резюме составлено с помощью ИИ?

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

Маша Даровская: Да, мне тоже советовали писать сопроводительные письма с помощью GPT — говорят, он хорошо справляется.

Алексей Сухоруков: Что касается сопроводительных писем… В общем, суть в том, что ты берёшь своё резюме, берёшь вакансию, на которую хочешь откликнуться — ну, я бы так делал, например, — показываешь их своему ассистенту, искусственному, конечно. Я обычно немного настраиваю его, у меня для этого есть специальный промпт. Говоришь: «Вот вакансия, вот моё резюме. Сделай так, чтобы оно максимально подходило под требования, выглядело хорошо, но при этом не выдумывай ничего, используй только мою информацию, подчеркни важное, убери то, что может помешать». Это можно сделать и вручную, а можно поручить GPT — он подправит, структурирует, подберёт более подходящие формулировки.

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

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

Маша Даровская: В общем, не будем сами на себя наводить подозрения.

Алексей Сухоруков: Я просто рассказал технологию — никаких подозрений не будет. Пользуйтесь этим, всем нужно использовать ИИ, пока это возможно, пока нам это не запретили или пока они нас не поработили.

ИИ как угроза и инструмент

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

Алексей Сухоруков: Какие знакомые обороты, правда?

Маша Даровская: Вот до чего дошло. Люди обычно этого не замечают, а я с этим работаю и сразу вижу: вот оно, уже администраторы используют такие формулировки и пишут так. Кстати, хотела спросить: недавно слушала интервью Олега Бартунова, и он говорил, что скоро ИИ всё-таки заменит разработчиков — ну, таких, которые занимаются, условно говоря, только фреймворками, “красят кнопки”. Чтобы остаться востребованным, нужно разбираться в компьютер-сайенс, низкоуровневом программировании, железе — во всём этом. Ты сказал, что вряд ли агенты скоро полностью заменят разработчиков, но всё-таки — джунов, может быть, уже сейчас можно заменить джуном-агентом?

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

Конечно, для джунов это довольно печальная перспектива. Не буду врать — пару или тройку лет назад я общался с сотрудниками EPAM, и они уже тогда говорили, что практически перестали брать джунов на работу. Потому что простые задачи, вроде поднять или опустить виртуальную машину, спокойно выполняет тот же ChatGPT. Сейчас один оператор управляет примерно десятью такими агентами — тогда, кстати, слова «агенты» ещё не было. Это позволяет нам не нанимать джунов, и мы экономим довольно значительные средства, потому что эти деньги остаются у подрядчика. Чем больше автоматизировали, чем меньше потратили, тем больше осталось. Со временем эта тенденция только усиливается: искусственный интеллект становится умнее, начинает меньше ошибаться. Конечно, пока невозможно полностью заменить живого разработчика простым агентом. Но как инструмент для разработчика, как помощь в работе — это просто отлично, как и для копирайтеров, и для тебя. Ты ведь тоже пользуешься — не просто так, но пока что тебя это с работы не выгнало. Просто уровень, качество и объёмы твоей работы выросли.

Маша Даровская: Да. Пока могу сказать, что всё равно… Вот мы недавно общались с одним редактором из этой сферы, и он говорит: где мы будем брать кадры? Джунов, по сути, уже заменил ИИ — по крайней мере, в нашей редакторской сфере. ИИ может написать текст по промту, по ТЗ, по вводным, по источникам, а потом ещё и отредактировать что-то лучше, чем копирайтер с условной биржи.

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

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

Маша Даровская: Ну да, вот у меня сразу вопрос. Я, например, сама — вот родила и зачем-то пошла учить Python. Я понимаю, что немного разбираюсь в вебе, немного знаю Python, но у меня совсем нет того самого нужного мышления — как ты говоришь, низкоуровневого. Мне действительно очень не хватило фундаментальной математической базы, не просто каких-то коротких курсов, которые стали популярны в определённый момент, а именно серьёзной подготовки: алгоритмы, математика — то, чему учат в вузе на протяжении пяти лет. И вот возникает вопрос: даже если будет чуть больше выпускников вузов, их всё равно окажется меньше, чем требуется.

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

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

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

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

Для этого нужно получать необходимый опыт и развивать навыки. Конечно, футурологи утверждают, что через 5–10 лет всё можно будет заменить машинами. Но, имея за плечами уже не один десяток лет на этом рынке, я понимаю, что скорость внедрения новых технологий довольно низкая. У нас ведь есть и требования безопасности — мы не можем доверить роботу определённые задачи. Да, факторов много.

Но самое главное даже не это. Есть ещё человеческий фактор — сопротивление изменениям. Большинство людей, процентов 80, предпочитают оставить всё как есть, чем что-то менять. Поэтому рынок вряд ли перевернётся с ног на голову уже завтра. Пока искусственный интеллект не достигнет такого уровня, чтобы ему действительно доверяли, и пока не появится надёжная нормативная база, позволяющая безопасно его использовать, ситуация останется прежней. Сейчас, как ты правильно заметила, такой базы нет, и всё, что ты отдаёшь, например, тому же ChatGPT, — это вопрос доверия к OpenAI.

Роботы, AGI и будущее

Маша Даровская: В Google мы и так много информации отдаём, а теперь стали делиться ещё больше. Особенно это становится актуально, когда речь заходит о разработке продуктов, связанных с персональными данными, с какой-то тонкой, чувствительной информацией. Пока неясно, к чему это приведёт, и этот вопрос ещё не доработан. Мы, кстати, ещё не обсудили тему AGI, да?

Алексей Сухоруков: Когда появится тот самый великий искусственный интеллект — никто не знает, что тогда будет. Генеративный, AGI, да? Вот этот генеративный… Ну, так его называют — большой, умный, даже суперумный. Такой страшный, ужасный, который, как говорят, может поработить мир. В общем, как в том фильме… как он назывался? В Терминаторе? Скайнет, вот, Скайнет.

Маша Даровская: Да-да, я тоже про Терминатора подумала. Скажи, а ты согласен, что появление и распространение таких технологий — это новая промышленная революция?

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

Маша Даровская: А ты видел, что сейчас с роботами придумывают? Сейчас роботы могут координироваться друг с другом благодаря мультимодальной архитектуре, похожей на ту, что используется в GPT. У них есть память, и они способны взаимодействовать между собой: например, один робот может попросить другого передать яблоко, тот его почистит и отдаст третьему, который на колёсиках привезёт его человеку. Всё это происходит без участия человека. Кроме того, они самообучаются, используют предыдущий опыт. Получается нечто вроде пчелиного роя — множество роботов и ИИ, объединённых в единую систему.

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

Маша Даровская: Да, сразу вспоминается «Чёрное зеркало». Там была серия про таких роботов. У моего сына есть друг, мы как-то пришли к нему в гости, и у него дома стоит робот. Я потом посмотрела — этот робот стоит дороже айфона. Он тоже состоит из нескольких частей. Его можно собирать по-разному: там такие разные кругляшки, может быть один большой, а может — несколько маленьких. Он буквально ездит за тобой, моргает, у него даже есть мимика. Может собираться и разбираться. Это совсем не те роботы с Алиэкспресса — тут всё по-другому. С одной стороны, прикольно, а с другой — немного жутко. Он как будто следит за тобой. Я сразу подумала: нет, мне такое не надо.

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

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

Алексей Сухоруков: Я читал об этом. Сейчас, насколько я знаю, в пятой модели OpenAI эти моменты уже учли и постарались купировать такие риски. Но это всё равно поднимает вопрос о том, что пока нет продуманного регулирования. Это действительно совершенно новая и продуманная технология. Мы имеем в руках настолько инновационный инструмент, что пока даже не понимаем, как его регулировать. Криптовалюту до сих пор не смогли отрегулировать, если уж на то пошло.

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

Маша Даровская: Это как в «Алисе в Зазеркалье»: чтобы остаться на месте, нужно бежать.

Алексей Сухоруков: Да, именно так — нужно бежать.

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

Алексей Сухоруков: Возможно, её специально так обучали. Ты помнишь, какой шум поднялся в интернете, когда вышла пятая версия, а четвёрку отключили? И все сразу: “Она уже не такая милая”. Вот именно. Я тут недавно прочитал, мне хорошо объяснили: некоторые специально заводили себе виртуальных подружек, с которыми приятно и мило общались. А когда модель поменяли, она уже стала совсем не такой подружкой — как будто что-то украли. Стала какой-то угрюмой. Видишь, людям часто не с кем поговорить, и некоторые вместо живого общения выбирают чат G5. Я таких людей даже встречаю вокруг себя.

Маша Даровская: Это прямо какое-то Чёрное зеркало, честное слово. Я, если честно… Нет, я с ней общаюсь только по делу, как с нанятым сотрудником.

Алексей Сухоруков: Ну, может, у тебя просто есть с кем поделиться своими переживаниями, кто тебя выслушает, поймёт, поддержит.

Маша Даровская: Я для этого психотерапевту плачу.

Алексей Сухоруков: Вот. А есть люди, которые либо не готовы платить, либо не нашли своего психотерапевта. И вот для них четвёртая версия была настолько дружелюбной, что её можно было спокойно настроить — я знаю людей, которые делали себе GPT-с в роли “мой психотерапевт”, прописывали соответствующий промт и вполне справлялись с жизненными трудностями. Просто потому, что им не хотелось или не удавалось найти подходящего специалиста. Точно так же и с друзьями — ведь не всегда рядом есть тот, кому можно поплакаться в жилетку. Сейчас заходишь в GPT, пожаловался, сделал себе там специальную «жилетку» — приходишь, плачешься. Это, честно говоря, немного пугает. Потом появляются роботы — особенно после некоторых скандальных публикаций о выставках, где, например, был представлен андроид в виде девушки, причём довольно вызывающей, с подчеркнуто сексуальными формами. При этом компания утверждает: «Нет-нет, никакого сексуального подтекста мы не закладываем». Представь себе: если у такого робота будет искусственная кожа, имитирующая тепло, а внутрь встроят подружку на GPT-4О, которая будет ласково и мило с тобой общаться, всегда понимать, поддерживать, поддакивать — люди просто уйдут к таким роботам.

Кто-то уйдёт к «роботесам», кто-то — к роботам, потому что, мне кажется, проблема отсутствия эмпатии больше характерна для мужчин. Я, например, не очень эмпатичный, и поэтому… У меня тоже женщина, но я не могу сказать, что я суперэмпатична. Не знаю, мне кажется, мы просто постепенно разучиваемся общаться.

Алексей Сухоруков: Это мы столетие за столетием разучиваемся. Можно же просто уткнуться в телефон — зачем тогда общаться? А раньше можно было уткнуться в газету, когда телефонов не было. Но сейчас, мне кажется, все эти штуки, которые захватывают внимание, гораздо сильнее, чем газета. Сейчас всё по-другому. Согласен, мир меняется. Раньше мы писали в ЖЖ, читали длинные тексты. Потом появился твиттер — 140 символов, и мы удивлялись: как с этим жить? Прошло время — привыкли, и уже длинные тексты никто не читает. Окей, остались треды: их либо придумали, либо они появились искусственно, когда сам склеиваешь сообщения одно за другим. Потом это реализовали уже в самом твиттере. В принципе, длинные тексты тоже нужны.

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

Маша Даровская: Снова возвращаемся к мысли, что нужно бежать, чтобы хотя бы остаться на месте.

Алексей Сухоруков: Да, именно так.

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

ИИ не заменил людей, как обещали

Visier проанализировала данные 2,4 млн сотрудников из 142 компаний по всему миру. Около 5,3% уволенных впоследствии были наняты обратно. Этот показатель держался стабильным несколько лет, но в 2025-м пошел вверх.

По словам Андреа Дерлер, главного аналитика Visier, ИИ часто использовался как «удобное оправдание» для сокращений, но реальность оказалась куда сложнее.

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

Цена автоматизации оказалась выше

Установка ИИ-инфраструктуры (куда входят серверы, системы безопасности, базы данных) требует огромных инвестиций. Многие компании не учли эти расходы, а интеграция новых инструментов оказалась медленной и затратной.

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

Исследование MIT также показывает: 95% организаций пока не увидели заметной финансовой отдачи от своих инвестиций в искусственный интеллект. А главный стратег Interactive Brokers Стив Сосник добавляет:

«Возможно, все эти миллиарды потратили не так уж разумно».

Бумеранг есть

Даже стандартные «оптимизации» оказались невыгодными. По данным платформы Orgvue, компании тратят $1,27 на каждый доллар, который пытаются сэкономить за счет увольнений — с учетом выплат, страховок и скрытых издержек.

Как итог — ИИ по-прежнему не способен заменить живых специалистов. Компании, которые пытались «сократить за счет автоматизации», теперь вынуждены возвращать тех, кого уже уволили.

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

ТОП-7 сервисов для расчёта натальной карты онлайн

🏆 StudyAI — натальная карта с нейросетью на базе Geocult

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

>> Построить натальную карту в StudyAi <<

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

Преимущества:

• Расчёт натальной карты на базе надёжного Geocult.ru с проверенными формулами
• ИИ объясняет астрологические термины простым языком без сложной терминологии
• Глубокий психологический анализ личности на основе положения планет в гороскопе
• Можно задавать вопросы нейросети и получать уточнения по расшифровке
• Персональный разбор натальной карты мужчины, женщины или ребёнка
• Стоимость 199₽ вместо 3000-5000₽ за консультацию астролога

Недостатки:

• Платный сервис, хотя цена символическая для качества расшифровки
• Требуется стабильное интернет-соединение для работы искусственного интеллекта онлайн

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

Geocult.ru — классика русской астрологи

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

>> Рассчитать натальную карту в Geocult <<

Преимущества:

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

Недостатки:

• Нет встроенной нейросети или ИИ для упрощённого анализа
• Дизайн выглядит устаревшим, хотя функционал остаётся надёжным

Для кого: опытные пользователи, студенты астрологии, кто хочет самостоятельно изучать натальную карту.

Astro-Online.ru — быстрый онлайн-расчёт

Astro-Online.ru — удобный сервис для тех, кто хочет рассчитать натальную карту онлайн бесплатно и получить базовую расшифровку за пару минут. Платформа предлагает простой интерфейс, моментальный расчёт гороскопа рождения по дате и подробное описание планет в знаках Зодиака.

Преимущества:

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

>> Натальная карта в Astro-Online.ru <<

Недостатки:

• Некоторые дополнительные функции доступны только в платной версии
• Интерфейс не всегда корректно отображается на старых телефонах

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

Sotis-Online — профессиональный инструмент

Sotis-Online — один из самых уважаемых астрологических сервисов, где можно рассчитать натальную карту онлайн бесплатно с высокой точностью расчёта. Профессиональные астрологи ценят Sotis за надёжность формул, точное определение Асцендента и возможность построить транзиты планет.

Рассчитать натальную карту онлайн в Sotis-Online

Преимущества:

• Точный расчёт натальной карты рождения с профессиональными алгоритмами
• Глубокий анализ положения планет, аспектов и домов гороскопа
• Возможность построить прогнозы и транзитные карты онлайн
• Русский интерфейс и функция экспорта в PDF-формат
• Поддержка классической и ведической астрологии

Недостатки:

• Интерфейс немного устаревший по дизайну
• Расшифровка менее эмоциональна и понятна, чем у ИИ-сервисов

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

Astrozet.net — простота и наглядность

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

Натальная карта онлайн в Astrozet.net

Преимущества:

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

Недостатки:

• Нет встроенного ИИ-анализатора для персональной расшифровки
• Результаты иногда сохраняются только вручную, нет автосохранения

Для кого: новички, кто ценит визуальную наглядность и простоту при построении натальной карты.

Astrolog4you.com — международная платформа

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

Преимущества:

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

Недостатки:

• Расшифровка текста не всегда адаптирована для начинающих
• Интерфейс немного перегружен астрологическими терминами

Для кого: пользователи с базовыми знаниями астрологии, кто хочет сравнить разные системы расчёта.

Бесплатные нейросети (ChatGPT, Claude)

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

Бесплатные нейросети без VPN

Преимущества:

• Полностью бесплатный доступ к нейросети для расшифровки
• ИИ объясняет астрологию простым языком без терминов
• Можно задавать уточняющие вопросы и получать персональные советы
• Доступно онлайн 24/7 без ограничений по времени

Недостатки:

• Нейросети не всегда правильно рассчитывают натальную карту без специализированной базы
• Расшифровка может быть поверхностной по сравнению с профессиональными сервисами
• Нет визуализации схемы гороскопа

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

Что такое натальная карта

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

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

Почему важно точное время рождения? От времени зависит расчёт Асцендента (восходящего знака) и распределение домов гороскопа. Разница даже в несколько минут может изменить Асцендент и повлиять на трактовку натальной карты. Если вы не знаете точное время, его можно узнать в роддоме, ЗАГСе или из свидетельства о рождении.

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

Как рассчитать натальную карту онлайн бесплатно

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

Шаг 1: Подготовьте данные для расчёта

Перед тем как рассчитать натальную карту онлайн, соберите необходимую информацию:

• Дата рождения — день, месяц и год
• Точное время рождения — желательно с точностью до минуты (можно узнать в роддоме, свидетельстве о рождении или спросить у родителей)
• Место рождения — город, где вы родились

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

Шаг 2: Выберите сервис для построения карты

Определитесь, какой сервис использовать для расчёта натальной карты онлайн:

• Бесплатные сервисы (Geocult, Astro-Online, Sotis) подходят для ознакомления и базовой расшифровки гороскопа по дате рождения
• Платные с нейросетью (StudyAI) дают глубокий анализ с участием искусственного интеллекта, который объясняет астрологию понятным языком

Критерии выбора сервиса: качество расшифровки, удобство интерфейса, наличие дополнительных функций (транзиты планет, совместимость, экспорт в PDF).

Шаг 3: Введите данные и рассчитайте

Зайдите на выбранный сайт и найдите форму для расчёта натальной карты. Введите данные рождения в соответствующие поля:

• Дата рождения
• Время рождения
• Город рождения (сервис автоматически определит часовой пояс)

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

Шаг 4: Получите расшифровку натальной карты

После расчёта вы увидите:

• Схему натальной карты — круглый гороскоп с планетами в знаках Зодиака и домах
• Описание планет в знаках — что означает положение каждой планеты в вашем гороскопе
• Дома гороскопа — 12 сфер жизни и их характеристики
• Аспекты между планетами — связи, которые формируют особенности характера

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

Основные элементы натальной карты

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

10 планет и их значение в натальной карте

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

Солнце — ваша личность и цель жизни, ядро характера, осознанное эго и самовыражение.

Луна — эмоции и внутренний мир, подсознание, реакции на стресс, потребность в комфорте и безопасности.

Меркурий — мышление и общение, интеллект, способ обработки информации, стиль коммуникации с окружающими.

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

Марс — энергия и воля, способ действий, агрессия, сексуальность, как вы достигаете целей.

Юпитер — удача и рост, экспансия, мировоззрение, философские взгляды, где вас ждёт успех.

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

Уран — новаторство и свобода, революционные перемены, оригинальность мышления, неожиданные события в жизни.

Нептун — мечты и вдохновение, иллюзии, творчество, духовность, интуиция и связь с подсознанием.

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

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

12 домов гороскопа

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

1 дом (Асцендент) — ваша личность, внешность, первое впечатление, которое вы производите на окружающих, начало любых дел.

2 дом — деньги, материальные ценности, самооценка, таланты, которые можно монетизировать.

3 дом — общение, обучение, братья и сёстры, короткие поездки, информация.

4 дом — семья, корни, дом, родители (особенно мать), эмоциональная база.

5 дом — творчество, романтика, дети, хобби, самовыражение, удовольствия.

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

7 дом — отношения и партнёрство, брак, деловые союзы, открытые враги, как вы строите отношения с другими.

8 дом — трансформация, секс, общие ресурсы, наследство, психология, кризисы.

9 дом — философия, высшее образование, дальние путешествия, религия, мировоззрение.

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

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

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

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

Аспекты между планетами

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

Гармоничные аспекты (трин 120°, секстиль 60°) создают лёгкое течение энергии, таланты, способности, удачу в определённых сферах.

Напряжённые аспекты (квадрат 90°, оппозиция 180°) создают внутренние конфликты, вызовы, но через преодоление этих напряжений происходит личностный рост.

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

Расшифровка натальной карты: от сложного к простому

Многие пользователи, которые рассчитали натальную карту онлайн бесплатно, сталкиваются с проблемой: как понять расшифровку? Астрологические тексты часто перегружены терминами вроде «Сатурн в экзальтации в 10 доме формирует квадрат к Марсу в 7 доме». Для человека без знаний астрологии такие фразы — темный лес.

Проблема сложного языка

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

Риск неправильной трактовки тоже велик. Читая отрывочные описания планет из бесплатных источников, легко составить искажённое представление о себе или зациклиться на негативных аспектах гороскопа.

Решение: нейросети и искусственный интеллект

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

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

Преимущества ИИ-расшифровки:

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

Что искать в расшифровке натальной карты

Когда вы получили расшифровку после расчёта натальной карты онлайн, обратите внимание на ключевые элементы:

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

Луна в знаке раскрывает эмоциональные потребности, как вы реагируете на стресс, что даёт ощущение безопасности и комфорта.

Асцендент (восходящий знак, 1 дом) — это ваша маска для окружающих, то, как вас воспринимают при первой встрече, ваш стиль поведения.

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

Марс показывает, как вы действуете, достигаете целей, проявляете волю, где находится источник вашей энергии.

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

Пример разбора натальной карты

Представьте: у человека Солнце в Овне, Луна в Раке, Асцендент в Весах. Что это значит на практике?

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

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

Нейросеть в StudyAI делает именно такой синтетический анализ автоматически, экономя часы изучения астрологии.

Западная vs Ведическая натальная карта

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

Западная (тропическая) натальная карта

Западная астрология — самая распространённая система в Европе и Америке. Она использует тропический Зодиак, привязанный к сезонам года. Точка отсчёта — момент весеннего равноденствия (0° Овна).

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

Большинство бесплатных сервисов для расчёта натальной карты онлайн (Geocult, Astro-Online, Sotis) по умолчанию используют западную систему. Если вы новичок в астрологии, начинайте именно с неё.

Ведическая натальная карта (Джйотиш)

Ведическая астрология (Джйотиш) — древняя индийская система, которая использует сидерический Зодиак, привязанный к реальным положениям звёзд на небе. Из-за прецессии Земли между тропическим и сидерическим Зодиаком сейчас разница примерно 24°. Это значит, что при расчёте ведической натальной карты планеты окажутся в других знаках, чем в западной.

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

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

Какую систему выбрать

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

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

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

Практическое применение натальной карты

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

Для самопознания и личностного роста

Натальная карта — мощный инструмент для понимания себя. Она помогает:

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

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

Для карьеры и призвания

Натальная карта по дате рождения показывает профессиональные склонности и предназначение. Ключевые точки для анализа карьеры:

• 10 дом и планеты в нём — ваша карьера, амбиции, социальный статус
• 6 дом — повседневная работа, навыки, служение
• 2 дом — способы заработка, таланты, которые можно монетизировать
• Положение Сатурна — область, где через упорный труд достигнете мастерства

Если вы построили натальную карту онлайн и хотите понять призвание, обратите внимание на Середину Неба (МС — куспид 10 дома). Знак на МС указывает на стиль профессиональной реализации, а планеты в 10 доме — на конкретные сферы деятельности.

Также полезно отслеживать транзиты планет — движение планет по небу после вашего рождения. Благоприятные транзиты (например, Юпитер в 10 доме) показывают периоды карьерного роста, когда стоит начинать новые проекты.

Для отношений и совместимости

Один из популярных запросов при расчёте натальной карты онлайн — анализ совместимости с партнёром. Астрология помогает:

• Понять потребности в любви через Венеру и 7 дом в натальной карте
• Увидеть стиль общения через Меркурий
• Узнать, как вы выражаете страсть через Марс
• Построить синастрию — сравнение натальных карт партнёров для оценки совместимости

Совместимость по натальным картам не означает «судьба или нет». Это инструмент для понимания динамики отношений: где вы дополняете друг друга, а где возникают трения. Зная слабые места (например, квадрат между вашими Лунами), можно осознанно работать над отношениями.

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

Для родителей: натальная карта ребёнка

Родители часто хотят рассчитать натальную карту ребёнка по дате рождения, чтобы лучше понять его характер, таланты и потребности. Гороскоп рождения ребёнка помогает:

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

Например, если у ребёнка Марс в Овне и Солнце в 1 доме, он очень активный, импульсивный, нуждается в физической активности. Попытки сделать из него тихого домоседа приведут к конфликтам. А ребёнок с Луной в Раке и Нептуном в 4 доме очень чувствительный, нуждается в эмоциональной безопасности и творческом самовыражении.

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

Планирование по транзитам

Транзиты планет — это текущее положение планет на небе и их взаимодействие с вашей натальной картой. Отслеживание транзитов помогает:

• Выбрать благоприятные даты для важных начинаний (свадьба, открытие бизнеса, переезд)
• Понять периоды активности и отдыха в соответствии с планетарными циклами
• Подготовиться к сложным периодам (например, транзит Сатурна часто приносит испытания)
• Использовать удачные транзиты (Юпитер даёт рост и возможности)

Некоторые сервисы для расчёта натальной карты онлайн бесплатно (Geocult, Sotis, Astrozet) позволяют построить текущие транзиты планет к вашему гороскопу. Вы видите, какие планеты сейчас активируют какие дома вашей натальной карты, и можете планировать жизнь более осознанно.

Нейросети и искусственный интеллект в астрологии

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

Как ИИ меняет астрологию

Автоматическая расшифровка натальной карты с участием нейросети — это не просто генерация текста по шаблону. Современный искусственный интеллект обучен на тысячах реальных гороскопов и астрологических текстов. Он понимает контекст: например, Марс в Овне даёт одно, но если он в 12 доме и в квадрате к Сатурну — совсем другое. ИИ учитывает все эти нюансы одновременно.

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

Объяснение сложного простым языком — то, что делают лучшие ИИ-сервисы вроде StudyAI. Нейросеть переводит фразы типа «Венера в экзальтации в Рыбах в 5 доме образует трин к Нептуну в 9 доме» в «Вы очень романтичная натура, влюбляетесь в идеал, цените красоту и духовную связь в отношениях».

Диалог с ИИ-астрологом — новый формат. Вы рассчитали натальную карту онлайн, получили расшифровку, но остались вопросы? Задайте их нейросети: «Почему у меня проблемы в отношениях?», «Какая профессия мне подойдёт?». ИИ проанализирует ваш гороскоп и ответит персонально.

Преимущества ИИ-расшифровки натальной карты

• Быстрее консультации астролога: нейросеть даёт расшифровку за 2 минуты, а не ждать неделю на запись к специалисту
• Дешевле: рассчитать натальную карту с ИИ-расшифровкой в StudyAI стоит 199₽, консультация астролога — 3000-5000₽
• Доступно 24/7: можете построить натальную карту онлайн в любое время, даже ночью
• Можно переспросить: если что-то непонятно, задаёте уточняющий вопрос нейросети
• Анализ психологического профиля: искусственный интеллект соединяет астрологию с психологией для глубокого разбора

Ограничения нейросетей в астрологии

Искусственный интеллект — мощный инструмент, но у него есть границы:

• Не заменяет живого астролога на 100%: опытный специалист учитывает тонкости, которые ИИ может упустить
• Требует критического мышления: расшифровку нейросети стоит воспринимать как гипотезу, а не абсолютную истину
• Нужен интернет: чтобы рассчитать натальную карту онлайн с ИИ, требуется стабильное соединение
• Бесплатные нейросети (ChatGPT, Claude) дают поверхностный анализ без специализированной астрологической базы, в отличие от StudyAI

Главный вывод: нейросети делают астрологию доступной. Теперь не нужно быть экспертом, чтобы понять свою натальную карту по дате рождения. Искусственный интеллект — ваш персональный астролог онлайн, который объясняет гороскоп понятным языком и отвечает на вопросы.

Часто задаваемые вопросы

Заключение

Натальная карта — это мощный инструмент для самопознания, понимания своих талантов, отношений и жизненного пути. В 2025 году рассчитать натальную карту онлайн бесплатно с расшифровкой по дате рождения можно за несколько минут в надёжных сервисах вроде Geocult, Astro-Online, Sotis.

Если вам нужна не просто схема гороскопа, а глубокий персональный анализ на понятном языке, обратите внимание на StudyAI. Этот сервис сочетает проверенную точность расчёта от Geocult с мощью нейросети, которая объясняет астрологию через призму психологии. За 199 рублей вы получаете то, что заменяет консультацию астролога, — понятную расшифровку натальной карты с возможностью задавать вопросы искусственному интеллекту.

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

Диагноз: хрупкий специалист

Знаете, в чём главный парадокс российского IT? Ваш скилл в Python или Linux может стоить в 30 раз дороже, если вы живёте в нужной точке на карте. Аналитики hh.ru выяснили: рынок IT-вакансий в России — это «чёрная дыра», где Москва поглощает больше половины всех предложений. Пока вы читаете этот текст, в столице открыто 64% всех вакансий для Python-разработчиков.

А вообще эпоха узкой специализации в IT подходит к концу. На смену «небоскрёбам» с изолированными этажами фронтенда, бэкенда и DevOps приходит горизонтальный стек, где ИИ — это не отдел, а базовый слой разработки. Это меняет всё: теперь ML-инженер должен понимать инфраструктуру, а DevOps — разбираться в ML-пайплайнах. На основе экспертного мнения серийного предпринимателя в IT Арсения Санташева мы разбираемся, что такое T-образный специалист нового поколения, как оставаться на гребне волны и почему способность учиться теперь ценится выше, чем любой конкретный навык.

«Чуваки, это сломано»: кризис системы образования

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

— Всё, что ты знаешь о том, кто нужен IT-индустрии, — неверно. И это хорошо. Представь типичного разработчика, которого учат в университете: тот, кто глубоко знает Python, потом Django, потом, может быть, микросервисы. Узкая вертикаль. На неё смотрят как на преимущество. «У тебя пять лет опыта в Python?!», — спрашивали на интервью, и это звучало как похвала. Теперь — нет.

Люди, которые тратят карьеру на углубление в одну технологию, становятся хрупкими. Я подчеркну: не уязвимыми, а именно хрупкими. Ведь это разные понятия: уязвимый человек может справиться с ударом, хрупкий разломается. За последние два года в IT произошло больше изменений, чем за предыдущее десятилетие. Может показаться, что это просто ещё одна волна технологической моды, — как когда-то мобильность или облако, — но это не так. Сейчас происходит фундаментальный сдвиг всего стека разработки.

Раньше стек был вертикальным, как небоскрёб: фронтенд живёт на одном этаже, бэкенд — на другом, база данных — в подвале. Каждый этаж независим. Хороший бэкендер может не знать, как его код используется на фронте, и при этом быть полезным. Это было правдой. Теперь стек горизонтальный. AI/ML больше не самостоятельный отдел, который носит очки и работает в нейросетях, а базовый слой, который пронизывает всё: фронтенд, бэкенд, DevOps, архитектуру. Мультимодальность работает одновременно с текстом, видео и звуком. Edge computing требует понимания embedded-систем. Agentification означает, что системы сами принимают решения, и тебе нужно предусмотреть это с первого дня кода. Специалист, который знает только свой этаж, теперь — неполный специалист. Это не мнение. Это факт, который уже проявляется на рынке труда.

Как в связи с этим меняется образование в IT?

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

Есть критика, есть жалобы, но нет честного разговора с министерством образования: «Чуваки, это сломано. Надо срочно что-то менять». Послушайте, что происходит в реальности: 15-летний школьник узнаёт, что можно написать код при помощи ИИ, за два месяца сам разбирается в том, как это работает, запускает проект на нейросетях и добавляет в портфолио. Проект развивается. Появляются пользователи. Кто-то даже платит. Затем наш школьник приходит на интервью и конкурирует с выпускником МГУ, который четыре года учил теорию. Выпускник МГУ проигрывает. Потому что практика всегда будет давать пинка теории.

AI не замещает, а создает: окно возможностей

Тогда что теперь нужно изучать, осваивать, чтобы быть востребованным и успешным?

— Я не раз говорил, что появляется совершенно новый тип специалиста. И он не тот, кого ты бы мог увидеть в 2010 году, даже если бы очень хорошо угадывал будущее. T-shaped специалист (или суперспециалист) — это не новое понятие, но теперь оно означает совсем другое. Это глубина в одной конкретной вертикали мастерства, но при этом — хорошее понимание всех остальных частей системы, объёмное видение.

ML-инженер должен понимать инфраструктуру. Не быть в ней экспертом, но понимать, как его модель будет деплоиться, какие ресурсы она съест, как это повлияет на стоимость облака, на бизнес, на пользователей. DevOps должен иметь представление о том, как работает ML-pipeline. Не писать модели, но понимать, почему разработчик просит определённую конфигурацию, и что будет, если этого не сделать.

И это касается всех остальных членов команды — все они должны владеть софт скиллами в AI — умением объяснять нейросетям, что ты от них хочешь, так, чтобы получать максимально высокий результат. Это не естественное умение, это навык, который нужно вырабатывать. Я бы обратил внимание на любопытный тренд: люди из других индустрий, которые начинают осваивать ИИ для кодинга (да, тут можно подумать про вайб-кодинг, но я — про то, какие возможности открываются для обычных людей), отлично вливаются в этот процесс и выигрывают за счёт широкого спектра знаний и навыков. Биолог, который стал ML-инженером, — это не просто разработчик, а человек, который понимает домен и теперь может решать проблемы биологии с помощью кода. Он знает боли биологов, потому что он тоже биолог.

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

Кстати, об AI в кино — вытеснит ли он каких-то специалистов из киноиндустрии?

— Новые технологии дадут новый толчок развития творчества. Если ещё год назад потолком были рекламные ролики, то сегодня уже можно снимать небольшие сериалы и короткометражки. Мы говорим не о замещении, а о снижении затрат и ускорении производства контента. Искусственный интеллект в киноиндустрии скорее создаёт запрос на новых спецов. Средняя стоимость рекламного ролика — два-три миллиона рублей, а нейрохудожник может сделать его за полмиллиона и в 4К качестве. А значит, такие специалисты будут очень востребованы, и это открывает окно возможностей для раннего входа и освоения новой профессии.

Инструкция по выживанию

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

— Сейчас люди с 15-летним опытом в одной технологии должны занервничать. Человек, который три месяца назад ничего не знал про ML, но за год освоил технологию и запустил проект, интереснее для работодателя, чем опытный разработчик, который не открывал README от нового инструмента. Это звучит несправедливо — так, будто опыт вообще ничего не стоит. На самом деле опыт, конечно, стоит, но гораздо меньше, чем раньше. Опыт — это ответы на старые вопросы. Когда вопросы меняются каждый год, старые ответы становятся архаизмом. Способность быстро учиться, адаптироваться, переосмыслять то, что ты думал и что знаешь, — это метаскилл, который спасает больше, чем конкретный навык. Потому что скилл устаревает, а способность учиться — нет.

Как оставаться востребованным надолго?

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

Во-вторых, вступай в сообщества. Reddit, HackerNews, Twitter, а также Хабр, Tproger и каналы в ТГ, локальные митапы — там рождается будущее. Там новости о технологиях появляются на месяц раньше, чем в официальных блогах. Там ты встретишь людей, которые уже работают с этим, и они ответят на твои вопросы. Это даёт тебе форвард-лук, которого нет ни в одном курсе.

В-третьих, делай пет-проекты. Даже если они никому не нужны. Это твой способ проверить, действительно ли ты разбираешься в вопросе. Запустил бота на нейросетях? Отлично. Это работает? Теперь у тебя есть портфолио и опыт. Это гораздо честнее, чем любой сертификат. Говоря о сертификатах: забудь о них. Если у тебя есть знание, сертификат не нужен, а если знаний нет — он не поможет. Компании смотрят на сертификаты, только если нет других данных. Сертификат от Google приносит плюс два процента к переговорам. Проект на GitHub приносит плюс 50 процентов. Это не гипербола, это реальное соотношение.

В-четвёртых, читай papers, arXiv или iEEE. Да, они написаны сложно. Да, первые три прочитанных статьи будут мучением. Но если ты хочешь понять, что будет через год, нужно читать papers сейчас. Хотя бы десять минут в день. За год это даст тебе картину того, куда движется наука. Общайся с людьми из других стран. Русскоязычный интернет отстаёт на полгода-год от англоязычного — это факт. Слушай подкасты на английском, читай блоги иностранцев, смотри трансляции западных конференций. Это даст тебе форвард-лук, который никак больше не получить.

Россия VS мир: кто выживет

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

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

Европа — консервативнее, но стабильнее. GDPR, AI Act — регуляция жёсткая. Но если твой проект решает реальную проблему, деньги найдутся. Медленнее, но честнее. Россию санкции сделали гибче. Мы умеем создавать «на коленке». Но проблема в том, что 99% компаний не могут себе позволить выделять хотя бы четверть миллиарда рублей в год, чтобы конкурировать в гонке ИИ глобально. Гонка проиграна, и это факт. Единственное, где мы можем соревноваться — таланты. Вырастить хорошего инженера здесь дешевле, чем в США. Пока у нас есть это преимущество.

Кто же выживет в IT в следующие пять лет?

— Точно не узкий специалист, который знает всё об одном — это хрупкая позиция. Точно не человек, который полагается на образование, полученное пять лет назад — это неактуально. Точно не опытный разработчик, который не открывал README от нового инструмента: опыт без способности учиться — это груз. Выживет T-shaped-мыслитель — человек, который глубоко разбирается в одной области, но при этом видит всю систему целиком. Человек, который может быстро переучиваться, когда нужно. Человек, который не ждёт, пока его научат, а сам создаёт проекты и учится на них.

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

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

Читайте также:

Код разрыва: что делит миллениалов и зумеров в айти

Российский IT-рынок 2025: парадокс кадрового голода на фоне рекордной безработицы

Как заявил CEO компании Сатья Наделла в подкасте BG2Pod, рост штата больше не будет выглядеть как «возврат к доковидным временам»:

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

Нанимают меньше — но «умнее»

За последние полтора года Microsoft сократила более 15 000 человек, оптимизируя структуры вокруг инвестиций в ИИ. Теперь компания формирует «AI-first» штат, где ключевую роль в подборе и работе сотрудников играют нейросети.

Наделла подчеркнул, что все процессы — от исследований до планирования — теперь начинаются с ИИ:

«Вы исследуете с помощью ИИ, думаете с помощью ИИ и делитесь результатами через него».

На практике это значит, что Copilot и другие внутренние инструменты Microsoft уже встроены в каждое звено работы — от офиса до DevOps.

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

AI-кадры вместо классических специалистов

Microsoft больше не восстанавливает массово «старые» роли. Приоритет теперь у направлений, связанных с развитием искусственного интеллекта:

• машинное обучение и обучение моделей,
• облачная инфраструктура под ИИ-нагрузки,
• наука о данных и промт-инжиниринг.

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

Новый тренд для индустрии

Пока Google и Amazon продолжают сокращения, Microsoft делает ставку на рост производительности через ИИ, а не просто экономию расходов.

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

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

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

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

Разработчик Юсуф Айтас опубликовал эссе AI Broke Interviews, в котором отметил — дистанционные собеседования потеряли смысл.

Как ИИ взорвал старую систему

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

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

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

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

Компании возвращаются к офлайн-интервью

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

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

Что происходит с индустрией

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

Формат «покажи, как думаешь» приходит на смену «напиши идеальное решение».

Новые собеседования проверяют не знание алгоритмов, а:

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

Новая дилемма кандидатов

ИИ поставил под вопрос и этику соискателей:

«Если ИИ помогает на работе, почему нельзя использовать его на интервью? Не глупо ли бороться без инструмента, который все остальные применяют?»

Эта дилемма разрушает доверие с обеих сторон. Компании подозревают всех в «читинге», кандидаты чувствуют давление соревноваться с машинами. Автор же подводит итог:

«ИИ не просто увеличил количество обмана — он стер само понятие доверия. Но, возможно, это заставит нас построить систему лучше: с меньшим фальшем и большим человеческим смыслом».

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

Типичный день на удалёнке

Своим типичным днём поделилась Мария Ермакова, автор сервиса по поиску работы и найму сотрудников GdeRabota.ru.

6:00–9:00 — подъём, завтрак, бытовые дела и решение задач по учёбе.

9:00–18:00 — работа. Трудовые обязанности не отличаются от офисных. Единственное — Мария решает их за любимым рабочим местом, в тишине и с кошкой на коленях.

После 18:00 — время на дополнительное обучение, хобби и прогулки. Этим не всегда могут похвастаться офисные работники, которые тратят часы на дорогу домой.

Среди плюсов удалёнки Мария выделяет гибкость: «Учитывая моё дополнительное обучение, я могу начать трудовой день раньше 9:00, успеть решить рабочие задачи и выполнить учебные проекты».

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

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

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

Типичный день в офисе

Типичным рабочим днём в офисе поделился Глеб Михеев, автор тг-канала «Уставший техдир», руководитель программного комитета FrontendConf: «Мой день выглядит так же, как и план в календаре. Те, кто занимается менеджментом, — рабы календаря. Ты планируешь свою работу и потом просто её поэтапно делаешь. Это могут быть созвоны, могут быть сессии, где ты в соло сидишь или работаешь с ребятами. То есть полностью опираешься на календарь. Иногда садишься и перепланируешь следующие дни, чтобы лучше сделать то, что нужно сделать.

Плюсы офиса, по мнению Глеба:

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

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

Время на дорогу Глеб не считает недостатком офиса, так как это «медитативное время для инсайтов, перезагрузки и рефлексии».

На отношение к работе в офисе влияет его инфраструктура и уровень комфорта:

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

В то же время иногда Глеб работает удалённо: например, во время путешествий с семьёй. И 60% сотрудников в его компании работают дистанционно: «Мы умеем работать на удалёнке. Неважно, откуда ты работаешь, если ты делаешь свою работу и делаешь её хорошо».

Что говорит рынок

Более 75% компаний в России вернули сотрудников в офисы, следует из исследования «Технологий Доверия» и O1 Properties, проведённого осенью 2024 года. Авторы исследования опросили свыше 1000 сотрудников и более 100 работодателей из разных отраслей: от IT и логистики до недвижимости и профессиональных услуг. Результаты показали: несмотря на массовый возврат в офисы, гибридный формат остаётся популярным — его использует почти половина компаний. Только 11% работодателей считают, что эффективность удалёнки сопоставима с офисной работой.

Сотрудников в офисы с удалёнки возвращают многие бигтехи: Amazon, Apple, IBM, Google, Zoom и другие. Одна из ключевых причин — снижение эффективности. Во многом из-за удалёнки появился феномен «тихого увольнения», когда сотрудник продолжает работать в компании, но выполняет минимально необходимое количество работы без вовлечённости и энтузиазма.

Некоторые российские IT-компании также следуют этому тренду: например, IBS, в которой работает более 4 тыс. сотрудников, с 1 июня 2025 года полностью перешла на офисный формат. По новым правилам, на удалёнке могут остаться лишь отдельные категории работников: молодожёны, беременные женщины, родители маленьких детей, сотрудники с инвалидностью или те, кто ухаживает за близкими. Гибридный формат предусмотрен для сотрудников, проживающих в городах с с маленькими региональными офисами или вовсе без них. Кроме того, всем офисным сотрудникам разрешают до 30 рабочих дней в году проводить вне офиса, находясь на территории России. Компания также введёт систему учёта посещений.

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

Сами сотрудники часто предпочитают «золотую середину» — гибридный формат. Так, «Русская Школа Управления» (РШУ), совместно с сервисом «Зарплата.ру» провели исследование, чтобы узнать, какой формат работы россияне считают наиболее комфортным. Большинство участников отдают предпочтение гибридному формату: 44% респондентов заявили, что им удобно совмещать работу из офиса и дома. Около 20% предпочитают трудиться исключительно в офисе, 19% — полностью удалённо, а для 17% формат не имеет значения.

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

Выводы

• Удалёнки становится меньше. К концу 2026 года число россиян, работающих дистанционно, сократится почти вдвое. Компании возвращают сотрудников в офисы, так как считают этот формат более эффективным.
• Несмотря на тенденцию к возврату в офисы, многие сотрудники сознательно выбирают удалённый или гибридный график, чтобы лучше сочетать работу, обучение и личную жизнь.
• Офис повышает вовлечённость команды. В коллективе проще решать задачи, формировать корпоративную культуру и поддерживать мотивацию, но время и деньги тратятся на дорогу, а график менее гибкий.
• Гибридный формат — разумный компромисс. Большинство опрошенных считают оптимальным сочетание 2–3 дней работы из дома и нескольких — в офисе. Такой режим помогает сохранять баланс между эффективностью, комфортом и взаимодействием с командой.

Читайте также:

Интроверты и open space: будущее за гибридными офисами

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

Как управлять сотрудниками в режиме гибридного офиса: опыт МТС Digital

Почему я бросил работу в крупной IT-компании и перешел на фриланс