amarao

Имя даёт силу над тем, чьё имя ты знаешь. В ожесточённой технической дискусии, кто первый нашёл удачное имя, тот и задал нарратив. Вырваться из thick concepts имени почти невозможно, и если предложенное имя прилипло (используется другими), победа в дискуссии почти обеспечена.

Урсула была почти права про истинное имя. Она была неправа, что эта штука существует объективно. Её придумывают. Кто придумал - того и тапки. С другой стороны, в её книге всё уже названо давным-давно...

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

Так что написать ещё раз было проще. Реально проще. NIH (not invented here) синдром, традиционно считается плохим; в большинстве случаев, "написать своё" - плохая идея, особенно, если это не новая уникальная задача или не странная комбинация требований.

Но всё меняется... Код становится дешёвым, и думать о том, "писать или нет" нужно не с точки зрения "сколько нужно потратить на написание", а с точки зрения, что лучше, ещё одна зависимость, или локальное сопровождение.

По мере того, как написание кода будет становиться всё лучше и дешевле (а оно будет, open-модели уже пишут терпимо, и будет ещё лучше, поскольку SOTA показывают куда идти), очевидно, что баланс между NIH и "ещё одной зависимостью" будет становиться всё более с перекосом в сторону NIH. Причин, помимо "дешёво и просто" много. Во-первых любая фича за ваш каприз. Во-вторых, минус огромная головная боль с сопровождением зависимостей. Security становится лучше (аргумент: сейчас модно искать 0-day с помощью LLM'ок, когда это станет не только модно, но и полезно, аудит локального кода будет рутинной процедурой, и локальность кода упрощает проблему), меньше возни с трекингом изменений.

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

А следующий этап - software on demand, то есть "под задачу". Сейчас оно звучит ещё странно и vibe'ово, но если посмотреть, что делают LLM при исследовании проблемы - они же пишут сниппеты на питоне для анализа. То же самое можно и с более крупным софтом. В ответ на запрос пользователя (допустим, в рамках фантастики ближнего полёта) "хочу синкать батареи у панелей синкать с батарей у машины, так, чтобы панельки побольше работали" будет написан софт, который именно это и делает. С конкретными моделями машины и панели (будет новая машина - "поправь, чтобы и с Jomdong работало"), без какой-либо далёкой перспективы, но будет.

И вот очень интересный момент будет, когда количество начнёт переходить в качество (или его отсутствие). Одна софтинка да, две да, но если у нас взаимодействие software on demand, которое общается с software on demand, которое что-то делает с данными из другого software on demand, вот тут вот что-то интересное уже начинает проклёвываться.

Точно ли `import json`, или можно просто дописать парсинг json'а на месте? А runtime нам нужен? А операционная система?

А что, если железо будет таким простым и таким специфичным (больше не надо legacy и совместимость), что софт под него проще писать с нуля каждый раз?

... А что, если и железо?

Чем больше я думаю про эту мысль с реддита, тем больше я понимаю, что это жестокая правда.

Человек, который заменил физический труд на офисную работу должен ходить в зал (или иметь достаточно физически-активное хобби). Обязательно, medical requirement. Потому что машины взяли на себя всю тяжёлую фическую работу, так что человек получает гиподинамию и должен с ней бороться.

Человек, который заменил ментальный труд на понукание ai'кой должен заниматься программированием вручную, ноль помощи AI (кроме линтеров и ревью, аналог тренажёров в зале). Потому машины взяли на себя всю тяжёлую программистскую работу, так что человек получает гипологию (я долго выбирал между αποφασίζω и νομίζω, выбрал λογάω, как близкое к общеизвестному "логос").

Цель? Поддержание мозга в тонусе, well-being, возможность побыть наедине со своим мозгом, почувствовать его сильные и слабые стороны.

Добро пожаловать в новую реальность.

Я пока не решил, что лучше, взять себе тихонько продакшен-задачу с низким приоритетом и решить её самому, или leetcode-style вещи. И у того и того есть определённые плюсы. Или хобби-проект? Я немного опасаюсь хобби-проектов, потому что это project management, совершенно не "хобби" проблема и вполне себе работа которой и на работе хватает... Может быть, PR'ы в opensource проекты? Строго без AI, потому что это как трейл. Можно на машине и быстрее, но фан-то не в этом...

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

В стародавние времена, до Интернета (ага, я помню!) одной из проблем было то, что как бы хорошо не был сформулирован вопрос, было не понятно, кому его задавать. Чем сложнее вопрос, тем меньше шансы найти человека, который мог бы ответить. Альтернативой было делать полное исследование, "найди ответ сам", по книгам или просто самостоятельно. Главной проблемой в этом был не объём работы, а необходимость обрабатывать чужой контекст в огромных объёмах, при этом не забывая свой собственный вопрос. Ну, как если бы кто-то задался вопросом "а можно ли перехватить панику в Rust'е?" и начал бы искать ответ с учебника по теории компиляторов. В теории, ты получишь ответ, но ценой такого объёма нового всего, что вопрос становится пренебрежимо мал в сравнении с тем, что узнаешь. (негативный перфекционист в этом месте как раз скажет, что так и надо, мол, много выучишь). Это делало стоимость вопроса запретительно высокой.

Интернеты времён web1 (статические веб-сайты) сделали процесс поиска несколько проще (не надо топать ножками в библиотеку и не надо читать-читать-читать, ведь есть контекстный поиск), но суть того, что ради вопроса надо вобрать в себя океан, осталась. В каком-то смысле стало даже больнее, потому что скорость увеличилась, а вот объём того, что нужно прошерстить стал больше, и он стал более дёрганный - нашёл ты упоминание про панику, но все слова вокруг непонятные, и их как-то надо запоминать и читать про них "в обратном порядке".


Интернеты времён web2 (интерактивное, форумы и т.д. - я передёргиваю, т.к. форумы были и на cgi-bin с тем же успехом...), вместе с фидо, принесли возможность задавать вопросы "в толпу", авось кто-то ответит. Это был гигантский прорыв, потому что можно было просто задавать вопрос. Цена вопроса упала на порядки, всё, что ты должен сделать, это сформулировать хороший вопрос (в сравнении с "вобрать в себя 10 учебников"). Но в замен тебе прилетало что-то, полное любви, уважения, внимания к заданному вопросу и прочие неоценимые достоинства перемножения интернет-культуры на русскую культуру, где в первую очередь тебе объяснят, почему тебе это не надо, а во вторую, что ты всё делаешь не так. Т.е. цена вопроса стала ниже, но всё равно трудно. Плюс шанс, что никто ничего не ответит. Привет, SO, +10 лайков к вопросу, ноль ответов.

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

Это приводит к изменению глубинной модели, когда вопросы не "копятся" (как было раньше), а когда их можно задавать прямо тут и сейчас, главное, ловить нотку "о, вопрос" и не лениться потратить эти 30 секунд.

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

Идеальная ситуация выглядит так:

* Важная задача, которая оправдывает затраты, достаточно долгая, чтобы имело смысл инвестировать в понимнаие.
* Умеренный дедлайн, чтобы было время на то, чтобы хорошо прочитать/подумать/спросить/попробовать/понять.
* Достаточно большой интервал времени под кусок задачи, с запасом на recovery (то есть не прыгать тут же в следующую задачу).
* Предметная область, в которой наработано много, чтобы было во что онбордиться, и в которой есть хорошие практики, к которым стоит идти (в некоторых областях есть хорошие практики как выживать, и это не то, что очень хочется изучать - лучше от такой области отойти).

Как-то за грандиозными облаками и AI'ками забылась простая история с администрированием локалхоста (своей собственной машины). Кажется мелочь, ерунда, но иногда оно пушает в область high-end administration.

Давным-давно, в другой стране, в другом политическом режиме, на ядре 2.6.18 на дистрибутиве Debian Etch я сделал файловую систему для ценных данных. Я выбрал в качестве файловой системы xfs, потому что на тот момент был вайб, что xfs хорошо подходит для больших объёмов с крупными файлами. Эта файловая система жила на raid1 поверх LVM, пережила несколько увлекательных приключений (включая исчезновение одной из PV в середине копирования), сменила несколько мажорных версий ядра, почти с десяток дистрибутивов (Debian etch -> Sid/Forky), неизвестное количество поколений процессоров, дисков и т.д.

И вот, случилось. 6.18 (иронично, 2.6.18 -> 6.18) отказывается монтировать эту файловую систему, ибо v4, а надо v5. Migration path нет. Шринка xfs не поддерживает. И это самая большая файловая система на моей машине.

Вообще, в моей машине осталось всего 4 блочных устройства: nvme, ssd и парочка жёстких дисков в raid1, и вот эта файловая система живёт на vg из двух жёстких дисков, размером 2ТБ (HDD 2x4TB). 2ТБ больше, чем любая другая VG на моей машине.

Пока что я откатился на 6.17 и имею доступ к файловой системе, но пришло время миграции. После долгих раздумий я решил отказаться от linux-raid и перейти на btrfs-raid, потому что btrfs способна выбрать правильную копию когда данные с обоих дисков рейда различаются, а linux-raid нет, т.к. не имеет чексумм. В новой файловой системе я буду использовать, наверное raid1+dup для метаданных и raid1 для данных.

Всё осложняется тем, что я не могу использовать LVM для btrfs, т.к. lvm поверх raid, а я хочу raid разобрать.

Мой план:

1. Прогнать long smart selftest на обоих дисках (по-очереди)
2. Сделать checking для рейда.
3. Вывести один диск из рейда, перевести рейд в linear.
4. Выведенный диск сконвертировать в новую VG, сделать LV, сделать btrfs (dup, no raid).
5. Скопировать всю файловую систему (rsync).
6. Поменять профиль btrfs на raid1
7. Оставшийся диск во вторую VG, аналогичную LV, добавить в btrfs
8. Запустить rebalance.

(отвечая на вопросы: бэкапы частично есть, частично нет и не будет, ибо жирновато для некоторых видов данных).

Вот такие вот будни localhost'а.

Меня заставляют использовать Claude, а я предпочитаю Codex.

Claude очень misaligned. Он всегда что-то подприсовывает. Ему говорят "поправь в модуле таком-то", он поправляет всюду. Ещё он туповат, то есть вместо того, чтобы вкопаться в суть проблемы, он шлёпает квадратно-гнездовое, срезая углы всюду, где можно.

Codex куда более crispy. Он точно следует инструкциям, хорошо понимает намерение через неточную формулировку, и больше думает вглубь.

Ещё Сlaude невероятно дорогой. За 20 баксов я получил у кодекса практически анлим (я понимаю, что эншитификация yet to come, но пока что я ни разу ниже недельного 50% usage не падал), у клауди за 20 баксов можно пару дней очень аккуратно поработать и всё.

Ещё codex каким-то волшебным образом (умная компактификация? subagents?) умудряется расходовать контекст очень экономно. В одном чате можно долго вести проблему и контекст тратится только на общение (и "обозревание" кодовой базы). А claude каждая мелкая опечатка - сожжёный контекст.

План на 2026: переехать с grep на ripgrep.

Нет, это не маленькое изменение, это перестройка куска фундамента.

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

Вместо этого оно существенно повышает качество. Наверное, это тихая революция в software engineering, потому что количество найденных идиотизмов и ошибок зашкаливает. Через несколько лет, когда ai-reviewed код начнёт составлять ощутимый процент от общей кодовой базы мы начнём видеть синергентический эффект этого. Что-то поменяется (если к тому времени AI не перепишет всё к чертям, во что я не верю).

Оно повышает не лучшее качество, оно повышает худшее качество. Миллион глупостей остающихся в коде, документации, ранбуках и т.д. внезапно оказываются хотя бы частично исправлены.

Что исправляет больше ошибок? Система типизации или AI? AI ловит ошибки совершенно недоступные для системы типов и линтеров, включая логические ошибки и ложные посылки.

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

Новое поколение человеков куда более подготовленно к потиранию ламп. Мы хорошо знаем, что плохо сформулированное желание ведёт к галлюцинационным результатам и слопу.

With a great power comes great "it's not me, it's bug in the script".