Привет, Хабр!
Примерно год назад наша команда загорелась идеей создать продукт, который позволил бы «поговорить с кодом». Мы, как и многие, находились под впечатлением от возможностей LLM. Казалось, что ещё немного – и нейросеть возьмёт на себя всю рутину по анализу легаси, аудиту систем и онбордингу новых разработчиков.
Недавно я посмотрел большое интервью с основателем и руководителем Revolut. Кто не знает, это такой Т-банк, только в мировом масштабе (они представлены в 40 странах уже) — как бы банк без офисов, но по сути ИТ-компания.
Самое интересное для меня была часть про управление такой большой и быстрорастущей компанией. Все управление выстроено на цифрах: метриках и показателях.
«Решения в компании принимаются на основе цифр, а не эмоций. Это позволяет минимизировать человеческий фактор и ошибки».
Почему это важно:
Устранение субъективности. (далее…)
Недавно один из наших клиентов столкнулся с неожиданной ситуацией: пришлось расстаться с мидл-разработчиком, который активно использовал ИИ для генерации кода, но при этом не погружался в бизнес-логику проекта. Каждый его пулреквест превращался в марафон правок для senior-разработчика, который тратил на ревью больше времени, чем ушло бы на написание кода с нуля.
Это не единичный случай. Мы наблюдаем тренд:
ИИ помогает джунам писать код быстрее, но перекладывает нагрузку на сеньоров;
ИИ не понимает архитектуру проекта и принятые в команде подходы;
Резюме долгое время считалось базовым инструментом оценки кандидата.
Но в последние годы вокруг него сформировалось сразу два противоположных нарратива:
— кандидаты доводят резюме до идеала с помощью AI
— компании внедряют AI для фильтрации этих резюме
Возникает логичный вопрос:
если обе стороны используют алгоритмы — не теряет ли резюме смысл?
Разберёмся, что на самом деле происходит — на основе исследований и практики.
Согласно мета-анализу Фрэнк Шмидт и Джон Хантер (1998), который обобщает десятки исследований с выборками в тысячи кандидатов:
Практическое применение методики от Boston Consulting Group — с калькулятором внутри.
Представьте: команда взялась за инициативу, расписала задачи по спринтам, завела тикеты в Jira — и ушла пилить. Через квартал выясняется, что не успели. Или успели, но никому не нужно. Или руководство неожиданно «не поддержало».
Большинство провалов проектов и инициатив — предсказуемы. Их можно увидеть заранее, если знать, куда смотреть.
Для этого существует DICE-фреймворк от Boston Consulting Group. Применяю его уже несколько лет, и почти каждый раз он обнажает риски, которые команда не замечала или не хотела замечать.
Если вы хоть раз гуглили «как настроить Obsidian для задач» — вы знаете, чем это заканчивается. Три часа в YouTube, пять вкладок с гайдами, десяток установленных плагинов и… система не работает. Потому что это чужая система.
Я строил свою два года. В этой статье не будет универсального гайда — будет разбор конкретного стека с объяснением, почему каждый плагин попал в него, а не просто список с описаниями из документации.
Если тема управления знаниями и задачами в Obsidian вам близка — заглядывайте в мой тг-канал, там я разбираю подобные вещи регулярно.
Мы разберем конкретную методику настройки контекста и правил общения на примере бесплатной Qwen 3.5-Plus (принципы универсальны для любой современной LLM).
ИИ работает по принципу «мышления векторами». ИИ не мыслит как человек, так как у него знания находятся в многомерном пространстве смыслов. Когда вы задаете запрос, модель ищет наиболее вероятный ответ, перемещаясь по этому пространству.
