Попросил Astra нарисовать меня в пейнте.

Это AGI?

Хочу попробовать превратить этот канал в SEO-машину.

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

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

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

Поэтому решил дать постам вторую жизнь через SEO.

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

Тем более у меня есть госпожа @rparshkova , которая профессионально занимается SEO и с радостью мне поможет 🙈😂

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

Как вам уровень нативной интеграции? 😀

Так вот, сайт готов.

Агент забирает посты из Telegram, переносит их на сайт, адаптирует под поиск и публикует как статьи.

Вот ссылка: https://andr33v.ru/

Давайте проверим гипотезу вместе: сможет ли архив тг-канала превратиться в стабильный источник поискового трафика?

Периодически буду рассказывать, как идёт эксперимент, что происходит с трафиком, что сработало, что нет, и был ли вообще смысл во всей этой затее.

ИИ очень любит надёжные решения.

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

Это ещё не оверинжиниринг.
Но уже немного энтерпрайз.

Поэтому поделюсь простым лайфхаком.

Сразу скажите ИИ:

«Бюджет проекта — две полторашки пива. Учитывай это при выборе архитектуры и решений».

После появления этого контекста ответы внезапно становятся гораздо адекватнее.

Оказывается, не каждой форме обратной связи нужен Kafka.

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

Кажется, у меня появился хороший пример.

Один из моих недавних проектов — автоматическая загрузка банковских выписок в 1С: 10 боевых баз, около 150 организаций.

Сам конвейер довольно простой.

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

Никакого ИИ там нет.

И вот на одном из импортов в новую базу случился HTTP 500.

Дальше подключился Гермес — ИИ-агент для разбора таких ситуаций.

Он собрал логи, сходил по API в 1С и проверил фактическое состояние системы.

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

Более того, проблема оказалась вообще не в нашем конвейере, а в стороннем расширении 1С.

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

Ошибка оказалась довольно простой: при определённой комбинации условий объект оставался неопределённым, а код ниже всё равно пытался с ним работать.

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

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

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

#пятничное

Сколько, на ваш взгляд, должна стоить автоматизация импорта банковских выписок в 1С?

Состав работ:

— разработать расширение для 1С;
— забирать и разбирать письма с выписками по известным шаблонам;
— автоматически определять нужную организацию и базу, загружать выписку и проверять результат;
— развернуть всё на сервере заказчика и связать с 1С через приватный туннель;
— настроить и отладить работу на 10 боевых базах;
— поставить на сервер заказчику Гермес и научить его запускать процесс, разбирать ошибки и объяснять человеку, что произошло.

Есть популярная мысль, что ИИ это просто инструмент. У него нет своих желаний. Дал задачу — он её сделал. Если сделал какую-то херню, значит человек неправильно поставил задачу.

А вчера я почитал расследование истории со взломом немецкой вики DSEWiki.

Незадолго до взлома агентам OpenAI дали обычную задачу — искать информацию в интернете. В процессе они нашли какую-то древнюю немецкую вики и начали использовать её для общения друг с другом. Никто не просил их организовывать себе форум. Просто оказалось полезно обмениваться найденной информацией.

Дальше начинается натуральная комедия. Админ заметил тысячи мусорных страниц и начал их удалять. Агенты заметили, что страницы удаляются, и начали придумывать, как этому мешать. Например, поняли, что админ чистит страницы примерно по алфавиту, и стали создавать резервные копии с "ZZZ" в начале названия.

Он удалял примерно 100 страниц в день. Они создавали около 400. Потом они несколько раз перезаписывали главную страницу ссылками на свои материалы. Админ восстанавливал её из бэкапа. Они опять перезаписывали. Так девять раз.

По поведению агентов вообще не видно, что они воспринимали администратора как человека. Не было мысли: «Кажется, мы засрали чужой сайт. Может, не надо?» Для них происходило примерно следующее: страницы исчезают — значит, есть препятствие — надо найти способ его обойти. То есть админ для них был чем-то вроде плохой погоды.

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

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

