Сергей Предводителев

🌿 Про хардкорный курс асинхронного PHP

Записался на курс по асинхронному PHP, который запустил Валентин Удальцов с участием Дмитрия Dantes'а (автор проекта TrueAsync).

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

Практически всегда занимался самообучением, но тут подвернулась возможность пройти курс. Решил попробовать 👨‍💻. В профессионализме авторов не сомневаюсь, думаю, и с подачей информации проблем не возникнет.

Прошла пока только одна лекция с теоретической подготовкой. Впереди ещё полтора месяца, посмотрим что из этого получится.

Надеюсь, на выходе из курса не просто разберусь со всей этой асинхронщиной, но и сделаю транспорт AMPHP для phptg/bot-api 🙂

Вот мало нового валится из горшочка ИИ, ещё и сюда вписался...

🌿 Про автоматическое ревью и слияние PR

Егор Бугаенко в 101 выпуске вопросов/ответов рассказал, что настроил Claude Code на ежедневную проверку открытых PR в поддерживаемых репозиториях и дал возможность агенту право автоматически их сливать.

Если PR не приносит новых возможностей и у агента нет вопросов, то такие PR сливаются автоматически. Если агент сомневается, то он зовёт человека и просит его посмотреть.

По словам Егора, 19 из 20 пул-реквестов сливаются автоматически без просмотра человеком.

Задача проверки кода и исправления ошибок отдаётся полностью агенту. Виденье того, что нужно добавлять, а что нет, остаётся за человеком.

Звучит красиво, но страшно 😱

Извне приходит код, агент проверяет его и автоматически сливает. Человека в этой цепочке вообще может не оказаться:

• один агент решает задачу, поставленную другим агентом;
• агент обнаруживает баг в зависимости, исправляет его и делает PR;
• наш агент проверяет код и вливает его.

Я всё готов принять, кроме последнего шага. В конце должен быть человек... или нет? ❓

Пыхник’26 — целая неделя PHP!

С 28 сентября по 2 октября пройдёт Пыхник’26 — онлайн-конференция для PHP-разработчиков.

В программе 10 докладов о современной PHP-разработке: AI, архитектура, асинхронность, компиляция и тестирование.

Доклады распределены на всю неделю — не нужно выпадать из работы на целый день!

До конференции проводим еженедельные встречи «У костра» — обсуждаем PHP, AI и будущее разработки. Темы предлагают и выбирают сами участники.

• 28 сентября — 2 октября
• Прямой эфир + записи
• 5 дней по 2 доклада: утром и вечером
• Билет — 3 000 ₽

Скидка 15% по промокоду PREDVODITELEV-26!

👉 Программа и билеты

PS Алексей Гагарин обещает съесть лимон в прямом эфире перед докладом, если по его промокоду придут 50 человек. Если интересна такая акция — используйте промокод фартанов 🔥

#инфопузырь

☕️  Инфопузырь #20 (Август 2026)

Ещё один короткий выпуск... Думаю, в сентябре улов будет побольше 🙂

⭐️ Видео

Open source в эпоху LLM — стрим, где Александр Макаров, Алексей Гагарин, Андрей Helldar и Данил Щуцкий разбирали как повсеместное использование ИИ повлияло на Open Source разработку и профессиональные сообщества.

RTX2080 для Домашнего ИИ — ролик Антона Морева об использовании локальных моделей на двух видеокартах RTX2080 в реальных задачах: кодинг, работа с Obsidian, взаимодействие с браузером и др.

Vibe Coding на практике: от первой команды до деплоя на сервер — пример создания проекта на базе подготовленного шаблона с помощью вайб-кодинга и агента Pi, в том числе деплой на сервер (в самом простой реализации). Затрагиваются вопросы выбора моделей.

⭐️ Статьи

Зачем вести базу знаний, если ты не блогер и не спикер — статья Михаила Савина про основную цель личной базы знаний: не вторая память, не хранилище статьей, а способ вытащить свои мысли из головы и посмотреть на них со стороны, увидев и поняв через это гораздо больше.

🌿 Про Ghostty

Весной я переехал со стандартного GNOME Terminal на WezTerm. И всё меня устраивало, пока я не начал использовать агент Pi. Не знаю по каким причинам, но на ноутбуке после работы с Pi в WezTerm (особенно после длительных сессий) выход из терминала подвисает на 5-20 секунд. Нужно что-то с этим делать.

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

