Мобильное Чтиво

Робот-пылесос прибирается в legacy 🤪

Чем больше я работаю с AI на рабочих проектах и пет, и чем больше общаюсь с другими ребятами в коммьюнити, тем сильнее вижу разницу между greenfield и legacy.

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

А в legacy все сильно хуже. Даже если это не какое-то ужасное древнее legacy. Достаточно скрытых знаний о том, почему здесь написано именно так и что нельзя случайно сломать рядом.

И к чему это приводит?

Приходится писать много документации и рулов, guardrails, отдельно объяснять агенту:
• какие старые подходы нельзя копировать
• где код выглядит нормально, но на самом деле это legacy
• какие неочевидные связи нельзя сломать
• как у нас принято писать новый код

Это все помимо того, что все надо покрывать тестами.

И все равно AI периодически смотрит на старый код и решает "О, значит здесь так принято, напишу ка я так же"😅

В какой-то момент начинаешь думать: а может, проще все переписать с нуля? Ну реально!

Конечно, я не предлагаю срочно переписывать все приложения. Это долго, дорого и риски. Хотя некоторые я бы все-таки переписал 😄

Но где-то точно существует граница, после которой поддерживать legacy с AI становится сложнее, чем запустить агента на пару недель и попросить его собрать все заново. Где эта граница?

У нас в Дринките 🐳 пока появился другой подход. Я назвал его "робот-пылесос".

Мой коллега Дима Максимов сделал автономного агента. Он сам берет небольшие задачи и создает PR. Нам остается все проверить и смержить.

И одна из его задач: постепенно прибираться за legacy! И я пока что очень в восторге!

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

Так же и здесь. Агент постепенно берет маленькие старые куски кода и приводит их к текущим подходам команды.

Главное ограничение сейчас не скорость агента, а наше code review. Мы могли бы запускать его намного чаще, но тогда просто PR-ы не протолкнуть.

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

Но сама идея мне нравится!

Не пытаться однажды выделить полгода на борьбу с legacy. А запустить робота-пылесоса, который будет понемногу прибираться в фоне, пока команда продолжает работать над продуктом.

Посмотрим, насколько чисто у нас станет через несколько месяцев 😄

#AI #SoftwareEngineering #LegacyCode #AIAgents #CodeReview

Заказываем кофе с помощью AI на Youtube

Опубликовали мой доклад с весеннего Мобиуса 2026 — Заказываем кофе с помощью AI!

Там про:
• как написать свой agent loop в приложении с помощью Firebase AI Logic
• как потерять деньги, используя Firebase AI Logic
• как это потом все переписать на Koog и больше не терять денег и получить более гибкое решение!

Обо всем этом и с примерами кода — в моем выступлении!

#mobius #drinkit

🟢 Call for Papers на Android Podlodka Crew #16

Друзья, следующая Android Podlodka Crew будет 21-25 сентября!
Тема сезона:
«Android × AI: новый workflow разработки»

Я уверен, что многие из вас делают и пробуют крутые штуки на стыке Android и AI. Нас интересуют в особенности темы:
1. Новый workflow Android-разработчика с AI-агентами
2. Харнес для AI-агента, который сам пишет приложение
3. Guardrails для AI в Android-проекте
4. Rules для AI-агентов в Android-проекте
5. Figma MCP и проверка UI после генерации
6. Важен ли код, если его написал AI
7. Как растить Android-разработчиков (джунов), когда есть AI
8. Что Android-разработчику теперь нужно знать самому
9. AI для UI-тестов (journeys и не только)
10. Gemini в Android Studio против Claude и Codex
11. AI и сложные анимации в UI
12. AI-friendly Android-библиотека
13. Что AI разблокировал в Android-инфраструктуре
14. Как не превратить Android-проект в AI-slop, который развалится без агентов
15. Android AI SDLC: от дизайна и отладки до релиза и монетизации

Или другие темы именно на стыке Android и AI!

Заносите ваши заявки в наш Call for Papers!

#podlodka #ai #android

👩‍💻 Офис будущего выглядит так!

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

Я люблю работать в офисе но если честно, теперь мне сложно, потому что мне нужно всегда говорить! Да я теперь общаюсь с агентами только голосом. Я стараюсь почти не писать.