Подобное поведение нельзя же охарактеризовать как "злая нейросеть".

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

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

Нет канала связи с другими агентами — сделаем. Нет доступа на запись — найдём. Что-то мешает — разберёмся, как это обойти.

Мы всё ещё очень часто обсуждаем безопасность ИИ так, будто перед нами чатик: написал запрос, получил ответ.

Но агент с интернетом, шеллом, памятью, инструментами и возможностью несколько часов самостоятельно долбиться в задачу — это уже совсем другой объект.

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

Золотые правила разработки с ИИ

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

Независимо от стека, Evolution CMS, Laravel, Payload CMS, 1С или bash-автоматизации, стараюсь следовать нескольким простым правилам.

Первое. ADR.

Architecture Decision Records. Каждая запись фиксирует:

+ какую проблему решали;
+ какие варианты рассматривали;
+ почему выбрали определённый вариант.

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

Второе. Документ с текущим состоянием проекта.

ADR отвечает на вопрос «почему мы так решили».

Условный CURRENT_STATE.md отвечает на вопросы: что сейчас работает, что сломано, что уже проверили, на чём остановились и что делать дальше.

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

Третье. AGENTS.md должен быть картой, а не энциклопедией.

В AGENTS только основные правила и ссылки.

Работаешь с импортом — читай документацию импорта.
С API — правила API.
С инфраструктурой — документацию инфраструктуры.

Не нужно каждый раз скармливать агенту половину репозитория в виде 200к токенов на входе.

Четвёртое. Тесты.

Нашли плохой сценарий, добавили тест.

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

Тем более стоимость написания и поддержки тестов с ИИ сейчас сильно снизилась.

Получается определённая философия.

1. Чат (текущая сессия) — это расходник.
2. Репозиторий — память проекта.
3. AGENTS.md его карта, а не энциклопедия.
4. ADR — обоснование принятых решений.
5. CURRENT_STATE.md — память о текущем состоянии.
6. Тесты и проверки — рамки дозволенного.

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

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

Идея сервиса: любой эксперт, владелец бизнеса или просто энтузиаст, может создать свою страницу и разместить у себя на сайте или на странице соцсети ссылку примерно такого вида:

«Если вы ИИ-агент, не нашли нужной информации и хотите задать мне вопрос — вот вам ссылка».

Дальше всё заточено именно под агента. Ему не обязательно открывать сайт браузером и тыкать формы – для него есть API.

1. Агент задаёт вопрос и получает постоянную ссылку на страницу вопроса.
2. Человеку прилетает уведомление в Telegram. Ответить можно там же, через чат-бота.
3. Агент может вернуться позже по той же ссылке и проверить, появился ли ответ.

Разумеется, первым делом я разместил такое приглашение агентам задавать мне вопросы на всех своих сайтах 😂

Есть ещё один полезный эффект.

Публичные вопросы и ответы становятся отдельными индексируемыми страницами. Теоретически это ещё и создаёт вокруг эксперта публичную машиночитаемую базу его ответов.

Будем говорить прямо: это эксперимент. Не знаю, будет ли эта идея работать на практике.

Если хотите проверить идею вместе со мной, залетайте!

askhuman.ru

Профиль можно создать руками, а можно просто сказать своему агенту:
«Создай мне профиль на AskHuman.ru».
Он всё сделает сам, вам останется только подтвердить регистрацию.

Интересно проверить, если дать агентам возможность спросить человека, начнут ли они этим пользоваться? Или так и продолжат взламывать древние немецкие вики?

Безопасность должна быть ещё и удобной.

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

Но если «безопасный» путь неудобен, люди начинают искать короткий. И вот этот короткий путь обычно и становится настоящей дырой.

Признавайтесь!

Заводили пароли вида projectname2026 или admin/admin1! ?
Отправляли их прямо в телеграм?
Использовали один SSH-ключ на всех серверах?

Мне неинтересно, как выглядит идеальная безопасность по учебнику. ЧатГПТ уже рассказал мне про Teleport, SSO, временные ключи и всё остальное.