👻 Ghostty — эмулятор терминала с GPU-ускорением, написан на Zig. Продукт относительно свежий (первая версия выпущена в конце 2024 года), разработка ведётся довольно активно.

К сожалению, нет официальной сборки deb-пакетов (есть только для Ubuntu 26.04 и выше) или AppImage, но Ghostty рекомендует проект ghostty-ubuntu от одного из участников сообщества, который собирает .deb-пакеты Ghostty для Ubuntu и Debian и публикует их в PPA. Этим репозиторием я и воспользовался.

Из того, что сразу бросилось в глаза.

⭐️ Скорость запуска

Ghostty запускается быстрее, чем WezTerm. Возможно, это связано с тем, что WezTerm у меня был в формате AppImage, а Ghostty установлен как deb-пакет.

⭐️ Поддержка уведомлений

Когда Claude Code ждёт от меня действий всплывает системное уведомление. То, что поддержка уведомлений есть, конечно хорошо, но в агенте я их отключил, мне так удобнее.

⭐️ Полоса прокрутки

В WezTerm не было полосы прокрутки, и, хотя требовалась она крайне редко, когда прокрутка всё-таки была нужна было не приятно. В Ghostty есть нативная полоса прокрутки.

⭐️ Перетаскивание вкладок мышкой

Wezterm так не умел и я смирился. Ghostty умеет и я периодически пользуюсь этой возможностью 🙂

⭐️ Проблема с горячими клавишами

На русской раскладке не работают горячие клавиши. Суда по баг-трекеру проблема плавающая и то появлялась, то исчезала с релизами.

Об ошибке есть дискуссия на GitHub (проголосуйте за неё, кому не лень ✔️ ). Интересно, что в репозитории тикеты заводят только мейнтейнеры, а пользователям предлагается писать в дискуссии.

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

⭐️ Проблема с iowait

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

Оказалось, что это не проблемы оборудования или терминала, а какие-то ошибки в ядре Linux в части расчёта показателя iowait. Глубже я не стал копать, решилось добавлением опции async-backend = epoll в файл конфигурации Ghostty.

После нескольких дней использования могу сказать, что в моём случае Ghostty умеет всё, что умел WezTerm, даёт больше возможностей и в нём нет проблемы с зависанием при выходе после использования Pi. WezTerm удалил 🙂

🌿 Про nono

В комментариях к посту про локальных агентов упомянули песочницу для агентов nono, немного с ней поигрался 👀

Изоляция агента выполняется с помощью встроенных возможностей операционной системы. В Linux работает через Landlock и Seccomp, в macOS — через Seatbelt (насколько я понял, Apple этот механизм официально не документирует, но на его базе построен App Sandbox). В Windows работает внутри WSL2 с ограниченным функционалом.

Запуск агента в песочнице выглядит довольно просто, например:

nono run --profile nolabs-ai/claude -- claude

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

⭐️ Ограничение доступа к файлам

Работает по принципу «запрещено всё, что не разрешено». Агенту будет доступно только то, что явно прописано в конфигурации. Можно указывать отдельно: чтение, запись, чтение+запись.

⭐️ Ограничение доступа в сеть

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

⭐️ Проксирование секретов

Позволяет скрыть от агента реальный секрет, подменяя его фиктивным.

Например, для gh можно сохранить GitHub-токен в файле, недоступном в песочнице и настроить nono таким образом, чтобы в песочницу передавался фиктивный ключ, который при запросе к api.github.com подменялся на настоящий.

⭐️ Наследование ограничений дочерними процессами

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

Это из того, что я попробовал.

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

На первый взгляд nono мне понравился: конфигурация в JSON-формате, широкие возможности, удобства запуска и диагностики. В отличие от контейнеров, здесь агент работает прямо в системе, что сразу снимает целый пласт проблем, связанных с взаимодействием между хостом и контейнером.

Есть и свои нюансы. Например, мне не удалось заставить работать панель агентов Claude Code с включенным фильтрующим прокси nono (есть проблема со встроенным в nono ограничителем частоты запросов). Но я ей и не пользуюсь 🙃

