Эд Хорьков из КОД9

RAG vs KAG. Мы все понимаем что у классического RAG-подхода есть много недостатков. Поэтому появился KAG - Knowledge-Augmented Generation. KAG пытается работать со смыслами в тексте, а не с чанками, формирует графы знаний, связи между этими знаниями, строин онтологию текста. Технически это выглядит так: - граф знаний (сущности, взаимосвязи, правила); - multi-hop reasoning (аля многошаговое рассуждения); - движок для запросов и объяснений.

1. Граф обеспечивает сущности, отношения и правила, на которых можно выполнять многошаговые выводы. 2. LLM формирует запрос к графу, получает связанный контекст и использует его как структурную память. 3. На основе этой памяти модель строит рассуждение, которое можно проверить, объяснить и повторить.

Китайский опен-сорс для построения KAG-а. https://github.com/OpenSPG/openspg

Прогноз на 2026 год: как вайбкодинг и нейросети изменят всё 1. К концу 2026 года у большинства айтишных вакансий будет требование навыка вайбкодить и проверять гипотезы с нейронками И вероятно именно в Claude Code, если OpenAI или Google не сделают конкурентноспособные модели для кода. 2. Возникнет давление на работодателей от сильных специалистов, которые пойдут делать своё дело Летом я провёл исследование среди моих выпускников и выяснил что подавляющее большинство продактов мечтают сделать свой продукт. Видимо, это такой прикол профессии. Теперь у всех без исключения такая возможность есть. Понятно, что воспользуются этой возможностью не все, но тренд точно будет расти. Работодатели будут вынуждены адаптироваться и как-то заинтересовывать сотрудников. Сейчас ВСЕ продакты, которые погружаются в вайбкодинг, что-то пилят своё. Сталкиваются с ограничениями психики, отсутствием навыка маркетинга и продаж. Но сталкиваются. Ставлю на значительный [десятки процентов] рост средних зарплат фулл-стек-билдеров, чтобы удерживать сильных ребят, которые фигачат за десятерых. Те, кто не вайбкодят будут с завистью смотреть на тех кто вайбкодит и тоже учиться. Я считаю, что сейчас отличная возможность для специалистов вырасти по деньгам начав приносить компании X10 результата. 3. Команды станут меньше, но команд станет больше Нужно меньше специалистов на задачу > команды становятся меньше. Освободившиеся ресурсы инвестируют в новые продукты или на то, на что не хватало ресурсов. Команд становится больше как в текущих компаниях, так и на рынке в целом. Думаю, что средний размер команды технологического бизнеса будет стремительно уменьшаться. 4. Разработчики будут менять инфраструктуру и процессы, чтобы продакты и маркетологи могли деплоить в прод эксперименты с минимальным ущербом Сейчас среднему продакту нельзя давать деплоить в прод. Во-первых, модели ещё не на таком уровне, во-вторых, можно сломать всё кхре нам. Но для того, чтобы бизнес получил ценность от вайбкодинга, ПРИДЁТСЯ дать продактам/дизайнерам/маркетологам/аналитикам деплоить в прод. Просто ещё не придумали как. Думаю, что к концу года появятся первые успешные кейсы. 5. Будет стремительный рост количества солопренёров Не у всех будет получаться. Но количество тех, кто будет стараться и тех у кого получится, будет стремительно расти. 6. Мы увидим автоматизацию там, где её в принципе не могло быть ещё год назад Бухгалтера, сотрудники поддержки, курьеры, юристы будут себе что-то вайбкодить. 7. Всем придётся переучиваться Если раньше я сначала месяц делал с дизайнером макет будущего продукта и потом пару месяцев разрабатывал, сейчас вайбкожу за пару дней, пару недель тестирую и потом уже работающее отдаю на отрисовку. Мой дизайнер за мной не поспевает. За вами не будут поспевать аналитики, разработчики и все остальные смежники. 8. Мы снова будем больше работать с файлами на компе, чем с экранами SaaSов Если вы начали работать с Cursor/Claude Code, то вы наверняка переехали из ноушна/конфлюенса/асаны в свой кастомный воркфлоу. За последние пару месяцев я работаю с файлами больше чем за последние 10 лет. Я УВЕРЕН, что джобы, которые люди раньше решали в SaaS'ах будут переезжать в кастомные навайбкоженные воркфлоу. 9. Появятся вайбкодинг-луддиты Которые до талого будут сопротивляться и кричать на каждом углу, что вайбкодинг херня и ничего нормального на нём не написать. Психотерапия прекрасно умеет работать с сопротивлением. Сопротивление бесполезно. 10. Основная эмоция года: а чо так можно было? Состояние шока и восторга будет сопровождать всех, кто хоть как-то будет связан с вайбкодингом. ———- Взял это у Вани Замесина: https://t.me/zamesin

