Программирование *

Режим чата теперь работает по той же логике, что и агентный, но только с read-only инструментами — можно исследовать кодовую базу без риска случайных изменений. Edit mode убрали: его сценарии полностью покрывает агентный режим.

Появилось ветвление диалогов. Если агент пошёл не туда, можно вернуться к любому вызову инструмента в истории и продолжить оттуда — новая ветка не затрагивает предыдущую. А сами сессии теперь можно экспортировать в JSON.

Для мультимодальных моделей — gemini-3-flash-preview, gpt-5.3-codex, kimi-k2.5 и gpt-5.4 — добавили возможность прикрепить изображение прямо в чат.

Автоматизация клиентского сервиса в медицине — это всегда баланс между точностью данных и скоростью ответа. Рассказываем, как мы создавали для фармацевтической компании «Буарон» умного помощника на базе Yandex Cloud Agent, который обеспечивает круглосуточную обработку запросов и использует связку PHP и WordPress.

Есть два фактора, которые гарантированно дают большую нагрузку на службу поддержки портала – это сложный продукт и широкий ассортимент. Фармацевтическая компания «Буарон» объединила оба. «Буарон» (Boiron) – один из мировых лидеров в производстве лекарств на основе природных субстанций, который в России представляет 130 гомеопатических монопрепаратов и 10 комплексных лекарств. База знаний включает в себя не только описания отдельных средств, но и комплексные решения, такие как «ЛОР-протокол», что требует от ИИ-ассистента высокой точности при сопоставлении запроса пользователя с нужным разделом. 

Портал компании заключает в себе огромный объем информации, в которой посетителю непросто ориентироваться. В год пользователи оставляют на сайте более 300 000 запросов – это больше 800 в сутки, при этом ответы не всегда находились, а часть обращений терялась или требовала личного участия специалистов.

Перед нами в QSOFT стояла задача автоматизировать обработку пользовательских запросов на сайте о клинической гомеопатии, снизить нагрузку на специалистов и сократить число пропущенных обращений. Для этого было решено создать умного помощника на базе Yandex Cloud Agent.

При сборке Java приложения в нативный образ требуются настройки для работы рефлексии, прокси и других динамических механизмов Java. Зачем, если JVM справлялась с этим сама? Разбираем отличия между миром статической компиляции и динамической Java.

AI-ассистенты в 2026 году умеют писать код, анализировать данные и управлять инфраструктурой. Но попросите Claude прочитать то, что вы только что скопировали — и он разведёт руками.

Буфер обмена — одна из самых базовых вещей в десктопном workflow, и AI к нему доступа не имеет. Я написал clipboard-mcp, чтобы это исправить.

В прошлой статье я рассказывал, как мы в «Первой Форме» пришли к навигации по корпоративным данным и почему одной языковой модели недостаточно, чтобы получать полезные ответы внутри компании. Тогда речь шла о самой идее картографирования данных — о слое, который связывает разрозненные системы, знает смысл терминов и помогает находить путь от вопроса к проверяемому ответу.

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

Компания меняется постоянно. Меняются процессы, документы, код, настройки, роли, рабочие привычки. То, что ещё недавно было правильным маршрутом к ответу, через некоторое время начинает вести только к части ответа или вовсе в неправильную сторону. Это уже опасно: если у компании нет карты, она честно признаёт, что ответа быстро не получить, но если карта устарела, она начинает отвечать уверенно — и именно поэтому ей легче поверить.

Меня зовут Денис Селезнёв, я генеральный директор «Первой Формы». В этой статье я расскажу, как работать с картой дальше, чтобы она не превращалась в красивый, но мёртвый артефакт. 

Доброго дня

В 2011 году у нас была идея сделать на web онлайн mind-web доску и недавно идея воплотилась в реальность.

Название приложения — «Наброски», или WebSketch, ссылка.

Релиз Veai 5.7 (ИИ-агент к JetBrains IDEs для написания кода, тестирования и отладки с доступом к топовым LLM и всем внутренним инструментам IDE) собрал в себе много исправлений неочевидного UX, с которым вы сталкивались ежедневного. Меньше ручных переключений, меньше ожидания между шагами, меньше повторов при сбоях.

Эта статья, по сути, родилась как развёрнутая версия комичной зарисовки, которую вы видите выше.

