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

Оказывается, документация Claude Code рассказывает не всё. Стоило только лишь заглянуть в исходники. И вот что можно настроить, но чего нет в доке:

— hooks, которые переписывают команды на лету;
— автоодобрение safe-команд без лишних подтверждений;
— постоянная память агентов между сессиями;
— auto-mode, который понимает описание окружения на обычном английском;
— самообучающиеся циклы памяти и «снов»;
— скрытые поля skills, agents и permissions, которых нет в документации.

И все это работает уже сейчас, а исходники Claude Code лежат у вас в node_modules. Мы собрали все в статью. Там больше конкретики, JSON-конфигов, shell-хуков и примеров, которые можно утащить себе почти без правок.

За карьеру получилось у меня поработать под руководством нескольких тимлидов, и я уже стал забывать их по именам, зато остались в памяти их любимые хоткеи. В некоторых описаниях вы, возможно и своих узнаете, а может и моих.

Обычно те тимлиды, к которым я попадал уже не писали код, или делали это очень редко. Чаще тимлид брал код из одного места, как-то его менял и переносил в другое, или не переносил, или переносил и делал задачу его починить. Всё, что делало большинство тимлидов, так или иначе было связано с чтением чужого кода. Но не весь код одинаков, поэтому разные способы его перемещения работают с принципиально разной скоростью, надёжностью и сопровождаемостью.

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

На связи Сергей Смирнов, AI-инженер и основатель LLMStart.ru. Сегодня разбираем мультимодальность в ИИ-агентах на реальном примере из продакшена.

Мы проанализировали 258 диалогов нашего агента-консультанта по 1С и поняли: у входящих и исходящих картинок совершенно разная физика. Для входящих критично качество распознавания, а для исходящих — надежная доставка. В статье я подробно рассказываю, почему мы осознанно отказались от модного Multimodal RAG и как на самом деле нужно выбирать архитектуру под свои данные.

Спойлер: экономить копейки на токенах — плохая идея, а усложнять систему стоит только тогда, когда это приносит реальные деньги.

Привет! Меня зовут Диана, я редактор и деврел в Контуре. В апреле запустила небольшое исследование про юмор в IT: опросила контуровцев и внешних пользователей, шутят ли они на работе и на какие темы, в чём специфика айтишного юмора и приемлемы ли для ребят чёрные шутейки. А ещё, я нашла три самых популярных и часто упоминаемых мема! — их можно было прикрепить по желанию в конце опросника. Приглашаю почитать результаты исследования и посмотреть на мемы.

GitHub постепенно превращается в кладбище старого кода. Мы сравнили тысячи репозиториев и посмотрели, какие языки быстрее теряют активность, а где экосистема всё ещё растёт.

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

В прошлой статье я описал 1C Code Bench — бенчмарк для оценки способности LLM писать правильный код на 1С. Там я описал принципы составления задач и проверки результатов, использованные технологии и прочее. На момент написания той статьи бенчмарк насчитывал 20 задач.

Привет, Хаброжители! Вы когда-нибудь отлаживали такой компонент пользовательского интерфейса, где достаточно нажать в неверном порядке несколько кнопок – и приложение валится? А не доводилось ли вам ломать голову, пытаясь отследить, почему в некоторых случаях форма отправляется нормально, а в других — отказывает? Такие неприятные сценарии зачастую возникают по одной базовой причине: непредсказуемое управление состоянием. Мы привыкли полагаться на булевы флаги, рассеянные по коду инструкции if-else, тем временем надеясь, что наше приложение будет правильно работать, чего бы пользователь ни делал в интерфейсе.

Когда я впервые увидел backtrace паники в Rust, я решил, что это просто аналог исключения. Вызвал panic!, стек раскрутился, деструкторы вызвались, поток умер. Примерно как throw в C++ или raise в Python. Потом я попытался передать панику через FFI-границу, и программа молча упала без backtrace. Потом обнаружил, что catch_unwind перестаёт работать, если в Cargo.toml поменять panic = "unwind" на panic = "abort". Потом выяснил, что двойная паника (когда деструктор паникует во время раскрутки) убивает процесс безусловно, и это не баг, а так задумано.

Оказалось, что за простым panic!("oops") стоит сложная система из сменных runtime-ов, платформозависимой раскрутки стека и кучи граничных случаев...

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

Но иногда бывает совсем наоборот. В начале рабочего дня вы беретесь за дело, а к обеду даже не успели въехать в контекст. Три сообщения, небольшой созвон буквально на 10-15 минут — и вот уже ваш мозг судорожно переключает процессы.

В этой статье попробуем разобраться:

— существует ли на самом деле то самое состояние потока или это просто красивый термин?

— почему разработчики так легко его теряют и сколько реально времени уходит на возвращение к задаче после отвлечения?

— какие простые организационные и технические практики помогают удерживать фокус и погружение?

