Kotlin Adept Notes

Худи RYBE для Kotlin — это лаконичная, функциональная вещь Мы добавили несколько фичей, чтобы тебе было классно и комфортно: ⚫️Карман на металлических кнопках ⚫️Салфетка для очков или экрана в кармане ⚫️Люверсы для пропуска ⚫️Удобный шнурок ⚫️Надпись на капюшоне и одна особенная внутри него ⚫️Карман внутри для наушников, чтобы они не болтались и не терялись    Выбрать свой язык программирования и заказать толстовку можно на сайте: http://rybe.store/ Наш tg

Как и обещал, поделюсь интересными инсайтами из докладов с прошедшего Mobius. В этот раз конференция получилась для меня не совсем привычной для офлайн-формата: было, к сожалению, мало стендов. Тут, очевидно, сказывается общая экономическая ситуация, но зато я посетил большое количество докладов, так что и в этом есть свои плюсы. Итак, что же интересного удалось вынести: 👉 SharedFlow использует под капотом кольцевой буфер, но по умолчанию создаётся без него, и это работает почти в 10 раз медленнее, чем с буфером. При этом в операторе shareIn буфер уже задаётся, так что рассмотрите возможность указания буфера по умолчанию, если создаёте SharedFlow через основной конструктор. 👉 Чтобы эффективно работать с большими изображениями, нужно читать их по частям с помощью BitmapRegionDecoder и использовать culling, чтобы убирать тайлы, которые не видны на экране. Также поможет субсэмплинг, позволяющий снижать разрешение тайла при низком зуме, и правильный выбор фазы отрисовки в Compose. Подробнее почитать об этом можно здесь. 👉 Работать с AGSL-шейдерами довольно просто на статических картинках, но как только в эту цепочку добавляется видео, всё становится значительно сложнее: придётся синхронизировать анимацию шейдеров с паузами в видео и решать другие проблемы. Подробнее посмотреть на реализацию таких шейдеров для Android и iOS можно здесь. 👉 Можно собрать собственного локального AI-ассистента на базе LLM с 2 миллиардами параметров и запустить его на телефоне. Но у слабой модели будут проблемы с самоидентификацией, а качество ответов в целом будет низким. Проблему самоидентификации можно исправить с помощью лаконичного JSON в системном промпте, а не длинного описания. Также по отдельности правила и примеры работают с такими моделями плохо, а вот их совместное использование даёт результат. Посмотреть пример такого AI-ассистента можно здесь. Пишите в комментариях, если хотите еще разобрать какую-то тему с конференции 💬

Помните, не так давно рассказывал вам, как мы решили перейти на state-based TextField и что из этого вышло? Так вот, это была ошибка, и я уже десять раз пожалел, что вообще затеял эту миграцию. Но ирония в том, что в Jetpack Compose 1.13.0-alpha03 старые текстовые поля уже пометили как deprecated, и рано или поздно всё равно придётся мигрировать. Хочу поделиться проблемами, с которыми мы столкнулись, помимо тех, о которых я писал раньше. 1. Нам нужно было сохранить возможность использовать старый API с value и onValueChange, но решение в лоб с двумя LaunchedEffect оказалось нерабочим при быстром вводе символов. Пришлось реализовывать довольно муторную синхронизацию состояния. 2. Ограничение длины текста теперь нельзя реализовать только на уровне бизнес-логики, необходимо ещё и ограничивать текст через InputTransformation. 3. Нельзя использовать OutputTransformation для добавления каких-нибудь единиц измерения в текстовое поле с клавиатурой типа Decimal: это ломается, например, на устройствах Xiaomi. Для этого нужно использовать prefix или postfix как в Material TextField. 4. Также столкнулись с проблемами на iOS в Compose Multiplatform. Например, Saver крашил приложение, а при вводе символов появлялось контекстное меню. В итоге на какой-то базовый компонент пришлось потратить много времени и сил. Так что на вашем месте я бы не спешил отказываться от старого доброго TextField и подождал, пока в новом наконец всё стабилизируется.

