Все потоки

Демо-период заканчивается — дальше ИИ только за деньги?

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

Раньше пользователь мог выбирать между бесплатной и более сообразительными платными моделями по ежемесячной подписке. Теперь правила усложняются. В начале апреля Anthropic запретила использовать сторонний агентский модуль OpenClaw со своей LLM Claude на подписках Pro и Max. Теперь Microsoft предупредила, что оплата ИИ-помощника Copilot на GitHub будет происходить по токенам, а не ежемесячно. Всё это звенья одной цепи.

В чём разница? Если раньше пользователь мог оплатить месячную подписку на LLM за 20–200 долларов и пользоваться ею для своих целей, то теперь оплата будет взиматься в зависимости от сложности задач. Узнать суть незнакомых библиотек можно несравнимо дешевле, чем заказывать сложные программы и запускать сложные сценарии, где ИИ подбирает выгодные билеты, отслеживает доступность и сообщает о готовности — это уже работа ИИ-агентов.

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

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

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

Почему «сильные кандидаты» в ИТ — это миф, и как мы перестали их искать

Привет, Хабр! Я Анастасия Туча, Recruitment Team Lead в Островке. Часто в ИТ-рекрутинге вижу формулировку: «сильный кандидат». Звучит понятно, почти универсально. На практике эта фраза часто скрывает главный вопрос: сильный для какой именно задачи? Для какой команды? Для какой стадии продукта? Для какого уровня автономности? Для какой роли в системе принятия решений?

В Островке мы используем skill-based подход, чтобы уйти от подобной размытости: оценивать не человека «в целом», а конкретный набор навыков, который нужен конкретной роли.

Вот как это устроено у нас

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

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

• формулировать вопросы к задаче

• видеть ограничения

• спорить с гипотезой, а не просто брать тикет

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

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

А дальше начинаются нюансы

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

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

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

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

Это не отменяет человеческое решение, но делает его более проверяемым: если мы говорим «кандидат хорошо подходит», становится проще увидеть, на каких конкретных наблюдениях это основано. А если в фидбеке появляется формулировка вроде «не почувствовали seniority», её приходится разложить: что именно не хватило — самостоятельности, глубины технических решений, работы с неопределённостью, умения объяснять trade-off’ы?

На практике мы убедились в профитах, которые даёт skill-based подход:

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

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

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

Подробности о нашем skill-based подходе можно узнать из записи митапа hh.ru.

***

И два вопроса к читателям.

Если вы нанимаете — что чаще перевешивает: формализованная оценка по навыкам или «химия» с кандидатом?

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

Ускорили разработку в 2 раза за счет AI? Понятно.
Вот только релизы не стали быстрее, time-to-market не сократился.

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

Agile создавался как ответ на высокую сложность разработки, но AI эту сложность уже снизил. А значит, текущая модель команд начинает устаревать.

В апреле на Product Focus Club наш CPTO Саша Бондаренко поделился своим видением трансформации команд. 

Он рассказал:
— почему инвестиции в AI не дают эффекта без пересборки процессов (на данных Klarna и DORA)
— как появляется новая роль Product Engineer вместо набора узких специалистов
— почему команды из 7-9 человек трансформируются в компактные поды из 2-3 инженеров
— как Platform Engineering становится системой контроля и масштабирования, а не поддержкой
— как выглядит Team Topologies 3.0 и с чего начать переход

Запись выступления доступна для просмотра на YouTube и VK Видео. 

Кстати, в рамках эксперимента мы запустили три pod-команды у нас в Garage Eight. И у ребят уже есть крутые результаты! Обязательно поделимся ими в нашем телеграм-канале.

Обновлена открытая библиотека theSVG из 5 880+ векторных SVG-иконок для разработчиков и дизайнеров. Есть вшитый поиск, CDN, CLI, API и готовые пакеты для React, Vue и Svelte. Бонусом у иконок есть разные варианты: цветные, монохромные, светлые, тёмные и wordmark.

Как определить свой внешний IP когда действуют белые списки Минцифры

