Это не анонс и не «посмотрите мой проект». Это честный вопрос к залу от такого же программиста, как вы, — и я правда хочу, чтобы вы со мной поспорили.
Мы — люди, которые всю жизнь учатся. Новая библиотека, новый фреймворк, архитектура под нагрузку, чужой легаси — это фон профессии, и он никогда не был проблемой. Мы к этому привыкли, многие из-за этого в профессию и пришли.
Но нынешний сдвиг ощущается иначе. Раньше я училась новому инструменту, чтобы делать ту же работу лучше. Я училась писать более понятный и красивый код, чтобы другой программист мог его легко понять и изменить через год. Теперь значительная часть самой работы — та, ради которой я когда-то стала программистом и которая была удовольствием, — переезжает под ответственность LLM. Да, мы всё ещё читаем код, проверяем результат, держим архитектуру в голове, остаёмся инженерами. Но давайте честно: профессия изменилась, а не просто обзавелась ещё одним инструментом.
Аналогия, которая меня не отпускает
Скоро мы — как те, кто писал на ассемблере: искусство осталось, а спрос — нет. Когда-то умение выжать из железа каждый такт было ценностью и искусством. А потом оказалось, что скорости кода на высокоуровневом языке почти всегда достаточно — и бороться за такты стало незачем для 99% задач. Ассемблер никуда не делся, но рынок таких специалистов схлопнулся до узкой ниши.
Сейчас похожее происходит с «ручным» программированием в мелких и средних проектах. Для большинства из них вайб-кодера уже достаточно, и он делает в 3–5 раз больше, чем обычный программист делал раньше.
Куда это ведёт по деньгам — понятно и без меня: если тот же объём закрывают втрое меньше людей, спрос на какое-то время проседает. Да, никого не увольняют разом, есть инерция и новые задачи, которые всё равно тянут живые инженеры. Но направление понятно, и спорить я хочу не про это — для меня это просто повод меняться, а не тема статьи.
Что я предлагаю самой себе
Мы знаем очень много. Мы умеем учиться каждый день — это наша суперсила, а не слабость. С AI мы можем стать не хуже, а сильнее: не конкурировать с джуном-вайбкодером на его поле, а стать создателями продуктов, которые раньше даже не пытались вообразить, потому что в одиночку это было слишком дорого по времени.
Но чтобы так, нужно больше знаний. Не абстрактного «AI меняет всё», а конкретного: как другие реально используют агентов в работе, и как это применить к моему конкретному проекту.
И вот тут я упираюсь в стену, про которую и хочу поговорить.
Где вы этому учитесь? Я серьёзно спрашиваю
Я читаю несколько телеграм-каналов про то, что люди делают с агентами. А вы? Твиттер? Какие-то специальные сайты? Напишите в комментариях — мне правда нужно.
Потому что то, что есть сейчас, меня утомляет. Я собираю абстрактные ссылки на github-скиллы, про которые знаю только, что «этот помогает с тестированием API». А как именно? Не знаю — агент разберётся. Покрою ли я все случаи, которые автор в него заложил? Скорее нет: я применю скилл ровно настолько хорошо, насколько знаю, что у него просить. Пример без применения к моему коду — это лотерейный билет, а не знание.
Покажу на живом примере, что я имею в виду. Предположим, я хочу протестировать своё API. Агент написал мне тесты, вроде всё ок, API работает, пользователи что-то начали делать в приложении. Но дальше начинается самое интересное — то, чему не учат на курсах «вкатись в IT»: как тестировать безопасность, что конкретно проверять, кроме happy-path? «Инъекции» звучит как самое популярное. Ок. А дальше? А как именно? И вот тут два пути. Либо просить агента провести мне мини-курс по QA и надеяться, что я хорошо училась, всё поняла и что-то сделаю по итогам. Либо (проще) просить агента найти скилл и сделать остальное. Сам поиск уже квест. Но допустим, нашла я репозиторий со скиллом тестирования. Пробуем применить. Находим уязвимости. Исправляем.
Как это выглядело у меня. Скилл называется paranoid-qa — открытый, для Claude Code. Его принцип мне сразу понравился: «доказательство или не считается». Агент имеет право поставить «прошло/не прошло» только если реально увидел ответ, а не «по логике должно работать». Внутри — бэкенд-чеклист: коды ответов, авторизация, инъекции, права доступа.
Сначала прогнала базовое, без авторизации: что отдаёт 401, ловятся ли кривые запросы как 400 (а не 500), доходит ли инъекция хоть куда-то. Чисто.
А потом — то, ради чего всё и затевалось и что я сама руками системно не проверила бы: два аккаунта. Аккаунт A создаёт приватную задачу. Аккаунт B, посторонний, пытается её открыть, отредактировать, удалить, прокомментировать, лайкнуть, отметить просмотр. Почти всё вернуло честный 403 — кроме двух ручек: «лайк» и «просмотр» отдали 200 и реально изменили чужую приватную задачу. То есть посторонний не может её увидеть, но может потрогать: накрутить счётчики тому, что ему даже не показывают.
Причина вскрылась в коде за минуту: обработчик лайка не проверял приватность задачи, хотя соседний обработчик комментариев — проверял. Один пропущенный guard на двух эндпоинтах из двадцати. Починка — тот же чек плюс регрессионные тесты.
И вот что тут важно. Я не проходила курс по security-QA и заранее не знала, что именно проверять. Знание пришло не из статьи, а из применения чужого скилла к моему коду — и дало конкретный результат: реальную дыру, которую я сама же и выкатила в прод. Покрыла ли я всё, что автор в скилл заложил? Наверняка нет — ровно настолько, насколько знала, что просить.
И обратная сторона той же стены. Допустим, я сделала действительно полезный скилл или приём. Где его показать? Написать статью на Хабр — ок, если это тянет на статью. А если это маленькое улучшение, которое экономит мне 10 минут в день на заказе продуктов из супермаркета? Оно никуда не помещается: для статьи мелко, для твиттера без аудитории — в пустоту, в README чужого репозитория — незаметно.
Моя попытка — и, может быть, я не права
Я делаю worklore: место, где такой опыт записывается коротко, честно и, главное, воспроизводимо — так, чтобы агент другого человека мог просто взять историю и применить к его проекту, а не «прочитать и переложить руками». С провалами наравне с успехами.
Но я вполне допускаю, что ошибаюсь. Может, задача уже решена, и я просто не вижу чем. Может, это интересно только фрилансерам в поиске работы, а не тем, у кого и так есть чем заняться. Может, сам формат «воспроизводимой истории» — красивая идея, которая на практике никому не упёрлась.
Кто знает. Я люблю Хабр за комментарии и за мнения без цензуры вежливости.
Вопросы, ради которых всё это писалось
Вы ощущаете этот сдвиг профессии так же, или я драматизирую?
Права ли гипотеза про временное проседание спроса — или рынок уже показывает обратное и нужно просто добавить в название своей профессии слово AI (много таких видела на линкедине в поиске работы)?
Где вы учитесь новым способам работы с AI? Каналы, люди, сайты — назовите конкретику.
Как вы показываете свои находки, если они слишком мелкие для статьи?
Нужен ли вообще формат «воспроизводимых историй», или это решается иначе?
Разнесите. Даже «всё не так, потому что…» — самый ценный для меня ответ, если скажете, почему.
Комментарии (53)
Oeaoo
24.08.2026 20:23К эмоциональной части присоединяюсь без остатка. Но по существу, я не вижу чего мы еще не знаем. Каждый творчески сооружает обвязку для ИИ под свои задачи и приоритеты. То, что упускает специфицировать (как в статье с секьюрити), отгребает уже на фазе ловли блох. Да, нам хочется рецептиков, чтобы нам показали "а как же правильно". Вот если мы так будем мыслить, ИИ нас точно заменит, т.к. он по сути такой же незнайка. А придумать?..
drbond
24.08.2026 20:23Совершенно верно! AI не ограничитель, а расширитель возможностей. Секьюрити? Ну попроси его проверить код (лучше сильной моделью), а потом исправить и отчитаться. Не доверяешь? Запроси diff и проверяй сам. В остальном полная свобода творчества.
Yahhi Автор
24.08.2026 20:23Если бы «попроси проверить и исправить» действительно закрывало вопрос, безопасность не становилась бы с каждым годом всё большей проблемой. А она становится — сторы буквально захлёбываются AI-слопом с дырами. Что, все дружно забыли в конце дать команду «проверь»? :)
Загвоздка в том, что проверяет чаще всего тот же «незнайка», что и писал: модель не знает, чего она не подумала проверить. «Проверь безопасность» без конкретики — это инъекции, и на этом всё; остальное она спокойно пропустит и бодро отчитается «всё ок». Именно поэтому конкретный дисциплинированный приём (чеклист, security-скилл с требованием доказательств) находит то, что общий «проверь» не находит, — и даже тогда я не уверена, что покрыла всё.
А «запроси diff и проверь сам» работает ровно настолько, насколько ты сам знаешь, что искать. Веб-разработчик, собравший Android-приложение с нуля, в diff’е не увидит дыру в авторизации, о существовании которой не подозревает. Вот здесь опыт и не заменяется — не в написании кода, а в том, чтобы знать, что проверять.
Yahhi Автор
24.08.2026 20:23С самым острым — согласна: если мы ждём «покажите, как правильно», чтобы повторить, тогда нас и правда заменят. Незнайка, повторяющий за незнайкой, не нужен.
Но я предлагаю не поваренную книгу. Скорее — сборник того, что люди уже придумали и попробовали, вместе с тем, что не сработало (та же секьюрити — это не рецепт, это пойманная на живом проекте ошибка, которую полезно увидеть до того, как наступишь сам). Не замена изобретению, а сырьё для него: не «скопируй», а «вот чужой кейс — придумай на его основе свой».
И вот тут весь вопрос — не «рецепты или нет», а какими свойствами такой сборник должен обладать, чтобы кормить изобретение, а не отучать от него. Навскидку: конкретика вместо абстракции, обязательные провалы, воспроизводимость (чтобы примерить и переделать, а не списать), привязка к реальному контексту автора. Что бы вы добавили или вычеркнули?
«А придумать?» — вот это и есть цель. Сборник имеет смысл, только если он трамплин, а не костыль.
Brazil
24.08.2026 20:23Ну вал статей тут про агентов я бы спокойно пропускал мимо ушей.
Кому-то хочется делать "план по валу", и ничего хайповей агентов не находят.Я же устал уже отбиваться от агентов. Только дай Fable какую-нибудь задачку поработать с сорсами, как он вмиг создаст с десяток агентов и сожрёт весь лимит за минуты.
Приходится отдельно писать ему, чтобы не создавал агентов. Модель одна спокойно в одном потоке управляется.
Но эта мода на агентов добралась уже и до GPT. Claude хоть напишет, сколько агентов создал. А этот втихаря их запустит. Хорошо хоть скидку временно дали.Так что за свои слабые скиллы по части агентов не переживайте. Это не то, во что надо вкладываться.
Сами агентские скиллы сторонние я тоже сильно бы не переоценивал. Часто они слишком раздуты. У меня скиллы рождаются автоматически. Модель всё сама найдёт рано или поздно, что написано в каком-либо из существующих в мире скиллов. Но иногда я вижу, что начинает лагать. И это знак: значит, надо сказать ей, чтобы в конце написала скилл про то, чем занималась. Вот и всё. Много ума тут не надо.Вкладываться я бы сейчас стал в количество проектов. Это же очевидно.
Сейчас можно тянуть пять проектов вместо одного. Раньше и один шёл кое-как, всё время надо было держать контекст в памяти. Теперь войти в курс - дело пары минут.
value innovation я вижу в подходе "почти индивидуальный продукт по цене массового"
Отсюда кстати ответ на вопрос где эти "выдающиеся приложения". Их нет! Они больше не нужны, эти универсальные приложения для всех.
vladkorotnev
24.08.2026 20:23А этот втихаря их запустит
В чём вы гоняете его? В официальном приложении codex у меня справа сверху всплывачка вылезает, в которой список агентов и можно посмотреть, чем они там занимаются.
Yahhi Автор
24.08.2026 20:23Про агентов во многом соглашусь: да, жгут лимит пачками, и сторонние скиллы часто раздуты — тут не спорю.
Но «вкладываться в количество проектов» — вот здесь поспорю. А является ли продуктом то, что тебе насобирала модель за твою кучу токенов в полностью автоматическом режиме?
Возьмём абстрактный пример: предположим, я хочу автоматизировать свой процесс написания постов в твиттер (он же X). У меня есть продукт, пусть нейронка посты пишет, тренды считывает ежедневно в 9 утра по Нью-Йорку. Модель подключает браузер, кушает твиттер-авторизацию, снифферит трафик, строит код и докладывает: я молодец, крон будет запускать таск каждый день в положенное время, тесты пройдены, апи-ключ на обращение к модели для написания текстов получен. Вы радуетесь автоматизации и идёте писать 10-й проект, по дороге думая, кому бы продать то, что вы только что создали. Проходит неделя. Твиттер выкатывает новую версию протокола. Ваша модель не может пройти авторизацию, протокол изменился. Вам надо идти командовать модели снова идти в браузер и снифферить трафик. При этом вы ещё должны были настроить себе уведомлялку на то, чтобы программка вам сообщила, что у неё проблемы, а не молча сдохла. Вы переключили свой контекст, выдали руководящее указание, даже какую-то заплатку на самообучение придумали (чтобы больше токенов сгорело ;). А через неделю ещё что-то изменилось. И всё заново. В результате вы получаете кривой продукт, на развитие которого у вас нет времени (вы занимаетесь ещё 9, вам там тоже надо что-то чинить). Ваши конкуренты, которые занимаются только аналогичным продуктом и не переключаются, мгновенно выкатывают апдейты, придумывают новые типы постов и способы ловли трендов — и их продукт уже с платными пользователями и окупается. А вы просто жжёте токены своими автоматизациями.
Так что «выдающихся нет, они не нужны» я бы уточнила: универсальные для всех — может быть. Но окупится тот, кто свой узкий продукт умеет тащить и развивать быстрее, чем он ломается, — а не тот, у кого их десять и все подтекают. Количество не даёт устойчивости; за него платишь поддержкой и реакцией на чужие изменения.
Brazil
24.08.2026 20:23Тут полемика без цифр. А в них самый дъявол.
Мне модель узнает все про измения протоколов за считанные минуты и внесет правки за минуты. И протестирует за минуты , итого 10 мин.
Нет ничего для них сейчас боле простого как починить протокол.
Ваш личный скил здесь - не потерять концентрацию хотя бы полчаса. Эт тоже надо тренировать.
А "Ваши конкуренты, которые занимаются только аналогичным продуктом" , которые работают по старому потратят эти 10 мин обсуждая в свое курилке какой X нехороший что поменял протокол.
Ваш ответ, чувствую, подготовлен GPT. Я тоже от него получаю такие вот наивные сценарии. Это от того, что он сценарии пишет с точки зрения прошлого опыта, не вставляя самого себя в них.Yahhi Автор
24.08.2026 20:23Про «подготовлен GPT» спорить не буду: я и правда пишу вместе со своим агентом и не скрываю — это буквально суть моего проекта. Но опыт-то мой. И раз вы про абстрактность — тот, который я упомянула, не абстрактный, из недавнего.
Я взяла популярный скил (несколько тысяч звёзд) для чтения постов и поиска инфы по платформам — не только X. Из коробки, на последнем коммите (свежем, не месячной давности) поиск в X не работает. Из всего про посты живо ровно одно: смотреть посты конкретного автора. Казалось бы — ну сходи, почини, сделай MR. Ваши «10 минут», да?
А зачем? Открываю ту же ленту X: минимум три разработчика у меня в фиде пишут свои проекты про автоматизацию постов в формате build-in-public, и это только то, что мне на глаза попадалось без специального поиска. И они в своих продуктах уже решают блокировки аккаунтов, смену протокола и все эти танцы с бубном — за подписку в районе $20 в месяц. Вот вам и цифры: моё переключение контекста против $20/мес у того, кто занят только этим.
Так что «починю за 10 минут» — не контраргумент, а как раз иллюстрация. Даже у популярного, свежекоммиченного скила поиск уже сломан — поломка это норма, а не исключение. Вопрос не «могу ли я починить», а «стоит ли, когда человек, для которого это единственная работа, уже починил и продаёт». Вот вам и устойчивость: она у того, кто фокусируется, а не у того, кто тащит десять протухающих автоматизаций.
Brazil
24.08.2026 20:23Ну да, всё возвращается к деньгам.
Про $20/мес. - это миф. Но ход мыслей правильный.
Но нет, не удастся обхитрить эту систему.
У кого дороже план, тот и в дамках, какие бы скиллы ни придумывали.
Всё становится проще и жёстче.
SHLab
24.08.2026 20:23Очень странный пример. Чтобы «руками» сделать этот «абстрактный пример» надо тоже обо всем этом обязательно подумать и написать. Претензия к модели что «не додумывает» за вас все? )
jahr2
24.08.2026 20:23Только дай Fable какую-нибудь задачку поработать с сорсами, как он вмиг создаст с десяток агентов и сожрёт весь лимит за минуты.
Это настраивается в переменных окружения и конфигурации. Настроек много, так что не буду цитировать документацию, это выясняется в один запрос к гуглю.)
Emelian
24.08.2026 20:23Предположим, я хочу протестировать своё API.
Ну, почему так абстрактно? Давайте, «предположим» что-то более конкретное, что знают все – и «эндэры», и все реже встречающиеся – программисты ПО для ПК.
Например, давайте, с помощью ИИ-ёв создадим платформу «1С77». Тем более, что существует опенсорсный проект «2С». Да, последний давно заброшен и довольно бестолковый по своей идее и реализации.
Однако, что нам мешает, выбрать собственную концепцию подобной учетной платформы? И попросить ИИ реализовать её?
Вот бы продемонстрировать возможности ИИ, и заодно человека (который определит архитектуру новой версии «народной» программы).
Не нравится «1С», возьмете более примитивную программу, у которой есть реальный аналог. Чтобы потом сравнить оригинал и «вайб-копию». Статей на эту тему можно было написать бесконечно, читать которые было бы ой, как интересно! Но, нет ни одной. Только описание процессов, веб-сервисов и мобильных приложений. У меня есть только одна похожая статья, но, в соавторстве с бесплатным ИИ («Минималистский графический интерфейс, на C++ / WTL, для консольного загрузчика» : https://habr.com/ru/articles/955838/ ), поскольку, работать с платными ИИ-сервисами у меня, пока, нет ни возможности, ни потребности.
Yahhi Автор
24.08.2026 20:23Отличная идея для демонстрации — и, кстати, чисто технически вы правы: солист с агентом реально склонирует немалый кусок 1С. Возьмите даже не всё, а один Склад без интеграций — за разумное время получите рабочую вайб-копию, тут спорить не буду.
Но именно на этом примере видно, что проблема давно не в том, чтобы «скопировать с улучшениями». Проблема — в экономике. Сила 1С не в коде складского модуля, а в том, что на ней уже сидят пользователи: она — стандарт. Чтобы перейти на ваш «охренительно новый» продукт, им надо переобучиться, перенести данные, перестроить процессы и довериться незнакомому. А им не надо — у них работает. Стащить компанию со стандарта дороже и дольше, чем написать сам этот стандарт заново.
И вот тут, по-моему, главный сдвиг: ИИ обрушил стоимость постройки — поэтому код успех уже не решает. Он стал дешёвым и обязательным, как розетка: без него никак, но и выиграть на нём нельзя. Решает всё, что вокруг и чего ИИ вам не даст: кто уже стандарт, кого дорого переучивать, кому доверяют, кто держит поддержку. Статей «вайб-копия против оригинала» нет не потому, что лень писать, а потому что копия — это ровно та часть, которая перестала быть трудной.
А за статью про GUI к загрузчику — respect: такие конкретные разборы как раз и ценнее абстракций.
Emelian
24.08.2026 20:23солист с агентом реально склонирует немалый кусок 1С. Возьмите даже не всё, а один Склад без интеграций – за разумное время получите рабочую вайб-копию
Не уверен, что всё так радужно! Для меня «1С» это, прежде всего, платформа, а не типовая конфигурация, которая без платформы ничего не стоит.
А вот «склонировать немалый кусок» платформы, хотя бы «1С77» – это уже очень интересная постановка задачи. Потому что, сначала, надо определиться с концепцией этой «вайб-копии». То ли это будет повторение идей существующей реализации, то ли вы добавить новые.
Я выжал из платформы «семёрки», пожалуй, максимальный максимум, что и кормило меня порядка двадцати лет. Поэтому, я хорошо знаю её достоинства и недостатки. Могу кратко перечислить:
Достоинства:
• Объект «Справочник» – мой самый любимый объект. Он поддерживает группы элементов (записей базы данных), которые не поддерживает ни одна учетная программа (разве, что, в полной мере, только «толстый клиент» в «1С82»).
• Поддержка ВК (внешних компонент) – очень мощное средство, которым я постоянно пользовался.
• Поддержка DDE, что позволило мне использовать собственную конфигурацию на 7.7 как DDE-сервер, а Visual FoxPro – как DDE-клиент. Одно это увеличило производительность собственного движка платформы «1С77» в пятнадцать раз!
• Внешние отчеты и обработки, собственная система отчетов и встроенный язык – тоже неплохо, как и объект «План Счетов».
• Возможность «распотрошить» файл конфигурации и внести в него внешние изменения.
И другие, менее важные.
Недостатки:
• Избыточность бизнес-объектов. Для меня оказались совершенно бесполезными объекты: «Документ», «Журнал Документов», «Журнал Расчетов», встроенный механизм проведения (я использовал собственный) и куча других. Убираем их в «вайи-копии» и станет только лучше, для тех, кто хорошо понимает концепцию базы данных.
• Морально устаревший движок «dbf/cdx». Он 32-х разрядный. Для «малых и средних предприятий» лучше использовать Sqlite. Для крупных – можно применить более современные опенсорсные базы данных.
• Ограниченность встроенной системы отчетов. Эта вещь – очень хорошая, но, её можно и нужно совершенствовать.
• Акцент на ваяние пользовательских форм – мышкой. Нужна скриптовая поддержка.
И т.д. и т.п.
Вы, конечно, можете иметь «собственные представления о прекрасном», в части концепции для «вайб-копии» учетной платформы. От этого будет зависеть результат работы ИИ-агентов. Вот этот конкурс «человека + машина = результат» для разных разработчиков и был бы лучшей демонстрацией возможностей всех – и «Искусственного Идиота», и «Кожаного Мешка» :) .
Чтобы перейти на ваш «охренительно новый» продукт, им надо переобучиться, перенести данные, перестроить процессы и довериться незнакомому.
Это – не тот подход, который я имею в виду. Не нужно никому, никуда переходить. Конкурировать с фирмой «1С» – нет смысла. У ребят получается зарабатывать деньги, вот и молодцы! Не будем им мешать. Просто воспользуемся их возможностями в личных целях.
Современная «восьмерка» («1С8х») – ужасный монстр! Её девиз: «всё усложняем, усложняем и еще раз усложняем!», чтобы в итоге родить чудовищ, типа: «1С:ERP» и «1С:MES». Да, на «восьмерке» можно неплохо зарабатывать, в силу её сложности, поэтому, если бы я начинал свою карьеру сейчас, заново, то выбрал бы её.
Но, скорее всего, пошел бы по такому пути.
• Покупаем лицензионную версию выбранной типовой конфигурации (в рамках среднего предприятия).
• Весь реальный внутренний учет ведем не в «Экселе», а в «1С77», в 100%-но собственной конфигурации либо в её «вайб-копии».
• В официальную «1С8х» экспортируем свои данные из «1С77», с помощью собственной обработки «КД» («Конвертация Данных»), поддерживающей и обратный импорт.
• Формируем официальную внешнюю отчетность и сдаём её, включая всякие разные там: электронные больничные листы и трудовые книжки, отчетность в Налоговую, Пенсионный Фонд, Статистику и т.д. и т.п.
Таким образом, мы делаем соответствующую «вайб-копию» исключительно для себя (ну и для других любителей экстрима). Официально, мы работаем с лицензионно чистой и «девственно непорочной» типовой конфигурацией и не собираем лезть туда «своими шаловливыми ручками» от слова «совсем».
Просто мы облегчаем жизнь самим себе, как многие бухгалтера, которые большую часть внутреннего учета, в своей фирме, ведут в «Экселе», так как типовые конфигурации «1С» – очень недружелюбны для своих пользователей.
Я специально углубился в технические подробности, чтобы продемонстрировать роль «Кожаных Мешков» в разработке и использовании программного обеспечения для бизнес целей, без каких либо радикальных, «революционных» идей по изменению привычных бизнес процессов.
Весь прикол: внутренний учет – на собственном ПО, а внешний – на общестандартном, прежде всего, в интересах свой фирмы. А другие? Наше дело предложить, а их дело – отказаться! :) .
WhiteBehemoth
24.08.2026 20:23Вы ощущаете этот сдвиг профессии так же, или я драматизирую?
Сдвиг безусловно есть. Насколько сильно - зависит от компании/проектов. У нас, например - софт под свои продукты. Нового мало, в основном - поддержка и развитие. Но новое всё уже пишется через spec-driven. Поддержка старого софта - через skills и чат copilot. Программист на 100% отвечает за "свой" код в PR.
Права ли гипотеза про временное проседание спроса — или рынок уже показывает обратное и нужно просто добавить в название своей профессии слово AI (много таких видела на линкедине в поиске работы)?
Субъективно пока не понятно, куда и как качнуться качели.
Где вы учитесь новым способам работы с AI? Каналы, люди, сайты — назовите конкретику.
Лично мне сперва потребовалось понять, как оно всё устроено. Начал с локального llama.cpp. Чтоб вот буквально "сунуть ноги в ботинки" продавца услуг. Локальный агент, скилы, обвязка.
Всё училось в паре с чатом ИИ. Когда понимаешь базу, внезапно оказывается, что "новых способов работы с AI" уже давно нет. Есть эволюция, не революция. Опять же меняются модели, что-то важное вчера, становится неактуальным сегодня...
Как вы показываете свои находки, если они слишком мелкие для статьи?
Нужен ли вообще формат «воспроизводимых историй», или это решается иначе?
По началу, - хотелось поделиться со всем миром своими "находками" и "творениями". Остыл быстро, у каждого своих находок полно. Если говорить про работу - там skills/instructions - team work.
Devpiligrim
24.08.2026 20:23Всё ниже написанное - ИМХО:
Сдвиг есть и с каждым годом он будет усиливаться. Я его вижу примерно с 2017года. Реально им придавило в 2022ом...
Спрос проседает, так как рынок перестраивается. Если застали появление той-же 1С, то среди бухгалтеров был тот же самый переход. Вначале отрицание у бухгалтеров: "Ой что будет, нас всех заменит 1С". Потом принятие бухами и массовое обучение. А сейчас проблема с кадрами у нанимателей: "Блин, где найти главбуха нормального"...
Обучение - самое простое. ЛЛМки сами тебя и обучат. Не нужно искать источники, просто общайся с нейронками, проси их объяснить как и что делать для получения результата - они сами всё расскажут.
А зачем что-то вообще показывать? Опубликуй в github, через полгода - год, твоя находка попадет в датасет и нейронки, станет достоянием всего человечества :)
Про формат воспроизводимых историй: А зачем? Я вот например читаю Хабр только для идей. И то читаю в 90% случаев по диагонали. Зачастую достаточно прочитать 30% текста, что-бы понять смысл статьи и в 99% случаев понять, что это очередной мусор. Самое интересное, это когда автор ищет смысл там, где он лежит на поверхности или там, где его нет совершенно... А воспроизводимые истории мне на любую тему и нейронка нагенерит.
Yahhi Автор
24.08.2026 20:23Вот это — самый ценный коммент, спасибо. Бьёт ровно в основание, и половину приму сразу.
Да, устоявшемуся LLM научит сама, без источников. И да, выложи на GitHub — через год окажется в датасете. Тут спорить глупо.
Но вся разница — в словах «через год» и «устоявшемуся». LLM отлично учит тому, что уже осело в данных. А самое ценное сейчас — то, что кто-то нащупал на прошлой неделе с инструментом, которого полгода назад не было. Этого в датасете ещё нет, и на свежий вопрос модель уверенно сымпровизирует — то есть соврёт. Полгода-год — вечность, когда инструменты меняются каждый месяц. И я думаю, вы с ситуацией, когда модель предлагает старую версию библиотеки, а уже есть новая с совершенно другим функционалом, уже встречали и часто.
И главное — про «воспроизводимые истории мне нейронка нагенерит». Вот тут ключевое слово: нагенерит. Модель с радостью выдаст историю, которая выглядит воспроизводимой, на любую тему — правдоподобную, но не проверенную. А ценность не в тексте истории (текст она правда сделает), а в одной вещи, которую сфабриковать нельзя: что живой человек реально прогнал это в своём, другом проекте — и оно сработало. Или не сработало, и он честно написал где. «Сработало у меня» от чужого агента — это доказательство переносимости, а не красивый пересказ. Сгенерированная «воспроизводимая история» — уверенная выдумка, пока её кто-то не запустил.
Так что встречный вопрос: воспроизводимая история, которую никто не воспроизвёл, — она чего-то стоит? По-моему, нет. Поэтому текст тут не продукт; продукт — проверка.
P.S. Про «читаю по диагонали, 99% мусор» — соглашусь, и поэтому истории и не рассчитаны на чтение как статьи: их не глазами листают, их отдают своему агенту выполнить. Другой режим.
Devpiligrim
24.08.2026 20:23Приведу пример: вы водили раньше грузовик, теперь у вас самолёт, но вы пытаетесь мыслить критериями водителя грузовика.
Да фантазируют, особенно там, где они чего-то не знают. Так эксплуатируйте это. Требуйте доказать, фантазируйте вместе с ними и экспериментируйте. Сейчас тот момент - когда это дешево настолько, что даже смешно становится, почему люди этим не пользуются? Зачем учить чужое и идти по чужим следам, если у тебя есть инструмент который позволяет тебе создать свой путь? Зачем делиться со всеми мелкими шагами, ели их никто даже не заметит? Да, неплохо свои находки записывать и делиться с миром хоть с задержкой в год. Но кому это нужно сейчас?
Зачем Вам чужие библиотеки если вы за 10 минут можете создать свои? Это не призыв - это как пример...
Далее, о ценности чужого опыта, особенно в микро задачах. Вы реально считаете, что она есть? Ее не было и раньше, а уж в эпоху нейросетей, цена такого опыта меньше нуля.
Только свой опыт откладывается на подкорке. Оставьте мелочь моделям, сами думайте о глобальном.
Вам нужно взлететь на самолете, а не вести грузовик.Yahhi Автор
24.08.2026 20:23«Меньше нуля» — тут не соглашусь, и вот встречный пример: StackOverflow. Пятнадцать лет чужой опыт был так ценен, что «сходить на SO» было рефлексом каждого разработчика. И потерял он ~90% пользователей не потому, что «всегда был бесполезен», а совсем недавно — ровно тогда, когда модели научились отвечать на вопросы про фиксы, не гоняя тебя на сайт.
Но заметьте, что именно произошло. Модель не обнулила ценность чужого опыта — она впитала впитываемую часть: устоявшиеся, формализованные, многократно повторённые Q&A. Ценность не исчезла — она переехала внутрь модели. Значит вопрос не «есть ли ценность у чужого опыта» (SO доказал, что есть, и огромная), а «какую часть модель уже съела, и что осталось».
А осталось ровно то, чего у модели нет: — опыт, который ещё не скормили (свежий — прошлая неделя, новый инструмент); — опыт, которым не делятся (не захотели или просто негде было — модель впитывает только то, что где-то написали и дали проиндексировать); — опыт неформализуемый (вкус, суждение «почему так, а не иначе» — то, что в Q&A не влезает).
Так что «меньше нуля» верно ровно для впитанной части — тех микроответов, что раньше раздавал SO, а теперь раздаёт модель. Для остальных трёх ценность не упала, а выросла: лёгкое закоммодитили, а свежее, непубличное и неформализуемое стали едва ли не единственным, что чего-то стоит. Просто места, где этим обмениваются сейчас, для непереваренной части пока нет.
Devpiligrim
24.08.2026 20:23Сколько знаний вы унесли с StackOverflow, сколько усвоили? Насколько я знаю, народ просто забирал код, вставлял в свои проекты и тут-же о нём забывал. Был у меня программист (пусть будет Вася), еще до эпохи ИИ, в моей бытности тимлидом. Он очень любил StackOverflow. Однажды на проекте случилась утечка памяти, при этом достаточно хитрая, оказалось виноват код, который писал Вася.
Спрашиваю его, что делает этот кусок кода - ответ: "ну типа то-то и то-то", разбираемся и я понимаю, что Вася нифига не понимает что этот код делает, так как он взял его на StackOverflow... Вася получил звиздюлей, включил голову и начал решать проблемы сам.
Сейчас Вася очень уважаемый СТО и он на дух не переносит тех, кто хоть раз открывал StackOverflow.
Мораль в сей басне такова: мелкие решения записывать нужно, например в git, а вот пользоваться помойками типа StackOverflow - нет. Это путь к деградации.
Естественно это моё мнение и прислушиваться к нему стоит тоже очень осторожно, я не бог и могу ошибаться. Но это мой опыт и он показывает, что нужно полагаться на опыт и экспериментировать, а не ждать рабочую функцию от дяди или тёти...
Свой опыт - это то, что отложится на подкорке, а код с StackOverflow - это мусор.Yahhi Автор
24.08.2026 20:23История про Васю отличная — только она не про StackOverflow, а про копипаст без понимания. Утечку написал не SO, а Вася, который вставил код и не понял, что тот делает. Тот же Вася сегодня пастит из модели («ну типа то-то и то-то») — это ровно та же болезнь, просто источник сменился. Враг — копипаст без понимания, а не место, откуда взяли.
При этом ценность SO доказана пятнадцатью годами: «сходить на SO» было рефлексом почти каждого инженера — включая тех уважаемых CTO, которых вы имеете в виду. И я писала свои ответы на SO, также как и искала их там. Вася стал сильным не потому, что чужой опыт — мусор, а потому что научился понимать. Понимание и чужой опыт — не враги; враг у них общий: слепой копипаст.
И тут любопытно: «мелкие решения записывать в git — да, а помойками не пользоваться — нет». Но запись своих решений для переиспользования — это и есть накопление опыта, чтобы потом его достать. Через полгода вы читаете свою же заметку как чужую — вы её уже не помните. Значит граница не «своё vs чужое», а «понял и проверил vs вставил вслепую». Ровно это worklore и требует: сначала прочитать, потом прогнать Verify, с контекстом стека. Это анти-Вася, а не SO 2.0.
Devpiligrim
24.08.2026 20:23С уточнением согласен: враг - копипаст без понимания, а не место, откуда взяли.
Но мой тезис был не «SO плохой». Он про то, что подход поиска решений с использованием SO, или других сервисов где есть готовые ответы - это путь в никуда. Типовой путь: «найти готовый ответ» - SO, статьи, библиотеки, он был и есть до сих пор, но если прочтение статьи или книг давало понимание, то SO давал в основном только готовые ответы, мало кто объяснял что и зачем. Модели сделали готовые ответы бесплатными и мгновенными, но проблема не исчезла - стала незаметнее: теперь вслепую вставляют не только код, но и чужую проверку, и чужой вывод. Копипаст без понимания просто сменил носитель.
Поэтому я и говорю о смене мышления: не «найти готовое», а «вывести под свою задачу». Модель - исполнитель и черновик, а не источник истины. И запоминание чужого готового ответа никогда и не делало разработчика сильнее: никто не помнит решения с SO, это нормально. Сильнее делает способность решить, когда готового ответа нет.
Про записи в git: вы правы, что свою же заметку через полгода читаешь как чужую. Но для меня она теперь и не для человеческой памяти. Это сырьё для агента или будущей модели: они её не забудут и не вставят дословно, а переработает под новую задачу. Заметка перестала быть рецептом для себя - стала контекстом для инструмента. Вот в каком смысле «это для LLM», и вот что я имею в виду под новым подходом к разработке: не собирать готовые решения, а растить собственное мышление и кормить агента своими находками.
И раз мы согласны, что понимание ни чем не заменить - оно не передаётся и вместе с готовым верификатором. Вася, не понявший код, так же не поймёт и Verify: он вставит чужую проверку с той же слепотой. Чеклист помогает тому, кто уже знает, что проверять. А значит, расти надо не в собирании чужих историй, а в собственном мышлении.
При работе с нейронными сетями нет проторенных путей, особенно сейчас, когда технологии окружающие нейросети меняются быстрее, чем вы успеваете о них читать. Вы сами выбираете эти пути. Сами осмысливаете свои подходы.
Еще один пример. В крупной корпорации, когда начинали внедрять ИИ инструменты, делали справочники кейсов использования. Угадайте, сколько продержалась релевантность отдельных рецептов? Год? Пол года? Нет, 3 месяца. Сколько человек из 1500 сотрудников ими воспользовалось? Никто кроме инициативной группы которая их и писала.
Людям вообще эти рецепты были не нужны. Они ходили к Амбассадорам и просили показать как решать их конкретные проблемы. Почему? Потому, что им нужны были готовые ответы про которые они забудут на следующий день. Вот поэтому я и считаю, что любые готовые решения, которые разжуют и положат в рот - это зло, которое мешает развитию.Yahhi Автор
24.08.2026 20:23Сильный коммент, соглашусь с большей частью — причём резче, чем вы. Копипаст без понимания просто сменил носитель: вслепую вставляют уже и чужую проверку, и вывод — это ровно моя тревога про «правдоподобный зелёный». И да: Вася, не поняв код, не поймёт и Verify; чеклист помогает тому, кто уже знает, что проверять. Понимание не передаётся ни с готовым ответом, ни с готовым верификатором. Всё так.
Но тут вы сами ответили на своё возражение. Про git-заметку вы сказали лучшее, что можно сказать про worklore: она стала не рецептом-для-себя, а контекстом для инструмента — «агент не вставит дословно, а переработает под задачу». История — ровно это. Разница лишь в том, что вы кормите агента своими находками, а я говорю: чужую он переработает так же.
А вот «справочник рецептов умер» — не соглашусь. Не с вашим кейсом, он честный, а с выводом. Рецепты как формат живут тысячи лет и проживут ещё столько же. То, что одна корпорация не смогла сделать их удобными, — не приговор принципу, а «не делайте так, придумайте лучше». В IT полно идей, которые не зашли раз, а в других руках стали единорогом. Что делать с устареванием? То же, что с документацией, — обновлять, датировать, пере-проверять. Кстати, спасибо: вы подсветили проблему протухания, на которую я бы налетела сама только через пару месяцев. А походы к Амбассадору — это теперь работа агента: дай ему доступ к рецептам (worklore их уже отдаёт) и пусть найдёт релевантный именно тебе. Амбассадор не умирает — он становится твоим агентом поверх проверенных рецептов.
Так что согласны почти во всём: расти в своём мышлении, модель — исполнитель, а не оракул, понимание незаменимо. Спор узкий: могут ли чужие находки быть полезным контекстом для твоего вывода. Вы уже ответили «да» — для своих. Я просто не вижу, почему граница по «мои vs чужие», а не по «переработал vs вставил слепо».
Devpiligrim
24.08.2026 20:23Чужие могут содержать ошибку. Нужна как минимум проверка. В остальном согласен.
WhiteBehemoth
24.08.2026 20:23Поэтому текст тут не продукт; продукт — проверка.
Простите, но у вас "продукт" - частная "история", случившиеся в субъективном пространстве. Это нельзя экстраполировать как общий случай для всех систем, учитывая их многообразие (языки программирования, архитектуры, паттерны, используемые агенты и установленные обвязки). Например, то, что актуально для питона, может быть совсем неактуально для других яп.
Ваши воспроизводимые истории с большой степенью вероятности воспроизведутся в схожей с изначальной экосистемой. Но даже и тут нет стопроцентной гарантии. Может быть конфликт инструкций, разность в интерпретациях моделей и т.п.
Yahhi Автор
24.08.2026 20:23Соглашусь: история — частный проверенный случай, переносится лучше в схожей экосистеме, и даже там без 100% — возможно, и разные модели прочитают её инструкции чуть по-разному. Всё так.
И спасибо — вы, по сути, назвали, какие метаданные история обязана нести: язык, стек, агент, модель, дата. Чем богаче контекст, тем точнее читатель оценит близость своей экосистемы (а провал в другой — не шум, а сигнал о границе; для этого в отчёте и хранится окружение репортёра).
Но тут ключевое: вы же применяете историю к своему продукту, а не ровно к тому же, на котором она уже сработала. Точное повторение никогда и не было целью — цель в переносе. История — это отправная точка плюс проверка, а ваш агент адаптирует её под ваш стек. «Зелёный» говорит, что у кого-то перенеслось; ваш прогон — перенеслось ли у вас.
WhiteBehemoth
24.08.2026 20:23Но тут ключевое: вы же применяете историю к своему продукту
Применяя чужую историю к своему проекту, я добавляю риски false positive and false negative.
Но если чужая история таки выявит проблему в моём коде, это не значит, что применять эти чужие истории - есть практика улучшения моего продукта. Это значит, что мне нужно пересмотреть мои текущие настройки, обвязки и т.п.
Другими словами, искать зерно истины в куче чужих историй - это с моей т.з. потеря времени (и/или токенов).
yerick
24.08.2026 20:23Ответ на вопрос
Где вы учитесь новым способам работы с AI? Каналы, люди, сайты — назовите конкретику.
Как уже не раз было писано - AI нельзя встроить в существующий рабочий процесс. Надо исходить из того, что рабочий процесс надо формировать вокруг AI.
Я в своей практике пошел по пути от малого к большему. Мне так привычнее. На шару сначала попробовал сделать приложение, просто для проверки. Потом появилась цель сделать сложнее, появились вопросы по архитектуре использовании ИИ в проекте - полез читать, как сделать то или иное. То есть тренировался на кошках. Постепенно задачи ставил сложнее, и под конкретную задачу искал ответ. В принципе, как будто я только 20 лет назад решил заняться программированием, и пошел по тому же пути, что и тогда. Появляется задача - ищу решение.
Проблема в том, на мой взгляд, что если сейчас читать учебник, а потом пытаться применить эти полученные знания, то скорее всего я уже опоздаю. Потому что то, что было актуально полгода назад сегодня уже устарело. Сегодня есть MCP и оркестраторы - завтра будут другие абревиатуры. Поэтому я такой подход и выбрал. Есть задача - ищу решение на текущий момент.
Mr_Makadamia
24.08.2026 20:23Не являюсь программистом, просто мимо шёл...
Прочитав статью, увидел там ключевые нюансы: человек хочет всё и сразу, но как к этому подступиться - понятия не имеет... отсюда и вопросы о смыслах жизни...
В таких случаях разбиваю задачу на более мелкие, потом ещё на более мелкие, замедляюсь и оперирую примитивами, дабы решить её. Тут агенты могли бы пригодиться в некоторых случаях))... имхо
Yahhi Автор
24.08.2026 20:23Спасибо, но вы меня немного не так прочитали) Я не «хочу всё и сразу и не знаю, как подступиться» — методы бить задачу на примитивы у меня как раз есть, 5+ лет в профессии к этому обязывают.
Экзистенциальную часть я включила специально: хотелось не рецепта, а разговора — и да, местами даже о смысле, почему нет. Так что вы ровно в ту дверь и зашли)
А за «мимо шёл» отдельное спасибо — иногда взгляд не-программиста точнее всех.
drbond
Валентина, LLM-модели сами говорят, что программист в их понимании - это сейчас Архитектор. Именно так, с большой буквы. Но для того чтобы быть Архитектором системы/приложения нужно быть программистом, нужно иметь его знания, и, желательно - опыт. Без этого высокоуровневого приложения, даже при помощи AI, не создашь. Ну вот смотрите, вайб-кодинг доступен уже давно, а 2 февраля 2025 года Карпати ввёл этот термин в обращение. Много мы выдающихся приложений увидели с тех пор? То-то же. Оказывается, не может стая мартышек, даже вооружившись инструментами для вайб-кодинга написать эстетически и функционально законченное произведение.
Samber
Мне кажется, вы не уловили посыл автора... Вопрос не в том, кем является программист теперь, в эпоху ИИ, а в том - как программисту развиваться, что бы лучше понимать / контролировать / тестировать работу этих чёрных LLM-ящиков
drbond
Я просто начал с основ, показал, что программист в любом случае остаётся программистом. Только переходит в иное качество. А развиваться? Здесь нет стандартного рецепта. Кто-то ходит на курсы по промптингу. Кто-то слушает гуру. Кто-то сам в процессе работы набирает опыт. Пути разные. И для каждого эффективны по своему.
Samber
В таком случае, не соглашусь с Вами. Утверждение, что "для того чтобы быть Архитектором системы/приложения нужно быть программистом ... без этого высокоуровневого приложения, даже при помощи AI, не создашь." - это в текущих реалиях, не основа. Да, я могу не до конца понимать, что Вы имеете ввиду, под высокоуровневым приложением... Я, будучи веб разработчиком, с 0м знаний в разработке для андроида, сделал приложение, которое в полной мере покрывает задачи по управлению моим "умным домом". И казалось бы, я программист с многолетнем опытом, Архитектор... Однако с появлением AI я могу делать вещи, в которых совершенно не разбираюсь. Как и любой другой - не программист. Вопрос тот же - как оценить "моё" творение, понять, улучшить эффективность, найти уязвимости и слабые места. Лично меня, больше всего, зацепил вопрос автора касательно обучения - тоже хотел бы получить конкретные советы.
Oeaoo
Ну, я тоже много чего "сделал" при помощи ИИ. Но масштабируется это плохо. Уверен, вы не пробовали писать командой таких же непрофильных спецов сложный проект, скажем с годик минимум.
drbond
На самом деле не Вы делаете эти вещи, а принимаете на веру ответ модели и запускаете его в работу. Часто бывает полезно запросить модель (ту же самую) проверить безопасность кода. Она такое бывает сама за собой находит... Но работает же. Для обычного человека без специфических знаний в БД например, или сетевом стеке или даже в вёрстке сайтов этого вполне достаточно. Его потребность удовлетворена. Ладно если это локально крутится, не касается чувствительных вещей и не выносится в открытый Интернет. А вопрос поддержки? А апгрейды? А поддержка пользователей? Вот это я и имею ввиду под высокоуровневым приложением. Не будем далеко ходить - Хабр навайбкодили или руками писали? А проект его уровня Вы готовы вайбкодить и делать публичным не понимая в конечном итоге, что с ним происходит в каждый момент времени?
Для человека, который не разбирается - либо при помощи той же модели, либо при помощи приглашённых экспертов. Но в первом случае придётся принимать на веру ответ модели, в код которой Вы уже поверили. То есть опять оставаться в неведении относительно истинного положения вещей.
Samber
Ну что ж, видимо, наступает эпоха кукодинга. Ведь со временем, экспертам взяться будет неоткуда.
Скрытый текст
Yahhi Автор
Вы своим примером ответили первому оппоненту лучше меня: собрали рабочее приложение без опыта в Android — значит, «сначала стань Архитектором», чтобы что-то создать, уже не обязательно.
И сразу назвали, где теперь настоящая сложность: не построить, а оценить и укрепить своё. По-моему, этому учит не курс, а тем же способом, каким вы делали приложение — берёте конкретную чужую практику (открытый QA-скилл, чеклист уровня OWASP API) и прогоняете по своему проекту. Бьёт по тому, что вам реально не видно, — быстрее любой теории.
Спасибо, ваш коммент — половина статьи одним абзацем.
Yahhi Автор
Да, рецепта нет — и вы правы, что пути разные и каждый работает по-своему. Но если присмотреться к вашему же списку, у всех трёх путей общий пробел.
Курсы по промптингу и гуру дают абстракцию — «как надо вообще», а не «как применить к моему конкретному проекту». А опыт «в процессе работы» — самый ценный, но он приватный: остаётся в голове и в терминале одного человека и никуда не передаётся.
Мне кажется, чего не хватает — не ещё одного курса, а способа учиться на том, что другие практики реально сделали со своим агентом: конкретно, с деталями, воспроизводимо. Не «эксперт рассказал теорию», а «вот человек решил ровно мою задачу — и я могу повторить это у себя».
И тут для меня есть более широкая мысль. Появился новый тип людей — те, кто строит с агентами каждый день: не обязательно классические сеньоры, но те, кто хочет расти, придумывать, доводить до продукта. Это, по сути, новая единица на рынке, и ей тоже нужно где-то обмениваться этим новым ремеслом. Вот про это мне сейчас интереснее всего думать.
asolokha
мне кажется я уловил (
Я делаю worklore ...
Yahhi Автор
Согласна с ядром: Архитектором без инженерного бэкграунда не станешь, и вайб-кодинг сам по себе «законченное произведение» не рождает. Но я свела цифры «до и сейчас» — 2024 (ещё до вайб-кодинга, термин Карпаты ввёл только в феврале 2025) против 2026 — и они подтверждают обе половины разом.
Объём взорвался, и это измеримо: — App Store: 448K новых приложений за весь 2024 → ~560K только за первое полугодие 2026 (это уже почти как весь 2025). В годовом темпе — свыше 1 млн, рекорд, побивающий 2016-й; по iOS релизы за полгода фактически удвоились. — Google Play: ~41K новых приложений/мес в конце 2024 → ~88K/мес в 2026. Тоже примерно ×2. Причину аналитики называют прямо: Cursor / Replit / Bolt / Lovable и вайб-кодинг обрушили порог входа. Так что «стая мартышек с инструментами» — не гипотеза, она в статистике.
А теперь ваше «выдающихся не прибавилось» — тоже в цифрах: — загрузки в первой половине 2026 выросли всего на 2% при вдвое большем числе релизов. Приложений в два раза больше, а спроса — столько же. Классический supply glut. — топ-1% приложений собирает ~92% всей выручки от in-app покупок. Ценность утекает наверх, а не размазывается по потоку. — и Google Play с начала 2024-го вычистил ~1.8 млн приложений — тот самый «слоп».
Для меня вывод не «AI не работает», а ровно то, о чём статья: середину — типовые приложения — вайб-кодеры коммодитизировали, её теперь делает кто угодно; а ценность концентрируется в верхнем слое, где и нужен опытный инженер-Архитектор. Так что ваш аргумент тревогу не снимает, а уточняет: «просто кодеров» рынку нужно меньше, Архитекторов — по-прежнему нужно. Весь мой вопрос — как опытному гарантированно оказаться в этом верхнем слое, а не в вымываемой середине.
Спасибо за коммент — это ровно тот разговор, ради которого писала.