Разработка мобильных приложений *

«Джунов больше не нанимаем»: как ИИ‑агенты меняют разработку и роль инженера

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

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

На нашей конференции про ускорение разработки AI Boost выступил Александр Поломодов, технический директор Т-Банка. Он подробно рассказал, как команды переходят от простых ИИ-помощников к полноценным агентам, которые действительно влияют на скорость и качество разработки. Теперь запись доступна на YouTube — и это возможность взглянуть на внедрение ИИ-агентов глазами тех, кто делает это в проде, а не в демо-среде.

Вы узнаете:

• Как сделать агентов рабочим инструментом: ключевой принцип — «проницаемость агента». Важно понимать, влияет ли он на время инженеров, какие метрики собирать и как интегрировать агентов в SDLC.

• Почему миф «ускорим всё и снизим косты» не работает: ИИ ускоряет не всё. Реальные примеры показывают новые риски и необходимость перестройки процессов.

• Как крупные команды строят агентную разработку: опыт Т-Банка — что автоматизировать первыми, какие роли и доступы давать агентам и как выглядит работа команды, когда агенты становятся её частью.

• Как меняется роль инженера и тимлида: часть рутины уходит к агентам. Инженер всё чаще становится «лидом команды агентов», растут требования к middle/senior, а задачи джунов частично автоматизируются.

• Как измерять эффективность ИИ-агентов: артефакты — не метрика. Важно смотреть на реальное влияние на скорость, избегать ложных показателей и встроить измерения в ежедневный процесс.

• Какие навыки нужны уже сейчас: умение формулировать задачи как сценарии, проектировать роли агентов и отвечать за процессы, а не только за код.

Спикер:

Александр Поломодов — технический директор T‑Tech.

«Мы переходим от простых ИИ‑помощников к агентам, которые реально влияют на скорость и качество разработки. Но без правильных процессов и метрик это остаётся только красивой демо‑картинкой.»

Смотрите полную запись доклада на YouTube — особенно если вы:

• руководите разработкой или продуктом и хотите понять, где агенты дадут реальную отдачу, а где нет;

• отвечаете за инженерную культуру и планируете, как изменится роль разработчиков в ближайшие 2–3 года;

• уже используете Copilot/Cursor и хотите перейти от «вайб‑кодинга» к системному использованию ИИ‑агентов в SDLC.

Все еще тестируете мобильные приложения в браузере?

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

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

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

Курс подходит для новичков. Для прохождения достаточно базовых знаний работы с компьютером. Развивайтесь и станьте экспертом в Mobile QA вместе с Академией Selectel.

Как внедрить ИИ в разработку и подружиться с безопасниками

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

Чтобы разобраться, как это работает в реальных процессах, мы собрали за одним столом лидеров из Сбера, Positive Technologies, RuStore и Ozon FinTech. Эксперты поделились практиками, ошибками, риск-моделями и объяснили, почему безопасность — это не тормоз, а часть архитектуры внедрения ИИ.

Теперь запись доступна на YouTube. Вы узнаете:

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

• Три ключевых AI-риска, про которые редко говорят вендоры. Злоупотребление моделями, небезопасный код, сгенерированный без проверки, и ИИ-агенты с доступами ко всему — эксперты поделятся кейсами.

• Как меняется соотношение безопасности и скорости при масштабировании. Почему крупные компании осторожнее, чем стартапы, и как учитывать репутационные и финансовые риски при внедрении автоматизации.

• Что делать, если ИИ сгенерировал уязвимый код, и это привело к взлому системы. Где проходит реальная граница ответственности между разработкой, безопасностью и инструментами.

• К чему готовиться в части регулирования. Почему регулирование ИИ будет идти по пути любых инженерных технологий, что происходит в Китае, и какие требования появятся первыми.

• Как безопасники и разработчики приходят к партнёрству.
  Почему зрелые команды кибербеза не тормозят внедрение технологий, а помогают строить безопасный процесс — и почему к 2026 году в компаниях появятся команды, частично состоящие из ИИ-агентов.

Спикеры:

• Сергей Марков — Директор по развитию технологий ИИ, Сбер.

