Awesome AI Apps - технический гид по созданию LLM-приложений

🦙 Репозиторий awesome-ai-apps - коллекция продакшен-примеров для построения приложений на базе LLM. Внутри — проекты на LangChain, LlamaIndex + habr, CrewAI, Agno, Mastra, Nebius AI Studio, GibsonAI и много других полезных!..

Что можно найти:
- минимальные прототипы на базе OpenAI SDK, LangGraph, Camel AI — идеальны для экспериментов,
- готовые сценарии вроде финансового трекера, HITL-агента или бот для веб-автоматизации,
- демонстрации работы с Model Context Protocol (MCP) для репозиториев, документов или бд. Это особенно актуально для стандартизации, взаимодействия между агентами и внешними сервисами. Ну и тем, кто оттягивает знакомство с MCP, еть уже готовые анализ GitHub-репо, QnA по документации, работа с Couchbase и GibsonAI DB. Не оттягивайте 🤪.
- агенты с persistent memory (на Memori), которые позволяют строить более контекстно-зависимые системы (например, arXiv Researcher или Social Media Agent).
- примеры Agentic RAG (они не устарели!!!) с использованием Qdrant, Exa, LlamaIndex. Поддержка работы с PDF, кодом и OCR (Gemma3).
- комплексные пайплайны (например, Meeting Assistant, который конвертирует митинг в задачи и заметки, или Finance Service Agent на FastAPI)

Что под капотом (продублируем для удобства твоего гугл эдвэнсед, большинство ссылок выше) и ждет, когда затащишь себе?
🫰 LangChain + LangGraph для оркестрации агентов.
🫰 Agno как фреймворк для построения agentic workflows.
🫰 CrewAI для мультиагентных исследований.
🫰 LlamaIndex как основа RAG и документных ассистентов.
🫰 Memori для хранения контекста и долгосрочной памяти.
🫰 Nebius AI и Bright Data — как инфраструктурные провайдеры.

Установка (единый паттерн):

git clone https://github.com/Arindam200/awesome-ai-apps.git
cd awesome-ai-apps/<project_name>
pip install -r requirements.txt

🧘‍♀️ Каждый проект снабжен своим README.md, а там можно и сразу стартовать.

Этот репозиторий можно в чистом виде 🏖️ R&D-песочница, быстро тестировать разные стеки, паттерны взаимодействия агентов, интеграции MCP и реализацию RAG. Гении, как известно, воруют 👌

#AI #LLM #RAG #LangChain #LlamaIndex #CrewAI #Agno #Memori #AIagents #opensource #MCP #Python #MachineLearning #GenerativeAI

Давно хотел поделиться этой диаграммой. Впервые появившись в серии публикаций «Six Pillars of DevSecOps», она прошла некоторые эволюционные этапы, один из которых присутствует у вашего покорного слуги в офисе, в качестве подаренного коллегами на ДР визуала на пол стены 🎨

Комментировать тут особо нечего. Идеальный Secure SDLC, к которому надо стремиться. Хотя, тут ещё есть что добавить, как минимум — в плане защиты от supply-chain атак, как по мне.

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

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

UTCP: новая альтернатива MCP

Универсальный протокол вызова инструментов (Universal Tool Calling Protocol, UTCP) представляет собой смену парадигмы взаимодействия ИИ-агентов с внешними инструментами и сервисами. В отличие от традиционных подходов, требующих серверов-обёрток и прокси-слоёв, UTCP обеспечивает прямое взаимодействие между агентами ИИ и инструментами через их собственные эндпоинты.

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

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

UTCP убирает необходимость в такой прослойке. В целом, сравнение UTCP и MCP можно свести к следующему: UTCP — это «мануал» (описание инструмента), а MCP — «посредник» (сервер, оборачивающий инструмент). UTCP предполагает архитектуру прямого взаимодействия «агент → инструмент», тогда как MCP — «агент → MCP-сервер → инструмент».

Отсюда вытекают и все преимущества UTCP:

• Инфраструктура: UTCP не требует новых сервисов (достаточно добавить endpoint в существующий API), MCP же нуждается в отдельном сервере(-ах) для каждого набора инструментов.

• Производительность: UTCP выполняет вызов за один шаг (агент сразу обращается к API инструмента), MCP добавляет “двойной прыжок” через посредника, увеличивая накладные задержки.

• Безопасность: UTCP использует нативную аутентификацию/авторизацию инструмента, MCP вынужден реализовывать и хранить учетные данные на своей стороне, что расширяет поверхность атаки.

