512 000 строк утёкшего кода, совещание ботиков, и почему человек стал узким местом разработки

31 марта 2026 года Anthropic случайно выложила npm-пакет с source map файлом на 59.8 мегабайт. Внутри - 512 000 строк TypeScript, 1 900 исходных файлов и 44 скрытых feature flags. Весь исходный код Claude Code, включая вещи, о которых пользователи даже не подозревали.

За несколько часов репозиторий форкнули 41 500 раз. Anthropic начала рассылать DMCA-takedowns, но было поздно. Сообщество успело найти упоминания KAIROS - автономного агента, который работает пока ты спишь, консолидирует память и проактивно действует без промптов. 150+ упоминаний в коде. Нерелизнутые модели Opus 4.7 и Sonnet 4.8. Режим "Undercover" для сотрудников Anthropic, скрывающий AI-атрибуцию в коммитах на публичных репозиториях.

Я пользуюсь Claude Code каждый день. Это мой основной инструмент разработки. Я пересадил на него команду, я создаю с ним проекты с нуля, и я вижу как он меняет саму суть профессии разработчика. В этой серии из трёх статей я расскажу что я понял за это время - от базовых фич до продвинутых паттернов, которые позволяют одному человеку работать как команда.

Начнём с десяти вещей, которые делают Claude Code не просто ещё одним AI-помощником.

Пятница, 23:47. Открываешь GitHub Trending, чтобы «быстренько глянуть, что там новенького», а там — пять новых AI-агентов, три фреймворка с архитектурой «как у Google, только лучше», и одна нейросеть, которая обещает заменить тебя вместе со стулом и кружкой остывшего кофе. Глаза разбегаются. Палец рефлекторно жмёт звезду на всём, что выглядит многообещающе. Список звёздочек пухнет, но в понедельник утром в продакшен почему-то идёт только старый добрый Python-скрипт, написанный джуном три года назад и покрытый пылью и матами в комментариях.

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

Поехали.

В марте–апреле 2026 разговор об AI-агентах резко перестал быть разговором только о новых интерфейсах и демо. На уровне инструментов произошел синхронный сдвиг: Cursor 3 переехал в agent-first интерфейс, OpenAI и Anthropic перестроили SDK вокруг агентных паттернов, а Claude Computer Use из «прикольной фичи» превратился в рабочий инструмент для длинных сценариев взаимодействия с компьютером. На этом фоне идеи Karpathy перестали выглядеть как частные наблюдения одного инженера и начали работать как язык, через который индустрия объясняет происходящее.

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

Ещё пару лет назад типичное LLM-приложение выглядело как последовательная цепочка вызовов: взяли промпт, добавили контекст из векторной базы, отправили в модель, получили ответ. LangChain популяризировал эту парадигму — chains, retrievers, memory — и это работало для простых сценариев вроде «ответь на вопрос по документации».
Но бизнес-задачи редко укладываются в линейный пайплайн. Пользователь хочет не просто получить ответ, а чтобы система совершила действие: создала тикет в Jira, отправила письмо, запросила данные из CRM, проверила погоду и только потом сформулировала ответ. Именно здесь на сцену выходят AI-агенты — системы, которые не просто генерируют текст, а автономно принимают решение, какой инструмент вызвать, в каком порядке, и интерпретируют результат. Проблема в том, что до недавнего времени подключение каждого нового инструмента требовало написания «клея» — кастомных функций, обёрнутых в @tool декоратор LangChain, с ручным управлением аутентификацией, обработкой ошибок и сериализацией данных. Для продакшена это быстро превращалось в зоопарк нестандартных интеграций, который сложно поддерживать и масштабировать.
Model Context Protocol (MCP) от Anthropic решает эту проблему, предлагая единый стандарт для подключения инструментов и источников данных к LLM-приложениям. Вместо того чтобы для каждого API писать свой адаптер, мы просто запускаем MCP-сервер, который предоставляет инструменты по стандартизированному протоколу. Агент подключается к этому серверу через MCP-клиент и получает доступ ко всем инструментам без лишнего кода.
В этой статье мы соберём полноценного агента, который:
1. Умеет работать с внешним миром через MCP (узнавать погоду и создавать GitHub Issues);
2. Имеет доступ к внутренней базе знаний через RAG;
3. Принимает решения по ReAct-подходу с использованием LangGraph.

