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

Привет, Хабр! Я делаю execai — терминальный AI-агент на Go (bubbletea), в духе Claude Code. Он читает файлы, гоняет shell-команды, ходит в kubernetes и стримит ответы в TUI.

В какой-то момент выяснилось, что пользователям нужен не «агент с одной моделью», а мультитул: у кого-то подписка Kimi Code за $19, у кого-то GLM Coding Plan за $18, у кого-то корпоративный ключ Anthropic, а кто-то хочет гонять Ollama локально и не платить вообще. И всё это — в одном чате, с общей историей, с переключением на лету.

Под катом — как устроена мультипровайдерная архитектура: один интерфейс из пяти строк, два несовместимых мира API (Anthropic-compat и OpenAI-compat), SSE-парсеры с аккумуляцией tool calls, динамические каталоги моделей, автодетект тарифа подписки и делегирование в чужие CLI. С реальным кодом и граблями, на которые мы наступили.

Привет, Хабр! Меня зовут Костя, я десять лет занимаюсь коммерческой Android-разработкой. Давно хотелось попробовать себя в вебе, а эксперименты с LLM давали некоторую уверенность в том, что по крайней мере есть шанс написать агентами поддерживаемый код и задеплоить.

Что же можно сделать? Конечно тамагочи! Текстовая браузерная игра: герой живёт в мире мрачного будущего. Непрямое управление, возможность предлагать миссии, а также тюнинг предпочтений героя. Эдакий Годвилль, но на новый лад. Как я делал, и что получилось, спустя пару недель, расскажу под катом :)

В прошлой статье (Непослушный using ) я разобрал, как using вмешивается в поиск имён и почему его поведение часто расходится с тем, что от него ждет программист, и на этом ветку статей про поиск имен (name lookup) можно временно закрыть.

Using'и попортят вам в проектах еще немало крови, но в целом их проблемы известны и легко ловятся, а теперь давайте поговорим обauto и выводе типов в шаблонах, который регулярно удивляет даже опытных программистов на C++, когда речь идёт о распаде типов (type decay) и неявных ловушках при работе с ним. Представьте, что у нас есть несколько переменных, которые выглядят разными: const int&, просто int, const int и int&&.

По наивной интуиции можно подумать, что компилятор должен относиться к ним по‑разному: и где‑то ссылка, где‑то константность, где‑то rvalue, но это будет работать только до тех пор, пока мы не используем auto или шаблон.

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

В документации к PropertyNameCaseInsensitive есть предупреждение про накладные расходы, но не сказано, когда они появятся. Замерил на четырёх машинах, трёх рантаймах и трёх размерах входного JSON: пока через настройки идёт один регистр ключей, флаг не добавляет ничего — 0,92–1,09. Политика именования camelCase тоже.

Разницу до ×4,3 даёт другое: какие ещё написания этих ключей прошли через настройки раньше. Два экземпляра JsonSerializerOptions, созданные через new с одинаковыми полями, делят один кеш имён.

Внутри: пять историй с таблицами по четырём машинам, листинги из dotnet/runtime, предел кеша в 64 записи и веб-настройки, на которых эта разница не видна.

Данные о том, как поиск видит ваш сайт, живут в интерфейсе Яндекс Вебмастера и в его API: чтобы узнать, по каким запросам показов много, а кликов нет, что выпало из индекса за месяц и что Яндекс считает проблемой сайта, человек ходит по вкладкам и сводит цифры руками, а программа собирает запросы к API v4. LLM-агент по умолчанию не умеет ни того, ни другого.

Разбираю, как устроен MCP-сервер для Яндекс Вебмастера: как уложить пару десятков эндпоинтов в восемь инструментов, какие грабли у API v4 и как сделать вход в Яндекс, который агент выполняет сам — без терминала и без клиентского секрета.

Почему ChatGPT иногда может ответить мгновенно, а иногда заставляет смотреть на надпись Thinking почти минуту?

Неужели модель..думает. А раз уж она думает может модель обрела… самосознание? На самом деле этот процесс сегодня называют Reasoning, и он в свое время стал настоящим прорывом в сфере ИИ. Теперь каждый новый флагман от ИИ лабораторий поддерживает режим размышлений.

Как один психолог случайно спроектировал думающую LLM? Сильно ли Reasoning повлиял на точность моделей? И как LLM стали испытывать «Горе от ума»?

Привет, Хабр! Меня зовут Ноянова Наталья, около 10 лет я исследую и работаю в ИБ, сейчас занимаюсь статическим анализом кода, изучаю его недостатки и уязвимости. Один из типов таких недостатков кода привлек моё внимание. Анализаторы кода описывают это как внутренние или внешние утечки информации, которые связаны с журналированием ошибок работы программы. И правки этого недостатка кода навели меня на мысли, которые изложены в данной статье.

