Хекслет

LLM, ИИ и агенты

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

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

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

И если раньше задачи связанные с машинным обучением были нишевыми и встречались редко, то теперь решения на базе ии внедряются повсеместно. Причем не на уровне красивых слов, а по настоящему. И эта работа больше не является уделом отдельных специалистов в области ml. Сейчас эта работа передается и программистам и автоматизаторам (те кто настраивают связи между сервисами). Для особо сложных случаев, появляется потребность в людях, которые объединяют в себе знания и программирования и администрирования и особенностей llm и платформ вокруг них (rag, fine tuning и так далее). Чем-то это похоже на появление когда-то DevOps (как спецов, а не как культуры).

Вот какие можно выделить направления:

- ИИ для спецов (программистов, аналитиков, девопс и тестировщиков). Тут мы дополняем существующие навыки, навыками по использованию агентов (от постановки задач, до написания скилов).
- Автоматизация с помощью ИИ. Сюда входят люди способные настроить workflow или агентов на базе существующих платформ. Это те же самые люди, которые настраивают интеграции между сервисами, например используя n8n.
- LLM-разработчик. Развитие предыдущего уровня, тут уже мы получаем человека, который хорошо разбирается в том как работают модели и способен с нуля создавать решения на базе мощностей компании.

Меняется мир меняемся и мы. Возможно вы заметили, что раздел ИИ на Хекслете наполнился программами. И первая из них стартует 30 марта, где мы будем изучать программирование с помощью ии-агентов. Посмотреть программы и записаться можно по ссылке https://ru.hexlet.io/courses_artificial-intelligence

p.s. а еще я опубликовал на днях видео, где для разработчиков и им сочувствующих рассказываю про то как собственно устроена эта современная разработка через агентов youtube.com/watch?v=Au8ioLEJDOU

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

Вот четыре такие привычки, которые стоит выработать как можно раньше.

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

Почему это работает?

▶ Отладка
Если что-то сломалось, git bisect или простой взгляд на историю покажет конкретное изменение, которое привело к багу.

▶ Понимание
Коммит с ясным сообщением («Исправил расчет скидки для промокодов», а не «fix») становится исторической записью о «зачем» и «почему». А вам и вашей команде не придется через месяц гадать на кофейной гуще.

▶ Ревью
Небольшой пул-реквест с одним логическим изменением просматривается в разы быстрее и качественнее.

Все это не про занудство и дотошность, а про прагматизм и уважение к своему будущему «я».

🔷 Письменные договоренности – волшебный чек-лист памяти
«Кажется, мы договорились, что...» – фраза, которая может привести к потерянным дням и испорченным отношениям. Наша память, увы, не самый ненадежный носитель, особенно под нагрузкой.

Что делать?
– Фиксируйте итоги созвонов в таск-трекере или общем чате: «Итак, по итогу обсуждения: делаем Х методом Y, ответственный – я, срок – среда».
– Отправляйте короткие письма-подтверждения после важных устных разговоров: «Как и обсуждали, я приступаю к задаче А, ожидаемый результат – Б».

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

🔷 Перестаньте использовать голову как жесткий диск
Держать в оперативной памяти список дел, идеи по рефакторингу, команду для настройки окружения и план встречи – верный способ исчерпать когнитивные ресурсы к обеду.

Инструменты – не слабость, а апгрейд:
– TODO-лист (хоть в том же TODO.md в проекте) освобождает от тревоги что-то забыть;
– Чек-листы для рутинных операций (деплой, Code Review) исключают человеческий фактор;
– Заметки/вики по проекту хранят контекст, который не поместится в голове.

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

🔷 Когда код перестает поддаваться
Если вы 30-40 минут пристально смотрите на экран, перечитываете одну функцию десятый раз и не можете понять логику бага – проблема уже не в коде. Проблема в туннельном зрении и усталости вашего мышления.

В этот момент продолжать = ошибаться дальше. Коэффициент полезного действия стремится к нулю.