Мы сердечно поздравляем всех, кто был с нами в этом 2025 году 🎉 – наших сотрудников нынешних и бывших, наших клиентов, партнеров и подрядчиков, тех кто следит за нашей работой, наших друзей в индустрии и сообществах! 💡 С наступающим вас Новым 2026-м годом! ✨ Желаем вам здоровья, счастья и веселья во всех годах, в которых вам предстоит оказаться 🙃 Нам искренне приятно работать с вами, знать вас, придумывать и создавать вместе новое! Мы продолжим делать это и в 2026 году, 17-м году нашего существования ) С наступающим Новым годом и Новым счастьем! 🎄🍾 Команда КОД9 xx ❤️

Итоги года В текущем году мы в КОД9 по настоящему прочувствовали на себе кризис рынка) Тем приятнее похвалиться проектами, которые мы сделали (и которые еще делаем) ⛴ AI-аналитик для морского грузоперевозчика - наш первый полноценный кейс с AI, сложная система совмещающая в себе RAG и Text2SQL-техники. 🔑 Система контроля доступов с SSO и 15 интеграциями, среди которых Битрикс, AD, SuperSet, и другие кастомные системы заказчика. 👗 Платформа fashion-курсов Mood Atelier - стартап из Португалии, где мы отвечаем за всю технологическую составляющую 🗄 - ШКАФ: приложение и бекенд для вендинговых шкафов, устанавливаемых в ЖК. Тут мы перехватили разработку и другой команды и кратно улучшили качество продукта. 👨‍🍳 - KDS: автоматизация процессов на кухне — сложный продукт с интеграций с IIKO и всякой специфичной для ресторанов историей. (кейс скоро будет!) 🎮 - Игровой портал для реселлинга игр для заказчика из Сингапура. Мало что могу тут написать, детали comming soon. Мы так же много занимались технологическим консалтигоном: - Помогли выстроить QA-процессы на крупном проекте со сжатыми сроками релизов - Проанализовали архитектуру заказчика, который готовится к масштабированию. Указали где будет ломаться.

Московское общество неизвестных машин ИИ уже стал частью повседневной работы бизнеса. Он помогает принимать решения, писать тексты, анализировать данные и автоматизировать процессы. Но при этом мы всё ещё плохо понимаем, как именно он меняет саму логику управления и ответственности. В последний рабочий день месяца я хочу рассказать про место, которое родилось именно из этого ощущения. Мы в КОД9 основали "Московское общество неизвестных машин". Что это такое? Я считаю , что рынок застрял между двумя крайностями. С одной стороны - восторг и вера в ИИ. С другой - попытки засунуть новые технологии в старые управленческие конструкции. Мы собрали людей из бизнеса и ИТ чтобы честно поговорить о том, что происходит, когда в управлении появляется не просто софт, а система с собственной логикой и скоростью мышления. На первой встрече мы говорили про - Уровни автономности ИИ в бизнесе - по аналогии с уровнями автономности self-driving машин - Обсуждали, почему корпоративные ИИ-системы оказываются особенно хрупкими перед лингвистическими атаками и джейлбрейками. - Почему ИИ перестаёт быть чисто цифровым явлением, всё чаще вмешиваясь в физическую реальность. Суть этой встречи можно сравнить с попыткой составить правила дорожного движения в момент, когда машины уже изобретены, но люди всё еще пытаются запрячь в них лошадей или обсуждают их устройство с точки зрения философии девятнадцатого века. Это была только первая встреча. Следующая будет в феврале - пишите мне если вам это интересно.

