По результатам написания прошлой статьи у нас получился объемный модуль для реализации функций низкоуровневого управления шиной I2C, который формирует управление линиями SCL/SDA, поддерживает мониторинг шины, ведет передачу и прием данных. В этой статье я предлагаю организовать полноценное вдумчивое тестирование всего что получилось.

Всем заинтересованным - добро пожаловать под кат! 🙂

Это продолжение темы начатой в статье Важны ли компилятору имена, и продолженной в Ночью все кошки серы, а using'и одинаковы, и далее в Компиляторы тоже путаются в именах. Если не читали, то лучше будет пробежаться по диагонали. Теперь вот мы подобрались к такой интересной теме, как квалифицированный и неквалифицированный поиск.

Что такое простой поиск(неквалифицированный) имени n в области S? Это механизм компилятора, который находит все объявления n, находящиеся непосредственно в этой области. Просто? С виду да, но даже этот простой механизм часто работает не так, как ожидает разработчик.

Например, у нас есть пространство имён N и локальная переменная N. Они могут сосуществовать вместе? Могут, потому что находятся в разных областях видимости. А пространство имён и глобальная переменная с тем же именем могут? Как же мы докатились до жизни такой, давайте разбираться.

Наконец-то нашлось вдохновение и время вернуться к старой статье, в которой я изобретал I2C Master Controller, но так и не довел задачу до логического конца. Спустя почти три года много воды утекло, появилось множество возможностей и ряд компетенций и я хотел бы реанимировать решение этой задачи и продолжить рассказ. Перечитав старый материал, я сформулировал обновленную группу задач: переделать I2C Master Controller, снабдив его функциями, которых не было в первой версии, типа clock stretching и burst-режима при этом сопроводив это детальным описанием процесса реализации и объяснением почему были предприняты те или иные действия. После все это воплотить сначала в симуляции, а потом и на реальном железе, с использованием EEPROM и OLED-дисплея SSD1306.

Вобщем, всем неравнодушным к теме цифровой схемотехники, ПЛИС и шине I2C - добро пожаловать под кат! :)

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

Я решил считать ~/.claude/ обычным кодом и хранить его в Git.

Так появился claude-config-template — репозиторий, из которого ~/.claude/ собирается через симлинки. В нём лежат скилы, агенты, команды, хуки и MCP-конфигурации.

Это даёт:
- переносимую конфигурацию между машинами
- единый источник правды для всех агентов
- версионирование и откат через Git

Финал серии: Agent Teams, GitHub Actions, Agent SDK, TDD, Ralph-loop на ночь и осторожный прогноз на 2027

Серия на Хабре: часть 1 - что Claude Code умеет из коробки · часть 2 - настройки, хуки и Context Rot · часть 3 - автономная работа и параллелизм.

Однажды вечером я дал Claude Code не задачу "сделай фичу", а уже написанную спеку и сложный план. Дальше работал не один чат, а цепочка: оркестратор разобрал план на независимые куски, поднял кодеров в отдельных worktree, дождался их diff'ов, потом вызвал ревьюеров на каждый кусок и собрал итоговый отчёт. Утром у меня был не "ответ ассистента", а несколько веток, замечания ревью и список решений, которые всё равно должен принять человек.

Это третья и финальная часть серии. В первой я показал что такое Claude Code и почему я называю его командой из 15. Во второй - десять настроек, которые эту команду делают управляемой: CLAUDE.md на 30 строк, permissions, хуки, совещание ботиков через Codex и Gemini, Context Rot.

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

Дальше начинается параллелизм, автоматизация и автономия. Десять приёмов, которые превращают Claude Code из "умного помощника" в систему из отдельных агентов, scheduled tasks и CI-задач.

И в конце - честный разговор про то, куда всё это идёт в 2027 и что останется разработчику.

Ранее я писал про утечку исходного кода Claude Code. 512 000 строк, KAIROS, упоминания нерелизнутых моделей Opus 4.7 и Sonnet 4.8. Так вот. В актуальном Claude Code уже есть Opus 4.7. Ровно как и было в leaked‑коде. Вместе с ней появился новый уровень /effort xhigh — это мы сегодня тоже разберём.

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