• Светлана Газизова — Директор по построению процессов безопасной разработки, Positive Technologies.

• Александр Толмачев — ex-CDO Ozon FinTech, преподаватель Сколково и ВШЭ.

• Сергей Кузнецов — Руководитель команды мобильной инфраструктуры, RuStore.

«Большинство серьёзных инцидентов происходит не из-за ИИ, а из-за плохо выстроенных процессов вокруг него. Агент с лишними правами доступа может привести к краху всего.»

— Сергей Марков, директор по развитию технологий ИИ, Сбер.

Смотрите полную запись круглого стола на YouTube — если вы внедряете ИИ, работаете с чувствительными данными или хотите адаптировать SDLC под новые риски.

Тестировщики не нужны? Shift-left подход меняет даже ИИ

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

Мария Лещинская, Head of QA Surf и кандидат технических наук по ИИ и ML, проверила это на практике. Она с командой комбинируют shift-left подход и автогенерацию автотестов, экспериментируют с MCP-решениями, генерируют десятки проверок. 

На основе опыта Мария посчитала реальную экономию времени и собрала лайфхаки внедрения ИИ в тестирование. Поделилась ими в своем выступлении на конференции AI Boost. Теперь запись есть на YouTube. 

Вы узнаете:

• Что именно меняет shift-left подход. Какие дефекты ловятся раньше всего, почему ошибка на проде ×100 по стоимости и как ранние проверки делают релиз предсказуемым.

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

• Как выглядит полный shift-left цикл на практике.

• Как добиться качественной автогенерации автотестов.

«Сейчас очень важны люди, которые системно понимают, как это должно работать, какие есть нюансы — и какие из них должен решать человек, а какие ИИ.»

— Мария Лещинская, Head of QA Surf

А еще в видео много лайфхаков для QA: 

• Как правильно использовать JSON для снижения количества ошибок.

• Много примеров рабочих промптов.

• Стратегия, как один QA + ИИ закрывают работу целой мини-команды.

В общем, меньше слов — смотрите запись выступления на YouTube.

Хотели ускорить разработку с ИИ, а получили сопротивление и хаос: как работать с командой

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

Евгений Сатуров, CTO Mobile в Surf, провел 50+ сессий парного программирования, понаблюдал, как разработчики впервые работают с ИИ, и собрал 40 страниц выводов. А потом рассказал обо всем на конференции AI Boost. Теперь выступление есть на YouTube.

Вы узнаете:

• Почему ИИ-кодинг — это отдельный навык, а не автоматическое ускорение разработки.

• Какие 5 ключевых страхов чаще всего мешают командам (стоимость, недоверие, потеря контроля, замедление, отказ от результата).

• Как ИИ подчеркивает слабые места постановки задач и почему качество промпта напрямую влияет на качество решения.

• Чем различаются системные, таск- и мета-промпты, и зачем их понимать каждому разработчику.

• Почему ИИ-агенты эффективнее на цельных задачах, чем на мелких правках.

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

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

Евгений Сатуров, CTO Mobile в Surf

В видео — много практики, наблюдений и реальных кейсов, как ИИ реально помогает командам — и какие ошибки лучше не повторять. Смотрите на YouTube.

Как научить приложение работать офлайн?

В новом выпуске подкаста Mobile Developer об этом рассказывает Данила Горячкин, iOS-инженер в Авито. Даня не понаслышке знаком с потребностью в мире Wi-Fi и развитой мобильной сети создать приложение, которое может работать без интернета, — а потому ему точно есть, чем поделиться.

Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.

What's new in Dub Dub — сайт, на котором собрали все анонсы WWDC с 2015 года. Есть вкладки по разным операционным системам Apple, списки аппаратных обновлений, фреймворков, API, интерфейса, версий Swift, Xcode, SF Symbols и других инструментов для разработчиков. Для фреймворков и API предусмотрели ссылки на страницы в официальной документации.

ИИ в продакшн: где заканчивается хайп и начинается реальная польза

