GitHub *

Пятница, 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-приложения:

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

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

Компания кажется потрясающей — 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 проект. Приглашаю сообщество проверить эту гипотезу вместе.

Anthropic отключила сторонние инструменты от подписки — теперь всё, что не Claude, идёт в Extra Usage по ценам API. Мой агент на Opus за вечер нажигает на десятки долларов. Я потратил вечер на то, чтобы разобраться, как именно Anthropic детектит сторонние запросы, и нашёл способ обойти блокировку. Ни одного гайда я еще не видел. Оказалось, что всё сводится к двум именам инструментов из семнадцати — этого достаточно, чтобы сервер понял, что запрос не от Claude Code. В статье весь путь от гипотезы до работающего решения, плюс пошаговый гайд для тех кто хочет повторить.

Я выпустил вторую версию 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. И вот тут началось интересное.