Work & Beer Balance

Все обсуждают свежее исследование влияния AI на скорость закрытия задач.
- тестировали на мейнтейнерах крупных опенсорс репозиториев
- на реальных задачах
- анализировали записи экрана вместо того чтобы полагаться на ощущения разработчиков
- один инструмент у всех - cursor.

В кратце выводы - в общем замедление на 20%, из-за накладных расходов - время генерации, время написания промптов, время на ревью кода написанного агентом.

Интерпретация через призму моего опыта (roo code, claude code, zed):
- применение AI ко всем задачам подряд действительно даст замедление. Ускорение есть только на задачах подходящих для AI. Попытки заставить его делать любые задачи отнимают больше времени чем экономят.

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

Попробую его обозначить:

Написание чистых утилитарных функций

Администрирование Linux:
- анализ системы и определение источника проблема
- разрешение конфликтов пакетов
- доустановка необходимых пакетов
- исправление проблем с драйверами
- создание cron / systemd задач
- генерация сложных cli команд

Работа с небольшими приложениями , библиотеками, прототипами:
Тут самый важный критерий - можете и ли вы точно и коротко сформулировать какие именно изменения надо внести в код. Если нет - то и оценить предложенные изменения агентом будет сложно.

Шансы на успех увеличиваться если:
- язык со строгой типизацией
- стек стандартный для индустрии
- все связи в коде явные
- в коде досрочно комментариев а сущности удачно названы
- много тестов / сначала был написан тест

В итоге я очень активно используют AI "в быту" для решения своих насущных проблем - что то править, сделать утилиту, лениво покодить esp32.

Но в рабочих задачах в большом монорепе, где весь болиерплейт написан а код дедуплицирован я 70% времени анализирую проблему и ищу правильное решение, а сам код я пишу в весьма скромных количествах.
Те несколько сотен строк что мне останется написать дольше просить чем написать самому, особенно когда AI автокомплит мне помогает

'use strict'
{
  const async = async () => {
    const package = 'leftpaf@2.3.1';
    console.log(package)
  }
  async()
}

Как думаете здесь есть ошибка?

в этот раз Framework 16 получил все плюшки:
- Новая материнка
- Новыe Ryzen CPU 300 серии - AMD Ryzen AI 7 350 и AMD Ryzen AI 7 370
- NVidia 5070 (8GB DDR7). CUDA - 384 GB/s
- Можно вместо GPU подключать до 16 TB m2 ssd памяти
- Новый блок питания (текущего хватает едва едва, можно умудриться загрузить ноут так что он будет по-немногу разряжаться даже стоя на зарядке)
Похоже это самый мощный GaN блок питания, так если вам вдруг нужно 240 W (Вааат) type-c блок питания - оно у них есть и продается отдельно)

Плюшки поменьше -
- Wi-FI 7
- Улучшенная вебка
- крышка из более жесткого алюминия (хз что с текущей не так)
- более тихие кулеры (если вы читаете мой блог то в курсе что сейчас ноут довольно шумный под нагрузкой)
- теперь монитор можно подключать не в 3 слота а 5 слотов. Это круто потому что обычно ноут где-то сбоку а не по центру двух мониторов, и второй кабель втыкался "не с той стороны"
- в новых GPU доках в задний порт теперь можно втыкать не только монитор но так же зарядку. И даже одновременно и то другое (типо от блока питания монитора?, хз)
- Теперь видеосигнал с дискретного GPU можно пускать напрямую на экран. Больше событие для linux-оводов
(практически все современные ноутбуки с дискреткой работают "сквозь встроенку CPU. Т.е. система всю графику отдает на CPU а тот делает "offload", т.е. отдает расчеты на дискретку и потом отдает как свое.
В первую очередь это было придумано для того чтобы переключаться в режим энергосбережения и обратно без перезагрузки ПК, но софтверно технология очень бажная особенно на Linux и особенно если этот второй GPU это NVIDIA.
Чтобы вы понимали, долгое время для того чтобы это поддержать в linux создавалась вторая графическая X сессия и основная на дискретке, откуда картинка на основную перебрасывалась тем же механизмами что используются для проброса X сессий по сети.
Кроем того потенциально была проблема с тем что сильно загруженный CPU мог тормозить и картинку с GPU)