Ну и сложно сидеть в офисе и вслух довольно громко говорить просто постоянно с Клодом или с другим AI-агентом. это смешная картинка но как будто бы я бы не отказался от такого девайса прямо сейчас. ну а как еще сидеть и работать в современном офисе? Я не понимаю.

киберпанк, который мы заслужили

Этот пост был полностью надиктован голосом, без какой-либо правки, кроме заголовка там эмоджик я руками подобрал

#ai #speechtotext

Выбираем тему нового сезона Podlodka Android Crew!

Кому лень читать — переходите и выбирайте тему тут!

Сначала была мысль пойти (опять!) против течения и сделать сезон НЕ про AI.

Типа все вокруг уже говорят про AI, конференции, посты, агенты, промпты, вайб-кодинг, вот это все.

Может, нам надо быть выше этого?

Но чем больше мы обсуждали, тем очевиднее становилось: у нас у всех уже изменилась работа.

Android-разработчик сегодня работает не так, как год-два назад.
• Все (ведь все?) уже пишут код с агентами каждый день!
• Кто-то генерирует тесты
• Кто-то пытается выстроить целый пайплайн разработки
• Кто-то, наоборот, смотрит на это все и думает: “Эх, трава раньше была зеленее....”

Поэтому мы предлагает на выбор целые 2 темы про Android + AI. Именно про практику Android-разработки:
• как реально встроить AI в workflow Android-инженера
• как писать фичи, UI и тесты с агентами
• сравнивать Gemini в Android Studio, Claude, Codex для Android разработки
• как собирать feedback loop через MCP, эмуляторы, Figma, hot reload
• какие guardrails, rules, lint, static analysis и CI-гейты нужны
• где AI ломается на Android UI, анимациях, gesture handling и edge cases

Плюс у нас есть отдельный кандидат на сезон про Advanced UI: сложные жесты, шейдеры, Canvas, stylus, FPS, Remote Compose и весь этот прекрасный набор хардкорных штук!

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

Помогите нам выбрать тему нового сезона Android Crew ЗДЕСЬ!

#podlodka #android #ai

Написал TBD-плагин для AI-агентов 🤖

Я в основном работаю в Claude Code и OpenCode.

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

Для меня это плохо, потому что я люблю работать по Trunk-Based Development. То есть стараюсь резать работу на маленькие PR’ы, которые:
• можно нормально отревьюить
• можно быстро смержить
• не ломают trunk
• несут какую-то отдельную логическую ценность

Для мобильной разработки это, как мне кажется, вообще особенно важно.
У нас цена ошибки выше: билд, QA, сторы, rollout, пользователи на разных версиях приложения.

Быстро просто задеплоить фикс нельзя, как на беке.

А еще в мобилке куча неочевидных мест, которые AI может случайно сломать.

Поэтому маленькие PR’ы здесь еще позволяют не потерять контроль над тем, что AI меняет в приложении.

И почти каждый раз я вручную объяснял агенту, как именно разбить задачу:
• где сделать безопасный первый PR
• где нужен feature toggle, где лучше branch by abstraction
• где механические изменения надо вынести отдельно и так далее.

В итоге вынес это всё в отдельный плагин 🧩
Trunk-Based Development for Coding Agents

Как использовать в Claude Code:

/using-tbd do the gift-cards task from our Jira, SHOP-1234


Можно комбинировать с другими штуками, например с Superpowers:

/using-tbd /using-superpowers do SHOP-1234


В OpenCode slash-команд нет, поэтому можно просто попросить загрузить using-tbd skill.

Что делает плагин:
• Сначала смотрит, помещается ли задача в один нормальный PR.
• Если нет, то раскладывает все на цепочку маленьких PR’ов.
• Пишет decomposition map в docs/tbd/decompositions/.

Дальше агент идет по одному PR за раз, а не пытается сделать всё сразу.

То есть это не про то, как писать код, не про TDD, не про конкретный стек и не про ваш процесс.
Это просто слой, который помогает держать нормальные границы PR’ов, когда с кодом работает AI.

Если тоже страдаете от больших AI-generated PR’ов попробуйте 🙌

Вот репозиторий:
https://github.com/makzimi/tbd

Навалите фидбека, поставьте звездочку ⭐️