Когда Министерство цифровой деградации России начинает ограничивать Интернет по своим белым спискам, внезапно обнаруживается, что из привычных инструментов не работает ничего. Невозможно зайти ни на один сайт: 2ip.ru myip.ru ifconfig.me ipify.org whatismyipaddress.com www.whatismyip.com ipinfo.io потому что никто из них не занесён в белые списки. Timeweb есть в белых списках, timeweb.com/check-ip страница открывается, но во время работы белых списков все поля пустые. Из поисковых серверов в этот момент доступен только Яндекс, но он тоже ничем не может помочь в данной ситуации, потому что не готов к такому, и предлагает те же самые сайты которые недоступны.

Вспоминаем жизнь до появления поисковых серверов - создаём свои коллекции нужных ссылок вручную.

В момент действия белых списков мне через моего сотового провайдера «Мегафон» (физически я нахожусь в СПб или Ленобласти) доступен очень ограниченный перечень сайтов. Возможно, что в том месте где Вы находитесь белый список будет другим. Просмотрев вручную всё что мне доступно по состоянию на 7 мая 2026 нашёл всего две ссылки которые показывают мой IP адрес: Яндекс Интернетометр yandex.ru/internet и Reg.ru reg.ru/web-tools/myip В Интернетометре Яндекса можно ещё и скорость померить. Из сервисов whois рабочий нашёл только один nic.ru/whois Разумеется, не надо заходить на эти ресурсы через свою выходную ноду VPN. Также, в момент когда действуют белые списки, возможно ещё и замедление скорости доступа даже к тому что разрешено. Привычный дизайн сайтов может быть нарушен, из-за того, что внешние ресурсы подгружаемые сайтом недоступны во время работы белых списков.

IP адрес который выдал Вашему устройству сотовый провайдер можно посмотреть на самом устройстве. На Android это вот тут: Settings / About phone / Status / IP Address

Возможны другие варианты. На BlackView BV9800: Settings / System / Advanced / About Phone / IP Address

Во время работы белых списков на смартфоне 100.82.28.67 а внешний IP на сайте Яндекс Интернетометр в это же время показывает 178.178.244.80

100.64.0.0 — 100.127.255.255 (маска подсети 255.192.0.0 или /10). Данная подсеть рекомендована согласно RFC 6598 для использования в качестве адресов для CGN (Carrier-Grade NAT); Вики

Список подсетей возможно доступных по белым спискам можно посмотреть тут Это — всё что вам надо знать о белых списках: как устроены и 6 способов обхода

PS: Запасайте наличные рубли, во время работы белых списков либо оплата наличными, либо предоплата на сайте. Оплата банковской картой в это время не работает. Видимо эквайринг Сбербанка в белые списки не попал.

Написал большую статью на Habr — От написания промптов к проектированию контекста. Или один очень обширный материал про Context Engineering

Полезно всем, кто работает с агентами Claude Code | Codex 🍦

Что внутри

Context rot и reasoning shift — почему длинный контекст это плохо

Типы Attention и как считается сложность в современных трансформерах

Из каких 7 слоёв состоит контекст Зачем нужен CLAUDE.md / AGENTS.md / GEMINI.md
Что такое MEMORY.md Секция про Skills, MCP, Subagents

Архитектура AGENTS LOOP

Как работает Prompt caching Как считается стоимость токенов

Что отличает Новичка от Мастера в работе с современными агентами

А какие там иллюстрации, мммм

А завтра онлайн в 18 мск буду читать лекцию по этой статье, залетайте послушать https://calendar.app.google/TDm1ZZusNtX5w394A

Дорожная карта Agentic AI. Level 4. Мастер примеров — few-shot и structured output

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

Где это реально работает

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

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

Три уровня, которые нужно понимать

Чтобы не гадать самим, нужно понимать разницу между режимами. На одном конце zero-shot: только инструкция, без примеров; на мощных моделях для простых задач часто хватает и этого. One-shot добавляет один эталонный образец и полезен, когда важен точный формат ответа. Ну а few-shot это уже от двух до десяти примеров; на практике 3–5 штук оптимум, потому что меньше даёт мало сигнала, а больше добавляет шум и лишние токены. Хорошую базу по технике даёт Prompting Guide, а про подход Claude подробнее в документации: multishot-prompting.

Что класть в примеры

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

Почему без structured output это бесполезно в бизнесе

