"Поскольку вы программист на C++, вероятность того, что вы слегка одержимы производительностью, выше среднего. А если нет, то вы, вероятно, по крайней мере с пониманием относитесь к такой точке зрения. (Если производительность вас совсем не интересует, аудитория Python разработчиков дальше по коридору)"
— Из пункта 42 книги С. Майерса “Effective Modern C++”, 2015.

Эта заметка описывает мой личный взгляд на то, как писать эффективный и надежный код для CPU. Статья ориентируется на С++, но значительная часть обсуждения CPU, кэшей, паттернов доступа к памяти и профилирования применима к Rust, Go и другим компилируемым языкам. Статья задумана как краткое введение и больше всего подходит студентам, имеющим опыт программирования на занятиях, но не в реальных проектах. Для профессионалов статья может быть полезной в качестве референса, чтобы не пугать новичков чем-то в духе Что каждый программист должен знать о памяти.

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

Качество работы LLM — функция от качества контекста на входе. Это утверждение звучит банально, однако зачастую разработчики оптимизируют модель, выбирая между GPT, Claude или Gemini, и промпт, но не контекст в целом. Между тем, разница между «агент с правильным контекстом» и «агент без контекста» — не 20% и не 50%. Эта разница находится в дистанции вариантов между «решил задачу за 5 минут» и «потратил час, сломал два сервиса, и результат пришлось откатить из‑за массы новых проблем».

Я solo‑разработчик. В моей экосистеме десятки актуальных проектов: платформа из десятков микросервисов, AI‑инференс кластер на неспецифическом железе типа mac studio и dgx spark, масса shared‑библиотек, инфраструктура на нескольких физических и десятках виртуальных хостов.

Последний год «пишу» код почти исключительно через LLM и Cursor. Начинал с deepseek на уровне «подскажи как написать функцию для...» и дошел до полноценной оркестрации на Claude 4.6: я формулирую задачу, агент анализирует условия и кодовую базу, обсуждаем архитектурный план, агент пишет код и тесты, запускает тесты, фиксит ошибки, получает от меня обратную связь по результатам ручной проверки.

Это работает хорошо, когда агент глубоко понимает контекст. И катастрофически плохо, когда контекста недостаточно. Эта статья — про то, как я решаю проблему контекста системно.

Оговорка о применимости

Описанная методология разрабатывалась и обкатывалась на одной из наиболее сильных моделей для работы с кодом — Claude 4.6 Opus с контекстным окном в миллион токенов. Это важно зафиксировать: большое окно контекста означает, что агент физически способен «увидеть» knowledge base, а сильные аналитические способности модели позволяют извлечь из неё пользу, а не утонуть в шуме.

Всем привет!

Если вы работаете с Git относительно недавно, почти наверняка у вас возникала потребность в отмене коммита. И, что печально, вы быстро поняли, что простого "откатить все назад" нет.

Где-то советуют git reset, где-то - git revert, а в третьих и вовсе пишется про checkout. По тому же правилу летят restore, amend, reflog и куча технологических формулировок, требующих знания git и после которых становится только сложнее, нежели понятнее.

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

Понятие контейнер сейчас активно применяется в контексте Docker и аналогичных решений по контейнеризации. Однако, в языке C++ контейнеры существуют уже очень давно и являются фундаментальной частью Standard Template Library (STL). Они предоставляют готовые реализации наиболее часто используемых структур данных, избавляя разработчика от необходимости писать их с нуля.

Контейнеры C++ можно разделить на несколько основных категорий. Последовательные контейнеры (Sequence Containers) хранят элементы в линейной последовательности, при этом порядок элементов определяется позицией добавления. Ассоциативные контейнеры (Associative Containers) автоматически сортируют элементы по ключу. При этом, они обеспечивают достаточно быстрый поиск (O(log n)). Неупорядоченные ассоциативные контейнеры (Unordered Associative Containers) хранят элементы в хеш-таблицах. Обеспечивают поиск в среднем за O(1). Адаптеры контейнеров (Container Adapters) предоставляют ограниченный интерфейс поверх других контейнеров.

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