Московской общество неизвестных машин ИИ уже стал частью повседневной работы бизнеса. Он помогает принимать решения, писать тексты, анализировать данные и автоматизировать процессы. Но при этом мы всё ещё плохо понимаем, как именно он меняет саму логику управления и ответственности. В последний рабочий день месяца я хочу рассказать про место, которое родилось именно из этого ощущения. Мы в КОД9 основали "Московское общество неизвестных машин". Что это такое? Я считаю , что рынок застрял между двумя крайностями. С одной стороны - восторг и вера в ИИ. С другой - попытки засунуть новые технологии в старые управленческие конструкции. Мы собрали людей из бизнеса и ИТ чтобы честно поговорить о том, что происходит, когда в управлении появляется не просто софт, а система с собственной логикой и скоростью мышления. На первой встрече мы говорили про уровни автономности ИИ в бизнесе - и внезапно стало ясно, что многие компании уже живут на уровнях, к которым они ментально не готовы. Обсуждали, почему корпоративные ИИ-системы оказываются особенно хрупкими перед лингвистическими атаками и джейлбрейками. И почему ИИ перестаёт быть чисто цифровым явлением, всё чаще вмешиваясь в физическую реальность. В какой-то момент разговор сам собой свернулся в метафору. Это похоже на попытку написать правила дорожного движения в эпоху, когда машины уже изобретены, но люди всё ещё обсуждают их с позиции философии XIX века — или пытаются запрячь в них лошадей. Наверное, именно ради таких разговоров и имеет смысл собираться. Пока неизвестные машины не стали для нас слишком привычными, чтобы задавать о них правильные вопросы.

Product-less разработка Есть такая легенда, что Gmail захватил рынок почты когда стал давать пользователям по 1GB бесплатно -- якобы их CFO рассчитал, что storage (диски, железо) будут дешеветь, и по мере того как пользователи будут выбирать доступное место, Gmail сможет дешево закупить необходимое железо. Когда мы думаем, что дальше будет с цифровыми продуктами, полезно посмотреть на текущие тенденции (как это сделал мифический CFO Гугла). На самом деле ничего не поменялось: - Compute дешевеет - Storage дешевеет НО!! - Разработка дешевеет! и будет дальше дешеветь. Это значит что в прекрасном будущем создание (почти) любых продуктов будет стремиться к нулю. Если сделать продукт ничего не стоит, то мы можем делать их сотни и тысячи, выкатывать и рынок и смотреть есть ли спрос. А это значит, что продакт-менеджеры будут не нужны. Каждый желающий сможет сделать нужный ему продукт под себя и под своих друзей -- вы ведь сами точно знаете что вам нужно) Такое пятничное предсказание для вас, дорогие читатели.

AI-бизнесы будущего (часть 1) Каждый сезон Y Combinator (лучший VC-фонд на планете) публикует короткое эссе о том, какие проекты им сейчас интересны и где они видят будущее. Посмотрим сегодня на пару идей оттуда. Обучение рабочего класса с помощью ИИ

Чтобы развивать искусственный интеллект, нужно строить дата-центры. Чтобы строить дата-центры, нужно много рабочих. А чтобы рабочих было достаточно, их нужно обучить — и сделать этот процесс масштабируемым. Нужны проекты, которые будут обучать рабочих (слесарей, сварщиков и т. п.) с помощью ИИ. Например — через VR/AR-программы и персонализированные траектории обучения.

Генерация видео как новый примитив

Качество ИИ-видео стремительно улучшается: модели вроде Google Veo 3 уже создают 8-секундные видео за несколько долларов. Дальше будет ещё дешевле и лучше. Теперь представим, что мы можем создавать видео любого сюжета, качества и наполнения с околонулевой стоимостью. Куда это можно применить? 1. В шоппинге. Ищете платье в отпуск — сразу показываем вас в этом платье, идущей по Милану. 2. В играх. Игра будет такой же реалистичной, как фильм, а фильм — как игра. Всё генерируется на лету. 3.В аренде и продаже недвижимости. Показываем видео из вашей будущей квартиры с той мебелью, которую вы хотите. Нужны проекты, которые либо строят инфраструктуру для таких видеопотоков, либо используют ИИ-видео как программный примитив.