В этот раз планирую лично посетить конференцию Mobius, которая пройдет с 21 по 22 октября в Санкт-Петербурге. Программа получилась довольно интересной, и, так как от AI-темы я уже подустал, рад, что осталась хардкор-секция. Выделил для себя несколько докладов, которые точно планирую посетить: • Максим Качинкин и Роман Могутнов расскажут про устройство шейдеров в Android и iOS на примере такой клёвой анимации, вдохновлённой Stranger Things. • Владислав Томилов расскажет про работу NFC в Android под капотом. • Максим Сидоров и Иван Гришов разберут, как устроен Kotlin Flow под капотом. • Денис Супрун поделится опытом миграции реального Compose Multiplatform-приложения на Аврору. После конференции поделюсь в канале интересными инсайтами из докладов, так что stay tuned! 🎟 По промокоду kotlinadept можно купить персональный билет дешевле.

Опубликовали доклад с прошедшей конференции, где я рассказал о том, как в рабочем проекте удалось попробовать себя сразу в нескольких ролях: от аналитика и дизайнера до бэкендера и мобильного разработчика, и что из этого получилось. В докладе: 👉 Узнаем, как проходила работа над этим проектом: от проработки сценариев до генерации макетов в Figma и создания приложения. 👉 Поделюсь своими мыслями о работе с AI: что оказалось эффективным, а что нет. 👉 Разберём, за счёт чего получилось ускорить TTM и можно ли масштабировать такой подход. ✅Приятного просмотра

На этом парад конференций Подлодки не заканчивается: уже на следующей неделе я выступлю с докладом на Podlodka Techlead Crew, где расскажу, как мне удалось примерить на себя несколько ролей, от аналитика и дизайнера до бэкендера и мобильного разработчика, на реальном легаси-проекте. 🟢Мы пройдём путь от проработки сценариев до генерации макетов в Figma и создания приложения. 🟢Разберём, за счёт чего получилось ускорить TTM, и насколько легко входить в чужие роли в большой компании, а не на пет-проектах. 🟢Поделюсь своими инсайтами по работе с AI, которые получил по ходу работы. 🟢Сделаем выводы о возможности масштабирования такого процесса. 🎲 Также у меня есть один бесплатный билет, который предлагаю разыграть. Пришлите в комметариях под этим постом любимый мем, связанный с разработкой, а я случайным образом выберу победителя сегодня в 21:00 МСК. 🎟 А ещё у меня есть промокод на покупку билета со скидкой: KotlinAdept

Полезные AI-тулзы для Android-разработчика На конференции обсудили разные AI-инструменты, которые помогут выполнять задачи качественнее и экономить токены. Поделюсь некоторыми из них. Перфоманс 🔘Echolot помогает находить проблемы производительности в 12 раз эффективнее по токенам, чем официальный скилл от Google. Поиск исходников 🔘Ksrc стабильно и эффективно по токенам помогает искать исходный код в Gradle-зависимостях. Обновление библиотек 🔘Связка Gradle MCP и Maven MCP отлично показывает себя в задачах обновления библиотек до актуальных версий и делает это почти в 2 раза эффективнее по токенам, чем голый агент. Проверка UI без пересборки приложения 🔘Чтобы быстро проверять вёрстку приложения, помогут Compose Hot Reload (требует Desktop-таргет), а также compose-ai-tools, который работает через Preview и может работать даже без Android Studio. Тестирование и отладка 🔘MCP Devices поддерживает множество платформ и помогает с тестированием, отладкой и отслеживанием проблем производительности. Работа с локальными моделями 🔘Vibe-action позволяет строить YAML-пайплайны для стабильной и предсказуемой работы даже со слабыми LLM-моделями. Автономная разработка 🔘Kent является оркестратором над харнессами и позволяет добиться лучшего качества за счёт агентных графов. 📌 А какими инструментами пользуетесь вы в повседневной разработке?

Как подружить строгий Java-энтерпрайз со всеми ИИ изменениями? Сбер поможет разобраться 24 сентября в московском офисе Сбера состоится Java Meetup — мероприятие, на котором эксперты расскажут: ✔️Что происходит в мире Java в 2026 году? ✔️В чём реальная польза (и скрытые риски) применения SDD, виртуальных потоков и Koog ✔️Обсудим, как меняется роль Java-разработчика под влиянием ИИ Никакой теорий — только реальные кейсы от практиков! Формат: офлайн в Москве (Кутузовский, 32) и онлайн трансляция. Время: сбор гостей — 16:30, начало — 17:00. Регистрация: здесь

