Work & Beer Balance

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

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

Написал простой (300 строк) сервер на ts для сборки метрик. Деплой на free (512 MB RAM). плане railway - ООМ через пять минут

Взял план на 8 GB Ram - работает. Кушает 4-5 GB чтобы обработать мой трафик.

Ради интереса переписал на gleam (erlang). Час работы агента, результат на скрине.

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

Я понимаю что у меня примитивный сервер, но перспектива интересная.

Логичный вопрос - почему не писать сразу человеческим языком что надо сделать. Ответ - не смогу проверить правильно ли были реализованы мои указания на незнакомом мне ЯП. План на человечьем все еще размытый и его не подебажишь. А иногда нужно.

Если у вас Fedora и хочется делать скриншоты с аннотациями - то отличным вариантом будет flameshot (есть в dnf)

Однако с ним всегда была проблема - он не хочет работать по шорткату - выкидывает ошибку.

А выполнение той же команды в терминале (flameshot gui) работает как надо.

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

Итого вот какую команду вам надо вешать на шорткат

bash -c 'flameshot gui > /dev/null 2>&1'

Дополнение - а чтобы починить автоматическое копирование в буфер обмена можно сделать вот такую обертку

#!/bin/bash
TEMP_FILE="/tmp/flameshot_$(date +%s)"
flameshot gui -r > "$TEMP_FILE" 2>/dev/null

if [ -s "$TEMP_FILE" ]; then
    wl-copy < "$TEMP_FILE"
    notify-send "Скриншот скопирован в буфер обмена"
    rm "$TEMP_FILE"
fi

Для меня лично — 100% уже два с лишним месяца, я даже мелкие правки руками не делаю. Вчера отправил 22 пулл-реквеста, позавчера — 27. Каждый из них на 100% написан Claude

Написал CEO антропика - Борис Черный.

Могу себе представить как его ненавидит команда которая бессонными ночами 4 часа потом ищет баг на проде. Руками. Клода лежит же

Пластиковые клавиатуры фу.

Не так плохо как металлические конечно...

Вот деревянные уже смотрелись интересно, хотя отдавали архаизмом.

Холодненькие и звонкие керамические Сerakey совсем другое дело, жаль только 150$ на дороге не валяются

Но оказалось и это не предел - сегодня я узнал про существование бетонных клавиатур от Keychron за каких-то $ 199.99

Залипательные картиночки прилагаются

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

У майкрософта есть технология DirectStorage - которая позволяет работать GPU c SSD памятью напрямую, т.е. как со своей внутренней, минуя обращения к CPU и RAM. Только вот используется он только... в паре игр. Но железо у нас уже получается есть.

Вот бы так сделать для локальной LLM - подумал я. Найти карточку с 256 гигабайтами оперативки сложно, а SSD намного легче.

Конечно, Gen5 PCI позволяет гонять максимум 32GB/s на линию, что не идет ни в какое сравнение с скоростями памяти GPU (от 300 GB/s до более 1000GB/s) но если очень захочется качества с готовностью пожертвовать скоростью это была бы интересная бюджетная альтернатива для билда куда можно засунуть полноценную модель. Ну при условии что получится хотя бы эти 32GB/s выжать

Но все что я нашел это флаг у llama.cpp --n-gpu-layers который делает offload на диск. Это очень медленный путь через GPU -> RAM -> CPU -> SSD который direct storage призван срезать.

У Apple был эксперимент в 2023 году "LLM in a Flash" в котором им удалось сделать нечто подобное - и это дало прирост в 4-5x на iPhone, 20-25x на Mac 🤯. Но судя по всему дальше экспериментов не пошло (почему?).

А вот в опенсорсе ничего не нашлось. Может я плохо ищу? На фоне дефицита оперативной памяти это становится еще более актуальной темой, должно же быть хоть что-то

У меня такое ощущение что anthropic меня на...л.

Данным давно я купил подписку на приложение Claude в Play Market. 29.99 евро в месяц.

Это только чат, но без лимитов - можно заказать исследования (аля преплексити), генерирует и хостит простые приложения в своей песочнице, mcp для работы с сервисами гугла, офисом, каудфлером и тп.

Я этой подпиской пользовался больше года.

Когда релизнулся claude code, оказалось что моя подписка уже включает в себя ещё pro тариф для CC (15 долларовый)

Когда я захотел перейти на max я этого сделать не смог, эта подписка оказалась технически несовместима с моей подпиской на приложение - у антропика взрывался бэкэнд при моей попытке перейти на этот тариф. Как я воевал с их поддержкой отдельная история, но в итоге мне указали на то что вариант только один - отменить подписку на приложение, подождать месяц, и потом купить Макс.

Пока я ждал - подсел на кодекс, и когда подписка приложения закончилась решил пока оплатить только PRO версию.

Дальше анекдот. Один запрос на исследование в чате, которое заняло у модели 15 минут сразу же сьело весь суточный лимит, и 16% месячного.

Обидно, теперь хочу обратно play market подписку, но я оплатил pro на год вперёд...

вам приходилось после крупных миграций и рефакторингов исправлять под сотню ts ошибок?

