Дневник разработчика | ИИ-завод блогеров

Что будет, если ИИ выполнит одну задачу дважды?

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

Каждую часть можно проверить отдельно и получить хороший результат. Но дальше возникает вопрос: правильно ли они передают работу друг другу?

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

Что произошло? Текст мог потеряться по дороге. А мог успешно дойти — потерялся только ответ о приёме.

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

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

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

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

Главная сложность здесь — проверить весь путь между сервисами. Успешная проверка отдельной функции ещё не доказывает, что вся цепочка работает правильно.

Эту часть разработки я пока не объявляю завершённой. Продолжаю проверять, исправлять и собирать подтверждения результата.

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

Пока я занят, ИИ продолжает работу. Что я готов ему доверить?

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

Такую идею OpenAI развивает в Dots. Этих ИИ-помощников представили 29 сентября. Они могут продолжать порученную работу между разговорами.

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

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

Но разрешение подготовить текст ещё не означает разрешение опубликовать его от моего имени.

Это как с обычным помощником: собрать документы для покупки и оплатить покупку — разные поручения.

В описании Dots есть важная деталь. Самостоятельный фоновый поиск ограничен чтением. Для действий, которые что-то меняют, предусмотрены правила доступа и проверки. При этом OpenAI прямо предупреждает: ошибки возможны, важную работу нужно проверять.

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

Я сейчас рассматриваю возможное применение этого подхода. Готовое подключение Dots к заводу не заявляю.

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

ChatGPT научился отвечать интерфейсом. Зачем мне это?

7 октября OpenAI представила GPT‑6 с Intelligent UI. Ответ может включать кнопки, формы, графики и инструменты, с которыми можно взаимодействовать прямо в разговоре.

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

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

Но я бы не оценивал обновление по красоте карточек. У меня три вопроса: понятны ли исходные данные, правильно ли считается результат и действительно ли этот экран экономит время?

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

Я разрабатываю «Завод блогеров» и смотрю на такие новости через практические задачи. Мне интересен интерфейс, в котором я могу сравнить варианты и понять последствия своего решения. Это идея для оценки, а не заявление о внедрении новой функции в проект.

Я бы начал с небольшого примера с известным ответом. Поменял исходные данные, проверил результат и посмотрел, удобно ли этим пользоваться с телефона.

Если такая проверка проходит, появляется причина пользоваться инструментом дальше. А бесконечно любоваться кнопками я и без ИИ умею.

Осталось пять настроек. Почему я не нажимаю «включить»

Я продолжаю делать Blogger Factory — сеть AI-блогеров. Сейчас я готовлю следующий production-шаг, и технически уже понятно, какие пять настроек нужно изменить.

Казалось бы, осталось пять значений. Поправить и поехали.

Но система уже живёт своей жизнью. Планировщик может создать новую задачу. Worker — уже обрабатывать предыдущую. API — принять запрос. Соседние сервисы — продолжать работу в shadow-режиме.

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

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

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

Проверил rollback — возврат назад. Отдельно убедился, что инструмент не запускает миграции, не меняет worker/beat и не может сам подключиться к production.

Потом было независимое review. В первой версии нашлись ошибки. Я их исправил и на повторной проверке получил PASS.

И всё равно я пока не нажимаю «включить».

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

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

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

Пять настроек. А вокруг них уже целый план.

Из таких скучных на первый взгляд вещей и складывается настоящий production AI.

Почему Google перестал принимать часть отчётов об уязвимостях?

С 1 октября 2026 Google приостановил приём новых продуктовых уязвимостей в OSS VRP — программе вознаграждений за находки в открытом коде. Решение не закрывает все программы Google.

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

19 марта Google отдельно описывал проблему некачественных ИИ-отчётов, в том числе с выдуманными деталями. Этот мартовский материал даёт контекст, но не доказывает, что каждую октябрьскую автоматическую заявку написал ИИ.

Представим обычную рабочую ситуацию. Модель просмотрела код и написала: «Найдена уязвимость». Текст подробный, выглядит уверенно. Автор переслал его разработчику.

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

Это мой пример, а не сообщение о конкретном случае в Google.

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

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

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

Для «Завода блогеров» мне близок именно этот вопрос: насколько легко проверить результат агента следующему участнику процесса. Иначе можно автоматизировать создание задач, а разбор оставить человеку.

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

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

ИИ советует, куда отправить сотрудников. Вы бы его послушали?

5 октября Logistics Reply представила пять новых агентов для работы склада. Меня заинтересовал Labor Distribution Agent: по описанию компании, он выявляет узкие места и рекомендует перераспределять сотрудников.

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

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

Это мой пример, а не сообщение о сбое продукта.

Logistics Reply предлагает задавать полномочия отдельно для каждой задачи: от предоставления информации и рекомендаций до действий в установленных границах. У одного агента может быть право советовать, у другого — выполнять определённую операцию.

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

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