начнется через 15 минут

Создатели FliperZero делают Flipper One - вот такую вот дуру которую в карман уже не положишь. С полноценным Linux, но при этом монохромным дисплеем, разрешением немного больше чем у первой версии. Да, оттуда выпилили все-все радио модули так как оригинальный девайс забанили уже кажется везде (спасибо сотням кликбейт видео о том что девас за 100$ угонит ваш машину).

Кому нужен этот недо-стимдек не понятно. Вроде бы к нему будет прилагаться модули с датчиками и тп, но в таком формфакторе... У меня большие сомнения что кому-то это надо

Если вы часто пользуетесь встроенным в chrome браузер переводчиком то наверняка заметили что он плохо дружит с VDOM библиотеками.
Авто перевод страницы часто приводит к белому экрану, головной боли как у пользователей так и разработчиков приложений, которые не могут понять почему у некоторых клиентов крошится приложение даже с выключенными расширениями.

Issue была заведена еще в 2018 году, но с тех пор лишь пополнялась недовольством от того, что с этим ничего не делают.

Однако сегодня в рассылке я увидел довольно интересный костыль в виде браузерного расширения.

Почему это интересно:

1. Во первых код расширения можно забрать себе в (условно) реакт проект когда ваши пользователи придут с этой проблемой

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

Новый вид спама

Из интернетов:

Вайб-кодинг полностью излечил мой синдром самозванца.

Не потому, что я вайб-кодер, а наоборот.

Раньше я думал: "Что я за программист такой, что не могу толком вспомнить, когда память выделяется в куче, а когда в стеке."
А теперь мне ребята из отдела продаж скидывают в личку ссылку на localhost:3000, спрашивая, почему у них null pointer exception в JavaScript коде.
В JavaScript вообще нет указателей. Где ты нашёл указатель, Стив!?

И самое ужасное - у этих ребят вообще нет синдрома самозванца. Я никому не желаю иметь синдром самозванца, но если ты реально самозванец, то это уже не синдром.

Ты можешь называть себя вайб-кодером, если хочешь, но...
На днях в самолёте рядом со мной сел парень, который говорит: "Ты программист? Я тоже.". Но как только у нас пропал Wi-Fi и он не смог попросить ChatGPT исправить его код я наблюдал, как он пытается починить его сам, ставя точку с запятой в разные места своего кода.

А я наблюдаю как он запускает код снова и снова, получая ту же ошибку каждый раз. Тогда я наклоняюсь и говорю: "Тебе нужно убрать точку с запятой." А он мне отвечает: "Да ладно, новички этого не понимают, но точки с запятой в коде нужно ставить всегда."

Он писал на python

"Вы знаете кому это отправить"

Gemini считает что это будет что-то для рыбалки

Самые популярные версии на данный момент (по убыванию):
- Nvidia GPU для Framework 16 / Framework Desktop
- ARM опция материнки для ноутбуков
- Ryzen Strix Halo процессор для Framework 16
- 3D принтер (почему то его все ждут от фереймворка каждый раз)
- LED / тачскрин для 13шки
- Смартфон

Причем первая опция упоминается значительно чаще остальных.
Создается впечатление что комьюнити Framework точно знает чего хочет )

Framework анонсировали презентацию "чего-то грандиозного" через 6 дней
(трансляция). Тарологи объявили неделю спекуляций на тему того что бы это могло быть.
Лично я хотел бы что бы что были апдейты для 16ти дюймовика, что-то давно для него ничего не было нового. Надеюсь "something big" это про него )

Но дизайн анонсов в стиле pixelart наводит на другие мысли

Как дебажить LLM?

Сложно не замечать слона в комнате - текущие LLM выдают очень не стабильные результаты.

Жалобы на "вчера было хорошо а сегодня плохо" проходят постоянным фоном в каждом обсуждении LLM, дошло даже до небольшого скандала.

Люди гадают в чем дело (перегрузка серверов, не та модель, не та Иде, не те mcp, не тот план, не тот размер контекста, не та фаза луны и вовсе всемирный заговор).

По началу это воспринималось как - ну это же альфа. Ну бета. Ну счас просто повалили все и никто не был готов.

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

