В 2026 году решили расширить штат. Разместил вакансию, начался поиск.
За первые два дня после публикации вакансии пришло более 400 откликов. Это сумасшедшая цифра... Ладно, собрался, отфильтровал, осталось около 300.
Начались собеседования, и именно на них я был сильно удивлён, ведь не так давно ситуация была другая…
Привет, Habr! Рад представить сообществу проект, над которым корпел практически целый год.
Тяжело писать вступление для такой щепетильной темы, но так как мы на техническом ресурсе, я опущу все очевидные мотивы и просто опишу, что получилось.
Идея появилась, когда я решил попользоваться бесплатными VLESS-конфигами. Найти их нетрудно, а вот пользоваться постоянно невозможно: конфиг может перестать отвечать, потерять скорость или перестать пропускать отдельный сервис. Приходится возвращаться к подписке, перебирать варианты и искать замену вручную. Платные сервисы тоже этим грешат, что, если честно, вызывает жжение ниже спины. Вот одним вечером и появилось желание испытать себя и автоматизировать этот процесс.
Хотелось оставить на телефоне, ноутбуке и роутере по одному профилю, а поиск работающих конфигов перенести на сервер. Так появился Hydrat: шлюз, к которому устройства подключаются по WireGuard, а дальше их трафик уходит через автоматически выбранный VLESS или Tor. Источники могут обновляться, внешние серверы - отваливаться и возвращаться в строй. Профиль на конечном устройстве из-за этого менять не нужно.
Расскажу с какими проблема столкнулся и как автоматически перебрать тысячи конфигов и найти десятки рабочих.
Что делать, когда процесс разработки с ИИ-агентами уже устоялся, но всё ещё приходиться сидеть рядом с ними и ждать, когда они закончат очередной этап работы, чтобы запустить следующий?
У меня это выглядит так. Появилась идея новой фичи для разработки. Я запускаю /opsx:explore скил OpenSpec и обсуждаю с ИИ как будем делать эту фичу, какие нюансы и детали надо предусмотреть. Когда открытых вопросов не остаётся, перехожу к /opsx:propose, чтобы подготовить спецификации перед разработкой. Потом ревью спек с помощью команды /review-artifacts и правка найденных нестыковок. Дальше запускаю /opsx:apply-sequential для реализации в автономном режиме и чистым контекстом агента для каждой подзадачи. Потом ревью через /audit-implementation и правки после него. Архивирование изменения через /opsx:archive. И наконец-то создание PR, финальное ревью и merge.
И так раз за разом! На простых задачах моё участие сводится к запуску команд и подтверждению предложенных решений. На задачах посложнее отвечаю на вопросы наподобие какую из альтернатив выберем. Хотя этот выбор можно сделать по критериям, зафиксированным в проекте. И это уже начинает утомлять. Пришло время автоматизировать и эту рутину. Так я начал делать свою фабрику, где ИИ-агенты («гномы») трудятся в полностью автономном режиме. А к человеку обращаются только тогда, когда столкнулись с проблемой, которую не могут решить сами.
Всем привет! Я фронтендер и по вечерам делаю пет-проект Workaem, агрегатор IT-вакансий. Как-то захотелось сделать рядом с ним что-нибудь несерьезное, и за выходные получилась аркада в духе Марио, только про карьеру в IT. Назвал я ее «Путь джуна». Вместо грибов тут офферы, вместо черепах легаси, а в замках вместо дракона сидят собеседования, от тестового задания до финального.
Потом я еще пару вечеров ее доделывал, и по дороге всплыло много такого, с чем я как фронтендер раньше не сталкивался. Фиксированный шаг физики, процедурные уровни, синтез звука, античит. Про это и расскажу, а заодно про баги, которые глазами никак не ловились.
Claude я использовал активно, как и в основном проекте. Код он пишет быстро, а вот почему уровень вдруг не проходится или почему таблица рекордов врет, разбирался я сам, в основном по скриншотам и логам.
Почему замена деталей по календарю не всегда снижает число отказов? Разбираем RCM — методологию выбора обслуживания по функциям оборудования и последствиям их потери: от шести паттернов отказа до дерева решений.
На тридцатом шаге мой ИИ-агент отправлял нейросети 123 856 входных токенов. Один запрос весил как небольшой роман и стоил соответственно. При этом большая часть контекста уже приезжала раньше: логи, прочитанные файлы, старые ответы инструментов и описания тех инструментов, которые на этом шаге вообще не использовались.
Я начал резать повторный контекст. Сначала на сервере, потом на компьютере пользователя. За два дня вокруг простой идеи выросли локальный архив, оглавление сессии, загрузка схем инструментов по требованию и песочница для вычислений.
На одном и том же 30-шаговом сценарии стоимость снизилась с 48,26 до 8,40 рубля, а вход — с 2,4 миллиона до 419 тысяч токенов. Полный вариант решил 30 задач из 30.
Красиво. Даже слишком.
Стенд был синтетическим. Когда я вынес движок в живого агента, выяснилось, что на коротких задачах оптимизация может сделать всё дороже. Тут и начинаются границы красивой цифры.
Первый вариант системы выглядел вполне стандартно: документы разбиваются на фрагменты, для них считаются embeddings, пользователь задаёт вопрос, несколько наиболее подходящих фрагментов отправляются в LLM вместе с запросом. Модель формулирует ответ — на первых тестах этого было достаточно.
Проблемы начались на вопросах, которые на первый взгляд мало чем отличаются друг от друга: Какая пеня установлена в договоре № 14/24? Кто из арендаторов не заплатил за май? А у него предусмотрена индексация? Контрагент предлагает заменить пеню 0,05% на 0,01%. Насколько это существенно?
Формально всё это вопросы об аренде. Для системы это четыре разные задачи.
Я больше десяти лет делаю рекламные платформы. Команды за это время были разные — по размеру, по составу, по зрелости. Но почти всегда был один загон — всем почему‑то было очень важно работать по спринтам.
Не обязательно называть это скрамом, хотя обычно называли. Важна была именно двухнедельная итерация как фундамент вокруг чего строится планирование (или то, что им кажется), отчетность и разговор со стейкхолдерами.
Диффузионная LLM может пересматривать свой контекст — в отличие от ARM. Я попробовал заставить её саму чистить RAG-контекст, положив ретрив графа знаний под маску. Результат спорный.
Эта серия из десяти частей — для тех, кто следит за новостями и любит карты. Сначала покажу, что внутри продукта, а потом разберём, как это работает. Здесь — только то, что видно на экране.
Я всегда хотел от новостей двух вещей: видеть весь мир сразу и получать его непрепарированным — не через обученных аналитиков, не через политологов, не через «независимые» СМИ, которые всё равно заняты сохранением страт. Лента даёт тебе информацию на чужих условиях: кто-то решил, что тебе показать первым, а что не показывать вовсе. Карта даёт мир и позволяет смотреть туда, куда хочешь ты.
Под этим лежат три права, и на самом деле это одно право: право говорить, право слушать, право получать и распространять информацию. Человек, у которого есть знание, тяжело поддаётся манипуляции — не невозможно, но тяжело: манипуляция живёт в зазоре между тем, что произошло, и тем, что тебе про это рассказали. Если событие стоит там, где оно произошло, и в тот час, когда произошло, часть этого зазора закрывается.
Отсюда вопрос, на который у меня нет ответа: как управлять обществом, где у всех равный доступ к непрепарированной информации? Мне интересно выяснить, что тогда останется.
Я делаю это один, почти каждый день в течение года. Карты новостей не новы, и WorldMapper не первый — но, я думаю, один из самых проработанных. И я его не брошу.
## Что на экране
Открываешь WorldMapper — видишь карту и рядом ленту заголовков. Каждая новость — точка: кликнул на пин, прочитал событие, посмотрел, что рядом. Не лента, которая тащит тебя вниз, а пространство, где ты выбираешь направление.
Практический разбор архитектуры AI‑ассистента, который постепенно вырос в production‑систему: управление состоянием диалогов, разделение каналов и бизнес‑логики, оркестрация NLU, LLM и ручной поддержки, а также Inbox/Outbox для надёжной обработки сообщений.
Статья показывает, как эти компоненты связались в единый lifecycle пользовательского сообщения и почему архитектура в итоге стала важнее самой AI‑части.
Один публичный IP, один 443-й порт, на нём уже работает сервис с живыми пользователями — и туда же нужно посадить второй. Менять настройки на устройствах пользователей нельзя.
Разбираю, как разделить порт между двумя TLS-сервисами, ничего не расшифровывая: SNI уходит открытым текстом в ClientHello, и nginx умеет читать его директивой ssl_preread, оставаясь для TLS прозрачным. Отдельно — почему всё держится на ветке default, чем за прозрачность платят (бэкенд перестаёт видеть реальные адреса клиентов) и когда у этого решения закончится срок годности.
Спекулятивное декодирование обещает ускорение до 6.5 раза: маленькая черновая модель набрасывает несколько токенов вперёд, большая проверяет их за один свой проход, а текст на выходе получается тот же самый. Я воспроизвёл EAGLE-3 на бесплатной Kaggle T4 и получил разброс от 2.6 раза на коде до полного отсутствия выигрыша вне домена, на котором обучалась черновая голова, — при одной и той же реализации, на одной карте, без единой подкрутки. Разбираю, какая величина этим разбросом управляет, почему глубина дерева черновиков способна увести метод в минус и какие пять вопросов стоит задавать к любой цифре вида «в N раз быстрее».
Агент отработал полчаса и остановился. У вас спрашивают, что он делал.
Вы открываете его логи. Там аккуратный рассказ агента о себе: вызвал такой-то инструмент, получил такой-то результат, решил сделать то-то. Рассказ убедительный, потому что писала его та же модель, чьи действия вы проверяете. Вы открываете метрики платформы. Там ровно то, что платформа умеет показывать: столько-то запросов, столько-то секунд, столько-то мегабайт.
Вопрос, на который нет ответа ни в одном из двух окон: откуда вообще берётся знание о том, что агент делал. Не что он про себя написал, а что он сделал.
Уезжал в долгий отпуск, а дома оставалась рабочая машина с RTX 5090: GPU периодически нужен для локальных моделей. Оставлять её включённой на несколько недель не хотелось, просить родню жать кнопку, тем более.
В итоге дома круглосуточно работает только плата ESP32 за пять долларов от USB-зарядки для телефона. Жму кнопку в веб-панели, плата будит ПК по Wake-on-LAN и подтверждает включение в Telegram. После загрузки Windows сама цепляется к MQTT-брокеру и исполняет любые команды: от «выключись» до «выполни python-скрипт и пришли вывод». Отдельной командой поднимается reverse SSH, и локальная Ollama становится доступной как облачный эндпоинт.
В статье разбираем, почему включение и управление сделаны двумя раздельными каналами, как устроена прошивка с deep sleep (плата еле тёплая и живёт месяцами), зачем нужен дебаунс команд на 5 секунд и где у схемы честные слабые места. Плюс найденные по дороге грабли: кириллица в Telegram из PowerShell, Wi-Fi, который греет плату сильнее, чем кажется, и авто-выключение через час простоя, если я сам забыл про включённый ПК.
Сейчас вокруг AI-разработки игр происходит странная вещь. С одной стороны, появились инструменты, с которыми один человек действительно может делать то, для чего раньше требовалась небольшая команда. Код, графика, анимация, исследования, прототипирование — всё это стало в разы доступнее.
С другой стороны, интернет постепенно заполняется проектами, которые выглядят примерно так: «Я написал два промпта — и нейросеть сделала мне игру». После этого появляется вполне предсказуемая реакция: кому вообще нужна игра, которую никто толком не придумал?
И с этой критикой мне сложно спорить. Потому что если попросить AI придумать игру, сделать графику, написать код, придумать баланс и решить, зачем игрок должен во всё это играть, результат действительно очень легко превращается в то, что сейчас любят называть AI slop.
Но за последние недели разработки собственной игры я пришёл к совершенно противоположному выводу: проблема не в том, что в создании игры участвует искусственный интеллект. Проблема начинается тогда, когда человек перестаёт принимать решения. Ведь ИИ не может пока понять, а интересно ли в это играть?
В последнее время меня всерьез стала беспокоить безопасность RSA. Криптография RSA держится на сложности факторизации большого полупростого числа, но какое именно число можно считать достаточно «большим» — вопрос интересный. Web PKI отказалась от 1024-битного RSA больше десяти лет назад, и хотя я не знаю никого, кто факторизовал бы ключ такого размера, это вполне по силам какому‑нибудь правительству или другой организации с большим количеством машин. Буквально пару дней назад кто‑то факторизовал 862-битный ключ RSA-260 в рамках конкурса RSA Factoring Challenge. Это самая крупная факторизация, о которой я слышал.
Как человек, что все еще верит в возможности FIRE на рынке РФ, я задался вопросом: что будет с вашим рентным портфелем, если наступит затяжной рыночный кризис, а вы продолжите ежемесячно изымать деньги на жизнь? Исследование показало, что стандартные способы инвестиций имеют склонность к обнулению капитала со временем (иногда лишь ускоряя это обнуление). А значит, было бы неплохо придумать модель долгосрочного инвестирования, что и рассматривается в статье. Будет интересно, если: хотите увидеть, как математика побеждает рыночный хаос (обывателям); забрать готовые модули бэктестера к себе в продакшен (новичкам, как я); имеете собственное видение по теме/любителям подсказать словом (созидателям и/или действующим квантам).
Вчера переехал на свой сервер. Сегодня утром обнаружил, что сайт у меня не открывается. Ни из дома, ни с телефона.
Сервер при этом в Москве, у российского хостера. И с ним всё в порядке.
Дальше про то, как я полдня искал причину, какие шесть версий проверил и выбросил, и чем всё кончилось. Если симптомы похожие, в конце готовая методика: что запускать и как читать результат.
Почему миллионы начинающих пользователей боятся «нажать не туда», а видеоуроки не формируют практических навыков? Рассказываю, как создала интерактивный симулятор настольных ОС (Windows 10, 11 и Linux) с уроками и мини-играми и как это помогает безопасно осваивать компьютерную грамотность прямо со смартфона.