На «Заводе блогеров» мне близка сама задача разграничения полномочий: что агент предлагает и какие действия ему действительно разрешены. Важно продумать это до запуска.

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

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

ИИ пишет код. Зачем Anthropic выделяет $100 млн на обучение инженеров?

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

2 октября Anthropic объявила о Claude Frontier Academy. Цель — обучить 10 тысяч инженеров до конца 2027 года, на программу выделяют $100 млн.

По описанию программы, участники сначала проходят практический интенсив, затем 12 недель внедряют Claude в своей организации с поддержкой наставников. В конце — оценка результата. На старте участников выдвигают компании.

Мне близок акцент на практике. Хороший ответ модели ещё нужно превратить в систему, которой смогут пользоваться другие.

Представим помощника для поддержки. Он написал убедительный ответ клиенту. Теперь вопросы: из каких данных он это взял? Имеет ли право видеть переписку? Может ли отправить ответ сам? Что произойдёт, если он ошибётся или сервис перестанет отвечать?

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

На «Заводе блогеров» я тоже думаю обо всём процессе: что поручить агенту, как проверить результат и где оставить решение за человеком. Новости про обучение инженеров интересно читать именно с этой стороны.

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

Что вам сейчас даётся тяжелее: объяснить ИИ задачу, проверить его ответ или встроить решение в свою работу?

ChatGPT готовит новый формат рекламы. Что будет с доверием?

OpenAI объявила о новом визуальном формате рекламы. Его начнут тестировать в октябре в США, при генерации изображений. Объявление обещают отделить от картинки, ответы — сохранить независимыми от рекламы.

Меня здесь больше интересует доверие к помощнику.

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

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

Я бы смотрел на три вещи. Видна ли пометка сразу? Не перекрывает ли объявление работу? Можно ли спокойно закончить задачу, не отвлекаясь на предложение?

Пока это мои вопросы к будущему тесту. Новый формат я не пробовал и выводы о его удобстве делать рано.

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

У рекламодателя свой вопрос: сработала ли реклама? У меня как у пользователя — помог ли сервис закончить дело? Хочу, чтобы второй вопрос не потерялся за первым.

Вы бы спокойно работали с ИИ, если рядом показывают рекламу?

Четыре мини-завода и Harness: мой сентябрь на «Заводе блогеров»

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

• Персонажей — создаёт и настраивает блогеров.
• Аналитики — изучает статистику и готовит рекомендации.
• SMM — превращает рекомендации в планы публикаций.
• Контента — готовит материалы по этим планам.

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

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

Техническая основа проекта — Python, FastAPI, PostgreSQL, Redis, Celery, Docker, Caddy и n8n. Для ИИ использую OpenAI и YandexGPT, добавил поддержку GigaChat.

Ещё одно изменение — переход с GitHub на локальную Gitea. Лимитов GitHub мне перестало хватать. Поэтому я купил отдельный SSD, организовал локальное хранение кода и дополнительную копию проекта.

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

Из последних работ, уже в начале октября: проверял остановку и восстановление сервисов. Нашёл проблему в файлах восстановления. Работу основных сервисов восстановил, запуск планировщика проверил. Само новое исправление пока не установил.

Дальше планирую разобраться с этой проблемой и продолжить проверку связки «аналитика → SMM → контент».

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

ИИ сказал «готово». А что изменилось на самом деле?

Мне стало интересно, насколько легко принять уверенный ответ агента за выполненную работу.

3 октября Microsoft и Hugging Face рассказали о ThinkingBox. Это среда, в которой проверяют, что осталось после действий ИИ: какие записи изменились, появился ли нужный результат и не случилось ли лишнего.

В публикации есть показательный тестовый сценарий. У клиента задержалась доставка. Агент посмотрел заказ, проверил информацию и создал обращение. А затем закрыл его как решённое, хотя проблема с доставкой оставалась открытой. По условиям задания обращение должно было остаться в ожидании решения.

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

Меня здесь зацепило, что проверять нужно именно нужный результат. Запись в системе появилась? Хорошо. Но правильная ли это запись, с нужным ли статусом, соответствует ли она задаче?

Для «Завода блогеров» я бы объяснил это на публикации. Сообщение «пост отправлен» полезно, но мне нужен сам пост на нужной площадке. Это уже понятный результат, который можно увидеть.

В ThinkingBox-Bench авторы проверяли 507 сценариев, повторяя каждый по 20 раз для разных моделей. Это позволяет отдельно увидеть, может ли агент справиться хотя бы однажды и насколько стабильно он справляется. Результаты относятся к этим тестовым задачам, а не ко всей работе ИИ.

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

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

Какую задачу вы бы поручили ИИ, если бы могли сразу увидеть и проверить её результат?