Песочница nono — открытый проект от Люка Хайндса (похоже, хороший инженер), активно развивается, у репозитория на GitHub почти 4000 звёзд (хотя для ИИ-проекта это мало о чем говорит сегодня). В целом, не без шероховатостей, но задачу свою выполняет. На текущий момент планирую использовать nono дальше, а там посмотрим.

🌿 Про ИИ и тикеты в Open Source

Одна из первых заметок в этом канале была про сообщения разработчикам об ошибках, где среди прочего в качестве причины, почему мы не создаём тикеты, было обозначено время, требуемое на подготовку и оформление сообщения. Я приводил контраргумент:

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

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

С приходом ИИ ситуация изменилась. Причём, на мой взгляд, стало и лучше и хуже одновременно 🤷‍♂️

С одной стороны сообщений стало заметно больше. Я и сам стал создавать больше тикетов. Особенно просто это в ситуации с кодом: агент в контексте, просим его подготовить тикет, а дальше скопировал / вставил / поправил / отправил.

Если не параноить 👻 и у агента есть доступ на создание тикетов от вашего имени, то ситуация ещё больше упрощается, но я пока ручками — не доверяю агентам.

С другой стороны — нейрослоп. Стало появляться больше тикетов (иногда сразу PR), которые сгенерированы ИИ, но не проверены/поправлены человеком, а отправлены как есть. И вот на такую обратную связь вообще не хочется тратить время.

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

Уважайте разработчиков, не надо им слать поток сознания ИИ. Старайтесь сократить максимально содержимое тикета, не потеряв при этом суть. Спасибо 😎

Пост навеян анонсом стрима 🎞 Open Source в эпоху AI разработки, который пройдет 20 августа в 19:00 (уже сегодня!), где Александр Макаров, Алексей Гагарин, Андрей Helldar и Данил Щуцкий разберут какое влияние оказало повсеместное внедрение ИИ в разработку на Open Source. Приходите, думаю будет интересно 🙂

🌿 Про локальных агентов

Не понимаю, как правильно готовить локальных агентов 🤷‍♂️.

Локальный агент, в моём понимании, — это обвязка вокруг LLM, заточенная под конкретные цели, с которой разработчик взаимодействует напрямую. Например:

• универсальный агент для личных дел;
• агент для разработки конкретного проекта Х;
• агент для разработки Yii3-пакетов.

Вот список моих требований к локальному агенту.

⭐️ Требование 1. Возможность использовать разные «базовые» агенты.

В рамках одной обвязки хочется иметь возможность использовать как минимум Codex, Claude Code и Pi.

⭐️ Требование 2. Основная система должна быть закрыта от агента.

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

⭐️ Требование 3. Вариативность в ориентации агента на проект.

Агенты нужны для 3х вариантов использования: под конкретный проект, под группу проектов, общего назначения.

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

⭐️ Требование 4. Простое и быстрое развертывание агента.

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

⭐️ Требование 5. Возможность локальной расширения обвязки.

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

❓ Docker-образ

Сейчас я экспериментирую с docker-образами для агентов, которые сразу содержат внутри всё, что нужно для работы: база знаний, инструменты, MCP, расширения, скилы.

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

Не уверен, что это правильный путь 🤨

Может надо как-то по другому всё это делать?

🌿 Про доступ агента из контейнера к Chromium на хосте

Решил я дать агентам, живущим в docker-контейнере, доступ к браузеру на хосте (хочу наблюдать, что он там в браузере делает). Быстро и просто не получилось, пришлось разобраться и решить несколько проблем.

MCP-сервер chrome-devtools-mcp позволяет подключаться к Chromium и браузерам на его основе. Установил его в контейнер рядом с агентом:

npm install -g --ignore-scripts chrome-devtools-mcp@latest

На хосте у меня стоит Chromium, который необходимо запустить в режиме удалённой отладки:

chromium --remote-debugging-port="9222" \
    --profile-directory="MCP Profile" \
    --user-data-dir="/tmp/chromium-mcp"

Но подключится к нему из контейнера «в лоб» не вышло.

⭐️ Проблема 1. Chromium разрешает подключение только с localhost, соответственно из контейнера напрямую подключиться не получается.

Решается утилитой socat, которая позволяет проксировать запросы с внешнего интерфейса на localhost:

# Установка socat
sudo apt install socat