Промты это магия Нет, это не магия, а работа с контекстом. Модели нужно 1. Объяснить, какой результат вам нужен 2. Дать достаточно контекста, чтобы она сама связала контекст с результатом Мини-гайд, как делать это нормально. 1) Сформулировать цель, а не описывать процесс ❌Плохой промпт (про процесс): Сначала проанализируй данные, потом найди паттерны, потом сделай выводы. ✅Хороший промпт (про цель): Мне нужен [результат], который должен дать [конкретный эффект]. Аудитория — [кто будет читать или использовать результат]. Успех — [как понять, что получилосьъ. Пример: Мне нужен документ-план, чтобы нетехнические стейкхолдеры поняли наш план внедрения ИИ и не запутались в деталях. 2) Задаём ограничения, а не правила поведения

Правила - это делай шаг 1, шаг 2. Ограничения - это рамки, в которых ответ будет полезным.

Пример трех типов ограничений: - Контекст - медицина, финансы, B2B, для ребёнка, для CTO - Качество - "коротко и с примерами" или "глубже и обстоятельнее" - Границы - "без абстрактных тезисов", "без сравнений", "без ссылок" Как писать: ❌Неправильно - "кратко, просто, без жаргона", ✅ Правильно - "текст должен работать для человека, который впервые слышит тему. C примерами и без терминов". 3) Давать примеры (аля one-shot/few-shot prompting)

Модели лучше понимают, когда им показывают пример, а не объясняют словами.

Можно дать:пример того, как правильно и пример того, как неправильно (антипример) Формат: "Вот пример нужного уровня детализации:...". " А вот так — слишком поверхностно" 4) Указывать критерии качества

Не надо писать ИИ "сделай хорошо", - он не знает что для вас хорошо. Пишите, что именно значит хорошо.

❌ Неправильно: сделай точно, будь кратким. ✅ Правильно : факты должны быть проверяемыми, чтобы читатель мог подтвердить их за пару минут ✅ Правильно: каждый раздел - максимум один абзац, чтобы текст работал как резюме. ❌ Неправильно: объясни понятно ✅ Правильно: человек должен понять без гугления терминов 5) Если задача сложная - делаем иерархию целей

Не расписываем как делать, а описываем, что должно получиться по этапам.

Пример:

1. Мне нужен анализ, где сначала оценивается текущая ситуация только по предоставленным данным. 2. Потом выявляются паттерны, у каждого минимум 3 подтверждения. 3. В конце предлагаются действия, которые соответствуют этим паттернам.

Универсальный шаблон промпта (сохраняйте пока я такой щедрый)

Мне нужен [результат], который решает [конкретную задачу]. Это для [конкретной аудитории или домена]. Хорошо — это [понятный результат], плохо — [понятный антипример]. Фокус на [приоритете, пример], избегай [лишнего, антипример] После прочтения/использования результата человек должен уметь [сделать конкретное действие].

Итог: Хороший промпт — это не делай мне ответ» а сделай мне результат, который можно использовать. Скидывайте свои задачи или промпты в комменты — докрутим вместе в рабочий вариант. В комментариях еще скину 1-2 примера. Референсы: - https://arxiv.org/abs/2505.13360 - https://arxiv.org/abs/2401.14043 - https://arxiv.org/abs/2410.22225