Профилирование Java‑приложений в production часто упирается не в отсутствие инструментов, а в их ограничения: CPU горит в одном месте, latency копится в другом, аллокации давят на GC, а lock contention вообще не виден в обычном CPU‑профиле.

В статье разбираем, как использовать async‑profiler для диагностики реальных Java‑сервисов: снимать CPU, allocation, wall‑clock и lock‑профили, читать flame graph и понимать, где именно приложение тратит ресурсы.

Рассказываю, как написал кроссплатформенную .NET-библиотеку для глобального перехвата клавиатуры и мыши. Под капотом: WH_KEYBOARD_LL на Windows, CGEventTap на macOS и polling через XQueryKeymap на Linux. Один интерфейс, три реализации, ноль внешних зависимостей.

Привет. В предыдущих статьях этого цикла мы разбирали, как Kubernetes-объекты читаются (первая — informer и кэш в controller-runtime) и записываются (вторая — Server-Side Apply, patch’и, managedFields). Сегодня — про их жизненный цикл.

Между kubectl apply и появлением объекта в etcd проходит целая цепочка: admission chain, мутирующие и валидирующие вебхуки, schema-валидация, встроенные плагины. Между kubectl delete и реальным исчезновением объекта может пройти от миллисекунд до часов — в зависимости от того, какие на нём финализаторы и какая стратегия каскадного удаления выбрана. Механизм при этом универсален для любого ресурса: Pod, Deployment, ваш CRD — жизненный цикл у всех один.

В этой статье я постараюсь ответить, что происходит с объектом от его рождения до смерти. И отдельно поговорим про другое измерение — эволюцию его API-схемы.

Как-то раз на одном из программистских форумов я наткнулся на интересную задачку. Интересна она была тем, что требовалось рекурсивное решение на Java. Мне захотелось разобраться…

Cursor, Copilot и другие AI‑инструменты обещают быстро закрыть рутину с unit‑тестами: сгенерировать кейсы, расставить моки, добавить ассерты и поднять покрытие. Но зелёные тесты ещё не означают, что код защищён от регрессий.

В статье разбираем пять типичных паттернов, из‑за которых AI‑сгенерированные тесты выглядят убедительно, но пропускают реальные баги.

TL;DR. Один «безобидный» foo.GetAsync().Result в middleware способен превратить ASP.NET Core, державший 50k RPS с p99 = 40 мс, в сервис с 12k RPS и p99 = 4 с — при CPU 8 %.

Виноват не сам blocking call, а hill-climbing — фидбэк-луп в ThreadPool, в недрах которого живёт дискретное преобразование Фурье. Разбираем по исходникам CoreCLR, почему это вообще возможно, воспроизводим эффект на ~80 строках кода и разбираемся, почему SetMinThreads — не решение, а анестезия.

Онлайн доска DGRM.net кеширует файлы в постоянном кеше. Постоянный кеш не удаляется при закрытии вкладки. Рассказываю как хранить большие файлы в браузере.

Как организовать шифрование на уровне протокола? На самом деле тема непростая и пожалуй (имхо) это как раз та самая тема, где прийти к компромиссу почти никогда не получается. Разве что просто не передавать чувствительные данные вовсе.

Я расскажу как шифрование можно организовать на уровне протокола brec и ни в коем случае не буду затрагивать те самые принципиальные решения, влияющие на безопасность (как передавать, куда передавать, отправлять ли, и хранить ли чувствительные данные вовсе). Иными словами нас интересует инструментальная сторона вопроса.

Каждый, кто программирует с агентами (Claude Code, Codex и т.д.), знает: перед тем как приступить к задаче, агент исследует проект. Это кажется логичным, естественным и закономерным, ведь люди делают так же. Обычно говорят: «агент наполняет контекст».

Для агента такой контекст должен содержать не только полезные сведения, но и не включать лишних, которые могут оказать влияние на конечный результат. Но добиться этого не так-то просто, поскольку:

- задача определена в общем виде (кто знает, что имел в виду автор)
- пути исследования не детерминированы (в общем виде не используется специфика фреймворка)
- используются базовые инструменты (read, grep, cat, find)

В итоге при первичном исследовании легко столкнуться с ситуацией, когда основной контекст заполнен сведениями, слабо относящимися к исходной задаче.

В Anthropic быстро осознали эту проблему и вынесли всю описанную работу в Explore sub-agent. В результате основной agent ставит задачу промптом, Explore выбирает путь исследования, а результат формирует в виде отчета. Проблему чистоты основного контекста они, конечно, решили. Но что с качеством такого анализа?

Наблюдая за работой Explore и видя, как агент, используя «примитивные» инструменты, в агонии пытаясь отыскать недостающее или, наоборот, пропускает важные сведения о проекте, невольно ловишь себя на мысли: «Как так вышло, что последние 10 лет развития индустрии инструментов прошли мимо agent?» А может, это человечество свернуло не туда?