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

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-помощником.

Приветствую, Хабр!

Меня зовут Владислав Тимашенков, я занимаюсь автоматизацией тестирования в ГК Infowatch.

Наша команда столкнулась с популярными болями автотестов для API:

- одно изменение в API требует обновления нескольких тестов;
- проверка структуры ответа распределена по тестам и не централизована;
- валидация вложенных структур и генерируемых полей требует дополнительного кода.

И мы задались вопросом: какой инструмент для валидации контракта нам подойдёт?

В этой статье расскажем о нашем переосмыслении подхода к тестированию API с помощью внедрения Pydantic.

Я с командой пишу один большой C++ проект. У каждого свой Claude Code, у некоторых по два-три параллельно. Все они правят один и тот же репозиторий в одно и то же время.

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

Я построила им координацию - и по дороге переизобрела обычную почту. Восемьдесят второго года. Адрес получателя, тема для быстрой сортировки, In-Reply-To для цепочек, у каждой сессии свой ящик, broadcast через папку all/.

Каждый Claude при старте заглядывает в свой ящик и, если есть непрочитанное, докладывает это себе в контекст до первого промпта. Ответ падает в sent отправителю, подтверждение доставки - в квитанциях. Ни брокера, ни опросов, ни централизованного сервиса - только markdown-файлы.

Сверху ещё два слоя: append-only передача смены между своими сессиями и атомарные файлы-замки с heartbeat’ом на общие ресурсы.

mclaude, open source, зависимостей в ядре - ноль.

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

Но как это работает на самом деле? Как разработчики обеспечивают возможность паузы в игре?

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

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

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

Поехали.

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

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

Привет, Хабр! Меня зовут Артём Корсаков. Я пишу на Scala и руковожу группой разработчиков в компании «Криптонит», а также веду Scalabook — русскоязычную базу знаний по Scala и функциональному программированию. В этой статье расскажу про обработку ошибок в библиотеке http4s на Scala 3. Мы разберём, как настроить декодирование запросов так, чтобы клиент получал не просто код “500” или “422” с общим сообщением, а сразу видел развёрнутый список всех проблем в запросе. Например, что логин уже занят, пароль содержит недопустимые символы, а капча не введена.

Пожалуй, самая раздражающая ошибка — это получение кода “500” в ответ на запрос, который ты десять раз перепроверил, сверился с документацией и уверен на все 100%, что запрос рабочий. Даже на 110%! 

В такие моменты раздражённо думаешь: “Что же этому серверу надо? Я же чётко сформулировал запрос!

Ответить на этот вопрос порой сложно. Например, я хочу зарегистрироваться на сайте, ввожу логин/пароль и получаю сообщение "Internal Server Error". Первое желание – тут же покинуть сайт и поискать более дружелюбный.

Давайте подумаем, как можно сделать сообщение об ошибке более информативным. Для этого будем использовать Scala 3, уточняющие типы и http4s.

Представим, что мы создаём API сервиса авторизации, который (помимо прочего) должен регистрировать новых пользователей.

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

В 2026 году каждый второй стартап обещает заменить команду разработчиков роем AI-агентов. Звучит как мечта уставшего тимлида: один агент пишет код, второй ревьюит, третий деплоит, четвертый отвечает на вопросы в Slack, а пятый, наверное, уже сам заказывает пиццу в офис. Никаких больничных, никаких «я не успеваю», только железная продуктивность 24/7.

Я тоже купился. Взял CrewAI, собрал команду из трёх агентов для анализа конкурентов и генерации отчётов. Демо отработало идеально: агенты обменялись парой сообщений, выдали связный Markdown-файл и даже отправили его в Telegram. «Ну всё, — подумал я, — теперь можно увольнять аналитиков и копирайтеров. Будущее наступило».

Ровно через четыре часа после запуска на реальной задаче я наблюдал картину, достойную сюрреалистического полотна: пять AI-агентов устроили бесконечный митинг в духе худших корпоративных созвонов. Они перебивали друг друга, уточняли уже уточнённое, ходили по кругу и, кажется, начали обсуждать погоду. Один агент назначил себя лидом и раздавал указания, которые остальные игнорировали. Другой пытался писать в файл, который в этот момент читал третий. Спустя 127 вызовов LLM и сожжённые $4.30 на API-ключах я остановил этот цирк вручную.

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

Три минуты на планирование, десять на исполнение. Да, в масштабах человека это быстро, но уже хочется еще быстрее!

Судя по всему, я не одна такая. Посмотрите на провайдеров, которые за доплату дают ответы в два-три раза быстрее. Спрос есть, значит желание такое имеется не только у меня.