Полгода назад Дарио Амодей из Anthropic заявил: к сентябрю 2025 года 90% кода будут писать нейросети — не помощники, а полноценная замена разработчиков.
Наступил ноябрь. Пророчество не сбылось — но IT-индустрия изменилась радикально. Теперь в компаниях раскол — кто-то жалуется, что нейросети только перегружают всех, а кто-то обучает ИИ на замену рутине.

На конференции AI Boost эксперты от Сбера, Магнита, Атол и Surf обсудили, что изменилось за последние полгода и как ИИ-агенты на самом деле работают в продакшене разработки. Получилась честная и горячая дискуссия, как команды бигтеха и ИТ-компаний переходят на ИИ и что стало с ролью разработчика. Смотрите запись самого обсуждаемого круглого стола конференции, из которой узнаете:

• Почему люди всё ещё пишут 90% кода и как команды учатся использовать AI-агентов в реальной работе.

• Чем хороший джун отличается от ML-модели и что ждёт джунов в мире, где их задачи уже умеет решать AI.

• Можно ли доверить нейросетям проектирование сложных систем и где проходит граница ответственности человека.

• Стоит ли перестраивать SDLC ради ИИ или достаточно встроить новые инструменты в существующие процессы.

• Почему спагетти-код может стать нормой.

• Может ли вообще ИИ заменить разработчиков — или все это так и останется хайпом.

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

Евгений Сатуров, CTO Mobile в Surf

Спикеры:

• Дмитрий Панычев — Head of Seller Development в Magnit OMNI

• Глеб Михеев — лидер трайба «Цифровой ассистент» в Сбере, автор телеграм-канала «Уставший техдир»

• Владимир Кочегаров — Head of QA в компании Атол

• Евгений Сатуров — CTO Mobile в Surf

Смотрите полную запись круглого стола на YouTube.

Dart/Flutter: с чего начать, чтобы не страдать

Привет! На связи Иван и Михаил, Flutter-разработчики из Финама. Когда мы начали писать на Flutter, поняли — граблей тут много, и на некоторые мы уже успели наступить, собрали бинго и готовы рассказать, где они поджидают. Делимся «анти-чеклистом» — вдруг поможет сэкономить время и нервы:

«Книга — лучший подарок», но не в этом случае

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

Что делать? Читать документацию, она обновляется. Поначалу может быть трудно вникнуть, опираясь только на нее. На этот случай есть запасной вариант — пройти какой-нибудь годный курс (вроде Udemy). Выбирайте те, где обновления выходят после каждого релиза.

Где брать актуальную информацию

Чтобы не отстать, нужно искать и читать свежие статьи про Flutter и Dart. Из русскоязычных источников нам помогает, конечно, Хабр, а еще рекомендуем ТГ-канал Amiga. Хорошие статьи на английском выходят на Medium. На Youtube-канале Flutter регулярно публикуют интересные видео. А еще мы попробовали лайфхак с нейросетью: она собирает дайджест свежих материалов за неделю. Удивительно, но это правда работает.

Начни со стейт-менеджментов и правильной архитектуры приложения

Самая частая боль новичков — хаос в коде. Мы видели проекты, где бизнес-логика жила прямо в build(). Всё работало… до первого бага.

Как действовать:

• Начните с простого setState — это базовый способ управления состоянием. Затем попробуйте пакеты Bloc, Riverpod — почувствуете разницу в читаемости и структуре.

• Изучите основы чистой архитектуры: это позволит вам быстрее понимать чужой код и лучше разбираться в своем.

• Хотите потренироваться? Попросите AI сгенерировать пример проекта с Bloc — и разберите его построчно. Или обратитесь к статьям.

Не бойся проблем при сборке

При сборке проекта ты скорее всего столкнешься с ошибками компиляции и в 90% случаев это будут ошибки, связанные с Xcode и Gradle. Не нужно паниковать, Flutter достаточно умен и в большинстве случаев предложит тебе решение. Если не было предложено решение или оно не сработало — не беда, первая ссылка в гугле вероятнее всего решит твою проблему. И не забывайте про старый дедовский способ перезагрузки:

flutter clean

flutter pub get

