GitHub *

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

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

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

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

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

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

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

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

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

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

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

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

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

Всем привет!

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

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

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

Все началось со статьи Как собрать клон Yamaha DX7 за 10$. Так как я достаточно давно занимаюсь музыкой, и люблю конструировать всякие электронные штучки, меня эта статья заинтересовала. Я тут же начал прикидывать по цене возможные варианты. RPI2040 конечно же очень дешево, но посмотрев пару обзоров на Picodexed на YouTube, меня не привлекла простенькая синтезаторная составляющая. Понятно, что это полная эмуляция движка Yamaha DX7, но слишком уж звук невзрачный и простой. После просмотра вариантов эмуляторов синтезаторов на RPI на YouTube меня больше заинтересовали проекты MiniDexed, MT32-pi и Mini-JV880. 

🏆 1 место на хакатоне без работающего кода? Легко!

Мы заняли 3 место с рабочим сервисом. Победители показали картинки и получили премию Мэра. Мы проверили их GitHub: там пусто.

Внутри расследование:

Ссылки на код победителей (alert() вместо API).

Разбор метрик (SMAPE 79%).

Как связи решают всё.

Читайте, как выигрывают не технологии, а подрядчики. 👇

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

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

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

14 января 2026 года Cursor опубликовала пост «Scaling long-running autonomous coding» (https://cursor.com/blog/scaling-agents).

В этом посте компания рассказала о своих экспериментах с «автономной работой кодинг-агентов в течение нескольких недель» со следующей чётко поставленной целью:

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

Компания рассказала о подходах, которые она попробовала, о предполагаемых причинах их провала и о том, как решались эти проблемы.

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

Чтобы протестировать эту систему, мы поставили перед собой амбициозную цель: создание веб-браузера с нуля. Агенты работали примерно неделю и написали больше миллиона строк кода в тысяче файлов. Исходный код можно посмотреть в GitHub (https://github.com/wilsonzlin/fastrender)

И здесь объяснения становятся немного запутанными и нечёткими. Компания заявляет, что «несмотря на размер кодовой базы, новые агенты всё равно понимают её и добиваются существенного прогресса» и что «сотни воркеров работают конкурентно, выполняя пушинг в одну и ту же ветвь с минимальными конфликтами», но ни разу не говорит, был ли проект успешным, работает ли он на самом деле. Можем ли мы сами запустить этот браузер? Это неясно, и компания ни разу не сделала подобных чётких заявлений.

Примерно год назад я написал статью ChatGPT без VPN за 10 минут (и установка нативного приложения). Хотя она актуальна до сих пор, сегодня я хочу вам рассказать про еще один способ.

Суть: мы делаем свой DNS-профиль в NextDNS или Cloudflare и автоматически актуализируем его раз в сутки.

Для этого я написал небольшую программу. Самое приятное: для ее работы вам не придется ничего устанавливать вообще.

Когда я закончил работать над проектом ecosyste-ms/package-manager-resolvers, мне стало интересно, какой алгоритм разрешения зависимостей использует сервис GitHub Actions. Когда вы записываете в файл рабочего потока uses: actions/checkout@v4, то объявляете зависимость. GitHub её разрешает, скачивает и исполняет. Так работает управление пакетами. Я же решил отправится в кодовую базу runner, чтобы увидеть весь этот процесс изнутри. И открытия, скажу я вам, оказались весьма тревожными.

Привет, на связи Ксюша, миддл-разработчик Surf. Миддлом я стала недавно. Когда я пришла в компанию, я, конечно, знала, что такое Git. Ну, по крайне мере, я так говорила. 

Как-то я, по чистейшей случайности, разумеется, перезаписала чужую ветку. А потом потратила часов 6, чтобы вернуть всё «как было». Благо, помог наш лид, который показал, что делать.

Так я и поняла, что Git — совсем не плохое слово из трёх букв. И теперь несу для всех, кто точно так же начинает свой путь в Git, подробную и понятную инструкцию работы с ним. Го разбираться.

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

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

Проиндексируем фото-видео архив для поиска на человеческом языке простыми фразами. Фраза: «новогодний праздник» найдет все фото и видео связанные с новым годом. В этом нам поможет Qwen3-VL и Qdrant.

...А заодно добавим поиск по лицу.

Откройте любой пулл‑реквест в проекте с любой «чистой архитектурой» и вы скорее всего увидите не обсуждение бизнес‑логики, а срач. «Это нельзя класть в UseCase, это логика домена!», «Зачем тут еще один DTO, мы же просто поле прокидываем!», «Этот интерфейс не нужен, у нас никогда не будет другой реализации!». Полагаю, очень много людей с таким сталкиваются.

Эта статья — о том, почему архитектура из спасения превратилась в тонны говнокода. И, что самое главное, — как прекратить этот хаос и, наконец, начать просто писать код, который работает, а не «следует всем концепциям».

Как мы воскресили русский NLP и сократили потребление памяти на 90%

Форкнули четыре ключевых библиотеки русского NLP (pymorphy, razdel, slovnet, natasha), которые не обновлялись годами. Сократили потребление памяти на 90%, ускорили загрузку в 30 раз, повысили точность токенизации с 70% до 95%. Всё работает offline, 100% совместимо с оригинальными API. Экосистема MAWO — production-ready инструменты для работы с русским текстом.

Помните ли вы тот момент, когда открываешь проект для обработки русского текста и видишь знакомую картину? В requirements.txt красуется pymorphy2, последний коммит в репозитории датирован 2015 годом, Python 3.12 ругается на deprecated методы, а production ждать не будет. Знакомо? Тогда эта история для вас.

Да, это очередная статья по чистому коду. Но по разным источникам, соотношение времени, затрачиваемого на чтение и написание кода, может достигать 7 к 1 и даже больше. Когда вы исправляете ошибку, добавляете новую функциональность или проводите рефакторинг, вы сначала погружаетесь в логику, написанную другими людьми (или вами же, но несколько месяцев назад). Именно поэтому читаемость кода становится более важным фактором, чем скорость его первоначального написания. Нечитаемый код — это технический долг, который замедляет всю команду и увеличивает стоимость разработки в долгосрочной перспективе.