GitHub *

Форк репозитория — операция настолько привычная, что на нее редко смотрят с подозрением. Но что, если через обычный форк можно запустить произвольный код на CI/CD-воркере чужой приватной компании? 

Именно такую цепочку мы обнаружили в GitFlic — отечественной платформе для совместной разработки ПО и хранения исходного кода от компании «РеСолют». 

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

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

Обнаруженные нами уязвимости были оперативно исправлены разработчиками компании «РеСолют» и зарегистрированы в БДУ ФСТЭК: BDU:2025-12462, BDU:2025-12463, BDU:2025-12464.

Для начала — просто гляньте на те фото и видео, которые я сгенерировал, вообще не прикасаясь к мышке или планшету. Конечно, до и после было проделано немало работы, но сам процесс создания цифрового арта не требовал ручного рисования. Так что скажем спасибо моим CPU и GPU — они реально тащили 💪

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

Все русскоязычные гайды по GitLab CI/CD — это «сделай вот так под Node.js/Java/.NET». А как оно вообще работает? Написал подробный туториал: термины, схемы, разбор .gitlab-ci.yml, логи runner’а построчно. Первая часть из трёх — от простейшего pipeline до понимания, что конкретно вам нужно в вашем случае.

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

Особенно остро это ощущалось на пайплайнах для сборки статики. Задачи требовали много ресурсов, выполнялись довольно долго, но основная нагрузка приходилась не столько процессор, сколько на дисковую подсистему (IOPS). В результате у нас возникали постоянные заторы при выполнении нескольких таких задач подряд.

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

Продолжаю делать свое macOS приложение DynamicNotch. В последнем обновлении делал реализацию добавления обложки текущего воспроизведения на заблокированный экран.

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

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

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

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

Скажите роботу «настрой манипулятор» — и он напишет драйвер сам. Звучит как фантастика из тех самых фильмов 80-х и 90-х, но мы уже реализовали это в OpenGrall. Рассказываю, как работает режим Инженера и почему последнее слово всегда остаётся за человеком

Всем привет! Храню 7 терабайт фото и видео у себя дома на Synology DS224+ с DSM 7.3+

Это сетевое хранилище поддерживает Docker. Я дополнительно установил плашку памяти и теперь у меня 18 ГБ ОЗУ.

Но суть в том, что ночами я слышу "булькание" и "шуршание" дисков, кстати диски красные, прямо созданные под сетевые хранилища: WD120EFBX-68B0EN0 две штуки по 12 ТБ с зеркалированием.

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

Выложил проект в репозиторий

За одни сутки и шесть долларов алгоритм самостоятельно провёл почти две тысячи экспериментов на российском фондовом рынке.

Он не ждал команды. Сам формулировал гипотезу, сам писал запрос к данным, сам оценивал результат — и сразу задавал следующий вопрос. Цикл за циклом, пока мы спали.

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

Под катом — история одной ночи, почти двух тысяч вопросов и нескольких ответов, которые пришлось заслужить. Если интересно, как звучит рынок в четыре утра — заходите.

Как мы автоматизировали сборку Unity-проектов под несколько платформ: прошли через Jenkins, GitHub Actions с game-ci и сорокаминутные билды — и в итоге написали собственный инструмент.

В статье:

Почему Jenkins и GitHub Actions не подошли

Что такое Unity Builder и какую боль закрывает

Визуальный пайплайн, параллельные задачи, FTP-интеграция

Почему для некоторых GitHub перестал быть безопасным дефолтом, и что с этим делать - если вы, конечно, не хотите узнать об этом в день блокировки аккаунта или когда ваши закрытые репозитории могут общественным достоянием?

Думаю, для многих GitHub почти стал именем нарицательным. Помню, как я не знал, что такое git, но уже публиковал исходный код маленькой игры на GitHub через загрузку файлов. Многое было другим на тот момент: ИТ не был на пике мейнстрима, ИИ казался чем-то очень далеким и GitHub был де-факто стандартом.

Времена меняются и довольно быстро: теперь многие задаются вопросом так ли перспективен ИТ, появились LLM, которые используются ежедневно, GitHub уже не справляется с нагрузкой, а его приватные репозитории оказывается не такие уж и приватные.

28 апреля 2026 года стало по-настоящему плохим днём для GitHub. Утром CTO платформы опубликовал длинное извинение за кризис стабильности - 8 серьёзных сбоев за два месяца. Этим же днём Wiz Research опубликовал детали критической уязвимости CVE-2026-3854: один обычный git push мог выполнить произвольный код на серверах GitHub.

По порядку разберём и свежие, и давние события с точки зрения обычного разработчика, которые происходят с GitHub сейчас

Когда я создавал свой первый Python-пакет я столкнулся с интересной задачей:как настроить CI/CD в GitHub так, чтобы при отправке новых изменений ничего не ломалось, а код автоматически публиковался в PyPI.

Обычно, чтобы проверить любой коммит, попадающий в master-ветку через pull request, необходимо запускать тесты. Кроме того, полезно использовать линтеры для проверки стиля кода, особенно если над проектом работают несколько разработчиков.

В этой статье я расскажу как все это настроить в Github, чтоб оно выполнялось автоматически.

Полгода назад я начал портировать нейросеть EdgeFace-XS из ONNX в чистый C. Думал — граф небольшой, 1.77M параметров, что может пойти не так? Первый наивный порт выдал 24мс. ONNX Runtime — 3.9мс. В 6 раз медленнее. А потом началась оптимизация

Всем привет! У человека в среднем около 4000 недель жизни. Четыре тысячи. Если нарисовать каждую неделю как маленькую клеточку — вся ваша жизнь поместится на один экран. Вот прям вся. От рождения до смерти. Мне 37 — значит примерно 1900 клеток уже закрашены, а оставшиеся… ну, это мы ещё посчитаем.

Эта концепция не моя и не новая — но на днях она всплыла в одном бизнес‑чате. Товарищ скинул скриншот из бота который как раз рисует такой grid. Закрашивает прожитые недели, оставляет пустые те что впереди. Красиво, минималистично, грустно. И я спросил: «А тебя это не тревожит?»

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+ лет.