AI-first компании Работа с документами и операционные процессы часто становятся бутылочным горлышком, когда компания растёт. Долгое рассмотрение договоров тормозит совершение сделок и напрямую влияет на кэшфлоу компании. Компания LogicMonitor, специализирующаяся на мониторинге ИТ-инфраструктуры, внедрила ИИ-решение для автоматизации процесса рассмотрения контрактов. Gartner пишет, что ROI составил более $100K за счёт ускорения первоначального рассмотрения контрактов и NDA на 50–70%. Я даже ввёл свою почту и скачал кейс, чтобы написать этот пост. Отдаю вам бесплатно (в комменты скину PDF). Шаги реализации проекта: 1. Определить, какие типы документов будем поддерживать. LogicMonitor взяли договоры MSA, NDA, повторяющиеся договоры. 2. Определить, что не автоматизируем. В нашем случае — финальное решение, выявление нестандартных рисков. Ответственность остаётся на юристе. 3. Навести порядок в документах до AI. Сделать хранилище договоров, контроль версий, прозрачный workflow движения документов между отделами. — Наконец, AI — 4. Подключение AI для редлайна (первичной проверки документов). 4.1 Делаем библиотеку эталонных пунктов (эталонные формулировки, запрещённые формулировки и т.п.). У LogicMonitor над этим работали 3 юриста. По сути, мы готовим для AI примеры «как надо» и «как не надо». 4.2 Готовим правила и политики: где компания готова уступать, где - нет, какие оговорки допустимы. 4.3 Тюним промпты под стиль компании. Важно, чтобы AI действовал как наш юрист, а не юрист абстрактной компании. 5. Включаем AI-ревью. 5.1 Загруженный договор программно разбиваем на пункты. 5.2 LLM сравнивает каждый пункт с библиотекой (из пункта 4.1). 5.3 LLM предлагает комментарии и помечает риски. 5.4 Передаём документ юристу на итоговую проверку. 6. Дообучаем AI-агента на комментариях юриста. Сравниваем комментарии юриста и комментарии AI и, при необходимости, дорабатываем библиотеку эталонных пунктов или промпты, чтобы AI точнее оставлял комментарии. Итоговый пайплайн получается такой: Sales-команда заводит договор в CRM AI сразу делает проверку и оставляет комментарии Юрист подключается только если есть риски или нестандартные условия При этом LogicMonitor решили, что им достаточно 80% точности при проверке входящего контракта. Это позволило быстрее запустить решение и обкатывать его на практике. В итоге сроки первичного ревью сократились с 10 часов до 10 минут. Хотите так же у себя → пишите мне, подскажу, чем могу. #AI_first_компании

Чек-листы по построению AI-Native Engineering Team от OpenAI Если у вас разработка ещё не AI-native — тогда мы идём к вам. По гайду от OpenAI разберём, как применять AI для AI-native-разработки по SDLC-блокам. Планирование Роль ИИ: превращать сырые идеи и бизнес-запросы в качественные инженерные задачи. Чек-лист: • Определить процессы, где нужно синхронизировать разные типы документации. Например, перенос документов в Jira-задачи или декомпозиция задачи на подзадачи. • Подключить ИИ к одной из таких задач. • Усложнить задачу ИИ: пусть он проверяет реализацию кода по описанию задачи, выявляя несостыковки. Дизайн и прототипирование Роль ИИ: сокращать путь от идеи до интерфейса, от интерфейса до компонентов. Чек-лист: • Использовать мультимодальных агентов, чтобы они понимали картинки, а не только текст. • Подключить вашу Figma через MCP к агенту (например, к Cursor или Windsurf — сам сделал, удобно). • Настроить workflow, чтобы ИИ по компонентам дизайна автоматически собирал компоненты в коде. • Использовать типизированные языки программирования (будет меньше проблем). Разработка Роль ИИ: разработка фичи end-to-end. Чек-лист: • Задача для ИИ должна быть хорошо описана. • Использовать PLAN.md, куда агент сначала будет писать план своих действий, разработчик его проверяет, и только затем агент кодит по этому плану. • Использовать AGENTS.md с детализацией того, что можно делать агенту, а что — нет. Дайте ему возможность самому проверять задачи и использовать линтеры. Тестирование Роль ИИ: контролировать edge-кейсы и регресс. Чек-лист: • Настроить агента для генерации тестов отдельным шагом, а не в процессе разработки. • Проверять, что тесты падают до реализации кода (читай — Test Driven Development). • Задать стандарты покрытия кода тестами в AGENTS.md. • Дать агенту инструменты для проверки процента покрытия кода. Код-ревью Роль ИИ: быть самым терпеливым ревьюером. Чек-лист: • Собрать «золотой набор» pull-request’ов, которые проревьюили ваши инженеры. • Использовать этот набор для выбора подходящего ИИ-решения для код-ревью. • Определить, как ваша команда будет отмечать хорошие/плохие ревью. Для начала можно просто ставить эмодзи в реквесте. Потом придумать что-то посложнее. Документация Роль ИИ: превращать код в понятные и доступные знания. Чек-лист: • Провести пару экспериментов с автогенерацией документации с помощью агентов. • Определить части процесса, где документация может быть сгенерирована автоматически. • Вставить правила автогенерации документации в AGENTS.md. • Вручную проверять сгенерированные документы. Деплой и поддержка Роль ИИ: быть помощником при инцидентах и деградациях. Чек-лист: • Подключить логи деплой-системы к агенту. • Ограничить права доступа агентов, чтобы он не удалил вашу БД (где-то читал такую историю). • Подготовить шаблоны промптов для сценариев быстрой проверки логов, расследования инцидентов и т. п. • Постоянно улучшать workflow — давать агенту больше прав, улучшать промпты и т. п. Вообще, написал всё это и подумал, что такое золото, конечно, нужно за деньги отдавать, а не выкладывать в канал. Но у нас тут принцип give first — поэтому делюсь. И чтобы два раза не вставать -- вот статья о том, как сделать Android-приложение меньше чем за месяц (на агентах — да). Пробуйте, тестируйте, пишите, если нужна помощь.