В топку тяжелые среды, работай по четвергам в Visual Studio Code

Среда разработки — твой основной инструмент, ты будешь работать в ней 99% своего времени, а значит она должна быть удобной и комфортной для тебя. Для Flutter есть две основные IDE: Android Studio и Visual Studio Code. Android Studio — мощная, с готовыми тулзами и анализаторами, но тяжеловесная. VS Code — лёгкий, быстрый и гибкий.

В Финаме мы работаем в VS Code — там проще интегрировать CLI-инструменты, автогенерацию кода и кастомные скрипты. Но выбор — это вопрос привычки: рекомендую попробовать обе. Главное, чтобы IDE не тормозила, когда запускаешь hot reload 20 раз в час. Я знаю людей, которые переходили с Android Studio на Visual Studio Code, но не знаю обратных примеров.

Логике в UI не место

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

Используйте стейт-менеджеры. Логика должна быть отделена от UI — это облегчает поддержку, переиспользование и покрытие тестами. 

Делите UI на независимые виджеты

Если экран превращается в тысячу строкового монолита — значит пора рефакторить. Разбивайте интерфейс на маленькие, самодостаточные виджеты (например: заголовок, список, кнопки). Это упрощает чтение, тестирование и повторное использование компонентов. И старайтесь ограничивать один экран не больше 150-200 строками кода.

Async — не просто await

Асинхронное программирование в Dart требует внимания:

• Оборачивайте важные вызовы в try/catch.

• Используйте async/await для читаемого кода; а если используете .then(), не забывайте обработать

Как AI меняет разработку прямо сейчас — приглашаем на прямой эфир 31 октября в 11:30

«Забудьте всё, чему вас учили в университете!» — построить карьеру, ни разу не услышав этой фразы, не удалось, пожалуй, ещё ни одному разработчику. Сегодня всё, что казалось нам очевидным и понятным, снова ставится под сомнение. Искусственный интеллект стремительно меняет правила игры, пока вы даже не догадываетесь об этом.

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

Евгений Сатуров, CTO мобильной разработки Surf, расскажет, какие «умные» инструменты уже используют в серьёзной разработке сегодня, что они умеют и как изменят рынок труда и роль разработчика в ближайшие годы.

Бонусы для участников:

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

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

Когда эфир: 31 октября, 11:30 (МСК).
Где: VK Video.

Как я сделал blur и линзу в Jetpack Compose

Всем привет! Меня зовут Владимир, я мобильный разработчик в «Финам». В одном из недавних проектов нужно было добавить в интерфейс Jetpack Compose визуальные эффекты поверх контента, например размытый хедер или движущуюся «лупу». 

Обычно такие приемы встречаются в играх, где весь экран — это фактически полотно для рисования OpenGL. В классической XML-разметке UI я с таким не сталкивался, поэтому пришлось довольно глубоко погрузиться во внутреннюю кухню Compose. Этот разбор может быть полезен тем, кто решает похожие задачи.

Сначала на Stack Overflow я нашел неплохой пример создания эффекта размытия на определенном участке экрана — к сожалению, это решение не было универсальным и зависело от верстки. Однако мое внимание привлекли два класса из фреймворка: RenderNode и GraphicsLayer. 

Если коротко, можно захватить часть экрана через GraphicsLayer, а в RenderNode записать контент. Но перед этим его можно обработать. После обработки метод drawWithContent() выводит результат в canvas. 

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

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

Какие выводу я могу сделать:

• в Compose можно делать крутые визуальные эффекты, если покопаться в RenderNode;

• это неочевидный, но мощный инструмент, он дает простор для кастомизации.

Мой пример не самый изобретательный, но способ, который я показал, открывает почти безграничные возможности для реализации визуальных эффектов в Android-разработке, чем мы в «Финам» и пользуемся очень активно в наших финтех-проектах. Итоговый результат оформил в GitHub-репозитории — берите и пробуйте в своих проектах.

Аналитик в IT: кто это такой и почему без него не запустить ни один "финтех" проект

