amarao

Люди учатся языку от окружающих. Человек слышит или читает грамматические обороты от других людей, и сам начинает их использовать. Те из них, которые удачны и понравились, остаются и становятся основой языка.

А теперь у нас появился специфичный AI-стиль текстов (особенно на английском), и люди всё больше ему подвергаются. Это и слоп (чисто негативное явление, которым пытаются накормить сайты и реддиты), и ответы LLM (скорее позитивное, чем негативное), и технические/формальные тексты, которые нельзя назвать слопом, но которые содержат в себе "LLM-стиль".

Недавно его назвали "token golf" (в отношении кода) - попытка выразить максимум за минимум токенов. Я думаю, оно применимо не только к коду, но и к языку (особенно этим страдает Клод).

Так вот, человек подвержен этому языку. Как именно он влияет на язык человека?

Я вижу несколько вариантов.

* никак. Самый маловероятный (столько воздействия и ничего?)
* адаптация (люди начинают повторять за LLM'ками грамматически). Этот вариант исходит из первго параграфа - люди повторяют те грамматические конструкции, которые прочитали.
* избегание. Лично я уже натрернировал свою аллергию на llm тексты, и если я их вижу в неожиданном месте, мне неприятно. Соответственно, если в своём тексте я вижу что-то отдалённо напоминающее llm-текст (с тем же "запахом"), я это ощущаю как неправильно и стараюсь исправить. В такой модели, если это широко распространено, будет, наоборот, отмирание оборотов, которые используются llm. Примерно как дворовая лексика. Все наслушаны, и все знают, что так не надо говорить.

И, наконец, самый вероятный вариант, это одновременное избегание и адаптация. Люди избегают насколько можно, но оно всё равно просачивается, просто потому что люди зеркалят, и наименее вопиющие формы остаются.

Бурные обсуждения - результат противления сторон.

Работа над CVD продолжается.

(Я его ещё толком не аносировал - замена молекулы без молекулярных прибабахов, возможно, в будущем, с поддержкой terraform -> ansible inventory и генерации kube.conf). Смотреть пока рано, так что даже ссылку не даю. CVD = create-verify-destroy.

И вот мне пришла в голову фантастическая идея по решению одного большого неудобства.

Проблема:

в нормальном режиме, когда мы создаём инфру, мы хотим подчистить её после тестов. Если что-то пошло не так у оператора, иногда мы хотим оставить инфру для отладки.

Обычно это делается с помощью --keep флага (или --destroy=never) и т.д.

Проблема с флагом состоит в том, что мы хотим сохранить именно эту сессию (вдруг нам не повезло в этот раз и повезёт в следующий? Будет грустно получить красный тест с destroy, а потом зелёный тест с --keep - пол-дня на воспроизведение).

Идея:

SIGUSR1 включает keep режим на ходу. Даже когда бежит ансибл или pytest, можно послать сигнал и оставить сетап живым.
SIGUSR2 аналогично выключает --keep режим на ходу.

Вторая идея: если упали тесты, известный sleep перед destroy, где можно нажать кнопку и отменить.

Третья идея: pre-signed links на которые можно послать "вкл/выкл" просто кликнув на ссылку в выводе CI сервера (не будет хорошо работать, если DNAT).

Четвёртая идея: во время sleep перед destroy, возможный поллинг внешнего ресурса на тему "удалять или нет?" (позвляет что-то сделать на внешней системе и сказать "не удаляй").

Я только что осознал ещё один fault domain при работе с LLM: violation of context locality.

Когда человек ковыряется в коде, его фокус обычно очень слоёно-углублённый (общее понимание что в целом, хорошее понимание текущей подсистемы, почти полное понимание модуля, полное понимание того куска с которым работает). Я понимаю, что можно заявить, что человек "ничего не понимает даже локально", но это всего лишь константа, на которую иерархия понимания умножается, а отношения между "всё в целом понимаю" и "хорошо знаю кусок с которым работаю сейчас" остаётся.

Если человек при своей работе сломал что-то далёкое, это обычно либо большая неудача, либо плохо организованный код. Мы стремимся изолировать куски кода, чтобы иметь возможность работать над обозримым.

И вот в эту картинку рабочего процесса врывается LLM. Хорошая LLM, astra, whatever. Которая вобрала в себя всё и одинаково хорошо понимает и этот кусок и соседний кусок и ещё другой соседний кусок.

Если произошла мискоммуникация между намерениями в коде и новыми изменениями, LLM может это заметить и подсветить. И тут, и там, и вот там, и вот там вот concern. Человек в такой ситуации понимает, что взял кусок не по рту и сдаёт назад, начинает делать осторожнее.

LLM же делает (правильно! но не правильно! мисскоммуникация) и поднимает 100500 concerns из разных доменов. Человек это либо игнорирует и делегирует llm разобраться (vibe), либо пытается понять. И вот тут-то начинает он Страдать, и чем тщательнее он думает, тем больнее он страдает.

Откуда страдания? От переключения контекста. Это принудительный мультитаскинг, на фоне которого вопрос от менеджера "ну как оно там?" отвлекающий от работы - это чистой воды умиление.

Это настоящий, самый страшный мультитаскинг, когда от человека ожидают peak competence в каждой подсвеченной проблеме. А каждая проблема со своим контекстом. И вот человек пытается это всё понять. А потом тут же понять. И снова понять. И снова. Это же невыносимая нагрузка, запредельная. Разумеется, человек ломается и впадает в vibe режим, либо ухватывается за маленький кусочек.

Мы долго ругали llm за то, что у них маленький контекст. llm отрастили контекст побольше. Помощнее. Их attention vector может придавить 20 человек насмерть своим размером.

Заметим, эта проблема одинаково болезненная как в plan стадии, так и в implement. Её нельзя решить с помощью лучших промптов или лучших скиллов. Это либо "поди сам разберись" (vibe), либо невыносимая нагрузка на человека.

Что делать? То же самое, что человек делает при знакомстве с большой кодовой базой большого проекта. Стремиться к локальности. Как? Не знаю. Очень чешутся руки сказать "делать как раньше делали и попроси llm проверить". Наверное, это не выход (нельзя игнорировать скорость и качество написания кода).

Значит, надо искать какой-то пограничный подход, который позволит человеку сохранять удобную для него структуру контекста. А вот как? (describe me problems with this idea within a human-comfortable context hierarchy... хаха, удачи с таким промптом).

Специальный класс доступности nine six.

(66.6666666%)

Наверное, сейчас это самая важная область самообучения. Не навык швырять 100500 агентов, а умение замечать плохое и останавливать вовремя. В человечьем коде у нас десятилетия умных людей (goto considered harmful!) и (у старшего поколения) собственные десятилетия факапов, чтобы понасмотреться на характерные неудачные паттерны).