AI-инструменты Кажется, что AI уже везде. У нас есть много горизонтальных AI-решений — записи звонков с транскрипцией, генерация мемов каждую пятницу, Perplexity для поиска и т.п. В то же время вертикальные агенты развиваются медленнее - это связано с тем, что не существует универсального решения, потому что все бизнесы разные. Каждый вертикальный агент должен быть сильно адаптирован под компанию и её конкретные процессы. Поэтому активно развиваются no-code/low-code инструменты, которые (по легенде) должны позволить бизнесу (или подрядчикам бизнеса, таким как КОД9) самостоятельно настраивать себе AI-агентов. Сегодня у нас на обзоре Dify.ai. Мы активно используем Dify на нескольких проектах. Фактически это low-code LLM-бэкенд, у которого есть: 1. Встроенный RAG-движок. Вы загружаете документы — он их сам чанкает, показывает чанки, всё можно настроить и подобрать нужные RAG-параметры. Мы не тестировали на большом массиве (500+), но на нескольких десятках документов работает отлично. 2. Готовые интеграции с большим количеством инструментов — поиски, базы данных. 3. Возможность работать как MCP-сервер (кстати, напишу пост про это). 4. Всё это добро можно легко интегрировать через API со своим бэкендом или фронтендом. 5. Ну и плюс — это open source, который можно поставить себе на сервер. Пробуйте, тестируйте, пишите, если нужна помощь. #AI-инструменты

AI first компании В мире моих снов Искуственный интеллект делает всю скучную работу, а мы люди занимается творчеством и исследуем космос. В этой рубрике я хочу разбирать компании, которые уже сейчас активно применяют AI у себя и меняют процессы. Eightfold -- HR-tech компания, основанная бывшими инженерами Гугла, изначально использовали AI для сопоставления резюме с ролями. Дальше стали сделали полноценный agentic AI у себя. Как там все работает: 1. AI-моделька оценивает резюме кандидата на предмет соответствия требованиями текущей вакансии. 2. Если резюме интересное -- AI-интервьювер сразу предлагает кандидату созвониться и задает вопросы. Во время звонка LLM-ка может углубиться и задать дополнительные вопросы в тех зонах, где кандидат отвечет неуверенно. Вот тут видео. 3. По результатам звонка, система создает карточку кандидата и выделает самых подходящих кандадатов из всего набора. Дальше эта информацию уходит HR-специалисту для анализа и принятий решения, кого нанимать. Как по простому сделать такое решение себе? Модуль оценки резюме не будем трогать, разберем для примера AI-интервьювера. Нам понадобиться такой набор артефактов: 1. Сценарий звонка-собеседования или набор вопросов или и то и другое. Люди пока делают такие штуки лучше машин, потому что в этой области много эмпирических знаний. 2. Голосовой AI-сервис, Eleven-labs или аналог (Voximplant, Veyra, you name it). Слушает, говорит в ответ, делает все это по промту. В промте - наш сценарий. Такие сервисы инкапсулируют (собирают) в себе кучу технологических решений, в которых мы точно не хотим разбираться для простого решения. 2. LLM которая обработает результаты звонка и сформирует резюме. Тут тоже понадобиться дать LLM какой-то шаблон для анализа. 3. Программная обертка, которая засунет результаты LLM в вашу любимую HR-систему, чтобы вы могли там работать с обработанными данными от кандидатов. Вроде все просто, но дьявол в деталях как обычно. Пробуйте, пишите, задавайте вопросы.

