Автор danluu.com: с нейросетями пора браться за более амбициозный софт

Отправная точка эссе: Майкл Малис (Michael Malis, автор pgrust, переписывания Postgres с помощью ИИ) с начала года показывает автору интересные результаты и в разговорах повторяет: «нам стоит быть амбициознее с софтом, который мы создаём». Автор оговаривается, что это реплика из неформальных бесед, и просит не придираться к разнице между «стоит» (should) и «можно» (can): сам он сказал бы «можно».

К проектам вроде pgrust отношение скептическое, потому что вокруг много низкокачественных ИИ-поделок. Автор признаёт, что и сам счёл бы pgrust очередной «халтурой», если бы не знал Малиса и не доверял его работе. Когда он всё же заглянул в проект (чтобы использовать его как пример), оказалось, что тестирование настолько тщательное, что нашло реальные ошибки в самом Postgres: числовую ошибку, из-за которой корректные операции SP-GiST могут завершаться сбоем; ошибку кэша формата, дающую неверные результаты в JSONPath; ошибку в pgcrypto, ломающую последующие операции; несколько ошибок безопасности памяти в загрузчике словарей; ошибку переполнения в типе money. Это не значит, что в pgrust нет багов, но, по мысли автора, даже если проект не состоится, попытка уже улучшила Postgres. Главный довод в пользу pgrust, производительность; если проект провалится, часть показанных оптимизаций может перейти в Postgres, Clickhouse и другие системы.

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

Первый пример автора. Услышав, что OpenAI будет использовать Cerebras для топовых моделей, он прикинул, на что уходило бы время его компьютера при модели в 10-100 раз быстрее. Узкими местами оказались бы ripgrep, компиляция Rust и накладные расходы на системные вызовы и файловую систему. Для уровня «работает у меня» всё это можно серьёзно улучшить, и он сделал движок регулярных выражений, который можно подстроить так, чтобы он обгонял универсальные библиотеки на нужной ему нагрузке; форк ripgrep на базе этого движка, быстрее на его рабочих задачах с codex (проект «ради забавы», текстовый индекс был бы лучше); и интерпретатор Rust, ускоряющий сборку его проектов. Переход с Mac на Linux сам по себе заметно снизил расходы на системные вызовы и файловые операции. Всё это заняло низкое однозначное число часов его времени; без знаний о регулярных выражениях, компиляторах и интерпретаторах на такой набор ушёл бы год и больше. Довести проекты до уровня «полезный продукт или открытый проект» потребовало бы гораздо больше работы.

По его прочтению, мысль Малиса в том, что людям даже не приходит в голову делать то, что теперь стало просто. Автор неделями видел в Twitter жалобы на медленную компиляцию Rust, хотя, по его мнению (он оговаривает «я думаю»), на тот момент она не была серьёзным узким местом. Люди, считает он, продолжают пользоваться «доагентной» моделью затрат: десять лет назад тот, кто писал новый компилятор из-за медленного старого, был из тех, кто вместо инди-игры начинает делать игровой движок и ничего не выпускает. Большинство продуктивных программистов до сих пор сторонятся такого, хотя теперь это разумно.

Второй пример, ИИ для настольной игры Azul, сильнее человека при равном времени на ход. С GPT-5.1/5.2 и без знаний об ИИ автор получил сверхчеловеческий результат примерно за 5 часов своего времени, а лучший на тот момент по видимости ИИ, примерно за 20 часов, причём он оказался сильнее людей, чем ИИ, которым жульничали на Board Game Arena. Тогда почти каждое предложение моделей было неверным, приходилось много направлять; прочитав статью, модель выдавала нечто лишь внешне похожее на описанный метод. Недавно Габриэль Кангуссу (Gabriel Cangussu) построил ИИ, который «разносит» ИИ автора, и, насколько тот может судить, потратил заметно меньше времени. Ключевое отличие, по разговору с ним, Fable 5.1 и Opus 5.5 гораздо лучше понимают ИИ для настольных игр.

Третий пример, сравнение приёмов верификации и тестирования на реализации zstd моделью GPT-5.6 Sol (режимы medium и xhigh). Когда автор повторил оценку с GPT-6 Astra, пришлось искать другие задачи, потому что модель стала слишком сильной: в реализации zstd она проходит все зарегистрированные тесты более чем в 99% случаев во всех условиях, даже заметно ухудшающих результат, например при TDD, и обходится примерно в $1. Автор перешёл на RFC IMAP, с которым GPT-5.6 Sol эффективно не справлялась, и на Pandoc, который нужно уметь читать и писать во множестве форматов.