Когда Apple добавила вырез (notch) в MacBook, реакция у многих была примерно одинаковая:

он есть — и с ним приходится просто мириться.

В отличие от iPhone, где появился Dynamic Island и вырез стал частью интерфейса, на macOS он до сих пор остаётся пассивным элементом. Он не несёт функциональной нагрузки и никак не взаимодействует с пользователем.

У меня возник простой вопрос:

а что если сделать вырез частью UI, а не ограничением?

Так появился проект DynamicNotch.

Помните, в 2016 сотрудник NASA Крис Гарри опубликовал код миссии Apollo 11 на GitHub? Его можно изучать, загружать и изменять. Ну и, конечно, использовать для полета на Луну в собственных целях. Речь идет об исходниках кода командного модуля Comanche 055 и лунного модуля Luminary 099. Это «живой» код из 1969 года с комментариями инженеров.

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

Многие венчурные фаундеры замечают, что последние 2-3 года происходит "инфляция гитхаб-звезд": их нужно все больше и больше, чтобы производить впечатление. 

И это на удивление важный параметр для венчурных опенсорс-стартапов: по динамике звезд инвесторы частично определяют хайповость, а по форкам - востребованность. Эти метрики я видел много раз в питчах, в том числе на YC demo days. А инвесторы мониторят тренды гитхаба.

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

Напишем с нуля на c# маленькую модель размером 422 Кб, сохраним в GGUF и запустим в LM Studio.

А в этом нам поможет всего один единственный компонент: ILGPU, позволяющий обучать модель на OpenCL. А точнее - на встройке AMD.

Ну а если у вас есть видеокарта NVidia - компонент позволяет обучать модель с помощью CUDA.

Привет, All!

Как вам идея, отказаться от тегов вообще и делать WEB-проекты исключительно на классах? А еще, чтобы и клиентский, и серверный коды шли рядом, как в десктопном приложении.И чтобы с одними и теми же переменными можно было работать и в PHP, и в JavaScript.

«Зачем?» — сапросит кто‑то. Отвечу: чтобы можно было строить не DOM‑элементы, а объекты предметной области бизнес‑процессов, которые автоматизирует мое приложение. И чтобы не тратить время на разные async, promise, ajax и так далее, пусть за это отвечает фреймворк!

Я говорю примерно вот о таком построении WEB-приложения:

Вы сделали open source проект. Потратили на него недели или даже месяцы: продумали архитектуру, аккуратно написали код, добавили нужные фичи. Даже сами начали им пользоваться.
А потом открыли GitHub… и ничего не произошло. Ни пользователей. Ни обсуждений. Ни pull request’ов. Иногда даже звёзды не появляются.

И в этот момент возникает вполне логичный вопрос:
“Что не так?”

Разбираем, что мешает проектам получать пользователей и контрибьюторов, и как это изменить.

Начиналось всё с уведомления, радостного для каждого разработчика:

«Вы попали в шорт-лист на вакансию разработчика ИИ».

Компания кажется потрясающей — DLMind, «лаборатория инноваций ИИ». Рекрутер выглядит вполне правдоподобным — Tim Morenc, CEDS, с качественным профилем на LinkedIn, профессиональными интонациями в переписке и историей взаимных связей.

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

Привет, Хаброжители! Освойте навыки программирования в тесном сотрудничестве с генеративным ИИ, используя GitHub Copilot — пожалуй, самый популярный ИИ-инструмент разработчика. Брент Ластер, опытный девелопер и преподаватель, описал реальные сценарии из ежедневной практики и тем самым показал, что GitHub Copilot — это не просто подсказки в редакторе, а полноценный партнер по программированию, который может в разы ускорить вашу работу, если знать, как с ним взаимодействовать.