Подготовил короткую методичку: как думать и что делать, чтобы внедрить ИИ в свой бизнес: 1. Выберите один бизнес-процесс (стоимость ~0) Он должен быть ограниченным, понятным, не сквозным (не охватывать весь бизнес). Примеры: обработка обращений, сверка договоров, подготовка КП. Сразу определите метрики, по которым будете измерять эффект: что именно хотите получить - большую производительность, качество, скорость, или экономию. Если нет понимания результата, лучше не начинайте. 2. Найдите внутреннего эксперта (стоимость ~0) Человека, который хорошо понимает процесс, который хотите оптимизировать, знает все нюансы и исключения. Он вам понадобится на всех следующих шагах. 3. Опишите контекст и знания (стоимость 💸) Вместе с экспертом зафиксируйте все, что связано с процессом: глоссарий, регламенты, примеры как правильно и как неправильно. Соберите 20–30 реальных кейсов, они пригодятся для промптинга и тюнинга. 4. Сделайте прототип (стоимость 💸💸💸) Используйте лучшую доступную LLM. Соберите минимальное решение на n8n, вайб-кодинге или приходите в КОД9. Главная цель — понять, может ли ИИ вообще справиться с задачей. 5. Замерьте результат (стоимость ~0) Вернитесь к метрикам из шага 1 и проверьте эффект. Например: если ИИ может снять хотя бы 5% нагрузки с отдела поддержки, предзаполняя ответы на запросы, это уже хорошо, можно двигаться дальше. Если результат не меряется - дальше не двигайтесь, там будет сильно дороже. 6. Дорабатывайте прототип (стоимость 💸💸💸💸💸💸💸) Используйте все, что человечество придумало к 2025 году: тюнинг промптов, агентский RAG, работу с памятью, оптимизацию по токенам. Итеративно улучшайте качество и снижайте стоимость, пока результат не стабилен. 7. Достигли оптимума — двигайтесь дальше Если качество больше не растет, а стоимость не падает, вы в оптимуме.Это значит, что решение работает стабильно и приносит измеримую пользу. Теперь два варианта: а) масштабируйте его на соседние процессы, где логика похожа б) найдите новый процесс в компании, который можно улучшить тем же методом. Или приходите к нам в КОД9, мы уже такое делаем.

Мы тут сделали супер-проект и наконец оформили кейс про этой у себя на сайте. Для нашего клиента из Сингапура мы собрали настоящего ИИ-аналитика: чат-бота, который объединяет данные из разных систем и отвечает на запросы прямо в слаке за минуты. Раньше, чтобы получить необходимую аналитику, менеджеры ждали ответы аналитиков по пол дня. Теперь они пишут в Slack сообщение аля: Покажи суда, где за неделю были нарушения по геозонам и повышенная усталость экипажа И через 1-2 минуты получают ответ. Все это работает на RAG, базе доменных знаний и централизованном DWH + Kafka + БД. За счет описанной семаники ИИ понимает весь специфический контекст индустрии и сама решает, из каких систем собрать нужную информацию. Все это мы делали 5 месяцев, потом еще смотрели как все работает и наконец может похвастаться кейсом: https://code9.studio/cases/ai-analitik

Я продолжаю про агентские компетенции, которые нужны чтобы делать свой продукт. Разработка, дизайн, UX, аналитика — всё это важно. Но делая продукт, команда должна понимать как продукт выходит на рынок -- Go-To-Market. Go-To-Market — этото такой как бы мост между созданием продукта и его жизнью на рынке. Без этого мостика ваш продукт провалится в яму) Из чего состоит Go-To-Market-компетенция: 1. Клиенты. Понимание, кто клиент, где он, как принимает решения. 2. Позиционирование. Чёткий ответ на вопрос "почему нас вообще-то должны купить" , выраженный в простых и понятных логических рассуждениях, по возможности без абстракций (бизнес вообще не любит абстракции когда речь идет о покупках софта) 3. Дистрибуция. Какие каналы реально работают, какие — иллюзия. 4. Настройка итерации на основе метрик. Самая интересная и недооцененая часть GTM-подхода. Идея в том что мы сделали продукт и запустили его, а дальше все не заканчивается а только начинается. Нужно опредить по каким метрикам мы следим за успехом продукта, как собираем обратную связь от пользователей, как это все преоретизируем и как меняем/докручиваем/усиливаем продукт чтобы повысить его ценность/виральность/ретеншен и т.п. Вообщем если делает продукт, то сначала делайте GTM-часть а потом уже саму разработку.

