Anthropic выпустила инструмент Claude Code — агента разработчика, который работает терминале. Он умеет разбираться во всем коде (code base) и помогает кодить быстрее через команды на обычном языке. Кажется это первый агент-разработчик напрямую от производителей LLM?


Ключевые возможности:
• Пишет код, исправляет баги
• Отвечает на вопросы об архитектуре и логике кода
• Запускает и исправляет тесты
• Работает с git: история, конфликты, коммиты и PR

Особенности:
• Работает прямо в терминале
• Понимает контекст всего проекта
• Выполняет реальные действия с кодом
• Прямое API-соединение без промежуточных серверов

Пока в бета-версии как research preview. Установка через npm: npm install -g @anthropic-ai/claude-code

Анонсируют, что пригодится для изучения незнакомого кода, автоматизации git-операций и интеллектуального редактирования.

UPD
Пока только waitlist, так что ждем

Ведущие европейские разработчики LLM Mistral выпустили "Mistral OCR" - модель, которая может поспособствовать развитию RAG-пайплайнов.

По заявлениям производителя это самая мощная модель для распознавания документов, при этом она может работать локально... но к сожалению не Open Source.

Умеет распознавать мультимодальные (текст, таблицы, pdf, презентации, формулы типа LaTeX и изображения) документы. Есть API, т.е. интегрируется в любые пайплайны (например в RAG). Точность на русском (и еще на десятке языков) языке выше 99%, т.е. выше, чем у Google Doс AI, Azure OCR или Gemini.

Локальное развертывание: можно использовать на собственных серверах для защиты чувствительной информации (повторюсь, но не open source). Высокая скорость обработки: до 2000 страниц в минуту на одном узле + batch inference.

Уже можно попробовать бесплатно в Le Chat, попробовать API на платформе Mistral (La Plateforme). Подробнее на сайте Mistral.

Сообщения о совершенствовании архитектур базовых моделей ИИ публикуются довольно часто и мы нередко задаемся вопросом об их перспективности. Ведь авторы и обозреватели нередко заявляют о радикальных преимуществах новых алгоритмов функционирования и скором вытеснении старых добрых трансформеров. Но несмотря на реальные преимущества тех или иных решений, они в целом пока не дают видимого экономического преимущества, добавляя единицы процентов к производительности моделей. Большинство новаторских моделей с трудом продвигаются в индустрию из академических исследований. Но вот недавняя публикация компании Inception сразу задела меня, заинтересовала многих с кем я говорил, и в надежде, что свершившееся заинтересует и многих читателей канала, публикую заметку по материалам упомянутой и последовавших за этим публикаций. Более того на нашем канале запланирована моя следующая лекция, посвященная детальному анализу предложенной авторами технологии и релизу готовых моделей на ее основе. Для начала о команде. Она впечатляет : "Нас основали профессора из Стэнфорда, Калифорнийского университета в Лос-Анджелесе и Корнелла — пионеры в области диффузионного моделирования и краеугольных технологий ИИ, включая Flash Attention, Decision Transformers и Direct Preference Optimization. В нашу инженерную команду входят ветераны из Google DeepMind, Microsoft, Meta, OpenAI и NVIDIA." Так в чем корень технологии? На настоящий момент известно два основных подхода к базовому принципу генеративного ИИ - это авторегрессионная модель и диффузионная модель. Позволю себе провести аналогию с двумя техниками работы скульптора, "генерирующего" свое произведение. Есть техника лепки, когда кусочек за кусочком добавляются к уже вылепленному, а есть техника высечения, когда из бесформенного в начале куска материала путем отделения кусок за куском формируется "генерируется" произведение. Так вот первая техника - это прямая аналогия работы авторегрессионных моделей GPT, а вторая техника - аналогия работы диффузионной модели. И что же сделали в Inception? Они соединили эти две технологии и сделали Diffusion LLM. теперь текст генерируется не токен за токеном, а фильтруется как из хаоса слов по группам токенов. Эффект в скорости составляет десятки раз! Наилучшие результаты по качеству получаются при генерации программного кода, поэтому свои первые модели разработчики ориентировали на работу с кодом. Так что встречайте и пробуйте (уже есть Playground) Mercury Coder Small и Mercury Coder Mini. https://www.inceptionlabs.ai/news

