Представлена открытая библиотека Telegram-ботов для разных задач Awesome Telegram. Там есть боты: поисковики, интеграторы с сотнями сервисов, для удаления ватермарок, загрузчики видео, аудио и картинок, генераторы картинок, стикеров, текстов, поздравлений. К каждому боту авторы приложили описание работы и инструкцию.
Про вайбкодинг
Я в создании продуктов и продуктовом дизайне уже больше 6 лет
Успел застать эру дизайна интерфейсов и в Photoshop, и в CorelDraw, проектировал UX в AdobeXD, а потом и Figma вышла
Поучаствовал в создании ~15 стартапов — и у нас чаще всего была 1 проблема — разработка.
Разработка стоила дорого во всех смыслах.
Это и прямые затраты — когда уже в процессе и каждый месяц уходят деньги на команду. И opportunity cost — когда идея даже не доходит до старта, потому что "где я возьму на разработчика".
Получается, чтобы создать продукт, у тебя было два пути: либо ты сам/кофаундер разработчик, либо у тебя есть деньги на разработку. Третьего не дано. Идеи без одного из этих условий оставались идеями ☕️
Что привнес вайбкодинг
Любые задачи Junior-уровня сейчас закрываются ИИшкой без проблем. С большими проектами сложнее — там пока люди не научились работать с большим контекстным окном. Но барьер входа упал радикально.
Например, в последнем батче YCombinator у большинства проектов почти весь код AI-сгенерирован. Это не плохо или хорошо, но вот как наблюдение
Что меняется
Время от идеи до работающего продукта сократилось в разы. ИИшка может собрать MVP за 2 дня, тогда как раньше даже простая разработка занимала недели или месяцы. Я до сих пор помню свои стартапы, где мы пилили функционал по 3-4 месяца — хотя сейчас я бы собрал это за несколько дней.
Теперь не нужна cost consuming команда, чтобы показать результат. Расходы из зарплатного фонда перетекают в расходы на подписки
Вайбкодинг резко удешевил и ускорил создание софта, поэтому венчур (и другие “money givers”) смещается от “дать денег, чтобы построили” к “дать денег, чтобы доказали спрос и масштабировали”
Как это влияет на мир
Количество созданных проектов увеличивается → конкуренция за пользователя растет → появляется больше нишевых решений
Раньше универсальный софт был следствием того, что разработка стоит дорого. Экономически выгоднее один продукт для всех. Сейчас за неделю можно создать 10 копий одного решения под разные рынки/ниши, и все они будут вполне рабочими
И получается, что самыми дорогими навыками теперь стали ⤵️
👨💻 Умение генерировать ценные идеи
👨💻 Продвигаться
👨💻 Выигрывать конкурентную борьбу за клиента
Почему вайбкодинг не спасет 95% проектов от провалов
Вайбкодинг убрал процесс, который и так не влиял на успешность продукта. Код сам по себе не делает продукт успешным — он просто был барьером на входе. Барьер сняли, но всё, что реально влияет на успех — все еще нужно уметь решать: понимание ЦА, работа с проблемой, умение донести продукт до людей, которым он нужен, и затем еще и масштабировать успех
Дальше — две долины (не той) смерти:
— Problem-Solution Fit: Решаем ли мы важную проблему?
— Product-Market Fit: Достаточно ли людей готовы за это платить?
Вероятность пройти оба — около 5%. У тех, кто не понимает, что нужно делать.
Потому что за "создать успешный продукт" спрятаны 4 огромных домена
Находить проблемы людей
Не "мне кажется, это нужно", а реальные боли, за решение которых платят
Проектировать решение
Так, чтобы оно действительно решало проблему. Не фичи ради фич
Продвигать через сотни конкурентов
Кстати, отсутствие конкурентов — red flag. Либо ты дизраптор с миллионами на маркетинг, либо рынка просто нет
Выстроить прибыльную бизнес-модель
Чтобы unit-экономика сходилась, а не "сначала наберём пользователей, потом разберёмся"
Каждый из этих пунктов — отдельная дисциплина. И вайбкодинг не помогает ни с одним из них
Итого
Вайбкодинг снижает ценность "уметь писать код". Но повышает ценность "уметь создавать продукты, которые покупают"
Технический барьер упал. Продуктовый — остался
Теперь просто больше людей могут быстрее создавать продукты, которые никому не нужны. Зато цикл обучения будет быстрее ☕️
Хорошая новость: если ты понимаешь продуктовую часть — у тебя огромное преимущество. Потому что большинство соревнуется в скорости разработки, а не в качестве идей.
«Джунов больше не нанимаем»: как ИИ‑агенты меняют разработку и роль инженера
ИИ-инструменты давно стали привычной частью рабочего стека разработчиков: автодополнение, генерация кода, помощь в тестах — всё это уже стандарт и даже набило оскомину. Но пока разработчики воспринимают ИИ как ассистента, они упускают начало нового этапа. На смену точечным ассистентам приходит агентный подход, когда автономные ИИ-агенты становятся полноценными участниками SDLC и работают не только с инженером, но и друг с другом.
Российские банки и крупные компании уже пробуют этот подход на практике: автоматизация тестов, аналитики, сопровождение фич в полуавтоматическом режиме. Но «волшебной кнопки 10x» всё ещё нет. Без продуманной интеграции и изменений в процессах ИИ легко превращается в красивую песочницу, которая не даёт реального ускорения.
На нашей конференции про ускорение разработки AI Boost выступил Александр Поломодов, технический директор Т-Банка. Он подробно рассказал, как команды переходят от простых ИИ-помощников к полноценным агентам, которые действительно влияют на скорость и качество разработки. Теперь запись доступна на YouTube — и это возможность взглянуть на внедрение ИИ-агентов глазами тех, кто делает это в проде, а не в демо-среде.
Вы узнаете:
Как сделать агентов рабочим инструментом: ключевой принцип — «проницаемость агента». Важно понимать, влияет ли он на время инженеров, какие метрики собирать и как интегрировать агентов в SDLC.
Почему миф «ускорим всё и снизим косты» не работает: ИИ ускоряет не всё. Реальные примеры показывают новые риски и необходимость перестройки процессов.
Как крупные команды строят агентную разработку: опыт Т-Банка — что автоматизировать первыми, какие роли и доступы давать агентам и как выглядит работа команды, когда агенты становятся её частью.
Как меняется роль инженера и тимлида: часть рутины уходит к агентам. Инженер всё чаще становится «лидом команды агентов», растут требования к middle/senior, а задачи джунов частично автоматизируются.
Как измерять эффективность ИИ-агентов: артефакты — не метрика. Важно смотреть на реальное влияние на скорость, избегать ложных показателей и встроить измерения в ежедневный процесс.
Какие навыки нужны уже сейчас: умение формулировать задачи как сценарии, проектировать роли агентов и отвечать за процессы, а не только за код.
Спикер:
Александр Поломодов — технический директор T‑Tech.
«Мы переходим от простых ИИ‑помощников к агентам, которые реально влияют на скорость и качество разработки. Но без правильных процессов и метрик это остаётся только красивой демо‑картинкой.»
Смотрите полную запись доклада на YouTube — особенно если вы:
руководите разработкой или продуктом и хотите понять, где агенты дадут реальную отдачу, а где нет;
отвечаете за инженерную культуру и планируете, как изменится роль разработчиков в ближайшие 2–3 года;
уже используете Copilot/Cursor и хотите перейти от «вайб‑кодинга» к системному использованию ИИ‑агентов в SDLC.
Запуски 2025: менеджмент в ИТ
В этой подборке собрали три курса, которые будут полезны специалистам, стремящимся развиваться как руководители в своих направлениях.
«Lead DevOps» — 5 месяцев
Научим быть «играющим тренером» — специалистом, который одинаково уверенно разбирается и в технологиях, и в менеджменте. После курса почувствуете, что к большой ответственности прилагается большая уверенность в своих силах.
«QA Lead» — 5 месяцев
Курс поможет вырасти из QA-инженера в руководителя QA-команды. Разберём, как формировать сильную команду, управлять стратегией автоматизации и выстраивать эффективные QA/QC-процессы.
«Технический директор — СТО» — 4 месяца
Программа для технических специалистов, которые хотят развиваться как руководители. Наставники и менторы — CTO из Яндекса и других крупных компаний.
Проект Open Scouts обеспечивает роботу целой команды ИИ-агентов для получения всевозможных сведений в сети. Сервис по расписанию мониторит сайты, соцсети и другие ресурсы и пересылает обновления на почту. ИИ-агенты могут следить за вакансиями, трендами, исследованиями или другими обновлениями данных в интернете по запросу.
Как внедрить ИИ в разработку и подружиться с безопасниками
ИИ-инструменты в разработке стали классикой. Но чем активнее команды используют ИИ, тем острее стоят вопросы безопасности. Об этом говорят гораздо реже, чем о новых моделях — хотя именно она определяет, выкатите ли вы фичу спокойно или поднимите команду в 3 ночи поднимать упавший сервер.
Чтобы разобраться, как это работает в реальных процессах, мы собрали за одним столом лидеров из Сбера, Positive Technologies, RuStore и Ozon FinTech. Эксперты поделились практиками, ошибками, риск-моделями и объяснили, почему безопасность — это не тормоз, а часть архитектуры внедрения ИИ.
Теперь запись доступна на YouTube. Вы узнаете:
Как защищать чувствительные данные, не превращая компанию в «закрытый контур». Какие подходы позволяют внедрять ИИ-инструменты в средах, где малейшая утечка — критический инцидент.
Три ключевых AI-риска, про которые редко говорят вендоры. Злоупотребление моделями, небезопасный код, сгенерированный без проверки, и ИИ-агенты с доступами ко всему — эксперты поделятся кейсами.
Как меняется соотношение безопасности и скорости при масштабировании. Почему крупные компании осторожнее, чем стартапы, и как учитывать репутационные и финансовые риски при внедрении автоматизации.
Что делать, если ИИ сгенерировал уязвимый код, и это привело к взлому системы. Где проходит реальная граница ответственности между разработкой, безопасностью и инструментами.
К чему готовиться в части регулирования. Почему регулирование ИИ будет идти по пути любых инженерных технологий, что происходит в Китае, и какие требования появятся первыми.
Как безопасники и разработчики приходят к партнёрству.
Почему зрелые команды кибербеза не тормозят внедрение технологий, а помогают строить безопасный процесс — и почему к 2026 году в компаниях появятся команды, частично состоящие из ИИ-агентов.
Спикеры:
Сергей Марков — Директор по развитию технологий ИИ, Сбер.
Светлана Газизова — Директор по построению процессов безопасной разработки, Positive Technologies.
Александр Толмачев — ex-CDO Ozon FinTech, преподаватель Сколково и ВШЭ.
Сергей Кузнецов — Руководитель команды мобильной инфраструктуры, RuStore.
«Большинство серьёзных инцидентов происходит не из-за ИИ, а из-за плохо выстроенных процессов вокруг него. Агент с лишними правами доступа может привести к краху всего.»
— Сергей Марков, директор по развитию технологий ИИ, Сбер.
Смотрите полную запись круглого стола на YouTube — если вы внедряете ИИ, работаете с чувствительными данными или хотите адаптировать SDLC под новые риски.
ИИ в деле: как измерить реальную эффективность и избежать ошибок внедрения
В новом выпуске нашего подкаста мы углубились в процессы, которые стоят за стабильностью и инновациями в крупном финтехе.
Наш гость — Дмитрий Журавлёв, руководитель разработки отдела единой авторизации и Центра компетенции LLM. Мы разобрались, как управлять критически важными, но на первый взгляд, совершенно разными направлениями в одной IT-инфраструктуре.
Единая авторизация:
Стек и архитектура: почему при выборе open-source решения мы в итоге ушли от оригинальной реализации.
Решение проблем безопасности: как объединение десятков разрозненных систем входа в единый контур повышает безопасность и снижает когнитивную нагрузку на разработчиков.
Центр компетенции ИИ:
Практическое применение: кейсы автоматизации рутины в нетехнических отделах, генерация персонализированного контента под разные психотипы клиентов и, главное, реальное ускорение MVP-разработки.
Метрики и эффективность: как измерить реальный профит (ROI) от внедрения LLM и почему TTM (Time to Market) — главная метрика успеха в ИИ-проектах.
Границы применимости:
Большие кодовые базы: почему в больших legacy-проектах ИИ может не помогать, а мешать. Опасности AI-генерации кода без ревью и архитектурного контроля.
Будущее разработчика: станем ли мы "пилотами" ИИ? И почему именно эмпатия и архитектурное мышление остаются за человеком.
Наш подкаст доступен на всех удобных платформах:
Youtube | Apple Podcast | Яндекс Музыка | Spotify | VK Музыка
Со временем у каждого разработчика появляется свой набор маленьких правил, которые работают лучше любых инструкций. Матвей из команды разработки сервисов на базе SMP поделился пятью привычками, которые помогают ему держать код аккуратным и читаемым.
1. Давать осмысленные имена сразу же
Хорошие названия переменных, функций и классов экономят время всей команде: код проще читать, легче понимать и поддерживать. А еще чем меньше вопросов «что делает эта функция?» или «что содержит переменная?», тем лучше.
2. Декомпозировать код и избегать вложенности
if внутри if или for внутри for путают: каждое разветвление создает еще одну ветку, которую приходится держать в голове. Лучше разбить логику на небольшие части — код становится прозрачнее и надежнее.
как не надо:
функция заказать_пиццу(адрес):
если адрес_валиден(адрес):
если у_ресторана_ингредиенты():
если клиент_может_платить():
печать "Пицца заказана!"
иначе:
печать "Недостаточно денег"
иначе:
печать "Нет ингредиентов"
иначе:
печать "Адрес некорректный"как надо:
функция заказать_пиццу(адрес):
если не адрес_валиден(адрес):
печать "Адрес некорректный"
вернуть
если не у_ресторана_ингредиенты():
печать "Нет ингредиентов"
вернуть
если не клиент_может_платить():
печать "Недостаточно денег"
вернуть
печать "Пицца заказана!"3. Регулярно делать рефакторинг
Подходы и стандарты меняются, команда учится новому и растет, а код устаревает. Регулярный рефакторинг помогает поддерживать код актуальным и облегчает жизнь новым разработчикам, которые, возможно, уже пробовали новые подходы в работе.
4. Настроить линтер и форматер
Линтер — статический анализатор кода, который следит за определенным стилем написания кода. Так как у каждого из нас свой подход, нам нужен «инструмент-судья», который беспристрастно оценит оформление кода. Форматер помогает автоматически исправить код и привести его к единому виду.
5. Комментировать только неочевидную бизнес-логику
Комментарии полезны, если они объясняют то, что нельзя понять из кода. Например, когда понимаем, что участок кода содержит особенность бизнес-логики, которая еще не ясна новому сотруднику. Но важно помнить, что избыток пояснений превращает понятный код в мешанину из кода и комментариев. Принцип простой: объясняем редкие, действительно сложные места и не трогаем остальное.
5 Ошибок Рефакторинга
Добавлять в рефакторинг улучшения
Строго отделяйте рефакторинг т.е. преобразование кода из одной формы в другую с полным сохранением поведения от любых даже самых незначительных улучшений, оптимизаций, украшательства и тд и тп
Делать один огромный коммит
Делайте много коммитов, каждый на свой шаг рефакторинга. Рефакторинг это как ходьба по заминированному лабиринту, нужно обязательно записывать все ходы и иногда отступать на шаг или N шагов назад и искать другой путь.
Рефакторить без промежуточных проверок
Когда вдохновение несет и хочется "прибраться" и тут и там и везде и некогда останавливаться можно "пролететь поворот" и даже не один. Лучше всего делить рефакторинг на логические этапы. "Дешевые" по времени и ресурсу проверки можно и нужно запускать как можно чаще: компиляция, тесты, запуск приложение локально. Между крупными этапами желательно проводить регрессионное тестирование. И самое отличное поэтапный релиз рефакторинга, чтобы провести не только синтетические проверки, но самую важную "проверку продакшеном"
Затягивать и долго не релизить рефакторинг
Топ выбрасываний рефакторинга на моей практике происходило из за желания довести его до окончательного окончания, всё всё исправить, привести в идеальную симметрию и тд и тп. Чем дольше человек очищает код, пока параллельно идут продуктовые спринты, тем больше он несет накладных расходов(мержить то надо) и тем больше падает вероятность успешной интеграции ветки рефакторинга с основной и его успешного релиза.
Не думать о запасном варианте
Не смотря на все многоступенчатые системы проверки качества вашего кода всегда есть далеко не нулевая вероятность ошибки, особенно когда "наводишь порядок" в самом ключевом месте системы (а где еще как не в таких местах наводить порядок).
В таких ситуация очень полезно оставлять запасной вариант, например флаг переключения на "абсолютно старый код", лучше всего налету без рестартов.
В своем канале о разработке в стартапах делюсь опытом и рассказываю еще больше удачных примеров и факапов. Буду рад видеть каждого! Заходите!
Всем удачного рефакторинга!
Представлен сервис LearnXinYMinutes, который поможет освоить базовые команды и понять, как они используются в работе в разных языках программирования, фреймворках и программных средах, включая IDE. Внутри есть 55 ссылок (от баша и C до YAML) для изучения с русским переводом.
Яндекс Практикум проводит опрос о найме IT и Digital специалистов на российском рынке. Этот опрос очень важен для рынка, и мы готовы поделиться отчетом по результатам опроса.
Опрос занимает 7-10 минут, в конце анкеты вас ждет бонус — бесплатный доступ к одному из курсов Яндекс Практикума (на ваш выбор).
Если вы рекрутер, лид рекрутеров или HR менеджер, перейдите по этой ссылке.
Если вы нанимающий менеджер — тимлид, техлид, руководитель направления, перейдите по этой ссылке.
Зачем нужен опрос?
Нам важно узнать больше о найме IT и Digital специалистов сегодня с позиции рекрутеров и смежных ролей: какие инструменты помогают ускорить найм, что для вас важно в найме, какие проблемы есть на рынке труда сегодня.
Это безопасно?
Все данные анонимны и будут проанализированы только в обобщенном виде.
А можно ли узнать результаты?
При желании в конце анкеты вы можете оставить свой e-mail, мы пришлем вам обобщенные результаты исследования — это возможность узнать больше о рынке найма сегодня.
⚡️ITFB Group запускает KODA — платформу для объективной оценки эффективности разработки
Мы представили KODA — собственную платформу, которая показывает, как на самом деле работает команда разработки. Не по ощущениям и не по субъективным отчётам, а на основе данных из всех инструментов инженеров: репозиториев, таск-трекеров, CI/CD, баз знаний и систем тестирования.
🔥 За первые 3 квартала внутреннего использования мы увеличили производительность команд на 30%, сократили количество переделок на 35% и ускорили code review на 40%.
💻 KODA объединяет инженерные метрики, ИИ-модули и аналитику, чтобы дать руководителям полную картину разработки — прозрачную, измеримую и безопасную. Все данные остаются внутри компании.
Наталья Романова, директор по развитию ITFB Group:
«Мы создавали KODA как инженеры для инженеров. Но в итоге получили инструмент, который одинаково важен и для бизнеса: он переводит работу разработки в язык цифр, прозрачности и управляемости».📎 По оценкам Gartner, к 2027 году подобные системы станут стандартом для половины компаний мира. Российский рынок только начинает этот путь — и KODA становится одним из первых решений такого уровня.
Подробнее о KODA — на сайте ITFB Group.
Больше никаких мучений с Markdown — расширение Markdown Viewer превращает все файлы Markdown в Word-документы без боли и страданий. Захватывает инфографику: любые схемы, диаграммы, графики в чистые картинки. Берёт формулы из LaTeX и переносит их в Word нативно, а не в формате ужасных вставок. Переносит форматирование — подсвечивает код, сохраняет таблицы и списки, как в оригинале. Работает локально. Подходит для работы с GitHub: открывает документы и даёт перенести всё в Word.
Хотели ускорить разработку с ИИ, а получили сопротивление и хаос: как работать с командой
Сегодня ИИ стараются внедрить буквально в каждый этап разработки. Иногда это вдохновляет, но чаще вызывает закономерный скепсис и сопротивление — особенно у команд, которых бездумно заставляют использовать новые инструменты. Почему возникает это сопротивление и как его преодолеть?
Евгений Сатуров, CTO Mobile в Surf, провел 50+ сессий парного программирования, понаблюдал, как разработчики впервые работают с ИИ, и собрал 40 страниц выводов. А потом рассказал обо всем на конференции AI Boost. Теперь выступление есть на YouTube.
Вы узнаете:
Почему ИИ-кодинг — это отдельный навык, а не автоматическое ускорение разработки.
Какие 5 ключевых страхов чаще всего мешают командам (стоимость, недоверие, потеря контроля, замедление, отказ от результата).
Как ИИ подчеркивает слабые места постановки задач и почему качество промпта напрямую влияет на качество решения.
Чем различаются системные, таск- и мета-промпты, и зачем их понимать каждому разработчику.
Почему ИИ-агенты эффективнее на цельных задачах, чем на мелких правках.
Как руководителю внедрять ИИ так, чтобы это не было про «разбирайтесь сами».
Главные барьеры на пути внедрения — не технические, а человеческие. Все ошибки и проблемы проистекают из страхов и заблуждений разработчиков, а не из несовершенства ИИ.
Евгений Сатуров, CTO Mobile в Surf
В видео — много практики, наблюдений и реальных кейсов, как ИИ реально помогает командам — и какие ошибки лучше не повторять. Смотрите на YouTube.
🦋 Почему «перезагрузка» — это не опция, а продуктовая необходимость
Я боюсь «ломать» то, что работает. Боюсь потерять стабильность и контроль.
Но есть примеры, где природа нифига не боится. Она умеет растворить всё до основания, чтобы на его основе создать что-то прекрасное.
Факт:
Когда гусеница превращается в бабочку, в коконе происходит жестокий биохимический процесс.
Всё тело гусеницы буквально растворяется в суп-пюре. Я себе это вижу не иначе, как финал "Терминатор 2: Судный день" под ту же музыку.
Так или иначе, сохраняются только имагинальные диски - крошечные зачатки будущих крыльев, глаз, ног. Т.к. сиквел этой истории никто не отменял.
Но шутки в сторону. Происходит не улучшение гусеницы. Это не «апгрейд» и не «ребрендинг».
Это- смерть одной формы и рождение совершенно другой. Старая система уничтожается, чтобы дать жизнь новой.
Менеджерская боль:
А мы в это время:
-Цепляемся за «успешные процессы», которые уже не масштабируются.
-Дорабатываем «проверенные решения», которые давно устарели.
- Улучшаем «старый UI», вместо того чтобы создать принципиально новый продукт.
Мы пытаемся «улучшить гусеницу», боясь признать - чтобы летать, нужно сначала перестать ползать.
И я так делал сотни раз: вместо того, чтобы мужественно, терпеливо и наверняка с неприятным последствиями все пересобрать - натягивал сову на глобус. Потому что это тупо дает результат быстрее. Короткий результат. Но быстрее.
- Вывод:
Настоящий прорыв требует не улучшения, а метаморфозы.
Иногда нужно:
- Разрушить текущую структуру.
- Отказаться от «работающих», но уже ограничивающих процессов.
- Пересобрать продукт с нуля, а не наращивать техдолг.
Да, это страшно. Да, будет больно. Иногда долго. Даже очень.
И делать это должны не пришлые эксперты. А сама команда.
Но единственное, что страшнее- остаться гусеницей в мире, где все уже летают.
p.s. Было бы безобразием не упомянуть, что гусеницы живут от нескольких недель до нескольких лет. Бабочка-максимум 20 дней.
Но. Цель жизни гусеницы - превратиться в бабочку. Цель бабочки - дать жизнь новым гусеницам.
- Вопрос:
А в вашем проекте или компании уже назрела необходимость не «улучшать гусеницу», а «стать бабочкой»? В какой точке вы застряли?
-
#крылья_ноги_и_хвосты
🦋 Почему «перезагрузка» — это не опция, а продуктовая необходимость
Я боюсь «ломать» то, что работает. Боюсь потерять стабильность и контроль.
Но есть примеры, где природа нифига не боится. Она умеет растворить всё до основания, чтобы на его основе создать что-то прекрасное.
Факт:
Когда гусеница превращается в бабочку, в коконе происходит жестокий биохимический процесс.
Всё тело гусеницы буквально растворяется в суп-пюре. Я себе это вижу не иначе, как финал "Терминатор 2: Судный день" под ту же музыку.
Так или иначе, сохраняются только имагинальные диски - крошечные зачатки будущих крыльев, глаз, ног. Т.к. сиквел этой истории никто не отменял.
Но шутки в сторону. Происходит не улучшение гусеницы. Это не «апгрейд» и не «ребрендинг».
Это- смерть одной формы и рождение совершенно другой. Старая система уничтожается, чтобы дать жизнь новой.
Менеджерская боль:
А мы в это время:
-Цепляемся за «успешные процессы», которые уже не масштабируются.
-Дорабатываем «проверенные решения», которые давно устарели.
- Улучшаем «старый UI», вместо того чтобы создать принципиально новый продукт.
Мы пытаемся «улучшить гусеницу», боясь признать - чтобы летать, нужно сначала перестать ползать.
И я так делал сотни раз: вместо того, чтобы мужественно, терпеливо и наверняка с неприятным последствиями все пересобрать - натягивал сову на глобус. Потому что это тупо дает результат быстрее. Короткий результат. Но быстрее.
- Вывод:
Настоящий прорыв требует не улучшения, а метаморфозы.
Иногда нужно:
- Разрушить текущую структуру.
- Отказаться от «работающих», но уже ограничивающих процессов.
- Пересобрать продукт с нуля, а не наращивать техдолг.
Да, это страшно. Да, будет больно. Иногда долго. Даже очень.
И делать это должны не пришлые эксперты. А сама команда.
Но единственное, что страшнее- остаться гусеницей в мире, где все уже летают.
p.s. Было бы безобразием не упомянуть, что гусеницы живут от нескольких недель до нескольких лет. Бабочка-максимум 20 дней.
Но. Цель жизни гусеницы - превратиться в бабочку. Цель бабочки - дать жизнь новым гусеницам.
- Вопрос:
А в вашем проекте или компании уже назрела необходимость не «улучшать гусеницу», а «стать бабочкой»? В какой точке вы застряли?
-
#крылья_ноги_и_хвосты
Ссылки и всплывающие подсказки в PlantUML
Всем привет!
Продолжаем тему PlantUML. Сегодня за 5 минут и без воды поговорим о Сылках и всплывающих подсказках в PLantUML
1️⃣ Для добавления ссылки и текста ссылки, используйте конструкцию: [[<URL-ссылки> <Текст ссылки>]]
Пример: [[http://plantuml.com Ссылка (без всплывающей подсказки) на plantUML]]
2️⃣Для добавления: всплывающей подсказки к тексту (с ссылкой), используйте конструкцию: [[<URL-ссылки>{<всплывающая подсказка>} <Текст ссылки>]]
Пример: [[http://plantuml.com Ссылка (без всплывающей подсказки) на plantUML]]
3️⃣Для добавления: всплывающей подсказки к тексту (без ссылки), используйте конструкцию: [[{<всплывающая подсказка>} <текст к которому относится всплывающая подсказка>]]
Пример: [[{всплывающая подсказка} Всплывающая подсказка (без ссылки)]]
🔥 Внимание!!! Чтобы всплывающие подсказки работали у заказчика, выгружайте диаграммы в формат SVG
Пример кода ниже (а ссылка тут), а файл с примером в формате SVG тут:
@startuml
Title **Ссылки и всплывающие подсказки в PlantUML**
' Для добавления: ссылки и текста ссылки, используйте конструкцию: `[[<URL-ссылки> <Текст ссылки>]]`
Alice -> Bob: [[http://plantuml.com Ссылка (без всплывающей подсказки) на plantUML]]
'Для добавления: всплывающей подсказки к тексту (с ссылкой), используйте конструкцию: `[[<URL-ссылки>{<всплывающая подсказка>} <Текст ссылки>]]`
Alice -> Bob: [[http://plantuml.com{всплывающая подсказка (с ссылкой)} Ссылка (со всплывающей подсказкой) на plantUML]]
' Для добавления: всплывающей подсказки к тексту (без ссылки), используйте конструкцию: `[[{<всплывающая подсказка>} <текст к которому относится всплывающая подсказка>]]``
Alice -> Bob: [[{всплывающая подсказка} Всплывающая подсказка (без ссылки)]]
@endumlЧтобы работали всплывающие подсказки на русском в плагине предпросмотра (в VS Code) добавьте в настройки (settings.json)
{
"plantuml.diagramsRoot": "docs/diagrams",
"plantuml.exportOutDir": "docs/diagrams/out",
"plantuml.exportFormat": "png",
"plantuml.exportSubFolder": false,
"plantuml.render": "PlantUMLServer",
"plantuml.server": "http://www.plantuml.com/plantuml",
"plantuml.commandArgs": [
"-charset",
"UTF-8"
]
}
Code Wiki — AI документация репозиториев от Google
Google релизнули новый интересный проект. Code Wiki — википедия с документацией open source репозиториев. А в будущем обещают CLI версию для автоматической документации приватных репозиториев! Неужели документация кода будет теперь всегда актуальной?
Как работает?
ИИ агент на базе Gemini шерстит репозиторий, разбирается во взаимозависимостях в коде, генерирует схемы и все это дело описывает в формате Wiki странички, с интерактивным оглавлением.
Code Wiki:
Помогает найти open source репозитории по нужной тематике. То есть информация о репозитории, видимо, векторизуется и сверху работает семантический поиск.
Позволяет общаться с репозиторием и его документацией через Gemini чат (в том числе можно на русском, если читать доку на английском не хочется).
Автоматически обновляет документацию и все схемы после каждого PR. А значит документация наконец-то всегда актуальна.
Я немного посравнивал документацию от Code Wiki и документацию в самих опенсорс репозиториях. На мой взгляд, в хорошо поддерживаемых open source репозиториях авторская документация, конечно, все равно лучше.
Но, все мы помним те самые опенсорс репы, где лежит как-будто что-то очень полезное для нашего проекта, но черт ногу сломит, пока разберешься, как оно работает. А автор удосужился написать только абзац с общим описанием, о чем репа. Вот на такой случай Code Wiki будет спасением!
Подписывайся на телеграм канал Заместители. Там еще больше интересного про ИИ агентов.
Сколько стоит получить 1 оффер?
Хотите вы этого или нет — но мы уже сделали 330 000 автоматизированных откликов за 5 месяцев. И за это время успели подсобрать кое какие данные.
Рассказываю:
Да, часть из откликов может быть нерелевантной, часть уходит «в молоко», но сейчас уже 40–50% попадают в яблочко.
А есть ли вообще выхлоп? Давайте посчитаем.
За всё время в нашем ассистенте Софи было 434 платных пользователя.
На этих 434 человек мы насчитали 1 956 приглашений на интервью. (Это именно те, что приходят через хх.ру (приглашения в тг или на почту мы не видим - поэтому их может быть и больше)).
Представим, очень грубо, что только 50% из них — это действительно релевантные приглашения, которые конвертировались в состоявшиеся интервью.
Получаем, что в среднем — 2,25 интервью на пользователя.
Средний пользователь заплатил нам 6 500 рублей.
Значит, одно интервью обходится примерно в 2 888 рублей.
Считается, что нужно пройти 3–5 интервью с разными компаниями, чтобы получить 1 оффер.
Итого — около 11 000 рублей стоит один оффер через Софи. Это значит что у кого-то он может выйти в 4500 рублей, а у кого-то в 30000, 40000 или вообще его не быть.
📕📖📚 "Управление победоносной командой" — звучит как отличное название, поэтому я решил ознакомиться со свежей книгой по управлению командами от бывшего бейсбольного тренера, а ныне тренера по лидерству и командной динамике: Трента М. Кларка.
И знаете, эта книга удивила меня прямотой, с которой автор рассуждает на тему того, что работает, что не работает, и какие принципы управления нужно использовать. Простые принципы, простые формулировки и чёткие требования следовать им без каких-либо отступлений.
Для валидации своих советов он говорит фразу: "Либо вы делаете всё правильно и ваша команда побеждает, либо она проигрывает, и тогда ваши советы не стоят ничего. Моя команда становилась чемпионом три раза".
Стиль изложения максимально напоминает книгу "45 татуировок менеджера" Максима Батырева, которую многие называют жёсткой, что подчёркивает, что человек пришёл из спорта, где высокие ставки и высокая награда за результат, и какие-либо оправдания не принимаются.
__
В основе "Управление победоносной командой" лежат три взаимосвязанных столпа: командная работа, мотивация, стратегия.
Кларк начинает с анализа командной работы не как модного слова, а как осознанной практики, закалённой в горниле соревнований. Он вспоминает ключевые моменты из своей карьеры в MLB — например, сплочение аутсайдеров во время изнурительных плей-офф, — чтобы показать, как доверие и взаимозависимость превосходят индивидуальное звёздное сияние.
Эти истории подчёркивают главный принцип: настоящие команды процветают благодаря SPARC — Духовности, Продуктивности, Ответственности, Обязанности и Обучаемости, — концепции, разработанной Кларком для формирования устойчивости.
Для бизнес-лидеров это означает создание среды, где сотрудничество побеждает изоляцию, подобно слаженной защите на поле, выполняющей двойной аут под давлением.
___
Если вам понравилась книга Батырева, либо вам импонирует "красный" менеджмент, то книгу могу вам порекомендовать к ознакомлению.