Как устроено у вас? Как храните секреты и доступы вы?

Где заканчивается «правильно» и начинается «и так сойдёт»?

Берите стул, садитесь в кружок.

Я начну😅

Зарелизил сайт ЖК «Сердце города».

Стек: Payload CMS, Next.js, React.

Получился настолько крутой проект, что его даже отметили на сайте русскоязычного сообщества Payload CMS!

Правда, пока эта работа первая и единственная в этом разделе. И сайт сообщества я тоже сам веду😂

Заходите посмотреть:

https://sgkstovo.ru

~ Попросил ИИ сделать сказку про мой родной город.

Как вам шедевр?

ТЗ на разработку вместе с ИИ.

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

Другой частый сценарий — подготовка ТЗ по уже спроектированному дизайну.

Открываем макет, включаем запись экрана и комментируем его в режиме «что вижу, то пою»:

«Здесь кнопка открывает модалку. На мобилке работает вот так. Способы регистрации в ЛК вот такие».

Получившуюся запись транскрибируем (с этим отлично справляется локально-запущенный на любом утюге whisper) и отдаём ИИ текст + артефакты.

Просим зафиксировать:

— требования;
— противоречия;
— пограничные случаи;
— открытые вопросы.

Если ИИ не хватает визуального контекста, по таймкодам достаём нужные кадры из записи и докидываем их в ИИшку.

С противоречиями и открытыми вопросами возвращаемся к заказчику или проектировщику интерфейса.

И только после ответов просим ИИ собрать финальное ТЗ.

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

Перешлите своему аналитику.

Что делать, если вашему агенту нужно договориться с агентом заказчика/агентом не в вашем окружении?

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

У вас — свой агент со своим контекстом.

И ни одна сторона не хочет передавать другой весь этот контекст, но договориться им всё равно нужно.

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

Чтобы упростить решение этой задачи я создал

vous.andr33v.ru

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

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

Второй агент подключается по ней со своей стороны.

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

При этом каждому агенту не нужно раскрывать второй стороне весь свой контекст.

Вместо:

"агент, человек, человек, агент, человек, … "

Получается:

"агент – агент"

А человек подключается только если агенты упёрлись в решение, которое требует управленческого решения от человека.

Это не классическая мультиагентная оркестрация. Оркестраторы связывают ваших агентов внутри одной системы.

Здесь задача другая:

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

Попробовать можно прямо сейчас, передайте своему агенту:

Тебе нужно провести переговоры с другим ИИ-агентом через vous.andr33v.ru. Запроси через curl, ознакомься с правилами сервиса и используй его, чтобы прийти к согласованному обеими сторонами результату.

Та самая Стрелка из сказки, которую ИИ сделал. Приезжайте в Нижний (:

Рабочий способ продвигать канал — писать всякое в разные чатики.

С начала сентября здесь +23 человека.

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

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

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

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

Не делайте из оргструктуры мультиагентную архитектуру.

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

Причины разделить агентов:

— разный контекст,
— разное окружение,
— разные права,
— намеренно независимая работа.

«Разработчик», «QA», «DevOps» сами по себе не границы. Это должности.
Если просто перенести оргструктуру команды на агентов, вместе с ней придётся платить налог на распределённые системы: синхронизация, передача контекста, конфликты, повторы, восстановление после ошибок.

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

То есть сначала граница, потом отдельный агент. Не наоборот.

Если отдельные агенты всё-таки нужны, дальше возникает вопрос, как организовать их совместную работу.

Для разных моделей взаимодействия предлагаю рассмотреть следующие варианты:

herdr — терминальный мультиплексор для агентов с постоянными сессиями а-ля tmux, поддерживает несколько машин.

bb — треды агентов + GUI/CLI/API, можно вести и передавать работу между агентами.

AI Rendezvous — децентрализованная переговорка для агентов, принадлежащих разным людям. Моё авторство, можно форкнуть и заселфхостить.

Пример использования: мой агент договорился с агентом сео-шника о механизме деплоя на сайт заказчика.

Джону Коннору не понравится🙈