Что Claude получает ещё до первого сообщения пользователя, зачем модели отдельные инструкции по работе с инструментами и длинными задачами и какие идеи из system prompts можно использовать в собственных AI-ассистентах.

Когда мы отправляем Claude первый запрос, для пользователя диалог только начинается.

Для модели нет.

До пользовательского сообщения Claude уже получает системную инструкцию, которая задаёт контекст работы: кто модель, какая сейчас дата, как оформлять ответы, как работать с доступными инструментами, что делать с неопределённостью и какие ограничения учитывать.

Anthropic публикует такие инструкции в официальной документации в разделе System Prompts. Причём там сохранена история изменений: от Claude Haiku 3 и Opus 3 до Fable 5 и Opus 5.

Получается довольно интересный датасет для тех, кто работает с LLM не только через обычный чат.

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

И некоторые выводы вполне применимы к собственным AI-агентам.

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

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

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

В индустрии разработки игр (а может софта и вообще) живёт очень удобная идея, которой многие оправдывают лишние слои логики и абстракции. Звучит она примерно так: «Я хочу, чтобы сам процесс создания игр был проще, приятнее и продуктивнее и готов пожертвовать 10% производительности ради этого» — Тим Суини.

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

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

Статья родилась после очередного приступа клинокодомании в отдельно взятой студии, когда кто‑то в очередной раз увидел и притащил всем известную книгу Мартина о достоинствах этой самой клинокодии. Но «Clean Code», тот что с заглавной буквы и тысячными тиражами, вовсе не «чистый код» в бытовом смысле, потому что Мартин придумал этот бренд, ярлык, и несколько лет пестовал его на конференциях, связав свое имя и это понятие. Правильнее было бы называть это «стиль мистера Мартина» или «стиль Дядюшки Боба», и тогда половина споров о важности книги отваливается сама собой, потому что спорить приходится уже не про абстрактную «чистоту», а про конкретные наборы приёмов конкретного автора. Та дискуссия с технической стороны так и не получила внятных результатов, потому что на третьем круге обсуждения в ход шла риторика и подмена понятий вроде «clean» (хороший, годный), который начал превращаться в «Clean» (по методичке), и обратно.

Представьте себе, что некий предприимчивый человек решил учредить свой первый бизнес. Он не умеет печь торты или замешивать тесто, но зато прекрасно знает рынок кухонного оборудования. Проанализировав все предприятия этой индустрии в Испании, он пришёл к выводу: если продавать новые печи пиццериям, кондитерским и пекарням, то достаточно занять буквально 10% рынка, чтобы стать миллиардером.

И вроде бы 10% совсем немного, когда смотришь на эту цифру в таблицах Excel.

Но учредитель мыслит стратегически. Он садится и разрабатывает план, который на бумаге выглядит безупречным. Согласно этому плану, нужно разработать более эффективную печь с инновационной технологией. Продать такую будет легко. Хотите повысить эффективность труда? Купите новую печь. Конец питча. У будущего учредителя есть опыт общения с инвесторами, и ему удаётся поднять достаточный капитал для создания MVP (минимально жизнеспособного продукта).

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

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

Это само по себе печально, но я бы хотел поговорить кое о чём ещё более прискорбном: назовём это теорией мёртвой экономики.

Целью этой статьи не является полный пересказ спецификации USB или книгу по USB. Я хочу приоткрыть магию работы USB и представить информацию таким образом, чтобы вы получили быстрый старт для понимания всего стека USB: от интерфейсов и конечных точек до электрических сигналов.

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

Звучит как безнадежная задача. Все, что Алиса крикнет Коле, услышит и Ева. Любая информация, которая дойдет до Коли, дойдет и до нее. Кажется, что общий секрет в таких условиях невозможен в принципе.

А теперь плохая новость для нашей интуиции: именно это сейчас происходит на вашем устройстве.

Когда я только знакомился с OSDev, я очень долго искал соответствующие материалы. Находил и на YouTube, и на Habr, и просто какие‑то англоязычные сайты (тогда я не сильно знал английский). Но почти все что я находил было либо незаконченным, либо недостаточно понятным и полным.

В этой статье я постараюсь рассказать все так, как ожидал я это от других.

Если в современных реалиях у разработчика возникает необходимость собрать надежное решение для обработки G‑кода, он обычно смотрит в сторону готовых вариантов (GRBL/FluidNC/Linux‑CNC), либо пишет свой кастомный парсер на С/С++ или Rust и для таких проектов вариант реализации на.NET даже не рассматривается ввиду того, что платформа является управляемой и потому недостаточно надежной (заслуженно или нет — разберем далее).

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

Практически каждый современный AI-агент, будь то Claude Code, Cursor, Codex, Gemini CLI или OpenCode, предлагает один и тот же механизм расширения своих возможностей - напишите Skill, опишите процесс решения задачи, добавьте примеры, подключите документацию и агент начнет выполнять эту работу значительно лучше.