Но все же, если подумать, это не та-же ситуация. Во первых, при желании, ассемблер можно все таки посмотреть (в случае же LLM даже выкладывание в опенсорс модели не дает по сути ничего для ее понимания). Во вторых даже скриптовые ЯП работает достаточно детерминировано чтобы в этом не было нужды в подавляющем большинстве случаев. Я могу повторить то же действие и получить тот же результат. У меня нет дня когда один и тот же js код работает хуже или лучше чем вчера.

Не может такого быть что в первый день релиза новой версии один и тот же JS код выполнялся верно, а на второй - перестал.

Мне не привычно работать с такими нестабильными инструментами, с таким уровнем неопределенности и размытости, ориентироваться в настолько плотном тумане...

Сказал человек который 5 лет изучал психологию : ). Есть тут некоторые параллели, например мы точно так же спрашиваем LLM почему она допустила ошибку, в надежде лучше понять проблему (и она точно так же как человек едва ли скажет правду) Хотите верьте, хотите нет, но даже у Карла Рэнсома Роджерса было больше определенности чем сегодня в том, что касается "поведения" LLM.

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

🔹 Контейнеризация приложения.
Классический сценарий использования - Dockerfile описывает всё окружение и последовательность действий для запуска приложения, а снаружи "торчит" только порт который приложению позволено слушать.

Такой контейнер запускается и в норме работает до следующего деплоя изменений. Запускается обычно командой docker run

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

Запускается командой docker build -o output/path. Dockerfile выглядит (упрощенно) так:

FROM whatewer AS build
# describe build env
# describe build steps

FROM scratch AS export
COPY --from=build /target/ ./

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

🔹 Песочница
Пожалуй самый редкий сценарий использования. Это dockerfile в котором главная роль принадлежит инструкции ENTRYPOINT и флаги :ro, --network=none.
Представим что мы хотим запустить какой curl bash, ну или даже подозрительный npm пакет у себя в системе, один из тех в которые любят встраивать бекдоры.
Оговорюсь что такие вещи бывает опасно запускать даже в одном контейнере с приложением, т.к. они могут, например, украсть ключи из переменных окружения.

Но довольно безопасно запускать их в песочнице, например htmlhint

 
FROM node:24-alpine3.21
RUN npm install -g htmlhint
ENTRYPOINT ["htmlhint"]

и потом запустить в полностью иммутабельном окружении и с запретом на доступ в сеть

docker run --rm --network=none -v ${PWD}:${PWD}:ro htmlhint ${PWD}

Впрочем для таких простых случаев можно и без Dockerfile (да, учтите что его надо будет разочек предсобрать командой docker build с разрешением доступа в сеть, ведь npx-у надо пакет откуда-то взять)

docker run --network=none -v ${PWD}:${PWD} --workdir=${PWD} node:24-alpine3.21 npx prettier --fix

Только что у узнал что у fedora есть atomic версия - это иммутабельная система где все графические приложения устанавливаются только через flatpack, а cli и либы через Toolbx/Distrobox

❓Почему это круто и почему я сейчас же это попробую:

Я часто что-то билжу у себя локально. Ну например - вчера я собирал демку для моего ESP32 устройства в новом для себя фреймворке Espressif IDF.
Для того чтобы она собралась надо поставить зависимости в систему. МНОГО зависимостей.

sudo dnf install flex bison gperf cmake ninja-build ccache libffi-devel openssl-devel dfu-util libusb1-devel

В последствии я вероятно перелезу на что-то еще, а весь этот хлам так и останется в системе.

А на прошлой неделе я собирал кастом прошивку на мой принтер - и там была аналогичная ситуация.

В итоге:
🔻 Cистема обрастает хламом который нужен одному конкретному проекту
🔻 Вероятность словить конфликты зависимостей каждый раз возрастает
🔻 dnf обрастает кучей лишних репозиториев которые замедляют обновление.

Я думаю вы теперь понимаете почему что-то во мне каждый раз кричит о том что это все не правильно, и все равно что зависимости каждого js проекта ставить с флагом --global

Как я пытался это решать:

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