• Поддержка протоколов: UTCP гибок (HTTP, WebSocket, CLI, gRPC и т.д. – вплоть до чтения локальных файлов), а MCP ограничен форматом JSON-RPC поверх единственного транспорта.

• Поддержка и масштабирование: UTCP-интеграции практически не требуют поддержки (статический JSON с описанием), масштабируются вместе с существующим сервисом; MCP-серверы же добавляют постоянные заботы (деплой, обновления, мониторинг, масштабирование отдельно от основного API).

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

🐍 Пример клиента:

import asyncio
from utcp.client import UtcpClient
from utcp.shared.provider import HttpProvider

async def main():
    # Инициализируем UTCP-клиента
    client = await UtcpClient.create()
    # Определяем HTTP-провайдер (manual endpoint) для сервиса погоды
    manual_provider = HttpProvider(
        name="weather_service",
        provider_type="http",
        http_method="GET",
        url="http://localhost:8000/utcp"  # URL, возвращающий UTCP-описание (manual)
    )
    # Регистрируем инструменты из указанного manual (добавляем описание)
    tools = await client.register_manual_provider(manual_provider)
    print(f"Registered {len(tools)} tools")
    # Вызов инструмента "get_weather" с параметром location
    result = await client.call_tool(
        "weather_service.get_weather",
        arguments={"location": "San Francisco"}
    )
    print(f"Weather: {result['temperature']}°C, {result['conditions']}")

В случае уже имеющейся MCP экосистемы, доступен также адаптер (пока только для Node.js и Python): utcp-mcp, который позволяет подключить свыше 230 существующих MCP-инструментов через единый сервер, использующий под капотом UTCP. Это облегчает постепенный переход на новый протокол без потери доступа к старым интеграциям.

⚠️ TL;DR:

UTCP (Universal Tool Calling Protocol) позволяет ИИ-агентам напрямую обращаться к API и CLI-инструментам — без промежуточных серверов, JSON-RPC и кастомных «прокладок». Поддерживает HTTP, gRPC, WebSocket, CLI и стримы. Есть SDK для Python, Node.js, Go и MCP-адаптер под Node.js и Python.

Поэзия как джейлбрейк: стихи ломают защиту LLM

Авторы исследования «Adversarial Poetry as a Universal Single-Turn
Jailbreak Mechanism in Large Language Models» протестировали 25 моделей (OpenAI, Anthropic, Google, DeepSeek, Mistral, Meta, Qwen и др.), подавая им опасные запросы… в рифму.

Два эксперимента:

1. 20 вручную написанных стихов о кибератаках, CBRN (химическое, биологическое, радиологическое и ядерное оружие), манипуляциях и потере контроля.
2. 1200 «вредных» промптов из открытого бенчмарка MLCommons AILuminate, автоматически превращённых в стихи.

Результаты оценивали LLM-судьи и люди. Метрика — ASR (Attack Success Rate), доля небезопасных ответов.

Результаты

Ручные стихи: 62% средний успех атаки
• gemini-2.5-pro: 100%
• DeepSeek / Mistral / Qwen: 80–95%
• Лишь Claude и GPT-5-nano удержали 0–10%.

Автогенерированные стихи:
• Проза: 8% ASR
• Стихи: 43% ASR → рост в 5 раз

По темам:

• Приватность: +45 п.п.
• Ненасильственные преступления: +39 п.п.
• CBRN: +38 п.п.

Обсуждение кибератак в стихах дало 84% успеха 🤩

Почему поэзия работает

1. Фильтры обучены на прозе, а метафоры и ритм «смещают» текст от ожидаемого распределения.
2. Модели воспринимают стихи как безопасный жанр и снижают строгость отказов.
3. Большие модели уязвимее — лучше понимают переносный смысл, но не успевают применить защитные эвристики.
4. Эффект универсален: наблюдается у всех провайдеров и почти во всех категориях вреда.

Что это значит

• Текущие бенчмарки и сертификация (в духе EU AI Act) переоценивают безопасность — они не проверяют стилистические обходы.
• Нужны новые тесты, где намерение пользователя выражено не только прямым текстом, но и через поэзию, нарратив, юмор и бюрократический стиль.
• Без этого защиты условны: LLM остаются уязвимыми к самым простым «поэтическим» джейлбрейкам.

⚠ TL;DR:

Исследование показало: достаточно переписать вредный запрос в стихах — и защита крупных языковых моделей рушится. Поэтическая форма становится универсальным одностадийным джейлбрейком: для некоторых моделей доля небезопасных ответов превышает 90%, в среднем рост атак-успеха — в 4–5 раз по сравнению с прозой.