Честно говоря, я довольно долго не видел надобности в подобной статье. Если кто-то начинал говорить о генерации кода на основе спецификаций, то я просто показывал ему эту картинку, и обычно этого хватало.

Однако сегодня сторонники агентного программирования утверждают, что нашли способ победить гравитацию и генерировать код исключительно на основе спецификаций. Более того, они настолько замутили воду, что теперь к приведённому фрагменту комикса нужно давать дополнительное пояснение, почему их утверждения нереалистичны.

Айсберг Claude Code: 30+ возможностей от новичка до автоматизации

Привет! Меня зовут Рамиль, я программист отдела серверных решений ЮMoney. Я собрал полезные советы по claude code и организовал её в интерактивном формате «Айсберга». Это способ подачи материала от очевидного к малоизвестному. На верхушке — то, что знает каждый, кто хоть раз открывал Claude Code. Чем глубже — тем реже встречаются эти знания, и тем больше они меняют подход к работе.

Пришёл в команду, открыл тесты — should render, снэпшоты, CSS-классы в ассертах. CI зелёный, покрытие растёт. Всё хорошо? Нет. Тесты падали при любом рефакторинге, но пропускали реальные баги в логике. Ложная уверенность, которая хуже отсутствия тестов. И проблема была не в отдельных файлах — а в самом инструменте, который провоцировал так писать.

В какой-то момент понял, что у меня открыто четыре IDE с разными проектами. В каждой крутится одна или несколько сессий с Claude AI. А я сижу и жонглирую вкладками. Планирование. Ревью там, где критично. Там, где не критично, накидываю хитрые тестовые сценарии, тестируя проект как black box. Постоянно переключаю контекст у себя в голове чтобы понять, а на каком шаге я на этой вкладке и в этом проекте. И потом бам, пора спать. Или есть. Или идти гулять с ребёнком. И в этот момент все процессы останавливаются. Агенты ждут. И получается по факту, что я слабое звено. Не модель с её косяками, а я. Начинаю меньше спать. Парадокс, вроде как должно было быть все наоборот: модели работают, ты спишь. Ан нет.

Привет. Делаю расширение для VS Code, которое даёт OpenCode CLI полноценный графический интерфейс. Называется PrimeCode.

Суть простая: OpenCode — мощный CLI-агент, но работать с ним в терминале на длинных сессиях не всегда удобно. Хотелось нормально видеть, что происходит — tool calls, изменения файлов, контекст, токены. Не форк, не отдельный продукт — именно UI-слой поверх OpenCode, который общается с ним через SDK и SSE-стриминг.

Если вы уже работаете с OpenCode и у вас есть существующие сессии — можно продолжить работу с ними прямо через расширение. Вся история, контекст, tool calls — всё подхватывается.

Одной из самых сложных частей C++ до сих пор считаются правила поиска имён, и ошибки связанные с name lookup проявляются обычно уже в рантайме. Код компилится и даже работает какое-то время, но при свете луны ведёт себя не так как ожидает программист. За простыми идентификаторами скрывается многоуровневая система областей видимости, категорий имён и специальных правил, и очень многое в нашем текущем стандарте растёт прямиком из восьмидесятых, частенько без изменений. Давайте посмотрим как компилятор видит имена в C++, какие области видимости существуют и почему они ведут себя по-разному.

В C++ есть несколько типов областей видимости, вы наверное сходу назовёте глобальное пространство имён, область параметров шаблона, область видимости класса и область параметров функции, но также есть блочная область видимости и область видимости перечислений. Между этими областями есть исторически сложившаяся асимметрия, которая частенько удивляет: два объявления using, которые вводят одно и то же имя в одну и ту же область видимости внутри пространства имён компилятор съест без возражений, но если попытаться сделать то же самое других областях видимости, то получим ошибку на повторное объявление. В серии статей про "нескучное программирование" я разбираю скользкие случаи и как мы докатились до такого. Это продолжение темы, начатой в "Важны ли компилятору имена", поэтому чтобы картинка была цельной, лучше пробежать её по диагонали.

«Происходит что-то масштабное». «Большинство людей не узнает об этом, пока не станет слишком поздно».

Более 85 миллионов человек увидели этот пост. Поделились. Поддержали.

И все ушли с совершенно неправильными выводами.

Не потому что данные неверны — данных не было изначально. А потому что Мэтт Шумер очень хорошо рассказывает страшные истории. Так, что читатель впадает в гипноз и принимает каждый аргумент за чистую монету.

