Разработчик, который не знает Swift, AppKit и ScreenCaptureKit, за три дня выпустил нативное macOS-приложение Screen Loupe: экранную лупу с 10+ тысячами строк кода, сотнями тестов, подписью, DMG, открытым исходным кодом и пройденным ревью в App Store. Код писал Claude Code. Автор почти не программировал вручную: время ушло на требования, проверку решений, тестирование и уточнение поведения продукта (личный разбор автора).
Вывод, который он делает из этого кейса, касается ролей. Программист превращается в инженера-продакта, дизайнер - в дизайнера-продакта, а продакт перестаёт быть переводчиком между командами. В англоязычных компаниях роль product engineer уже существует, и автор ждёт, что в русскоязычных вакансиях скоро появится много инженеров-продактов, дизайнеров-продактов и других гибридов.
Дальше разбор по частям: что именно делал автор, какие навыки оказались критичными, почему статичный макет проигрывает работающему продукту и как дешевизна кода меняет экономику функций, нужных одному человеку.
Три дня, 10 тысяч строк и ноль знаний Swift: как это вообще возможно
Стартовые условия автор описывает без прикрас: «Swift и AppKit я толком не знаю, под macOS никогда не писал». Это не помешало ему описать задачу и запустить работу.
«В этот раз через три дня у меня было нативное приложение: 10+ тысяч строк, сотни тестов, подпись, DMG, open source, ревью в App Store. Понятно, что код писал Claude Code».
Синтаксис, знание фреймворков и рутинная сборка перестали быть входным барьером: их закрывает агент. Барьер переместился в другую область. Что именно должно получиться. Как проверить, что получилось то, что нужно. Как объяснить ошибку, когда поведение расходится с ожиданием.
Оговорка по масштабу. Это единичный личный опыт, а не замер производительности команд. Автор не приводит сравнений по срокам, стоимости или качеству с классической разработкой, поэтому переносить одну историю на весь рынок не стоит. Игнорировать показанный сдвиг тоже не получится: продукт собран, протестирован и прошёл ревью в App Store, а профильных навыков под macOS у автора не было (разбор кейса Screen Loupe).
Что именно делал автор, если не программировал
Режим работы автор описывает одной фразой: «Я почти не программировал, а работы было полно». Дальше эта работа раскладывается на понятные части.
Постановка требований и уточнение поведения
Чтобы лупа была полезной, сначала появился сценарий: рассматривать мелкие элементы интерфейса прямо на экране, не прерываясь на скриншоты. Затем автор описывал, что приложение делает при наведении, нажатии, анимации и переходных состояниях. Статичный снимок такие случаи не покрывает: у него нет динамики.
Здесь нужна продуктовая работа: определить, какие состояния важны, что считается корректным поведением, какой результат устроит пользователя. Знание Swift на этом этапе не требуется, а понимание интерфейса и сценария требуется целиком.
Тестирование и проверка решений
В приложении появились сотни тестов. Автор проверял решения и уточнял поведение, когда результат расходился с задуманным. Когда код генерирует модель, проверка становится главной точкой контроля: ожидаемое поведение формулируется заранее, а затем подтверждается тестом.
Та же логика видна в разборе рисков AI-генерации кода: генерация закрывает часть работы, а требования к человеку, который принимает результат, растут вместе с объёмом сгенерированного кода.
Инженер-продакт: почему программист становится продактом
Сдвиг обязанностей удобно показать таблицей.
| Роль | Фокус раньше | Фокус с AI-ассистентом | Ключевой навык |
|---|---|---|---|
| Программист | Написать код, знать синтаксис и API фреймворков | Сформулировать требования, проверить результат, отвечать за поведение продукта | Декомпозиция и проверка |
| Дизайнер | Нарисовать макет и описать спецификацию | Собрать работающий интерфейс и проверить его в живом продукте | Пользовательский сценарий и вкус |
| Продакт | Передавать требования между командами | Работать с кодом и прототипами напрямую | Понимание технической стороны |
Вопрос, который разработчик задаёт себе теперь, звучит иначе: не «как это написать», а «зачем нужна эта функция, кому она нужна и как проверить, что она работает». Автор Screen Loupe не писал код и при этом решал, что войдёт в продукт и как оно будет себя вести.
Расширение зоны ответственности не отменяет сопротивления. Часть разработчиков не хочет отдавать код агентам, и причины рациональные: авторство, контроль, инженерная ответственность. В разборе почему часть разработчиков не хочет отдавать код ИИ-агентам показано, где делегирование безопасно, а где ведёт к потере контроля.
Дизайнер-продакт: зачем рисовать кнопку, если можно сразу сделать настоящую
Макет кнопки и кнопка, которая нажимается, дают разный объём информации о продукте. Первый показывает, как элемент выглядит. Вторая показывает, как он ведёт себя: где ломается на длинном тексте, что делает при быстром двойном клике, как выглядит в состоянии загрузки.
Когда собрать работающий интерфейс стало дешевле, дизайнер может пропустить этап статичного макета и сразу получить прототип. Автор называет эту роль дизайнером-продактом: человек отвечает за пользовательский сценарий и поведение продукта, а визуальный стиль становится следствием этих решений.
Побочный эффект тоже заметен. Растёт риск скатиться в шаблонные решения, которые модель выдаёт по умолчанию. Дизайнерский вкус и понимание контекста работают фильтром между осмысленным интерфейсом и типовой заготовкой.
Что будет с Figma и почему AI-среда может стать конкурентом
Прогноз автора: инструмент дизайна получает конкурента в виде AI-среды, где главный объект - работающий продукт, а не макет. Аргументы простые.
- Скорость: изменения видны сразу, отдельный этап синхронизации макета и кода исчезает.
- Проверка: поведение интерфейса проверяется нажатиями, а не догадками по статичному кадру.
- Персонализация: правку под конкретный сценарий дешевле внести прямо в продукт, чем описывать её в макете и передавать в разработку.
Это именно прогноз, а не установленный факт. Figma не обязана исчезнуть: обсуждение интерфейса, библиотека компонентов и совместная работа в макете остаются полезными. Конкуренция идёт за роль основного места, где принимаются решения о продукте. Как AI-среда становится рабочим слоем для разработки и интерфейсов, разобрано в материале про Gradio как распространённый UI-слой для AI.
Персонализация софта: почему функции с одним пользователем стали выгодны
Экономику автор формулирует коротко: «Функция с одним пользователем, мной, теперь окупается». Раньше считать такую функцию не имело смысла: часы разработки на одного человека ничем не отбивались.
Сценарий Screen Loupe это показывает. Проблема начинается, когда мелкие элементы интерфейса нужно рассматривать часто: «Скриншот, открыл, увеличил, вернулся в приложение, снова скриншот». Для наведения, нажатия, анимации или переходного состояния снимок не подходит вообще. Готового инструмента под свой сценарий автор не нашёл. Похожие решения существуют: xScope, разные magnifier'ы, системные средства macOS, инструменты для измерения отдельных вещей, для веба - pixel perfect overlay. Ни одно не покрывало его потребности целиком.
Дальше работает арифметика. Если приложение под себя собирается за три дня, порог окупаемости опускается до уровня личной задачи. Софт становится персональным не по настройкам, а по набору функций, написанных под одного человека. Тот же вектор виден в персонализации ассистентов: характер AI-ассистента влияет на удержание сильнее, чем мощность модели.
Как применить этот опыт: практические выводы для разработчиков, дизайнеров и продактов
Что делать разработчику. Тренировать формулирование требований и проверку: описывать ожидаемое поведение до генерации кода и закрывать его тестом. Навык оценивать чужой код растёт в цене, а не падает. Полезно смотреть и на то, что на самом деле измеряют бенчмарки: разбор Real-SWE объясняет, почему выводы о «смерти» программистов делать рано.
Что делать дизайнеру. Осваивать инструменты, которые собирают работающий интерфейс, и переносить внимание с пикселей на сценарии: состояния, ошибки, крайние случаи. Этап статичного макета не исчезает совсем, но перестаёт быть единственным входом в работу.
Что делать продакту. Уходить от роли переводчика: работать с кодом и прототипами напрямую, писать требования так, чтобы их можно было проверить, участвовать в тестировании. Автор описывает именно такой режим: полно работы, почти нет ручного кода.
Границы подхода стоит обозначить прямо. Кейс единичный, метрик автор не приводит, а выводы о будущем ролей и о конкуренции с Figma остаются его прогнозами. Время на проверку и тесты входит в стоимость и может оказаться больше ожидаемого. Практический шаг для проверки на себе: взять одну небольшую задачу, которую вы не стали бы делать из-за отсутствия профильных навыков, и довести её до работающего результата с AI-ассистентом. Так видно, где экономия реальна, а где только кажется.