Райан Даль, создатель Node.js, одной из ключевых технологий современного веба: времена, когда код писали люди, всё.
Даль сформулировал свою позицию в посте в X: «Это говорили уже тысячу раз, но я тоже вставлю слово: времена, когда код писали люди, закончилась. Это тревожно для тех из нас, кто называет себя инженерами ПО, но от этого не менее верно. Это не значит, что у инженеров больше не будет работы, но про написание синтаксиса напрямую она больше не будет».
Скрытые уязвимости в CI/CD: что мы упускаем и как защитить процесс доставки
CI/CD давно перестал быть просто удобным способом ускорить релизы. Сегодня это критическая часть цепочки поставки, через которую проходит весь код, зависимости и инфраструктурные изменения. Именно поэтому пайплайн всё чаще становится целью атак, при этом многие уязвимости остаются незаметными годами.
Одна из самых недооценённых проблем — избыточные права. Токены доступа, используемые в пайплайнах, часто имеют больше разрешений, чем требуется для конкретного шага. Компрометация такого токена даёт атакующему доступ не только к репозиторию, но и к облачной инфраструктуре, артефактам и секретам.
Вторая зона риска — зависимости и сторонние экшены. Автоматизация строится на готовых шагах и шаблонах, которые редко проходят полноценный аудит. Обновление популярного экшена или контейнерного образа может незаметно внести вредоносный код в процесс сборки, и он будет исполняться с доверенными правами.
Отдельного внимания заслуживает хранение секретов. Даже при использовании секретных хранилищ они нередко утекaют в логи, артефакты или кэши. Проблема усугубляется тем, что логи CI часто доступны большему кругу людей, чем production-системы.
Неочевидная, но опасная категория уязвимостей — доверие к окружению сборки. Самохостинг раннеров без изоляции, повторное использование виртуальных машин и отсутствие очистки после джобов позволяют атакующему закрепиться в системе и влиять на последующие сборки.
Защита CI/CD начинается с принципа минимальных привилегий. Каждый токен, сервисный аккаунт и ключ должен иметь строго ограниченный набор прав и короткий срок жизни. Второй шаг — контроль цепочки зависимостей: фиксация версий, проверка хэшей, собственные зеркала и регулярный аудит используемых экшенов и образов.
Важно также относиться к пайплайну как к коду: проводить ревью изменений, логировать подозрительные действия и мониторить аномалии. Изоляция окружений, одноразовые раннеры и автоматическая ротация секретов значительно снижают потенциальный ущерб от атаки.
CI/CD — это не просто автоматизация, а часть поверхности атаки. Чем раньше это осознаётся, тем меньше шансов, что уязвимость проявится уже после успешного релиза.
А какие риски в своих пайплайнах вы обнаружили только со временем?
Не пользуюсь LLM-агентами, если могу. Давно замечаю: просто избегаю запускать LLM прямо в проекте, потому что боюсь разучиться кодить и думать. Поход в ChatGPT себе разрешаю — это как встать с дивана, чтобы пойти в магазин, а не заказывать доставку на дом. Там нужно правильно сформулировать запрос, потому что он не может добрать контекст проекта сам. Можно перекинуться парой мыслей, как с товарищем на работе. Надо подумать, как применить ответ, что выкинуть. В итоге я всё равно как-то худо-бедно программирую сам.
Пока я отрицаю прогресс, из мира агентов доносится много шума про управление контекстом и токенами. Агенты в ответ на запросы жрут лимиты по токенам, выделенные на отрезок времени. Ну либо запросы по API просто тарифицируются. Причем чем дольше общаешься с нейросетью, тем больше контекста ей нужно держать, учитывать, корректировать, сжимать. Помимо этого, нейронка ещё подглядывает правила проекта в .md-файлах, что-то помнит между переписками.
Чем больше у нейронки пузырь вашего контекста, тем хуже она работает. Путается в постоянно пополняющихся правилах, корректировках и ограничениях. Наконец, контекстный оверхед — это еще очень дорого. Каждый запрос к API содержит тысячи «мусорных» токенов и выжирать лимиты получается еще быстрее.
В ответ на это индустрия на венчурные деньги придумывает и продвигает свои «велосипеды», чтобы с помощью агентов эффективнее и дешевле решать задачи:
В Cursor IDE есть Rules, которые накладывают ограничения поверх ваших промптов. Их можно применять вручную или автоматически; говорят, автомат работает хуже.
Anthropic пиарит Skills (еще пример Playwright Skill). Это интерфейс для решения типовых задач с адаптивными ступенями контекста в зависимости от сложности.
Есть MCP (Model Context Protocol) — условное API, которое расширяет возможности агентов, чтобы они не писали собственные инструменты и не тратили контекст и токены на типовые задачи: открыть браузер, прочитать Jira, отправить письмо и т. д.
Также есть субагенты; их оркестрирует агент-оркестратор. У субагентов чистый контекст: они получают задачу, выполняют её и идут на «свалку».
И вот среди этого новояза я – старпер со своим ChatGPT: после 2–3 запросов удаляю чат и начинаю новый. Вот моя экономика токенов и галлюцинаций. Меня и Альтмана маркетингом не проведешь!
Не лайфхаки, а системный подход
К кому идти за ростом — техлиду, delivery или HR? Системный аналитик в статье «Как я перестала искать карьеру и начала видеть систему: системные законы как компас в хаосе матричной структуры» применяет теорию систем к карьере.
Эта статья — не про лайфхаки. Она про то, как я начала видеть организацию как живую систему, как поняла, что карьера — это не лестница, а путь через слои системы. И как, применяя законы системной динамики, теории систем и элементы бизнес-расстановок, я нашла свою точку опоры.
В статье о том, как использовать законы системного мышления как инструмент для карьерного планирования и построения эффективных команд.
Отраслевое исследование QA: автоматизация, AI и метрики — сбор данных
Команда Test IT (бренд Девелоники) запустила отраслевое исследование по состоянию QA в российских командах. Формат — открытый опрос, результаты обещают опубликовать для всех участников.
Ссылка на исследование - если работаете в QA и готовы поделиться реальной практикой (включая проблемы и ограничения). Участие в опросе займет немного времени, итоговые данные будут направлены участникам рынка и респондентам.
Не могу не поделиться своим открытием! Хотя для многих это и прозвучит как баян, но я для себя вновь открыл ценность ИИ.
Я же опять стал студентом. Спустя 20 лет. На этот раз учусь в ВШЭ. И поймал себя на странном ощущении, что правила игры теперь совсем другие.
Двадцать лет назад учеба в университете была похожа на жонглирование (а еще и покуралесить с однокурсниками надо было успеть). Стандартная лекция: слушаешь лектора, пытаешься понять и одновременно лихорадочно конспектируешь. Мысль теряется, пока записываешь. Запись теряет смысл, пока ловишь мысль. Были, конечно, уникумы, которые умудрялись успевать записывать и делать качественные конспекты. Такие конспекты ходили по рукам, переписывались и были на вес золота. Тогда это была норма, так все учились.
Вернувшись в аудиторию на Executive Master in Management, я поначалу действовал по старинке. Слушаю, записываю. Перечитываю иногда. Но что-то было не так…
Хорошо, что довольно быстро понял: я застрял в 2005-м, а мир ушел далеко вперед.
Сегодня у меня совершенно другой алгоритм.
На лекции я просто слушаю, задаю вопросы, связываю новое с опытом. На все 100% сфокусирован на понимании и осознании материала.
А все остальное делают технологии:
Структура и ключевые тезисы от преподавателя,
Аудиозапись лекции на телефон
Транскрибация в mymeet
Claude, который превращает полтора часа живой речи в аккуратный 20-страничный конспект,
Алиса Про (бывший Яндекс Нейроэксперт) сшивает все конспекты в единую базу знаний, с которой легко взаимодействовать.
Рутина практически исчезла. Я переоткрыл для себя обучение. Появилась необычайная легкость и еще большее желание учиться.
Я смотрю на сегодняшних студентов и немного завидую. Белой завистью.
Им не нужно тратить внимание на «успеть записать».
Они могут сразу строить ментальные модели, учиться быстрее и глубже. Кто-то может возразить, мол, так и писать можно разучиться. Но это отдельная тема для обсуждения.
И да, я по-прежнему за очное обучение. Все-таки сила невербальных коммуникаций никуда не делась. В новом подходе появляется много пространства для главного, для понимания. А понимание рождается не в конспекте, а в живом контакте. С преподавателем, с материалом, с собственным опытом.
А вы уже пересобрали свой способ учиться или все еще учитесь так, как будто ИИ не существует?
Тестовый фреймворк для Си.
Иногда может показаться, что для тестирования программ нужно обязательно взять монструозный фреймворк, внедрить его в свою систему сборки, а потом при каждой проверке искать, какие же assert он умеет делать.
На практике это не всегда так.
Да, мир Си — дикий запад. Но, тем лучше, всегда есть выбор.
Джон Брюер приводит превосходный пример того, каким может быть минималистичный фреймворк для тестирования. Всего пара макро и одна переменная, восхитительно!
Статья на сайте Джона Брюера: https://jera.com/techinfo/jtns/jtn002
RAG vs Fine-tuning: что выбрать для бизнес-данных
RAG даёт актуальные данные, Fine-tuning — застывшие знания
Задача: сделать Telegram-бота для сотрудников, который отвечает на вопросы по внутренним регламентам, инструкциям и политикам компании.
Первый вопрос: fine-tuning или RAG?
Fine-tuning отпал сразу
Регламенты обновляются — новая политика отпусков, изменения в ДМС, новый регламент согласований. Переобучать модель каждый раз?
Нужны точные ссылки — "это написано в п.3.2 Положения о командировках", а не "примерно так заведено"
Галлюцинации опасны — бот не должен выдумывать правила, которых нет
Конфиденциальность — отправлять внутренние документы в OpenAI для fine-tuning?
RAG решил все проблемы
Обновил документ = бот уже знает — без переобучения
Прозрачность — бот показывает источник: "согласно Положению о ДМС, раздел 4..."
Данные внутри периметра — эмбеддинги можно считать локально
Контроль — легко добавить/удалить документы из базы знаний
Типичные вопросы к боту
"Сколько дней отпуска у меня по ТК?"
→ Ответ + ссылка на Положение об отпусках
"Как согласовать командировку?"
→ Пошаговая инструкция + ссылка на регламент
"Что покрывает ДМС?"
→ Перечень услуг + ссылка на договор
Когда что выбирать
КритерийRAGFine-tuningДокументы обновляются✅❌Нужны ссылки на источник✅❌Конфиденциальные данные✅⚠️Специфичный тон ответов➖✅Быстрый MVP➖✅
Мой вывод
Для корпоративной базы знаний — однозначно RAG.
Fine-tuning оправдан, если:
База знаний статична (редко меняется)
Не нужны ссылки на источники
Важен уникальный стиль общения бота
А как вы решаете задачу корпоративного бота? RAG, fine-tuning, или готовые решения типа Notion AI?
Представлен проект нейросети для звуковой генерации HeartMuLa, которая умеет создавать треки студийного качества, клонировать голоса и вставлять их в песни, умеет также делать транскрибции треков через Whisper.
Репозиторий проекта, ссылка на Hugging Face и на портал ModelScope
А так ли надежен AI от Google?
Я публично веду исследование и собираю статистику причин провалов игровых проектов. Часто, как первичную точку для анализа того или иного игрового проекта я использую Google.
Однако, сегодня google меня немного удивил. На мой запрос: "What were the key issues with civilization vii game at the release"? Вот что сегодня, 20.01.2026 выдал Google:
AI Overview
Sid Meier's Civilization VII is scheduled for release on February 11, 2025 [1, 2]. As of today, January 20, 2026, the game has not been released, and therefore, it is impossible to identify key issues from its actual launch.
Однако, скорректировав запрос с уточнением "What were the key issues with civilization vii game at the release in 2025", я уже получил более разумный ответ:
AI Overview
Sid Meier's Civilization VII faced a rocky, "mixed" reception upon its February 2025 release, with many players describing it as unfinished and in a "rough" state. The launch was marked by complaints regarding fundamental gameplay changes, a poor user interface (UI), and missing quality-of-life features that left many long-term fans disappointed.
Обратил внимание, что часто от ИИ ожидают больше, чем он сейчас может дать. Тем более не стоит считать информацию формируемую генеративным AI полностью достоверной и не подлежащей проверке. Проводите кроссвалидацию с первоисточниками того, что вы получаете от генеративных нейросетей в форме утверждений.
Ранее я разбирал риски присущие ИИ в статье "Риски, присущие работе искусственного интеллекта".
Удачи в построении эффективных и устойчивых процессов.
С уважением,
Максим Торнов
P.S. Если вы заметили опечатку или неточность, буду искренне благодарен за сообщение об этом в личные сообщения.
Исследователи Microsoft опубликовали масштабное исследование о влиянии генеративного ИИ на рынок труда, назвав 40 профессий, наиболее подверженных автоматизации. Самыми уязвимыми оказались профессии, связанные с обработкой информации: созданием текстов, анализом данных, объяснением и передачей знаний. На вершине рейтинга — переводчики и устные интерпретаторы, писатели и авторы, историки, журналисты, политологи и специалисты по работе с клиентами. Также высокие показатели применимости ИИ зафиксированы у продавцов и сотрудников колл-центров. Только в США в этих сферах занято около 5 миллионов человек.
В исследователи подчёркивают: высокий уровень применимости ИИ не означает неизбежного исчезновения профессии. Речь идет скорее о трансформации рабочих процессов.
40 профессий, наиболее подверженных влиянию генеративного ИИ:
Переводчики;
Историки;
Бортпроводники и обслуживающий персонал;
Менеджеры по продаже услуг;
Писатели и авторы;
Специалисты службы поддержки клиентов;
Операторы станков с ЧПУ;
Телефонные операторы;
Агенты по продаже билетов и туристические клерки;
Радио- и телеведущие, диджеи;
Брокеры;
Преподаватели по управлению домашним хозяйством;
Телемаркетологи;
Консьержи;
Политологи;
Журналисты, репортеры и новостные аналитики;
Математики;
Технические писатели;
Корректоры;
Хостес;
Редакторы;
Преподаватели бизнеса;
Специалисты по связям с общественностью (PR);
Промоутеры и демонстраторы товаров;
Рекламные агенты;
Клерки по открытию новых счетов;
Ассистенты-статистики;
Сотрудники проката/аренды;
Специалисты по анализу данных (Data Scientists);
Персональные финансовые консультанты;
Архивисты;
Преподаватели экономики;
Веб-разработчики;
Бизнес-аналитики и управленческие консультанты;
Географы;
Модели;
Рыночные аналитики;
Диспетчеры экстренных служб;
Операторы коммутаторов;
Преподаватели библиотечного дела.
10 профессий, наименее подверженных влиянию генеративного ИИ
Операторы земснарядов;
Операторы шлюзов и мостов;
Операторы водоочистных сооружений;
Формовщики и изготовители литейных форм;
Операторы техники для укладки и обслуживания железнодорожных путей;
Операторы сваебойных установок;
Шлифовальщики и отделочники полов;
Санитары;
Операторы моторных лодок;
Операторы лесозаготовительной техники.
Разработчик Эван Хан спустя 13 лет практики установил все 376 параметров Vim. Его конфигурационный файл состоит из почти из 2900 строк.
AI не заменяет - AI меняет роль
Спор про скорость - ловушка. Правильный вопрос: что стало узким местом?
55% компаний, которые уволили людей из-за AI, теперь жалеют (Orgvue, 2025). Исследование METR показало странное - разработчики думают что с AI работают на 20% быстрее, а объективно на 19% медленнее (METR, июль 2025).
Хинтон говорит что скоро AI будет делать за минуты работу на месяц. CEO AWS называет отказ от найма джуниоров "одной из самых глупых вещей" (MIT Tech Review).
Кто прав? Мой опыт говорит - оба мимо. AI не заменяет и не замедляет. Он меняет распределение труда.
Что отдал AI
Почти всю черновую аналитику:
Spec drafts - первые версии спецификаций по сырым требованиям
C4 диаграммы - контейнеры, компоненты, контекст
Sequence diagrams - потоки взаимодействия
Поисковые запросы - сбор контекста из документации и кодовой базы
Тест-кейсы - acceptance criteria по спецификации
Ручное кодирование сократил до точечных мест: интерфейсы, критичные участки, отладка. Всё остальное - через агента.
Звучит как будто всё отдал. Но нет.
Что не отдам
Здоровье. Доктор может использовать AI - это хорошо. Но это должен быть доктор с образованием и опытом. AI как инструмент - да. AI вместо врача - нет.
То же с психологом и коучем. Всё что связано со здоровьем и осознанностью - только к профессионалам.
В коде аналогично: security-критичные участки, интерфейсы с внешними системами, инварианты бизнес-логики - там доля ручной работы и глубокой экспертизы остаётся выше. AI ускорил черновики и сбор вариантов, но ответственность за модель и критерии - на мне.
Про "парадокс продуктивности"
Подозреваю, что люди измеряют "ощущение скорости", а система измеряет "время до принятого PR".
Не согласен с интерпретацией METR.
Раньше: пробуешь 1-2 варианта, выбираешь, идёшь. Натыкаешься на проблемы - третья версия. Четвёртая. Legacy копится.
Сейчас: пробую кучу вариантов сразу. Да, на каждый уходит больше времени. Но я не тащу три неудачных попытки. Выбираю лучший до того как закапываю в продакшн.
Микро-кейс: фича интеграции с внешним API. Раньше - 3 дня на реализацию, потом 2 дня на переделку когда выяснились edge cases. Сейчас - 1.5 дня, но 40% времени ушло в спецификацию и тест-контракты. Переделок ноль.
Это не замедление. Это сдвиг: меньше "time-to-code", больше "time-to-confident".
Джуниоры: как меняется обучение
CEO AWS: "Как это будет работать через 10 лет, когда никто ничему не научился?"
Согласен. Передача знаний должна быть. С AI можно делать сайты без образования - но индустрия не только про сайты. Есть вещи где нужна математика и computer science.
Но джуниор теперь не "пишет CRUD". Джуниор учится:
Формулировать требования так, чтобы агент понял
Писать тест-контракты до реализации
Дебажить и верифицировать результат
Понимать, когда AI галлюцинирует
Сдвиг роли
Меньше клавиатурной работы, больше постановки, проверки и ответственности за инварианты.
Раньше - исполнитель. Теперь - проектировщик и валидатор.
Причём само проектирование тоже с AI - общаешься с агентом, раскладываешь задачу, проверяешь результат. Во многих продуктовых задачах ручное написание кода - не главное узкое место. Узкое место - постановка, проверка, интеграция, риски.
Что стало важнее
Системный подход. "Герой-разработчик" и "пожаротушитель" - уходит. Ценятся люди, которые системно решают задачи.
И новый навык: строить свою систему работы с AI.
Это мой актив. Моя интеллектуальная собственность. Я трачу время не только на задачи, но и на эту систему.
Как не потерять сервер в Minecraft из-за опасных модов
Уверен, что многие владельцы Minecraft-проектов сталкивались с игроками, которые хотели взломать сервер и выдать себе права администратора. Я понимаю, что подобное случается не только в играх, и из научного интереса изучаю, как и почему это происходит.
В этой статье мы рассмотрим CVE, найденную в моде Integrated Scripting.
Проект QArt Coder позволяет вставить лицо пользователя в QR Code. Многие точки в QR‑коде являются лишними, что означает, что их можно расположить в виде картинки, а не просто случайным образом. Короткие URL‑адреса и небольшие изображения с высокой контрастностью в этом проекте работают лучше всего.
Про The Clean Architecture.
Конечно, говоря про Clean Architecture, нельзя обойти стороной книгу Роберта Мартина “Чистая Архитектура”.
Это замечательная книга. В ней можно найти большое количество исторического контекста, с помощью которого Мартин наглядно демонстрирует необходимость введения новых абстракций.
Но не менее полезной можно считать дистиллированную версию в блоге Clean Coder. Автор заметки — тот же Роберт Мартин. Если Вы не знакомы с Clean Architecture, то статья станет хорошей отправной точкой.
Статья в блоге Clean Coder: https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
Промпт-инженер показал способ превратить ChatGPT в гения осмысленных и живых текстов. Идея простая: на Википедии есть список признаков текста, написанного нейросетями — если показать его ИИ и сказать так не делать, это просто... сработает. Итоговый структурированный промпт получился достаточно объёмным.
Про воркеры простыми словами
На работе мне понадобилось реализовать воркер. Описываю, как сам эту тему разобрал. Я не разработчик, пишу утилиты на Python для QA.
Воркер — это сервис, который ждёт событие-триггер и по нему выполняет некий коллбэк. В отличие от фоновых задач в вашем сервисе, воркер живёт в отдельном контейнере.
Пример
Сборщик мусора в БД: пройтись раз в час, например, и удалить старые записи. Или, как у меня задача на работе: обработать xlsx-файл, который передали в ручку.
Зачем
Чтобы сделать работу приложения асинхронной. Представим задачу, которую можно обработать дольше, чем за 10 секунд. Клиент на вашем сайте не будет сидеть и смотреть в экран эти 10 секунд. Он перезагрузит страницу, сессия прервётся, и задача не выполнится. Или веб-сервер вернёт клиенту таймаут. В описанном сценарии обработка запроса — синхронная процедура. Она плохо подходит для быстрых веб-сервисов. А вот асинхронная обработка: кинули запрос, получили ответ 200 OK и пошли чилить, пока задача исполняется — это то, что нужно. Воркер как раз для этого.
Коллбэк
Коллбэком воркера может быть любая нужная функция: отправить имейл, прочитать содержимое, залить файл во временное хранилище и т. д.
Триггеры
Триггерами для воркера могут быть:
крон
таймер
событие
Очереди
Воркеры по событию обычно подписаны на очередь. В моём случае это как раз Redis Queue (библиотека rq, например https://python-rq.org/ ). Запрос в ручку получает 200 OK. Мой сервис создаёт запись в БД типа «задача id такой-то, статус processing» и публикует событие в очереди. Воркер забирает событие, чтобы другие воркеры не могли задачу задублировать, и пробует выполнить свой коллбэк. Если всё ок, воркер пишет в БД данные по выполненной задаче и подтверждает в очереди прочтение события. Иначе воркер может ретраить, может завалить задачу и вернуть её в очередь, а может и сам упасть.
Воркер-пул
Воркеров может быть несколько. Они могут выполнять как несколько разных задач, так и одну вместе. Увеличение числа воркеров требует оркестрации и иногда для этого также выделяет контейнер с оркестратором. Воркеры могут передавать задачи друг другу. Могут конкурировать за задачи, если очередь организовать неправильно. А могут вообще читать разные потоки и быть никак не связаны друг с другом.
Накладные расходы
Чем сложнее слой с воркером, тем больше необходимость следить за их хелсчеками. В отличие от вашего сервиса, воркер может тихо упасть. Ваш сервис отдаёт 200, а по факту задачи не отрабатывают. Так что воркеры накладывают дополнительные накладные расходы: связанность, обработка ошибок, логирование, алерты, ретраи, рестарты подов и т. д.
Образ
Воркер собирается из того же образа, что и ваше приложение, но у него отдельный энтри-поинт. Вместо запуска через main.py у, например, worker.py, есть строчка вида:
def main():
... # Какая-то логика по инициализации воркера и очереди
if name == '__main__':
main() # Если запускают этот модуль напрямую, выполни команду main()Из-за этого кода модуль можно вызвать напрямую python -m app.worker. В main(), как правило, скрыта логика какого-то while-true цикла и шатдауна на случай завершения работы воркера.
Открытый проект blip в режиме онлайн позволяет визуально оценить сетевую задержку (латентность или latency) при передачи данных от ПК до разных серверов в мире. Решение работает в браузере на любом ПК, ноутбуке, планшете, смартфоне с поддержкой javascript и HTML canvas.
🎣 14 собесов за неделю благодаря КАРАСЮ — и да, вам не показалось)
Привет, Хабр.
Сразу скажу, про карася расскажу ниже, сначала немного контекста)
Недавно я писал о том, как мы с командой пытаемся решить инженерную задачу под названием «поиск работы». Проблема знакома многим: квалифицированные специалисты тратят сотни часов на рутину — пролистывание лент, однотипные отклики, формальные сопроводительные. Цикл повторяется с каждым новым поиском.
Тогда мы решили посмотреть на это как на систему: входные данные (резюме), правила сопоставления (вакансии), повторяемые действия (отклики) — и автоматизировать то, что не требует креатива. Так родился OfferMate 1.0.
🚀 Что получилось в первой версии
Мы создали ассистента, который:
🔎 Искал вакансии на hh.ru и в Telegram-каналах.
🤖 Автоматизировал отклики через официальное API.
✍️ Генерировал сопроводительные письма, анализируя резюме и требования вакансии.
⚙️ Работал в фоне, экономя пользователям до 10-15 часов в неделю.
Мы набрали несколько сотен активных пользователей. И получили огромное количество фидбеков и результатов, одним из которых поделюсь
🎯 Эксперимент «Карась» и неожиданный результат
Чтобы протестировать систему на реальной нагрузке, мы запустили в блоге условный «челлендж»: попросили желающих оставить в комментариях слово «КАРАСЬ». Это был сигнал для подключения к бета-тесту.
Результаты нас ошеломили. Один из «карасей» поделился статистикой: за 5 рабочих дней — 18 откликов от HR, 9 скринингов и 5 технических собеседований. И при этом это был не единичный случай! Мы получили несколько подобных фидбеков и увидели, что система реально работает и приносит результаты. А также получили огромный заряд мотивации. 💥
⚡️ Переворотный момент
Но за быстрым успехом пришли тревожные новости. HH ограничили способы взаимодействия с платформой и нам пришлось искать обходные пути...
🏗️ OfferMate 2.0: фундамент на годы вперёд
И пока все наслаждались новогодними праздниками, наша команда копалась в деталях. Мы не стали наращивать «костыли» на старую архитектуру, а начали строить новый фундамент.
🔥 Наше ключевое изменение:
Мы реализовали механизм, который работает напрямую через пользователя, полностью имитируя человеческие действия в браузере. Это безопасно и снимает внешние ограничения, давая беспрецедентную стабильность.
Грубо говоря, мы учим систему «работать руками» пользователя)
✨ Что в итоге мы реализовали в 2.0?
🛡️ Абсолютная стабильность. Больше никаких внезапных остановок из-за изменений на стороне площадок.
⚙️ Полная автоматизация рутины. Система может автономно управлять всем циклом: поиск → подъём резюме → отклик → отслеживание статусов.
🎭 Глубокая оптимизация сопроводительных писем под культуру конкретной компании.
🧠 Автоматизация прохождения типовых онлайн-тестов (New)
📊 Централизованные уведомления со статистикой (New)
⏱️ Когда запуск и как попасть в 2.0
Сейчас мы на стадии закрытого бета-тестирования и готовимся к релизу нашего продукта.
Самый сложный технологический этап пройден. Сейчас мы интегрируем новую логику в бота и проводим стресс-тесты под нестандартными сценариями.
Хотим всё хорошо оттестировать и ворваться в новый сезон найма, чтобы разрывать его вместе с вами! 💥
Публичный запуск планируем в конце января. 🗓️🎄
❗️Чтобы обеспечить качество, мы откроем только 100 слотов на 3 дня.
Это осознанное решение для контроля нагрузки и получения концентрированной обратной связи.
Мы хотим, чтобы OfferMate 2.0 вышел не «сырым анонсом», а готовым инструментом, которому можно доверить карьерный маневр.
🤝 Как поучаствовать
Присоединиться к запуску и поучаствовать в тестировании — можно будет в нашем Telegram-канале: https://t.me/offermatecrew
Мы приглашаем сообщество Хабр помочь нам в разработке лучшего ИИ-ассистента для поиска работы!
P.S. В комментариях готов подискутировать на тему пользы автоматизированных откликов и ответить на технические вопросы 👇
