👣 Как удалить все неиспользуемые импорты во Flutter-проекте

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


Одна команда, которая все решает:

В корне проекта достаточно выполнить:

dart pub get && dart fix --apply

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

Если хочется сначала посмотреть, что именно будет удалено, можно выполнить dart fix --dry-run. Покажет список изменений, но ничего не тронет.


Почему об этом вообще стоит думать:

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

dart fix решает эту проблему мгновенно. Инструмент официальный, встроенный в экосистему Dart, так что никаких сторонних зависимостей тащить не нужно.


Что важно помнить:

Перед массовой чисткой лучше сделать коммит - мало ли что. Сгенерированные файлы (.g.dart) dart fix трогать не должен, они все равно перезапишутся при следующей сборке. И всегда после чистки стоит прогнать dart analyze && flutter test, чтобы убедиться, что ничего не сломалось.


🔗 Читать подробнее


💡 Вывод:

dart fix --apply - это не магия, а просто правильный инструмент. Он не делает код быстрее и не добавляет новых фич. Зато он убирает мусор, который отвлекает, запутывает и создает иллюзию сложности. Если в вашем проекте есть неиспользуемые импорты - команда решит проблему за секунду. Если их нет - вы либо уже все почистили, либо просто не замечаете.


➡️ Flutter & Dart | Мобильный трудоголик

👨‍💻 Некоторые приложения для iPhone получили загадочное обновление «от Apple».

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


Какие приложения пострадали:

В списке приложений: Candy Crush Soda Saga, Sentry Mobile, Catan Universe, Bluetti, Mortal Kombat, Duet Display, VLC и многие другие. Категории приложений совершенно разные: игры, утилиты, медиаплееры. Что их объединяет - непонятно.


Что говорят разработчики:

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

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


Догадки:

Разработчики выдвигают несколько предположений:

🔵Технические правки со стороны Apple (например переподпись сертификатами).

🔵Исправление критических уязвимостей, о которых не говорят вслух.

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


🔗 Читать подробнее


💡 Вывод:

Apple тихо, но уверенно обновляет приложения в App Store от своего имени. Что именно она меняет - неясно. Разработчики, чьи приложения попали под это, похоже, тоже не в курсе. Пока это выглядит как техническая необходимость, а не как злоупотребление. Но сам прецедент заставляет задуматься: Apple может влиять на приложения на вашем телефоне даже без участия их создателей.


➡️ Подписаться на канал
Мобильный трудоголик

🔢 Полный контроль над списками: создаем свою замену List в SwiftUI.

Привет! Наткнулся на статью, где автор разбирает, почему List подходит не для всех случаев. Да, для однородных данных (например списка писем или задач) List незаменим. Но когда интерфейс становится сложнее - появляются разные типы карточек, нестандартные отступы, кастомные фоны - List начинает мешать. Специфичные модификаторы вроде listRowBackground или listRowInsets работают только внутри List и не дают гибкости.

Автор предлагает альтернативу - ScrollView с ленивыми стеками (LazyVStack / LazyHStack). За последние годы SwiftUI значительно подтянул их производительность. Если вы не отображаете сотни тысяч однородных строк, ScrollView - отличный выбор.


Что предлагает автор статьи:

🔵ScrollingSurface - простая обертка над ScrollView и ленивым стеком. Позволяет задать направление прокрутки и выравнивание. Автор использует ее как корневой контейнер для всех экранов своего приложения CardioBot.

🔵DividedCard - карточка с разделителями между дочерними элементами. Использует Group(subviews:) из Container View API, чтобы разобрать переданное содержимое, добавить Divider между элементами и обернуть все в фон с закругленными углами.

🔵SectionedSurface - обрабатывает секции внутри переданного содержимого. Использует ForEach(sections:), чтобы извлечь заголовки, контент и футеры, отфильтровать пустые секции и добавить отступы.

🔵NavigationButtonStyle - кастомный стиль кнопки, который добавляет шеврон справа, как в стандартном NavigationLink внутри List. Это мелочь, но без нее навигация выглядит неполноценно.


Как это собирается вместе:

В итоговом экране автор использует ScrollingSurface как корневой контейнер, внутри - SectionedSurface с секциями, а внутри секций - DividedCard с NavigationLink. Все это покрывается кастомным стилем кнопки. API получается очень похожим на стандартный List, но с полным контролем над внешним видом.


💡 Вывод:

Отказываться от List не нужно - он хорош для своих задач. Но когда интерфейс становится сложным и неоднородным, современный SwiftUI дает инструменты, чтобы построить свою замену. ScrollView с ленивыми стеками и Container View API позволяют создавать переиспользуемые компоненты, которые не уступают List в производительности, но дают полный контроль над дизайном. Если ваш интерфейс перерос стандартный List - присмотритесь к этому подходу.


➡️ Подписаться на канал
Мобильный трудоголик

🔢 Новая фича Swift: деманглинг прямо в рантайме.

В будущей версии Swift появится официальный API для деманглинга - преобразования страшных имен вроде $sSS7cStringSSSPys4Int8VG_tcfC в читаемый вид Swift.String.init(cString: Swift.UnsafePointer<Swift.Int8>) -> Swift.String. Это важное изменение для всех, кто пишет инструменты для отладки, профилирования или анализа кода.