В этом выпуске подкаста мы разбираемся, как разработчики понимают, что и как им делать. Нашим гостем стал Игорь Мохов, аналитик с нестандартным путем в IT — из сферы технической безопасности.

Мы обсудили:

• Личный путь: Как Игорь сменил профессию в 30+ лет и почему выбрал именно аналитику, вспомнив свой опыт написания кода еще в университете.

• Суть работы аналитика: Чем на самом деле занимается этот специалист? Игорь выделил три ключевые функции: общение с заказчиком, чтобы понять его истинные потребности; глубокий анализ и проработка алгоритмов; и ответственность за проект «от и до» — от сбора требований до успешного выхода в продакшен.

• Ключевые различия: Чем бизнес-аналитик отличается от системного и почему в современных реалиях востребованы универсальные специалисты с широким набором навыков.

• Проблемы и вызовы: Почему в команде шутят, что «если все хорошо, значит, команда поработала отлично, а если что-то пошло не так — виноват аналитик».

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

Наш подкаст доступен на всех удобных платформах:

Youtube Music | Apple Podcast | Яндекс Музыка | Spotify | VK Музыка

Как войти в нужную дверь: API-ключ и как с ним работать

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

Чтобы использовать API-ключ, нужно:

1. Получить его в личном кабинете сервиса.

2. Добавить в запрос — обычно в заголовке Authorization.

3. Следить за безопасностью: не хранить ключ в коде и регулярно менять.

Пример запроса в Node.js:

const axios = require('axios');

const API_KEY = process.env.MY_API_KEY;

axios.get('https://api.example.com/data', {

  headers: { 'Authorization': Api-Key ${API_KEY} }

})

.then(r => console.log(r.data))

.catch(e => console.error('Ошибка', e.response?.status));

В базе знаний Рег.облака поделились подробной инструкцией: как создать, подключить и защитить API-ключ. Заходите, сохраняйте и используйте :) 

Разбор полётов: вся правда о падениях Android-приложений

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

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

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

Дизайнеры Apple изменили функцию скриншота в новой версии iOS. Они зачем-то поменяли кнопки местами: кнопка удаления теперь находится на месте привычной кнопки сохранения. Из-за этого пользователи с непривычки удаляют снимки экрана сразу после создания.

LLM — инструмент оптимизации 

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

Архитектурные отличия 

Скорость генерации зависит от числа активных параметров, FLOPs per token, а также методов оптимизации. Лёгкие модели (например, Gemini 2.5 Flash, GPT-4o mini) используют агрессивную квантизацию, меньший размер KV-кэша и оптимизированные операции для быстрого инференса. Это повышает скорость обработки запроса, но увеличивает шанс галлюцинаций в сложных, многоступенчатых рассуждениях.

Тяжёлые модели (наподобие Gemini 2.5 Pro, GPT-5) часто применяют Mixture of Experts (MoE), динамически активируя только нужные экспертные нейронные сети, что позволяет балансировать между вычислительной мощностью и скоростью.

Цели и специализация

Важная метрика — контекстное окно. Лёгкие модели эффективны для локального скоупа: генерация unit-тестов или добавление JSDoc. Тяжёлые модели, благодаря огромному окну (до 2 млн токенов у некоторых версий Gemini), способны анализировать кросс-файловые зависимости, документацию, схемы архитектуры (мультимодальность) и предлагать высокоуровневые изменения, осуществлять глобальное архитектурное ревью и рефакторинг.

Семейства моделей

Так какие модели в итоге использовать? Выбираем по уровню резонинга и надёжности. Качественные модели незаменимы, когда ты мигрируешь легаси-код, проектируешь сложную схему БД или создаёшь подробную техническую документацию — они лучше удерживают цепь рассуждений (chain of thought). Быстрые модели — твой инструмент для автоматической генерации фикстур, CI/CD-скриптов или написания inline-подсказок в IDE.

Выбор и выводы

Интегрируй быстрые модели в IDE для мгновенных подсказок. Это также идеальный выбор для автоматической генерации кода-заглушки, санации данных или создания mock-объектов в тестах. В таких случаях не страшно ошибиться, а выигрыш во времени и, главное, в токенах огромен. Это идеальное решение для рутины. Применяй качественные модели для анализа уязвимостей (например, SQL-инъекций), проверки сложных инъекций зависимостей или проектирования.

