Сори, мысли вслух. Наконец-то я на-ходил себе агента, который готовит дайджест статей, и хочу поделиться этим опытом — вдруг кому-то будет интересно. До этого я использовал LLM в основном для работы с уже готовыми проектами: генерация кода, дополнения, рефакторинг. А вот чтобы он с нуля создавал проект целиком — как-то не доходили руки попробовать. Кстати, если есть пожелания по формату или контенту этого дайджеста — дайте знать, пожалуйста. Во-первых, как в целом у меня готовится дайджест. В течение недели я просматриваю разные источники (Twitter, Medium, Substack и довольно большое количество RSS-подписок). Всё, что кажется интересным, сохраняю в Raindrop. Раз в неделю я разбираю всё, что там накопилось, и просматриваю каждую статью. Какие-то удаляю, потому что заголовок был интереснее, чем сама статья. Какие-то — потому что тратить на них время уже не хочется, хотя изначально казалось иначе. Остальные раскидываю на «прочитать и изучить» и «включить в дайджест» — на последние вешается отдельный tag. Итак я взял Cursor и ввёл довольно небольшой prompt для создания агента. Что-то вроде: «Сделай агента на LangGraph, который по заданному tag получает список статей из Raindrop, дальше прогоняет их через LLM с определённым промптом, чистит ссылки от UTM и формирует список в заданном формате. И чтобы всё это работало и отслеживалось в Docker Desktop». На удивление, он довольно быстро накатал всё, что нужно: вменяемую структуру проекта, Docker-образы и даже конфиги для Cursor для запуска и отладки в Docker (хотя, если честно, отлаживать локально потом всё равно оказалось проще). Дальше я внимательно изучил весь код и начал задавать вопросы по тем подходам, которые были неочевидны. В одном месте он довольно хитро применил фабричную функцию с замыканием — редко встречал такое в своей практике, но выглядит прикольно. Самого агента он сделал хорошо: аккуратно описал стейты и шаги от получения данных из внешнего сервиса до вывода результата в консоль. Но пришлось дотачивать напильником функцию получения списка статей из Raindrop. Там настолько странная схема, что я когда-то нашёл её на форумах, и строка запроса для получения статей по tag у меня уже была сохранена в других исходниках. Пока я прямо не попросил агента сделать «вот так», он не смог побороть Raindrop — потому что всё, что у них написано в документации, по факту не работает 🙂 Зато авторизацию в Raindrop он сделал хорошо. Там хитрая логика: по secret_key нужно получать токен через call_back вызов со стороны сервиса, и он живёт 14 дней. Про 14 дней он знал, но пришлось отдельно попросить добавить проверку, что токен всё ещё валиден. Отдельный забавный момент: он ни в какую не имел представления о том, что у OpenAI через API доступна модель GPT-5.2, и настойчиво предлагал использовать 4.1. Очень понравилось, как он написал README.md — всё чётко объяснил: что создано, как это запускать и как оно работает, хотя я этого изначально не просил. А вот с комментариями в коде не очень: их было мало. Какие выводы для себя: — по времени всё не так однозначно: изучение, проверка и отладка кода заняли довольно много времени. Не факт, что писать самому было бы сильно дольше, но когда пишешь — сразу лучше понимаешь, что происходит; — всякие мелочи вроде названий переменных и форматирования вывода проще всё-таки потом руками поправить; — зато он создал неплохую структуру кода и проекта — хороший, грамотный «скелет», который дальше уже можно спокойно развивать; — и в целом всё заработало с первого раза: никаких критичных runtime-проблем после генерации не было (кроме, как обычно, Raindrop API).