Мифы и заблуждения в AI-разработке Забавно, как в мире AI-разработки постоянно появляются новые лучшие практики, а потом оказывается, что они неэффективны или, наоборот, приносят больше вреда, чем пользы. Приведу несколько примеров. Эффективность Миф: Дешевая модель сделает задачу дешевле, чем более дорогая. Реальность: Стоимость задачи складывается из стоимости запроса и количества итераций. Поэтому более дорогая модель может сделать задачу дешевле. Миф: Чем выше reasoning, тем лучше качество. Реальность: Модель на более низком reasoning может показывать результаты лучше, чем на высоком. Миф: Чем больше сабагентов работает над задачей, тем лучше. Реальность: Увеличение декомпозиции ролей агентов приводит к ухудшению качества. Миф: Скиллы значительно улучшают качество работы агента. Реальность: Большинство скиллов не имеют эвалов, и если их просто сгенерировал агент, то получаем ухудшение качества. Экономия токенов Миф: Caveman экономит 65% токенов. Реальность: JetBrains измерили и оказалось, что экономия составляет всего 8,5%. Миф: RTK экономит 60–90% токенов. Реальность: На высоком reasoning ничего не экономит, а на низком, наоборот, может увеличить стоимость. Миф: С Ponytail агент пишет на 54% меньше кода. Реальность: На самом деле всего на 15%. А с какими заблуждениями в AI сталкивались вы?

Тем временем мы с командой подготовили для вас новый сезон Podlodka Android Crew при поддержке RWB. И в этот раз сезон посвящён AI, куда уж без него 😈 Но мы старались подготовить не просто доклады в вакууме, а действительно практически полезные сессии, связанные с Android-разработкой, из которых вы сможете унести много полезного. Что в программе: 🟢Узнаем, как с помощью AI эффективно решать задачи оптимизации производительности приложения, не тратя при этом огромное количество токенов. 🟢Посмотрим на разные автономные воркфлоу, которые позволяют обеспечить качество при разработке Android-приложений. 🟢Разберёмся в многообразии появляющихся инструментов для Android-разработки и узнаем, что действительно работает, а что нет. ✅ Уже завтра состоится первая публичная сессия о том, как изменилась разработка с приходом AI от Антона Шилова. 🗓 А сам сезон пройдёт с 21 по 25 сентября. Так что залетайте, будет интересно. Ведь конференция Подлодки — это не только доклады, но и нетворкинг, где можно обсудить наболевшие вопросы и поучаствовать в разных активностях. А по промокоду KotlinAdept будет скидка

Прошло уже более полугода с того момента, как я рассказывал вам о реализации Android-приложения для удалённого доступа. И наконец-то мой коллега Евгений Мельцайкин выступит сегодня на конференции E-CODE с докладом по теме. Из доклада вы узнаете: 🔘Как реализовать функциональность постоянного доступа 🔘Об архитектуре решения, построенного на межпроцессном взаимодействии нескольких сервисов 🔘Как автоматически выдавать разрешение на демонстрацию экрана 🔘Как поднимать сервис после перезагрузки устройства 🗓 Доклад можно посмотреть в прямом эфире онлайн уже сегодня, 12 сентября, в 18:30 по МСК. 🔗 Подключиться к трансляции

Если вы тоже городили костыли для поддержки смены системной темы внутри Compose Multiplatform-приложения, как описано в документации, то в Compose Multiplatform 1.12.0 проект на iOS просто перестанет компилироваться. Я создал issue по теме и накидал workaround. Проголосуйте за issue, если столкнулись с такой же проблемой. Как считаете, норм ли сносить публичное API, хоть и предназначавшееся для внутреннего использования в минорном обновлении?

⚡️⚡️Мобильные разработчики снова соберутся на Mobius этой осенью! 21–22 октября в Санкт-Петербурге и онлайне пройдет Mobius — конференция JUG Ru Group для мобильных разработчиков. По традиции в фокусе — практические задачи, нативный и кроссплатформенный подходы, архитектура и реальный опыт продуктовых команд. ✨Программа уже активно формируется, делимся наиболее интересными докладами: 🔹Портирование Android-приложений под HarmonyOS NEXT. Спикер расскажет про автоматизированный перенос с сохранением архитектуры: от преобразования Kotlin-кода в ArkTS до трансляции Jetpack Compose в ArkUI. 🔹AI-driven T-shape. Разбор реального опыта команды о том, как искусственный интеллект помогает осваивать соседние платформы и бэкенд, ускоряя развитие инженеров и уменьшая time-to-market. 🔹Liquid Glass своими руками на Metal. Анатомия визуального эффекта из iOS 26 и его воссоздание для более старых версий с разбором интеграции в кодовую базу Telegram. 📣 Встречаемся 21–22 октября (Санкт-Петербург + online). Подробнее о программе и билетах — на сайте.

