Происходит вполне осязаемый процесс зомбирования многопоточностью
Современная многопоточность это alter ego ... последовательного программирования.
Кажется многопоточность это просто абстракция операционной системы над реальным железом, и не более того. Мы используем её чтобы делегировать ОСи работу по переключению контекста, а как оно дальше исполняется, нас в целом не волнует. В результате использование потоков может привести либо к конкурентному исполнению (1 задача в каждый момент времени), либо к параллельному (много задач одновременно).
Как и любая другая абстракция, она нужна для удобства написания программ. Более того, многопоточность опциональная (aka "opt-in"), программист может в рантайме решить, стоит ли использовать её или нет. При параллельном исполнении программа скорее всего затратит меньше времени, что часто и является желаемым эффектом.
Я осознаю, что дальше в статье идут почти философские рассуждения, но кажется существует недопонимание терминов на базовом уровне.
Кажется мой коммент к предыдущей статье про django-cfg подтвердился, и никому в целом не нужен ллм-сгенерированный проект на десятки тысяч строк, разобраться в котором примерно невозможно.
То, что проект django-cfg сменил направление с конфигурации сервера джанги на персональную ллм-платформу, это конечно интересно.
Стоит также отметить что на гитхабе коммитов меньше, чем релизов на pypi, а значит восстановить хоть какую-любо историю изменений невозможно. Огромные коммиты, меняющие десятки тысяч строк, также не помогают ситуации. Ещё емнип пакет pydantic2 принадлежит автору, и так же является ллм слопом.
Теперь пару слов про Cure. Как я понимаю, автор говорит о нём, когда упоминает что написал свой язык.
Бесконечный респект за написание своего языка, но правильно ли я помню что пару месяцев назад сайт был полностью сгенерирован ЛЛМами, и на котором были заявления, не подтверждающиеся реально существующим кодом? Если кому-то очень скучно, можно одним глазом глянуть тред на хакерньюсе и другим на вебархив.
Согласиться можно только с критикой синтаксиса макросов, он действительно сбивает с толку, очень перегружен, и неудобен для написания.
Всё остальное, к сожалению, просто придирки. Сравнения с эрлангом и эликсиром не особо к месту.
У раста есть свои проблемы. Тема прибитого сбоку асинка не раскрыта, тайп касты через as, negative impls не упомянуты. То что Copy реализован для примитивов, что иногда приводит к неожиданному результату, тоже не упомянуто.
В общем есть много что обсудить. Я понимаю, что эти проблемы всплывают только при длительном использовании языка, и только в каких-то конкретных случаях, но представленное в статье не является хорошим аргументом.
Оригинальная статья странная, и кажется её целью не было нормально что-то поисследовать.
Выборка:
Table 2. Distribution of commits and PRs by associated AI agent. OpenAI Codex ... 89% commits
Я пытался понять, что такое RefactorMiner, и как они его использовали для категоризации коммитов. Но кажется всё прозаичнее:
4.3. RQ3: What is the purpose of agentic refactoring? 4.3.2. Approach ... The classification uses the Pull Request title, commit message, and detected refactoring types as input. Due to the large sample size of the collected Agentic Refactoring commits, we leverage GPT-4.1-mini to automatically categorize each commit.
В целом складывается ощущение что в оригинале просто льют воды (что в целом случается), однако забавно, что в наблюдениях (по ходу статьи) приведены в основном недостатки ЛЛМ агентов, а в итоговых выводах как бы между строк говорится о том, что ЛЛМ агенты уже во всю рефакторят код, и что пора бы всем их начинать использовать.
Ещё к сожалению, данная статья (перевод, не оригинал) теряет много деталей. Перевод (эта статья):
Доверяйте агенту, чтобы справиться с рутиной. Такой рефакторинг уже полезен с точки зрения типовых исправлений, выравнивания стиля, декомпозиции и сокращения времени на код-ревью.
Оригинал
Implications for Developers
<...> Developers can delegate routine cleanup to agents and focus human effort on design-level restructuring that requires domain knowledge and architectural intent. Given that many refactoring instances (53.9%) occur implicitly within non-refactoring commits (Section 4.1), developers must remain vigilant during code review to validate these tangled changes.
Для сравнения, "доверяйте агенту" против "разработчики имеют возможность делегировать ..., но даже в этом случае нужно быть на чеку ..."
Дальше разбирать лень, в оригинале ещё несколько интересных наблюдений сделано (можно погрепать по "finding"). Если коротко, ЛЛМ агенты хороши, если вам надо повысить метрики по перекладыванию кирпичей из одной кучи в другую.
Быстро по тезисам из этой статьи тогда, раз уж такое дело
Рефакторинг <...> улучшает читаемость и сопровождение системы
Тогда и только тогда когда это не бессмысленный рефакторинг дробления функций на более мелкие и потом сбор их них больших функций.
LLM-агенты дополнительно позволяют автоматизировать рефакторинг кода,
Кажется, не позволяют, и к этому выводу приходят в оригинальной статье
[по сравнению с человеком,] агент скорее занимается «повседневным уходом» за кодовой базой и реже трогает архитектуру системы.
Кажется даже очевидно почему — я уверен, в выборке для обучения просто огромное количество ответов со stackoverflow о том, как из одной большой функции сделать 2 поменьше. И там же на стаковерфлоу примерно 0 ответов о том, как дизайнить архитектуру приложения (что логично).
Как часто и как выглядит рефакторинг у агентов
Это довольно распространенная практика: 26.1% Java-коммитов явно посвящены рефакторингу и демонстрируют больше рефакторинговых операций за счёт того, что они сконцентрированы в одном месте. То есть это не побочный эффект других правок, а именно продуманная задача (часто в отдельном PR).
Несколько раз перечитывал и не понял, что имеется в виду.
_
P.S. у ЛЛМ ботов нет "сознания", L в LLM значит "Language", то есть они буквально перемешивают тонны текста и выдают результаты основываясь на статистических данных. Как уже выше было сказано, объём данных с ответом на вопрос "как вычленить две функции из одной" гораздо выше чем "как спроектировать приложение Х". Вот в целом и всё. Для качественного прыжка необходим другой подход, какая-то новая архитектура модели машинного обучения, или что-то ещё, — кто знает. Пока LLM упираются в стену при недостатке данных для обучения, а также ломаются при наличии небольшого объёма "плохих" (aka poisoned) данных.
Не думаю, что за мою 45-летнюю карьеру какой-то другой язык удивлял меня сильнее, чем Zig. Могу с уверенностью сказать, что Zig — это не только новый язык программирования, но и, на мой взгляд, совершенно новый способ написания программ.
Иронично что после такого громкого начала идёт перечиследние довольно обыденных вещей, которыми обладает большое количество современных языков.
Откровенно не понимаю, почему эта статья собрала так много голосов на хакер ньюсе.
В зиге действительно есть интересные концепты, хотелось бы сфокусироваться на них.
Там есть ещё один интересный кейс: ямловые шаблоны, которые с чего-то стали очень популярны
Представьте: язык, в котором "yes" может быть либо строкой либо булом, со значимыми пробелами, используется для шаблонизации и встраивания других объектов. No fun писать специальный темплейт движок для такого.
В языках со скобками можно просто зашаблонировать куски и вставить их "как есть", и получить однозначный результат после прогона форматтера
Без проблем. Опять же, у меня свой юзкейс для кучи деплойментов на десятки серверов, с кучей зависимых друг от друга частей, у вас — свой.
Могу сказать что в проде у нас для конфигов используется смесь ямла и питона (ворклоады либо определены прямо в питоне, либо питон парсит ямл и выплёвывает объект ворклоада). Так можно валидировать всё и вся. Например, можно статически на этапе сборки и проверки конфигов построить файл-мап всех портов которые должны быть открыты публично или только во внутренней подсети. Питон в целом нормально, но немного геморно, в основном потому, что нужно слишком много дата процессинга писать чтобы сконверить один ворклоад в нужный формат. (У питона есть и другие проблемы, но мы их опустим)
Было бы неплохо для этого использовать какой-нибудь простенький язык, но мы решили остаться на питоне, потому что остальные куски инфры уже были на нём. Но в целом я думаю какой-нибудь CUE бы нам подошёл.
Удачи вам с вашим языком конфигов, посмотрим как будет развиваться
урезав возможности для того чтобы убрать всякие уязвимости.
или просто использовать уже готовый язык, с урезанными возможностями, хорошим тулингом и имплементацией с минимальным количеством зависимостей (чтобы уменьшить риск уязвимостей)
все-таки язык конфигурации, а не язык программирования
Встаём на тонкий лёд споров об определениях. Является ли ваш х... и ямловый <<: *a тем же самым, что и питоновское a | { ... }? Если да, то почему одно является язком программирования, а другое нет?
Язык программирования не обязательно должен быть развесистым как питон, даже простенький DSL может являтся ЯПом. Также, к счастью, перечисленные мной конкуренты (CUE, jsonnet, Pkl, dhall) не являются generic-purpose язками, и некоторые даже не являются turing complete.
Было бы интересно увидеть подробное сравнение вашего языка и перечисленных.
как сделать ключ с пробелом?
Никак. А надо?
Получается, что язык даже не является суперсетом JSON. Но если серьёзо отвечать на вопрос, то да, конечно надо.
можно ли сделать циклы?
Если это про циклические зависимости, то нет - детектится и выдается ошибка
Нет, речь про циклы, конечно, а-ля for item in ... или подобные способы избежать копипасты кода. Особенно полезно при модификации списков, учитывая что рекурсивный мерж просто обновит значение (что в целом логично, и правильно)
В целом свой язык конфигов прикольно, хорошее занятие.
От себя могу добавить (и там в треде выше уже упомянули), что при работе с огромным количеством конфигов действительно хочется иметь простой не-тьюринг полный язык для избежания дедупликации всего по нескольку раз, и для этого нужны абстракции в виде циклов, условий, и т.п. Но это субъективно конечно. Моё мнение в основном совпадает с этой статьёй https://ruudvanasseldonk.com/2025/abstraction-not-syntax.
Основная проблема всех "статичных" языков не в синтаксисе (хотя насчёт ямла можно поспорить), а в том, что в этих языках нет синтаксических конструкций для избежания копипасты.
HCL пытается с этим что-то делать, вводя модули, но не забывая вводить магические переменные для описания циклов — что, по мне, отвратительно, и начинает напоминать Ansible с его декларативными конструкциями, которые на практике оказываются просто нетипизируемым ямлом. Ямл тоже пытается избежать копипасты со своими anchors, и <<, но, опять же, на практике это превращается в просто месиво.
Итого, потребность в хорошем языке для конфигов действительно есть.
В статье отсутствует какое-либо сравнение с существующими языками, включая плюсы и минусы каждого из них. Понятно, что ATMC яыляется более "выразительным", и более абстрактным, нежели JSON, YAML etc. Поэтому также стоит сравнить с Pkl, dhall, CUE, jsonnet и другими.
По статье, не доконца понял
можно ли отрендерить/экспоритировать .atmc конфиг в другие форматы?
как сделать ключ с пробелом?
можно ли сделать циклы?
пофейлится ли конфиг с одинаковыми ключами или есть какое-то правило?
при рекурсивном мерже, мержатся ли списки или просто перезаписываются?
Довольно много воды, как мне показалось, и в целом ничего нового узнать не получилось.
Ещё в статье сделано очень много предпложений разряда "сильно подозреваю, что у многих есть мысли, что, например, ...", и в целом ничего плохого в таких предпложениях нет, просто такие блоки текста не информативны, имхо.
Однако, ближе к концу делается несколько интересный утверждений/предположений (я не уверен уже)
По своему опыту могу сказать, что письмо является самым эффективным способом.
По моему опыту (стоит сказать, что я не учитель), эффективность изучения иностранного языка очень сильно зависит от студента, кто-то может на слух воспринимать сложные конструкции на интуитивном уровне, кто-то лучше понимает грамматику, и отталкивается от неё. Задача преподавателя как раз понять, какой из способов больше всего подходит конкретному ученику, и помогать развивать недостающие знания.
Сейчас становится очевидно, что ценность приобретают не сами знания, а способность их быстро и эффективно использовать, так сказать «оперативная память», которая включает и способность к концентрации.
Звучит как поток слов. Способность быстро и эффективно использовать занаия кажется в почёте во все времена, не уверен, что что-то поменялось в последние годы. Также не уверен, что оперативная память как-то влияет на способность к концентрации (имеется ли в виду под концентрацией "внимание" и применимы ли тут исследования про СДВГ, я понять не смог, так что не буду делать предпложения). Постоянные повторения слов и времён заталкивают эти слова в "постоянную память", из которой как раз сложно выкинуть фундаментальные концепты.
Итого, больше похоже на саморекламу телеграм канала
Статья была бы нормальная, если бы не была на 80% наполнена водой, с примерами, подтверждения нескольким из которых я не нашёл.
Упоминается "вайбкоженая" уязвимость в Fortnite, информация о которой скорее всего взята с этого сайта, и не имеет никакого отношения к вайб кодингу:
Fortnite, with over 350 million users, discovered a SQL injection vulnerability in 2019 that could have let attackers access user accounts. The vulnerability was in authentication-related code that hadn’t been properly validated against injection attacks.
Это оказался просто пример уязвимости, для иллюстрации потенциальной проблемы.
Далее,
CVE-2025-55284 — уязвимость в Claude Code позволяла извлекать данные с компьютера разработчика
Если я правильно понимаю, сама уязвимость не была результатом вайб кодинга, и просто упомянута здесь для красного словца.
Продолжаем,
Симптомы "уставшей модели"
После 20-30 итераций правок модель начинает вести себя странно. Из статьи "Вайб-кодинг глазами старого разработчика":
И опять же, посыл статьи нормальный, правильный, -- нужно думать когда используешь ллм код, -- но зачем так наспех собирать что-то в статью, мне откровенно непонятно.
Кажется многопоточность это просто абстракция операционной системы над реальным железом, и не более того. Мы используем её чтобы делегировать ОСи работу по переключению контекста, а как оно дальше исполняется, нас в целом не волнует. В результате использование потоков может привести либо к конкурентному исполнению (1 задача в каждый момент времени), либо к параллельному (много задач одновременно).
Как и любая другая абстракция, она нужна для удобства написания программ. Более того, многопоточность опциональная (aka "opt-in"), программист может в рантайме решить, стоит ли использовать её или нет. При параллельном исполнении программа скорее всего затратит меньше времени, что часто и является желаемым эффектом.
Я осознаю, что дальше в статье идут почти философские рассуждения, но кажется существует недопонимание терминов на базовом уровне.
Кажется мой коммент к предыдущей статье про django-cfg подтвердился, и никому в целом не нужен ллм-сгенерированный проект на десятки тысяч строк, разобраться в котором примерно невозможно.
То, что проект
django-cfgсменил направление с конфигурации сервера джанги на персональную ллм-платформу, это конечно интересно.Стоит также отметить что на гитхабе коммитов меньше, чем релизов на pypi, а значит восстановить хоть какую-любо историю изменений невозможно. Огромные коммиты, меняющие десятки тысяч строк, также не помогают ситуации. Ещё емнип пакет
pydantic2принадлежит автору, и так же является ллм слопом.Теперь пару слов про Cure. Как я понимаю, автор говорит о нём, когда упоминает что написал свой язык.
Бесконечный респект за написание своего языка, но правильно ли я помню что пару месяцев назад сайт был полностью сгенерирован ЛЛМами, и на котором были заявления, не подтверждающиеся реально существующим кодом? Если кому-то очень скучно, можно одним глазом глянуть тред на хакерньюсе и другим на вебархив.
Согласиться можно только с критикой синтаксиса макросов, он действительно сбивает с толку, очень перегружен, и неудобен для написания.
Всё остальное, к сожалению, просто придирки. Сравнения с эрлангом и эликсиром не особо к месту.
У раста есть свои проблемы. Тема прибитого сбоку асинка не раскрыта, тайп касты через
as, negative impls не упомянуты. То чтоCopyреализован для примитивов, что иногда приводит к неожиданному результату, тоже не упомянуто.В общем есть много что обсудить. Я понимаю, что эти проблемы всплывают только при длительном использовании языка, и только в каких-то конкретных случаях, но представленное в статье не является хорошим аргументом.
Пробежался бегло по коду, и кажется там абсолютно всё сгенерено нейросетями, перед сном читать не рекомендую.
Оригинальная статья странная, и кажется её целью не было нормально что-то поисследовать.
Выборка:
Я пытался понять, что такое RefactorMiner, и как они его использовали для категоризации коммитов. Но кажется всё прозаичнее:
В целом складывается ощущение что в оригинале просто льют воды (что в целом случается), однако забавно, что в наблюдениях (по ходу статьи) приведены в основном недостатки ЛЛМ агентов, а в итоговых выводах как бы между строк говорится о том, что ЛЛМ агенты уже во всю рефакторят код, и что пора бы всем их начинать использовать.
Ещё к сожалению, данная статья (перевод, не оригинал) теряет много деталей. Перевод (эта статья):
Оригинал
Для сравнения, "доверяйте агенту" против "разработчики имеют возможность делегировать ..., но даже в этом случае нужно быть на чеку ..."
Дальше разбирать лень, в оригинале ещё несколько интересных наблюдений сделано (можно погрепать по "finding"). Если коротко, ЛЛМ агенты хороши, если вам надо повысить метрики по перекладыванию кирпичей из одной кучи в другую.
Быстро по тезисам из этой статьи тогда, раз уж такое дело
Тогда и только тогда когда это не бессмысленный рефакторинг дробления функций на более мелкие и потом сбор их них больших функций.
Кажется, не позволяют, и к этому выводу приходят в оригинальной статье
Кажется даже очевидно почему — я уверен, в выборке для обучения просто огромное количество ответов со stackoverflow о том, как из одной большой функции сделать 2 поменьше. И там же на стаковерфлоу примерно 0 ответов о том, как дизайнить архитектуру приложения (что логично).
Несколько раз перечитывал и не понял, что имеется в виду.
_
P.S. у ЛЛМ ботов нет "сознания", L в LLM значит "Language", то есть они буквально перемешивают тонны текста и выдают результаты основываясь на статистических данных. Как уже выше было сказано, объём данных с ответом на вопрос "как вычленить две функции из одной" гораздо выше чем "как спроектировать приложение Х". Вот в целом и всё. Для качественного прыжка необходим другой подход, какая-то новая архитектура модели машинного обучения, или что-то ещё, — кто знает. Пока LLM упираются в стену при недостатке данных для обучения, а также ломаются при наличии небольшого объёма "плохих" (aka poisoned) данных.
Как мне кажется, минусы навалили из-за:
статья просто копипаста из ридми проекта (или наоборот)
в статье очень много воды, громких заголовков и повторений, что также отдаёт ЛЛМ вайбами
действительно важные фичи этого языка не вынесены на первый план и на них не сделан акцент, но в свою очередь сделан акцент на простоте синтаксиса
дополняя предыдущий поинт, нет сравнений даже с JSON, упомянутым в заголовке
ИМХО, у статьи было бы более высокая плотность информации на символ если бы она была сильно короче, к примеру:
короткое введение
нужно мержить конфиги рекурсивно? -- делается через
...нужно разбить конфиги на модули? -- есть модули
и т.д.
Не понял, про какой "вид" речь? Растовый println поддерживает захват переменных с определённой версии
Но это всё вкусовщина, что в питоне, что в расте, что в зиге.
Имхо это наименьшая из проблем зига. Раст прожил несколько лет без захвата внешних переменных в
println!и в целом всем было +- всё равно.Пока не может. В ближайшем будущем тоже скорее всего не сможет, дальше посмотрим
Иронично что после такого громкого начала идёт перечиследние довольно обыденных вещей, которыми обладает большое количество современных языков.
Откровенно не понимаю, почему эта статья собрала так много голосов на хакер ньюсе.
В зиге действительно есть интересные концепты, хотелось бы сфокусироваться на них.
Там есть ещё один интересный кейс: ямловые шаблоны, которые с чего-то стали очень популярны
Представьте: язык, в котором "yes" может быть либо строкой либо булом, со значимыми пробелами, используется для шаблонизации и встраивания других объектов. No fun писать специальный темплейт движок для такого.
В языках со скобками можно просто зашаблонировать куски и вставить их "как есть", и получить однозначный результат после прогона форматтера
Без проблем. Опять же, у меня свой юзкейс для кучи деплойментов на десятки серверов, с кучей зависимых друг от друга частей, у вас — свой.
Могу сказать что в проде у нас для конфигов используется смесь ямла и питона (ворклоады либо определены прямо в питоне, либо питон парсит ямл и выплёвывает объект ворклоада). Так можно валидировать всё и вся. Например, можно статически на этапе сборки и проверки конфигов построить файл-мап всех портов которые должны быть открыты публично или только во внутренней подсети. Питон в целом нормально, но немного геморно, в основном потому, что нужно слишком много дата процессинга писать чтобы сконверить один ворклоад в нужный формат. (У питона есть и другие проблемы, но мы их опустим)
Было бы неплохо для этого использовать какой-нибудь простенький язык, но мы решили остаться на питоне, потому что остальные куски инфры уже были на нём. Но в целом я думаю какой-нибудь CUE бы нам подошёл.
Удачи вам с вашим языком конфигов, посмотрим как будет развиваться
В ямле
noэто строка "no" или false? (И там ещё много примеров, можно погуглить по "yaml from hell")Уж лучше явные строки чем гадать на кофейной гуще, и вычленять различия версий 1.0, 1.1, 1.2 (речь про ямл спек, конечно же)
это, конечно, не так, есть как минимум CUE и несколько других вариантов
или просто использовать уже готовый язык, с урезанными возможностями, хорошим тулингом и имплементацией с минимальным количеством зависимостей (чтобы уменьшить риск уязвимостей)
но в целом это субъектившина
Встаём на тонкий лёд споров об определениях. Является ли ваш
х...и ямловый<<: *aтем же самым, что и питоновскоеa | { ... }? Если да, то почему одно является язком программирования, а другое нет?Язык программирования не обязательно должен быть развесистым как питон, даже простенький DSL может являтся ЯПом. Также, к счастью, перечисленные мной конкуренты (CUE, jsonnet, Pkl, dhall) не являются generic-purpose язками, и некоторые даже не являются turing complete.
Было бы интересно увидеть подробное сравнение вашего языка и перечисленных.
Получается, что язык даже не является суперсетом JSON. Но если серьёзо отвечать на вопрос, то да, конечно надо.
Нет, речь про циклы, конечно, а-ля
for item in ...или подобные способы избежать копипасты кода. Особенно полезно при модификации списков, учитывая что рекурсивный мерж просто обновит значение (что в целом логично, и правильно)В целом свой язык конфигов прикольно, хорошее занятие.
От себя могу добавить (и там в треде выше уже упомянули), что при работе с огромным количеством конфигов действительно хочется иметь простой не-тьюринг полный язык для избежания дедупликации всего по нескольку раз, и для этого нужны абстракции в виде циклов, условий, и т.п. Но это субъективно конечно. Моё мнение в основном совпадает с этой статьёй https://ruudvanasseldonk.com/2025/abstraction-not-syntax.
Основная проблема всех "статичных" языков не в синтаксисе (хотя насчёт ямла можно поспорить), а в том, что в этих языках нет синтаксических конструкций для избежания копипасты.
HCL пытается с этим что-то делать, вводя модули, но не забывая вводить магические переменные для описания циклов — что, по мне, отвратительно, и начинает напоминать Ansible с его декларативными конструкциями, которые на практике оказываются просто нетипизируемым ямлом. Ямл тоже пытается избежать копипасты со своими anchors, и
<<, но, опять же, на практике это превращается в просто месиво.Итого, потребность в хорошем языке для конфигов действительно есть.
В статье отсутствует какое-либо сравнение с существующими языками, включая плюсы и минусы каждого из них. Понятно, что ATMC яыляется более "выразительным", и более абстрактным, нежели JSON, YAML etc. Поэтому также стоит сравнить с Pkl, dhall, CUE, jsonnet и другими.
По статье, не доконца понял
можно ли отрендерить/экспоритировать .atmc конфиг в другие форматы?
как сделать ключ с пробелом?
можно ли сделать циклы?
пофейлится ли конфиг с одинаковыми ключами или есть какое-то правило?
при рекурсивном мерже, мержатся ли списки или просто перезаписываются?
Ещё много вопросов можно задать, но думать лень
Довольно много воды, как мне показалось, и в целом ничего нового узнать не получилось.
Ещё в статье сделано очень много предпложений разряда "сильно подозреваю, что у многих есть мысли, что, например, ...", и в целом ничего плохого в таких предпложениях нет, просто такие блоки текста не информативны, имхо.
Однако, ближе к концу делается несколько интересный утверждений/предположений (я не уверен уже)
По моему опыту (стоит сказать, что я не учитель), эффективность изучения иностранного языка очень сильно зависит от студента, кто-то может на слух воспринимать сложные конструкции на интуитивном уровне, кто-то лучше понимает грамматику, и отталкивается от неё. Задача преподавателя как раз понять, какой из способов больше всего подходит конкретному ученику, и помогать развивать недостающие знания.
Звучит как поток слов. Способность быстро и эффективно использовать занаия кажется в почёте во все времена, не уверен, что что-то поменялось в последние годы. Также не уверен, что оперативная память как-то влияет на способность к концентрации (имеется ли в виду под концентрацией "внимание" и применимы ли тут исследования про СДВГ, я понять не смог, так что не буду делать предпложения). Постоянные повторения слов и времён заталкивают эти слова в "постоянную память", из которой как раз сложно выкинуть фундаментальные концепты.
Итого, больше похоже на саморекламу телеграм канала
Статья была бы нормальная, если бы не была на 80% наполнена водой, с примерами, подтверждения нескольким из которых я не нашёл.
Упоминается "вайбкоженая" уязвимость в Fortnite, информация о которой скорее всего взята с этого сайта, и не имеет никакого отношения к вайб кодингу:
Это оказался просто пример уязвимости, для иллюстрации потенциальной проблемы.
Далее,
Если я правильно понимаю, сама уязвимость не была результатом вайб кодинга, и просто упомянута здесь для красного словца.
Продолжаем,
Полез искать, что за статья, видимо эта https://habr.com/ru/articles/943856/, упомянутого куска кода не нашёл.
И опять же, посыл статьи нормальный, правильный, -- нужно думать когда используешь ллм код, -- но зачем так наспех собирать что-то в статью, мне откровенно непонятно.