Разбираю как выглядит нормальный QA-пайплайн в GitHub Actions: от линтинга до E2E тестов на Playwright. С рабочими конфигами, кэшированием и уведомлениями о падениях.

Привет, Хаброжители! Книга предлагает практическое руководство по внедрению архитектуры медальона (bronze, silver, gold уровни) для эффективной работы с большими данными, чтобы избежать превращения хранилищ в бесполезное «болото данных».

Автор делится реальными кейсами и примерами кода для Microsoft Fabric и Azure Databricks, объясняет, как интегрировать медальон в data mesh, и рассматривает вопросы безопасности, контрактов данных и применения генеративного ИИ.

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

Когда говорят «память для ИИ-агента», очень легко начать спорить о разном, думая, что обсуждается одно и то же.

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

На OpenClaw эта развилка видна особенно хорошо. У платформы уже есть понятная архитектура плагинов и отдельный слот plugins.slots.contextEngine, куда можно подключать внешний движок контекста. А в последнем обновлении OpenClaw 2026.4.7 в вернули и встроенный memory-wiki stack — то есть подход с накопительной wiki уже перестал быть просто красивой идеей из заметки и стал частью реального инструментария.

Если смотреть на самые интересные подходы к памяти для OpenClaw прямо сейчас, то разговор крутится вокруг пяти систем и направлений:

Важное уведомление

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

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

Ответственность за применение полученных знаний лежит исключительно на пользователе.

Возможно, ни одна из описанных технологий не нова. Но их сочетание — с учётом российских реалий (CGNAT, DPI, белые списки) — представляет собой, насколько я вижу, ещё не реализованный на практике open-source проект. Приглашаю сообщество проверить эту гипотезу вместе.

Я выпустил вторую версию PHP-веб-панели для управления Amnezia VPN. Теперь это не просто интерфейс к одному серверу, а полноценная система управления VPN-инфраструктурой: 9 протоколов, роли, лимиты, метрики, резервные копии, Docker-управление удаленными хостами и REST API для автоматизации. Проект открыт и доступен на GitHub.

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

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

Возьмём Veai и посмотрим на это через призму архитектуры. В основе Veai лежит идея максимально использовать инструменты IDE: Veai относится к Claude Code примерно так же, как разработчик с IDE относится к разработчику, сидящему только в терминале.

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

У меня нет макбука. Но два моих приложения лежат в App Store. Рассказываю весь путь: регистрация Apple Developer из России, сертификаты без Xcode, автоматическая сборка через GitHub Actions. Три варианта: для вайбкодеров, программистов без мака и хардкорщиков.

Несколько месяцев назад я делал плановую проверку кодовой базы на одном из проектов и нашёл обфусцированный код в файле vite.config.js. Он был на той же строке что и закрывающий };, но сдвинут вправо на несколько сотен пробелов — туда, куда ни один diff-вьюер не прокрутит и ни один редактор не покажет без горизонтального скролла.

Я пошёл смотреть через git log — какой коммит это принёс. Оказался merge-коммит. Не обычный коммит в ветке — именно merge. И вот тут началось интересное.

Мы не стали спорить с TIOBE и RedMonk и собрали свой рейтинг языков программирования на основе GitHub. Данные за 2024–2025 показывают неожиданные вещи: JavaScript впереди, TypeScript резко растёт, а Rust и Go выигрывают по качеству проектов. Разбираем, что стоит за цифрами и где могут быть искажения.

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

И пока большинство CI/CD инструментов помогают вам деплоить. GitCrab заставляет вас бороться.

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

В итоге всё началось с простого Telegram-бота, а закончилось полноценным web-приложением с отдельным backend, интеграциями и нормальным интерфейсом.

Сегодня хочу рассказать про сам путь: как из “скрипта под задачу” постепенно вырастает система.

Как пережить блокировку Github-аккаунта

и почему к ней лучше подготовиться заранее

что делать, если вы не можете войти аккаунт и что стоит сделать, чтобы уменьшить последствия в случае блокировки

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