Сколько стоит отказ от OpenCV Весь препроцессинг в сканере, о котором я рассказывал в прошлых постах, держится на OpenCV — библиотеке компьютерного зрения, написанной на C++. Нам из неё нужно меньше десятка функций: гомография, ресайз, гауссово размытие, CLAHE, Otsu и другое. Платим за это мы, конечно, размером: библиотека добавляет к APK около 200 МБ 😱 Здесь сразу оговорюсь, что это цифра для универсального APK со всеми ABI внутри, и очевидно, что App Bundle столько не весит: на устройство прилетает один ABI из четырёх, то есть пятьдесят мегабайт. Вот только это всё ещё много, так что AAB проблему полноценно не решает. Идея кажется очевидной: функций немного, может быть, переписать всё это на Kotlin и выкинуть зависимость целиком? Благо теперь, в мире AI, это можно сделать почти бесплатно. Как ни странно, по бенчмаркам удалось добиться почти того же качества, но вот по времени препроцессинг стал работать в 9 раз дольше на 95-м перцентиле. Кто бы мог подумать 😲 Этот вариант, очевидно, не подходит. Поэтому появилась идея собрать свою урезанную версию OpenCV, только у своей сборки есть и минусы: 🔘Обновление OpenCV перестаёт быть сменой одной цифры в зависимостях: нужно пересобрать под все ABI, прогнать сборку в CI, проверить, что ничего не отвалилось. 🔘Сложный порог входа, даже с AI-агентами можно будет прикурить после очередного апдейта NDK или AGP. 🔘Готовые обёртки OpenCV написаны и отлажены, а если мы где-то накосячим с жизненным циклом, то получим серьёзную утечку памяти в нативе. 🔘И наконец, нет гарантий, что не понадобятся ещё какие-то методы из OpenCV и потом может быть очень больно всё заново пересобирать и обновлять. Так что остаётся либо мириться с размером, либо усложнять поддержку. А что бы выбрали вы?

Как читать плохо пропечатанные коды В прошлый раз я упомянул, что returnErrors в ZXing подготавливает почву и для других препроцессингов. Сегодня разберём ещё один пример препроцессинга для исправления плохой печати. Речь про коды, у которых модули (те самые чёрные и белые квадратики, из которых состоит DataMatrix) напечатались с разрывами. 1️⃣ Первый шаг кажется максимально контринтуитивным: чтобы прочитать код, картинку сначала придётся намеренно испортить. Для этого накладываем гауссово размытие по вертикали, чтобы склеить разорванные модули. 2️⃣ Далее уменьшаем изображение методом INTER_AREA, то есть с усреднением по площади, до трёх пикселей на модуль. Всё, что мельче модуля (шум матрицы, зернистость бумаги), просто исчезает, а модуль в три пикселя выживает. Порядок здесь важен: размывать нужно именно до уменьшения, после него склеивать уже нечего. 3️⃣ После усреднения вместе с мусором приглушаются и полезные участки, поэтому CLAHE (Contrast Limited Adaptive Histogram Equalization) помогает вернуть контраст. Если по-простому, то картинка делится на 64 клетки, в каждой берутся самый тёмный и самый светлый пиксель, и затем яркость плавно растягивается. 4️⃣ Последний шаг — это перевод серого в чисто чёрно-белое. Алгоритм Otsu сам подбирает уровень, ниже которого всё становится чёрным, а всё, что выше — белым. И уже эта картинка скармливается снова в ZXing. Нюанс в том, что ни ось размытия, ни нужный размер заранее неизвестны: первое зависит от того, как принтер испортил печать, а второе от расстояния съёмки. Поэтому перебирается сетка: три целевых размера кода на шесть вариантов источника — размытия по вертикали и горизонтали с тремя разными ядрами. Затем пытаемся декодировать каждый вариант. 💡 И тут снова выручает returnErrors. Если до этого код не читался вообще никак, то на некоторых комбинациях ZXing хотя бы находит символ: прочитать модули он всё ещё не может и возвращает ошибку контрольной суммы, но это уже подсказка. Она позволяет отбросить неактуальные комбинации и подбирать размер вокруг удачной, убавляя или прибавляя пиксели. Таким образом, если повезёт подобрать нужные параметры, код получится прочитать, но стоить это может дорого. Именно поэтому в потоковом режиме сканирования такому перебору нужен жёсткий бюджет по времени, а весь препроцессинг стоит выносить в отдельный поток, иначе будут сильные просадки по FPS.