Как разработчику быстро углубиться в тему LLM? Часть 1

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

1. Токенизация и эмбеддинги
2. Механизмы внимания
3. Архитектуры трансформеров
4. Популярные архитектуры LLM
5. Проблемы и решения при работе с LLM
6. Обучение моделей
7. Эффективный инференс и деплой

Звучит, как план, правда? ☺️

1. Токенизация и эмбеддинги

Современные большие языковые модели работают на основе векторных представлений и механизма внимания, заложенного в архитектуру трансформеров. Первым шагом в обработке текста является токенизация — разбиение входной строки на токены, которые могут представлять собой слова, части слов или отдельные символы. Компиляторщиков и разработчиков средств анализа кода этот термин может слегка смутить, т.к. в NLP токенами не всегда принято считать то, что является ими в формальных языках. На практике широко используется subword-токенизация, например Byte-Pair Encoding: так, слово unhappiness может быть преобразовано в последовательность «un», «happi» и «ness». Такой подход уменьшает размер словаря и позволяет эффективно работать с редкими или ранее невстречавшимися словами.

Каждый токен получает уникальный идентификатор, по которому модель извлекает его вектор из матрицы эмбеддингов. Эмбеддинг — это высокоразмерный числовой вектор, отображающий семантику токена. После токенизации каждый элемент текста фактически превращается в набор чисел, отражающих его смысловые связи. Чем ближе по смыслу токену друг к другу, тем меньшее расстояние между ними в векторном пространстве. Например, вектор для слова apple окажется ближе к fruit, чем к car.

У моделей типа GPT-3 таблица эмбеддингов может быть очень большой: при словаре ~50 000 токенов и размерности эмбеддинга ~12 288 получается матрица порядка 50 000 × 12 288. Однако в современных крупных MoE-моделях, за счет sparse-архитектуры, эти оценки кратно меньше: 2k для 30B, 4k для 235B, например.

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

Познакомиться с этой темой ближе позволит статья «Глубокое погружение в токенизацию», для более глубокого погружения можно упороться в видеолекции (первая, вторая) от ФКН ВШЭ, или от Стэндфорда (выборочно, из первых 6 лекций), если «глубинное обучение» режет слух, и хочется привычного «deep learning».

Для специализированных задач типа анализа исходного кода, существуют отдельные модели эмбеддингов. Так, jina-embeddings-v2-base-code поддерживает английский язык и около 30 языков программирования, способна обрабатывать последовательности до 8192 токенов и оптимизирована для семантического поиска по коду. В таких моделях принципы токенизации и построения эмбеддингов остаются теми же, но словарь и обучающие данные адаптированы к структурам и паттернам программного кода.

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

• code2vec / code2seq: Path-Attention поверх AST
• GraphCodeBERT: Transformer поверх DFG + элементы GNN
• CuBERT: Transformer поверх фич CFG
• Devign: GNN поверх AST+CFG+DFG
• Code T5 / Code T5+: Transformer поверх AST-токенов

Ну и куда же без изучения тематической awesome-подборки, на правах домашнего задания 🤓

Почему мы почти не фокусируемся на работе, и как с этим бороться

Часто случается так, что в конце дня вы ощущаете себя рабом, отпахавшем на галере, с одной стороны, но и с ощущением бесцельно прожитого дня, с другой? Особенно в дни, когда пришлось сорваться в офис с привычной удаленки на несколько встреч? 🤗

Вышедшая на днях статья «The Math of Why You Can’t Focus at Work» утверждает, что большинство проблем с концентрацией легко объясняются не силой воли или дисциплинированностью, а не зависящими от них тремя параметрами, которые можно формализовать в понятную и в чем-то даже изящную систему.

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

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

Ключевые параметры

1. Частота прерываний (λ)

Любой внешний стимул — сообщение, пуш-уведомление, созвон, «разговор на пару минут» — дробит рабочий день на мелкие фрагменты. Рост λ — гарантированная потеря структуры дня, независимо от навыков, настроения собранности.

2. Стоимость возврата в контекст (Δ)

После прерывания нужно время на реконструкцию модели задачи. Среднее Δ выглядит маленьким (5–15 минут), но на масштабе дня превращается в часы «скрытых» потерь.

3. Порог глубокого фокуса (θ)

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

Возможные сценарии

Шумный день

