«На небе только и разговоров, что о море и о закате» — ой, это не про нас 😄
Сейчас на всех IT-конференциях одно модное словечко: AI (или «ЭйАй» — по-нашему).
🤔 Но как добавить реальной пользы этим AI-powered штукам? Чтобы они не просто болтали, а делали.
Сидел я, думал, как бы докрутить эту дурашку хоть до 0.2 Джарвиса (помощника Тони Старка, если что).
И нашел интересное! Есть MCP (Model Context Protocol) — открытый стандарт, своего рода «USB‑C для ИИ» 🔌
Проще говоря: MCP — это единый способ, по которому LLM (типа ChatGPT, Claude) общаются с внешним миром: календарями, почтой, задачами, базами данных.
С чем конкурирует? С Function Calling (OpenAI), Tool Use (Anthropic) и другими. Но у него ключевые плюсы:
✅ Не зависит от модели (работает с GPT, Claude, Llama)
✅ Динамическое обнаружение инструментов
✅ Постоянное соединение и работа с ресурсами
📌 Когда что выбрать? Кратко:
• MCP: Для сложных систем, где несколько ИИ должны работать с одними инструментами (например, в компании).
• Function Calling: Самый быстрый старт, если вы в экосистеме OpenAI.
• Классические API: Когда ИИ — не главный герой вашего продукта.
Я уже прикрутил доступные MCP-серверы к своим помощникам. Теперь они: 📅 смотрят в календарь, ✅ проверяют задачи в Тудушнике, ✉️ готовят письма. Стало значительно лучше!
Но чувствую, это только вершина айсберга.
Инструмент надо изучить глубже!
https://modelcontextprotocol.io/docs/getting-started/intro
Сейчас на всех IT-конференциях одно модное словечко: AI (или «ЭйАй» — по-нашему).
🤔 Но как добавить реальной пользы этим AI-powered штукам? Чтобы они не просто болтали, а делали.
Сидел я, думал, как бы докрутить эту дурашку хоть до 0.2 Джарвиса (помощника Тони Старка, если что).
И нашел интересное! Есть MCP (Model Context Protocol) — открытый стандарт, своего рода «USB‑C для ИИ» 🔌
Проще говоря: MCP — это единый способ, по которому LLM (типа ChatGPT, Claude) общаются с внешним миром: календарями, почтой, задачами, базами данных.
С чем конкурирует? С Function Calling (OpenAI), Tool Use (Anthropic) и другими. Но у него ключевые плюсы:
✅ Не зависит от модели (работает с GPT, Claude, Llama)
✅ Динамическое обнаружение инструментов
✅ Постоянное соединение и работа с ресурсами
📌 Когда что выбрать? Кратко:
• MCP: Для сложных систем, где несколько ИИ должны работать с одними инструментами (например, в компании).
• Function Calling: Самый быстрый старт, если вы в экосистеме OpenAI.
• Классические API: Когда ИИ — не главный герой вашего продукта.
Я уже прикрутил доступные MCP-серверы к своим помощникам. Теперь они: 📅 смотрят в календарь, ✅ проверяют задачи в Тудушнике, ✉️ готовят письма. Стало значительно лучше!
Но чувствую, это только вершина айсберга.
Инструмент надо изучить глубже!
https://modelcontextprotocol.io/docs/getting-started/intro
Обожаю момент ловли инсайта — не процесс, а сам результат! 😎 Особенно когда он помогает доформулировать мысль, которая крутилась в голове, и вдруг — всё укладывается в стройную картину.💆
Жаль, что не всегда успеваешь записать её, пока она свежая и чёткая. Вчера с женой обсуждали майндсеты — образы мышления и принятия решений. Выделили два:
• Doer: “Потерплю, сэкономлю, но сделаю сам” 👨🌾
• Entrepreneur: “Пойму задачу, привлеку ресурсы, сэкономлю время”🤵♂️
Оба имеют право на жизнь, но в нашей суровой северной ментальности стоит развивать второй — предпринимательский.
Преимущества зависят от контекста.
А ещё есть корпоративные майндсеты, ну те, которые помогают в корпоративно жизни.
Сегодня запомнился “достигатель”, которого можно описать цитатой председателя совета директоров банка — “Если я сам в своём кабинете тебе ещё не отказал в реализации того, что ты хочешь сделать — значит, ты для этого сделал ещё недостаточно”
Мотивирует?
Жаль, что не всегда успеваешь записать её, пока она свежая и чёткая. Вчера с женой обсуждали майндсеты — образы мышления и принятия решений. Выделили два:
• Doer: “Потерплю, сэкономлю, но сделаю сам” 👨🌾
• Entrepreneur: “Пойму задачу, привлеку ресурсы, сэкономлю время”🤵♂️
Оба имеют право на жизнь, но в нашей суровой северной ментальности стоит развивать второй — предпринимательский.
Преимущества зависят от контекста.
А ещё есть корпоративные майндсеты, ну те, которые помогают в корпоративно жизни.
Сегодня запомнился “достигатель”, которого можно описать цитатой председателя совета директоров банка — “Если я сам в своём кабинете тебе ещё не отказал в реализации того, что ты хочешь сделать — значит, ты для этого сделал ещё недостаточно”
Мотивирует?
✍1
По следам поста про "Зачем СТО пишет код" - пишу про "Почему СТО не должен писать код" и коротко не получается.
Получается очень контекстозависимо.
Версии от TechCrunch victim до GreenField хипстеров.
Потому спрошу у вас:
Какие причины видите, по которым CTO лучше уже не писать промышленный код?
Получается очень контекстозависимо.
Версии от TechCrunch victim до GreenField хипстеров.
Потому спрошу у вас:
Какие причины видите, по которым CTO лучше уже не писать промышленный код?
Ключевой навык при работе с GPT — критическое мышление. Без него никак 😎
С вечеринки жена притащила домой какую-то фигурку — странную, но милую. Спросил у GPT, что это такое.
Результат:
Алиса: уверенно заявила, что это "брейнрот" и сразу предложила купить набор. Коммерсантка, что сказать.
Perplexity: спокойно и чётко — «Брекнрот», вот имя, вот описание, всё по делу.
GIGA: «Это персонаж из советского мультфильма “Летучий корабль”. Лягушка, с колесом вместо тела и палками вместо ног».
Обожаю, его галлюцинации 🐸✨
С вечеринки жена притащила домой какую-то фигурку — странную, но милую. Спросил у GPT, что это такое.
Результат:
Алиса: уверенно заявила, что это "брейнрот" и сразу предложила купить набор. Коммерсантка, что сказать.
Perplexity: спокойно и чётко — «Брекнрот», вот имя, вот описание, всё по делу.
GIGA: «Это персонаж из советского мультфильма “Летучий корабль”. Лягушка, с колесом вместо тела и палками вместо ног».
Обожаю, его галлюцинации 🐸✨
😁3
Context engineering vs prompt engineering
Пару последних недель я часто сталкиваюсь с публикациями коллег, посвящёнными ожиданиям и оценке эффективности внедрения инструментов на основе искусственного интеллекта. В профессиональном сообществе нередко звучит мнение, что без ИИ сегодня «ничего не работает», и что любые инструменты на его основе якобы гарантированно дадут эффект.
С августа я занимаюсь процессом популяризации и внедрения AI‑инструментов в нашу производственную среду. Для нас производство — это, прежде всего, разработка программных продуктов, поэтому речь идёт о внедрении ИИ в контур PDLC (Product Development Lifecycle). Однако, вопреки ожиданиям, эти решения не «взлетают» так, как рассчитывалось.
https://iostech.ru/2025/12/context-engineering-vs-prompt-engineering/
Пару последних недель я часто сталкиваюсь с публикациями коллег, посвящёнными ожиданиям и оценке эффективности внедрения инструментов на основе искусственного интеллекта. В профессиональном сообществе нередко звучит мнение, что без ИИ сегодня «ничего не работает», и что любые инструменты на его основе якобы гарантированно дадут эффект.
С августа я занимаюсь процессом популяризации и внедрения AI‑инструментов в нашу производственную среду. Для нас производство — это, прежде всего, разработка программных продуктов, поэтому речь идёт о внедрении ИИ в контур PDLC (Product Development Lifecycle). Однако, вопреки ожиданиям, эти решения не «взлетают» так, как рассчитывалось.
https://iostech.ru/2025/12/context-engineering-vs-prompt-engineering/
👍1
🚀 Учимся на ошибках: 10 правил для AI-агентов с итогового митапа сообщества разработчиков
Все любят учиться — особенно на чужих ошибках. Я, например, обожаю ретроспективы и митапы, где разбирают три главных вопроса:
Что пошло не так?
Чему научились?
Что вынесли на будущее?
Вчера как раз прошёл финальный митап разработчиков AI-агентов для производственных процессов. Собрал для вас ценные инсайты — прямую выжимку их опыта.
Итак, 10 правил, которые стоит запомнить каждому, кто работает с агентами:
1. Хорошая идея — лишь начало. Без качественной реализации она ничего не стоит.
2. Команда — важнее технологии. Успех проекта решают люди.
3. Один агент — одна задача. Чем уже фокус, тем выше эффективность.
4. Профессиональные сообщества — сила. Используйте распределённый опыт и экспертизу.
5. Пользователь всегда хочет «другое». Смотрите на продукт с разных сторон, общайтесь с максимальным количеством юзеров.
6. Документация — это искусство. Всегда найдётся тот, кому не понятно.
7. Пользователь ждёт «серебряную пулю». И это нужно учитывать, управляя ожиданиями.
8. Масштабирование закладывается заранее. Хочешь роста — думай об архитектуре с самого начала.
9. Метрики — это всё. Определи, как их собирать и анализировать, ещё до старта.
10. Промпты можно отладить на чистом GigaChat. Качество работы агента начинается с качества запроса.
Это стоит выучить как мантру.
Согласны?
Все любят учиться — особенно на чужих ошибках. Я, например, обожаю ретроспективы и митапы, где разбирают три главных вопроса:
Что пошло не так?
Чему научились?
Что вынесли на будущее?
Вчера как раз прошёл финальный митап разработчиков AI-агентов для производственных процессов. Собрал для вас ценные инсайты — прямую выжимку их опыта.
Итак, 10 правил, которые стоит запомнить каждому, кто работает с агентами:
1. Хорошая идея — лишь начало. Без качественной реализации она ничего не стоит.
2. Команда — важнее технологии. Успех проекта решают люди.
3. Один агент — одна задача. Чем уже фокус, тем выше эффективность.
4. Профессиональные сообщества — сила. Используйте распределённый опыт и экспертизу.
5. Пользователь всегда хочет «другое». Смотрите на продукт с разных сторон, общайтесь с максимальным количеством юзеров.
6. Документация — это искусство. Всегда найдётся тот, кому не понятно.
7. Пользователь ждёт «серебряную пулю». И это нужно учитывать, управляя ожиданиями.
8. Масштабирование закладывается заранее. Хочешь роста — думай об архитектуре с самого начала.
9. Метрики — это всё. Определи, как их собирать и анализировать, ещё до старта.
10. Промпты можно отладить на чистом GigaChat. Качество работы агента начинается с качества запроса.
Это стоит выучить как мантру.
Согласны?
👍4
Продолжаю делиться инсайтами с митапов разработчиков ИИ-агентов.
Опытные AI инженеры рассказали о реальных сложностях, с которыми столкнулись в процессе создания AI-агентов, о новых навыках, которые им пришлось осваивать, и о том, как первоначальная оценка «да тут на 2-3 недели работы» превращалась в 5 месяцев от идеи и сбора команды до первого пром-релиза.
Итак, на что стоит обратить внимание и что нужно «прокачать» в своем стеке:
- LangChain - фреймворк, который значительно ускоряет разработку сложных LLM-приложений, избавляя от необходимости создавать базовую инфраструктуру с нуля.
- LangGraph - мощное расширение LangChain для построения агентских систем со сложной, нелинейной логикой, управляемыми потоками выполнения и сохранением состояния.
- LangFuse - must-have инструмент для production-среды. Помогает понять работу сложных цепочек, оптимизировать затраты и улучшать качество через детальный анализ трассировок и метрик.
- SkillFlow - фреймворк для создания кооперативных мульти-агентных систем, где каждый агент обладает уникальными, специализированными навыками.
- ChainLit (Claude) - самый быстрый способ «завернуть» вашу LLM-логику в полноценное веб-приложение с современным чат-интерфейсом.
Понятно, что для учебных или простых кейсов LangGraph и SkillFlow могут быть избыточны. Но мы с вами говорим о создании решений enterprise-уровня, да?
Поэтому обязательно изучайте, как эти инструменты применяются на практике: сами тестируйте, включайте в требования к вакансиям, добавляйте в LiveCode-интервью или просите показать примеры в портфолио на GitHub
Вот и мой план на поучиться в новогодние каникулы созрел.
Опытные AI инженеры рассказали о реальных сложностях, с которыми столкнулись в процессе создания AI-агентов, о новых навыках, которые им пришлось осваивать, и о том, как первоначальная оценка «да тут на 2-3 недели работы» превращалась в 5 месяцев от идеи и сбора команды до первого пром-релиза.
Итак, на что стоит обратить внимание и что нужно «прокачать» в своем стеке:
- LangChain - фреймворк, который значительно ускоряет разработку сложных LLM-приложений, избавляя от необходимости создавать базовую инфраструктуру с нуля.
- LangGraph - мощное расширение LangChain для построения агентских систем со сложной, нелинейной логикой, управляемыми потоками выполнения и сохранением состояния.
- LangFuse - must-have инструмент для production-среды. Помогает понять работу сложных цепочек, оптимизировать затраты и улучшать качество через детальный анализ трассировок и метрик.
- SkillFlow - фреймворк для создания кооперативных мульти-агентных систем, где каждый агент обладает уникальными, специализированными навыками.
- ChainLit (Claude) - самый быстрый способ «завернуть» вашу LLM-логику в полноценное веб-приложение с современным чат-интерфейсом.
Понятно, что для учебных или простых кейсов LangGraph и SkillFlow могут быть избыточны. Но мы с вами говорим о создании решений enterprise-уровня, да?
Поэтому обязательно изучайте, как эти инструменты применяются на практике: сами тестируйте, включайте в требования к вакансиям, добавляйте в LiveCode-интервью или просите показать примеры в портфолио на GitHub
Вот и мой план на поучиться в новогодние каникулы созрел.
10👍3
Достаточно ли новых навыков разработчиков для успешной разработки ИИ решений?
Нет, недостаточно.
Внедрение ИИ, или даже трансформация в AI native — это не просто еще один инструмент в арсенале команды. Это культурный сдвиг в подходе к разработке, особенно в том, как мы документируем и организуем архитектурные решения.
В классической разработке исполняемым компьютером является только код.🧑💻 От его качества зависит результат, что неизбежно создает возможность оставить западающие области в производственном цикле. Самые очевидные из них — документация и архитектурные описания.
Технические писатели и архитекторы, какими бы опытными они ни были, часто отстают от темпа работы разработчиков. История знакома всем: разработали, протестировали (как смогли), развернули (как договорились), работает — отлично, документацию доделаем позже.
Но с🤖 эта схема не работает.
При интеграции ИИ в разработку нужно общаться с ним по правилу “мусор на входе — мусор на выходе”. Это означает, что ИИ нужна полная и структурированная информация о проекте: документация, архитектура, стандарты. Если этой информации нет или она неполная, результаты будут неудовлетворительными.💀
Две практики, которые стоит внедрить для повышения эффективности работы ИИ:
1. DocAsCode — документация как исходный код
Документацию нужно рассматривать как часть кодовой базы:
• Писать в текстовых форматах (Markdown, reStructuredText), а не в бинарных (Word, PDF)
• Хранить в системе контроля версий (Git) вместе с кодом или рядом с ним
• Проводить код-ревью через pull/merge requests
• Автоматизировать сборку через CI/CD пайплайны
• Добавлять автоматизированные тесты на качество
2. ArchAsCode — архитектура как исходный код
Архитектурные решения, диаграммы и стандарты описываются через декларативные языки разметки, что позволяет:
• Верифицировать решения на соответствие установленным правилам
• Генерировать артефакты автоматически
• Развертывать инфраструктуру как код
• Тестировать архитектурные ограничения
• Версионировать все изменения
Это логическое развитие после Infrastructure as Code (IaC) — от автоматизации инфраструктуры к автоматизации самих архитектурных решений.
Будем разбирать в деталях?
Нет, недостаточно.
Внедрение ИИ, или даже трансформация в AI native — это не просто еще один инструмент в арсенале команды. Это культурный сдвиг в подходе к разработке, особенно в том, как мы документируем и организуем архитектурные решения.
В классической разработке исполняемым компьютером является только код.
Технические писатели и архитекторы, какими бы опытными они ни были, часто отстают от темпа работы разработчиков. История знакома всем: разработали, протестировали (как смогли), развернули (как договорились), работает — отлично, документацию доделаем позже.
Но с
При интеграции ИИ в разработку нужно общаться с ним по правилу “мусор на входе — мусор на выходе”. Это означает, что ИИ нужна полная и структурированная информация о проекте: документация, архитектура, стандарты. Если этой информации нет или она неполная, результаты будут неудовлетворительными.
Две практики, которые стоит внедрить для повышения эффективности работы ИИ:
1. DocAsCode — документация как исходный код
Документацию нужно рассматривать как часть кодовой базы:
• Писать в текстовых форматах (Markdown, reStructuredText), а не в бинарных (Word, PDF)
• Хранить в системе контроля версий (Git) вместе с кодом или рядом с ним
• Проводить код-ревью через pull/merge requests
• Автоматизировать сборку через CI/CD пайплайны
• Добавлять автоматизированные тесты на качество
2. ArchAsCode — архитектура как исходный код
Архитектурные решения, диаграммы и стандарты описываются через декларативные языки разметки, что позволяет:
• Верифицировать решения на соответствие установленным правилам
• Генерировать артефакты автоматически
• Развертывать инфраструктуру как код
• Тестировать архитектурные ограничения
• Версионировать все изменения
Это логическое развитие после Infrastructure as Code (IaC) — от автоматизации инфраструктуры к автоматизации самих архитектурных решений.
Будем разбирать в деталях?
Please open Telegram to view this post
VIEW IN TELEGRAM
Вот и до меня докатилось отключение подписки Perplexity PRO, купленной по серой схеме.
https://habr.com/ru/news/980202/
В целом подписка и её возможности интересные, но надо подумать над продлением, получше изучить возможности доступных нейросеток.
Какие ваши рекомендации?
https://habr.com/ru/news/980202/
В целом подписка и её возможности интересные, но надо подумать над продлением, получше изучить возможности доступных нейросеток.
Какие ваши рекомендации?
Хабр
Perplexity отключает годовые подписки, купленные через посредников за несколько сотен рублей
Судя по обсуждению на 4PDA, ИИ-поисковик Perplexity начал массово отзывать подписки Pro у пользователей, которые активировали их в обход официальных условий. Под удар попали те, кто покупал годовой...