Собираем бэкенд-комьюнити на JVM Day Бэкендеры, 29 августа в Москве пройдет хардкорная конференция. Ждут своих: Java-, Scala- и Kotlin-разработчиков, архитекторов и тимлидов. Здесь выступят и расскажут: — Андрей Кулешов — что нового в мире JVM за год. — Сергей Петрелевич — разработка по Mechanical Sympathy. — Александр Ланцов — Java после Loom: другие модели concurrency. — Антон Курако — как бенчмарки вводят в заблуждение. А вечером во дворе T-Space — посиделки, интерактивы и открытый микрофон с историями ошибок. Мест мало, а цена билета будет расти. Успевай зарегистрироваться

Перспективное отображение Продолжаю заниматься сканером и хочу поделиться одним интересным инсайтом, как улучшить качество сканирования кодов маркировки. Базовый пайплайн выглядит так: 1. Кадр с камеры уходит в детектор (tflite-модель), который находит на нём координаты потенциальных кодов. 2. По каждому боксу вырезается ROI с небольшим паддингом, переводится в grayscale и отдаётся в декодер, например, ZXing. То есть качество сканирования напрямую зависит от качества детектора и декодера. И часто происходит так, что код сфотографирован под углом или наклеен на слегка изогнутую поверхность: детектор такой код находит без проблем, а вот декодер прочитать его уже не может. Чтобы улучшить ситуацию, можно применить так называемое перспективное отображение или гомографию, чтобы скорректировать перспективу и получить изображение кода, как будто снятого в лоб. Чтобы это сделать, достаточно знать координаты четырёх углов кода. И тогда всё сводится к двум вызовам OpenCV: getPerspectiveTransform считает матрицу по четырём парам точек, warpPerspective применяет её к изображению. Проблема в том, как получить эти углы. Ведь детектор ничего не знает о положении кода в пространстве и отдаёт обычный прямоугольник. Тут помогает включить параметр returnErrors в настройках ZXing: если ему удалось распознать паттерн кода, но не удалось декодировать по каким-то причинам, он отдаст координаты всех четырёх углов, к которым мы затем можем применить гомографию и снова попытаться распознать уже неискажённое изображение. При этом ZXing и сам умеет в перспективу, но его гомография стоит в самом конце и не выпрямляет картинку, а лишь подсказывает, куда смотреть на всё том же косом кадре. Бинаризация и подсчёт размера кода отрабатывают раньше и видят его искажённым, что приводит к неверно прочитанным модулям и ошибкам размерности. Ещё returnErrors подготавливает почву и для других препроцессингов, например, для борьбы с плохо пропечатанными кодами. Если тема интересна, ставьте реакции, и я постараюсь еще простым языком разобрать, как это все работает.

Как сделать свой SDK для Remote Config Если вы используете Firebase Remote Config для работы с фиче-флагами, то, возможно, для вас он станет платным, и кто-то начнёт искать альтернативу. Мы, на самом деле, уже давно с него мигрировали на другое стороннее решение из-за высоких рисков блокировки, а теперь полностью переходим на собственный сервис. Хочется поделиться особенностями разработки такого SDK. Начать стоит с выделения фасада с базовыми методами fetch, activate и get<Type> с Timber-подобным API. Тогда вы сможете с лёгкостью заменить одно решение другим. При реализации собственного SDK нужно учесть несколько важных моментов. 1. Понадобятся три вида хранилища данных: персистентное для хранения актуальных значений, персистентное для хранения временных значений (после fetch и до activate) и memory cache для моментального получения актуальных значений. 2. Нужно хорошо продумать, как исключить race condition и data race. Первичную инициализацию memory cache лучше сделать блокирующей, чтобы не потерять данные. Для методов fetch и activate лучше использовать общий mutex, чтобы не допустить рассинхронизации значений. 3. Предусмотрите throttle-механизм, чтобы не перегружать ваш бэкенд. При этом заранее продумайте, как будете реализовывать force fetch, когда значения нужно обновить как можно скорее, а также фоновое обновление, если пользователь долго не выгружает приложение из памяти. В общем, на первый взгляд кажется, что задача простая, но в ней очень много подводных камней. Так что это вполне хороший кейс для собеседования по System Design для мобильных разработчиков.