Поднявшаяся с легкой руки Андрея Карпаты волна обсуждений vibe coding размывает многие догмы сегодняшнего понимания разработки программ. Но вот появляются и такие сообщения, на первый взгляд курьезные. В самый раз на выходные.

Сообщается, что известный помощник по программированию Cursor сказал пользователю под ником «janswist», что тот должен написать код самостоятельно, а не полагаться на то, что Cursor сделает это за него.
«Я не могу генерировать код для вас, так как это будет означать завершение вашей работы... вы должны разработать логику самостоятельно. Это гарантирует, что вы поймете систему и сможете ее правильно поддерживать», — сказал ему Курсор после того, как он провел час, «настраивая» код с помощью инструмента.
Итак, janswist подал отчет об ошибке на форуме продукта компании: «Cursor сказал мне, что мне следует изучить кодирование, а не просить его генерировать его», и приложил снимок экрана. Отчет об ошибке вскоре стал вирусным на Hacker News и был освещен Ars Technica.
Предполагается, что Cursor обучался на сайте Stack Overflow и он мог усвоить не только советы по кодированию, но и человеческий сарказм.

Как разработчики используют LLM: дайджест исследования

Прочитали за вас 40-страничное исследование от Университета Северной Каролины о влиянии языковых моделей на разработку ПО. Ключевые выводы:

-LLM повышают продуктивность за счёт сокращения рутины, упрощения поиска решений и создания шаблонного кода
-Лучше всего разбивать задачи на мелкие компоненты и итеративно уточнять промпты
-Для оценки кода эффективно использовать комбинацию ручной проверки и автоматизированного тестирования
-LLM особенно хороши в написании тестов и рефакторинге

Для организаций важно:

• Создавать библиотеки шаблонов промптов для сотрудников
• Обучать команды промпт-инжинирингу
• Использовать RAG для включения проектной документации в генерацию

Полный дайджест с инсайтами на Хабре.

Наткнулся на интересный пост:
Каждый день меня спрашивают: "А правда ли ИИ помогает инженерам с большими/сложными/legacy кодовыми базами?"
И знаете что? Однозначно да, если всё делать правильно!
Студенты курсов AI  для разработчиков поделились со мной своим опытом, как они это делают на практике:

Инженер 1:
Первым делом — разберитесь, как устроена кодовая база, спрашивая об этом ИИ. При этом ИИ заодно тоже её изучает.
Например, в Cursor вы можете @ Codebase (или @ какую-то часть кода) и попросить:
• "Сделай Mermaid-диаграммы последовательности и потоков для понимания связей между всеми важными файлами проекта"
• "Результат можно загрузить в  https://mermaid.live/ для просмотра"
• "Дай мне команды для терминала — как запускать, тестировать и останавливать приложение локально и в проде"
• "Расскажи, как ещё можно использовать это приложение, и где найти документацию"
• "Напиши документацию, чтобы я мог начать работать с этой кодовой базой. Сделай это рекурсивно — по директориям, поддиректориям, и пусть всё связывается между собой"
Дальше используйте обычный процесс разработки, но с помощью ИИ:
• Тикет в Jira → ИИ читает, ищет важную информацию, делает выжимку
• Изучение кода → ИИ читает код и пишет саммари на важные части
• Создаем branch → ИИ анализирует код и предлагает исправления
• Тесты → Дайте ИИ взглянуть на существующую инфраструктуру тестов и попросите создать новые тесты для вашей фичи
• Запустите тесты  → ИИ помогает исправить несостыковки
• Сделайте PR, при необходимости воспользуйтесь услугами ИИ
• И так далее
 
Сам пост тут, там еще от 4 инженеров есть советы  по использованию AI.

PS: Думаю на английском промты будут лучше работать

Микроскоп ИИ выявил сложные возможности планирования и рассуждения Клода. При генерации поэзии модель планирует несколько слов вперед, сначала выбирая соответствующие рифмующиеся слова, а затем конструируя каждую строку, чтобы вести к этим целям . Для многошаговых задач рассуждения, таких как определение столицы штата, где находится Даллас, Клод последовательно активирует представления, сначала связывая «Даллас находится в Техасе», а затем «столица Техаса — Остин» . Решение математических задач демонстрирует параллельную обработку с одним путем для приближения и другим для точного расчета . Эти результаты бросают вызов предположению, что LLM просто предсказывают от токена к токену, демонстрируя более сложный внутренний процесс.