Если бы лаконичность приносила кэшбэк, q‑разработчики уже покупали бы клавиатуры на сдачу. Но в эпоху LLM важно другое: не как мало символов мы нажали, а как уверенно модель понимает и продолжает наш код.
Сообщество q/kdb+ исторически любит «жать до предела»: одно выражение — и готова единичная матрица, одна операция — и целая трансформация. Проблема в том, что для LLM такая плотность — как скороговорка на бегу. В экспериментах модели объясняют компактные q‑конструкции с постоянными «погодите-ка» и пересборкой рассуждений, тогда как более развёрнутые записи разбирают ровно и без суеты. Даже в Python видно то же самое: «i += 1» информативно плотнее, но по перплексности заметно тяжелее, чем «i = i + 1».
Почему так? Подсказывает Шеннон. Если мы выражаем ту же информацию меньшим числом токенов (то есть «сжимаем без потерь»), средняя неожиданность на токен растёт. А при генерации LLM отсекaет маловероятные продолжения: чем выше перплексность, тем больше риск, что нужный токен просто не попадёт в «топ» и цепочка свернёт не туда. В коде это оборачивается блужданиями в объяснениях, хрупкостью при отладке и ошибками при расширении.
Отсюда практическое правило для q/kdb+: не заставляйте ассистента писать телеграммами. Дайте модели право на воздух — явные формы, разнесённые операции вместо хитрых комбо, понятные имена и комментарии. На сложных задачах добавляйте «думай по шагам» и «объясняй промежуточные выводы»: это растягивает смысл по токенам и удерживает когнитивную нагрузку в пределах, где модель стабильна.
Эстетика минимализма прекрасна, когда код пишет человек с контекстом в голове. Когда пишет LLM, выигрыш в читаемости для машины (и, внезапно, для команды) приносит больше пользы, чем экономия символов. Пусть краткость останется сестрой таланта, а надёжность — вашим продакшеном.