Как это работает сейчас:

Сейчас, чтобы получить человеческое имя символа, приходится либо запускать внешний процесс swift-demangle, либо использовать неофициальные внутренние API рантайма. Первый вариант медленный, второй - ненадежный и может сломаться в любой момент.


Решение:

Новый модуль Runtime получит функцию demangle(_:), которая принимает искаженное имя и возвращает строку в читаемом виде или выбрасывает ошибку, если символ невалиден.

Для высокопроизводительных сценариев (например профайлеры, которые обрабатывают тысячи символов в секунду) добавлен второй вариант - запись результата в заранее выделенный буфер через UTF8Span. Это позволяет избежать лишних аллокаций и копирований.


Важное предупреждение:

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


Кому это может пригодиться:

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


💡 Вывод:

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


➡️ Подписаться на канал
Мобильный трудоголик

📱 ИИ-инженер: почему недостаточно просто уметь общаться с ChatGPT.

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

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


Системный промптинг - не искусство, а инженерия:

Многие ошибочно считают промтинг чем-то вроде магии или искусства общения. На самом деле, это инженерная дисциплина. Хороший промпт - это не просто вопрос, это структурированное техническое задание для модели. Разница между любителем и профессионалом видна в подходе к формулировкам.

Новичок попросит: «Напиши код кнопки». Результат будет случайным - где-то SwiftUI, где-то UIKit, с разной логикой.

Инженер строит систему взаимодействия. Он определит роль: «Ты - senior iOS-разработчик».
Задаст формат ответа: «Верни только код SwiftUI без пояснений».
Укажет требования: «Используй модификатор .accessibilityLabel и предусмотри состояния .disabled».
И добавит ограничения: «Не используй устаревшие API iOS 14».

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


Архитектура контекста:

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

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


Стратегия адаптации:

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

🔹Промптинг - это быстро и дешево. Как готовить по базовому рецепту. Подходит для прототипов и задач, где допустима некоторая вариативность.

🔹RAG (Retrieval-Augmented Generation) - это когда к модели подключают внешнюю память. Представьте врача, который перед ответом листает вашу медицинскую карту. Этот подход нужен, когда важна актуальность данных или работа с приватной информацией - документацией компании, персональными данными пользователя.

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

Выбор зависит от ответов на вопросы: Как часто меняются данные? Насколько критичны ошибки? Каков бюджет?


Защитные барьеры:

Модель может сгенерировать что угодно: от гениального кода до опасного совета. Инженер обязан построить систему безопасности. Это не доверие, а верификация.

На практике барьеры работают как фильтры. Валидация вывода: перед применением сгенерированного кода он проверяется компилятором или линтером. Модерация контента: текст анализируется на предмет токсичности. Ограничение домена: модель явно инструктируют не отвечать на вопросы вне своей компетенции.


💡 Вывод:

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


➡️ Кот Денисова

👨‍💻 Почему ревью в App Store Connect стало занимать недели.

В последнее время все больше iOS-разработчиков сталкиваются с зависшими ревью. Приложения ждут неделями, а то и дольше. Причем проблема носит массовый характер. Разбираемся, что происходит и почему Apple не справляется с потоком.


Почему ревью зависли:

Основная причина - резкий рост числа запросов на проверку. В 2025 году App Store получил около 557 тысяч новых заявок, что на 24% больше, чем в 2024-м. Это первый сильный рост с 2016 года. За первый квартал 2026-го уже 235 тысяч новых приложений. Пользователей больше не стало, а вот приложений - да.


Почему так много новых приложений:

Благодаря ИИ-инструментам порог входа в разработку резко упал. С помощью Claude Code, Codex и аналогичных решений даже непрофессионалы могут создавать рабочие приложения, просто формулируя задачи на естественном языке. На рынок теперь выходят не студии, а одиночные разработчики. Сделать MVP стало дешевле, проверить спрос - проще, а выход на аудиторию через соц. сети - доступнее. Подписочная модель монетиации превращает даже небольшое приложение в полноценный источник дохода.


Что изменилось в процессе ревью:

Apple официально заявляет, что 90% заявок рассматриваются менее чем за 24 часа. Опытные разработчики говорят что доходит до 48 часов. Но часть разработчиков сталкивается с ожиданием в недели. Среднее время остается быстрым, но в сложных или подозрительных приложениях резко увеличивается.


Почему проверять стало сложнее:

Раньше App Review в основном отсеивал баги, приватные API и контентные нарушения. Теперь появилась новая головная боль: приложения, которые с помощью ИИ генерируют или исполняют код, меняющий функциональность после публикации. Это прямое нарушение Guideline 2.5.2. Проверить такое приложение вручную - задача нетривиальная и очень ресурсоемкая.


Что требуют сейчас:

По сообщениям разработчиков, Apple начала запрашивать для новых приложений:

🔹Запись видео с реального устройства.

🔹Описание смысла приложения и реальной ценности.

🔹Инструкции по получению доступа к основным функциям.