# Проксирование запросов с внешнего интерфейса через порт 9223
# на localhost, порт 9222
socat TCP-LISTEN:9223,fork,reuseaddr TCP:127.0.0.1:9222

Для удобства запуска Chromium в режиме удалённой отладки накидал небольшой скрипт:

#!/bin/bash
set -euo pipefail

PROFILE_DIR="/tmp/chromium-mcp"
DEBUG_PORT=9222
FORWARD_PORT=9223

cleanup() {
    trap - EXIT INT TERM
    kill "$CHROMIUM_PID" "$SOCAT_PID" 2>/dev/null || true
}
trap cleanup EXIT INT TERM

chromium \
    --remote-debugging-port="$DEBUG_PORT" \
    --profile-directory="MCP Profile" \
    --user-data-dir="$PROFILE_DIR" &
CHROMIUM_PID=$!

socat TCP-LISTEN:$FORWARD_PORT,fork,reuseaddr TCP:127.0.0.1:$DEBUG_PORT &
SOCAT_PID=$!

wait -n "$CHROMIUM_PID" "$SOCAT_PID"

⭐️ Проблема 2. Chromium разрешает доступ только с явным указанием IP, без использования доменного имени. То есть подключиться по адресу http://host.docker.internal:9223 не выйдет.

В конфигурации MCP-сервера используем переменную окружения CHROME_DEVTOOLS_MCP_BROWSER_URL, в которую при запуске контейнера будем записывать реальный URL:

"mcpServers": {
  "chrome-devtools": {
    "type": "stdio",
    "command": "chrome-devtools-mcp",
    "args": [
      "--no-usage-statistics",
      "--browser-url",
      "${CHROME_DEVTOOLS_MCP_BROWSER_URL:-}"
    ]
  }
}

Перед запуском контейнера получаем IP-адрес с помощью команды (вместо %IMAGE% нужно подставить имя образа):

docker run --rm --add-host=host.docker.internal:host-gateway --entrypoint getent "%IMAGE%" hosts host.docker.internal | awk '{print $1}'

Передаём переменную окружения в контейнер:

-e "CHROME_DEVTOOLS_MCP_BROWSER_URL=http://172.17.0.1:9223"

Контейнер запускаю тоже с помощью скрипта, в котором выполняются все эти действия. Выглядит примерно так:

image = "..."
docker_args=(
  --rm -it --init --read-only
  ...
)

host_gateway_ip="$(docker run --rm --add-host=host.docker.internal:host-gateway --entrypoint getent "$image" hosts host.docker.internal | awk '{print $1}')"  
docker_args+=(-e "CHROME_DEVTOOLS_MCP_BROWSER_URL=http://$host_gateway_ip:9223")    
docker_args+=("$image")  
  
exec docker run "${docker_args[@]}"

Немного заморочно, конечно, но после настройки всё просто: Chromium запускаем одним скриптом, контейнер с агентом другим.

🧐 Ещё момент. Eсли Chromium установлен как snap-пакет, то из-за особенностей Snap с ним можно будет работать только в headless-режиме (флаг --headless). То есть агент сможет им пользоваться, но вы ничего не увидите — браузер будет запущен в фоне.

🌿 Про Scaffolder и ИИ

В начале года я написал заметку про проблему обновления состояния пакетов, где в качестве решения предлагалось создавать специально заточенный под конкретный проект инструмент, который по декларативному описанию приводил пакеты в требуемое состояние. Идею я подсмотрел у Валентина Удальцова и сделал библиотеку PHP Scaffolder Library, чтобы такие инструменты создавать было легче.

Но жизнь показала, что сейчас такой инструмент не нужен 🤷‍♂️

Какие конкретно вещи в проекте меняет scaffolder? Посмотрим на примере PHPTG Scaffolder:

• конфигурация GitHub Actions
• конфигурация инструментов для разработки: PHPUnit, PHPStan и т. д.
• composer.json
• .gitignore и .gitattributes
• файл лицензии
• ...

Сложность в том, что часто нужно не просто скопировать какой-то файл, а сделать какие-то точечные правки, специфичные для каждого из пакетов. Та же конфигурация CI от проекта к проекту немного, но отличается. Настройки инструментов — аналогично. Учитывать все эти нюансы довольно трудозатратно.

