Люблю современные технологии и радостно слежу, как они отвоевывают у мироздания очередной кусочек тьмы неведения и освещают его своим сиянием компьютерного разума. Вот и сейчас не могу не умилиться. Подруга купила робота для ноготочков. Это чудо называется O Nail. Предназначено для создания маникюра.
Обычно машинки для маникюра - это что-то вроде бормашины, прости ее Боже. Мастера маникюра пилят клиентам ногти и только от их мастерства зависит, уйдёт ли их клиентка из салона с руками, спиленными по локти, или в этот раз обойдётся.
Если без шуток, то вот эта конкретная малышка для маникюра размером с паспорт 🪪. Она может пилить ногти на аккумуляторе и без проводов, весь день. Звук от нее примерно как от робота пылесоса на подзарядке, очень тихий. И самое главное - внутри чип, который распознаёт скорость вращения фрезы (фреза - это сверло, вот на этих продолговатых штуках, они называются ручки). И этот механизм в зависимости от силы нажатия регулирует скорость вращения.
То есть, если у тебя жёсткая кожа на пятке, а мастер давит на фрезу, чтобы спилить твой пяточный мозоль, то этот чип анализирует твердость твоей кожи, силу нажатия и скорость вращения. И автоматически понижает обороты.
Судя по инфо в интернетах, у O Nail ещё много таких аппаратов: одни для сушки ногтей, другие для поглощения пыли и т д. И все с искусственным интеллектом, так или иначе. Например, в лампе для сушки маникюра диоды на контроллере, которые УФ-излучением вредным светят только на ногтевую пластину, но не на кожу… и так далее.
Пока другие складывают доски, мы запускаем следующий сезон Capture the Flag. Волны принесут новый формат. Что будем делать:
🔴 Исследовать системы и искать флаги 🔴 Решать задачи разного уровня: для профи, новичков и даже школьников (от 14 лет) 🔴 Соревноваться в мастерстве поиска уязвимостей
Скоро расскажем подробно про формат нового запуска: точно будет интересно! Занимайте в своём календаре дату 25 апреля — и регистрируйтесь на нашем сайте.
Представляем Clouden — платформу для единого управления гибридной и мультиоблачной инфраструктурой ⭐️
Продукт создан на базе платформы BILLmanager Enterprise и расширяет её возможности в сторону комплексного контроля над виртуализацией, физическими серверами и множеством публичных облаков через единый интерфейс.
Clouden отвечает на ключевой запрос рынка — необходимость единого управления разнородными средами, включая физические серверы, различные платформы виртуализации и публичные облака. Платформа решает главную задачу бизнеса, трансформируя сложную разрозненную инфраструктуру в управляемую систему. Clouden предоставляет единое окно для контроля, автоматизации и оркестрации всех ресурсов, превращая процесс запроса и выдачи ИТ-услуг в быструю, стандартизированную операцию.
«Рынок созрел для решений, которые не навязывают свою экосистему, а гибко объединяют уже имеющиеся у компании технологии, — отмечает Павел Гуральник, генеральный директор ISPsystem (входит в «Группу Астра»). — Clouden — это логичное развитие нашей экспертизы и платформы BILLmanager. Основная задача Clouden — дать бизнесу и госсектору единый пульт управления для всей существующей ИТ-инфраструктуры: своих серверов, различных платформ виртуализации, российских и зарубежных облаков. Это позволяет ускорять цифровые проекты за счет полной управляемости и прозрачности».
✔️ Платформа Clouden относится к категории CMP (cloud management platform) решений и обеспечивает сквозную автоматизацию, встроенную BI-аналитику для прогнозирования затрат, портал самообслуживания и гибкую систему тарификации.
Готовы протестировать возможности Clouden? Выберите любой удобный способ знакомства на странице продукта!
Go vet не поможет! Статический анализ Golang проектов с помощью PVS-Studio
На нем написан Docker, Kubernetes, Gitea и многие другие проекты самых разных масштабов. Наверное, вы догадались, что речь идёт о Go. Мы никогда не писали об ошибках на Golang проектах, но настало время это исправить, ведь скоро выйдет анализатор PVS-Studio для Go!
Статические анализаторы являются довольно распространёнными инструментами в разработке. В Golang есть встроенный механизм статического анализа — go vet. Однако стандартные линтеры не всегда справляются. Для тех, кто с нами не знаком, мы — компания PVS-Studio, занимаемся разработкой одноименного статического анализатора для C, C++, C# и Java. В последнее время мы активно занимаемся разработкой анализатора для Go и уже скоро планируем выпустить открытую бета-версию.
Зима в разгаре, а мы нанимаем: новые вакансии в SSP SOFT
Кто мы и чем занимаемся? Лидеры («одни из», конечно) найма ИТ-специалистов на российском рынке— за прошлый год мы наняли 179 сотрудников, и уже в январе 2026 к нам присоединились 11 новых гуру! Занимаемся заказной разработкой ПО и предоставляем крупным клиентам выделенные команды на ИТ-аутсорсинг.
У нас новый московский офис, который открылся в 2025 году у самой Красной площади! А еще есть вакансии в офис в Томске и на удаленку из любой точки России.
Команда в SSP SOFT — это реальные проекты, дружная атмосфера, где работать — продуктивно, без выноса мозга и микро-менеджмента. В январе 2026 ищем опытных спецов, кто готов в новое профессиональное будущее вместе с нами.
Что предоставляет экосистема SSP SOFT: ✅ Мы пишем код, который формирует завтрашний день. Никакой скучной рутины. ✅ Центр компетенций и личное менторство ускорят развитие до максимума. ✅ Офис, гибрид или фулл-удаленка? Есть все варианты. ✅ Время — ваш ресурс. Мы его уважаем.
Подробности о вакансиях читайте на нашей странице ХХ.ру, но туда откликаться необязательно. Ждем резюме в ЛС нашей HR Lead Алине (https://t.me/AONikitina). Не забудьте добавить «секретную фразу» в сопроводительное письмо, «Увидел(а) вашу вакансию на Хабре».
Желаем всем хабровцам успешной карьеры в 2026 году 🚀)
Как развивать документацию и продвигать техписателей
В продуктовой команде документацией пользуются все, но ожидают от нее разного. Аналитику важно одно, разработчику — другое, поддержке — третье. Если не учитывать контекст, можно бесконечно что‑то улучшать и все равно не попадать в цель.
Даша, технический писатель Naumen SMP, рассказала о том, как через коммуникацию с командой она разбиралась в реальных ожиданиях от документации и выстраивала направление ее развития.
С чего вообще началась эта работа и какую задачу вы перед собой ставили?
Мы начали с целей. Во‑первых, хотелось сформировать понятное представление о роли технических писателей внутри команды. Во‑вторых — понять, чего заказчики действительно ждут от документации.
Как вы к этому подошли на практике?
Первым шагом мы составили каталог услуг технических писателей. Если ты хочешь, чтобы коллеги понимали твою роль, важно сначала самим зафиксировать, что именно ты делаешь и в каком объеме.
Еще мы выделили ключевых заказчиков и сгруппировали их. Это были аналитики и руководители продуктов, разработчики и тестировщики, поддержка, инженеры инфраструктуры, коллеги из маркетинга и дизайна. Благодаря этому вместо 51 интервью получилось провести 19, этого оказалось достаточно.
Как проходили интервью и что оказалось самым сложным?
Мы начинали с обсуждения каталога услуг. Потом говорили о проблемах с документацией и процессами, а в конце проверяли наши гипотезы.
Сложнее всего было работать с эмоциональными запросами. Потому что важно не останавливаться на эмоции, а докапываться до сути. Очень помогал метод «5 почему»: позволяет превратить раздражение в конкретное и решаемое требование.
Что получилось после обработки всех интервью?
Мы сгруппировали потребности и получили 12 направлений. Самые заметные — это нехватка понимания роли технических писателей, запрос на обновление интерфейса документации и очень сильная боль у разработчиков по поводу документации по API.
Как вы поняли, за что браться в первую очередь?
Использовали простой фреймворк приоритизации «ценность / усилия». Смотрели не только на то, как часто звучит проблема, но и на силу боли. Поэтому, например, поиск в документации стал приоритетнее аналитики — о нем говорили реже, но намного острее.
Какие результаты уже есть?
Мы собрали регламенты и знания о работе технических писателей в одном месте, сделали публичный каталог услуг, обновили интерфейс документации вместе с дизайнерами и разработчиками, а документацию по API переработали совместно с командой разработки: улучшили навигацию и примеры.
Твой главный вывод из этого опыта?
Документация развивается не сама по себе: она развивается через диалог. Коммуникация помогает не только улучшать тексты, но и выстраивать понимание роли, ожиданий и зон ответственности. Когда это появляется, становится проще принимать решения и двигаться дальше и в документации, и в продукте.
После запуска лендинга начали прилетать первые заявки. И в какой‑то момент у меня возник вопрос: а если вообще к ним не прикасаться и посмотреть, что будет, если агент, как заявляют, может сам автономно работать, то пусть уже и обработкой лидов занимается
Собрал простую логику:
Заявка с формы падает на почту.
Каждые 15 минут агент сам идёт в inbox и смотрит новые письма.
Достаёт из письма имя, email и компанию.
Гуглит информацию о компании: чем занимаются, сколько людей, чем живут.
Ставит оценку лида от 1 до 10 по тем критериям, которые мы раньше прописали, когда думали над лендингом.
Если 5 и выше сам отвечает, предлагает созвон, задаёт пару уточняющих вопросов и продолжает диалог. Ниже 5 — кидает в «низкий приоритет».
То есть задача: не просто разложить письма по папкам, а реально принять решение и начать общаться вместо меня.
Что в итоге с заявками? Честно? ничего эпичного. В какой‑то момент просто закончились токены API, и бот тихо умер. Это был эксперимент, я не следил за потолком по бюджету, поэтому всё остановилось не потому что «технология не работает», а потому что я забил на настройки.
Минусы Clawdbot
Цена эксперимента. Около $400 за Claude API за одну неделю для теста это перебор. Для боевого кейса, где один лид стоит дорого, уже не так страшно. Но если нормально конфигурировать (дешёвые модели на рутину, лимиты по токенам и т.д.), это можно ужать до $100–150 в месяц и ниже.
Галлюцинации. Он несколько раз придумывал вещи, которых не было: размеры компаний, инструменты, цифры. Я это пока не воспринимаю как «всё, выкидываем», потому что большая часть проблемы в архитектуре памяти и контекста: как он хранит свои знания, как к ним обращается. Это нужно чинить именно на уровне архитектуры агента, а не в промпте.
На выходных хочу показать на видео, как это вообще поднять с нуля на облаке и настроить под свои задачи, если вы не технарь. Если у вас есть вопросы напишите, постараюсь ответить на видео и показать.
P.S Если нужен готовый Product Discovery Agent, с которым я это всё гонял, напишите, выложу.
Мой Телеграм канал, кстати на 15 февраля запланирован бесплатный воркшоп по вайбкодингу, записаться там же в тг.
OAuth на практике: что оказалось удобным, а что отпугнуло пользователей
Мы запустили молодую платформу с двумя типами аккаунтов: обычные пользователи и разработчики (публикуют PWA и управляют приложениями).
Бренда и доверия пока нет, поэтому вопрос авторизации быстро стал не техническим, а психологическим.
С чего начали
Для обычных пользователей: • Email / пароль • Google • GitHub
Для разработчиков — жёстче: • Обязательная привязка Google • Обязательная привязка GitHub
Логика казалась разумной: «Разработчик = есть GitHub» «Двойная верификация = меньше спама»
На практике это не сработало.
Первые тревожные сигналы
Регистрация разработчиков шла крайне медленно, несмотря на интерес к публикации приложений.
Сначала списывали на: • новый продукт • низкое доверие • отсутствие аудитории
Но после общения с разработчиками (в том числе через Habr) картина прояснилась.
Что отпугивало разработчиков
Новый сервис → нежелание делиться данными
Даже если это «просто email», психологический барьер остаётся.
Когда с первого шага нужно: • линковать внешние аккаунты • проходить несколько этапов подтверждения • подключать сторонние сервисы
это воспринимается как лишний фрикцион.
Особенно для соло-разработчиков и небольших команд.
Git ≠ GitHub
Ключевой инсайт.
Мы обнаружили, что: • не все хотят логиниться через GitHub • часть использует GitLab или Bitbucket • некоторые принципиально не хотят связывать GitHub с новым сервисом
Обязательная привязка GitHub стала серьёзным барьером.
А мнение стандартных пользователей разделилось:
Часть говорила:
«Чем больше OAuth-кнопок, тем солиднее выглядит платформа».
Логика простая: • если есть Google / Facebook / Discord — значит не ноунейм • интеграции с крупными сервисами повышают доверие
Это не про безопасность — это про ощущение легитимности.
Другие говорили ровно противоположное:
«Слишком много кнопок — ощущение перегруженности».
И это тоже справедливый аргумент.
Что мы изменили
Упростили форму для пользователей
Оставили: • Google • Facebook • Discord
Достаточно выбора для доверия, без визуального шума.
Git-провайдеры вынесли в отдельную группу
Под отдельной кнопкой: • GitHub • GitLab • Bitbucket
Для разработчиков это стало понятнее и логичнее.
Убрали обязательный GitHub
Теперь для developer-аккаунта нужно подключить любой Git-аккаунт, если ни один не подключён.
Без принудительного GitHub.
Первые цифры (осторожно)
Прошла всего неделя, выборка маленькая, платформа всё ещё молодая.
Тем не менее: • Зарегистрированные пользователи: +13% (было 0–6% в неделю) • Зарегистрированные разработчики: +16% (было 0–3%)
Похоже, это те разработчики, которые знали о платформе, но их останавливало требование GitHub.
Выводы (пока не финальные) • OAuth — это не только безопасность, но и психология доверия • Жёсткие требования на старте почти всегда бьют по росту • Git ≠ GitHub — и это важно • Много провайдеров могут как повышать доверие, так и перегружать UI
Для молодой платформы даже такие ранние сигналы уже показательны.
Интересно услышать опыт коллег: добавляли ли вы OAuth-провайдеров после запуска? были ли случаи, когда обязательная авторизация через конкретный сервис тормозила рост?
Аппаратная виртуализация: как работает и зачем нужна
Виртуальные машины, облачные платформы, миграции без простоя — всё это держится на аппаратной виртуализации. Технология давно стала базой для дата-центров и корпоративных инфраструктур, но вопросы «как именно это работает» и «чем отличается от программной виртуализации» возникают регулярно.
В новом материале разобрали архитектуру аппаратной виртуализации, сравнили полную виртуализацию, паравиртуализацию и виртуализацию с аппаратной поддержкой. Также прошлись по различиям между гипервизорами первого и второго типа, разобрали плюсы и минусы подхода, сценарии применения — от консолидации серверов до облачных IaaS-платформ — и добавили FAQ по безопасности и отказоустойчивости.
Открываем регистрацию на GoCloud 2026 — конференцию про AI и облака 🦾☁️
Уже 9 апреля мы вновь встречаемся на нашей главной ежегодной конференции. В этом году ключевой темой станет AI как сервис — а именно, простые, безопасные инструменты для работы с AI и AI-агентами, которые можно использовать сегодня. Еще поговорим о кибербезопасности, гибридных решениях, трендах в работе с данными и многом другом.
Что вас ждет
4 трека про AI, Data, инструменты разработки и облачную инфраструктуру
40+ спикеров
Демозоны сервисов
Практические воркшопы
Нетворкинг и afterparty
Что узнаете
Какие инструменты позволяют использовать AI без кастомной разработки и долгой настройки
Как бизнес уже работает с AI-системами и какие результаты получает от их внедрения
Тренды в AI, облаках и работе с данными, а также подходы, которые становятся стандартом для бизнеса
Сценарии использования сервисов, готовые инструменты и способы оптимизации затрат в ваших проектах
Как выстраивается полный цикл разработки и доставки с минимальной нагрузкой на команду
Как принять участие
Можно посмотреть трансляцию на сайте (ссылка придет зарегистрированным участникам в письме) или прийти в кинотеатр «КАРО 11 Октябрь», ул. Новый Арбат, 24 в Москве. Собираемся 9 апреля в 10:00. Количество мест для офлайн-участия ограничено. Регистрируйтесь уже сейчас.
👉 Зарегистрироваться на GoCloud 2026 Постепенно будем рассказывать о программе, а пока можете почитать, как прошли предыдущие конференции Cloud.ru:
Может показаться, что начинать изучать программирование поздно — все вакантные места уже заняты другими разработчиками. Но это не так: толковые специалисты нужны всегда и везде, поэтому начать никогда не поздно.
Если не знаете какой язык выбрать, присмотритесь к одному из самых популярных — к C++. Он хорошо подходит для системного и прикладного программного обеспечения, игровых движков, финансовых технологий, высоконагруженных сервисов, встраиваемых систем и всего, где важна скорость и эффективность.
Для вашего удобства мы собрали учебные программы по C++ в одном месте — на Хабр Карьере, а сегодня предлагаем познакомиться с основными инструментами, которые вам предстоит освоить, чтобы стать опытным разработчиком:
— С++. Основа основ: язык программирования с высокой производительностью.
Краткий обзор применяемых материалов и процессов изготовления гибких плат, которые требуют изменения подхода к проектированию. Рассмотрим конкретные примеры дизайна меди, покрывной пленки, краевых разъемов, обработки контура и панелизации.
Участие — традиционно бесплатное по предварительной регистрации
После запуска лендинга начали прилетать первые заявки. И в какой‑то момент у меня возник вопрос: а если вообще к ним не прикасаться и посмотреть, что будет, если агент, как заявляют, может сам автономно работать, то пусть уже и обработкой лидов занимается
Собрал простую логику:
Заявка с формы падает на почту.
Каждые 15 минут агент сам идёт в inbox и смотрит новые письма.
Достаёт из письма имя, email и компанию.
Гуглит информацию о компании: чем занимаются, сколько людей, чем живут.
Ставит оценку лида от 1 до 10 по тем критериям, которые мы раньше прописали, когда думали над лендингом.
Если 5 и выше сам отвечает, предлагает созвон, задаёт пару уточняющих вопросов и продолжает диалог. Ниже 5 — кидает в «низкий приоритет».
То есть задача: не просто разложить письма по папкам, а реально принять решение и начать общаться вместо меня.
Что в итоге с заявками? Честно? ничего эпичного. В какой‑то момент просто закончились токены API, и бот тихо умер. Это был эксперимент, я не следил за потолком по бюджету, поэтому всё остановилось не потому что «технология не работает», а потому что я забил на настройки.
Минусы Clawdbot
Цена эксперимента. Около $400 за Claude API за одну неделю для теста это перебор. Для боевого кейса, где один лид стоит дорого, уже не так страшно. Но если нормально конфигурировать (дешёвые модели на рутину, лимиты по токенам и т.д.), это можно ужать до $100–150 в месяц и ниже.
Галлюцинации. Он несколько раз придумывал вещи, которых не было: размеры компаний, инструменты, цифры. Я это пока не воспринимаю как «всё, выкидываем», потому что большая часть проблемы в архитектуре памяти и контекста: как он хранит свои знания, как к ним обращается. Это нужно чинить именно на уровне архитектуры агента, а не в промпте.
На выходных хочу показать на видео, как это вообще поднять с нуля на облаке и настроить под свои задачи, если вы не технарь. Если у вас есть вопросы напишите, постараюсь ответить на видео и показать.
P.S Если нужен готовый Product Discovery Agent, с которым я это всё гонял, напишите, выложу.
Мой Телеграм канал, кстати на 15 февраля запланирован бесплатный воркшоп по вайбкодингу, записаться там же в тг.
Интуиция — плохой советчик, когда на кону бюджет в миллионы. Выбор технологического стека, подрядчика или стратегии развития часто превращается в «битву мнений». Побеждает тот, кто громче, а не тот, кто прав. Результат: внедрение ради внедрения, скрытые косты и проваленные сроки.
Роль Agile Coach мертва… да здравствует агент изменений
TL;DR Роль Agile Coach должна умереть, чтобы переродиться в роль Change Agent (или Organizational Architect). И работать такие спецы должны не "вечно", а проектно - как спецназ внедрения изменений.
Здесь и далее: скрам-мастер и аджайл коуч тождественны.
1. Выделенная роль в команде — это кража ответственности
Постоянно приставленный к команде Agile Coach (или Scrum Master, или Delivery Manager в роли «няньки») - это прямое забирание ответственности у руководителей.
Зачем компания платит продактам и тимлидам хорошие деньги? Наверное, не для того, чтобы кто‑то другой создавал атмосферу безопасности, фасилитировал и работал с людьми.
Если руководитель не умеет управлять динамикой команды — значит, его надо учить, а не ставить ему «костыль» в виде коуча (ну и спрашивать с него соответственно). Соответственно, большая часть работы Agile Coach → Change Agent это обучение тем навыкам, которых не хватает руководителям. Скорее всего в больших организациях уже есть T&D‑отдел, который и занимается обучением. Наша задача состыковать системно прокачивание самых актуальных навыков.
2. Коуч для руководителей и архитектор среды
Роль трансформируется в коуча для руководителей и человека, который проводит изменения (зачастую проектно).
Чаще всего наболее активная часть работы - это движение системы к зрелости через работу с лидами. Агенты по изменениям - архитекторы среды обмена опытом. Даже на разборах ситуаций по хорошему (и когда получается) надо молчать и давать слово коллегам руководителя, даже если знаешь «правильный» ответ. Система должна уметь саморегулироваться, когда нас не будет.
Тут еще есть научная обоснованность: в модели проведения изменений ADKAR доказательно видно как CLARC (people менеджеры) это те, через кого мы проводим изменения.
3. Тест на прочность: «А что, если я уйду?»
Agile Coach делает хорошую работу, если после его ухода система радикально не ломается. Посмотрите, как быстро команды откатываются назад и насколько (например, по метрикам), когда из них убирают скрам‑мастера.
Стабильная привычка, как известно, формируется около 3 месяцев. В зависимости от масштаба изменений вы можете работать 3-6 месяцев и довести команду до определенного целевого состояния.
Нет предела совершенству, но нам с вами не туда: доводить процессы и майндсет до идеальных состояний почти никогда не стоит. Команды после нашего ухода все равно откатятся (и это нормально, главное чтоб не до нуля). С точки зрения всей системы, нам важнее дотягивать другие команды, процессы, взаимодействия, целеполагание до базового и достаточного уровня (который каждая организация определяет сама). Это даст намного более сильный результат по всей организации.
Более того, если долго работать с одной командой - возникает привыкание и порой выученная беспомощность, вы тратите свое время неэффективно. Нужно зайти, настроить, передать ответственность лидам и выйти. А потом трекать (как в настоящем стартапе) - что получается у лидов и команды, что нет - и точечно консультировать.
4. Мы наняты бизнесом, а не командой
Прошли времена раздутых бюджетов, когда можно было плодить «аджайл ради аджайла» чтобы «оптимизировать процессы». В текущих реалиях (особенно с нынешними ставками ЦБ) каждая копейка на счету.
Мы должны уметь драйвить бизнес‑стратегию, будь то организационная трансформация, радикальная смена концепции стартапа, оптимизация костов. И часто команда будет считать, что это «не по аджайлу».
Балансировать перформанс и здоровье команды (например, удовлетворенность, отток, выгорание) - вот это реальная задача, с которой надо помочь руководителям справиться или продумать оркестрацию изменений.
Софт скилы - это новые хард скилы
Управление изменениями, оргдизайн, работа с сопротивлением и сложная фасилитация - язык не поворачивается назвать это «софт скилами». Сейчас это самые настоящие харды. И именно за эти харды бизнес готов платить.
Друзья, 12 февраля проведём открытый вебинар по следам нашего ESB-исследования в «Кругах Громова».
Если коротко — за последний год мы оценили 18 российских интеграционных платформ по единой методологии: 12 категорий, 1 000 баллов. Такого раньше на рынке не было. Результаты местами предсказуемые, местами — неожиданные.
На вебинаре поговорим:
— Почему компании до сих пор путают Kafka, ESB и data pipeline — и платят за это дважды — 5 классов интеграционных решений: когда какой работает, а когда — категорически нет — Как мы строили матрицу зрелости и кто в итоге получил номинацию — Что планируем исследовать дальше — и как повлиять на приоритеты
Будет живой эфир с интерактивом, не просто «говорящая голова».
Кто работает с интеграциями, выбирает платформу или просто в теме — приходите, будет интересно.
Ребята, в свете блокировок Telegram я накидал bash-скрипт который сделает всю магию и поднимет вам прокси за пару минут. На выходе получите адрес прокси и сразу им поделиться с друзьями...
Вы наверное уже видели хайп вокруг OpenClaw (он же Clawdbot) – open-source AI-агент, куча постов в твиттере про него, и тут же волна разоблачений: утечки данных, открытые серверы, дыры в безопасности.
Да, кстати бэкдоры там есть. Не классические, но серые зоны в коде нашёл, клонировал репо и почистил всё руками. Если интересно – расскажу отдельным постом, там любопытная история.
Это AI-ассистент с открытым кодом, который умеет не только отвечать текстом, а выполнять действия. Ты пишешь ему в Telegram обычным языком что нужно сделать. А у него под капотом набор инструментов: он может открыть браузер, зайти на любой сайт, прочитать и отправить почту, создать и отредактировать файл, запустить команду на сервере, поставить задачу по расписанию.
Ты описываешь задачу, а он сам выбирает какие инструменты нужны, сам выстраивает порядок действий, и работает шаг за шагом пока не сделает. Всё это крутится на твоём сервере или компе, 24/7.
Написал «зайди на сайт конкурента, выпиши их тарифы» он реально откроет сайт, прочитает страницу, пришлет таблицу. Написал «проверь почту, если есть заявки разбери» он зайдет в Gmail, посмотрит письма, обработает ну и т.д. насколько хватит фантазии, есть свои но...
Мне было интересно другое: а эта штука вообще что-то полезное умеет?
У меня давно лежал список из идей, наверное всем знакомо это чувство, когда идей много, на каждую нужна неделя+ ресёрча, чтобы понять а надо ли это делать. В одиночку это оверкилл, сидеть по выходным не всегда получается.
В общем я поставил себе этого уникума. Там кстати установка не такая уж и сложная все понятно, единственное я бы не рекомендовал вам устанавливать на свой личный комп, а на рабочий уж тем более.
Запустил, настроил под себя, еще сделал для него инструкции (skills) под свои задачи: что и как выполнять.
И вуаля телеграмме у вас там появляется свой "ИИ друг", который умеет больше чем просто чат гпт. Первым же делом написал ему промпт:
«Вот 10 моих идей для продуктов .... пройдись по каждой найди рынок, определи боль. Если боли нет убей идею. Те что выжили приоритизируй. Для лучшей собери лендинг и подготовь рекламу. Работай сам»
Агент за ночь прошёлся по 7 из 10 идей (на 3 не хватило контекстного окна). Для каждой: нашёл конкурентов через поиск, зашёл на их сайты через браузер, спарсил прайсинг, проанализировал отзывы. Спарсил Редит, ТГ каналы и комменты (неожиданно, такое я в инструкции не писал), выявил боли ЦА собрал табличку с приоритетами.
Три идеи убил сам. Написал: «Нет подтверждённой боли, рынок перенасыщен, не рекомендую тратить время». С аргументами, со ссылками.
Сделал: JTBD интервью на синтетических пользователях, ICE-скоринг гипотез. Приоритизировал и выбрал сам одну гипотезу.
Для идеи-лидера: сгенерировал HTML-лендинг, задеплоил на Vercel одной командой и прислал мне живую ссылку. Написал 5 вариантов объявлений для Яндекс.Директ с ключевыми словами.
С самим Директом через браузер не справился там тяжёлый интерфейс с капчей. Тексты взял его, я кампанию настроил руками.
Запустил рекламу. Настроил агенту, чтоб каждое утро сам проверял статистику, оптимизировал ключи, отключал не релевантные. Присылал мне отчёт.
ИИ агент получил 3 лида через форму обратной связи на лендинге.
Но самое интересное случилось с этими заявками — и об этом в следующем посте.
Спойлер: агент не просто собирал заявки. Он сам их обрабатывал, квалифицировал и отвечал клиентам. Без моего участия.
