🧠 Memory Bank для iOS разработчиков

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

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

Здесь есть чем поделиться. Пока собрал прикольные библиотеки для iOS разрабов:

1️⃣ Awesome Cursor Rules

Главный агрегатор всех cursor rules. Внутри есть отдельные секции SwiftUI Guidelines и UIKit Guidelines — cursor rules именно под iOS-разработку

2️⃣ Memory Bank System v0.8

Это прям фреймворк с разными режимами. Динамично работает с разными фазами, супер круто экономит токены.

3️⃣ Two MCP Servers Made Claude Code an iOS Build System

Разбор XcodeBuildMCP + Apple Native MCP. Как они вместе дают агенту полный доступ к iOS toolchain структурированный JSON вместо парсинга логов. Вы ведь знаете что один сырой парсинг xcodelogs займет у вас 9к токенов? Ну тогда это сократит токены в сотни раз.

4️⃣ Rewriting a 12 Year Old Objective-C iOS App with Claude Code

Реальный кейс разраба который переписал апку с Obj-c на SwiftUI. Много полезных советов по настройке и CLAUDE.md

🤖 AI собеседования

Мы этого боялись и вот это настало. АИ Собесы.

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

Поэтому нетрудно было догадаться, что собесы первыми пойдут под автоматизацию.

1️⃣ Команда Sierra переделала весь процесс под АИ

Сейчас у команды такой процесс:

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

🟡Build. 2 часа в одиночестве, любые AI-инструменты, полная свобода менять скоп.

🔘Review. Демо, разбор продуктовых решений, ревью кода и обсуждение пути в продакшн.

Параллельно пилотируют debugging-интервью. Кандидату дают средний кодовый репозиторий и черновой PR от коллеги с фичей. Нужно его отревьюить и улучшить с помощью coding-агентов.

2️⃣ Meta AI-Enabled Coding Interview

Детальный разбор нового формата coding-интервью в Meta, где использование AI обязательно.

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

Советы:
🟣Недоиспользовать AI так же плохо, как перегружать им. Многие боятся штрафов за использование AI их нет. Оценивается lift поверх AI, а не количество написанного вручную кода.

🟣Уметь объяснить код, написанный AI. Не объяснять строчку за строчкой, а дать 2–3 предложения о логике и ключевых функциях.

🟣Не тупо промти. Используй DFS до понимания задачи. AI согласится и даст слабое решение. Лучше покажи топ-3 подхода с трейдоффами.

🟣Работать, пока AI думает. Проговаривай следующие шаги, пиши комментарии — не стой и не жди ответа.

Ну все. Можно сказать что рынок собесов скоро будет менять и у нас.

Ставь 🔥 если тебе нравятся собесы с АИ. И 💀 если считаешь это кринжем.

Количественные метрики против качественных. Outcome vs Output

С января я Competence Lead в Еде. Играющий тренер одной из мобильных команд. Помогаю выстраивать цели, достигать результата и объективно оценивать перформанс.

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

В этой роли я лучше начинаю оценивать результат. Более внимательно. Чужой. Свой. Чужой со своим. Чужой с чужим.

В эпоху AI закрывать задачи стало проще. Добиваться результата же все также сложно.

У одних 400к строк кода. Звучит мощно, пока не выяснится, что это форк библиотеки, JSON от тестов, линтер или кодогенерация. У других десятки закрытых тикетов, но это одна продуктовая задача и десять багов от нее же. Активности много, импакта мало.

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

Outcome vs Output.

Output. Это то, что ты произвел. Это код, фича, тесты, документация.

Outcome. Это тоо, что изменилось после. Поведение пользователя, метрики, деньги.

🟣Написал 2000 строк кода. Output есть. Outcome? Зависит от того, что это за код и использует ли его кто-то.

🟣Закрыл 15 задач за спринт. Output большой. Но если 10 из них баги от своей же фичи, Outcome под вопросом.

🟣Зарефакторил модуль. Output очевидный. Outcome ускорилась сборка.

🟣Добавил новый экран онбординга. Output есть. Outcome retention вырос на 8%. Вот это результат.

Что если остается только оценка активности? Что если оценивать только Output'ы?

В команде любая задача станет оверинжинирингом. Задачу на 10 строк кода будут раздувать на 500. Будет культура усложнения. Страх удалять код, плохие фичи. Время на проектирование никто не будет тратить. Только решаем костыльно задачи здесь и сейчас. Скоро перфомансревью, а на будущее не будем смотреть.

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

Как говорят "Лучше минимум аутпутов и максимум ауткамов".

Полезные ссылки
• How to measure productivity?