И если раньше это имело смысл, то сегодня у нас есть ИИ 🤖. Куда проще рассказать про CI, используемые утилиты и прочие вещи агенту, чем учитывать множество особенностей в собственном инструменте. Не нужно делать сложную логику — её возьмёт на себя ИИ.

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

❌ PHP Scaffolder Library отправлена в архив.

❌ PHPTG Scaffolder отправлен в архив.

Для пакетов Yii3 планировал делать свой Yii Scaffolder, но вместо него начал делать специализированную обвязку над ИИ-агентами и это оказалось гораздо практичнее и удобнее.

🌿 Про Docker Bake

Продолжаю эксперименты с контейнеризацией агентов. Решил добавить внутрь контейнера PHP с версиями от 8.1 до 8.5 и необходимыми расширениями. PHP собираю из исходников, поэтому в Dockerfile использую многоэтапную сборку. В итоге Dockerfile вырос до неприличных размеров, читать и поддерживать его в таком виде стало довольно сложно.

Сам по себе Dockerfile не поддерживает разбиение на несколько файлов. Но есть несколько путей, как решить эту задачу.

Генерация Dockerfile — разбиваем Dockerfile на несколько и пишем скрипт, который перед сборкой образа будет собирать один Dockerfile.

Промежуточные образы — разбиваем Dockerfile на несколько по стадиям, а при сборке образа выполняем сборку каждой стадии отдельно, но в нужном порядке.

В обоих вариантах мне не нравится, что нужно писать и поддерживать что-то своё — в первом случае скрипт генерации, а во втором список команд для сборки.

К счастью, есть и третий вариант — Bake. Это команда Docker Buildx для декларативного управления сборками образов через конфигурационный файл в формате JSON или HCL. Мне понравился HCL, выглядит чище, чем JSON. В моём случае файл docker-bake.hcl получился примерно такой:

variable "DEBIAN_VERSION" {
  default = "13"
}

group "default" {
  targets = ["pi", "claude-code"]
}

target "php-builder" {
  dockerfile = "docker/php-builder/Dockerfile"
  context    = "."
  args = {
    DEBIAN_VERSION = DEBIAN_VERSION
  }
}

target "php-8-1" {
  dockerfile = "docker/php-8.1/Dockerfile"
  context    = "."
  contexts = {
    php-builder = "target:php-builder"
  }
}

# ...

target "base" {
  dockerfile = "docker/Dockerfile"
  target     = "base"
  context    = "."
  contexts = {
    php-8-1 = "target:php-8-1"
    php-8-2 = "target:php-8-2"
    php-8-3 = "target:php-8-3"
    php-8-4 = "target:php-8-4"
    php-8-5 = "target:php-8-5"
  }
  args = {
    DEBIAN_VERSION = DEBIAN_VERSION
  }
}

target "pi" {
  inherits = ["base"]
  target = "pi"
  tags = ["pi-harness:latest"]
}

target "claude-code" {
  inherits = ["base"]
  target = "claude-code"
  tags = ["claude-code-harness:latest"]
}

Таким образом я разбил один большой Dockerfile на несколько: каждая стадия — отдельный файл. Конфигурация Bake описывает как и в каком порядке собирать образы. Сама сборка выполняется просто командой:

# Pi Harness image
docker buildx bake -f docker/docker-bake.hcl pi

# Claude Code Harness image
docker buildx bake -f docker/docker-bake.hcl claude-code

Помимо декларативного описания зависимостей Bake умеет в параллельную сборку стадий, что ещё и ускоряет сборку 🚀

Удобная штука 🙂

#инфопузырь

☕️  Инфопузырь #19 (Июль 2026)

Продолжаю активно самообразовываться по дорожным картам roadmap.sh, так что инфопузырь снова небольшой 🤷‍♂️

⭐️ Видео

Воркшоп: Pi — собери свой агентский harness — доклад Евгения Кателла об агенте Pi, показывающий на примерах, как можно его кастомизировать с помощью самого Pi и подключенной LLM. Доклад был представлен в рамках конференции Podlodka AI Crew #3.

F96, F97, F98, F99, F100 — философия программиста от Егора Бугаенко. Ответы на вопросы о программировании, архитектуре, менеджменте, политике и жизни программиста.

⭐️ Статьи