ChatGPT выпустил свой браузер — Atlas, пока только под Mac. Я конечно поставил себе и пошел тестить. Попросил агента посмотреть что там в воронке в АМО

посмотри все сделки в воронке SMB и скажи какие их них давно пора удалить

На скриншоте как раз этот процесс. Работает все с черепашьей скоростью пока что. Надо тестить дальше

Какие компетенции есть у агентства VS какие будут нужны в будущем Какие есть сейчас: 1. Технические/ремесленные: как разработать работающий цифровой продукт. Такая базовая история, которую все имею и поэтому она стала коммодити. 2. Продуктовые: какой должен быть продукт, чтобы он был логичным для пользователя. Иногда есть, иногда частично, иногда совсем нет. Когда нет - берем клиентов только с готовым ТЗ или занимаемся аутстаффом. 3. Операционно-проектные: как вести бизнес с точки зрения проектов, денег и бумаг. Мы умеем делать проекты с заданной маржинальностью и выбивать дебиторку) 4. Аккаунтиновые и нетворкинговые - как выстраивать отношения с потенциальными и существующими B2B-клиентами чтобы он хотел дальше с вами работать. Если есть - клиенты работают с вами годами. Если нет - уходят после первого проекта. 5. Продажи и переговоры - как понимать своего B2B клиента, диагностировать его проблему, задавать правильные вопросы. Сюда входит и умение скринить клиента и не брать всякий скам, которые сожгет время и не принесет денег. 6. Маркетинговые и пиарные - как всем рассказывать что вы делаете и умеете делать. Потенциальные клиенты должны знать о ваших успехах из сторонних источников. Пока писал поиск придумал визуализировать это в виде гексограммы.

Уникальный шанс для студий Считаю, что сейчас у студий уникальный шанс трансформироваться и стать продуктовыми компаниями. Почему так? 1. ИИ-трансформация В ближайшие 3-5-10 лет любому бизнесу, чтобы выжить, нужно будет внедрить ИИ по всей своей вертикали — начиная от найма и заканчивая продажами. Для этого придется создать массу IT-продуктов. Нас ждут новые таск-трекеры с ИИ (Notion уже пытается), ITSM-системы, МИСы, где ИИ будет апсейлить клиентов и т.п. Всех этих продуктов ЕЩЁ НЕТ, их нужно будет КОМУ-ТО СОЗДАТЬ. Вчерашние студии могут этим заняться. 2. B2B-продукты Студии исторически работают на B2B-рынке, понимают его, умеют (или не умеют :)) делать B2B-продажи. Поэтому трансформация в B2B-продакт-мейкинг будет более органичной, чем в B2C. Когда появились мобильные телефоны, все хотели делать пользовательские приложения, но никто не понимал B2C-аудиторию, как делать продукты для конечных пользователей, как их продавать, как позиционировать — это все сильно сложно в случае с B2C. С B2B все иначе. 3. Рынок для B2B Количество требуемых B2B-продуктов значительно больше, чем B2C, а конкуренция значительно меньше. Да, и потенциальный заработок с одной единицы продукта может быть меньше, но он всё равно есть. Под каждую вертикаль бизнеса нужны будут новые продукты с новой идеологией (AI-first) и новыми пользовательскими сценариями. 4. Налоговые изменения Всем уже понятно, что в дальнейшем налоги будут повышаться, а льготы — убираться. Поэтому перепродажа ресурсов (а это то, что делают все студии, даже те, кто это отрицает) будет становиться всё менее выгодной. В продуктовой разработке при правильной работе получается совсем другой мультипликатор на человека, и это сделает продуктовую модель более привлекательной, чем продажа часов разработки с фиксированным мультипликатором. 5. Компетенции Все эти изменения потребуют от студий развития новых компетенций. Каких именно — напишу в следующий раз.