Способности AI в написании кода растут быстрее, чем наше умение этими способностями пользоваться. Поэтому рост баллов на SWE-bench не коррелирует с метриками продуктивности, которые волнуют инженерных руководителей. Когда команда Anthropic выкатывает продукт вроде Cowork за 10 дней, а другая команда не может довести до ума сломанный POC на тех же моделях, разница в одном: первые закрыли разрыв между возможностями моделей и практикой, вторые — нет.

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

31 марта из npm source maps утёк исходный код Claude Code. Через часы появился OpenClaude — форк с OpenAI-совместимым шимом, который позволяет подключить GPT-4o, DeepSeek, Llama через Ollama или любую модель. Разбираю, как это устроено, что реально работает, что нет, и почему «бесплатный Claude Code» — не совсем то, чем кажется.

Я использовал Claude Code несколько месяцев, потом перешёл на Codex. Недавно вернулся обратно — и причина не в бенчмарках. Также протестировал оба инструмента на одной и той же задаче.

В этой статье я разберу разные аспекты Claude Code и Codex, сравню флагманские модели Opus 4.6 и GPT-5.3-Codex, расскажу, что реально влияет на опыт AI-разработки, и покажу кейс-стади: построение RAG-пайплайна в обоих агентах.

Сразу предупрежу: читать ~12 минут. По-моему, это оправдано, если вы собираетесь платить $200/месяц за любой из них.

Последние полтора года я использую Cursor IDE в качестве основной среды разработки. Сначала использовал её как среду с просто удобным автодополнением строк (относительно GitHub Copilot). Потом AI стал умнее, удобнее, появился режим планирования и Claude стал базовым атрибутом моего рабочего дня.

Неделю назад мой open source проект Databasus (инструмент для резервного копирования PostgreSQL, ~6k звёзд ⭐️ и ~275k Docker pulls) получил поддержку от Anthropic в рамках OSS программы: и теперь у меня есть Claude Code Max на ближайшие полгода. Следовательно, я переключился на него... и осознал, что очень сильно привык к UX в Cursor IDE. Самые умные безлимитные модели — это, конечно, классно. Но удобство и контроль за изменениями для меня в приоритете.

Поэтому я взял Opus и навайбкодил расширение для VS Code, которое приближает взаимодействие с CLI агентами к опыту Cursor IDE: когда ты видишь изменения и можешь точечно их корректировать. Пара потраченных часов сделали работу в ближайшие полгода для меня ощутимо комфортнее.

Что и как я делал — ниже.

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

Чем интересен именно кодинг-агент? Это идеальная ловушка для самоуверенного разработчика.

Цель кристально ясна: читай код, пойми его, измени, проверь. Что может пойти не так? (Спойлер: вообще всё.) Под этой обманчивой простотой скрывается хаос — модели, которые обходят ваши ограничения с грацией уличного кота, инструменты, ломающиеся способами, о которых вы не подозревали, и промпты, которые прекрасно работают ровно до момента обновления модели на одну минорную версию.

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

Что я собственно построил

Назвал я его QuillCode. Звучит солидно, а внутри — вот что:

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

Как прошивка может противостоять всяческим флуктуациям во время своей работы и обезопасить себя от зависания или повреждения исходных данных?

«Простота — требование, необходимое для обеспечения надёжности», — Эдсгер Дейкстра

Невидимая структура данных

В каждой программе используется стек — стек вызовов. Каждый вызов функции записывает в стек кадр, каждый возврат извлекает его. Он настолько фундаментален, что мы редко о нём задумываемся.

Но когда нам нужен собственный стек или очередь, крайне важно правильно выбрать реализацию.

Однажды я отлаживал вылет прошивки во встраиваемой системе RISC-V. У системы был планировщик задач, использующий очередь для управления ожидающими задачами. При большой нагрузке система вылетала с переполнением стека.

Переполнение стека? Очередь должна была находиться в куче, а не в стеке.

Проблема заключалась не в самой очереди, а в том, как она была реализована. Для очереди использовался связанный список, и каждый вызов malloc() выполнял распределение из пула памяти, делившего пространство со стеком. Под нагрузкой очередь разрасталась, пул фрагментировался и рано или поздно стеку не оставалось места для роста.

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

О проблемах с ИИ-кодингом на Хабре написано уже много. Но хочется перейти к конструктивному подходу: да, наломать дров с ИИ легко, а вот как работать с ним наиболее профессионально?

