Ну по моему опыту даже с описанными требованиями всё равно LLM не хуже. Грубо говоря, в умелых руках LLM явно добавляет производительности. Соответственно, хорший джун будет использовать LLM (нет ни одной причины не использовать). А далее вопрос в том, какую прибавочную стоимость он создаёт для вас, учитывая, что вы и без него можете использовать LLM. С моей точки зрения, человек, который создаёт прибавочную стоимость в таких условиях уже не совсем джун.
Вот я чего-то в последнее время хожу по похожим веткам и оставляю похожие комментарии. Вы со своим опытом, как бы мягче выразиться, далеко оторвались от земли и, быть может, позабыли, куда меньше-то. Сочетание "индусский код" не про LLM придумано, и явно не про хайлоад и многопоточность. То, чего вы хотите, возможно, совсем не космос, но совершенно за пределами средних талантов средних выпускников. Это уже всё специализация, знания, опыт.
Не, это чит :) Мидла и я умею. Представьте себе вот настоящего сферического выпускника в вакууме, для которого это ну чуть ли не первая профильная работа. С моей колокольни он по любым критериям уступит агенту. Да, конечно, выпускник под грамотным руководством может вырасти так, как агент не вырастет, но, может, у меня и нет такой цели. Может, у меня есть цель как раз отдать на аутсорс ровно те задачи, которые решать мидлу-сеньору и неинтересно. И вот эта ниша имхо с рынка труда вообще исчезает как класс.
Посмотрите на это с другой стороны. Проблемы с производительностью, случаи потери данных, время отклика, плохая архитектура -- это всё ответственность тимлида, ну или хотя бы мидла. Теперь представьте, что вы вот такой тимлид или мидл. Зачем вам вообще нужны джуниоры? Хотя бы в количестве одной штуки? Они пишут код плюс-минус не лучше Клода, точно так же косячат с архитектурой и производительностью, но работают гораздо медленее, очень многого в принципе не знают, требуют значительных усилий на babysitting ну и так далее. Можно обсуждать что там происходит на рынке глобально, но вот этой ниши, на мой взгляд, так просто теперь не существует. Ну разве что давать им задачи, где требуется ручной контроль (кнопки чтобы аккуратно расставлены были) и ручное же тестирование.
Ну так и здесь не Chat-GPT заявил, а OpenAI. Конечно, к ним априорного доверия меньше, но всё же не Пупкин. Короче говоря, если бы я был журналистом-новостником, пропустил бы. К какому-нибудь Трампу ещё меньше доверия, но всё, что он говорит, в ленты попадает.
Ну вы неоправданно задираете планку. Все слышали о том, что Перельман "вроде как" доказал гипотезу Пуанкаре ещё до того, как доказательства были более-менее верифицированы. На проверку доказательства теоремы Ферма тоже ушло немало времени, там даже ошибку нашли и не без труда исправили. Так что вполне себе инфоповод, по крайней мере, в русле традиции.
Мне кажется, что абсолютно все такие статьи пишутся людьми, которые сами ежедневно руками кодят, и все претензии можно свести к формуле "я пишу лучше, чем coding agent". С этой точки зрения всё понятно: есть вариант написать самому хорошо, либо, вероятно, с помощью агента побыстрее, но результат будет во всех отношениях хуже.
Если выйти на уровень менеджера или тимлида, то ситуация выглядит уже совсем иначе: я не пишу код, но под моим началом работают люди, которые пишут, а моя задача -- обеспечивать приемлемое качество и соответствие срокам. И вот при таком раскладе уже вовсе неочевидно, что агент справляется хуже среднего программиста. Фраза "индусский код" не про LLM придумана. Джуниор (и не только джуниор) тоже может неделю чего-то ваять и так ничего и не наваять.
Мне кажется, что вот таким фрустрирующим профессионалам стоит задуматься не о качестве агентов, а о качестве процессов. В небольшой компании достаточно иметь сильную команду, и на выходе явного шлака не получится. Но эта система не маштабируется: невозможно рассчитывать, что все вокруг талантливые, знающие, опытные и аккуратные. Но можно попытаться настроить конвейер так, что даже если на линии оказался не самый надёжный работник, сама система не позволит получить на выходе негодный продукт.
И ведь ничего концептуально нового тут нет: спецификации, code review, тестирование, метрики. Многое из этого мы не делали не потому, что мы не верим в подход, а потому что банально не хватает сил. Я доверяю Васе, шут с ним, с code review, Вася дичи не напишет. Если Петя сказал, что протестировал, не буду требовать автотестов в репозитории, чего уж там. А теперь это всё нагенерировать не очень обременительно, так что почему бы и нет.
В общем, для себя я сделал вывод, что надо полировать конвейер.
Автор этой статьи борется с какими-то просадками на наносекунды тут и там в то время как 95%+ софта пишется на на каком-нибудь Электроне. Всё, что описано в статье, совершенно разумно, но это уже какое-то выжимание последних капель, которое имеет смысл, если всё остальное сделано -- от алгоритмических оптимизаций до кастомных аллокаторов памяти.
В ООН порядка 200 стран, и безо всякого лампового социализма легко выбрать кучу такиих пар, где простолюдины первой страны завидовали бы простолюдинам второй. И ничего не меняется вообще, то есть эмпирически концепция не работает. Дальше уже можно рассужать, почему, но так или иначе, реальность такова.
Его очень трудно осмыслить, потому что автор ведёт себя так же, как и те, кого он критикует. Тут очень много соображений, которые подаются как данность (начиная от того, что никаким перераспределением денег и ББД проблему не решить и кончая тем, что к Кремниевой долине не читали Лакатоша и Фейерабенда), а если автор чего и пытается доказывать, то делает он это ссылкой на авторитет, как будто бы работа того или иного философа есть божественное откровение и истина в последней инстанции.
Очень много эмоций и необязательной критики тех, кто автору не нравится. Противоречия, которые уже подметили выше ("AI всех выкинет на улицу" а через пару абзацев "AI не может заменить людей"), а в конце всё равно какие-то несвежие идеи, типа давайте дадим больше контроля над технологиями людям а не корпорациям -- окей, но если технология меня заменит, а ББД всё равно "не работает", что радости с того, что технология в руках общества?.. Короче говоря, проблемы поднимаются понятные, но уровень дискуссии удручает.
Да, ситуация понятна, ну мы все живём "в процессе", и у меня нет твёрдого мнения по этому вопросу. Моя интуиция состоит в том, что концептуально правильно разделять этапы планирования и разработки, а каждая задача должна оставлять за собой некие осязаемые артефакты -- код, документацию, юнит-тесты. Разделение на планирование и код -- это такое же разделение, как на "багфикс", "рефакторинг", "новая функциональность". Вроде нет сомнений, что нехорошо в одном коммите совмещать багфикс и новое, но при этом превратить два предложения текста в три страницы кода через "магию" в голове -- как бы ок.
В принципе, тут же нет ничего нового: скажем, в TDD вы тоже по идее заранее пишете тесты (они же спеки по сути), а потом уже код. С другой стороны, многие классические рекомендации даются не потому, что они оптимальны, а потому что иначе нереалистично. Скажем, вы можете просить LLM делать себе код ревью хоть три раза в день, но коллега этого делать не будет.
Кроме того, разные этапы можно делать разными системами с разной ценой, если хочется сэкономить.
Признаться, я не читаю всё, что генерирует openspec. Я читаю хотя бы tasks.md (то есть чеклист) и общее описание design.md. Выгода (как мне кажется, на истину не претендую опять же) в том, что 1) после завершения работы только небольшая часть этого текста становится проектной документацией, вы получаете её бесплатно, и дальше при решении других задач LLM может читать документацию, а не лопатить сразу код (что опять же по идее должно экономить токены); 2) иногда в процессе работы LLM начинает автоматически жаловаться, что какой-то кусок кода не соответствует спецификации, а это сигнал -- надо перепроверить и исправить либо документ, либо код.
Глобально, помню, в какой-то книге было сказано, что если вы говорите, что не используете какую-то "методологию программирования", то вы просто не знаете, как она называется. Можно подходить к процессу по-разному, но надо отдавать себе отчёт в том, что конкретно происходит. Если у вас немного людей, и вы все на одной волне, может, и вправду незачем разжёвывать -- и так каждый понимает друг друга с полуслова. Но надо чётко осознавать особенности сетапа -- у кого-то так, у кого-то не так.
Скажем, мне комфортно думать в процессе письма, вот как сейчас. У меня есть коллега, который с ChatGPT общается голосом. Для меня это нонсенс, я не могу говорить и при этом думать. Но для него комфортно, что ж.
Я бы сказал, что это разумная критика, но она сама по себе настолько в общих чертах сформулирована, что непонятно, соглашаться или спорить. Дьявол в деталях.
С одной стороны, если я даю абзац текста подчинённому, и он пишет целую подсистему, я по сути уповаю на то, что он достаточно опытен, и у него в голове "логика, контекст и знание предметной области" совпадают с моими. На практике это поучается методика plug and pray, ну ок, небесспорно.
С другой стороны, "более подробными" по сравнению с чем? Очевидно, что английский текст не должен приближаться к Питону по объёму, но точно так же очевидно, что какие-то технические решения должны быть либо частью постановки задачи, либо запротоколированы уже после реализации, чтобы было понятно, что вот эта штука оптимизирует память, а не скорость, или наоборот, и так оно задумано.
Для меня очевидно, что три строчки текста из issue в качестве описания подсистемы явно мало. С другой стороны, конечно, надо избегать крайностей.
Ну я не вижу тут больших противоречий. В openspec описания полного устройства и не ожидается, всё по канонам agile. В идеале есть документ, который описывает общие принципы (используется такой-то фреймворк, такие-то архитектурные решения), и есть описание требуемой задачи, по сути github issue. А по мере закрытия задач растёт проектная документация.
Смотрите, даже если вы пишете небольшую функцию, которая у вас занимает 3 часа, всё равно вы отдельно её продумываете, и отдельно программируете, не так ли? И если что-то работает не так, у вас хотя бы в голове же есть картина -- проблема в постановке задачи или в реализации.
Соответственно, вы пишете спеку и по ней программируете задачу, потом следующую и так далее. Но на практике так никто не делает не потому, что это концептуально неправильно, а потому что нереально.
Но с появлением LLM это стало реально. Я сейчас почти все задачи для LLM прогоняю через OpenSpec, крому ну уж совсем мусорных на выброс. Я ему даю описание задачи (фактически github issue), дальше он генерирует несколько документов -- развёрнутое описание того, что надо сделать и чек-лист, он же "definition of done". Дальше запускается процесс, и если всё проходит хорошо, краткая выжимка этого всего (что конкретно сделано) становится частью документации проекта.
Ну вот за spec driven dev буду стоять - если бы было время и силы, в идеале разработка так бы и выглядела даже без всяких LLMs. Отделить планирование от кодирования - совершенно разумная цель, и очень хорошо, что её стало проще добиться.
Я понимаю эту логику, но рано или поздно мы всё равно упираемся в интуицию и наше восприятие. Исходная статья Вигнера называется "unreasonable effectiveness..." -- то есть оба слова апеллируют к нашей оценке: что такое (un)reasonable и что такое effective.
Это не баг и не дыра в логике. Это послание от человека к человеку: вот смотрите, мы на трёх буквах на своей планете можем кучу всего сделать, а можно себе вообразить обстоятельства, при которых понадобилось бы десять букв, причём для каждого раздела науки они бы работали по-разному. Удивительно? Ну а дальше собеседник, конечно, может сказать, что неудивительно. Ну ок :)
Я не вижу тут особых дыр. Вы говорите, что классическая физика ломается на абсолютном нуле или на температуре внутри звезды, или есть какие-то явления, которые мы не понимаем. Хорошо, Вигнер и не говорил, что мы понимаем всё, и что формулы работают на любых краях.
Он говорит: камни, о которых писал Галилей, падают одновременно не только в Пизе, но и везде на планете, и не только во времена Галилея, но и до сих пор. И неважно, идёт дождь или снег, в комнате мы или снаружи. Ну и далее идут рассуждеия о том, что одни и те же формулы по сути кочуют из одного раздела науки в другие.
То есть в опытах Галилея можно варьировать самые разные условия -- массу, географическую локацию, сезон, и оказывается, что эти вариации ни на что не влияют. Да, можно сказать, что это всё "локально работает", а внутри чёрной дыры не работает, но это рассуждения из стиля "стакан наполовину пуст": сравните с с цифровым миром, где вообще никакой локальности нет. В компьютерной программе можно поменять одну строку, и всё, она будет работать совсем по-другому.
Таким образом, Вигнер предлагает удивляться тому, что наука вообще работает хотя бы на каких-то масштабах и что нам в принципе удаётся перебрасываь мостики из одного раздела знаний в другие. И если эту точку зрения критиковать, надо апеллировать не к локальности и субъективности, а попробовать рассмотреть противоположный тезис: "нет ничего удивительного, что законы Галилея работают до сих пор, нет ничего удивительного, что одни и те же формулы повторяются..." Как-то так.
Мне кажется, вы излишне придираетесь. Используя ньютоновскую физику вы можете построить самолёт, который взлетит и пушку, которая стреляет куда надо. Вигнер в своей статье не пытался давать математических оценок. Он говорит ровно это: вот смотрите, вы можете с помощью простых формул делать практически пригодные предсказания на очень широком диапазоне явлений. А ещё одни и те же формулы практически без изменений можно переиспользовать, например, если считать, что газ состоит из "шариков", а средняя скорость шариков -- это температура, то можно из механики вывести термодинамику, хотя, казалось бы, где связь? Наверно, если хочется, можно переформулировать как "на человеческом масштабе всё на всё похоже и нехитро устроено", но даже в такой постановке это равно нетривиальное наблюдение.
Окей, забудем про голову, сам факт что банальное перемножение ma даёт формулу для F достаточно точно работает для объектов от молекул до планет уже весьма нетривиален. Почему так? Мы ведь знаем, что она неточна, есть квантовые и релятивисткие эффекты. А представтьте себе, что нам была бы нужна отдельная формула для F для массы через каждые 100 кг, например.
Ну по моему опыту даже с описанными требованиями всё равно LLM не хуже. Грубо говоря, в умелых руках LLM явно добавляет производительности. Соответственно, хорший джун будет использовать LLM (нет ни одной причины не использовать). А далее вопрос в том, какую прибавочную стоимость он создаёт для вас, учитывая, что вы и без него можете использовать LLM. С моей точки зрения, человек, который создаёт прибавочную стоимость в таких условиях уже не совсем джун.
Вот я чего-то в последнее время хожу по похожим веткам и оставляю похожие комментарии. Вы со своим опытом, как бы мягче выразиться, далеко оторвались от земли и, быть может, позабыли, куда меньше-то. Сочетание "индусский код" не про LLM придумано, и явно не про хайлоад и многопоточность. То, чего вы хотите, возможно, совсем не космос, но совершенно за пределами средних талантов средних выпускников. Это уже всё специализация, знания, опыт.
Не, это чит :) Мидла и я умею. Представьте себе вот настоящего сферического выпускника в вакууме, для которого это ну чуть ли не первая профильная работа. С моей колокольни он по любым критериям уступит агенту. Да, конечно, выпускник под грамотным руководством может вырасти так, как агент не вырастет, но, может, у меня и нет такой цели. Может, у меня есть цель как раз отдать на аутсорс ровно те задачи, которые решать мидлу-сеньору и неинтересно. И вот эта ниша имхо с рынка труда вообще исчезает как класс.
Посмотрите на это с другой стороны. Проблемы с производительностью, случаи потери данных, время отклика, плохая архитектура -- это всё ответственность тимлида, ну или хотя бы мидла. Теперь представьте, что вы вот такой тимлид или мидл. Зачем вам вообще нужны джуниоры? Хотя бы в количестве одной штуки? Они пишут код плюс-минус не лучше Клода, точно так же косячат с архитектурой и производительностью, но работают гораздо медленее, очень многого в принципе не знают, требуют значительных усилий на babysitting ну и так далее. Можно обсуждать что там происходит на рынке глобально, но вот этой ниши, на мой взгляд, так просто теперь не существует. Ну разве что давать им задачи, где требуется ручной контроль (кнопки чтобы аккуратно расставлены были) и ручное же тестирование.
Ну так и здесь не Chat-GPT заявил, а OpenAI. Конечно, к ним априорного доверия меньше, но всё же не Пупкин. Короче говоря, если бы я был журналистом-новостником, пропустил бы. К какому-нибудь Трампу ещё меньше доверия, но всё, что он говорит, в ленты попадает.
Ну вы неоправданно задираете планку. Все слышали о том, что Перельман "вроде как" доказал гипотезу Пуанкаре ещё до того, как доказательства были более-менее верифицированы. На проверку доказательства теоремы Ферма тоже ушло немало времени, там даже ошибку нашли и не без труда исправили. Так что вполне себе инфоповод, по крайней мере, в русле традиции.
Мне кажется, что абсолютно все такие статьи пишутся людьми, которые сами ежедневно руками кодят, и все претензии можно свести к формуле "я пишу лучше, чем coding agent". С этой точки зрения всё понятно: есть вариант написать самому хорошо, либо, вероятно, с помощью агента побыстрее, но результат будет во всех отношениях хуже.
Если выйти на уровень менеджера или тимлида, то ситуация выглядит уже совсем иначе: я не пишу код, но под моим началом работают люди, которые пишут, а моя задача -- обеспечивать приемлемое качество и соответствие срокам. И вот при таком раскладе уже вовсе неочевидно, что агент справляется хуже среднего программиста. Фраза "индусский код" не про LLM придумана. Джуниор (и не только джуниор) тоже может неделю чего-то ваять и так ничего и не наваять.
Мне кажется, что вот таким фрустрирующим профессионалам стоит задуматься не о качестве агентов, а о качестве процессов. В небольшой компании достаточно иметь сильную команду, и на выходе явного шлака не получится. Но эта система не маштабируется: невозможно рассчитывать, что все вокруг талантливые, знающие, опытные и аккуратные. Но можно попытаться настроить конвейер так, что даже если на линии оказался не самый надёжный работник, сама система не позволит получить на выходе негодный продукт.
И ведь ничего концептуально нового тут нет: спецификации, code review, тестирование, метрики. Многое из этого мы не делали не потому, что мы не верим в подход, а потому что банально не хватает сил. Я доверяю Васе, шут с ним, с code review, Вася дичи не напишет. Если Петя сказал, что протестировал, не буду требовать автотестов в репозитории, чего уж там. А теперь это всё нагенерировать не очень обременительно, так что почему бы и нет.
В общем, для себя я сделал вывод, что надо полировать конвейер.
Автор этой статьи борется с какими-то просадками на наносекунды тут и там в то время как 95%+ софта пишется на на каком-нибудь Электроне. Всё, что описано в статье, совершенно разумно, но это уже какое-то выжимание последних капель, которое имеет смысл, если всё остальное сделано -- от алгоритмических оптимизаций до кастомных аллокаторов памяти.
В ООН порядка 200 стран, и безо всякого лампового социализма легко выбрать кучу такиих пар, где простолюдины первой страны завидовали бы простолюдинам второй. И ничего не меняется вообще, то есть эмпирически концепция не работает. Дальше уже можно рассужать, почему, но так или иначе, реальность такова.
Его очень трудно осмыслить, потому что автор ведёт себя так же, как и те, кого он критикует. Тут очень много соображений, которые подаются как данность (начиная от того, что никаким перераспределением денег и ББД проблему не решить и кончая тем, что к Кремниевой долине не читали Лакатоша и Фейерабенда), а если автор чего и пытается доказывать, то делает он это ссылкой на авторитет, как будто бы работа того или иного философа есть божественное откровение и истина в последней инстанции.
Очень много эмоций и необязательной критики тех, кто автору не нравится. Противоречия, которые уже подметили выше ("AI всех выкинет на улицу" а через пару абзацев "AI не может заменить людей"), а в конце всё равно какие-то несвежие идеи, типа давайте дадим больше контроля над технологиями людям а не корпорациям -- окей, но если технология меня заменит, а ББД всё равно "не работает", что радости с того, что технология в руках общества?.. Короче говоря, проблемы поднимаются понятные, но уровень дискуссии удручает.
Да, ситуация понятна, ну мы все живём "в процессе", и у меня нет твёрдого мнения по этому вопросу. Моя интуиция состоит в том, что концептуально правильно разделять этапы планирования и разработки, а каждая задача должна оставлять за собой некие осязаемые артефакты -- код, документацию, юнит-тесты. Разделение на планирование и код -- это такое же разделение, как на "багфикс", "рефакторинг", "новая функциональность". Вроде нет сомнений, что нехорошо в одном коммите совмещать багфикс и новое, но при этом превратить два предложения текста в три страницы кода через "магию" в голове -- как бы ок.
В принципе, тут же нет ничего нового: скажем, в TDD вы тоже по идее заранее пишете тесты (они же спеки по сути), а потом уже код. С другой стороны, многие классические рекомендации даются не потому, что они оптимальны, а потому что иначе нереалистично. Скажем, вы можете просить LLM делать себе код ревью хоть три раза в день, но коллега этого делать не будет.
Кроме того, разные этапы можно делать разными системами с разной ценой, если хочется сэкономить.
Признаться, я не читаю всё, что генерирует openspec. Я читаю хотя бы tasks.md (то есть чеклист) и общее описание design.md. Выгода (как мне кажется, на истину не претендую опять же) в том, что 1) после завершения работы только небольшая часть этого текста становится проектной документацией, вы получаете её бесплатно, и дальше при решении других задач LLM может читать документацию, а не лопатить сразу код (что опять же по идее должно экономить токены); 2) иногда в процессе работы LLM начинает автоматически жаловаться, что какой-то кусок кода не соответствует спецификации, а это сигнал -- надо перепроверить и исправить либо документ, либо код.
Глобально, помню, в какой-то книге было сказано, что если вы говорите, что не используете какую-то "методологию программирования", то вы просто не знаете, как она называется. Можно подходить к процессу по-разному, но надо отдавать себе отчёт в том, что конкретно происходит. Если у вас немного людей, и вы все на одной волне, может, и вправду незачем разжёвывать -- и так каждый понимает друг друга с полуслова. Но надо чётко осознавать особенности сетапа -- у кого-то так, у кого-то не так.
Скажем, мне комфортно думать в процессе письма, вот как сейчас. У меня есть коллега, который с ChatGPT общается голосом. Для меня это нонсенс, я не могу говорить и при этом думать. Но для него комфортно, что ж.
Я бы сказал, что это разумная критика, но она сама по себе настолько в общих чертах сформулирована, что непонятно, соглашаться или спорить. Дьявол в деталях.
С одной стороны, если я даю абзац текста подчинённому, и он пишет целую подсистему, я по сути уповаю на то, что он достаточно опытен, и у него в голове "логика, контекст и знание предметной области" совпадают с моими. На практике это поучается методика plug and pray, ну ок, небесспорно.
С другой стороны, "более подробными" по сравнению с чем? Очевидно, что английский текст не должен приближаться к Питону по объёму, но точно так же очевидно, что какие-то технические решения должны быть либо частью постановки задачи, либо запротоколированы уже после реализации, чтобы было понятно, что вот эта штука оптимизирует память, а не скорость, или наоборот, и так оно задумано.
Для меня очевидно, что три строчки текста из issue в качестве описания подсистемы явно мало. С другой стороны, конечно, надо избегать крайностей.
Ну я не вижу тут больших противоречий. В openspec описания полного устройства и не ожидается, всё по канонам agile. В идеале есть документ, который описывает общие принципы (используется такой-то фреймворк, такие-то архитектурные решения), и есть описание требуемой задачи, по сути github issue. А по мере закрытия задач растёт проектная документация.
Смотрите, даже если вы пишете небольшую функцию, которая у вас занимает 3 часа, всё равно вы отдельно её продумываете, и отдельно программируете, не так ли? И если что-то работает не так, у вас хотя бы в голове же есть картина -- проблема в постановке задачи или в реализации.
Соответственно, вы пишете спеку и по ней программируете задачу, потом следующую и так далее. Но на практике так никто не делает не потому, что это концептуально неправильно, а потому что нереально.
Но с появлением LLM это стало реально. Я сейчас почти все задачи для LLM прогоняю через OpenSpec, крому ну уж совсем мусорных на выброс. Я ему даю описание задачи (фактически github issue), дальше он генерирует несколько документов -- развёрнутое описание того, что надо сделать и чек-лист, он же "definition of done". Дальше запускается процесс, и если всё проходит хорошо, краткая выжимка этого всего (что конкретно сделано) становится частью документации проекта.
Ну вот за spec driven dev буду стоять - если бы было время и силы, в идеале разработка так бы и выглядела даже без всяких LLMs. Отделить планирование от кодирования - совершенно разумная цель, и очень хорошо, что её стало проще добиться.
Я понимаю эту логику, но рано или поздно мы всё равно упираемся в интуицию и наше восприятие. Исходная статья Вигнера называется "unreasonable effectiveness..." -- то есть оба слова апеллируют к нашей оценке: что такое (un)reasonable и что такое effective.
Это не баг и не дыра в логике. Это послание от человека к человеку: вот смотрите, мы на трёх буквах на своей планете можем кучу всего сделать, а можно себе вообразить обстоятельства, при которых понадобилось бы десять букв, причём для каждого раздела науки они бы работали по-разному. Удивительно? Ну а дальше собеседник, конечно, может сказать, что неудивительно. Ну ок :)
Я не вижу тут особых дыр. Вы говорите, что классическая физика ломается на абсолютном нуле или на температуре внутри звезды, или есть какие-то явления, которые мы не понимаем. Хорошо, Вигнер и не говорил, что мы понимаем всё, и что формулы работают на любых краях.
Он говорит: камни, о которых писал Галилей, падают одновременно не только в Пизе, но и везде на планете, и не только во времена Галилея, но и до сих пор. И неважно, идёт дождь или снег, в комнате мы или снаружи. Ну и далее идут рассуждеия о том, что одни и те же формулы по сути кочуют из одного раздела науки в другие.
То есть в опытах Галилея можно варьировать самые разные условия -- массу, географическую локацию, сезон, и оказывается, что эти вариации ни на что не влияют. Да, можно сказать, что это всё "локально работает", а внутри чёрной дыры не работает, но это рассуждения из стиля "стакан наполовину пуст": сравните с с цифровым миром, где вообще никакой локальности нет. В компьютерной программе можно поменять одну строку, и всё, она будет работать совсем по-другому.
Таким образом, Вигнер предлагает удивляться тому, что наука вообще работает хотя бы на каких-то масштабах и что нам в принципе удаётся перебрасываь мостики из одного раздела знаний в другие. И если эту точку зрения критиковать, надо апеллировать не к локальности и субъективности, а попробовать рассмотреть противоположный тезис: "нет ничего удивительного, что законы Галилея работают до сих пор, нет ничего удивительного, что одни и те же формулы повторяются..." Как-то так.
Мне кажется, вы излишне придираетесь. Используя ньютоновскую физику вы можете построить самолёт, который взлетит и пушку, которая стреляет куда надо. Вигнер в своей статье не пытался давать математических оценок. Он говорит ровно это: вот смотрите, вы можете с помощью простых формул делать практически пригодные предсказания на очень широком диапазоне явлений. А ещё одни и те же формулы практически без изменений можно переиспользовать, например, если считать, что газ состоит из "шариков", а средняя скорость шариков -- это температура, то можно из механики вывести термодинамику, хотя, казалось бы, где связь? Наверно, если хочется, можно переформулировать как "на человеческом масштабе всё на всё похоже и нехитро устроено", но даже в такой постановке это равно нетривиальное наблюдение.
Окей, забудем про голову, сам факт что банальное перемножение ma даёт формулу для F достаточно точно работает для объектов от молекул до планет уже весьма нетривиален. Почему так? Мы ведь знаем, что она неточна, есть квантовые и релятивисткие эффекты. А представтьте себе, что нам была бы нужна отдельная формула для F для массы через каждые 100 кг, например.
Вы просто можете не вводить понятие квалиа, которое далеко не очевидно существует. Сепульки она тоже не может объяснить, что делать.