GitHub *

Скажите роботу «настрой манипулятор» — и он напишет драйвер сам. Звучит как фантастика из тех самых фильмов 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+ лет.

Многие венчурные фаундеры замечают, что последние 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 — это не просто подсказки в редакторе, а полноценный партнер по программированию, который может в разы ускорить вашу работу, если знать, как с ним взаимодействовать.