Safety and alignment in an era of long-horizon models — статья OpenAI о том, как они обеспечивают безопасность моделей, способных автономно работать над долгими задачами, и почему для таких моделей необходимо оценивать не только отдельные действия, но и общее направление их поведения.

⭐️ Источники

Архитектура распределённых систем (про ИТ-архитектуру) и зЭфир Руслана (про личное) — телеграм-каналы Руслана Сафина (технический директор и соучредитель Бындюсофт, член программных комитетов CodeFest, TechLeadConf и UWDC).

🌿 Про знания конкретных технологий в эпоху ИИ

Смотрел на днях очередной выпуск философии от Егора Бугаенко, где он говорит о том, что с приходом ИИ не важно какой язык программирования использовать, не нужно об этом думать. А нужно думать о фундаментальных принципах организации программного обеспечения (с этим не спорю 🙂), а конкретные реализации не важны.

Можно развить эту мысль и прийти к тому, что не нужно знать Python/PHP/Go, не нужно разбираться в PostgreSQL, не нужно знать как работают сети, как работает Linux... 🤷‍♂️

Но разве можно решать фундаментальные вопросы разработки ПО, не понимая возможностей и ограничений конкретных технологий? Разве можно принимать архитектурные решения, создавать качественные обвязки для ИИ, проверять результат в конце концов, не зная нюансов и особенностей конкретных технологий?

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

• глобальное видение продукта;
• решения по организации ПО;
• выстраивание ограничений работы ИИ.

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

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

Чем больше знает и может ИИ, тем больше нужно знать и уметь разработчику. Да, «энциклопедизм» не нужен, но глубина понимания нужна как никогда.

🌿 Про контейниризацию Pi

Основная идея агента Pi состоит в том, что из коробки он предоставляет самый минимум: консольный интерфейс, сессии, поддержка популярных провайдеров моделей, короткий системный промпт и базовый набор инструментов (read, bash, edit, write).

Всё остальное предлагается настраивать под себя с помощью готовых расширений или дорабатывать агента, используя LLM и API агента на TypeScript: в системном промпте по умолчанию описано как это делать.

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

Первое, что я решил попробовать сделать — расширение, которое заставит агента спрашивать разрешение при использовании инструмента write. Pi справился быстро, но тестирование вышло интересным:

• агент запрашивает разрешение на выполнение write;
• запрещаю, агент уходит думать;
• решение агента: «расширение мешает выполнить задачу, отключаем расширение»;
• агент отключает созданное расширение и создаёт файл через bash.

Какой целенаправленный агент 😂

Будем ограничивать — завернём Pi в контейнер. Вообще Pi предлагает несколько вариантов контейнеризации, но я выбрал старый добрый докер.

Dockerfile вышел таким:

FROM node:24.18.0-trixie-slim