Для исправления подобных недостатков требуется не просто внести правки в код (вроде замены ссылок, начинающихся с «http» на «https»), а произвести целый ряд действий: перенастроить конфигурацию работы программы, понять суть безопасного логирования, найти баланс между необходимым и излишним. Ниже примеры таких решений, а также причины, почему это стоит вашего внимания. Сперва — общая теория, затем — обзор практик безопасного логирования, что будет, если вы его не настроите. Спойлер — сперва поймут, чем вы пользуетесь, затем подберут уязвимости для него, настроят эксплойты и применят.

Журналирование ошибок — это критически важная часть жизненного цикла программного обеспечения. Оно упрощает отладку, позволяет выявлять сбои на ранней стадии и предотвращать их повторение. Однако журналы (жарг. логи) должны быть не только информативными, но и безопасными.

Статья написана на основе горького опыта наблюдения за ошибками разработчиков и участия в CTF. Приведена общая информация о журналировании ошибок, библиотеках для этого, как это может сыграть на руку хакерам и как от этого можно предотвратить.

Ну, привет.

lock xadd. Вот и весь Arc::clone на x86. Одна инструкция. Заглядываешь в дизассемблер и даже немного обидно: столько разговоров про атомарные счётчики ссылок, а внутри обычный атомарный инкремент, который компилятор даже не утруждается оборачивать во что-то крутое.

Вот только эта инструкция вам подыгрывает. На вашем ноуте она бесплатная. А потом тот же код уезжает в прод на пару десятков ядер, и тот же самый инкремент оказывается самым дорогим местом в горячем цикле. Самая подлянка в том, что профайлер на ноуте этого не покажет: чтобы увидеть цену, нужен контеншен, а на одном ядре его нет. Так что вся статья, если честно, про одно. Как научиться смотреть на Arc::clone и видеть не инкремент, а короткий разговор с протоколом кэш-когерентности вашего процессора.

Arc принято звать умным указателем. Мне ближе другая формулировка: это примитив синхронизации, который натянул костюм указателя, чтобы вы его не боялись. Давайте снимем всю эту оболочку и глянем, кто там внутри. По ходу разберёмся, откуда в нём два счётчика, почему clone беспамятный, а drop нет, как живёт Weak, что за толстый указатель прячется в Arc<dyn Trait>, зачем придумали make_mut и где Rc делает Arc по скорости.

Статья настоящий разбор-детектив: почему неблокирующий API может блокироваться, как потерять монитор после деоптимизации JIT, почему try-catch иногда важнее коллбэков, и как решать сложные проблемы новыми концепциями мышления. Приятного чтения!

Привет! Это команда Яндекс Практикума. Приёмная кампания 2026 уже идёт и закончится всего , поэтому сегодня подробно расскажем, какие навыки и компетенции нужно развивать начинающим разработчикам несмотря на ИИ и как в этом помогает онлайн-магистратура «Фронтенд-, бэкенд-разработка и ИИ-решения» ИТМО в партнёрстве с Практикумом. А ещё — почему эксперты ИТМО и Яндекса создали гибкую программу для студентов с разным опытом и что нужно, чтобы поступить.

Делюсь личным опытом создания проекта с нуля на вайбкоде.

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

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

Все мы знаем, что языки делятся на динамические и статические: Python или JS позволяют молниеносно прототипировать, но расплачиваться нестабильностью в продакшене приходится потом, тогда как C++, Java или C# требуют прописывать типы сразу, оплачивая монументальную надежность замедлением разработки.

В 2006 году Джереми Сиек предложил разрешить этот конфликт концепцией постепенной типизации в работе «Gradual Typing for Functional Languages»: язык остается динамическим по умолчанию, однако разработчик может аннотировать типами отдельные модули или функции, не покрывая ими всю кодовую базу, а типизированный и нетипизированный код взаимодействуют через специальный динамический тип Dyn. Звучит как сказка — быстрое прототипирование с постепенным наращиванием стабильности. Однако при детальной проработке вскрылись фундаментальные нюансы: в серии последующих работ Сиек, Таха, Вадлер и другие показали, что стыковка типизированного и нетипизированного кода требует операции приведения типа (cast), а дизайн этого каста упирается в противоречие между тремя желаемыми свойствами — надёжностью системы типов (soundness), собственно постепенностью (gradual typing) и отсутствием рантайм-обёрток на границах (no wrappers).

Позднее сообщество, и я в том числе, переосмыслило третью вершину: no wrappers — это забота о производительности и прозрачности рантайма, безусловно важная, но с позиции программиста, а не математика-оптимизатора, правильнее говорить о удобстве разработчика (developer-friendly). Это свойство вбирает в себя no wrappers как частный случай, добавляя понятные сообщения об ошибках, низкий порог входа и отсутствие многослойных типовых аннотаций, ведь если ради производительности приходится городить бесконечные теоремы типов, такая система едва ли приживётся на суровом рынке опенсорса.

Так родилась трилемма Святого Грааля системы типов: выбрать можно любые два свойства, а третье неизбежно пострадает, и в этой статье мы разберём, как создатели языков пытались достичь всех трёх и на какие компромиссы шли.

