Целый квартал внедряешь AI на бэкенд. Продумываешь оркестрацию, пишешь промпты, прикручиваешь и откручиваешь тулы. Тестируешь, фиксишь пограничные случаи. Выкатываешь в прод. Работает.
Через два месяца выходит новая модель. Большая часть архитектуры превращается в легаси.
В этом году примеров была масса, вспомните хотя бы последний горячий релиз GPT-5 и как круто начал на ней работать курсор.
Новые LLM могут менять поведение AI системы непредсказуемо. Иногда хуже. Иногда наоборот становится много лучше — выходит реально умная модель и твоя сложная оркестрация оказывается вообще не нужна.
Смена моделей не похожа на framework churn во фронтенде. Это фундаментально хуже. Нет ченджлогов, гайдов или автоматической миграции. Система может быть просто завязана на чёрный ящик.
---
Разработчики не переписывают софт под новую версию PostgreSQL.
DevOps не пересобирают всю инфру под новый Kubernetes.
Но AI-системы часто строят как монолит вокруг модели.
Чем это отличается от платформы которая в процессе разработки смертельным узлом завязалась на Stripe, и другие платежные системы не внедряет годами, не смотря на просьбы клиентов?(не внедряет не сколько потому что все равно, а потому что игра не стоит свеч – переписывать слишком много, ну или просто не знают как переписать, чтобы ничего не сломать)
Проблема не в том, что модели меняются.
Проблема в том, что модель делают частью big-ball-of-mud архитектуры.
Правильный подход: модель = внешняя зависимость. Как БД. Как API.
Не "система на GPT". Система с LLM-модулем.
Как такое строить:
1. Model-agnostic контракты — система не знает что внутри Claude или GPT. Только контракты входа-выхода.
2. Тестируйте внешнее поведение — модель меняется, промпты меняются. Eval тесты остаются.
3. Изолируйте model-specific логику — оркестрация, память, планирование живут отдельно от генерации токенов и от ключевой бизнес логики.
4. Версионируй это, версионируй то — промпты, конфиги, eval датасеты. Откатиться должно быть возможным намного быстрее чем тушить пожар.
Это не защита от переписывания. Это защита от того, чтобы переписывание не превращалось в спринты боли.
Разрабатываете AI систему и хотите обсудить архитектуру которая переживёт GPT-6?
Приходите на консультацию @m0n0x41d💗
Через два месяца выходит новая модель. Большая часть архитектуры превращается в легаси.
В этом году примеров была масса, вспомните хотя бы последний горячий релиз GPT-5 и как круто начал на ней работать курсор.
Новые LLM могут менять поведение AI системы непредсказуемо. Иногда хуже. Иногда наоборот становится много лучше — выходит реально умная модель и твоя сложная оркестрация оказывается вообще не нужна.
Смена моделей не похожа на framework churn во фронтенде. Это фундаментально хуже. Нет ченджлогов, гайдов или автоматической миграции. Система может быть просто завязана на чёрный ящик.
---
Разработчики не переписывают софт под новую версию PostgreSQL.
DevOps не пересобирают всю инфру под новый Kubernetes.
Но AI-системы часто строят как монолит вокруг модели.
Чем это отличается от платформы которая в процессе разработки смертельным узлом завязалась на Stripe, и другие платежные системы не внедряет годами, не смотря на просьбы клиентов?
Проблема не в том, что модели меняются.
Проблема в том, что модель делают частью big-ball-of-mud архитектуры.
Правильный подход: модель = внешняя зависимость. Как БД. Как API.
Не "система на GPT". Система с LLM-модулем.
Как такое строить:
1. Model-agnostic контракты — система не знает что внутри Claude или GPT. Только контракты входа-выхода.
2. Тестируйте внешнее поведение — модель меняется, промпты меняются. Eval тесты остаются.
3. Изолируйте model-specific логику — оркестрация, память, планирование живут отдельно от генерации токенов и от ключевой бизнес логики.
4. Версионируй это, версионируй то — промпты, конфиги, eval датасеты. Откатиться должно быть возможным намного быстрее чем тушить пожар.
Это не защита от переписывания. Это защита от того, чтобы переписывание не превращалось в спринты боли.
Разрабатываете AI систему и хотите обсудить архитектуру которая переживёт GPT-6?
Приходите на консультацию @m0n0x41d
Please open Telegram to view this post
VIEW IN TELEGRAM
Многие начинающие AI-инженеры, программисты, предпринимающие первые попытки внедрения AI в формате «разговорный интерфейс», допускают болезненную ошибку – всегда делают поддержку контекста диалога.
Контекст распухает, биллинг за токены вызывает дрожь в пятках.
(цитирую: "Алерт от порогов в OpenAI пришёл на 2 недели раньше чем мы рассчитывали.")
А решение часто на виду, просто оно контринтутивно – не делать поддержку контекста диалога вообще.
Особенно для MVP.
При рассмотрении решаемой проблемы и ценности для конечного пользователя часто выясняется, что проект хорошо реализуется более простыми методами.
Когда вы и ваша команда думаете над новой фичей/продуктом – не уходите на уровень реализации прежде, чем хотя бы немного формально опишете сценарии использования.
Если вы испытываете сложности со своим AI-проектом – Приходите на консультацию!
Разберёмся где сэкономить и сделать надёжнее
@m0n0x41d❤️
Контекст распухает, биллинг за токены вызывает дрожь в пятках.
(цитирую: "Алерт от порогов в OpenAI пришёл на 2 недели раньше чем мы рассчитывали.")
А решение часто на виду, просто оно контринтутивно – не делать поддержку контекста диалога вообще.
Особенно для MVP.
При рассмотрении решаемой проблемы и ценности для конечного пользователя часто выясняется, что проект хорошо реализуется более простыми методами.
Когда вы и ваша команда думаете над новой фичей/продуктом – не уходите на уровень реализации прежде, чем хотя бы немного формально опишете сценарии использования.
Если вы испытываете сложности со своим AI-проектом – Приходите на консультацию!
Разберёмся где сэкономить и сделать надёжнее
@m0n0x41d
Please open Telegram to view this post
VIEW IN TELEGRAM
Вы сами не до конца понимаете что делает ваш AI модуль на бекенде?
Ничего, похоже это "нормально" в настоящих реалиях.
Я не открою новых секретов, арка уже классическая – чтобы четко понимать что делает ваша AI система нужна понятная, читаемая, и хотя-бы немного формальная спецификация/дока.
Ключевые слова тут – "хотя-бы немного", потому что я прекрасно понимаю ритмы команд, особенно стартапов. Это ведь норма и база – быстро создавать MVP и итерироваться.
Проблема в том что часто не происходит своевременная смена лыж, и разработка продолжается в режиме бесконечного интуитивного "творчества."
Минимальный формальный подход тут возможен такой – смотреть на то что именно система должна делать – не в ваших фантазиях, и не в фантазиях ваших клиентов, а что именно решается в реальности, вот в той где бьешься мезинцем об угол стола.
Так что гораздо выгоднее(при том в любой перспективе) немного притормозить и рассмотреть фичи именно в функциональном разрезе.
Например оказывается, что несколько логических "веток" пайплайна извлекающего намерения пользователя вовсе не разные ветки, потому что по итогу заканчиваются в очень похожей, или вообще в одной и той-же бизнес логике.
Если вовремя это не исправить, это потенциальная дорога в наслоение неоптимизированных концепций в систему и промпт(ы), а значит – дорога в галлюцинации, дорогую и медленную разработку в будущем.
Смотрите на решаемые задачи из самой задачи, из прибитого логическим гвоздями функционала, из реальности, а не из соображений о некоторой "возможной реальности."
Твист в том что это удивительно редкий навык - вовремя остановиться и переключиться на стратегическую работу.
Проведите вот такое упражнение:
Возьмите свою AI систему и для каждой ее "фичи" выпишите одно предложение - что она делает для конечного пользователя. Если предложения похожи - возможно у вас дубликаты.
Приходите на консультацию, разберемся с любыми "реальностями"!
@m0n0x41d💗
Ничего, похоже это "нормально" в настоящих реалиях.
Я не открою новых секретов, арка уже классическая – чтобы четко понимать что делает ваша AI система нужна понятная, читаемая, и хотя-бы немного формальная спецификация/дока.
Ключевые слова тут – "хотя-бы немного", потому что я прекрасно понимаю ритмы команд, особенно стартапов. Это ведь норма и база – быстро создавать MVP и итерироваться.
Проблема в том что часто не происходит своевременная смена лыж, и разработка продолжается в режиме бесконечного интуитивного "творчества."
Минимальный формальный подход тут возможен такой – смотреть на то что именно система должна делать – не в ваших фантазиях, и не в фантазиях ваших клиентов, а что именно решается в реальности, вот в той где бьешься мезинцем об угол стола.
Так что гораздо выгоднее
Например оказывается, что несколько логических "веток" пайплайна извлекающего намерения пользователя вовсе не разные ветки, потому что по итогу заканчиваются в очень похожей, или вообще в одной и той-же бизнес логике.
Если вовремя это не исправить, это потенциальная дорога в наслоение неоптимизированных концепций в систему и промпт(ы), а значит – дорога в галлюцинации, дорогую и медленную разработку в будущем.
Смотрите на решаемые задачи из самой задачи, из прибитого логическим гвоздями функционала, из реальности, а не из соображений о некоторой "возможной реальности."
Твист в том что это удивительно редкий навык - вовремя остановиться и переключиться на стратегическую работу.
Проведите вот такое упражнение:
Возьмите свою AI систему и для каждой ее "фичи" выпишите одно предложение - что она делает для конечного пользователя. Если предложения похожи - возможно у вас дубликаты.
Приходите на консультацию, разберемся с любыми "реальностями"!
@m0n0x41d
Please open Telegram to view this post
VIEW IN TELEGRAM
#ai_on_backend
MCP сервер – это не обязательно «плагин»
Типичное отношение к MCP серверам слишком часто интуитивно - это отношение как к плагину с рядом инструментов.
Вот есть наш AI клиент, и вот мы подключаем сервер, привнося в клиент новые функциональные возможности.
В дефолтной интуиции разработчики MCP сервера часто тоже – «навешаю ка я в него сразу весь CRUD: create_news, update_news, delete_news, get_categories, assign_category, check_duplicate...
И вот клиент захлебывается в инструментах, контекст раздувается, со всеми небезызвестными вытекающими.
***
Вот когнитивный трюк: относитесь к MCP серверу в первую очередь как к серверу.
Как к отдельной самостоятельной сущности, что отвечает за кусок бизнес-логики и инкапсулирует её, а не просто «предоставляет наружу»!
Смотрите на разработку MCP через призму DDD/bounded contexts, и естественным образом начнете принимать правильные решения в проектировании интерфейса.
Реальный пример: Делаю новостной агрегатор - дашборда для событий и алертов. Есть сущность "новость" с категориями, комментариями.
Уже достаточно, чтобы следуя «интуитивным» подходам разработать обычный такой жирненький CRUD.
По ряду причин AI на бэкенд дашборды было решено не внедрять, а подключать извне через MCP протокол.
Это значит что агент(ы) должны подписываться на свои источники и наполнять дашборду.
Немного подумав я понял что в этом MCP нужен только один инструмент —
И всё.
Никаких get_categories, никаких апдейтов топиков, никаких манипуляций — пока они реально не потребуются.
Агенту даже знать не нужно, была ли новость уже обработана — сервер сам отвечает за дедупликацию и всё остальное, это кодируется элементарно.
Таким образом я сильно разгрузил предыдущий вариант системы, теперь есть несколько внешних агентов-сборщиков, у которых вместо 6-8 инструментов и лишних токенов в контексте - два-три инструмента!
(инструмент от дашборды для публикации, и остальные только для работы со своим источником навостей – поисковик, кравлер, gmail, отдельные rss и так далее)
MCP сервер – это не обязательно «плагин»
Типичное отношение к MCP серверам слишком часто интуитивно - это отношение как к плагину с рядом инструментов.
Вот есть наш AI клиент, и вот мы подключаем сервер, привнося в клиент новые функциональные возможности.
В дефолтной интуиции разработчики MCP сервера часто тоже – «навешаю ка я в него сразу весь CRUD: create_news, update_news, delete_news, get_categories, assign_category, check_duplicate...
И вот клиент захлебывается в инструментах, контекст раздувается, со всеми небезызвестными вытекающими.
***
Вот когнитивный трюк: относитесь к MCP серверу в первую очередь как к серверу.
Как к отдельной самостоятельной сущности, что отвечает за кусок бизнес-логики и инкапсулирует её, а не просто «предоставляет наружу»!
Смотрите на разработку MCP через призму DDD/bounded contexts, и естественным образом начнете принимать правильные решения в проектировании интерфейса.
Реальный пример: Делаю новостной агрегатор - дашборда для событий и алертов. Есть сущность "новость" с категориями, комментариями.
Уже достаточно, чтобы следуя «интуитивным» подходам разработать обычный такой жирненький CRUD.
По ряду причин AI на бэкенд дашборды было решено не внедрять, а подключать извне через MCP протокол.
Это значит что агент(ы) должны подписываться на свои источники и наполнять дашборду.
Немного подумав я понял что в этом MCP нужен только один инструмент —
publish_news. И всё.
Никаких get_categories, никаких апдейтов топиков, никаких манипуляций — пока они реально не потребуются.
Агенту даже знать не нужно, была ли новость уже обработана — сервер сам отвечает за дедупликацию и всё остальное, это кодируется элементарно.
Таким образом я сильно разгрузил предыдущий вариант системы, теперь есть несколько внешних агентов-сборщиков, у которых вместо 6-8 инструментов и лишних токенов в контексте - два-три инструмента!
СТО в вашем стартапе на сегодняшнем мите сказал: "Нам в команде хватит 3 сеньоров вместо 10 разработчиков".
Возможно он не шутит.
Скорее всего вы уже забыли про исследование METR, где обнаружилось что AI в прикладной работе разработчиков часто замедляет, а не ускоряет.
А вот свежее от Anthropic – на базе 100K разговоров с Claude 132-ух инженеров внутри компании.
Результат - 80% экономии времени. Дарио Амодей говорит: "70-80-90% кода в Anthropic пишет Claude"👀
Один из их инженеров: "Такое чувство, что я прихожу на работу каждый день, чтобы самого себя этой же работы лишить".
Как так?
METR: AI замедляет на 19%
Anthropic: AI ускоряет на 80%
Разница в 99 процентных пунктов. Кто врёт?
Никто.
Это не про инструмент. Это про то, как мы работаем.
Вот как это движение в правильную сторону выглядит на практике:
Anthropic сегодня анонсировали прокаченный Claude + Slack. Тегаешь @Claude в треде - и он теперь решает сам: либо просто ответить в контексте, либо автоматически создать сессию Claude Code и делегировать задачу туда.
От алерта до PR с минимальным участием человека.
Раньше баги или отправлялись в вечный беклог, или лениво копились в "in progress" и нагружали и без того уставших разработчиков дополнительным переключением внимания.
Просто METR измеряли "дали разработчику Cursor и смотрим что будет". А Anthropic измеряли AI, встроенный в процессы разработки, скорее всего еще и с довольно строгой инженерной культурой и методами работы с этим AI.
Вот разница.
Первое, это когда вы купили дорогой инструмент и ждёте магии. А второе, это когда вы перестроили процессы и методы работы под сильные стороны AI, именно то за что я всю дорогу топлю в этом блоге.
А теперь представьте недалекое будущее:
Команда из 10 разработчиков: -> 7 фиксят техдолг, баги, клепают мелкие круд задачи → 3 синьора/техлида проектируют новое
VS
Команда ТОЛЬКО из тех самых 3 сеньоров++ с Claude: -> Claude фиксит техдолг, баги, круд (тегаешь @claude в Slack с Sentry алертами) -> 3 инженера проектируют новые фичи и решения
Производительность выше. Затраты ниже. И да, очень гурбо, но ~7 человек больше не нужны.
Эти ресурсы можно перераспределить или на маркетинг, или компенсировать за повышенное число закрываемых задач мега-сеньорам 🙂
Да, сейчас в интеграции Claude Code в слак есть баг - контекст треда не передаётся в сессию. Но это просто баг. Его исправят за неделю, максимум две.(Скорее всего намного быстрее – ибо это ломает смысл интеграции более чем полностью)
Так что будущее вот вот наступит, да?
И это будущее не в том, чтобы дать каждому разработчику AI-ассистента и ждать не пойми чего. Ускорение генерации плохого кода мы уже проходили.
Будущее в том, чтобы встроить AI в процессы: от алерта до PR с минимальным участием человека.
Кстати, в METR исследовании не до конца понятна компетенция разработчиков в системном мышлении и работе с LLM ассистентами. Возможно, проблема не в AI, а в том, как люди с ним работают.
Даёте команде AI-инструменты и ждёте magic? Получите -19%.
Встраиваете AI в процессы? Получите +80%.
Разница не в инструментах. Разница в том, как вы их используете.
Не знаете, как это делать правильно?
Приходите на консультацию: @m0n0x41d❤️
Возможно он не шутит.
Скорее всего вы уже забыли про исследование METR, где обнаружилось что AI в прикладной работе разработчиков часто замедляет, а не ускоряет.
А вот свежее от Anthropic – на базе 100K разговоров с Claude 132-ух инженеров внутри компании.
Результат - 80% экономии времени. Дарио Амодей говорит: "70-80-90% кода в Anthropic пишет Claude"
Один из их инженеров: "Такое чувство, что я прихожу на работу каждый день, чтобы самого себя этой же работы лишить".
Как так?
METR: AI замедляет на 19%
Anthropic: AI ускоряет на 80%
Разница в 99 процентных пунктов. Кто врёт?
Никто.
Это не про инструмент. Это про то, как мы работаем.
Вот как это движение в правильную сторону выглядит на практике:
Anthropic сегодня анонсировали прокаченный Claude + Slack. Тегаешь @Claude в треде - и он теперь решает сам: либо просто ответить в контексте, либо автоматически создать сессию Claude Code и делегировать задачу туда.
От алерта до PR с минимальным участием человека.
Раньше баги или отправлялись в вечный беклог, или лениво копились в "in progress" и нагружали и без того уставших разработчиков дополнительным переключением внимания.
Просто METR измеряли "дали разработчику Cursor и смотрим что будет". А Anthropic измеряли AI, встроенный в процессы разработки, скорее всего еще и с довольно строгой инженерной культурой и методами работы с этим AI.
Вот разница.
Первое, это когда вы купили дорогой инструмент и ждёте магии. А второе, это когда вы перестроили процессы и методы работы под сильные стороны AI, именно то за что я всю дорогу топлю в этом блоге.
А теперь представьте недалекое будущее:
Команда из 10 разработчиков: -> 7 фиксят техдолг, баги, клепают мелкие круд задачи → 3 синьора/техлида проектируют новое
VS
Команда ТОЛЬКО из тех самых 3 сеньоров++ с Claude: -> Claude фиксит техдолг, баги, круд (тегаешь @claude в Slack с Sentry алертами) -> 3 инженера проектируют новые фичи и решения
Производительность выше. Затраты ниже. И да, очень гурбо, но ~7 человек больше не нужны.
Эти ресурсы можно перераспределить или на маркетинг, или компенсировать за повышенное число закрываемых задач мега-сеньорам 🙂
Будем честны, AI помогает решать больше задач параллельно, но мозги все равно знатно от этого устают – никто не выкидвает инженера из цикла, ему все равно ревьювить PR от LLM и прочее.
Да, сейчас в интеграции Claude Code в слак есть баг - контекст треда не передаётся в сессию. Но это просто баг. Его исправят за неделю, максимум две.
Так что будущее вот вот наступит, да?
И это будущее не в том, чтобы дать каждому разработчику AI-ассистента и ждать не пойми чего. Ускорение генерации плохого кода мы уже проходили.
Будущее в том, чтобы встроить AI в процессы: от алерта до PR с минимальным участием человека.
Кстати, в METR исследовании не до конца понятна компетенция разработчиков в системном мышлении и работе с LLM ассистентами. Возможно, проблема не в AI, а в том, как люди с ним работают.
Даёте команде AI-инструменты и ждёте magic? Получите -19%.
Встраиваете AI в процессы? Получите +80%.
Разница не в инструментах. Разница в том, как вы их используете.
Не знаете, как это делать правильно?
Приходите на консультацию: @m0n0x41d
Please open Telegram to view this post
VIEW IN TELEGRAM