Привет, Хабр!

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

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

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

Мы в середине большого сдвига, который еще не устоялся. Многое из того, каким способом мы привыкли делить работу на части, придется пересобрать. Это мой взгляд, через мой опыт и то, что я вижу вокруг. В англоязычных компаниях роль product engineer уже появилась. Думаю, скоро и у нас в вакансиях станет много инженеров-продактов, дизайнеров-продактов и других гибридов. Попробую объяснить почему.

Началось все с экранной лупы.

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

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

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

Что-то похожее нашлось: xScope, разные magnifier’ы, системные средства macOS, инструменты для измерения отдельных вещей, для веба — всякие pixel perfect overlay. Но какого-то простого сценария, который сидел у меня в голове, я не нашел. Может, плохо искал. Но суть в другом, я задался вопросом: а насколько сложно сегодня не искать вообще а запилить свое?

Решил — сделал

Нюанс в том, что я много лет работаю на Mac, но никогда серьезно не разрабатывал под macOS. Я не знаю Swift, не знаю глубоко AppKit, никогда не работал со ScreenCaptureKit. Не знаю всех особенностей разрешений, sandbox, code signing и notarization. Не знаю, как правильно гнать поток с экрана и как это дружит с несколькими мониторами, Retina и разными системами координат. Более того, с 99% уверенностью готов заявить, что мало кто знает.

У меня есть хороший опыт разработки под Windows на Visual C++. Понадобись мне такая штука под Windows лет двадцать назад, я бы примерно понимал, куда идти. Но старый навык за это время, мягко говоря, протух, да и с нативным приложением под совсем другую платформу он помогает слабо.

В общем, есть идея простой программы, есть инженерный опыт и нет знания стека. Раньше тут было два пути: сесть учить Swift, AppKit и ScreenCaptureKit и вернуться к экранной лупе через пару месяцев, когда она уже не нужна, — или забить. Теперь появился третий: отдать реализацию coding agent’у. Я взял Claude Code.

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

Три дня спустя

Примерно через три дня у меня было готовое нативное приложение для macOS — Screen Loupe (код открыт). Работает оно ровно так, как я изначально хотел его заиспользовать на практике под свои личные нужды. На экран кладется Capture Area — рамка над интересующим местом, ее содержимое в реальном времени показывается в отдельном Viewer. Его можно увеличивать без размазывания пикселей, двигать, замораживать, смотреть цвет под курсором, включать pixel grid и линейку, накладывать референс и смотреть Difference.

Как мне сказал агент, внутри только Swift, AppKit, ScreenCaptureKit и Metal, сторонних зависимостей нет. Было написано 10+ тысяч строк кода и сколько-то там сотен тестов. Есть документация, описание архитектуры, скрипты сборки, подпись, notarization, DMG, репозиторий на GitHub, автоматизация рутинных операций. Все то, что появляется вокруг программы, если хочется получить не демку на вечер, а инструмент, которым можно пользоваться. Приложение ушло на ревью в App Store, выложено в open source, для обычной установки собраны подписанные DMG.

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

Я почти не программировал

Ха :) Я сказал неправду в заголовке. Я вообще не программировал. Для человека, который когда-то считал себя сильным разработчиком, это непривычная формулировка. Я почти не писал код. Но и сидеть три дня, глядя, как работает AI, мне не пришлось — работы было полно.

Я объяснял, что приложение должно делать, и смотрел, как оно работает. Говорил, что мне не нравится, менял требования. Спрашивал, почему архитектура устроена именно так, просил разобрать альтернативу, выяснял, что произойдет при потере permission и почему изображение странно ведет себя на Retina. Что будет если поток прервется, как его восстановить. Обсуждал производительность. Просил одних агентов проверить решения других. И тестировал приложение как пользователь: через пять минут работы находил то, что нормально выглядело в описании, но раздражало в реальности. Менял, снова пользовался, снова менял.

Да, мы знаем, что агенты не идеальны. Иногда они косячат. Иногда косячат много и сильно. Иногда входят в какой-то круг ада и похоти и просто жгут токены, а ты, когда уже сожжен 5 часовой лимит, просто новому чату говоришь откатить последние 10 коммитов и вбить молотком в память так больше не делать. Кстати, хороший добротный мат в чате иногда помогает разрядить обстановку и снизить градус внутреннего напряжения :) Продолжаем.

Программист никуда не делся. Он поднялся этажом выше

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

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

Агент говорит, что здесь нужен такой алгоритм, — почему? Предлагает такой паттерн — зачем? Строит архитектуру вот так — какие у нее достоинства? Что будет под нагрузкой? Где система развалится и как восстановится после ошибки? Какие состояния невозможны по дизайну, а какие мы просто надеемся никогда не увидеть? Где у нас одна степень защиты, а где три? Что случится, если пользователь сделает совсем не то, чего мы ждем?

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

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

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

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

А завтра мне понадобится другая экранная лупа

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

Допустим, завтра мне нужна не просто лупа, а нормальная screenshot studio. Я ведь уже выделяю область экрана — почему бы не снимать скриншоты именно там, сразу с нужным масштабом? Еще день — и такая функция есть.

Послезавтра мне нужно сравнить одно и то же место в приложении на iPhone и Android. Можно положить рядом два телефона или два эмулятора и смотреть глазами. А я хочу две линзы: одна Capture Area смотрит на iPhone, вторая на Android, рядом два увеличенных изображения одного элемента, масштаб и сдвиг синхронные, можно заморозить кадр и сравнить расстояния. Не знаю, есть ли такой готовый инструмент. Маловероятно, но как говорят математики, без ограничения общности предположим, что такого нет. Тогда, вы поняли мысль, еще два дня — и он есть. У меня.

Мне не нужен рынок. Мне нужна эта кнопка завтра

Здесь традиционная модель софта начинает выглядеть странно. Раньше, если мне не хватало функции, я мог написать разработчикам: «Ребята, сделайте возможность одновременно записывать две области экрана, синхронизировать их и экспортировать рядом». Хороший product manager вполне разумно спросит, сколько людей этим воспользуется. Окажется, 0,3%. А фича требует дизайна, разработки, тестирования, документации, поддержки, и тащить ее потом за собой десять лет. Конечно, ее никто не сделает — и с точки зрения производителя это правильно.

Но для меня эта функция может быть очень ценной. Например, я хочу показать разработчику, что одна и та же анимация на Android и iPhone ощущается по-разному. Снять два видео легко. А дальше начинается ерунда: открыть видеоредактор, импортировать оба ролика, обрезать, найти одинаковый момент действия, синхронизировать, подогнать скорость и размер, положить рядом, зациклить, экспортировать GIF или MP4. Все ради того, чтобы человек за пять секунд увидел: «А, понял, здесь действительно дергается иначе». Можно, конечно, просто отправить ему два видео с инструкцией «открой оба, поставь рядом, одновременно нажми Play, смотри вот сюда». Мы все понимаем, чем это закончится.

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

Рынку эта функция может быть не нужна. Мне она нужна завтра. И это наконец перестает быть большой проблемой.

Софт становится персональным не по данным, а по возможностям

К персонализации мы давно привыкли: у каждого свой YouTube (у меня патриотический Рутюб конечно же), свой Spotify (у меня Яндекс.Музыка), своя лента, свои рекомендации. Но сама программа у миллионов людей одна и та же — кнопки на тех же местах, те же возможности, workflow, который придумал кто-то другой. Покупая инструмент, мы покупаем и чужое представление о том, как должна быть устроена наша работа. Нет нужной функции — адаптировать под меня.

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

Если каждая такая возможность стоит недели работы команды, это бред. Если несколько часов или день — совершенно нормальная экономика. У конкретной функции может быть один пользователь. Я. И она все равно окупается.

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

Как Figma выиграла у Sketch

Когда-то интерфейсы спокойно рисовали в Photoshop. Потом появился Sketch и сказал: зачем рисовать UI в программе, которая создавалась для другой работы? Давайте сделаем специализированный инструмент. Это сработало.

Потом пришла Figma и победила не потому, что научилась рисовать прямоугольник каким-то новым способом. Дизайн перестал быть файлом на компьютере дизайнера и стал ссылкой. Один документ открывают дизайнер, разработчик, продакт, копирайтер, заказчик. Все видят актуальную версию, работают одновременно, никто не выясняет, у кого final_final_7.sketch. Это было изменение модели работы, а не очередная функция графического редактора.

Сегодня у Figma полно конкурентов: Lunacy, Penpot, локальные, self-hosted, бесплатные или сильно дешевле. Но хороший бесплатный редактор сам по себе Figma не угрожает, потому что она давно не просто редактор. Вокруг нее команды, библиотеки компонентов, design systems, плагины, процессы, подрядчики, клиенты. Нарисовать кнопку можно где угодно. Заменить весь этот контур гораздо сложнее.

Но такой контур защищает от более дешевого редактора. От того, что меняется сам объект работы, он защищает гораздо хуже.

А зачем вообще рисовать кнопку?

Последнее время я много смотрю на Claude Artifacts и похожие инструменты. Говорю: «кнопку чуть больше», «темнее», «здесь мало воздуха», «на мобильном это должно уходить вниз», «при нажатии покажи spinner, а если через пять секунд ответа нет — ошибку и Retry». И каждый раз меняется не картинка кнопки, а сама кнопка. Она нажимается, у нее есть состояния, анимация, ошибки, к ней можно подключить реальные данные. Это уже интерфейс, а не его изображение.

Отсюда неприятный для привычного процесса вопрос: зачем сначала рисовать то, что потом все равно придется программировать?

Старый процесс выглядит примерно так: идея → требования → Figma → prototype → handoff → код → проверка, насколько код похож на Figma → исправления.

А можно сказать так: «давайте попробуем две линзы», и получить работающие две линзы и посмотреть. А потом сказать: «Нет, так неудобно. Вторую сдвинь, между ними оставь восемь пикселей, при resize размеры синхронизировать. Хотя нет, синхронизацию сделать optional». И снова посмотреть.

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

Что тогда будет с Figma

Figma это, конечно, видит. Figma Make уже делает прототипы на реальном коде и умеет работать с локальным production code, а сама Figma явно пытается соединить canvas, design system и код в одну среду. Так что вопрос не в том, заметит ли она происходящее, а в том, что в итоге окажется главным: AI-среда, внутри которой иногда нужен canvas, или Figma-подобная среда, где AI — еще один способ управления?

Сегодня в Figma главный объект — дизайн, а AI помогает его создавать и превращать во что-то работающее. В Claude и подобных системах главный объект все чаще — сама работающая штука, а визуальный редактор, если понадобится, становится одним из режимов работы с ней. Prompt, canvas, code, running app — разные представления одного продукта.

Если так, то следующий большой конкурент Figma может вообще не называться дизайн-редактором. Это может быть IDE, в которой основной объект редактирования — работающий продукт.

К чему я все это?

Дизайнер тоже меняется

Здесь легко скатиться в любимое интернетом «дизайнеры больше не нужны». Я так не думаю, я вообще очень ценю и уважаю дизайнеров, они вкладывают душу, двигая унылое г…, придуманное product owner’ами к совершенству, да простят меня небеса, но профессия точно начинает меняться.

Хороший дизайн — это не только визуальная красота. Это решения о том, какое состояние увидит пользователь и что произойдет при ошибке, что здесь главное, а что можно спрятать, как человек поймет, что действие завершилось, и можно ли его отменить. Как интерфейс ведет себя на маленьком экране, с клавиатуры, когда данных нет. Что человек почувствует, когда система ответит через три секунды вместо ста миллисекунд. Это проектирование поведения.

Поэтому дизайнер, как мне кажется, превращается в дизайнера-продакта, который работает не с изображением продукта, а с самим продуктом. Canvas при этом не обязан исчезать: иногда мышкой подвинуть элемент проще, чем объяснять словами, иногда удобнее component tree, prompt или код. Непонятно только, почему все эти способы должны жить в разных профессиях и разных программах, если объект у них один.

Зачем тогда продакт

Если программист начинает думать о том, как должна вести себя система, а дизайнер — работать с тем, как она реально работает, оба быстро заходят на территорию product manager’а. Тогда он зачем?

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

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

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

Если разработчик говорит исключительно на языке технологий — «здесь у нас Kafka, там Rust, здесь event sourcing, а вот это перепишем, потому что архитектурно красивее», — но не может объяснить, что от этого почувствует пользователь, что-то не так. Если дизайнер говорит только «здесь 16 пикселей, такой шрифт, такой radius», но не понимает, зачем пользователь вообще пришел на этот экран, — тоже. А если продакт в ответ только таскает между ними тикеты, он и сам не очень нужен.

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

Границы профессий сдвигаются

Специализации при этом остаются. Я не стану за три дня macOS-разработчиком уровня человека, который десять лет пишет под AppKit. Разработчик не станет хорошим дизайнером оттого, что Claude умеет двигать ему кнопки. Дизайнер не начнет внезапно понимать распределенные системы, продакт не станет специалистом по Metal. И не должен.

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

Поэтому, начинай я сейчас карьеру программиста, я бы гораздо меньше переживал о том, какой язык выбрать первым. Срок жизни конкретного навыка сокращается, а цена понимания принципов растет. Как устроены системы и как через них проходят данные. Как искать причину ошибки. Что такое latency и consistency, почему одна архитектура масштабируется, а другая нет, как устроена безопасность, как измерять производительность, как проверить гипотезу и понять, что тест действительно что-то тестирует. И рядом — совсем не программистские вопросы: кто пользователь, что он сейчас пытается сделать, где продукт заставляет человека работать на себя вместо того, чтобы работать на человека. Дизайнеру точно так же мало учиться только Figma, а продакту — только писать PRD. Инструменты будут меняться очень быстро. Умение видеть систему целиком протухает гораздо медленнее.

Возвращаясь к экранной лупе

Три дня назад мне просто хотелось нормально рассмотреть несколько пикселей на экране. Раньше я бы нашел подходящую программу или приспособился к существующим — изучать разработку под macOS ради небольшой лупы было бы экономически бессмысленно. В этот раз через несколько дней у меня появился работающий продукт.

И важным оказалось не то, что AI написал 10 тысяч строк. Через год напишет больше. Важно, что все три дня я тоже работал, просто я был и не программистом, и не дизайнером, и не тестировщиком. Я был продактом, который делал реальный современный продукт под конкретные потребности пользователя таким образом, чтобы эти потребности были закрыты.

Для справки, я попросил агента оценить, сколько бы мидл разработчик делал бы примерно такой продукт? И ответ довольно внушительный: 6-9 месяцев под ключ. Подтвердить или опровергнуть реально не могу, но выводы делайте сами.

Теперь, глядя на следующую функцию, я думаю не «есть ли программа, которая это умеет», а «мне это действительно нужно?». Если нужно, вопрос, существует ли такое на рынке, перестает быть главным.

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

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

Когда-то в моей трудовой написали «инженер-программист». Если бы тогдашнему мне эту запись делали сегодня, я бы попросил написать «инженер-продакт».

P.S.

Screen Loupe лежит в open source: github.com/ayenora/screen-loupe. Если вам тоже была нужна такая штука — пользуйтесь. Понравится — ставьте звезды, присылайте issues и идеи. Несколько обновлений я точно еще сделаю. Особенно теперь, когда фраза «было бы неплохо добавить…» звучит совсем иначе, чем раньше.