Привет, друзья! Меня зовут Наталья и я frontend‑разработчик в компании SimbirSoft. 

Когда‑то в 2020 году микрофронтенды были модой. Чуть ли ни каждый хотел почувствовать себя всемогущим и попробовать разделить монолит на части, а также получить от шефа премию или эмоциональное поглаживание и картонку с надписью «Спасибо» (если повезет, то отдадут прямо с рамкой). Затем забыли про них и, но недавно в компанию пришла потребность разработки сайта с архитектурным паттерном «Микрофронтенды». Всех обязали вспомнить или узнать что же такое микрофронтенды? Чушь или все‑таки необходимость? Давайте разбираться.

По мере роста проектов мне как Vue‑разработчику уже неоднократно приходилось сталкиваться с вопросом: как разделить фронтенд между несколькими командами так, чтобы они меньше зависели друг от друга? 

Одним из вариантов остаются микрофронтенды. В статье я разберу Module Federation 2.0 для Vue 3 + Vite, изоляцию стилей и состояния, способы коммуникации между remotes и то, что происходит с этой архитектурой, когда в проекте появляется SSR и Nuxt 4.

Статья будет полезна разработчикам и техлидам, которые рассматривают разделение крупного фронтенда между несколькими командами. А если вы пока только знакомитесь с микрофронтендами, основные понятия я тоже постараюсь объяснить по ходу статьи. 

Сначала разберём Module Federation для Vue 3 + Vite, затем — изоляцию стилей и состояния, коммуникацию между приложениями, SSR в Nuxt 4 и роль host‑приложения в маршрутизации.

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

Привет, Хабр! На связи команда Caila — платформы Just AI, объединяющей LLM и другие генеративные модели, включая модели для создания изображений и видео.

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

Создаём одно приложение для портала Битрикс24 двумя способами: через внешний ИИ и через платформу вайб-кодинга Битрикс24 Вайбкод. 

На этом эксперименте покажем, почему платформа быстрее понимает CRM и требует меньше ручной настройки.

Вот в github:
https://github.com/Divetoxx/Piano

🎹 Основная философия: «Ритмическое дирижирование без ошибок»
Главное новшество этого фортепиано заключается в том, что пользователю никогда не нужно беспокоиться о неправильном воспроизведении нот.
Идеальная высота звука (Гц): Каждая частота и высота звука точно запрограммированы в плотные векторы нот. Математически невозможно сыграть неправильную ноту или допустить ошибку!
Время ваше: Время, интервалы и эмоциональный темп совершенно не ограничены. Нажимая на клавиатуру или мышь, ВЫ динамически создаете ритм и временную структуру. Вы не просто нажимаете на клавиши — вы дирижируете шедевром!

Большинство публичных материалов об агентной разработке описывает работу с frontier-моделями. В корпоративной среде frontier-модель часто недоступна: отправка кода внешним LLM-провайдерам запрещена политикой безопасности, работа идет через внутренний шлюз, и его модели заметно слабее передовых - а добиться от такой модели соблюдения процесса промптами не удается. В статье описан подход, к которому удалось прийти в этих условиях, - структурная инженерия: запреты в таблицах, которые модель сверяет, а не помнит; правила, приходящие свежим чтением в момент, когда нужны; изоляция агентов через файлы; детерминированные блокировки кодом там, где цена ошибки высока. Дальше - устройство харнеса и осечки, из которых он вырос.

21-й выпуск IT‑новостей от OpenIDE!

OpenAI раскатили GPT-5.6 на всех, и та же модель тут же отменила все Stripe‑подписки в чужом стартапе за семь секунд.

JetBrains проверили скилл, который обещал экономию 65% токенов, и намеряли 8,5%. OpenIDE Pro вышла для всех без регистрации.

Kimi выложили открытую модель на 2,8 триллиона параметров, Cursor выпустили Grok 4.5 вместе со SpaceXAI, Anthropic убрали Fable 5 из двадцатидолларовой подписки.

По данным GitLab, 91% компаний держат в работе минимум два ИИ‑инструмента, 54% — три и более. 78% команд пишут и коммитят код быстрее, чем раньше, 60% говорят, что отдача от ИИ превзошла ожидания, 73% отмечают рост качества кода. По любым меркам внедрение состоялось. А теперь «менее успешная цифра»: 80% признают, что подключили ИИ‑инструменты раньше, чем придумали, как ими управлять. Скорость обогнала контроль, и вся история начинается ровно на этом стыке.

Сталкивались ли вы с кейсом, когда по заданному списку email или номеров телефонов необходимо проверить всех клиентов на совпадение с ними? Поиск через интерфейс в различных системах не всегда удобен или даже невозможен. В этой статье я расскажу, как организовать универсальное хранилище объектов различного типа под разные цели. Мы создадим единый справочник в базе данных и организуем поиск по нему.