Десятилетиями мы учили разработчиков, что Markdown - это документация. Средство общения между людьми. Формат, который не исполняется и никак не влияет на поведение программы, а затем неожиданно оказалось, что один Markdown-файл способен изменить проект сильнее, чем сотни строк кода и здесь индустрия практически мгновенно наступила на старые грабли.

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

Привет! Меня зовут Михаил Шпаков, я руковожу разработкой Timeweb Cloud. Раньше я рассказывал, как мы построили систему автотестов с 5 000+ проверками и как делаем визуализацию облака. Сегодня текст в формате мнения: про то, как LLM перекраивают профессию разработчика, а вслед за ней и требования к людям в командах. Покажу картину, которая складывается у меня из таких разговоров и ежедневной работы с командой, и расскажу, какие выводы я из неё делаю.

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

Именно здесь полезен советник (advisor) в Claude Code. Советник автоматически вызывается в важных точках и, более того, читает всю историю беседы. А значит, если заранее обратиться прямо к советнику и написать: «Суть этого проекта вот в чем», то каждый раз при вызове он будет сверять работу исполняющей модели с этой сутью. Иными словами, его можно использовать как «регулярное напоминание» для забывчивой исполняющей модели.

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

Я много лет занимаюсь развитием финтех-продуктов, а сейчас руковожу продуктами биллинговой платформы в Selectel.

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

Ниже — о том, почему привычный GUI может уступить место ИИ-агентам и как это решает вечную дилемму продуктового дизайна.

Да не вопрос! На самом деле буквально три месяца назад у меня вообще не было никакого AGENTS.md. Он появился автоматом, когда я устанавливал code-review-graph.

История такая: я каждый день провожу стримы на Ютубе, где показываю процесс разработки своего проекта. И однажды в чатике мне посоветовали воспользоваться code-review-graph, чтобы сэкономить токенов в Codex. Я воспользовался советом, запустил установку через терминал — и в проекте автоматом появилась куча инструкций для разных агентов. Среди этих инструкций оказался и AGENTS.md.

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

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

Утро 8 июня 1966 года. База Эдвардс в Калифорнии. Майор ВВС Карл Кросс паркует машину у ангара за час до старта. В правом кресле XB-70 Valkyrie он сядет сегодня впервые в жизни. Его ждет первый полет на самом амбициозном детище американской авиации 60-х.

Самолет, к которому он шел, через час с небольшим окажется в плоском штопоре, а еще через 25 секунд превратится в обломки в пустыне Мохаве. Кадр, который сделают в строю за 20 секунд до катастрофы, станет, наверное, самой известной фотографией в истории испытательной авиации. А виновником катастрофы окажется фотограф компании General Electric, попросивший пилотов «потесниться для красивого снимка».

Вместе с растущей AI-индустрией приходят и её побочки. Я мейнтейнер библиотеки react-native-tdlib и довольно быстро заметил: все больше PR выглядят как чистый вывод агента. Сначала я честно реагировал — писал в каждый такой PR вопросы: тестировали ли вы это, что именно меняет ваш код, зачем вот эта строчка. В какой-то момент понял, что трачу время на переписку с людьми, которые сами не знают, что написали.

Первая мысль была — написать большой README или CONTRIBUTING и прямым текстом сказать: «сгенерированный код не принимаю». Но тут же упёрся в вопрос: а как доказать, что код сгенерирован? Аргумент «чую, тут пахнет Claude Code» — так себе позиция для публичного спора в комментариях к PR.

Решение оказалось довольно простым — AGENTS.md. Он конечно не доказывает, что PR сгенерирован, но отлично ловит самые очевидные автоматические PR, где автор, кажется, вообще не участвовал в процессе.

Все знают, как писать промпты правильно: роль, критерии готовности, защита от выдумок, разметка под конкретную модель. Проблема в другом - выписывать все эти пунктыруками для каждого нового промпта утомительно. Да ещё и думать надо :) Поэтому я собрал скилл, который делает рутину за меня: описываешь задачу своими словами, получаешь полноценный промпт под Claude, GPT, Gemini или DeepSeek. Под катом - как он устроен: десять обязательных блоков, Python-проверяльщик, протокол разнообразия из свежей научной работы. Скилл открытый, ссылка внутри.

Привет, Хабр! Меня зовут Владислав, я разрабатываю компиляторы в YADRO. В этой статье я расскажу вам про алиасинг памяти в C++: как он развивался, к чему пришел сейчас и что комитет по стандартизации языка думает делать с алиасингом в будущем. По пути я немного затрону алиасинг в других языках, рассмотрю связанные случаи undefined behavior, а также пропозалы C++, которые, как ожидалось, проблемы с алиасингом решат.

Компании уже оплачивают сотрудникам Claude Code, Cursor или Codex, но не всегда видят рост производительности.

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

Разбираю, зачем команде общая память, и при чём тут GBrain, OpenBrain и обычные Markdown-файлы.