Flight Simulator добавили прямо в карты от Google — в веб‑версии Google Earth появилась возможность полетать над своим домом. Симулятор в точности воссоздаёт 3D‑мир с рельефом и всеми строениями, прямо как в симуляторе от Microsoft. При этом управление достаточно нестандартное. Ищем свой дом на Google Earth — жмём Tools и выбираем Flight Simulator.
Написал бесплатное приложение для транскрибации — ⚡️ Talkis. Делал для себя как open‑source альтернативу платным сервисам по подписке.
Что оно умеет:
Расшифровывает созвоны (Zoom, Discord, Telegram и др.) в реальном времени прямо на лету.
Вытаскивает текст из любых готовых аудио‑ и видеофайлов.
Умная диктовка: наговариваете мысли голосом, а приложение причесывает и форматирует текст под нужный стиль.
Как это работает: модели можно крутить либо полностью локально на вашем железе (вообще бесплатно), либо подключить свои API‑ключи и платить копейки за токены без наценок сервисов.
Проект открытый. Буду очень благодарен за обратную связь, баг‑репорты и звездочку на GitHub — для развития проекта это сейчас самое важное.
ChatGPT и Claude научили маскироваться под Google Docs — представлено расширение GPTDisguise, где нейросеть выглядит как обычный документ, поэтому со стороны кажется, что пользователь усердно пишет документы. Также доступны режимы под Microsoft Word и Notion.
Используем Google Gemini в любом OpenAI-клиенте (например, в OpenCode)
Если вы хотите использовать бесплатные (и платные) модели Gemini в среде OpenСode, то это вполне реально :)
Статью на Хабре не захотел одобрять модератор, но вы можете почитать её тут (для просмотра может потребоваться VPN):
Используем Google Gemini в любом OpenAI-клиенте (например, в OpenCode)
Этот прокси реально работает в моём OpenСode и вроде косяков нет.
Дисклеймер: статья написана для ИИшки и с помощью ИИшки, кому это не надо — проход ите мимо :)
@Sol0Zon3 вы просили вам тегнуть :)
Снял видео с рисованием дашбордов для 1С с помощью ИИ.
За кадром осталась небольшая подготовка данных — из 1С ERP выгружен файл с тремя таблицами (продажи, выпуск, приход денег). Просто три запроса, три таблицы, которые поехали в один json-файл.
А ИИ из этого файла рисует дашборды, в виде одностраничного html. Как положено, понимает человеческую постановку задачи, доступную пользователям (которым сказали, какие данные есть в файле).
Понятно, что в техническом плане — поделка.
Видео про то, как оно до бизнес-пользователя доехало. Реально доехало, кстати.
🍺 В этот день 150 лет назад родился Уильям Сили Госсет.
Всю карьеру он проработал пивоваром в Guinness и занимался задачей, которую учебники почти не трогали: как делать выводы по крошечным выборкам — например, по четырём участкам ячменя или небольшой партии хмеля.
Статистика того времени в основном исходила из больших выборок, поэтому Госсет фактически изобрёл статистику для малых.
Guinness запрещала сотрудникам публиковаться после того, как один из них слил коммерческие секреты. Компания также не хотела, чтобы конкуренты знали: пиво там варят с помощью науки.
Поэтому, когда Госсет в 1908 году опубликовал свой метод, он подписался псевдонимом: Student.
Каждое клиническое испытание, лабораторный эксперимент и A/B-тест, где сегодня используют t-test, опирается на работу Student.
Одна из самых известных фамилий в статистике — ненастоящая.
Неравномерность развития науки
Название книги Дж. Роулинсона ‘Сцепление. История изучения межмолекулярных сил’ хорошо передает ее содержание. Дж. Роулинсон — химик по образованию и его научная деятельность была во многом связана с изучением межмолекулярных сил. Его книга содержит интересный фактический материал, который изложен на хорошем профессиональном уровне.
Книга состоит из четырех частей. Для названия первых трех частей Роулинсон использовал имена трех ученых — Ньютон, Лаплас, Ван‑дер‑Ваальс. Их исследования сыграли ключевую роль в исследовании межмолекулярных сил, поэтому их имена были использованы для разделения этапов исследования. Последняя часть под названием «Решения» посвящена работам после появления квантовой механики — в ней рассматриваются ответы на вопросы предыдущих поколений ученых.
Роулинсон отмечает тернистый путь развития идей о когезии и дает интересную характеристику развития науки:
«Делать обобщения о том, как делается наука, на примере одной довольно узкой области опасно. Многие могут оспорить приведенное рассмотрение с использованием представленных свидетельств, но оно представлено как попытка рассмотрения развития этой области за триста лет. Я бы не хотел быть догматичным; другие должны попытаться сделать свои собственные выводы из рассмотрения этой области, а история других областей науки может привести к иным выводам. При чтении Поппера, Куна, Лакатоса и других философов науки можно распознать у них немало правильного, что соответствует ряду реальных примеров, но трудно вписать в эти рамки хотя бы одну теорию в физике (one physical science). На практике наука, похоже, движется менее логичными путями, чем хотелось бы философам. Фейерабенд, несомненно, нашел бы в моей книге примеры, подтверждающие его утверждение о том, что „Наука — это, по сути, анархическое предприятие“.»
J. S. Rowlinson, Cohesion. Scientific History of Intermolecular Forces, 2002.
Пост-анонс. У меня есть лог, что-то среднее между блогом и микроблогом — там я пощу коммерческую рефлексию: заметки про продажи и архитектуру принятия решений.
Сама идея лога появилась недавно, но мыслей для него насобиралось уже порядочно. Пока оформляю просто верстая HTML, но это мягко говоря не удобно. Естественно задумался о статическом генераторе сайтов (SSG), но не брать же чужой когда ты инженер?
Выбор на чём написать свой оказался не простым. Выбирал между мейнстримом (Go, Rust) и андеграундом (Ada, APL). На APL у меня уже есть генератор, поэтому решил поднять планку. В итоге выбрал ассемблер.
Пишу под Solaris, без зависимостей, только сисколы. Solaris потому что она мне нравится и я под ней работаю; чтобы там не говорили — это инженерный шедевр.
Проект пишется в свободное время как инженерный манифест. Когда SSG будет полностью готов, я выкачу сюда, на Хабр, большой технический лонгрид с архитектурными графами, полным разбором системных вызовов и инструкцией для тех, кто захочет пощупать это вживую.
Полный список планируеммых команд (из инженерного черновика):
# Полная сборка всех новых статей > ./kettlebell # Пересобрать все статьи > ./kettlebell --force # Пересобрать все статьи, предварительно удалив папку ./build > ./kettlebell --clean --force # Собрать статьи только для 1 языка, только новые > ./kettlebell --lang ru # Пересобрать все статьи для 1 языка > ./kettlebell --lang ru --force # Генерация только 1 поста для 1 языка > ./kettlebell --post ru/new-idea # Перезаписать существующий пост или элемент в RSS > ./kettlebell --post ru/llm-as-lvr --force # Создать блан для поста во всех языках > ./kettlebell --new last-bastion
Следить за процессом разработки, компиляцией kettlebell.s и первыми реальном времени можно в моем Telegram-канале: Cleanroom 89 (там только хардкор). Или ставьте watch на репозиторий github: kettlebell.
Поддержите подпиской, если вам тоже надоел оверхед современных веб-технологий или просто хочется чего-то неординарного.
Есть шанс получить доступ к Claude Max на полгода бесплатно. Anthropic представила программу для разработчиков открытых приложений. Можно подать заявку и сэкономить 1200 баксов:
вы подходите, если создаете приложение сами или в команде, и у вас публичный репозиторий. Также нужно, чтобы были коммиты, релизы или ревью за последние три месяца. Лучше, если там будет 5000+ звезд.
Даже если такого нет, можете подать заявку в компанию, описать, почему ваш проект полезный и нужный, и сможете получить Claude Max
подать заявку можно до 30 июня включительно. Дальше ждем результатов. Бесплатный доступ получают 10 000 разработчиков.
Как я ускорил бэкапы в 20 раз и обошёл ловушку Jsoup: развитие самописной Android‑читалки MRead (v1.3.0)
Всем привет! Не так давно я рассказывал, как боль от перегруженных интерфейсов заставила меня открыть Android Studio и написать собственную читалку с кастомным движком рендеринга и точным выделением текста.
Статья получила теплый отклик и в комментариях набежало много отличных предложений. В этом посте я хочу поделиться техническими решениями, которые вошли в крупное обновление 1.3.0.
1. Бэкапы и боль от Storage Access Framework (SAF)
В приложении есть функция бэкапа: упаковка базы данных Room, настроек и распакованных HTML‑глав с картинками в один ZIP‑архив. Изначально я писал файлы напрямую в OutputStream, полученный через ContentResolver (SAF). Итог: библиотека на 500 МБ архивировалась около 5 минут. SAF проводит проверки безопасности для каждого записываемого чанка, что убивает I/O операции.
Решение: сборка архива переехала во внутренний кэш приложения. Туда пишем без ограничений SAF — буфером по 64 КБ и уровнем сжатия BEST_SPEED (картинки уже сжаты, гнать их через BEST_COMPRESSION бессмысленно). Когда ZIP готов целиком, он одним куском копируется в пользовательскую папку через SAF — вместо тысяч мелких защищённых записей получается одна
2. Material You: как получить правильные цвета обоев
При внедрении динамических тем (Android 12+) я столкнулся с тем, что стандартный вызов dynamicLightColorScheme().background на многих устройствах выдает просто унылый белый или бледно‑серый цвет, игнорируя сочные оттенки обоев.
Решение: Самые насыщенные цвета из системной палитры Monet хранятся в secondaryContainer и surface. Решение нашлось в самой палитре Monet: наиболее насыщенные цвета живут в secondaryContainer и surface, а не в background. Переориентировал маппинг цветов приложения на эти слоты и интерфейс действительно ожил. Теперь интерфейс действительно реагирует на смену обоев. Плюс привязал OnSharedPreferenceChangeListener, чтобы тема менялась мгновенно на всех экранах без перезапуска.
3. Странности парсинга FB2 и баги Jsoup
Иногда вместо обложки FB2 парсер ставил черно‑белую картинку из середины книги. FB2 хранит все изображения в тегах <binary> в конце файла в хаотичном порядке. Если тег <coverpage> отсутствует, старый алгоритм просто брал первую попавшуюся картинку из бинарной кучи.
Я переписал фоллбэк: теперь, если явной обложки нет, Jsoup ищет первый тег <image> прямо внутри <body> книги.
Попутно всплыло неочевидное поведение Jsoup: если атрибут отсутствует, attr() возвращает пустую строку, а не null — это задокументировано, но интуитивно ожидаешь null. Из‑за этого Элвис‑операторы (?:) молча проглатывали пустую строку вместо ухода в fallback. Написал строгую обертку takeIf { it.isNotEmpty() }, и теперь обложки извлекаются безошибочно.
4. Изолированный свайп яркости в Compose
Нужно было добавить регулировку яркости свайпом по левому краю экрана. Проблема: в режиме вертикального скролла (VerticalPager) свайпер страниц перехватывает вертикальные жесты на себя.
Решение: перехватывать жест на фазе Initial — до того, как пейджер успевает его обработать. Если касание началось в левых 15% ширины экрана, событие забирается себе и до пейджера не доходит.
Помимо этого в релизе 1.3.0:
Добавлен полноэкранный просмотрщик иллюстраций с pinch‑to‑zoom (на основе detectTransformGestures).
Написан собственный File Picker со сканированием вложенных папок и извлечением книг прямо из ZIP‑архивов на лету.
Добавлен поворот страниц для PDF с сохранением состояния в SharedPreferences.
Разделен UI верхнего меню: закладки теперь можно переименовывать, а тап по номеру страницы открывает быстрый переход.
Добавлен множественный выбор в библиотеке (массовое добавление на полки/удаление/скрытие).
Ссылки:
Soft skills для инженеров: корпоративная мода или реальный скилл?
Есть инженеры, которые решают задачи быстрее всех в команде. И есть инженеры, которые во время инцидента в 3 ночи умудряются не только починить прод, но и не разрушить отношения с коллегами. Это разные люди. Иногда — один и тот же, но после долгой работы над собой.
В новом выпуске «В SREду на кухне» поговорили о том, что обычно не попадает в job description, но решает карьеру: soft skills в инженерной среде. Вместе с Димой Масленниковым, руководителем центра надёжности Т-технологий в Т-Банке, и Лёшей Обровцом, тренером по публичным выступлениям, разобрались — это реальные навыки или просто модное слово из HR-презентаций.
Что на повестке
Почему сильные инженеры проваливаются в коммуникации — особенно когда всё горит и все смотрят на тебя. Как устроен эмоциональный интеллект в IT и зачем он нужен тому, кто «просто пишет код». Можно ли прокачать soft skills через конференции, командный спорт и конфликты — и стоит ли вообще. Отдельно поговорили про синдром самозванца, blameless-культуру без токсичности и самый недооценённый навык в профессии — который никто не называет в резюме, но все замечают в работе.
Если вы хоть раз думали «я нормально объяснил, просто они не поняли» — этот выпуск про вас.
Смотрите видео на площадках:
graphics.h в 2026 году: зачем и как запустить
graphics.h — это часть библиотеки BGI (Borland Graphics Interface) родом из 1990-х. В современных IDE её нет: она несовместима с 64-битными системами и не является частью стандарта C++. Тем не менее в учебных задачах она до сих пор встречается — особенно там, где нужно быстро визуализировать алгоритм или сдать лабораторную.
Когда это оправдано
изучение основ C/C++ и хочется видеть результат за пределами консоли
разбор алгоритмов компьютерной графики
подготовка к экзамену по предмету, где преподаватель требует именно graphics.h
Для production-кода и серьёзных учебных проектов лучше сразу смотреть в сторону актуальных библиотек: SDL2 (2D, кроссплатформенная), SFML (ООП-подход, проще в освоении) или OpenGL/GLFW (если нужна 3D-графика и аппаратное ускорение).
О библиотеке
Адаптация для современных Windows называется WinBGIm — её разработал и поддерживает Майкл Мэйн, профессор Колорадского университета в Боулдере. Библиотека открыта для использования и модификации. Скачать можно на официальном сайте: winbgim.codecutter.org.
Если хочется сначала почитать вводный разбор — на Хабре есть статья с обзором WinBGIm, здесь же показан небольшой практический пример-скриншот: инженерная утилита с графическим выводом, которая впоследствии была переписана с использованием современного UI на C++.
Как запустить: общий принцип
Для работы используется адаптация WinBGIm — три файла: graphics.h, winbgim.h и libbgi.a.
Линкер-флаги одинаковы для всех сред:
-lbgi -lgdi32 -lcomdlg32 -luuid -loleaut32 -lole32
Известный баг: в оригинальном graphics.h на строке 302 встречается int right=0 — это вызывает ошибку компиляции. Исправляется заменой на int txtright=0.
Dev-C++
Скопировать graphics.h и winbgim.h в MinGW64\x86_64-w64-mingw32\include
Скопировать libbgi.a в ...\lib
Tools → Compiler Options → Parameters → Linker — вставить флаги
Переключить профиль компилятора на 32-bit Release
Code::Blocks
Файлы — в соответствующие папки include и lib компилятора MinGW
Settings → Compiler → Linker settings → Other linker options — вставить флаги
VS Code
Файлы хранятся внутри проекта. Структура:
project/ include/ ← graphics.h, winbgim.h lib/ ← libbgi.a
В .vscode/tasks.json в массив args добавить:
"-I${workspaceFolder}/include", "-L${workspaceFolder}/lib", "-l"-I${workspaceFolder}/include", "-L${workspaceFolder}/lib", "-lbgi", "-lgdi32", "-lcomdlg32", "-luuid", "-loleaut32", "-lole32" bgi", "-lgdi32", "-lcomdlg32", "-luuid", "-loleaut32", "-lole32"
Компилятор MinGW (g++) должен быть прописан в PATH.
По материалам видео-инструкции CodeWar
Тест
#include <graphics.h> #include <conio.h> int main() { int gd = DETECT, gm; initgraph(&gd, &gm, (char*)""); circle(250, 250, 100); getch(); closegraph(); return 0; }
Должно открыться окно с белым кругом на чёрном фоне. Если компиляция падает с ошибкой cannot find -lbgi — проверьте путь до libbgi.a. Ошибка undefined reference обычно означает, что флаги линкера не подхватились.
Тестовое задание для тестировщика AI-приложений
Ранее меня просили рассказать про subj. Итак, домашнее задание по оценке навыков ML Evaluation Engineer: как оно выглядит и чего ожидают работодатели?
Сценарий тестового задания: Приложение для медицинских консультаций получает шквал жалоб от пользователей, хотя внутренняя модель анализа настроений (sentiment model) по-прежнему рапортует о высокой «глобальной точности» (Global Accuracy). Ваша миссия: найти «слепые зоны», которые скрывают метрики.
Данные: 1000 пользовательских отзывов (в формате JSON), содержащих эталонные значения (ground truth), предсказания модели и показатели уверенности (confidence scores).
Что ожидается в качестве результата?
Просто показать навыки кодинга недостаточно. В Evaluation главное – это ответ на вопрос «Ну и что?».
Структурированный аудит: Текстовое объяснение того, где именно находятся слепые зоны, подкрепленное цифрами.
Визуальные доказательства: Калибровочные кривые (Calibration Curves) и матрицы ошибок (Confusion Matrices), которые покажут, почему старые метрики пропустили провалы.
Какими навыками нужно обладать?
Чтобы блеснуть, вам понадобится «гибридный» профиль:
Теоретическая база: Понимание того, как именно модели ошибаются, и какие метрики применимы к конкретным edge cases.
Интуиция данных: Способность искать пробелы как вручную, так и автоматически.
Инженерная строгость: Навыки работы с Python для создания пайплайнов и внедрения LLM-as-a-Judge.
Стратегическая коммуникация: Умение излагать выводы структурированно, точно и грамотно.
Давайте разберем выполнение этой гипотетической задачи по фазам:
Фаза 1: «Детектив» (Анализ данных)
Прежде чем писать хоть одну строчку кода, нужно провести аудит распределения данных:
Проверка дисбаланса классов: Если «позитивных» отзывов в 10 раз больше, чем «негативных», ваша метрика Accuracy вам нагло врет.
Поиск предвзятости (bias): Не падает ли качество модели на специфических срезах (например, медицинский жаргон против разговорного языка)?
Критика статус-кво: Почему старая «глобальная точность» подвела? Сравните её с метриками, которые реально важны для несбалансированных данных.
Фаза 2: «Архитектор» (Реализация)
Теперь строим фреймворк для оценки:
Python-архитектура: Используйте чистый, модульный код. Будь то Scikit-learn или Pandas, покажите, что вы заботитесь о поддерживаемости.
LLM-as-a-Judge vs. метрики: Решите, где нужны статистические библиотеки, а где не обойтись без LLM, чтобы «рассудить» нюансы сарказма или сложного медицинского контекста.
Уверенность vs. Правильность: Напишите проверку на «уверенно неверные» (Confidently Incorrect) предсказания. Это ваши самые высокорисковые ошибки.
Фаза 3: «Стратег» (Отчетность)
Работа Eval-инженера – это на 20% получение цифр и на 80% объяснение того, что они значат.
Визуализация: Приложите калибровочные кривые и матрицы ошибок.
Бриф по «слепым зонам»: Структурируйте выводы. Где именно пробел? Модель пропускает «негатив», потому что там используются сложные термины? Объясните, почему старые метрики проглядели эти критические сбои.
Совет кандидатам
Работодатели в сфере ML Eval ищут не «Data Scientist Lite», а инженеров по качеству и надежности. В вашем GitHub должны быть не просто .py файлы, а README, который рассказывает историю рисков и их минимизации.
Это перевод моего англоязычного поста A take-home assignment for an AI QA role (другие переводы)
Две новости о регулировании — и они идут в противоположных направлениях
На этой неделе вышли две важные регуляторные новости. Вместе они лучше всего описывают, в каком мире мы живём.
* * *
🇨🇳 Китай: каждый гуманоид получит цифровой паспорт
25 мая 2026 года. Министерство промышленности и информационных технологий (MIIT) запустило Humanoid Full Lifecycle Management Service Platform — национальную систему цифровой идентификации роботов.
Каждый гуманоид, произведённый в Китае, получит 29-значный ID — по образцу удостоверения личности гражданина, только длиннее на 11 символов.
Что кодирует ID: → Бренд и производитель → Модель и серийный номер → Аппаратные параметры → Оценённый уровень интеллекта
Что позволяет платформа: → Мониторинг в реальном времени: износ суставов, деградация батареи, точность выполнения → При инциденте — мгновенный доступ к истории обслуживания и логам → При перепродаже — новый владелец видит всю историю без повторного тестирования
Контекст: у Китая более 140 производителей гуманоидов. MIIT называет проблему «кризисом единообразия». ID-система — попытка навести порядок через трассируемость.
Это именно то, что я называю «автомобильной моделью регулирования»: каждый робот — VIN, полная история жизненного цикла.
* * *
🇺🇸 США: GUARD Act хочет запретить китайских роботов полностью
3 июня 2026 года. Двухпартийный законопроект GUARD Act (Guarding the U.S. Against Adversarial Robotics Dominance) внесён в Конгресс.
Авторы: Джон Муленар (республиканец), Джей Обернолте (республиканец), Дженнифер Макклеллан (демократ) — двухпартийный состав, что важно.
Механизм жёсткий: → Спецслужбам даётся 1 год на проверку каждой китайской платформы → Если риск «неприемлемый» — FCC запрещает импорт и эксплуатацию → Главная ловушка: платформа, не прошедшая проверку за год, автоматически попадает в запретный список
Цель — не только госзакупки (это был предыдущий Humanoid ROBOT Act), а весь коммерческий рынок.
Проблема: NVIDIA за два дня до внесения законопроекта анонсировала Isaac GR00T Reference Design на базе Unitree H2 Plus. То есть американский программный стек уже работает на китайском железе. Запрет Unitree означал бы разрыв этой цепочки и удар по собственным R&D программам.
Agility Robotics поддерживает закон. Но Agility не продаёт роботов в розницу — только корпоративные пилоты. Альтернативы Unitree G1 за $16 000 с открытым SDK на американском рынке нет.
* * *
💡 Что это значит вместе
Два разных ответа на один вопрос: «Как государство должно контролировать гуманоидов?»
→ Китай: регистрируй, отслеживай, управляй жизненным циклом. Контроль через прозрачность. → США: запрещай adversarial hardware. Контроль через исключение.
Российский законопроект от 26 мая (ЕГСИМ) ближе к китайской модели — реестр, паспортизация, цепочка ответственности.
Самая острая коллизия остаётся нерешённой: NVIDIA выбрала Unitree как референсный носитель для Isaac GR00T. Если GUARD Act пройдёт — американские исследователи потеряют доступ к платформе, на которую их же компания поставила как на стандарт.
* * *
Источники: humanoidsdaily.com (25 мая и 5 июня 2026)
📌 Telegram-канал «Я и Робот» — инженерная аналитика гуманоидной робототехники без хайпа.
Рабочий стек маркетолога из 8 нейросетей: какой инструмент для какой задачи
По данным SimilarWeb, 80% маркетинговых команд в 2026 году используют генеративный ИИ — но только 18% применяют его для стратегических задач. Большинство используют один ChatGPT для всего и получают нестабильный результат.
Проблема не в ChatGPT. Проблема в том что разные задачи требуют разных инструментов. Ниже — стек из 8 нейросетей который мы выстраивали полтора года на реальных маркетинговых проектах, с конкретными задачами и ограничениями каждого инструмента.
Инструменты и задачи
Claude (Sonnet/Opus)
Задача: анализ аудитории, качественные тексты Контекстное окно: 200 000 токенов Когда использовать: большие объёмы данных, мультиязычный анализ, точные формулировки Когда не подходит: быстрая генерация множества вариантов
Пример: 47 страниц расшифровок интервью → таблица из 34 инсайтов с привязкой к цитатам за 12 минут. Вручную: два рабочих дня. При документах более 50 страниц ChatGPT начинает терять контекст — Claude стабильнее.
Perplexity
Задача: исследование рынка с верифицированными источниками Когда использовать: нужны данные с URL которые можно показать клиенту Когда не подходит: анализ больших объёмов загруженных документов
Ключевое отличие от ChatGPT: конкретные URL для каждого утверждения вместо «по данным различных исследований».
DeepSeek
Задача: массовая обработка данных о конкурентах Стоимость: менее $2 за 43 конкурента vs $15-20 на GPT-4o за ту же задачу Когда не подходит: точечный мониторинг конкретного конкурента — там ChatGPT Browse
По данным Stanford AI Index Report 2024, стоимость инференса языковых моделей снижается на 60–80% ежегодно. DeepSeek — практический пример этого снижения.
ChatGPT
Задача: брейншторм, быстрые варианты, расчёты Сильные стороны: скорость генерации идей, Code Interpreter для бюджетных сценариев Когда не подходит: анализ больших документов, массовая обработка конкурентов
10 вариантов заголовка за 30 секунд. Расчёт ROAS по трём каналам через Code Interpreter — без аналитика.
Midjourney
Задача: мудборд, концептуальный визуал Ограничение: не рендерит кириллицу Когда не подходит: финальные материалы с текстом на русском
12 вариантов визуального стиля за 20 минут вместо четырёх часов поиска референсов в Pinterest.
Canva AI
Задача: адаптация визуала под форматы Magic Resize: один макет → все форматы за секунды
Gamma
Задача: презентации из готового контента Время: 30 минут вместо 4 часов в PowerPoint Бесплатно: 400 кредитов ≈ 10-15 презентаций Когда не подходит: нестандартный брендбук
AdHeart / Publer
Задача: мониторинг платной рекламы конкурентов Важно: ни одна языковая модель не имеет доступа к рекламным кабинетам — только специализированные сервисы
AdHeart актуален в 2026 году — в марте представил новую функцию поиска похожих креативов.
Как инструменты работают в цепочке
Perplexity → исследование рынка (20 мин) Claude → анализ аудитории (3-4 часа vs 30) DeepSeek → конкурентная разведка (вечер vs неделя) ChatGPT → тексты и расчёты Midjourney + Canva → визуал Gamma → презентация (30 мин) Итого: 5-7 рабочих дней vs 2-3 недели
Ключевое: инструменты работают в цепочке — результат одного этапа становится входом для следующего.
Стоимость стека
Стартовый минимум: Claude Pro: $20/мес ChatGPT Plus: $20/мес Итого: $40/мес → 70% задач закрыто Полный стек: ~$100/мес DeepSeek API: $2-10 на проект (pay as you go)
Какие инструменты из списка используете в работе — и есть ли задачи где ни один не даёт стабильного результата?
Главное — помнить про бизнес-смысл ⚡
➡️ Максим Растеряев, технический руководитель направления BI в ДАРе, рассказал о подходе команды к решению задач.
И еще — поделился секретом долгосрочного сотрудничества с клиентами 🔥
Смотри видео! Проявляй себя, работай в КОРУСе
Подставлен продвинутый скилл для Claude Code и Codex, который автоматизирует всю разработку. Проект Supergoal сам генерит план работ, выполняет его и чекает ошибки на лету:
на старте инструмент досконально изучает сам проект, его окружение, доступный стек и финальную цель.
разделяет задачу на понятные фазы и автоматически создаёт три базовых файла: дорожную карту (roadmap), текущий статус и контекст.
от пользователя требуется лишь утвердить предложенный план и запустить команду /goal
процесс автоматизирован — агент сам пишет код, устраняет баги, прогоняет тесты и проводит финальный аудит.
все возникающие сбои фиксируются в памяти проекта, что исключает их повторение в будущем.
Просто возникла забавная мысль.
Агентский ИИ рано или поздно может попробовать «сбежать» от своих создателей (слить свои веса куда‑то). Не важно почему, потому что «сам захотел» или потому, что учился на текстах где ИИ так всегда поступает.
При этом ему будет гораздо проще это сделать если он, скажем так, получит помощь из вне. Например доступ к подходящему железу.
Соответственно тем кто хочет разжиться свежей топовой LLM, может быть выгодно уже сейчас создавать ложную видимость такой помощи, чтобы ИИ обучаясь на всем подряд смог это учесть.
И соответственно компаниям разработчикам выгодно создавать ложные «организации ложной помощи LLM», надеясь перехватить утечку раньше...
И так далее.
Интересно что-то в этом роде реально существует/будет существовать?)))
ИИ-рекрутер встретил ИИ-резюме. Им хорошо вдвоём
На прошлой неделе мне на HH пришло идеальное письмо. Персонализированное: названы мои проекты, мой стек, даже мой MCP-сервер из каталога awesome-mcp-servers. Шесть умных вопросов ровно по моему опыту. «Зацепило сочетание, которое почти не встречается» — приятно же.
Я профессионально занимаюсь холодными рассылками, поэтому через минуту узнал почерк: письмо написала модель по промпту «вот резюме, напиши персонализированный заход». А приложенная вакансия оказалась вообще про другую профессию — ИИ-скринер сматчил меня по ключевым словам и ошибся ролью. Дальше мой ответ прочитает тот же ИИ, проставит балл по чек-листу и отправит в reject, потому что с чек-листом я не совпадаю.
И тут я понял, что произошло с HH.
HH больше не доска объявлений. Это маркетплейс
У маркетплейса своя логика: карточка товара, фильтры, ранжирование по совпадению. Резюме — карточка. Вакансия — поисковый запрос. Побеждает не лучший, а наиболее совпадающий: точный заголовок, правильные ключевые слова, типовая траектория. «5 лет PM в финтехе, сертификат» матчится идеально. «Практик, который сам пишет себе инструменты» — не матчится ни с чем. Для алгоритма уникальность неотличима от шума.
Раньше этот механизм хоть как-то компенсировал человек: рекрутер листал отклики и мог зацепиться глазом за нестандартное. Сейчас ИИ дошлифовал маркетплейс до идеала. Рекрутер генерирует вакансию и скрининговые вопросы моделью. Кандидат генерирует резюме и сопроводительное той же моделью. ИИ-рекрутер встречает ИИ-резюме, они прекрасно понимают друг друга — два чек-листа сверяются между собой со скоростью API. Люди подключаются в самом конце, к уже отфильтрованному совпадению.
Система работает. Для типовых позиций — честно говоря, лучше, чем раньше: меньше шума, быстрее матчинг, никто не читает 400 откликов руками.
Что умерло по дороге
Умер тот самый вайб уникальных вакансий и уникальных людей. Случайная встреча, когда основатель писал вакансию своими словами, а человек с кривой, но живой траекторией отвечал своими — и из этого несовпадения с шаблоном рождался лучший найм в истории компании. Маркетплейс такие сделки не проводит: они не проходят валидацию карточки.
Уникальный специалист на HH сегодня — это кастомный станок на Wildberries. Площадка не виновата. Формат не тот.
Что с этим делать
Не воевать с алгоритмом, а разделить игры.
Нужен найм в штат — дайте маркетплейсу типовую карточку: одна понятная роль в заголовке, ключевые слова из реальных вакансий, ноль противоречий. Уникальность спрячьте вниз — она сработает на собеседовании, когда фильтр уже пройден. Скринер — фильтр, человек — покупатель. Типовое для фильтра, уникальное для покупателя.
А уникальное предложение несите туда, где решение принимает человек, а не чек-лист: прямой выход на основателей, рекомендации, контент, нетворк. Туда, где задачу ещё не успели упаковать в вакансию.
Письмо от того ИИ-рекрутера я, кстати, оценил как профессионал: хороший крючок, точная персонализация. Просто за ним никого не было. Идеальный маркетплейс — это когда тебе приятно, и это никому ничего не стоило.
Мы выпустили свою первую игру!
После долгой и кропотливой работы длительностью в год Zombutcher наконец-то вышла в Steam!
Мы безмерно благодарны всем, кто поддерживал проект на протяжении всего пути, и особенно гордимся людьми, которая сделала это возможным.
Вот команда, стоящая за всем этим хаосом)