Это прямая реакция на вал завайбкоженных приложений, которые стали массово отправлять в стор.


🔗 Читать подробнее


💡 Вывод:

Зависшие ревью - это не сбой, а следствие структурных изменений в экосистеме. Поток новых приложений вырос кратно, а механизмы проверки остались прежними. Apple пытается ужесточить требования, но процесс отладки новых правил занимает время. Разработчикам остается только закладывать больше времени на публикацию новых приложений и готовить максимально полную документацию заранее.


Подписаться на канал:
➡️ Telegram | Max

Закрытый канал:
🚀 Мобильный трудоголик PRO

🔢 Жизненный цикл SwiftUI View: когда onAppear вызывается не так, как ожидали.

На первый взгляд, onAppear кажется простым и понятным: показалась вью - сработало, скрылась - сработало onDisappear. Но на практике все сложнее. В зависимости от того, где находится вью - в TabView, NavigationStack или List - поведение может кардинально отличаться. И если не понимать этих нюансов, можно нарваться на баги, которые трудно воспроизвести.


Две разные системы:

Чтобы понять, что происходит, нужно разделить два понятия: время жизни узла (node lifetime) и видимость на экране (visibility). Узел живет, пока существует идентичность вью. К узлу привязаны @State и @StateObject. А видимость - это то, видит ли пользователь вью сейчас. onAppear и onDisappear реагируют именно на видимость, а не на создание или уничтожение узла.

В простых случаях эти две шкалы совпадают. Но в сложных контейнерах - расходятся.


TabView - узлы живут, видимость меняется:

Когда вы переключаете вкладки, узлы вью не уничтожаются. Они остаются в памяти, меняется только флаг видимости. Поэтому onAppear срабатывает при каждом переключении на вкладку, но @State сохраняет свое значение.

Нюанс: на iOS 17 TabView создавал все вкладки сразу при запуске. На iOS 18+ - только при первом открытии. Один и тот же код может вести себя по-разному на разных версиях.


NavigationStack - при возврате узел уничтожается:

В навигационном стеке при возврате назад (pop) узел детальной вью уничтожается, а @State сбрасывается. При повторном переходе создается новый узел. В отличие от TabView, здесь данные не сохраняются между показами.


List и LazyVStack - узлы создаются и уничтожаются при скролле:

В ленивых списках узлы для ячеек создаются, когда те подъезжают к видимой области, и могут быть уничтожены, когда уезжают далеко. Поэтому @State внутри ячейки нельзя использовать для хранения данных - при повторном появлении оно сбросится.


Главное правило - body выполняется до onAppear:

body вычисляется до того, как сработает onAppear или .task. Нельзя полагаться на то, что в onAppear данные подгрузятся до первого вызова body. Нужно всегда предусматривать начальное состояние.


🔗 Читать подробнее


💡 Вывод:

onAppear в SwiftUI - это не «вью создана», а «вью стала видимой». Время жизни узла и видимость - это две независимые шкалы. Понимание этого спасает от багов, когда @State вдруг не сбрасывается или, наоборот, сбрасывается не вовремя. Разные контейнеры ведут себя по-разному и это нужно тестировать, а не гадать.


Подписаться на канал:
➡️ Telegram | Max

Закрытый канал:
🚀 Мобильный трудоголик PRO

🔢 Copy-on-Write в Swift: как массивы экономят память.

Всем привет! Наткнулся на статью, где автор подробно разбирает механизм Copy-on-Write (COW) в Swift. Это та самая технология, благодаря которой массивы, строки и словари ведут себя как типы значений, но при этом не создают полные копии больших объемов данных при каждом присваивании.


Что такое COW простыми словами:

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

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


Как это работает под капотом:

Тип-значение (например ваш массив) хранит ссылку на объект-хранилище (класс). При присваивании копируется ссылка, а не само хранилище. При попытке изменения вызывается метод isKnownUniquelyReferenced(_:), который проверяет, есть ли у хранилища другие ссылки. Если есть - создается новое хранилище с копией данных, и только потом происходит изменение.

Проверить уникальность можно и в своем коде, если вы пишете кастомную COW-структуру.


Как реализовать свой COW-контейнер:

Автор приводит пример SharedBuffer<Element>:

🔹Публичная структура-обертка.

🔹Внутренний класс Storage, хранящий массив элементов.

🔹Метод ensureUniqueStorage(), который копирует хранилище, если на него есть другие ссылки.

🔹Все мутирующие методы сначала вызывают ensureUniqueStorage()

Простой, но эффективный паттерн.


Распространенные заблуждения:

🔹«Структуры автоматически используют COW». Нет. COW - это стратегия реализации конкретных типов (Array, String, Dictionary). Ваши структуры по умолчанию копируются целиком.

🔹«COW рекурсивно копирует все вложенные объекты». Нет. Копируется только само хранилище контейнера. Если внутри лежат ссылочные типы, их изменение не триггерит COW.


🔗 Читать подробнее


💡 Вывод:

Copy-on-Write - один из ключевых механизмов, позволяющих Swift сочетать производительность и безопасность. Понимание того, как он работает, дает вам инструмент для проектирования эффективных структур данных и помогает писать более производительный код.