.htaccess — это конфигурационный файл, который использует веб‑сервер Apache для задания специфических настроек для каждой отдельной папки сайта. Благодаря ему можно:

Как я без Mac, с помощью Claude AI и GitHub Actions, создал кроссплатформенное приложение для шифрования сообщений поверх любого мессенджера. Android на Kotlin, iOS на Swift без MacBook, десктоп на Python. AES-256, три платформы, два отказа от Apple и один баг с буквой «а».

Наверно, все владельцы роутеров MikroTik знают, что они декодируют все SMS по стандарту 7-bit вне зависимости от того, как изначально было закодировано сообщение. Как оказалось, даже при декодировании 7-bit MikroTik использует не все 128 символов из стандартного алфавита (GSM 7-bit Default Alphabet).

А ещё вместо одного длинного SMS роутер покажет вам его части по отдельности, иногда с неполными дубликатами. Как же тогда нормально прочитать любое сообщение, отправленное на роутер? Надо стать протоссом и построить MotherSMS.

Я делал микросервисный 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

(Тут можно упоминать какой-нибудь крутой сервис VPN, но этого не будет, т.к. собрал свой, чем собсснно горжусь)
В январе 2026 я запустил Telegram-бота с одной простой идеей: вечером спрашивать «как прошёл день по твоей цели?» и давать три кнопки: ✅ Сделано, 🌓 Частично, 😕 Не сделано.

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

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

Вот как это вышло...

Итак, я решил довести до реально работающего проекта превосходный эмулятор синтезатора Roland JV880. Это рэковый модуль (без клавиатурный), сделанный на базе синтезатора JV80. Соответственно он поддерживает все карты расширения этого синтезатора и почти все MIDI команды.

Привет, Хабр! Хочу поделиться честной историей, в которой мое желание избавиться от рутины, любовь к разработке, open source и enterprise переплелись самым тесным и неожиданным образом. Четыре года назад я всего лишь хотел делать свою восьмичасовую работу за пару часов, а остальное время отдыхать , добавить во внутренний тулинг удобные кнопочки и меню, используя свой опыт разработки, но все пошло не по плану, и я сначала стал разработчиком своего собственного инструмента VSCode-XP (open-vsx.org, marketplace.visualstudio.com), потом его мейнтейнером на GitHub, продвигал его использование среди экспертов на профильных конференциях. Потом наработанный открытым сообществом опыт перенял enterprise-продукт и получилась история в стиле Толкиновского «Хоббита, или Туда и обратно».

Привет, Хабр! Меня зовут Кияшева Екатерина. В начале марта я активно занялась поиском работы после творческого отпуска и сама столкнулась с радикальным изменением рынка:

• Нет откликов: открыть резюме на пару дней больше не работает.

• Фильтрация на hh.ru, на мой взгляд, сильно забагована. Автопоиск сбрасывает часть фильтров. В рассылку попадают вообще не интересные вакансии, а интересные не попадают. В чате поддержки отвечает бот, так что сообщить девелоперу о баге невозможно.

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

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

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

В процессе стало очевидно две вещи:

· У Jami огромный технический потенциал.
· В реальных сетевых условиях (особенно в мобильных сетях России) он работает значительно хуже, чем мог бы.

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

Если вы разработчик, знакомый с C++, сетевыми протоколами, ICE или распределёнными системами — возможно, этот разбор будет вам интересен.

Всем привет!

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

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

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

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

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

Сегодня рассказываю как я писал hypetype для macOS, сколько потратил часов, нервов и денег в сравнении с Windows версией, чему научился и какие выводы сделал.

AI всё чаще используется в разработке: генерация кода, автодополнение, агентные IDE. Но возникает логичный вопрос - можно ли доверить LLM полноценный code review?

В этой статье я решил проверить это на практике. Я сравнил несколько моделей, доступных через Ollama Cloud - Qwen 3.5, GPT-OSS и DeepSeek v3.1 - и дал им проанализировать реальные Pull Request из легаси-проекта на Python.

Спойлер: некоторые модели показали неожиданно хороший результат.