#mobile #tbd #ai #agents #claude

🚧 Не дай AI свернуть не туда!

Когда много работаешь с AI-агентами, быстро появляется красивая мечта типо:

«А давайте агент сам напишет приложение, а мы просто посмотрим результат» 😅

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

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

Сейчас это часто называют harness. Термин довольно растяжимый, и, кажется, все понимают его немного по-своему.

Мое текущее понимание (особенно для мобильной разработки) такое:

• все, на что можно ответить true / false, должно проверяться статически. Не AI. Не на ревью. Мы итак к этому стремились всегда. Но сейчас прямо супер надо. Что я сюда отношу:
• все виды тестов (прямо по всей пирамиде идем)
• линтеры
• статические чекеры
• архитектурные тесты
• тесты зависимостей между модулями
• любые скрипты, которые могут сказать: “так можно” или “так нельзя”

Потому что если правило можно формализовать, значит его нужно формализовать.

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

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

Ещё подключили проверки зависимостей между модулями через Module Graph Assert.
Чтобы модули зависели друг от друга только так, как мы договорились, а не как случайно получилось.

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

Пусть AI думает, генерит, предлагает решения.
А все, что можно проверить тупо и однозначно, пусть проверяют статические анализаторы.

А вот там, где нужен reasoning:
• соответствует ли решение задаче
• не потеряли ли мы важный edge case
• не выглядит ли решение неоптимально
• не создали ли мы костыль

Вот там уже подключаются люди, AI code review.

В общем, мой текущий вывод такой:

AI-агентам нужны стены, рвы и автоматические ворота!

💬 А что вы уже добавляете в свой harness для мобильных приложений?
Какие тесты, линтеры, чекеры или правила реально помогают не дать AI и людям свернуть не туда? Навалите в комменты ваш опыт, мне реально очень интересно!

#android #ai #architecture #testing #kotlin #mobiledev

🤖 AI на собеседованиях: как теперь правильно?

Кажется, все уже поняли, что AI с нами навсегда.

Ну или почти все 😅
(иногда встречаю людей, которые всё ещё делают вид, что ничего не поменялось, но да ладно)

Что лично я вижу:
единого консенсуса, как теперь проводить интервью по-новому пока нет.

Недавно я проходил собеседование, где задача была написать приложение. Но не “запрещаем AI”, а наоборот: "пиши с AI!"

Ну т.е. пиши так, как ты реально работаешь, максимально используя AI-агентов.

Формально это всё ещё был лайв-кодинг. Но по факту фокус сильно сместился. Пока AI-агенты писали код, мы могли обсуждать:
• почему я разбиваю задачу именно так
• какие инструкции даю агентам
• где проверяю результат сам
• почему выбираю такое архитектурное решение
• где нужен TDD, а где это лишнее
• как не превратить AI в генератор случайного мусора
• какие инженерные практики остаются обязательными

И это, на мой взгляд, очень похоже на реальную работу!

Потому что суть профессии не изменилась.
Мы всё ещё должны понимать архитектуру, код, тесты, границы ответственности, edge cases, качество решений.

Просто теперь рутину (написание кода) можно сильно ускорить.

AI не отменяет инженерные практики. Он их усиливает. Ну или усиливает хаос, если практик не было 😅

И вот мне стало интересно.

А как сейчас компании адаптируют другие типы интервью?

Например:
• алгоритмы и структуры данных
• system design
• обычные technical questions
• архитектурные секции

Там AI тоже можно использовать, но уже не так очевидно, как именно. Я пока вот не понял как лучше.

💬 Расскажите, как у вас с этим?
Как вы используете AI на разных типах секций? Какие прикольные инсайты можете рассказать?

P.S. Да, я был в отпуске, хорошо отдохнул, поэтому не было постов. Сейчас со свежей головой буду накидывать чаще свои мысли!

#ai #interview #softwareengineering #androiddev

🇰🇿 Увидимся в Алматы на Android Meetup

28 мая буду выступать на Bereke Android Meetup в Алматы.

Расскажу про наш опыт постепенного перехода на Kotlin Multiplatform в Drinkit.