Подписаться на канал:
➡️ Telegram | Max

Закрытый канал:
🚀 Мобильный трудоголик PRO

👣 Два года спустя: как увольнения повлияли на Flutter

Всем привет! Сегодня хочу разобрать интересную статью про судьбу Flutter после увольнений в Google. В апреле 2024 года Google уволил инженеров из команд Flutter, Dart и Python - за несколько недель до Google I/O, где традиционно анонсировали светлое будущее. Тогда было много паники и постов «Flutter умер». Прошло два года. Flutter не умер. Но и не остался прежним. Пора без истерик разобраться, что на самом деле изменилось.


Что тогда произошло:

Увольнения затронули в основном DevOps и инфраструктуру, а не разработчиков самого фреймворка. План развития продукта не изменился. Но сообщество правильно прочитало сигнал: для Google Flutter - больше не стратегический приоритет, а просто поддерживаемый продукт. Разница огромная. Стратегическому приоритету выделяют лучших инженеров, лоббируют внутри компании, вкладывают ресурсы. Поддерживаемому продукту - фиксят критические баги, но новых горизонтов не открывают.


Что случилось потом:

Flutter продолжил выпускать релизы. Impeller стал стабильным. Дорожная карта 2024 года выполнена. BMW, Alibaba и eBay все еще используют Flutter на проде. Опрос Stack Overflow 2024 показал 46% использования среди кроссплатформенных фреймворков - больше, чем у React Native (35%).

Но вот что важно: Тим Снит (многолетний руководитель разработки Flutter, лицо проекта на I/O) ушел в Apple в 2023 году. Брэндон ДеРозье (создатель Impeller) в 2025 году перешел в команду Android XR. Это не увольнения. Это добровольные уходы ключевых людей. И они сигнализируют о том, что даже внутри Google самые талантливые инженеры перестали видеть будущее за Flutter.


Почему я все еще использую Flutter:

Фреймворк работает. Для 90% задач кроссплатформенной разработки - стабильно, быстро, предсказуемо. Сообщество огромное, уже более 50 000 пакетов на pub.dev. Релизы выходят четыре раза в год. С точки зрения инженерной реальности Flutter не стал хуже.

Но соотношение затрат и выгод изменилось. Теперь нужно задавать себе другие вопросы.


🔗 Читать подробнее


💡 Вывод:

Используйте Flutter там, где он подходит. Понимайте свои зависимости и риски. Не принимайте архитектурные решения по звездам на GitHub и по рекомендациям от ИИ. Релевантный показатель один: решает ли фреймворк вашу проблему сегодня и есть ли у него разумный путь поддержки на три года вперед. По этому показателю Flutter проходит проверку. Не на отлично. Не так уверенно, как в 2021 году. Но проходит. Те, кто ожидает немедленного краха, ошибаются. Те, кто утверждает, что все осталось по-прежнему, тоже ошибаются. Правда, как обычно, посередине: Flutter - рабочий инструмент, но теперь его стоит выбирать с открытыми глазами, понимая, что уровень поддержки со стороны Google может и дальше снижаться.


➡️ Flutter & Dart | Мобильный трудоголик

👨‍💻 Apple добавила годовую подписку с ежемесячной оплатой.

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


Как это работает:

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

Apple добавила прозрачности: в аккаунте пользователя будет видно, сколько платежей уже прошло и сколько осталось. Также будут приходить email и push-уведомления перед очередным списанием.


Почему это интересно для разработчиков:

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

Появляется новый инструмент для A/B-тестов и ценовых стратегий. Можно комбинировать с классическими годовыми подписками и месячными без обязательств.


На что обратить внимание:

Нужно аккуратно объяснять пользователю условия в интерфейсе. Если не предупредить, что «отменить подписку» не означает «прекратить платить прямо сейчас», можно получить негативные отзывы, споры и возвраты.

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


🔗 Читать подробнее


💡 Вывод:

Новый тип подписки - компромисс между годовым контрактом (высокий порог входа, но предсказуемый доход) и ежемесячной подпиской (низкий порог, но нестабильные оттоки). Для некоторых категорий приложений, особенно с высокой ценой годовой подписки, это может стать золотой серединой. Главное - честно и понятно объяснять пользователям условия, чтобы не получить волну негатива в отзывах.


Подписаться на канал:
➡️ Telegram | Max

Закрытый канал:
🚀 Мобильный трудоголик PRO

🍏 Разработчики Apple забыли удалить инструкции для ИИ перед релизом приложения.

В обновлении приложения Apple Support (версия 5.13) пользователи обнаружили файлы claude.md. Разработчики быстро это заметили и в следующем обновлении файлы убрали, но интернет все помнит.


Что это за файл:

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


Что это значит для Apple:

Самое интересное - не то, что Apple использует ИИ для разработки (это уже никого не удивляет), а то, что они используют Claude от Anthropic, а не свои внутренние наработки. Это сигнал: даже в Apple предпочитают готовые решения от сторонних разработчиков, когда речь заходит о современных ИИ-инструментах.

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