Что делать вместо этого?
– Сделать перерыв: выпить чаю, пройтись, погладить кошку, если она у вас есть и вы работаете из дома.
– Переключиться на другую простую задачу.
– Объяснить проблему кому-то вслух. Часто решение приходит на этапе формулировки.

Назовем это «стратегической паузой», а не прокрастинацией.

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

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

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

Первые месяцы в IT – это как попытка выпить из пожарного гидранта: информации слишком много, все важно и все срочно. Работа, учеба, да и домашние дела никто не отменял – как все успеть и не сойти с ума? Мы собрали ключевые принципы, которые помогут вам выстроить устойчивую систему, а не выживать в режиме аврала.

Тайм-менеджмент – ваш главный союзник
Первое и самое важное правило: работа и учеба должны иметь четкие границы. Физические или временные.

🔷 Не забирайте рабочие задачи домой. Ваше вечернее время – это инвестиция в восстановление или в учебу. Смешивая все в одну кучу, вы гарантированно получите выгорание.
🔷 Если вы на удаленке – имитируйте офис. Начинайте и заканчивайте в одно время. Закрывайте рабочий мессенджер и таск-трекер. Ваш мозг нуждается в ритуале «окончания рабочего дня», чтобы переключиться.
🔷 Используйте технику «тайм-боксинга». Выделяйте конкретные временные блоки (например, по 90 минут) на учебу и жестко им следуйте. Так вы не будете бесконечно сидеть над одной задачей.

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

🔷 Установите себе лимит. Если вы бьетесь над учебной задачей или рабочим багом больше 1-2 часов, это сигнал: пора просить помощи.
🔷 Спрашивайте правильно. Вместо «у меня ничего не работает» сформулируйте: «Я пытаюсь сделать X, чтобы получить Y. Использовал подход A и B, но столкнулся с ошибкой C. В каком направлении думать?». Так вы покажете свою работу и облегчите наставнику или коллеге задачу.
🔷 Используйте все ресурсы: наставника, одногруппников, коллег, сообщества Хекслета в Telegram. Чужой опыт может сэкономить вам день, а иногда и неделю.

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

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

Лучшая стратегия – учиться постоянно, но небольшими порциями. Короткие ежедневные сессии (даже по 30-40 минут) эффективнее одного семичасового марафона на выходных. Знания успевают «улечься».

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

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

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

Управление энергией, а не временем
Стресс от совмещения двух серьезных активностей – это не слабость, а объективная реальность. Нужно не геройски терпеть, а управлять.

🔷 Сон и питание – это не опционально, а обязательно. Это базовая инфраструктура для вашей продуктивности. Недостаток сна сводит на нет любые техники тайм-менеджмента.
🔷 Так же, как вы планируете задачу по программированию, внесите в календарь «прогулка», «ничегонеделание» или «хобби». Это буфер, который не даст системе перегреться.
🔷 Отслеживайте свое состояние. Чувствуете постоянное раздражение или туман в голове? Это красные флаги. Значит, нужно не «потерпеть еще недельку», а срочно снижать нагрузку и восстанавливаться.

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

Делитесь в комментариях своими лайфхаками – ваш опыт совмещения поможет другим 😉

🔥У каждого был свой момент — первый деплой, первый удачный pull request или когда перестал(а) паниковать на баги. Допишите свою короткую историю в комментариях на тему: «Я понял(а), что начал(а) реально разбираться в программировании, когда…»

Поделитесь — интересно читать, какие у кого были переломные моменты.

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

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

Подробнее – в карточках. Сохраняйте, чтобы всегда было под рукой 🙌

Каждый день вы открываете десятки сайтов. Но за простым действием «ввести URL и нажать Enter» скрывается четко отлаженный механизм из нескольких этапов.

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

Этап 1: DNS-запрос – ищем адрес дома
Когда вы вводите адрес сайта, браузер сначала должен понять,
на какой сервер идти.

Человек понимает vk.com, а браузеру нужен числовой адрес сервера.

Для этого используется специальная система, которая сопоставляет имена сайтов и адреса серверов — по сути, справочник интернета.