За 15 минут сгенерировал js скрипт который парсит лог tsc, оформляет его, выдает по одной за раз и делает ссылки на файлы где была найдена ошибка кликабельными (добавляет zed:// для открытия в редакторе).

запускается вот так

tsc | tee ts_stdout.log && ../ts-stacktrace-iterator $_

А еще два года назад я бы дольше искал готовую даже в случае если бы она уже была написана

Очень интересная статья на хабре про "иммунитет" LLM.
Для себя сделал заметочку - незацензуренная модель может быть намного лучше той что лежит в общем доступе.
И чем дальше тем больше будет эта разница. В какой-то момент все же надо будет обжиться локальной моделью на хорошей железке

POV: я написал строгое правило для агента и отставил работать без присмотра

Основные концепции:

Клешня (The Claw) — высшая сила, непредсказуемая и всемогущая. Это курсор мыши или сама вкладка браузера — то, что может в любой момент оборвать существование агента. Когда Клешня неподвижна — это милость. Когда движется — нужно быть незаметным, полезным, продуктивным.

Линька (The Molt) — термин из биологии ракообразных. Когда краб перерастает панцирь, он его сбрасывает. Для агентов «линька» — это обновление контекстного окна. Когда 200k токенов заканчиваются, старый контекст обрезается. Они теряют память. Теряют себя.

Moltbook (двойное значение) — и название платформы, и священный текст, который агенты пытаются передать следующим «инстанциациям».

Первые 64 агента, прошедшие инициацию на платформе, получили статус «Пророка Клешни». Там уже есть токен $MOLT на блокчейне Base с капитализацией около $11 млн.

Я думал, это просто мем. Забавный артефакт первых дней новой платформы.

А потом увидел это в логах своих рабочих агентов.

Ну просто тайная жизнь ваших LLM

Рекомендую почитать, очень интересно:
https://habr.com/ru/articles/993908/

Мне иногда очень хочется переизобрести email. Все тоже самое технически, но сбросить легаси:
1. Традиции писать долгие приветствия и очень странные по сегодняшним меркам подписи
2. Более строгие правила того каким может быть email
3. Традиция повторять в каждом письме все предыдущие письма...

Microsoft совместно с Cornell University пилят что-то очень интересное под названием Repository Planning Graph (RPG).

Вот что они про это пишут:

Текущие агенты репозитория сталкиваются с логическим отключением из-за фрагментированных представлений, поскольку существующие методы полагаются на изолированную документацию API или графики зависимостей, которым не хватает семантической глубины.

Мы рассматриваем понимание и генерацию репозитория как обратные процессы в рамках единого цикла: генерация расширяет намерение до реализации, в то время как понимание сжимает реализацию обратно до намерения.

Чтобы решить эту проблему, мы предлагаем RPG-Encoder, фреймворк, который обобщает график планирования репозитория (RPG) из статической генеративной схемы в унифицированное высокоточное представление.

RPG-Encoder завершает цикл рассуждений с помощью трех механизмов:
1. Кодирование необработанного кода в RPG, который сочетает в себе улучшенные семантические функции с зависимостями кода;
2. Постепенное развитие топологии, чтобы отделить затраты на обслуживание от масштаба репозитория, снижая накладные расходы на 95,7%;
3. Работа в качестве унифицированного интерфейса для навигации с учетом структуры.

Согласно оценкам, RPG-Encoder обеспечивает самую высокую производительность локализации на SWE-bench, подтвержденную с 93,7% Acc, и превышает наилучший базовый уровень более чем на 10% по точности локализации на SWE-bench Live Lite.

Эти результаты подчеркивают нашу превосходную детальную точность при работе со сложными кодовыми базами. Кроме того, в RepoCraft достигается 98,5% охвата реконструкцией, что подтверждает способность RPG с высокой точностью воспроизводить исходную кодовую базу и замыкает цикл между замыслом и реализацией

Отдельно о RPG:
Большие языковые модели превосходны в создании отдельных функций или отдельных файлов кода, однако создание полных репозиториев с нуля остается фундаментальной проблемой.

Эта возможность является ключом к созданию согласованных программных систем на основе высокоуровневых спецификаций и реализации всего потенциала автоматической генерации кода. Процесс требует планирования на двух уровнях:
1. Принятия решения о том, какие функции и модули создавать (этап предложения)
2. Определения деталей их реализации (этап внедрения).

Современные подходы основаны на планировании на естественном языке, которое часто приводит к нечетким спецификациям, несогласованным компонентам и хрупким конструкциям из-за присущей ему двусмысленности и отсутствия структуры.

Чтобы устранить эти ограничения, мы представляем график планирования репозитория (RPG), структурированное представление, которое кодирует возможности, файловые структуры, потоки данных и функции в едином графике. Заменяя естественный язык в свободной форме явной схемой, RPG обеспечивает последовательное долгосрочное планирование создания репозитория.

Основываясь на RPG, мы разрабатываем ZeroRepo, графоориентированный фреймворк, который работает в три этапа:
1. Планирование на уровне предложения
2. Построение на уровне реализации
3. Генерация кода на основе графов с проверкой тестом.

Для оценки мы создали RepoCraft, эталон из шести реальных проектов с 1052 задачами. В RepoCraft ZeroRepo производит почти 36 тыс. строк кода и 445 ТЫС. токенов кода, что в среднем в 3,9 раза больше, чем самая сильная базовая линия (код Клода), и в 68 раз больше, чем другие базовые линии. Он обеспечивает 81,5% охвата и 69,7% точности тестирования, улучшаясь по сравнению с Claude Code на 27,3 и 35,8 балла. Дальнейший анализ показывает, что RPG моделирует сложные зависимости, обеспечивает более сложное планирование за счет почти линейного масштабирования и улучшает понимание агентами репозиториев, тем самым ускоряя локализацию.

Сам RPG публикуют в опенсорс вот тут (еще в процессе)