Почему это обсуждают:

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


🔗 Читать подробнее


💡 Вывод:

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


Подписаться на канал:
➡️ Telegram | Max

Закрытый канал:
🚀 Мобильный трудоголик PRO

🔨 Agent Skills для ускорения сборки Xcode.

Наткнулся на статью, где автор рассказывает о наборе Agent Skills для оптимизации времени сборки Xcode. Понимаю, что к ИИ-инструментам многие относятся скептически, но здесь речь не о написании кода за вас, а об экономии времени.


Почему это важно:

Автор приводит простую математику. Если вы делаете 50 сборок в день и ускоряете каждую на 5 секунд, это около 5 минут в день. В год - 30 часов. Один из первых пользователей сэкономил 20 секунд на каждой сборке. Для больших проектов разница может быть еще заметнее.


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

Отдельное внимание уделено сборке без изменений (zero-change build). Это когда вы ничего не меняли в коде, а Xcode все равно что-то пересобирает. У одного из проектов такая сборка занимала 70 секунд. После оптимизации - 9 секунд. Разница в 87%.


Как устроен скилл:

Это не один инструмент, а целый оркестр из шести специализированных скиллов:

🔹Оркестратор запускает весь процесс и направляет.

🔹Бенчмарк делает три чистые и три инкрементальные сборки, сохраняет результаты в JSON.

🔹Анализ проводится тремя скиллами, которые проверяют настройки сборки, конфигурацию проекта, исходный код и зависимости - всего более 40 пунктов.

🔹План оптимизации формируется на основе анализа и представляется разработчику для утверждения.

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

🔹Финальный бенчмарк показывает результат и сравнивает с исходными данными.


Что можно оптимизировать:

Скилл проверяет:

🔹Настройки компилятора и линкера.

🔹Конфигурацию Swift Package Manager.

🔹Build phases (скрипты, копирование ресурсов).

🔹Сложность кода (например долгие компиляции конкретных файлов).

🔹Включение кэширования компиляции (Compilation Caching).


Результаты на реальных проектах:

Автор приводит данные трех приложений:

🔹Helm: чистая сборка почти без изменений (в пределах погрешности), инкрементальная ускорилась на 87% (с 70 до 9 секунд).

🔹Stock Analyzer: чистая сборка быстрее на 20%, инкрементальная - на 32%.

🔹Enchanted: чистая сборка быстрее на 14%, инкрементальная - на 12%.


🔗 Читать подробнее


💡 Вывод:

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


Подписаться на канал:
➡️ Telegram | Max

Закрытый канал:
🚀 Мобильный трудоголик PRO

👨‍💻 Почему агенты пишут плохой код.

Вокруг ИИ-агентов для разработки сформировался странный парадокс. Одни заявляют, что не писали код руками полгода и полностью делегируют задачи машине. Другие клянутся, что агенты глупые и не способны на что-то сложнее «Hello World». Оба мнения честны и оба - об одном и том же инструменте. Разрыв в результатах говорит не о качестве технологии, а о катастрофической разнице в подходе к ее использованию. Успех определяет не сам агент, а навык, стоящий за промптом.


Проблема не в инструменте, а в операторе:

Ключевое заблуждение - ожидать от агента волшебства. Это не искусственный общий интеллект, который читает мысли. Это сложный, но ограниченный инструмент, который действует строго по инструкции. Разница между командами «напиши код» и «напиши на Swift функцию, которая асинхронно загружает JSON по URL, обрабатывает ошибки сети и парсит результат в структуру User с полями id и name, используя современный async/await синтаксис» - это разница между хаотичным выводом и рабочим решением.


Главный навык - умение формулировать, а не писать код:

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

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

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

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


Провальные паттерны коммуникации:

Большинство неудач происходят по шаблонным сценариям:

🔹Слишком абстрактно: «Сделай красивый интерфейс». Агент не понимает, что такое «красивый» в вашем контексте.

🔹Без контекста: «Пофикси баг». Агент не знает кодобазы, архитектуры и истории проблемы.

🔹Противоречиво: «Код должен быть быстрым и читаемым, но еще и очень компактным». Это взаимоисключающие требования на этапе реализации.


Стратегия эффективного промптинга:

Вместо расплывчатых пожеланий нужен структурированная задача:

🔹Роль: «Ты senior iOS-разработчик, специализирующийся на оптимизации производительности».

🔹Цель: «Мне нужно реализовать фичу А в контексте Б для достижения цели В».

🔹Контекст: «Вот текущая архитектура проекта, вот основные принятые в проекте требования».

🔹Ограничения: «Нельзя использовать библиотеку X, минимальная версия iOS - 15, код должен проходить линтер с настройками Y».

🔹Критерии успеха: «Код считается успешным, если он покрыт unit-тестами на 90%, не вызывает ошибок и соответствует всем указанным требованиям».

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


💡 Вывод:

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


➡️ Кот Денисова

🔢 MapKit: работа с картами в SwiftUI.

SwiftUI и MapKit постепенно сближаются. Если раньше для работы с картами приходилось писать код на UIKit и оборачивать его в UIViewRepresentable, то теперь для этого есть нативный Map view. Разбираем, какие возможности появились и как их использовать.