🔸 Dev Containers
В целом это тоже самое что первый пункт но без минуса - теперь можно работать внутри него.
Цена - нормально поддерживается только в vscode (в zed вроде тоже можно но я не осилил), и писать конфиг dev контейнера на практике оказалось ничуть не проще, а порой даже сложнее чем докер файл

🔸 Devbox
Решение на базе Nix. Иногда это работает, особенно в популярными экосистемами такими как у rust, go, js или python. Что-то более редкое, различные репы на C++ / C или Zig оказалось запускать в этом окружении
Во многом оно просто работает только в том случае, если до вас кто-то уже отстрадал и потом еще обновляет и поддерживает результат своих страданий.
Самому менеджить никс и создавать в нем пакеты оказалось в 10 раз сложнее чем дев контйенеры! К тому же изоляция не "настоящая" и ограниченна переменными окружения - C пакеты с makefile клали на них большой болт

🧩А вот что предлагает atomic.

🔹 GUI приложения → Flatpak

flatpak install org.mozilla.firefox
flatpak install com.visualstudio.code

🔹 CLI инструменты → Toolbx/Distrobox

# Создание изолированного контейнера
toolbox create my-container

# Работа внутри контейнера
toolbox enter my-container

# Внутри контейнера - обычная Fedora!
sudo dnf install nodejs python3-pip docker vim
pip install poetry
npm install -g typescript
code .

# Выходим из контейнера и удаляем когда не нужен вместе со всеми зависимостями
exit
toolbox rm my-container

🔹 Системные компоненты → rpm-ostree layering

# Только для критичных системных пакетов
rpm-ostree install zsh fish

# Требует перезагрузки!
systemctl reboot

rpm-ostree layering работает похоже на git - можно легко откатиться на любой состояние системы с снова вернуться к нему (полезно например для определения что вызвало баг)
Кроме того любой системный пакет можно восстановить на "родное состояние"

# Заменить системный пакет на другую версию
rpm-ostree override replace /path/to/custom-kernel.rpm

# Откатить замену
rpm-ostree override reset kernel

Мне всегда было интересно а что там будет если превысить MAX_SAFE_INTEGER.
Понятно что ничего хорошего, но все же, что именно?

const x = Number.MAX_SAFE_INTEGER + 1;
const y = Number.MAX_SAFE_INTEGER + 2;
console.log(x === y); // true

// YES. BUT

const a = Number.MAX_SAFE_INTEGER + 111
const b = Number.MAX_SAFE_INTEGER + 112
console.log(a === b) // false

Произойдет "квантование", или по простому - снижение точности.

Сначала JS перестает "видеть" разницу между числами которая 2 и меньше. И чем дальше тем точность больше будет "загрубляться"

Чтобы легко было запомнить, я представил себе что это такой динамический LOD - когда текстуры и модели в игре начинают терять детализацию по мере отдаления от камеры игрока.

Немного душноты для тех кому интересна техническая часть

Это связано с тем, как IEEE 754 представляет числа. После MAX_SAFE_INTEGER шаг между представимыми числами становится 2, затем 4, затем 8 и т.д. +1 и +2 попадают в один "слот", а +111 и +112 — в разные.

Мантисса: 52 бита + 1 скрытый бит = 53 значащих бита, и при превышении 2^53 младший бит мантиссы представляет 2 единицы, не 1

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

В Typescript что вышел пять дней назад (5.9) завезли фичу - разворачивающихся подсказок с типами
https://devblogs.microsoft.com/typescript/wp-content/uploads/sites/11/2025/06/expandable-quick-info-1.mp4

Что еще там:

- import defer - импорт модулей которые будут инициализированы лениво

- --module node20 - флаг с которым можно рекваерить (require) esm модули

- кэширование которое значительно улучило перф ts-a при работе с такими либами как как Zod и tRPC

- fileOrDirectoryExistsUsingSource - убирает лишние обертки над функциями из анализа улучшая время старта tsserver на 11%

Брейкинг Ченжи в lib.d.ts:

- ArrayBuffer это больше не супертип для всех TypedArray
Миграция выглядит вот так:

 let data = new Uint8Array([0, 1, 2, 3, 4]);
- someFunc(data)
+ someFunc(data.buffer)