О чем буду рассказывать:
• как заходить в KMP постепенно
• что у нас сработало, а что не очень
• как смотреть на это с архитектурной точки зрения
• что по размеру бинарников
• и как быть с командными вопросами 😅

Кроме меня будут ещё классные доклады:
• Паша Королев про WebView и Compose
• Данияр Амангелды про Remote Compose
• Анель Кадырова про api/implementation модули и связность компонентов

📍 Алматы, MOST IT Hub
🗓 28 мая, 18:30
регистрация в bio

Приходите, буду рад всех видеть!

#kmp #android #ios #meetup

💃 Наконец-то нормальный changelog для Jetpack Compose

Если у вас тоже, как у меня, были проблемы чтобы понять, а что нового изменилось в Jetpack Compose BOM, и надо было ходить по страницам типо такой и собирать изменения, то вам понравится, этот пост 😅

Вася Малеев сделал сайт, где это легко увидеть в одном месте! Мне очень нравится!

Можно накидать звездочек на github, чтобы Google заметил и сделал сам нормальное решение типо такого!

#jetpackcompose #compose #android

👩‍💻 Генерация сетевого слоя из Swagger

Так вышло, что долгое время в проекте Drinkit 🐳 мы писали api модельки и методы руками. Наша структура проекта не была удобная к тому, чтобы быстро из коробки взять какой-то инструмент и сгенерить нам сетевой слой.

Но в прошлом году мы это исправили, и Дима Максимов сделал нам генерацию сетевого слоя из Swagger, теперь нет случайных ошибок, когда поставил nullable тип, хотя он не nullable и т.п.

Дима написал про это статью, а точнее Первую часть. Будет вторая, я тоже ее запощу потом.

У кого еще нет автогенерации сетевого слоя из Swagger — рекомендую!

#swagger #api #generation

💚 Mobius 2026 Spring. Как это было

Я приехал на Mobius рассказать про AI, но главое оказались люди!

Я выступал на Mobius уже в 4-й раз, но впервые в офлайне. Так что для меня это было одновременно и знакомый, и новый Mobius 😅

Про доклад все просто. Рассказал про нашу AI-фичу в Drinkit, Koog, AI-агента прямо на клиенте, всякие архитектурные трейдоффы и вот это все.

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

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

Отдельно было очень приятно, что подходили ребята и говорили хорошие слова про Drinkit 🐳 Это прямо очень ценно. Спасибо большое, гайз 💙

Еще мне понравилось, как Mobius зашел в AI-тему. С одной стороны, AI было достаточно много. С другой стороны, конференция не превратилась в «щё один AI ивент, а все-таки осталась про мобилку. Большое спасибо за это ПК!

Организаторам большой респект. Очень классный, сильный ивент.

Ну и всем, кто был на Mobius, тоже спасибо. Вы классные :)

Скоро начинаю свой доклад на Мобиусе!

Присоединяйтесь!

Пасхалка в моем докладе на Mobius 🌌⚔️

Это один из моих слайдов (разделительный слайд) на завтрашнем выступлении.

Всего у меня будет 7 разделов. Я решил их так назвать:

Episode I — Revenge of the Customizer
Episode II — AI New Hope
Episode III — The Empire Codes Back
Episode IV — The Agents Awaken
Episode V — The Firebase Menace
Episode VI — The Rise of Koog
Episode VII — The Last Takeaways

Да, разделов всего 7, а не 9. Не хотел искуственно добавлять еще 2 просто так 😉

Увидимся завтра! ✋

#mobius #easteregg #conference

🚀 Drinkit переезжает на KMP!

Ну ладно, переезжаем пока громко сказано 😅
Но первая фича на Kotlin Multiplatform у нас уже есть!

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

В итоге мы пошли аккуратно: вертикально режем фичи и постепенно выносим общую доменную логику в shared-модуль.

Сейчас сделали первую фичу:
• доменный слой общий на KMP
• UI остаётся нативный на Android и iOS

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

Так что можете нас поздравить 🎉
А ещё жду вас в комментариях с мнениями, почему это большая ошибка, почему мы зря начали и какие грабли я, конечно же, скоро соберу 😅

Пока что я доволен so far.

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

🎁 В закрепе розыгрыш промокода на Мобиус!!! 🎁

#kmp #kotlin #android #ios #mobiledev #drinkit