Известные разработчики вроде Митчелла Хашимото (создателя Terraform и Ghostty) всё чаще говорят что-то в духе «вот тут уже ни строчки кода не написал вручную». При этом Хашимото — противник слопа, и он подчёркивает, что добился от ИИ качественного кода. А что помогает добиваться?

Мы в проекте Kodik подобные вопросы ощущаем особенно остро, потому что в редакторе кода с ИИ делаем… собственно, сам этот редактор кода с ИИ. Так что для нас все проблемы особенно наглядны, а их решения — особенно важны.

Поэтому мы собрали вместе идеи и из опыта мировой IT-индустрии, и из нашего собственного. Это не какая-то «окончательная истина»: сейчас вся планета только разбирается, ни у кого ещё нет полных ответов, и полезно обмениваться опытом. Так что смело дополняйте в комментариях: интересно узнать, что помогает вам, и собрать «общехабровую кладезь знаний». Если кто-то захочет конструктивно возразить, такое обсуждение тоже полезно.

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

В статье пошагово показано, как завести аккаунт Claude Code в обход санкций, с европейского IP-адреса, на европейский телефон, с оплатой виртуальной карточкой.

Конкретно вы нашем случае Claude Code нужен для настройки сервера и написания скриптов. Мы собираемся использовать зарубежный VPS в качестве прокси для захода на YouTube, Instagram, Facebook и другие заблокированные сайты (браузер запускается прямо на VPS, как BrowserBox). А также для установки прокси Telegram, если его тоже заблокируют.

Агент поможет с установкой VPN, стороннего клиента для просмотра и скачивания YouTube, а также защитит VPS от AI-ботов и прочей дряни, так что можно нормально работать в интернете из РФ без эмиграции.

Я делал микросервисный fullstack в финтехе с Claude Code и столкнулся с тем, с чем сталкиваются все: AI пишет код быстро, но не держит систему в голове и ведёт себя как гиперактивный джун. Каждую сессию — новые архитектурные решения, конфликты между сервисами, документация, отстающая от кода.

Поэтому я решил что я не спешу со своим проектом и написал FullSpec — open-source фреймворк (MIT), который организует разработку с Claude Code через цепочку формальных спецификаций. Вызываешь /chain, отвечаешь на вопросы — система ведёт от идеи до production: требования → проектирование → тесты → код → review → release.

Под капотом: 71 скилл, 23 параллельных AI-агента, 80+ скриптов валидации, CONFLICT-детекция (код противоречит спеке → каскадное обновление), живая документация из спек.

GitHub: https://github.com/NSEvteev/FullSpec

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

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

И Cursor, и Claude Code пришли к одному ответу - субагенты. Но реализовали его по-разному

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

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

Контекст у LLM - это не бездонный мешок, а рабочая часть "памяти" модели, ее нужно проектировать: что хранить отдельно, что подмешивать just-in-time, что выбрасывать после шага и что обязательно возвращать после compaction.

В этой статье я разберу context engineering на примере coding agents, а конкретно на Claude Code: почему long context до сих пор деградирует, почему проблема особенно больно бьет по агентам, чем полезны /compact и Plan Mode, и как собрать минимальный контекстный конвейер без магии и лишней философии.

OpenAI 5 месяцев строили продукт без единой строчки ручного кода — миллион строк, 1500 PR, 7 инженеров. Разбираю их подход «harness engineering» и что из этого можно применить уже сейчас: как организовать AGENTS.md, почему скучные технологии побеждают, и зачем нужна архитектура с первого дня.

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

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

Мы сделали это за вас. В этой подборке - семь нейросетей, которые реально стоят вашего времени и закрывают практически любые повседневные задачи.

Приятного прочтения - и готовьтесь обновить закладки.

Команда разработчиков под руководством Андрея Бреслава, российского разработчика и автора языка программирования Kotlin, представила публичную альфа-версию нового инструмента для разработчиков — CodeSpeak. Платформа позиционируется как язык программирования нового поколения, в котором инженеры пишут спецификации на английском языке, а нейросети берут на себя генерацию, тестирование и рефакторинг исполняемого кода. Полноценное внедрение инструмента позволяет сократить объем кодовой базы в проектах в пять-десять раз. Технология поддерживает интеграцию в существующие сложные проекты на Python.