В копилку к предсказуемости добавил бы ещё слаженность. Команда это больше чем N специалистов каждый сам по себе. Это сработавшиеся люди, которые договорились о стиле, о качестве кода, об архитектуре, о дизайне, о трейдоффах. У них есть роли и свой пайплайн доставки целости. Команда целиком даёт определенный выхлоп, и одна лишь прокачка функции написания кода в ней не даст аналогичный буст производительности всей команды.
P.S. Солидарен с автором по вариантам использования LLM. Истерии не подвержен, но при этом использую почти ежедневно. Ну и аккуратно наращиваю насмотренность в команде по теме: и на хороших, и на плохих примерах, чтобы мнение было комплексное, без розовых очков.
Всё исследование строилось вокруг конкретного сценария — нагрузки высоконагруженного сервиса Messenger с очень большой MongoDB-инсталляцией, разнородными по размеру сообщениями и понятной key-value моделью с явными partition key и clustering key
Абзац читается как "на самом деле мы искали подходящую базу под мессенджер и победила Кассандра", что заметно сужает задачу и снижает ценность доводов. Это ведь дефолтная, проверенная временем go to база для мессенджеров, ничего удивительного.
Состав чатов (chat_members): таблица, которая хранит пары GUID пользователя — chat_id
На этом моменте промелькнула мысль: среди чатов есть заведомо один на один, такие как между водителем и пассажиром, не рассматривали ли вынести их в отдельную таблицу, где сразу хранятся два ID участников?
В целом согласен, но на моменте с созданием треда немного скепсис появился. Мб просто хорошего опыта с многопоточностью (в классическом понимании) в Python не было, всегда ощущалось как костыль.
Спасибо, тема раскрыта с интересного угла. В конце немного не хватило про МикроВМ, например про тот же FireCracker хотя бы в двух словах как про наиболее яркого представителя.
Это все ещё вариант по-умолчанию для кэша, практически стал именем нарицательным, как Kafka. Плюс есть тонны обучающего материала и примеров, где в контейнерах поднимается именно Redis. Уход от него если и случится, то будет очень инертным.
Насколько я помню, в оригинальном сообщении призыв так писать продакшн-системы отсутствует, ровно как и призыв не писать. Поэтому, наверное, валидно сказать, что не призывал.
Указанная статья уже несвежая, поэтому вынесу обсуждение сюда:
вайбкодинг это такой новомодный стиль разработки ПО, при котором исходный код генерируется компьютером путем составления запросов на человеческом языке.
Это очень большое искажение относительно первоначального поста! Честно признаюсь, что копирую ответ нейронки чисто для экономии времени на печать, но со смыслом полностью согласен:
Вайбкодинг (vibe coding) — термин, введённый Андреем Карпатым (экс-лидером автопилота Tesla, сооснователем OpenAI) в феврале 2025 года.
В первоначальном смысле Карпатого это не просто «помощь нейросети в написании кода», а специфический, почти медитативный стиль разработки:
Полное принятие генераций ИИ. Разработчик не читает код, не анализирует его и не пытается понять, что именно написал ИИ. Он просто видит, что результат (внешне) работает, и принимает это.
Отказ от рефакторинга и исправлений. Если что-то ломается — ты не ищешь баг в коде, а скармливаешь ошибку обратно нейросети и просишь исправить. При этом сам код остаётся «чёрным ящиком».
Снятие контроля. Карпатый сравнивал это с «утратой чувства собственного авторства» — ты перестаёшь быть инженером, который управляет каждой строкой, и становишься «дирижёром», который только даёт команды и смотрит, заводится ли результат.
Использование голосового ввода. Ключевая деталь оригинального описания: ты говоришь вслух, что нужно сделать (например, «сделай кнопку красной и добавь анимацию»), ИИ пишет код, ты его запускаешь — и если работает, двигаешься дальше. Без IDE, без дебаггера, без мыслей о структуре.
Доверие на грани «магии». Карпатый подчёркивал, что в таком режиме ты просто «чувствуешь вайб» (настроение, поток), а не контролируешь детали. Отсюда и название.
Важно: Карпатый говорил об этом как об экстремальном эксперименте и способе быстро прототипировать, когда качество и поддерживаемость кода не важны. Он не призывал так писать продакшн-системы. В первоначальном смысле вайбкодинг — это осознанный отказ от инженерной дисциплины в пользу скорости и ощущения потока.
Позже термин стали использовать шире (для любой генерации кода нейросетями), но оригинальное определение Карпатого именно такое: «отпустить контроль и просто наслаждаться процессом, даже не глядя на код».
Возникает вопрос: заказчик, который явно просит делать его проект посредством вайбкодинга, точно понимает что просит?
квартира 60 м² в центре стоит примерно 13.9 млн рублей
В центре чего? Некого абстрактного города в России? У нас по ценам на недвижку четкое разделение между Москвой и всем остальным, а среднее по больнице ни там, ни там не является хорошей прикидкой.
В статье приведено много замечательных снимков (или это сканы?) карт, которые ранее многим наверняка встречались в печатном виде. Что было исходником этих карт? Т.е. является ли эта картинка с разметкой "рендером" или проекцией бо'льшего объема информации или именно в таком виде карты и существовали, в виде изображения? Вряд ли секрет, что сейчас карты в цифровом виде существуют, а когда-то строго в виде каракуль на бумаге. Так вот, во время СССР как было? Использовали ли ЭВМ для их хранения и обработки, был ли цифровой вид?
Ниже приведу цитату, при чтении которой возникла мысль - как будто зря не назвали 2ГИС и Карты Яндекса, которые не менее успешные продукты.
Сегодня крупнейшие корпорации также собирают цифровые данные о городах. Google сканирует улицы, Apple строит 3D-карты, Microsoft анализирует спутниковые снимки, а OpenStreetMap обновляется миллионами пользователей
В копилку к предсказуемости добавил бы ещё слаженность. Команда это больше чем N специалистов каждый сам по себе. Это сработавшиеся люди, которые договорились о стиле, о качестве кода, об архитектуре, о дизайне, о трейдоффах. У них есть роли и свой пайплайн доставки целости. Команда целиком даёт определенный выхлоп, и одна лишь прокачка функции написания кода в ней не даст аналогичный буст производительности всей команды.
P.S. Солидарен с автором по вариантам использования LLM. Истерии не подвержен, но при этом использую почти ежедневно. Ну и аккуратно наращиваю насмотренность в команде по теме: и на хороших, и на плохих примерах, чтобы мнение было комплексное, без розовых очков.
Абзац читается как "на самом деле мы искали подходящую базу под мессенджер и победила Кассандра", что заметно сужает задачу и снижает ценность доводов. Это ведь дефолтная, проверенная временем go to база для мессенджеров, ничего удивительного.
На этом моменте промелькнула мысль: среди чатов есть заведомо один на один, такие как между водителем и пассажиром, не рассматривали ли вынести их в отдельную таблицу, где сразу хранятся два ID участников?
BTW, с почином! Первая статья и первый комментарий на Хабре :)
В целом согласен, но на моменте с созданием треда немного скепсис появился. Мб просто хорошего опыта с многопоточностью (в классическом понимании) в Python не было, всегда ощущалось как костыль.
Отвлечённый вопрос: не болит ли от использования Python в такой критически важной части Облака?
Но Вы и
Обычному человеку с дефолтной выносливостью таки не хватит этого времени.
Здорово, конечно, но над слогом явно стоит поработать... Более формальной статьи на Хабре не припомню.
Хорошая систематизирующая статья, полезно 👍
Спасибо, тема раскрыта с интересного угла. В конце немного не хватило про МикроВМ, например про тот же FireCracker хотя бы в двух словах как про наиболее яркого представителя.
Это все ещё вариант по-умолчанию для кэша, практически стал именем нарицательным, как Kafka. Плюс есть тонны обучающего материала и примеров, где в контейнерах поднимается именно Redis. Уход от него если и случится, то будет очень инертным.
Это просто несерьёзно - в 26 году платные кодеки, как 20 лет назад?
P.S. Недавно посмотрел занимательное видео по теме, в очередной раз поблагодарил Фабриса Беллара за ffmpeg.
Насколько я помню, в оригинальном сообщении призыв так писать продакшн-системы отсутствует, ровно как и призыв не писать. Поэтому, наверное, валидно сказать, что не призывал.
Хайп раздувают, не иначе.
Указанная статья уже несвежая, поэтому вынесу обсуждение сюда:
Это очень большое искажение относительно первоначального поста! Честно признаюсь, что копирую ответ нейронки чисто для экономии времени на печать, но со смыслом полностью согласен:
Возникает вопрос: заказчик, который явно просит делать его проект посредством вайбкодинга, точно понимает что просит?
При чтении были ассоциации с лором Dark Souls, это добавило статье шарма)
В центре чего? Некого абстрактного города в России? У нас по ценам на недвижку четкое разделение между Москвой и всем остальным, а среднее по больнице ни там, ни там не является хорошей прикидкой.
Спасибо, прочитал, и теперь абсолютно уверенно могу сказать - я не знаю C++ 😅
Два вопроса:
В статье приведено много замечательных снимков (или это сканы?) карт, которые ранее многим наверняка встречались в печатном виде. Что было исходником этих карт? Т.е. является ли эта картинка с разметкой "рендером" или проекцией бо'льшего объема информации или именно в таком виде карты и существовали, в виде изображения? Вряд ли секрет, что сейчас карты в цифровом виде существуют, а когда-то строго в виде каракуль на бумаге. Так вот, во время СССР как было? Использовали ли ЭВМ для их хранения и обработки, был ли цифровой вид?
Ниже приведу цитату, при чтении которой возникла мысль - как будто зря не назвали 2ГИС и Карты Яндекса, которые не менее успешные продукты.
Хм, вроде уже была похожая статья за вашим авторством...