Android, iOS, Windows Phone и прочие
Научился программировать в 30 лет — и создал приложение для правительства Великобритании. Рассказываю всё: как найти идею, выбрать стек, использовать ИИ и продвинуть продукт без команды и бюджета.
Почти каждый фронтенд-разработчик однажды задаётся вопросом: что на самом деле происходит внутри современных фреймворков. Почему изменение переменной автоматически обновляет интерфейс? Как библиотека понимает, что именно нужно перерисовать?
Помните времена, когда пуш-уведомление реально что-то значило? Телефон вибрировал, и ты точно знал: случилось что-то важное. Такси подъехало. Деньги списались. Начальник написал что-то срочное (ладно, обычно не срочное, но хотя бы по делу).
Это был 2016 год.
На дворе 2026-й. Шторка уведомлений среднего пользователя превратилась в мусорный бак, куда маркетологи сбрасывают свои KPI с маниакальным упорством.
Мы умудрились взять гениально простой инструмент доставки ценности и превратить его в систему психологического давления. Давайте разберем, где конкретно мы свернули не туда, и как разработчику не участвовать в этом цирке с конями.
Кажется, мы приближаемся к моменту, когда генерация кода перестанет быть игрушкой и станет обычным инструментом разработки. Уже сейчас можно попросить модель написать API, SQL-запрос или даже кусок архитектуры сервиса. Но что будет дальше, когда такой подход станет стандартом? Изменится ли профессия разработчика или просто появится ещё один инструмент вроде IDE?
В этой статье я попробую разобрать, как генерация кода может изменить сам процесс разработки. Не в теории, а с инженерной стороны: архитектура, поддержка, технический долг, debugging и то, как вообще читать код, который писал не человек.
Пару месяцев назад я решил провести небольшой эксперимент. Попробовать писать сервис почти полностью через генерацию кода. Не просто отдельные функции, а прямо весь сервис: API, базу данных, обработчики.
Честно говоря, в какой-то момент стало немного странно. Ты вроде разработчик, но код пишет не совсем ты.
Возникает ощущение, будто ты больше архитектор или редактор кода.
И тут появляется вопрос.
Если генерация станет стандартом, кем вообще будет программист?
Тем, кто пишет код?
Тем, кто проверяет код?
Или тем, кто придумывает системы, которые этот код потом генерируют?
Попробую поделиться наблюдениями.
После одного из релизов у FanBattle приложение перестало открываться у части пользователей. Проблема затронула около 5% аудитории. Баг исправили быстро, но пользователи не могли даже узнать, что вышла новая версия — приложение падало раньше, чем успевал появиться интерфейс.
Разбираем, как команда решила проблему через раннюю инициализацию SDK и force update.
Как часто вы слышите что-то о протоколе WebSocket? А как часто видели его в проектах? Продакшн? Андроид? Что? Его кто-то использует?
А теперь представьте, что перед вами стоит задача внедрить WS в крупный продакшн проект с нуля. С чего начать? Как подступиться?
Худшая новость для многих SaaS‑команд в ближайшие годы (думаю, уже в этом году заметим) пользователь может перестать пользоваться вашим приложением, но продолжить пользоваться вашим сервисом.
Еще недавно цифровой продукт был устроен предельно понятно. Компания делала приложение, проводила продуктовые исследования, проектировала пользовательские сценарии, раскладывала кнопки, экраны, роли и ограничения. А пользователь либо принимал эту логику, либо уходил.
То есть сама модель была такой:
«Вот наш интерфейс. Вот наш сценарий. Пользуйтесь так, как мы задумали».
Эта модель не исчезнет завтра. Да и на текущий момент она устраивает болшинство пользователей, благодаря сформировавшейся десятилетиями потребительской привычке «используй что дают». Но именно сейчас она начинает терять монополию, потому что между пользователем и сервисом появился новый слой – агенты. Не просто чат-боты, которые подсказывают, а инструменты, которые уже умеют искать данные, ходить по сайтам, нажимать кнопки, связывать сервисы между собой и выполнять цепочки действий. OpenAI вывела Operator как браузерного агента, Anthropic продвигает Computer use и MCP, Microsoft на Build 2025 прямо говорит об open agentic web, а OpenAI отдельно документирует работу с remote MCP servers и коннекторами для доступа к внешним сервисам. 
И вот здесь начинается главное изменение – раньше продуктом был интерфейс, теперь продукт всё чаще смещается в три других слоя:
Идея сделать мобильное приложение у меня была давно. Это была своего рода идея фикс – решить свою собственную рабочую боль. Боль малоподвижности в течение рабочего дня.
С возрастом я стала замечать, что режим «не спать ночами, где-то гулять, а потом с утра бахнуть стаканчик кофе и продолжать работать как ни в чём не бывало» больше не работает. После 30 лет тело стало очень быстро напоминать о себе.
Если я плохо поспала или недостаточно двигалась несколько дней подряд, энергия падала стремительно. Уже после обеда я начинала думать о том, как дожить до вечера. А после понедельника – как дожить до выходных. Качество жизни стало от этого страдать.
Если в твоей жизни есть что-то кроме работы, то на это часто просто не остаётся сил. В лучшем случае хватает ресурса только на работу. В худшем – не хватает даже на неё, и приходится дотягивать на морально-волевых и кофе. К вечеру состояние «ватки»: диван, сериал, чипсы – и это весь дофамин, на который остаются силы и желание.
А если к этому добавляется еще и выгорание, как было в моем случае, то состояние энергичности вообще становится забытым явлением, а каждый день похож на уговоры самой себя хотя бы что-то сделать.
В новом выпуске замена циклов рекурсией и Android на десктопах, нарезание Android-монолита и промпт-контракты, снижение комиссии в Play Store, потери органики и что с этим делать, скрытый bottleneck сборок и многое другое. Заходите!
До пятой версии главный экран был функциональным, но визуально скучным. Типичный Material Design без характера. Я получил несколько честных отзывов — в том числе жёстких — и решил переделать всё.
Swift известен системой pattern matching. Большинство разработчиков используют её в switch, иногда в if case или guard case. Но в языке есть ещё одна конструкция, которую многие никогда не видели — for case let.
Интересно, что даже разработчики с несколькими годами опыта часто о ней не знают. Более того, в официальной документации Apple она упоминается лишь вскользь, потому что технически это не отдельная фича языка, а комбинация существующих механизмов. Тем не менее, эта конструкция может заметно упростить код.
В этой статье я хочу разобраться:
Дизайн – это не только то, как что-то выглядит. В разработке продукта дизайн формирует то, как пользователи воспринимают его, как взаимодействуют с ним и насколько последовательно бренд проявляется на каждом экране.
Flutter предоставляет для этого мощные инструменты, но истинное мастерство в создании тем оформления выходит далеко за рамки изменения нескольких цветов или шрифтов. Оно включает в себя создание единого языка дизайна, его предсказуемое применение ко всем компонентам, управление масштабируемостью и обеспечение доступности, производительности и удобства сопровождения пользовательского интерфейса по мере развития продукта на мобильных устройствах, в веб-среде и на настольных компьютерах.
В работе постоянно сталкиваешься с багами. В топе самых неприятных — крэш. Еще хуже — когда он неочевидный, и сразу сложно сказать, откуда "растут ноги". В этой статье попробуем воспользоваться LLDB для разбора проблемы на реальном примере.
Это первая часть цикла статей о разработке системы публикации структурированных интерактивных постов через Telegram Bot API. В следующих частях — архитектура, рендеринг шаблонов и управление доступом к закрытым чатам.
С чего всё начинается
Представьте типичную задачу: пользователь вашего сервиса хочет опубликовать в своём Telegram-канале структурированный пост. Не просто текст — а пост с заголовком, многострочным описанием, блоком реквизитов, динамическим индикатором прогресса и интерактивными кнопками. Пост, который после публикации будет обновляться в реальном времени по мере поступления новых данных. Пост, под которым есть кнопка, открывающая отдельный диалог в боте — и всё это происходит без перехода в браузер, без форм, без лишних шагов.
На первый взгляд — ничего сложного. Telegram Bot API умеет отправлять текст, прикреплять медиа, рисовать inline-кнопки. Но именно в этот момент начинается то, что разработчики называют «дьявол в деталях».
На практике задача немедленно разбивается на несколько инженерных проблем, каждая из которых требует отдельного решения. И если пропустить хотя бы одну — система либо ломается при первом же граничном случае, либо создаёт такой UX, что пользователи просто не понимают, что происходит.
Не Vibe-Coding, а инженерия с AI: Как за полгода я сделал Android‑приложение «Трекер привычек» с социальными функциями, синхронизацией, офлайн-режимом и виджетом
Но не в самом приложении Max – речь пойдёт о продукте стороннего разработчика внутри мессенджера, который почему-то не хочет исправлять очевидную и крайне серьезную ошибку своего сервиса.
Привет! Меня зовут Абакар, я работаю главным техническим лидером разработки в Альфа-Банке.
Когда-то давно мне приходилось работать над стартапом, цель которого была — форкнуть основной клиент приложения Telegram и доработать его, а именно добавить в него ИИ-чат-ботов, с которыми можно было общаться. Но это было в далёкие времена, когда ИИ ещё не был на таком «хайпе», как сейчас.
Боль каждого лида — это ответы на сообщения в чатах, и вот недавно я задумался: а что, если спасти себя и заодно опробовать ИИ? Попробовать добавить в Telegram функциональность генерации ответа на сообщение и сделать это без глубокого погружения в исходный код, просто как продакт, который просит своего разработчика что-то для него сделать. Для этих целей я выбрал инструмент — Cursor, с которым общался в визуальном редакторе. Давайте посмотрим, получилось у меня или нет!
Большинство разработчиков думают об офлайн-режиме в последнюю очередь - когда приложение уже готово, дизайн согласован, а PM давит на дедлайн. В результате пользователь видит белый экран, зависший спиннер или, что хуже - молча потерянные данные. Эта статья про то, как выстроить честный UX для состояний без сети: от психологии тревоги до кода с экспоненциальным откатом, от визуального языка ошибок до стратегий разрешения конфликтов. Всё это пригодится при разработке любого мобильного или веб-приложения, которое работает в условиях нестабильного соединения - а таких большинство.
На прошлой неделе ездил на OpenTalks.AI, и на кофе-брейке в какой-то момент заговорили про будущее джунов в эпоху ИИ-кодинга. Тема уже не новая, но какого-то понятного ответа у индустрии как будто бы и нет, даже топовые спикеры на профильных конфах и митапах часто напрямую говорят - не знаем, что делать с джунами.
Если вы хотите узнать ещё больше об организации процессов ML-разработки, подписывайтесь на наш Телеграм-канал Варим ML
Давайте вообще кратко вспомним, в чём проблема. До текущего момента стандартный путь разработчика или ML-инженера выглядел примерно так:
Мы привыкли думать, что архитектура программ рождается из требований бизнеса, бюджетов и технологий. Но в самом начале любого проекта лежит архитектура мышления — разработчика, заказчика, пользователя. Эта статья и ряд других в серии «каскад» — попытка рассмотреть проектирование как отражение когнитивных механизмов человека. Не UX, не поведение пользователей, а именно то, как фазы нашего мышления формируют будущую систему. И главное — как, поняв это, создавать более устойчивые и человечные архитектуры.