Базовое отображение:

Самый простой способ - добавить карту одной строкой: Map(). Она автоматически заполнит доступное пространство. Ее можно оформлять как любой другой SwiftUI-компонент: добавлять скругление углов через .cornerRadius, ограничивать размер через .frame, настраивать отступы.


Настройка камеры:

Управлять тем, что видит пользователь, можно через MapCameraPosition. Камеру можно задать один раз при создании карты (параметр initialPosition) или связать с @State через двухсторонний биндинг (position), чтобы менять положение динамически.

Камера настраивается через MKMapCamera: указывается центр, расстояние, угол наклона (pitch) и направление (heading). Все это упаковывается в MapCamera, затем в MapCameraPosition.camera.


Ограничение видимой области:

Если нужно, чтобы пользователь не мог уйти за пределы определенной территории, используется MapCameraBounds. Задается регион, в котором должен оставаться центр карты. Например, можно запретить вертикальное перемещение, оставив только горизонтальное.


Интерактивность:

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


🔗 Читать подробнее


💡 Вывод:

Работа с картами в SwiftUI стала гораздо удобнее. Нативный Map view покрывает большинство сценариев: от простого отображения до управления камерой и ограничения видимой области. Если нужны совсем экзотические возможности, можно опуститься до UIKit-оберток, но в 90% случаев встроенных средств достаточно.


Подписаться на канал:
➡️ Telegram | Max

Закрытый канал:
🚀 Мобильный трудоголик PRO

👨‍💻 ИИ-агенты в App Store: Apple ищет компромисс между трендом и безопасностью.

До WWDC остались недели, и появляется все больше слухов о том, как Apple планирует встраивать ИИ в свои платформы. Одна из ключевых и самых щепетильных тем - допуск в App Store агентов, способных автономно выполнять действия за пользователя. С одной стороны, тренд игнорировать нельзя. С другой - правила App Store не резиновые.


В чем проблема:

ИИ-агенты (например те, что могут сами управлять приложениями, удалять письма, совершать покупки) - это вызов для Apple. Правила App Store строго запрещают приложениям выполнять код, который меняет их функциональность или функциональность других приложений. Агенты как раз этим и занимаются.

Кроме того, есть риск обхода комиссии и потери контроля над монетизацией. Если агент может создать приложение на лету и запустить его, минуя App Store, Apple теряет и деньги и возможность проверить, что этот код безопасен.


Что предложит Apple:

По данным источников, компания разрабатывает специальную систему, которая позволит агентам работать в рамках экосистемы, но под строгим контролем. Основная цель - предотвратить хаотичное поведение, когда агент выходит из-под контроля (например как в случае с OpenClaw, где бот удалял всю почту пользователя).

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

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


🔗 Читать подробнее


💡 Вывод:

Apple не хочет оставаться в стороне от бума ИИ-агентов, но и не готова жертвовать принципами. Новая система - это компромисс. Если она сработает, разработчики получат доступ к новой аудитории, пользователи - полезных помощников, а Apple сохранит контроль. Но все решит то, насколько жесткими окажутся ограничения. Если они будут слишком строгими, агенты могут так и остаться за пределами App Store, либо перейти на другие платформы, где жестких правил меньше.


Подписаться на канал:
➡️ Telegram | Max

Закрытый канал:
🚀 Мобильный трудоголик PRO

🔨 Time Profiler: повышение производительности с помощью ИИ.

Всем привет! Нашел интересную статью, где автор делится опытом использования Time Profiler в связке с ИИ-агентами. Устройства сейчас действительно быстрые чем раньше и потребность в профилировании снизилась. Но это не значит, что проблем с производительностью больше нет. Просто мы перестали их замечать.


Кейс - ускорение в 25 раз:

Автор взял конкретную задачу - загрузку accessibility-элементов в RocketSim. На одном экране с 70+ элементов это занимало 12 секунд. Вместе с ИИ-агентом они прошли несколько итераций:

🔹12 с -> 4 с (в 3 раза быстрее).

🔹4 с -> 2,5 с (еще в 2 раза).

🔹2,5 с -> 525 мс (в 23 раза).

🔹525 мс -> 485 мс (финальные 25 раз).

Ключевой момент: если бы остановились на первой итерации, решив, что «и так неплохо», результат был бы в 25 раз хуже.


Как это работает:

У автора уже был CLI для RocketSim. ИИ-агент мог запускать его до и после изменений, сравнивать результаты и отменять правки, если стало хуже. Для анализа использовался Time Profiler с добавленными signpost (чтобы код был виден в инструменте).


Процесс выглядит так:

🔹Агент вносит изменения в код.

🔹Разработчик запускает приложение в Instruments с шаблоном Time Profiler и signpost.

🔹Копирует результаты (интервалы signpost и глубокую копию Time Profiler).

🔹Отдает агенту с запросом: «Проанализируй и предложи план дальнейших оптимизаций».

🔹Цикл повторяется, пока агент не скажет, что быстрее уже не сделать.


Кому может быть полезно:

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