Это решается настройками. Конкретными. Которые лежат в двух файлах и никто до них не доходит.

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

Cursor или его аналоги, здорово облегчают написание кода, когда речь идет о каких‑то не очень больших проектах. Но стоит попробовать применить их к серьезному, сложному проекту, состоящему из нескольких репозиториев, и тут же сталкиваешься с тем, что эти «чудеса» оборачиваются просто огромными счетами за токены. Я в этой статье поделюсь, как мне удалось перестать впустую сжигать миллионы токенов. Для этого пришлось собрать и запустить три MCP‑сервера по протоколу Model Context Protocol, что позволило сэкономить до 90% бюджета, при этом совершенно не потеряв в эффективности модели при работе с кодом.

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

В прошлой статье я разобрал, как работает квалифицированный поиск и как using namespace участвует в нём только в качестве запасного варианта, когда собственных объявлений в указанной области нет. Компилятор сначала смотрит, что объявлено непосредственно в текущем контексте, и только при неудаче переходит к именам, подмешанным через директиву using. Казалось бы, схема прозрачная и предсказуемая: есть область поиска, есть приоритет явных объявлений, есть «правило N-объявлений» как страховка.

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

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

Неделю назад друг собрал себе новый компьютер. Ничего экстремального: материнская плата Gigabyte B760 Gaming AX, процессор Intel Core i5-14600KF, башенный кулер, корпус с приличной продувкой. Включил, поставил Windows, запустил OCCT — через несколько секунд температура улетела в 100°C, процессор ушёл в тротлинг.

Друг написал мне: «У меня нормально или нет?». Хороший кулер, правильная термопаста, продуваемый корпус, новейший процессор за 30 тысяч рублей. Не нормально.

Оказалось — это не уникальная ситуация. Тысячи людей с 13/14 поколением Intel видят то же самое. И решение везде одно: залезь в BIOS и понизь напряжение. То есть сделай прямо противоположное тому, что десятилетиями понималось под «настройкой для энтузиастов».

Под катом — почему так вышло, как разгон превратился в андервольтинг, и что с этим делать конкретно на Intel Raptor Lake, AMD Ryzen 9000 и Intel Arrow Lake.

Перевёл 16 курсов Anthropic Academy на русский за неделю. 448 уроков, субтитры, Telegram-авторизация, пейволл и т.п. на shared-хостинге за $2/мес. Рассказываю, как устроен пайплайн и что пошло не так.

Если вы часто упираетесь в лимиты Claude Code / Codex и не понимаете, куда улетают токены — этот лонгрид для вас

Да и вообще всем, кто хочет разбираться в современных AI инструментах, будет полезно

Разбираемся

1. Как устроено контекстное окно изнутри: 7 слоёв (от весов модели до MCP и skills)
2. Что такое attention и при чем тут O(n²)
3. Как работает agent loop на примере 4 вызовов модели
4. Почему prompt caching экономит до 10× в лимитах при правильной работе с ним

Сууупер длинная статья

Если ваш ИИ-агент при каждом вопросе начинает grep-ом по всему проекту — у меня есть для вас одна штука. SocratiCode — это MCP-сервер, который индексирует кодовую базу через Qdrant и даёт агенту нормальный поиск вместо построчного чтения. Разобрал, как он устроен внутри, потестировал на нашем монорепе и сравнил с обычным режимом Claude Code

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

Но теперь Вселенная, кажется, решила над нами посмеяться. Представьте, что весь этот исполинский космический механизм почему-то знает о существовании Солнца и Земли. На самых огромных масштабах, вплоть до границ наблюдаемого космоса, прочерчена невидимая генеральная ось Вселенной, и она, вопреки логике и здравому смыслу, проходит прямо через наш дом. Это звучит как безумие: почему параметры системы, заложенные в момент рождения Вселенной 13,8 миллиарда лет назад, должны подгоняться под положение какой-то рядовой звезды, и под плоскость орбиты какой-то рядовой планеты? Мы словно снова оказались в центре мироздания, из которого нас так долго и упорно гнали.