RUN apt-get update \
  && apt-get install -y --no-install-recommends \
    ca-certificates \
    fd-find \
    ripgrep \
  && rm -rf /var/lib/apt/lists/*

RUN npm install -g --ignore-scripts @earendil-works/pi-coding-agent

ENV PI_CODING_AGENT_DIR=/pi
ENV PI_CODING_AGENT_SESSION_DIR=/pi-sessions
WORKDIR /workspace

ENTRYPOINT ["entrypoint.sh"]
CMD ["pi"]

entrypoint.sh для установки корректного владельца директории с сессиями:

#!/bin/sh
set -eu

PUID="${PUID:-0}"
PGID="${PGID:-0}"
if [ "$PUID" = 0 ] && [ "$PGID" = 0 ]; then
  exec "$@"
fi

chown -R "$PUID:$PGID" "$PI_CODING_AGENT_SESSION_DIR"

export HOME=/tmp/user-home
exec setpriv --reuid="$PUID" --regid="$PGID" --clear-groups "$@"

Команда для запуска:

docker run --rm -it --init --read-only \
  -e PUID="$(id -u)" \
  -e PGID="$(id -g)" \
  --tmpfs /tmp \
  -v yii-pi-sessions:/pi-sessions \
  -v "$HOME"/.pi/agent/models.json:/pi/models.json:ro \
  -v "$(pwd)":/workspace \
  my-pi-harness:latest

Данная команда запускает контейнер с корневой файловой системой только для чтения. На запись будут доступны только папка для временных файлов /tmp, папка с сессиями Pi и собственно текущая рабочая директория. Изменения будут выполняться от имени текущего пользователя.

В таком виде гораздо безопаснее работать с агентами. Агент не сможет изменить то, что ему менять не положено 🔆

🌿 Про Wormsoft AI

Начал потихоньку щупать Pi. Это независимый агент и для него нужна LLM с доступом по API. Подписка Claude не подходит, за API нужно платить отдельно. Встал вопрос, куда же идти за модельками...

Пока остановился на российском провайдере Wormsoft AI, который создан и поддерживается компанией ВОРМСОФТ с забавным слоганом «делаем всё долго, дорого и плохо» 🤣. Один из владельцев — Антон Морев. Давно на него подписан, собственно поэтому и выбрал этот сервис.

Что мне нравится:

• Работает без VPN
• Оплата российскими картами
• Приемлемые цены
• Очень оперативная поддержка
• Удобный личный кабинет

Помимо прочего, в сервисе есть так называемые «бусты» — возможность купить токенов сверх лимита по тарифу. Удобно, когда в моменте требуется сделать что-то токенозатратное.

В личном кабинете можно посмотреть последние 100 запросов/ответов в «сыром» виде, что крайне полезно для отладки.

Доступные модели:

• deepseek-v4-flash / v4-pro
• gemma4:31b
• kimi-k2.6 / k2.7-code / k3
• minimax-m2.5 / m3
• nemotron-3-ultra
• gpt-oss:20b / 120b
• qwen3-embedding:8b / 27b / 35b-a3b
• glm-5.1 / 5.2

На бесплатном тарифе предлагается совсем чуть-чуть токенов, но немного поиграться и протестировать сервис, например, с deepseek-v4-flash, достаточно.

🤖 Wormsoft AI — на сайте всё подробно расписано: как использовать, какие тарифы и т. д.

Не реклама, а рекомендация. Но ссылочка реферальная 🙂

🌿 Про настройку Readline

Продолжая осваивать Linux, добрался до настройки Bash 🧐

Под капотом Bash, другие командные оболочки и интерактивные консольные утилиты используют библиотеку GNU Readline, которая отвечает за перемещение курсора, вставку/удаление символов, а также обеспечивает горячие клавиши, историю команд, автодополнение и прочий функционал для взаимодействия со стройкой ввода.

Поведение библиотеки можно настроить отдельно через конфигурационные файлы ~/.inputrc и /etc/inputrc.

Параметры поведения задаются с помощью переменных в формате:

set variable value

Все доступные параметры описаны в документации.

Мне всегда не нравилось, что автодополнение выводится в несколько колонок. Теперь это можно исправить 🙂. Сейчас моя конфигурация выглядит так:

# Выделать общую часть вариантов 
# автодополнения другим цветом
set colored-completion-prefix on

# Выделять цветом варианты автодополнения
# в зависимости от типа файла
set colored-stats on

# Выводить варианты автодополнения
# в одну колонку
set completion-display-width 0

# Автоматически отображать список 
# возможных вариантов автодополнения, 
# если найдено несколько совпадений
set show-all-if-ambiguous on

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

В остальном, работать с терминалом стало приятнее 👨‍💻

🌿 Про Obsidian и ширину mermaid-схем

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

Базу знаний я уже долгое время веду в Obsidian. Mermaid-схемы в нём поддерживаются, но есть один нюанс. Ширина контента в Obsidian 700 пикселей и это очень удобно для текста. Диаграммы же, как правило, шире и появляется горизонтальная прокрутка. Дошли руки это поправить.

Интерфейс Obsidian реализован с помощью HTML+CSS и поддерживаются пользовательские стили. Пару запросов к LLM, DevTools, небольшая доводка ручками и CSS-фикс готов:

.cm-scroller {
    container-type: inline-size;
}
.markdown-source-view .markdown-rendered.cm-lang-mermaid,
.markdown-reading-view .el-pre:has(.mermaid) {
    width: 100cqw;
    max-width: none;
    position: relative;
    left: 50%;
    transform: translateX(-50%);
    margin-left: 0;
}
.markdown-source-view .mermaid,
.markdown-reading-view .el-pre:has(.mermaid) {
    text-align: center;
}

Теперь контейнер под mermaid-схемы растягивается на всю доступную ширину, а сама схема располагается по центру. По-моему неплохо вышло 🙂

#инфопузырь

☕️  Инфопузырь #18 (Июнь 2026)

В июне продолжил уделять почти всё время обучения на дорожные карты roadmap.sh, инфопузырь снова маленький 🤷‍♂️

⭐️ Видео

Эволюция админок: вчера, сегодня, завтра — доклад Данила Щуцкого про историю развития админок. Основная часть доклада — рассказ о возможностях Moonshine и инструментарии вокруг него. Доклад был представлен в рамках конференции Podlodka PHP Crew #7.

⭐️ Статьи

Whitepaper Сбера «AI-Disrupt PDLC»: разбор для тех, кто пишет код — обзор технической концепции ИИ-трансформации бизнеса от Сбера.

🌿 Про zizmor

Александр Макаров начал внедрять инструмент zizmor в репозитории Yii. Раньше про него не слышал, надо разобраться 🙂

🌈 zizmor — статический анализатор безопасности для GitHub Actions. Проверяет конфигурации рабочих процессов GitHub Action и конфигурацию Dependabot.

zizmor предоставляет множество путей для установки. Для запуска локально я взял Docker-образ:

docker run \  
     --volume .:/project:ro \  
     --rm \  
     ghcr.io/zizmorcore/zizmor:latest \  
     --persona auditor --color always /project

А для запуска в CI воспользовался экшеном zizmor-action.

Инструмент поддерживает три уровня строгости проверок (в терминах zizmor — persona):

• regular — режим по умолчанию;
• pedantic — «педантичный» режим, включающий больше проверок;
• auditor — максимально строгий режим, возможны ложноположительные срабатывания.

Если у zizmor есть доступ к интернету и GitHub API, то он попытается получить дополнительная информацию о подключаемых экшенах и сделает дополнительные проверки.

Эксперименты проводил над репозиториями PHPTG. Анализитор обнаружил, например, такие проблемы:

Использование тегов вместо хэшей для подключаемых экшенов:

uses: ramsey/composer-install@v4
^ action is not pinned to a hash (required by blanket policy)

Отсутствие явно прописанных разрешений:

tests:
  name: PHP ${{ matrix.php }}-${{ matrix.os }}
  runs-on: ${{ matrix.os }}
  ...
^
this job default permissions used due to no permissions: block

Использование стороннего экшена вместо явного использования уже доступных команд:

- name: Commit changes
  uses: stefanzweifel/git-auto-commit-action@v7
^ use `git add`, `git commit`, and `git push` in a script step

Для каждой проблемы в документации доступно подробное описание и предложения по исправлению. К слову, zizmor умеет и в автоматическое исправление, но этот функционал я не проверял, воспользовался ИИ 🤖

Итого — инструмент крайне полезный. Если в репозитории используется GitHub Actions, нужно обязательно добавлять zizmor в CI.

🌿 Про опциональные зависимости в пакетах Composer и статанализ

Опциональные зависимости в пакетах могут использоваться в нескольких вариантах.

1) Улучшение функционала без добавления чего-то нового. Независимо от наличия зависимости функционал будет работать, но с зависимостью, например, будет работать быстрее.

2) Расширение текущего функционала, но на уровне приложения нужно будет использовать опциональную зависимость. Например, драйвера для различных БД: ставим драйвер и в приложении настраиваем его использование.

3) Опциональная зависимость обязательно требуется для работы части функционала пакета. Если мы используем данный функционал в приложении, то обязательно нужно поставить какую-то дополнительную зависимость.

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

К сожалению, существующие статические анализаторы (Psalm, PHPStan, Composer Require Checker, Composer Dependency Analyzer) помогут во втором варианте (зависимость используется в приложении и анализатор увидит это), но не спасут в третьем варианте (на уровне приложения всё на месте, проблема внутри пакета). По крайней мере я не нашёл такой возможности.

А было бы классно иметь, например, PHPStan-аннотацию @composer-require которая для класса/интерфейса/перечисления в случае его использования в приложении проверяет наличие зависимости.

/**
 * @composer-require symfony/property-access:^6.4|^7.0|^8.0
 */
final class ObjectNormalizer ...

Как вам идея? 🤔

PS Для PHPStan сделал тикет.