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

🌿 Про локальных агентов Не понимаю, как правильно готовить локальных агентов 🤷‍♂️. Локальный агент, в моём понимании, — это обвязка вокруг 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 сделал тикет.

Пыхник’26 Привет, дорогие Пыхари! На закрытии Пых.конф’25 мы с вами договорились, что встретимся снова в 2026. В этом году вместо полноценной Пых.конф мы решили попробовать другой формат — Пыхник! Примерный план: • конец августа / начало сентября; • загородный отель Art Village (12 км от МКАД); • 100-120 офлайн-участников; • 1 зал без параллельных потоков; • 8 лучших докладов про PHP и экосистему; • фуршет от конференции + рестораны на территории; • записи докладов для всех участников уже на следующий день; • возможность приехать с семьёй и провести в отеле ещё пару дней. По предварительным расчётам стоимость участия может составить 6000₽. Добиться такой цены получится за счёт простого формата: без нескольких залов, сложного продакшена и прочих атрибутов больших конференций. Чтобы не рисковать деньгами и понять, нужна ли такая встреча сообществу, мы думаем запустить краудфандинг на Planeta.ru (у нас уже был положительный опыт со слониками). Собираем необходимую сумму — проводим мероприятие, нет — деньги возвращаются. Пожалуйста, проголосуй ниже безотносительно даты и программы — так мы сможем предварительно оценить интерес. И ждём побольше вопросов в комментариях, чтобы мы ничего не забыли учесть!

🌿 Про Пыхник 2026 Есть мысль вместо полноформатной Пых.конф’26 встретится PHP-сообществом на природе в ламповом формате под названием 💙Пыхник. Проголосуйте, как вам эта идея?

🌿 Про случай с лимитами в Claude Code и выбор модели Решил я как-то обновить зависимость yiisoft/html в пакете Yii Bootstrap 5, который предоставляет виджеты из Bootstrap. В последних версиях Yii HTML был изменён порядок вывода атрибутов в тегах: ранее они сортировались, а теперь выводятся в порядке их добавления. В тестах Yii Bootstrap 5 очень много проверок HTML, которые нужно было исправить в соответствии с новым порядком атрибутов. По итогу изменения затронули более 1000 строк (см. PR). Отличная задача для ИИ-агента. Тут даже объяснять ничего не надо: смотри ошибки в тестах и исправляй. Запустил я Claude Code, сделал простейший промпт, и он начал работу: • запустил тесты; • посмотрел ошибки; • осознал, что от него требуется; • запустил в фоне параллельно 10+ агентов • начал вносить правки • и упёрся в лимит 🤷‍♂️ Так быстро лимиты у меня ещё не заканчивались (у меня, правда, тариф Pro). Проблема была в том, что файлы тестов большие, вывод PHPUnit тоже большой, а модель по умолчанию у меня стояла Opus 4.6. Claude Code в субагентах всё это дело активно читал и быстро упёрся в лимиты. В следующий раз я выбрал дешёвую модель Haiku 4.5 для быстрых ответов, попросил агента не запускать субагентов и просто шаг за шагом править тесты. И он отлично справился, скушав не так уж много токенов. Такая вот зарисовка из опыта взаимодействия с LLM 🙂

🍉 Podlodka AI Crew #3 «AI-First Development» С 15 по 19 июня пройдёт третий сезон онлайн-конференции Podlodka AI Crew, который будет посвящён уже не отдельным ИИ-инструментам, а в целом модели разработки с полноценной интеграцией с ИИ. Программа: • Открытая сессия «Жизнь после SDD, как не убить качество» • Демо-сессия «CLI-агенты как основа AI-автоматизаций» • Круглый стол «Как AI меняет найм инженеров» • Демо-сессия «Дизайн без дизайнеров: генерируем UI с помощью AI» • Воркшоп «Воркшоп по Pi — собери свой агентский harness» • Демо-сессия «Скиллы: как создавать, улучшать и распространять на команды» • Демо-сессия «Как эффективно проверять код, сгенерированный Ai» • Демо-сессия «Model routing и управление контекстом: как настроить экономику AI-агентов» • Доклад «Eval Driven Development: как перестать проверять AI на глаз» • Демо-сессия «Как внедрить AI в компанию за 50к в месяц» • Доклад «Агенты, которые улучшают сами себя» • Бар «Prompt in the Dark» ⚡️ Полная информация на сайте — расписание, спикеры, билеты. ————— По традиции, бонусы для подписчиков 😎 ⭐️ SERGEI — промокод на скидку 500 рублей ⭐️ Розыгрыш двух бесплатных проходок Чтобы получить проходку, нужно выполнить несколько условий: • быть подписанным на канал @sergei_predvoditelev; • написать в комментарии к этому посту как сейчас ИИ встроен в ваш личный процесс разработки. В субботу, 13 июня, случайно-субъективно выберу победителей 😏

#инфопузырь ☕️  Инфопузырь #17 (Май 2026) В мае много образовательного времени ушло на дорожные карты roadmap.sh, так что в этот раз выпуск инфопузыря вышел очень коротким. ⭐️ Видео AI workflow для разработчика: как перестать получать мусор от нейросети и писать нормальный код — обзор нововведений в AI Factory от Данила Шуцкого, но большую часть ролика занимают рассуждения Данилы о выработке шаблонов взаимодействия с LLM и в целом об организации процесса работы с LLM. Локальный LLM на вашем компьютере на примере LM Studio — доклад Сергея Кузнецова о личном опыте использования локальных LLM и мультиагентных систем. Доклад был представлен в рамках конференции Podlodka AI Crew #1. ⭐️ Источники Тимур Хахалев про AI Coding — телеграм-канал про агентскую разработку. Подписчиков много, Тимур также продаёт свои курсы и консультации, но контент канала на первый взгляд интересный и полезный.

🌿 Про клиентов для работы с большими языковыми моделями Экосистема для работы с LLM очень активно развивается, в том числе появляется множество инструментов для взаимодействия с LLM в формате чата. Авторы моделей делают своих клиентов (Claude Code, Claude Desktop Gemini CLI, Codex CLI). Создаются независимые решения, например, OpenCode или Dive. Помимо отдельных приложений создаются плагины для IDE (IDEA, VS Code) или новые IDE (Codex, Antigravity и др.). И везде реализуется аналогичный функционал: • встроенные инструменты; • навыки; • режимы работы. Какой-то стандартизации здесь не наблюдается и каждый делает как ему хочется 🤷‍♂️ Но если разобраться, то эти вещи избыточны, точнее они не должны быть отдельными сущностями, а должны настраиваться в приложении поверх MCP-серверов. MCP — протокол, описывающий взаимодействие LLM-клиентов с внешними инструментами и источниками данных. В частности, MCP-сервер предоставляет инструменты, промпты и ресурсы. ❓ Зачем каждый реализовывает свои инструменты для работы с файловой системой или GIT, если можно подключить MCP-сервер, который это всё предоставит? ❓ Зачем придумывать свой функционал навыков, если можно получать промпты и ресурсы из MCP-сервера? ❓ Зачем делать встроенные режимы работы, если можно реализовать их через набор инструментов, промптов и ресурсов MCP-сервера? LLM-клиенты должны предоставлять удобный интерфейс и иметь максимально гибкую настройку MCP-серверов. Никаких встроенных промптов/инструментов/навыков и подобных вещей. Процесс взаимодействия с моделью должен быть полностью под контролем пользователя 😎