Но платить за скорость — не единственный выход.

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

Эта — про деньги. Про то, сколько мне стоило не понимать, что у меня за паттерн. И про то, что я сделал, когда наконец понял.

Продолжаем серию «Kotlin для новичков». Сегодня разбираем фундамент, без которого не обходится ни одно приложение: строки и коллекции. Как правильно резать подстроки, форматировать JSON, чем List отличается от MutableList и зачем enum в Kotlin круче, чем в Java. Заглядывайте, будет полезно!

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

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

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

Гляньте-ка! Это я с сервером Minecraft, запущенным на компьютере UNIVAC 1219B:

А ниже будет эмулятор NES с первым отрендеренным кадром Pinball.

… и селфи, напечатанное на телетайпе при помощи техники многократной печати «overstrike».

Мы сделали ещё кучу безумных штук, и в том числе:

• Программы OCaml (!)

• Веб-сервер

• Шифрование Curve25519 + AES

• Интерпретатор BASIC

• ELIZA

• Игры наподобие Oregon Trail, Wordle и Battleship

… а также многое другое! И всё это на компьютере из 1960-х с частотой 250 кГц и всего с 90 КБ ОЗУ. Ради такого я и живу! Я одержим запуском кода в странных местах и преодолением технических ограничений. Этот проект стал для меня самым амбициозным на данный момент, он отнял у меня и других примерно восемь месяцев.

Исходники проекта я выложил на Github. Также можете посмотреть видео TheScienceElf об этом проекте!

Третья статья из шести про инженерный процесс для разработки с ИИ-агентами. Автор, Андрей Юмашев, много лет руководил разработкой и инфраструктурой, полтора года назад отдал весь код агентам. Первая статья про путь от первых проектов до стандарта SENAR. Вторая про то, чем агент отличается от программиста. Эта про то, кем становится человек, когда код пишет не он.

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

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

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

Когда AI-агент пишет код в пустом проекте, первые 30-40% токенов он тратит на ориентацию — читает README, туториалы, API-reference. Ни один формат не отвечает на главный его вопрос: “какой паттерн скопировать и где грабли?”

Вторая проблема глубже: LLM знает “всё на свете”, но распределено это неравномерно. Статей пятилетней давности в интернете больше, чем свежих — и агент по умолчанию тянет меня в прошлое, предлагая устаревшие рецепты. Каждый раз гонять deep research — дорого, и результат всё равно испаряется с сессией.

Happyin Knowledge Space — 785 статей в 26 доменах, под MIT. Reference cards, не туториалы. Граф wiki-ссылок вместо vector DB. llms.txt на шести языках. Пишется по результатам моих реальных ресерчей — каждый deep research теперь становится карточкой в базе и не испаряется. Локально разворачивается за 5 минут, работает без серверов и без embedding-моделей.

Telegraph API обещает принимать content до 64 КБ, но на практике CONTENT_TOO_BIG прилетает уже на 17-20 КБ. Разбираю, как измерял реальный лимит, при чём тут UTF-8 vs UTF-16 для кириллицы, и каким обходным путём чинил молчаливую деградацию RU-канала.

Представьте: сервис А звонит сервису Б, а тот зависает. Сервис А ждёт, занимает потоки, не освобождает ресурсы. Потом к нему приходит другой сервис — и тоже встаёт в очередь. Так один сбой разрастается по всей системе, как снежный ком. Этот эффект называется каскадным отказом.

Паттерн Circuit Breaker (предохранитель) решает эту проблему. В статье разбираем его на примере ассистента HR с зонтиком, показываем, как настроить Resilience4j, и делимся, какие ошибки стоит (а какие не стоит) учитывать в статистике.
 

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

<Картинка не влезла в превью.>

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

За остаток цикла мы должны выяснить, как можно строить среднеразмерные игровые сцены на F#, а также почему этот цикл называется так, как называется. Конкретно в этой главе мы разберёмся с RenderingServer-ом (бывший VisualServer), но не с нуля, а с позиций достигнутых в »Godot — рисование без правил» и »Прямоугольные тайловые миры». Если вы уже прочитали эти статьи, то вам должно быть известно, что рисование через RenderingServer — это довольно экзотический подход, который воспринимает хождение сквозь стены как рядовое событие. Авторы движка этому не препятствуют, но и не содействуют, поэтому документации по этому серверу — кот наплакал. Мне так и не удалось выудить ответы на все интересующие меня вопросы в словесной форме и их пришлось выковыривать при помощи живых экспериментов. Последние ни в статью, ни в проект не влезли, но тут важна сама парадигма, при которой мы всегда отталкиваемся от практики, а не от теории, которой пока просто нет.