Новые AI модели и инструменты выходят каждую неделю, городские сумасшедшие хоронят программирование, а кто-то, обложившись сотней агентов, создает супер-успешные проекты. Как с этим жить, решительно непонятно. Чтобы помочь с этим справиться, ребята из подкаста Подлодка запустили закрытое сообщество инженеров, которые уже активно используют AI в работе и хотят делать это системно. Вот кому туда стоит подключиться: 👉Если вы хотите просто держать руку на пульсе происходящего в индустрии Подлодка вытаскивает очень крутых экспертов из Uber, xAI, Google, Яндекса, Cursor и других компаний. Они рассказывают, как работают их команды – и вы можете узнать у них то, о чем на конференциях начнут говорить только через год. А в закрытом чате разбирают все важные новости и изменения подходов к разработке. Если нет времени читать – вам приходит дайджест с главными выводами. 👉Если вы хотите вкатиться в лучшие практики AI разработки В клубе прошло уже больше 40 стримов на разные темы – от разбора фреймворков для Spec-Driven Development до того, как строить общий реестр скиллов для команды или автономные фабрики фичей. В чате есть специализированные комнаты по самым горячим темам – например, локальные модели, или тот же самый SDD. Клубчане делятся там своими сетапами и практиками. А еще в клубе есть бот, который может ответить на любой ваш вопрос на основе всего архива прошедших стримов и обсуждений в чате! 👉Если вы уже активно внедряете AI в свою работу или команды Это ровно то, чем занимаются все в клубе – так что вы сможете найти единомышленников с похожими проблемами. Как работать со скептиками, как не попасть в зависимость от вендоров моделей, как не сжечь все бюджеты на токены – все эти вопросы можно обсуждать в чате и на Random Coffee. Периодически в клубе проводят хакатоны. В мае в течение двух недель 15 команд делали свои фабрики фичей с разными архитектурами. В августе ребята стартуют новый хакатон, где будут копать в сторону самообучающихся агентов и долгосрочной памяти. 🔗Детали, расписание, заявки в клуб

Страх начать сначала Три месяца назад я пытался улучшить сканер кодов маркировки на Android, и первый подход не дал мне ровным счётом ничего, что даже загнало меня в некоторую апатию. Тогда пришлось перейти к тяжёлой артиллерии, а именно к написанию кастомного пайплайна на C++ с использованием MediaPipe. Это было то ещё приключение: весь код, разумеется, писался агентами, а я пытался понять, что там вообще происходит 🚬 В итоге мне удалось добиться определённых успехов в улучшении качества сканирования, однако работа с MediaPipe была больше похожа на ад: 🔘Как это добро дебажить 🔘Как нормально поставлять собранную либу в Kotlin-проект 🔘Как задать критерии успеха, ведь сканирование статического изображения ≠ сканированию с камеры Я отложил эту задачу, переключился на другой проект, а теперь вернулся к ней снова. Логичным шагом было бы продолжить с того, на чём я остановился. Раньше я наверняка так бы и сделал, потому что банально было бы жалко бросать свои труды. Но сейчас сам код стал почти бесплатным, поэтому я решил начать с чистого листа. Я запустил deep research по поиску лучшего пайплайна для сканирования, который почти съел все лимиты. В итоге я получил лютейший нейрослоп, в котором не было ровным счётом ничего полезного 😔 Но я не стал отчаиваться и решил сделать ещё один подход к реализаёции уже без MediaPipe, но с обновлёнными LLM. И, как ни странно, буквально за час получил полностью работающее решение, которое оказалось на голову выше всего того, что я делал раньше 😎 Разумеется, мне всё ещё далеко до коммерческих решений, но благодаря тому, что я не побоялся начать сначала, теперь я хотя бы могу всё это дебажить, итеративно улучшать и смотреть, что работает, а что нет. Именно на таких задачах можно оценить, насколько улучшились LLM'ки за последнее время, потому что в повседневной разработке очень сложно заметить реальную разницу.