Согласен. Истина - одна и она непознаваема, а правда - у каждого своя. Коллективная правда - это согласование персональных правд. Кто не согласовал, тот не член коллектива. Благо, большинство коллективов не требуют от своих членов максимального совпадения персонального "дома знаний" с коллективным. Довольствуются только фрагментами - охотничьи-рыболовные коллективы, актёрские труппы и киногруппы, семья, государство, работа, водители категории B, армия, школа и т.п. Один человек одновременно состоит в нескольких десятках или сотнях коллективов.
И в каждом коллективе, даже в коллективе из двух человек, присутствует согласование фрагментов "дома знания" каждого с некоторым эталоном (зафиксированным в виде текста, изустных правил, обрядов и т.п.).
"Передать знание" во всей его полноте невозможно, но согласовать фрагменты персонального знания с другими со-общниками - вполне доступно. Более того, очень сильно распространено. Например, человечество вполне успешно сгруппировалось в тех, у кого на дорогах в приоритете "помеха слева" и тех, у кого в приоритете "помеха справа". Есть также и другие группы - кому всё равно, кто не в курсе, что это, кто периодически переходит из группы в группу и т.д.
Знание можно описать (формализовать), а вот описания уже можно сравнивать. Математические формулы - вполне себе описание. Как и эмбеддинги (компактные числовые представления фрагментов знаний, удобные для машинного сравнения и поиска). То, что они не передают сами знания - ничего страшного. Эмбеддинги - это инструмент. Как координаты в пространстве. Широта и долгота получают смысл только с географической картой, без неё они - бесполезная абстракция.
Комментатор в целом пытается сказать следующее. Автор статьи, по его мнению, постоянно делает концептуальные подмены и «онтологические скачки»: выдаёт метафоры и инженерные модели (внимание как ресурс, эмбеддинги как «отпечаток смысла», метрики поведения как меру ценности) за строгие описания реальности. Он считает, что это следствие профессиональной деформации: вера в измеримость, алгоритмы и SMM завышает их эпистемический статус. Критик настаивает, что смысл субъективен, не редуцируется к формальным представлениям, а столкновение с «неподходящим» и даже неприятным контентом принципиально важно для мышления. Текст можно критиковать и отвергать, не считая его бессмысленным.
Ну, то есть, комментатор не согласен с позицией автора. Ладно. Спасибо за обратную связь.
P.S.
надо бы и к комментариям сжатие через LLM прикрутить - тоже полезно может быть.
«Думать, что 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) Правда, он довольно таки неизвестная штука для широких масс. Ну, буду популяризовать по мере сил и возможностей :)
Согласен. Истина - одна и она непознаваема, а правда - у каждого своя. Коллективная правда - это согласование персональных правд. Кто не согласовал, тот не член коллектива. Благо, большинство коллективов не требуют от своих членов максимального совпадения персонального "дома знаний" с коллективным. Довольствуются только фрагментами - охотничьи-рыболовные коллективы, актёрские труппы и киногруппы, семья, государство, работа, водители категории B, армия, школа и т.п. Один человек одновременно состоит в нескольких десятках или сотнях коллективов.
И в каждом коллективе, даже в коллективе из двух человек, присутствует согласование фрагментов "дома знания" каждого с некоторым эталоном (зафиксированным в виде текста, изустных правил, обрядов и т.п.).
"Передать знание" во всей его полноте невозможно, но согласовать фрагменты персонального знания с другими со-общниками - вполне доступно. Более того, очень сильно распространено. Например, человечество вполне успешно сгруппировалось в тех, у кого на дорогах в приоритете "помеха слева" и тех, у кого в приоритете "помеха справа". Есть также и другие группы - кому всё равно, кто не в курсе, что это, кто периодически переходит из группы в группу и т.д.
Знание можно описать (формализовать), а вот описания уже можно сравнивать. Математические формулы - вполне себе описание. Как и эмбеддинги (компактные числовые представления фрагментов знаний, удобные для машинного сравнения и поиска). То, что они не передают сами знания - ничего страшного. Эмбеддинги - это инструмент. Как координаты в пространстве. Широта и долгота получают смысл только с географической картой, без неё они - бесполезная абстракция.
Это GPT-выжимка по комменту:
Ну, то есть, комментатор не согласен с позицией автора. Ладно. Спасибо за обратную связь.
P.S.
надо бы и к комментариям сжатие через LLM прикрутить - тоже полезно может быть.
Я один не вижу смысла в этом тексте?
Это вопрос формулировок (модели ОС и её настроек).
Согласен.
Согласен.
Спасибо :)
Математики ближе всех подобрались к истине (объективности). Они могут через формулы видеть истину, которая одинакова для всех, вне зависимости от типов и настроек их собственных ОС.
Коллективы существуют, это реальность. С объективностью сложнее - это уже вопрос настроек персональной ОС. Я различаю "истину" и "правду". Истина одна для всех, но у каждого своя правда. Похоже, что истина персонально непознаваема, хоть и существует.
Абсолютно верно. Картину мира можно выстроить самостоятельно, но это будет очень скудная КМ. Даже у детей-магули, выращенных животными она богаче. Начальное образование - это фундамент, согласен.
Эмбеддинг - это вектор, рассчитанный по тексту. Он не привязан к человеку, он привязан к тексту. Это просто характеристика текста - его координаты в некотором многомерном пространстве смыслов (мерность зависит от модели, которая считает - 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) Правда, он довольно таки неизвестная штука для широких масс. Ну, буду популяризовать по мере сил и возможностей :)