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 браузера/клиента. На каком браузере пробовали реализовать разговор через верхний динамик?
Ну, 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
Да, полностью, это общеизвестные сервера
Да, можно