Но даже с хорошими примерами остаётся вопрос: куда девать результат. В продакшене нужен не текст, а JSON строго по схеме: category: "техподдержка", priority: "высокий", responsible: "техотдел". Чтобы результат сразу ушёл в CRM, в базу, в следующий сервис: не придётся разбирать свободный текст руками. Примеры для few-shot делайте сразу в этом формате: так модель быстрее схватывает нужную структуру. Документация: OpenAI Structured Outputs, Claude Structured Outputs.

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

По опыту, хорошие примеры в паре со structured output закрывают без файнтюна и без ML-команды огромный пласт задач на извлечение, разметку и классификацию.

Разобрали продвинутый few-shot на реальном кейсе: смотрите видео.

🔔 Следующая тема: RAG и векторные базы — как передать агенту знания о вашем бизнесе.

⬅️ Предыдущая тема: Level 4. Своя кузница — локальный запуск моделей

Подписывайтесь, пожалуйста, чтобы не пропустить!

Больше про ИИ — в ТГ-канале и ВК. Каталог наших курсов, услуг и кейсов по ИИ-агентам. По вопросам — пишите в личку.

SELECTOS OpenFix Day 2.0 стартует через час

В 19:00 (мск) мы начинаем митап для инженеров и системных администраторов. Ждем всех, кто не только разворачивает Linux в продакшене, но и читает исходники, гоняет ядро в дебаггере, отслеживает регрессии и закрывает CVE до того, как они становятся инцидентом. 

Программа митапа

• Итоги программы OpenFix и планы на будущее.

• Пластмассовый мир: что не так с ИИ-хайпом и как с этим жить.

• Как ИИ может помочь в управлении ОС.

• Как я ронял прод: конкурс инженерных факапов.

Подключайтесь

✔️ на YouTube

✔️ в VK

РБПО по ГОСТ Р 56939—2024: вебинар №11 из 30 – Динамический анализ кода программы

Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.

Предлагаем сегодня вашему вниманию вебинар цикла, посвящённый процессу, описанному в разделе 5.11. – "Динамический анализ кода программы". На YouTube. Слайды.

Цели 11-го процесса по ГОСТ Р 56939—2024:

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

Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.

Разрешите показать ASCII мета-шрифт. Сделал пока латинские заглавные. Фишка - каждая буква включает саму себя.

Как вам? Использую в своих ASCII играх и в книжке про “невозможную” ASCII графику.

Опасная романтизация рынка.

Когда оказывается, что разработка немного (ну или сильно) опередила рисерч и маркетинг в соц.сетях, ты (как C-level в команде из 3 человек) начинаешь задавать себе неприятный вопрос: а вдруг эта идея важна только нам?

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

То самое «когнитивное искажение» (согласно словарю) - это систематическая ошибка в мышлении, восприятии или поведении, которая возникает из-за субъективных убеждений, стереотипов и особенностей работы мозга.

Но как так может быть, что только у нас, таких особенных, единственных в своем роде людей, и у нашего вейтлиста из 100+ человек, (да, мы знаем, это не так много) есть именно такие особенности мозга? Я в этом СИЛЬНО сомневаюсь.

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

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

Так что, возможно, это самая честная стадия early-stage продукта: когда команда верит в проблему, но все еще учится объяснять ее не только самой себе.

Так что да, возможно, говоря про свой (прости г-ди) стартап, я могу сказать, что где-то мы перепутали порядок - сначала построили, а уже потом начали системно доказывать.

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

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

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

• роутеры D-Link, TP-Link, Ростелеком (ИскраТел), ZyXEL, Paradyne;

• мобильные телефоны N95i и Toshiba Portege;

• IP-видеокамеры - 2 экземпляра;

• видеокарту;

• коммуникаторы и ТСД на базе Windows CE;

• транспондер;

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

Итого всё это «добро» весит около 10 килограммов и представляет собой настоящую историческую веху, в которую я, как олдфаг, вспоминающий интернет по талонам, с ностальгией готов окунуться. Валерий, очень рад познакомиться лично и ещё раз спасибо за предоставленное оборудование!

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

Если у вас есть предложения, с чего именно мне начать, - с радостью выслушаю ваши пожелания.

🧠 Обязательно поделись с теми, кому это может быть полезно: 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте