человек у руля работает в 5-10 раз производительнее среднестатистического разработчика
Среднестатистический разработчик работает с Enterprise-решениями, которые кратно больше CLI-утилиты, контекст там сложнее, код там сложнее и зачастую сама кодовая база кратно больше, соответственно и сломать что-то проще, поэтому сравнение некорректное. CLI-утилиты и 4o мог писать без проблем (и даже упаси боже GPT-3.5), если вы видите прорыв в том, что теперь вывод LLM сразу в файл идет - то я тут прорыва не вижу.
А если говорить про число пользователей, то в Yandere Simulator тоже много людей играло, но все ужаснулись, когда заглянули внутрь. Количество пользователей - не показатель, у нас и до ИИ было куча систем на коленке, которыми пользовались люди, но все эти системы держались на соплях.
Им не надо создавать хайп вокруг своей деятельности.
Конечно, им же не нужно привлекать новых пользователей продукта, они просто шлют письма радости о том, как всё вокруг прекрасно.
Напомню о том, что в ИИ вкладывается огромное количество денег, а платных юзеров - мизерное количество, которого едва ли хватит покрыть 1/10_000 от затрат на поддержку ИИ-индустрии. Им нужны новые клиенты, иначе вся система перестанет работать в конечном счете, когда инвесторы захотят увидеть заработок.
Мы слышали о том, как ИИ ускоряет скорость разработки 1000 раз от самых разных лиц, но мы почему-то до сих пор не видим массового перехода по всему миру. Бигтехи всюду кричат о том, что ИИ ускоряет и мобилизует разработку, однако, потом почему-то возвращают людей назад, ибо сокращения были слишком необоснованными и под косу пошли люди, на которых действительно держались системы, которые и без ИИ способны выполнять работу как "10x инженер"
Им важно, чтобы продукты создавались быстро, качественно и решали их задачи.
Быстро? Да, действительно быстрее. Качественнее? Сомнительно. Гляньте на последние новости, в ПО начинает появляться куча дыр, AWS/Cloudflare падает раз через раз, у Next появляется уязвимость с помощью которой можно пролезть в шелл на хост (React2Shell). У разработчиков падает насмотренность и пропадает навык написания и понимания кода, многие из-за дедлайнов не проверяют код за нейронкой и на прод выкатывается черт пойми что. Если вы это называете качеством - то у нас с вами разное мировоззрение.
Да и к тому же, есть первые наблюдения (важно, что это наблюдение, а не целое исследование, ибо оно реализовано на достаточно малой выборке), исходя из которых разработчики с ИИ становятся медленнее (тык), потому что код:
Сложнее проверять, нежели писать
Сложнее фиксить, нежели написать нормально с чистого листа
Я искренне радуюсь за всех PM, которые теперь могут KPI по задачам закрыть, но мне не сильно интересно что у них там за KPI, у меня есть работа и я хочу делать её хорошо. Я использую LLM, но точечно, когда это оправдано, а не забиваю кувалдой гвозди.
Это просто следующий шаг той же эволюции
Если вы 20 лет в IT, то вы должно быть так же радовались Low-Code, No-Code решениям, конструкторам и прочей чепухе. Повторюсь: для того чтобы инженеры поддерживали продукт, они должны знать как он работает, а не слепо верить выводу LLM. Эволюция в технических отраслях предполагает детерминированный результат, а не "запущу 3 git worktree и выберу вариант от Claude, который выглядит менее болезненно"
Промпт — это способ взаимодействия. Инженерия — это понимание что строить, зачем и как. Одно другому не противоречит.
Инженерия это также способность понять что уже построено и анализировать текущую систему. Приходя к столь желаемому подходу "от реализации к архитектуре" вы упускаете одну очень важную деталь - знание того как работает построенная система начинает пропадать, просто потому что при увеличении скорости написания кода - вы не можете столь же эффективно анализировать происходящее.
---
Ну и на всякий повторюсь: LLM - прекрасная технология, которая может помочь в разработке, но даже её нужно использовать аккуратно. Инженер, который не знает как работает его собственная система и имеет только общее представление, исходя из промптов что он вводил - не является инженером.
Вайб-код - прекрасное решение для пет-проектов, но для продуктовых систем - слишком рискованное и опасное
Ну, использовал и использовал. Человеку 56 лет, он в свое удовольствие пишет себе эффекты для педальки. Код на C он сам написал (опять же в свое удовольствие), а на Python там один класс "навайбкожен", он то же самое и в обычном чате мог сделать у DeepSeek/ChatGPT, но все начали бухтеть так, будто он Claude Code открыл и ядро начал переписывать.
Вроде бы уже 300 раз все обговаривали, что для скриптов и всяких мелочей ИИ или агенты не являются чем-то плохим, плохо когда с помощью них слоп делают, пихают в продакшен и продают как продукт или вообще себя Full Cycle Engineer считают
26 декабря 2025 года Андрей Карпатый — сооснователь OpenAI, экс-директор AI в Tesla, автор термина "vibe coding" — написал в Twitter:
"I've never felt this much behind as a programmer"
На следующий день ответил Борис Черный — создатель Claude Code, Principal Engineer:
"In the last thirty days, I landed 259 PRs. Every single line was written by Claude Code. The last month was my first month as an engineer that I didn't open an IDE at all."
Создатель одного из самых успешных AI-инструментов в истории — перестал открывать IDE и писал код самостоятельно.
Оба твита набрали 20 миллионов просмотров и активно обсуждались в сообществах.
И вот что еще интересно:
«Newer coworkers and even new grads that don't make all sorts of assumptions about what the model can and can't do — are able to use the model most effectively.»
Ну, Claude Code - это обычная CLI утилита, которая API дергает, нет там такого кода, который был бы невероятно сложен, от того даже бездушная LLM может с ним спокойно справиться)
А в остальном, это ж чисто продуктовые твиты, которые нацелены на маркетинг, ибо оба человека работают в среде ИИ и им невыгодно, чтобы эта тема умерла :)
Можете кидать камнями, но не вижу я ничего кайфого в том, чтобы просто работать PM для LLM и отходить от всего технического, тем самым не расширяя свои знания и кругозор. А про то что TODO-листы надо составлять для LLM и стараться по спеке работать - так это и до LLM было)
---
P.S. А вообще, если честно, наскучила вся эта тема с ИИ. Не узнал ничего нового из статьи. Было б даже интересней следить за тем, как бы вы без LLM за 300 дней выучили технологии, да сделали бы пару проектов, сейчас уже наверное каждая вторая статья на хабре - повторение документации Claude Code и AGENTS.md без каких-либо интересных моментов
P.S.S. Ну и термин "Full Cycle Engineer" вы конечно интересно подобрали. Можно было бы гордиться, если бы вы это всё без LLM могли, а так можно себя называть "Full Cycle Prompter", от инженерии тут мало что есть
но по итогу мы придем именно к AI-driven development
Я вас могу уверить, что чисто к AI-driven мы не придем. Возможно, на каких-то малобюджетных проектах или галерах это и хорошая идея, однако, для Enterprise-систем или больших компаний, использовать ИИ для написания всего кода - крайней плохая идея.
Когда в вашей команде нет никакой осведомленности о кодовой базе, все решения принимаются с помощью "fix it now", а архитектурой даже и не пахнет - дело запахнет жареным очень быстро.
Практически все LLM-энтузиасты твердят о "бухгалтеры с компьютером заменили бухгалтеров со счетами", "ИИ придет на смену программистам уже через пару лет, как машины пришли на смену коням", однако, все они забывают одно - когда пришли "новые" бухгалтеры они знали профессию точно так же, как и предыдущие со всеми её поднаготными, когда пришли машины, то первыми водителями были конюхи, а не люди с улицы.
В данном случае дела обстоят точно так же, вне зависимости от того использует ли разработчик ИИ - он остается разработчиком, тогда как AI-driven-промптер всего лишь является копирайтером с расширенным словарным запасом. От того и программные продукты у первых и вторых выходят на совершенно разном уровне.
Сама идея того, что мы придем к полной сингулярности, где разработка будет происходить без вмешательства человека - достаточно утопична, хотя бы потому что текущие LLM это и не ИИ вовсе
За этими технологиями будущее, которое уже наступило
Я пользуюсь ИИ, можно даже сказать что активно, но никакого будущего кроме кучи проблем с поддерживанием кода из-за коллег, которые используют LLM как панацею и несмотрят на качество кода пока что не вижу
не слушайте Критиков-консерваторов
То есть людей, которые имеют опыт в разработке и говорят о минусах вайб-кодинга мы теперь в котел кидаем?
Прочитал вашу статью, однако, так и не понял чем ваша автоматическая генерация id удобнее стандартного прописывания testid.
По сути (если не смотреть в сторону $mol), вы же просто используете кастомный JSX-трансформер, чтобы навесить id исходя из имён компонентов и их иерархии на вообще все элементы. Такой подход ведёт к тому, что QA, которые будут писать тесты, всегда должны использовать генерацию тестов с помощью "прокликивания" элементов, ну или смотреть на дерево компонент чтобы "по частям" собрать селектор. С точки зрения DX, такой подход - не самый удобный.
С одной стороны, нам не приходится ручками прописывать ID, а с другой, потенциально, такой подход ведёт к огромному названию селектора, перегруженности DOM-дерева ID-шниками и невозможности зарефакторить то же название компонента без просьбы переписать тест
Хэши удобно применять, когда приложение находится в том же пространстве, что и тесты (в одном репозитории), а также само приложение запускается в режиме разработки. Такие прогоны обычно полезны, когда разработчики сливают свои фичи и проверяют не задели ли они ничего лишнего. Сам подход избавляет нас от, порой, излишнего усложнения названия селекторов и предоставляет лаконичный подход для тестирования DEV-сборки, но для PROD-сборки, он не поможет.
Если тестировать прод-версию, то да, удаление там никак не поможет. В таком случае testid оставляют, однако, в моей практике иногда делили окружения не только на DEV и PROD, но и на PRE_PROD или STAGE (кому как удобно называть). Последние идентификаторы окружения отличались от PROD только тем, что в них как раз и были данные селекторы. Да, придется немножко заморочиться, для того чтобы заставить те же бандлеры выдавать прод-код не только с условным NODE_ENV="production", однако, уверяю, там не так сложно и временные затраты себя окупят.
Касательно предложений:
Подход который вы описали очень похож на подход во втором пункте, с различием лишь в том, что мы добавляем именное пространство (у вас это some-page:). Я не берусь судить насколько такой подход хороший или плохой, но точно знаю несколько ситуаций, где он пригождался. Подходы к рандомизации/именованию отличаются от случая к случаю, порой такие именные пространства являются оверинжинирингом, а порой вписываются идеально. К слову, айдишнику из списка я бы не сильно доверял, так как если на странице есть два одинаковых списка, то их ID могут полностью совпасть.
Во втором пункте, насколько я понял, вы продолжаете идею с именными пространствами, но как уже ранее говорил, порой они вписываются идеально, а порой являются усложнением
Ну, это же по сути ограничение API, а не самого протокола. Протокол может передавать любые данные (даже текст). Какие медиа-устройства учавствуют в разговоре регулирует API браузера/клиента. На каком браузере пробовали реализовать разговор через верхний динамик?
Среднестатистический разработчик работает с Enterprise-решениями, которые кратно больше CLI-утилиты, контекст там сложнее, код там сложнее и зачастую сама кодовая база кратно больше, соответственно и сломать что-то проще, поэтому сравнение некорректное. CLI-утилиты и 4o мог писать без проблем (и даже упаси боже GPT-3.5), если вы видите прорыв в том, что теперь вывод LLM сразу в файл идет - то я тут прорыва не вижу.
А если говорить про число пользователей, то в Yandere Simulator тоже много людей играло, но все ужаснулись, когда заглянули внутрь. Количество пользователей - не показатель, у нас и до ИИ было куча систем на коленке, которыми пользовались люди, но все эти системы держались на соплях.
Конечно, им же не нужно привлекать новых пользователей продукта, они просто шлют письма радости о том, как всё вокруг прекрасно.
Напомню о том, что в ИИ вкладывается огромное количество денег, а платных юзеров - мизерное количество, которого едва ли хватит покрыть 1/10_000 от затрат на поддержку ИИ-индустрии. Им нужны новые клиенты, иначе вся система перестанет работать в конечном счете, когда инвесторы захотят увидеть заработок.
Мы слышали о том, как ИИ ускоряет скорость разработки 1000 раз от самых разных лиц, но мы почему-то до сих пор не видим массового перехода по всему миру. Бигтехи всюду кричат о том, что ИИ ускоряет и мобилизует разработку, однако, потом почему-то возвращают людей назад, ибо сокращения были слишком необоснованными и под косу пошли люди, на которых действительно держались системы, которые и без ИИ способны выполнять работу как "10x инженер"
Быстро? Да, действительно быстрее. Качественнее? Сомнительно. Гляньте на последние новости, в ПО начинает появляться куча дыр, AWS/Cloudflare падает раз через раз, у Next появляется уязвимость с помощью которой можно пролезть в шелл на хост (React2Shell). У разработчиков падает насмотренность и пропадает навык написания и понимания кода, многие из-за дедлайнов не проверяют код за нейронкой и на прод выкатывается черт пойми что. Если вы это называете качеством - то у нас с вами разное мировоззрение.
Да и к тому же, есть первые наблюдения (важно, что это наблюдение, а не целое исследование, ибо оно реализовано на достаточно малой выборке), исходя из которых разработчики с ИИ становятся медленнее (тык), потому что код:
Сложнее проверять, нежели писать
Сложнее фиксить, нежели написать нормально с чистого листа
Я искренне радуюсь за всех PM, которые теперь могут KPI по задачам закрыть, но мне не сильно интересно что у них там за KPI, у меня есть работа и я хочу делать её хорошо. Я использую LLM, но точечно, когда это оправдано, а не забиваю кувалдой гвозди.
Если вы 20 лет в IT, то вы должно быть так же радовались Low-Code, No-Code решениям, конструкторам и прочей чепухе. Повторюсь: для того чтобы инженеры поддерживали продукт, они должны знать как он работает, а не слепо верить выводу LLM. Эволюция в технических отраслях предполагает детерминированный результат, а не "запущу 3 git worktree и выберу вариант от Claude, который выглядит менее болезненно"
Инженерия это также способность понять что уже построено и анализировать текущую систему. Приходя к столь желаемому подходу "от реализации к архитектуре" вы упускаете одну очень важную деталь - знание того как работает построенная система начинает пропадать, просто потому что при увеличении скорости написания кода - вы не можете столь же эффективно анализировать происходящее.
---
Ну и на всякий повторюсь: LLM - прекрасная технология, которая может помочь в разработке, но даже её нужно использовать аккуратно. Инженер, который не знает как работает его собственная система и имеет только общее представление, исходя из промптов что он вводил - не является инженером.
Вайб-код - прекрасное решение для пет-проектов, но для продуктовых систем - слишком рискованное и опасное
Ну, использовал и использовал. Человеку 56 лет, он в свое удовольствие пишет себе эффекты для педальки. Код на C он сам написал (опять же в свое удовольствие), а на Python там один класс "навайбкожен", он то же самое и в обычном чате мог сделать у DeepSeek/ChatGPT, но все начали бухтеть так, будто он Claude Code открыл и ядро начал переписывать.
Вроде бы уже 300 раз все обговаривали, что для скриптов и всяких мелочей ИИ или агенты не являются чем-то плохим, плохо когда с помощью них слоп делают, пихают в продакшен и продают как продукт или вообще себя Full Cycle Engineer считают
Ну, Claude Code - это обычная CLI утилита, которая API дергает, нет там такого кода, который был бы невероятно сложен, от того даже бездушная LLM может с ним спокойно справиться)
А в остальном, это ж чисто продуктовые твиты, которые нацелены на маркетинг, ибо оба человека работают в среде ИИ и им невыгодно, чтобы эта тема умерла :)
Можете кидать камнями, но не вижу я ничего кайфого в том, чтобы просто работать PM для LLM и отходить от всего технического, тем самым не расширяя свои знания и кругозор. А про то что TODO-листы надо составлять для LLM и стараться по спеке работать - так это и до LLM было)
---
P.S. А вообще, если честно, наскучила вся эта тема с ИИ. Не узнал ничего нового из статьи. Было б даже интересней следить за тем, как бы вы без LLM за 300 дней выучили технологии, да сделали бы пару проектов, сейчас уже наверное каждая вторая статья на хабре - повторение документации Claude Code и AGENTS.md без каких-либо интересных моментов
P.S.S. Ну и термин "Full Cycle Engineer" вы конечно интересно подобрали. Можно было бы гордиться, если бы вы это всё без LLM могли, а так можно себя называть "Full Cycle Prompter", от инженерии тут мало что есть
Следующий вечер:
Сэр, нам отключили Claude, всё пропало
Я вас могу уверить, что чисто к AI-driven мы не придем. Возможно, на каких-то малобюджетных проектах или галерах это и хорошая идея, однако, для Enterprise-систем или больших компаний, использовать ИИ для написания всего кода - крайней плохая идея.
Когда в вашей команде нет никакой осведомленности о кодовой базе, все решения принимаются с помощью "fix it now", а архитектурой даже и не пахнет - дело запахнет жареным очень быстро.
Практически все LLM-энтузиасты твердят о "бухгалтеры с компьютером заменили бухгалтеров со счетами", "ИИ придет на смену программистам уже через пару лет, как машины пришли на смену коням", однако, все они забывают одно - когда пришли "новые" бухгалтеры они знали профессию точно так же, как и предыдущие со всеми её поднаготными, когда пришли машины, то первыми водителями были конюхи, а не люди с улицы.
В данном случае дела обстоят точно так же, вне зависимости от того использует ли разработчик ИИ - он остается разработчиком, тогда как AI-driven-промптер всего лишь является копирайтером с расширенным словарным запасом. От того и программные продукты у первых и вторых выходят на совершенно разном уровне.
Сама идея того, что мы придем к полной сингулярности, где разработка будет происходить без вмешательства человека - достаточно утопична, хотя бы потому что текущие LLM это и не ИИ вовсе
Я пользуюсь ИИ, можно даже сказать что активно, но никакого будущего кроме кучи проблем с поддерживанием кода из-за коллег, которые используют LLM как панацею и несмотрят на качество кода пока что не вижу
То есть людей, которые имеют опыт в разработке и говорят о минусах вайб-кодинга мы теперь в котел кидаем?
Прочитал вашу статью, однако, так и не понял чем ваша автоматическая генерация
idудобнее стандартного прописыванияtestid.По сути (если не смотреть в сторону $mol), вы же просто используете кастомный JSX-трансформер, чтобы навесить
idисходя из имён компонентов и их иерархии на вообще все элементы. Такой подход ведёт к тому, что QA, которые будут писать тесты, всегда должны использовать генерацию тестов с помощью "прокликивания" элементов, ну или смотреть на дерево компонент чтобы "по частям" собрать селектор. С точки зрения DX, такой подход - не самый удобный.С одной стороны, нам не приходится ручками прописывать ID, а с другой, потенциально, такой подход ведёт к огромному названию селектора, перегруженности DOM-дерева ID-шниками и невозможности зарефакторить то же название компонента без просьбы переписать тест
Рад что вам понравилась статья!
Касательно вопросов:
Хэши удобно применять, когда приложение находится в том же пространстве, что и тесты (в одном репозитории), а также само приложение запускается в режиме разработки. Такие прогоны обычно полезны, когда разработчики сливают свои фичи и проверяют не задели ли они ничего лишнего. Сам подход избавляет нас от, порой, излишнего усложнения названия селекторов и предоставляет лаконичный подход для тестирования DEV-сборки, но для PROD-сборки, он не поможет.
Если тестировать прод-версию, то да, удаление там никак не поможет. В таком случае
testidоставляют, однако, в моей практике иногда делили окружения не только на DEV и PROD, но и на PRE_PROD или STAGE (кому как удобно называть). Последние идентификаторы окружения отличались от PROD только тем, что в них как раз и были данные селекторы.Да, придется немножко заморочиться, для того чтобы заставить те же бандлеры выдавать прод-код не только с условным NODE_ENV="production", однако, уверяю, там не так сложно и временные затраты себя окупят.
Касательно предложений:
Подход который вы описали очень похож на подход во втором пункте, с различием лишь в том, что мы добавляем именное пространство (у вас это
some-page:). Я не берусь судить насколько такой подход хороший или плохой, но точно знаю несколько ситуаций, где он пригождался. Подходы к рандомизации/именованию отличаются от случая к случаю, порой такие именные пространства являются оверинжинирингом, а порой вписываются идеально.К слову, айдишнику из списка я бы не сильно доверял, так как если на странице есть два одинаковых списка, то их ID могут полностью совпасть.
Во втором пункте, насколько я понял, вы продолжаете идею с именными пространствами, но как уже ранее говорил, порой они вписываются идеально, а порой являются усложнением
Ну, это же по сути ограничение API, а не самого протокола. Протокол может передавать любые данные (даже текст). Какие медиа-устройства учавствуют в разговоре регулирует API браузера/клиента. На каком браузере пробовали реализовать разговор через верхний динамик?
Тут я вам вряд ли подскажу, так как не сильно знаком с Web3
Да, полностью, это общеизвестные сервера
Да, можно