В стадии evals нет никакой магии, гуглить тут особо нечего. Это просто этап, где мы запускаем разнородные механизмы проверки и реализуем сценарии тестирования. Они делятся на два подмножества:
детерминированные (линтеры, типы, санитайзеры, срезы перформанса и т.п.) — измеримы, область применимости известна и вычислима
недетерминированные на базе LLM (judge-системы, агентская кросс-валидация и т.д.) — измерения возможны, но метрики шумные и границы применимости заранее неизвестны
В каждом проекте свой набор практик, но ключевое препятствие на пути к доверию как раз в недетерминированных гейтах. Дело в том, что мы не можем напрямую посчитать границы компетентности модели. Измерить можем, но только как эмпирическую частоту на своей выборке — условно, coverage по компетенциям не посчитать. Из того, что вчера задача из той же области решилась полностью автоматически, не следует, что сегодня задача X решится.
Помимо этого, ошибки судьи коррелируют с ошибками источника. Чтобы их избежать, можно взять разные модели для судейских агентов, но корреляцию они уберут не полностью. Модели обучаются примерно на тех же корпусах, по схожим методикам, поэтому в спорном месте спеки с высокой вероятностью выберут ту же развилку, и тогда проверка подтвердит корректное решение не той задачи. Многослойная проверка работает только при независимости слоёв, а здесь её нет.
Отсюда и вопрос, а может ли с принципиальной точки зрения LLM выступать наблюдателем на стадии верификации или нет, и если нет, то какими механизмами можем преодолеть это при помощи детерминированных проверок в CI. У меня нет ответа, да и ни у кого, пока проблема решается на человеческой тяге там, где ошибка чревата хоть какими-то последствиями, кроме перезалива PR.
Лорен не поставила эту проблематику и не привела пример метрик и механизмов, которые помогут быть уверенным в результате. Диагностика компилятора и прогон линтеров — это, конечно, хорошо, но они закрывают конкретный класс ошибок и ничего не говорят о соответствии спецификации. Агентское судейство на этапе верификации — рабочая практика, не спорю, но доказательства надёжности носят эмпирический характер и их надо предъявлять.
Например, можно было рассказать пару слов про мутационное тестирование: намеренно вносим в код дефекты и смотрим, сколько из них ловят тесты, написанные агентами. Доля пойманных (kill rate) как раз показывает, чего эти тесты стоят. Маленькая деталь, а даст неподготовленному читателю больше, чем весь спич.
По цифрам: и в заголовке, и в статье упоминаются 800 PR — в них нет смысла без контр-показателей. Предметный разговор случится, когда покажут долю PR, вернувшихся на доработку к человеку, процент откатов и хотфиксов, долю ошибок, доехавших до прода, и стоимость токенов на принятый PR. Тезис «руками не пишут, не ревьюят и не тестируют» вообще противоречит статье.
AI-native разработка — интересная и классная штука, чужой опыт полезен. Однако у всего есть цена, и она никак не отражена в статье. Восторженный доклад энтузиаста — это нормально, но нужно подтверждать громкие заявления цифрами. Если у Лорен всё так классно работает, как она пишет, то ей впору не PR мерджить, а патентовать пайплайн, потому что проблема сейчас на фронтире исследований и возможность практически выкинуть человека из цикла — как золото Эльдорадо, но пока в руках только лопаты :)
Так, а где контроль то, что LLM сделала все правильно? Нет примера из разряда — вот у нас есть задача по которой есть спека, наш агент её выполнил так-то и так-то, затем рой агентов + некие утилиты доказали, что решение соответствует спеке. В этой точке в статье должно появиться описание инструментов и то как они гарантируют проверку логики. Некий способ доказать изоморфность постановки задачи к её решению. Метрики, цифры и так далее, описание дрифта с целевым решением на разных конфигурациях инструментов и LLM моделей. Без всего этого тезисы голословные и ничем не подкреплены.
Я тоже могу включить в yolo моде агента, заставить его писать код и настроить проверки в CI. Не бог весть какая задача, Claude такое за пару вечеров сварганит вот только доверия к этому подходу ровно столько насколько я уверен в промптах, инструкциях и возможностях модели.
Автоматизация в том, что у коллег уже ai-native разработка и код руками они не пишут, не ревювят, и не тестируют, и результат - 800 PR как раз в том, что все скиллы и инструменты уже настроены.
Количество не аргумент, можно и большие цифры выдавать хоть со скилами хоть без. Особенно при неограниченных ресурсах. Если код никто не ревьюит, и не тестирует, то как же так выходит, что мы думаем, что он соответствует логике? То, что принято сейчас называть автоматизацией не то, чтобы действительной ей является. Решение все равно создаю я. Описываю спецификацию, проектирую архитектуру и придумываю процессы. Написание кода агентом это финальная часть решения, которая не является боттлнеком сама по себе. Это ускорение клавиатуры. Нужна метрика подтверждающая, что описание достаточно точной задачи, которую агент сможет реализовать без уточнений будет эффективнее, чем написание самому с нуля иначе автоматизация иллюзорна.
Тейк про то, что скилы написаны и инструменты настроены я не принимаю. По Станиславскому «Не верю!». Пока продукт является конструктором из готовых компонент такой подход ещё с пивом покатит, однако достаточно сменить язык проекта, домен или вкорячить новую фичу на базе технологий под которую нет скилов и начинается новая итерация prompt engineering. Да и под каждую фичу все равно надо описать задачу. При этом если домен сложный, то без профильных знаний никуда, например разработка ОС или работа с медицинским оборудованием.
сотрудник в Курсоре вовлекается на уровне evals и governance
В статье этого нет, а стадии довольно интересные.
Лорен все рассказала по тезису - основная проблема в доверии и как они ее решают
Для Лорен сам факт наличия инструментов намеренных повысить качество кода повышает уровень доверия. Оно и понятно, степень ошибки в домене в котором она работает не столь высока. Насколько я могу догадываться речь идет ещё и о фронтенде за счет чего мы получаем быструю петлю обратной связи потому что можем увидеть проблему глазами.
Спасибо за перевод. Тема довольно интересная жаль только, что сам вопрос доверия — то ради чего статья существует вообще не раскрыт.
Риторика Лорен полна подменой понятий, противоречий и не подкрепленных утверждений поэтому не могу просто пройти мимо. Сюжетная канва вообще очень странно устроена. С одной стороны выдвигается тезис, что основная проблема в доверии, но в то же время на протяжении всего спича проблемой является отсутствие у агентов умения решать конкретные задачи без участия человека.
Дальше тезисно
Когда вы не доверяете агенту, вы вынуждены постоянно вовлекаться в процесс и проверять каждое действие. Это сильно ограничивает вашу продуктивность, вы не можете распараллелить работу и запустить сразу много агентов, потому что не верите ни одному из них.
Можем, просто результат придется проверять в конце. Мне не нравится, что количество строк кода и набор закрытых PR выдается за валидную метрику продуктивности. В каком году мы живем? Не думал, что мемы про индусский код и разработку через количество станут новой веткой реальности.
Лорен показала кривую, на которой по вертикали отложен уровень доверия, а по горизонтали — время
А рядом на заборе нарисовала граффити. Что доказывает кривая? В каких единицах измерения доверие отмечено? Корреляция с количеством агентов и доверием кем измерена?
Верификация означает способность агента самостоятельно запускать код, снимать CPU‑трассировки, открывать симулятор iOS или иным способом проверять свою работу в реальной среде
Верификация означает не это. Она означает, что у нас есть механизмы проверки кода на соответствие спецификации. Написанной людьми между прочим. Это могут быть как статические инструменты, так и человек в виде принимающего лица. Здесь проводится попытка провернуть слушателя на половом органе поскольку с одной стороны мы хотим доверять LLM через средства проверки и в то же время считаем, что LLM сама способна выступить в его роли. Нет тут гарантий никаких.
Верификация не гарантирует, что код будет хорошим в смысле архитектуры, но она гарантирует, что код будет корректным. А это уже огромный шаг вперёд к доверию.
То есть тупо проверили, что код компилится, проходит линтеры и проставили галочку "проверено". Нужен кто-то или что-то, что проверяет правильность того, что мы сделали и LLM здесь не подойдет поскольку она и есть источник кода. Так понимаю здесь речь идет о TypeScript, а если у нас не Rust/Go/Java, а что-то динамическое? Получается и этих механизмов нет, остается только доверять автотестам от той же LLM.
Лорен проводит параллель с управлением людьми. Если вы менеджер и не доверяете своей команде, вы начинаете микроменеджерить, тратить время на проверку каждого коммита. Точно так же с агентами.
За подобную софистику надо помидорами закидывать. Здесь попытка наделить LLM человеческими качествами через проведение аналогии. Нет их, агент это просто программа работающая на базе языковой модели. Да, иногда хорошо работает, а иногда и нет. Проверка как раз об этом.
В CI реализованы проверки на уровне графа зависимостей, чтобы код из рендерер‑процесса не импортировал тяжеловесные модули, которые должны работать только в главном процессе Electron. Запрещены все паттерны, которые плохо обрабатываются агентами: например, useEffect в React, потому что это частая причина проблем с производительностью и агенты часто используют его неправильно.
Ну опять же, это все про то как код выглядит, а не то как он работает. Самое важное понять что код выдает результат, что нам нужен.
Статья имеет нулевую ценность. Описан абсолютно тривиальный путь разработчика работающего с агентами. Сначала просто пробуешь работать с агентом, пишешь вручную весь контекст в диалоговом режиме. Через какое-то время понимаешь, что можно улучшить процесс через написание скилов и спецификации проекта. Потом осознаешь, что контекст не резиновый и начинаешь более качественно писать скилы и управлять им. Затем в помощь приходят готовые инструменты лучше встраивающие информацию о кодовой базе в контекст и т.д.
Описанный подход опирается на предположение, что LLM достаточно умна, чтобы сделать все правильно при наличии поданного контекста. Это утверждение никак не доказано и все механизмы нацеленные на подсовывание машине нужных инструкций это костыльные попытки заставить гомункула делать то, что нам надо. Сегодня одна модель, завтра другая. Новые веса, новый вендор, обучение на новом датасете и можем перестать уметь выполнять задачи которые раньше хорошо решались. Проблема тут в том, что LLM это статистическая модель работающая с вероятностями, а система проверки должна работать детерминировано.
Все время пишем скилы, спеку и инструменты, чтобы система работала автономно... где же тут автоматизация? :)
Это все очень здорово конечно, но не понятно какой контент считается взрослым. Понятно, что подросток вряд ли будет изучать тонкости разработки распределенного приложения на Go например, но что делать когда платформа просто источник развлечений?
У многих болгеров/стримеров основная возрастная категория это дети и подростки. Что если мне нравится использовать YouTube только для просмотра летсплеев любимых игр и мемов? Выглядит что будут возникать ложно положительные срабатывания из-за которых захочется перейти на другую платформу как уже было отмечено комментаторами сверху.
На мой взгляд фильтрация контента в первую очередь должна исходить от родителей, а не от внешних систем. Лучше заниматься улучшением просвещения в воспитании, а не усложнять работу того, что не нуждается в подобных улучшениях.
Почему-то очень смеялся с примера с банком. Эксперт предложил думать головой и делать нормально, а не хуяк-хуяк и в продакшн. Вы решили хуяк-хуяк и декларируете это как правильный подход. Не надо так. Это больше про ошибку выжившего.
Продолжения истории о том, что стало с продуктом через год-два и не развалило ли это решение его через 5 лет конечно же никто не предоставит.
В чем вообще ценность этой статьи? То, что нужно всегда думать своей головой и так база для любого специалиста, а сама статья просто мусор выглядящий как скомканный набор мыслей оформленный через ChatGPT
if (match1 := pattern1.match(data)):
result = match1.group(1)
elif (match2 := pattern2.match(data)):
result = match2.group(2)
else:
result = None
Вместо:
match1 = pattern1.match(data)
match2 = pattern2.match(data)
if match1:
result = match1.group(1)
elif match2:
result = match2.group(2)
else:
result = None
Выглядит как попытка добавления синтаксического мусора в язык. Количество логики в данном случае не уменьшилось, зато теперь надо парсить глазами содержимое между скобок.
Эх, только взял 3090 Ti, а теперь она на помойку (нет). А если серьезно во всех этих новостях меня расстраивает, что скорость прогресса на рынке потребительских мониторов не поспевает за ростом вычислительных мощностей. Большинство так и сидит на Full HD, либо только привыкает к QHD, когда если верить сказанному в новости карта уже может давать адекватный фреймрейт в 8к (сложилось такое мнение).
Диффурам :) Простите не удержался, но любой матан совсем самостоятельно изучать довольно больно хотя бы в плане мотивации, а многие вещи при его владении воспринимаются куда легче, если мы говорим о чтении Кнута например.
Но тут же оговорюсь, что эти знания находят своё практическое применение далеко не везде.
Он ещё и в Оперу залез паразитически устанавливая виджет своего поисковика на стартовую панель взамен гугловской без возможности изменить его на родной досаждая периодически всплывающими подсказками о включении если ты его вырубил в настройках. Причём он устанавливается даже когда качаешь «версию с поиском google» с офф сайта Оперы при наличии русской локали/геометки на хосте, точно не уверен, но тут претензия и к создателям Оперы конечно.
Не такая уж и бесплатная, подозреваю деньги налогоплательщиков расходуемые на содержание этой инфраструктуры куда больше нежели заключённые способны компенсировать.
Быть может в процессе эволюции, когда видов первобытного человека было более одного определённые черты лица свидетельствовали о принадлежности особи к своему виду и это делало партнёра более привлекательным. Меня бы, если честно, удовлетворил бы и ответ о том, что это всего-лишь ответная реакция в прошивке нашего мозга сформированная случайным образом.
Возможно также сам вопрос поставлен некорректным образом и на самом деле нужно спросить откуда берётся тяга к красоте, попытки найти которую в окружающем заставляют эту красоту сформироваться в глазах смотрящего, а не наоборот.
Эволюция это слепой процесс не имеющий цели и не стремящийся осознанно закрепить какие-либо полезные признаки. Передаются и закрепляются гены способствующие их передаче, иначе говоря, партнёр с красивым личиком более привлекателен для размножения отсюда и выделение этого признака.
это удел опытных программистов, которые хотят вложить больше
Так кода то особо меньше не стало, просто он перешел из вертикальной плоскости в горизонтальную.
Читаемость — весьма субъективное понятие
Быть может до определенного момента. Любая конструкция имеющая вложенное содержимое локализуемое посредством скобок любого формата по умолчанию заставляет парсить глазами этот текст, ухудшая читаемость.
Как мне кажется из приведенного Вами тезиса о скорости и типизации не следует наличие проблем с написанием больших проектов. YouTube по-вашему достаточно большой проект?
За 3 года программирования на Python ни разу не столкнулся с тем, что в какой-то момент времени в процессе долгой работы программы получаю объект не того типа, который функция ожидала принять. Это ещё связано и с тем, что в нём нет приведения типов и, соответственно, граблей этим обусловленных. ИМХО больше проблем доставляют слабо типизированные языки вроде Си или Js совершающие не очевидные преобразования при подаче разнотиповых операндов, лишь бы получить хоть какой-нибудь результат даже, если он бесполезен.
В стадии evals нет никакой магии, гуглить тут особо нечего. Это просто этап, где мы запускаем разнородные механизмы проверки и реализуем сценарии тестирования. Они делятся на два подмножества:
детерминированные (линтеры, типы, санитайзеры, срезы перформанса и т.п.) — измеримы, область применимости известна и вычислима
недетерминированные на базе LLM (judge-системы, агентская кросс-валидация и т.д.) — измерения возможны, но метрики шумные и границы применимости заранее неизвестны
В каждом проекте свой набор практик, но ключевое препятствие на пути к доверию как раз в недетерминированных гейтах. Дело в том, что мы не можем напрямую посчитать границы компетентности модели. Измерить можем, но только как эмпирическую частоту на своей выборке — условно, coverage по компетенциям не посчитать. Из того, что вчера задача из той же области решилась полностью автоматически, не следует, что сегодня задача X решится.
Помимо этого, ошибки судьи коррелируют с ошибками источника. Чтобы их избежать, можно взять разные модели для судейских агентов, но корреляцию они уберут не полностью. Модели обучаются примерно на тех же корпусах, по схожим методикам, поэтому в спорном месте спеки с высокой вероятностью выберут ту же развилку, и тогда проверка подтвердит корректное решение не той задачи. Многослойная проверка работает только при независимости слоёв, а здесь её нет.
Отсюда и вопрос, а может ли с принципиальной точки зрения LLM выступать наблюдателем на стадии верификации или нет, и если нет, то какими механизмами можем преодолеть это при помощи детерминированных проверок в CI. У меня нет ответа, да и ни у кого, пока проблема решается на человеческой тяге там, где ошибка чревата хоть какими-то последствиями, кроме перезалива PR.
Лорен не поставила эту проблематику и не привела пример метрик и механизмов, которые помогут быть уверенным в результате. Диагностика компилятора и прогон линтеров — это, конечно, хорошо, но они закрывают конкретный класс ошибок и ничего не говорят о соответствии спецификации. Агентское судейство на этапе верификации — рабочая практика, не спорю, но доказательства надёжности носят эмпирический характер и их надо предъявлять.
Например, можно было рассказать пару слов про мутационное тестирование: намеренно вносим в код дефекты и смотрим, сколько из них ловят тесты, написанные агентами. Доля пойманных (kill rate) как раз показывает, чего эти тесты стоят. Маленькая деталь, а даст неподготовленному читателю больше, чем весь спич.
По цифрам: и в заголовке, и в статье упоминаются 800 PR — в них нет смысла без контр-показателей. Предметный разговор случится, когда покажут долю PR, вернувшихся на доработку к человеку, процент откатов и хотфиксов, долю ошибок, доехавших до прода, и стоимость токенов на принятый PR. Тезис «руками не пишут, не ревьюят и не тестируют» вообще противоречит статье.
AI-native разработка — интересная и классная штука, чужой опыт полезен. Однако у всего есть цена, и она никак не отражена в статье. Восторженный доклад энтузиаста — это нормально, но нужно подтверждать громкие заявления цифрами. Если у Лорен всё так классно работает, как она пишет, то ей впору не PR мерджить, а патентовать пайплайн, потому что проблема сейчас на фронтире исследований и возможность практически выкинуть человека из цикла — как золото Эльдорадо, но пока в руках только лопаты :)
Так, а где контроль то, что LLM сделала все правильно? Нет примера из разряда — вот у нас есть задача по которой есть спека, наш агент её выполнил так-то и так-то, затем рой агентов + некие утилиты доказали, что решение соответствует спеке. В этой точке в статье должно появиться описание инструментов и то как они гарантируют проверку логики. Некий способ доказать изоморфность постановки задачи к её решению. Метрики, цифры и так далее, описание дрифта с целевым решением на разных конфигурациях инструментов и LLM моделей. Без всего этого тезисы голословные и ничем не подкреплены.
Я тоже могу включить в yolo моде агента, заставить его писать код и настроить проверки в CI. Не бог весть какая задача, Claude такое за пару вечеров сварганит вот только доверия к этому подходу ровно столько насколько я уверен в промптах, инструкциях и возможностях модели.
Количество не аргумент, можно и большие цифры выдавать хоть со скилами хоть без. Особенно при неограниченных ресурсах. Если код никто не ревьюит, и не тестирует, то как же так выходит, что мы думаем, что он соответствует логике? То, что принято сейчас называть автоматизацией не то, чтобы действительной ей является. Решение все равно создаю я. Описываю спецификацию, проектирую архитектуру и придумываю процессы. Написание кода агентом это финальная часть решения, которая не является боттлнеком сама по себе. Это ускорение клавиатуры. Нужна метрика подтверждающая, что описание достаточно точной задачи, которую агент сможет реализовать без уточнений будет эффективнее, чем написание самому с нуля иначе автоматизация иллюзорна.
Тейк про то, что скилы написаны и инструменты настроены я не принимаю. По Станиславскому «Не верю!». Пока продукт является конструктором из готовых компонент такой подход ещё с пивом покатит, однако достаточно сменить язык проекта, домен или вкорячить новую фичу на базе технологий под которую нет скилов и начинается новая итерация prompt engineering. Да и под каждую фичу все равно надо описать задачу. При этом если домен сложный, то без профильных знаний никуда, например разработка ОС или работа с медицинским оборудованием.
В статье этого нет, а стадии довольно интересные.
Для Лорен сам факт наличия инструментов намеренных повысить качество кода повышает уровень доверия. Оно и понятно, степень ошибки в домене в котором она работает не столь высока. Насколько я могу догадываться речь идет ещё и о фронтенде за счет чего мы получаем быструю петлю обратной связи потому что можем увидеть проблему глазами.
Спасибо за перевод. Тема довольно интересная жаль только, что сам вопрос доверия — то ради чего статья существует вообще не раскрыт.
Риторика Лорен полна подменой понятий, противоречий и не подкрепленных утверждений поэтому не могу просто пройти мимо. Сюжетная канва вообще очень странно устроена. С одной стороны выдвигается тезис, что основная проблема в доверии, но в то же время на протяжении всего спича проблемой является отсутствие у агентов умения решать конкретные задачи без участия человека.
Дальше тезисно
Можем, просто результат придется проверять в конце. Мне не нравится, что количество строк кода и набор закрытых PR выдается за валидную метрику продуктивности. В каком году мы живем? Не думал, что мемы про индусский код и разработку через количество станут новой веткой реальности.
А рядом на заборе нарисовала граффити. Что доказывает кривая? В каких единицах измерения доверие отмечено? Корреляция с количеством агентов и доверием кем измерена?
Верификация означает не это. Она означает, что у нас есть механизмы проверки кода на соответствие спецификации. Написанной людьми между прочим. Это могут быть как статические инструменты, так и человек в виде принимающего лица. Здесь проводится попытка провернуть слушателя на половом органе поскольку с одной стороны мы хотим доверять LLM через средства проверки и в то же время считаем, что LLM сама способна выступить в его роли. Нет тут гарантий никаких.
То есть тупо проверили, что код компилится, проходит линтеры и проставили галочку "проверено". Нужен кто-то или что-то, что проверяет правильность того, что мы сделали и LLM здесь не подойдет поскольку она и есть источник кода. Так понимаю здесь речь идет о TypeScript, а если у нас не Rust/Go/Java, а что-то динамическое? Получается и этих механизмов нет, остается только доверять автотестам от той же LLM.
За подобную софистику надо помидорами закидывать. Здесь попытка наделить LLM человеческими качествами через проведение аналогии. Нет их, агент это просто программа работающая на базе языковой модели. Да, иногда хорошо работает, а иногда и нет. Проверка как раз об этом.
Ну опять же, это все про то как код выглядит, а не то как он работает. Самое важное понять что код выдает результат, что нам нужен.
Статья имеет нулевую ценность. Описан абсолютно тривиальный путь разработчика работающего с агентами. Сначала просто пробуешь работать с агентом, пишешь вручную весь контекст в диалоговом режиме. Через какое-то время понимаешь, что можно улучшить процесс через написание скилов и спецификации проекта. Потом осознаешь, что контекст не резиновый и начинаешь более качественно писать скилы и управлять им. Затем в помощь приходят готовые инструменты лучше встраивающие информацию о кодовой базе в контекст и т.д.
Описанный подход опирается на предположение, что LLM достаточно умна, чтобы сделать все правильно при наличии поданного контекста. Это утверждение никак не доказано и все механизмы нацеленные на подсовывание машине нужных инструкций это костыльные попытки заставить гомункула делать то, что нам надо. Сегодня одна модель, завтра другая. Новые веса, новый вендор, обучение на новом датасете и можем перестать уметь выполнять задачи которые раньше хорошо решались. Проблема тут в том, что LLM это статистическая модель работающая с вероятностями, а система проверки должна работать детерминировано.
Все время пишем скилы, спеку и инструменты, чтобы система работала автономно... где же тут автоматизация? :)
Это все очень здорово конечно, но не понятно какой контент считается взрослым. Понятно, что подросток вряд ли будет изучать тонкости разработки распределенного приложения на Go например, но что делать когда платформа просто источник развлечений?
У многих болгеров/стримеров основная возрастная категория это дети и подростки. Что если мне нравится использовать YouTube только для просмотра летсплеев любимых игр и мемов? Выглядит что будут возникать ложно положительные срабатывания из-за которых захочется перейти на другую платформу как уже было отмечено комментаторами сверху.
На мой взгляд фильтрация контента в первую очередь должна исходить от родителей, а не от внешних систем. Лучше заниматься улучшением просвещения в воспитании, а не усложнять работу того, что не нуждается в подобных улучшениях.
Почему-то очень смеялся с примера с банком. Эксперт предложил думать головой и делать нормально, а не хуяк-хуяк и в продакшн. Вы решили хуяк-хуяк и декларируете это как правильный подход. Не надо так. Это больше про ошибку выжившего.
Продолжения истории о том, что стало с продуктом через год-два и не развалило ли это решение его через 5 лет конечно же никто не предоставит.
В чем вообще ценность этой статьи? То, что нужно всегда думать своей головой и так база для любого специалиста, а сама статья просто мусор выглядящий как скомканный набор мыслей оформленный через ChatGPT
Это:
Вместо:
Выглядит как попытка добавления синтаксического мусора в язык. Количество логики в данном случае не уменьшилось, зато теперь надо парсить глазами содержимое между скобок.
Эх, только взял 3090 Ti, а теперь она на помойку (нет). А если серьезно во всех этих новостях меня расстраивает, что скорость прогресса на рынке потребительских мониторов не поспевает за ростом вычислительных мощностей. Большинство так и сидит на Full HD, либо только привыкает к QHD, когда если верить сказанному в новости карта уже может давать адекватный фреймрейт в 8к (сложилось такое мнение).
Но тут же оговорюсь, что эти знания находят своё практическое применение далеко не везде.
Возможно также сам вопрос поставлен некорректным образом и на самом деле нужно спросить откуда берётся тяга к красоте, попытки найти которую в окружающем заставляют эту красоту сформироваться в глазах смотрящего, а не наоборот.
Быть может до определенного момента. Любая конструкция имеющая вложенное содержимое локализуемое посредством скобок любого формата по умолчанию заставляет парсить глазами этот текст, ухудшая читаемость.
За 3 года программирования на Python ни разу не столкнулся с тем, что в какой-то момент времени в процессе долгой работы программы получаю объект не того типа, который функция ожидала принять. Это ещё связано и с тем, что в нём нет приведения типов и, соответственно, граблей этим обусловленных. ИМХО больше проблем доставляют слабо типизированные языки вроде Си или Js совершающие не очевидные преобразования при подаче разнотиповых операндов, лишь бы получить хоть какой-нибудь результат даже, если он бесполезен.