Трактуй LLM как специализированный набор микросервисов. Быстрые для потоковых, low-risk задач, где важна скорость. Качественные — для анализа и high-risk рефакторинга. Главное — правильно оценивать риски. Если ошибка в коде LLM стоит тебе дня отладки или, хуже, продакшн-инцидента, выбирай качество. Во всех остальных случаях — скорость.

Больше постов ищите в нашем Telegram-канале

Квиз: сможете ли вы найти ошибку в мобильном приложении?

Проверьте свои навыки и получите 1 000 бонусов на тестирование в мобильной ферме Selectel. 

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

Пройти квиз →

🎁 За участие — 1 000 бонусов в панели управления. Важно: количество промокодов ограничено.

Мощный инструмент для Android-разработчиков

Retrofit — это библиотека, которая стала стандартом для работы с REST API в Android-приложениях. В нашей статье «Погружаемся в недра Retrofit» мы подробно разбираем, как использовать Retrofit максимально эффективно, чтобы упростить код и повысить стабильность приложений.

Что внутри?

• Обзор основных возможностей Retrofit: от простой отправки запросов до работы с асинхронностью и обработкой ошибок.

• Интеграция с OkHttp — что дает и как использовать на полную мощность.

• Механизмы конвертации данных: Gson, Moshi и как кастомизировать парсинг.

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

• Советы по тестированию Retrofit-клиентов и особенностям работы с сетевыми вызовами.

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

Дайджест открытых мероприятий МФТИ на октябрь

❗️На все мероприятия требуется предварительная регистрация через телеграм-бота: https://t.me/mipt_events_bot.

Инструмент стратегической канвы для поиска своего ценностного предложения
🗓 8 октября 🕛 18:00 (Мск)

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

Построение распределенных систем: подходы, методы, команда
🗓 9 октября 🕛 19:00 (Мск)

Разберем на примере веб-приложения построение архитектуры распределенной системы.

Собираем команду стартапа: кого берем сразу, а кого привлекаем чуть позже
🗓 15 октября 🕛 20:00 (Мск)

Составим эффективный план по привлечению специалистов в команду начинающего стартапа, когда еще нет продукта.

Разработчик IT-продукта в 2025 году: роль и современные подходы
🗓 16 октября 🕛 18:00 (Мск)

Узнаем от практикующего специалиста со стажем 10+ лет про современные методологии разработĸи и как разработчику взаимодействовать с бизнесом.

Типы архитектур: основные приложения
🗓 24 октября 🕛 19:00 (Мск)

Разберем основные типы архитектур на примерах и обсудим будущее разработки приложений.

📍У некоторых мероприятий дата и время могут быть скорректированы. Мы сообщим заранее, если такое произойдет

♾️Регистрация через телеграм-бота: https://t.me/mipt_events_bot

Есть ли смысл спрашивать моб.разработчика про устройство хештаблицы?

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

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

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

И биг О это..

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

Где здесь здравый смысл?

Вместо этого лучше спрашивать напрямую про оптимизацию времени выполнения и использования памяти.

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

Нет - проходишь, да - ну ка расскажи тогда про хештаблицы голубчик.

Хотя я бы сразу такого взял на заметку. Ибо незачем в ключи совать то что не предназначено быть ключём, мы же с базами данных так не делаем? (Или у кого-то это бестпрактис? Тогда делитесь в комментариях для расширения кругозора 😁 )

Как я понял про хешмапы спрашивают 2 вида людей:

1. Каргокультисты, "а зачем ты спрашиваешь?", а все спрашивают и я спрашиваю, говорят что это "бла, бла, бла", и для здоровья полезно. (Так много чего для здоровья полезно 😁)

2. Те кто пару раз пихал таки в качестве ключа какую-нибудь дичь и потом отлаживал это дело пару недель, и теперь транслирует свою боль на весь мир. (Понимаю было больно, но это прошло, можно отпустить)

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

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

Или нет?