С LLM - это новый дивный мир, который надо осваивать заново.

Вот, я только что обратил внимание на новый плохой паттерн, который я называю overscoping.

Хорошая фича планируется в pair planning между человеком и llm. Задача человека - выразить желание и форму того, что должно получиться, подстроиться под реальность. Задача llm - поймать проблемы, unsoundness. Может быть, даже, предложить решение. Но ни в коем случае не предложить фичу. Именно "предложить фичу" и происходит в overscoping, LLM под личиной помощи, на самом деле ухватывает вершки и додумывает за человека фичу, напихивая туда всё, что модно-благородно выглядит. Более холистик, более eloquent, более гладко, больше аспектов учтено (безопасность, масштабирование, лучшие практики, etc).

Включая то, что абсолютно нерелевантно. Потому что "что релевантно" знает человек.

(для любителей обговнякать всё - я исхожу из добросовестного инженера, любой текст можно превратить в бесполезность, введя некомпетентность в качестве исходного допущения в нужное местечко).

Итак, человек знает что "релевантно". LLM подсвечивает противоречия (иногда критически важные - такие штуки вызывают "wow, оно меня поняло и остановило от большой ошибки"), поднимает concerns.

Но это в идеальном мире. В реальном LLM тупо херачит всё это, включая concerns, которые не concerns.

А ведь каждая из них - незапрошенный requirements, который осложняет фичу.

Мы все привыкли к тому, что kamehameha в коде (множественные вложенности на if'ах) - это зло и антипаттерн. Этому даже если хорошее умное описание про избыточную вариативность, цикломатическую сложность, про необходимость поддерживать инварианты или идентифицировать properties и т.д.

Так вот, незапрошенный requirement - это как if, но в дизайне фичи. Даже не один. Это +1 элементу матрицы (т.е. если у нас была матрица 2х3x4 проблемы, дополнительный +1 - это не 2х3x4+1, это (2+1)x3x4, то есть катастрофа.

overscoping - это засовывание дополнительных requirements, потому что человек упустил это. Оно попадает в документы, потом его невероятно тяжело изживать.

И вот это анти-продуктивный момент. Вместо того, чтобы думать о фиче, человек думает о не-фиче, о лишнем мусоре, который надо изничтожать.

Это невероятно тяжело. Это тяжелее, чем писать самому.

Вот почему я перестал давать это LLM. Я пишу, оно предлагает/ссаными тряпками меня гоняет. Я исправляю.

Получаются куцые не eloquent, не fluent texts, но по делу. Даже так - я могу дать llm написать разок, но читаю я это по диагонали и сношу всё к чертям.

Всё - важно. забыл снести что-то, что выглядит как разумное уточнение - получил проползшее требование.


... И ещё.

Лучше неполные требования, чем избыточные полные.

Ожидаемое качество ниже, чем вывод от LLM - wow, обалдеть как хорошо.

Ожидаемое качество выше, чем вывод от LLM - миллион криков боли о том, как людям приходится заставлять людей заставлять LLM делать лучше, чем LLM сама делает.

Отдельный класс людей, которые согласились с качеством LLM и надеются, что оно не станет хуже по мере того, как проект оказывается покрыт слопом.

The art of carving production code from raw slop is a new art and is worth learning.

Или, перефразируя,

“I simply remove everything that is not production from LLM output.”

Самые дорогие у человека - thinking tokens. Вторые по цене - ingestion. output tokens дёшевы, особенно, если на них не были потрачены thinking или ingestion токены.

Перевожу на русский: Сложнее всего - думать. Следующее по сложности - внимательно слушать. Говорить, особенно не думая, легко.

Ходить читать за LLM унизительно и неприятно.