Думаю, вы уже в курсе, что происходит в РФ с белыми списками: работают белые списки, ТСПУ в режиме drop-all пропускает только одобренные IP + SNI, рунет медленно, но верно становится интранетом

Мы просканировали 46 млн российских IP-адресов, нашли 63 тысячи выживших, разобрали работу ТСПУ. И главное - актуальные методы пробива (от Serverless-функций и покупки VPS с белым IP до туннелей через WebRTC).

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

1)    Чуть-чуть об авторе

Автор имеет опыт в коммерческой разработке печатных плат около двух лет. До начала этого пути занимался баловством с микроконтроллерами на самодельных платах. На текущий же момент можно перечислить два значимых успешных проекта: материнская плата на RK3588 (LPDDR4X-4266MT/s, HDMI2.1, PCIe2/3, Ethernet 2.5G, USB2/3, SATA3), модуль памяти UDIMM DDR4 3200 MT/s. Разумеется, было много прочих, но они не требовали глубокого понимания работы с согласованием сигналов по задержке, понимания импеданса. Стоит учитывать, что автор является самоучкой чуть более чем полностью, так как более опытных коллег попросту не было и нет. Опыт работы имеется только с российскими фабриками.

Разработка велась в Altium, какого-либо моделирования (Cadence/Ansys/иной софт) не проводилось. Однако, проекты полностью работоспособны, что является косвенным доказательством валидности моих эвристик.

Последний вводный абзац. Если будет интерес и потребность – планируется сделать еще одну статью о workflowпри работе с DDR4 в Altium. Также есть что рассказать про LPDDR4, если будет таковой запрос. Если есть интерес к разработке печатных плат – по ссылке доступно мое «пособие», полностью свободное.

Привет, Хабр!

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

Сегодня рассмотрим open-source RAG-фреймворк HippoRAG 2. В сфере RAG главным преимуществом данного фреймворка является качество ответов, потому что принципы его работы основаны на реальном человеческом мозге. Давайте разберёмся, откуда он взялся, как устроен изнутри и как его запустить.

Год с Claude Code: как собрать рабочую конфигурацию с первого запуска

Жемал Хамидун, Head of AI Alpina Digital, CPO AlpinaGPT, автор тг-канала «Готовим ИИшницу».

Представьте сцену. Вы пишете в терминал: «разберись, почему на main падает вот этот тест, и попробуй починить». Жмёте Enter. Спиннер крутится, подписи меняются — сначала “Pondering…”, потом зачем-то “Julienning…”, потом “Recombobulating…”. Через минуту агент прочитал логи CI, нашёл зафейлившийся тест, заглянул в связанный модуль, заметил, что кто-то криво подкрутил регекс, предложил правку, дождался вашего «да» — и коммитит. Пока вы наливаете чай, PR уже уехал на ревью.

Выглядит как магия. На деле внутри — удивительно стройная инженерная конструкция: главный цикл на пару сотен строк, обросший целой экосистемой обслуживающих подсистем. Я несколько вечеров подряд ковырялся в исходниках одного такого CLI-агента для разработки: де-обфусцированный дистрибутив примерно на 300 модулей, файл-вход почти на 800 тысяч строк после разсборки бандла. И за «магией» обнаружились вещи, про которые отдельно хочется написать: собственный React-реконсилятор для терминала, двухуровневая загрузка описаний инструментов, классификатор опасных bash-команд, трёхрежимное сжатие контекста, fork-join для саб-агентов, защита от невидимых Unicode-инъекций в промпте.

Эта статья — мои заметки по итогам погружения. Не реклама конкретного продукта (реальных имён функций и классов я намеренно избегаю), а разговор про архитектурные решения, которые стоят за современным CLI-агентом. Главный цикл и его устройство, инструменты, контекст и его сжатие, разрешения и хуки, MCP, память между сессиями.

В прошлой статье я разобрал почему Claude Code ломает проекты (context drift, отсутствие CLAUDE.md, нет хуков на тесты) и как выстроить защиту от регрессий. Статья попала в топ-5 Хабра за сутки — видимо, проблема задела нерв.

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

Я работаю с 20+ проектами на нескольких VPS-серверах. После того как я замерил, куда реально уходит контекст — картина оказалась неприятной.