«Думать, что LLM — это „просто ещё один инструмент“, значит фактически утверждать, что ядро защищено от этого. Что, на мой взгляд, глупая позиция. Нет. Глупа ваша позиция. Нет никакого смысла говорить о ИИ-шлаке. Это просто глупо. Почему? Потому что те, кто использует ИИ-шлак, не будут документировать свои патчи как таковые. Это настолько очевидная истина, что я не понимаю, зачем вообще кто-то поднимает тему ИИ-шлака. Так что прекратите эту глупость (So stop this idiocy).
Истина одна для всех, но у каждого своя правда. Похоже, что истина персонально непознаваема, хоть и существует.
Математики ближе всех подобрались к истине (объективности). Они могут через формулы видеть истину, которая одинакова для всех, вне зависимости от типов и настроек их собственных ОС.
Автор правильно начал о процессе построения личного миропонимания. Но потом ушел в "объективность". И даже договорился до "коллектива":)
Коллективы существуют, это реальность. С объективностью сложнее - это уже вопрос настроек персональной ОС. Я различаю "истину" и "правду". Истина одна для всех, но у каждого своя правда. Похоже, что истина персонально непознаваема, хоть и существует.
Поэтому качество системы подготовки имеет огромную роль.
Абсолютно верно. Картину мира можно выстроить самостоятельно, но это будет очень скудная КМ. Даже у детей-магули, выращенных животными она богаче. Начальное образование - это фундамент, согласен.
В конце автор сбивается на попытки формализовать и обобщить (я про эмбеддинги). Он, нмв, забывает о кодировании/декодировании. Кто будет выявлять и идентифицировать оные? В какой модели (у анализируемого чела она одна, у аналитика другая)?
Эмбеддинг - это вектор, рассчитанный по тексту. Он не привязан к человеку, он привязан к тексту. Это просто характеристика текста - его координаты в некотором многомерном пространстве смыслов (мерность зависит от модели, которая считает - 384, 768, 1536, 3072, ... координат). Можно смотреть на это пространство, как на библиотеку.
Так вот, эмбеддинг любого текста - это некоторый адрес этого текста среди всех полок, стеллажей, помещений, этажей, зданий, ... этой библиотеки. Изначально библиотека пустая, мы берём тексты, рассчитываем для них эмбеддинги и помещаем тексты в библиотеку.
Считается, что тексты, близкие по смыслу (токенам), будут находиться близко друг к другу. А это значит, что вне зависимости от принципов аналитики человека, если ему "зашёл" текст с некоторым адресом, ему высоковероятно могут также "зайти" другие тексты, находящиеся рядом. Другое дело, что они могут быть сильно похожи на то, что он и так знает. Это решается увеличением расстояния поиска от начальной точки (понравившегося текста).
Более того, если смотреть, с каких "полок" человек обычно берёт тексты ориентируясь на названия / аннотации / оглавления / предисловия, какие из них он потом читает - можно примерно представлять, зайдёт ли ему новый текст, попавший в библиотеку или нет.
Нормализуется не мышление человека, нормализуются тексты, которые он читает.
Настройте свой комплект входных фильтром и научитесь отсекать этот шум. Будете удивлены, 99,99% упомянутого "избытка инфы" пропадет.
Судя по Вашему комменту, моя публикация фильтр прошла. Лестно.
Вместо того чтобы сразу бросаться в реализацию, мы создаем "Change" - папку с описанием изменений.
Если я правильно понимаю, то разработка идёт путём создания цепочки таких папок (или замещении одной и той же по мере продвижения).
Вот это - выжимка LLM по основным папкам и файлам вашего подхода:
AGENTS.md ← правила мышления агента
openspec/
project.md ← контекст проекта
changes/
<id>/
proposal.md ← зачем
tasks.md ← что
spec(s)/spec.md ← как должно работать
design.md ← (опционально) архитектура
.beads/ ← как и в каком порядке делать
.cursor/commands/
openspec-to-beads.md ← формальный переход WHAT → HOW
Такой вопрос: а где хранится целевой образ проекта в которым мы с агентами работаем? Описание того, что мы должны получить?
Это похоже на движение "отсюда и вперёд", а не "нам надо попасть туда".
Вы не можете хранить весь целевой образ проекта в одном файле project.md - это размывает контекст для каждой рабочей итерации агента. Там можно хранить базовые, глобальные ограничители и инструкции, которые именно что нужны для каждой рабочей итерации агента.
Спецификация держит рамки продукта
Если это про openspec/changes/ , то эта спецификация держит рамки изменения продукта. Рамки самого продукта в этом случае держит лишь код, который агент должен изменять. Со всеми вытекающими.
По-идее, здесь должна помогать иерархия файлов AGENTS.md. По крайней мере Codex пытается выстраивать их в цепочку и создавать корпус инструкций, применяемых по текущему месту работы (нахождению модифицируемого исходника).
Для LLM важен контекст. Даже не так - важны плотность и однородность контекста. Если ваши 300 строчек правил противоречат друг другу, то модель не сможет следовать им всем одновременно. А вот как сделать так, чтобы для каждого исходника у агента был плотный и однородный контекст (причём для различных исходников и для различных сценариев модификаций этих исходников должен быть различный контекст) - вот это уже большой вопрос, на который у Spec Kit пока что ответа нет.
Spec Kit также генерирует дерево папок и файлов, показывающее, что будет создано, изменено или удалено. Этот уровень видимости помогает разработчикам немедленно понять полный объем предстоящих изменений.
Почему "немедленно"-то? Как можно "немедленно понять", что именно хранится в дереве папок и файлов? Это как войти в супермаркет и немедленно понять, где лежит всё, что тебе нужно купить для сегодняшнего ужина, хотя в этом супермаркете ты в первый раз.
Проверяйте сгенерированный план с архитекторами и старшими разработчиками. Убедитесь, что архитектура согласована, не вводятся несанкционированные слои, а точки интеграции точны.
Может просто дать возможность самим "архитекторам и старшим разработчикам" этот план сгенерировать? По мне, так это делегирование ответственности за сгенерённый нейронкой слоп.
Я согласен, что спецификации должны быть частью проекта, если в нём задействованы llm-агенты, но доверять агентам самим генерировать спецификации, которые ты сам не понимаешь? Это зло.
Проверка сгенерированных ИИ Markdown-файлов необходима, но когнитивно утомительна. В отличие от кода или документации, написанный ИИ текст выглядит грамматически правильным и вроде бы разумным, но требует постоянного тщательного изучения на предмет фактической и архитектурной точности.
Но вот чего мы не сказали: чтение текста, сгенерированного ИИ, ментально истощает.
Абсолютная правда! Я это как следует прочувствовал на этой статье.
Заплюсовал за идею - сам двигаюсь в подобном направлении. Но как практик хотел бы увидеть меньше нейрогенерёнки и больше кода или хотя бы скриншотов, на которых видна структура ваших спецификаций. По моему опыту в плоских файлах (типа constitution.md) архитектуру проекта не описать - нужна иерархия каталогов и файлов в них. Так-то можно по коду распихать AGENTS.md и в них хранить спецификации и для /services/, и для /api/client. Мне нейронка выжимку по структуре сделала, но не уверен, что это именно то, что вы имели в виду.
У вас есть собственная устойчивая картина мира - ей и пользуйтесь. Я дал вам возможность посмотреть на мир с моей точки зрения, вы - дали такую же возможность мне.
Да, это довольно интересная линия для размышлений. Эзотерики нечто подобное называли "эгрегором". Но в это понятие включался и носитель (человек, LLM), и нарратив. "Учение Маркса всесильно, потому что оно верно" - вот яркий пример нарратива ("Капитал") и эгрегора (СССР). Или, например, "Deutschland über alles" (рефрен нарратива) и нацистская Германия (эгрегор).
Нарративы действительно бьются за субстрат - поэтому очень важно фильтровать идеи, которые мы думаем (позволяем им развиваться в нас). Они определяют нашу жизнь.
Не совсем так. Я использую DI через конструкторы в чистом JS. Без транспиляции вообще. Дело не в TS, а в транспиляции (любой). Если (когда) EcmaScript по своему синтаксису приблизится вплотную к TypeScript - я спокойно буду указывать типы в сигнатурах функций. Я так уже делал - в PHP. Там до версии 5 было всё то же самое, что в JS сейчас.
Но я когда-то писал код на Java под GWT и транспилировал его в JavaScript. Тогда-то ко мне и пришло осознание, что когда мы транспилируем один язык в другой, то их недостатки суммируются, а достоинства - нет. Так что тут дело не в синтаксисе TypeScript, а в транспиляции как таковой.
У меня довольно неплохо работал JSDoc в PhpStorm. Как оказалось, это PhpStorm довольно неплохо работал с JSDoc :) Я использовал и автодополнение, и навигацию по коду, и документирование во всплывающих подсказках. В общем всё, что мне давала типизация в PHP/Java. Но этот же самый код переставал обслуживаться "в самой популярной IDE для JS-мира". И это озадачивало.
Ответ, на мой взгляд, в том, что Microsoft не будет развивать один свой продукт (VSCode) в ущерб другому своему продукту (TypeScript). Не будет нативной поддержки JSDoc в VSCode от Microsoft. Даже если код написан на чистом JS, всё равно нужен файл jsconfig.json и запись "types": "types.d.ts" в package.json, если проект планируется использовать с VSCode (или с любым другим редактором кода с возможностью интеграции c tsserver по LSP). Если будет "другой хороший JSDoc-анализатор" с возможностью подключения по LSP, то у него будут свои правила (свой "jsconfig.json").
Ну а пока, да - придётся декларировать всё мало-мальски значимое в types.d.ts , чтобы tsserver мог это видеть.
Без JSDoc'ов анализ JS-кода вообще очень печален в любой IDE. А с JSDoc'ами анализатор IDEA очень даже неплохо с кодом управлялся. Может и похуже Java/JavaDoc, но точно не хуже, чем PHP/PhpDoc.
На самом деле, "информация без оглядки на её источник" не имеет совершенно никакой ценности.
Спросите в незнакомом городе любого человека "Как пройти к вокзалу?", затем пройдите чуток и спросите следующего. Вот вам пример работы с информацией "без оглядки на её источник".
Например, мнение профессионального сантехника о том, какую лучше купить арматуру для сливного бачка -- вполне ценное.
Если только он не сидит на проценте от конкретного магазина.
при этом у него, вероятно, нет причины меня обманывать.
Главная причина, по которой одни люди обманывают других людей в том, что вторые доверяют первым. Слово "вероятно" говорит о том, что ваше доверие обманывали.
А вот, пардон, ваше мнение в этом вопросе для меня ценности не имеет -- потому что о вашей компетенции в данной области я ничего не знаю, и соответственно, не имею никакой возможности оценить достоверность вашего сообщения.
Это совершенно нормально, если вы обращаете больше внимания на источник информации, а не на саму информацию.
опираясь на сложившееся у меня мнение о том, насколько вы авторитетны в качестве источника информации
Я уже говорил, что "отказ от авторитета источника знания" требует "постоянной работы по формированию своей собственной, персональной картины мира". Вы формируете свою картину мира, больше опираясь на авторитеты, я - больше опираясь на само знание. Но, по-большому счёту, это вопрос полутонов, а не выбора стороны.
Таким образом, у ученика формируется понимание того, что школьные знания -- не догма, а базис, который запросто может расширяться и изменяться по мере получения новых знаний.
... а Учитель - является источником правильного знания, который поможет сформировать правильную картину мира. А потом Владимир, не к ночи будь помянут, Соловьёв-Шапиро по телевизору раз в пару лет переобувается сам и переобувает всю свою аудиторию. Допустим, для вас Соловьёв-Шапиро не авторитет, но вот сантехник - авторитет, например. А это значит, что он может использовать свой авторитет в целях приведения вас к нужному ему выводу.
автор даёт нейронке пару тезисов, а она генерит из них несколько килобайт пространных рассуждений, смысла в которых не больше, чем в тех тезисах, из которых они сгенерированы.
Видите, это ваш опыт. А у меня опыт другой. Я даю нейронке на вход контекст на десятки тысяч токенов, а на выходе получаю результат в сотню-тысячу токенов (на порядки(!!) меньше). Поэтому я и хочу, чтобы вы не читали моих статей до тех пор, пока не станете готовы к такой подаче информации. Или даже вообще никогда, если вам это органически неприемлемо. Это будет на пользу и вам, и мне.
Мы вполне сможем существовать на одной площадке в параллельных пространствах и даже пересекаться на нейтральных темах.
Кстати - да! Механизм черного списка (y) Правда, он довольно таки неизвестная штука для широких масс. Ну, буду популяризовать по мере сил и возможностей :)
Да, я уже понял, что ваши вкусы несколько специфичны.
Механизм голосования на Хабре как раз и сделан для того, чтобы публично и сжато отражать реакцию аудитории ("вертухаев с вахтёрами", по-вашему). Но вашему сердцу "срач в комментах" милее, раз вы пришли на эту площадку и игнорируете этот её механизм.
Вы, конечно, можете фантазировать, что это не срач, но я, со своей стороны, вполне могу фантазировать, что это самый что ни на есть срач.
Как специалист, вы, возможно, вполне себе на уровне - я не в курсе. Но как человек социальный - такое себе. Тут я вижу. своими глазами - достаточно зайти в историю ваших комментариев.
Пока только не понятно, зачем вы общаетесь с людьми, которые вас раздражают, если у вас получается плохо? Тренируетесь? Тогда достойно уважения, в какой-то мере. Главное, чтобы вы росли над собой, а не получали удовольствие от этой девиации. Но это уже какая-то выгода, получается. Что близко к скотству, по вашем же словам.
Н-да, если вы и вправду всё делаете без выгоды, то, выходит, куда ветер в голове подул, туда и понесло. Надеюсь, что это вы так компенсируете свою мегацелеустремлённость в профессиональном плане (не можете же вы код вообще без оптимизаций писать).
В общем, не имею никакого желания общаться в вами ни по вашей специальности, ни вне её. У нас довольно сильно различаются жизненные ценности.
... и дать возможность скрывать в ленте такие публикации всем желающим
Вот это самое главное. Без этого работать не будет.
Но это уже только Хабр может прикрутить. Если решит, конечно же. Тут авторы уже бессильны.
А так-то читатель в своём праве выражать любым доступным ему способом своё нежелание видеть "нейрослоп" в своей ленте. Некоторых даже предупреждение будет бесить (что и доказал ваш эксперимент).
Я один не вижу смысла в этом тексте?
Это вопрос формулировок (модели ОС и её настроек).
Согласен.
Согласен.
Спасибо :)
Математики ближе всех подобрались к истине (объективности). Они могут через формулы видеть истину, которая одинакова для всех, вне зависимости от типов и настроек их собственных ОС.
Коллективы существуют, это реальность. С объективностью сложнее - это уже вопрос настроек персональной ОС. Я различаю "истину" и "правду". Истина одна для всех, но у каждого своя правда. Похоже, что истина персонально непознаваема, хоть и существует.
Абсолютно верно. Картину мира можно выстроить самостоятельно, но это будет очень скудная КМ. Даже у детей-магули, выращенных животными она богаче. Начальное образование - это фундамент, согласен.
Эмбеддинг - это вектор, рассчитанный по тексту. Он не привязан к человеку, он привязан к тексту. Это просто характеристика текста - его координаты в некотором многомерном пространстве смыслов (мерность зависит от модели, которая считает - 384, 768, 1536, 3072, ... координат). Можно смотреть на это пространство, как на библиотеку.
Так вот, эмбеддинг любого текста - это некоторый адрес этого текста среди всех полок, стеллажей, помещений, этажей, зданий, ... этой библиотеки. Изначально библиотека пустая, мы берём тексты, рассчитываем для них эмбеддинги и помещаем тексты в библиотеку.
Считается, что тексты, близкие по смыслу (токенам), будут находиться близко друг к другу. А это значит, что вне зависимости от принципов аналитики человека, если ему "зашёл" текст с некоторым адресом, ему высоковероятно могут также "зайти" другие тексты, находящиеся рядом. Другое дело, что они могут быть сильно похожи на то, что он и так знает. Это решается увеличением расстояния поиска от начальной точки (понравившегося текста).
Более того, если смотреть, с каких "полок" человек обычно берёт тексты ориентируясь на названия / аннотации / оглавления / предисловия, какие из них он потом читает - можно примерно представлять, зайдёт ли ему новый текст, попавший в библиотеку или нет.
Нормализуется не мышление человека, нормализуются тексты, которые он читает.
Судя по Вашему комменту, моя публикация фильтр прошла. Лестно.
Если я правильно понимаю, то разработка идёт путём создания цепочки таких папок (или замещении одной и той же по мере продвижения).
Вот это - выжимка LLM по основным папкам и файлам вашего подхода:
Такой вопрос: а где хранится целевой образ проекта в которым мы с агентами работаем? Описание того, что мы должны получить?
Это похоже на движение "отсюда и вперёд", а не "нам надо попасть туда".
Вы не можете хранить весь целевой образ проекта в одном файле
project.md- это размывает контекст для каждой рабочей итерации агента. Там можно хранить базовые, глобальные ограничители и инструкции, которые именно что нужны для каждой рабочей итерации агента.Если это про
openspec/changes/, то эта спецификация держит рамки изменения продукта. Рамки самого продукта в этом случае держит лишь код, который агент должен изменять. Со всеми вытекающими.Можно глянуть на результат?
По-идее, здесь должна помогать иерархия файлов AGENTS.md. По крайней мере Codex пытается выстраивать их в цепочку и создавать корпус инструкций, применяемых по текущему месту работы (нахождению модифицируемого исходника).
Для LLM важен контекст. Даже не так - важны плотность и однородность контекста. Если ваши 300 строчек правил противоречат друг другу, то модель не сможет следовать им всем одновременно. А вот как сделать так, чтобы для каждого исходника у агента был плотный и однородный контекст (причём для различных исходников и для различных сценариев модификаций этих исходников должен быть различный контекст) - вот это уже большой вопрос, на который у Spec Kit пока что ответа нет.
Почему "немедленно"-то? Как можно "немедленно понять", что именно хранится в дереве папок и файлов? Это как войти в супермаркет и немедленно понять, где лежит всё, что тебе нужно купить для сегодняшнего ужина, хотя в этом супермаркете ты в первый раз.
Может просто дать возможность самим "архитекторам и старшим разработчикам" этот план сгенерировать? По мне, так это делегирование ответственности за сгенерённый нейронкой слоп.
Я согласен, что спецификации должны быть частью проекта, если в нём задействованы llm-агенты, но доверять агентам самим генерировать спецификации, которые ты сам не понимаешь? Это зло.
Абсолютная правда! Я это как следует прочувствовал на этой статье.
Заплюсовал за идею - сам двигаюсь в подобном направлении. Но как практик хотел бы увидеть меньше нейрогенерёнки и больше кода или хотя бы скриншотов, на которых видна структура ваших спецификаций. По моему опыту в плоских файлах (типа
constitution.md) архитектуру проекта не описать - нужна иерархия каталогов и файлов в них. Так-то можно по коду распихатьAGENTS.mdи в них хранить спецификации и для/services/, и для/api/client. Мне нейронка выжимку по структуре сделала, но не уверен, что это именно то, что вы имели в виду.А вы попробуйте просто попросить LLM быть компактнее. Типа, а теперь то же самое, но в одном предложении. Они и в такое тоже умеют.
У вас есть собственная устойчивая картина мира - ей и пользуйтесь. Я дал вам возможность посмотреть на мир с моей точки зрения, вы - дали такую же возможность мне.
"Соловьёв-Шапиро" - это вот.
Да, это довольно интересная линия для размышлений. Эзотерики нечто подобное называли "эгрегором". Но в это понятие включался и носитель (человек, LLM), и нарратив. "Учение Маркса всесильно, потому что оно верно" - вот яркий пример нарратива ("Капитал") и эгрегора (СССР). Или, например, "Deutschland über alles" (рефрен нарратива) и нацистская Германия (эгрегор).
Нарративы действительно бьются за субстрат - поэтому очень важно фильтровать идеи, которые мы думаем (позволяем им развиваться в нас). Они определяют нашу жизнь.
Не совсем так. Я использую DI через конструкторы в чистом JS. Без транспиляции вообще. Дело не в TS, а в транспиляции (любой). Если (когда) EcmaScript по своему синтаксису приблизится вплотную к TypeScript - я спокойно буду указывать типы в сигнатурах функций. Я так уже делал - в PHP. Там до версии 5 было всё то же самое, что в JS сейчас.
Но я когда-то писал код на Java под GWT и транспилировал его в JavaScript. Тогда-то ко мне и пришло осознание, что когда мы транспилируем один язык в другой, то их недостатки суммируются, а достоинства - нет. Так что тут дело не в синтаксисе TypeScript, а в транспиляции как таковой.
У меня довольно неплохо работал JSDoc в PhpStorm. Как оказалось, это PhpStorm довольно неплохо работал с JSDoc :) Я использовал и автодополнение, и навигацию по коду, и документирование во всплывающих подсказках. В общем всё, что мне давала типизация в PHP/Java. Но этот же самый код переставал обслуживаться "в самой популярной IDE для JS-мира". И это озадачивало.
Ответ, на мой взгляд, в том, что Microsoft не будет развивать один свой продукт (VSCode) в ущерб другому своему продукту (TypeScript). Не будет нативной поддержки JSDoc в VSCode от Microsoft. Даже если код написан на чистом JS, всё равно нужен файл
jsconfig.jsonи запись"types": "types.d.ts"вpackage.json, если проект планируется использовать с VSCode (или с любым другим редактором кода с возможностью интеграции ctsserverпо LSP). Если будет "другой хороший JSDoc-анализатор" с возможностью подключения по LSP, то у него будут свои правила (свой "jsconfig.json").Ну а пока, да - придётся декларировать всё мало-мальски значимое в
types.d.ts, чтобыtsserverмог это видеть.Без JSDoc'ов анализ JS-кода вообще очень печален в любой IDE. А с JSDoc'ами анализатор IDEA очень даже неплохо с кодом управлялся. Может и похуже Java/JavaDoc, но точно не хуже, чем PHP/PhpDoc.
Не "безразлично", а "негативно". Такой крутой спец, а в обычную логику не силён.
Спросите в незнакомом городе любого человека "Как пройти к вокзалу?", затем пройдите чуток и спросите следующего. Вот вам пример работы с информацией "без оглядки на её источник".
Если только он не сидит на проценте от конкретного магазина.
Главная причина, по которой одни люди обманывают других людей в том, что вторые доверяют первым. Слово "вероятно" говорит о том, что ваше доверие обманывали.
Это совершенно нормально, если вы обращаете больше внимания на источник информации, а не на саму информацию.
Я уже говорил, что "отказ от авторитета источника знания" требует "постоянной работы по формированию своей собственной, персональной картины мира". Вы формируете свою картину мира, больше опираясь на авторитеты, я - больше опираясь на само знание. Но, по-большому счёту, это вопрос полутонов, а не выбора стороны.
... а Учитель - является источником правильного знания, который поможет сформировать правильную картину мира. А потом Владимир, не к ночи будь помянут, Соловьёв-Шапиро по телевизору раз в пару лет переобувается сам и переобувает всю свою аудиторию. Допустим, для вас Соловьёв-Шапиро не авторитет, но вот сантехник - авторитет, например. А это значит, что он может использовать свой авторитет в целях приведения вас к нужному ему выводу.
Видите, это ваш опыт. А у меня опыт другой. Я даю нейронке на вход контекст на десятки тысяч токенов, а на выходе получаю результат в сотню-тысячу токенов (на порядки(!!) меньше). Поэтому я и хочу, чтобы вы не читали моих статей до тех пор, пока не станете готовы к такой подаче информации. Или даже вообще никогда, если вам это органически неприемлемо. Это будет на пользу и вам, и мне.
Мы вполне сможем существовать на одной площадке в параллельных пространствах и даже пересекаться на нейтральных темах.
Кстати - да! Механизм черного списка (y) Правда, он довольно таки неизвестная штука для широких масс. Ну, буду популяризовать по мере сил и возможностей :)
Да, я уже понял, что ваши вкусы несколько специфичны.
Механизм голосования на Хабре как раз и сделан для того, чтобы публично и сжато отражать реакцию аудитории ("вертухаев с вахтёрами", по-вашему). Но вашему сердцу "срач в комментах" милее, раз вы пришли на эту площадку и игнорируете этот её механизм.
Вы, конечно, можете фантазировать, что это не срач, но я, со своей стороны, вполне могу фантазировать, что это самый что ни на есть срач.
Как специалист, вы, возможно, вполне себе на уровне - я не в курсе. Но как человек социальный - такое себе. Тут я вижу. своими глазами - достаточно зайти в историю ваших комментариев.
Пока только не понятно, зачем вы общаетесь с людьми, которые вас раздражают, если у вас получается плохо? Тренируетесь? Тогда достойно уважения, в какой-то мере. Главное, чтобы вы росли над собой, а не получали удовольствие от этой девиации. Но это уже какая-то выгода, получается. Что близко к скотству, по вашем же словам.
Н-да, если вы и вправду всё делаете без выгоды, то, выходит, куда ветер в голове подул, туда и понесло. Надеюсь, что это вы так компенсируете свою мегацелеустремлённость в профессиональном плане (не можете же вы код вообще без оптимизаций писать).
В общем, не имею никакого желания общаться в вами ни по вашей специальности, ни вне её. У нас довольно сильно различаются жизненные ценности.
Вот это самое главное. Без этого работать не будет.
Но это уже только Хабр может прикрутить. Если решит, конечно же. Тут авторы уже бессильны.
А так-то читатель в своём праве выражать любым доступным ему способом своё нежелание видеть "нейрослоп" в своей ленте. Некоторых даже предупреждение будет бесить (что и доказал ваш эксперимент).