Он пишет «масштабнее, чем Covid» — и не приводит ни одной цифры по занятости. Он говорит «поделитесь, пока не поздно» — транслируя собственную тревогу по поводу собственной работы в ИИ-компании.

Потом, в продолжении, он сказал CNBC, что «не хотел никого пугать» и что «если бы знал, насколько это станет вирусным, переписал бы некоторые части».

Конечно.

Если вы прочитали его пост так, как прочитало большинство, и решили действовать на его основе — вы принимаете неправильное решение. Вы либо сократите людей, от которых всё ещё зависите, либо побежите без плана, либо подмените реальную стратегию блестящими инструментами.

Я покажу вам одну простую кривую спроса, которая опровергает каждое заявление из серии «ИИ всех заменит».

К концу этого текста вы сможете избежать трёх ошибок, которые прямо сейчас совершают 80 миллионов человек — и с которыми данные активно спорят.

Bearer-токен работает слишком просто: кто его получил, тот и авторизован. Именно поэтому утечки токенов регулярно превращаются в реальные инциденты — от CI/CD до облачных хранилищ.

В новом переводе от команды Spring АйО рассмотрим, как DPoP меняет эту модель, привязывая токен к ключу клиента, зачем это нужно backend-разработчику и как поднять рабочую реализацию на Keycloak и Quarkus.

Привет, Хабр! Меня зовут Роман, я программист в команде «Гравитон» и моя задача в компании — разработка API/CLI интерфейсов и приложений на языке Python.

Цель данной статьи в том, чтобы показать как через внедрение «типовых подходов» и вспомогательных библиотек/утилит очень сильно упрощается поддержка проекта в настоящем (при передаче другому человеку или разработке в команде) и в будущем (возобновили проект спустя время).

Первое, что нужно сказать — проект на Python это не только сам Python, но и множество технологий используемых вместе (Git, Docker, и т.д.). В этой статье мы сконцентрируемся на самом проекте, а именно с чего начать, что прикрутить, что учитывать при разработке.

Всем привет! На связи Сергей Смирнов, действующий и практикующий AI-инженер. ИИ интересовал меня задолго до нынешнего хайпа: ещё со времён защиты кандидатской, он всегда был для меня не панацеей, а инструментом автоматизации и решения прикладных задач.

С началом «эры» генеративного ИИ я занимаюсь разработкой агентских систем — и в этой статье хочу поделиться тем, что происходит, когда агента нужно не просто запустить, а сделать так, чтобы он работал надёжно, предсказуемо и без страха отдать его реальным пользователям.

Это будет своего рода дорожная карта подготовки агента к продакшену.

В одной из сессий Claude написал у меня 47 файлов. 1 892 строки. Два новых сценария, рефакторинг шести обработчиков, миграция конфига. 38 минут.

Каждый коммит — автоматический CPG-анализ. Каждый промпт — обогащение контекстом из графа. Каждый пул-реквест — радиус поражения и оценка риска.

Не потому что я не доверяю ИИ. А потому что я не доверяю никакому генератору кода без автоматической верификации. Включая себя.

Я довольно быстро понял, что проблема не в модели. Проблема в отсутствии конвейера верификации. Линтеры ловят синтаксис. Тесты ловят поведение. Но никто не ловит структурную деградацию — рост цикломатической сложности, расширение радиуса поражения, дрейф числовых утверждений в документации.

Буквально пару лет назад было весело обсуждать фронтендеров, у которых каждые полгода появлялся новый фреймворк или библиотека. Кажется, сейчас у них всё устаканилось и breaking change изменений в направлении развития уже не видно. Ну или может я о них не слышу.

Зато теперь источником новостей и обсуждений стал великий и ужасный искусственный интеллект и всё, что с ним связано: релизы моделей каждую неделю, новые агенты каждый месяц и инновационные протоколы каждые полгода. Я думаю, вы уже слышали про MCP, вероятнее всего слышали про Skills, но вот с ACP возможно ещё не сталкивались. Сегодня поговорим именно о нём.

Недавно в популярном Facebook-посте: «GPT работает всё хуже. Просишь пересчитать формулу на 600 грамм, он бодро выдаёт две по 300. Пора, видимо, валить».

Проблема знакомая каждому, кто пытался использовать LLM для расчётов. Но это не деградация конкретной модели. Это фундаментальное ограничение архитектуры. И у него есть решение.