Чтобы не тратить время, браузер сначала ищет ответ поблизости:

- проверяет, не открывали ли вы этот сайт недавно,
- смотрит локальные сохранённые данные.

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

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

Этап 2: Соединение с сервером – «рукопожатия»
Когда IP-адрес найден, браузеру нужно установить соединение с сервером.

Перед тем как начать передавать данные, стороны должны договориться о двух вещах:

Что соединение надёжное
Браузер и сервер проверяют, что оба готовы общаться и данные не потеряются по дороге.

Что соединение безопасное
Если сайт работает по HTTPS, данные будут передаваться в зашифрованном виде, а браузер убеждается, что общается именно с тем сервером, а не с подменой.

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

Вывод: без этих «рукопожатий» не было бы ни стабильной доставки данных, ни безопасности.

Этап 3: Загрузка данных – запрос и ответ
По установленному безопасному каналу браузер отправляет HTTP-запрос (чаще всего GET), указывая путь к ресурсу и нужные заголовки.

Сервер обрабатывает запрос и возвращает HTTP-ответ, который содержит:
– Статус-код (200 – ОК, 404 – не найдено, 500 – ошибка сервера);
– Заголовки с метаинформацией — они говорят браузеру, что это за данные и как с ними работать (можно ли кешировать, как долго хранить и как интерпретировать;
– Тело ответа – обычно HTML-документ будущей страницы.

Здесь на помощь снова приходит кеширование. Правильные HTTP-заголовки (Cache-Control, ETag) позволяют браузеру не загружать повторно статические ресурсы (CSS, JS, картинки), если они не изменились. Это радикально ускоряет открытие знакомых сайтов.

Этап 4: Рендеринг — превращение кода в страницу
Получив HTML, браузер начинает магию превращения кода в пиксели на экране.

HTML → DOM
Браузер разбирает HTML и строит дерево элементов страницы.

CSS → стили
Он понимает, как эти элементы должны выглядеть: цвета, размеры, отступы.

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

Отрисовка страницы
Элементы превращаются в пиксели на экране.

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

Чем сложнее CSS и JavaScript, тем тяжелее браузеру рендерить страницу и тем ниже производительность.

Что в итоге?
От ввода адреса до готовой страницы ваш браузер и сервер проделывают гигантскую работу за доли секунды. Понимание этого конвейера помогает джунам видеть полную картину, а не только свой участок кода. А всем разработчикам – осознанно подходить к оптимизации скорости загрузки и безопасности сайтов.

Вопрос, которым задавался, пожалуй, каждый, кто выходил на работу:
«Что здесь вообще происходит и как мне быть полезным?».

Это и есть точка старта для онбординга.

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

Обычно это:
🔹 Недели хаоса и пустой суеты с задачами;
🔹 Лишние ошибки из-за незнания контекста и процессов;
🔹 Внутренние собственные мысли («А туда ли я вообще пришел?»).

Хороший же онбординг решает три ключевые задачи:
- Ускоряет выход на продуктивность – человек быстрее начинает приносить реальную пользу;
- Снижает количество ошибок – потому что объяснены правила игры, процессы и границы ответственности.
- Убирает тревожность – дает опору в первые недели, когда вопросов больше, чем ответов.

По сути, он дает ответы на базовые вопросы:
📍 Где я оказался и как тут все устроено?
📍 Что конкретно от меня ждут?
📍 Как здесь принято работать и взаимодействовать?

И здесь главный вывод: онбординг – это не «забота ради заботы». Это экономика.

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

Предлагаем поделиться своим опытом в комментариях и рассказать, что запомнилось, а чего не хватило во время вашего первого (и не только первого) онбординга👇

Иногда тишина – не проблема, а суперсила. Сейчас объясним 🙏

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

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

Возникает тревожный вопрос: «Если мне сложно постоянно говорить и быть в центре общения, значит ли это, что я не создан для командной работы?».

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

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

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

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

Ждут честной обратной связи.

Гораздо важнее вовремя и спокойно сказать: «Я пока не понял эту логику», «У меня есть техническое ограничение» или «Я вижу здесь риск». Это можно делать коротко, по делу и в удобном для вас формате.

И здесь открывается главный козырь многих интровертов – сила письменной коммуникации.

IT-среда для этого идеальна. Команды активно используют чаты (Slack, Пачка), системы управления задачами (Jira, Яндекс Трекер или WEEEK, например), код-ревью и документацию. Четко и грамотно сформулированное письменное сообщение или комментарий к коду – это полноценный, а иногда и более эффективный вклад, чем устное выступление. Вы можете тщательно обдумать формулировку, приложить примеры кода или ссылки, дав коллегам всю информацию для глубокого ответа. Ваш вклад в общее дело от этого не становится менее весомым.

Самая частая и выматывающая ошибка – это попытка притворяться экстравертом, выдавливая из себя слова просто «чтобы сказать» на встрече, или, наоборот, уходя в глухую оборону из-за страха сказать что-то «не так».

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

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

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

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

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

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

Почему?

Потому что внутри работает мощный стоп-кран: страх ошибиться. Он не дает нажать «Отправить», показать код, задать «глупый» вопрос или взяться за новую, пугающую задачу. Это чувство знакомо каждому, кто начинал свой путь в IT, а многие носят его с собой годами.

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

Написать программу – это вступить в диалог с машиной, где ее постоянное «нет» («ошибка компиляции», «undefined», «500 Internal Server Error») – это не критика, а основной способ общения.

Новичок часто находится в плену иллюзии: кажется, что опытный разработчик пишет чистый, работающий код с первого захода, как Моцарт, записывающий готовую симфонию. Реальность куда прозаичнее. Опытный разработчик не волшебник – он просто эффективный дебаггер. Он не делает меньше ошибок; он делает их быстрее, обнаруживает их мгновенно и, главное, не испытывает при этом чувства стыда или неполноценности. Он относится к ошибке спокойно и технично: «Ага, вот здесь условие не сработало. Значит, переменная приходит пустой. Посмотрим, почему». Для него это не личная неудача, а полноценный шаг в алгоритме решения задачи.

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

«Сначала досконально изучу всю теорию, посмотрю все курсы, и только потом попробую».

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

Поэтому давайте договоримся о главном: в IT ошибаются все. Абсолютно. Разница лишь в цене и времени. Ошибка, которую вы нашли сами в своем пет-проекте, стоит вам пяти минут и пары нервных клеток. Та же ошибка, допущенная из-за страха спросить и «дотянутая» до продакшена, может стоить команде бессонной ночи, а компании – денег и репутации. Чем раньше и дешевле вы научитесь безопасно для всех ошибаться, тем ценнее вы станете как специалист.

Если вам сейчас страшно – вы на правильном пути. Это знак того, что вы учитесь чему-то новому и значимому. Ваш вопрос должен звучать не «как избежать ошибок?», а «как научиться ошибаться правильно?».

Вот короткий алгоритм, который помогает превратить страх в инструмент:

🔹 Локализуйте. Вместо «у меня все плохо» скажите: «Я не понимаю, как передать состояние между этими двумя компонентами». Конкретная проблема решаема, глобальная «плохость» – нет.
🔹 Действуйте до уверенности. Не ждите, пока будет «идеально». Сделайте рабочую, даже корявую версию. Запустите ее. Первая работающая, но кривая версия – это на 90% успех.
🔹 Форматируйте запрос о помощи. Не «я тупой, ничего не работает», а «я пытался сделать X, ожидал Y, но получил Z. Вот мой код и ошибка. Где я мог ошибиться?». Это демонстрирует ваш ход мыслей и вызывает у коллег желание помочь, а не снисхождение.

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

🔥 Рубрика «Собеседование в комментариях»

Задача на проектирование, максимально приближённая к реальной работе.

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

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

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

Пишите свои варианты в комментариях — обсудим архитектурные подходы и возможные компромиссы.