Оговорка: утверждениям «всё просто работает, софт решён» автор не верит. Новые модели «с одного раза» делают больше, но он берётся за более амбициозное, где модели всё ещё буксуют, и с каждой моделью, по его ощущению, уходит дальше от «просто работает», потому что разрыв между тем, что модель может эффективно проверить без серьёзной помощи, и тем, что она может реализовать, растёт.

В конце автор честно предупреждает: чтобы публиковать больше, он пишет посты за полчаса и почти не редактирует, поэтому они хуже подкреплены. Строгих бенчмарков нет, были лишь быстрые сравнения; его интерпретатор Rust дал ускорение примерно в 50 раз на холодных сборках и в 2 раза на тёплых (кэшированных), но он не измерял это строго и даже не описал этот проект. В приложении приведён комментарий Йосси Крейнина (Yossi Kreinin, цитируется с разрешения): если автор опубликует текст, Крейнин напишет ответ о том, что большинству людей, наоборот, стоит быть менее амбициозными с ИИ-софтом, иначе их ждёт провал; многие задачи не подходят для «агентных циклов», так как нет чётких критериев «прошло/не прошло». Продолжение комментария в тексте оборвано.

Ключевые факты

• Автор блога danluu.com, отталкиваясь от слов Майкла Малиса (pgrust), считает: благодаря современным моделям проекты, ранее слишком большие, стали осуществимы, и браться за них стоит.
• Тестирование pgrust нашло реальные ошибки в самом Postgres (SP-GiST, JSONPath, pgcrypto, загрузчик словарей, переполнение в money), хотя автор не утверждает, что pgrust безошибочен.
• Свои движок регулярных выражений, форк ripgrep и интерпретатор Rust автор сделал за низкое однозначное число часов; без ИИ, по его оценке, ушёл бы год и больше.
• ИИ для Azul: с GPT-5.1/5.2 около 5 часов до сверхчеловеческого уровня и около 20 часов до сильнейшего на тот момент; с GPT-6 Astra zstd проходит все тесты более чем в 99% случаев при стоимости около $1.
• Автор предупреждает, что текст написан за полчаса без строгих замеров; в приложении Йосси Крейнин возражает, что большинству стоит быть менее амбициозными.

Почему это важно

Это личное свидетельство практика о том, как сменилась оценка трудоёмкости: задачи, на которые раньше ушёл бы год, теперь укладываются в несколько часов. Автор называет это «доагентной моделью затрат», которую люди продолжают носить в голове, и поэтому не берутся за решаемое. При этом он подчёркивает, что «всё решено» неверно: чем сильнее модель, тем больше он берёт задач на пределе её возможностей, а разрыв между умением модели проверять и умением реализовывать растёт.

Кому это важно

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

Как это применить

Из текста следует несколько приёмов. Прикинуть, где уходило бы время при значительно более быстрой модели, и улучшать именно эти места на уровне «работает у меня». Строить крупные проекты вместе с вдумчивым тестированием и замерами, как делает Малис, чьи тесты нашли ошибки в Postgres. Учитывать, что довести работу до качества «полезный продукт или открытый проект» потребует заметно больше усилий. Для областей, где вы не специалист, проверка результата моделью занимает время, так как нужно разобраться, что она должна была сделать.

Можно ли доверять

Это мнение одного автора, а не исследование. Сам он признаёт, что пишет пост за полчаса почти без правки, без строгих бенчмарков, а ускорения в 50 и 2 раза получены быстрым сравнением. Многое основано на личном опыте и на доверии к Малису: в pgrust автор сам не вникал, а нашёл примеры ошибок Postgres лишь при подготовке текста. Контраргумент Крейнина приведён в приложении, но его комментарий в доступном тексте оборван. Данных о производительности pgrust и о готовности проекта к промышленному использованию в тексте нет.

Риски и подводные камни

Автор сам называет риски: множество ИИ-проектов низкого качества, дутые бенчмарки и недоверие общества к ним. Крейнин утверждает, что многие задачи плохо подходят для «агентных циклов» из-за отсутствия чётких критериев «прошло/не прошло», и что большинству людей амбициозные проекты с ИИ грозят провалом. Кроме того, успех автора связан с конкретными моделями (в тексте названы GPT-5.1/5.2, GPT-5.6 Sol, GPT-6 Astra, Fable 5.1, Opus 5.5), а его проекты пока служат для личного использования.

«Нам стоит быть амбициознее с софтом, который мы создаём.»

— Майкл Малис (pgrust), в пересказе автора эссе из неформальных разговоров