🔹Тем, кто использует ИИ-агентов в своей работе и хочет дать им реальные данные о производительности, а не гадать на кофейной гуще.

🔹Разработчикам инструментов и SDK, где важна скорость работы (CLI, accessibility, обработка больших объемов данных).


🔗 Читать подробнее


💡 Вывод:

Instruments не умерли. Они просто стали реже нужны - но когда они нужны, без них никуда. А с ИИ-агентами процесс становится еще эффективнее: вы не тратите часы на анализ стеков, а просто даете агенту данные и получаете готовый план оптимизаций. И да, 25-кратное ускорение - не предел. Все упирается в то, как часто вы готовы запускать этот цикл.


Подписаться на канал:
➡️ Telegram | Max

Закрытый канал:
🚀 Мобильный трудоголик PRO

👣 Flutter отказывается от CocoaPods в пользу Swift Package Manager

Начиная с релиза Flutter 3.44, Swift Package Manager (SwiftPM) заменяет CocoaPods как стандартный менеджер зависимостей для iOS и macOS. Это означает, что больше не нужно возиться с установкой Ruby или настройкой CocoaPods, чтобы просто запустить приложение.


Почему CocoaPods уходит:

CocoaPods официально переведен в режим поддержки без активного развития. Его реестр станет доступен только для чтения 2 декабря 2026 года. Существующие сборки продолжат работать, но новые версии пакетов добавляться уже не будут. Flutter переходит на решение, которое официально поддерживает Apple, чтобы приложения продолжали получать обновления зависимостей и имели доступ к экосистеме Swift-пакетов.


Что будет с приложениями:

Flutter CLI автоматизирует переход. При сборке или запуске iOS / macOS приложения CLI сам обновит Xcode-проект для использования SwiftPM. Если приложение использует плагины, которые еще не перешли на SwiftPM, Flutter выдаст предупреждение и временно использует CocoaPods для таких плагинов.

В случае критических проблем можно временно отключить SwiftPM в pubspec.yaml:

flutter:
  config:
    enable-swift-package-manager: false

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


🔗 Читать подробнее


💡 Вывод:

Переход на SwiftPM - неизбежный шаг. CocoaPods устарел, и поддержка его заканчивается. Для разработчиков приложений процесс в основном автоматический. А вот авторам плагинов предстоит работа - иначе их пакеты станут несовместимыми и потеряют позиции на pub.dev. Лучше заняться этим сейчас, а не ждать, когда CocoaPods окончательно отключат.


➡️ Flutter & Dart | Мобильный трудоголик

🔢 NSCache в Swift: как правильно кэшировать и не бояться утечек памяти.

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


В чем подвох:

NSCache пришел из Objective-C, поэтому и ключи, и значения должны быть ссылочными типами (AnyObject). String и Int так просто не положить - нужно оборачивать в NSString или NSNumber. На практике это неудобно, но решается оберткой.


Как сделать удобную обертку:

Можно написать generic-класс Cache<Key: Hashable, Value>, который внутри хранит NSCache<WrappedKey, Entry>. WrappedKey - класс-обертка для ключа, Entry - для значения. Благодаря этому можно будет работать с обычными типами (String, Int и другими структурами).


Важные ограничения:

На проде почти всегда нужно задавать countLimit и totalCostLimit. Иначе кэш может незаметно разрастись и занять всю память. totalCostLimit - примерная граница суммарного размера объектов. cost при вставке - абстрактная метрика. Для изображений можно использовать width * height, для текста - count (length). Главное, чтобы более объемные объекты удалялись из кэша в первую очередь.


Когда NSCache подходит:

🔹Кэширование изображений в таблицах и коллекциях.

🔹Результаты разбора Markdown в NSAttributedString.

🔹Тяжелые вычисления (фильтры, предикты).

🔹Результаты парсинга, которые не критично потерять.


Когда не подходит:

🔹Данные, которые должны переживать перезапуск приложения (здесь нужно сохранять в память).

🔹Кэш с TTL (временем жизни).

🔹Сетевые ответы с управлением через заголовки (для этого есть URLCache).


🔗 Читать подробнее


💡 Вывод:

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


Подписаться на канал:
➡️ Telegram | Max

Закрытый канал:
🚀 Мобильный трудоголик PRO

🔢 Модуляризация iOS-приложений через SPM: как навести порядок в зависимостях.

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


Три слоя, один поток зависимостей:

Автор делит все приложение на три уровня:

🔹Common - самые низовые утилиты: логгеры, расширения, хелперы. Не зависят ни от чего внутри проекта.

🔹Services - два подмодуля: API (сетевые модели и эндпоинты) и Domain (бизнес-логика, сервисы, моки). Domain зависит от API и Common.

🔹Features - экраны на SwiftUI. Импортируют только Domain и Common. Никогда - API.

Зависимости текут строго снизу вверх. Модуль может зависеть только от того, что лежит под ним.


Как это выглядит в Package.swift:

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


Что в каждом модуле:

🔹API - только модели, которые зеркалируют ответ сервера, и типизированные эндпоинты.