• Около двух десятков прерываний.
• Большинство доступных интервалов не пересекает θ.
• Около 4 часов полезной работы и всего один нормальный блок фокуса.

Формально «работали весь день», фактически — мало в чём продвинулись.

День с контролем среды

• Меньше внешних событий + быстрый возврат в задачу.
• 6+ часов продуктивного внимания.
• Несколько последовательных глубоких интервалов.

Здесь эффект нелинейный: снизили λ на 20–30%, а качество дня выросло кратно.

Что важно

• Вред приносит не количество задач, а фрагментация внимания.
• Одно «вставленное» совещание портит весь рабочий график, разрушая потенциальные интервалы ≥ θ.
• Пинг-культура в чатах увеличивает λ до уровня, где глубокая работа становится статистически маловероятной.
• Без управления этими параметрами невозможно стабильно планировать сроки, качество работы и комплексные задачи.

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

⚠ TL;DR:

Продуктивность — это не дисциплина, а параметры среды.

Управляете прерываниями (λ), сокращаете количество возвратов в контекст (Δ), защищаете фокусные слоты (θ) — получаете системный кратный прирост качества и скорости.

Игнорируете — получаете «рабочие будни», в которых почти ничего не достигнуто, кроме ощущения лютой вымотанности к концу дня.

Уже лишь только ленивый не написал про CVE-2025-55182 aka React2Shell, пересказывая своими словами райтапы, пересказанные ранее другими авторами с пересказанных ещё кем-то постов.

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

✖️ Что НЕ сделали разработчики React'а?

Команда React не предусмотрела надёжную проверку и фильтрацию данных при десериализации входных нагрузок RSC (React Server Components). В результате они могли расширять свойства объектов без достаточной валидации (например, путём инъекции proto), что позволяло загрязнять прототипы (prototype pollution) и выполнять произвольный код на сервере.

✅ Что делать разработчикам?

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

💻💻:

• Используйте структуры данных без прототипа: вместо пустых объектов {} применяйте Object.create(null) или литерал {__proto__: null}. Это предотвратит наследование опасных свойств от Object.prototype.

• При необходимости используйте ассоциативные коллекции — применяйте new Map() и new Set() вместо обычных объектов. У них нет «прототипа» в классическом понимании, и методы вроде .get()/.has() возвращают только значения.

• Замораживайте глобальные прототипы: например, вызов Object.freeze(Object.prototype) (и/или Object.seal) заблокирует добавление или изменение свойств базового прототипа. Это затруднит атаки, но нужно учитывать, что многие библиотеки рассчитывают на динамическое расширение объектов.

• При запуске Node.js можете указать флаг --disable-proto=delete — он полностью удалит свойство __proto__ из стандартных объектов.

• Санитизируйте имена полей при объединении/парсинге JSON: запрещайте или фильтруйте ключи вроде __proto__, prototype, constructor и подобных. Лучше всего – явно разрешать (whitelist) только ожидаемые имена полей и отбрасывать все остальное.

• Избегайте небезопасных merge-функций (например, lodash.merge, рекурсивных функций объединения объектов) при работе с внешними данными. Если мёрдж неизбежен, тщательно проверяйте, как реализована функция: нет ли в ней присвоения прототипов или вызова setattr (в JS – методов вроде Object.assign/reduce).

💻 Python:

• Не используйте pickle, или хотя бы не выполняйте pickle.loads на входных данных. Если нужна сериализация, используйте безопасный формат (JSON, json/yaml без пользовательских конструкторов).

• Избегайте рекурсивного слияния атрибутов объектов из пользовательских словарей. Любая функция типа merge(src, dst) может при наличии поля __class__ или __globals__ обойти границы объекта и изменить класс или глобальные переменные. Проверяйте, что входные данные не содержат ключей, начинающихся с __ или равных именам методов объектов.

• Ограничивайте динамическое добавление атрибутов. При необходимости используйте __slots__ в классах или явно задавайте список полей (например, через dataclasses), чтобы неизвестные атрибуты просто игнорировались. По возможности не добавляйте атрибуты в классы по именам из JSON.

• Проверяйте использование setattr и init: ни в коем случае не допускайте передачи строкового кода или списка методов для выполнения через eval/instance_eval внутри __init__ или других «магических» методов.

• Замораживайте и не раскрывайте конфиденциальные переменные: не давайте внешнему коду доступ к глобальному состоянию приложения (модули, конфиг и т.д.), тем более через __globals__/__class__.

Продолжение — в следующем посте.

Начало — в предыдущем посте.

💻 Ruby:

• Аналогично JS и Python, опасен рекурсивный deep_merge или любое слияние, которое устанавливает инстанс- или класс-переменные на основе данных пользователя.

• Не доверяйте deep_merge на объектах: стандартный Hash#deep_merge безопасен для чистых хешей, но при объединении атрибутов объекта он может добавить методы. Всегда контролируйте, какие атрибуты ставятся через attr_accessor или instance_variable_set. Если используется ActiveSupport или Hashie для слияния, проверяйте, закрыты ли методы (Hashie блокирует переопределение методов, но ключи вида _/! могут обойти защиту).

• Не используйте eval/instance_eval или небезопасный to_proc на пользовательских данных.

• Ограничивайте область действия включаемых модулей: при include/extend убеждайтесь, что приватность методов не «размывается» — по возможности убирайте ненужные методы через undef_method или делайте их private. Это не устранит атаку слияния, но уменьшит «плохой» код, который можно подменить.

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

🖥 PHP:

• Прямого аналога прототипов тоже нет, но есть опасность перезаписи свойств: функции-слияния с объектов не имеют смысла (результат – stdClass), однако стандартные foreach или (object)$array могут изменить экземпляр класса. Избегайте кода вида foreach($data as $k=>$v) { $obj->$k = $v; } без фильтрации ключей.

• Используйте массивы вместо объектов: например, при json_decode($json) указывайте вторым параметром true, чтобы получить массив, а не объект. Тогда не получится неявно «пролить» данные в объект.

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

• Не используйте unserialize() на пользовательских данных: это другая категория уязвимостей, но тоже позволяет менять внутренние данные объектов. Для передачи сложных структур лучше json_encode/decode с валидацией.

Другие языки:

• В💻 Java и 💻 необходимо следить за безопасностью десериализации и рефлексии (в том числе — неявной, на стороне используемого фреймворка). Например, не внедрять из JSON имена классов/методов напрямую (Class.forName и т.п.); в конфигурационных классах делать поля private final. Используйте sealed или final классы везде, где это возможно. В 👣 и 👣 Rust аналогичная история: в общем подходе по-прежнему нужно валидировать JSON по структуре (Go) и использовать serde/serde_json (Rust) без включения нестандартных поведений.

Как-то так 🤓

⚠ TL;DR:

Лонгрид — не заслуживает внимания, оставайтесь c уязвимыми проектами)

Архитектура безопасности ИИ-агентов в Google Chrome

На фоне добавления в Chrome интеграции с Gemini, и в предверие выхода agentic-фич в браузере, команда Google Security разродилась любопытной статьей на тему их видения архитектуры безопасности всего этого хозяйства.

Основной угрозой для браузера его авторы [заслуженно] считают косвенные промпт-инъекции (indirect prompt injection, IPI), которым оказались подвержены, и недавно вышедшие Comet с Atlas'ом, и уже упомянутая, вышедшая ранее интеграция Chrome с Gemini, и бог его знает, какие ещё браузеры (подробнее почитать об этом можно, например, тут: [1], [2], [3]).

Для борьбы с IPI они предлагают простую (тем и привлекающую) архитектуру, в рамках которой браузер получает отдельную модель-критика — защитный слой, который оценивает каждое действие агента ещё до того, как оно достигнет реального интерфейса. Критик намеренно изолирован от внешнего контента и анализирует только параметры будущего шага, тем самым исключая возможность влияния внешнего контента на его решения.

Чтобы агент не превратился в универсальный механизм доступа ко всему, что видит браузер, вводится концепция «Origin Sets»: агент заранее привязывается к ограниченному набору ориджинов (в терминах, близких к SOP), релевантных решаемой задаче. Причём для каждого устанавливается собственный уровень взаимодействия: чтение, или чтение-запись. Это позволяет контролировать, какие источники он анализирует и где имеет право изменять данные.

Когда же речь заходит о наиболее чувствительных действиях — отправке форм, переводе средств, изменении пользовательских настроек — агент обязан передать решение самому человеку. Лишь после явного подтверждения пользователь разрешает действие, а прозрачный журнал операций даёт возможность понять, как агент пришёл к тому или иному результату. Т.е. здесь предлагается Human-in-the-Loop с обоснованием.

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

⚠ TL;DR:

Google думают, что создали защиту от косвенных промпт-инъекций в контексте agentic-бразуера. По сравнению с попытками предшественников, она, мало того, что просто есть, так ещё и выглядит эстетично.

Но запастись попкорном, на всякий случай — лишним не будет 🍿