LLM-клиент с MCP – дорогой и неэффективный подход в разработке
В наше время тяжело представить разработку цифровых продуктов, в которые хоть в какой-то степени не включили так называемый ИИ на больших языковых моделях (LLM). И я вовсе не против, но у меня вызывают вопросы подходы разработчиков к способам внедрения интеллектуальных инструментов в свои продукты.Думаю, абсолютное большинство оптимальным способом внедрения интеллекта в продукт выбрали использование проприетарных моделей через API, с добавлением кастомного функционала через вызовы MCP серверов. Кажется, это уже даже стало стандартом, и в этом я вижу проблему.
Принципы ответственной ИИ-ассистированной разработки ПО
Введение:Данный документ описывает систему взглядов и практических правил для интеграции ИИ-ассистентов в процесс разработки программного обеспечения. Цель — не запретить использование ИИ, а превратить его в управляемый инструмент, который повышает эффективность, не компрометируя качество, безопасность и ответственность инженера.Раздел I: Философские основы и расстановка ролейИИ — это не программист. ИИ — это инструмент, усилитель интеллекта, а не замена инженеру. Вы сохраняете полный контроль и ответственность за результат.
Cursor и ИИ-ассистенты ускоряют разработку — но без нормальных автотестов топят всю команду
Привет, Хабр. Пишу, потому что на текущем проекте прямо сейчас живу эту боль: всем включили Cursor «для скорости», а нормальных автотестов так и не завезли. Может, кто-то уже описывал этот кейс, но я не нашёл — поэтому делюсь своей ситуацией и тем, как это надо было делать с самого начала.Как это обычно происходитРуководство/CTO/кто-то сверху читает твиты про то, как «скорость разработки ×10 за счёт ИИ», проводит собрание и выдаёт директиву: «Теперь весь код пишем через Cursor или другие ИИ-ассистенты».
Как мы сократили время планирования спринтов с помощью AI
Привет! Меня зовут Саша, я Product Manager в Cloud.ru
CRISPR-GPT и копилот эволюции
Как ИИ входит в генную инженерию и почему это похоже на программирование кода жизни и сознания
OpenAI Guardrails: защита ИИ-приложений от атак
Всем привет!В этой статье разберёмся с OpenAI Guardrails — одним из самых эффективных инструментов для обеспечения безопасности ИИ-систем. Это продолжение цикла о защите и контроле ИИ-агентов, в первой части мы рассмотрели инструмент модерации запросов. Guardrails предоставляет намного более мощные возможности для защиты, позволяя создавать многоуровневую систему валидации входных и выходных данных.Если вам интересны детали, рекомендуем ознакомиться с дополнительными материалами из нашего Telegram-канала
Мальчик способный, но ленивый: история создания AI-агента для пресейл-оценки
На связи Георгий, аналитик SoftMediaLab. В этот раз хочу поделиться опытом создания ИИ-агента для оценки на пресейле.
Как юристу надоело объяснять, что дело швах: рождение «неШемяки!»
AI Legal веб-сервис для тех, кто устал гадать«Шемякин суд» — это не просто избитый фразеологизм, но реальность для многих, кто ввязался в судебную тяжбу, не оценив заранее все риски. Тысячи проигранных дел, потраченные нервы и деньги — всего этого можно было бы избежать, задай истец себе вовремя один простой вопрос: «Каковы мои шансы?». “неШемяка!” — это маленькое веб‑приложение, которое пытается ответить на один простой вопрос, есть ли хоть малейший смысл подавать иск, это сервис, который пытается отличить перспективное дело от заранее проигрышного.
Как сделать ИИ-агентов и RAG действительно автономными
Существует проблема описанная тут.Суть проста — если LLM (или агенты вокруг LLM) вызывают последовательно одни и те же запросы с одним и тем же контекстом, попадание в тупик/цикл — вопрос лишь времени. То есть в случае зацикливания между агентами/контекстами надо менять промты или сам контекст, или последовательность вызова агентов.Это яркая демонстрация, когда агенты, несмотря на всю свою сложность, тупят хуже моей кошки. Кошка не будет в цикле проверять две пустые миски в поисках еды: она сделает это раз, ну или два, и пойдёт дальше. А агенты будут, если наткнутся на такую ситуацию.