🔹Domain - здесь происходит основная работа: модели предметной области, маппинг из API-моделей в доменные, сервисы (closure-based, без протоколов) и моки. Моки тоже живут здесь, потому что они возвращают доменные модели, а не API-шные.

🔹Features - чисто UI. Импортируют только Domain, используют моки для превью. Никакого сетевого слоя внутри.


ServiceEnvironment для массовой инъекции:

Когда сервисов становится больше двух, можно использовать контейнер ServiceEnvironment, который собирает все сервисы в одну структуру. Через кастомный модификатор все прокидывается в окружение одной строкой. Превью используют .mock, приложение - .live.


🔗 Читать подробнее


💡 Вывод:

Модуляризация через локальные SPM-пакеты - это не про идеальную архитектуру ради архитектуры. Это про скорость и масштабируемость. Начинать лучше с малого: вынести сначала Domain, потом API, а фичи - по мере роста. Результат - приложение, где новый разработчик за пять минут понимает структуру, а CI не ждет десять минут на сборку.


Подписаться на канал:
➡️ Telegram | Max

Закрытый канал:
🚀 Мобильный трудоголик PRO

🔢 Как выбрать архитектуру для iOS-проекта и не совершить ошибку.

Привет! Многие команды до сих пор внедряют сложные архитектуры вроде VIPER или Clean Architecture, считая их стандартом индустрии. Проблема в том, что эти решения часто не закрывают реальные проблемы проекта, зато увеличивают объем кода, замедляют сборку и усложняют онбординг новых разработчиков. Автор статьи проанализировал 147 проектов и результаты этого анализа выглядят довольно интересно.


Что говорят цифры:

Распределение архитектур среди проектов выглядит так: MVVM лидирует с 41%, MVC на втором месте с 34%, VIPER и Clean Architecture занимают 18%, TCA - 5%.

Главная проблема в том, что 73% проектов используют архитектуры, которые не решают их реальных проблем. Внедрение Clean Architecture в средних командах приводит к росту кода на 143%, замедлению разработки на 67% и увеличению времени онбординга новых разработчиков до трех недель.


Архитектуры и их зоны ответственности:

🔹MVC отлично подходит для команд из 1-3 человек и простых приложений. Проблема массивного контроллера возникает не из-за самой архитектуры, а из-за неумения выделять сервисы - в 89% проблемных приложений причина именно в этом.

🔹MVVM - золотая середина для команд 3-10 человек, особенно в связке с SwiftUI. Покрытие тестами вырастает до 67% (против 23% в MVC) при умеренном росте кодовой базы (+35%).

🔹VIPER и Clean Architecture оправданы только для команд от 15 человек, особенно в финансовых или медицинских приложениях, где цена ошибки измеряется миллионами. Плата за это - избыточный код: одна фича может занимать 7 файлов и 730 строк кода против 3 файлов и 260 строк в MVVM.

🔹TCA подходит для команд уровня Senior, которым нужна 100% тестируемость и предсказуемое состояние. Но порог входа высок - 2-3 месяца обучения, плюс возможные проблемы с производительностью.


Как не ошибиться с выбором:

Автор статьи рекомендует придерживаться такой формулы при выборе верной архитектуры:

🔹Для стартапа или MVP (1-3 разработчика) - SwiftUI с простым MVVM. Приоритет на скорость.

🔹Для среднего приложения (4-8 разработчиков) - MVVM + Coordinator + DI.

🔹Для корпоративных приложений (10+ разработчиков) - Clean Architecture или модульный MVVM. Приоритет на масштабируемость.


🔗 Читать подробнее


💡 Вывод:

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


Подписаться на канал:
➡️ Telegram | Max

Закрытый канал:
🚀 Мобильный трудоголик PRO

👨‍💻 Конец паники: почему ИИ не убьет ИТ, а сделает его сильнее.

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


Миф о замене - почему ИИ не станет вашим начальником:

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

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


Эволюция, а не революция:

🔹CASE-инструменты (вроде Rational Unified Process) обещали генерацию кода из диаграмм. Итог: их используют как вспомогательные средства, а код все равно пишут люди.

🔹SQL создавался для бухгалтеров, чтобы они сами делали запросы. Итог: SQL стал инструментом программистов.

🔹Конструкторы сайтов (вроде WordPress) не уничтожили веб-разработку, а создали огромный рынок для кастомизации, плагинов и сложных интеграций.

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


Парадокс спроса - почему автоматизация создает больше рабочих мест:

Логика «один программист с ИИ сделает работу пяти, значит, программистов нужно в пять раз меньше» - ошибочна. Экономика работает иначе:

🔹Снижается порог рентабельности задач. То, что раньше было невыгодно автоматизировать (слишком дорого), с ИИ становится целесообразным.

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

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

Проще говоря, ИИ не сокращает количество работы, он увеличивает объем работы, которую бизнес готов и может заказать.


Новая карта компетенций:

В новой реальности ценность смещается:

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

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

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


💡 Вывод:

ИИ не отбирает работу у программистов. Он отбирает работу у тех, кто отказывается меняться. Это естественный эволюционный фильтр.

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

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


➡️ Кот Денисова